From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Antti Palosaari <crope@iki.fi>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 09/12] tda10071: use jiffies when poll firmware status
Date: Tue, 11 Aug 2015 12:50:42 -0300 [thread overview]
Message-ID: <20150811125042.594967d6@recife.lan> (raw)
In-Reply-To: <55CA124F.9080507@iki.fi>
Em Tue, 11 Aug 2015 18:18:39 +0300
Antti Palosaari <crope@iki.fi> escreveu:
> On 08/11/2015 01:20 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 9 Jul 2015 07:06:29 +0300
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> Use jiffies to set timeout for firmware command status polling.
> >> It is more elegant solution than poll X times with sleep.
>
> >> /* wait cmd execution terminate */
> >> - for (i = 1000, uitmp = 1; i && uitmp; i--) {
> >> + #define CMD_EXECUTE_TIMEOUT 30
> >> + timeout = jiffies + msecs_to_jiffies(CMD_EXECUTE_TIMEOUT);
> >> + for (uitmp = 1; !time_after(jiffies, timeout) && uitmp;) {
> >> ret = regmap_read(dev->regmap, 0x1f, &uitmp);
> >> if (ret)
> >> goto error;
> >> -
> >> - usleep_range(200, 5000);
> >
> > Hmm... removing the usleep() doesn't sound a good idea. You'll be
> > flooding the I2C bus with read commands and spending CPU cycles
> > for 30ms spending more power than the previous code. That doesn't
> > sound more "elegant solution than poll X times with sleep" for me.
> >
> > So, I would keep the usleep_range() here and add a better
> > comment on the patch description.
>
> First of all, polling firmware ready status is very common for chips
> having firmware. And there is 2 ways to implement it:
> 1) poll N times in a loop using X sleep, timeout = N * X
> 2) poll in a loop using jiffies as a timeout
>
> IMHO 2 is more elegant solution and I have started using it recently.
Yes, (2) is more elegant.
> What you now propose is add some throttle in order to slow down polling
> interval to reduce I2C I/O. Yes sure less I/O is better, but downside is
> that it makes some unneeded extra delay to code path. Usually these sort
> firmware ready polling ends rather quickly, in a loop or two.
If only few interactions is needed, then OK. Please add a comment then,
explaining that.
>
> Sure it eats some extra CPU cycles, but I think extra control messages
> are about nothing compared to I/O used for data streaming.
>
> Which kind of throttle delay you think is suitable for polling command
> status over I2C bus?
>
> regards
> Antti
>
next prev parent reply other threads:[~2015-08-11 15:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 4:06 [PATCH 01/12] em28xx: remove unused a8293 SEC config Antti Palosaari
2015-07-09 4:06 ` [PATCH 02/12] a8293: remove legacy media attach Antti Palosaari
2015-07-09 4:06 ` [PATCH 03/12] a8293: use i2c_master_send / i2c_master_recv for I2C I/O Antti Palosaari
2015-07-09 4:06 ` [PATCH 04/12] a8293: improve LNB register programming logic Antti Palosaari
2015-07-09 4:06 ` [PATCH 05/12] a8293: coding style issues Antti Palosaari
2015-07-09 4:06 ` [PATCH 06/12] tda10071: remove legacy media attach Antti Palosaari
2015-07-09 4:06 ` [PATCH 07/12] tda10071: rename device state struct to dev Antti Palosaari
2015-07-09 4:06 ` [PATCH 08/12] tda10071: convert to regmap I2C API Antti Palosaari
2015-07-09 4:06 ` [PATCH 09/12] tda10071: use jiffies when poll firmware status Antti Palosaari
2015-08-11 10:20 ` Mauro Carvalho Chehab
2015-08-11 15:18 ` Antti Palosaari
2015-08-11 15:50 ` Mauro Carvalho Chehab [this message]
2015-07-09 4:06 ` [PATCH 10/12] tda10071: protect firmware command exec with mutex Antti Palosaari
2015-07-09 4:06 ` [PATCH 11/12] tda10071: do not get_frontend() when not ready Antti Palosaari
2015-07-09 4:06 ` [PATCH 12/12] tda10071: implement DVBv5 statistics Antti Palosaari
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=20150811125042.594967d6@recife.lan \
--to=mchehab@osg.samsung.com \
--cc=crope@iki.fi \
--cc=linux-media@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 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.