Re: [RFC] Fix Device Power Management States

[Benjamin Herrenschmidt]

On Wed, 2004-08-11 at 08:41, Patrick Mochel wrote:
> On Tue, 10 Aug 2004, Pavel Machek wrote:
> 
> > I still do not see it... swsusp does not care about logical state of
> > device. (Actually manipulating logical state of device might make
> > swsusp less transparent). It cares about device not doing DMA (I also
> > said "no interrupts", but that is not strictly neccessary: we disable
> > interrupts for atomic copy. Device should do no NMIs, through).
> 
> Perhaps it is unncessary to do at a class level, at least at this point.
> I think we all agree that we need some sort of stop/start methods for
> devices, though. In which, we can add to struct bus_type:
> 
> 	int (*dev_stop)(struct device *);
> 	int (*dev_start)(struct device *);
> 
> Sound good?

Well, darwin has those, though I'm not sure if it's that necessary to
have them at all, well, maybe...

One thing is sure, having those at the class device level, if I
understand correctly, means we would have broken the ordering
requirement of always following the bus tree.

Honestly, I would stick to not having those at first, the PM callbacks
are enough for most cases, and just have "helpers" that the PM callbacks
call provided by their "class". For example, we could have a
netdev_quiesce_device() call that wuold wrap queue stopping and whatever
else (not much) has to be done at the network level.

IDE sort-of already has that via the PM request infrastructure, low
drivers only implement the few state machine steps they need for things
like cache flush or standby command. It would make sense to do a similar
mecanism for SCSI.

Honestly, there is really not that much to do related to class-side
start/stop, most of the work is usually at the driver level anyway from
experience (I implemented working PM for a bunch of drivers), there are
few things to take care with the "upper level", but not really that
much, and I would rather keep that as a helper function.

Let's keep things simple,

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/