Hi Péter,
On 3/20/24 21:30, Péter Ujfalusi wrote:
On 20/03/2024 17:42, Péter Ujfalusi wrote:
On 15/03/2024 13:27, Bastien Curutchet wrote:
The McBSP's DX pin that outputs serial data during playback streams can be used during capture streams to repeatedly output a chosen pattern. For instance, this can be useful to drive an active-low signal during captures (by choosing <0> as output pattern).
Are there really any other use of this than to pull down or up the DX pin (0 or 0xffff)
I don't know, indeed today I can only think about these two patterns. I tried to do something in a 'generic' way so it can evolve if needed.
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. * 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.
Bast regards, Bastien