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.
Bug exists since kernel v3.6:
commit b4ae3f22d2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jun 14 11:04:48 2012 -0700
drm/i915: load boot context at driver init time
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>
intel_enable_rc6() is used to check if we can compute the RC6 residency
in the sysfs code. Disable this for platforms older than Ironlake.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Put the comment a bit closer to the actual write (Paulo Zanoni)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Fix space before tab.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We also wait for that blank on other platforms but the w/a doesn't
apply there. Not an issue at all.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the moment we have the following interrupt enabling sequence:
1. irq preinstall hook
2. enabling the interrupt handler and calling irq postinstall hook
3. enable rps interrupts from the async work
And the folliwing disable sequence:
1. disabling the interrupt handler and calling the uninstall hook
2. disabling the rps interrupt
Since the postinstall hook now always sets up PMIIR, PMIER and PMIMR
to known-good states there no way for an interrupt to sneak in in the
enable sequence, so we can reinstate the WARN lost in
commit eda63ffb90
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:26 2013 -0700
drm/i915: Add PM regs to pre/post install
Note that there's some room for future cleanups since most of the
interrupt register clearing in the disable function is rather
redundant. But that's better done in follow-up patches, if at all.
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VECS enabling required some changes to how rps interrupts are
enabled/disabled since VECS interrupts are handling with the PM
interrupt registers.
But now that the pre/postinstall sequences is identical for all
platforms with rps support (snb, ivb, hsw, vlv) we can also use the
exact same sequence to actually enable the rps interrupts. Strictly
speaking using spinlocks is overkill on snb/ivb & vlv since they have
no VECS ring, but imo that's more than made up by the common code.
Hence this just unifies the vlv code with the snb-hsw code which
matched exactly before the VECS enabling. See
commit eda63ffb90
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:26 2013 -0700
drm/i915: Add PM regs to pre/post install
and
commit 4848405cce
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:27 2013 -0700
drm/i915: make PM interrupt writes non-destructive
for why the gen6 code (shared between snb, ivb and hsw) needed to be
changed originally.
v3: Improve the commit message to more clearly spell out why we want
to unify the code and what exactly changes.
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again extract a common helper. For the postinstall hook things are a
bit more complicated since we have more cases on ilk-hsw/vlv here.
But since vlv was clearly broken by failing to initialize
dev_priv->gt_irq_mask correctly the shared code is clearly justified.
Also kill the PMIER setting in the async rps enable work. I should
have been save, but also clearly looked rather fragile. PMIER setup is
now all down in the irq pre/postinstall hooks.
With this we now have the usual interrupt register sequence for GT/PM
irq registers:
- IER is setup once with all the interrupts we ever need in the
postinstall hook and never touched again. Exceptions are SDEIER,
which is touched in the preinstall hook (when the irq handler isn't
enabled) and then only from the irq handler. And DEIER/VLV_IER with
is used in the irq handler but also written to once in the
postinstall hook. But since that write is essentially what enables
the interrupt and we should always have MSI interrupts we should be
save. In case we ever have non-MSI interrupts we'd be screwed.
- IIR is cleared in the postinstall hook before we enable/unmask the
respective interrupt sources. Hence we can't steal an interrupt
event an accidentally trigger the spurious interrupt logic in the
core kernel. Note that after some discussion with Ben Widawsky we
think that we actually should clear the IIR registers in the
preinstall hook. But doing that is a much larger patch series.
- IMR regs are (usually) all masked off. Those are the only regs
changed at runtime, which is all protected by dev_priv->irq_lock.
This unification also kills the cargo-culted read-modify-write PM
register setup for VECS. Interrupt setup is done without userspace
being able to interfere, so we better know what values we want to put
into those registers. RMW cycles otoh are really good at papering over
races, until stuff magically blows up and no one has a clue why.
v2: Touch the gen6+ PM interrupt registers only on gen6+.
v3: Improve the commit message to more clearly spell out why we want
to unify the code and what exactly changes.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a comment to explain why the l3 parity interrupt is
special.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the rps interrupt locking isn't clearly separated (at elast
conceptually) from all the other interrupt locking having a different
lock stopped making sense: It protects much more than just the rps
workqueue it started out with. But with the addition of VECS the
separation started to blurr and resulted in some more complex locking
for the ring interrupt refcount.
With this we can (again) unifiy the ringbuffer irq refcounts without
causing a massive confusion, but that's for the next patch.
v2: Explain better why the rps.lock once made sense and why no longer,
requested by Ben.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch partially reverts commit 36ec8f8774 for
IvyBridge CPUs.
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>
Soon we want to gut a lot of our existing assumptions how many address
spaces an object can live in, and in doing so, embed the drm_mm_node in
the object (and later the VMA).
It's possible in the future we'll want to add more getter/setter
methods, but for now this is enough to enable the VMAs.
v2: Reworked commit message (Ben)
Added comments to the main functions (Ben)
sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch]
(Daniel)
v3: Rebased on new reserve_node patch
Changed DRM_DEBUG_KMS to actually work (will need fixing later)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depends upon the magic sign extension rules in C. This has
been added in
commit 3727d55e4d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed May 8 10:45:14 2013 -0700
drm/i915: allow stolen, pre-allocated objects to avoid GTT allocation v2
Use a proper #define instead. Spotted while reviewing Ben's
drm_mm_create_block changes.
v2: Cast the constant to u32 since otherwise we again have a type
mismatch. Suggested by Chris Wilson.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use wait_for() instead of the open coded loop to avoid spreading the
same old timeout related bugs.
This changes the loop to use msleep(1) instead of udelay(10) when the
Punit had not yet completed the frequency change. In practice that
doesn't seem to hurt performance as the Punit appears to be ready pretty
much always.
Also give the status bit a name, instead of using the magic number 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>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Damien's FBC_CHIP_DEFAULT no fbc
reason.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A genuine 'static' omission and 2 other warnings triggered by not
including the header where those functions where defined.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When running on my snb machine, recent kernels display successively:
[drm:intel_update_fbc], fbc set to per-chip default
[drm:intel_update_fbc], fbc disabled per module param
But no module param is set. This happens because the check for the
module parameter uses a variable that has been overridden inside the
"per-chip default" code.
Fix up the logic and add another reason for the FBC to the be disabled.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function has no user outside of intel_pm.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently print a DRM_DEBUG_KMS message on the happy path and don't
print anything on the "failed to allocate" path. On some desktop
environments (e.g., Unity) I see the "scheduling delayed FBC enable"
thousands and thousands of times on my dmesg.
So kill the useless message for the happy case, saving a lot of dmesg
space, and properly signal the "kzalloc fail" case.
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>
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>
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>
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>
Always print both the MHz value and raw register value for rps stuff.
Also kill a somewhat pointless local 'rpe' variable and just use
dev_priv->rps.rpe_delay.
While at it clean up the caps in "GPU" and "Punit" debug messages.
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>
No need to apply WaForceL3Serialization:vlv twice.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The specs are a bit unclear whether the per-plane trickle feed disable
control exists on VLV. There is another trickle feed disable control
in the MI_ARB register.
After some experimentation it turns out both the DSPCNTR trickle feed
bits and the MI_ARB bit can be toggled. However the DSPCNTR bits don't
seem to have any effect.
The MI_ARB bit, on the other hand, has a noticable effect. I performed
an experiment where I reduced the FIFO size via DSPARB and observed the
effect of the MI_ARB trickle feed bit on the display.
Using a 1920x1080-60 mode, with MI_ARB=0x4 the display started to have
problems with DSPARB=0x42424242, whereas with MI_ARB=0x0 the problems
didn't start until DSPARB=0x09090909. This seems to confirm that the
MI_ARB trickle feed bit actually does work.
So replace the use of the DSPCNTR trickle feed bits with MI_ARB
on VLV.
v2: Amend commit message with results from experimentation
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>
WaFbcNukeOn3DBlt for IVB, HSW.
According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC.
Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that
follows each render submission."
v2: Chris noticed that flush_domains check was missing here and also suggested to do
LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the
module parameter check.
v3: Adding Wa name as Damien suggested.
v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from spec.
v5: Ville noticed than on blt a Cache Clean LRI should be used instead the Nuke one.
v6: Check for flush domain on blt (by Ville).
Check for scanout dirty (by Chris).
v7: Apply proper fbc_dirty implemented by Chris.
v8: remove unused variables.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull the code to disable trickle feed for all primary planes into a
separate function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We disable trickle feed in all the (relevant) clock gating functions,
except ironlake_init_clock_gating(). Copy paste the same code there as
well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to BSpec, trickle feed should be disabled for BW and
mobile CL. Those constraints seem to match all of our gen4 chipsets.
Trickle feed is disabled via the MI_ARB_STATE register instead of
per plane controls on gen4.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The docs say that the trickle feed disable bit is present (for primary
planes only, not video sprites) on CTG, and that it must be set
for ELK. Just set it for all g4x chipsets.
v2: Do it in init_clock_gating too
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
v2: Use gen >= 5, not gen > 4 (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the DSPCLK_GATE_D access for VLV. The code incorrectly tried to
poke at the ILK+ version of the register which is at the wrong offset.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The LP watermark registers don't exist on VLV, so don't touch them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.
Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.
I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).
So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.
v2: Fix up ilk cpu pll handling.
v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.
v4: Rebase on top of Imre's is_cpu_edp removal.
v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
a new place which looked at the pixel_clock and so needed conversion.
v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
on top of the fdi dotclock handling fix in the fdi lanes/bw
computation code.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PM interrupts have an expanded role on HSW. It helps route the EBOX
interrupts. This patch is necessary to make the existing code which
touches the mask, and enable registers more friendly to other code paths
that also will need these registers.
To be more explicit:
At preinstall all interrupts are masked and disabled. This implies that
preinstall should always happen before any enabling/disabling of RPS or
other interrupts.
The PMIMR is touched by the workqueue, so enable/disable touch IER and
IIR. Similarly, the code currently expects IMR has no use outside of the
RPS related interrupts so they unconditionally set 0, or ~0. We could
use IER in the workqueue, and IMR elsewhere, but since the workqueue
use-case is more transient the existing usage makes sense.
Disable RPS events:
IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts
Enable RPS events:
IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events
(really shouldn't happen)
v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in
enable/disable rps functions (Haihao)
v3: Bug found by Chris where we were clearing the wrong bits at rps
disable.
expanded commit message
v4: v3 was based off the wrong branch
v5: Added the setting of PMIMR because of previous patch update
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the moment, these values are wiped out anyway by the rps
enable/disable. That will be changed in the next patch though.
v2: Add post install setup to address issue found by Damien in the next
patch.
replaced
WARN_ON(dev_priv->rps.pm_iir != 0);
with rps.pm_iir = 0;
With the v2 of this patch and the deferred pm enabling (which changed
since the original patches) we're now able to get PM interrupts before
we've brought up enabled rps. At this point in boot, we don't want to do
anything about it, so we simply ignore it. Since writing the original
assertion, the code has changed quite a bit, and I believe removing this
assertion is perfectly safe.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: I don't agree with the justification to drop the WARN and
added a FIXME to that effect.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we compute the results for both 1/2 and 5/6 partitioning and then
use hsw_find_best_result to choose which one to use.
With this patch, Haswell watermarks support should be in good shape.
The only improvement we're missing is the case where the primary plane
is disabled: we always assume it's enabled, so we take it into
consideration when calculating the watermarks.
v2: - Check the latency when finding the best result
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were previously only setting the WM_PIPE registers, now we are
setting the LP watermark registers. This should allow deeper PC
states, resulting in power savings.
We're only using 1/2 data buffer partitioning for now.
v2: Merge both hsw_compute_pri_wm_* functions (Ville)
v3: - Simplify hsw_compute_wm_results (Ville)
- Rebase due to changes on the previous patch
v4: Unconfuse wm_lp/level (Ville)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values.
With this patch, the haswell_update_wm function will set the correct
values for the WM_PIPE registers, but it will still keep all the LP
watermarks disabled.
The patch may look a little bit over-complicated for now, but it's
because much of the infrastructure for setting the LP watermarks is
already in place, so we won't have too much code churn on the patch
that sets the LP watermarks.
v2: - Fix pixel_rate on panel fitter case (Ville)
- Try to not overflow (Ville)
- Remove useless variable (Ville)
- Fix p->pri_horiz_pixels (Paulo)
v3: - Fix rounding errors on hsw_wm_method2 (Ville)
v4: - Fix memcmp bug (Paulo)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell, whenever we change the sprites we need to completely
recalculate all the watermarks, because the sprites are one of the
parameters to the LP watermarks, so a change on the sprites may
trigger a change on which LP levels are enabled.
So on this commit we store all the parameters we need to store for
proper recalculation of the Haswell WMs and then call
haswell_update_wm.
Notice that for now our haswell_update_wm function is not really using
these parameters we're storing, but on the next commits we'll use
these parameters.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because we want to call it from the "sprite disable" paths, since on
Haswell we need to update the sprite watermarks when we disable
sprites.
For now, all this patch does is to add the "enable" argument and call
intel_update_sprite_watermarks from inside ivb_disable_plane. This
shouldn't change how the code behaves because on
sandybridge_update_sprite_wm we just ignore the "!enable" case. The
patches that implement Haswell watermarks will make use of the changes
introduced by this patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We never check the return values, and there's not much we could do on
errors anyway. Just simplify the signatures. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename all VLV IOSF sideband register accessor functions to
vlv_<port>_{read,write}. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Group both the HSW/LPT SBI interface and VLV IOSF sideband register
accessor functions into a new file. No functional changes.
v2: also move intel_sbi_{read,write} (Daniel)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 1544d9d573 added a workaround
inside haswell_init_clock_gating and mentioned it is "a workaround for
early silicon revisions and should be removed later". This workaround
is documented in bit 31 of PRI_CTL. I asked Arthur and he mentioned
that setting FORCE_ARB_IDLE_PLANES replaces that workaround for the
newer machines. So use the new one.
Also notice that there's still another workaround for PRI_CTL that
involves WM_DBG, but it's not the one we're reverting. And notice that
we were previously setting WM_DBG_DISALLOW_MULTIPIPE_LP which disables
the LP watermarks when more than one pipe is used, and we really don't
want this because we need the LP watermarks if we want to reach deeper
PC states.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a comment for the w/a name Ville dug out of Bspec.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And the SNB_READ_WM0_LATENCY macro is not valid anymore because we
have the "New WM0" at 63:56, so the "Old WM0" could maybe be zero if
the new one is not zero.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove the "placeholder" comment and set the actual value described by
the specification. We still don't enable IPS, but it won't hurt to
already have the value set here.
While at it, fully set the register value instead of just masking the
values we're changing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the "*8" calculation to the left side so we don't propagate
rounding errors. Also use DIV_ROUND_CLOSEST because that's what the
spec says we need to do.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of mode->crtc_display. The spec says "pipe horizontal
total number of pixels" and the "Haswell Watermark Calculator" tool
uses the "Pipe H Total" instead of "Pipe H Src" as the value.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The spec says the linetime watermarks must be programmed before
enabling any display low power watermarks, but we're currently
updating the linetime watermarks after we call intel_update_watermarks
(and only at crtc_mode_set, not at crtc_{enable,disable}). So IMHO the
best way guarantee the linetime watermarks will be updated before the
low power watermarks is inside the update_wm function, because it's
the function that enables low power watermarks. And since Haswell is
the only platform that has linetime watermarks, let's completely kill
the "intel_update_linetime_watermarks" abstraction and just use the
intel_update_watermarks abstraction by creating haswell_update_wm.
For now haswell_update_wm is still calling sandybridge_update_wm, but
in the future I plan to implement a function specific to Haswell.
v2: - Rename patch
- Disable LP watermarks before changing linetime WMs (Chris)
- Add a comment explaining that this is just temporary code.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRmpexAAoJEHm+PkMAQRiGrRIH/1uWFW38RvaCV/PXm/ia6Z+x
BfBJfBIvPxGwb4n7aQNQlhU25xkfrPZ6szO4WiBH5/KPH3xYi2I2OZ1AzffkYqMF
BWkPmsPK6EsTdp16zsi6JtH2aXArG4SpYA7ZamPvDkmfigHuiZg7GlL/9eHTRPNV
P7Q8JToOrcnP8RoGgNj0uFiQeQbc62Kmoq7WuPtUhVlpQCCCknXgOJiYgz9w6Xe9
/i79YFS8WRrzAquExT1NbIOh4ZMqB9MvuroaVWy8JDDLUyz7QUvOCe3tCDNguwgi
FdWvU6nfkdQq5SLaWCWXDE9Rp/pL1MvfBn9vCOwFcp42aw0aQ0PgJVIXvsqufd0=
=jgDI
-----END PGP SIGNATURE-----
Merge tag 'v3.10-rc2' into drm-intel-next-queued
Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts
grew a bit out of hand. intel_dp.c has the only real functional
conflict since the logic changed while dev_priv->edp.bpp was moved
around.
Also squash in a whitespace fixup from Ben Widawsky for
i915_gem_gtt.c, git seems to do something pretty strange in there
(which I don't fully understand tbh).
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_dp.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should prevent mode set failures on LPT.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Pimp the w/a tag to fit into Damien's new scheme.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There was a race between Rodrigo writing those patches and me
formalizing the addition of platform tags. This patches fixes it.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
v2: Ville suggested to enable it back when disabling fbc to avoid wasting
power.
v3: RMW to preserve other bits (by Ville)
v4: Fix from Ville: sed &/| at RMW
v5: Too far on sed.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Insert missing space that checkpatch spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Display register 420B0h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch introduce Frame Buffer Compression (FBC) support for HSW.
FBC is tied to primary plane A in HSW.
v2: Ville pointed out docs say FBC must be disabled before disabling
the plane on HSW.
v3: Really enabling it by default at HSW.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Display register 42020h bit 9 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
v2: RMW to preserve other bits (by Ville)
v3: Fix from Ville: sed &/| at RMW
v4: Too far on sed.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Display register 42000h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch introduce Frame Buffer Compression (FBC) support for IVB,
without enabling it by default.
It adds a new function gen7_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_IVYBRIDGE checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
v4: Ville pointed out that according to BSpec FBC_CTL bits 0:3 must be 0.
v5: Up to v4 this work was entirely focused on Haswell. However Ville
noticed I could reuse the FBC work done for HSW and get FBC for free
at Ivybridge. So it makes more sense enable FBC for IVB first.
FBC for HSW comming on next patches. We are just not enabling it by
default on IVB.
v6: Fix confused commit name (by Matt Turner).
v7: Remove gtt_offset shift since it is page aligned byte offset (by Ville).
Cc: Matt Turner <mattst88@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create
a special structure for vbt stuff.
v2: Basically conflicts fixes
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases, we may not need GTT address space allocated to a stolen
object, so allow passing -1 to the preallocated function to indicate as
much.
v2: remove BUG_ON(gtt_offset & 4095) now that -1 is allowed (Ville)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
But we need to get the right stolen base and make pre-allocated objects
for BIOS stuff so we don't clobber it. If the BIOS hasn't allocated a
power context, we allocate one here too, from stolen space as required
by the docs.
v2: fix stolen to phys if ladder (Ben)
keep BIOS reserved space out of allocator altogether (Ben)
v3: fix mask of stolen base (Ben)
v4: clean up preallocated object on unload (Ben)
don't zero reg on unload (Jesse)
fix mask harder (Jesse)
v5: use unref for freeing stolen bits (Chris)
move alloc/free to intel_pm.c (Chris)
v6: NULL pctx at disable time so error paths work (Ben)
v7: use correct PCI device for config read (Jesse)
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the calculated FBC watermark is no good, we simply disable FBC
watermarks. But we fail to re-enable them later if the calculated
watermark becomes good again. Fix that, but remember to leave FBC
watermarks disabled on ILK since that's required by some workarounds.
v2: Fix checkpatch complaint
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For the device to enter D3 we should enable PCH clock gating.
v2:
- use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo)
- rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We did not mention the workaround name when implementing those. This
should help us track what we already implement.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also allows us to easily
add new domains in case we need.
v2: Add more domains to enum intel_display_power_domain
v3: Even more domains requested
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both the docs and the existing code were wrong. So fix both and use a
switch statement like we do elsewhere to make things simple & clear.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the incorrect enabled pipes mask for pipe C in the WM calculations.
Additionally, in an effort to make the code easier to understand,
populate the mask with 1 << PIPE_[ABC] instead of raw numbers.
v2: Use 1 << PIPE_[ABC] (ickle/danvet)
v3: Pass PIPE_[ABC] to g4x_compute_wm0() (ickle)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of repeatedly bombarding the user with a request to reboot and
increase the stolen size with every fb refresh, just inform them the
first time only.
v2: Rearrange code so the hint to increase the amount of memory stolen
by the BIOS is only emitted if we fail to find sufficient stolen memory
for FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup formatting code mismatch that gcc spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally add a WARN_ON to ensure we obey that piece of ordering
constraint. Long term I want to lock down the setup/teardown code in a
similar way to how we painstakingly check modeset sequence constraints
already.
v2: Disable polling after hpd handling is shut down - since Egbert's
hpd irq storm handling the hotplug work can re-arm the polling
handler. Spotted by Jani Nikula.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't want to write reserved regs here, and may want to do other bits
in the future, so split it out.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville noticed this while doing another review; we may as well cancel
this work just to make sure we don't try anything fancy after disabling
the RPS interfaces.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt handler. It'll generally only fire when we go idle
(or if for some reason there's a long delay between RPS interrupts), but
won't be re-armed again until the next RPS event, so shouldn't affect
power consumption after we go idle and it triggers.
v2: use delayed work instead of timer + work queue combo (Ville)
v3: fix up delayed work cancel (must be outside lock) (Daniel)
fix up delayed work handling func for delayed work (Jesse)
v4: cancel delayed work before RPS shutdown (Jani)
pass delay not absolute time to mod_delayed_work (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit fec46b5eff.
The latest version of our PM programming doc (which is WAY better than
previous versions, and thanks for that) says something along the lines
of, "On Haswell overclocking is no long achieved via mailbox registers."
Which I misinterpreted as, the driver must done something different than
it did on IVB, and SNB.
It appears I jumped the gun, and that's all false. We've gotten some
clarification, and it appears at least *reading* the overclocking
information works in exactly the same manner.
Cc: kim.l.saw-chu@intel.com
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calculation (Ben)
clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
put RP and RC regs together (Jesse)
fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
split out min/max funcs for use in sysfs (Jesse)
add debugfs & sysfs freq controls (Jesse)
v7: update with Ben's hw_max changes (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
[danvet: Follow checkpatch sugggestion to use min_t to avoid casting
fun.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.
This should fix some machines that were showing black screens on all
outputs.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.
v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It returns true if we've requested to turn the power well on and it's
really on. It also returns true for all the previous gens.
For now there's just one caller, but I'm going to add more.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.
In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.
In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.
v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)
Reported-by: freezer from #intel-gfx on irc
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
be bad for CPU" range when we have PCH_NOP.
There is a bit of a hack in init clock gating. We want to do most of the
clock gating, but the part we skip will hang the system. It could
probably be abstracted a bit better, but I don't feel it's too
unsightly.
v2: Use inverse HAS_PCH_NOP check (Jani)
v3: Actually do what I claimed in v2 (spotted by Daniel)
Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
Move LVDS bail into this patch (Ben)
v4: logical rebase conflict resolution with SDEIIR (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Brush up patch a bit and resolve conflicts:
- Adjust PCH_NOP checks due to Egbert's hpd handling rework.
- Addd a PCH_NOP check in the irq uninstall code.
- Resolve conflicts with Paulo's SDE irq handling race fix.
v5: Drop the added hunks in the ilk irq handler again, they're bogus.
OOps.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRWLTrAAoJEHm+PkMAQRiGe8oH/iMy48mecVWvxVZn74Tx3Cef
xmW/PnAIj28EhSPqK49N/Ow6AfQToFKf7AP0ge20KAf5teTq95AY+tH74DAANt8F
BjKXXTZiR5xwBvRkq7CR5wDcCvEcBAAz8fgTEd6SEDB2d2VXFf5eKdKUqt1avTCh
Z6Hup5kuwX+ddtwY2DCBXtp2n6fL0Rm5yLzY1A3OOBye1E7VyLTF7M5BR603Q44P
4kRLxn8+R7jy3hTuZIhAeoS8TKUoBwVk7DmKxEzrhTHZVOmvwE9lEHybRnIyOpd/
k1JnbRbiPsLsCVFOn10SQkGDAIk00lro3tuWP2C1ljERiD/OOh5Ui9nXYAhMkbI=
=q15K
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc5' into drm-intel-next-queued
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups
for -next, but they will conflict all over the place with
commit 9d1a455b0c
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Mar 18 11:25:36 2013 +0100
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
from -fixes.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed.
drivers/gpu/drm/i915/intel_panel.c: A field rename in -next
conflicts with a bugfix in -fixes. Take the version from
-fixes and apply the rename.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't need this until we start using the wait event commands.
v2: move to i915_irq.c (Jesse)
drop unneeded sprite flip done enables (Ville)
v3: drop the DPFLIPSTAT enables altogether (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add checkpatch bikeshed about missing space.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to HSW PM programming guide, frequency bits starts at
24 instead of 25.
v2: Paulo Zanoni noticed that only frequency bits can be set at
GEN6_RPNSWREQ. All others are read only.
CC: Ben Widawsky <ben@bwidawsk.net>
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HSW doesn't overclock the same way as IVB or SNB. I do not know about
VLV, so I've kept that off as well. I'm still working on getting the doc
updates to explain how we overclock on Haswell.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add missing () spotted by Wu Fengguang's kernel build robot.
Acked by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're still not 100% ready to disable the power well, so don't disable
it for now. When we disable it we break the audio driver (because some
of the audio registers are on the power well) and machines with eDP on
port D (because it doesn't use TRANSCODER_EDP).
Also, instead of just reverting the code, add a Kernel option to let
us disable it if we want. This will allow us to keep developing and
testing the feature while it's not enabled.
This fixes problems caused by the following commit:
commit d6dd9eb1d9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jan 29 16:35:20 2013 -0200
drm/i915: dynamic Haswell display power well support
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec mentions this for HSW+. I can't quite tell what the effects are,
and I don't easily have a way to test this.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change the gen6+ max delay if the pcode read was successful (not the
inverse).
The previous code was all sorts of wrong and has existed since I broke
it:
commit 42c0526c93
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Sep 26 10:34:00 2012 -0700
drm/i915: Extract PCU communication
I added some parentheses for clarity, and I also corrected the debug
message message to use the mask (wrong before I came along) and added a
print to show the value we're changing from.
Looking over the code, I'm not actually sure what we're trying to do. I
introduced the bug simply by extracting the function not implementing
anything new. We already set max_delay based on the capabilities
register (which is what we use elsewhere to determine min and max).
This would potentially increase it, I suppose? Jesse, I can't find the
document which explains the definitions of the pcode commands, maybe you
have it around.
Based on Jesse's response, this could potentially be for -fixes, or
stable, or maybe lead to us dropping it entirely. As the current code is
is, things won't completely break because of the aforementioned
capabilities register, and in my experimentation, enabling this has no
effect, it goes from 1100->1100.
I found this while reviewing Jesse's VLV patches.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Bikeshed-away the redudant parens spotted by Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll re-enable select bits as needed after testing and power measurement.
v2: split out wake handling bits (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can prevent a hang when we get to tessellation. We need to set bit 15
as well for this workaround.
v2: update changelog with accurate info
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We could split this out into a separate routine at some point as an
optimization.
v2: use FORCEWAKE_KERNEL (Ville)
Note: Ville mentioned in his review that he declines to be responsible
if this blows up due to the lack of "readback a register != FW_ACK,
but from the same cacheline" magic we have in other forcewake
implementations.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Bikeshed overtly long lines according to checkpatch.pl. Nope,
this time around I didn't screw up printk message since I've left
those alone.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRRkrbAAoJEHm+PkMAQRiGy3oH/jrbHinYs0auurANgx4TdtWT
/WNajstKBqLOJJ6cnTR7sOqwOVlptt65EbbTs+qGyZ2Z2W/Lg0BMenHvNHo4ER8C
e7UbMdBCSLKBjAMKh1XCoZscGv4Exm8WRH3Vc5yP0Hafj3EzSAVLY1dta9WKKoQi
bh7D1ErUlbU1zczA1w5YbPF0LqFKRvyZOwebMCCAKAxv5wWAxmbcPNxVR4sufkjg
k6TkQ2ysgWivZAfy3tJYOcxiEu7ahpZVEuYdlZEJQXHRQUfoNljQlOp4BqKsYUai
5A0kaf2VpKay/7pkhvTfBBcF/jFJ68pYP6gQ2ThNdr0b5kOiAfMWj030Xyngnhg=
=iO9t
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc3' into drm-intel-next-queued
Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce in
commit a321e91b6d
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
The merge itself is just two trivial conflicts:
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're starting to add many IS_HASWELL checks for the power well code,
so add a HAS_POWER_WELL macro to properly document that we're checking
for hardware that has the power down well.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflicts since some converted code was added by
not-yet merged patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
