(Under Verification) [TDM_Dev] os/board/rtl8730e: fix dma buffer interleaving for TDM

[lhenry-realtek]

Fix DMA interleaving for 8 channel mode when different data format is used in TDM

Data format can now be controlled by setting the configuration struct of the i2s tdm device

When left-justified mode is used, the BCLK will be inverted, but the slots should be correctly assigned instead of following default mapping

[allen-kim-sec]

@lhenry-realtek

TDM is not correctly working.

1. Sudden Stop channels : first 4msec data is correct , but Next data has corrupt
2. why FSync as high when we choose Rising Edge? Low level is correct without delay .
3. it has stopped duration for 909.67 usec. BCLK is continuously working but FSync is stopped

describe the result of this commit

• first status MCLK ( as Low ) , BLCK ( as LOW ) , FSYNC ( as High ) , DIN0 ( as High )
• first BCLK Rising Edge in 2.08 usec from MCLK Rising Edge , MCLK falling Edge at the first Rising Edge of BCLK
• first FSYNC Falling Edge 104.74us from the first BCLK Rising Edge
• It transfer the available data to start Transfer after the First Rising Edge of FSYNC
• the current configuration code is sampling at FALLING Edge for available data.
• first 4 msec is okay
• FSYNC is stopped during 909.67usec as High Level
  . actuall ch.121 data received ( 120 ch is available , 121ch data is corrupt
• Next TDM Fram is leaking ( 3.98405 msec from Rising FSync to the end of Rising FSync , Only 6ch are avaliable )

[allen-kim-sec]

@lhenry-realtek

TDM is not correctly working.

Please sugguest the proper configuration to get 100% capturing.
it is possible to change FSYNC activated as Falling Edge ?

1Sudden Stop channels : first 4msec data is correct , but Next data has corrupt
why FSync as high when we choose Rising Edge? Low level is correct without delay .
it has stopped duration for 909.67 usec. BCLK is continuously working but FSync is stopped
describe the result of this commit

first status MCLK ( as Low ) , BLCK ( as LOW ) , FSYNC ( as High ) , DIN0 ( as High )
first BCLK Rising Edge in 2.08 usec from MCLK Rising Edge , MCLK falling Edge at the first Rising Edge of BCLK
first FSYNC Falling Edge 104.74us from the first BCLK Rising Edge
It transfer the available data to start Transfer after the First Rising Edge of FSYNC
the current configuration code is sampling at FALLING Edge for available data.
first 4 msec is okay
FSYNC is stopped during 909.67usec as High Level
. actuall ch.121 data received ( 120 ch is available , 121ch data is corrupted
Next TDM Fram is leaking ( 3.98405 msec from Rising FSync to the end of Rising FSync , Only 6ch are avaliable )

[lhenry-realtek]

Please sugguest the proper configuration to get 100% capturing.
it is possible to change FSYNC activated as Falling Edge ?

Hi @allen-kim-sec

I am currently testing Left Justified mode, There is no difference from regular mode other than FS/WS/LRCLK inverted, the data received in DMA buffer is still the same, just in different order

Left Justified mode will simply swap this around

I am checking on the waveform again, so far the signal may appear correct but I have noticed that the LA sometimes show 1bit difference from the DMA buffer. The DMA buffer is consistent and within range of each sample, the LA is showing sometimes dropping 1 bit and then other samples are OK

Currently trying to generate a valid TDM signal with another board and try to RX it

[allen-kim-sec]

Please sugguest the proper configuration to get 100% capturing.
it is possible to change FSYNC activated as Falling Edge ?

Hi @allen-kim-sec

I am currently testing Left Justified mode, There is no difference from regular mode other than FS/WS/LRCLK inverted, the data received in DMA buffer is still the same, just in different order

Left Justified mode will simply swap this around

I am checking on the waveform again, so far the signal may appear correct but I have noticed that the LA sometimes show 1bit difference from the DMA buffer. The DMA buffer is consistent and within range of each sample, the LA is showing sometimes dropping 1 bit and then other samples are OK

Currently trying to generate a valid TDM signal with another board and try to RX it

I don't want to argue about what is right or wrong; I just want you to provide the correct answer to my request. In reality, only the first 64 samples are read accurately, and too many samples are lost. Whether there is a 1 clock delay or not, it doesn't matter; the method used is irrelevant, and all transmitted data must be received without any loss. For stable buffering, I want the interrupt and buffer to work properly, and I hope that all data is accurately captured at a lower level before the OS driver transfers the accumulated buffer to the application.

[allen-kim-sec]

@lhenry-realtek

I2S can use both ; Falling and Rising Edge Sampling condition.
typically TX generate signal after the Falling Edge of BCLK , Receiver can cature signal at the Rising Edge of BCLK..
sampling at Falling Edge of Clock if Data valid Clock Edge is Falling Edge Mode. the above figures are "Rising Edge" because Generated Signal after the Falling Edge.

I don't want to argue about what is right or wrong; I just want you to provide the correct answer to my request. In reality, only the first 64 samples are read accurately, and too many samples are lost. Whether there is a 1 clock delay or not, it doesn't matter; the method used is irrelevant, and all transmitted data must be received without any loss. For stable buffering, I want the interrupt and buffer to work properly, and I hope that all data is accurately captured at a lower level before the OS driver transfers the accumulated buffer to the application.

[lhenry-realtek]

I will close this PR and move changes to #6968