Message ID | 20220406002648.393486-1-dmitry.baryshkov@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | arm: qcom: qcom-apq8064: add separate device node for tsens | expand |
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?
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.
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?
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.
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
On 12/04/2022 23:08, Bjorn Andersson wrote: > 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). Nice catch. I forgot about the gcc-apq8064 schema. Will fix in the next iteration.