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
