lkml.org 
[lkml]   [2014]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] PINCTRL: Warn if direct IRQ GPIO set to output
On 14-05-29 06:44 AM, Linus Walleij wrote:
> On Tue, May 27, 2014 at 9:26 PM, <eric.ernst@linux.intel.com> wrote:
>
>> From: Eric Ernst <eric.ernst@linux.intel.com>
>>
>> For Baytrail, you should never set a GPIO set to direct_irq
>> to output mode. When direct_irq_en is set for a GPIO, it is
>> tied directly to an APIC internally, and making the pad output
>> does not make any sense. Assert a WARN() in the event this happens.
>>
>> Signed-off-by: Eric Ernst <eric.ernst@linux.intel.com>
> Can I get some ACK from the author's of this driver on Eric's patch?
>
> Eric, you *are* aware of what the gpio_lock_as_irq() and
> gpio_unlock_as_irq() in the .irq_request_resources are doing
> right? Is this patch just some extra safety measure?
>
> Yours,
> Linus Walleij
Linus, thanks for the feedback.

I do see the usage for gpio_lock_as_irq() and gpio_unlock_as_irq(),
though I'm not sure if this would help me in this scenario. I am adding
an extra safety measure, as an attempt to check exactly how the GPIO pin
was configured, possibly before kernel, before changing the direction to
output.

In my situation, a device attached via GPIO will act as an IRQ, but also
toggled as output during setup in order to communicate with the device
(ugly device, i know). Specifically for this pincntrl device on
Baytrail, we need to make sure that if the pin were ever to be used for
IO, that direct IRQ is not set in its config register (ie - don't handle
the IRQ via the APIC). This check and WARN is to look for that
situation, and provide a caution to the user that what they're asking
for isn't necessarily what they will be getting.
Thanks,
Eric


\
 
 \ /
  Last update: 2014-05-30 00:41    [W:0.089 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site