Re: Alternative Concept

[David Brownell <david-b@pacbell.net>]

On Tuesday 20 March 2007 8:36 am, Igor Stoppa wrote:

> Your approach is to just label policy what you want to kick out of the
> driver =) Nice one!

I had a similar reaction ... although, I was also wondering exactly
what benefit would come from kicking that stuff out of drivers, and
thus needing to rewrite/retest a lot of them.


> > Ok, seems you are happy with current clock framework and advocating it
> > to be as is.
>
> As I wrote several times i haven't seen yet a reason to replace it;
> certainly there is space for improvement but so far this proposal has
> not been on the lines of: how to improve the clk fw

Yes.  This thread is unfortunately very much a "where's the beef".
I was afraid that was what would happen, given the complete lack
of interface proposal.

I suspect that until some non-troll content is provided, I'll tune out.


> > Are you against addition some features to it, such as enable/disable 
> > "turn the unused clock off" rule,

That'd be what we call a "misfeature", or "bug".  Are you suggesting
this be done to the IRQ subsystem too?  It has a rule that unused
IRQs must be turned off.  Likewise that IRQs not used as wake events
shouldn't be enabled as wake events.  I hope you're not restricting
your addition of misfeatures to just the clock framework!


> > Besides that it is meaningless for you, do you have any technical
> > objections for that?
>
> Do you mean apart from the fact that it means hijacking the fw?
> Noooo, not at all.

I take it that was meant to be sarcasm...

Me, yes I have already presented technical objections, all of which
appear to have been ignored.


> But why is it meaningful to you? Why can't you interact with the entity
> that is actually controlling a certain clock, rather than with the clock
> itself?

Good question.  I hope that one doesn't get ignored, too.

- Dave