Hi Péter,
On 3/21/24 19:31, Péter Ujfalusi wrote:
Hi Bastien,
On 3/21/24 17:14, Bastien Curutchet wrote:
I think the definition of the 'ti,drive-dx' is somehow odd. It allows you to set it to 0x1234 and the DX pin will show 0x1234 when you capture 32bit. If you capture 16bit then it will transmit 0x12 (or 0x34?), no? If you have 4 channel capture then I won't speculate what will be on the DX pin ;)
Would not be better to say that the DX pin will be driven low or high during capture _and_ disable the playback support?
After some thinking, it might be still better to use the DX pin as GPIO and either have a custom machine driver which would handle it (set low when a capture trigger happens) or connect it in DAPM as a supply, bias or something and ASoC would handle it automagically.
I think that would be cleaner in many ways. What do you think?
I agree, that would be cleaner. I ran a few tests to see if that would work on my hardware. It doesn't ... So I looked back to the schematics and found two reasons : * the DX pin needs to be in sync with the clock.
I'm not sure what this means, sync with which clock?
Sorry, that was not very clear, I meant sync with the bit block that is output on McBSP.CLKR pin.
* the DX pin needs to be in a high-impedance state between two frames so a pull-up can drive it back up. Actually, the DX pin is also linked to the FSR pin so it provides the frame clock to the capture stream.
Hrm, you are using the DX pin as FSR for the capture? Why not McBSP.FSR pin >
The McBSP.FSR pin is used for the capture but is driven by the McBSP.DX pin. Both pins are linked together.
Looking back to the patch, one thing stood out: you are setting the XDATDLY to 2. You have some sort of T1 framing on the bus? The pullup will make the DX line high in for the framing bit, right? > Or you simulate another FSR line with T1 framing DX?
Yes the goal is to simulate an FSR.
The 'ti,drive-dx' sounds like a bad property for sure, you have T1 framing and driving the DX to certain level. It is like DSP_A (1 bit delay) playing constant 0x2 ?
Can you use aplay /dev/zero and a DT property to select T1 framing for the playback? Or that would be too coarse for timing the start of playback and capture?
That's a good idea, thank you. I'll try this and come back to you.
Best regards, Bastien