linux-kernel - Re: [PATCH 13/13] ASoC: ti: davinci-i2s: Opitonally drive DX pin during capture streams

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 22 Mar 2024 09:58:52 +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/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