Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:44:22PM +0100, Christer Weinigel wrote:
> On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
> > You really need to read the entire thread - I've already said that yet
>
>> discussion continues about how to solve the problem.  This thread which
>> has been running for a number of days now has been entirely about how
>> to solve this.
>
>
> Sigh, the always oh so polite Russell.  I have read the thread before; I  
> reread the whole thread one more time before posting.

Look, the clk API unification issue has been rattling around for six months
or more not making very much progress.  Should it continue to be discussed
for another six months while nothing happens because agreement can't be
reached?

Do you not realise what you suggested has already been proposed?

Does it help the discussion to have more people coming into the discussion
saying "we should do X" when we've already had people suggesting that we
should already do X - and we've had people saying afterwards "we should
do Y"?

Do you really think that you saying "we should do X" means that we'll have
lots of people suddenly saying "oh yes, you're right" when they didn't
before?

It's covering old ground over and over again.  Raising the same points
over and over again is just a pointless waste of time - it just sends the
discussion around the same loops time and time again.  Nothing actually
ever gets resolved but lots of time gets wasted discussing it.

>> Consider this: is it better to continue talking about this for the next
>> six months, while still having N spinlock based implementations, and M
>> mutex based implementations.
>>
>> Or is it better to consolidate the N spinlock based implementations
>> down to one spinlock implementation, and M mutex based implementations
>> down to one mutex implementation, and then discuss how to resolve the
>> differences between the two implementations?
>
>
> Going that way might very well mean that you will be stuck with two  
> implementations forever.  But yes, it might be better with two working  
> ones than one which takes a bit longer to finish.
>
> But my impression is that the different suggestions in the thread aren't  
> that far apart.  Except for the discussion if clk_enable/disable should  
> be able to sleep or not, people seem to agree on most of the rest of the  
> API.

As I said, at this point I _really_ don't care what happens provided
it doesn't end up screwing the facilities enjoyed by the existing
implementations.

I'm tired of reading this discussion.