Re: [PATCH 4/4] iio: afe/rescale: Implement write_raw

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

 



Hi Peter,

Le ven., juil. 22 2022 at 00:16:36 +0200, Peter Rosin <peda@xxxxxxxxxx> a écrit :
Hi!

2022-07-21 at 21:15, Paul Cercueil wrote:
 Implement write_raw by converting the value if writing the scale, or
 just calling the managed channel driver's write_raw otherwise.

 Signed-off-by: Paul Cercueil <paul@xxxxxxxxxxxxxxx>
 ---
  drivers/iio/afe/iio-rescale.c | 22 ++++++++++++++++++++++
  1 file changed, 22 insertions(+)

diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
 index 5c9970b93384..0edb62ee4508 100644
 --- a/drivers/iio/afe/iio-rescale.c
 +++ b/drivers/iio/afe/iio-rescale.c
@@ -141,6 +141,27 @@ int rescale_process_offset(struct rescale *rescale, int scale_type,
  	}
  }

 +static int rescale_write_raw(struct iio_dev *indio_dev,
 +			     struct iio_chan_spec const *chan,
 +			     int val, int val2, long mask)
 +{
 +	struct rescale *rescale = iio_priv(indio_dev);
 +	unsigned long long tmp;
 +
 +	switch (mask) {
 +	case IIO_CHAN_INFO_SCALE:
 +		tmp = val * 1000000000LL;
 +		do_div(tmp, rescale->numerator);
 +		tmp *= rescale->denominator;
 +		do_div(tmp, 1000000000LL);

do_div is for unsigned operands. Can val never ever be negative?
What about the numerator and denominator, can those be negative? I
think this code should live in a new rescale_process_inverse_scale
function, or something like that (and a few tests could be added to
drivers/iio/test/iio-test-rescale.c)

I can do that.


 +		return iio_write_channel_attribute(rescale->source, tmp, 0,
 +						   IIO_CHAN_INFO_SCALE);
 +	default:

What if the source driver has a .write_raw_get_fmt callback? That bit
of info is silently dropped (with no comment that a shortcut has been
taken). How does inverse rescaling mix with a .write_raw_get_fmt that
returns e.g. IIO_VAL_INT_PLUS_MICRO_DB anyway? I think all cases might
get a bit hairy to support, so I think you need to do some filtering
and somehow fail the .write_raw call if the .write_raw_get_fmt of the
source returns something that gets too difficult to support.

If the inverse rescale uses the same code as rescale_process_scale() then it becomes problematic, yes, as it likes to change the type of the value.

What I could try - compute the inverse of the value, then find the closest scale value+type that the source driver supports, and use this as the value+type. Then the only failure point would be if .write_raw_get_fmt returns something different than the formats returned by .read_avail, but that sounds unlikely to happen.

Cheers,
-Paul

 +		return iio_write_channel_attribute(rescale->source,
 +						   val, val2, mask);
 +	}
 +}
 +
  static int rescale_read_raw(struct iio_dev *indio_dev,
  			    struct iio_chan_spec const *chan,
  			    int *val, int *val2, long mask)
@@ -250,6 +271,7 @@ static int rescale_read_avail(struct iio_dev *indio_dev,
  }

  static const struct iio_info rescale_info = {
 +	.write_raw = rescale_write_raw,
  	.read_raw = rescale_read_raw,
  	.read_avail = rescale_read_avail,
  };






[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