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:   Mon, 26 Jun 2023 16:43:23 +0530
From:   Mohammad Rafi Shaik <quic_mohs@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <swboyd@...omium.org>,
        <andersson@...nel.org>, <broonie@...nel.org>, <agross@...nel.org>
CC:     <robh+dt@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_rohkumar@...cinc.com>, <srinivas.kandagatla@...aro.org>,
        <dianders@...omium.org>, <judyhsiao@...omium.org>,
        <quic_visr@...cinc.com>,
        Srinivasa Rao Mandadapu <quic_srivasam@...cinc.com>
Subject: Re: [RESEND v6 6/8] arm64: dts: qcom: sc7280: Modify VA/RX/TX macro
 clock nodes for audioreach solution


On 6/16/2023 4:59 PM, Konrad Dybcio wrote:
> On 16.06.2023 12:35, Mohammad Rafi Shaik wrote:
>> From: Srinivasa Rao Mandadapu <quic_srivasam@...cinc.com>
>>
>> Modify VA, RX and TX macro and lpass_tlmm clock properties and
>> enable them. For audioreach solution mclk, npl and fsgen clocks
>> are enabled through the q6prm clock driver.
>>
>> Delete the power domain properties from VA, RX and TX macro,
>> for audioreach solution the macro, dcodec power domains enabled
>> through the q6prm clock driver.
>>
>> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@...cinc.com>
>> Signed-off-by: Mohammad Rafi Shaik <quic_mohs@...cinc.com>
>> ---
> Maybe sc7280-audioreach.dtsi containing all these changes that could be
> reused by others would be in order?
Thanks for comment,

yes, will create a common sc7280-audioreach.dtsi file, which will 
contain common audioreach changes
and could be reused by others.
>>   .../sc7280-herobrine-audioreach-wcd9385.dtsi  | 43 +++++++++++++++++++
>>   1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-audioreach-wcd9385.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine-audioreach-wcd9385.dtsi
>> index 9daea1b25656..c02ca393378f 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-audioreach-wcd9385.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-audioreach-wcd9385.dtsi
>> @@ -196,3 +196,46 @@ q6prmcc: clock-controller {
>>   		};
>>   	};
>>   };
>> +
>> +&lpass_rx_macro {
>> +	/delete-property/ power-domains;
>> +	/delete-property/ power-domain-names;
> Surely they shouldn't cause issues, even if the vote would be
> superfluous? They are still powered by these power domains, I'd assume?
No, In Audioreach case this macro and decodec clocks are not power by 
power domains,
this macro and decodec hw clocks are enrolled by q6prmcc clock voting.
>> +	clocks = <&q6prmcc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_CLK_ID_TX_CORE_NPL_MCLK  LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&lpass_va_macro>;
>> +	clock-names = "mclk", "npl", "macro", "dcodec", "fsgen";
> The drivers use clk_get with name-based lookup.. you should be able to
> simply extend the list in the common DTSI. Please test that on both
> audioreach and the other thing though.
>
> Konrad
The clock names are not a extensions, same set of clocks are used in non 
ADSP solutions.
In Audioreach solution these clocks enabling by q6prmcc clock voting.

Rafi.
>> +
>> +	status = "okay";
>> +};
>> +
>> +&lpass_tlmm {
>> +	clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>> +	clock-names = "core", "audio";
>> +};
>> +
>> +&lpass_tx_macro {
>> +	/delete-property/ power-domains;
>> +	/delete-property/ power-domain-names;
>> +	clocks = <&q6prmcc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_CLK_ID_TX_CORE_NPL_MCLK  LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&lpass_va_macro>;
>> +	clock-names = "mclk", "npl", "macro", "dcodec", "fsgen";
>> +
>> +	status = "okay";
>> +};
>> +
>> +&lpass_va_macro {
>> +	/delete-property/ power-domains;
>> +	/delete-property/ power-domain-names;
>> +	clocks = <&q6prmcc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> +		 <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>> +	clock-names = "mclk", "macro", "dcodec";
>> +
>> +	status = "okay";
>> +};

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