From: Simon Horman <horms@verge.net.au>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH][RFC] drivers: sh: late disabling of clocks
Date: Tue, 21 Jun 2011 03:02:14 +0000 [thread overview]
Message-ID: <20110621030208.GK16230@verge.net.au> (raw)
In-Reply-To: <20110609091339.14510.31590.sendpatchset@t400s>
On Tue, Jun 21, 2011 at 11:29:31AM +0900, Magnus Damm wrote:
> On Tue, Jun 21, 2011 at 11:14 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Jun 16, 2011 at 07:54:38AM +0900, Simon Horman wrote:
> >> On Wed, Jun 15, 2011 at 11:21:40PM +0900, Magnus Damm wrote:
> >> > On Tue, Jun 14, 2011 at 3:41 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > > On Mon, Jun 13, 2011 at 05:59:08PM +0900, Simon Horman wrote:
> >> > >> On Thu, Jun 09, 2011 at 06:13:39PM +0900, Magnus Damm wrote:
> >> > >> > From: Magnus Damm <damm@opensource.se>
> >> > >> >
> >> > >> > This RFC patch kills two birds with one stone:
> >> > >> >
> >> > >> > 1) Fix existing issue where in-use clocks without software
> >> > >> > reference are disabled during boot. One example of this
> >> > >> > is the handling of the Mackerel serial console output.
> >> > >> >
> >> > >> > 2) Make sure so far unused clocks actually get turned off
> >> > >>
> >> > >> Is access to allow_disable SMP-safe?
> >> > >> In particular, does the the access in clk_late_init()
> >> > >> need to be guarded by clock_lock as calls to __clk_disable() are?
> >> > >
> >> > > On reflection I think that the problem is a bit deeper.
> >> > >
> >> > > I think allow_disable is set to 1 prematurely, as it indicates
> >> > > to __clk_disable() that calling clk->ops->disable(clk) is allowed,
> >> > > even if the iteration of the loop in clk_late_init() is not complete.
> >> > >
> >> > > My proposed re-working of clk_late_init() is below.
> >> > > Completely untested.
> >> >
> >> > Right, I was thinking something along those lines too. The spinlock
> >> > should make sure we're serialized.
> >>
> >> Great. Feel free to take my ideas verbatim if it helps.
> >
> > Hi Magnus,
> >
> > have you had time to look into this?
>
> I have not updated this patch yet, mainly due to lack of feedback. Not
> so much due to lack of feedback from you - I appreciate your ideas and
> I agree that your rework of the ordering is correct. I'm however still
> not sure if other people agree with my approach of delaying the
> disable operations until a certain point in time.
Understood.
next prev parent reply other threads:[~2011-06-21 3:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-09 9:13 [PATCH][RFC] drivers: sh: late disabling of clocks Magnus Damm
2011-06-13 8:59 ` Simon Horman
2011-06-14 6:41 ` Simon Horman
2011-06-15 14:21 ` Magnus Damm
2011-06-15 22:54 ` Simon Horman
2011-06-21 2:14 ` Simon Horman
2011-06-21 2:29 ` Magnus Damm
2011-06-21 3:02 ` Simon Horman [this message]
2011-06-21 5:27 ` Paul Mundt
2011-06-21 5:48 ` Magnus Damm
2011-06-21 6:39 ` Paul Mundt
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=20110621030208.GK16230@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-sh@vger.kernel.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