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

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

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

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
asleep, this could be an exported per-fbdev flag, an error code, or
whatever. In this case, fbcon can either buffer text input, or fallback
to the cfb working on the backed up fb image (that last thing can be
handled entirely within the fbdev I guess).

Ben.

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

[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 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. THe only problem is for fbcon to know that a given fbdev is
> asleep, this could be an exported per-fbdev flag, an error code, or
> whatever. In this case, fbcon can either buffer text input, or fallback
> to the cfb working on the backed up fb image (that last thing can be
> handled entirely within the fbdev I guess).

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

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[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
>> asleep, this could be an exported per-fbdev flag, an error code, or
>> whatever. In this case, fbcon can either buffer text input, or fallback
>> to the cfb working on the backed up fb image (that last thing can be
>> handled entirely within the fbdev I guess).
>
>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
framebuffer content.

Ben.

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

[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 only problem is for fbcon to know that a given fbdev is
> >> asleep, this could be an exported per-fbdev flag, an error code, or
> >> whatever. In this case, fbcon can either buffer text input, or fallback
> >> to the cfb working on the backed up fb image (that last thing can be
> >> handled entirely within the fbdev I guess).
> >
> >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
> framebuffer content.

Fine. Keep it. But there's no reason to keep on updating it when the screen
contents change. Fbcon can do that when the fbdev goes out of sleep mode.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[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 run and the backup is restored to the
> > >display.
> > >
> > >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. THe only problem is for fbcon to know that a given fbdev is
> > asleep, this could be an exported per-fbdev flag, an error code, or
> > whatever. In this case, fbcon can either buffer text input, or fallback
> > to the cfb working on the backed up fb image (that last thing can be
> > handled entirely within the fbdev I guess).
> 
> 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).

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?

No, there does not need to be graphical images of the text console -- a
simply text buffer would suffice.  But what about things like GTKFb and
Embedded QT?  They would certainly benefit from having a backup screen
image, right?  I do not believe there is any way to determine if the
console is in fact in a 'text' or graphical state.

Brad Douglas
brad@neruo.com
http://www.linux-fbdev.org

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

[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 to ask you where is this code? I like to take a look at it to
figure out what you are doing.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

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

[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 mach64 & chipsfb notifiers don't do anything to fbcon (they don't
stop the cursor timer neither). I have some WIP progress code in my local
tree that
implements sleep support for more recent models with a notifier in
aty128fb too.
I added some fbcon suspend/resume routines for the cursor, but they are
currently
called from my aty128fb sleep notifier, which is wrong.

Ben.

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

[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 it will be
possible to have only a serial console and use /dev/fb by itself. In this
case we don't even need dummycon since their is no VT support present.

>No, there does not need to be graphical images of the text console -- a
>simply text buffer would suffice.

See email to Ben.

>But what about things like GTKFb and
>Embedded QT?  They would certainly benefit from having a backup screen
>image, right?  I do not believe there is any way to determine if the
>console is in fact in a 'text' or graphical state.

Yes and it would not be hard to do this. I have the basic idea in the
email to Ben. As for console in text or graphical state take a look at
vt_ioctl.c:vt_ioctl() for KDGETMODE. You get back KD_TEXT or KD_GRAPHICS.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

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

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

  What he is talking about is in 2.5.X when you explictly open /dev/fb it
will call take_over_console with dummy con. This allows for several
things. One is with this approach their is no chance of a conflict between
X/DRI and fbdev. Especially when we will have fbdev drivers using DMA
internally to preform console operations. For some hardware using DMA is
the only way fbdev can work and on some platforms fbcon is the only
choice. So things going into /dev/ttyX will not have a chance to interfere
with X.  The second reason is for security. It is possible to have a
program to open /dev/fb and see what is being typed on the fore ground
console. I sealed up those holes using the dummy con approach and some
test to see if the current process is local.
  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 such in the case of the X server then copy the image of the
framebuffer to regular ram. Then power down /dev/fb using some ioctl calls
provide.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

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

[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 such in the case of the X server then copy the image of the
>framebuffer to regular ram. Then power down /dev/fb using some ioctl calls
>provide.

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

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.

I'm wondering if it would be possible to make X think there's a console switch
(without actually switching to an active console, as we don't know if we
even have
one of those available for us), wait for it to reply, and then start the sleep
process.

One other possibility would be to implement APM-like events, I still have
to study
those more in details as our sleep process is currently quite different
from APM
(and definitely not BIOS-based).

For now, I have my hooks in fbcon that suspend/restart the cursor timer,
that's
enough to make sleep stable on 2.4 since we take care of shutting down
the display
very last (after any other driver) to make sure no printk will end up
trying to
display something while the chip is powered down.
I'll digest your various comments look into all this in more depth with
2.5 console
codebase. I beleive some solution must be found for x86 laptops too.

Ben.

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

[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 bug in X: one must not change the video mode by banging the hardware
when running on a fbdev system.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[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. THe only problem is for fbcon to know that a given fbdev is
>asleep, this could be an exported per-fbdev flag, an error code, or
>whatever. In this case, fbcon can either buffer text input, or fallback
>to the cfb working on the backed up fb image (that last thing can be
>handled entirely within the fbdev I guess).

Hi!
  I had to give it some thought. I like to see this handles inside the
fbdev driver itself instead of inside fbcon. For 2.5.X it will be possible
to use /dev/fb with vgacon. Even better yet it will be possible to use
just a serial console and not use a VT but still use /dev/fb. So we will
want to to have fbdev doing power management itself. As for handling the
cursors I recently purposed a standardize cursor api so X can use it as
well via userland and a standard fbcon_cursor can be written. With this
api it would be easy to handle suspending and restoring the cursor for
fbcon for /dev/fb.
  As for fbcon knowing when it is asleep. Hum. We could have a flags to
tell it to have text data updates to be placed in the shadow buffer
(struct vc_datas->vc_screenbuffer) only;

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

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

[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 cursor timer, while fbdev's would handle HW
> >issues. THe only problem is for fbcon to know that a given fbdev is
> >asleep, this could be an exported per-fbdev flag, an error code, or
> >whatever. In this case, fbcon can either buffer text input, or fallback
> >to the cfb working on the backed up fb image (that last thing can be
> >handled entirely within the fbdev I guess).

    [...]

>   As for fbcon knowing when it is asleep. Hum. We could have a flags to
> tell it to have text data updates to be placed in the shadow buffer
> (struct vc_datas->vc_screenbuffer) only;

Very simple to implement in the fbdev itself: just replace the drawing ops by
dummy drawing ops.

This can already be done now, by providing a dummy struct display_switch, and
in the future by providing dummy accels.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[RFC] fbdev & power management

[Benjamin Herrenschmidt]

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 handle HW related things (shutting the backlight
off, putting the chip to sleep when possible, backing up the frame buffer
content, etc...) from there.

We do call the video sleep last during the sleep process, and wake it up
first, to avoid any problem if something is beeing printed to the console
while the chip is suspended.

However, this is not very safe. First, there's the cursor timer, which
can screw us up. I have a hack in my tree where the fbdev driver calls a
new routine in fbcon.c that stops/starts the cursor timer.

But I'm looking toward a more generic solution. By having a way to
"suspend" the entire fbcon, maybe we can have all console output blocked
& buffered until the fbcon is woken up. Also, a question is should we
call that fbcon_suspend()/fbcon_resume() (currently only the cursor timer
stuff) from the fbdev's or should the fbcon itself register as a power
management client, and then call fbdev's suspend/resume routines ? I
prefer the second solution as the fbdev's are often PCI devices (and so
already have the ability of having PCI suspend/resume hooks).

Another solution would be to have all fbdev's have it's own suspend/
resume hook (and maintain a "suspend" state that would tell fbdev to stop
calling them or start working on a memory based backup image), and
separately, fbdev's own suspend/resume (for the cursor, as it's not head-
dependant but rather global to all fbdev's).

Any comment ?

Ben.

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

[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 handle HW related things (shutting the backlight
> off, putting the chip to sleep when possible, backing up the frame buffer
> content, etc...) from there.
> 
> We do call the video sleep last during the sleep process, and wake it up
> first, to avoid any problem if something is beeing printed to the console
> while the chip is suspended.
> 
> However, this is not very safe. First, there's the cursor timer, which
> can screw us up. I have a hack in my tree where the fbdev driver calls a
> new routine in fbcon.c that stops/starts the cursor timer.
> 
> But I'm looking toward a more generic solution. By having a way to
> "suspend" the entire fbcon, maybe we can have all console output blocked
> & buffered until the fbcon is woken up. Also, a question is should we
> call that fbcon_suspend()/fbcon_resume() (currently only the cursor timer
> stuff) from the fbdev's or should the fbcon itself register as a power
> management client, and then call fbdev's suspend/resume routines ? I
> prefer the second solution as the fbdev's are often PCI devices (and so
> already have the ability of having PCI suspend/resume hooks).

I believe the second solution would be best.  We want to only have
hardware specific code in the fbdev drivers (well, as much as allows).

> Another solution would be to have all fbdev's have it's own suspend/
> resume hook (and maintain a "suspend" state that would tell fbdev to stop
> calling them or start working on a memory based backup image), and
> separately, fbdev's own suspend/resume (for the cursor, as it's not head-
> dependant but rather global to all fbdev's).

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?

Brad Douglas
brad@neruo.com
http://www.linux-fbdev.org