All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Ford <aford173@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
	Marek Vasut <marex@denx.de>,
	linux-input@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Input: ili210x - add ILI2117 support
Date: Mon, 4 Nov 2019 17:40:28 -0600	[thread overview]
Message-ID: <CAHCN7x+=_FM32JTEKAb=5pPJNvim88cUFuEXgdGhMG9gdr0Emg@mail.gmail.com> (raw)
In-Reply-To: <20191104233621.GP57214@dtor-ws>

On Mon, Nov 4, 2019 at 5:36 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Mon, Nov 04, 2019 at 05:25:23PM -0600, Adam Ford wrote:
> > On Mon, Nov 4, 2019 at 3:43 PM Sven Van Asbroeck <thesven73@gmail.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > On Mon, Nov 4, 2019 at 4:28 PM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > I am using IRQ_TYPE_EDGE_RISING for the 2117A.  Is that correct?  For
> > > > my touchscreen, the IRQ line is low until a touch is detected, so I
> > > > assume we want to capure on the rising edge.
> > >
> > > That is correct for the 2117A, as far as I know. I am using the same
> > > setting.
> > >
> > > >
> > > > Regarding Dmitry's patch,
> > > > Is it a good idea to use msleep in an IRQ?  It seems like using the
> > > > schedule_delayed_work() call seems like it will get in and get out of
> > > > the ISR faster.
> > > >
> > > > If we use msleep and scan again, isn't it possible to starve other processes?
> > >
> > > I believe using msleep() is ok because this is not a "real" interrupt handler,
> > > but a threaded one. It runs in a regular kernel thread, with its interrupt
> > > turned off (but all other interrupts remain enabled). Its interrupt is
> > > re-enabled automatically after the threaded handler returns.
> > >
> > > See
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/interrupt.h#L50
> > >
> > > > > @@ -268,7 +278,7 @@ static irqreturn_t ili210x_irq(int irq, void *irq_data)
> > > > >                 }
> > > > >
> > > > >                 touch = ili210x_report_events(priv, touchdata);
> > > > > -               keep_polling = touch || chip->continue_polling(touchdata);
> > > > > +               keep_polling = chip->continue_polling(touchdata, touch);
> > > > >                 if (keep_polling)
> > > >
> > > > Why not just check the value of touch instead of invoking the function
> > > > pointer which takes the value of touch in as a parameter?
> > > >
> > >
> > > The value of touch must be checked inside the callback, because
> > > some variants use it to decide if they should poll again, and
> > > some do not, such as the ili211x.
> >
> > That makes sense.
> > >
> > > If I have misinterpreted your suggestion, could you perhaps
> > > express it in C, so I can understand better?
> >
> > You explained it.
> > I'm good.
>
> OK, I refreshed the branch with fixes and a couple of new patches. It is
> on top of 5.3 now. If this works for you guys I will be merging it for
> 5.5.

I will test it tomorrow on a 2117a and reply with results.  I am very
excited to see this integrated.

adam
>
> Thanks.
>
> --
> Dmitry

  reply	other threads:[~2019-11-04 23:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-02 14:17 [PATCH 1/2] Input: ili210x - Add DT binding for the Ilitek ILI2117 touch controller Marek Vasut
2019-03-27 19:44 ` Rob Herring
2019-08-07 11:27   ` Marek Vasut
2019-11-01 20:48 ` [PATCH 2/2] Input: ili210x - add ILI2117 support Sven Van Asbroeck
2019-11-03 23:55   ` Adam Ford
2019-11-04  0:16     ` Marek Vasut
2019-11-04  7:02       ` Dmitry Torokhov
2019-11-04  7:01   ` Dmitry Torokhov
2019-11-04  9:13     ` Marek Vasut
2019-11-04 13:49     ` Sven Van Asbroeck
2019-11-04 14:19       ` Adam Ford
2019-11-04 18:36         ` Dmitry Torokhov
2019-11-04 18:37     ` Sven Van Asbroeck
2019-11-04 21:28       ` Adam Ford
2019-11-04 21:43         ` Sven Van Asbroeck
2019-11-04 23:25           ` Adam Ford
2019-11-04 23:36             ` Dmitry Torokhov
2019-11-04 23:40               ` Adam Ford [this message]
2019-11-05  2:04                 ` Sven Van Asbroeck
2019-11-05 13:27                   ` Adam Ford
2019-11-05 15:26               ` Sven Van Asbroeck
2019-11-05 15:29               ` Sven Van Asbroeck
2019-11-05 15:53                 ` Sven Van Asbroeck
2019-11-11 18:16                 ` Dmitry Torokhov
2019-11-11 18:43                   ` Rob Herring
2019-11-12  0:19                     ` 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='CAHCN7x+=_FM32JTEKAb=5pPJNvim88cUFuEXgdGhMG9gdr0Emg@mail.gmail.com' \
    --to=aford173@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=thesven73@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 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.