All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Eger <eger@theboonies.us>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver
Date: Tue, 17 Feb 2004 08:50:37 +1100	[thread overview]
Message-ID: <1076968236.3648.42.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402160947080.30742@home.osdl.org>

On Tue, 2004-02-17 at 04:56, Linus Torvalds wrote:

> The console layer already always calls "unblank_screen()" on any switch to
> text mode, _regardless_ of whether it was switching from another console
> or not. That should be the place where this is done, and perhaps by
> changing the console layer to be a bit more helpful about things (mainly
> re-name the damn thing, since it has nothing to do with "unblank" any
> more).
> 
> "unblank_screen()" is really the same as "reset_screen" - it's also called
> on resume. While "do_blank_screen()" is basically "go away".

That's interesting... I didn't want to do a full mode + engine restore
in unblank_screen though as this can be called from interrupt time by
printk... But then, with the LVDS blanking, I already have to delay
up to 1 second in this function, so .... I think I'll have to find a
way to abstract a delay function that schedules in normal case _but_
when called from printk....

> So why don't you just reset the thing in "con_blank()" that gets called in 
> all the right cases?

Do we want to pay the cost (in time) of a full mode set + engine reset
on each unblank ? I could limit myself to restoring the accel engine,
that faster, but with X also not always restoring the console mode
properly, I'd have preferred re-setting the whole mode... 

Maybe we should go that way for now (engine only in unblank), then try
to fix X for the mode thing (if doable.... there is some VGA magic in
there that I don't understand)

Ben.



  reply	other threads:[~2004-02-16 21:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.50L0.0402160411260.2959-100000@rosencrantz.theboonies.us>
2004-02-16  4:01 ` 2.6.3-rc3 radeonfb: Problems with new (and old) driver Benjamin Herrenschmidt
2004-02-16 17:56   ` Linus Torvalds
2004-02-16 21:50     ` Benjamin Herrenschmidt [this message]
2004-02-16 22:13       ` Linus Torvalds
2004-02-16 22:18         ` Benjamin Herrenschmidt
2004-02-16 22:30           ` Linus Torvalds
2004-02-16 22:57             ` Benjamin Herrenschmidt
2004-02-16 23:09               ` Linus Torvalds
2004-02-16 23:31                 ` Benjamin Herrenschmidt
2004-02-16 23:49                   ` Linus Torvalds
2004-02-17  0:04                     ` Benjamin Herrenschmidt
2004-02-15  6:16 [PATCH] Remove debug cruft from via-pmu.c driver Benjamin Herrenschmidt
2004-02-15 18:02 ` 2.6.3-rc3 radeonfb: Problems with new (and old) driver Mike Houston
2004-02-15 21:01   ` Petr Vandrovec

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=1076968236.3648.42.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=eger@theboonies.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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.