linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
	Nick Dyer <nick.dyer@itdev.co.uk>,
	Stephen Warren <swarren@nvidia.com>,
	Yufeng Shen <miletus@chromium.org>,
	Benson Leung <bleung@chromium.org>,
	Doug Anderson <dianders@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	linux-input@vger.kernel.org, devicetree@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
Date: Fri, 08 Aug 2014 15:24:29 +0200	[thread overview]
Message-ID: <53E4CF8D.7080302@collabora.co.uk> (raw)
In-Reply-To: <20140807164725.GA22421@core.coreip.homeip.net>

Hello,

On 08/07/2014 06:47 PM, Dmitry Torokhov wrote:
> 
> Actually, I take this back. In mainline everything as it should: if
> pdata does not specify particular trigger the flags requested end up
> being IRQF_ONESHOT, which should preserve trigger bits previously set up
> by the board or OF code. In Chrome kernel we have:
> 

In theory it should work as Dmitry and Nick said since if no trigger flags are
set then whatever was set before (by OF, platform code, ACPI) should be used.

I also verified what Tomasz mentioned that the IRQ trigger type is parsed and
set correctly by OF:

irq_of_parse_and_map()
	 irq_create_of_mapping()
		irq_set_irq_type()
			__irq_set_trigger()
				chip->irq_set_type()
					exynos_irq_set_type()

But for some reason it doesn't work for me unless I set the trigger type in the
flags passed to request_threaded_irq().

I found that what makes it to work is the logic in __setup_irq() [0] that Nick
pointed out on a previous email:

		/* Setup the type (level, edge polarity) if configured: */
		if (new->flags & IRQF_TRIGGER_MASK) {
			ret = __irq_set_trigger(desc, irq,
					new->flags & IRQF_TRIGGER_MASK);

			if (ret)
				goto out_mask;
		}

So __irq_set_trigger() is only executed if the struct irqaction flags has a
trigger flag which makes sense since this shouldn't be necessary with DT due
__irq_set_trigger() being called from irq_create_of_mapping() before when the
"interrupts" property is parsed.

But for some reason it is necessary for me... I checked that struct irq_data
state_use_accessors value is correct and even tried setting that value to
new->flags after the mentioned code block but it makes no difference. Input
events are not reported by evtest and AFAICT interrupts are not being generated.

It works though if the trigger type is passed to request_threaded_irq() like
$subject does or if new->flags are set before the new->flags & IRQF_TRIGGER_MASK
conditional.

For example, with the following changes interrupts are fired correctly:

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 3dc6a61..2d8adbb 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1169,6 +1169,9 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
struct irqaction *new)

                init_waitqueue_head(&desc->wait_for_threads);

+               if (!(new->flags & IRQF_TRIGGER_MASK))
+                       new->flags |= irqd_get_trigger_type(desc);
+
                /* Setup the type (level, edge polarity) if configured: */
                if (new->flags & IRQF_TRIGGER_MASK) {
                        ret = __irq_set_trigger(desc, irq,

Any ideas what could be wrong here?
				
> 	/* Default to falling edge if no platform data provided */
> 	irqflags = data->pdata ? data->pdata->irqflags : IRQF_TRIGGER_FALLING;
> 	error = request_threaded_irq(client->irq, NULL, mxt_interrupt,
> 				     irqflags | IRQF_ONESHOT,
> 				     client->name, data);
>

Exactly, that's how I found the issue. When I compared both drivers I noticed
that the Chrome OS driver did that and since all the supported platforms are DT
based, the above is equivalent to just IRQF_TRIGGER_FALLING | IRQF_ONESHOT.

So according to my explanation, new->flags & IRQF_TRIGGER_MASK is true so
__irq_set_trigger() is executed and that's why it works with the Chrome OS driver.

In fact the Chrome OS DTS does not set a trigger type in the "interrupts" property:

trackpad@4b {
	reg=<0x4b>;
	compatible="atmel,atmel_mxt_tp";
	interrupts=<1 0>;
	interrupt-parent=<&gpx1>;
	wakeup-source;
};


> which I believe should go away. If it is needed on ACPI systems we need
> to figure out how to do things we can do with OF there.
> 

The above code should not be related to ACPI systems since whatever code that
parses an ACPI table should just call irq_set_irq_type() like is made by OF, so
request_threaded_irq() should just work with ACPI too.

I agree it should go away but first I want to understand why is needed in the
first place. Unfortunately commit:

031f136 ("Input: atmel_mxt_ts - Set default irqflags when there is no pdata")

from the Chrome OS 3.8 does not explain why this is needed, instead of adding
this information in the DTS (e.g: interrupts=<1 IRQ_TYPE_EDGE_FALLING>).

> Thanks.
>

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1172

  reply	other threads:[~2014-08-08 13:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-07  0:48 [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting Javier Martinez Canillas
2014-08-07  0:48 ` [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example Javier Martinez Canillas
2014-08-07 12:38   ` Nick Dyer
2014-08-08 14:52     ` Javier Martinez Canillas
2014-08-15 12:01       ` Javier Martinez Canillas
2014-08-15 16:08         ` Nick Dyer
2014-08-15 16:13           ` Stephen Warren
2014-09-11 14:52             ` [PATCH] Input: atmel_mxt_ts - fix merge in DT documentation Nick Dyer
2014-09-11 17:32               ` Dmitry Torokhov
2014-08-18 13:20           ` [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example Javier Martinez Canillas
2014-08-07  1:14 ` [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting Tomasz Figa
2014-08-07  1:47   ` Javier Martinez Canillas
2014-08-07  6:09     ` Dmitry Torokhov
2014-08-07  7:49       ` Javier Martinez Canillas
2014-08-07 16:47         ` Dmitry Torokhov
2014-08-08 13:24           ` Javier Martinez Canillas [this message]
2014-08-08 16:25             ` Tomasz Figa
2014-08-07 12:20 ` Nick Dyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53E4CF8D.7080302@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=bleung@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=miletus@chromium.org \
    --cc=nick.dyer@itdev.co.uk \
    --cc=olof@lixom.net \
    --cc=swarren@nvidia.com \
    --cc=tomasz.figa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).