All of lore.kernel.org
 help / color / mirror / Atom feed
From: p.zabel@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [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

WARNING: multiple messages have this Message-ID (diff)
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: 54+ 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 ` 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  9:46   ` Philipp Zabel
2017-08-16 11:30   ` Andre Przywara
2017-08-16 11:30     ` Andre Przywara
2017-08-16 12:12     ` Andreas Färber
2017-08-16 12:12       ` Andreas Färber
2017-08-16 15:11       ` Philipp Zabel
2017-08-16 15:11         ` Philipp Zabel
2017-08-16 15:17         ` Andre Przywara
2017-08-16 15:17           ` Andre Przywara
2017-08-16 16:41         ` Andreas Färber
2017-08-16 16:41           ` Andreas Färber
2017-08-16 16:46           ` Andre Przywara
2017-08-16 16:46             ` Andre Przywara
2017-08-16 20:46   ` Alexandru Gagniuc
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  9:46   ` Philipp Zabel
2017-08-16 20:46   ` Alexandru Gagniuc
2017-08-16 20:46     ` Alexandru Gagniuc
2017-08-21  8:45     ` Philipp Zabel
2017-08-21  8:45       ` Philipp Zabel
2017-08-16  9:46 ` [PATCH v3 3/5] reset: stm32: " Philipp Zabel
2017-08-16  9:46   ` Philipp Zabel
2017-08-16 12:52   ` Eugeniy Paltsev
2017-08-16 12:52     ` Eugeniy Paltsev
2017-08-16 12:55     ` Andreas Färber
2017-08-16 12:55       ` Andreas Färber
2017-08-16 13:03     ` Andre Przywara
2017-08-16 13:03       ` Andre Przywara
2017-08-16 20:50   ` Alexandru Gagniuc
2017-08-16 20:50     ` Alexandru Gagniuc
2017-08-16 20:52     ` Andreas Färber
2017-08-16 20:52       ` Andreas Färber
2017-08-16 20:55       ` Alexandru Gagniuc
2017-08-16 20:55         ` Alexandru Gagniuc
2017-08-17  9:19         ` Andre Przywara
2017-08-17  9:19           ` Andre Przywara
2017-08-21  8:38           ` Philipp Zabel
2017-08-21  8:38             ` Philipp Zabel
2017-08-29  8:39   ` [v3,3/5] " Gabriel FERNANDEZ
2017-08-29  8:39     ` Gabriel FERNANDEZ
2017-08-16  9:47 ` [PATCH v3 4/5] reset: zx2967: " Philipp Zabel
2017-08-16  9:47   ` Philipp Zabel
2017-08-16 20:50   ` Alexandru Gagniuc
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  9:47   ` Philipp Zabel
2017-08-16 21:00   ` Alexandru Gagniuc
2017-08-16 21:00     ` Alexandru Gagniuc
2017-08-21  8:21     ` Philipp Zabel [this message]
2017-08-21  8:21       ` Philipp Zabel

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=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.