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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov 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.
> 
> > 
> >> 
> >> "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 :(

Is this platform enabling the SWIOTLB layer? The reason I am asking is
b/c if you do indeed enable it you end up using the TTM DMA pool
which allocates pages using the dma_alloc_coherent - which means that
all of the pages that come out of TTM are already 'DMA' mapped.

And that means the radeon_gart_bind and all its friends 
use the DMA addresses that have been constructed by SWIOTLB IOMMU.

Perhaps the PA-RISC IOMMU creates the DMA addresses differently?

When the card gets programmed, you do end up using ttm_agp_bind right?
I am wondering if something like this:

https://lkml.org/lkml/2010/12/6/512

is needed to pass in the right DMA address?

> 
> --- 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@p0n4ik.tk>:
> >> 
> >> 11.07.2013, 23:48, "Helge Deller" <deller@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@gmail.com>:
> >>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@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@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> -------- Завершение пересылаемого сообщения --------
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel