Message-ID: <20110115163155.GF6917@pengutronix.de>
Date:	Sat, 15 Jan 2011 17:31:55 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Christer Weinigel <christer@...nigel.se>,
	Saravana Kannan <skannan@...eaurora.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: Locking in the clk API

On Sat, Jan 15, 2011 at 04:21:21PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-König wrote:
> > On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > > No - I've been suggesting for about a week now about doing two entirely
> > > separate consolidations.
> > I didn't read that out of your mails.
> 
> It was actually four days ago:
> | Maybe another approach for the time being is to unify in two steps: first
> | unify the implementations which use a spinlock - and those which can use
> | a spinlock, and separately those which must use a mutex.
> | 
> | Then this issue can be revisited in the future.
> 
> > > I think it would be insane to do the consolidation of the two different
> > > implementations in one patch or even one patch set.  There needs to be
> > > a consolidation of spinlock-based clks as one patch set, which is
> > > entirely separate and independent from the consolidation of mutex-based
> > > clks.
> > I think they should share most of the code.  Apart from calling
> > different locking functions they should be pretty much identical, no?
> 
> That way you get unions of mutexes and spinlocks (which is one thing
> we're trying to avoid) and conditionals controlling whether a mutex
> or spinlock is taken - which we've already ascertained was strongly
> objected to by folk in mainline (and quite rightfully so IMHO.)
If the decision is done basing on a Kconfig symbol it's an #ifdef.
That's not great but IMHO much better than a runtime decision.
 
> > > What if one of the consolidations turns out to be a problem?  Do we want
> > > to throw both out, or do we want to keep as much as we possibly can?
> > Do you really expect fundamental problems that make it necessary to
> > switch all platforms that use the (say) sleeping variant back to their
> > original implementation?  I don't think that when the general idea of
> > using clk_ops prooves for the atomic case it cannot happen that a
> > "native" implementation for a sleeping clk is better that a sleeping
> > clk_ops implementation.
> 
> I'm saying keep all the options open until we've got the whole thing
> sorted out.  If you think it's possible to do without creating a mess
> in the process - and without unions of mutexes and spinlocks or
> conditionals controlling whether we use mutex_lock vs spin_lock then
> please show the patches.

Jeremy: I think it would be quite easy to convert your series to use an
#ifdef instead of the flag.  I don't want to do this (at least not
without asking first) because it's your series, not mine.  How should we
proceed?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists