linux-kernel - Re: [RFC PATCH v1 2/2] iio: adc: meson: add support for the GXLX SoC

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: <5CEDC847-2653-42F3-A85E-A06D6E5DB135@gmail.com>
Date: Mon, 6 Jan 2025 17:44:56 +0400
From: Christian Hewitt <christianshewitt@...il.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
 linux-amlogic@...ts.infradead.org,
 linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org,
 gnstark@...utedevices.com,
 lars@...afoo.de,
 robh@...nel.org,
 krzk+dt@...nel.org,
 conor+dt@...nel.org
Subject: Re: [RFC PATCH v1 2/2] iio: adc: meson: add support for the GXLX SoC

> On 5 Jan 2025, at 7:49 pm, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
> 
> Hi Jonathan,
> 
> On Sat, Jan 4, 2025 at 2:59 PM Jonathan Cameron <jic23@...nel.org> wrote:
>> 
>> On Tue, 31 Dec 2024 20:42:07 +0100
>> Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
>> 
>>> The SARADC IP on the GXLX SoC itself is identical to the one found on
>>> GXL SoCs. However, GXLX SoCs require poking the first three bits in the
>>> MESON_SAR_ADC_REG12 register to get the three MPLL clocks (used as clock
>>> generators for the audio frequencies) to work.
>>> 
>>> The reason why there are MPLL clock bits in the ADC register space is
>>> entirely unknown and it seems that nobody is able to comment on this.
>>> So clearly mark this as a workaround and add a warning so users are
>>> notified that this workaround can change (once we know what these bits
>>> actually do).
>> 
>> So IIUC this is to make some non ADC component work.
> That's correct
> 
>> How are you handling dependencies?  The ADC driver might not be loaded or
>> is there some reason it definitely is at the point where the audio driver
>> loads?
> Unfortunately there are no dependencies at the moment.
> To me it's not even 100% clear if those bits are a dependency for the
> audio IP or if they are instead linked with the clock controller (more
> background info: some of the MPLL clocks are - at least in theory, in
> practice we don't use that - are also used as input for the Mali GPU
> and video subsystem. The only practical usage that I'm aware of is the
> audio controller).

In my testing it makes no difference to the audio driver when the adc
bit poke is done. The audio driver probes and loads and you can play
media without generating any visible errors. There’s just no audible
output on GXLX until the poke - it’s like hitting an un-mute button.

For the series:

Tested-by: Christian Hewitt <christianshewitt@...il.com>

Christian

> Christian and I have both tried with all of our contacts at Amlogic
> but did not get any answers.
> If I knew the purpose of these bits I'd model them as whatever they
> are (resets, clock gates, ...) and provide proper dt-bindings.
> 
> 
> Best regards,
> Martin