ср, 5 бер. 2025 р. о 16:37 Lukasz Luba <lukasz.luba@xxxxxxx> пише:
>
>
>
> On 3/5/25 10:06, Svyatoslav Ryhel wrote:
> > ср, 5 бер. 2025 р. о 11:52 Lukasz Luba <lukasz.luba@xxxxxxx> пише:
> >>
> >>
> >>
> >> On 3/3/25 12:21, Svyatoslav Ryhel wrote:
> >>> To avoid duplicating sensor functionality and conversion tables, this design
> >>> allows converting an ADC IIO channel's output directly into a temperature IIO
> >>> channel. This is particularly useful for devices where hwmon isn't suitable
> >>> or where temperature data must be accessible through IIO.
> >>>
> >>> One such device is, for example, the MAX17040 fuel gauge.
> >>>
> >>> Signed-off-by: Svyatoslav Ryhel <clamor95@xxxxxxxxx>
> >>> ---
> >>> drivers/thermal/thermal-generic-adc.c | 54 ++++++++++++++++++++++++++-
> >>> 1 file changed, 53 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
> > ...
> >>>
> >>> +static const struct iio_chan_spec gadc_thermal_iio_channel[] = {
> >>> + {
> >>> + .type = IIO_TEMP,
> >>> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> >>
> >> I would add the IIO_CHAN_INFO_SCALE and say it's in milli-degrees.
> >>
> >
> > I have hit this issue already with als sensor. This should definitely
> > be a IIO_CHAN_INFO_PROCESSED since there is no raw temp data we have,
> > it gets processed into temp data via conversion table. I will add
> > Jonathan Cameron to list if you don't mind, he might give some good
> > advice.
>
> I'm not talking about 'PROCESSED' vs 'RAW'...
> I'm asking if you can add the 'SCALE' case to handle and report
> that this device will report 'processed' temp value in milli-degrees
> of Celsius.
>
Sure, I take this into account.
> >
> >>> + }
> >>> +};
> >>> +
> >>> +static int gadc_thermal_read_raw(struct iio_dev *indio_dev,
> >>> + struct iio_chan_spec const *chan,
> >>> + int *temp, int *val2, long mask)
> >>> +{
> >>> + struct gadc_thermal_info *gtinfo = iio_priv(indio_dev);
> >>> + int ret;
> >>> +
> >>> + if (mask != IIO_CHAN_INFO_PROCESSED)
> >>> + return -EINVAL;
> >>
> >> Therefore, here it would need to handle such case as well, when
> >> a client is asking about scale.
> >>
> >>> +
> >>> + ret = gadc_thermal_get_temp(gtinfo->tz_dev, temp);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + *temp /= 1000;
> >>
> >> IMO we shouldn't cut the precision if it's provided.
> >> The user of this would know what to do with the value (when
> >> the proper information about scale is also available).
> >>
> >
> > The it will not fit existing IIO framework and thermal readings will
> > be 1000 off. I have had to adjust this since my battery suddenly got
> > temperature reading of 23200C which obviously was not true. With
> > adjustment temperature will be in 10th of C (yes, odd, I know but it
> > is what it is).
>
> Your battery driver should get and check the 'SCALE' info first, then
> it will know that the value is in higher resolution than it needs.
> Therefore, it can divide the value inside its code.
> Your proposed division here is creating a limitation.
>
> You shouldn't force all other drivers to ignore and drop the
> available information about milli-degC (which is done in this patch).
