Daniel Vetter [Wed, 17 Jul 2013 04:55:04 +0000 (06:55 +0200)]
drm/i915: Sanitize shared dpll state
There seems to be no limit to the amount of gunk the firmware can
leave behind. Some platforms leave pch dplls on which are not in
active use at all. The example in the bug report is a Apple Macbook
Pro.
Note that this escape scrunity of the hw state checker until we've
tried to use this enabled, but unused pll since we did only check for
the inverse case of a in-used, but disabled pll.
v2: Add a WARN in the pll state checker which would have caught this
case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66952 Reported-and-tested-by: shui yangwei <yangweix.shui@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix long-standing SNB regression in power consumption after resume v2
This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.
For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.
I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.
Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
References: https://patchwork.kernel.org/patch/2827634/ (patch v1) Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a
cc: stable.] Cc: stable@vger.kernel.org (Note: tiny conflict due to the addition of
the backlight lock in 3.11) Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1) Tested-by: rocko <rockorequin@hotmail.com> (v1) Tested-by: JohnMB <johnmbryant@sky.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: factor out GMCH panel fitting code and use for eDP v3
broke that by reordering the computation of the gmch pfit state with
the block of code that prepared the adjusted mode for it and told the
modeset core not to overwrite the adjusted mode with default settings.
We might want to switch around the core code to just fill in defaults,
but this code predates the pipe_config modeset rework. And in the old
crtc helpers we did not have a suitable spot to do this.
Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Hans de Bruin <jmdebruin@xmsnet.nl> Reported-and-tested-by: Hans de Bruin <jmdebruin@xmsnet.nl> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 11 Jul 2013 11:35:40 +0000 (13:35 +0200)]
drm/i915: fix up readout of the lvds dither bit on gen2/3
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and we've left the dither bit enabled behind us. This can
happen if the BIOS has set the bit (some seem to unconditionally do
that, even in the complete absence of an lvds port), but not enabled
pipe B at boot-up. Then we won't clear the pfit control register since
we can only touch that if the pfit is associated with our pipe in the
crtc configuration - we could trample over the pfit state of the other
pipe otherwise since it's shared. Once pipe B is enabled we notice
that the 6to8 dither bit is set and complain about the mismatch.
Note that testing indicates that we don't actually need to set this
bit when the pfit is disabled, dithering on 18bpp panels seems to work
regardless. But ripping that code out is not something for a bugfix
meant for -rc kernels.
v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
comments from Chris on irc.
v3: Use Chris suggestion to make the control flow in
i9xx_get_pfit_config easier to understand.
v4: Kill the extra line, spotted by Chris.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Cc: Knut Petersen <Knut_Petersen@t-online.de> Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html Tested-by: Knut Petersen <Knut_Petersen@t-online.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Workaround incoherence with fence updates on Valleyview
Jon Bloomfield came up with a plausible explanation and cheap fix
(drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
race condition, so lets run with it.
This is a candidate for stable as the old workaround incurs a
significant cost (calling wbinvd on all CPUs before performing the
register write) for some workloads as noted by Carsten Emde.
Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
References: https://www.osadl.org/?id=1543#c7602
References: https://bugs.freedesktop.org/show_bug.cgi?id=63825 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Carsten Emde <C.Emde@osadl.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.
Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.
v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Carsten Emde <C.Emde@osadl.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 9 Jul 2013 08:22:39 +0000 (09:22 +0100)]
drm/i915: Fix write-read race with multiple rings
Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj->ring would
now point to ring B, but its last_write_seqno would be still relative to
ring A. This would allow for the user to read from the object before the
GPU had completed the write, as set_domain would only check that ring B
had passed the last_write_seqno.
To fix this simply (and inelegantly), we bump the last_write_seqno when
switching rings so that the last_write_seqno is always relative to the
current obj->ring.
This fixes igt/tests/gem_write_read_ring_switch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org
[danvet: Add note about the newly created igt which exercises this
bug.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in a hangup if the system is highly
loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
this condition can result in secondary issues.
v2: Only revert patch for Ivybridge CPUs
Issue info message if mt forcewake is disabled on Ivybridge
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Tue, 9 Jul 2013 14:05:26 +0000 (17:05 +0300)]
drm/i915: fix lane bandwidth capping for DP 1.2 sinks
DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
the driver will treat as an invalid value and use 1.62Gbps instead. Fix
this by capping to 2.7Gbps for sinks reporting a 5.4Gbps max bw.
Also add a warning for reserved values.
v2:
- allow only bw values explicitly listed in the DP standard (Daniel,
Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Implement workaround for broken CS tlb on i830/845
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 3 Jul 2013 10:56:54 +0000 (12:56 +0200)]
drm/i915: reinit status page registers after gpu reset
This fixes gpu reset on my gm45 - without this patch the bsd thing is
forever stuck since the seqno updates never reach the status page.
Tbh I have no idea how this ever worked without rewriting the hws
registers after a gpu reset.
To satisfy my OCD also give the functions a bit more consistent names:
- Use status_page everywhere, also for the physical addressed one.
- Use init for the allocation part and setup for the register setup
part consistently.
Long term I'd really like to share the hw init parts completely
between gpu reset, resume and driver load, i.e. to call
i915_gem_init_hw instead of the individual pieces we might need.
v2: Add the missing paragraph to the commit message about what bug
exactly this patch here fixes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65495 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 2 Jul 2013 08:48:31 +0000 (10:48 +0200)]
drm/i915: Don't try to tear down the stolen drm_mm if it's not there
Every other place properly checks whether we've managed to set
up the stolen allocator at boot-up properly, with the exception
of the cleanup code. Which results in an ugly
*ERROR* Memory manager not clean. Delaying takedown
at module unload time since the drm_mm isn't initialized at all.
v2: While at it check whether the stolen drm_mm is initialized instead
of the more obscure stolen_base == 0 check.
v3: Fix up the logic. Also we need to keep the stolen_base check in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.
v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function (if
we indeed have stolen memory).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953 Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 29 Jun 2013 22:26:50 +0000 (23:26 +0100)]
drm/i915: Break up the large vsnprintf() in print_error_buffers()
So it appears that I have encountered some bogosity when trying to call
i915_error_printf() with many arguments from print_error_buffers(). The
symptom is that the vsnprintf parser tries to interpret an integer arg
as a character string, the resulting OOPS indicating stack corruption.
Replacing the single call with its 13 format specifiers and arguments
with multiple calls to i915_error_printf() worked fine. This patch goes
one step further and introduced i915_error_puts() to pass the strings
simply.
It may not fix the root cause, but it does prevent my box from dying and
I think helps make print_error_buffers() more friendly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66077 Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 29 Jun 2013 21:05:26 +0000 (22:05 +0100)]
drm/i915: Refactor the wait_rendering completion into a common routine
Harmonise the completion logic between the non-blocking and normal
wait_rendering paths, and move that logic into a common function.
In the process, we note that the last_write_seqno is by definition the
earlier of the two read/write seqnos and so all successful waits will
have passed the last_write_seqno. Therefore we can unconditionally clear
the write seqno and its domains in the completion logic.
v2: Add the missing ring parameter, because sometimes it is good to have
things compile.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 28 Jun 2013 15:54:08 +0000 (16:54 +0100)]
drm/i915: Only clear write-domains after a successful wait-seqno
In the introduction of the non-blocking wait, I cut'n'pasted the wait
completion code from normal locked path. Unfortunately, this neglected
that the normal path returned early if the wait returned early. The
result is that read-only waits may return whilst the GPU is still
writing to the bo.
Fixes regression from
commit 3236f57a0162391f84b93f39fc1882c49a8998c7 [v3.7]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 24 09:35:09 2012 +0100
drm/i915: Use a non-blocking wait for set-to-domain ioctl
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Xiong Zhang [Fri, 28 Jun 2013 04:59:06 +0000 (12:59 +0800)]
drm/i915: correct intel_dp_get_config() function for DevCPT
On DevCPT, the control register for Transcoder DP Sync Polarity is
TRANS_DP_CTL, not DP_CTL.
Without this patch, Many call trace occur on CPT machine with DP monitor.
The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X)
v2: use intel-crtc to simple patch, suggested by Daniel.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Extend the encoder->get_config comment to specify that we now
also depend upon intel_encoder->base.crtc being correct. Also bikeshed
s/intel_crtc/crtc/.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 27 Jun 2013 15:52:15 +0000 (17:52 +0200)]
drm/i915: fix hpd interrupt register locking
Our interrupt handler (in hardirq context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in the hardirq context.
Note also that on ilk+ the race isn't just against the hotplug
reenable timer, but also against the fifo underrun reporting. That one
also modifies the SDEIMR register (again protected by the same
dev_priv->irq_lock).
To lock things down again sprinkle a assert_spin_locked. But exclude
the functions touching SDEIMR for now, I want to extract them all into
a new helper function (like we do already for pipestate, display
interrupts and all the various gt interrupts).
v2: Add the missing 't' Egbert spotted in a comment.
v3: Actually fix the right misspelled comment (Paulo).
Cc: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 27 Jun 2013 15:52:14 +0000 (17:52 +0200)]
drm/i915: fold the no-irq check into intel_hpd_irq_handler
The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 27 Jun 2013 15:52:13 +0000 (17:52 +0200)]
drm/i915: fold the queue_work into intel_hpd_irq_handler
Everywhere the same.
Note that this patch leaves unnecessary braces behind, but the next
patch will kill those all anyway (including the if itself) so I've
figured I can keep the diff a bit smaller.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.
To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the end the irq storm handling code will handle all hotplug
logic (and so also encapsulate the locking nicely).
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 27 Jun 2013 11:44:59 +0000 (13:44 +0200)]
drm/i915: close tiny race in the ilk pcu even interrupt setup
By the time we write DEIER in the postinstall hook the interrupt
handler could run any time. And it does modify DEIER to handle
interrupts.
Hence the DEIER read-modify-write cycle for enabling the PCU event
source is racy. Close this races the same way we handle vblank
interrupts: Unconditionally enable the interrupt in the IER register,
but conditionally mask it in IMR. The later poses no such race since
the interrupt handler does not touch DEIMR.
Also update the comment, the clearing has already happened
unconditionally above.
v2: Actually shove the updated comment into the right train^W commit,
as spotted by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 27 Jun 2013 11:44:58 +0000 (13:44 +0200)]
drm/i915: fix locking around ironlake_enable|disable_display_irq
The haswell unclaimed register handling code forgot to take the
spinlock. Since this is in the context of the non-rentrant interupt
handler and we only have one interrupt handler it is sufficient to
just grab the spinlock - we do not need to exclude any other
interrupts from running on the same cpu.
To prevent such gaffles in the future sprinkle assert_spin_locked over
these functions. Unfornately this requires us to hold the spinlock in
the ironlake postinstall hook where it is not strictly required:
Currently that is run in single-threaded context and with userspace
exlcuded from running concurrent ioctls. Add a comment explaining
this.
v2: ivb_can_enable_err_int also needs to be protected by the spinlock.
To ensure this won't happen in the future again also sprinkle a
spinlock assert in there.
v3: Kill the 2nd call to ivb_can_enable_err_int I've accidentally left
behind, spotted by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 26 Jun 2013 04:53:40 +0000 (21:53 -0700)]
drm/i915: Fix context sizes on HSW
With updates to the spec, we can actually see the context layout, and
how many dwords are allocated. That table suggests we need 70720 bytes
per HW context. Rounded up, this is 18 pages. Looking at what lives
after the current 4 pages we use, I can't see too much important (mostly
it's d3d related), but there are a couple of things which look scary. I
am hopeful this can explain some of our odd HSW failures.
v2: Make the context only 17 pages. The power context space isn't used
ever, and execlists aren't used in our driver, making the actual total
66944 bytes.
v3: Add a comment to the code. (Jesse & Paulo)
Reported-by: "Azad, Vinit" <vinit.azad@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 25 Jun 2013 11:16:34 +0000 (14:16 +0300)]
Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"
The PIPECONF color range bit doesn't appear to be effective, on HDMI
outputs at least. The color range bit in the port register works though,
so let's use it.
I have not yet verified whether the PIPECONF bit works on DP outputs.
Ville Syrjälä [Fri, 14 Jun 2013 11:02:52 +0000 (14:02 +0300)]
drm/i915: Fix VLV PLL LPF coefficients for DAC
The current PLL settings produce a rather unstable picture when
I hook up a VLV to my HP ZR24w display via a VGA cable.
According to VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9, we should
use the the same LPF coefficients for DAC as we do for HDMI and RBR DP.
And indeed that seems to cure the shivers.
v2: Add the name of the relevant document to the commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 25 Jun 2013 18:38:11 +0000 (21:38 +0300)]
drm/i915: Jump to at least RPe on VLV when increasing the GPU frequency
If the current GPU frquency is below RPe, and we're asked to increase
it, just go directly to RPe. This should provide better performance
faster than letting the frequency trickle up in response to the up
threshold interrupts.
For now just do it for VLV, since that matches quite closely how VLV
used to operate when the rps delayed timer kept things at RPe always.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 25 Jun 2013 18:38:10 +0000 (21:38 +0300)]
drm/i915: Don't increase the GPU frequency from the delayed VLV rps timer
There's little point in increasing the GPU frequency from the delayed
rps work on VLV. Now when the GPU is idle, the GPU frequency actually
keeps dropping gradually until it hits the minimum, whereas previously
it just ping-ponged constantly between RPe and RPe-1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 25 Jun 2013 16:21:06 +0000 (19:21 +0300)]
drm/i915: GEN6_RP_INTERRUPT_LIMITS doesn't seem to exist on VLV
I can't find GEN6_RP_INTERRUPT_LIMITS (0xA014) anywhere in VLV docs.
Reading it always returns zero from what I can tell, and eliminating
it doesn't seem to make any difference to the behaviour of the system.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 25 Jun 2013 16:21:02 +0000 (19:21 +0300)]
drm/i915: Don't wait for Punit after each freq change on VLV
It seems that even though Punit reports the frequency change to have
been completed, it still reports the old frequency in the status
register for some time.
So rather than polling for Punit to complete the frequency change after
each request, poll before. This gets rid of the spurious "Punit overrode
GPU freq" messages.
This also lets us continue working while Punit is performing the actual
frequency change. As a result, openarena demo088-test1 timedemo average
fps is increased by ~5 fps, and the slowest frame duration is reduced
by ~25%.
The sysfs cur_freq file always reads the current frequency from Punit
anyway, so having rps.cur_delay be slightly off at times doesn't matter.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 25 Jun 2013 16:26:45 +0000 (17:26 +0100)]
drm/i915: Detect invalid scanout pitches
Report back the user error of attempting to setup a CRTC with an invalid
framebuffer pitch. This is trickier than it should be as on gen4, there
is a restriction that tiled surfaces must have a stride less than 16k -
which is less than the largest supported CRTC size.
v2: Fix the limits for gen3
v3: Move check into intel_framebuffer_init() and fix VLV limits. (vsyrjala)
v4: Use idiomatic '>=' for generation checks
References: https://bugs.freedesktop.org/show_bug.cgi?id=65099 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 25 Jun 2013 09:06:52 +0000 (11:06 +0200)]
drm/i915: don't scream into dmesg when a modeset fails
There are legit cases, e.g. when userspace asks for something
impossible. So tune it down to debug output like we do with all other
userspace-triggerable warnings.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111#c5 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Rebased.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 24 Jun 2013 19:33:28 +0000 (21:33 +0200)]
drm/i915: Fix up sdvo hpd pins for i965g/gm
Bspec seems to be full of lies, at least it disagress with reality:
Two systems corrobated that SDVO hpd bits are the same as on gen3.
v2: Update comment a bit.
Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Alex Fiestas <afiestas@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 7 Jun 2013 13:03:50 +0000 (16:03 +0300)]
drm/i915: fix build warning on format specifier mismatch
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville)
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 24 Jun 2013 16:32:36 +0000 (18:32 +0200)]
drm/i915: tune down DIDL warning about too many outputs
Nothing the user (nor we) really can do about this, but upsets a nice
quiet boot.
Note that this happens mostly on SDVs where OEMs obviously haven't had
a chance yet to appropriately trim the output list.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988 Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Amend commit message a bit to clarify a question from Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") makes
certain assumptions about the under laying DMA API that are not always
correct.
On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup
I see:
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
Bit of debugging traced it down to dma_map_sg failing (in
i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB).
That unfortunately are sizes that the SWIOTLB is incapable of handling -
the maximum it can handle is a an entry of 512KB of virtual contiguous
memory for its bounce buffer. (See IO_TLB_SEGSIZE).
Previous to the above mention git commit the SG entries were of 4KB, and
the code introduced by above git commit squashed the CPU contiguous PFNs
in one big virtual address provided to DMA API.
This patch is a simple semi-revert - were we emulate the old behavior
if we detect that SWIOTLB is online. If it is not online then we continue
on with the new compact scatter gather mechanism.
An alternative solution would be for the the '.get_pages' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rui Guo [Wed, 19 Jun 2013 13:10:23 +0000 (21:10 +0800)]
drm/i915: Fix PCH detect with multiple ISA bridges in VM
In some virtualized environments (e.g. XEN), there is irrelevant ISA bridge in
the system. To work reliably, we should scan trhough all the ISA bridge
devices and check for the first match, instead of only checking the first one.
Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
[danvet: Fixup conflict with the num_pch_pll removal. And add
subsystem header to the commit message headline.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:27 +0000 (17:27 -0300)]
drm/i915: fix the "ghost eDP" encoder unwind path
Because calling intel_dp_encoder_destroy inside
intel_edp_init_connector is just wrong. This is the initialization
path, so we should properly unwind all the initialization through the
whole caller stack.
On the intel_dp_encoder_destroy function we do the following:
1 - Call i2c_del_adapter
2 - Call drm_encoder_cleanup
3 - If edp:
3.1 - Cancel panel_vdd_work
3.2 - Call ironlake_panel_vdd_of_sync
4 - Free the encoder
And here is how we unwind each specific step:
1 - We have intel_dp_init_connector -> intel_dp_i2c_init ->
i2c_dp_aux_add_bus -> i2c_add_adapter, so we call
i2c_del_dapter at intel_dp_init_connector
2 - Call it in the same function that called drm_encoder_init
3 - Call it in the same function that called INIT_DELAYED_WORK
4 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:26 +0000 (17:27 -0300)]
drm/i915: fix the "ghost eDP" connector unwind path
Because calling intel_dp_destroy inside intel_edp_init_connector is
just wrong. This is the initialization path, so we should properly
unwind all the initialization through the whole caller stack.
On the intel_dp_destroy function we do the following:
1 - Free edid if it exists
2 - Call intel_panel_fini in case it's eDP
3 - Call drm_sysfs_connector_remove
4 - Call drm_connector_cleanup
5 - Free the connector
And here is how we unwind each specific step:
1 - No need as we still didn't assign anything
2 - No need as we still didn't call intel_panel_init
3 - Call it in the same function that called drm_sysfs_connector_add
4 - Call it in the same function that called drm_connector_init
5 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:25 +0000 (17:27 -0300)]
drm/i915: propagate errors from intel_dp_init_connector
In case we detect a "ghost eDP", intel_edp_init_connector frees both
the connector and encoder and then returns. On Haswell, intel_ddi_init
then tries to use the freed encoder on the HDMI initialization path
since the following commit:
commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 10 23:28:35 2013 +0200
drm/i915: don't setup hdmi for port D edp in ddi_init
So now on intel_ddi_init we check for the "ghost eDP" case and return
without trying to initialize HDMI. This way we won't try to read the
freed "intel_encoder" struct in the next "if" statement.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:23 +0000 (17:27 -0300)]
drm/i915: don't check encoder at DP connector destroy()
By the time we call intel_dp_destroy (which destroys the connector)
the encoder may have been destroyed already, so if we use it we may be
reading some free memory. That happens in drm_mode_config_cleanup()
and also inside intel_dp_init_connector() when we detect a ghost eDP.
I also hope this may solve some random memory bugs.
Reported by kmemcheck.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was rearming the workqueue with a 0 timeout, causing
a WARN_ON, and possible loop.
Daniel writes:
"I've looked a bit into this and I think we need to have a separate
work struct for recovering these lost hotplug events since the
continuous self-rearming case is a real risk (e.g. if a connector
flip-flops all the time). At least I don't see a sane way to block out
re-arming with the current code in a simple way. So reverting the
offender seems like the right thing and I'll go back to the drawing
board for 3.12."
YoungJun Cho [Wed, 26 Jun 2013 01:21:42 +0000 (10:21 +0900)]
drm/prime: add return check for dma_buf_fd
The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Seung-Woo Kim [Wed, 26 Jun 2013 01:21:41 +0000 (10:21 +0900)]
drm/prime: reorder drm_prime_add_buf_handle and remove prototype
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Wed, 26 Jun 2013 01:21:40 +0000 (10:21 +0900)]
drm/prime: fix to put an exported dma_buf for adding handle failure
When drm_prime_add_buf_handle() returns failure for an exported
dma_buf, the dma_buf was already allocated and its refcount was
increased, so it needs to be put.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Joonyoung Shim [Wed, 19 Jun 2013 06:03:05 +0000 (15:03 +0900)]
drm/prime: support to cache mapping
The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.
[airlied: rebased on top of other prime changes] Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Mon, 24 Jun 2013 07:40:53 +0000 (16:40 +0900)]
drm/prime: replace NULL with error value in drm_prime_pages_to_sg
Instead of NULL, error value is casted with ERR_PTR() for
drm_prime_pages_to_sg() and IS_ERR_OR_NULL() macro is replaced
with IS_ERR() macro for drm_gem_map_dma_buf().
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Mon, 24 Jun 2013 06:34:21 +0000 (15:34 +0900)]
drm/prime: fix to check return of dma_map_sg in prime helper
The dma_map_sg(), in map_dma_buf callback operation of prime helper,
can return 0 when it fails to map, so it needs to release related
resources.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Wed, 26 Jun 2013 23:39:58 +0000 (08:39 +0900)]
drm/gem: add mutex lock when using drm_gem_mmap_obj
The drm_gem_mmap_obj() has to be protected with dev->struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds assertion to check whether drm_gem_mmap_obj() is
called with mutex lock or not.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
cli->mutex was inverted with reservations, and multiple reservations were
used without a ticket, fix both. This commit had to be done after the previous
commit, because otherwise ttm_eu_* calls would use a different seqno counter..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/ttm: make ttm reservation calls behave like reservation calls
This commit converts the source of the val_seq counter to
the ww_mutex api. The reservation objects are converted later,
because there is still a lockdep splat in nouveau that has to
resolved first.
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the contents of the dma-buf.
Changes since v1:
- Fix locking issue in ticket_reserve, which could cause mutex_unlock
to be called too many times.
Changes since v2:
- All fence related calls and members have been taken out for now,
what's left is the bare minimum to be useful for ttm locking conversion.
Changes since v3:
- Removed helper functions too. The documentation has an example
implementation for locking. With the move to ww_mutex there is no
need to have much logic any more.
drm/ast: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/mgag200: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:
drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
Having nouveau builtin would still allow ACPI_VIDEO to be used as external module
if some of the deps for acpi_video have not been met, which would result in a linking
failure. Solve this by selecting all dependencies as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/nouveau: complain loudly if buffer is pinned during destruction
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 28 Jun 2013 00:53:23 +0000 (10:53 +1000)]
Merge branch 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux into drm-next
This is the pull request for radeon for 3.11. Highlights include:
- Support for CIK (Sea Islands) asics: 3D, compute, UVD
- DPM (Dynamic Power Management) support for 6xx-SI
- ASPM support for 6xx-SI
- Assorted bug fixes
* 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux: (168 commits)
drm/radeon/SI: fix TDP adjustment in set_power_state
drm/radeon/NI: fix TDP adjustment in set_power_state
drm/radeon: fix endian issues in atombios dpm code
drm/radeon/dpm: fix UVD clock setting on SI
drm/radeon/dpm: fix UVD clock setting on cayman
drm/radeon/dpm: add support for setting UVD clock on rv6xx
drm/radeon/dpm: add support for setting UVD clock on rs780
drm/radeon: fix typo in ni_print_power_state
drm/radeon: fix typo in cik_select_se_sh()
drm/radeon/si: fix typo in function name
drm/radeon/dpm: fix typo in setting uvd clock
drm/radeon/dpm: add dpm_set_power_state failure output (si)
add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_enable failure output (si)
drm/radeon/dpm: add dpm_enable failure output (7xx-ni)
drm/radeon/kms: add dpm support for SI (v7)
drm/radeon: switch SI to use radeon_ucode.h
drm/radeon: add SI to r600_is_internal_thermal_sensor()
drm/radeon/dpm/rs780: properly catch errors in dpm setup
...
Dave Airlie [Thu, 27 Jun 2013 23:50:34 +0000 (09:50 +1000)]
Merge tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Last 3.11 feature pull. I have a few odds bits and pieces and fixes in my
queue, I'll sort them out later on to see what's for 3.11-fixes and what's
for 3.12. But nothing to hold this here up imo.
Highlights:
- more hangcheck work from Mika and Chris to prepare for arb robustness
- trickle feed fixes from Ville
- first parts of the shared pch pll rework, with some basic hw state
readout and cross-checking (this shuts up the confused pch pll refcount
WARN that Linus just recently forwarded)
- Haswell audio power well support from Wang Xingchao (alsa bits acked by
Takashi)
- some cleanups and asserts sprinkling around the plane/gamma enabling
sequence from Ville
- more gtt refactoring from Ben
- clear up the adjusted->mode vs. pixel clock vs. port clock confusion
- 30bpp support, this time for real hopefully
* tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: remove a superflous semi-colon
drm/i915: Kill useless "Enable panel fitter" comments
drm/i915: Remove extra "ring" from error message
drm/i915: simplify the reduced clock handling for pch plls
drm/i915: stop killing pfit on i9xx
drm/i915: explicitly set up PIPECONF (and gamma table) on haswell
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
drm/i915: set up PIPECONF explicitly on ilk-ivb
drm/i915: find guilty batch buffer on ring resets
drm/i915: store ring hangcheck action
drm/i915: add batch bo to i915_add_request()
drm/i915: change i915_add_request to macro
drm/i915: add i915_gem_context_get_hang_stats()
drm/i915: add struct i915_ctx_hang_stats
drm/i915: Try harder to disable trickle feed on VLV
drm/i915: fix up pch pll enabling for pixel multipliers
drm/i915: hw state readout and cross-checking for shared dplls
drm/i915: WARN on lack of shared dpll
drm/i915: split up intel_modeset_check_state
drm/i915: extract readout_hw_state from setup_hw_state
...
projects / linux-beck.git / log