From: shawn.guo@freescale.com (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 08/10] ARM: mxs: add ocotp read function
Date: Thu, 6 Jan 2011 09:45:19 +0800 [thread overview]
Message-ID: <20110106014518.GA17891@freescale.com> (raw)
In-Reply-To: <20110105175617.GD12222@shareable.org>
On Wed, Jan 05, 2011 at 05:56:17PM +0000, Jamie Lokier wrote:
> Jamie Iles wrote:
> > On Wed, Jan 05, 2011 at 05:44:09PM +0100, Uwe Kleine-K?nig wrote:
> > > Hello Jamie,
> > > On Wed, Jan 05, 2011 at 04:16:46PM +0000, Jamie Iles wrote:
> > > > On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> > > > > + /* check both BUSY and ERROR cleared */
> > > > > + while ((__raw_readl(ocotp_base) &
> > > > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > > > + /* nothing */;
> > > >
> > > > Is it worth using cpu_relax() in these polling loops?
> > > I don't know what cpu_relax does for other platforms, but on ARM it's
> > > just a memory barrier which AFAICT doesn't help here at all (which
> > > doesn't need to be correct). Why do you think it would be better?
> >
> > Well I don't see that there's anything broken without cpu_relax() but
> > using cpu_relax() seems to be the most common way of doing busy polling
> > loops that I've seen. It's also a bit easier to read than a comment and
> > semi-colon. Perhaps it's just personal preference.
>
> cpu_relax() is a hint to the CPU to, for example, save power or be
> less aggressive on the memory bus (to save power or be fairer).
>
> Currently these architectures do more than just a barrier in cpu_relax():
> x86, IA64, PowerPC, Tile and S390.
>
> Although it's just a hint on ARM at the moment, it might change in
> future - especially with power mattering on so many ARM systems.
> (Even now, just changing it to a very short udelay might save power
> on existing ARMs without breaking drivers.)
>
Sounds reasonable. I would take the suggestion. Thanks, both Jamie.
--
Regards,
Shawn
WARNING: multiple messages have this Message-ID (diff)
From: Shawn Guo <shawn.guo@freescale.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: "Jamie Iles" <jamie@jamieiles.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
gerg@snapgear.com, B32542@freescale.com, netdev@vger.kernel.org,
s.hauer@pengutronix.de, baruch@tkos.co.il, w.sang@pengutronix.de,
r64343@freescale.com, linux-arm-kernel@lists.infradead.org,
eric@eukrea.com, bryan.wu@canonical.com, davem@davemloft.net,
lw@karo-electronics.de
Subject: Re: [PATCH v3 08/10] ARM: mxs: add ocotp read function
Date: Thu, 6 Jan 2011 09:45:19 +0800 [thread overview]
Message-ID: <20110106014518.GA17891@freescale.com> (raw)
In-Reply-To: <20110105175617.GD12222@shareable.org>
On Wed, Jan 05, 2011 at 05:56:17PM +0000, Jamie Lokier wrote:
> Jamie Iles wrote:
> > On Wed, Jan 05, 2011 at 05:44:09PM +0100, Uwe Kleine-König wrote:
> > > Hello Jamie,
> > > On Wed, Jan 05, 2011 at 04:16:46PM +0000, Jamie Iles wrote:
> > > > On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> > > > > + /* check both BUSY and ERROR cleared */
> > > > > + while ((__raw_readl(ocotp_base) &
> > > > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > > > + /* nothing */;
> > > >
> > > > Is it worth using cpu_relax() in these polling loops?
> > > I don't know what cpu_relax does for other platforms, but on ARM it's
> > > just a memory barrier which AFAICT doesn't help here at all (which
> > > doesn't need to be correct). Why do you think it would be better?
> >
> > Well I don't see that there's anything broken without cpu_relax() but
> > using cpu_relax() seems to be the most common way of doing busy polling
> > loops that I've seen. It's also a bit easier to read than a comment and
> > semi-colon. Perhaps it's just personal preference.
>
> cpu_relax() is a hint to the CPU to, for example, save power or be
> less aggressive on the memory bus (to save power or be fairer).
>
> Currently these architectures do more than just a barrier in cpu_relax():
> x86, IA64, PowerPC, Tile and S390.
>
> Although it's just a hint on ARM at the moment, it might change in
> future - especially with power mattering on so many ARM systems.
> (Even now, just changing it to a very short udelay might save power
> on existing ARMs without breaking drivers.)
>
Sounds reasonable. I would take the suggestion. Thanks, both Jamie.
--
Regards,
Shawn
next prev parent reply other threads:[~2011-01-06 1:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 14:07 [PATCH v3 00/10] net/fec: add dual fec support for i.MX28 Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 01/10] net/fec: fix MMFR_OP type in fec_enet_mdio_write Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 02/10] net/fec: remove the use of "index" which is legacy Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 04/10] net/fec: improve pm for better suspend/resume Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 05/10] net/fec: add dual fec support for mx28 Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 16:34 ` Uwe Kleine-König
2011-01-05 16:34 ` Uwe Kleine-König
2011-01-06 4:14 ` Shawn Guo
2011-01-06 4:14 ` Shawn Guo
2011-01-06 7:10 ` Uwe Kleine-König
2011-01-06 7:10 ` Uwe Kleine-König
2011-01-07 7:00 ` Shawn Guo
2011-01-07 7:00 ` Shawn Guo
2011-01-07 9:44 ` Uwe Kleine-König
2011-01-07 9:44 ` Uwe Kleine-König
2011-01-05 14:07 ` [PATCH v3 06/10] ARM: mx28: update clock and device name for dual fec support Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 07/10] ARM: mx28: add the second fec device registration Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 08/10] ARM: mxs: add ocotp read function Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 16:16 ` Jamie Iles
2011-01-05 16:16 ` Jamie Iles
2011-01-05 16:44 ` Uwe Kleine-König
2011-01-05 16:44 ` Uwe Kleine-König
2011-01-05 17:25 ` Jamie Iles
2011-01-05 17:25 ` Jamie Iles
2011-01-05 17:56 ` Jamie Lokier
2011-01-05 17:56 ` Jamie Lokier
2011-01-05 18:35 ` Russell King - ARM Linux
2011-01-05 18:35 ` Russell King - ARM Linux
2011-01-05 19:44 ` Jamie Lokier
2011-01-05 19:44 ` Jamie Lokier
2011-01-05 20:15 ` Russell King - ARM Linux
2011-01-05 20:15 ` Russell King - ARM Linux
2011-01-06 0:50 ` Jamie Lokier
2011-01-06 0:50 ` Jamie Lokier
2011-01-06 9:13 ` Russell King - ARM Linux
2011-01-06 9:13 ` Russell King - ARM Linux
2011-01-06 1:45 ` Shawn Guo [this message]
2011-01-06 1:45 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 09/10] ARM: mx28: read fec mac address from ocotp Shawn Guo
2011-01-05 14:07 ` Shawn Guo
2011-01-05 14:07 ` [PATCH v3 10/10] ARM: mxs: add initial pm support Shawn Guo
2011-01-05 14:07 ` Shawn Guo
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=20110106014518.GA17891@freescale.com \
--to=shawn.guo@freescale.com \
--cc=linux-arm-kernel@lists.infradead.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.