On Fri, May 31, 2024 at 03:04:51PM +0530, Taniya Das wrote:
>
>
> On 3/18/2024 1:24 PM, Krzysztof Kozlowski wrote:
> > On 18/03/2024 06:35, Taniya Das wrote:
> > > Certain clocks are not accessible on QCM6490-IDP board,
> > > thus mark them as protected. Update the lpassaudio node to
> > > support the new compatible.
> > >
> > > Signed-off-by: Taniya Das <quic_tdas@xxxxxxxxxxx>
> > > ---
> >
> > >
> > > +&gcc {
> > > + protected-clocks = <GCC_AGGRE_NOC_PCIE_1_AXI_CLK> ,<GCC_PCIE_1_AUX_CLK>,
> > > + <GCC_PCIE_1_AUX_CLK_SRC>, <GCC_PCIE_1_CFG_AHB_CLK>,
> > > + <GCC_PCIE_1_MSTR_AXI_CLK>, <GCC_PCIE_1_PHY_RCHNG_CLK_SRC>,
> > > + <GCC_PCIE_1_PIPE_CLK>, <GCC_PCIE_1_PIPE_CLK_SRC>,
> > > + <GCC_PCIE_1_SLV_AXI_CLK>, <GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
> > > + <GCC_QSPI_CNOC_PERIPH_AHB_CLK>, <GCC_QSPI_CORE_CLK>,
> > > + <GCC_QSPI_CORE_CLK_SRC>,<GCC_USB30_SEC_MASTER_CLK>,
> > > + <GCC_USB30_SEC_MASTER_CLK_SRC>, <GCC_USB30_SEC_MOCK_UTMI_CLK>,
> > > + <GCC_USB30_SEC_MOCK_UTMI_CLK_SRC>,
> > > + <GCC_USB30_SEC_MOCK_UTMI_POSTDIV_CLK_SRC>, <GCC_USB30_SEC_SLEEP_CLK>,
> > > + <GCC_USB3_SEC_PHY_AUX_CLK>, <GCC_USB3_SEC_PHY_AUX_CLK_SRC>,
> > > + <GCC_USB3_SEC_PHY_COM_AUX_CLK>, <GCC_USB3_SEC_PHY_PIPE_CLK>,
> > > + <GCC_USB3_SEC_PHY_PIPE_CLK_SRC>, <GCC_CFG_NOC_LPASS_CLK>,
> > > + <GCC_MSS_GPLL0_MAIN_DIV_CLK_SRC>, <GCC_MSS_CFG_AHB_CLK>,
> > > + <GCC_MSS_OFFLINE_AXI_CLK>, <GCC_MSS_SNOC_AXI_CLK>,
> > > + <GCC_MSS_Q6_MEMNOC_AXI_CLK>, <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
> > > + <GCC_SEC_CTRL_CLK_SRC>, <GCC_WPSS_AHB_CLK>,
> > > + <GCC_WPSS_AHB_BDG_MST_CLK>, <GCC_WPSS_RSCP_CLK>;
> > > +};
> > > +
> > > +&lpass_audiocc {
> > > + compatible = "qcom,qcm6490-lpassaudiocc";
> >
> > What? Why do you override compatible for given board? This is a SoC
> > block, not board!
>
> On QCM6490-IDP and QCS690-RB3Gen2 boards, the HLOS Audio driver requires the
> support for the reset functionality only from the LPASS region.
> Rest of the clocks functionality is controlled from LPASS firmware.
>
> Hence, in the earlier series we marked all the clocks as protected and
> introduced new "qcom,adsp-skip-pll" flag to skip PLL configurations.
> But as the flag was also not approved and the ask was to use the compatible
> string, we went ahead with this approach.
Is this also applicable for the QCM6490 FairPhone5? If so, maybe it's
time to have qcm6490.dtsi.
--
With best wishes
Dmitry
