| Message ID | 20210721030613.3105327-6-liambeguin@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | iio: afe: add temperature rescaling support | expand |
On 2021-07-21 05:06, Liam Beguin wrote: > From: Liam Beguin <lvb@xiphos.com> > > Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > Add support for these to allow using the iio-rescaler with them. > > Signed-off-by: Liam Beguin <lvb@xiphos.com> > --- > drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > index d0669fd8eac5..2b73047365cc 100644 > --- a/drivers/iio/afe/iio-rescale.c > +++ b/drivers/iio/afe/iio-rescale.c > @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > do_div(tmp, 1000000000LL); > *val = tmp; > return scale_type; > + case IIO_VAL_INT_PLUS_NANO: > + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > + tmp = div_s64(tmp, rescale->denominator); > + > + *val = div_s64(tmp, 1000000000LL); > + *val2 = tmp - *val * 1000000000LL; > + return scale_type; Hi! My objection from v5 still stands. Did you forget or did you simply send the wrong patch? Untested suggestion, this time handling negative values and canonicalizing any overflow from the fraction calculation. neg = *val < 0 || *val2 < 0; tmp = (s64)abs(*val) * rescale->numerator; rem = do_div(tmp, rescale->denominator); *val = tmp; tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; do_div(tmp, rescale->denominator); *val2 = do_div(tmp, 1000000000LL); *val += tmp; if (neg) { if (*val < 0) *val = -*val; else *val2 = -*val; } > + case IIO_VAL_INT_PLUS_MICRO: > + tmp = ((s64)*val * 1000000LL + *val2) * rescale->numerator; > + tmp = div_s64(tmp, rescale->denominator); > + > + *val = div_s64(tmp, 1000000); Why do you not have the LL suffix here? Cheers, Peter > + *val2 = tmp - *val * 1000000; > + return scale_type; > default: > return -EOPNOTSUPP; > } >
On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: > On 2021-07-21 05:06, Liam Beguin wrote: > > From: Liam Beguin <lvb@xiphos.com> > > > > Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > > Add support for these to allow using the iio-rescaler with them. > > > > Signed-off-by: Liam Beguin <lvb@xiphos.com> > > --- > > drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > > index d0669fd8eac5..2b73047365cc 100644 > > --- a/drivers/iio/afe/iio-rescale.c > > +++ b/drivers/iio/afe/iio-rescale.c > > @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > > do_div(tmp, 1000000000LL); > > *val = tmp; > > return scale_type; > > + case IIO_VAL_INT_PLUS_NANO: > > + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > > + tmp = div_s64(tmp, rescale->denominator); > > + > > + *val = div_s64(tmp, 1000000000LL); > > + *val2 = tmp - *val * 1000000000LL; > > + return scale_type; Hi Peter, > > Hi! > > My objection from v5 still stands. Did you forget or did you simply send > the > wrong patch? Apologies, again I didn't mean to make it seem like I ignored your comments. I tried your suggestion, but had issues when *val2 would overflow into the integer part. Even though what I has was more prone to integer overflow with the first multiplication, I thought it was still a valid solution as it passed the tests. > > Untested suggestion, this time handling negative values and > canonicalizing any > overflow from the fraction calculation. > > neg = *val < 0 || *val2 < 0; > tmp = (s64)abs(*val) * rescale->numerator; > rem = do_div(tmp, rescale->denominator); > *val = tmp; > tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; > do_div(tmp, rescale->denominator); > *val2 = do_div(tmp, 1000000000LL); > *val += tmp; > if (neg) { > if (*val < 0) > *val = -*val; > else > *val2 = -*val; I'll look into this suggestion. > } > > > + case IIO_VAL_INT_PLUS_MICRO: > > + tmp = ((s64)*val * 1000000LL + *val2) * rescale->numerator; > > + tmp = div_s64(tmp, rescale->denominator); > > + > > + *val = div_s64(tmp, 1000000); > > Why do you not have the LL suffix here? Doesnt' LL make it into a 64 bit integer? I left it out because the second parameter of div_s64() should be s32. Thanks, Liam > > Cheers, > Peter > > > + *val2 = tmp - *val * 1000000; > > + return scale_type; > > default: > > return -EOPNOTSUPP; > > } > >
On 2021-07-28 02:21, Liam Beguin wrote: > On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: >> On 2021-07-21 05:06, Liam Beguin wrote: >>> From: Liam Beguin <lvb@xiphos.com> >>> >>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. >>> Add support for these to allow using the iio-rescaler with them. >>> >>> Signed-off-by: Liam Beguin <lvb@xiphos.com> >>> --- >>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c >>> index d0669fd8eac5..2b73047365cc 100644 >>> --- a/drivers/iio/afe/iio-rescale.c >>> +++ b/drivers/iio/afe/iio-rescale.c >>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, >>> do_div(tmp, 1000000000LL); >>> *val = tmp; >>> return scale_type; >>> + case IIO_VAL_INT_PLUS_NANO: >>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; >>> + tmp = div_s64(tmp, rescale->denominator); >>> + >>> + *val = div_s64(tmp, 1000000000LL); >>> + *val2 = tmp - *val * 1000000000LL; >>> + return scale_type; > > Hi Peter, > >> >> Hi! >> >> My objection from v5 still stands. Did you forget or did you simply send >> the >> wrong patch? > > Apologies, again I didn't mean to make it seem like I ignored your comments. > I tried your suggestion, but had issues when *val2 would overflow into > the integer part. Not saying anything about it not working does indeed make it seem like you ignored it :-) Or did I just miss where you said this? Anyway, no problem, it can be a mess dealing with a string of commits when there are numerous things to take care of between each iteration. And it's very easy to burn out and just back away. Please don't do that! > Even though what I has was more prone to integer overflow with the first > multiplication, I thought it was still a valid solution as it passed the > tests. I did state that you'd need to add overflow handling from the fraction calculation and handling for negative values, so it was no surprise that my original sketchy suggestion didn't work as-is. > >> >> Untested suggestion, this time handling negative values and >> canonicalizing any >> overflow from the fraction calculation. >> >> neg = *val < 0 || *val2 < 0; >> tmp = (s64)abs(*val) * rescale->numerator; >> rem = do_div(tmp, rescale->denominator); >> *val = tmp; >> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; >> do_div(tmp, rescale->denominator); >> *val2 = do_div(tmp, 1000000000LL); >> *val += tmp; >> if (neg) { >> if (*val < 0) >> *val = -*val; >> else >> *val2 = -*val; This last line should of course be *val2 = -*val2; Sorry. > > I'll look into this suggestion. Thanks! > >> } >> >>> + case IIO_VAL_INT_PLUS_MICRO: >>> + tmp = ((s64)*val * 1000000LL + *val2) * rescale->numerator; >>> + tmp = div_s64(tmp, rescale->denominator); >>> + >>> + *val = div_s64(tmp, 1000000); >> >> Why do you not have the LL suffix here? > > Doesnt' LL make it into a 64 bit integer? > I left it out because the second parameter of div_s64() should be s32. It just looked really odd with 1000000000LL for all instances, but then 1000000LL only for some. The lack of symmetry bothered me. To me, it seems as if we either need to support old/small crap with int being 16-bit, or we don't. If we don't need support for 16-bit, then we don't need any LL suffix, since 1000000000 fits just fine in 32-bit. If we do need 16-bit support, then we need LL (or something) all over since neither 1000000 nor 1000000000 fit in 16-bit. I think the compiler looks at the value of the constant and not the size of its type when selecting how big values the mul/add/whatever needs handle. So, adding LL feels like the safe option. Further, I guesstimate that the runtime cost of adding LL is zero and that the compile time cost is negligible. But maybe I'm missing something? Cheers, Peter > > Thanks, > Liam > >> >> Cheers, >> Peter >> >>> + *val2 = tmp - *val * 1000000; >>> + return scale_type; >>> default: >>> return -EOPNOTSUPP; >>> } >>> >
On Wed Jul 28, 2021 at 3:19 AM EDT, Peter Rosin wrote: > On 2021-07-28 02:21, Liam Beguin wrote: > > On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: > >> On 2021-07-21 05:06, Liam Beguin wrote: > >>> From: Liam Beguin <lvb@xiphos.com> > >>> > >>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > >>> Add support for these to allow using the iio-rescaler with them. > >>> > >>> Signed-off-by: Liam Beguin <lvb@xiphos.com> > >>> --- > >>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > >>> 1 file changed, 14 insertions(+) > >>> > >>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > >>> index d0669fd8eac5..2b73047365cc 100644 > >>> --- a/drivers/iio/afe/iio-rescale.c > >>> +++ b/drivers/iio/afe/iio-rescale.c > >>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > >>> do_div(tmp, 1000000000LL); > >>> *val = tmp; > >>> return scale_type; > >>> + case IIO_VAL_INT_PLUS_NANO: > >>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > >>> + tmp = div_s64(tmp, rescale->denominator); > >>> + > >>> + *val = div_s64(tmp, 1000000000LL); > >>> + *val2 = tmp - *val * 1000000000LL; > >>> + return scale_type; > > > > Hi Peter, > > > >> > >> Hi! > >> > >> My objection from v5 still stands. Did you forget or did you simply send > >> the > >> wrong patch? > > > > Apologies, again I didn't mean to make it seem like I ignored your comments. > > I tried your suggestion, but had issues when *val2 would overflow into > > the integer part. Hi Peter, > > Not saying anything about it not working does indeed make it seem like > you > ignored it :-) Or did I just miss where you said this? Anyway, no > problem, > it can be a mess dealing with a string of commits when there are > numerous > things to take care of between each iteration. And it's very easy to > burn > out and just back away. Please don't do that! It was my mistake. Thanks for the encouragement :-) > > > Even though what I has was more prone to integer overflow with the first > > multiplication, I thought it was still a valid solution as it passed the > > tests. > > I did state that you'd need to add overflow handling from the fraction > calculation and handling for negative values, so it was no surprise that > my original sketchy suggestion didn't work as-is. > > > > >> > >> Untested suggestion, this time handling negative values and > >> canonicalizing any > >> overflow from the fraction calculation. > >> > >> neg = *val < 0 || *val2 < 0; > >> tmp = (s64)abs(*val) * rescale->numerator; > >> rem = do_div(tmp, rescale->denominator); > >> *val = tmp; > >> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; > >> do_div(tmp, rescale->denominator); > >> *val2 = do_div(tmp, 1000000000LL); > >> *val += tmp; > >> if (neg) { > >> if (*val < 0) > >> *val = -*val; > >> else > >> *val2 = -*val; > > This last line should of course be *val2 = -*val2; > Sorry. > > > > > I'll look into this suggestion. > > Thanks! > Starting from what you suggested, here's what I came up with. I also added a few test cases to cover corner cases. if (scale_type == IIO_VAL_INT_PLUS_NANO) mult = 1000000000LL; else mult = 1000000LL; /* * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if *val OR * *val2 is negative the schan scale is negative */ neg = *val < 0 || *val2 < 0; tmp = (s64)abs(*val) * (s32)abs(rescale->numerator); *val = div_s64_rem(tmp, (s32)abs(rescale->denominator), &rem); tmp = (s64)rem * mult + (s64)abs(*val2) * (s32)abs(rescale->numerator); tmp = div_s64(tmp, (s32)abs(rescale->denominator)); *val += div_s64_rem(tmp, mult, val2); /* * If the schan scale or only one of the rescaler elements is * negative, the combined scale is negative. */ if (neg || ((rescale->numerator < 0) ^ (rescale->denominator < 0))) *val = -*val; return scale_type; > > > >> } > >> > >>> + case IIO_VAL_INT_PLUS_MICRO: > >>> + tmp = ((s64)*val * 1000000LL + *val2) * rescale->numerator; > >>> + tmp = div_s64(tmp, rescale->denominator); > >>> + > >>> + *val = div_s64(tmp, 1000000); > >> > >> Why do you not have the LL suffix here? > > > > Doesnt' LL make it into a 64 bit integer? > > I left it out because the second parameter of div_s64() should be s32. > > It just looked really odd with 1000000000LL for all instances, but then > 1000000LL only for some. The lack of symmetry bothered me. > > To me, it seems as if we either need to support old/small crap with > int being 16-bit, or we don't. If we don't need support for 16-bit, > then we don't need any LL suffix, since 1000000000 fits just fine in > 32-bit. If we do need 16-bit support, then we need LL (or something) > all over since neither 1000000 nor 1000000000 fit in 16-bit. > > I think the compiler looks at the value of the constant and not the > size of its type when selecting how big values the mul/add/whatever > needs handle. So, adding LL feels like the safe option. Further, I > guesstimate that the runtime cost of adding LL is zero and that the > compile time cost is negligible. Thanks for the explanation, I thought it might matter but I agree that the asymmetry looks odd. I'll fix it. Thanks, Liam > > But maybe I'm missing something? > > Cheers, > Peter > > > > > Thanks, > > Liam > > > >> > >> Cheers, > >> Peter > >> > >>> + *val2 = tmp - *val * 1000000; > >>> + return scale_type; > >>> default: > >>> return -EOPNOTSUPP; > >>> } > >>> > >
On 2021-07-29 17:56, Liam Beguin wrote: > On Wed Jul 28, 2021 at 3:19 AM EDT, Peter Rosin wrote: >> On 2021-07-28 02:21, Liam Beguin wrote: >>> On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: >>>> On 2021-07-21 05:06, Liam Beguin wrote: >>>>> From: Liam Beguin <lvb@xiphos.com> >>>>> >>>>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. >>>>> Add support for these to allow using the iio-rescaler with them. >>>>> >>>>> Signed-off-by: Liam Beguin <lvb@xiphos.com> >>>>> --- >>>>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ >>>>> 1 file changed, 14 insertions(+) >>>>> >>>>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c >>>>> index d0669fd8eac5..2b73047365cc 100644 >>>>> --- a/drivers/iio/afe/iio-rescale.c >>>>> +++ b/drivers/iio/afe/iio-rescale.c >>>>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, >>>>> do_div(tmp, 1000000000LL); >>>>> *val = tmp; >>>>> return scale_type; >>>>> + case IIO_VAL_INT_PLUS_NANO: >>>>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; >>>>> + tmp = div_s64(tmp, rescale->denominator); >>>>> + >>>>> + *val = div_s64(tmp, 1000000000LL); >>>>> + *val2 = tmp - *val * 1000000000LL; >>>>> + return scale_type; >>> >>> Hi Peter, >>> >>>> >>>> Hi! >>>> >>>> My objection from v5 still stands. Did you forget or did you simply send >>>> the >>>> wrong patch? >>> >>> Apologies, again I didn't mean to make it seem like I ignored your comments. >>> I tried your suggestion, but had issues when *val2 would overflow into >>> the integer part. > > Hi Peter, > >> >> Not saying anything about it not working does indeed make it seem like >> you >> ignored it :-) Or did I just miss where you said this? Anyway, no >> problem, >> it can be a mess dealing with a string of commits when there are >> numerous >> things to take care of between each iteration. And it's very easy to >> burn >> out and just back away. Please don't do that! > > It was my mistake. Thanks for the encouragement :-) > >> >>> Even though what I has was more prone to integer overflow with the first >>> multiplication, I thought it was still a valid solution as it passed the >>> tests. >> >> I did state that you'd need to add overflow handling from the fraction >> calculation and handling for negative values, so it was no surprise that >> my original sketchy suggestion didn't work as-is. >> >>> >>>> >>>> Untested suggestion, this time handling negative values and >>>> canonicalizing any >>>> overflow from the fraction calculation. >>>> >>>> neg = *val < 0 || *val2 < 0; >>>> tmp = (s64)abs(*val) * rescale->numerator; >>>> rem = do_div(tmp, rescale->denominator); >>>> *val = tmp; >>>> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; >>>> do_div(tmp, rescale->denominator); >>>> *val2 = do_div(tmp, 1000000000LL); >>>> *val += tmp; >>>> if (neg) { >>>> if (*val < 0) >>>> *val = -*val; >>>> else >>>> *val2 = -*val; >> >> This last line should of course be *val2 = -*val2; >> Sorry. >> >>> >>> I'll look into this suggestion. >> >> Thanks! >> > > Starting from what you suggested, here's what I came up with. > I also added a few test cases to cover corner cases. > > if (scale_type == IIO_VAL_INT_PLUS_NANO) > mult = 1000000000LL; > else > mult = 1000000LL; > /* > * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if *val OR > * *val2 is negative the schan scale is negative > */ > neg = *val < 0 || *val2 < 0; > > tmp = (s64)abs(*val) * (s32)abs(rescale->numerator); Small nit, but I think abs() returns a signed type compatible with the argument type. I.e. (s32)abs(rescale->...) where both numerator and denominator are already s32 could just as well be written without the cast as plain old abs(rescale->...) > *val = div_s64_rem(tmp, (s32)abs(rescale->denominator), &rem); > > tmp = (s64)rem * mult + > (s64)abs(*val2) * (s32)abs(rescale->numerator); > tmp = div_s64(tmp, (s32)abs(rescale->denominator)); > > *val += div_s64_rem(tmp, mult, val2); > > /* > * If the schan scale or only one of the rescaler elements is > * negative, the combined scale is negative. > */ > if (neg || ((rescale->numerator < 0) ^ (rescale->denominator < 0))) > *val = -*val; Unconditionally negating *val doesn't negate the combined value when *val is zero and *val2 isn't. My test "if (*val < 0)" above attempting to take care of this case is clearly not right. It should of course be "if (*val > 0)" since *val is not yet negated. Duh! In fact, I think a few tests scaling to/from the [-1,1] interval would be benefitial for this exact reason. Cheers, Peter
On 2021-07-30 08:49, Peter Rosin wrote: > On 2021-07-29 17:56, Liam Beguin wrote: >> On Wed Jul 28, 2021 at 3:19 AM EDT, Peter Rosin wrote: >>> On 2021-07-28 02:21, Liam Beguin wrote: >>>> On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: >>>>> On 2021-07-21 05:06, Liam Beguin wrote: >>>>>> From: Liam Beguin <lvb@xiphos.com> >>>>>> >>>>>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. >>>>>> Add support for these to allow using the iio-rescaler with them. >>>>>> >>>>>> Signed-off-by: Liam Beguin <lvb@xiphos.com> >>>>>> --- >>>>>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ >>>>>> 1 file changed, 14 insertions(+) >>>>>> >>>>>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c >>>>>> index d0669fd8eac5..2b73047365cc 100644 >>>>>> --- a/drivers/iio/afe/iio-rescale.c >>>>>> +++ b/drivers/iio/afe/iio-rescale.c >>>>>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, >>>>>> do_div(tmp, 1000000000LL); >>>>>> *val = tmp; >>>>>> return scale_type; >>>>>> + case IIO_VAL_INT_PLUS_NANO: >>>>>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; >>>>>> + tmp = div_s64(tmp, rescale->denominator); >>>>>> + >>>>>> + *val = div_s64(tmp, 1000000000LL); >>>>>> + *val2 = tmp - *val * 1000000000LL; >>>>>> + return scale_type; >>>> >>>> Hi Peter, >>>> >>>>> >>>>> Hi! >>>>> >>>>> My objection from v5 still stands. Did you forget or did you simply send >>>>> the >>>>> wrong patch? >>>> >>>> Apologies, again I didn't mean to make it seem like I ignored your comments. >>>> I tried your suggestion, but had issues when *val2 would overflow into >>>> the integer part. >> >> Hi Peter, >> >>> >>> Not saying anything about it not working does indeed make it seem like >>> you >>> ignored it :-) Or did I just miss where you said this? Anyway, no >>> problem, >>> it can be a mess dealing with a string of commits when there are >>> numerous >>> things to take care of between each iteration. And it's very easy to >>> burn >>> out and just back away. Please don't do that! >> >> It was my mistake. Thanks for the encouragement :-) >> >>> >>>> Even though what I has was more prone to integer overflow with the first >>>> multiplication, I thought it was still a valid solution as it passed the >>>> tests. >>> >>> I did state that you'd need to add overflow handling from the fraction >>> calculation and handling for negative values, so it was no surprise that >>> my original sketchy suggestion didn't work as-is. >>> >>>> >>>>> >>>>> Untested suggestion, this time handling negative values and >>>>> canonicalizing any >>>>> overflow from the fraction calculation. >>>>> >>>>> neg = *val < 0 || *val2 < 0; >>>>> tmp = (s64)abs(*val) * rescale->numerator; >>>>> rem = do_div(tmp, rescale->denominator); >>>>> *val = tmp; >>>>> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; >>>>> do_div(tmp, rescale->denominator); >>>>> *val2 = do_div(tmp, 1000000000LL); >>>>> *val += tmp; >>>>> if (neg) { >>>>> if (*val < 0) >>>>> *val = -*val; >>>>> else >>>>> *val2 = -*val; >>> >>> This last line should of course be *val2 = -*val2; >>> Sorry. >>> >>>> >>>> I'll look into this suggestion. >>> >>> Thanks! >>> >> >> Starting from what you suggested, here's what I came up with. >> I also added a few test cases to cover corner cases. >> >> if (scale_type == IIO_VAL_INT_PLUS_NANO) >> mult = 1000000000LL; >> else >> mult = 1000000LL; >> /* >> * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if *val OR >> * *val2 is negative the schan scale is negative >> */ >> neg = *val < 0 || *val2 < 0; >> >> tmp = (s64)abs(*val) * (s32)abs(rescale->numerator); > > Small nit, but I think abs() returns a signed type compatible > with the argument type. I.e. (s32)abs(rescale->...) where both > numerator and denominator are already s32 could just as well > be written without the cast as plain old abs(rescale->...) > > >> *val = div_s64_rem(tmp, (s32)abs(rescale->denominator), &rem); >> >> tmp = (s64)rem * mult + >> (s64)abs(*val2) * (s32)abs(rescale->numerator); >> tmp = div_s64(tmp, (s32)abs(rescale->denominator)); >> >> *val += div_s64_rem(tmp, mult, val2); >> >> /* >> * If the schan scale or only one of the rescaler elements is >> * negative, the combined scale is negative. >> */ >> if (neg || ((rescale->numerator < 0) ^ (rescale->denominator < 0))) Hang on, that's not right. If the value and only one of the rescaler elements is negative, the result is positive. || is not the correct logical operation. >> *val = -*val; > > Unconditionally negating *val doesn't negate the combined value when > *val is zero and *val2 isn't. My test "if (*val < 0)" above attempting > to take care of this case is clearly not right. It should of course be > "if (*val > 0)" since *val is not yet negated. Duh! > > In fact, I think a few tests scaling to/from the [-1,1] interval > would be benefitial for this exact reason. So, with both these issues taken care of: if (neg ^ ((rescale->numerator < 0) ^ (rescale->denominator < 0))) { if (*val > 0) *val = -*val; else *val2 = -*val2; } (bitwise ^ is safe since all operands come from logical operations, i.e. they are either zero or one and nothing else) Cheers, Peter
On Fri Jul 30, 2021 at 2:49 AM EDT, Peter Rosin wrote: > On 2021-07-29 17:56, Liam Beguin wrote: > > On Wed Jul 28, 2021 at 3:19 AM EDT, Peter Rosin wrote: > >> On 2021-07-28 02:21, Liam Beguin wrote: > >>> On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: > >>>> On 2021-07-21 05:06, Liam Beguin wrote: > >>>>> From: Liam Beguin <lvb@xiphos.com> > >>>>> > >>>>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > >>>>> Add support for these to allow using the iio-rescaler with them. > >>>>> > >>>>> Signed-off-by: Liam Beguin <lvb@xiphos.com> > >>>>> --- > >>>>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > >>>>> 1 file changed, 14 insertions(+) > >>>>> > >>>>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > >>>>> index d0669fd8eac5..2b73047365cc 100644 > >>>>> --- a/drivers/iio/afe/iio-rescale.c > >>>>> +++ b/drivers/iio/afe/iio-rescale.c > >>>>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > >>>>> do_div(tmp, 1000000000LL); > >>>>> *val = tmp; > >>>>> return scale_type; > >>>>> + case IIO_VAL_INT_PLUS_NANO: > >>>>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > >>>>> + tmp = div_s64(tmp, rescale->denominator); > >>>>> + > >>>>> + *val = div_s64(tmp, 1000000000LL); > >>>>> + *val2 = tmp - *val * 1000000000LL; > >>>>> + return scale_type; > >>> > >>> Hi Peter, > >>> > >>>> > >>>> Hi! > >>>> > >>>> My objection from v5 still stands. Did you forget or did you simply send > >>>> the > >>>> wrong patch? > >>> > >>> Apologies, again I didn't mean to make it seem like I ignored your comments. > >>> I tried your suggestion, but had issues when *val2 would overflow into > >>> the integer part. > > > > Hi Peter, > > > >> > >> Not saying anything about it not working does indeed make it seem like > >> you > >> ignored it :-) Or did I just miss where you said this? Anyway, no > >> problem, > >> it can be a mess dealing with a string of commits when there are > >> numerous > >> things to take care of between each iteration. And it's very easy to > >> burn > >> out and just back away. Please don't do that! > > > > It was my mistake. Thanks for the encouragement :-) > > > >> > >>> Even though what I has was more prone to integer overflow with the first > >>> multiplication, I thought it was still a valid solution as it passed the > >>> tests. > >> > >> I did state that you'd need to add overflow handling from the fraction > >> calculation and handling for negative values, so it was no surprise that > >> my original sketchy suggestion didn't work as-is. > >> > >>> > >>>> > >>>> Untested suggestion, this time handling negative values and > >>>> canonicalizing any > >>>> overflow from the fraction calculation. > >>>> > >>>> neg = *val < 0 || *val2 < 0; > >>>> tmp = (s64)abs(*val) * rescale->numerator; > >>>> rem = do_div(tmp, rescale->denominator); > >>>> *val = tmp; > >>>> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; > >>>> do_div(tmp, rescale->denominator); > >>>> *val2 = do_div(tmp, 1000000000LL); > >>>> *val += tmp; > >>>> if (neg) { > >>>> if (*val < 0) > >>>> *val = -*val; > >>>> else > >>>> *val2 = -*val; > >> > >> This last line should of course be *val2 = -*val2; > >> Sorry. > >> > >>> > >>> I'll look into this suggestion. > >> > >> Thanks! > >> > > > > Starting from what you suggested, here's what I came up with. > > I also added a few test cases to cover corner cases. > > > > if (scale_type == IIO_VAL_INT_PLUS_NANO) > > mult = 1000000000LL; > > else > > mult = 1000000LL; > > /* > > * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if *val OR > > * *val2 is negative the schan scale is negative > > */ > > neg = *val < 0 || *val2 < 0; > > > > tmp = (s64)abs(*val) * (s32)abs(rescale->numerator); > > Small nit, but I think abs() returns a signed type compatible > with the argument type. I.e. (s32)abs(rescale->...) where both > numerator and denominator are already s32 could just as well > be written without the cast as plain old abs(rescale->...) Understood, I'll get rid of the redundant typecasts > > > > *val = div_s64_rem(tmp, (s32)abs(rescale->denominator), &rem); > > > > tmp = (s64)rem * mult + > > (s64)abs(*val2) * (s32)abs(rescale->numerator); > > tmp = div_s64(tmp, (s32)abs(rescale->denominator)); > > > > *val += div_s64_rem(tmp, mult, val2); > > > > /* > > * If the schan scale or only one of the rescaler elements is > > * negative, the combined scale is negative. > > */ > > if (neg || ((rescale->numerator < 0) ^ (rescale->denominator < 0))) > > *val = -*val; > > Unconditionally negating *val doesn't negate the combined value when > *val is zero and *val2 isn't. My test "if (*val < 0)" above attempting > to take care of this case is clearly not right. It should of course be > "if (*val > 0)" since *val is not yet negated. Duh! Oh I see, thanks for pointing that out. Since at that point *val can't be negative because of all the abs() calls, we could also just check that *val is not zero. > > In fact, I think a few tests scaling to/from the [-1,1] interval > would be benefitial for this exact reason. Sounds good, I'll add a few more cases for this. Thanks, Liam > > Cheers, > Peter
On Fri Jul 30, 2021 at 3:01 AM EDT, Peter Rosin wrote: > On 2021-07-30 08:49, Peter Rosin wrote: > > On 2021-07-29 17:56, Liam Beguin wrote: > >> On Wed Jul 28, 2021 at 3:19 AM EDT, Peter Rosin wrote: > >>> On 2021-07-28 02:21, Liam Beguin wrote: > >>>> On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: > >>>>> On 2021-07-21 05:06, Liam Beguin wrote: > >>>>>> From: Liam Beguin <lvb@xiphos.com> > >>>>>> > >>>>>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > >>>>>> Add support for these to allow using the iio-rescaler with them. > >>>>>> > >>>>>> Signed-off-by: Liam Beguin <lvb@xiphos.com> > >>>>>> --- > >>>>>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > >>>>>> 1 file changed, 14 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > >>>>>> index d0669fd8eac5..2b73047365cc 100644 > >>>>>> --- a/drivers/iio/afe/iio-rescale.c > >>>>>> +++ b/drivers/iio/afe/iio-rescale.c > >>>>>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > >>>>>> do_div(tmp, 1000000000LL); > >>>>>> *val = tmp; > >>>>>> return scale_type; > >>>>>> + case IIO_VAL_INT_PLUS_NANO: > >>>>>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > >>>>>> + tmp = div_s64(tmp, rescale->denominator); > >>>>>> + > >>>>>> + *val = div_s64(tmp, 1000000000LL); > >>>>>> + *val2 = tmp - *val * 1000000000LL; > >>>>>> + return scale_type; > >>>> > >>>> Hi Peter, > >>>> > >>>>> > >>>>> Hi! > >>>>> > >>>>> My objection from v5 still stands. Did you forget or did you simply send > >>>>> the > >>>>> wrong patch? > >>>> > >>>> Apologies, again I didn't mean to make it seem like I ignored your comments. > >>>> I tried your suggestion, but had issues when *val2 would overflow into > >>>> the integer part. > >> > >> Hi Peter, > >> > >>> > >>> Not saying anything about it not working does indeed make it seem like > >>> you > >>> ignored it :-) Or did I just miss where you said this? Anyway, no > >>> problem, > >>> it can be a mess dealing with a string of commits when there are > >>> numerous > >>> things to take care of between each iteration. And it's very easy to > >>> burn > >>> out and just back away. Please don't do that! > >> > >> It was my mistake. Thanks for the encouragement :-) > >> > >>> > >>>> Even though what I has was more prone to integer overflow with the first > >>>> multiplication, I thought it was still a valid solution as it passed the > >>>> tests. > >>> > >>> I did state that you'd need to add overflow handling from the fraction > >>> calculation and handling for negative values, so it was no surprise that > >>> my original sketchy suggestion didn't work as-is. > >>> > >>>> > >>>>> > >>>>> Untested suggestion, this time handling negative values and > >>>>> canonicalizing any > >>>>> overflow from the fraction calculation. > >>>>> > >>>>> neg = *val < 0 || *val2 < 0; > >>>>> tmp = (s64)abs(*val) * rescale->numerator; > >>>>> rem = do_div(tmp, rescale->denominator); > >>>>> *val = tmp; > >>>>> tmp = rem * 1000000000LL + (s64)abs(*val2) * rescale->numerator; > >>>>> do_div(tmp, rescale->denominator); > >>>>> *val2 = do_div(tmp, 1000000000LL); > >>>>> *val += tmp; > >>>>> if (neg) { > >>>>> if (*val < 0) > >>>>> *val = -*val; > >>>>> else > >>>>> *val2 = -*val; > >>> > >>> This last line should of course be *val2 = -*val2; > >>> Sorry. > >>> > >>>> > >>>> I'll look into this suggestion. > >>> > >>> Thanks! > >>> > >> > >> Starting from what you suggested, here's what I came up with. > >> I also added a few test cases to cover corner cases. > >> > >> if (scale_type == IIO_VAL_INT_PLUS_NANO) > >> mult = 1000000000LL; > >> else > >> mult = 1000000LL; > >> /* > >> * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if *val OR > >> * *val2 is negative the schan scale is negative > >> */ > >> neg = *val < 0 || *val2 < 0; > >> > >> tmp = (s64)abs(*val) * (s32)abs(rescale->numerator); > > > > Small nit, but I think abs() returns a signed type compatible > > with the argument type. I.e. (s32)abs(rescale->...) where both > > numerator and denominator are already s32 could just as well > > be written without the cast as plain old abs(rescale->...) > > > > > >> *val = div_s64_rem(tmp, (s32)abs(rescale->denominator), &rem); > >> > >> tmp = (s64)rem * mult + > >> (s64)abs(*val2) * (s32)abs(rescale->numerator); > >> tmp = div_s64(tmp, (s32)abs(rescale->denominator)); > >> > >> *val += div_s64_rem(tmp, mult, val2); > >> > >> /* > >> * If the schan scale or only one of the rescaler elements is > >> * negative, the combined scale is negative. > >> */ > >> if (neg || ((rescale->numerator < 0) ^ (rescale->denominator < 0))) > > Hang on, that's not right. If the value and only one of the rescaler > elements is negative, the result is positive. || is not the correct > logical operation. > > >> *val = -*val; > > > > Unconditionally negating *val doesn't negate the combined value when > > *val is zero and *val2 isn't. My test "if (*val < 0)" above attempting > > to take care of this case is clearly not right. It should of course be > > "if (*val > 0)" since *val is not yet negated. Duh! > > > > In fact, I think a few tests scaling to/from the [-1,1] interval > > would be benefitial for this exact reason. > > So, with both these issues taken care of: > > if (neg ^ ((rescale->numerator < 0) ^ (rescale->denominator < 0))) { > if (*val > 0) > *val = -*val; > else > *val2 = -*val2; > } > > (bitwise ^ is safe since all operands come from logical operations, i.e. > they are either zero or one and nothing else) You're right, this should've been a ^ from the start. Thanks, Liam > > Cheers, > Peter
On Wed, 28 Jul 2021 09:19:58 +0200 Peter Rosin <peda@axentia.se> wrote: > On 2021-07-28 02:21, Liam Beguin wrote: > > On Fri Jul 23, 2021 at 5:16 PM EDT, Peter Rosin wrote: > >> On 2021-07-21 05:06, Liam Beguin wrote: > >>> From: Liam Beguin <lvb@xiphos.com> > >>> > >>> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. > >>> Add support for these to allow using the iio-rescaler with them. > >>> > >>> Signed-off-by: Liam Beguin <lvb@xiphos.com> > >>> --- > >>> drivers/iio/afe/iio-rescale.c | 14 ++++++++++++++ > >>> 1 file changed, 14 insertions(+) > >>> > >>> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c > >>> index d0669fd8eac5..2b73047365cc 100644 > >>> --- a/drivers/iio/afe/iio-rescale.c > >>> +++ b/drivers/iio/afe/iio-rescale.c > >>> @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, > >>> do_div(tmp, 1000000000LL); > >>> *val = tmp; > >>> return scale_type; > >>> + case IIO_VAL_INT_PLUS_NANO: > >>> + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; > >>> + tmp = div_s64(tmp, rescale->denominator); > >>> + > >>> + *val = div_s64(tmp, 1000000000LL); > >>> + *val2 = tmp - *val * 1000000000LL; > >>> + return scale_type; > > > > Hi Peter, > > > >> > >> Hi! > >> > >> My objection from v5 still stands. Did you forget or did you simply send > >> the > >> wrong patch? > > > > Apologies, again I didn't mean to make it seem like I ignored your comments. > > I tried your suggestion, but had issues when *val2 would overflow into > > the integer part. > > Not saying anything about it not working does indeed make it seem like you > ignored it :-) Or did I just miss where you said this? Anyway, no problem, > it can be a mess dealing with a string of commits when there are numerous > things to take care of between each iteration. And it's very easy to burn > out and just back away. Please don't do that! Just to add here, I'm really appreciating the two of you figuring this out between you and looking forward to getting the resulting improvements (particularly the tests!) in place. Thanks, Jonathan
diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c index d0669fd8eac5..2b73047365cc 100644 --- a/drivers/iio/afe/iio-rescale.c +++ b/drivers/iio/afe/iio-rescale.c @@ -41,6 +41,20 @@ int rescale_process_scale(struct rescale *rescale, int scale_type, do_div(tmp, 1000000000LL); *val = tmp; return scale_type; + case IIO_VAL_INT_PLUS_NANO: + tmp = ((s64)*val * 1000000000LL + *val2) * rescale->numerator; + tmp = div_s64(tmp, rescale->denominator); + + *val = div_s64(tmp, 1000000000LL); + *val2 = tmp - *val * 1000000000LL; + return scale_type; + case IIO_VAL_INT_PLUS_MICRO: + tmp = ((s64)*val * 1000000LL + *val2) * rescale->numerator; + tmp = div_s64(tmp, rescale->denominator); + + *val = div_s64(tmp, 1000000); + *val2 = tmp - *val * 1000000; + return scale_type; default: return -EOPNOTSUPP; }