PowerPC radeon KMS - is it possible?

PowerPC radeon KMS - is it possible?

[o jordan]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]


Hi list,
Firstly let me say thanks for the great work you do!!!
I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04.  I can only get it working by forcing PCI mode (agpmode=-1).  Setting agpmode=1 or a higher number just results in freezing and a flashing screen.  Does anybody know how to get it working fully with agp?
I've tried the Debian experimental kernel with the same results.  I notice with Fedora 16 they also recommend setting agpmode=-1 with a radeon card.  So I'm guessing there is no easy fix??
I've been trying to sort out the kernel configuration for ati/radeon cards with Ubuntu.  I raised a bug to build back in the framebuffers https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288 .  I'd appreciate any help with that bug report.
With Userspace Mode Setting there is nolonger any 3D hardware acceleration (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 ) so this is why I'm interested in getting KMS working properly.  However, some people seem to really want suspend which currently requires radeonfb.  So I'm trying to find a kernel configuration that works well for UMS and KMS!!!  
This is what I proposed:

CONFIG_DRM_RADEON_KMS=y

CONFIG_FB_RADEON=y

CONFIG_FB_ATY128=y

CONFIG_FB_ATY=y
So people can disable radeonfb from the yaboot prompt/conf if they want fully working KMS.  I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or built in.   We are now in kernel freeze for 12.04 so to get any changes is going to take some serious begging!!!
Cheers
Adam 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2180 bytes --]

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Die, 2012-04-17 at 20:49 +0100, o jordan wrote:=20
>=20
> I've been trying to get Kernel Mode Setting working on my iBook with
> Ubuntu 12.04.  I can only get it working by forcing PCI mode
> (agpmode=3D-1).  Setting agpmode=3D1 or a higher number just results in
> freezing and a flashing screen.

At which point? When radeon KMS initializes, or only when X starts?

> I've tried the Debian experimental kernel with the same results.  I
> notice with Fedora 16 they also recommend setting agpmode=3D-1 with a
> radeon card.  So I'm guessing there is no easy fix??

Probably not (AGP is flaky in general, but in particular with older
UniNorth bridges), but it might be interesting to see some kernel output
from booting without agpmode=3D-1. If you can't get it via ssh, maybe you
can via netconsole or so.


> With Userspace Mode Setting there is nolonger any 3D hardware
> acceleration
> (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 )

=46rom the Mesa upstream POV, the drivers from the 7.11 branch could be
used for this.


> CONFIG_DRM_RADEON_KMS=3Dy
> CONFIG_FB_RADEON=3Dy

Not sure it's a good idea to set both of these =3Dy: It will prevent the
radeon driver from initializing at all by default if radeonfb is active.
If you want CONFIG_FB_RADEON=3Dy, I'd suggest leaving
CONFIG_DRM_RADEON_KMS disabled. KMS can always be enabled at boot time
with radeon.modeset=3D1.

> CONFIG_FB_ATY128=3Dy
> CONFIG_FB_ATY=3Dy

There's no KMS for pre-Radeon ATI cards yet, so these are not directly
related.


> I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or
> built in. =20

I think it would only need to be built in if the radeon driver was built
in, which is not recommended.


P.S. The dri-devel list at freedesktop.org might be better for this, at
least in addition to linuxppc-dev.

--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Tue, 2012-04-17 at 20:49 +0100, o jordan wrote:
> Hi list,
> 
> 
> Firstly let me say thanks for the great work you do!!!
> 
> 
> I've been trying to get Kernel Mode Setting working on my iBook with
> Ubuntu 12.04.  I can only get it working by forcing PCI mode
> (agpmode=-1).  Setting agpmode=1 or a higher number just results in
> freezing and a flashing screen.  Does anybody know how to get it
> working fully with agp?
> 

Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> Note also that KMS doesn't afaik have the power management code that
> radeonfb has for those old Mac chipsets, so suspend/resume won't work.

How hard would it be to add it?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> 
> > Note also that KMS doesn't afaik have the power management code that
> > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
> 
> How hard would it be to add it?

The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-) So the real deal is to figure out
how best to "hook it up" there.

There's some duplication 
Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > 
> > > Note also that KMS doesn't afaik have the power management code that
> > > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
> > 
> > How hard would it be to add it?
> 
> The code itself is relatively self contained, but the KMS power
> management side is a bit ... messy :-) So the real deal is to figure out
> how best to "hook it up" there.
> 
> There's some duplication 

Argh... bloody x220 touchpad...

So I was saying, there's also some duplication in the area of dynamic
clocks configuration. Some of this could be an issue as afaik, to work
reliably, the suspend/resume code really wants the stuff to be setup
exactly the way the code in radeon_pm does....

But it's definitely worth trying to port it over.

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > >=20
> > > > Note also that KMS doesn't afaik have the power management code tha=
t
> > > > radeonfb has for those old Mac chipsets, so suspend/resume won't wo=
rk.
> > >=20
> > > How hard would it be to add it?
> >=20
> > The code itself is relatively self contained, but the KMS power
> > management side is a bit ... messy :-)

That's an interesting way to put it, given the hacks to make it work
between radeonfb and uninorth_agp. :) (Which are complicating making at
least hibernation work with KMS on uninorth_agp)

In contrast, radeon KMS uses the standard Linux device suspend/resume
hooks.

> > So the real deal is to figure out how best to "hook it up" there.
> >=20
> > There's some duplication=20
>=20
> Argh... bloody x220 touchpad...
>=20
> So I was saying, there's also some duplication in the area of dynamic
> clocks configuration. Some of this could be an issue as afaik, to work
> reliably, the suspend/resume code really wants the stuff to be setup
> exactly the way the code in radeon_pm does....

Are you referring to radeon_pm in radeonfb or radeon KMS?

Most of the latter isn't used on PPC laptops because it relies on an x86
video BIOS.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 12:54 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote: 
> > On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > > > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > > > 
> > > > > Note also that KMS doesn't afaik have the power management code that
> > > > > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
> > > > 
> > > > How hard would it be to add it?
> > > 
> > > The code itself is relatively self contained, but the KMS power
> > > management side is a bit ... messy :-)
> 
> That's an interesting way to put it, given the hacks to make it work
> between radeonfb and uninorth_agp. :) (Which are complicating making at
> least hibernation work with KMS on uninorth_agp)

Oh, I forgot about the AGP hooks indeed... but even that, it's in arch
code so it's not necessarily a huge deal to move it over. IE. It's just
a function pointer to call at the right time that's exported by the
arch.

> In contrast, radeon KMS uses the standard Linux device suspend/resume
> hooks.

Well, as radeonfb does.

The hack with AGP is so that radeonfb gets to control when the AGP is
suspended/restored  as it needs to be done in a specific order and the
device model doesn't provide the right ordering (they are sibling
devices).

There's also an early-wakeup hack but that's orthogonal, it's mostly
useful for debugging and doesn't necessarily need to be ported over.
  
> > Argh... bloody x220 touchpad...
> > 
> > So I was saying, there's also some duplication in the area of dynamic
> > clocks configuration. Some of this could be an issue as afaik, to work
> > reliably, the suspend/resume code really wants the stuff to be setup
> > exactly the way the code in radeon_pm does....
> 
> Are you referring to radeon_pm in radeonfb or radeon KMS?

radeonfb.

> Most of the latter isn't used on PPC laptops because it relies on an x86
> video BIOS.

Right, we might be able to easily port my old code over by simply making
it ppc specific. In radeonfb, it's also used for some thinkpads among
others but KMS does that with the BIOS on these no ? (ie. D2 state).

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote:=20
>=20
> Right, we might be able to easily port my old code over by simply making
> it ppc specific. In radeonfb, it's also used for some thinkpads among
> others but KMS does that with the BIOS on these no ? (ie. D2 state).

KMS doesn't have any non-BIOS suspend/resume code yet, so it's either
that or no suspend/resume. :)


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 15:07 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote: 
> > 
> > Right, we might be able to easily port my old code over by simply making
> > it ppc specific. In radeonfb, it's also used for some thinkpads among
> > others but KMS does that with the BIOS on these no ? (ie. D2 state).
> 
> KMS doesn't have any non-BIOS suspend/resume code yet, so it's either
> that or no suspend/resume. :)

Sure, my point is I don't know what happens on those old thinkpads, ie,
what does the BIOS provides to KMS and whether it's a good enough
alternative to the "hand made" D2 approach radeonfb used on them.

But heh, I'm happy to just ignore those, that would make things easier,
in which case we can just have a non-bios pair of suspend/resume calls
provided as empty weak functions, and have a radeon_mac_pm.c providing
more/less the existing radeonfb code for power macs overriding those
weak functions.

If it's mac-only it's going to be easier to deal with.

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> Not sure it's a good idea to set both of these =y: It will prevent the
> radeon driver from initializing at all by default if radeonfb is active.

You can say video=radeonfb:off.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > Not sure it's a good idea to set both of these =3Dy: It will prevent th=
e
> > radeon driver from initializing at all by default if radeonfb is active=
.
>=20
> You can say video=3Dradeonfb:off.

I know, I'm referring to the default behaviour without any relevant
kernel command line options.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: 
>> Michel Dänzer <michel@daenzer.net> writes:
>> 
>> > Not sure it's a good idea to set both of these =y: It will prevent the
>> > radeon driver from initializing at all by default if radeonfb is active.
>> 
>> You can say video=radeonfb:off.
>
> I know, I'm referring to the default behaviour without any relevant
> kernel command line options.

Which is exactly the right behaviour for me.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 13:25 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:=20
> >> Michel D=C3=A4nzer <michel@daenzer.net> writes:
> >>=20
> >> > Not sure it's a good idea to set both of these =3Dy: It will prevent=
 the
> >> > radeon driver from initializing at all by default if radeonfb is act=
ive.
> >>=20
> >> You can say video=3Dradeonfb:off.
> >
> > I know, I'm referring to the default behaviour without any relevant
> > kernel command line options.
>=20
> Which is exactly the right behaviour for me.

You do understand that 'prevent the radeon driver from initializing at
all' means direct rendering won't work at all, even with older Mesa
drivers?


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> You do understand that 'prevent the radeon driver from initializing at
> all' means direct rendering won't work at all, even with older Mesa
> drivers?

Until radeondrmfb has suspend support, this is what I want.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > You do understand that 'prevent the radeon driver from initializing at
> > all' means direct rendering won't work at all, even with older Mesa
> > drivers?
>=20
> Until radeondrmfb has suspend support, this is what I want.

Then you could disable CONFIG_DRM_RADEON, or prevent the radeon module
from loading. *shrug*


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote: 
>> Michel Dänzer <michel@daenzer.net> writes:
>> 
>> > You do understand that 'prevent the radeon driver from initializing at
>> > all' means direct rendering won't work at all, even with older Mesa
>> > drivers?
>> 
>> Until radeondrmfb has suspend support, this is what I want.
>
> Then you could disable CONFIG_DRM_RADEON, or prevent the radeon module
> from loading. *shrug*

I have it built-in for easier testing.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> Probably not (AGP is flaky in general, but in particular with older
> UniNorth bridges), but it might be interesting to see some kernel output
> from booting without agpmode=-1. If you can't get it via ssh, maybe you
> can via netconsole or so.

While logging into KDE:

radeon 0000:00:10.0: GPU lockup CP stall for more than 10064msec
GPU lockup (waiting for 0x000003EE last fence id 0x000003ED)
radeon: wait for empty RBBM fifo failed ! Bad things might happen.
Failed to wait GUI idle while programming pipes. Bad things might happen.
radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: GPU reset succeed
radeon 0000:00:10.0: GPU reset succeed
radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: GPU reset succeed
radeon: wait for empty RBBM fifo failed ! Bad things might happen.
Failed to wait GUI idle while programming pipes. Bad things might happen.

After that is is dead.  GPU lockup appears to be a common problem with
the radeon driver.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > Probably not (AGP is flaky in general, but in particular with older
> > UniNorth bridges), but it might be interesting to see some kernel outpu=
t
> > from booting without agpmode=3D-1. If you can't get it via ssh, maybe y=
ou
> > can via netconsole or so.
>=20
> While logging into KDE:
>=20
> radeon 0000:00:10.0: GPU lockup CP stall for more than 10064msec
> GPU lockup (waiting for 0x000003EE last fence id 0x000003ED)
> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
> Failed to wait GUI idle while programming pipes. Bad things might happen.
> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: GPU reset succeed
> radeon 0000:00:10.0: GPU reset succeed
> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: GPU reset succeed
> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
> Failed to wait GUI idle while programming pipes. Bad things might happen.

That's even with agpmode=3D1?

Note that I'm interested in seeing the full dmesg or at least all
agp/drm/radeon related messages.


> After that is is dead.

The whole machine? That's probably due to something going wrong (e.g. an
MCE) while trying to reset the GPU. I fixed one such problem recently,
but it's still not as reliable as on x86 unfortunately.

> GPU lockup appears to be a common problem with the radeon driver.

It's what happens when anything goes wrong with the GPU. If it doesn't
happen with agpmode=3D-1, it's probably an AGP related coherency issue.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
> 
> > GPU lockup appears to be a common problem with the radeon driver.
> 
> It's what happens when anything goes wrong with the GPU. If it doesn't
> happen with agpmode=-1, it's probably an AGP related coherency issue. 

I had some success hacking the DRM to do an in_le32 from the ring head
after writing it. Just a gross hack but it seemed to help on a G5.

I suspect there's a fundamental design issue with apple bridge in that
the CPU to memory path isn't coherent at all with the GPU to memory path
ie. even vs. cache flush instructions (ie buffers in the memory
controllers can still be out of sync).

Darwin does some gross hacks to work around that, some of them visible
in the AGP drivers, some burried in the Apple driver, I don't know for
sure. It's possible that they end up mapping all AGP memory as cache
inhibited, but we can't do that because of our linear mapping.

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 10:02 +0200, Michel D=C3=A4nzer wrote:
> >=20
> > > GPU lockup appears to be a common problem with the radeon driver.
> >=20
> > It's what happens when anything goes wrong with the GPU. If it doesn't
> > happen with agpmode=3D-1, it's probably an AGP related coherency issue.=
=20
>=20
> I had some success hacking the DRM to do an in_le32 from the ring head
> after writing it. Just a gross hack but it seemed to help on a G5.

AFAICT radeon_ring_commit() does that already:

        DRM_MEMORYBARRIER();
        WREG32(ring->wptr_reg, (ring->wptr << ring->ptr_reg_shift) & ring->=
ptr_reg_mask);
        (void)RREG32(ring->wptr_reg);

We added the readback about a decade ago. :)


> I suspect there's a fundamental design issue with apple bridge in that
> the CPU to memory path isn't coherent at all with the GPU to memory path
> ie. even vs. cache flush instructions (ie buffers in the memory
> controllers can still be out of sync).
>=20
> Darwin does some gross hacks to work around that, some of them visible
> in the AGP drivers, some burried in the Apple driver, I don't know for
> sure. It's possible that they end up mapping all AGP memory as cache
> inhibited, but we can't do that because of our linear mapping.

We are doing that though...


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 12:34 +0200, Michel D=C3=A4nzer wrote:=20
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> >=20
> > I suspect there's a fundamental design issue with apple bridge in that
> > the CPU to memory path isn't coherent at all with the GPU to memory pat=
h
> > ie. even vs. cache flush instructions (ie buffers in the memory
> > controllers can still be out of sync).
> >=20
> > Darwin does some gross hacks to work around that, some of them visible
> > in the AGP drivers, some burried in the Apple driver, I don't know for
> > sure. It's possible that they end up mapping all AGP memory as cache
> > inhibited, but we can't do that because of our linear mapping.
>=20
> We are doing that though...

This reminded me, I've been running with the patch below, but I'm not
sure it makes any difference. Maybe Andreas or Jordan can try it.


diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.=
h
index 416e12c..eb34fa5 100644
--- a/arch/powerpc/include/asm/agp.h
+++ b/arch/powerpc/include/asm/agp.h
@@ -2,9 +2,12 @@
 #define _ASM_POWERPC_AGP_H
 #ifdef __KERNEL__
=20
+#include <asm/cacheflush.h>
 #include <asm/io.h>
=20
-#define map_page_into_agp(page)
+#define map_page_into_agp(page)	\
+	flush_dcache_range((unsigned long)page_address(page), \
+			   (unsigned long)page_address(page) + PAGE_SIZE)
 #define unmap_page_from_agp(page)
 #define flush_agp_cache() mb()
=20


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: 
> > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: 
> > > 
> > > I suspect there's a fundamental design issue with apple bridge in that
> > > the CPU to memory path isn't coherent at all with the GPU to memory path
> > > ie. even vs. cache flush instructions (ie buffers in the memory
> > > controllers can still be out of sync).
> > > 
> > > Darwin does some gross hacks to work around that, some of them visible
> > > in the AGP drivers, some burried in the Apple driver, I don't know for
> > > sure. It's possible that they end up mapping all AGP memory as cache
> > > inhibited, but we can't do that because of our linear mapping.
> > 
> > We are doing that though...
> 
> This reminded me, I've been running with the patch below, but I'm not
> sure it makes any difference. Maybe Andreas or Jordan can try it.

It certainly is something we need to do, provided we also know there
will be no subsequent access to that page via a cachable mapping until
it's removed from AGP.

Cheers,
Ben.
> 
> diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h
> index 416e12c..eb34fa5 100644
> --- a/arch/powerpc/include/asm/agp.h
> +++ b/arch/powerpc/include/asm/agp.h
> @@ -2,9 +2,12 @@
>  #define _ASM_POWERPC_AGP_H
>  #ifdef __KERNEL__
>  
> +#include <asm/cacheflush.h>
>  #include <asm/io.h>
>  
> -#define map_page_into_agp(page)
> +#define map_page_into_agp(page)	\
> +	flush_dcache_range((unsigned long)page_address(page), \
> +			   (unsigned long)page_address(page) + PAGE_SIZE)
>  #define unmap_page_from_agp(page)
>  #define flush_agp_cache() mb()
>  
> 
> 

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 21:19 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 12:44 +0200, Michel D=C3=A4nzer wrote:
> > On Mit, 2012-04-18 at 12:34 +0200, Michel D=C3=A4nzer wrote:=20
> > > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> > > >=20
> > > > I suspect there's a fundamental design issue with apple bridge in t=
hat
> > > > the CPU to memory path isn't coherent at all with the GPU to memory=
 path
> > > > ie. even vs. cache flush instructions (ie buffers in the memory
> > > > controllers can still be out of sync).
> > > >=20
> > > > Darwin does some gross hacks to work around that, some of them visi=
ble
> > > > in the AGP drivers, some burried in the Apple driver, I don't know =
for
> > > > sure. It's possible that they end up mapping all AGP memory as cach=
e
> > > > inhibited, but we can't do that because of our linear mapping.
> > >=20
> > > We are doing that though...
> >=20
> > This reminded me, I've been running with the patch below, but I'm not
> > sure it makes any difference. Maybe Andreas or Jordan can try it.
>=20
> It certainly is something we need to do, provided we also know there
> will be no subsequent access to that page via a cachable mapping until
> it's removed from AGP.

TTM should take care of that.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> -#define map_page_into_agp(page)
> +#define map_page_into_agp(page)	\
> +	flush_dcache_range((unsigned long)page_address(page), \
> +			   (unsigned long)page_address(page) + PAGE_SIZE)

That didn't help.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Benjamin Herrenschmidt]

On Wed, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: 
> > On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
> > > 
> > > > GPU lockup appears to be a common problem with the radeon driver.
> > > 
> > > It's what happens when anything goes wrong with the GPU. If it doesn't
> > > happen with agpmode=-1, it's probably an AGP related coherency issue. 
> > 
> > I had some success hacking the DRM to do an in_le32 from the ring head
> > after writing it. Just a gross hack but it seemed to help on a G5.
> 
> AFAICT radeon_ring_commit() does that already:
> 
>         DRM_MEMORYBARRIER();
>         WREG32(ring->wptr_reg, (ring->wptr << ring->ptr_reg_shift) & ring->ptr_reg_mask);
>         (void)RREG32(ring->wptr_reg);
> 
> We added the readback about a decade ago. :)

Hrm, I have a different hack in that old tree I was playing with a while
back, let me see...

--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -2245,6 +2245,9 @@ void radeon_commit_ring(drm_radeon_private_t
*dev_priv)
        DRM_MEMORYBARRIER();
        GET_RING_HEAD( dev_priv );
 
+#ifdef CONFIG_PPC
+       in_be32(dev_priv->ring.start);
+#endif
        if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R600) {


I think that my rational was to ensure that all previous stores to
AGP (indirect buffers etc...) were pushed out & ordered vs the ring
wptr update or something like that, bcs I think those path aren't well
ordered in HW. In fact I suspect we might even need a bigger hammer than
that in_be32().

Another hack I had around was removing the SBA reset from agp-uninorth
completely on binding new pages, it seemed to cause hangs.

> > I suspect there's a fundamental design issue with apple bridge in that
> > the CPU to memory path isn't coherent at all with the GPU to memory path
> > ie. even vs. cache flush instructions (ie buffers in the memory
> > controllers can still be out of sync).
> > 
> > Darwin does some gross hacks to work around that, some of them visible
> > in the AGP drivers, some burried in the Apple driver, I don't know for
> > sure. It's possible that they end up mapping all AGP memory as cache
> > inhibited, but we can't do that because of our linear mapping.
> 
> We are doing that though...

Are we really ? I thought we were taking existing cachable RAM objects
and mapping them into the AGP gart. Are we replacing both kernel & user
mappings for those objects with an equivalent cache inhibited mapping ?

I'm not -that- familiar with how ttm works here. In any case it can
cause bus checkstops because the same pages can be prefetched into the
cache via the linear mapping which is covered by BATs (unless you make
your graphic objects HIGHMEM only but good luck with that :-)

To make that work reliably we should disable the BAT mapping so the
linear mapping can then be controlled on a per-page basis (on 32-bit)
and this is complicated .... we have code that more/less relies on the
BAT mapping being there elsewhere. On 64-bit it's even nastier because
we use 16M pages for the linear mapping.

Cheers,
Ben.

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 21:17 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 12:34 +0200, Michel D=C3=A4nzer wrote:
> > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> > > On Wed, 2012-04-18 at 10:02 +0200, Michel D=C3=A4nzer wrote:
> > > >=20
> > > > > GPU lockup appears to be a common problem with the radeon driver.
> > > >=20
> > > > It's what happens when anything goes wrong with the GPU. If it does=
n't
> > > > happen with agpmode=3D-1, it's probably an AGP related coherency is=
sue.=20
> > >=20
> > > I had some success hacking the DRM to do an in_le32 from the ring hea=
d
> > > after writing it. Just a gross hack but it seemed to help on a G5.
> >=20
> > AFAICT radeon_ring_commit() does that already:
> >=20
> >         DRM_MEMORYBARRIER();
> >         WREG32(ring->wptr_reg, (ring->wptr << ring->ptr_reg_shift) & ri=
ng->ptr_reg_mask);
> >         (void)RREG32(ring->wptr_reg);
> >=20
> > We added the readback about a decade ago. :)
>=20
> Hrm, I have a different hack in that old tree I was playing with a while
> back, let me see...
>=20
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c

Note that radeon_cp.c is UMS code, for KMS you need to look at
radeon_ring.c.

> @@ -2245,6 +2245,9 @@ void radeon_commit_ring(drm_radeon_private_t
> *dev_priv)
>         DRM_MEMORYBARRIER();
>         GET_RING_HEAD( dev_priv );
> =20
> +#ifdef CONFIG_PPC
> +       in_be32(dev_priv->ring.start);
> +#endif
>         if ((dev_priv->flags & RADEON_FAMILY_MASK) >=3D CHIP_R600) {
>=20
>=20
> I think that my rational was to ensure that all previous stores to
> AGP (indirect buffers etc...) were pushed out & ordered vs the ring
> wptr update or something like that, bcs I think those path aren't well
> ordered in HW. In fact I suspect we might even need a bigger hammer than
> that in_be32().

Probably wouldn't hurt trying something like that in the KMS code as
well.


> Another hack I had around was removing the SBA reset from agp-uninorth
> completely on binding new pages, it seemed to cause hangs.

You mean like commit 5613beb46d54da6ef7f1c4589e9f2e60eeb10721? :)


> > > I suspect there's a fundamental design issue with apple bridge in tha=
t
> > > the CPU to memory path isn't coherent at all with the GPU to memory p=
ath
> > > ie. even vs. cache flush instructions (ie buffers in the memory
> > > controllers can still be out of sync).
> > >=20
> > > Darwin does some gross hacks to work around that, some of them visibl=
e
> > > in the AGP drivers, some burried in the Apple driver, I don't know fo=
r
> > > sure. It's possible that they end up mapping all AGP memory as cache
> > > inhibited, but we can't do that because of our linear mapping.
> >=20
> > We are doing that though...
>=20
> Are we really ? I thought we were taking existing cachable RAM objects
> and mapping them into the AGP gart.

No, the radeon driver has always mapped memory uncacheable to the CPU
while it's bound into the AGP GART.

> Are we replacing both kernel & user mappings for those objects with an
> equivalent cache inhibited mapping ?=20
>=20
> I'm not -that- familiar with how ttm works here.

I'm hardly more familiar with how it all works than you. :)

> In any case it can cause bus checkstops because the same pages can be
> prefetched into the cache via the linear mapping which is covered by
> BATs

So you've been saying for about a decade. :) But I've never seen any
problems tracked down to that.

> (unless you make your graphic objects HIGHMEM only but good luck with
> that :-)

FWIW I think TTM indeed prefers highmem pages for GPU access. The radeon
driver normally doesn't need kernel mappings for them.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: 
>> Michel Dänzer <michel@daenzer.net> writes:
>> 
>> > Probably not (AGP is flaky in general, but in particular with older
>> > UniNorth bridges), but it might be interesting to see some kernel output
>> > from booting without agpmode=-1. If you can't get it via ssh, maybe you
>> > can via netconsole or so.
>> 
>> While logging into KDE:
>> 
>> radeon 0000:00:10.0: GPU lockup CP stall for more than 10064msec
>> GPU lockup (waiting for 0x000003EE last fence id 0x000003ED)
>> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
>> Failed to wait GUI idle while programming pipes. Bad things might happen.
>> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: GPU reset succeed
>> radeon 0000:00:10.0: GPU reset succeed
>> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
>> radeon 0000:00:10.0: GPU reset succeed
>> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
>> Failed to wait GUI idle while programming pipes. Bad things might happen.
>
> That's even with agpmode=1?

Yes.  Note that I get pretty far into the login process until the lockup
happens.

> Note that I'm interested in seeing the full dmesg or at least all
> agp/drm/radeon related messages.

This was a test with agpmode=1:

Linux agpgart interface v0.103
agpgart-uninorth 0000:00:0b.0: Apple UniNorth 2 chipset
agpgart-uninorth 0000:00:0b.0: configuring for size idx: 64
agpgart-uninorth 0000:00:0b.0: AGP aperture is 256M @ 0x0
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
radeon 0000:00:10.0: enabling device (0006 -> 0007)
[drm] initializing kernel modesetting (RV350 0x1002:0x4E56 0x1002:0x4E56).
[drm] register mmio base: 0x90000000
[drm] register mmio size: 65536
radeon 0000:00:10.0: Invalid ROM contents
radeon 0000:00:10.0: Invalid ROM contents
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[drm] Using device-tree clock info
[drm] AGP mode requested: 1
agpgart-uninorth 0000:00:0b.0: putting AGP V2 device into 1x mode
radeon 0000:00:10.0: putting AGP V2 device into 1x mode
radeon 0000:00:10.0: GTT: 256M 0x00000000 - 0x0FFFFFFF
[drm] Generation 2 PCI interface, using max accessible memory
radeon 0000:00:10.0: VRAM: 128M 0x0000000098000000 - 0x000000009FFFFFFF (32M used)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 384080 kiB
[TTM] Zone highmem: Available graphics memory: 515152 kiB
[TTM] Initializing pool allocator
[drm] radeon: 32M of VRAM memory ready
[drm] radeon: 256M of GTT memory ready.
[drm] radeon: ib pool ready.
[drm] radeon: 1 quad pipes, 1 Z pipes initialized.
radeon 0000:00:10.0: WB disabled
[drm] fence driver on ring 0 use gpu addr 0x00000000 and cpu addr 0xf1086000
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000000001000
[drm] ring test succeeded in 2 usecs
[drm] ib test succeeded in 0 usecs
[drm] Connector Table: 2 (ibook)
[drm] No panel info found in BIOS
[drm] Panel info derived from registers
[drm] Panel Size 1024x768
[drm] radeon legacy LVDS backlight initialized
[drm] No TV DAC info found in BIOS

>> After that is is dead.

> The whole machine?

No pings any more.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 13:30 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
> > On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:=20
> >> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> This was a test with agpmode=3D1:
>=20
> Linux agpgart interface v0.103
> agpgart-uninorth 0000:00:0b.0: Apple UniNorth 2 chipset
> agpgart-uninorth 0000:00:0b.0: configuring for size idx: 64
> agpgart-uninorth 0000:00:0b.0: AGP aperture is 256M @ 0x0

Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
radeon.test=3D1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)


> >> After that is is dead.
>=20
> > The whole machine?
>=20
> No pings any more.

You might be able to get more information via netconsole. That's how I
tracked down and fixed one cause of MCEs during the GPU reset.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)

Neither changes anything.

> You might be able to get more information via netconsole.

This *is* netconsole.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> > radeon.test=3D1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
>=20
> Neither changes anything.

How small aperture sizes have you tried?

The purpose of radeon.test=3D1 isn't to change anything but to catch
problems transferring data between system memory bound via AGP GART and
video RAM. Does it pass for the whole AGP aperture?


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

Michel Dänzer <michel@daenzer.net> writes:

> On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
>> Michel Dänzer <michel@daenzer.net> writes:
>> 
>> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
>> > radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
>> 
>> Neither changes anything.
>
> How small aperture sizes have you tried?

32M. With the old UMS driver 3D once worked fine ...

> The purpose of radeon.test=1 isn't to change anything but to catch
> problems transferring data between system memory bound via AGP GART and
> video RAM. Does it pass for the whole AGP aperture?

AFAICT yes.  For the default 256M it printed "[drm] Tested GTT->VRAM and
VRAM->GTT copy for GTT offset" for every other offset from 0x201000
to 0xfe01000.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:=20
> >> Michel D=C3=A4nzer <michel@daenzer.net> writes:
> >>=20
> >> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> >> > radeon.test=3D1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8=
c)
> >>=20
> >> Neither changes anything.
> >
> > How small aperture sizes have you tried?
>=20
> 32M. With the old UMS driver 3D once worked fine ...

That doesn't necessarily mean much per se, as with UMS memory is only
statically mapped into the AGP GART once (so most of those 32M are
wasted at least most of the time), whereas with KMS it's dynamically
(un)mapped on demand.


> > The purpose of radeon.test=3D1 isn't to change anything but to catch
> > problems transferring data between system memory bound via AGP GART and
> > video RAM. Does it pass for the whole AGP aperture?
>=20
> AFAICT yes.  For the default 256M it printed "[drm] Tested GTT->VRAM and
> VRAM->GTT copy for GTT offset" for every other offset from 0x201000
> to 0xfe01000.

Okay, so apparently there's at least no obvious problem with 256M on
your UniNorth revision either.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Wed, 18 Apr 2012 17:01:20 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Andreas Schwab <schwab@linux-m68k.org>
> CC: o jordan <ojordan12345@hotmail.co.uk>, linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: 
> > Michel Dänzer <michel@daenzer.net> writes:
> > 
> > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
> > >> Michel Dänzer <michel@daenzer.net> writes:
> > >> 
> > >> > Have you tried smaller aperture sizes (uninorth_agp.aperture)
> > >> > and/or radeon.test=1? (See commit
> > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > >> 
> > >> Neither changes anything.
> > >
> > > How small aperture sizes have you tried?
> > 
> > 32M. With the old UMS driver 3D once worked fine ...
> 
> That doesn't necessarily mean much per se, as with UMS memory is only
> statically mapped into the AGP GART once (so most of those 32M are
> wasted at least most of the time), whereas with KMS it's dynamically
> (un)mapped on demand.
That may be a stupid question, but is it allowed (for a DRM client or
whatever does the mapping) to change the content of a page mapped into
the AGP GART or is it necessary to explicitly unmap the page, change its
content and map it again?
I would say it's necessary to unmap the page first (sounds more like
the pci_[un]map_page() approach) - at least when it should work with
non-coherent architectures, too.

