Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING

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

 



On 02/07/14 11:49, Sekhar Nori wrote:
> On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
>> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
>> least a valid) choice. That's probably because the Atmel IRQ signal is
>> routed to our GPIO controller, which is also an IRQ controller, and then
>> "forwarded" up the chain to the GIC, with the polarity the GIC expects.
>>
>> If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add
>> some kind of DT property to configure the polarity of the IRQ output.
> 
> Yeah, I think so too.
> 
> Nick,
> 
> If you are going to rebase your branch, will you be able to fold in the
> patch in my previous e-mail? Else, I can send a more formal patch to you.

Either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW will work with these chips
(it isn't a question of polarity but whether it's edge- or level-
triggered). There isn't a sensible default. Atmel prefer IRQF_TRIGGER_LOW,
however I've seen some IRQ controllers will revert to a polled mode for
IRQF_TRIGGER_LOW, which kills performance.

So, the sensible course of action seems to be to remove the default
IRQF_TRIGGER_FALLING in the device tree parsing, and provide a device tree
parameter for the flags. If you agree, I will sort this out at my end, you
don't need to send a patch.

I have to leave it in in the case where there is neither static platform
data, or device tree node, because that is used for some systems, but that
shouldn't affect either of you.

BTW, I do have a set of patches ready to send, once this change is made.

cheers

Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux