On 02/07/14 18:25, Dmitry Torokhov wrote:
> In this case board code should take care of setting up the interrupt
> properly and the driver should simply use 0 as flags in request_irq().
> By the way, doesn't generic DT infrastructure already allow specifying
> interrupt triggers and sets them up pr
On Wednesday 02 July 2014 05:24 PM, Nick Dyer wrote:
> 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
On Wed, Jul 2, 2014 at 4:54 AM, Nick Dyer wrote:
> 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
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
On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
> Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
>> Nick,
>>
>> I have been using your for-next branch to base my development of
>> touchscreen support on TI's DRA7x EVM. With the recent updates,
>> it has worked out great and once I got
Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
> Nick,
>
> I have been using your for-next branch to base my development of
> touchscreen support on TI's DRA7x EVM. With the recent updates,
> it has worked out great and once I got the configuration right,
> it was just a question of adding D
