All of lore.kernel.org
 help / color / mirror / Atom feed
From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MXS: Convert mutexes in clock.c to spinlocks
Date: Mon, 19 Dec 2011 12:57:05 +0100	[thread overview]
Message-ID: <201112191257.06145.marek.vasut@gmail.com> (raw)
In-Reply-To: <20111219082225.GC14542@n2100.arm.linux.org.uk>

> On Mon, Dec 19, 2011 at 05:03:45AM +0100, Marek Vasut wrote:
> > > On Sun, Dec 18, 2011 at 03:06:13PM +0100, Marek Vasut wrote:
> > > > The mutexes can't be safely used under certain circumstances. I
> > > > noticed this
> > > 
> > > > issue during some network instability at home:
> > > Yes, this is a known issue.  And there was some discussion[1] about
> > > why mutex is needed.
> > 
> > Thanks for pointing this out, I was unaware of it.
> > 
> > > But I really have not thought about why we can
> > > not use spinlock only, since using mutex only leads to the issue we
> > > are seeing here, and using spinlock in enable/disable and mutex in
> > > rate/parent will not work, because the mxs clocks have enable/disable
> > > and rate/parent functions access the same register.  I know it's not
> > > good to hold spinlock in rate/parent functions for a long time, but
> > > do we have a way around rather than using spinlock for both sets of
> > > functions?
> > 
> > Yea, spinlock is not good either. On the other hand, is it really held
> > for so long ?
> 
> There is another solution to this, which I've pointed out before when
> this has come up:
> 
> 1. Convert all your drivers to _also_ use clk_prepare()/clk_unprepare().
>    You need to do this anyway as it will become mandatory for the common
>    clk stuff.
> 
> 2. Rename your existing clk_enable()/clk_disable() implementation to
>    clk_prepare()/clk_unprepare().  Ensure CONFIG_HAVE_CLK_PREPARE is
>    selected.
> 
> 3. Provide a new no-op clk_enable()/clk_disable() functions.

Well, I'm still unsure how'd you then enable/disable the clock ? 
clk_prepare/clk_unprepare is good, but how would that help in avoiding the 
mutex/spinlock?

> 
> This fixes the issue because clk_prepare()/clk_unprepare() must only be
> called from process contexts, whereas clk_enable()/clk_disable() may be
> called from atomic contexts as well.

Sure, but I need to enable the clock in atomic context ...

M

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marek.vasut@gmail.com>
To: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@freescale.com>, Wolfgang Denk <wd@denx.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-kernel@vger.kernel.org, Huang Shijie <b32955@freescale.com>,
	linux-arm-kernel@lists.infradead.org,
	Shawn Guo <shawn.guo@linaro.org>, Stefano Babic <sbabic@denx.de>
Subject: Re: [PATCH] MXS: Convert mutexes in clock.c to spinlocks
Date: Mon, 19 Dec 2011 12:57:05 +0100	[thread overview]
Message-ID: <201112191257.06145.marek.vasut@gmail.com> (raw)
In-Reply-To: <20111219082225.GC14542@n2100.arm.linux.org.uk>

> On Mon, Dec 19, 2011 at 05:03:45AM +0100, Marek Vasut wrote:
> > > On Sun, Dec 18, 2011 at 03:06:13PM +0100, Marek Vasut wrote:
> > > > The mutexes can't be safely used under certain circumstances. I
> > > > noticed this
> > > 
> > > > issue during some network instability at home:
> > > Yes, this is a known issue.  And there was some discussion[1] about
> > > why mutex is needed.
> > 
> > Thanks for pointing this out, I was unaware of it.
> > 
> > > But I really have not thought about why we can
> > > not use spinlock only, since using mutex only leads to the issue we
> > > are seeing here, and using spinlock in enable/disable and mutex in
> > > rate/parent will not work, because the mxs clocks have enable/disable
> > > and rate/parent functions access the same register.  I know it's not
> > > good to hold spinlock in rate/parent functions for a long time, but
> > > do we have a way around rather than using spinlock for both sets of
> > > functions?
> > 
> > Yea, spinlock is not good either. On the other hand, is it really held
> > for so long ?
> 
> There is another solution to this, which I've pointed out before when
> this has come up:
> 
> 1. Convert all your drivers to _also_ use clk_prepare()/clk_unprepare().
>    You need to do this anyway as it will become mandatory for the common
>    clk stuff.
> 
> 2. Rename your existing clk_enable()/clk_disable() implementation to
>    clk_prepare()/clk_unprepare().  Ensure CONFIG_HAVE_CLK_PREPARE is
>    selected.
> 
> 3. Provide a new no-op clk_enable()/clk_disable() functions.

Well, I'm still unsure how'd you then enable/disable the clock ? 
clk_prepare/clk_unprepare is good, but how would that help in avoiding the 
mutex/spinlock?

> 
> This fixes the issue because clk_prepare()/clk_unprepare() must only be
> called from process contexts, whereas clk_enable()/clk_disable() may be
> called from atomic contexts as well.

Sure, but I need to enable the clock in atomic context ...

M

  reply	other threads:[~2011-12-19 11:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-18 14:06 [PATCH] MXS: Convert mutexes in clock.c to spinlocks Marek Vasut
2011-12-18 14:06 ` Marek Vasut
2011-12-19  3:27 ` Shawn Guo
2011-12-19  3:27   ` Shawn Guo
2011-12-19  4:03   ` Marek Vasut
2011-12-19  4:03     ` Marek Vasut
2011-12-19  8:22     ` Russell King - ARM Linux
2011-12-19  8:22       ` Russell King - ARM Linux
2011-12-19 11:57       ` Marek Vasut [this message]
2011-12-19 11:57         ` Marek Vasut
2011-12-19 12:15         ` Russell King - ARM Linux
2011-12-19 12:15           ` Russell King - ARM Linux
2011-12-19 20:54           ` Marek Vasut
2011-12-19 20:54             ` Marek Vasut
2011-12-19 21:03             ` Russell King - ARM Linux
2011-12-19 21:03               ` Russell King - ARM Linux
2011-12-19 21:05               ` Marek Vasut
2011-12-19 21:05                 ` Marek Vasut
2011-12-19 21:28                 ` Russell King - ARM Linux
2011-12-19 21:28                   ` Russell King - ARM Linux
2011-12-19 21:37                   ` Marek Vasut
2011-12-19 21:37                     ` Marek Vasut
2011-12-19 21:43                     ` Marek Vasut
2011-12-19 21:43                       ` Marek Vasut
2011-12-19 23:23             ` Shawn Guo
2011-12-19 23:23               ` Shawn Guo
2011-12-19 23:35               ` Marek Vasut
2011-12-19 23:35                 ` Marek Vasut
2011-12-20  0:19                 ` Shawn Guo
2011-12-20  0:19                   ` Shawn Guo
2011-12-20  3:09                   ` Marek Vasut
2011-12-20  3:09                     ` Marek Vasut

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=201112191257.06145.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.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.