drm/radeon: "ring test failed" on PA-RISC Linux
Alex Ivanov
gnidorah at p0n4ik.tk
Tue Sep 10 02:20:57 PDT 2013
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.
>
>>
>> "The Rage128 product revealed a weakness in some motherboard
>> chipsets in that there is no mechanism to guarantee
>> that data written by the CPU to memory is actually in a readable
>> state before the Graphics Controller receives an
>> update to its copy of the Write Pointer. In an effort to alleviate this
>> problem, we"ve introduced a mechanism into the
>> Graphics Controller that will delay the actual write to the Write Pointer
>> for some programmable amount of time, in
>> order to give the chipset time to flush its internal write buffers to
>> memory.
>> There are two register fields that control this mechanism:
>> PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
>>
>> In the radeon DRM codebase I didn't found anyone using/setting
>> those registers. Maybe PA-RISC has some problem here?..."
>
> I doubt it. If you are using AGP, I'd suggest disabling it and first
> try to get things working using the on chip gart rather than AGP.
> Load radeon with agpmode=-1.
Already tried this without any luck. Anyway, a radeon driver fallbacks
to the PCI mode in our case, so does it really matter?
In addition, people with PCI cards experiencing the same issue...
> The on chip gart always uses cache
> snooped pci transactions and the driver assumes pci is cache coherent.
> On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
> system ram. On PCIE asics, the gart table is stored in vram. The
> gart page table maps system pages to a contiguous aperture in the
> GPU's address space. The ring lives in gart memory. The GPU sees a
> contiguous buffer and the gart mechanism handles the access to the
> backing pages via the page table. I'd suggest verifying that the
> entries written to the gart page table are valid and then the
> information written to the ring buffer is valid before updating the
> ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
> causes the CP to start fetching data from the ring.
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
--- radeon_device.c.orig 2013-09-10 08:55:05.000000000 +0000
+++ radeon_device.c 2013-09-10 09:12:17.000000000 +0000
@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
{
if (rdev->dummy_page.page)
return 0;
- rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
- if (rdev->dummy_page.page == NULL)
+ rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev, PAGE_SIZE,
+ &rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+ if (!rdev->dummy_page.page)
return -ENOMEM;
- rdev->dummy_page.addr = pci_map_page(rdev->pdev, rdev->dummy_page.page,
- 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
dev_err(&rdev->pdev->dev, "Failed to DMA MAP the dummy page\n");
- __free_page(rdev->dummy_page.page);
- rdev->dummy_page.page = NULL;
+ radeon_dummy_page_fini(rdev);
return -ENOMEM;
}
return 0;
@@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
{
if (rdev->dummy_page.page == NULL)
return;
- pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- __free_page(rdev->dummy_page.page);
+ dma_free_coherent(&rdev->pdev->dev, PAGE_SIZE,
+ rdev->dummy_page.page, rdev->dummy_page.addr);
rdev->dummy_page.page = NULL;
}
>
> Alex
>
>>
>> Thanks.
>>
>> -------- Пересылаемое сообщение --------
>> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah at p0n4ik.tk>:
>>
>> 11.07.2013, 23:48, "Helge Deller" <deller at gmx.de>:
>>
>>> adding linux parisc mailing list...:
>>>
>>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>>> On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>> 11.07.2013, 01:14, "Matt Turner" <mattst88 at gmail.com>:
>>>>>> On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah at p0n4ik.tk> wrote:
>>>>>>> Thank you so much! Your guess looks to be right. After applying of your
>>>>>>> patch there was no more KP and X just worked.
>>>>>> Nice! Does DRI work?
>>>>> Not on my side. Plus i can't visually jump over 8bit depth, although Xorg
>>>>> states 24bit in it's log.
>>>>> As for DRI, i'm experiencing
>>>>> "ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.
>>>> FWIW, I'm seeing the same failure on my FireGL X1:
>>>> 80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)
>>>>
>>>> [drm] radeon: irq initialized.
>>>> [drm] Loading R300 Microcode
>>>> [drm] radeon: ring at 0x0000000060001000
>>>> [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
>>>> [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
>>>> radeon 0000:80:00.0: failed initializing CP (-22).
>>>> radeon 0000:80:00.0: Disabling GPU acceleration
>>>> [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
>>>> [drm] radeon: cp finalized
>>>> [drm] radeon: cp finalized
>>
>> I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives?
>> Should we forward this to dri-devel mail list?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> -------- Завершение пересылаемого сообщения --------
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
More information about the dri-devel
mailing list