All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-input@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	devicetree <devicetree@vger.kernel.org>,
	linux-sunxi@googlegroups.com
Subject: Re: [PATCH v3] input: Add support for ChipOne icn8318 based touchscreens
Date: Sun, 22 Mar 2015 15:42:14 -0700	[thread overview]
Message-ID: <20150322224214.GA9792@dtor-ws> (raw)
In-Reply-To: <550EA0E7.30608@redhat.com>

On Sun, Mar 22, 2015 at 12:00:55PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 22-03-15 05:03, Dmitry Torokhov wrote:
> >Hi Hans,
> >
> >On Tue, Mar 10, 2015 at 06:05:33PM +0100, Hans de Goede wrote:
> >>+	error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq,
> >>+					  IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> >
> >Shouldn't we let DT data tell us what trigger to use? I.e. just leave
> >IRQF_ONESHOT here?
> 
> That is an interesting question, that new data is available is signalled by
> the irq pin of the chip going low is a property of the chip, not the board
> layout, so I believe it is best to leave this as is.

My concern is that even if pin behavior is property of chip maybe on
some boards we want to use level-triggered interrupts instead of edge?
And if we indeed want to hard-code the trigger then shouldn't the
binding document use onecell mapping (so that users do not attempt to
configure triggers from DT)?

> 
> Also note that if we want to get this from devicetree, that simply leaving out the
> flag is not enough, we must specifically get the data from devicetree and pass
> it into request_irq AFAICT. So the above would change to:
> 
> 	irqflags = irqd_get_trigger_type(irq_get_irq_data(client->irq)) | IRQF_ONESHOT,
> 	error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, irqflags,

No, of_irq_get() that i2c core calls before probing driver should
already set the trigger type for us. There is no need for the individual
drivers to do that.

Thanks.

-- 
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: dmitry.torokhov@gmail.com (Dmitry Torokhov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] input: Add support for ChipOne icn8318 based touchscreens
Date: Sun, 22 Mar 2015 15:42:14 -0700	[thread overview]
Message-ID: <20150322224214.GA9792@dtor-ws> (raw)
In-Reply-To: <550EA0E7.30608@redhat.com>

On Sun, Mar 22, 2015 at 12:00:55PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 22-03-15 05:03, Dmitry Torokhov wrote:
> >Hi Hans,
> >
> >On Tue, Mar 10, 2015 at 06:05:33PM +0100, Hans de Goede wrote:
> >>+	error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq,
> >>+					  IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> >
> >Shouldn't we let DT data tell us what trigger to use? I.e. just leave
> >IRQF_ONESHOT here?
> 
> That is an interesting question, that new data is available is signalled by
> the irq pin of the chip going low is a property of the chip, not the board
> layout, so I believe it is best to leave this as is.

My concern is that even if pin behavior is property of chip maybe on
some boards we want to use level-triggered interrupts instead of edge?
And if we indeed want to hard-code the trigger then shouldn't the
binding document use onecell mapping (so that users do not attempt to
configure triggers from DT)?

> 
> Also note that if we want to get this from devicetree, that simply leaving out the
> flag is not enough, we must specifically get the data from devicetree and pass
> it into request_irq AFAICT. So the above would change to:
> 
> 	irqflags = irqd_get_trigger_type(irq_get_irq_data(client->irq)) | IRQF_ONESHOT,
> 	error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, irqflags,

No, of_irq_get() that i2c core calls before probing driver should
already set the trigger type for us. There is no need for the individual
drivers to do that.

Thanks.

-- 
Dmitry

  reply	other threads:[~2015-03-22 22:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 17:05 [PATCH v3] input: Add support for ChipOne icn8318 based touchscreens Hans de Goede
2015-03-10 17:05 ` Hans de Goede
     [not found] ` <1426007133-9606-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-22  4:03   ` Dmitry Torokhov
2015-03-22  4:03     ` Dmitry Torokhov
2015-03-22 11:00     ` Hans de Goede
2015-03-22 11:00       ` Hans de Goede
2015-03-22 22:42       ` Dmitry Torokhov [this message]
2015-03-22 22:42         ` Dmitry Torokhov
2015-03-24 17:45         ` Hans de Goede
2015-03-24 17:45           ` Hans de Goede
     [not found]           ` <5511A29F.1010404-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-24 18:33             ` Dmitry Torokhov
2015-03-24 18:33               ` Dmitry Torokhov

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=20150322224214.GA9792@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.