An error occurred fetching the project authors.
- 20 Jan, 2013 1 commit
-
-
Daniel Vetter authored
Two exceptions: - debugfs files only read information which is not related to crtc, so can stay on the modeset_config lock. - Same holds for the edp vdd work in intel_dp.c. Add a corresponding WARN_ON and a comment next to the intel_dp struct fields for documentation. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Jan, 2013 1 commit
-
-
Ben Widawsky authored
The purpose of the gtt structure is to help isolate our gtt specific properties from the rest of the code (in doing so it help us finish the isolation from the AGP connection). The following members are pulled out (and renamed): gtt_start gtt_total gtt_mappable_end gtt_mappable gtt_base_addr gsm The gtt structure will serve as a nice place to put gen specific gtt routines in upcoming patches. As far as what else I feel belongs in this structure: it is meant to encapsulate the GTT's physical properties. This is why I've not added fields which track various drm_mm properties, or things like gtt_mtrr (which is itself a pretty transient field). Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [Ben modified commit messages] Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 Nov, 2012 1 commit
-
-
Chris Wilson authored
Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 Oct, 2012 1 commit
-
-
Daniel Vetter authored
The overlay on the i830M has a peculiar failure mode: It works the first time around after boot-up, but consistenly hangs the second time it's used. Chris Wilson has dug out a nice errata: "1.5.12 Clock Gating Disable for Display Register Address Offset: 06200h–06203h "Bit 3 Ovrunit Clock Gating Disable. 0 = Clock gating controlled by unit enabling logic 1 = Disable clock gating function DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." Now I've nowhere found that 0xc8 register and hence couldn't apply the l2 cache workaround. But I've remembered that part of the magic that the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache allocations so that the overlay scaler has some scratch space. And while pondering how that could explain the hang the 2nd time we enable the overlay, I've remembered that the old ums overlay code did _not_ issue the OVERLAY_OFF cmd. And indeed, disabling the OFF cmd results in the overlay working flawlessly, so I guess we can workaround the lack of the above workaround by simply never disabling the overlay engine once it's enabled. Note that we have the first part of the above w/a already implemented in i830_init_clock_gating - leave that as-is to avoid surprises. v2: Add a comment in the code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827 Cc: stable@vger.kernel.org Tested-by:
Rhys <rhyspuk@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 Oct, 2012 1 commit
-
-
Chris Wilson authored
The intention was to allow the caller to avoid a failure to queue a request having already written commands to the ring. However, this is a moot point as the i915_add_request() can fail for other reasons than a mere allocation failure and those failure cases are more likely than ENOMEM. So the overlay code already had to handle i915_add_request() failures, and due to commit 3bb73aba Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 20 12:40:59 2012 +0100 drm/i915: Allow late allocation of request for i915_add_request() the error handling code in intel_overlay.c was subject to causing double-frees, as found by coverity. Rather than further complicate i915_add_request() and callers, realise the battle is lost and adapt intel_overlay.c to take advantage of the late allocation of requests. v2: Handle callers passing in a NULL seqno. v3: Ditto. This time for sure. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 Oct, 2012 2 commits
-
-
David Howells authored
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by:
Dave Jones <davej@redhat.com>
-
David Howells authored
Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by:
Dave Jones <davej@redhat.com>
-
- 24 Aug, 2012 1 commit
-
-
Chris Wilson authored
Avoid stalling and waiting for the GPU by checking to see if there is sufficient inactive space in the aperture for us to bind the buffer prior to writing through the GTT. If there is inadequate space we will have to stall waiting for the GPU, and incur overheads moving objects about. Instead, only incur the clflush overhead on the target object by writing through shmem. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Aug, 2012 1 commit
-
-
Daniel Vetter authored
Now that all affected i830M systems have the pipe A quirk set, we don't need to do any special dances in the overlay code any longer. And reading through the code I'm rather dubios that it actually does what it claims to do ... As a nice benefit this rips out a users of the crtc helper dpms callback. v2: As suggested by Chris Wilson, replace the code by an appropriate WARN to ensure that the pipe A is indeed running. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 May, 2012 1 commit
-
-
Ben Widawsky authored
Wait request is poorly named IMO. After working with these functions for some time, I feel it's much clearer to name the functions more appropriately. Of course we must update the callers to use the new name as well. This leaves room within our namespace for a *real* wait request function at some point. Note to maintainer: this patch is optional. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 May, 2012 1 commit
-
-
Daniel Vetter authored
Our handling of the crtc timing computation has been nicely cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over the place. But with commit f9bef081 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Apr 15 19:53:19 2012 +0200 drm/i915: don't clobber the special upscaling lvds timings and commit ca9bfa7e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 we now only set the crtc timing fields in the encoder->mode_fixup (lvds only) and in crtc->mode_fixup (for everyone else). And since commit 75c13993 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 23:48:46 2012 +0100 drm/i915: fixup overlay checks for interlaced modes the only places we actually need the crtc timings is in the mode_set function. I guess the idea of the drm core is that every time it creates a drm mode, it also sets the timings. But afaics it never uses them, safe for the precise vblank timestamp code (but that can only run on active modes, i.e. after our mode_fixup functions have been called). The problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the timings are pretty much bogus for us anyway (at least with interlaced support). So I guess it's the drivers job that every active modes needs to have crtc timings that suits it, and with these patches we should have that. drm core doesn't seem to care about modes that just get passed around. Hence we can now safely rip out all the remaining calls to set_crtcinfo left in the driver and clean up this confusion. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 May, 2012 4 commits
-
-
Daniel Vetter authored
The LP refers to 'low priority' as opposed to the high priority ring on gen2/3. So lets constrain its use to the code of that era. Unfortunately we can't yet completely remove the associated macros from common headers and shove them into i915_dma.c to the other dri1 legacy support code, a few cleanups are still missing for that. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
This originates from a hack by me to quickly fix a bug in an earlier patch where we needed control over whether or not waiting on a seqno actually did any retire list processing. Since the two operations aren't clearly related, we should pull the parameter out of the wait function, and make the caller responsible for retiring if the action is desired. The only function call site which did not get an explicit retire_request call (on purpose) is i915_gem_inactive_shrink(). That code was already calling retire_request a second time. v2: don't modify any behavior excepit i915_gem_inactive_shrink(Daniel) Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Also ditch the cargo-culted dev_priv checks - either we have a giant hole in our setup code or this is useless. Plainly bogus to check for it in either case. v2: Chris Wilson noticed that I've missed one bogus dev_priv check. v3: The check in the overlay code is redundant (Chris) Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
With the exception of a forced cast for phys_obj stuff (a problem in other patches as well) all of these are fairly simple __iomem compliance fixes. As with other patches, yank/paste errors may exist. Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> [danvet: Added comment to explain the __iomem cast.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 Feb, 2012 1 commit
-
-
Danny Kukawka authored
This reverts commit e167976e, Since this was already fixed in commit 3bd3c932 some days before this commit cause seq_file.h to be included twice. Signed-off-by:
Danny Kukawka <danny.kukawka@bisect.de> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 Feb, 2012 2 commits
-
-
Daniel Vetter authored
The drm core _really_ likes to frob around with the crtc timings and put halfed vertical timings (in fields) in there. Which confuses the overlay code, resulting in it's refusal to display anything at the lower half of an interlaced pipe. Tested-by:
Christopher Egert <cme3000@gmail.com> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We have a pretty decent confusion about vertical timings of interlaced modes. Peter Ross has written a patch that makes interlace modes work on a lot more platforms/output combinations by doubling the vertical timings. The issue with that patch is that core drm _does_ support specifying whether we want these vertical timings in fields or frames, we just haven't managed to consistently use this facility. The relavant function is drm_mode_set_crtcinfo, which fills in the crtc timing information. The first thing to note is that the drm core keeps interlaced modes in frames, but displays modelines in fields. So when the crtc modeset helper copies over the mode into adjusted_mode it will already contain vertical timings in half-frames. The result is that the fixup code in intel_crtc_mode_fixup doesn't actually do anything (in most cases at least). Now gen3+ natively supports interlaced modes and wants the vertical timings in frames. Which is what sdvo already fixes up, at least under some conditions. There are a few other place that demand vertical timings in fields but never actually deal with interlaced modes, so use frame timings for consistency, too. These are: - lvds panel, - dvo encoders - dvo is the only way gen2 could support interlaced mode, but currently we don't support any encoders that do. - tv out - despite that the tv dac sends out an interlaced signal it expects a progressive mode pipe configuration. All these encoders enforce progressive modes by resetting interlace_allowed. Hence we always want crtc vertical timings in frames. Enforce this in our crtc mode_fixup function and rip out any redudant timing computations from the encoders' mode_fixup function. v2-4: Adjust the vertical timings a bit. v5: Split out the 'subtract-one for interlaced' fixes. v6: Clarify issues around tv-out and gen2. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Christopher Egert <cme3000@gmail.com> Tested-by:
Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 Jan, 2012 1 commit
-
-
Ben Widawsky authored
Sometimes it may be the case when we idle the gpu or wait on something we don't actually want to process the retiring list. This patch allows callers to choose the behavior. Reviewed-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 Sep, 2011 1 commit
-
-
Akshay Joshi authored
Various issues involved with the space character were generating warnings in the checkpatch.pl file. This patch removes most of those warnings. Signed-off-by:
Akshay Joshi <me@akshayjoshi.com> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- 30 Jun, 2011 1 commit
-
-
Chris Wilson authored
As pointed out by Dan Carpenter, it was seemingly possible to hit an error whilst mapping the buffer for the regs (except the only likely error returns should not happen during init) and so leak a pin count on the bo. To handle this we would need to reacquire the struct mutex, so for simplicity rearrange for the lock to be held for the entire function. For extra pedagogy, test that we only call init once. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- 28 Jun, 2011 2 commits
-
-
Hugh Dickins authored
When auditing the locking in i915_gem.c (for a prospective change which I then abandoned), I noticed two places where struct_mutex is not held across GEM object manipulations that would usually require it. Since one is in initial setup and the other in driver unload, I'm guessing the mutex is not required for either; but post a patch in case it is. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
When auditing the locking in i915_gem.c (for a prospective change which I then abandoned), I noticed two places where struct_mutex is not held across GEM object manipulations that would usually require it. Since one is in initial setup and the other in driver unload, I'm guessing the mutex is not required for either; but post a patch in case it is. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- 10 Jun, 2011 2 commits
-
-
Chris Wilson authored
We need to perform a few operations in order to move the object into the display plane (where it can be accessed coherently by the display engine) that are important for future safety to forbid whilst pinned. As a result, we want to need to perform some of the operations before pinning, but some are required once we have been bound into the GTT. So combine the pinning performed by all the callers with set_to_display_plane(), so this complication is contained within the single function. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 Feb, 2011 2 commits
-
-
Chris Wilson authored
The code paths for modesetting are growing in complexity as we may need to move the buffers around in order to fit the scanout in the aperture. Therefore we face a choice as to whether to thread the interruptible status through the entire pinning and unbinding code paths or to add a flag to the device when we may not be interrupted by a signal. This does the latter and so fixes a few instances of modesetting failures under stress. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Dave Airlie spotted that we had a potential bug should we ever rearrange the drm_i915_gem_object so not the base drm_gem_object was not its first member. He noticed that we often convert the return of drm_gem_object_lookup() immediately into drm_i915_gem_object and then check the result for nullity. This is only valid when the base object is the first member and so the superobject has the same address. Play safe instead and use the compiler to convert back to the original return address for sanity testing. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 07 Feb, 2011 2 commits
-
-
Jesse Barnes authored
We had some conversions over to the _PIPE macros, but didn't get everything. So hide the per-pipe regs with an _ (still used in a few places for legacy) and add a few _PIPE based macros, then make sure everyone uses them. [update: remove usage of non-existent no-op macro] [update 2: keep modesetting suspend/resume code, update to new reg names] Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [ickle: stylistic cleanups for checkpatch and taste] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
A lot of minor tweaks to fix the tracepoints, improve the outputting for ftrace, and to generally make the tracepoints useful again. It is a start and enough to begin identifying performance issues and gaps in our coverage. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 05 Dec, 2010 1 commit
-
-
Chris Wilson authored
The bulk of the change is to convert the growing list of rings into an array so that the relationship between the rings and the semaphore sync registers can be easily computed. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 02 Dec, 2010 1 commit
-
-
Chris Wilson authored
With this change, every batchbuffer can use all available fences (save pinned and scanout, of course) without ever stalling the gpu! In theory. Currently the actual pipelined update of the register is disabled due to some stability issues. However, just the deferred update is a significant win. Based on a series of patches by Daniel Vetter. The premise is that before every access to a buffer through the GTT we have to declare whether we need a register or not. If the access is by the GPU, a pipelined update to the register is made via the ringbuffer, and we track the last seqno of the batches that access it. If by the CPU we wait for the last GPU access and update the register (either to clear or to set it for the current buffer). One advantage of being able to pipeline changes is that we can defer the actual updating of the fence register until we first need to access the object through the GTT, i.e. we can eliminate the stall on set_tiling. This is important as the userspace bo cache does not track the tiling status of active buffers which generate frequent stalls on gen3 when enabling tiling for an already bound buffer. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 Nov, 2010 1 commit
-
-
Chris Wilson authored
A glorified s/obj_priv/obj/ with a net reduction of over a 100 lines and many characters! Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 04 Nov, 2010 1 commit
-
-
Daniel Vetter authored
a00b10c3 "Only enforce fence limits inside the GTT" also added a fenceable/mappable disdinction when binding/pinning buffers. This only complicates the code with no pratical gain: - In execbuffer this matters on for g33/pineview, as this is the only chip that needs fences and has an unmappable gtt area. But fences are only possible in the mappable part of the gtt, so need_fence implies need_mappable. And need_mappable is only set independantly with relocations which implies (for sane userspace) that the buffer is untiled. - The overlay code is only really used on i8xx, which doesn't have unmappable gtt. And it doesn't support tiled buffers, currently. - For all other buffers it's a bug to pass in a tiled bo. In short, this disdinction doesn't have any practical gain. I've also reverted mapping the overlay and context pages as possibly unmappable. It's not worth being overtly clever here, all the big gains from unmappable are for execbuf bos. Also add a comment for a clever optimization that confused me while reading the original patch by Chris Wilson. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 29 Oct, 2010 1 commit
-
-
Chris Wilson authored
So long as we adhere to the fence registers rules for alignment and no overlaps (including with unfenced accesses to linear memory) and account for the tiled access in our size allocation, we do not have to allocate the full fenced region for the object. This allows us to fight the bloat tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside the GTT we still suffer the additional alignment constraints, so it doesn't magic allow us to render larger scenes without stalls -- we need the expanded GTT and fence pipelining to overcome those...] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 27 Oct, 2010 4 commits
-
-
Daniel Vetter authored
Like before add a parameter mappable (also to gem_object_pin) and set it depending upon the context. Only bos that are brought into the gtt due to an execbuffer call can be put into the unmappable part of the gtt, everything else (especially pinned objects) need to be put into the mappable part of the gtt. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Preparing the ringbuffer for adding new commands can fail (a timeout whilst waiting for the GPU to catch up and free some space). So check for any potential error before overwriting HEAD with new commands, and propagate that error back to the user where possible. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Dan Carpenter authored
"depth" should be signed in case packed_depth_bytes() returns -EINVAL. This probably doesn't make a difference at runtime. In the original code we would return -EINVAL later if (rec->offset_Y % 4294967274) is non-zero. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 26 Oct, 2010 1 commit
-
-
Peter Zijlstra authored
Keep the current interface but ignore the KM_type and use a stack based approach. The advantage is that we get rid of crappy code like: #define __KM_PTE \ (in_nmi() ? KM_NMI_PTE : \ in_irq() ? KM_IRQ_PTE : \ KM_PTE0) and in general can stop worrying about what context we're in and what kmap slots might be appropriate for that. The downside is that FRV kmap_atomic() gets more expensive. For now we use a CPP trick suggested by Andrew: #define kmap_atomic(page, args...) __kmap_atomic(page) to avoid having to touch all kmap_atomic() users in a single patch. [ not compiled on: - mn10300: the arch doesn't actually build with highmem to begin with ] [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c] Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Chris Metcalf <cmetcalf@tilera.com> Cc: David Howells <dhowells@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Miller <davem@davemloft.net> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Dave Airlie <airlied@linux.ie> Cc: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 Sep, 2010 1 commit
-
-
Chris Wilson authored
Avoid confusion between i965g meaning broadwater and the gen4+ chipset families. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-