Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-21 Thread Benjamin Herrenschmidt
> > >I need to ask you where is this code? I like to take a look at it to >figure out what you are doing. You can find the mach64 sleep notifier in atyfb.c (under CONFIG_POWERBOOK) , the code that calls sleep notifiers is in drivers/macintosh/via-pmu.c (the various sleep functions). The current

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-21 Thread James Simmons
>Ok, I see. Currently, the sleep process is started from an ioctl sent to >another driver, which will in turn call various notifier functions to >shut down bits of hardware and finally put the machine to sleep. It's not >a direct ioctl to the /dev/fb (which may not be opened). [snip]... I need

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-15 Thread Geert Uytterhoeven
On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote: > One problem I have is that my fbdev sleep routine will restore the mode > on wakeup, > but that of course doesn't work with X when not using useFBDev as fbdev > have no > knowledge of the current mode or register settings used by X. That's a bu

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-15 Thread Benjamin Herrenschmidt
> Now for fbcon its simpler. Things get writing to the shadow buffer >(vc_screenbuf). When the console gets woken up update_screen is called. >While power down the shadow buffer can be written to which is much faster >than saving a image of the framebuffer. Of course if you still want to do >this

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-15 Thread Geert Uytterhoeven
On Wed, 14 Mar 2001, James Simmons wrote: > >>So the fbdev drivers would register PM with fbcon, not PCI, correct? > > > >Either that, or the fbdev would register with PCI (or whatever), _and_ > >fbcon would too independently. In that scenario, fbcon would only handle > >things like disabling the

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread James Simmons
>But wouldn't falling back to dummycon prevent the driver specific >suspend/resume calls from working? Or at a minimum, make handling those >calls more complex? Not if suspend/resume are handled on the fbdev driver level. Dummycon would only shutdown fbcon on explict open of /dev/fb. Also note

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread James Simmons
>>I'd go for a fallback to dummycon. It's of no use to waste power on >>creating graphical images of the text console when asleep. And the >>fallback to dummycon is needed anyway while a fbdev is opened (in >>2.5.x). > >We do already have the backup image since we need to backup & restore the >fr

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread James Simmons
>>So the fbdev drivers would register PM with fbcon, not PCI, correct? > >Either that, or the fbdev would register with PCI (or whatever), _and_ >fbcon would too independently. In that scenario, fbcon would only handle >things like disabling the cursor timer, while fbdev's would handle HW >issues

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread Brad Douglas
On 14 Mar 2001 14:39:57 +0100, Geert Uytterhoeven wrote: > On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote: > > >I think registering fbcon as a PM client and doing the above when the > > >fbdev suspend/resume hooks are called should work. A memory backup is > > >worked on until the resume is ru

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread Geert Uytterhoeven
On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote: > >> Either that, or the fbdev would register with PCI (or whatever), _and_ > >> fbcon would too independently. In that scenario, fbcon would only handle > >> things like disabling the cursor timer, while fbdev's would handle HW > >> issues. THe o

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread Benjamin Herrenschmidt
>> Either that, or the fbdev would register with PCI (or whatever), _and_ >> fbcon would too independently. In that scenario, fbcon would only handle >> things like disabling the cursor timer, while fbdev's would handle HW >> issues. THe only problem is for fbcon to know that a given fbdev is >> a

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread Geert Uytterhoeven
On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote: > >I think registering fbcon as a PM client and doing the above when the > >fbdev suspend/resume hooks are called should work. A memory backup is > >worked on until the resume is run and the backup is restored to the > >display. > > > >So the fbd

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-14 Thread Benjamin Herrenschmidt
>I think registering fbcon as a PM client and doing the above when the >fbdev suspend/resume hooks are called should work. A memory backup is >worked on until the resume is run and the backup is restored to the >display. > >So the fbdev drivers would register PM with fbcon, not PCI, correct? Eit

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

2001-03-13 Thread Brad Douglas
On 13 Mar 2001 22:25:29 +0100, Benjamin Herrenschmidt wrote: > I'm working on improving some aspects of Power Management on the > PowerBooks, and among other things, I have a problem with fbdevs. > > Currently, each fbdev registers a power management callback to sleep/ > wakeup the device. We han