Gerhard

PS: Sorry for hijacking the thread. :-)
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:=20
> > > Michel D=C3=A4nzer <michel@daenzer.net> writes:
> > >=20
> > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:=20
> > > >> Michel D=C3=A4nzer <michel@daenzer.net> writes:
> > > >>=20
> > > >> > Have you tried smaller aperture sizes (uninorth_agp.aperture)
> > > >> > and/or radeon.test=3D1? (See commit
> > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > >>=20
> > > >> Neither changes anything.
> > > >
> > > > How small aperture sizes have you tried?
> > >=20
> > > 32M. With the old UMS driver 3D once worked fine ...
> >=20
> > That doesn't necessarily mean much per se, as with UMS memory is only
> > statically mapped into the AGP GART once (so most of those 32M are
> > wasted at least most of the time), whereas with KMS it's dynamically
> > (un)mapped on demand.
> That may be a stupid question, but is it allowed (for a DRM client or
> whatever does the mapping) to change the content of a page mapped into
> the AGP GART or is it necessary to explicitly unmap the page, change its
> content and map it again?

The former.

> I would say it's necessary to unmap the page first (sounds more like
> the pci_[un]map_page() approach) - at least when it should work with
> non-coherent architectures, too.

I'm afraid non-coherent platforms haven't really been a concern yet for
KMS, and always doing the above dance would probably have a significant
performance impact on coherent platforms.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Wed, 18 Apr 2012 18:06:36 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org, schwab@linux-m68k.org, ojordan12345@hotmail.co.uk
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: 
> > > > Michel Dänzer <michel@daenzer.net> writes:
> > > > 
> > > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
> > > > >> Michel Dänzer <michel@daenzer.net> writes:
> > > > >> 
> > > > >> > Have you tried smaller aperture sizes (uninorth_agp.aperture)
> > > > >> > and/or radeon.test=1? (See commit
> > > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > > >> 
> > > > >> Neither changes anything.
> > > > >
> > > > > How small aperture sizes have you tried?
> > > > 
> > > > 32M. With the old UMS driver 3D once worked fine ...
> > > 
> > > That doesn't necessarily mean much per se, as with UMS memory is
> > > only statically mapped into the AGP GART once (so most of those
> > > 32M are wasted at least most of the time), whereas with KMS it's
> > > dynamically (un)mapped on demand.
> > That may be a stupid question, but is it allowed (for a DRM client or
> > whatever does the mapping) to change the content of a page mapped into
> > the AGP GART or is it necessary to explicitly unmap the page, change
> > its content and map it again?
> 
> The former.
I know that the uninorth AGPGART driver does a cache flushing for newly
mapped pages, but is there any code in the driver that handles the
former case (or isn't this necessary on PPC Macs)?

> > I would say it's necessary to unmap the page first (sounds more like
> > the pci_[un]map_page() approach) - at least when it should work with
> > non-coherent architectures, too.
> 
> I'm afraid non-coherent platforms haven't really been a concern yet for
> KMS, and always doing the above dance would probably have a significant
> performance impact on coherent platforms.
Are there any plans for a page flushing API? I suppose that wouldn't
have such a big performance impact on coherent platforms (but probably
an impact on the userspace API).

Thanks!

Gerhard
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:=20
> > > > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:=20
> > > > > Michel D=C3=A4nzer <michel@daenzer.net> writes:
> > > > >=20
> > > > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:=20
> > > > > >> Michel D=C3=A4nzer <michel@daenzer.net> writes:
> > > > > >>=20
> > > > > >> > Have you tried smaller aperture sizes (uninorth_agp.aperture=
)
> > > > > >> > and/or radeon.test=3D1? (See commit
> > > > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > > > >>=20
> > > > > >> Neither changes anything.
> > > > > >
> > > > > > How small aperture sizes have you tried?
> > > > >=20
> > > > > 32M. With the old UMS driver 3D once worked fine ...
> > > >=20
> > > > That doesn't necessarily mean much per se, as with UMS memory is
> > > > only statically mapped into the AGP GART once (so most of those
> > > > 32M are wasted at least most of the time), whereas with KMS it's
> > > > dynamically (un)mapped on demand.
> > > That may be a stupid question, but is it allowed (for a DRM client or
> > > whatever does the mapping) to change the content of a page mapped int=
o
> > > the AGP GART or is it necessary to explicitly unmap the page, change
> > > its content and map it again?
> >=20
> > The former.
> I know that the uninorth AGPGART driver does a cache flushing for newly
> mapped pages,

Ah, right, that probably explains why the map_page_into_agp change
doesn't make any difference.


> but is there any code in the driver that handles the former case (or
> isn't this necessary on PPC Macs)?

If by 'former case' you mean userspace modifying memory mapped into the
AGP GART, then no, this generally doesn't require special treatment on
PowerMacs. (Ignoring the potential issue mentioned by Ben in this
thread)


> > > I would say it's necessary to unmap the page first (sounds more like
> > > the pci_[un]map_page() approach) - at least when it should work with
> > > non-coherent architectures, too.
> >=20
> > I'm afraid non-coherent platforms haven't really been a concern yet for
> > KMS, and always doing the above dance would probably have a significant
> > performance impact on coherent platforms.
> Are there any plans for a page flushing API? I suppose that wouldn't
> have such a big performance impact on coherent platforms (but probably
> an impact on the userspace API).

Not that I know of.

Note that this isn't necessarily the only possible approach for
addressing this problem. The driver knows which memory buffers are used
by a GPU command stream sequence, so it should be able to take any
measures necessary to ensure the device sees their contents as of when
the command stream was submitted.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Thu, 19 Apr 2012 08:32:51 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: ojordan12345@hotmail.co.uk, schwab@linux-m68k.org, linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: 
> > > > > > Michel Dänzer <michel@daenzer.net> writes:
> > > > > > 
> > > > > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
> > > > > > >> Michel Dänzer <michel@daenzer.net> writes:
> > > > > > >> 
> > > > > > >> > Have you tried smaller aperture sizes
> (uninorth_agp.aperture)
> > > > > > >> > and/or radeon.test=1? (See commit
> > > > > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > > > > >> 
> > > > > > >> Neither changes anything.
> > > > > > >
> > > > > > > How small aperture sizes have you tried?
> > > > > > 
> > > > > > 32M. With the old UMS driver 3D once worked fine ...
> > > > > 
> > > > > That doesn't necessarily mean much per se, as with UMS memory is
> > > > > only statically mapped into the AGP GART once (so most of those
> > > > > 32M are wasted at least most of the time), whereas with KMS it's
> > > > > dynamically (un)mapped on demand.
> > > > That may be a stupid question, but is it allowed (for a DRM client
> > > > or whatever does the mapping) to change the content of a page
> > > > mapped into the AGP GART or is it necessary to explicitly unmap
> > > > the page, change its content and map it again?
> > > 
> > > The former.
> > I know that the uninorth AGPGART driver does a cache flushing for
> > newly mapped pages,
> 
> Ah, right, that probably explains why the map_page_into_agp change
> doesn't make any difference.
> 
> 
> > but is there any code in the driver that handles the former case (or
> > isn't this necessary on PPC Macs)?
> 
> If by 'former case' you mean userspace modifying memory mapped into the
> AGP GART, then no, this generally doesn't require special treatment on
> PowerMacs. (Ignoring the potential issue mentioned by Ben in this
> thread)
I guess you refer to the ordering issue here.

The "former case" is an explanation, why I see data corruption with my
AGPGART driver (more or less a copy of the uninorth driver) on my
non-coherent platform. There are no cache flushes done for writes to
already mapped pages.
I tested this with radeon.test=1, but I'm not even sure if this code
changes already mapped pages (all of this makes it hard to tell for
me whether I stumble over a severe hardware error and/or a "simple"
coherency problem).

> > > > I would say it's necessary to unmap the page first (sounds more
> > > > like the pci_[un]map_page() approach) - at least when it should
> > > > work with non-coherent architectures, too.
> > > 
> > > I'm afraid non-coherent platforms haven't really been a concern yet
> > > for KMS, and always doing the above dance would probably have a
> > > significant performance impact on coherent platforms.
> > Are there any plans for a page flushing API? I suppose that wouldn't
> > have such a big performance impact on coherent platforms (but probably
> > an impact on the userspace API).
> 
> Not that I know of.
> 
> Note that this isn't necessarily the only possible approach for
> addressing this problem. The driver knows which memory buffers are used
> by a GPU command stream sequence, so it should be able to take any
> measures necessary to ensure the device sees their contents as of when
> the command stream was submitted.
Good to hear! Anyway the TTM backend and the KMS drivers are a way
too complex for me so that I can only hope there will be a solution
for non-coherent platforms someday. :-)

Thanks for the clarification!

Gerhard
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote:=20
> > > > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:=20
> > > > >=20
> > > > > That may be a stupid question, but is it allowed (for a DRM clien=
t
> > > > > or whatever does the mapping) to change the content of a page
> > > > > mapped into the AGP GART or is it necessary to explicitly unmap
> > > > > the page, change its content and map it again?
> > > >=20
> > > > The former.
> > > I know that the uninorth AGPGART driver does a cache flushing for
> > > newly mapped pages, but is there any code in the driver that handles=
=20
> > > the former case (or isn't this necessary on PPC Macs)?
> >=20
> > If by 'former case' you mean userspace modifying memory mapped into the
> > AGP GART, then no, this generally doesn't require special treatment on
> > PowerMacs. (Ignoring the potential issue mentioned by Ben in this
> > thread)
> I guess you refer to the ordering issue here.

Yeah.

> The "former case" is an explanation, why I see data corruption with my
> AGPGART driver (more or less a copy of the uninorth driver) on my
> non-coherent platform. There are no cache flushes done for writes to
> already mapped pages.

As I said, the radeon driver always maps AGP memory uncacheable for the
CPU, so no such CPU cache flushes should be necessary.

> I tested this with radeon.test=3D1, but I'm not even sure if this code
> changes already mapped pages [...]

It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer
memory into the AGP GART, and the test only maps it to the CPU after
that.

I take it the test fails for you? How exactly?


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Andreas Schwab]

FWIW, I just got a GPU lockup also in PCI mode, but at least it isn't as
fatal (system still up apart from the unusable X display).

radeon 0000:00:10.0: GPU lockup CP stall for more than 10000msec
GPU lockup (waiting for 0x00000C3C last fence id 0x00000C34)
Failed to wait GUI idle while programming pipes. Bad things might happen.
radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x84110140
radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x80010140
radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x00000140
radeon 0000:00:10.0: GPU reset succeed
radeon 0000:00:10.0: GPU reset succeed
[drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[drm] PCIE GART of 512M enabled (table at 0x0000000002C00000).
radeon 0000:00:10.0: WB enabled
[drm] fence driver on ring 0 use gpu addr 0x78000000 and cpu addr 0xefac7000
[drm] radeon: ring at 0x0000000078001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEA
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:00:10.0: failed initializing CP (-22).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Thu, 19 Apr 2012 14:41:16 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org, schwab@linux-m68k.org, ojordan12345@hotmail.co.uk
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
> > > > > > 
> > > > > > That may be a stupid question, but is it allowed (for a DRM
> > > > > > client or whatever does the mapping) to change the content of
> > > > > > a page mapped into the AGP GART or is it necessary to
> > > > > > explicitly unmap the page, change its content and map it again?
> > > > > 
> > > > > The former.
> > > > I know that the uninorth AGPGART driver does a cache flushing for
> > > > newly mapped pages, but is there any code in the driver that
> > > > handles the former case (or isn't this necessary on PPC Macs)?
> > > 
> > > If by 'former case' you mean userspace modifying memory mapped into
> > > the AGP GART, then no, this generally doesn't require special
> > > treatment on PowerMacs. (Ignoring the potential issue mentioned by
> > > Ben in this thread)
> > I guess you refer to the ordering issue here.
> 
> Yeah.
> 
> > The "former case" is an explanation, why I see data corruption with my
> > AGPGART driver (more or less a copy of the uninorth driver) on my
> > non-coherent platform. There are no cache flushes done for writes to
> > already mapped pages.
> 
> As I said, the radeon driver always maps AGP memory uncacheable for the
> CPU, so no such CPU cache flushes should be necessary.
I know. We also discussed this topic over two years ago. :-)

What I didn't understand yet is how this uncacheable memory is allocated
(well, I never took the time to look at this again). The functions in
ttm_page_alloc.c seem to allocate normal cacheable memory and try to set
the page flags with set_pages_array_uc(), which is more or less a no-op
on powerpc. ttm_page_alloc_dma.c on the other side is only used with
SWIOTLB!?

> > I tested this with radeon.test=1, but I'm not even sure if this code
> > changes already mapped pages [...]
> 
> It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer
> memory into the AGP GART, and the test only maps it to the CPU after
> that.
Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/
ttm_bo_kmap()/..some other TTM functions../vmap()?

> I take it the test fails for you? How exactly?
I didn't work on the driver for a long time. It looks like I did the last
tests with a 2.6.39 kernel, where I changed the radeon test routine to not
stop on a failed copy. This way I could check for a pattern in the failed
copies.

Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code changed
in the meantime so I guess it would make sense to repeat it with a newer
kernel version.

[    5.185619] calling  agp_init+0x0/0x5c @ 1
[    5.189816] Linux agpgart interface v0.103
[    5.193993] initcall agp_init+0x0/0x5c returned 0 after 4076 usecs
[    5.200359] calling  agp_articias_init+0x0/0x58 @ 1
[    5.205411] agpgart-articias 0000:00:00.0: MAI Logic Articia S chipset
[    5.213555] agpgart-articias 0000:00:00.0: configuring for size idx: 6
[    5.220996] agpgart-articias 0000:00:00.0: AGP aperture is 128M @ 0xc0000000
[    5.228557] initcall agp_articias_init+0x0/0x58 returned 0 after 22629 usecs
[    5.235791] calling  drm_core_init+0x0/0x16c @ 1
[    5.240839] [drm] Initialized drm 1.1.0 20060810
[    5.245623] initcall drm_core_init+0x0/0x16c returned 0 after 4937 usecs
[    5.252510] calling  ttm_init+0x0/0x8c @ 1
[    5.256908] initcall ttm_init+0x0/0x8c returned 0 after 197 usecs
[    5.263172] calling  radeon_init+0x0/0x11c @ 1
[    5.267731] [drm] radeon kernel modesetting enabled.
[    5.274683] [drm] initializing kernel modesetting (RV280 0x1002:0x5960).
[    5.281657] [drm] register mmio base: 0x88000000
[    5.286397] [drm] register mmio size: 65536
[    5.327510] [drm] AGP mode requested: 1
[    5.331485] agpgart-articias 0000:00:00.0: AGP 1.0 bridge
[    5.337071] agpgart-articias 0000:00:00.0: putting AGP V2 device into 1x mode
[    5.344440] radeon 0000:01:00.0: putting AGP V2 device into 1x mode
[    5.350865] radeon 0000:01:00.0: GTT: 128M 0xC0000000 - 0xC7FFFFFF
[    5.357197] [drm] Generation 2 PCI interface, using max accessible memory
[    5.364111] radeon 0000:01:00.0: VRAM: 256M 0x0000000080000000 - 0x000000008FFFFFFF (256M used)
[    5.373060] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    5.379815] [drm] Driver supports precise vblank timestamp query.
[    5.386068] [drm] radeon: irq initialized.
[    5.390264] [drm] Detected VRAM RAM=256M, BAR=128M
[    5.395177] [drm] RAM width 128bits DDR
[    5.399322] [TTM] Zone  kernel: Available graphics memory: 380684 kiB.
[    5.406047] [TTM] Zone highmem: Available graphics memory: 773900 kiB.
[    5.412725] [TTM] Initializing pool allocator.
[    5.417395] [drm] radeon: 256M of VRAM memory ready
[    5.422442] [drm] radeon: 128M of GTT memory ready.
[    5.428527] agpgart-articias 0000:00:00.0: TLB flush!
[    5.433785] radeon 0000:01:00.0: WB disabled
[    5.438671] [drm] Loading R200 Microcode
[    5.444292] agpgart-articias 0000:00:00.0: TLB flush!
[    5.449629] [drm] radeon: ring at 0x00000000C0001000
[    5.454761] [drm] ring test succeeded in 0 usecs
[    5.460620] agpgart-articias 0000:00:00.0: TLB flush!
[    5.465889] [drm] radeon: ib pool ready.
[    5.470212] [drm] ib test succeeded in 0 usecs
[    5.475939] agpgart-articias 0000:00:00.0: TLB flush!
[    5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
[    5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
[    5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
[    5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
[    5.541777] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326170 (GTT map 0xf1326000-0xf1426000)
[    5.554535] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326174 (GTT map 0xf1326000-0xf1426000)
[    5.567303] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326178 (GTT map 0xf1326000-0xf1426000)
[    5.580049] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132617c (GTT map 0xf1326000-0xf1426000)
[    5.592843] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326180 (GTT map 0xf1326000-0xf1426000)
[    5.605652] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326184 (GTT map 0xf1326000-0xf1426000)
[    5.618392] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326188 (GTT map 0xf1326000-0xf1426000)
[    5.631178] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132618c (GTT map 0xf1326000-0xf1426000)
[    5.643970] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326190 (GTT map 0xf1326000-0xf1426000)
[    5.656769] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326194 (GTT map 0xf1326000-0xf1426000)
[    5.669494] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326198 (GTT map 0xf1326000-0xf1426000)
[    5.682293] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132619c (GTT map 0xf1326000-0xf1426000)
[    5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
[    5.891734] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec4, expected 0xf1570ec4 (VRAM map 0xf1480000-0xf1580000)
[    5.904616] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec8, expected 0xf1570ec8 (VRAM map 0xf1480000-0xf1580000)
[    5.917460] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ecc, expected 0xf1570ecc (VRAM map 0xf1480000-0xf1580000)
[    5.930286] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed0, expected 0xf1570ed0 (VRAM map 0xf1480000-0xf1580000)
[    5.943164] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed4, expected 0xf1570ed4 (VRAM map 0xf1480000-0xf1580000)
[    5.956052] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed8, expected 0xf1570ed8 (VRAM map 0xf1480000-0xf1580000)
[    5.968898] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416edc, expected 0xf1570edc (VRAM map 0xf1480000-0xf1580000)
[    5.981758] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee0, expected 0xf1570ee0 (VRAM map 0xf1480000-0xf1580000)
[    5.994593] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee4, expected 0xf1570ee4 (VRAM map 0xf1480000-0xf1580000)
[    6.007455] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee8, expected 0xf1570ee8 (VRAM map 0xf1480000-0xf1580000)
[    6.020309] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416eec, expected 0xf1570eec (VRAM map 0xf1480000-0xf1580000)
[    6.033208] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef0, expected 0xf1570ef0 (VRAM map 0xf1480000-0xf1580000)
[    6.046077] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef4, expected 0xf1570ef4 (VRAM map 0xf1480000-0xf1580000)
[    6.058964] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef8, expected 0xf1570ef8 (VRAM map 0xf1480000-0xf1580000)
[    6.071850] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416efc, expected 0xf1570efc (VRAM map 0xf1480000-0xf1580000)

For the GTT->VRAM copy it looks like the AGPGART driver at least
gets the graphics aperture translation table right, as both the
returned and expected values are within a page. But the page offset
of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
fooled by a hardware bug or a cache coherency problem.
The VRAM->GTT copy totally puzzles me, as it returns a wrong page
address, but the offset is fine!?

br,
Gerhard

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:=20
> > >=20
> > > The "former case" is an explanation, why I see data corruption with m=
y
> > > AGPGART driver (more or less a copy of the uninorth driver) on my
> > > non-coherent platform. There are no cache flushes done for writes to
> > > already mapped pages.
> >=20
> > As I said, the radeon driver always maps AGP memory uncacheable for the
> > CPU, so no such CPU cache flushes should be necessary.
> I know. We also discussed this topic over two years ago. :-)
>=20
> What I didn't understand yet is how this uncacheable memory is allocated
> (well, I never took the time to look at this again). The functions in
> ttm_page_alloc.c seem to allocate normal cacheable memory and try to set
> the page flags with set_pages_array_uc(), which is more or less a no-op
> on powerpc.
> ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!?
[...]=20
> Could it be that the memory is finally mapped uncacheable by radeon_bo_km=
ap()/
> ttm_bo_kmap()/..some other TTM functions../vmap()?

Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
and vmap() is used to enforce them for kernel mappings.


> Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code change=
d
> in the meantime so I guess it would make sense to repeat it with a newer
> kernel version.

I was going to suggest that. :)

> [    5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
> [    5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
> [    5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
> [    5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
[...]=20
> [    5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0=
: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)

> For the GTT->VRAM copy it looks like the AGPGART driver at least
> gets the graphics aperture translation table right, as both the
> returned and expected values are within a page. But the page offset
> of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
> fooled by a hardware bug or a cache coherency problem.

Hard to say... at least it managed to transfer the first 352 bytes
correctly. ;)

> The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> address, but the offset is fine!?

Maybe it's still the values from the GTT->VRAM test, i.e. either the GPU
writes didn't make it to the memory mapped into the AGP GART (some AGP
bridges are known to have issues with that) or the CPU doesn't see it.

BTW, does your driver set cant_use_aperture, or is the linear aperture
accessible by the CPU?


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Fri, 20 Apr 2012 15:18:16 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
> > > > 
> > > > The "former case" is an explanation, why I see data corruption
> > > > with my< AGPGART driver (more or less a copy of the uninorth
> > > > driver) on my non-coherent platform. There are no cache flushes
> > > > done for writes to already mapped pages.
> > > 
> > > As I said, the radeon driver always maps AGP memory uncacheable for
> > > the CPU, so no such CPU cache flushes should be necessary.
> > I know. We also discussed this topic over two years ago. :-)
> > 
> > What I didn't understand yet is how this uncacheable memory is
> > allocated (well, I never took the time to look at this again). The
> > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > memory and try to set the page flags with set_pages_array_uc(),
> > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > the other side is only used with SWIOTLB!?
> [...] 
> > Could it be that the memory is finally mapped uncacheable by
> radeon_bo_kmap()/
> > ttm_bo_kmap()/..some other TTM functions../vmap()?
> 
> Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
> and vmap() is used to enforce them for kernel mappings.
Okay, that sounds like the approach used by arch/powerpc/mm/dma-
noncoherent.c in my ("green") ears. What about the PCIGART mode?
Is the driver free to use cached memory in this mode?

> > Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code
> > changed in the meantime so I guess it would make sense to repeat it
> > with a newer kernel version.
> 
> I was going to suggest that. :)
As expected. :-)

> > [    5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
> > [    5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
> > [    5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
> > [    5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
> [...] 
> > [    5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
> 
> > For the GTT->VRAM copy it looks like the AGPGART driver at least
> > gets the graphics aperture translation table right, as both the
> > returned and expected values are within a page. But the page offset
> > of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
> > fooled by a hardware bug or a cache coherency problem.
> 
> Hard to say... at least it managed to transfer the first 352 bytes
> correctly. ;)
Better than nothing! :-)

> > The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> > address, but the offset is fine!?
> 
> Maybe it's still the values from the GTT->VRAM test, i.e. either the GPU
> writes didn't make it to the memory mapped into the AGP GART (some AGP
Good point. Maybe I should explicitly clear the gtt_map before the
VRAM->GTT copy test is executed.

> bridges are known to have issues with that) or the CPU doesn't see it.
What is the workaround for such an AGP bridge? If there is one at all...

> BTW, does your driver set cant_use_aperture, or is the linear aperture
> accessible by the CPU?
The driver sets cant_use_aperture. I couldn't get it working at all
without it.

regards,
Gerhard
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:=20
> > > > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > > > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:=20
> > > > >=20
> > > > > The "former case" is an explanation, why I see data corruption
> > > > > with my< AGPGART driver (more or less a copy of the uninorth
> > > > > driver) on my non-coherent platform. There are no cache flushes
> > > > > done for writes to already mapped pages.
> > > >=20
> > > > As I said, the radeon driver always maps AGP memory uncacheable for
> > > > the CPU, so no such CPU cache flushes should be necessary.
> > > I know. We also discussed this topic over two years ago. :-)
> > >=20
> > > What I didn't understand yet is how this uncacheable memory is
> > > allocated (well, I never took the time to look at this again). The
> > > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > > memory and try to set the page flags with set_pages_array_uc(),
> > > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > > the other side is only used with SWIOTLB!?
> > [...]=20
> > > Could it be that the memory is finally mapped uncacheable by
> > radeon_bo_kmap()/
> > > ttm_bo_kmap()/..some other TTM functions../vmap()?
> >=20
> > Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
> > and vmap() is used to enforce them for kernel mappings.
> Okay, that sounds like the approach used by arch/powerpc/mm/dma-
> noncoherent.c in my ("green") ears. What about the PCIGART mode?
> Is the driver free to use cached memory in this mode?

Yes, it assumes PCI(e) GART to be CPU cache coherent.


> > > [    5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT co=
py 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
> > [...]
> > > The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> > > address, but the offset is fine!?
> >=20
> > Maybe it's still the values from the GTT->VRAM test, i.e. either the GP=
U
> > writes didn't make it to the memory mapped into the AGP GART (some AGP
> > bridges are known to have issues with that) or the CPU doesn't see it.
> What is the workaround for such an AGP bridge? If there is one at all...

The only workaround short of not using AGP would be not doing GPU->AGP
transfers, but that's not implemented or even planned at all.


> > BTW, does your driver set cant_use_aperture, or is the linear aperture
> > accessible by the CPU?
> The driver sets cant_use_aperture. I couldn't get it working at all
> without it.

Does the hardware really not allow the CPU to access the linear aperture
though? Because if it does, I wonder if that might be more reliable.


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Mon, 23 Apr 2012 11:56:06 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: 
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
> > > > > > 
> > > > > > The "former case" is an explanation, why I see data corruption
> > > > > > with my< AGPGART driver (more or less a copy of the uninorth
> > > > > > driver) on my non-coherent platform. There are no cache
> > > > > > flushes done for writes to already mapped pages.
> > > > > 
> > > > > As I said, the radeon driver always maps AGP memory uncacheable
> > > > > for the CPU, so no such CPU cache flushes should be necessary.
> > > > I know. We also discussed this topic over two years ago. :-)
> > > > 
> > > > What I didn't understand yet is how this uncacheable memory is
> > > > allocated (well, I never took the time to look at this again). The
> > > > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > > > memory and try to set the page flags with set_pages_array_uc(),
> > > > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > > > the other side is only used with SWIOTLB!?
> > > [...] 
> > > > Could it be that the memory is finally mapped uncacheable by
> > > radeon_bo_kmap()/
> > > > ttm_bo_kmap()/..some other TTM functions../vmap()?
> > > 
> > > Yeah, AFAICT, basically ttm_io_prot() defines the mapping
> > > attributes, and vmap() is used to enforce them for kernel mappings.
> > Okay, that sounds like the approach used by arch/powerpc/mm/dma-
> > noncoherent.c in my ("green") ears. What about the PCIGART mode?
> > Is the driver free to use cached memory in this mode?
> 
> Yes, it assumes PCI(e) GART to be CPU cache coherent.
Okay. I guess it should be possible to modify it so that it makes use
of uncacheable memory - just for testing!?
PCIGART was working "somehow" on my platform up to the ~2.6.39 kernel,
i.e. I could login to GNOME and open a program until the machine
locked-up. :-)

> > > > [    5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
> > > [...]
> > > > The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> > > > address, but the offset is fine!?
> > > 
> > > Maybe it's still the values from the GTT->VRAM test, i.e. either
> > > the GPU writes didn't make it to the memory mapped into the AGP
That's indeed the case. I changed the code so that gtt_map is
reinitialized with some magic value before the VRAM->GTT copy and the
debug output shows that the GPU writes don't make it to the memory -
or they are going to the wrong memory location, but that's harder to
track.

> > > GART (some AGP bridges are known to have issues with that) or the
> > > CPU doesn't see it.
> > What is the workaround for such an AGP bridge? If there is one at
> > all...
> 
> The only workaround short of not using AGP would be not doing GPU->AGP
> transfers, but that's not implemented or even planned at all.
Okay.

> > > BTW, does your driver set cant_use_aperture, or is the linear
> > > aperture accessible by the CPU?
> > The driver sets cant_use_aperture. I couldn't get it working at all
> > without it.
> 
> Does the hardware really not allow the CPU to access the linear aperture
> though? Because if it does, I wonder if that might be more reliable.
I'm afraid no, but I could try it out again.

BTW: I see that the uninorth driver defines needs_scratch_page. What
is this actually good for?

Thanks!
Gerhard
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote:
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:=20
> > > > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > > > On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:=20
> > > > >=20
> > > > > What I didn't understand yet is how this uncacheable memory is
> > > > > allocated (well, I never took the time to look at this again). Th=
e
> > > > > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > > > > memory and try to set the page flags with set_pages_array_uc(),
> > > > > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > > > > the other side is only used with SWIOTLB!?
> > > > [...]=20
> > > > > Could it be that the memory is finally mapped uncacheable by
> > > > radeon_bo_kmap()/
> > > > > ttm_bo_kmap()/..some other TTM functions../vmap()?
> > > >=20
> > > > Yeah, AFAICT, basically ttm_io_prot() defines the mapping
> > > > attributes, and vmap() is used to enforce them for kernel mappings.
> > > Okay, that sounds like the approach used by arch/powerpc/mm/dma-
> > > noncoherent.c in my ("green") ears. What about the PCIGART mode?
> > > Is the driver free to use cached memory in this mode?
> >=20
> > Yes, it assumes PCI(e) GART to be CPU cache coherent.
> Okay. I guess it should be possible to modify it so that it makes use
> of uncacheable memory - just for testing!?

Sure. Just set man->available_caching and man->default_caching as in the
AGP case in radeon_init_mem_type().=20

> PCIGART was working "somehow" on my platform up to the ~2.6.39 kernel,
> i.e. I could login to GNOME and open a program until the machine
> locked-up. :-)

But it's worse with newer kernels?


> BTW: I see that the uninorth driver defines needs_scratch_page. What
> is this actually good for?

It causes the code in drivers/char/agp/backend.c to allocate a scratch
page (bridge->scratch_page) which the driver can use for unused GART
entries.=20


--=20
Earthling Michel D=C3=A4nzer           |                   http://www.amd.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Tue, 24 Apr 2012 16:15:00 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote:
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: 
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > [...] 
> > > > > > Could it be that the memory is finally mapped uncacheable by
> > > > > > radeon_bo_kmap()/ttm_bo_kmap()/..some other TTM
> > > > > > functions../vmap()?
> > > > > 
> > > > > Yeah, AFAICT, basically ttm_io_prot() defines the mapping
> > > > > attributes, and vmap() is used to enforce them for kernel
> > > > > mappings.
> > > > Okay, that sounds like the approach used by arch/powerpc/mm/dma-
> > > > noncoherent.c in my ("green") ears. What about the PCIGART mode?
> > > > Is the driver free to use cached memory in this mode?
> > > 
> > > Yes, it assumes PCI(e) GART to be CPU cache coherent.
> > Okay. I guess it should be possible to modify it so that it makes use
> > of uncacheable memory - just for testing!?
> 
> Sure. Just set man->available_caching and man->default_caching as in the
> AGP case in radeon_init_mem_type(). 
Thanks for the info! I'll play around with it.

> > PCIGART was working "somehow" on my platform up to the ~2.6.39 kernel,
> > i.e. I could login to GNOME and open a program until the machine
> > locked-up. :-)
> 
> But it's worse with newer kernels?
Yes, it's worse. But that's surely the fault of the buggy northbridge.
I believe the bridge doesn't like some of the code that the driver uses
to avoid ordering issues. But I still have to find out where the lockups
exactly happen.

> > BTW: I see that the uninorth driver defines needs_scratch_page. What
> > is this actually good for?
> 
> It causes the code in drivers/char/agp/backend.c to allocate a scratch
> page (bridge->scratch_page) which the driver can use for unused GART
> entries.
Okay, so it would make sense to set this for my platform's AGP bridge,
which doesn't seem to support a "GATT entry valid" bit.

Gerhard
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de