On Tue, Jul 17, 2018 at 04:55:10PM -0700, Doug Anderson wrote: > Hi, > > On Tue, Jul 17, 2018 at 4:42 PM, Matthias Kaehlcke <[email protected]> wrote: > > On Thu, Jul 12, 2018 at 02:09:04PM +0530, Amit Kucheria wrote: > >> We also split up the regmap address space into two, for the TM and SROT > >> registers. This was required to deal with different address offsets for the > >> TM and SROT registers across different SoC families. > >> > >> 8996 has two TSENS IP blocks, initialise the second one too. > >> > >> Since tsens-common.c/init_common() currently only registers one address > >> space, the order is important (TM before SROT). This is OK since the code > >> doesn't really use the SROT functionality yet. > >> > >> Signed-off-by: Amit Kucheria <[email protected]> > >> Reviewed-by: Bjorn Andersson <[email protected]> > >> Tested-by: Matthias Kaehlcke <[email protected]> > >> --- > >> arch/arm64/boot/dts/qcom/msm8996.dtsi | 14 ++++++++++++-- > >> 1 file changed, 12 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi > >> b/arch/arm64/boot/dts/qcom/msm8996.dtsi > >> index 8c7f9ca..688e752 100644 > >> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi > >> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi > >> @@ -459,9 +459,19 @@ > >> status = "disabled"; > >> }; > >> > >> - tsens0: thermal-sensor@4a8000 { > >> + tsens0: thermal-sensor@4a9000 { > > ~~~~~~ > > > > I suppose the address of the TM block is used here instead of the SROT > > address (which is lower) since SROT functionality is currently not > > used. Would/should this change if/when the driver uses SROT? > > For device tree you're always supposed to use the address of the first > "reg" listed as the unit address in the node name. It doesn't matter > if it's bigger or smaller as long as it's the first one listed. > > The bindings indicate that the TM block should be listed as the first > register. This won't change even if you start using SROT.
Thanks for the clarification, there is always something more to learn! Reviewed-by: Matthias Kaehlcke <[email protected]>
