Re: comments on irc log

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On Wednesday 23 March 2005 12:16 pm, Todd Poynor wrote:
> David Brownell wrote:
> 
> > 
> > So to focus on one point:  "pm_message_t" doesn't work well
> > at all, since it doesn't have a way to identify the target
> > system power state, and drivers thus have no way to see if
> > they should drop their requests for those clocks or whether
> > the hardware should keep working away.
> 
> If I've followed the discussion correctly, it sounds like a lot of the 
> system intelligence is targeted at the bus driver level, and the current 
> generic platform bus driver for embedded onchip devices will probably 
> become something very tied to the particular platform. 

There's no driver for the "platform bus", just individual drivers
that hang off that data structure.   So nothing to target with
any "intelligence"; it's safe from Homeland Security.  :)


> If so, then at  
> least the bus driver would need to be told of the system state, which 
> can code the logic for figuring out which devices must be stopped prior 
> to entering a state, and device drivers can simply follow orders to 
> suspend.

I think it suffices to have the drivers know what to do:
"If going to system state X, then drop request for clock Y".

You seem to suggest something that knows which drivers exist,
and then goes to talk to them.  This isn't IMO a problem that
needs to be centrally managed, and I think it'd work better
to just let them do the right thing ... easier to make one
driver coordinate such stuff internally, than to make it
cope with various externally-induced surprises.


> But I suppose there's some cases in which a device driver may  
> have options more complicated than run/suspend in the face of changes in 
> clock gating, so having the info available to all drivers could be 
> useful even in that situation.

That too.  But, remember that in this case <asm/hardware/clock.h>
isn't structured to give clock change notifications to drivers; it's
not a cpufreq style thing, as a rule.  The model is that drivers
manage their own clocks, there's no scale() callback from any
central manager (like DPM does).  And the only question is when
they clk_unuse():  which system state is active after suspend().

- Dave


> 
> -- 
> Todd
> 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]