This will need to get modified when the ioctl expands, and so is only
here for reference/to make Daniel happy.
Signed-off-by: Ben Widawsky
---
tests/drm_reg_read.c | 86
1 file changed, 86 insertions(+)
create mode 100644 tests/drm_reg_read.c
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access, the
IOCTL can provide this service.
Currently the implementation whitelists only the render ri
On Wed, Jul 11, 2012 at 11:44:36AM +0100, Chris Wilson wrote:
> On Wed, 11 Jul 2012 12:31:52 +0200, Daniel Vetter
> wrote:
> > Somehow detect_ddc manages to fall through all checks when we think
> > that something responds on the ddc i2c address, but the edid read
> > failed. Fix this up by expli
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
... 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
This is precursor to some work I'm doing, but I think it stands nicely
as its own refactor.
v2: skip teardown returning on success (BUG)
Reviewed-by: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 36 +-
drivers/gpu/drm/i915/intel_rin
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
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
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
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
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 ++
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
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
... 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
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 files changed, 5
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
Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.
Also switch to intel_crtc for the enable function.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 57 +++--
1 files changed, 33 insertions(+), 24
... 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 ...
Signed-Off-by: Daniel Vetter
---
driv
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
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
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 files changed, 7 insertions(+), 6 deletions(-)
diff --g
This seems to be the symptom of a few neat bugs, hence be more
obnoxious when this fails.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
... and move a few others only used by i915_dma.c into the dri1
dungeon.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 22 +++---
drivers/gpu/drm/i915/i915_drv.h | 13 ++---
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/
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
This requires a few changes
- We still need a noop function for crtc->disable, becuase the fb
helper is a bit too intimate with the crtc helper.
- We need to clear crtc->fb ourselves in intel_crtc_disable now that
we no longer rely on the helper's disable_unused_functions to do
that.
- We nee
... using the pipe masks from the previous patch.
Well, not quite:
- We still need to call the disable_unused_functions helper, until
we've moved the call to commit_output_state further down and
adjusted intel_crtc_disable a bit. The next patch will do that.
- Because we don't support (yet) mo
This is definetely a bit more generic than currently required, but
if we keep track of all crtcs that need to be disabled/enable (because
they loose an encoder or something similar), crtcs that get completely
disabled and those that we need to do an actual mode change on nicely
prepares us for glob
- Use the check_cloned helper from the previous patch.
- Use encoder->new_crtc to check crtc properties.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/d
The "is this encoder cloned" check will be reused by the lvds encoder,
hence exract it.
v2: Be a bit more careful about that we need to check the new, staged
ouput configuration in the check_non_cloned helper ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 22 +
While at it, adjust a few things:
- Only assigng the new mode to crtc->mode right before calling the
mode_set callbacks - none of the previous callbacks depend upon
this, they all use the mode argument (as they should).
- Check encoder->new_crtc instead of the current crtc to check whether
th
It's rather pointless to compute crtc->enabled twice right away ;-)
The only thing we really have to be careful about is that we frob the
dpms state only after a successful modeset and when we've actually
haven't just disabled the crtc.
Hooray for convoluted interfaces ...
Signed-Off-by: Daniel
Originally this has been introduced in
commit 6eebd6bb5f1ea04f04019e5c39f87a0f17ffb472
Author: Chris Wilson
Date: Mon Nov 28 21:10:05 2011 +
drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)
With the improvements of the output state staging and no longer
overwriti
Passing in the old fb, having overwritten the current fb, leads to
some neatly convoluted code. It's much simpler if we defer the
crtc->fb update to the place that updates the hw, in pipe_set_base.
This way we also don't need to restore anything in case something
fails - we only update crtc->fb onc
This is the core of the new modeset logic.
The current code which is based upon the crtc helper code first
updates all the link of the new display pipeline and then calls the
lower-level set_mode function to execute the required callbacks to get
there. The issue with this approach is that for disa
We actually only touch the connector -> encoder and encoder -> crtc
linking. So it's enough to just save/restore that.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 28 +++-
drivers/gpu/drm/i915/intel_drv.h |4 ++--
2 files changed, 17
Because they all are, the ioctl command never calls us with any of
these violated. Also drop a equally pointless empty debug message (and
also in set_cursor, while we're at it).
With all these changes, intel_crtc_set_config is neatly condensed down
to it's essence, the actual modeset code (or fb u
Otherwise we'll set_fb complains pretty loudly if we the crtc is off
and userspace moves the NULL fb around a bit. Yeah, this actually
happens in the wild ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff -
Yikes!
But yeah, we have to do this until someone volunteers to clean up the
fb helper and rid it of its incetious relationship with the crtc
helper code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
Note that this function already clobbers the mode config state,
so we have to clean things up if something fails.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 121 +++---
1 files changed, 67 insertions(+), 54 deletions(-)
diff --git a/driv
This computes what exactly changed in the modeset configuration, i.e.
whether a full modeset is required or only an update of the
framebuffer base address or no change at all.
In the future we might add more checks for e.g. when only the output
mode changed, so that we could do a minimal modeset f
At the end this won't be of much use to us, but meanwhile just extract
it to get a better overview of what exactly set_config does.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 127 --
1 files changed, 76 insertions(+), 51 deletions(-)
intel_crtc_set_config is an unwidly beast and is in serious need of
some function extraction. To facilitate that, introduce a struct to
keep track of all the state involved. Atm it doesn't do much more than
keep track of all the allocated memory.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/
Many BIOSen forget to turn on the pipe A after resume (because they
actually don't turn on anything), so we have to do that ourselves when
sanitizing the hw state.
I've discovered this due to the recent addition of a pipe WARN that
takes the force quirk into account.
v2: Actually try to enable th
We now track the connector state in encoder->connectors_active, and
because the DP output can't be cloned, that is sufficient to track the
link state. Hence use this instead of adding yet another modeset state
variable with dubious semantics at driver load and resume time.
Also, connectors_active
Afaict this has been used for two things:
- To prevent the crtc enable code from being run twice. We have now
intel_crtc->active to track this in a more precise way.
- To ensure the code copes correctly with the unknown hw state after
boot and resume. Thanks to the hw state readout and sanitize
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.
v2: Fix dpms check and don't presume that if the hw isn't
... 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
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|
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
Note that even though this connector is cloneable we still can use the
exact same test to check whether the connector is on or whether the
encoder 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-Off-
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 e3dd7b3..af78502 100644
--- a/drivers/gpu/drm/i915/i
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 3136f56..aa9beaa 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/dr
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/
Also add some macros to make the pipe computation a bit easier.
v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_dp.c | 50 +++
2 files c
It is all glorious if we try really hard to only enable/disable 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
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
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
- 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
Together with the static helper functions 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 pla
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 +++
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 7edb3a1..28a5ba0 1006
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(+),
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/
It's unused. At it confused me quite a bit until I've discovered that.
Cc: dri-de...@lists.freedesktop.org
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 bac55
Go through the interface vtable instead, because not everyone might be
using the crtc helper code.
Cc: dri-de...@lists.freedesktop.org
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
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
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
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
Intel hw only has one MUX for encoders, so outputs are either 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 b
Similar to the sdvo conversion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dvo.c | 32 ++--
1 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index d72584a..756e977 10
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
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
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
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(
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
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 e754c
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
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
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
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
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
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
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
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 shouldn't call the encoder's disable
func
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 this new set of crtc display_funcs take full
responsibility of modeset operations for the entire display output
pipeline (by calling down into
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
selecting which one (and atm there isn't even much magic, but on
recent platforms where not even
Or: How to fix cpu edp in 81 simple steps. Admittedly this includes some minor
detours.
Yeah, I've managed to pull it through and finally put the last piece into place
that started this entire endeavour: cpu edp on my ivb works!
I'm too lazy to repeat all the high-level overview stuff from the co
On Wed, 11 Jul 2012 12:31:52 +0200, Daniel Vetter
wrote:
> Somehow detect_ddc manages to fall through all checks when we think
> that something responds on the ddc i2c address, but the edid read
> failed. Fix this up by explicitly checking for this case.
>
> This fixes a regression on newer chip
On Wed, 11 Jul 2012 12:31:53 +0200, Daniel Vetter
wrote:
> We have way too much lying hardware to rely on a simple "does someone
> answer on the ddc i2c address?" check. And now it's unused, so just
> kill it.
>
> Signed-Off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson,
We have way too much lying hardware to rely on a simple "does someone
answer on the ddc i2c address?" check. And now it's unused, so just
kill it.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h |1 -
drivers/gpu/drm/i915/intel_modes.c | 28
Somehow detect_ddc manages to fall through all checks when we think
that something responds on the ddc i2c address, but the edid read
failed. Fix this up by explicitly checking for this case.
This fixes a regression on newer chips because since
commit aaa377302b2994fcc2c66741b47da33feb489dca
Auth
On Wed, 11 Jul 2012 11:47:51 +0200, Daniel Vetter
wrote:
> Somehow detect_ddc manages to fall through all checks when we think
> that something responds on the ddc i2c address, but the edid read
> failed. Fix this up by explicitly checking for this case.
I'd prefer if we flatten the control flow
Somehow detect_ddc manages to fall through all checks when we think
that something responds on the ddc i2c address, but the edid read
failed. Fix this up by explicitly checking for this case.
This fixes a regression on newer chips because since
commit aaa377302b2994fcc2c66741b47da33feb489dca
Auth
On Wed, Jul 11, 2012 at 12:36:59AM +0200, Daniel Vetter wrote:
> On Wed, Jul 11, 2012 at 12:31:06AM +0200, Daniel Vetter wrote:
> > I so totally suck.
> >
> > This can cause a black screen if (for whatever reason) the bios
> > hasn't set this bit itself.
> >
> > This regression has been introduce
On Tue, 10 Jul 2012 21:44:14 -0700, Ben Widawsky wrote:
> This is precursor to some work I'm doing, but I think it stands nicely
> as its own refactor.
>
> Signed-off-by: Ben Widawsky
Reviewd-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
97 matches
Mail list logo
