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]

Message-ID: <d20dc37c-13fa-43d1-af52-dce8d8dcdd75@gmail.com>
Date: Wed, 20 Mar 2024 22:30:57 +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



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?

-- 
Péter