Now that set_mode also disables crtcs and expects it's new
configuration in the staged output links we need to adjust the load
detect code a bit.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --gi
With this change we can (finally!) rip out a few of the temporary hacks
and clean up a few other things:
- Kill intel_crtc_prepare_encoders, now unused.
- Kill the hacks in the crtc_disable/enable functions to always call the
encoder callbacks, we now always call the crtc functions with the right
We need this to avoid confusing the hw state readout code with the cpt
pch plls at resume time: We'd read the new pipe state (which is
disabled), but still believe that we have a life pll connected to that
pipe (from before the suspend). Hence properly disable pipes to clear
out all the residual st
... let's see how whether this catches anything earlier and I can
track down a few bugs.
v2: Add more checks and also add DRM_DEBUG_KMS output so that it's
clear which connector/encoder/crtc is being checked atm. Which proved
rather useful for debugging ...
v3: Add a WARN in the common encoder dp
Even with the old crtc helper code we should have disabled all
encoders on that pipe by now, and with the new code this would
definitely paper over a bug. We already have the necessary checks
in place in intel_disable_transcoder, so if we accidentally leave
a pch port on, this will be caught.
Henc
Because they should have been disabled when shutting down the display
pipe previously. To ensure that this is the case, add a few assserts
instead of unconditionally disabling the fdi link.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |8 +---
1 file changed, 5 i
... because our current set_mode implementation doesn't bother to adjust
for the dpms state, we just forcefully update it. So stop pretending that
we're better than we're are and rip out this extranous call.
Note that this totally confuses userspace, because the exposed connector
property isn't ac
Hopefully this makes userspace slightly less confused about us
frobbing the dpms state behind its back. Yeah, it would be better
to be more careful with not changing the dpms state, but that is
quite more invasive.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |9
The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.
LVDS has some similar funky hacks, but that would require more work
(we need to move around the
By using the new pre_enabel/post_disable functions.
To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 74 ++
Because that's what it is. Unfortunately we can't rip this out because
the fb helper has an incetious relationship with the crtc helper - it
likes to call disable_unused_functions, among other things.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
drivers/gpu/dr
With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:
- WARN if the port enable bit is in the wrong state or if the edp pll
bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll h
These have been added because dp links are fiddle things and don't
like it when we try to re-train an enabled output (or disable a
disable output harder). And because the crtc helper code is
ridiculously bad add tracking the modeset state.
But with the new code in place it is simply a bug to disab
See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
applies to all platforms where we currently support eDP on, i.e. ilk,
snb & ivb.
Without this change we fail to light up the eDP port on previously
unused crtcs (likely because something is stuck on the old pipe), and
we also f
Makes more sense to group the entire mode_set stage into one function.
Noticed while discussion the rather confusing set of function names
with Paulo Zanoni. Unfortunately I don't have an idea to make the
function names lesss confusion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel
In order for the Display Engine to send messages to the Render Engine,
that event must be unmasked in the Display Engine Render Response Mask
Register (DERRMR). By default all events are masked to prevent unwanted
messages to conserve power, and it is strongly recommended that only
single events be
On Mon, Jun 18, 2012 at 11:04:30PM +0100, Chris Wilson wrote:
> On Mon, 18 Jun 2012 19:03:38 -0300, Eugeni Dodonov
> wrote:
> > We should not hit this under any sane conditions, but still, this does not
> > looks right.
>
> For pedagology.
> >
> > CC: Chris Wilson
> > CC: Daniel Vetter
> > CC
The IVB simulator really doesn't like a TLB invalidate with no post-sync
operation, in fact it blows up in an assertion failure. The
documentation states that we must issue the TLB invalidate with a CS
stall: "Also Requires stall bit ([20] of DW1) set." This patch doesn't
comply with the docs, but
Who will monitor this sysfs interface, 2D driver or 3D driver or other
application ?
Now, I don't find any user of this sysfs interface in 2D driver or 3D driver.
thanks
-Original Message-
From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org
[mailto:intel-gfx-
On Thu, Jul 26, 2012 at 04:48:43PM -0700, Ben Widawsky wrote:
> The IVB simulator really doesn't like a TLB invalidate with no post-sync
> operation, in fact it blows up in an assertion failure. The
> documentation states that we must issue the TLB invalidate with a CS
> stall: "Also Requires stall
101 - 120 of 120 matches
Mail list logo
