Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:13 +0200
Peter Rosin <peda@xxxxxxxxxx> wrote:

> On 2018-03-27 15:22, Jonathan Cameron wrote:
> > On Tue, 27 Mar 2018 09:42:40 +0200
> > Peter Rosin <peda@xxxxxxxxxx> wrote:  
> >> On 2018-03-24 15:03, Jonathan Cameron wrote:  
> >>> On Mon, 19 Mar 2018 18:02:46 +0100
> >>> Peter Rosin <peda@xxxxxxxxxx> wrote:  
> >>>> +	if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> >>>> +		chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);    
> >>> if the parent doesn't support RAW, is there a lot of point in carrying on?    
> >>
> >> Nope, better to error out I suppose. But I'm not familiar with channels
> >> without RAW, what alternatives are there anyway?  
> > 
> > Potentially _PROCESSED though that will need somewhat different handling.
> > A nasty trick for that might be to map it to RAW and then have the SCALE
> > reflect the divider circuit scale only.  
> 
> Hmm, I think a lot of things might assume RAW to be a pure integer, and
> maybe they are even correct to do so? So yes, that seems nasty indeed...
Seems unlikely to occur often as ADCs are mostly linear, but you never
know...  We'll figure it out when it happens.

> 
> > It's perfectly possible to have channels with neither _RAW or _PROCESSED
> > but I suspect we don't care about them here.
> > 
> > There might be an application that needs to do buffered data flows in the
> > long run, but we can figure out how to do that when one exists.
> > 
> > It won't be a huge amount more than you have here, though we might need
> > a trigger pass through as well to allow you to set the trigger for
> > the front end and having it automatically applied to the backend.  
> 
> Yes, this is the same for the iio-mux. I don't need it, I in fact need
> very little bandwidth for these things. Someone with an itch will have
> to fill in the buffer/trigger handling...
Absolutely!

> 
> Cheers,
> Peter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html