lkml.org 
[lkml]   [2017]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-sunxi] Re: [PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3
在 2017-09-18 16:30,Maxime Ripard 写道:
> On Mon, Sep 18, 2017 at 03:36:43PM +0800, Icenowy Zheng wrote:
>> 于 2017年9月18日 GMT+08:00 下午3:33:36, Maxime Ripard
>> <maxime.ripard@free-electrons.com> 写到:
>> >On Thu, Sep 14, 2017 at 10:52:46PM +0800, Icenowy Zheng wrote:
>> >> Allwinner H3 features a thermal sensor like the one in A33, but has
>> >its
>> >> register re-arranged, the clock divider moved to CCU (originally the
>> >> clock divider is in ADC) and added a pair of bus clock and reset.
>> >>
>> >> Update the binding document to cover H3.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
>> >> ---
>> >> Changes in v4:
>> >> - Add nvmem calibration data (not yet used by the driver)
>> >> Changes in v3:
>> >> - Clock name changes.
>> >> - Example node name changes.
>> >> - Add interupts (not yet used by the driver).
>> >>
>> >> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 30
>> >++++++++++++++++++++--
>> >> 1 file changed, 28 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> >b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> >> index badff3611a98..6c470d584bf9 100644
>> >> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> >> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> >> @@ -4,12 +4,26 @@ The Allwinner SoCs all have an ADC that can also
>> >act as a thermal sensor
>> >> and sometimes as a touchscreen controller.
>> >>
>> >> Required properties:
>> >> - - compatible: "allwinner,sun8i-a33-ths",
>> >> + - compatible: must contain one of the following compatibles:
>> >> + - "allwinner,sun8i-a33-ths"
>> >> + - "allwinner,sun8i-h3-ths"
>> >> - reg: mmio address range of the chip,
>> >> - #thermal-sensor-cells: shall be 0,
>> >> - #io-channel-cells: shall be 0,
>> >>
>> >> -Example:
>> >> +Optional properties:
>> >> + - nvmem-cells: A phandle to the calibration data provided by a
>> >nvmem device.
>> >> + If unspecified default values shall be used.
>> >> + - nvmem-cell-names: Should be "calibration-data"
>> >
>> >I'd prefer to have which sensor it applies to here. It wouldn't change
>> >anything for the H3, but it definitely does for example for the A83t
>> >that has two sensors, one for each cluster, and one for the GPU, each
>> >with calibration data.
>> >
>> >What about cluster0-calibration?

I prefer sensor0-calibration to sensor3-calibration now.
(Theortically the new generation THS can support up to 4 sensors)

>>
>> The calibration data is in fact a 2 word (8 bytes) zone,
>> which is reserved for 4 sensors on all SoCs, even on H3.
>> It's half word per sensor.
>>
>> I prefer to just assume a 2 word cell for every SoC.
>
> You have three different data sources, it should be reprensented as
> such.
>
> Otherwise, the client has to get some knowledge of how the data are
> stored in the provider, which is an abstraction violation.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

\
 
 \ /
  Last update: 2017-09-18 17:47    [W:0.075 / U:0.192 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site