Messages in this thread | | | Date | Thu, 15 Dec 2005 14:31:24 +0000 | From | Luke Kenneth Casson Leighton <> | Subject | ordering of suspend/resume for devices. any clues, anyone? |
| |
[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> -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |