Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux