On Monday 28 March 2005 8:29 am, Jordan Crouse wrote:
> > struct device_driver {
>
> Its still in debate, but if we decide to do centralized policy
> management (like DPM), then we will need some way to pass in attributes
> such as device inactivity timeout to the device.
Device inactivity is a good example of something that's _already_ done
in a well-decentralized manner. E.g. X11/DPMS, and hdparm. If you're
after a motivation to adopt the MontaVista DPM model, that undermines
your argument ...
> Personally, I would be
> happy with a call that passed a pointer for flexibility, but it seems
> that recently, people are heavily favoring arguments that can be
> typchecked.
Pointers can easily be type-checked. :)
> [ As an aside, I think that deciding where policy management will live
> will help clear up some of the nagging issues we've been having about
> the role of the drivers vs. the role of the system, etc, etc. ]
I think system policy should live at the system level, and driver policy
should live at the driver level. Simple. ;)
> > A table could be defined that indicates what should be called for each
> > power level transition. *suspend and *resume could handle any extra
> > steps (ex. saving state). As an example, *start and *stop may only be
> > called when power is going to be lost entirely.
>
> I think we discussed this during the IRC meeting. I certainly don't
> favor multiple calls which increase the level of complexity of the
> calling entity.
It's a tradeoff. Needless complexity should be avoided, of course.
Device driver authors should have only a limited slate of system-wide
issues to cope with ... which argues more for keeping complexity in
the core. On the other hand, complex core logic can be hard to maintain
and error prone too.
> I would need one table to tell me what power level the
> device should be at, and a second table to tell me if I need to call
> stop() or start(). Furthermore some devices may go clocks off during
> one S-T-R transition, and then keep clocks on for wake another time.
Same is true for power, not just for clocks: both get switched on/off.
> Our current thinking is to assume that the driver is intelligent enough
> to know what to do for any given power level, and I think a single call
> would suffice for that.
There's also system configuration to think of. A recent example: a
device should turn off several controllers whenever it's not hooked
up to its docking station (with power supply). Regardless of whatever
else the other system power state(s) may be.
Some of these issues are completely orthogonal to other issues about
system state. You're right that these are examples of places where
the intelligence is best kept at the _driver_ level ... in this case,
the driver that handles the "I'm docked!" IRQ is the natural place to
know what devices a given docking configuration should activate.
- Dave
