From: Jon Hunter <jon-hunter@ti.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Javier Martinez Canillas <martinez.javier@gmail.com>,
Grant Likely <grant.likely@secretlab.ca>,
Alexandre Courbot <acourbot@nvidia.com>,
Stephen Warren <swarren@nvidia.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
Date: Tue, 16 Apr 2013 18:14:21 -0500 [thread overview]
Message-ID: <516DDB4D.9020500@ti.com> (raw)
In-Reply-To: <516DCCA8.3070108@wwwdotorg.org>
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
WARNING: multiple messages have this Message-ID (diff)
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 18:14:21 -0500 [thread overview]
Message-ID: <516DDB4D.9020500@ti.com> (raw)
In-Reply-To: <516DCCA8.3070108@wwwdotorg.org>
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
next prev parent reply other threads:[~2013-04-16 23:14 UTC|newest]
Thread overview: 190+ 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 ` Benoit Cousson
2012-02-15 16:04 ` [PATCH 1/5] gpio/omap: Remove bank->id information and misc cleanup Benoit Cousson
2012-02-15 16:04 ` Benoit Cousson
2012-02-16 5:53 ` DebBarma, Tarun Kanti
2012-02-16 5:53 ` DebBarma, Tarun Kanti
2012-02-16 9:33 ` Cousson, Benoit
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-15 16:04 ` Benoit Cousson
2012-02-16 5:41 ` DebBarma, Tarun Kanti
2012-02-16 5:41 ` DebBarma, Tarun Kanti
2012-02-16 6:35 ` Grant Likely
2012-02-16 6:35 ` Grant Likely
2012-02-16 7:11 ` DebBarma, Tarun Kanti
2012-02-16 7:11 ` DebBarma, Tarun Kanti
2012-02-16 6:37 ` Shubhrajyoti
2012-02-16 6:37 ` Shubhrajyoti
2012-02-16 8:56 ` Cousson, Benoit
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-15 16:04 ` Benoit Cousson
2012-02-22 14:23 ` Rob Herring
2012-02-22 14:23 ` Rob Herring
2012-02-22 14:31 ` Cousson, Benoit
2012-02-22 14:31 ` Cousson, Benoit
2012-02-22 17:23 ` Rob Herring
2012-02-22 17:23 ` Rob Herring
2012-02-22 18:29 ` Stephen Warren
2012-02-22 18:29 ` Stephen Warren
2012-02-24 15:30 ` Cousson, Benoit
2012-02-24 15:30 ` Cousson, Benoit
2013-02-26 10:01 ` Javier Martinez Canillas
2013-02-26 10:01 ` Javier Martinez Canillas
2013-02-26 16:33 ` Stephen Warren
2013-02-26 16:33 ` Stephen Warren
2013-02-26 22:40 ` Jon Hunter
2013-02-26 22:40 ` Jon Hunter
2013-02-26 22:44 ` Stephen Warren
2013-02-26 22:44 ` Stephen Warren
2013-02-26 23:01 ` Jon Hunter
2013-02-26 23:01 ` Jon Hunter
2013-02-26 23:06 ` Stephen Warren
2013-02-26 23:06 ` Stephen Warren
2013-02-26 23:45 ` Jon Hunter
2013-02-26 23:45 ` Jon Hunter
2013-02-27 0:13 ` Stephen Warren
2013-02-27 0:13 ` Stephen Warren
2013-02-27 1:07 ` Jon Hunter
2013-02-27 1:07 ` Jon Hunter
2013-02-27 3:57 ` Javier Martinez Canillas
2013-02-27 3:57 ` Javier Martinez Canillas
2013-02-27 17:50 ` Stephen Warren
2013-02-27 17:50 ` Stephen Warren
2013-02-27 20:05 ` Javier Martinez Canillas
2013-02-27 20:05 ` Javier Martinez Canillas
2013-02-27 23:16 ` Jon Hunter
2013-02-27 23:16 ` Jon Hunter
2013-02-28 12:17 ` Javier Martinez Canillas
2013-02-28 12:17 ` Javier Martinez Canillas
2013-02-28 20:49 ` Jon Hunter
2013-02-28 20:49 ` Jon Hunter
[not found] ` <512D3EC2.6050408-l0cyMroinI0@public.gmane.org>
2013-03-02 20:05 ` Grant Likely
2013-03-02 20:05 ` Grant Likely
2013-03-07 23:14 ` Jon Hunter
2013-03-07 23:14 ` Jon Hunter
2013-03-15 11:21 ` Javier Martinez Canillas
2013-03-15 11:21 ` Javier Martinez Canillas
2013-03-22 8:10 ` Linus Walleij
2013-03-22 8:10 ` Linus Walleij
2013-03-22 15:33 ` Stephen Warren
2013-03-22 15:33 ` Stephen Warren
2013-03-22 22:52 ` Jon Hunter
2013-03-22 22:52 ` Jon Hunter
2013-03-27 13:52 ` Linus Walleij
2013-03-27 13:52 ` Linus Walleij
2013-03-27 16:09 ` Stephen Warren
2013-03-27 16:09 ` Stephen Warren
2013-03-27 20:55 ` Linus Walleij
2013-03-27 20:55 ` Linus Walleij
2013-03-29 17:01 ` Stephen Warren
2013-03-29 17:01 ` Stephen Warren
2013-04-10 18:12 ` Linus Walleij
2013-04-10 18:12 ` Linus Walleij
2013-04-10 20:29 ` Stephen Warren
2013-04-10 20:29 ` Stephen Warren
2013-04-10 21:28 ` Linus Walleij
2013-04-10 21:28 ` Linus Walleij
2013-04-11 20:30 ` Stephen Warren
2013-04-11 20:30 ` Stephen Warren
2013-04-11 22:16 ` Linus Walleij
2013-04-11 22:16 ` Linus Walleij
2013-04-11 22:47 ` Stephen Warren
2013-04-11 22:47 ` Stephen Warren
2013-04-14 1:35 ` Javier Martinez Canillas
2013-04-14 1:35 ` Javier Martinez Canillas
2013-04-14 20:53 ` Linus Walleij
2013-04-14 20:53 ` Linus Walleij
2013-04-15 11:25 ` Javier Martinez Canillas
2013-04-15 11:25 ` Javier Martinez Canillas
2013-04-15 16:58 ` Stephen Warren
2013-04-15 16:58 ` Stephen Warren
[not found] ` <516C73C6.5050409@ti.co m>
2013-04-15 21:40 ` Jon Hunter
2013-04-15 21:40 ` Jon Hunter
2013-04-15 21:44 ` Jon Hunter
2013-04-15 21:44 ` Jon Hunter
2013-04-15 22:16 ` Stephen Warren
2013-04-15 22:16 ` Stephen Warren
2013-04-15 23:04 ` Jon Hunter
2013-04-15 23:04 ` Jon Hunter
2013-04-16 18:40 ` Stephen Warren
2013-04-16 18:40 ` Stephen Warren
2013-04-16 19:27 ` Jon Hunter
2013-04-16 19:27 ` Jon Hunter
2013-04-16 21:57 ` Jon Hunter
2013-04-16 21:57 ` Jon Hunter
2013-04-16 22:11 ` Stephen Warren
2013-04-16 22:11 ` Stephen Warren
2013-04-16 23:14 ` Jon Hunter [this message]
2013-04-16 23:14 ` Jon Hunter
2013-04-17 0:41 ` Javier Martinez Canillas
2013-04-17 0:41 ` Javier Martinez Canillas
2013-04-17 2:00 ` Jon Hunter
2013-04-17 2:00 ` Jon Hunter
2013-04-17 7:55 ` Javier Martinez Canillas
2013-04-17 7:55 ` Javier Martinez Canillas
[not found] ` <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-17 13:25 ` Jon Hunter
2013-04-17 13:25 ` Jon Hunter
2013-04-17 13:42 ` Javier Martinez Canillas
2013-04-17 13:42 ` Javier Martinez Canillas
[not found] ` <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-17 13:52 ` Jon Hunter
2013-04-17 13:52 ` Jon Hunter
2013-04-17 14:21 ` Javier Martinez Canillas
2013-04-17 14:21 ` Javier Martinez Canillas
2013-04-17 16:18 ` Javier Martinez Canillas
2013-04-17 16:18 ` Javier Martinez Canillas
2013-04-26 7:31 ` Linus Walleij
2013-04-26 7:31 ` Linus Walleij
2013-04-26 21:31 ` Jon Hunter
2013-04-26 21:31 ` Jon Hunter
2013-06-11 21:25 ` Grant Likely
2013-06-11 21:25 ` Grant Likely
2013-06-12 9:43 ` Linus Walleij
2013-06-12 9:43 ` Linus Walleij
2013-04-17 15:41 ` Stephen Warren
2013-04-17 15:41 ` Stephen Warren
2013-04-26 7:27 ` Linus Walleij
2013-04-26 7:27 ` Linus Walleij
2013-04-26 21:25 ` Jon Hunter
2013-04-26 21:25 ` Jon Hunter
[not found] ` <517AF0C1.60009-l0cyMroinI0@public.gmane.org>
2013-05-03 14:35 ` Linus Walleij
2013-05-03 14:35 ` Linus Walleij
2013-04-26 7:11 ` Linus Walleij
2013-04-26 7:11 ` Linus Walleij
2013-04-26 6:59 ` Linus Walleij
2013-04-26 6:59 ` Linus Walleij
2013-04-15 16:53 ` Stephen Warren
2013-04-15 16:53 ` Stephen Warren
2013-04-15 20:00 ` Jon Hunter
2013-04-15 20:00 ` Jon Hunter
2013-04-11 22:49 ` Javier Martinez Canillas
2013-04-11 22:49 ` Javier Martinez Canillas
2013-04-11 22:51 ` Stephen Warren
2013-04-11 22:51 ` Stephen Warren
2013-04-10 21:44 ` Arnd Bergmann
2013-04-10 21:44 ` Arnd Bergmann
2013-02-27 3:33 ` Javier Martinez Canillas
2013-02-27 3:33 ` Javier Martinez Canillas
2013-02-27 17:47 ` Stephen Warren
2013-02-27 17:47 ` Stephen Warren
2013-02-27 20:00 ` Javier Martinez Canillas
2013-02-27 20:00 ` Javier Martinez Canillas
2013-02-26 23:08 ` Jon Hunter
2013-02-26 23:08 ` Jon Hunter
2013-02-27 3:47 ` Javier Martinez Canillas
2013-02-27 3:47 ` Javier Martinez Canillas
2013-02-27 20:13 ` Jon Hunter
2013-02-27 20:13 ` Jon Hunter
2013-02-27 23:41 ` Linus Walleij
2013-02-27 23:41 ` Linus Walleij
2013-02-28 13:04 ` Benoit Cousson
2013-02-28 13:04 ` Benoit Cousson
2013-03-01 0:09 ` Linus Walleij
2013-03-01 0:09 ` Linus Walleij
2013-03-01 0:42 ` Jon Hunter
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 ` Benoit Cousson
2012-02-15 16:04 ` [PATCH 5/5] arm/dts: OMAP3: " Benoit Cousson
2012-02-15 16:04 ` 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=516DDB4D.9020500@ti.com \
--to=jon-hunter@ti.com \
--cc=acourbot@nvidia.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=khilman@deeprootsystems.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=martinez.javier@gmail.com \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.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.