From: Dave Airlie airl...@gmail.com
Date: Sat, 14 Feb 2009 17:42:02 +1000
On Sat, Feb 14, 2009 at 4:09 PM, David Miller da...@davemloft.net wrote:
1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead
of the constant 4096 to determine how many GART entries there
are. The
So I've narrowed down the final problems I'm having. It's the surface
swapping settings indeed.
Running Xorg at depth 8, the CP can execute indirect buffers just
fine, no code changes necessary.
However, the CP hangs on indirect execution for depth 16 and 24. But
these depths work if
The only think I can think to do is use a surface instead of the
aperture swappers
and make the surface cover all the VRAM except the GART table which is
at the end.
Why not use a surface to cover the GART ? At least this would ensure a
known swapper setting for it.
That's interesting, it
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Sat, 14 Feb 2009 20:07:54 +1100
I did some research, and it does appear that the GART does read the
PTEs from the VRAM using the Host Data Path. This means the surface
control byte swapping settings are applied.
So for depths
From: David Miller da...@davemloft.net
Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST)
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Sat, 14 Feb 2009 20:07:54 +1100
We can do that by registering a surface from the kernel to cover the
GART I suppose, and clean things a bit so
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in the frame buffer
it gets applied the current fb swapper setting... ouch !
On Sat, Feb 14, 2009 at 4:09 PM, David Miller da...@davemloft.net wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in the frame buffer
it gets applied the current fb swapper setting... ouch !
On Thu, Feb 12, 2009 at 9:09 PM, David Miller da...@davemloft.net wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in
1) The kernel radeon framebuffer driver doesn't mess with
the framebuffer endianness setting.
2) On = R300 (which my chip is), Xorg leaves it alone too.
They leave alone the swapper of the engine, not the fb one
(SURFACE_CNTL) afaik.
I dbl checked the other day and it seems that we
On Fri, 2009-02-13 at 08:26 +1100, Benjamin Herrenschmidt wrote:
1) The kernel radeon framebuffer driver doesn't mess with
the framebuffer endianness setting.
2) On = R300 (which my chip is), Xorg leaves it alone too.
They leave alone the swapper of the engine, not the fb one
From: Dave Airlie airl...@gmail.com
Date: Thu, 12 Feb 2009 21:23:13 +1000
are you on a PCI or PCIE card, I've no idea what buses you have on sparc64.
On the PCI cards the GART table will always be in main memory.
PCIE always in VRAM.
PCI-E
13 matches
Mail list logo
