(Added devicetree and linuxppc-dev to cc: list) On Wed, Sep 9, 2009 at 5:50 AM, Vitaly Bordug<v...@kernel.crashing.org> wrote: > Hi Grant, > > Remember I was asking some time ago about multiple gpio chips per > device node to enable sint gpio on 52xx? > > I need an advice again: adding multiple chips is OK but it stores > address of the of_gpio_chip or smth like that in device_node->data. > And that is used in routine that grabs all data from gpios<>. Hereby > to implement multiple chips, I'd need to store in device_node ->data > ponter to the array of gpio_chips, and to store actual amount of those > chips somewhere, + study of_get_gpio_flags() to traverse several > gpio_chips. That way, gpio_cells would be 3. Seems a little overkill...
Hmmm. Refactoring the existing binding in non-backwards compatible ways is not okay. gpio_cells cannot be changed from 2 to 3 without breaking existing users. > Maybe it would be better to split away gpio_sint stuff? I don't like it much since it kind of is one block of registers. However, a binding change must be made regardless because the current binding has no method of describing the sint pins (or the output-only pins for that matter). That leaves 2 options that I see: 1) Add a new node for the sint register range in the GPIO standard registers block. 2) add some kind of offset to the 1st cell in the gpio property. (ie. 0-0x20 for simple GPIOs, 0x200-0x207 for interrupt gpios, and 0x100-0x107 for output only gpios) I'll ignore which approach is easier to implement currently in Linux and try to focus on what the best binding would be. Option 2 looks pretty ugly and non-intuitive to me. The only advantage there is it keeps things described as a single block in the mpc5200 user manual all in one node. However, I think the clarity of option 1 wins out, especially considering that there isn't currently any code that tries to describe the sint pins in the device tree, so it has a smaller likelyhood of causing breakage. ... so it would seem that my opinion on this matter is now the exact opposite from the last time I talked to you now that I've actually looked at the binding. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
