From: jon-hunter@ti•com (Jon Hunter)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
Date: Tue, 16 Apr 2013 21:00:15 -0500 [thread overview]
Message-ID: <516E022F.5050708@ti.com> (raw)
In-Reply-To: <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter <jon-hunter@ti•com> wrote:
>>
>> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>>
>>>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>>> ...
>>>>>> If some driver is calling gpio_request() directly, then they will most
>>>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>>>> xlate function would not be called in this case (mmc drivers are a good
>>>>>> example). So I don't see that as being a problem. In fact that's the
>>>>>> benefit of this approach as AFAICT it solves this problem.
>>>>>
>>>>> Oh. That assumption seems very fragile. What about drivers that actually
>>>>> do have platform data (or DT bindings) that provide both the IRQ and
>>>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>>>
>>>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>>>> IDs then at least they would use a different xlate function. Another
>>>> option to consider would be defining the #interrupt-cells = <3> where we
>>>> would have ...
>>>>
>>>> cell-#1 --> IRQ domain ID
>>>> cell-#2 --> Trigger type
>>>> cell-#3 --> GPIO ID
>>>>
>>>> Then we could have a generic xlate for 3 cells that would also request
>>>> the GPIO. Again not sure if people are against a gpio being requested in
>>>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>>>> the xlate, we could have this function call gpio_request() if the
>>>> interrupt controller is a gpio and there are 3 cells.
>>>
>>> I rather dislike this approach since:
>>>
>>> a) It requires changes to the DT bindings, which are already defined.
>>> Admittedly it's backwards-compatible, but still.
>>>
>>> b) There isn't really any need for the DT to represent this; the
>>> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
>>> vice-versa (if the HW has such a concept), so there's no need for the DT
>>> to contain this information. This seems like pushing Linux's internal
>>> requirements into the design of the DT binding.
>>
>> Yes, so the only alternative is to use irq_to_gpio to avoid this.
>>
>>> c) I have the feeling that hooking the of_xlate function for this is a
>>> bit of an abuse of the function.
>>
>> I was wondering about that. So I was grep'ing through the various xlate
>> implementations and found this [1]. Also you may recall that in the
>> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
>> channel, which is very similar. However, I don't wish to get a
>> reputation as abusing APIs so would be good to know if this really is
>> abuse or not ;-)
>>
>> Cheers
>> Jon
>>
>> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
>
> I was looking at [1] shared by Jon and come up with the following
> patch that does something similar for OMAP GPIO. This has the
> advantage that is local to gpio-omap instead changing gpiolib-of and
> also doesn't require DT changes
>
> But I don't want to get a reputation for abusing APIs neither :-)
>
> Best regards,
> Javier
>
> From 23368eb72b125227fcf4b22be19ea70b4ab94556 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora•co.uk>
> Date: Wed, 17 Apr 2013 02:03:08 +0200
> Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora•co.uk>
> ---
> drivers/gpio/gpio-omap.c | 29 ++++++++++++++++++++++++++++-
> 1 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 8524ce5..77216f9 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1097,6 +1097,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
> static const struct of_device_id omap_gpio_match[];
> static void omap_gpio_init_context(struct gpio_bank *p);
>
> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
> + struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq,
> + unsigned int *out_type)
> +{
> + int ret;
> + struct gpio_bank *bank = d->host_data;
> + int gpio = bank->chip.base + intspec[0];
> +
> + if (WARN_ON(intsize < 2))
> + return -EINVAL;
> +
> + ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
> + if (ret)
> + return ret;
> +
> + *out_hwirq = intspec[0];
> + *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops omap_gpio_irq_ops = {
> + .xlate = omap_gpio_irq_domain_xlate,
> +};
> +
> static int omap_gpio_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1144,7 +1171,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>
>
> bank->domain = irq_domain_add_linear(node, bank->width,
> - &irq_domain_simple_ops, NULL);
> + &omap_gpio_irq_ops, bank);
> if (!bank->domain)
> return -ENODEV;
>
That would work for omap, in fact I posted pretty much the same thing a
day ago [1] ;-)
I was trying to see if we could find a common solution that everyone
could use as it seems that ideally we should all be requesting the gpio.
Cheers
Jon
[1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
next prev parent reply other threads:[~2013-04-17 2:00 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-15 16:04 [PATCH 0/5] gpio/omap: Cleanup and adaptation to Device Tree Benoit Cousson
2012-02-15 16:04 ` [PATCH 1/5] gpio/omap: Remove bank->id information and misc cleanup Benoit Cousson
2012-02-16 5:53 ` DebBarma, Tarun Kanti
2012-02-16 9:33 ` Cousson, Benoit
2012-02-15 16:04 ` [PATCH 2/5] gpio/omap: Use devm_ API and add request_mem_region Benoit Cousson
2012-02-16 5:41 ` DebBarma, Tarun Kanti
2012-02-16 6:35 ` Grant Likely
2012-02-16 7:11 ` DebBarma, Tarun Kanti
2012-02-16 6:37 ` Shubhrajyoti
2012-02-16 8:56 ` Cousson, Benoit
2012-02-15 16:04 ` [PATCH 3/5] gpio/omap: Add DT support to GPIO driver Benoit Cousson
2012-02-22 14:23 ` Rob Herring
2012-02-22 14:31 ` Cousson, Benoit
2012-02-22 17:23 ` Rob Herring
2012-02-22 18:29 ` Stephen Warren
2012-02-24 15:30 ` Cousson, Benoit
2013-02-26 10:01 ` Javier Martinez Canillas
2013-02-26 16:33 ` Stephen Warren
2013-02-26 22:40 ` Jon Hunter
2013-02-26 22:44 ` Stephen Warren
2013-02-26 23:01 ` Jon Hunter
2013-02-26 23:06 ` Stephen Warren
2013-02-26 23:45 ` Jon Hunter
2013-02-27 0:13 ` Stephen Warren
2013-02-27 1:07 ` Jon Hunter
2013-02-27 3:57 ` Javier Martinez Canillas
2013-02-27 17:50 ` Stephen Warren
2013-02-27 20:05 ` Javier Martinez Canillas
2013-02-27 23:16 ` Jon Hunter
2013-02-28 12:17 ` Javier Martinez Canillas
2013-02-28 20:49 ` Jon Hunter
2013-03-02 20:05 ` Grant Likely
2013-03-07 23:14 ` Jon Hunter
2013-03-15 11:21 ` Javier Martinez Canillas
2013-03-22 8:10 ` Linus Walleij
2013-03-22 15:33 ` Stephen Warren
2013-03-22 22:52 ` Jon Hunter
2013-03-27 13:52 ` Linus Walleij
2013-03-27 16:09 ` Stephen Warren
2013-03-27 20:55 ` Linus Walleij
2013-03-29 17:01 ` Stephen Warren
2013-04-10 18:12 ` Linus Walleij
2013-04-10 20:29 ` Stephen Warren
2013-04-10 21:28 ` Linus Walleij
2013-04-11 20:30 ` Stephen Warren
2013-04-11 22:16 ` Linus Walleij
2013-04-11 22:47 ` Stephen Warren
2013-04-14 1:35 ` Javier Martinez Canillas
2013-04-14 20:53 ` Linus Walleij
2013-04-15 11:25 ` Javier Martinez Canillas
2013-04-15 16:58 ` Stephen Warren
2013-04-15 21:40 ` Jon Hunter
2013-04-15 21:44 ` Jon Hunter
2013-04-15 22:16 ` Stephen Warren
2013-04-15 23:04 ` Jon Hunter
2013-04-16 18:40 ` Stephen Warren
2013-04-16 19:27 ` Jon Hunter
2013-04-16 21:57 ` Jon Hunter
2013-04-16 22:11 ` Stephen Warren
2013-04-16 23:14 ` Jon Hunter
2013-04-17 0:41 ` Javier Martinez Canillas
2013-04-17 2:00 ` Jon Hunter [this message]
2013-04-17 7:55 ` Javier Martinez Canillas
2013-04-17 13:25 ` Jon Hunter
2013-04-17 13:42 ` Javier Martinez Canillas
2013-04-17 13:52 ` Jon Hunter
2013-04-17 14:21 ` Javier Martinez Canillas
2013-04-17 16:18 ` Javier Martinez Canillas
2013-04-26 7:31 ` Linus Walleij
2013-04-26 21:31 ` Jon Hunter
2013-06-11 21:25 ` Grant Likely
2013-06-12 9:43 ` Linus Walleij
2013-04-17 15:41 ` Stephen Warren
2013-04-26 7:27 ` Linus Walleij
2013-04-26 21:25 ` Jon Hunter
2013-05-03 14:35 ` Linus Walleij
2013-04-26 7:11 ` Linus Walleij
2013-04-26 6:59 ` Linus Walleij
2013-04-15 16:53 ` Stephen Warren
2013-04-15 20:00 ` Jon Hunter
2013-04-11 22:49 ` Javier Martinez Canillas
2013-04-11 22:51 ` Stephen Warren
2013-04-10 21:44 ` Arnd Bergmann
2013-02-27 3:33 ` Javier Martinez Canillas
2013-02-27 17:47 ` Stephen Warren
2013-02-27 20:00 ` Javier Martinez Canillas
2013-02-26 23:08 ` Jon Hunter
2013-02-27 3:47 ` Javier Martinez Canillas
2013-02-27 20:13 ` Jon Hunter
2013-02-27 23:41 ` Linus Walleij
2013-02-28 13:04 ` Benoit Cousson
2013-03-01 0:09 ` Linus Walleij
2013-03-01 0:42 ` Jon Hunter
2012-02-15 16:04 ` [PATCH 4/5] arm/dts: OMAP4: Add gpio nodes Benoit Cousson
2012-02-15 16:04 ` [PATCH 5/5] arm/dts: OMAP3: " Benoit Cousson
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=516E022F.5050708@ti.com \
--to=jon-hunter@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