On Fri, Mar 24, 2017 at 4:12 PM, Rob Herring <robh@xxxxxxxxxx> 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. Yours, Linus Walleij -- 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
