aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAge
* Merge branch 'drm-next' of ↵Linus Torvalds2009-03-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (53 commits) drm: detect hdmi monitor by hdmi identifier (v3) drm: drm_fops.c unlock missing on error path drm: reorder struct drm_ioctl_desc to save space on 64 bit builds radeon: add some new pci ids drm: read EDID extensions from monitor drm: Use a little stash on the stack to avoid kmalloc in most DRM ioctls. drm/radeon: add regs required for occlusion queries support drm/i915: check the return value from the copy from user drm/radeon: fix logic in r600_page_table_init() to match ati_gart drm/radeon: r600 ptes are 64-bit, cleanup cleanup function. drm/radeon: don't call irq changes on r600 suspend/resume drm/radeon: fix r600 writeback across suspend/resume drm/radeon: fix r600 writeback setup. drm: fix warnings about new mappings in info code. drm/radeon: NULL noise: drivers/gpu/drm/radeon/radeon_*.c drm/radeon: fix r600 pci mapping calls. drm/radeon: r6xx/r7xx: fix possible oops in r600_page_table_cleanup() radeon: call the correct idle function, logic got inverted. drm/radeon: RS600: fix interrupt handling drm/r600: fix rptr address along lines of previous fixes to radeon. ...
| * drm: detect hdmi monitor by hdmi identifier (v3)Ma Ling2009-03-29
| | | | | | | | | | | | | | | | Sometime we need to communicate with HDMI monitor by sending audio or video info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device. The patch intends to detect HDMI monitor by this rule. Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: drm_fops.c unlock missing on error pathDan Carpenter2009-03-29
| | | | | | | | | | | | | | | | | | | | | | drm_open_helper() from drm_fops.c had a missing mutex_unlock in a error path. This was caught by smatch (http://repo.or.cz/w/smatch.git/). Compile tested. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: read EDID extensions from monitorMa Ling2009-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | Usually drm read basic EDID, that is enough for us, but since igital display were introduced i.e. HDMI monitor, sometime we need to interact with monitor by EDID extension information, EDID extensions include audio/video data block, speaker allocation and vendor specific data blocks. This patch intends to read EDID extensions from digital monitor for users. Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: Use a little stash on the stack to avoid kmalloc in most DRM ioctls.Eric Anholt2009-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kmalloc was taking up about 1.5% of the CPU on an ioctl-heavy workload (x11perf -aa10text on 965). Initial results look like they have a corresponding improvement in performance for aa10text, but more numbers might not hurt. Thanks to ajax for pointing out this performance regression I'd introduced back in 2007. [airlied: well I introduced it sneakily inside Eric's patch] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: add regs required for occlusion queries supportMaciej Cencora2009-03-29
| | | | | | | | | | | | | | [airlied: cleaned up slightly for drm-next] Signed-off-by: Maciej Cencora <m.cencora@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/i915: check the return value from the copy from userDave Airlie2009-03-28
| | | | | | | | | | | | | | This produced a warning on my build, not sure why super-warning-man didn't notice this one, its much worse than the %z one. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: merge Linux master into HEADDave Airlie2009-03-28
| |\ | | | | | | | | | | | | | | | | | | Conflicts: drivers/gpu/drm/drm_info.c drivers/gpu/drm/drm_proc.c drivers/gpu/drm/i915/i915_gem_debugfs.c
| * | drm/radeon: fix logic in r600_page_table_init() to match ati_gartAlex Deucher2009-03-18
| | | | | | | | | | | | | | | | | | | | | This fixes page table init on rs600. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: r600 ptes are 64-bit, cleanup cleanup function.Dave Airlie2009-03-13
| | | | | | | | | | | | Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: don't call irq changes on r600 suspend/resumeDave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | Until we sort out r600 IRQs don't do this. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: fix r600 writeback across suspend/resumeDave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | This update was done in mainline radeon, but not in the r600. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: fix r600 writeback setup.Dave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes 2 bugs: 1. the AGP calculation wasn't consistent with the PCI(E) calc for the RPTR_ADDR registers. This consolidates the writes and fixes it up. 2. The scratch address was being incorrectly calculated, this breaks it out into a lot more linear steps. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: fix warnings about new mappings in info code.Dave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | | | | This fixes up the warnings in the debugfs code that conflicted with the mapping fixups. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: NULL noise: drivers/gpu/drm/radeon/radeon_*.cHannes Eder2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this sparse warning: drivers/gpu/drm/radeon/r600_cp.c:1811:52: warning: Using plain integer as NULL pointer drivers/gpu/drm/radeon/radeon_cp.c:1363:52: warning: Using plain integer as NULL pointer drivers/gpu/drm/radeon/radeon_state.c:1983:61: warning: Using plain integer as NULL pointer Signed-off-by: Hannes Eder <hannes@hanneseder.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: fix r600 pci mapping calls.Dave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | This realigns the r600 pci mapping calls with the ati pcigart ones, fixing the direction and using the correct interface. Suggested by Jerome Glisse. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: r6xx/r7xx: fix possible oops in r600_page_table_cleanup()Alex Deucher2009-03-13
| | | | | | | | | | | | | | | Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | radeon: call the correct idle function, logic got inverted.Dave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | This calls the correct idle function for the R600 and previous chips. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: RS600: fix interrupt handlingAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | the checks weren't updated when RS600 support was added. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm/r600: fix rptr address along lines of previous fixes to radeon.Dave Airlie2009-03-13
| | | | | | | | | | | | Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/r600: fixup r600 gart table accessor like ati_pcigart.cDave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | This attempts to fixup the r600 GART accessors so they work on other arches. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/ati_pcigart: use memset_io to reset the memoryDave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | Also don't setup pci_gart if we aren't going to need it. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | radeon: add support for rs600 GPUsAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | RS600s are an AMD IGP for Intel CPUs, that look like RS690s from a lot of perspectives but look like r600s from a memory controller point of view. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | radeon: fix r600 AGP supportAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | This fixes the ioremap issues with r600 AGP. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: add initial support for R6xx/R7xx GPUsAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | This adds support for 2D/Xv acceleration in the X.org 2D driver, to the drm. It doesn't yet provide any 3D support hooks. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: add r6xx/r7xx microcodeAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the same microcode system as the current radeon code. It should be converted to the new microcode loader I suppose, though really I need a lot more proof of the worth of me maintaining firmware blobs externally. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: prep for r6xx/r7xx supportAlex Deucher2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | - add r6xx/r7xx regs and macros - add r6xx/r7xx chip families - fix register access for regs with offsets >= 0x10000 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | i915/drm: Remove two redundant agp_chipset_flushesOwain G. Ainsworth2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | agp_chipset_flush() is for flushing the intel GMCH write cache via the IFP, these two uses are for when we're getting the object into the cpu READ domain, and thus should not be needed. This confused me when I was getting my head around the code. With thanks to airlied for helping me check my mental picture of how the flushes and clflushes are supposed to be used. Signed-off-by: Owain G. Ainsworth <oga@openbsd.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/i915: Display fence register state in debugfs i915_gem_fence_regs node.Chris Wilson2009-03-13
| | | | | | | | | | | | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/i915: Add information on pinning and fencing to the i915 list debug.Eric Anholt2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | This was inspired by a patch by Chris Wilson, though none of it applied in any way due to the debugfs work and I decided to change the formatting of the new information anyway. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/i915: Consolidate gem object list dumpingBen Gamari2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Here we eliminate a few functions in favor of using a single function to dump from all of the object lists. Signed-Off-By: Ben Gamari <bgamari@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: Convert proc files to seq_file and introduce debugfsBen Gamari2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old mechanism to formatting proc files is extremely ugly. The seq_file API was designed specifically for cases like this and greatly simplifies the process. Also, most of the files in /proc really don't belong there. This patch introduces the infrastructure for putting these into debugfs and exposes all of the proc files in debugfs as well. This contains the i915 hooks rewrite as well, to make bisectability better. Signed-off-by: Ben Gamari <bgamari@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: split busmaster enable out to a separate functionDave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | this is just a code cleanup from the kms tree. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: align ring writes to 16 dwords boundaries.Dave Airlie2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | On some radeon GPUs this appears to introduce another level of stability around interacting with the ring. Its pretty much what fglrx appears to do. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: Print PCI ID of cards when probingBenjamin Herrenschmidt2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | This is usedul when you have multiple cards to figure out which one is which minor. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only X86 32-bit uses a different alignment for "unsigned long long" than it's 64-bit counterpart. Therefore this compat translation is only correct, and only needed, when either CONFIG_X86 or CONFIG_IA64. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: radeon: Fix unaligned access in r300_scratch().David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In compat mode, the cmdbuf->buf 64-bit address cookie can potentially be only 32-bit aligned. Dereferencing this as 64-bit causes expensive unaligned traps on platforms like sparc64. Use get_unaligned() to fix. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Platforms such as sparc64 have D-cache aliasing issues. We cannot allow virtual mappings in different contexts to be such that two cache lines can be loaded for the same backing data. Updates to one cache line won't be seen by accesses to the other cache line. Code in sparc64 and other architectures solve this problem by making sure that all userland mappings of MAP_SHARED objects have the same virtual address base. They implement this by keying off of the page offset, and using that to choose a suitably consistent virtual address for mmap() requests. Making things even worse, getting this wrong on sparc64 can result in hangs during DRM lock acquisition. This is because, at least on UltraSPARC-III, normal loads consult the D-cache but atomics such as 'cas' (which is what cmpxchg() is implement using) only consult the L2 cache. So if a D-cache alias is inserted, the load can see different data than the atomic, and we'll loop forever because the atomic compare-and-exchange will never complete successfully. So to make this all work properly, we need to make sure that the hash address computed by drm_map_handle() preserves the SHMLBA relevant bits, and that's what this patch does for _DRM_SHM mappings. As a historical note, many years ago this bug didn't exist because we used to just use the low 32-bits of the address as the hash and just hope for the best. This preserved the SHMLBA bits properly. But when the hashtab code was added to DRM, this was no longer the case. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: radeon: Use surface for PCI GART table.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allocates a physical surface for the PCI GART table, this way no matter what other surface configurations exist the GART table will always be seen by the hardware properly. We encode the file pointer of the virtual surface allocate using a special cookie value, called PCIGART_FILE_PRIV. On the last close, we release that surface. Just to be doubly safe, we run the pcigart table setup with the main surface control register clear. Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: radeon: Fix calculation of RB_RPTR_ADDR in non-AGP case.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | The address needs to be a GART relative address, rather than a PCI DMA address. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: radeon: Fix RADEON_*_EMITED defines.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | These are not supposed to be booleans, they are supposed to be bit masks. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: radeon: Fix ring_rptr accesses.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The memory behind ring_rptr can either be in ioremapped memory or a vmalloc() normal kernel memory buffer. However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus readl() and writel()) to access it. Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's vmalloc'd memory. Adjust all of the ring_rptr access code as needed. While we're here, kill the 'scratch' pointer in drm_radeon_private. It's only used in the one place where it is initialized. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: ati_pcigart: Need to use PCI_DMA_BIDIRECTIONAL.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.David Miller2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: Drop unused and broken dri_library_name sysfs attribute.Kristian Høgsberg2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel shouldn't be in the business of telling user space which driver to load. The kernel defers mapping PCI IDs to module names to user space and we should do the same for DRI drivers. And in fact, that's how it does work today. Nothing uses the dri_library_name attribute, and the attribute is in fact broken. For intel devices, it falls back to the default behaviour of returning the kernel module name as the DRI driver name, which doesn't work for i965 devices. Nobody has ever hit this problem or filed a bug about this. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: claim PCI device when running in modesetting mode.Kristian Høgsberg2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under kernel modesetting, we manage the device at all times, regardless of VT switching and X servers, so the only decent thing to do is to claim the PCI device. In that case, we call the suspend/resume hooks directly from the pci driver hooks instead of the current class device detour. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: Make drm_local_map use a resource_size_t offsetBenjamin Herrenschmidt2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes drm_local_map to use a resource_size for its "offset" member instead of an unsigned long, thus allowing 32-bit machines with a >32-bit physical address space to be able to store there their register or framebuffer addresses when those are above 4G, such as when using a PCI video card on a recent AMCC 440 SoC. This patch isn't as "trivial" as it sounds: A few functions needed to have some unsigned long/int changed to resource_size_t and a few printk's had to be adjusted. But also, because userspace isn't capable of passing such offsets, I had to modify drm_find_matching_map() to ignore the offset passed in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS. If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps for a given device, we might have to change that trick, but I don't think that happens on any current driver. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: Split drm_map and drm_local_mapBenjamin Herrenschmidt2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once upon a time, the DRM made the distinction between the drm_map data structure exchanged with user space and the drm_local_map used in the kernel. For some reasons, while the BSD port still has that "feature", the linux part abused drm_map for kernel internal usage as the local map only existed as a typedef of the struct drm_map. This patch fixes it by declaring struct drm_local_map separately (though its content is currently identical to the userspace variant), and changing the kernel code to only use that, except when it's a user<->kernel interface (ie. ioctl). This allows subsequent changes to the in-kernel format I've also replaced the use of drm_local_map_t with struct drm_local_map in a couple of places. Mostly by accident but they are the same (the former is a typedef of the later) and I have some remote plans and half finished patch to completely kill the drm_local_map_t typedef so I left those bits in. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
| * | drm: Use resource_size_t for drm_get_resource_{start, len}Benjamin Herrenschmidt2009-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DRM uses its own wrappers to obtain resources from PCI devices, which currently convert the resource_size_t into an unsigned long. This is broken on 32-bit platforms with >32-bit physical address space. This fixes them, along with a few occurences of unsigned long used to store such a resource in drivers. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@linux.ie>