Re: [PATCH v2 0/4] arm: qcom: qcom-apq8064: add separate device node for tsens

[Bjorn Andersson <bjorn.andersson@linaro.org>]

On Tue 12 Apr 12:20 PDT 2022, Dmitry Baryshkov wrote:

> On Tue, 12 Apr 2022 at 21:43, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Dmitry Baryshkov (2022-04-06 12:57:30)
> > > On Wed, 6 Apr 2022 at 18:40, Stephen Boyd <sboyd@kernel.org> wrote:
> > > >
> > > > Quoting Dmitry Baryshkov (2022-04-05 17:26:44)
> > > > > Currently gcc-msm8960 driver manually creates tsens device. Instantiate
> > > > > the device using DT node instead. This follow the IPQ8064 device tree
> > > > > schema.
> > > >
> > > > Why can't the schema be changed?
> > >
> > > But these commits change the schema. They make apq8064 follow more
> > > logical scheme of ipq8064.
> > >
> >
> > Sounds like ipq8064 and apq8064 follow different schemas. Is there any
> > benefit to harmonizing the two vs. just leaving it as it is in the dts
> > and making the schema match whatever the dts has?
> 
> I'd prefer to harmonize them. It makes no sense to have two different
> approaches for the single IP block (shared between ipq and apq/msm).
> And having a separate device tree node for the tsens removes a
> dependency from gcc on the nvmem/qfprom.
> Note, upstream qcom-msm8960.dtsi doesn't describe tsens at all, so we
> don't have to worry about it.
> 

The apq8064 design was chosen in order to make the dts represent the GCC
being a single hardware block, and the fact that this is a clock and a
thermal driver in Linux is an implementation decision.

Seems like we forgot about this decision when we introduce the
ipq8064...


I'm not against harmonizing the two, but I don't see any changes to
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml and the
clock patch describes what happens, but not why (i.e. if it's to
harmonize the implementations the commit message should say so).

Regards,
Bjorn