search for: ioremap_wc

...-mapped BO, e.g. a BO >> mapped through the BAR. >> > Um wait, this memory is behind an already mapped bar? I think ioremap on > ARM defaults to uncached mappings, so if you want to access the memory > behind this bar as WC you need to map the BAR as a whole as WC by using > ioremap_wc. Tried mapping the BAR using ioremap_wc(), but to no avail. On the other hand, could it be that VRAM BOs end up creating a mapping over an already-mapped region? I seem to remember that ARM might not like it...

...the BAR. >> >> >> > Um wait, this memory is behind an already mapped bar? I think ioremap on >> > ARM defaults to uncached mappings, so if you want to access the memory >> > behind this bar as WC you need to map the BAR as a whole as WC by using >> > ioremap_wc. >> >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >> hand, could it be that VRAM BOs end up creating a mapping over an >> already-mapped region? I seem to remember that ARM might not like it... > > Multiple mapping are generally allowed, as...

...>>>>> Um wait, this memory is behind an already mapped bar? I think ioremap on >>>>> ARM defaults to uncached mappings, so if you want to access the memory >>>>> behind this bar as WC you need to map the BAR as a whole as WC by using >>>>> ioremap_wc. >>>> >>>> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >>>> hand, could it be that VRAM BOs end up creating a mapping over an >>>> already-mapped region? I seem to remember that ARM might not like it... >>> >&gt...

...gt;> > >> > Um wait, this memory is behind an already mapped bar? I think ioremap on > >> > ARM defaults to uncached mappings, so if you want to access the memory > >> > behind this bar as WC you need to map the BAR as a whole as WC by using > >> > ioremap_wc. > >> > >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other > >> hand, could it be that VRAM BOs end up creating a mapping over an > >> already-mapped region? I seem to remember that ARM might not like it... > > > > Multiple map...

This patch is not meant to be merged, but rather to try and understand why this is needed and what a more suitable solution could be. Allowing BOs to be write-cached results in the following happening when trying to run any program on Tegra/GK20A: Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 ... (nouveau_bo_rd32) from [<c0357d00>] (nouveau_fence_update+0x5c/0x80)

...;> Um wait, this memory is behind an already mapped bar? I think ioremap on > >>>>> ARM defaults to uncached mappings, so if you want to access the memory > >>>>> behind this bar as WC you need to map the BAR as a whole as WC by using > >>>>> ioremap_wc. > >>>> > >>>> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other > >>>> hand, could it be that VRAM BOs end up creating a mapping over an > >>>> already-mapped region? I seem to remember that ARM might not like it......

...;> mapped through the BAR. > >> > > Um wait, this memory is behind an already mapped bar? I think ioremap on > > ARM defaults to uncached mappings, so if you want to access the memory > > behind this bar as WC you need to map the BAR as a whole as WC by using > > ioremap_wc. > > Tried mapping the BAR using ioremap_wc(), but to no avail. On the other > hand, could it be that VRAM BOs end up creating a mapping over an > already-mapped region? I seem to remember that ARM might not like it... Multiple mapping are generally allowed, as long as they have the...

Implementing those is completely unecessary. Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 ----- drivers/gpu/drm/drm_gem_vram_helper.c | 5 ----- drivers/gpu/drm/qxl/qxl_ttm.c | 6 ------ drivers/gpu/drm/radeon/radeon_ttm.c | 5 ----- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 11 -----------

https://bugs.freedesktop.org/show_bug.cgi?id=58806 Priority: medium Bug ID: 58806 Assignee: nouveau at lists.freedesktop.org Summary: failed to create kernel channel, -12 on G4 PPC QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: stefan at

...wait, this memory is behind an already mapped bar? I think ioremap on >>>>>>> ARM defaults to uncached mappings, so if you want to access the memory >>>>>>> behind this bar as WC you need to map the BAR as a whole as WC by using >>>>>>> ioremap_wc. >>>>>> >>>>>> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >>>>>> hand, could it be that VRAM BOs end up creating a mapping over an >>>>>> already-mapped region? I seem to remember that ARM might not...

..._bo_rd32 is done over an IO-mapped BO, e.g. a BO > mapped through the BAR. > Um wait, this memory is behind an already mapped bar? I think ioremap on ARM defaults to uncached mappings, so if you want to access the memory behind this bar as WC you need to map the BAR as a whole as WC by using ioremap_wc. Regards, Lucas > Any idea about the origin of this behavior? Does ARM forbid cached > mappings over IO regions? > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ > 1 file changed, 4 insertions(+) >...

...pdev->dev, "Cannot remap MMIO BAR\n"); > + rc = -EIO; > + goto release_regions; > + } > + > + mdev->aper.pa = pci_resource_start(pdev, mdev->ops->aper_bar); > + mdev->aper.len = pci_resource_len(pdev, mdev->ops->aper_bar); > + mdev->aper.va = ioremap_wc(mdev->aper.pa, mdev->aper.len); > + if (!mdev->aper.va) { > + dev_err(&pdev->dev, "Cannot remap Aperture BAR\n"); > + rc = -EIO; > + goto unmap_mmio; > + } > + > + mdev->ops->init(mdev); > + > + pci_set_drvdata(pdev, mdev); > + > +...

