From: Hans Verkuil <hverkuil@xs4all.nl>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: drm/radeon: "ring test failed" on PA-RISC Linux
Date: Tue, 10 Sep 2013 15:03:05 +0200 [thread overview]
Message-ID: <522F1889.7090508@xs4all.nl> (raw)
In-Reply-To: <CADnq5_PpNowLsbNOZufVHuR8M=a4zXZTmJBzG+VtPzR09wSN+g@mail.gmail.com>
On 09/10/2013 02:37 PM, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> Alex,
>>
>> 09.09.2013, в 21:43, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>
>>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>> Folks,
>>>>
>>>> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
>>>> native video options of the latest PA-RISC servers and workstations
>>>> (these are ATIs, most of which are based on R100/R300/R420 chips) work
>>>> correctly on this platform (big endian pa-risc).
>>>>
>>>> However, we hadn't much success. DRM fails every time with
>>>> "ring test failed" for both AGP & PCI.
>>>>
>>>> Maybe you would give us some suggestions that we could check?
>>>>
>>>> Topic started here:
>>>> http://www.spinics.net/lists/linux-parisc/msg04908.html
>>>> And continued there:
>>>> http://www.spinics.net/lists/linux-parisc/msg04995.html
>>>> http://www.spinics.net/lists/linux-parisc/msg05006.html
>>>>
>>>> Problems we've already resolved without any signs of progress:
>>>> - Checked the successful microcode load
>>>> "parisc AGP GART code writes IOMMU entries in the wrong byte order and
>>>> doesn't add the coherency information SBA code adds"
>>>> "our PCI BAR setup doesn't really work very well together with the Radeon
>>>> DRM address setup. DRM will generate addresses, which are even outside
>>>> of the connected LBA"
>>>>
>>>> Things planned for a check:
>>>> "The drivers/video/aty uses
>>>> an endian config bit DRM doesn't use, but I haven't tested whether
>>>> this makes a difference and how it is connected to the overall picture."
>>>
>>> I don't think that will any difference. radeon kms works fine on
>>> other big endian platforms such as powerpc.
>>
>> Good! I'll opt it out then.
Actually, I am experiencing exactly the same problem on a Sam460ex ppc
system, at least as of 3.9 (the last time I tried it).
Very rarely the ringtest would pass, but then it would fail somewhere else.
I never could figure it out since as far as I could tell all the addresses
and logic was correct. It wasn't important enough for me to work more on it,
but I'd be happy to test code. I'm travelling for the next week and a half,
so I can't do anything right now.
One bug I found when working on drm/kms support for the ppc was that in
struct ttm_bus_placement the base address type was wrong: it should be
phys_addr_t, not unsigned long. The PPC460 is in 32-bit mode but physical
addresses are >32 bits.
The patch below fixes that. I always wanted to post this fix, but never got
around to it...
Regards,
Hans
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
arch/powerpc/sysdev/ppc4xx_msi.c | 6 +++---
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 49b0659..fa33568 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1066,7 +1066,7 @@ int radeon_device_init(struct radeon_device *rdev,
if (rdev->rmmio == NULL) {
return -ENOMEM;
}
- DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)rdev->rmmio_base);
+ DRM_INFO("register mmio base: 0x%llx\n", (uint64_t)rdev->rmmio_base);
DRM_INFO("register mmio size: %u\n", (unsigned)rdev->rmmio_size);
/* io port mapping */
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3cb5d84..fcdb208 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -81,7 +81,7 @@ struct ttm_placement {
*/
struct ttm_bus_placement {
void *addr;
- unsigned long base;
+ phys_addr_t base;
unsigned long size;
unsigned long offset;
bool is_iomem;
--
1.7.10.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-09-10 13:14 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 7:11 [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register Helge Deller
2013-06-14 7:28 ` Matt Turner
2013-06-14 7:38 ` Helge Deller
2013-06-14 7:40 ` Helge Deller
2013-06-14 8:38 ` Thomas Bogendoerfer
2013-07-09 5:34 ` Alex Ivanov
2013-07-09 15:18 ` John David Anglin
2013-07-09 19:45 ` Alex Ivanov
2013-07-09 20:59 ` John David Anglin
2013-07-09 23:35 ` John David Anglin
2013-07-10 20:19 ` Alex Ivanov
2013-07-10 20:28 ` John David Anglin
2013-07-10 21:14 ` Matt Turner
2013-07-10 21:29 ` Alex Ivanov
[not found] ` <51DF0B90.3040506@gmx.de>
2013-07-11 19:47 ` Helge Deller
2013-08-04 11:00 ` Alex Ivanov
2013-08-04 15:44 ` John David Anglin
2013-08-04 16:28 ` Matt Turner
2013-08-10 19:41 ` John David Anglin
2013-09-09 16:44 ` drm/radeon: "ring test failed" on PA-RISC Linux Alex Ivanov
2013-09-09 17:43 ` Alex Deucher
2013-09-10 9:20 ` Alex Ivanov
2013-09-10 12:37 ` Alex Deucher
2013-09-10 13:03 ` Hans Verkuil [this message]
2013-09-10 13:25 ` Konrad Rzeszutek Wilk
2013-09-11 11:11 ` Fwd: " Alex Ivanov
2013-09-17 8:13 ` Alex Ivanov
2013-09-17 9:23 ` Alex Ivanov
2013-09-17 14:24 ` Alex Deucher
2013-09-17 19:33 ` Alex Ivanov
2013-09-20 6:52 ` Alex Ivanov
2013-09-20 21:27 ` Alex Deucher
2013-09-21 3:39 ` Alex Ivanov
2013-09-23 20:11 ` Konrad Rzeszutek Wilk
2013-09-25 16:29 ` Alex Ivanov
2013-09-25 17:28 ` Konrad Rzeszutek Wilk
2013-09-25 18:17 ` Alex Deucher
2013-09-25 18:51 ` Alex Ivanov
2013-09-26 8:39 ` Alex Ivanov
2013-09-10 15:45 ` Michel Dänzer
2013-06-14 8:39 ` [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register Thomas Bogendoerfer
2013-06-18 21:21 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=522F1889.7090508@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=alexdeucher@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.