linux-kernel - Re: [PATCH 2/2] arm64: dts: rockchip: enable rk809 audio codec on the rk3568 evb1

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:   Wed, 23 Feb 2022 09:41:21 +0100
From:   Michael Riesch <michael.riesch@...fvision.net>
To:     Heiko Stuebner <heiko@...ech.de>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:     Rob Herring <robh+dt@...nel.org>, Liang Chen <cl@...k-chips.com>,
        frank-w@...lic-files.de
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: enable rk809 audio codec on the
 rk3568 evb1

Hello Heiko,

On 2/23/22 00:11, Heiko Stuebner wrote:
> Hi,
> 
> Am Dienstag, 22. Februar 2022, 18:50:04 CET schrieb Michael Riesch:
>> Enable the Rockchip RK809 audio codec on the Rockchip RK3568
>> EVB1. This requires the VCCIO_ACODEC voltage regulator to be set
>> to always on.
>>
>> Signed-off-by: Michael Riesch <michael.riesch@...fvision.net>
> 
> [...]
> 
>> @@ -282,6 +301,7 @@ regulator-state-mem {
>>  
>>  			vccio_acodec: LDO_REG4 {
>>  				regulator-name = "vccio_acodec";
>> +				regulator-always-on;
> 
> As this seems to supply the codec (in the rk809?) shouldn't the
> sound part model that relationship and handle regulators
> instead of requiring an arbitary regulator to be always on?

To be honest, I am not entirely sure. VCCIO_ACODEC is supplied by the
(LDO regulator part of the) RK809. As far as I can tell, the audio codec
part of the RK809 is powered internally. There is indeed a note "IO
Power = LDO4" (which corresponds to VCCIO_ACODEC) at the I2S interface,
which would make the RK809 the producer and a consumer of this voltage.
This could be modeled in the driver, but seeing that the rk808 driver
and the codec driver are directly coupled I think it would not change much.

I admit that I am going for the low-effort solution here, but it is done
in similar fashion on other boards. What do you think?

As to the other consumers of VCCIO_ACODEC: The microphone requires this
voltage, but is there a representation of an analog microphone?

And of course the voltage serves as supply for one of the PMU IO
(voltage) domains (vccio1). But I think here the principle is that the
IO voltage is only turned on if there is a peer on the other end, which
(most likely) consumes this voltage as well.

If you decide to accept the change as is, could you please fix up the
commit message "rk3568 evb1" -> "rk3568-evb1-v10" for consistency? This
did not occur to me when I sent the patches, sorry!

Best regards,
Michael

> 
> 
> Heiko
> 
>>  				regulator-min-microvolt = <3300000>;
>>  				regulator-max-microvolt = <3300000>;
>>  
>> @@ -366,6 +386,10 @@ regulator-state-mem {
>>  				};
>>  			};
>>  		};
>> +
>> +		codec {
>> +			mic-in-differential;
>> +		};
>>  	};
>>  };
>>  
>> @@ -386,6 +410,11 @@ touchscreen0: goodix@14 {
>>  	};
>>  };
>>  
>> +&i2s1_8ch {
>> +	rockchip,trcm-sync-tx-only;
>> +	status = "okay";
>> +};
>> +
>>  &mdio0 {
>>  	rgmii_phy0: ethernet-phy@0 {
>>  		compatible = "ethernet-phy-ieee802.3-c22";
>>
> 
> 
> 
>