提交 · bd633a7c1ca0663ba10426a0a6aeda0257cbe804 · openeuler / Kernel

23 8月, 2013 20 次提交

drm/i915: fix SDEIMR assertion when disabling LCPLL · bd633a7c

由 Paulo Zanoni 提交于 8月 19, 2013

This was causing WARNs in one machine, so instead of trying to guess
exactly which hotplug bits should exist, just do the test on the
non-HPD bits. We don't care about the state of the hotplug bits, we
just care about the others, that need to be 1.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

bd633a7c

drm/i915: grab force_wake when restoring LCPLL · 215733fa

由 Paulo Zanoni 提交于 8月 19, 2013

If LCPLL is disabled, there's a chance we might be in package C8 state
or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
led lights up on my motherboard). So grab the force_wake, which will
get us out of RC6 and, as a consequence, out of PC8+ (since we need
RC6 to get into PC8+).

Note: Discussions with hw designers are still ongoing what exactly
goes boom here. But I think we can go ahead and just merge this little
hack for now until it's clear what we actually need.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add small note about the current state of the discussion
around this hack.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

215733fa

drm/i915: drop WaMbcDriverBootEnable workaround · 3414caf6

由 Jesse Barnes 提交于 8月 21, 2013

Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.

Note that this seems to break libva on ChromeOS after resumes (but
strangely _not_ after booting up).

This essentially reverts

commit b4ae3f22
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 14 11:04:48 2012 -0700

    drm/i915: load boot context at driver init time

and

commit b3bf0766
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Nov 20 13:27:44 2012 -0200

    drm/i915: implement WaMbcDriverBootEnable on Haswell
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reported-and-Tested-by: NStéphane Marchesin <marcheu@chromium.org>
[danvet: Add note about impact and regression citation.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

3414caf6

drm/i915: Cleaning up the relocate entry function · 5032d871

由 Rafael Barbalho 提交于 8月 21, 2013

As the relocate entry function was getting a bit too big I've moved
the code that used to use either the cpu or the gtt to for the
relocation into two separate functions.
Signed-off-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

5032d871

drm/i915: merge HSW and SNB PM irq handlers · 1403c0d4

由 Paulo Zanoni 提交于 8月 15, 2013

Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does
and also processes the 2 additional VEBOX bits. So merge those
functions and wrap the VEBOX bits on a HAS_VEBOX check. This
check isn't really necessary since the bits are reserved on
SNB/IVB/VLV, but it's a good documentation on who uses them.

v2: - Change IS_HASWELL check to HAS_VEBOX
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

1403c0d4

drm/i915: fix how we mask PMIMR when adding work to the queue · 4d3b3d5f

由 Paulo Zanoni 提交于 8月 09, 2013

It seems we've been doing this ever since we started processing the
RPS events on a work queue, on commit "drm/i915: move gen6 rps
handling to workqueue", 4912d041.

The problem is: when we add work to the queue, instead of just masking
the bits we queued and leaving all the others on their current state,
we mask the bits we queued and unmask all the others. This basically
means we'll be unmasking a bunch of interrupts we're not going to
process. And if you look at gen6_pm_rps_work, we unmask back only
GEN6_PM_RPS_EVENTS, which means the bits we unmasked when adding work
to the queue will remain unmasked after we process the queue.

Notice that even though we unmask those unrelated interrupts, we never
enable them on IER, so they don't fire our interrupt handler, they
just stay there on IIR waiting to be cleared when something else
triggers the interrupt handler.

So this patch does what seems to make more sense: mask only the bits
we add to the queue, without unmasking anything else, and so we'll
unmask them after we process the queue.

As a side effect we also have to remove that WARN, because it is not
only making sure we don't mask useful interrupts, it is also making
sure we do unmask useless interrupts! That piece of code should not be
responsible for knowing which bits should be unmasked, so just don't
assert anything, and trust that snb_disable_pm_irq should be doing the
right thing.

With i915.enable_pc8=1 I was getting ocasional "GEN6_PMIIR is not 0"
error messages due to the fact that we unmask those unrelated
interrupts but don't enable them.

Note: if bugs start bisecting to this patch, then it probably means
someone was relying on the fact that we unmask everything by accident,
then we should fix gen5_gt_irq_postinstall or whoever needs the
accidentally unmasked interrupts. Or maybe I was just wrong and we
need to revert this patch :)

Note: This started to be a more real issue with the addition of the
VEBOX support since now we do enable more than just the minimal set of
RPS interrupts in the IER register. Which means after the first rps
interrupt has happened we will never mask the VEBOX user interrupts
again and so will blow through cpu time needlessly when running video
workloads.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Add note that this started to matter with VEBOX much more.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

4d3b3d5f

drm/i915: don't queue PM events we won't process · 60611c13

由 Paulo Zanoni 提交于 8月 15, 2013

On SNB/IVB/VLV we only call gen6_rps_irq_handler if one of the IIR
bits set is part of GEN6_PM_RPS_EVENTS, but at gen6_rps_irq_handler we
add all the enabled IIR bits to the work queue, not only the ones that
are part of GEN6_PM_RPS_EVENTS. But then gen6_pm_rps_work only
processes GEN6_PM_RPS_EVENTS, so it's useless to add anything that's
not GEN6_PM_RPS_EVENTS to the work queue.

As a bonus, gen6_rps_irq_handler looks more similar to
hsw_pm_irq_handler, so we may be able to merge them in the future.

v2: - Add a WARN in case we queued something we're not going to
      process.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

60611c13

drm/i915: don't disable/reenable IVB error interrupts when not needed · 333a8204