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
