All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	devicetree-discuss list <devicetree-discuss@ozlabs.org>
Subject: GPIO - marking individual pins (not) available in device tree
Date: Thu, 23 Oct 2008 16:32:49 -0500	[thread overview]
Message-ID: <4900ED81.3040202@genesi-usa.com> (raw)

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@genesi-usa.com>
Genesi, Manager, Developer Relations

WARNING: multiple messages have this Message-ID (diff)
From: Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
To: linuxppc-dev list
	<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	devicetree-discuss list
	<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Subject: GPIO - marking individual pins (not) available in device tree
Date: Thu, 23 Oct 2008 16:32:49 -0500	[thread overview]
Message-ID: <4900ED81.3040202@genesi-usa.com> (raw)

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-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
Genesi, Manager, Developer Relations

             reply	other threads:[~2008-10-23 21:32 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 21:32 Matt Sealey [this message]
2008-10-23 21:32 ` GPIO - marking individual pins (not) available in device tree Matt Sealey
2008-10-23 22:22 ` Mitch Bradley
2008-10-23 23:05   ` Matt Sealey
2008-10-24  0:52     ` Mitch Bradley
2008-10-24  3:29       ` David Gibson
2008-10-24  3:29         ` David Gibson
2008-10-24  4:17         ` Mitch Bradley
2008-10-24  4:17           ` Mitch Bradley
2008-10-24  4:45           ` David Gibson
2008-10-24  4:45             ` David Gibson
2008-10-24 22:14             ` Matt Sealey
2008-10-26 23:47               ` David Gibson
2008-10-27 15:40                 ` Matt Sealey
2008-10-27 18:34                   ` Anton Vorontsov
2008-10-27 18:56                     ` Matt Sealey
2008-10-27 20:10                       ` Anton Vorontsov
2008-10-27 20:10                         ` Anton Vorontsov
2008-10-27 21:56                         ` Matt Sealey
2008-10-27 21:56                           ` Matt Sealey
2008-10-27 23:12                           ` Anton Vorontsov
2008-10-27 23:12                             ` Anton Vorontsov
2008-10-27 23:40                             ` Anton Vorontsov
2008-10-28  0:47                               ` Matt Sealey
2008-10-28  1:11                             ` Matt Sealey
2008-10-28  1:11                               ` Matt Sealey
2008-10-28  2:37                               ` Anton Vorontsov
2008-10-28 16:53                                 ` Matt Sealey
2008-10-28 16:53                                   ` Matt Sealey
2008-10-28 17:39                                   ` Grant Likely
2008-10-28 19:46                                     ` Matt Sealey
2008-10-28 19:46                                       ` Matt Sealey
2008-10-28  0:15                   ` David Gibson
2008-10-28  0:15                     ` David Gibson
2008-10-28  0:51                     ` Matt Sealey
2008-10-28  1:50                       ` David Gibson
2008-10-28  5:20                       ` Grant Likely
2008-10-28  5:20                         ` Grant Likely
2008-10-24 22:03       ` Matt Sealey
2008-10-24 22:20         ` Stephen Neuendorffer
2008-10-24 22:20           ` Stephen Neuendorffer
2008-10-26 21:39           ` Matt Sealey
2008-10-24 23:44         ` Mitch Bradley
2008-10-26 21:13           ` Matt Sealey
2008-10-26 21:13             ` Matt Sealey
2008-10-26 23:53             ` David Gibson
2008-10-27 16:12               ` Matt Sealey
2008-10-27 16:12                 ` Matt Sealey
2008-10-27 16:35                 ` Scott Wood
2008-10-27 16:35                   ` Scott Wood
2008-10-27 17:05                   ` Matt Sealey
2008-10-27 17:25                     ` Scott Wood
2008-10-27 17:49                       ` Matt Sealey
2008-10-27 17:54                         ` Scott Wood
2008-10-28  0:38                           ` David Gibson
2008-10-28  0:38                             ` David Gibson
2008-10-28  0:34                 ` David Gibson
2008-10-28  0:34                   ` David Gibson
2008-10-24  4:58     ` David Gibson
2008-10-24  3:27   ` David Gibson
2008-10-24  3:27     ` David Gibson
2008-10-24 16:41 ` Anton Vorontsov
2008-10-24 17:01   ` Anton Vorontsov
2008-10-24 22:17     ` Matt Sealey
2008-10-24 22:17       ` Matt Sealey
2008-10-24 22:37       ` Anton Vorontsov
  -- strict thread matches above, loose matches on Subject: below --
2008-10-28 13:31 Konstantinos Margaritis
2008-10-28 14:11 ` Anton Vorontsov
2008-10-28 14:11   ` Anton Vorontsov
2008-10-28 14:15 ` Grant Likely
2008-10-28 14:15   ` Grant Likely
2008-10-28 17:06   ` Matt Sealey
2008-10-28 17:06     ` Matt Sealey
2008-10-28 17:32     ` Grant Likely
2008-10-28 23:37 ` David Gibson
2008-10-28 23:37   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4900ED81.3040202@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.