Anton Vorontsov wrote:
The GPIO spec doesn't specify a controller bank. It says - - - - gpio-specifier may encode: bank, pin position inside the bank, whether pin is open-drain and whether pin is logically inverted. - - - - May encode. Or may not encode. FYI, for most (all) SOC GPIO controllers we don't use "bank" encoding in the gpio-specifier.
This is exactly 100% precisely why I asked about it, there should at least be a binding for each specific controller where this is relevant, but since there is very little variation on "use pin 15 please with these flags" (only what "pin 15" means is undefined so far, and left to the driver/controller variation) there must be a generic way to specify groups of IO pins which may not be consecutive. I don't get your example; > device { > gpios = <&gpio 0 0 &gpio 1 0 &gpio 2 0>; > } > > ^^ Three gpios, 0, 1, 2. Based on a compatible entry Linux can > translate them in any way. > > For example GPIO0 - bit 15, GPIO1 - bit 20, GPIO2 - bit 1. This kind of defeats the object. While the pin numbering may well be board-specific, it makes sense to maintain it as it relates to offsets into a register or offsets into a bank of registers the same way that interrupt mappings on the MPC5200B are ripped out of a table in the MPC5200B documentation. What the above example does is give a completely arbitrary number which only maps to a real pin or offset *inside the driver* meaning 10 boards with the same chip all have to have different drivers, gpio_chip libraries to allocate the pins - the driver to note which pin is for which purpose, and gpiolib to make sure some driver accessing them has not been loaded twice. Right? Even if I have my Efika sitting here I want to share my GPIO library code between it and the lite5200b - be that making the "sleep switch" code look for a certain gpio pin marker in the device tree so it knows what to allocate (so the number isn't hardcoded into the driver as a compile-time switch or a check for the /soc node model) The current model seems to me like it is not getting any benefit whatsoever from being defined in a device tree, in fact it is making certain GPIO functionality go back to the hardcoded-per-board stuff we used to have in arch/ppc. This is just proving the point that nobody is forward-thinking about this stuff, and is just implementing hack over hack over hack to get something to work, and refining it later. We're already running kernels which need to be specially built for specially built U-Boot versions, special options for the dtc, and device trees which change every other week. Specifying the bare minimum here for the functionality a single user uses defeats the object of having a descriptive device tree. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev