drm/radeon: "ring test failed" on PA-RISC Linux

[Hans Verkuil]

On 09/10/2013 02:37 PM, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah at p0n4ik.tk> wrote:
>> Alex,
>>
>> 09.09.2013, в 21:43, Alex Deucher <alexdeucher at gmail.com> написал(а):
>>
>>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah at 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 at 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