On Mon, Oct 27, 2008 at 01:56:03PM -0500, Matt Sealey wrote: > 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.
Sorry, your mail doesn't make any sense to me. That makes me think that you you didn't understand the whole GPIO thing... Or maybe I misunderstood you completely. Can you _simply_ describe the problem you're trying to solve, w/o that much emotions? Can you give examples of what you've tried, and describe why you don't like it? Am I understand correctly that some 52xx boards have an external GPIOs header, and you need to describe it, and maybe write some driver to do something with a device called _GPIO header_ with a _pin_ named "wakeup" that connects to a CPU _pin_ that pinmuxed to a _GPIO_ that can wakeup the CPU? I remember I purposed the solution to this problem, what was wrong with it? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev