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

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

[Luke Kenneth Casson Leighton]

[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>
--

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

[Greg KH]

On Thu, Dec 15, 2005 at 02:31:24PM +0000, Luke Kenneth Casson Leighton wrote:
> [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:

<snip>

Known issue, I'd take this to the linux-pm mailing list instead, as the
people there are working on stuff for this.

thanks,

greg k-h

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

[Luke Kenneth Casson Leighton]

On Thu, Dec 15, 2005 at 10:37:44AM -0800, Greg KH wrote:

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

> > <snip>

> > possible solutions, as i see them:
> 
> <snip>
> 
> Known issue, I'd take this to the linux-pm mailing list instead, as the
> people there are working on stuff for this.
 
 thanks greg.

 l.

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

[Pavel Machek]

Hi!

> [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.

I'd say "make LCD system/platform device". That will init it first,
shut it down last.
							Pavel

-- 
Thanks, Sharp!

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

[Luke Kenneth Casson Leighton]

heya pavel,

thanks for the tip.  as it turns out, a function table was hacked-n
that back-link from the w100fb framebuffer resume function into the
LCD code.

in this way, it is possible to call functions in the LCD module
doing GPIO to start the power-up sequence required for the
LCD and backlight, wait a few ms, initialise the video chip
(in the w100fb code), then call _another_ set of functions in
the LCD module to finish off the initialisation.

not pretty, but there you go.

l.

On Wed, Dec 21, 2005 at 11:21:09AM +0100, Pavel Machek wrote:
> Hi!
> 
> > [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.
> 
> I'd say "make LCD system/platform device". That will init it first,
> shut it down last.
> 							Pavel
> 
> -- 
> Thanks, Sharp!

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