Re: [PATCH 2/3] thermal: add support for the thermal sensor on Allwinner new SoCs

From: Maxime Ripard
Date: Thu Mar 09 2017 - 09:31:42 EST


On Thu, Mar 09, 2017 at 08:36:24AM +0800, Icenowy Zheng wrote:
>
>
> 02.03.2017, 22:11, "Maxime Ripard" <maxime.ripard@xxxxxxxxxxxxxxxxxx>:
> > On Thu, Mar 02, 2017 at 12:02:13AM +0800, Icenowy Zheng wrote:
> >> Â2017å3æ1æ 23:56ä Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>åéï
> >> Â>
> >> Â> On Wed, Mar 01, 2017 at 06:20:51PM +0800, Icenowy Zheng wrote:
> >> Â> >
> >> Â> > 2017å3æ1æ 18:14ä Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>åéï
> >> Â> > >
> >> Â> > > On Tue, Feb 28, 2017 at 03:18:13PM +0800, Icenowy Zheng wrote:
> >> Â> > > >
> >> Â> > > > 2017å2æ28æ 14:44ä Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>åéï
> >> Â> > > > >
> >> Â> > > > > On Tue, Feb 28, 2017 at 03:40:53AM +0800, Icenowy Zheng wrote:
> >> Â> > > > > > From: Ondrej Jirman <megous@xxxxxxxxxx>
> >> Â> > > > > >
> >> Â> > > > > > Allwinner SoCs from H3 (including H5, A64, etc) have a new version of
> >> Â> > > > > > thermal sensor, and needs a new driver for it.
> >> Â> > > > > >
> >> Â> > > > > > Add such a driver.
> >> Â> > > > > >
> >> Â> > > > > > Currently only H3 is supported, but other SoCs are easily to be
> >> Â> > > > > > supported by adding new formula and set the sensor number.
> >> Â> > > > > >
> >> Â> > > > > > Signed-off-by: OndÅej Jirman <megous@xxxxxxxxxx>
> >> Â> > > > > > [Icenowy: extend to support further multiple-sensor SoCs, change commit
> >> Â> > > > > >Â message]
> >> Â> > > > > > Signed-off-by: Icenowy Zheng <icenowy@xxxxxxxx>
> >> Â> > > > >
> >> Â> > > > > There's no need to create a new driver for that. This can be handled
> >> Â> > > > > by the GPADC driver we already have.
> >> Â> > > >
> >> Â> > > > sun8i-ths is not GPADC at all.
> >> Â> > > >
> >> Â> > > > The latest SoC I know that use GPADC as thermal sensor is A33.
> >> Â> > >
> >> Â> > > It's not called the same way, but it definitely is an evolution of the
> >> Â> > > same controller. There's no need for a new driver, only reworking what
> >> Â> > > is already there.
> >> Â> >
> >> Â> > I don't think so -- here's some evidence:
> >>
> >> ÂBut the H3 THS have many new IRQs, functions, different sampling
> >> Ârate set method and a quite different register layout.
> >>
> >> ÂDoing this in GPADC driver is possible but meaningless.
> >>
> >> Â> >
> >> Â> > 1. The old GPADC do not have module clock.
> >> Â>
> >> Â> The A33 could use a PLL.
> >>
> >> ÂBut it's a dedicated mod clk on new generation THS.
> >
> > And all of this really are evolutions. The block is still driven in
> > the exact same way. And this is where there is value in having the
> > same driver: you share the logic, which is mostly common, instead of
> > duplicating it.
>
> After some thinking, I can accept a common driver for A23/A33 thermal
> sensor and H3/A64/H5 ones, but I cannot accept use iio-sun4i-gpadc
> driver for it, as now H3/A64/H5 thermal sensors are not just an ADC --
> they features hardware alarm levels, and in some SoC it become a
> multiple channel thermal sensor.

The A23 and A33 is trivial to support on the already existing GPADC
driver. If you have it already working on the A33, then the amount of
work for your driver to support the A33, or for the GPADC to support
the newer SoC is strictly the same.

Except in one case, we have a common, debugged, already reviewed and
already merged driver. In the other case, we have no such things.

> I will insist on doing a dedicated driver for it, or if you like, I can add
> A23/A33 support to this driver. (Considering no one have already posted
> any patches for A23/A33 thermal sensor, except my old ones, so my
> work at least won't conflict with anything merged)

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474821.html

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Attachment: signature.asc
Description: PGP signature