- 07 1月, 2010 1 次提交
-
-
由 Zhenyu Wang 提交于
drm_pci_alloc() has input of address mask for setting pci dma mask on the device, which should be properly setup by drm driver. And leave it as a param for drm_pci_alloc() would cause confusion or mistake would corrupt the correct dma mask setting, as seen on intel hw which set wrong dma mask for hw status page. So remove it from drm_pci_alloc() function. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 3月, 2009 4 次提交
-
-
由 Dave Airlie 提交于
Also don't setup pci_gart if we aren't going to need it. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 David Miller 提交于
The variable 'max_pages' is ambiguous. There are two concepts of "pages" being used in this function. First, we have ATI GART pages which are always 4096 bytes. Then, we have system pages which are of size PAGE_SIZE. Eliminate the confusion by creating max_ati_pages and max_real_pages. Calculate and use them as appropriate. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 David Miller 提交于
The buffers mapped by the PCI GART can be written to by the device, not just read. For example, this happens via the RB_RPTR writeback on Radeon. So we can't use PCI_DMA_TODEVICE else we'll get protection faults on IOMMU platforms. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 David Miller 提交于
The PCI GART table initialization code treats the GART table mapping unconditionally as a kernel virtual address. But it could be in the framebuffer, for example, and thus we're dealing with a PCI MEM space ioremap() cookie. Treating that as a virtual address is illegal and will crash some system types (such as sparc64 where the ioremap() return value is actually a physical I/O address). So access the area correctly, using gart_info->gart_table_location as our guide. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 14 7月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 6月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
Switch to using more correct pci dma mapping interfaces. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 26 4月, 2008 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Now that the ATI pcigart code uses dma_alloc_coherent, we don't need the dma_sync_single_for_device() that we used to have here. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 30 3月, 2008 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
This patch fixes bits of the DRM so to make the radeon DRI work on non-cache coherent PCI DMA variants of the PowerPC processors. It moves the few places that needs change to wrappers to that other architectures with similar issues can easily add their own changes to those wrappers, at least until we have more useful generic kernel API. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 29 3月, 2008 1 次提交
-
-
由 Andrew Morton 提交于
drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init': drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t' Cc: Dave Airlie <airlied@linux.ie> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 3月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It makes sure the pcigart table is allocated in coherent memory for DMA operations. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 07 2月, 2008 1 次提交
-
-
由 Márton Németh 提交于
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see drivers/char/drm/drmP.h), it is not worth doing this again. At some other places the ending "\n" was added. airlied:- I cleaned up a few that this patch missed also Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 11 7月, 2007 2 次提交
-
-
由 Dave Airlie 提交于
Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Dave Airlie 提交于
some drivers still todo. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 08 5月, 2007 1 次提交
-
-
由 Dave Airlie 提交于
radeon: make PCI GART aperture size variable, but making table size variable This is precursor to getting a TTM backend for this stuff, and also allows the PCI table to be allocated at fb 0 radeon: add support for reverse engineered xpress200m The IGPGART setup code was traced using mmio-trace on fglrx by myself and Phillip Ezolt <phillipezolt@gmail.com> on dri-devel. This code doesn't let the 3D driver work properly as the card has no vertex shader support. Thanks to Matthew Garrett + Ubuntu for providing me some hardware to do this work on. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 25 1月, 2006 2 次提交
-
-
由 Dave Airlie 提交于
From: Nick Piggin <npiggin@suse.de> Allocate a compound page for the user mapping instead of tweaking the page refcounts. Signed-off-by: NNick Piggin <npiggin@suse.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Dave Airlie 提交于
From: Randy Dunlap <rdunlap@xenotime.net> Use NULL instead of 0 (sparse warnings): drivers/char/drm/ati_pcigart.c:64:10: warning: Using plain integer as NULL pointer drivers/char/drm/ati_pcigart.c:130:21: warning: Using plain integer as NULL pointer drivers/char/drm/ati_pcigart.c:171:14: warning: Using plain integer as NULL pointer Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 02 1月, 2006 1 次提交
-
-
由 Dave Airlie 提交于
In order to work on FreeBSD the gart needed to use a local mapping This patch moves the mainline to the new code and aligns some comment changes From: Eric Anholt <anholt@freebsd.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 09 11月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
Fix the PCIGART increment and add a cpu_to_le32 for ppc (untested) Paulus was unsure if we need to cpu_to_le32 but the old code was definitely wrong, so make it consistent and let the PPC guys figure it out later. Signed-off-by: NDave Airlie <airlied@linux.ie> Cc: Paul Mackerras <paulus@samba.org> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 30 9月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
PCI Express support broke PCIGART Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 25 9月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
I've been threatening this for a while, so no point hanging around. This lindents the DRM code which was always really bad in tabbing department. I've also fixed some misnamed files in comments and removed some trailing whitespace. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 11 9月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
Add support for Radeon PCI Express cards (needs a new X.org DDX) Also allows PCI GART table to be stored in VRAM for non PCIE cards Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 07 7月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
This patch contains the following cleanups: - make needlessly global functions static - remove the following unused global functions: - drm_fops.c: drm_read - i915_dma.c: i915_do_cleanup_pageflip Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-