From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andi Shyti <andi.shyti@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Andi Shyti <andi@etezian.org>,
javier@dowhile0.org
Subject: Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen
Date: Thu, 27 Apr 2017 16:56:45 -0700 [thread overview]
Message-ID: <20170427235645.GB33675@dtor-ws> (raw)
In-Reply-To: <20170427234156.glh2lchwr57fllmo@gangnam.samsung>
On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote:
> Hi Dmitry,
>
> On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote:
> >
> > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev)
> > > +{
> > > + struct stmfts_data *sdata = dev;
> > > + int ret;
> > > +
> > > + mutex_lock(&sdata->mutex);
> > > + ret = i2c_smbus_read_i2c_block_data(sdata->client,
> > > + STMFTS_READ_ONE_EVENT,
> > > + STMFTS_EVENT_SIZE, sdata->data);
> > > +
> > > + if (ret < 0 || ret != STMFTS_EVENT_SIZE)
> > > + goto exit;
> >
> > Why do we split read into 2 chunks? Can we issue STMFTS_READ_ALL_EVENT
> > right away instead of reading first event, analyzing it, and then (maybe)
> > fetching the rest?
>
> The reason is that I don't need to read all the events at once
> anytime, for example debug events or confirmation events normally
> occur with a single event in the fifo. In this case I would read
> only 32bytes instead of 256bytes.
>
> Unfortunately there are no other ways to know how many events are
> in the queue beforehand.
>
> There are some "magic" commands to figure that out, but this is
> specific to the Samsung's version of the stmfts and I don't want
> to push it to everyone else.
>
> The difference between this version of the driver and the
> previous one is that in this one if I stress-use of the
> touchscreen, the throughput is optimised (e.g. if I use more
> fingers).
> Before I was reading single events at time, establishing for each
> read an i2c "handshake", this was de-synchronizing the protocol.
>
> > Also, why do we use smbus protocol for the first event and i2c for the
> > rest?
>
> Standing to the datasheet, the device is smbus compatible and it
> should use smbus all the time. The problem is that here the
> protocol is broken in case I want to read out the full FIFO,
> which has a total of 256bytes and I have to force the read by
> using the function "stmfts_read_i2c_block_data()".
>
> Personally I don't like these kind of i2c reads, because they
> duplicate code, the SMBUS does that already, this is why in the
> previous version I was reading the events one by one.
>
> Do you think it is better to make a single read of all the fifo?
It depends on what the common case is. It looks like for touch data you
always do 2 i2c transactions per interrupt. I wonder if doing it once
and paying the price of overhead for debug a nd confirmation events is
not worth it.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2017-04-27 23:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170327130756epcas1p3e4d73c234d6f5b613b0b7cb37b54b972@epcas1p3.samsung.com>
2017-03-27 13:07 ` [PATCH v3 0/2] STM FingerTip S touchscreen support for TM2 board Andi Shyti
[not found] ` <CGME20170327130756epcas1p3134e88ccee37242db029357ae3d52603@epcas1p3.samsung.com>
2017-03-27 13:07 ` [PATCH v3 1/2] Input: add STMicroelectronics FingerTip touchscreen driver Andi Shyti
[not found] ` <20170327130743.27783-2-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-03-27 13:11 ` Andi Shyti
[not found] ` <CGME20170327130756epcas1p321726d525c31814c3f76895b895739cd@epcas1p3.samsung.com>
[not found] ` <20170327130743.27783-1-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-03-27 13:07 ` [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen Andi Shyti
2017-04-07 9:31 ` Andi Shyti
[not found] ` <20170407093129.rgubrthbaclar4yr-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
2017-04-17 10:39 ` Andi Shyti
[not found] ` <20170327130743.27783-3-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-04-25 2:31 ` Andi Shyti
2017-04-27 0:39 ` Dmitry Torokhov
2017-04-27 23:41 ` Andi Shyti
2017-04-27 23:56 ` Dmitry Torokhov [this message]
2017-04-28 0:07 ` Andi Shyti
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=20170427235645.GB33675@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=a.hajda@samsung.com \
--cc=andi.shyti@samsung.com \
--cc=andi@etezian.org \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=javier@dowhile0.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
/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).