* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 15:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m27gxd9jie.fsf@igel.home>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 14:55 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334759498.5989.328.camel@thor.local>
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."
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Add 64-bit CPU targets for gcc
From: Kumar Gala @ 2012-04-18 14:33 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20120418144528.65b70fbb@kryten>
On Apr 17, 2012, at 11:45 PM, Anton Blanchard wrote:
>=20
> Add a menu to select various 64-bit CPU targets for gcc. We
> default to -mtune=3Dpower7 and if gcc doesn't understand that we
> fallback to -mtune=3Dpower4.
>=20
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
Can you add a target for e5500 cpu.
- k
>=20
> Index: linux-build/arch/powerpc/Makefile
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-build.orig/arch/powerpc/Makefile 2012-04-18 =
14:31:31.614666419 +1000
> +++ linux-build/arch/powerpc/Makefile 2012-04-18 14:37:08.680708678 =
+1000
> @@ -69,6 +69,16 @@ LDFLAGS_vmlinux :=3D $(LDFLAGS_vmlinux-y)
>=20
> CFLAGS-$(CONFIG_PPC64) :=3D -mminimal-toc -mtraceback=3Dno =
-mcall-aixdesc
> CFLAGS-$(CONFIG_PPC32) :=3D -ffixed-r2 -mmultiple
> +
> +CFLAGS-$(CONFIG_GENERIC_CPU) +=3D $(call =
cc-option,-mtune=3Dpower7,-mtune=3Dpower4)
> +CFLAGS-$(CONFIG_CELL_CPU) +=3D $(call cc-option,-mcpu=3Dcell)
> +CFLAGS-$(CONFIG_POWER4_CPU) +=3D $(call cc-option,-mcpu=3Dpower4)
> +CFLAGS-$(CONFIG_POWER5_CPU) +=3D $(call cc-option,-mcpu=3Dpower5)
> +CFLAGS-$(CONFIG_POWER6_CPU) +=3D $(call cc-option,-mcpu=3Dpower6)
> +CFLAGS-$(CONFIG_POWER7_CPU) +=3D $(call cc-option,-mcpu=3Dpower7)
> +
> +CFLAGS-$(CONFIG_TUNE_CELL) +=3D $(call cc-option,-mtune=3Dcell)
> +
> KBUILD_CPPFLAGS +=3D -Iarch/$(ARCH)
> KBUILD_AFLAGS +=3D -Iarch/$(ARCH)
> KBUILD_CFLAGS +=3D -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
> @@ -76,22 +86,11 @@ CPP =3D $(CC) -E $(KBUILD_CFLAGS)
>=20
> CHECKFLAGS +=3D -m$(CONFIG_WORD_SIZE) -D__powerpc__ =
-D__powerpc$(CONFIG_WORD_SIZE)__
>=20
> -ifeq ($(CONFIG_PPC64),y)
> -ifeq ($(CONFIG_POWER4_ONLY),y)
> - KBUILD_CFLAGS +=3D $(call cc-option,-mcpu=3Dpower4)
> -else
> - KBUILD_CFLAGS +=3D $(call cc-option,-mtune=3Dpower4)
> -endif
> -endif
> -
> KBUILD_LDFLAGS_MODULE +=3D arch/powerpc/lib/crtsavres.o
>=20
> -ifeq ($(CONFIG_TUNE_CELL),y)
> - KBUILD_CFLAGS +=3D $(call cc-option,-mtune=3Dcell)
> -endif
> -
> -# No AltiVec instruction when building kernel
> +# No AltiVec or VSX instructions when building kernel
> KBUILD_CFLAGS +=3D $(call cc-option,-mno-altivec)
> +KBUILD_CFLAGS +=3D $(call cc-option,-mno-vsx)
>=20
> # No SPE instruction when building kernel
> # (We use all available options to help semi-broken compilers)
> Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype =
2012-04-18 14:31:25.134549903 +1000
> +++ linux-build/arch/powerpc/platforms/Kconfig.cputype =
2012-04-18 14:36:40.576207829 +1000
> @@ -78,6 +78,36 @@ config PPC_BOOK3E_64
>=20
> endchoice
>=20
> +choice
> + prompt "CPU selection"
> + depends on PPC64
> + default GENERIC_CPU
> + help
> + This will create a kernel which is optimised for a particular =
CPU.
> + The resulting kernel may not run on other CPUs, so use this =
with care.
> +
> + If unsure, select Generic.
> +
> +config GENERIC_CPU
> + bool "Generic"
> +
> +config CELL_CPU
> + bool "Cell Broadband Engine"
> +
> +config POWER4_CPU
> + bool "POWER4"
> +
> +config POWER5_CPU
> + bool "POWER5"
> +
> +config POWER6_CPU
> + bool "POWER6"
> +
> +config POWER7_CPU
> + bool "POWER7"
> +
> +endchoice
> +
> config PPC_BOOK3S
> def_bool y
> depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 14:31 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m2bomp9krb.fsf@igel.home>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 14:28 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334756287.5989.326.camel@thor.local>
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."
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
From: Kumar Gala @ 2012-04-18 14:28 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
On Apr 17, 2012, at 11:42 PM, Anton Blanchard wrote:
>=20
> Older versions of gcc had issues with using -maltivec together with
> -mcpu of a non altivec capable CPU. We work around it by specifying
> -mcpu=3D970, but the logic is complicated.
>=20
> In preparation for adding more -mcpu targets, remove the workaround
> and just require gcc 4.0 for 64-bit builds.
>=20
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>=20
> 4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1.
> I highly doubt a ppc64 kernel will build these days on either RHEL4 or
> SLES9.
>=20
> Anything else we have to worry about?
There are probably embedded customers that might utilize older =
compilers, so this concerns me a little.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add back condition for smp
From: Kumar Gala @ 2012-04-18 14:15 UTC (permalink / raw)
To: Scott Wood; +Cc: PPC list, York Sun
In-Reply-To: <4F8DEC0E.4060700@freescale.com>
On Apr 17, 2012, at 5:17 PM, Scott Wood wrote:
> On 04/17/2012 04:39 PM, York Sun wrote:
>> The timebase synchronization is only necessary if we need to reset a
>> separate core. Currently only KEXEC and CPU hotplug require =
resetting
>> a single core. The following code should be in the condition of
>> CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
>>=20
>> .give_timebase =3D smp_generic_give_timebase,
>> .take_timebase =3D smp_generic_take_timebase,
>>=20
>> Signed-off-by: York Sun <yorksun@freescale.com>
>> Acked-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/smp.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/platforms/85xx/smp.c =
b/arch/powerpc/platforms/85xx/smp.c
>> index 56942af..868c6d7 100644
>> --- a/arch/powerpc/platforms/85xx/smp.c
>> +++ b/arch/powerpc/platforms/85xx/smp.c
>> @@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops =3D {
>> .cpu_disable =3D generic_cpu_disable,
>> .cpu_die =3D generic_cpu_die,
>> #endif
>> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
>> .give_timebase =3D smp_generic_give_timebase,
>> .take_timebase =3D smp_generic_take_timebase,
>> +#endif
>> };
>>=20
>> #ifdef CONFIG_KEXEC
>=20
> Note that this is only a temporary fix, that assumes the environments
> where tbsync is problematic[1] (virtualization and simulation) do not
> enable CONFIG_KEXEC or CONFIG_HOTPLUG_CPU. Eventually the sync should
> be done via CCSR like in U-Boot, and the decision on whether to do it
> should be runtime.
Is the thinking with the CCSR like u-boot sync after boot would resync =
to some non-zero TB value?
I'm guessing the idea is doing such a rsync w/TB stopped in the system =
is quick enough that the freezing of it will not be noticed. One should =
measure this and see what it looks like in core cycles and how it scales =
based on # of cores. (could use alternate TB as a counter to measure).
- k=
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 13:47 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334755511.5989.318.camel@thor.local>
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."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:38 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m24nshb7l9.fsf@igel.home>
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
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add back condition for smp
From: Kumar Gala @ 2012-04-18 13:37 UTC (permalink / raw)
To: York Sun; +Cc: linuxppc-dev
In-Reply-To: <1334698746-11529-1-git-send-email-yorksun@freescale.com>
On Apr 17, 2012, at 4:39 PM, York Sun wrote:
> The timebase synchronization is only necessary if we need to reset a
> separate core. Currently only KEXEC and CPU hotplug require resetting
> a single core. The following code should be in the condition of
> CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
>=20
> .give_timebase =3D smp_generic_give_timebase,
> .take_timebase =3D smp_generic_take_timebase,
This doesn't explain why you are putting the #ifdef back, only under =
what conditions it applies.
>=20
> Signed-off-by: York Sun <yorksun@freescale.com>
> Acked-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/platforms/85xx/smp.c =
b/arch/powerpc/platforms/85xx/smp.c
> index 56942af..868c6d7 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops =3D {
> .cpu_disable =3D generic_cpu_disable,
> .cpu_die =3D generic_cpu_die,
> #endif
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
> .give_timebase =3D smp_generic_give_timebase,
> .take_timebase =3D smp_generic_take_timebase,
> +#endif
> };
>=20
> #ifdef CONFIG_KEXEC
> --=20
> 1.7.0.4
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334747877.3143.12.camel@pasglop>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m2k41d9nup.fsf@igel.home>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 13:22 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334754160.5989.305.camel@thor.local>
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."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andreas Schwab, o jordan, linuxppc-dev
In-Reply-To: <1334747941.3143.13.camel@pasglop>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334748206.3143.17.camel@pasglop>
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
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 13:02 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m28vhtb7tc.fsf@igel.home>
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
^ permalink raw reply
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Mauro Carvalho Chehab @ 2012-04-18 12:58 UTC (permalink / raw)
To: Borislav Petkov
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Egor Martovetsky,
Niklas Söderlund, Tim Small, Arvind R., Chris Metcalf,
Olof Johansson, Doug Thompson, Linux Edac Mailing List,
Michal Marek, Jiri Kosina, Linux Kernel Mailing List, Joe Perches,
Andrew Morton, linuxppc-dev
In-Reply-To: <20120417214027.GB15397@aftab>
Em 17-04-2012 18:40, Borislav Petkov escreveu:
> On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
>> Ok. well, we can either multiply nr_pages by channel_count or to let it
>> clear that this is per channel. I prefer the last option (see the enclosed
>> patch).
>>
>>>> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>>>> int i, j, empty = 1;
>>>> enum mem_type mtype;
>>>> enum edac_type edac_mode;
>>>> + int nr_pages;
>>>>
>>>> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>>>>
>>>> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
>>>> i, pvt->mc_node_id);
>>>>
>>>> empty = 0;
>>>> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>>>> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>>>> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
>>>> /* 8 bytes of resolution */
>>>>
>>>> mtype = amd64_determine_memory_type(pvt, i);
>>>>
>>>> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
>>>> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
>>>> + debugf1(" nr_pages: %u\n", nr_pages);
>>>>
>>>> /*
>>>> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
>>>> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>>>> for (j = 0; j < pvt->channel_count; j++) {
>>>> csrow->channels[j].dimm->mtype = mtype;
>>>> csrow->channels[j].dimm->edac_mode = edac_mode;
>>>> + csrow->channels[j].dimm->nr_pages = nr_pages;
>>>
>>> I'm guessing you want to accumulate the nr_pages for all channels here
>>> and dump it properly?
>>>
>>
>> As you've requested to not move the debugf0() to be after the loop, it is
>> easier to just multiply it at the printk. As an advantage, when the kernel
>> is compiled without debug, no code will be produced.
>>
>> IMO, the best way to solve it is with this small patch. If you're ok, I'll
>> fold it with this one and add your ack.
>>
>> Regards,
>> Mauro
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 8804ac8..6d6ec68 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>>
>> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
>> - debugf0(" nr_pages= %u channel-count = %d\n",
>> + debugf0(" nr_pages/channel= %u channel-count = %d\n",
>> nr_pages, pvt->channel_count);
>>
>> return nr_pages;
>> @@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> mtype = amd64_determine_memory_type(pvt, i);
>>
>> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
>> - debugf1(" nr_pages: %u\n", nr_pages);
>> + debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
>>
>> /*
>> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
>
> Yeah, this is basically what the code did anyway, so yes, please fold it
> in and you can add my ACK. I'll continue reviewing the rest tomorrow.
Thanks!
Mauro
>
> Thanks.
>
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 12:49 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334745854.5989.295.camel@thor.local>
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."
^ permalink raw reply
* [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Anton Blanchard @ 2012-04-18 12:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1334732224.1159.4.camel@pasglop>
Remove CONFIG_POWER4_ONLY, the option is badly named and only does two
things:
- It wraps the MMU segment table code. With feature fixups there is
little downside to compiling this in.
- It uses the newer mtocrf instruction in various assembly functions.
Instead of making this a compile option just do it at runtime via
a feature fixup.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v2: Use CPU_FTR_NOEXECUTE to select the newer mtocrf
Index: linux-build/arch/powerpc/configs/g5_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/g5_defconfig 2012-04-18 22:12:59.292790202 +1000
+++ linux-build/arch/powerpc/configs/g5_defconfig 2012-04-18 22:13:13.029035714 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
Index: linux-build/arch/powerpc/configs/maple_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/maple_defconfig 2012-04-18 22:12:59.264789702 +1000
+++ linux-build/arch/powerpc/configs/maple_defconfig 2012-04-18 22:13:13.029035714 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
Index: linux-build/arch/powerpc/configs/pasemi_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/pasemi_defconfig 2012-04-18 22:12:59.280789988 +1000
+++ linux-build/arch/powerpc/configs/pasemi_defconfig 2012-04-18 22:13:13.029035714 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
# CONFIG_VIRT_CPU_ACCOUNTING is not set
CONFIG_SMP=y
Index: linux-build/arch/powerpc/kernel/exceptions-64s.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 22:12:59.252789487 +1000
+++ linux-build/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 22:13:13.029035714 +1000
@@ -94,12 +94,10 @@ machine_check_pSeries_1:
data_access_pSeries:
HMT_MEDIUM
SET_SCRATCH0(r13)
-#ifndef CONFIG_POWER4_ONLY
BEGIN_FTR_SECTION
b data_access_check_stab
data_access_not_stab:
END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
-#endif
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common, EXC_STD,
KVMTEST, 0x300)
@@ -301,7 +299,6 @@ machine_check_fwnmi:
EXC_STD, KVMTEST, 0x200)
KVM_HANDLER_SKIP(PACA_EXMC, EXC_STD, 0x200)
-#ifndef CONFIG_POWER4_ONLY
/* moved from 0x300 */
data_access_check_stab:
GET_PACA(r13)
@@ -328,7 +325,6 @@ do_stab_bolted_pSeries:
GET_SCRATCH0(r10)
std r10,PACA_EXSLB+EX_R13(r13)
EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted, EXC_STD)
-#endif /* CONFIG_POWER4_ONLY */
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_STD, 0x300)
KVM_HANDLER_SKIP(PACA_EXSLB, EXC_STD, 0x380)
Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 22:12:59.312790560 +1000
+++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 22:13:13.029035714 +1000
@@ -116,15 +116,6 @@ config PPC_BOOK3E
def_bool y
depends on PPC_BOOK3E_64
-config POWER4_ONLY
- bool "Optimize for POWER4"
- depends on PPC64 && PPC_BOOK3S
- default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
- The resulting binary will not work on POWER3 or RS64 processors
- when compiled with binutils 2.15 or later.
-
config 6xx
def_bool y
depends on PPC32 && PPC_BOOK3S
Index: linux-build/arch/powerpc/include/asm/asm-compat.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/asm-compat.h 2012-04-18 22:12:59.236789201 +1000
+++ linux-build/arch/powerpc/include/asm/asm-compat.h 2012-04-18 22:13:13.033035785 +1000
@@ -29,18 +29,9 @@
#define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh)
#define PPC_STLCX stringify_in_c(stdcx.)
#define PPC_CNTLZL stringify_in_c(cntlzd)
+#define PPC_MTOCRF(FXM, RS) MTOCRF((FXM), (RS))
#define PPC_LR_STKOFF 16
#define PPC_MIN_STKFRM 112
-
-/* Move to CR, single-entry optimized version. Only available
- * on POWER4 and later.
- */
-#ifdef CONFIG_POWER4_ONLY
-#define PPC_MTOCRF stringify_in_c(mtocrf)
-#else
-#define PPC_MTOCRF stringify_in_c(mtcrf)
-#endif
-
#else /* 32-bit */
/* operations for longs and pointers */
Index: linux-build/arch/powerpc/lib/copyuser_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/copyuser_64.S 2012-04-18 22:12:59.180788200 +1000
+++ linux-build/arch/powerpc/lib/copyuser_64.S 2012-04-18 22:13:13.033035785 +1000
@@ -30,7 +30,7 @@ _GLOBAL(__copy_tofrom_user_base)
dcbt 0,r4
beq .Lcopy_page_4K
andi. r6,r6,7
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
blt cr1,.Lshort_copy
/* Below we want to nop out the bne if we're on a CPU that has the
* CPU_FTR_UNALIGNED_LD_STD bit set and the CPU_FTR_CP_USE_DCBTZ bit
@@ -186,7 +186,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 /* put #bytes to 8B bdry into cr7 */
+ PPC_MTOCRF(0x01,r6) /* put #bytes to 8B bdry into cr7 */
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -201,7 +201,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
37: lwzx r0,r7,r4
83: stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/memcpy_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/memcpy_64.S 2012-04-18 22:12:59.208788700 +1000
+++ linux-build/arch/powerpc/lib/memcpy_64.S 2012-04-18 22:13:13.033035785 +1000
@@ -12,7 +12,7 @@
.align 7
_GLOBAL(memcpy)
std r3,48(r1) /* save destination pointer for return value */
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
andi. r6,r6,7
@@ -154,7 +154,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7
+ PPC_MTOCRF(0x01,r6) # put #bytes to 8B bdry into cr7
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -169,7 +169,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
lwzx r0,r7,r4
stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/mem_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/mem_64.S 2012-04-18 22:12:59.192788415 +1000
+++ linux-build/arch/powerpc/lib/mem_64.S 2012-04-18 22:13:13.033035785 +1000
@@ -19,7 +19,7 @@ _GLOBAL(memset)
rlwimi r4,r4,16,0,15
cmplw cr1,r5,r0 /* do we get that far? */
rldimi r4,r4,32,0
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
mr r6,r3
blt cr1,8f
beq+ 3f /* if already 8-byte aligned */
@@ -49,7 +49,7 @@ _GLOBAL(memset)
bdnz 4b
5: srwi. r0,r5,3
clrlwi r5,r5,29
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
beq 8f
bf 29,6f
std r4,0(r6)
@@ -65,7 +65,7 @@ _GLOBAL(memset)
std r4,0(r6)
addi r6,r6,8
8: cmpwi r5,0
- PPC_MTOCRF 1,r5
+ PPC_MTOCRF(1,r5)
beqlr+
bf 29,9f
stw r4,0(r6)
Index: linux-build/arch/powerpc/include/asm/ppc_asm.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 22:12:59.220788915 +1000
+++ linux-build/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 22:13:13.033035785 +1000
@@ -369,7 +369,15 @@ BEGIN_FTR_SECTION \
END_FTR_SECTION_IFCLR(CPU_FTR_601)
#endif
-
+#ifdef CONFIG_PPC64
+#define MTOCRF(FXM, RS) \
+ BEGIN_FTR_SECTION_NESTED(848); \
+ mtcrf (FXM), (RS); \
+ FTR_SECTION_ELSE_NESTED(848); \
+ mtocrf (FXM), (RS); \
+ ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_NOEXECUTE, 848)
+#endif
+
/*
* This instruction is not implemented on the PPC 603 or 601; however, on
* the 403GCX and 405GP tlbia IS defined and tlbie is not.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 11:30 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334736133.5989.278.camel@thor.local>
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."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 11:25 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334735555.5989.272.camel@thor.local>
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."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 11:23 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334746446.5989.300.camel@thor.local>
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.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 11:19 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Andreas Schwab, o jordan, linuxppc-dev
In-Reply-To: <1334745854.5989.295.camel@thor.local>
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()
>
>
>
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 11:17 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334745292.5989.291.camel@thor.local>
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.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 10:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334745439.3143.5.camel@pasglop>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox