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 05:03:45 +0100	[thread overview]
Message-ID: <201112190503.46668.marek.vasut@gmail.com> (raw)
In-Reply-To: <20111219032712.GB4962@S2100-06.ap.freescale.net>

> 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 ?

M

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marek.vasut@gmail.com>
To: Shawn Guo <shawn.guo@freescale.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, Wolfgang Denk <wd@denx.de>,
	Stefano Babic <sbabic@denx.de>, Shawn Guo <shawn.guo@linaro.org>,
	Huang Shijie <b32955@freescale.com>,
	Sascha Hauer <s.hauer@pengutronix.de>
Subject: Re: [PATCH] MXS: Convert mutexes in clock.c to spinlocks
Date: Mon, 19 Dec 2011 05:03:45 +0100	[thread overview]
Message-ID: <201112190503.46668.marek.vasut@gmail.com> (raw)
In-Reply-To: <20111219032712.GB4962@S2100-06.ap.freescale.net>

> 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 ?

M

  reply	other threads:[~2011-12-19  4:03 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 [this message]
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
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=201112190503.46668.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.