With the option '-r', the testdisplay could paint a 2-D bar code(QR bar code)
on the screen. The word "pass" is hiden in the bar code image.
Further more, with this option, testdisplay will wait until a system signal
'SIGUSR1' coming after each mode setting. This function is for another program
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/t
The power docs say that when the gt leaves rc6, it is in the lowest
frequency and only about 25 usec later will switch to the frequency
selected in GEN6_RPNSWREQ. If the downclock limit expires in that
window and the down limit is set to the lowest possible frequency, the
hw will not send the down
On Thu, 26 Jul 2012 11:16:14 +0200, Daniel Vetter
wrote:
> The power docs say that when the gt leaves rc6, it is in the lowest
> frequency and only about 25 usec later will switch to the frequency
> selected in GEN6_RPNSWREQ. If the downclock limit expires in that
> window and the down limit is s
And then I remembered I was going to mention...
I spent yesterday evening trying to tempt the fail back to IVB, to no
avail. So I think the underlying cause was the sporadic read returning 0
which we promptly set to rplim with the original rmw sequence. Then we
falsely continued to warn during int
We believe to have squashed all issues around the gen6+ rps interrupt
generation and why the gpu sometimes got stuck. With that cleared up,
there's no user left for the sanitize_pm infrastructure, so let's just
rip it out.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |
On Thu, 26 Jul 2012 11:50:05 +0200, Daniel Vetter
wrote:
> We believe to have squashed all issues around the gen6+ rps interrupt
> generation and why the gpu sometimes got stuck. With that cleared up,
> there's no user left for the sanitize_pm infrastructure, so let's just
> rip it out.
>
> Sign
On Tue, Jul 10, 2012 at 10:27:08AM +0100, Chris Wilson wrote:
> By selecting the cache level (essentially whether or not the CPU snoops
> any updates to the bo, and on more recent machines whether it resides
> inside the CPU's last-level-cache) a userspace driver is able to then
> manage all of its
Several functions of the GPU have the restriction that differing memory
domains cannot be placed next to each other (as the GPU may prefetch
beyond the end of one domain and hang as it crosses into the other
domain). We use the facility of the drm_mm to mark ranges with a
particular color that corr
Date: Thu, 26 Jul 2012 12:51:57 +0200
Signed-off-by: Paul Menzel
---
NEWS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index a6819d4..08340f8 100644
--- a/NEWS
+++ b/NEWS
@@ -38,7 +38,7 @@ Among the other tweaks this week:
* Shadow support was dropped from
On Thu, Jul 26, 2012 at 11:49:32AM +0100, Chris Wilson wrote:
> Several functions of the GPU have the restriction that differing memory
> domains cannot be placed next to each other (as the GPU may prefetch
> beyond the end of one domain and hang as it crosses into the other
> domain). We use the f
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Jul 26, 2012 at 11:14:59AM +0100, Chris Wilson wrote:
> On Thu, 26 Jul 2012 11:50:05 +0200, Daniel Vetter
> wrote:
> > We believe to have squashed all issues around the gen6+ rps interrupt
> > generation and why the gpu sometimes got stuck. With that cleared up,
> > there's no user left f
... but this time around don't forget to save/restore the lbpc reg.
--
Hi Carsten,
Please test this quick hack, afaict that should be more towards the
ultimate truth of gen4 backlight heaven than adding random invert
brightness quirks.
Yours, Daniel
---
drivers/gpu/drm/i915/i915_drv.h |
... but this time around don't forget to save/restore the lbpc reg.
v2: Actually try to restroe LBPC on resume.
--
Hi Carsten,
Please test this quick hack, afaict that should be more towards the
ultimate truth of gen4 backlight heaven than adding random invert
brightness quirks.
Yours, Daniel
-
... but this time around don't forget to save/restore the lbpc reg.
v2: Actually try to restroe LBPC on resume.
--
Hi Carsten,
Please test this quick hack, afaict that should be more towards the
ultimate truth of gen4 backlight heaven than adding random invert
brightness quirks.
Yours, Daniel
-
Add Haswell audio registers definition and dump support.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c | 574 +-
1 file changed, 571 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 8a0f
On Thu, Jul 26, 2012 at 02:23:36PM +0800, Yi Sun wrote:
> With the option '-r', the testdisplay could paint a 2-D bar code(QR bar code)
> on the screen. The word "pass" is hiden in the bar code image.
> Further more, with this option, testdisplay will wait until a system signal
> 'SIGUSR1' coming
Okay, thank you Daniel.
Thanks
--Yi Sun
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, July 26, 2012 9:02 PM
> To: Sun, Yi
> Cc: daniel.vet...@ffwll.ch; Jin, Gordon; intel-gfx@lists.freedesktop.org
> Subject: Re:
... but this time around don't forget to save/restore the lbpc reg.
v2: Actually try to restroe LBPC on resume.
v3: _Really_ try to git add.
--
Hi Carsten,
Please test this quick hack, afaict that should be more towards the
ultimate truth of gen4 backlight heaven than adding random invert
bright
... by adding seemingly redudant posting reads.
This little dragon lair exploded the first time around when we've
refactored the code a bit to use the common wait_for_atomic_us in
"drm/i915: Group the GT routines together in both code and vtable",
which caused QA to file fdo bug #51738.
Chris Wil
On Thu, 26 Jul 2012 16:24:50 +0200, Daniel Vetter
wrote:
> ... by adding seemingly redudant posting reads.
>
> This little dragon lair exploded the first time around when we've
> refactored the code a bit to use the common wait_for_atomic_us in
> "drm/i915: Group the GT routines together in both
Thank you for your statement, Daniel.
Is there any way to work around the HDMI infoframe issues you have
mentioned? Are there any patches I could try?
Regards,
Frederik
2012/7/24 Daniel Vetter :
> On Tue, Jul 24, 2012 at 08:46:04PM +0200, Frederik Vogelsang wrote:
>> Hi,
>>
>> thanks for your
On Thu, Jul 26, 2012 at 06:26:17PM +0200, Frederik Vogelsang wrote:
> Thank you for your statement, Daniel.
>
> Is there any way to work around the HDMI infoframe issues you have
> mentioned? Are there any patches I could try?
Other people have already tested 3.6-next and it did not help. So I gu
From: Damien Lespiau
Also, ignore tags/TAGS files generated by "make tags".
Signed-off-by: Damien Lespiau
---
.gitignore |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 243457e..93d1ffa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,6
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index eae2199..43c49a9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_ge
On Thu, Jul 26, 2012 at 03:50:02PM +0100, Chris Wilson wrote:
> On Thu, 26 Jul 2012 16:24:50 +0200, Daniel Vetter
> wrote:
> > ... by adding seemingly redudant posting reads.
> >
> > This little dragon lair exploded the first time around when we've
> > refactored the code a bit to use the common
Damien Lespiau writes:
> From: Damien Lespiau
>
> Signed-off-by: Damien Lespiau
> ---
> intel/intel_bufmgr_gem.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index eae2199..43c49a9 100644
> --- a/intel/int
---
intel/intel_bufmgr_gem.c |1 +
1 file changed, 1 insertion(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 57319fb..22f3cba 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2848,6 +2848,7 @@ drm_intel_gem_context_create(drm_intel_bufmgr *b
Hi
2012/7/3 Daniel Vetter :
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f33fe1a..b71303c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -752,3 +747,18 @@ void intel_ddi_dpms(struct drm_encoder *encoder
Olivier Galibert writes:
> In some cases the fragment shader view of the vue registers was out of
> sync with the builder. This fixes it.
s/builder/SF outputs/ ?
I'd love to see the pre-gen6 code get rearranged so the FS walked the
bitfield of FS inputs from SF and chose the urb offset for eac
Olivier Galibert writes:
> Previous code only selected two side in pure fixed-function setups.
> This version also activates it when needed with shaders programs.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_sf.c |2 +-
> 1 file changed, 1 insertion(+), 1 deleti
Olivier Galibert writes:
> @@ -121,12 +108,15 @@ static void do_twoside_color( struct brw_sf_compile *c )
> brw_push_insn_state(p);
> brw_CMP(p, vec4(brw_null_reg()), backface_conditional, c->det,
> brw_imm_f(0));
> brw_IF(p, BRW_EXECUTE_4);
> - {
> - switch (c->nr_verts) {
> -
Olivier Galibert writes:
> The program keys are updated accordingly, but the values are not used
> yet.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_clip.c| 90
> ++-
> src/mesa/drivers/dri/i965/brw_clip.h|1 +
> src/mesa/d
Daniel Vetter writes:
> We don't yet use this, but now that we start to look into putting that
> l3$ we better set the associated flush bit, too.
>
> Also add the only other missing PIPE_CONTROL bit #define.
Reviewed-by: Eric Anholt
pgpmuUosTUjO0.pgp
Description: PGP signature
___
Daniel Vetter writes:
> Since we don't guarantee that objects stay at the same gtt offset,
> userspace needs to reload all indirect state anyway, even with hw
> contexts. The hw provides a little pipe_control flag to disable at
> least some these indirect state pointers and hence avoid to
> save/
On Thu, Jul 26, 2012 at 7:33 PM, Eric Anholt wrote:
> Daniel Vetter writes:
>
>> Since we don't guarantee that objects stay at the same gtt offset,
>> userspace needs to reload all indirect state anyway, even with hw
>> contexts. The hw provides a little pipe_control flag to disable at
>> least s
Hi
2012/7/11 Daniel Vetter :
> @@ -2502,7 +2495,6 @@ intel_dp_init(struct drm_device *dev, int output_reg)
> return;
>
> intel_dp->output_reg = output_reg;
> - intel_dp->dpms_mode = -1;
In your current modeset-rework branch, you're also removing the
"intel_dp->port =
Hi all,
Mostly just rebased, but a few bikesheds from Paulo incorporated. I've also
moved the patches that can go in early to the front (the first 8 patches).
Bigger changes since last time around:
- added support for the newly merged ns2501 dvo controller
- s/intel_crtc_set_mode/intel_set_mode/
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the ne
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 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dri
With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/dvo_ns2501.c|7 ---
drivers/gpu/drm/i915/intel_display.c |2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gp
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
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
... 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 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
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 file changed, 33 insertions(+), 24
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
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
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 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu
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 file changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/
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
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 file chang
Similar to the sdvo conversion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dvo.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 227551f..4ad988f 100
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 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/d
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
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 file 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 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7ae1a71..941d0d1 10064
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 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
- 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 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/
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
Instead of going through the crtc helper function tables.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
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/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
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
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(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 0876782..7828583 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i91
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 5fc7abc..52f9e7f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b
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-
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 6 dvo drivers.
v2: With the newly added ns2501 we now have 6 dvo drivers instead of
ju
... 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.
v2: Fix dpms check and don't presume that if the hw isn't
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
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
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
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/
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 file changed, 76 insertions(+), 51 deletions(-)
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
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 file changed, 67 insertions(+), 54 deletions(-)
diff --git a/drive
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 file changed, 6 insertions(+)
diff --git a/drivers/g
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 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
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
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
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
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
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
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
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 +
- 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 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/dr
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
... 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 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
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 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/
1 - 100 of 120 matches
Mail list logo
