On 2016-10-21 09:17, jic23@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx> wrote: >>>> On 20 October 2016 13:55:12 BST, Lars-Peter Clausen <lars@xxxxxxxxxx> >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
