linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Shyti <andi@etezian.org>
To: "dbasehore ." <dbasehore@chromium.org>
Cc: andi@etezian.org, dmitry.torokhov@gmail.com,
	johnny.chuang@emc.com.tw,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org, joe@perches.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	james.chen@emc.com.tw, kt.liao@emc.com.tw
Subject: Re: [PATCH] Input: elants_i2c - Fix sw reset delays
Date: Mon, 27 Aug 2018 14:51:45 +0300	[thread overview]
Message-ID: <20180827115145.GA1567@jack.zhora.eu> (raw)
In-Reply-To: <CAGAzgsqhTbgB2vAYDLMUFvuJ7F4pqHxRp+Xo+iny8g9ghTYM6g@mail.gmail.com>

Hi Derek,

next time, could you please avoid using html mails when replying
to the mailing list? They are not clear.

On Fri, Aug 24, 2018 at 04:07:41PM -0700, dbasehore . wrote:
> 
> 
> On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti <andi@etezian.org> wrote:
> 
>     Hi Derek,
> 
>     > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
>     > > > > We only need to wait 10ms instead of 30ms before starting fastboot
>     or
>     > > > > sending IAP on the touchscreen. Also, instead of delaying everytime
>     > > > > sw_reset is called, this delays 10ms in the function that starts
>     > > > > fastboot. There's also an explicit 20ms delay before sending IAP
>     when
>     > > > > updating the firmware, so no additional delay is needed there. This
>     > > > > change also has the benefit of not delaying when wakeup is enabled
>     > > > > during suspend. This is because sw_reset is called, yet fastboot
>     > > > > isn't.
> 
>     ...
> 
>     > > > > -       /*
>     > > > > -        * We should wait at least 10 msec (but no more than 40)
>     before
>     > > > > -        * sending fastboot or IAP command to the device.
>     > > > > -        */
>     > > > > -       msleep(30);
>     > > > > -
> 
>     moving from 30 to 0 is a bit alarming... what does the datasheet
>     say?
> 
> 
> We're moving from 30msec to 10msec. We used to do this in an older kernel.

That's not what you are saying in your commit message:

  "... This change also has the benefit of not delaying when
  wakeup is enabled during suspend... "

and indeed, in resume the "elants_i2c_sw_reset()" function would
be called without any msleep. Or am I missing something? Would
it be correct based on the datasheet?

>  
> 
> 
>     Sometimes delays are implicit in the system where you are testing
>     the driver, so that without any msleep it might work in your
>     system but it might not on others.
> 
>     > +             /*
>     > +              * We should wait at least 10 msec (but no more than 40)
>     before
>     > +              * sending IAP command to the device.
>     > +              */
>     >               msleep(20);
> 
>     I agree though that it's not nice to wait twice here (even though
>     as Dmitry says it doesn't hurt so much). Wouldn't it make more
>     sense to remove this msleep instead?
>     This way...
> 
> 
> We still need this if the delay is removed from the sw_reset function. We have
> a total of 20msecs delayed between sw_reset and sending IAP in our old kernel
> which should be well tested. There seems to be no reason why the delays
> increased.

Yes, that's what I'm saying, removing this msleep to me looks
more correct than removing it from sw_reset().

>     > +     /*
>     > +      * We should wait at least 10 msec (but no more than 40) before
>     sending
>     > +      * fastboot command to the device.
>     > +      */
>     > +     usleep_range(10 * 1000, 11 * 1000);
>     > +
>     >       error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd));
> 
>     ... you do not need to add an extra sleep here.
> 
> 
> I added it here since I removed the 30msec sleep in sw_reset. This prevents us
> from sleeping on resume when the touch controller is already on for wake up
> capabilities. This is the same delay that we have in our old 3.8 kernel, so
> it's pretty well tested and shipped in production.

And here we fall in my first question (and also Dmitry's
concern), Are we sure we don't need to sleep after resume? Again,
what does the datasheet say?

I don't know the answer, you might be right, but I need to know
why you are removing the sleep after resume and why, instead,
the original developer added it there.

Two more nitpicks on this patch:

1. by adding the usleep_range() outside from the
elants_i2c_sw_reset() function, to another developer reading the
code, might not really look clear why we are waiting. The
comment you copy pasted does not, indeed, refer that we are
waiting because a reset has been performed and we need to wait
for the _reset time_ before sending IAP commands.

2. this is a matter of taste: to me "10000" looks more clear than
"10 * 1000", which doesn't add any better readability of the
number itself.

Thanks,
Andi

  parent reply	other threads:[~2018-08-27 11:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 23:10 [PATCH] Input: elants_i2c - Fix sw reset delays Derek Basehore
2018-08-23 23:30 ` Dmitry Torokhov
2018-08-23 23:32   ` Dmitry Torokhov
2018-08-23 23:34     ` Dmitry Torokhov
2018-08-24  8:49       ` Andi Shyti
     [not found]         ` <CAGAzgsqhTbgB2vAYDLMUFvuJ7F4pqHxRp+Xo+iny8g9ghTYM6g@mail.gmail.com>
2018-08-24 23:10           ` dbasehore .
2018-08-27 11:51           ` Andi Shyti [this message]
2018-08-27 13:23             ` dbasehore .

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=20180827115145.GA1567@jack.zhora.eu \
    --to=andi@etezian.org \
    --cc=dbasehore@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.chen@emc.com.tw \
    --cc=joe@perches.com \
    --cc=johnny.chuang@emc.com.tw \
    --cc=kt.liao@emc.com.tw \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.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).