>
>
>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
>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
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
> 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
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
>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
>>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
>>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
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
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
>> 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
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
>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
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
14 matches
Mail list logo