Hi all,
This patch bomb is just the prep work for the actual rework ;-)
The goal of this little adventure is to move away from the crtc helper code,
which has the fundamental assumption that encoders and crtc can be
enabled/disabled in any order, as long as we take care of depencies.
Our hw work
We already have this pattern at quite a few places, and moving part of
the modeset helper stuff into the driver will add more.
v2: Don't clobber the crtc struct name with the macro parameter ...
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |4 +++
drivers/gpu/drm/i9
Because that's what we're essentially calling. This is the first step
in untangling the crtc_helper induced dpms handling mess we have - at
the crtc level we only have 2 states and the magic is just in selectin
which one (and atm there isn't even much magic, but on recent
platforms where not even t
Just impendance matching with the the crtc helper stuff.
... and somehow the design of this all ended up in this commit here,
too ;-)
The big plan is that a new set of display_funcs that take crtc take
full responsibility of a modeset (and call down into object-specific
callbacks and functions).
Just prep work, not yet put to some use.
Note that because we're still using the crtc helper to switch modes
(and their complicated way to do partial modesets), we need to call
the encoder's disable function unconditionally.
But once this is cleaned up we should call the encoder's disable
functio
For some odd reason we've missed i830 and a i855 variant. Also
kill the two now redundant i830 entries.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dr
Now that all affected i830M systems have the pipe A quirk set,
we don't need to do any special dances in the overlay code any
longer. And reading through the code I'm rather dubios that it
actually does what it claims to do ...
As a nice benefit this rips out a users of the crtc helper dpms
callba
A few things need adjustement:
- Change the dpms state by calling the dpms connector function and
not some crtc helper internal callbacks. Otherwise this will break
once we switch to our own dpms handling.
- Instead of tracking and restoring intel_crtc->dpms_mode use the
connector's dpms vari
I've picked hdmi as the first encoder to convert because it's rather
simple:
- no cloning possible
- no differences between prepare/commit and dpms off/on switching.
A few changes are required to do so:
- Split up the dpms code into an enable/disable function and wire it
up with the intel encode
Like hdmi tv outputs are simple: They only have 2 states and can't be
cloned. Hence give it the same treatment.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 35 +++
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/gp
With the previous patch LVDS is also a simple case. Treat it
accordingly.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 52 ++---
1 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers
LVDS is the first output where dpms on/off and prepare/commit don't
perfectly match. Now the idea behind this special case seems to be
that for simple resolution changes on the LVDS we don't need to stop
the pipe, because (at least on newer chips) we can adjust the panel
fitter on the fly.
There a
DP is the first encoder which isn't simple. As
commit d240f20f545fa4ed78ce48d1eb62ab529f2b1467
Author: Jesse Barnes
Date: Fri Aug 13 15:43:26 2010 -0700
drm/i915: make sure eDP PLL is enabled at the right time
discovered, we need to enable the eDP PLL for the cpu port _before_ we
enable t
Will be used more in the next patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 79be8
Splitting them up between pch and gmch variants just makes it harder
to find things. Especially since the hotplug bits are actually valid
on earlier chips, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 47 ++
1 files changed, 22 ins
With the base addresses shifting around, this is easier to handle.
Also move to the real reg offset on vlv.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_crt.c | 23 ---
2 files changed, 17 insertions(+), 7 deletions(
CRT is the first output which can be cloned, hence we cannot (yet)
move the dpms handling over to disable/enable. This requires some more
smarts in intel_crtc_dpms first to set the display pipe status
depening upon encoder->connectors_active of all connected encoders.
Because that will happen in a
Similar to crt, this doesn't convert the dpms functions.
Also similar to crt, we don't switch of the display pipe
for the intermediate modes, only DPMS_OFF is truely off.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 58 +++-
1 files chang
All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.
While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the
Intel hw only has one MUX for encoders, so outputs are not cloneable
or all in the same group of cloneable outputs. This neatly simplifies
the code and allows us to ditch some ugly if cascades in the dp and
hdmi init code (well, we need these if cascades for other stuff still,
but that can be taken
Instead of having a giant if cascade to figure this out according to
the passed-in register. We could do quite a bit more cleaning up and
all by using the port at more places, but I think this should be part
of a bigger rework to introduce a struct intel_digital_port which
would keep track of all t
Yeah, big patch but I couldn't come up with a neat idea of how to
split it up further, that wouldn't break dpms on cloned configs
somehow. But the changes in dvo/sdvo/crt are all pretty much
orthonogal, so it's not too bad a patch.
These are the only encoders that support cloning, which requires a
All encoders are now converted so there's no need for these checks any
more.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 24
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/
We no longer need them. And now that all encoders are converted, we
can finally move the cpt modeset check to the right place - at the end
of the crtc_enable function.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 23 +++
drivers/gpu/drm/i915/intel
Go through the interface vtable instead, because not everyone might be
using the crtc helper code.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_h
It's unused. At it confused me quite a bit until I've discovered that.
Signed-Off-by: Daniel Vetter
---
include/drm/drm_crtc.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bac55c2..a1a0386 100644
--- a/include/drm
And the following static functions required by it:
drm_encoder_crtc_ok, drm_crtc_helper_disable
No changes safe for the s/drm/intel prefix change.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 314 +-
1 files changed, 313 insertions(+),
And drop the check, we always have it.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 72c415b..0fd9085 1006
Also kill the error-path, we have a fixed connector-encoder mapping.
Unfortunately we can't rip out all the ->best_encoder callbacks, these
are all still used by the fb_helper. Neat helper layering violation there.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 18 +++
Together with the static helpers drm_crtc_prepare_encoders and
drm_encoder_disable (which will be simplified in the next patch, but
for now are 1:1 copies). Again, no changes beside new names for these
functions.
Also call our new set_mode instead of the crtc helper one now in all
the places we've
- We don't have the ->get_crtc callback.
- Call intel_encoder->disable directly.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 25 -
1 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers
Instead of going through the crtc helper function tables.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
ind
With the new infrastructure we're doing this when enabling/disabling
the entire display pipe.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c |2 --
drivers/gpu/drm/i915/intel_display.c | 24
drivers/gpu/drm/i915/intel_dp.c |2 --
dri
This is the first tiny step towards cross-checking the entire modeset
state machine with WARNs. A crtc can only be enabled when it's
actually in use, i.e. crtc->active imlies crtc->enabled.
Unfortunately we can't (yet) check this when disabling the crtc,
because the crtc helpers are a bit slopy wi
It is all glorious if we try really hard to only enable an entire
display pipe to ensure that everyting happens in the right order. But
if we don't know the output configuration when the driver takes over,
this will all be for vain because we'll make the hw angry right on the
first modeset.
Hence
Also add some macros to make the pipe computation a bit easier.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_dp.c | 50 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/d
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 29 +
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 24
3 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 2fce753..5920c5f 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/dr
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 7fb4bc1..7bcd4b2 100644
--- a/drivers/gpu/drm/i915/i
Note that even though this connector is cloneable we have still can
use the exact same test to check whether the connector is on or
whether the output is enabled - both the dpms code and the encoder
disable/enable frob the exact same hw state.
For dvo/sdvo outputs, this will be different.
Signed-
SDVO is the first real special case - we support multiple outputs on
the same encoder and the encoder dpms state isn't the same as when
just disabling the outputs when the encoder is cloned.
Hence we need a real connector get_hw_state function which inquires
the sdvo encoder about its active outpu
Similar to the sdvo code we poke the dvo encoder whether the output is
active. Safe that dvo encoders are not standardized, so this requires
a new callback into the dvo chip driver.
Hence implement that for all 5 dvo drivers.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/dvo.h|
... instead of resetting a few things and hoping that this will work
out.
To properly disable the output pipelines at the initial modeset after
resume or boot up we need to have an accurate picture of which outputs
are enabled and connected to which crtcs. Otherwise we risk disabling
things at the
Atm we can only check the connector state after a dpms call - while doing
modeset with the copy&pasted crtc helper code things are too ill-defined
for proper checking. But the idea is very much to call this check
from the modeset code, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i
The link generated by the release script was incorrect. They should be
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.bz2
On Fri, 29 Jun 2012 11:17:47 -0700
Ben Widawsky wrote:
> I botched the 2.3.36 release quite royally. Here is 2.6.
My experience with these patches is that they make it less likely that
the hang is reported to the userspace in a timely fashion (filling the
ring full leads to lots of lost rendering) and worse make it much more
likely that i915_gem_fault() hits an EIO and goes bang. That is
unacceptable and trivi
On Tue, Jul 3, 2012 at 5:59 PM, Chris Wilson wrote:
> My experience with these patches is that they make it less likely that
> the hang is reported to the userspace in a timely fashion (filling the
> ring full leads to lots of lost rendering) and worse make it much more
> likely that i915_gem_faul
From: Paulo Zanoni
And rely on the fact that it's 0 to assume that machines without a PCH
will have PCH_NONE as dev_priv->pch_type.
Just today I finally realized that HAS_PCH_IBX is true for machines
without a PCH. IMHO this is totally counter-intuitive and I don't
think it's a good idea to assu
From: Paulo Zanoni
Previously we had has_pch_split to tell us whether we had a PCH or not
and we also had dev_priv->pch_type to tell us which kind of PCH it
was, but it could only be used if we were 100% sure we did have a PCH.
Now that PCH_NONE was added to dev_priv->pch_type we don't need
has_p
From: Paulo Zanoni
This function is used to set the PCH_DREF_CONTROL register, which does
not exist on LPT anymore.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/intel_display.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Tue, Jul 03, 2012 at 03:57:31PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> And rely on the fact that it's 0 to assume that machines without a PCH
> will have PCH_NONE as dev_priv->pch_type.
>
> Just today I finally realized that HAS_PCH_IBX is true for machines
> without a PCH. IMHO
On Tue, Jul 03, 2012 at 03:57:32PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Previously we had has_pch_split to tell us whether we had a PCH or not
> and we also had dev_priv->pch_type to tell us which kind of PCH it
> was, but it could only be used if we were 100% sure we did have a PC
"Cheah, Douglas" wrote:
>Hello folks,
>
>I am seeing corruption when running spectex from mesa demos which looks
>like vertex being randomly clipped on Valleyview, however spectex works
>fine on Ivy Bridge.
>
>After tracing down the codes I realize that the current Mesa driver
>would program the
On Mon, Jul 02, 2012 at 11:51:09AM -0300, Eugeni Dodonov wrote:
> This is based on Ivy Bridge clock gating for now, but is subject to
> changes in the future.
>
> Signed-off-by: Eugeni Dodonov
This copy of presumeably the ivb clock gate code is missing the changes
introduce in:
commit 208482232
2012/7/3 Daniel Vetter :
> I think most of the HAS_PCH_xxx are implicitly guarded because we've split
> up the pch modeset into it's own functions. I think there might only be a
> few issues in the encoder functions maybe. Have your checked all the
> HAS_PCH_IBX checks there? If you want, I can go
On Tue, Jul 3, 2012 at 10:29 PM, Paulo Zanoni wrote:
> 2012/7/3 Daniel Vetter :
>> I think most of the HAS_PCH_xxx are implicitly guarded because we've split
>> up the pch modeset into it's own functions. I think there might only be a
>> few issues in the encoder functions maybe. Have your checked
2012/7/3 Daniel Vetter :
> Hm, what about defining PCH_NONE as -1, PCH_RESERVED as 0 and then adding
> a WARN_ON(dev_priv->pch_type == PCH_RESERVED)? detect_pch is called
> unconditionally, and that way we would catch this. Might be overkill otoh,
> so if you think this is not worth it, np.
I actu
The up and down thresholds are very asymetric, so it is possible
to have a case where a spike of rendering increases the GPU clock to
the max (because the up threshold is low) and then a simple blinking
cursor is enough to keep the clock at the maximum speed forever
(because the down threshold is h
From: Paulo Zanoni
And rely on the fact that it's 0 to assume that machines without a PCH
will have PCH_NONE as dev_priv->pch_type.
Just today I finally realized that HAS_PCH_IBX is true for machines
without a PCH. IMHO this is totally counter-intuitive and I don't
think it's a good idea to assu
On 07/03/12 17:24, Daniel Vetter wrote:
> On Mon, Jul 02, 2012 at 11:51:09AM -0300, Eugeni Dodonov wrote:
>> This is based on Ivy Bridge clock gating for now, but is subject to
>> changes in the future.
>>
>> Signed-off-by: Eugeni Dodonov
>
> This copy of presumeably the ivb clock gate code is mi
Will do, I am not familiar with the procedure in Mesa but I will post a patch
in their mailing list requesting for it to be included.
I just had a chance to test this on a couple more mesa demo applications and
3DMarkmobile that also exhibit a lot of corruptions in Valleyview. The fix work
well
On Mon, 2012-07-02 at 18:49 +, Christophe Oosterlynck wrote:
> Hi,
>
> Is there any update on this issue or has a bug been reported?
>
> I seem to have a similar issue ("[drm:i915_hangcheck_hung] *ERROR* Hangcheck
> timer") when using vaapi with gstreamer.
>
https://bugs.freedesktop.org/s
62 matches
Mail list logo
