On 06/27/2013 09:26 PM, Alexandre Belloni wrote:

Hi,

On 27/06/2013 16:27, Guenter Roeck wrote:

quoted

On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:

quoted

On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:

quoted

On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:

quoted

The low resolution ADC of the mxs is able to read an internal temperature
sensor, expose that using hwmon.

Signed-off-by: Alexandre Belloni <redacted>
---

Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?

Actually, I wonder if we should not just put the hwmon driver
capabilities directly into the mxs-lradc driver, just like it's already
been done in this driver for the touchscreen support.

The probing of this hwmon driver doesn't really belong to the DT, it's
not really realistic to probe it from the machine definition, and it
really is the IP that is wired that way.

Merging iio-hwmon functionality into an adc driver seems just as bad
(or even worse) as copying it into a new driver.

If the lradc driver knows that the ADC channels are temperature sensors, it
should register them with the iio subsystem as IIO_TEMP type. Then you should
be able to use iio_hwmon as is.

They are already registered as IIO_TEMP but only implement read_raw. Also,

iio_hwmon_read_val() is using iio_read_channel_processed() and that will
basically only read one of the 2 channels. As I documented, you actually
need to read both channel 8 and channel 9 and then compute the value in
Kelvins. I'm not sure how you want me to do that in the current framework.

What are these two channels actually measuring? Is the value of a single
channel meaningful on it's own? If not it might make sense to update the IIO
driver to just have one temperature channel.

- Lars