Re: [PATCH] drm: make sure page protections are updated after changing vm_flags.

On 10/06/09 13:39, Andrew Morton wrote: > On Wed, 30 Sep 2009 15:55:39 -0700 > Jeremy Fitzhardinge wrote: > > >> Some architectures compute ->vm_page_prot depending on ->vm_flags, so >> we need to update the protections after adjusting the flags. >> >&g

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/06/09 01:10, Jan Beulich wrote: >>>> Jeremy Fitzhardinge 05.10.09 21:09 >>> >>>> >> vmalloc_32 is a general problem. The only clean way I can see to make >> it work under Xen is to make sure all the pages in the DMA32 zone are >&

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/05/09 07:37, Konrad Rzeszutek Wilk wrote: > Jeremy suggested another one. That is for the Xen IOMMU to fix the virtual > mappings. Meaning we would swipe out the virtual address of the page to point > to a virtual address (along with returning an 32-bit bus address) under the > 4GB mark. > T

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/05/09 03:32, Jan Beulich wrote: > Are you really convinced fixing this in DRM is the right thing to do? To > me, the use of vmalloc_32() in drivers/ieee1394/ seems to make similar > assumptions (pci_map_sg() not modifying the buffer addresses), and > who knows where else such assumptions exis

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/01/09 23:58, Boris Derzhavets wrote: > Dmesg report attached:- > > [ 18.088588] mtrr: type mismatch for d000,1000 old: > write-back new: write-combining > [ 18.088653] mtrr: type mismatch for d000,1000 old: > write-back new: write-combining > [ 18.338143] mtrr: type mism

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/02/09 10:23, Boris Derzhavets wrote: > Jeremy, > Please, be aware of bugzilla.xensource.com [1519] the most recent > entries :- > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1519 > Ah, OK. I pushed a variant of Konrad's patches. Could you try them out? Thanks, J --

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800) . Test commited for JF

On 10/02/09 12:50, Boris Derzhavets wrote: > Done via "git pull" for another close enough "linux-2.6-xen" clone :- > # git pull > # git checkout xen/master > # git log > So you're saying it works? I didn't see anything bad in the dmesg output. If it is working, what does /proc/mtrr say? Thanks,

Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/01/09 12:21, Konrad Rzeszutek Wilk wrote: > The are other users of 'vmalloc_32' that look like they depend on this > memory being under the 4GB mark. Most of them are do video capture through > USB - so it probably is limited to only accessing up to 4GB. > Hm. The only sane way I can see

Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/01/09 12:07, Jeremy Fitzhardinge wrote: > Could modify drm_vmalloc_dma to do the vmalloc "manually": > >1. call __get_vm_area to reserve a chunk of vmalloc address space >2. allocate a bunch of individual pages with dma_alloc_coherent >3. insert them into

Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

On 10/01/09 10:35, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 30, 2009 at 11:21:49AM -0400, Konrad Rzeszutek Wilk wrote: > >> With those two options defined in the boot line, the radeon kernel driver >> spits out: >> >> [ 244.190885] [drm] Loading RV730/RV740 PFP Microcode >> [ 244.190911] [d

Re: [PATCH] drm/i915: add _PAGE_IOMAP to GTT mapping attributes

On 10/01/09 01:41, Jan Beulich wrote: >> Why, what's wrong with VM_IO? It's documented as being "Memory mapped >> I/O or similar". VM_PFNMAP is another option, but that seems more >> dubious. Are there places where VM_IO is being legitimately set on >> normal page mappings? >> > This is wha

[PATCH] drm: make sure page protections are updated after changing vm_flags.

Some architectures compute ->vm_page_prot depending on ->vm_flags, so we need to update the protections after adjusting the flags. Reported-by: Jan Beulich Signed-off-by: Jeremy Fitzhardinge diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 8104eca..9d3e39f 100644

Re: [PATCH] drm/i915: add _PAGE_IOMAP to GTT mapping attributes

On 09/30/09 23:49, Jan Beulich wrote: >> This patches looks like the wrong answer, not sure why wrapping the GEM >> stuff is required, probably should change the drm core not the driver. >> > I was actually doing this intentionally this way, because I had no reason > to believe that drm_gem_m

Re: [PATCH] drm/i915: add _PAGE_IOMAP to GTT mapping attributes

On 09/30/09 23:40, Jan Beulich wrote: >> Hm, _PAGE_IOMAP is x86-specific. I guess that doesn't matter in this >> case, but it would for other drivers. Previously _PAGE_IOMAP was set in >> vm_get_page_prot -> arch_vm_get_page_prot. Is that path no longer being >> used? It looks like it should be

Re: [PATCH] drm/i915: add _PAGE_IOMAP to GTT mapping attributes

On 09/30/09 03:13, Jan Beulich wrote: > This is for avoiding translation of the passed in address in virtual > environments like Xen. > Ah, thanks. I suspected one of these was missing and was about to go hunting for it. Do think other DRI drivers are missing this too? Hm, _PAGE_IOMAP is x86

Re: [PATCH] drm/i915: add _PAGE_IOMAP to GTT mapping attributes

On 09/30/09 03:13, Jan Beulich wrote: > This is for avoiding translation of the passed in address in virtual > environments like Xen. > I think something like this is more generally correct. mmap_region() already sets vma->vm_page_prot = vm_get_page_prot(vma->vm_flags), but we need to update t

[PATCH 1/2] agp: use more dma-ops-like operations for agp memory

nd 2) make sure memory is physically contigious when the hardware expects it This change uses swiotlb_phys_to_bus/bus_to_phys to do the phys<->gart conversion, since they already do the right thing, and dma_alloc_coherent for gatt allocations. This works equally well running native. Signe

[PATCH 2/2] agp/intel: use dma_alloc_coherent for special cursor memory

emory. Signed-off-by: Jeremy Fitzhardinge Cc: David Airlie diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c index 4373adb..8ba6808 100644 --- a/drivers/char/agp/intel-agp.c +++ b/drivers/char/agp/intel-agp.c @@ -244,33 +244,29 @@ static void intel_i810_agp_enable(s

Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

Thomas Hellström wrote: > Hi! > > For a long time now, the agpgart module has been creating illegal > mapping aliases, since the user-space mappings of the pages in the > gart are usually write-combined, whereas the kernel linear mapping of > the same pages are uc for x86, and may even be wb for

i915 vsync interrupt fix

I need this patch from Alan Hourihane to make direct rendering work properly on my 945GM-based laptop. It comes from https://bugs.freedesktop.org/show_bug.cgi?id=7233. This change is immediately useful to me now, but I don't know if the development DRM is going to b