On Tue, 2012-10-23 at 18:42 +1100, Benjamin Herrenschmidt wrote:
As you can see, it's not doing much before the failure:
Allright, that debug output is bad, it's missing a bunch of stuff,
due to a bad log level (the prink(KERN_DEBUG) in the atom debug
stuff doesn't work anymore new kernel btw
Hi Folks !
I've been tracking a problem on POWER server with a CEDAR card (FirePro
2270 X1 server) on a POWER machine.
The cool thing is that our PCI-E bridges fancy error handling is kicking
in and freezing all to that device traffic as soon as the error is
detected. By sprinkling some test
On Tue, 2012-10-23 at 18:54 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2012-10-23 at 18:42 +1100, Benjamin Herrenschmidt wrote:
As you can see, it's not doing much before the failure:
Allright, that debug output is bad, it's missing a bunch of stuff,
due to a bad log level (the prink
On Tue, 2012-10-23 at 21:45 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2012-10-23 at 18:54 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2012-10-23 at 18:42 +1100, Benjamin Herrenschmidt wrote:
As you can see, it's not doing much before the failure:
Allright, that debug output
On Tue, 2012-10-23 at 09:34 -0400, Alex Deucher wrote:
I'll do some more tests tomorrow to confirm whether that is the problem
or not at which point, if it is, we'll need some kind of quirk to
indicate that it supports only MSI32 and not MSI64 or something along
those lines. Guys, go
On Wed, 2012-05-02 at 17:59 +0200, Hans Verkuil wrote:
For the latter, you could try if hacking the driver as described in
http://lists.ozlabs.org/pipermail/linuxppc-dev/2012-April/097668.html
helps.
I tried this but that had no effect that I could see.
For the former, Benjamin
On Mon, 2012-04-16 at 15:39 +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
It was the same code as for RADEON_HOST_DATA_SWAP_32BIT. This caused bus
errors
on FreeBSD/PPC, but I'm not sure how it could not cause problems anywhere...
What kind of bus errors ?
fine on my caicos card on a G5 including some
quik tests with Xv, gnome3 shell, etc...
Thanks a lot to Jerome Glisse for holding my hand through debugging that
(and finding the actual bug).
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/src/evergreen_accel.c b/src
On Thu, 2011-07-14 at 17:19 +0200, Michel Dänzer wrote:
On Mit, 2011-07-13 at 16:28 +1000, Benjamin Herrenschmidt wrote:
The writeback ring pointer and IH ring pointer are read using le32_to_cpu
so we do not want the chip to byteswap them on big-endian.
We still want to byteswap the ring
On Fri, 2011-07-15 at 04:19 +, Matt Turner wrote:
On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
We should have a read memory barrier between reading the WPTR from
memory and reading ring entries based on that value (ie, we need to
ensure both
(Note that this is duplicated under various other names such
as R600_BUF_SWAP_32BIT etc...). At least now all the definitions
agree.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/radeon_reg.h
an explicit one just
in case.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/r600.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b
and the system.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/r600.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm
shifts.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/atombios_crtc.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers
Just defining rdev-rmmio properly in the first place should do
the trick. In some cases, the cast were also complete dups as
the original variable was already of the right type.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit
with the surrounding code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/evergreen.c |3 ---
drivers/gpu/drm/radeon/r600.c |7 ---
drivers/gpu/drm/radeon/r600_cp.c | 23
Hi Alex !
A couple of things I noticed while doing some of the fixes I posted
recently:
- There seem to be what could be a HW issue, I would appreciate if you
could double check with your HW guys, at least on rv610 (I haven't been
able to test on other cards).
When MSI is -disabled- (using old
(Note that this is duplicated under various other names such
as R600_BUF_SWAP_32BIT etc...). At least now all the definitions
agree.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon_reg.h |2 +-
1 files changed, 1 insertions(+), 1 deletions
an explicit one just
in case.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/r600.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 3c86b15..7e5c801 100644
and the system.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/r600.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 7e5c801..25b2dab 100644
--- a/drivers/gpu
Just defining rdev-rmmio properly in the first place should do
the trick. In some cases, the cast were also complete dups as
the original variable was already of the right type.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon.h | 22
with the surrounding code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/evergreen.c |3 ---
drivers/gpu/drm/radeon/r600.c |7 ---
drivers/gpu/drm/radeon/r600_cp.c | 23 +--
3 files changed, 9 insertions(+), 24
On Wed, 2011-07-13 at 10:38 -0400, Alex Deucher wrote:
case 6:
- args.v6.ulCrtcPclkFreq.ucCRTC = crtc_id;
- args.v6.ulCrtcPclkFreq.ulPixelClock =
cpu_to_le32(clock / 10);
+ args.v6.ulDispEngClkFreq =
On Wed, 2011-07-13 at 10:42 -0400, Alex Deucher wrote:
On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
The writeback ring pointer and IH ring pointer are read using le32_to_cpu
so we do not want the chip to byteswap them on big-endian.
We still
On Wed, 2011-07-13 at 10:48 -0400, Alex Deucher wrote:
On Wed, Jul 13, 2011 at 10:43 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
We should have a read memory barrier between reading the WPTR from
On Wed, 2011-07-13 at 11:33 -0400, Alex Deucher wrote:
I'm thinking about instead defining in a .h something like
#ifdef __BIG_ENDIAN
#define CP_RB_SWAP CP_RB_SWAP_32BIT
#else
#define CP_RB_SWAP 0
#endif
And using CP_RB_SWAP everywhere, removing all the dups (which are
Hi !
The radeon driver is storing PCI addresses in unsigned long's which
won't work well on 32-bit platforms with 64-bit physical address space
such as PowerPC 4xx. This fixes it by using unsigned long long instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
index f7ae1a8
Nguyen
-Original Message-
From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 5:38 PM
To: Dave Airlie
Cc: Tai Tri Nguyen; Alex Deucher; xorg-driver-ati@lists.x.org; Tuan
Thanh Phan
Subject: Re: [radeonhd] 0x94CC:0x1545:0x3650: Radeonhd RV610
On Wed, 2008-08-13 at 20:07 +1000, Dave Airlie wrote:
On Wed, Aug 13, 2008 at 7:54 PM, Tai Tri Nguyen [EMAIL PROTECTED] wrote:
Hi Alex,
The driver I'm using is from git, the latest version of xf86-video-ati
git clone
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
I
29 matches
Mail list logo
