On Mon, Oct 5, 2009 at 10:01 AM, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: > On Mon, Oct 05, 2009 at 11:32:31AM +0100, Jan Beulich wrote: >> >>> Jeremy Fitzhardinge <jer...@goop.org> 02.10.09 20:42 >>> >> >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? >> >> 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 exist. After all, vmalloc_32() >> is *defined* to have the property assumed by both of the users, and >> other than for most kmalloc() cases using GFP_DMA{,32} we're talking >> about double buffering generally large amounts of data here even in >> the cases where the DMA API is being used properly. > > I was chatting with Jeremy about this, and I realized that in some > sense the radeon driver assumes that physical != bus addresses. Which is > OK on x86, but if this card was ever moved to a Sun box it would fail. >
FWIW, the radeon drm has been working fine on both sparc and ppc for years. Alex > The patch here thwarts this by allocating memory from the IOMMU, so that > even if bus != physical address from pci_map_page, that is OK. > > Another way to make this work right is to modify the drivers > that use vmalloc_32, with pci_map_[sg|page], is for them to check if the > physical > != bus address, and if so, remap the virtual address (page_to_vmalloc) to > point to the new bus addresses (and free the "old" page). Obviously this > requires some book-keeping, but it does fix those drivers if they were to > move to > non-x86 architecture. Or on machines where the IOMMU hands out non-physical > addresses. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
