Ville Syrjälä [Thu, 15 May 2014 17:20:36 +0000 (20:20 +0300)]
drm/i915: Draw a picture about video timings
The docs are a bit lacking when it comes to describing when certain
timing related events occur in the hardware. Draw a picture which
tries to capture the most important ones.
v2: Clarify a few details (Imre)
v3: Add HSW+ HDMI scanline counter numbers
Acked-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:50 +0000 (13:35 +0300)]
drm/i915: Improve gen3/4 frame counter
Currently the logic to fix up the frame counter on gen3/4 assumes that
start of vblank occurs at vblank_start*htotal pixels, when in fact
it occurs htotal-hsync_start pixels earlier. Apply the appropriate
adjustment to make the frame counter more accurate.
Also fix the vblank start position for interlaced display modes.
Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Akash Goel <akash.goels@gmail.com>" Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:49 +0000 (13:35 +0300)]
drm/i915: Add a small adjustment to the pixel counter on interlaced modes
In interlaced modes, the pixel counter counts all pixels,
so one field will have htotal more pixels. In order to avoid
the reported position from jumping backwards when the pixel
counter is beyond the length of the shorter field, just
clamp the position the length of the shorter field. This
matches how the scanline counter based position works since
the scanline counter doesn't count the two half lines.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Akash Goel <akash.goels@gmail.com>" Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 22 May 2014 08:44:40 +0000 (09:44 +0100)]
drm/i915: Hold CRTC lock whilst freezing the planes
Daniel keeps on ramping up the warning level of the DRM and our display
core to make it complain whenever the locking rules are not followed.
This caught
introducing an unlocked access to the CRTC whilst disabling it for
suspend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 22 May 2014 08:16:52 +0000 (09:16 +0100)]
drm/i915: Only discard backing storage on releasing the last ref
Before purging our pages (as opposed to copying back the contents from
the GPU), make sure that there is not an exposed CPU mmapping through
which the user can inspect the results.
Ville Syrjälä [Wed, 21 May 2014 11:04:46 +0000 (14:04 +0300)]
drm/i915: Wait for pending page flips before enabling/disabling the primary plane
We have to write to the primary plane base address registrer when we
enable/disable the primary plane in response to sprite coverage. Those
writes will cause the flip counter to increment which could interfere
with the detection of CS flip completion. We could end up completing
CS flips before the CS has even executed the commands from the ring.
To avoid such issues, wait for CS flips to finish before we toggle the
primary plane on/off.
v2: Rebased due to atomic sprite update changes
Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 21 May 2014 20:29:31 +0000 (17:29 -0300)]
drm/i915: grab the audio power domain when enabling audio on HSW+
With the current code, we unconditionally touch
HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power
well is off, and that will trigger an "Unclaimed register" message.
Just adding the intel_crtc->config.has_audio should already avoid the
unclaimed register messsages, but since we actually need the power
well to make the Audio code work, it makes sense to also grab the
audio power domain reference, and release it when it's not needed
anymore.
I used IGT's pm_rpm to reproduce this bug, but it can probably be
reproduced on other tests that do modesets. I'm using a machine with
eDP+HDMI connected.
Regression introduced by:
commit acfa75b02e72bad7c93564ac379712e29c001432
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 23:54:51 2014 +0200
drm/i915: Simplify audio handling on DDI ports
Credits to Daniel for suggesting this implementation.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 21 May 2014 19:23:20 +0000 (16:23 -0300)]
drm/i915: don't read HSW_AUD_PIN_ELD_CP_VLD when the power well is off
Because this will trigger "Unclaimed register" messages. All I need to
reproduce this problem is to boot my HSW machine with eDP+HDMI
connected.
Regression introduced by:
commit 9ed109a7b445e3f073d8ea72f888ec80c0532465
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 23:54:52 2014 +0200
drm/i915: Track has_audio in the pipe config
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
Also add a note to prevent this from happening again - people really
should be less lazy and take more time to look for a good home of
their new driver-global state.
Cc: Imre Deak <imre.deak@intel.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 16 May 2014 16:40:25 +0000 (19:40 +0300)]
drm/i915: Shuffle fifo underrun disable/enable points for gmch platforms
Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
So in order to avoid false positives we must enable the FIFO underrun
reporting only when at least one plane is enabled on the pipe. For
now just move the underrun reporting enable/disable points to the
other side of the plane enable/disable point. That doesn't cover cases
when we turn off all the planes for the pipe but leave the pipe running
on purpose, but it's better than the current situation.
On gen4+ we can actually move the underrun reporting enable/disable to
the opposite ends of the crtc enable/disable hooks. I suppose in theory
we could leave the underrun reporting enabled all the time, except on
VLV where PIPESTAT stops working when the display power well is down.
If we ever get around to unifying the PIPESTAT irq handling for all
gmch platforms, we should still follow the VLV route for other platforms.
It would also micro-optimize the irq handler a bit since we could then
skip the PIPESTAT reads for all disabled pipes.
Gen3 is still a mystery, but for now I'm going to assume it behaves
like gen4+.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 16 May 2014 16:40:24 +0000 (19:40 +0300)]
drm/i915: Simplify the uncleared FIFO underrun detection
Checking whether the error interrupt was enabled or not isn't really
necessary when we check for uncleared FIFO underruns. If it was enabled
we'll race with the interrupt handler a bit, but that seems OK as we
still claim the interrupt.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 16 May 2014 16:40:22 +0000 (19:40 +0300)]
drm/i915: Check for FIFO underruns at the end of modeset on gmch
FIFO underruns don't generate interrupts on gmch platforms, so
if we want to know whether a modeset triggered FIFO underruns we
need to explicitly check for them.
As a modeset on one pipe could cause underruns on other pipes,
check for underruns on all pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com>
[danvet: Fix up merge error, kudos to Ville for noticing it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 16 May 2014 16:40:21 +0000 (19:40 +0300)]
drm/i915: Check for FIFO underuns when disabling reporting on gmch platforms
FIFO underruns don't generate an interrupt on gmch platforms, so we
should check whether there were any that we failed to notice when
we're disabling FIFO underrun reporting.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 25 Apr 2014 17:14:32 +0000 (20:14 +0300)]
drm/i915: Provide DPIO diagrams as docboox tables
The ascii art version of the DPIO diagram gets mangled by docbook, so
we can't use it there. Insted provide another version built using
<table>.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 25 Apr 2014 17:14:31 +0000 (20:14 +0300)]
drm/i915: Add a brief description of the VLV display PHY internals
Document the internal structure of the VLV display PHY a bit to help
people understand how the different register blocks relate to each
other.
v2: Add a bit more text
Make it a DOC: comment, but leave the ascii art out since
it would get mangled
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Wed, 21 May 2014 16:01:06 +0000 (19:01 +0300)]
drm/i915: Add null state batch to active list
for proper refcounting to take place as we use
i915_add_request() for it.
i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.
v2: we need to check for correct ring now (Ville Syrjälä)
v3: no need to expose i915_gem_move_object_to_active (Chris Wilson)
v4: cargoculted vma/active/inactive error handling removed (Chris Wilson)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 20 May 2014 14:20:05 +0000 (17:20 +0300)]
drm/i915: Re-enable vblank irqs for already active pipes
If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the vblank
interrupts.
So in order to make sure vblank interrupts get re-enabled post-resume,
call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
active.
v2: Also drm_vblank_off() if the pipe got disabled magically
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Testecase: igt/kms_flip/vblank-vs-suspend Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 14 May 2014 13:40:34 +0000 (15:40 +0200)]
drm/i915: Accurately initialize fifo underrun state on gmch platforms
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms and hence we must allow underrun
reporting on disabled pipes. Otherwise nothing really works,
especially the CRC support since that's key'ed off the same irq
disable bit.
This allows us to ditch the fifo underrun reporting hack from the vlv
runtime pm code and unexport the internal function from i915_irq.c
again. Yay!
v2: Keep the display irq disabling, spotted by Imre.
Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 14 May 2014 13:26:49 +0000 (15:26 +0200)]
drm/i915: rip our vblank reset hacks for runtime PM
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
Daniel Vetter [Thu, 15 May 2014 13:33:46 +0000 (15:33 +0200)]
drm/i915: Use new kms-native vblank functions
Only the low-level irq handling functions still use integer crtc
indices with this. But fixing that will require a lot more sugery
and some good ideas for backwards compat with old ums userspace.
Both in drivers and in the drm core.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 15 May 2014 13:32:12 +0000 (15:32 +0200)]
drm/irq: Add kms-native crtc interface functions
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
v2:
- Polish kerneldoc a bit (Thierry).
- Drop "dev" parameter since it's unecessary.
- Split out i915 changes (Thierry).
Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 8 May 2014 14:41:51 +0000 (16:41 +0200)]
drm/irq: kerneldoc polish
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
v2: Polish as suggested by Thierry.
Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.
Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when disabling/enabling crtcs. So this seems
to be unnecessary now. The most important side effect was that due to
the delayed vblank disabling we have been pretty much guaranteed to
receive a vblank interrupt soonish after a crtc was enabled.
Note that our vblank handling across modeset is still fairly decent
fubar - we don't actually handle vblank counter all to well.
drm_update_vblank_count will make sure that the frame counter always
rolls forward, but userspace isn't really all to ready to cope with
the big jumps this causes.
This isn't a big mostly because the hardware retains the frame
counter. But with runtime pm and also across suspend/resume we fall
over.
Fixing this is a lot more involved and also needs som i-g-ts. So
material for another patch series.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 15 Apr 2014 18:41:38 +0000 (21:41 +0300)]
drm/i915: Move buffer pinning and ring selection to intel_crtc_page_flip()
All of the .queue_flip() callbacks duplicate the same code to pin the
buffers and calculate the gtt_offset. Move that code to
intel_crtc_page_flip(). In order to do that we must also move the ring
selection logic there.
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>
Ville Syrjälä [Tue, 15 Apr 2014 18:41:34 +0000 (21:41 +0300)]
drm/i915: Fix mmio vs. CS flip race on ILK+
Starting from ILK, mmio flips also cause a flip done interrupt to be
signalled. This means if we first do a set_base and follow it
immediately with the CS flip, we might mistake the flip done interrupt
caused by the set_base as the flip done interrupt caused by the CS
flip.
The hardware has a flip counter which increments every time a mmio or
CS flip is issued. It basically counts the number of DSPSURF register
writes. This means we can sample the counter before we put the CS
flip into the ring, and then when we get a flip done interrupt we can
check whether the CS flip has actually performed the surface address
update, or if the interrupt was caused by a previous but yet
unfinished mmio flip.
Even with the flip counter we still have a race condition of the CS flip
base address update happens after the mmio flip done interrupt was
raised but not yet processed by the driver. When the interrupt is
eventually processed, the flip counter will already indicate that the
CS flip has been executed, but it would not actually complete until the
next start of vblank. We can use the DSPSURFLIVE register to check
whether the hardware is actually scanning out of the buffer we expect,
or if we managed hit this race window.
This covers all the cases where the CS flip actually changes the base
address. If the base address remains unchanged, we might still complete
the CS flip before it has actually completed. But since the address
didn't change anyway, the premature flip completion can't result in
userspace overwriting data that's still being scanned out.
CTG already has the flip counter and DSPSURFLIVE registers, and
although the flip done interrupt is still limited to CS flips alone,
the code now also checks the flip counter on CTG as well.
v2: s/dspsurf/gtt_offset/ (Chris)
Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add g4x_ prefix to flip_count_after_eq.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: don't disable the DP port if the link is lost
we no longer call intel_dp_link_down from generic DP code, but only
from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder
disabling callback in intel_ddi.c.
Hence the early return is no longer needed and the big comment just
confusing, so let's rip it out. To ensure what we don't accidentally
use this again on ddi encoders add a WARN_ON instead.
Spotted while reading through intel_dp.c
Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 19 Feb 2014 19:29:49 +0000 (21:29 +0200)]
drm: Add drm_vblank_on()
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during that
time.
Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
re-enabled vblank interrupts if the refcount is already elevated. This
will allow drivers to choose the specific places in the modeset sequence
at which vblank interrupts get disabled and enabled.
Testcase: igt/kms_flip/*-vs-suspend Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add Testcase tag for the igt I've written.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 6 Mar 2014 15:27:39 +0000 (17:27 +0200)]
drm: Make blocking vblank wait return when the vblank interrupts get disabled
If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 19 Feb 2014 17:36:08 +0000 (19:36 +0200)]
drm: Make the vblank disable timer per-crtc
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
disable timer per-crtc to avoid this issue.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 19 May 2014 16:23:26 +0000 (19:23 +0300)]
drm/i915: Clear GDSR after reset on ILK
Clear the reset domain after a succesful GPU reset on ilk. We already
do that on gen4, so let's try to be a bit more consistent. And if
ether render or media reset fails, we might use the leftover value
in the register to pinpoint the culprit.
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>
Imre Deak [Tue, 20 May 2014 16:47:20 +0000 (19:47 +0300)]
drm/i915: add missing unregister_oom_notifier to the error/unload path
I'm trying to reduce the WARNs during driver reload and this was one of
them. Also while at it remove the redundant condition from before
unregister_shrinker().
v2:
- fix the error path too and move the unregister to its logical place
(Chris)
- remove redundant condition from before unregister_shrinker()
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:41 +0000 (13:28 +0300)]
drm/i915/chv: Add a bunch of pre production workarounds
The following workarounds should be needed for pre-production hardware
only:
* WaDisablePwrmtrEvent:chv
* WaSetMaskForGfxBusyness:chv
* WaDisableGunitClockGating:chv
* WaDisableFfDopClockGating:chv
* WaDisableDopClockGating:chv
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>
Ville Syrjälä [Wed, 9 Apr 2014 10:29:04 +0000 (13:29 +0300)]
drm/i915/chv: Use RMW to toggle swing calc init
The spec only tells us to set individual bits here and there. So we use
RMW for most things. Do the same for the swing calc init.
Eventually we should optimize things to just blast the final value in
with group access whenever possible. But to do that someone needs to
take a good look at what's the reset value for each registers, and
possibly if the BIOS manages to frob with some of them. For now
use RMW access always.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:29:03 +0000 (13:29 +0300)]
drm/i915/chv: Don't do group access reads from TX lanes either
Like PCS, TX group reads return 0xffffffff. So we need to target each
lane separately if we want to use RMW cycles to update the registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:29:02 +0000 (13:29 +0300)]
drm/i915/chv: Don't use PCS group access reads
All PCS groups access reads return 0xffffffff, so we can't use group
access for RMW cycles. Instead target each spline separately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fight conflict with misplaced ; .... ARGH!] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 28 Apr 2014 11:15:24 +0000 (14:15 +0300)]
drm/i915/chv: Set soft reset override bit for data lane resets
The bits we've been setting so far only progagate the reset singal to
the data lanes. To actaully force the reset signal we need to set another
override bit.
v2: Fix mispalced ';' (Mika)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:29:00 +0000 (13:29 +0300)]
drm/i915/chv: Reset data lanes in encoder .post_disable() hook
Seems like we shouldn't leave the data lane resert deasserted when
the port if disabled. So propagate the reset the data lanes in
the encoder .post_disable() hook.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:59 +0000 (13:28 +0300)]
drm/i915/chv: Turn off dclkp after the PLL has been disabled
During the enable sequence we first enable the dclkp output to the
display controller, and then enable the PLL. Do the opposite during
the disable sequence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:58 +0000 (13:28 +0300)]
drm/i915/chv: Move data lane deassert to encoder pre_enable
We need to pick the correct data lanes based on the port not the
pipe, so move the data lane deassert into the encoder .pre_enable()
hook from the chv_enable_pll().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:57 +0000 (13:28 +0300)]
drm/i915/chv: Fix CHV PLL state tracking
Setup the pipe config dpll state correctly for CHV. Also add
a assert_pipe_disabled() to chv_disable_pll(), and program the
DPLL_MD registers in chv_enable_pll().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:56 +0000 (13:28 +0300)]
drm/i915/chv: Register port D encoders and connectors
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:55 +0000 (13:28 +0300)]
drm/i915/chv: Fix PORT_TO_PIPE for CHV
Fix the encoder .get_config hooks to report the correct active pipe for
CHV.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:54 +0000 (13:28 +0300)]
drm/i915/chv: Bump num_pipes to 3
CHV has three pipes so let's expose them all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:53 +0000 (13:28 +0300)]
drm/i915/chv: Add cursor pipe offsets
Unsurprisingly the cursor C regiters are also at a weird offset on CHV.
Add more pipe offsets to handle them.
This also gets rid of most of the differences between the i9xx vs. ivb
cursor code. We can unify the remaining code as well, but I'll leave
that for another patch.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:52 +0000 (13:28 +0300)]
drm/i915/chv: Fix gmbus for port D
On CHV the GMBUS port for port D is different from other gmch platforms
which have port D. Fix it up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 28 Apr 2014 11:07:43 +0000 (14:07 +0300)]
drm/i915/chv: Configure crtc_mask correctly for CHV
On CHV pipe C can driver only port D, and pipes A and B can drivbe only
ports B and C. Configure the crtc_mask appropriately to reflect that.
v2: Moar braces (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:50 +0000 (13:28 +0300)]
drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:49 +0000 (13:28 +0300)]
drrm/i915/chv: Use valleyview_pipestat_irq_handler() for CHV
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:48 +0000 (13:28 +0300)]
drm/i915/chv: Clarify VLV/CHV PIPESTAT bits a bit more
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rafael Barbalho [Mon, 28 Apr 2014 11:00:42 +0000 (14:00 +0300)]
drm/i915/chv: Add CHV display support
Add support for the third pipe in cherrview
v2: Don't use spaces for indentation (Jani)
Wrap long lines
Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
[vsyrjala: slightly massaged the patch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rafael Barbalho [Wed, 9 Apr 2014 10:28:40 +0000 (13:28 +0300)]
drm/i915/chv: Implement WaDisableSamplerPowerBypass for CHV
Cherryview also needs this WA.
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
[vsyrjala: Looks like it's for pre-prodution hw only] 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>
Ville Syrjälä [Mon, 28 Apr 2014 11:31:09 +0000 (14:31 +0300)]
drm/i915/chv: Add some workaround notes
We implement the following workarounds:
* WaDisableAsyncFlipPerfMode:chv
* WaProgramMiArbOnOffAroundMiSetContext:chv
v2: Drop WaDisableSemaphoreAndSyncFlipWait note
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>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This workaround is listed for CHV, but not for BDW. However BSpec notes
that on BDW CSunit clock gating is always disabled irrespective of the
relevant bit in the GEN6_UGCTL1 registers. For CHV however, such text
is not present in BSpec, so it seems safer to just set the bit.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BDW has the same requirement but the w/a database doens't list
this w/a for BDW. Seems to be another one of those "stick a bunch
of known workarounds into this bag and write something on the label"
type of things.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Apr 2014 10:28:35 +0000 (13:28 +0300)]
drm/i915/chv: Implement WaVSRefCountFullforceMissDisable:chv and WaDSRefCountFullforceMissDisable:chv
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:13 +0000 (23:55 +0200)]
drm/i915: Extract intel_prepare_shared_dpll
This is the last piece of code which write state to the hardware in
the ironalake ->crtc_mode_set callback.
I think we could merge this with the pll->enable hook, but otoh the
ordering requirements with the ldvs port are really tricky. Doing the
FP0/1 writes up-front before we even prepare the lvds port (in the
pre_pll_enable hook) like on i9xx seems safest.
With this ilk+ platforms are now ready for runtime PM with DPMS. Since
hsw/bdw also support runtime pm besides snb we need to first make the
haswell code save before we can touch the core code.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 20 May 2014 13:19:19 +0000 (15:19 +0200)]
drm/i915: Only update shared dpll state when needed
Instead of every time it isn't active: We only need to do that when
the pll is currently unused, i.e. when pll->refcount == 0. For
paranoia add a warning for the ibx case where plls have a fixed
mapping and hence should always be unused after the call to
intel_put_shared_dpll.
v2: Simplify control flow and use struct assignment instead of memcpy
as suggested by Damien.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:11 +0000 (23:55 +0200)]
drm/i915: Extract vlv_prepare_pll
With this all hw writes are also gone from the ->crtc_mode_set hook on
vlv. I wondered whether we should track more of the pll state in the
pipe config, but otoh as long as we don't have shared plls that's not
really useful - the cross-checking of the port clock should be
sufficient.
While at it also de-magic some of the pipe checks, this has been
irking me since a long time.
Whit this vlv is now ready for runtime PM on dpms. If we'd have
runtime PM support in general ...
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:10 +0000 (23:55 +0200)]
drm/i915: Extract i9xx_set_pll_dividers
These two writes are the very last hw writes from the
->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit
different, so this here is just warm-up.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:09 +0000 (23:55 +0200)]
drm/i915: Shovel hw setup code out of hsw_crtc_mode_set
Again the same story: This code just transform sw state from the pipe
config into hardware state. And again we can't move the pll code, but
this time around because the state isn't properly tracked in the pipe
config.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:08 +0000 (23:55 +0200)]
drm/i915: Shovel hw setup code out of ilk_crtc_mode_set
Again this code just transforms sw state from the pipe config into
hardware state, so we can just move it around. Unfortunately again a
few forward declarations since intel_display.c is becoming a bit of a
mess.
Note that both for i9xx and ironlake code the only things remaining in
the ->crtc_mode_set hook is now the clock state computation and
sharing code. That needs to be moved into the compute config stage so
that we can catch impossible configurations earlier.
Also note that some of the DPLL hw setup code is still run from within
->crtc_mode_set, namele the pll->mode_set callback. We need to move
that first before we can do fancy things like enable runtime PM for
dpms off.
v2: Make it compile again after the rebase, bisectability issue
reported by Wu Fengguang.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:07 +0000 (23:55 +0200)]
drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set
Now this really should be in the pipe config somewhere, but till now
it isn't. We can at least move it up a bit next to all the other pll
code since intel_dp_set_m_n really doesn't depend upon this.
This is just prep work so that moving all the hw frobbing code from
->crtc_mode_set to ->crtc_enable is clean.
v2: Do the same for haswell while at it, not just for ivb.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:06 +0000 (23:55 +0200)]
drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set
All these functions simply convert sw state as encoded in the pipe
config or primary framebuffer into hardware state. So we can move them
all into the crtc enable hook. Unfortunately this means a little bit
of duplication between the i9xx and vlv functions, but since we
already have highly refactored code I think this is acceptable.
Also a pile of forward declarations unfortunately.
Note also that the various <platform>_update_pll functions are still
called from within the ->crtc_mode_set hook. Mostly they compute the
clock state for the pipe config, but unfortunately there are some
random register writes interspersed. Those need to be moved out first
before we can enable runtime PM for DPMS.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 20 May 2014 07:28:43 +0000 (08:28 +0100)]
drm/i915: Implement an oom-notifier for last resort shrinking
Before the process killer is invoked, oom-notifiers are executed for one
last try at recovering pages. We can hook into this callback to be sure
that everything that can be is purged from our page lists, and to give a
summary of how much memory is still pinned by the GPU in the case of an
oom. This should be really valuable for debugging OOM issues.
Note that the last-ditch effort call to shrink_all we've previously
called from our normal shrinker when we could free as much as the vm
demaned is moved into the oom notifier. Since the shrinker accounting
races against bind/unbind operations we might have called shrink_all
prematurely, which this approach with an oom notifier avoids.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72742 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com>
[danvet: Bikeshed logical | into || and pimp commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 19 May 2014 16:23:24 +0000 (19:23 +0300)]
drm/i915: Fix ILK GPU reset domain bits
We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.
We were actually always writing 0x2 to the reset domain bits, which
is a reserved value. In practice it looks like the hardware ignores that
value since nothing happens if I write that value when there's a 3D
workload running. Writing the _correct_ render domain value actually
makes the GPU stop.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 19 May 2014 16:23:22 +0000 (19:23 +0300)]
drm/i915: Drop bogus comments about display reset
There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does, ie. we don't perform a display reset. Drop
the bogus comments.
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 Mar 2014 13:23:06 +0000 (13:23 +0000)]
drm/i915: Invalidate our pages under memory pressure
Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory pressure and forced to drop GEM objects from
memory. In effect, this should just allow us to discard unused pages for
memory reclaim and to start writeback earlier.
v2: Hugh Dickins warned that explicitly starting writeback from
shrink_slab was prone to deadlocks within shmemfs.
Cc: Hugh Dickins <hughd@google.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 25 Mar 2014 13:23:05 +0000 (13:23 +0000)]
drm/i915: Refactor common lock handling between shrinker count/scan
We can share a few lines of tricky lock handling we need to use for both
shrinker routines and in the process fix the return value for count()
when reporting a deadlock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 25 Mar 2014 13:23:04 +0000 (13:23 +0000)]
drm/i915: Include bound and active pages in the count of shrinkable objects
When the machine is under a lot of memory pressure and being stressed by
multiple GPU threads, we quite often report fewer than shrinker->batch
(i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to
skip calling into i915.ko to release pages, despite the GPU holding onto
most of the physical pages in its active lists.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72742 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 25 Mar 2014 13:23:03 +0000 (13:23 +0000)]
drm/i915: Translate ENOSPC from shmem_get_page() to ENOMEM
shmemfs first checks if there is enough memory to allocate the page
and reports ENOSPC should there be insufficient, along with
the usual ENOMEM for a genuine allocation failure.
We use ENOSPC in our driver to mean that we have run out of aperture
space and so want to translate the error from shmemfs back to
our usual understanding of ENOMEM. None of the the other GEM users
appear to distinguish between ENOMEM and ENOSPC in their error handling,
hence it is easiest to do the fixup in i915.ko
Cc: Hugh Dickins <hughd@google.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shashank Sharma [Mon, 19 May 2014 15:24:03 +0000 (20:54 +0530)]
drm/i915: Add MIPI mmio reg base
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Daniel Vetter [Mon, 19 May 2014 14:09:35 +0000 (16:09 +0200)]
drm/i915: Don't die in wait_for_pending_flips
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary "this is a lost
cause" timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78383 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these registers are reset and failing to program them results
in a blank screen.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Mon, 19 May 2014 08:41:17 +0000 (11:41 +0300)]
drm/i915: rename IOSF sideband opcodes according to the spec
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:05 +0000 (23:55 +0200)]
drm/i915: Move fb pinning into __intel_set_mode
Our two ->crtc_mode_set callbacks really don't care whether the fb is
pinned and set up already or not - all the state computation and
handling which originally looked at the framebuffer is already using
the indirection through the pipe configuration.
Eventually we want to move this up a bit more, but as long as the crtc
mode_set callback still exists (and as long as we don't need to pin an
entire pile of planes due to atomic modesets) there's not much point
in it. So I'll let this be for now.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:04 +0000 (23:55 +0200)]
drm/i915: Inline set_base into crtc_mode_set
A lot of the code in set_base is uncessary when the crtc is off, so we
can get rid of it all. Also, we don't need to call the fbc/psr update
functions since the crtc enable/disable hooks do that already.
The only things we really need are:
- Pin the new framebuffer and potentially unpin the old framebuffer
(if the crtc has been on and we only change the configuration).
- Update the plane registers.
The first step will move out of platform code with the very next
patch.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:03 +0000 (23:55 +0200)]
drm/i915: Sprinkle intel_edp_psr_update over crtc_enable/disable
My plan here is to split up set_base into a prepare step, which does
the pinning, and a commit stage, which updates the hw state. Eventually
we should be able to move the prepare step at the beginning of any
atomic update. For now I only want to move the commit step into the
crtc_enable callbacks.
As a prep step sprinkle intel_edp_psr_update all over the place so
that we don't have to concern ourselves with that in the commit step.
v2: Rebase on top of Ville's enable/disable functions for all planes.
v3: Rebase more.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:55:01 +0000 (23:55 +0200)]
drm/i915: Make ->update_primary_plane infallible
Way back we've used this to reject framebuffers with unsupported
pixel formats. But since the modesetting reorg with the compute
config stage we reject those much earlier and just BUG() in this
callback. So switch to a void return type.
Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Do not call retire_requests from wait_for_rendering
is that we can completely fill all of memory using small objects, such
that we exhaust the filp space, and spend all of our time evicting
objects from the aperture. As such, we never fill the ring, and never
trigger the last resort flushing in
drm/i915: Flush request queue when waiting for ring space
and so all the requests are left active and the objects keep that last
active reference. Eventually the system comes to a halt as it runs out
of memory.
The impact is mainly limited to test cases as regular userspace will
trigger retirement by manually checking whether an object is active.
Testcase: igt/gem_lut_handle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78724 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Mon, 19 May 2014 01:15:08 +0000 (11:15 +1000)]
Merge branch 'ast-updates' of ssh://people.freedesktop.org/~/linux into drm-next
Pull in latest updates to AST driver.
* 'ast-updates' of ssh://people.freedesktop.org/~/linux:
drm/ast: initial DP501 support (v0.2)
drm/ast: rename the mindwm/moutdwm and deinline them
drm/ast: resync the dram post code with upstream
drm/ast: add AST 2400 support.
drm/ast: add widescreen + rb modes from X.org driver (v2)
projects / linux-beck.git / log