Re: [PATCH] iio: afe: iio-rescale: Support processed channels

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

 



On 2021-01-04 18:11, Jonathan Cameron wrote:
> On Mon, 4 Jan 2021 15:45:07 +0100
> Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> 
>> On Mon, Dec 14, 2020 at 5:34 PM Jonathan Cameron
>> <Jonathan.Cameron@xxxxxxxxxx> wrote:
>>> On Mon, 14 Dec 2020 16:30:22 +0100 Peter Rosin <peda@xxxxxxxxxx> wrote:  
>>
>>>>>> And that gets transformed by the
>>>>>> rescaler into the processed values being presented as raw, with rescaling
>>>>>> added on top, but with the read_avail info for this new raw channel being
>>>>>> completely wrong.
>>>>>>
>>>>>> For the intended driver (ab8500-gpadc) this is not the case (it has no
>>>>>> read_avail for its raw channel). But it does have a raw channel, so adding
>>>>>> read_avail seems easy and I can easily see other drivers already doing it.
>>>>>> Haven't checked that though...  
>>>>>
>>>>> Drat. I'd failed to register this is one of those corner cases.  
>>>>
>>>> I'm not sure, I just browsed the code. Maybe I misread it?  
>>>
>>> It's doing both - you were right.  I think there are only a small number of
>>> drivers that have that history.
>>>
>>> Looks superficially like it's easy enough to catch this corner case and
>>> block it - so lets do that.  
>>
>> Sorry if I am a bit confused here. I don't understand what I am supposed
>> to do to proceed with using this driver with the ab8500 GPADC...
>>
>> Shall I fix something in the AB8500 GPADC as a prerequisite?
>> In that case I think I need some more pointers...
> 
> I confess I'm a bit lost, but I 'think' the problem we had
> left was around read_avail which doesn't play well if we
> it defined for the _raw value in the provider, but not the _processed value.
> 
> So if we detect their is a _processed channel (which we are going to use) we
> just need to make sure that we don't pass the read_avail for _raw through
> to be exposed by the rescale driver as the consumer as it will be garbage.
> Best plan is probably to just pretend the read_avail for the provider doesn't
> exist in this case.
> 
> @Peter, does that cover it of are there other similar cases?

Yes, that's it. Just hide _raw in read_avail if we are proceding with _processed
as _raw.

> It definitely also wants a big fat comment saying why we are hiding this!

Yup.

Cheers,
Peter



[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