From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andreas Schwab <schwab@suse.de>
Cc: Dave Airlie <airlied@gmail.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Date: Sun, 10 Apr 2005 09:33:11 +1000 [thread overview]
Message-ID: <1113089591.9518.440.camel@gaston> (raw)
In-Reply-To: <jey8brj4tx.fsf@sykes.suse.de>
On Sat, 2005-04-09 at 18:24 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Can you redo the counting of the workarounds with the patch ?
>
> Switching from X to console:
>
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
Ok, so the above is interesting, something is callign setcmap way too
much here I would say... Besides, it looks like set_par is called twice,
which is wrong too.
> Switching from console to X:
>
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode
> agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode
> radeonfb_setcolreg: INPLL
> radeonfb_setcolreg: OUTPLL
> radeonfb_setcolreg: OUTPLL
> ... last three lines repeated 63 times
Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely
dumb, and calling the ioctl 64 times to set each palette entry instead
of doing a single call for the whole palette...
Anyway. Except for maybe the double set-par on switch from X to console,
there isn't much more we can do here. We might be able to improve X but
there is a significant lag between a fix done to X.org HEAD appears in
any distro. The fact is, according to ATI, there is a HW bug on M6 taht
can cause lockups of the chip, and this 5ms workaround is necessary to
avoid it...
Ben.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andreas Schwab <schwab@suse.de>
Cc: Dave Airlie <airlied@gmail.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Date: Sun, 10 Apr 2005 09:33:11 +1000 [thread overview]
Message-ID: <1113089591.9518.440.camel@gaston> (raw)
In-Reply-To: <jey8brj4tx.fsf@sykes.suse.de>
On Sat, 2005-04-09 at 18:24 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Can you redo the counting of the workarounds with the patch ?
>
> Switching from X to console:
>
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
Ok, so the above is interesting, something is callign setcmap way too
much here I would say... Besides, it looks like set_par is called twice,
which is wrong too.
> Switching from console to X:
>
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode
> agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode
> radeonfb_setcolreg: INPLL
> radeonfb_setcolreg: OUTPLL
> radeonfb_setcolreg: OUTPLL
> ... last three lines repeated 63 times
Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely
dumb, and calling the ioctl 64 times to set each palette entry instead
of doing a single call for the whole palette...
Anyway. Except for maybe the double set-par on switch from X to console,
there isn't much more we can do here. We might be able to improve X but
there is a significant lag between a fix done to X.org HEAD appears in
any distro. The fact is, according to ATI, there is a HW bug on M6 taht
can cause lockups of the chip, and this 5ms workaround is necessary to
avoid it...
Ben.
next prev parent reply other threads:[~2005-04-09 23:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-11 5:42 [PATCH] radeonfb: Implement proper workarounds for PLL accesses Benjamin Herrenschmidt
2005-03-13 0:12 ` [PATCH] radeonfb: (#2) " Benjamin Herrenschmidt
2005-04-05 21:44 ` Andreas Schwab
2005-04-05 23:31 ` Benjamin Herrenschmidt
2005-04-06 22:35 ` Andreas Schwab
2005-04-06 22:47 ` Benjamin Herrenschmidt
2005-04-07 20:21 ` Andreas Schwab
2005-04-07 21:22 ` Dave Airlie
2005-04-07 22:59 ` Benjamin Herrenschmidt
2005-04-07 23:58 ` Andreas Schwab
2005-04-08 0:03 ` Benjamin Herrenschmidt
2005-04-08 1:19 ` Benjamin Herrenschmidt
2005-04-08 1:19 ` Benjamin Herrenschmidt
2005-04-08 21:11 ` Andreas Schwab
2005-04-09 0:03 ` Benjamin Herrenschmidt
2005-04-09 0:03 ` Benjamin Herrenschmidt
2005-04-09 16:24 ` Andreas Schwab
2005-04-09 23:33 ` Benjamin Herrenschmidt [this message]
2005-04-09 23:33 ` Benjamin Herrenschmidt
2005-04-10 10:05 ` Moritz Muehlenhoff
2005-04-10 22:45 ` Benjamin Herrenschmidt
2005-04-10 23:10 ` Brice Goglin
2005-04-07 22:47 ` Benjamin Herrenschmidt
2005-04-07 23:13 ` Andreas Schwab
2005-04-07 23:19 ` Benjamin Herrenschmidt
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=1113089591.9518.440.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=airlied@gmail.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=schwab@suse.de \
/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.