[PATCH 3/5] gpio/omap: Add DT support to GPIO driver
Stephen Warren
swarren at wwwdotorg.org
Wed Apr 17 08:11:52 EST 2013
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.
c) I have the feeling that hooking the of_xlate function for this is a
bit of an abuse of the function.
More information about the devicetree-discuss
mailing list