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 for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