From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Matt Mackall <mpm@selenic.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, adaplas@pol.net
Subject: Re: Radeon FB troubles with recent kernels
Date: Tue, 15 Feb 2005 10:08:11 +1100 [thread overview]
Message-ID: <1108422492.12653.30.camel@gaston> (raw)
In-Reply-To: <1108420723.12740.17.camel@gaston>
> Appeared ? hah... that's strange. X is known to fuck up the chip when
> quit, but I wouldn't have expected any change due to the new version of
> radeonfb. From what you describe, it looks like an offset register is
> changed by X, or the surface control.
>
> My patch did not change any of radeonfb accel code though...
>
> I'll catch up with you on IRC ...
Ok, from our discussions, it's not related to the power management code,
and an engine reset triggered by fbset fixes it. So at this point, I can
see no change in the driver explaining it...
We did some changes to the VT layer to force a mode setting (and thus an
engine reset) when going away from X, so I can't see why that wouldn't
work, while using fbset later on works ... this goes through the same
code path in the driver... unless we are facing a timing issue...
X is known to play funny tricks, like touching the engine when it's in
the background (not frontmost VT) and quit, or possibly other bad things
on console switch. Maybe I changed enough delays (speeded up) the mode
switch so that we fall into a case where X has not finished mucking up
with us...
Can you try adding some msleep(200) or so at the beginning at
radeonfb_set_par() or radeon_write_mode() to see if that makes any
difference ?
Some printk's in there would help to... I expect calls to
radeon_engine_init() to fix it and such a call is present in the mode
restore unless accel is disabled...
Can you check what's happening ?
Ben.
next prev parent reply other threads:[~2005-02-14 23:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 20:39 Radeon FB troubles with recent kernels Matt Mackall
2005-02-14 22:38 ` Benjamin Herrenschmidt
2005-02-14 23:08 ` Benjamin Herrenschmidt [this message]
2005-02-15 0:02 ` Antonino A. Daplas
2005-02-15 0:20 ` Matt Mackall
2005-02-15 1:07 ` Benjamin Herrenschmidt
2005-02-15 6:06 ` Matt Mackall
[not found] <3xVku-kH-15@gated-at.bofh.it>
2005-02-15 3:14 ` Vincent C Jones
2005-02-15 12:46 ` Benjamin Herrenschmidt
2005-02-15 12:50 ` Benjamin Herrenschmidt
[not found] <3y1SR-5K6-1@gated-at.bofh.it>
[not found] ` <3yatk-4mE-29@gated-at.bofh.it>
2005-02-15 15:07 ` Vincent C Jones
2005-02-15 22:02 ` Benjamin Herrenschmidt
2005-02-16 1:53 ` Vincent C Jones
2005-02-16 2:41 ` Benjamin Herrenschmidt
2005-02-16 14:39 ` Vincent C Jones
-- strict thread matches above, loose matches on Subject: below --
2005-02-16 10:08 tvrtko.ursulin
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=1108422492.12653.30.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=adaplas@pol.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox