- 10 Feb, 2012 10 commits
-
-
Peter Ross authored
Signed-off-by:
Peter Ross <pross@xvid.org> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-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>
-
Peter Ross authored
Signed-off-by:
-
Daniel Vetter authored
The hw seems to use this to correctly insert the required delay before/after an even/odd interlaced field. This might also explain why we need to substract 1 half-line from vtotal - if the hw just adds the delay programmend in VSYNCSHIFT the total frame time would be about that too long. These registers seems to only exist on gen4 and later. For paranoia also program it to 0 for progressive modes, but according to documentation the hw should just ignore it in this case. Reviewed-by:
-
Daniel Vetter authored
gen2 doesn't support it, so be a bit more paranoid and add a check to ensure that we never ever set an unsupported interlaced bit. Ensure that userspace can't set an interlaced mode by resetting interlace_allowed for the crt on gen2. dvo and lvds are the only other encoders that gen2 supports and these already disallow interlaced modes. Reviewed-by:
-
Daniel Vetter authored
According to Paulo Zanoni, this is what windows does. Reviewed-by:
-
Daniel Vetter authored
According to bspec, we need to subtract an additional line from vtotal for interlaced modes and vblank_end needs to equal vtotal. All other timing fields do not need this special treatment, so kill it. Bspec says that this is irrespective of whether the interlaced mode has an odd or even vtotal, both modes are supported. Reviewed-by:
-
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:
-
Daniel Vetter authored
- Clarify which bits are for which chips. - Note that gen2 can't do interlaced directly (only via dvo tv chips). - Move the mask to the top to make it clearer how wide this field is. - Add defintions for all possible values. This patch doesn't change any code. v2: Paulo Zanoni pointed out that the pixel doubling modes do no longer exist on ivb. Cc: Peter Ross <pross@xvid.org> Reviewed-by:
-
Daniel Vetter authored
Back-merge from drm-fixes into drm-intel-next to sort out two things: - interlaced support: -fixes contains a bugfix to correctly clear interlaced configuration bits in case the bios sets up an interlaced mode and we want to set up the progressive mode (current kernels don't support interlaced). The actual feature work to support interlaced depends upon (and conflicts with) this bugfix. - forcewake voodoo to workaround missed IRQ issues: -fixes only enabled this for ivybridge, but some recent bug reports indicate that we need this on Sandybridge, too. But in a slightly different flavour and with other fixes and reworks on top. Additionally there are some forcewake cleanup patches heading to -next that would conflict with currrent -fixes. Signed-Off-by: -
Dave Airlie authored
Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux into drm-fixes * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux: drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2) drm/i915: no lvds quirk for AOpen MP45 drm/i915: Force explicit bpp selection for intel_dp_link_required drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT drm/i915:: Disable FBC on SandyBridge
-
- 09 Feb, 2012 9 commits
-
-
Daniel Vetter authored
We want to unconditionally enable ppgtt for two reasons: - Windows uses this on snb and later. - We need the basic hw support to work before we can think about real per-process address spaces and other cool features we want. But Chris Wilson was complaining all over irc and intel-gfx that this will blow up if we don't have a module option to disable it. Hence add one, to prevent this. ppgtt support seems to slightly change the timings and make crashy things slightly more or less crashy. Now in my testing and the testing this got on troublesome snb machines, it seems to have improved things only. But on ivb it makes quite a few crashes happen much more often, see https://bugs.freedesktop.org/show_bug.cgi?id=41353 Luckily Eugeni Dodonov seems to have a set of workarounds that fix this issue. v2: Don't try to enable ppgtt on pre-snb. v3: Pimp commit message and make Chris Wilson less grumpy by adding a module option. v4: New try at making Chris Wilson happy. Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
-
Daniel Vetter authored
This was pretty usefull for debugging, might be useful for diagnosing issues. Reviewed-by:
-
Daniel Vetter authored
Split out for easier cross-checking of the boring pieces with bspec. Reviewed-by:
-
Daniel Vetter authored
This adds support to bind/unbind objects and wires it up. Objects are only put into the ppgtt when necessary, i.e. at execbuf time. Objects are still unconditionally put into the global gtt. v2: Kill the quick hack and explicitly pass cache_level to ppgtt_bind like for the global gtt function. Noticed by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
This just adds the setup and teardown code for the ppgtt PDE and the last-level pagetables, which are fixed for the entire lifetime, at least for the moment. v2: Kill the stray debug printk noted by and improve the pte definitions as suggested by Chris Wilson. v3: Clean up the aperture stealing code as noted by Ben Widawsky. v4: Paint the init code in a more pleasing colour as suggest by Chris Wilson. v5: Explain the magic numbers noticed by Ben Widawsky. Reviewed-by:
-
Daniel Vetter authored
We need this because ppgtt page directory entries need to be in the global gtt pagetable. Reviewed-by:
-
Daniel Vetter authored
To implement a PPGTT for drm/i915 that fully aliases the GTT, we also need to properly alias the scratch page. Reviewed-by:
-
Daniel Vetter authored
Chris Wilson and me have again stared at funny error states and it's been pretty clear from the start that something was seriously amiss. The seqnos last seen by the cpu were a few hundred behind those that the gpu could have possibly emitted last before it died ... Chris now tracked it down (hopefully, definit verdict's still out), but in hindsight we'd have found the bug by simply dumping the cpu side tracking of the ring head and tail registers. Fix this and prevent an identical time-waster in the future. Because the hangs always involved semaphores in one way or another, we've tried to dump the mbox registers, but couldn't find any inconsistencies. Still, dump them too. Reviewed-and-wanted-by:
-
Daniel Vetter authored
These are all user-trigerable, so tune down their loudness a notch. For some of these we have i-g-t tests (because they prevent newly-discovered bugs), without this patches running the test suite leaves behind a dirty dmesg. Reviewed-by:
-
- 08 Feb, 2012 5 commits
-
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
On gen5 we also need to correctly set up swizzling in the display scanout engine, but only there. Consolidate this into the same function. This has a small effect on ums setups - the kernel now also sets this bit in addition to userspace setting it. Given that this code only runs when userspace either can't (resume, gpu reset) or explicitly won't(gem_init) touch the hw this shouldn't have an adverse effect. Reviewed-by:
-
Daniel Vetter authored
We have to do this manually. Somebody had a Great Idea. I've measured speed-ups just a few percent above the noise level (below 5% for the best case), but no slowdows. Chris Wilson measured quite a bit more (10-20% above the usual snb variance) on a more recent and better tuned version of sna, but also recorded a few slow-downs on benchmarks know for uglier amounts of snb-induced variance. v2: Incorporate Ben Widawsky's preliminary review comments and elaborate a bit about the performance impact in the changelog. v3: Add a comment as to why we don't need to check the 3rd memory channel. v4: Fixup whitespace. Acked-by:
Eric Anholt <eric@anholt.net> Signed-Off-by:
-
Keith Packard authored
An identical patch has been merged for i9xx_crtc_mode_set: Commit 59df7b17 Author: Christian Schmidt <schmidt@digadd.de> Date: Mon Dec 19 20:03:33 2011 +0100 drm/intel: Fix initialization if startup happens in interlaced mode [v2] But that one neglected to fix up the ironlake+ path. This should fix the issue reported by Alfonso Fiore where booting with only a HDMI cable connected to his TV failed to display anything. The issue is that the bios set up things for 1080i and used the pannel fitter to scale up the lower progressive resolutions. We failed to clear the interlace bit in the PIPEACONF register, resulting in havoc. v2: Be more paranoid and just unconditionally clear the field before setting new values. Cc: Peter Ross <pross@xvid.org> Cc: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by:
Keith Packard <keithp@keithp.com>
-
Daniel Vetter authored
According to a bug report, it doesn't have one. Cc: stable@kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263Acked-by:
-
- 06 Feb, 2012 1 commit
-
-
Keith Packard authored
It is never correct to use intel_crtc->bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly. Fixing that will require more extensive changes, and so must be addressed separately from this bugfix. intel_dp_link_required is called from intel_dp_mode_valid and intel_dp_mode_fixup. * intel_dp_mode_valid is called to list supported modes; in this case, the current crtc values cannot be relevant as the modes in question may never be selected. Thus, using intel_crtc->bpp is never right. * intel_dp_mode_fixup is called during mode setting, but it is run well before ironlake_crtc_mode_set is called to set intel_crtc->bpp, so using intel_crtc-bpp in this path can only ever get a stale value. Cc: Lubos Kolouch <lubos.kolouch@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: stable@vger.kernel.org Reviewed-by:
Dave Airlie <airlied@redhat.com> Tested-by: camalot@picnicpark.org (Dell Latitude 6510) Tested-by:
Roland Dreier <roland@digitalvampire.org> Signed-off-by:
-
- 03 Feb, 2012 2 commits
-
-
Matthijs Kooijman authored
This return statement got dropped while fixing the conflicts introduced in 7a7e8734. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Julia Lawall authored
The c32 structure is allocated on the stack and its idx field is not initialized before copying it to user level. This patch takes the value from the result of the ioctl, as done for the other fields. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
- 02 Feb, 2012 13 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: rbd: fix safety of rbd_put_client() rbd: fix a memory leak in rbd_get_client() ceph: create a new session lock to avoid lock inversion ceph: fix length validation in parse_reply_info() ceph: initialize client debugfs outside of monc->mutex ceph: change "ceph.layout" xattr to be "ceph.file.layout"
-
Josh Triplett authored
Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alex Elder authored
The rbd_client structure uses a kref to arrange for cleaning up and freeing an instance when its last reference is dropped. The cleanup routine is rbd_client_release(), and one of the things it does is delete the rbd_client from rbd_client_list. It acquires node_lock to do so, but the way it is done is still not safe. The problem is that when attempting to reuse an existing rbd_client, the structure found might already be in the process of getting destroyed and cleaned up. Here's the scenario, with "CLIENT" representing an existing rbd_client that's involved in the race: Thread on CPU A | Thread on CPU B --------------- | --------------- rbd_put_client(CLIENT) | rbd_get_client() kref_put() | (acquires node_lock) kref->refcount becomes 0 | __rbd_client_find() returns CLIENT calls rbd_client_release() | kref_get(&CLIENT->kref); | (releases node_lock) (acquires node_lock) | deletes CLIENT from list | ...and starts using CLIENT... (releases node_lock) | and frees CLIENT | <-- but CLIENT gets freed here Fix this by having rbd_put_client() acquire node_lock. The result could still be improved, but at least it avoids this problem. Signed-off-by:Alex Elder <elder@dreamhost.com> Signed-off-by:
Sage Weil <sage@newdream.net>
-
Christopher Yeoh authored
This fixes the race in process_vm_core found by Oleg (see http://article.gmane.org/gmane.linux.kernel/1235667/ for details). This has been updated since I last sent it as the creation of the new mm_access() function did almost exactly the same thing as parts of the previous version of this patch did. In order to use mm_access() even when /proc isn't enabled, we move it to kernel/fork.c where other related process mm access functions already are. Signed-off-by:
Chris Yeoh <yeohc@au1.ibm.com> Signed-off-by:
-
Alex Elder authored
If an existing rbd client is found to be suitable for use in rbd_get_client(), the rbd_options structure is not being freed as it should. Fix that. Signed-off-by:
-
Alex Elder authored
Lockdep was reporting a possible circular lock dependency in dentry_lease_is_valid(). That function needs to sample the session's s_cap_gen and and s_cap_ttl fields coherently, but needs to do so while holding a dentry lock. The s_cap_lock field was being used to protect the two fields, but that can't be taken while holding a lock on a dentry within the session. In most cases, the s_cap_gen and s_cap_ttl fields only get operated on separately. But in three cases they need to be updated together. Implement a new lock to protect the spots updating both fields atomically is required. Signed-off-by:
-
Xi Wang authored
"len" is read from network and thus needs validation. Otherwise, given a bogus "len" value, p+len could be an out-of-bounds pointer, which is used in further parsing. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Sage Weil authored
Initializing debufs under monc->mutex introduces a lock dependency for sb->s_type->i_mutex_key, which (combined with several other dependencies) leads to an annoying lockdep warning. There's no particular reason to do the debugfs setup under this lock, so move it out. It used to be the case that our first monmap could come from the OSD; that is no longer the case with recent servers, so we will reliably set up the client entry during the initial authentication. We don't have to worry about racing with debugfs teardown by ceph_debugfs_client_cleanup() because ceph_destroy_client() calls ceph_msgr_flush() first, which will wait for the message dispatch work to complete (and the debugfs init to complete). Fixes: #1940 Signed-off-by: -
Alex Elder authored
The virtual extended attribute named "ceph.layout" is meaningful only for regular files. Change its name to be "ceph.file.layout" to more directly reflect that in the ceph xattr namespace. Preserve the old "ceph.layout" name for the time being (until we decide it's safe to get rid of it entirely). Add a missing initializer for "readonly" in the terminating entry. Signed-off-by:
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon/kms/blit: fix blit copy for very large buffers drm/radeon/kms: fix TRAVIS panel setup drm/radeon: fix use after free in ATRM bios reading code. drm/radeon/kms: Fix device tree linkage of DP i2c buses too drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height. drm/radeon/kms: disable output polling when suspended drm/nv50/pm: signedness bug in nv50_pm_clocks_pre() drm/nouveau/gem: fix fence_sync race / oops drm/nouveau: fix typo on mxmdcb option drm/nouveau/mxm: pretend to succeed, even if we can't shadow the MXM-SIS drm/nouveau/disp: check that panel power gpio is enabled at init time
-
git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds authored
* 'next' of git://git.monstr.eu/linux-2.6-microblaze: Revert "microblaze: Add topology init"
-
Linus Torvalds authored
Merge branches 'core-urgent-for-linus', 'perf-urgent-for-linus', 'sched-urgent-for-linus' and 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: bugs, x86: Fix printk levels for panic, softlockups and stack dumps * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf top: Fix number of samples displayed perf tools: Fix strlen() bug in perf_event__synthesize_event_type() perf tools: Fix broken build by defining _GNU_SOURCE in Makefile x86/dumpstack: Remove unneeded check in dump_trace() perf: Fix broken interrupt rate throttling * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW sched: Fix ancient race in do_exit() sched/nohz: Fix nohz cpu idle load balancing state with cpu hotplug sched/s390: Fix compile error in sched/core.c sched: Fix rq->nr_uninterruptible update race * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/reboot: Remove VersaLogic Menlow reboot quirk x86/reboot: Skip DMI checks if reboot set by user x86: Properly parenthesize cmpxchg() macro arguments
-
Ilija Hadzic authored
Evergreen and NI blit copy was broken if the buffer maps to a rectangle whose one dimension is 16384 (max dimension allowed by these chips). In the mainline kernel, the problem is exposed only when buffers are very large (1G), but it's still a problem. The problem could be exposed for smaller buffers if anyone modifies the algorithm for rectangle construction in r600_blit_create_rect() (the reason why someone would modify that algorithm is to tune the performance of buffer moves). The root cause was in i2f() function which only operated on range between 0 and 16383. Fix this by extending the range of i2f() function to 0 to 32767. While at it improve the function so that the range can be easily extended in the future (if it becomes necessary), cleanup lines over 80 characters, and replace in-line comments with one strategic comment that explains the crux of the function. Credits to michel@daenzer.net for pointing out the root cause of the bug. v2: Fix I2F_MAX_INPUT constant definition goof and warn only once if input argument is out of range. Edit the comment a little bit to avoid some linguistic confusion and make it look better in general. Signed-off-by:Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by:
Michel Dänzer <michel@daenzer.net> Signed-off-by:
-
