Re: [Q] tps65185 EPD PMIC temperature interface - which subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 30 Apr 2021 20:02:13 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:

> On Fri, Apr 30, 2021 at 11:24:04PM +0200, Andreas Kemnade wrote:
> > Hi,
> > 
> > I am going about to clean up stuff to further upstream support for my
> > ebook readers. One question arises about the temperature interface of
> > the EPD PMIC. Vendor code uses regulator_get_voltage in the EPDC
> > driver to read a temperature in celsius and provides temperature through
> > the regulator interface (besides sysfs/hwmon). That is ugly. But what
> > are the options, if a kernel consumer should be able to reference it via
> > devicetree phandle and read out from it? I see temperature sensors
> > both in the iio and the hwmon subsystem, but do not find a description
> > why these things are there. If I put it into the iio-subsystem
> > iio_channel_get() and friends can be used, if I understand things
> > correctly, there are no such functions in the hwmon subsystem, so I
> > would not be able to use it there. So the better choice is to put it
> > into the iio subsystem?
> >   
> 
> I am guessing a bit here since a lot of context is missing. Presumably
> there is a regulator driver. That regulator driver could register itself
> with the hwmon subsystem using [devm_]hwmon_device_register_with_info()
> and tell it to register a thermal zone sensor. It should then be possible
> to read the temperature of that sensor using thermal_zone_get_temp().
> 
Well, I try to give first some missing context. It is about temperature
compensation, not cooling vs. overheating protection. EPDs behave
different at different temperatures, so the driver needs a temperature
to compensate for it.
EPDs need also a bit more exotic voltages, so usually there is a
separate PMIC for them. Usually that PMIC can also deliver a
temperature. So drivers for that should consist of
- mfd (obvious)
- regulator (also obvious)
- something for providing the temperature (and that "something" is not
  that clear to me as there are several subsystems dealing with
  temperature)

 
And on EPD controller side I would like to be able to define (besides
other things) in the device tree
  epd-temperature = <&some_sensor>;

So your idea was to have that temperature sensor as a hwmon and
providing also a thermal_sensor. If I understand correcly that would
also require me to define a thermal zone where I can add the
thermal sensor and which I could then reference somewhere.
According to devicetree/bindings/thermal/thermal-zones.yaml defining
trip points is required. That does not make sense in this context So I
am wondering whether I am right there since it is not about
overheating but about compensation. And there is only a
thermal_zone_get_zone_by_name() but not a thermal_zone_get_sensor_by_name().
Maybe I am getting something wrong.
Vendor kernels in the wild additionally provide temperature by abusing
the regulator API which is IMHO not acceptable.

But if that thing would in to the iio subsystem, I would simply be able
to use iio_channel_get() to get the sensor from the device tree and
iio_channel_read() to read values from it. There is a iio_hwmon and no
hwmon_iio, so if someone wants a hwmon interface for it, it would not
block anything.

The main point about writing this mail now is that I do not want to
submit a driver, spin some polishing rounds, then somebody says:"Please
go to subsystem Y, not X"

Regards,
Andreas



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux