GPIO - marking individual pins (not) available in device tree
Mitch Bradley
wmb at firmworks.com
Fri Oct 24 09:22:03 EST 2008
You could have the gpio node define an "address space" where each
"address" is a GPIO pin number.
The node would have one address cell and one size cell, and the
"decode-unit" and "encode-unit" methods would be the garden-variety
flavors that just convert integers between binary and ASCII. Since this
is not a memory mapped address space, a "ranges" property wouldn't be
necessary or appropriate.
The node could have an "available" property with address/size pairs
defining pins that can be freely used. For example, if pins 4 and 7-9
were free, the available property would contain
000000004 00000001 \ 1 pin starting at #4
000000007 00000003 \ 3 pins starting at 7
This is modeled on the /memory node's "available" property.
Subordinate nodes could represent specific preassigned GPIO functions,
for example
/<whatever>/gpio/wakeup at 12
As an alternative to the "available" property, you could instead have
subordinate nodes for the user-assignable GPIOs, e.g.:
/<whatever>/gpio/usergpio at 4
/<whatever>/gpio/usergpio at 7
...
That last idea is probably a bit over-the-top, though, especially if
there are a lot of unassigned GPIOs.
You could adopt the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by a
subordinate node's "reg" property is implicitly available. That's the
way it works for other address spaces.
Mitch Bradley
> Hi guys,
>
> I'm a little perplexed as to how I would define a GPIO controller in a
> device tree but mark off pins as available or not, so users can geek
> around in their own drivers without defining in a device tree exactly
> what they intend to use it for (especially if it's something really
> weird).
>
> Easiest example - the Efika runs an MPC5200B has 3 GPIO pins on the
> board. It's not much, but they're there for use. All the other GPIOs
> are absolutely out of bounds, off limits and probably dangerous to
> touch, but since each GPIO block has a 32-bit register to handle them,
> you can twiddle any bit you like with impunity and cause all the
> damage you want. A simple thought comes to mind in that the gpiolib
> should not allow a request for one of these "bad" GPIO pins to succeed.
>
> So, how do we define in a bank of GPIOs, which ones are free for use,
> without them being attached to a device and given as a "gpios" property?
>
> Would we suggest a node;
>
> gpio-header {
> compatible = "bplan,efika-gpio";
> gpios = <&gpio-standard 16 0 17 0>;
> };
>
> gpio-header2 {
> compatible = "bplan,efika-gpio-wkup";
> gpios = <&gpio-wkup 18 0>;
> };
>
> Which a driver can then look for? I would much rather I did not have
> to come up with a special compatible property though, after all,
> MPC5200B GPIO are not special and the Efika does not do fancy magic
> with them :)
>
> My goal is basically to give an entry in the device tree whereby
> (using a forth script) you can pick between IrDA, GPIO, a Sleep Switch
> (for Sylvain's patch for Lite5200 and Efika from a year or two ago..),
> or whatever else you like. But a generic GPIO "geek port" is basically
> then undefined and left hanging.
>
> By the way I did notice that none of the GPT timer entries in the
> lite5200b.dts have GPIO references and the GPT GPIO block is not
> defined. Is this because the timers are not exposed on the board for
> GPIO or just no need for it? Each timer has a pin it can sample, drive
> and do PWM on.. this leads me to wonder how the PWM driver framework
> as announced/proposed last week would work here, and if the device
> tree should specifically pick which operation works on which timer
> (after all if you have a PWM fan controller on a timer pin, you would
> want to advertise the fact, but having the full 8 timers as a
> "gpio-controller" and "pwm-controller" both at the same time, sharing
> the same reg property but supporting only a subset of that controller,
> needs addressing.
>
> --
> Matt Sealey <matt at genesi-usa.com>
> Genesi, Manager, Developer Relations
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at ozlabs.org
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
More information about the Linuxppc-dev
mailing list