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 02/26/2013 04:01 PM, Jon Hunter wrote:
> 
> On 02/26/2013 04:44 PM, Stephen Warren wrote:
>> On 02/26/2013 03:40 PM, Jon Hunter wrote:
>>>
>>> On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
>>>
>>> [snip]
>>>
>>>> I was wondering if the level/edge settings for gpios is working on OMAP.
>>>>
>>>> I'm adding DT support for an SMSC911x ethernet chip connected to the
>>>> GPMC for an OMAP3 SoC based board.
>>>>
>>>> In the smsc911x driver probe function (smsc911x_drv_probe() in
>>>> drivers/net/ethernet/smsc/smsc911x.c), a call to request_irq() with
>>>> the flag IRQF_TRIGGER_LOW is needed because of the wiring on my board.
>>>>
>>>> Reading the gpio-omap.txt documentation it says that #interrupt-cells
>>>> should be <2> and that a value of 8 is "active low level-sensitive".
>>>>
>>>> So I tried this:
>>>>
>>>> &gpmc {
>>>> 	ethernet@5,0 {
>>>> 		pinctrl-names = "default";
>>>> 		pinctrl-0 = <&smsc911x_pins>;
>>>> 		compatible = "smsc,lan9221", "smsc,lan9115";
>>>> 		reg = <5 0 0xff>; /* CS5 */
>>>> 		interrupt-parent = <&gpio6>;
>>>> 		interrupts = <16 8>; /* gpio line 176 */
>>>> 		interrupt-names = "smsc911x irq";
>>>> 		vmmc-supply = <&vddvario>;
>>>> 		vmmc_aux-supply = <&vdd33a>;
>>>> 		reg-io-width = <4>;
>>>>
>>>> 		smsc,save-mac-address;
>>>>       };
>>>> };
>>>
>>> Are you requesting the gpio anywhere? If not then this is not going to
>>> work as-is. This was discussed fairly recently [1] and the conclusion
>>> was that the gpio needs to be requested before we can use as an interrupt.
>>
>> That seems wrong; the GPIO/IRQ driver should handle this internally. The
>> Ethernet driver shouldn't know/care whether the interrupt it's given is
>> some form of dedicated interrupt or a GPIO-based interrupt, and even if
>> it somehow did, there's no irq_to_gpio() any more, so the driver can't
>> tell which GPIO ID it should request, unless it's given yet another
>> property to represent this.
> 
> I agree that ideally this should be handled internally. Did you read the
> discussion on the thread that I referenced [1]? If you have any thoughts
> we are open to ideas :-)
> 
> Cheers
> Jon
> 
> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/92192

Oh, when I clicked that link the first time, all I saw was the patch,
not any discussion. I guess it must have timed out finding the other
emails or something.

I disagree that the GPIO needs to be requested, and that a custom DT
property and associated code are needed for that; simply requesting the
IRQ should be enough to make everything work.

In the Tegra GPIO IRQ driver for example, the irq_set_type irq_chip op
goes and configures the base GPIO HW to enable the pin as a GPIO, just
like gpio_request() would. I imagine the OMAP driver can do whatever
similar action it needs.
--
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