ordering of suspend/resume for devices. any clues, anyone?

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

[hi, please kindly cc me direct as i am deliberately subscribed with
settings to not receive posts from this list, but if that is inconvenient
for you to cc me, don't worry i can always look up the archives
to keep track of replies, thank you.]

http://handhelds.org/moin/moin.cgi/BlueAngel

works.

am seeking some advice regarding power management - specifically
the ordering of devices "resume" functions being called.

we have an LCD, and an ATI chip.  switching on the LCD powers up
the ATI chip.

unfortunately, resume calls the ATI device initialisation
_before_ the LCD resume initialisation.  the ATI chip's
initialisation fails - naturally - because it's not even
powered up.

of course - this can't be taken care of in userspace as an apm
event because the framebuffer device cannot be a module [without
terminating all running x-applications].

so.

possible solutions, as i see them:

1) have some awfulness in the LCD driver and the ATI driver with some
shared resume initialisation callbacks.

2) work out where the initialisation of the LCD driver is called
from, and somehow get that inserted into the initialisation order
in the reverse way from what it is now, such that the linked list
of device drivers is inverted, such that the resume event will
end up calling the LCD resume _after_ the ATI resume.

3) some lovely "dependency" work gets done in the linux kernel
where you can register priorities on the resume order.

this would mirror the way that the old apm "event.d" thing
would have worked.

4) other - that i don't know about, but would love to hear from
someone if there already exists a solution.

any clues, anyone?

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--