mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Alexandru Gagniuc <alex.g@adaptrum.com>, linux-kernel@vger.kernel.org
Cc: "Andre Przywara" <andre.przywara@arm.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@st.com>,
	"Maxime Ripard" <maxime.ripard@free-electrons.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Baoyou Xie" <baoyou.xie@linaro.org>,
	"Eugeniy Paltsev" <Eugeniy.Paltsev@synopsys.com>,
	"Steffen Trumtrar" <s.trumtrar@pengutronix.de>,
	"Dinh Nguyen" <dinguyen@kernel.org>,
	"Andreas Färber" <afaerber@suse.de>,
	linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de
Subject: Re: [PATCH v3 5/5] reset: simple: read back to make sure changes are applied
Date: Mon, 21 Aug 2017 10:21:00 +0200	[thread overview]
Message-ID: <1503303660.8125.4.camel@pengutronix.de> (raw)
In-Reply-To: <561b4eb5-98be-f844-57cb-b5ce5962258f@adaptrum.com>

Hi Alexandru,

On Wed, 2017-08-16 at 14:00 -0700, Alexandru Gagniuc wrote:
> 
> On 08/16/2017 02:47 AM, Philipp Zabel wrote:
> > Read back the register after setting or clearing a reset bit to make
> > sure that the changes are applied to the reset controller hardware.
> > Theoretically, this avoids the write to stay stuck in a store buffer
> 
> Is there hardware where this has been observed to happen, or is this 
> purely theoretical? It would be nice to have a "this is needed on 
> hardware XYZ because ABC, and doesn't affect other hardware" comment in 
> the source.

This is purely theoretical, at least in the context of reset
controllers. I'm happy to drop this patch for now.

> > during the delay of an assert-delay-deassert sequence, and makes sure
> > that the reset really is asserted for the specified duration.
> > 
> > > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> >  drivers/reset/reset-simple.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
> > index 13e7d5559acc9..d98a7e7d802d1 100644
> > --- a/drivers/reset/reset-simple.c
> > +++ b/drivers/reset/reset-simple.c
> > @@ -39,17 +39,20 @@ static int reset_simple_set(struct reset_controller_dev *rcdev,
> > > >  	int reg_width = sizeof(u32);
> > > >  	int bank = id / (reg_width * BITS_PER_BYTE);
> > > >  	int offset = id % (reg_width * BITS_PER_BYTE);
> > > > +	void __iomem *addr = data->membase + (bank * reg_width);
> > > >  	unsigned long flags;
> > > >  	u32 reg;
> > 
> > > >  	spin_lock_irqsave(&data->lock, flags);
> > 
> > > > -	reg = readl(data->membase + (bank * reg_width));
> > > > +	reg = readl(addr);
> > > >  	if (assert ^ data->active_low)
> > > >  		reg |= BIT(offset);
> > > >  	else
> > > >  		reg &= ~BIT(offset);
> > > > -	writel(reg, data->membase + (bank * reg_width));
> > > > +	writel(reg, addr);
> > > > +	/* Read back to make sure the write doesn't linger in a store buffer */
> > > > +	readl(addr);
> 
> You're not using the returned value to check that the reset was actually 
> set. This seems a very arbitrary readback workaround, which gives no 
> indication if it actually succeeded or not.

True. For those reset controllers that support status readback, this
would be a better check.

> Also the set() is now asymmetrical to clear(). In cases when releasing 
> reset on a HW block that is about to have IO performed on it, one would 
> want to make sure the reset is actually deasserted before doing any IO.

Thanks for this observation, the reset_simple_set function name is
ambiguous. I'll rename it to reset_simple_update.
The function is called both for assert and deassert operations, and
whether the bit is set or cleared depends on both the assert parameter
and the active_low flag.

regards
Philipp

      reply	other threads:[~2017-08-21  8:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16  9:46 [PATCH v3 0/5] Unify simple reset drivers Philipp Zabel
2017-08-16  9:46 ` [PATCH v3 1/5] reset: add reset-simple to unify socfpga, stm32, sunxi, and zx2967 Philipp Zabel
2017-08-16 11:30   ` Andre Przywara
2017-08-16 12:12     ` Andreas Färber
2017-08-16 15:11       ` Philipp Zabel
2017-08-16 15:17         ` Andre Przywara
2017-08-16 16:41         ` Andreas Färber
2017-08-16 16:46           ` Andre Przywara
2017-08-16 20:46   ` Alexandru Gagniuc
2017-08-16  9:46 ` [PATCH v3 2/5] reset: socfpga: use the reset-simple driver Philipp Zabel
2017-08-16 20:46   ` Alexandru Gagniuc
2017-08-21  8:45     ` Philipp Zabel
2017-08-16  9:46 ` [PATCH v3 3/5] reset: stm32: " Philipp Zabel
2017-08-16 12:52   ` Eugeniy Paltsev
2017-08-16 12:55     ` Andreas Färber
2017-08-16 13:03     ` Andre Przywara
2017-08-16 20:50   ` Alexandru Gagniuc
2017-08-16 20:52     ` Andreas Färber
2017-08-16 20:55       ` Alexandru Gagniuc
2017-08-17  9:19         ` Andre Przywara
2017-08-21  8:38           ` Philipp Zabel
2017-08-29  8:39   ` [v3,3/5] " Gabriel FERNANDEZ
2017-08-16  9:47 ` [PATCH v3 4/5] reset: zx2967: " Philipp Zabel
2017-08-16 20:50   ` Alexandru Gagniuc
2017-08-16  9:47 ` [PATCH v3 5/5] reset: simple: read back to make sure changes are applied Philipp Zabel
2017-08-16 21:00   ` Alexandru Gagniuc
2017-08-21  8:21     ` Philipp Zabel [this message]

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=1503303660.8125.4.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=Eugeniy.Paltsev@synopsys.com \
    --cc=afaerber@suse.de \
    --cc=alex.g@adaptrum.com \
    --cc=alexandre.torgue@st.com \
    --cc=andre.przywara@arm.com \
    --cc=baoyou.xie@linaro.org \
    --cc=dinguyen@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=s.trumtrar@pengutronix.de \
    --cc=wens@csie.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

all inboxes | Powered by JetHome®