LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Collins <paul@burly.ondioline.org>
Cc: James Cloos <cloos@jhcloos.com>,
	linux-fbdev-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)
Date: Thu, 06 Nov 2008 18:52:41 +1100	[thread overview]
Message-ID: <1225957961.13603.48.camel@pasglop> (raw)
In-Reply-To: <87k5bhs8a7.fsf@burly.wgtn.ondioline.org>

On Thu, 2008-11-06 at 19:00 +1300, Paul Collins wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > Heh, it would have been easier to do
> >
> > 	width = (image->width | 0x1f) + 1; 
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > Oh and you also need to change the src_bytes calculation 
> 
> With the slightly less embarrassing patch below applied and using the
> default 8x16 font, the machine boots successfully with the expected
> gibberish console display.  I can then setfont one of the large fonts
> and it does not lock up.  The gibberish changes and if I do dmesg I even
> get a few chunks of legible output: http://ondioline.org/~paul/corruption.png

Ok. Well, that's both good and bad news. Good news is, we have a handle
on what the bug can be, ie, the comment in X might refer to an actual HW
limitation/bug, though I find it strange that it works fine in some
cases and not others.

The bad news is, I yet to figure out if we have a proper way out of it
using the clipping etc... that doesn't involve making the acceleration
totally worthless in the first place since it's already not very
interesting on a few platforms.

I'll dig but I'm afraid chances are that I'll disable the acceleration
by default unless some special command line arg is passed so that David
can still get his faster console on sparc.

Maybe using a completely different approach such as caching pre-expanded
glyphs would lead to better results... though I think it's harder to
implement with fbcon.

Cheers,
Ben.

> 
> diff --git a/drivers/video/aty/radeon_accel.c b/drivers/video/aty/radeon_accel.c
> index 8718f73..6dbd24a 100644
> --- a/drivers/video/aty/radeon_accel.c
> +++ b/drivers/video/aty/radeon_accel.c
> @@ -176,6 +176,7 @@ static void radeonfb_prim_imageblit(struct radeonfb_info *rinfo,
>  {
>  	unsigned int src_bytes, dwords;
>  	u32 *bits;
> +	int width;
>  
>  	radeonfb_set_creg(rinfo, DP_GUI_MASTER_CNTL, &rinfo->dp_gui_mc_cache,
>  			  rinfo->dp_gui_mc_base |
> @@ -208,9 +209,11 @@ static void radeonfb_prim_imageblit(struct radeonfb_info *rinfo,
>  	 * work ok for me without that and the doco doesn't seem to imply
>  	 * there is such a restriction.
>  	 */
> -	OUTREG(DST_WIDTH_HEIGHT, (image->width << 16) | image->height);
> +	/* Let us pad. */
> +	width = (image->width | 0x1f) + 1;
> +	OUTREG(DST_WIDTH_HEIGHT, (width << 16) | image->height);
>  
> -	src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
> +	src_bytes = (((width * image->depth) + 7) / 8) * image->height;
>  	dwords = (src_bytes + 3) / 4;
>  	bits = (u32*)(image->data);
> 


  reply	other threads:[~2008-11-06  7:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m31vy1k3ea.fsf@lugabout.jhcloos.org>
2008-10-28  0:00 ` David Miller
2008-10-28  1:46   ` James Cloos
2008-10-28  0:05 ` Benjamin Herrenschmidt
2008-10-28  1:50   ` James Cloos
2008-10-28  9:24   ` James Cloos
2008-11-02 21:48     ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2008-11-03  7:01       ` Paul Collins
2008-11-03  7:34         ` Benjamin Herrenschmidt
2008-11-04  6:49           ` Paul Collins
2008-11-04 21:33             ` Benjamin Herrenschmidt
2008-11-06  6:00               ` Paul Collins
2008-11-06  7:52                 ` Benjamin Herrenschmidt [this message]
2008-11-04 21:36             ` Benjamin Herrenschmidt
2008-11-05  8:39         ` Benjamin Herrenschmidt
2008-11-05 10:28           ` Paul Collins
2008-11-05 20:31             ` Benjamin Herrenschmidt
2008-11-06  3:49             ` Benjamin Herrenschmidt
2008-11-06  4:49               ` Paul Collins
2008-11-03 15:33       ` James Cloos
2008-11-03 20:22         ` 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=1225957961.13603.48.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=cloos@jhcloos.com \
    --cc=davem@davemloft.net \
    --cc=khc@pm.waw.pl \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@burly.ondioline.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).