On Tue 12 Apr 12:20 PDT 2022, Dmitry Baryshkov wrote: > On Tue, 12 Apr 2022 at 21:43, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > > > Quoting Dmitry Baryshkov (2022-04-06 12:57:30) > > > On Wed, 6 Apr 2022 at 18:40, Stephen Boyd <sboyd@xxxxxxxxxx> 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
