- 19 8月, 2013 1 次提交
-
-
由 Daniel Vetter 提交于
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature flag set, so strictly speaking the modesetting check is redundant. But adding it has the upside that it makes it very clear that the dma support is legacy stuff. Reviewed-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 7月, 2013 3 次提交
-
-
由 Daniel Vetter 提交于
All users of it are now gone! Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
由 Daniel Vetter 提交于
The version offered by the core is ridiculously optimized and does the same thing. So use it. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
由 Daniel Vetter 提交于
It fiddles the sarea out of the maps which are also handled in drm_bufs.c With this drm_drv.c is a notch more legacy free. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
- 31 5月, 2013 2 次提交
-
-
由 Andy Lutomirski 提交于
I didn't fix this in the earlier patch -- it would have broken the build due to the now-deleted garbage in drm_os_linux.h. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NAndy Lutomirski <luto@amacapital.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Andy Lutomirski 提交于
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS mappings with DRM_WRITE_COMBINING set, resulted in an unconditional MTRR being added but the actual mappings being created as UC-. Now these mappings have the MTRR added only if needed, but they will be mapped with pgprot_writecombine. The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of hardcoding the bit twiddling. The DRM_AGP case is unchanged for now. [airlied: fix ppc build] Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NAndy Lutomirski <luto@amacapital.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 03 10月, 2012 1 次提交
-
-
由 David Howells 提交于
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NDave Airlie <airlied@redhat.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: NDave Jones <davej@redhat.com>
-
- 20 7月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
Absolutely unused. All the values are only ever initialized and then used at most in some debug printout functions. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 21 4月, 2012 1 次提交
-
-
由 Linus Torvalds 提交于
This continues the theme started with vm_brk() and vm_munmap(): vm_mmap() does the same thing as do_mmap(), but additionally does the required VM locking. This uninlines (and rewrites it to be clearer) do_mmap(), which sadly duplicates it in mm/mmap.c and mm/nommu.c. But that way we don't have to export our internal do_mmap_pgoff() function. Some day we hopefully don't have to export do_mmap() either, if all modular users can become the simpler vm_mmap() instead. We're actually very close to that already, with the notable exception of the (broken) use in i810, and a couple of stragglers in binfmt_elf. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 14 6月, 2011 2 次提交
-
-
由 Tormod Volden 提交于
Drivers using multiple framebuffers got broken by commit 41c2e75e which ignored the framebuffer (or register) map offset when looking for existing maps. The rationale was that the kernel-userspace ABI is fixed at a 32-bit offset, so the real offsets could not always be handed over for comparison. Instead of ignoring the offset we will compare the lower 32 bit. Drivers using multiple framebuffers should just make sure that the lower 32 bit are different. The existing drivers in question are practically limited to 32-bit systems so that should be fine for them. It is assumed that current drivers always specify a correct framebuffer map offset, even if this offset was ignored since above commit. So this patch should not change anything for drivers using only one framebuffer. Drivers needing multiple framebuffers with 64-bit map offsets will need to cook up something, for instance keeping an ID in the lower bit which is to be aligned away when it comes to using the offset. All of above applies to _DRM_REGISTERS as well. Signed-off-by: NTormod Volden <debian.tormod@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jay Estabrook 提交于
Remove an obsolete Alpha adjustment, and modify another, to go with the current Alpha architecture support. Signed-off-by: NJay Estabrook <jay.estabrook@gmail.com> Tested-by: NMatt Turner <mattst88@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 8月, 2010 1 次提交
-
-
由 Davidlohr Bueso 提交于
Currently most, if not all, memory allocation in drm_bufs.c is followed by initializing the memory with 0. Replace the use of kmalloc+memset with kzalloc. Signed-off-by: NDavidlohr Bueso <dave@gnu.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 01 6月, 2010 2 次提交
-
-
由 Jordan Crouse 提交于
Add __arm defines to specify behavior specific for an ARM processor. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jordan Crouse 提交于
Remove the drm_resource wrappers and directly use the actual PCI and/or platform functions in their place. [airlied: fixup nouveau properly to build] Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Reviewed-by: NMatt Turner <mattst88@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 16 3月, 2010 1 次提交
-
-
由 Thomas Weber 提交于
[Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: NThomas Weber <swirl@gmx.li> Acked-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 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>
-
- 18 9月, 2009 1 次提交
-
-
由 Pekka Paalanen 提交于
Fix the error message: this is add, not rm. Move the closing brace to proper spot: _DRM_GEM branch should not be included in the block. Signed-off-by: NPekka Paalanen <pq@iki.fi> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 6月, 2009 1 次提交
-
-
由 Eric Anholt 提交于
It hasn't been used in ages, and having the user tell your how much memory is being freed at free time is a recipe for disaster even if it was ever used. Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 11 6月, 2009 1 次提交
-
-
由 Ben Skeggs 提交于
A driver will use the _DRM_DRIVER map flag to indicate that it wants to be responsible for removing the map itself, bypassing the DRM's automagic cleanup code. Since the multi-master changes this has been broken, resulting in some drivers having their registers unmapped before it's finished with them. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 6c51d1cf, which apparently causes DRI initialization failures on Radeons. Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Requested-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 6月, 2009 1 次提交
-
-
由 Ben Skeggs 提交于
A driver will use the _DRM_DRIVER map flag to indicate that it wants to be responsible for removing the map itself, bypassing the DRM's automagic cleanup code. Since the multi-master changes this has been broken, resulting in some drivers having their registers unmapped before it's finished with them. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 5月, 2009 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Currently, userspace can fail to obtain the SAREA mapping (among other reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the page size. This breaks for example on PowerPC with 64K pages and radeon despite the kernel radeon actually doing the right rouding in the first place. The way SAREA_MAX is defined with a bunch of ifdef's and duplicated between libdrm and the X server is gross, ultimately it should be retrieved by userspace from the kernel, but in the meantime, we have plenty of existing userspace built with bad values that need to work. This patch works around broken userspace by rounding the requested size in drm_addmap_core() of any SHM map to the page size. Since the backing memory for SHM maps is also allocated within addmap_core, there is no danger of adjacent memory being exposed due to the increased map size. The only side effect is that drivers that previously tried to create or access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL), will now succeed at the cost of a little bit more memory used if that happens to be when the map is created. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 13 3月, 2009 4 次提交
-
-
由 David Miller 提交于
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: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Benjamin Herrenschmidt 提交于
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: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Benjamin Herrenschmidt 提交于
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: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Benjamin Herrenschmidt 提交于
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: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 03 3月, 2009 1 次提交
-
-
由 Thomas Hellstrom 提交于
Currently only one waiter is woken up, leaving other waiters hanging waiting for the DRM lock. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 29 12月, 2008 3 次提交
-
-
由 Dave Airlie 提交于
this exports the locked version of the symbol as struct_mutex locks it all. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Add core support for mapping of GEM objects. Drivers should provide a vm_operations_struct if they want to support page faulting of objects. The code for handling GEM object offsets was taken from TTM, which was written by Thomas Hellström. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This is step one towards having multiple masters sharing a drm device in order to get fast-user-switching to work. It splits out the information associated with the drm master into a separate kref counted structure, and allocates this when a master opens the device node. It also allows the current master to abdicate (say while VT switched), and a new master to take over the hardware. It moves the Intel and radeon drivers to using the sarea from within the new master structures. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 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>
-
- 07 2月, 2008 3 次提交
-
-
由 Eric Anholt 提交于
The i830 and newer intel 2D code adds the AGP base to map offsets already, because it wasn't doing the AGP enable which used to set dev->agp->base. Credit goes to Zhenyu for finding the issue. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Jesse Barnes 提交于
Add suspend/resume support to the i915 driver. Moves some of the initialization into the driver load routine, and fixes up places where we assumed no dev_private existed in some of the cleanup paths. This allows us to suspend/resume properly even if X isn't running. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Dave Airlie 提交于
Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 20 10月, 2007 1 次提交
-
-
由 Pavel Emelyanov 提交于
The task_struct->pid member is going to be deprecated, so start using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in the kernel. The first thing to start with is the pid, printed to dmesg - in this case we may safely use task_pid_nr(). Besides, printks produce more (much more) than a half of all the explicit pid usage. [akpm@linux-foundation.org: git-drm went and changed lots of stuff] Signed-off-by: NPavel Emelyanov <xemul@openvz.org> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 10月, 2007 2 次提交
-
-
由 Eric Anholt 提交于
The data is now in kernel space, copied in/out as appropriate according to t This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal with those failures. This also means that XFree86 4.2.0 support for i810 DR is lost. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Eric Anholt 提交于
As a fallout, replace filp storage with file_priv storage for "unique identifier of a client" all over the DRM. There is a 1:1 mapping, so this should be a noop. This could be a minor performance improvement, as everyth on Linux dereferenced filp to get file_priv anyway, while only the mmap ioct went the other direction. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 25 8月, 2007 1 次提交
-
-
由 Scott Thompson 提交于
Signed-off-by: Scott Thompson <postfail <at> hushmail.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-