From patchwork Tue Sep 10 09:20:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Ivanov X-Patchwork-Id: 2864431 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B32F69F495 for ; Tue, 10 Sep 2013 09:28:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CBC7020306 for ; Tue, 10 Sep 2013 09:28:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 6603020181 for ; Tue, 10 Sep 2013 09:28:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 76C04E632F for ; Tue, 10 Sep 2013 02:28:43 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org X-Greylist: delayed 449 seconds by postgrey-1.32 at gabe; Tue, 10 Sep 2013 02:28:29 PDT Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [84.201.143.137]) by gabe.freedesktop.org (Postfix) with ESMTP id 1FE88E5C5C for ; Tue, 10 Sep 2013 02:28:29 -0700 (PDT) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward4l.mail.yandex.net (Yandex) with ESMTP id EBE6E1440E02; Tue, 10 Sep 2013 13:20:58 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 9241F16A082E; Tue, 10 Sep 2013 13:20:58 +0400 (MSK) Received: from relay.gero.in (relay.gero.in [77.37.212.15]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id FuXHPjsu08-Kwte2GUO; Tue, 10 Sep 2013 13:20:58 +0400 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: drm/radeon: "ring test failed" on PA-RISC Linux From: Alex Ivanov In-Reply-To: Date: Tue, 10 Sep 2013 13:20:57 +0400 Message-Id: References: <995101375614033@web11d.yandex.ru> <197191378745089@web11j.yandex.ru> To: Alex Deucher X-Mailer: Apple Mail (2.1508) Cc: Maling list - DRI developers X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Alex, 09.09.2013, ? 21:43, Alex Deucher ???????(?): > On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov 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 :( > > Alex > >> >> Thanks. >> >> -------- ???????????? ????????? -------- >> 04.08.2013, 15:06, "Alex Ivanov" : >> >> 11.07.2013, 23:48, "Helge Deller" : >> >>> 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" : >>>>>> On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov 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 --- 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; }