Messages in this thread |  | | Subject | Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector | From | Peter Rosin <> | Date | Sat, 22 Oct 2016 00:58:27 +0200 |
| |
On 2016-10-21 09:17, jic23@kernel.org wrote: > On 20.10.2016 19:17, Peter Rosin wrote: >> On 2016-10-20 19:37, Jonathan Cameron wrote: >>> On 20 October 2016 18:30:19 BST, Jonathan Cameron >>> <jic23@jic23.retrosnub.co.uk> wrote: >>>> On 20 October 2016 13:55:12 BST, Lars-Peter Clausen <lars@metafoo.de> >>>> wrote: >>>>> On 10/20/2016 11:25 AM, Peter Rosin wrote: >>>>>> Also, is there some agreed-upon way to dig out the maximum value >>>>>> from >>>>>> an iio channel? If so, "dpot-dac,max-ohms" can be eliminated from >>>>>> the >>>>>> dt bindings, which would have been nice... >>>>> >>>>> Yes, this is something we could really use. In a sense it exists for >>>>> the >>>>> devices with buffer-capable channels where there is the real_bits >>>>> field >>>>> which tells us the data width of the channel. But a dedicated >>>>> mechanism >>>>> for >>>>> querying the maximum (and minimum) valid code seems like a useful >>>>> feature. >>>>> Not only for in-kernel clients, but also for userspace. >>>> >>>> This was something that was addressed by the rather ancient patch >>>> series i posted that added >>>> an available call back which provided info on range and values for >>>> all info mask elements. >>>> Series got buried by there being a lot of precursors but quite a few of >>>> those have merged since. >>>> >>>> Hmm Google won't let me find it on my phone. Was a while back now. >>>> Will >>>> try to get on pc with >>>> decent email archive later and dig out a reference. >>> http://marc.info/?l=linux-iio&m=138469765309868&w=2 I think... >> >> Interesting, one issue with that is that it is all in real world >> units, while I'd rather have the raw value. > Um.. It's been a while, but the principle was (IIRC) that every > _available would match the units fo the associated info mask element. > Thus if you have a _raw element it would be in adc counts (most likely). > > _input would be in relevant real world units, scale etc in the whatever > units the value itself is in.
Ok, so I forward ported that patch and added code so that the relevant channels provide what is available. I also added code to turn the rest of the parameter style devicetree properties into iio device/channel attributes. So, it is now much neater from a bindings point of view.
Before I post the updated patches, I'm wondering what the status is on that ancient patch? It didn't forward port without issues, but there were no real difficulties that I noticed. Should I just start off my v2 series with that patch? I tend to think that that's the best option, because I suspect that adding a "max-ohms" devicetree property as a stop-gap pending some new infrastructure is pretty unrealistic...
Basically, my question is if that ancient patch as any chance of living at all in a form close to what it is, or if should start looking for an alternative right away?
Cheers, Peter
|  |