...pdev->dev, "Cannot remap MMIO BAR\n"); > + rc = -EIO; > + goto release_regions; > + } > + > + mdev->aper.pa = pci_resource_start(pdev, mdev->ops->aper_bar); > + mdev->aper.len = pci_resource_len(pdev, mdev->ops->aper_bar); > + mdev->aper.va = ioremap_wc(mdev->aper.pa, mdev->aper.len); > + if (!mdev->aper.va) { > + dev_err(&pdev->dev, "Cannot remap Aperture BAR\n"); > + rc = -EIO; > + goto unmap_mmio; > + } > + > + mdev->ops->init(mdev); > + > + pci_set_drvdata(pdev, mdev); > + > +...

...) > + > + if (mem->bus.addr) > + vaddr_iomem = (void *)(((u8 *)mem->bus.addr)); > + else if (mem->placement & TTM_PL_FLAG_WC) I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new mem->bus.caching enum as replacement. > + vaddr_iomem = ioremap_wc(mem->bus.offset, size); > + else > + vaddr_iomem = ioremap(mem->bus.offset, size); > + > + if (!vaddr_iomem) > + return -ENOMEM; > + > + dma_buf_map_set_vaddr_iomem(map, vaddr_iomem); > + > + } else { > + struct ttm_operation_ctx ctx = { > + .interru...

...tionally. Which one is preferable? Best regards Thomas >> +??????? else if (mem->placement & TTM_PL_FLAG_WC) > > I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new > mem->bus.caching enum as replacement. > >> +??????????? vaddr_iomem = ioremap_wc(mem->bus.offset, size); >> +??????? else >> +??????????? vaddr_iomem = ioremap(mem->bus.offset, size); >> + >> +??????? if (!vaddr_iomem) >> +??????????? return -ENOMEM; >> + >> +??????? dma_buf_map_set_vaddr_iomem(map, vaddr_iomem); >> + >&g...

...l Trace: [ 14.072407] [<c1030bbe>] warn_slowpath_common+0x65/0x95 [ 14.072416] [<c1030c00>] warn_slowpath_null+0x12/0x15 [ 14.072425] [<c101d24a>] __ioremap_caller+0xd1/0x247 [ 14.072435] [<c10b6e4b>] ? create_object+0x1fa/0x207 [ 14.072443] [<c101d464>] ioremap_wc+0x1e/0x28 [ 14.072455] [<f81a19d0>] ? ttm_mem_reg_ioremap+0x70/0x93 [ttm] [ 14.072467] [<f81a19d0>] ttm_mem_reg_ioremap+0x70/0x93 [ttm] [ 14.072498] [<f8217588>] ? nouveau_bo_wr32+0x3ab/0x735 [nouveau] [ 14.072510] [<f81a1f74>] ttm_bo_move_memcpy+0x63/0x257 [ttm]...

...m = (void *)(((u8 *)mem->bus.addr)); > > > + else if (mem->placement & TTM_PL_FLAG_WC) > > > > I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new > > mem->bus.caching enum as replacement. > > > > > + vaddr_iomem = ioremap_wc(mem->bus.offset, > > > size); > > > + else > > > + vaddr_iomem = ioremap(mem->bus.offset, size); > > > + > > > + if (!vaddr_iomem) > > > + return -ENOMEM; > > > + > > > + dma_buf_map_set_vaddr_iomem(map, vaddr_iome...

...n. > > Best regards > Thomas > >>> +??????? else if (mem->placement & TTM_PL_FLAG_WC) >> I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new >> mem->bus.caching enum as replacement. >> >>> +??????????? vaddr_iomem = ioremap_wc(mem->bus.offset, size); >>> +??????? else >>> +??????????? vaddr_iomem = ioremap(mem->bus.offset, size); >>> + >>> +??????? if (!vaddr_iomem) >>> +??????????? return -ENOMEM; >>> + >>> +??????? dma_buf_map_set_vaddr_iomem(map, vad...

...if (ret) + return ret; + + if (mem->bus.is_iomem) { + void __iomem *vaddr_iomem; + unsigned long size = bo->num_pages << PAGE_SHIFT; + + if (mem->bus.addr) + vaddr_iomem = (void *)(((u8 *)mem->bus.addr)); + else if (mem->placement & TTM_PL_FLAG_WC) + vaddr_iomem = ioremap_wc(mem->bus.offset, size); + else + vaddr_iomem = ioremap(mem->bus.offset, size); + + if (!vaddr_iomem) + return -ENOMEM; + + dma_buf_map_set_vaddr_iomem(map, vaddr_iomem); + + } else { + struct ttm_operation_ctx ctx = { + .interruptible = false, + .no_wait_gpu = false + }; + struc...

...em); + if (ret) + return ret; + + if (mem->bus.is_iomem) { + void __iomem *vaddr_iomem; + size_t size = bo->num_pages << PAGE_SHIFT; + + if (mem->bus.addr) + vaddr_iomem = (void __iomem *)mem->bus.addr; + else if (mem->bus.caching == ttm_write_combined) + vaddr_iomem = ioremap_wc(mem->bus.offset, size); + else + vaddr_iomem = ioremap(mem->bus.offset, size); + + if (!vaddr_iomem) + return -ENOMEM; + + dma_buf_map_set_vaddr_iomem(map, vaddr_iomem); + + } else { + struct ttm_operation_ctx ctx = { + .interruptible = false, + .no_wait_gpu = false + }; + struc...