All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linux Fbdev development list 
	<linux-fbdev-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>
Subject: [RFC] fbdev & power management
Date: Tue, 13 Mar 2001 22:25:29 +0100	[thread overview]
Message-ID: <20010313212529.16206@smtp.wanadoo.fr> (raw)

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.



             reply	other threads:[~2001-03-13 21:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-13 21:25 Benjamin Herrenschmidt [this message]
2001-03-14  8:02 ` [Linux-fbdev-devel] [RFC] fbdev & power management Brad Douglas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010313212529.16206@smtp.wanadoo.fr \
    --to=benh@kernel.crashing.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.