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: Thu, 21 Mar 2024 20:31:33 +0200
From: Péter Ujfalusi <peter.ujfalusi@...il.com>
To: Bastien Curutchet <bastien.curutchet@...tlin.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 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?

>  * 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?

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?

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?

-- 
Péter