On Wed, Sep 25, 2013 at 1:28 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote: >> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>: >> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote: >> > >> >> 21.09.2013, в 1:27, Alex Deucher <alexdeucher@xxxxxxxxx> написал(а): >> >>> The register writes seems to be going through the register backbone correctly: >> >>> >> >>> [0x00B] 0x15E0=0x00000000 >> >>> [0x00C] 0x15E4=0xCAFEDEAD >> >>> [0x00D] 0x4274=0x0000000F >> >>> [0x00E] 0x42C8=0x00000007 >> >>> [0x00F] 0x4018=0x0000001D >> >>> [0x010] 0x170C=0x80000000 >> >>> [0x011] 0x3428=0x00020100 >> >>> [0x012] 0x15E4=0xCAFEDEAD >> >>> >> >>> You can see the 0xCAFEDEAD written to the scratch register via MMIO >> >>> from the ring_test(). The CP fifo however seems to be full of garbage. >> >>> The CP is busy though, so it seems to be functional. I guess it's >> >>> just fetching garbage rather than commands. >> > >> > If it is fetching garbage, that would imply the DMA (or bus addresses) >> > that are programmed in the GART are bogus. If you dump them and try >> > to figure out if bus adress -> physical address -> virtual address == >> > virtual address -> bus address that could help. And perhaps seeing what >> > the virtual address has - and or poisoning it with known data? >> > >> > Or perhaps the the card has picked up an incorrect page table? Meaning >> > the (bus) address given to it is not the correct one? >> > >> >> Konrad, >> >> Let's see. Please notice that i'm not PA-RISC or general linux kernel >> developer, just the user, so i may do things completely wrong. >> I was hoping that PA-RISC smarties will join me here, but they seem >> to be busy with other duties. Even port's mail list activity is low >> during last weeks. > > I took a look at the arch/parisc/kernel/pci-dma.c and I see that > is mostly a flat platform. That is bus addresses == physical addresses. > Unless it is an pclx or pclx2 CPU type (huh?) - if its it that > then any calls to dma_alloc_coherent will map memory out of a pool. > In essence it will look like a SWIOTLB bounce buffer. > > But interestingly enough there is a lot of 'flush_kernel_dcache_range' > call for every DMA operation. And I think the you need to do > dma_sync_for_cpu call in the radeon_test_writeback for it to > use the flush_kernel_dcache_range. I don't know what the > flush_kernel_dcache_range does thought so I could be wrong. > > That means you can ignore the little code below I wrote and > see about doing something like this: > > > diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c > index 3cae2bb..9e5923d 100644 > --- a/drivers/gpu/drm/radeon/radeon_cp.c > +++ b/drivers/gpu/drm/radeon/radeon_cp.c > @@ -876,6 +876,7 @@ static void radeon_test_writeback(drm_radeon_private_t * dev_priv) > > RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef); > > + flush_kernel_dcache_range(dev_priv->ring_rptr, PAGE_SIZE); > for (tmp = 0; tmp < dev_priv->usec_timeout; tmp++) { > u32 val; > You'd want to add the add the flush to r100_ring_test() in r100.c. radeon_cp.c is for the old UMS support. Alex > But that is probably a shot in the dark. I have no clue what the flush_.. > is doing. > > [edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver > where bus and physical addresses are different. sigh. What type of machine > is this? Does it have the IOMMU in it?] >> >> > If you dump them and try >> > to figure out if bus adress -> physical address -> virtual address == >> > virtual address -> bus address that could help >> >> With following >> >> radeon/radeon_ttm.c: >> >> radeon_ttm_tt_populate(): >> ... >> for (i = 0; i < ttm->num_pages; i++) { >> gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev, ttm->pages[i], >> 0, PAGE_SIZE, >> PCI_DMA_BIDIRECTIONAL); >> >> void *va = bus_to_virt(gtt->ttm.dma_address[i]); >> if ((phys_addr_t) va != virt_to_bus(va)) { > > You are missing a translation here (you were comparing the virtual address > to the bus address). I was thinking something along this: > > unsigned int pfn = page_to_pfn(ttm->pages[i]); > dma_addr_t bus = gtt->ttm.dma_address[i]; > void *va_bus, *va, *va_pfn; > > if ((pfn << PAGE_SHIFT) != bus) > printk("Bus 0x%lx != PFN 0x%lx, bus, pfn << PAGE_SHIFT); /* OK, that means > bus addresses are different */ > > va_bus = bus_to_virt(gtt->ttm.dma_address[i]); > va_pfn = __va(pfn << PAGE_SHIFT); > > if (!virt_addr_valid(va_bus)) > printk("va_bus (0x%lx) not good!\n", va_bus); > if (!virt_addr_valid(va_pfn)) > printk("va_pfn (0x%lx) not good!\n", va_pfn); > > /* We got VA for both bus -> va, and pfn -> va. Should be the > same if bus and physical addresses are on the same namespace. */ > if (va_bus != va_pfn) > printk("va bus:%lx != va pfn: %lx\n", va_bus, va_pfn); > > /* Now that we have bus -> pa -> va (va_bus) try to go va_bus -> bus address. > The bus address should be the same */ > if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus)) > printk("bus->pa->va:%lx != bus->pa->va->ba: %lx\n", gtt->tmm.dma_address[i],virt_to_bus(va_bus)); > >> DRM_INFO("MISMATCH: %p != %p\n", va, (void *) virt_to_bus(va)); >> /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ // Leads to a Kernel Fault > > That is odd. I would have thought it would be usuable. > >> ... >> } >> >> I'm getting the output: >> >> [drm] MISMATCH: 0000000080280000 != 0000000040280000 > > In theory that means the bus address that is programmed in (gtt->dma_address[i]) > is 0000000040280000 (which is what virt_to_bus(va) should have resolved itself to). > > > Tha you can't get access to 'va' (0000000080280000) is odd. One way to try to > access it is to do: > > va = __va(page_to_pfn(ttm->pages[i]) << PAGE_SHIFT); > DRM_INFO("CONTENTS: %x\n", *((uint32_t)va)); > > As that would get it via the page -> va. > _______________________________________________ > 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