From: b-cousson@ti•com (Cousson, Benoit)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH 08/10] gpio/omap: Adapt GPIO driver to DT
Date: Fri, 9 Sep 2011 03:48:33 +0200 [thread overview]
Message-ID: <4E697071.6040804@ti.com> (raw)
In-Reply-To: <20110908181507.GG2967@ponder.secretlab.ca>
On 9/8/2011 8:15 PM, Grant Likely wrote:
> On Wed, Aug 24, 2011 at 03:09:14PM +0200, Benoit Cousson wrote:
>> Adapt the GPIO driver to retrieve information from a DT file.
>> Note that since the driver is currently under cleanup, some hacks
>> will have to be removed after.
>>
>> Signed-off-by: Benoit Cousson<b-cousson@ti•com>
>> Cc: Grant Likely<grant.likely@secretlab•ca>
>> Cc: Charulatha V<charu@ti•com>
>> Cc: Tarun Kanti DebBarma<tarun.kanti@ti•com>
>
> Mostly looks good. Comments below.
>
>> ---
>> drivers/gpio/gpio-omap.c | 103 ++++++++++++++++++++++++++++++++++++++++++----
>> 1 files changed, 94 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0599854..96d19d7 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -21,6 +21,7 @@
>> #include<linux/io.h>
>> #include<linux/slab.h>
>> #include<linux/pm_runtime.h>
>> +#include<linux/of_platform.h>
>>
>> #include<mach/hardware.h>
>> #include<asm/irq.h>
>> @@ -521,7 +522,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
>> unsigned long flags;
>>
>> if (bank->non_wakeup_gpios& gpio_bit) {
>> - dev_err(bank->dev,
>> + dev_err(bank->dev,
>
> nit: unrelated whitespace change
>
>> "Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
>> return -EINVAL;
>> }
>> @@ -1150,6 +1151,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
>> irq_set_handler_data(bank->irq, bank);
>> }
>>
>> +static const struct of_device_id omap_gpio_match[];
>> +
>> static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> {
>> static int gpio_init_done;
>> @@ -1157,11 +1160,25 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> struct resource *res;
>> int id;
>> struct gpio_bank *bank;
>> + struct device_node *node = pdev->dev.of_node;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(omap_gpio_match,&pdev->dev);
>> + if (match) {
>> + pdata = match->data;
>> + /* XXX: big hack until the bank_count is removed */
>> + of_property_read_u32(node, "bank_count",&gpio_bank_count);
>
> Nit: by convention, '-' is preferred over '_' in DT property names.
>
>> + if (of_property_read_u32(node, "id",&id))
>> + return -EINVAL;
>> + /* XXX: maybe the id in DT should be zero based to avoid that */
>> + id -= 1;
>
> Actually, the reason it is -1 based, is that when using the DT, gpio
> number are dynamically assigned. Since the gpio numbers are resolved
> entirely within the core DT gpio support code, the number used by
> linux isn't actually important for building a .dts file.
I'm not sure about that. The six controllers are handled as banks, so
the order does matters. In fact it should be considered as a big GPIO
controller with 192 entries. And this is that global number that the HW
documentation, board definition and even pin mux use.
The user does not even have a clue about the controller used without
doing a little bit of math.
Here is for example how a beagle board is using the gpio global number.
static struct gpio omap3_beagle_rev_gpios[] __initdata = {
{ 171, GPIOF_IN, "rev_id_0" },
{ 172, GPIOF_IN, "rev_id_1" },
{ 173, GPIOF_IN, "rev_id_2" },
};
The current GPIO usage will force us doing that:
node {
gpios = <&gpio6 11 0>,
<&gpio6 12 0>,
<&gpio6 13 0>;
};
It looks to me that this kind of conversion tends to be error prone.
I guess that this is a quite standard organization, so is there a way to
handle that global number? Like that for example:
node {
gpios = <&omap_gpio 171 0>,
<&omap_gpio 172 0>,
<&omap_gpio 173 0>;
};
Benoit
next prev parent reply other threads:[~2011-09-09 1:48 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 13:09 [RFC PATCH 00/10] OMAP: Add DT support for early init OMAP4 devices Benoit Cousson
2011-08-24 13:09 ` [RFC PATCH 01/10] OMAP2+: l3-noc: Add support for device-tree Benoit Cousson
2011-09-08 18:01 ` Grant Likely
2011-09-08 21:59 ` Cousson, Benoit
2011-09-08 23:35 ` Grant Likely
2011-08-24 13:09 ` [RFC PATCH 02/10] arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver Benoit Cousson
2011-09-08 18:03 ` Grant Likely
2011-09-09 0:10 ` Cousson, Benoit
2011-09-09 2:41 ` Grant Likely
2011-08-24 13:09 ` [RFC PATCH 03/10] documentation/dt: Add l3-noc bindings Benoit Cousson
2011-09-08 18:06 ` Grant Likely
2011-09-09 0:18 ` Cousson, Benoit
2011-08-24 13:09 ` [RFC PATCH 04/10] arm/dts: OMAP4: Add mpu, dsp and iva nodes Benoit Cousson
2011-09-08 18:07 ` Grant Likely
2011-08-24 13:09 ` [RFC PATCH 05/10] documentation/dt: Add mpu, dsp and iva bindings Benoit Cousson
2011-09-08 18:09 ` Grant Likely
2011-09-09 0:30 ` Cousson, Benoit
2011-09-09 2:40 ` Grant Likely
2011-08-24 13:09 ` [RFC PATCH 06/10] hwspinlock: OMAP4: Add spinlock support in DT Benoit Cousson
2011-09-07 19:58 ` Ohad Ben-Cohen
2011-09-08 7:14 ` Cousson, Benoit
2011-09-08 7:56 ` Ohad Ben-Cohen
2011-09-08 8:07 ` Cousson, Benoit
2011-09-08 8:11 ` Ohad Ben-Cohen
2011-09-08 14:47 ` Arnd Bergmann
2011-09-08 15:34 ` Cousson, Benoit
2011-09-08 16:03 ` Arnd Bergmann
2011-09-08 16:36 ` Ohad Ben-Cohen
2011-09-09 12:58 ` Arnd Bergmann
2011-09-11 7:57 ` Ohad Ben-Cohen
2011-09-12 14:32 ` Arnd Bergmann
2011-08-24 13:09 ` [RFC PATCH 07/10] documentation/dt: Add spinlock bindings Benoit Cousson
2011-09-08 18:10 ` Grant Likely
2011-09-09 0:32 ` Cousson, Benoit
2011-08-24 13:09 ` [RFC PATCH 08/10] gpio/omap: Adapt GPIO driver to DT Benoit Cousson
2011-09-08 18:15 ` Grant Likely
2011-09-09 1:48 ` Cousson, Benoit [this message]
2011-08-24 13:09 ` [RFC PATCH 09/10] arm/dts: OMAP4: Add gpio nodes Benoit Cousson
2011-09-08 18:16 ` Grant Likely
2011-08-24 13:09 ` [RFC PATCH 10/10] documentation/dt: Add OMAP GPIO properties Benoit Cousson
2011-09-08 18:18 ` Grant Likely
2011-09-09 1:51 ` Cousson, Benoit
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=4E697071.6040804@ti.com \
--to=b-cousson@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox