On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote: > Alex, > > 09.09.2013, в 21:43, Alex Deucher <alexdeucher@xxxxxxxxx> написал(а): > > > On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@xxxxxxxxx> 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@xxxxxxxxx>: > >> > >> 11.07.2013, 23:48, "Helge Deller" <deller@xxxxxx>: > >> > >>> 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@xxxxxxxxx>: > >>>>>> On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> -------- Завершение пересылаемого сообщения -------- > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
