Re: [PATCH 1/5] iio: xoadc: augment DT bindings a bit

[Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

On 24/03/17 15:25, Linus Walleij wrote:
> On Fri, Mar 24, 2017 at 4:12 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Sat, Mar 18, 2017 at 02:33:58PM +0100, Linus Walleij wrote:
> 
>>> -- #address-cells: should be set to <1>
>>> +- #address-cells: should be set to <2>, the first cell is the
>>> +  prescaler (on PM8058) or premux (on PM8921) with two valid bits
>>> +  so legal values are 0x00, 0x01 or 0x02. The second cell
>>> +  is the main analog mux setting (0x00..0x0f). The combination
>>> +  of prescaler/premux and analog mux uniquely addresses a hardware
>>> +  channel on all systems.
>>
>> 64-bits to describe 48 possible combinations... I'd just combine these
>> into 1 cell.
> 
> That was what I did first but it becomes very unintuitive and
> require translation using tables etc from the datasheets. You
> have to shuffle and stuff bits to get that one cell value.
> 
> The addressing is really done in two steps:
> 
> premux -> mux -> channel
> 
> Example:
> 
> Premux 0x02
> Mux 0x08
> 
> I guess I could of course put that into one cell using 4+4 bits
> and form 0x28.
> 
> On the other hand, that is not how the hardware works, because
> there premux/prescaler and analog mux are two separate things.
> 
>>>  - reg: should contain the hardware channel number in the range
>>> -  0 .. 0x0f (4 bits). The hardware only supports 16 channels.
>>> +  0 .. 0xff (8 bits).
>>> +
>>> +  On PM8058 the hardware only supports 16 channels, but we get the same
>>> +  channels repeating with its input divided down by 1 or 3. Channels 00,
>>> +  10, 20, ... f0 are the raw values, 04, 14, 24 .. f4 are "unity" channels
>>> +  divided by 1, and 08, 18, 28 .. f8 are channels divided by 3. Bits 0
>>> +  and 1 of the channel index should always be 0.
>>> +
>>> +  On PM8921 the hardware supports more than 16 channels through a complex
>>> +  routing matrix using a premux, so 00, 10, 20 .. f0 are the basic raw
>>> +  channels while another set of channels appear for 04, 14, 24 .. f4,
>>> +  and again some of the same channels appear again divided down by 3
>>> +  in 08, 18, 28 .. f8. Again bits 0 and 1 of the channel index should
>>> +  always be 0.
>>
>> Now I'm lost...
> 
> That is actually how it looks with the old scheme, which you are
> kind of requesting that I use instead. In a way it's good that I left
> the old documentation in there because it illustrates my problem
> with what you request above: lots of "holes" in that address
> space and very unituitive numbers.
> 
I definitely agree that clarity is probably better than worrying about the
few extra bytes...

Jonathan
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html