David Brownell wrote: > On Wednesday 23 March 2005 12:16 pm, Todd Poynor wrote: >>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. It was my try at taking some of the other comments I've read on moving smarts to the PCI et al busses and applying them to the platform bus, looks like that's not what's in the works. And it would indeed presuppose board-specific code that knows about its onchip/onboard drivers (for example, PowerPC 4xx at least used to centrally manage various aspects of its onchip devices). So the platform bus is not intended to encapsulate the platform logic for device clocking interactions with system power states, this goes into the drivers, which should be fine. Depending on the eventual implementation perhaps it could be the case that some common drivers would need board-specific logic to deal with these interactions, but if so then that can always be dealt with. -- Todd
