[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5467add6-0099-4e54-a4f7-12aa149d03c7@bootlin.com>
Date: Thu, 21 Mar 2024 16:14:04 +0100
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Péter Ujfalusi <peter.ujfalusi@...il.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>
Cc: linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>, herve.codina@...tlin.com,
christophercordahi@...ometrics.ca
Subject: Re: [PATCH 13/13] ASoC: ti: davinci-i2s: Opitonally drive DX pin
during capture streams
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
Powered by blists - more mailing lists