On Wed, Jun 12, 2013 at 12:07:39AM +0100, Damien Lespiau wrote:
> On Tue, May 21, 2013 at 09:54:54PM +0200, Daniel Vetter wrote:
> > Again the same confusion that our code expects m1/m2 in register values.
> > This time around with the added fun that many of the existing values
> > have been all of
On Wed, Jun 12, 2013 at 12:07:39AM +0100, Damien Lespiau wrote:
> On Tue, May 21, 2013 at 09:54:54PM +0200, Daniel Vetter wrote:
> > Again the same confusion that our code expects m1/m2 in register values.
> > This time around with the added fun that many of the existing values
> > have been all of
On Tue, Jun 11, 2013 at 04:18:46PM -0700, Jesse Barnes wrote:
> On Tue, 11 Jun 2013 23:06:59 +0200
> Daniel Vetter wrote:
>
> > On Tue, Jun 11, 2013 at 11:08:16PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The current PLL settings produce a rather uns
On Wed, Jun 12, 2013 at 10:14 AM, Ville Syrjälä
wrote:
> On Tue, Jun 11, 2013 at 04:18:46PM -0700, Jesse Barnes wrote:
>> On Tue, 11 Jun 2013 23:06:59 +0200
>> Daniel Vetter wrote:
>>
>> > On Tue, Jun 11, 2013 at 11:08:16PM +0300, ville.syrj...@linux.intel.com
>> > wrote:
>> > > From: Ville Syrj
Stéphane Marchesin found that fences for pinned objects (i.e. the
scanout) were not being restored upon resume, leading to corruption on
the display and reference counting issues. This is due to a bug in
commit 312817a39f17dbb4de000165b5b724e3728cd91c [2.6.38]
Author: Chris Wilson
Date: Mon Nov
For guilty batchbuffer analysis later on when rings are reset,
store what state the ring was on when hang was declared.
This helps to weed out the waiting rings from the active ones.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c |8 ++--
drivers/gpu/drm/i915/in
In order to track down a batch buffer and context which
caused the ring to hang, store reference to bo into the request struct.
Request can also cause gpu to hang after the batch in the flush section
in the ring. To detect this add start of the flush portion offset into the
request.
Signed-off-by:
To count context losses, add struct i915_ctx_hang_stats for
both i915_hw_context and drm_i915_file_private.
drm_i915_file_private is used when there is no context.
v2: renamed and cleaned up the struct (Chris Wilson, Ian Romanick)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c
If context has recently submitted a faulty batchbuffers guilty of
gpu hang and decides to keep submitting more crap, ban it permanently.
v2: Store guilty ban status bool in gpu_error instead of pointers
that might become danling before hang is declared.
v3: Use return value for banned status
To get context hang statistics for specified context,
add i915_gem_context_get_hang_stats().
For arb-robustness, every context needs to have its own
hang statistics tracking. Added function will return
the user specified context statistics or in case of
default context, statistics from drm_i915_fi
Only execbuffer needed all the parameters on i915_add_request().
By putting __i915_add_request behind macro, all current callsites
become cleaner. Following patch will introduce a new parameter
for __i915_add_request. With this patch, only the relevant callsite
will reflect the change making commit
After hang check timer has declared gpu to be hang,
rings are reset. In ring reset, when clearing
request list, do post mortem analysis to find out
the guilty batch buffer.
Select requests for further analysis by inspecting
the completed sequence number which has been updated
into the HWS page. If
On Tue, Jun 11, 2013 at 03:49:26PM -0700, Stéphane Marchesin wrote:
> It's basically the same deal as the RC6+ issues on ivy bridge
> except this time with RC6 on sandy bridge. Like last time the
> core of the issue is that the timings don't work 100% with our
> voltage regulator. So from time to t
We don't (yet) have proper pixel multiplier readout support on pch
split platforms, so the cross check will naturally fail.
v2: Fix spelling in the comment, spotted by Ville.
v3: Since the ordering constraint is pretty tricky between the crtc
get_pipe_config callback and the encoder->get_config c
As we play games in set-to-domain in order to first perform a lockless
wait on outstanding rendering, it is possible that we report a spurious
GPU hang during that wait. After reclaiming the lock we then want to do
a more thorough test as to whether the hang is indeed fatal and what the
correct err
On Wed, Jun 12, 2013 at 12:35:31PM +0300, Mika Kuoppala wrote:
> In order to track down a batch buffer and context which
> caused the ring to hang, store reference to bo into the request struct.
> Request can also cause gpu to hang after the batch in the flush section
> in the ring. To detect this
On Wed, Jun 12, 2013 at 12:35:33PM +0300, Mika Kuoppala wrote:
> After hang check timer has declared gpu to be hang,
s/hang/hung/ :-p
> rings are reset. In ring reset, when clearing
> request list, do post mortem analysis to find out
> the guilty batch buffer.
>
> Select requests for further anal
Stéphane Marchesin found a bug where the fences were not being restored,
and in particular the fence pin_count was incorrect. Had we had a
warning in place, this bug would have come to light much earlier. Better
late than never?
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Stéphane Marchesi
On Wed, Jun 12, 2013 at 12:35:28PM +0300, Mika Kuoppala wrote:
> To count context losses, add struct i915_ctx_hang_stats for
> both i915_hw_context and drm_i915_file_private.
> drm_i915_file_private is used when there is no context.
>
> v2: renamed and cleaned up the struct (Chris Wilson, Ian Roma
On Wed, Jun 12, 2013 at 11:29:47AM +0100, Chris Wilson wrote:
> Stéphane Marchesin found a bug where the fences were not being restored,
> and in particular the fence pin_count was incorrect. Had we had a
> warning in place, this bug would have come to light much earlier. Better
> late than never?
On Wed, Jun 12, 2013 at 09:39:54AM +0200, Daniel Vetter wrote:
> Afaik eaglelake as the desktop version of cantiga has all the same stuff
> (minus a few mobile-only power saving features). The spreadsheet I have
> here is even called eaglelake_cantiga_something.xls.
Ah right, so let's believe this
Hi all,
So here's my irq locking review, inspired by the VECS patches. The first part
(up to patch 14) deals mostly with display interrupts and especially
interactions between the hpd storm detection and the fifu underrun reporting.
Most of it is just unification, but there's two cases where lock
The haswell unclaimed register handling code forgot to take the
spinlock. Since this is in the context of the non-rentrant interupt
handler and we only have one interrupt handler it is sufficient to
just grab the spinlock - we do not need to exclude any other
interrupts from running on the same cpu
By the time we write DEIER in the postinstall hook the interrupt
handler could run any time. And it does modify DEIER to handle
interrupts.
Hence the DEIER read-modify-write cycle for enabling the PCU event
source is racy. Close this races the same way we handle vblank
interrupts: Unconditionally
Just to keep the paranoia equal also sprinkle locking asserts over the
pipestat interrupt enable/disable functions.
Again this results in false positives in the interrupt setup. Add
bogo-locking for these and a big comment explaining why it's there and
that it's indeed unnecessary.
Signed-off-by:
We already have a vfunc for this (and other parts of the hpd storm
handling code already use it).
Cc: Egbert Eich
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/
Everywhere the same.
Cc: Egbert Eich
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1f8d914..38bb26f 100644
--- a/drivers/gpu
The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.
To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the en
The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.
Cc: Egbert Eich
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 33 +
1 file
Our interrupt handler (in hardird context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in th
The preinstallhook is supposed to clear all interrupts. Doing it
again in the postinstall hook has the risk that we're eating
an interrupt source from the handler. If that happens too often,
the kernel will disable our interrupt handler.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915
This way all changes to SDEIMR all go through the same function, with
the exception of the (single-threaded) setup/teardown code.
For paranoia again add an assert_spin_locked.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 42 +++--
1 file
Same treatment as for SERR_INT: If we clear only the bit for the pipe
we're enabling (but unconditionally) then we can always check for
possible underruns after having disabled the interrupt. That way pipe
underruns won't be lost, but at worst only get reported in a delayed
fashion.
Signed-off-by:
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always clear the transcoder's bit (and none of the other bits)
It's racy: There's no guarantee that we won't walk this code (due to a
pch fifo underrun interrupt) while someone is changing the pointers
around.
The only reason we do this is to use the righ crtc for the pch fifo
underrun accounting. But we never expose this to userspace, so
essentially no one r
Since we only have one interrupt handler and interrupt handlers are
non-reentrant.
To drive the point really home give them all an _irq_handler suffix.
This is a tiny micro-optimization but even more important it makes it
clearer what locking we actually need. And in case someone screws this
up:
The if (pm_iir & ~GEN6_PM_RPS_EVENTS) check was redunandant. Otoh
adding a check for rps events allows us to avoid the spinlock grabbing
for VECS interrupts.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 22 ++
1 file changed, 10 insertions(+), 12 deletio
And kill the comment about it. Queueing work is a barrier type event,
no amount of locking will help in ordering things (as long as we queue
the work after having updated all relevant data structures). Also, the
queue_work works itself as a sufficient memory barrier.
Again on the surface this is j
Now that the rps interrupt locking isn't clearly separated (at elast
conceptually) from all the other interrupt locking having a different
lock stopped making sense. With this we can (again) unifiy the
ringbuffer irq refcounts without causing a massive confusion, but
that's for the next patch.
Sig
With the simplified locking there's no reason any more to keep the
refcounts seperate.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 +
2 files changed, 11 insertions(+), 14 deletions(-)
diff
The code to handle it is broken - there's simply no code to clear CS
parser errors on gen5+. And behold, for all the other rings we also
don't enable it!
Leave the handling code itself in place just to be consistent with the
existing mess though. And in case someone feels like fixing it all up.
T
Preinstall disables interrupts, we clear the status register in the
postinstall hook before we actually enable interrupt sources.
Also add a comment for the curios ring IMR masking, it doesn't
seem to be required on any other platform.
We seem to have some room for common gt_preinstall/postinstal
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end up in hard to track down surprises.
Hence unifiy things and since we have copies of this code in 3 places
now, extract it into its own little helper.
Signed-o
This just unifies the vlv code with the snb-hsw code which matched
exactly before the VECS enabling.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i9
Again extract a common helper. For the postinstall hook things are a
bit more complicated since we have more cases on ilk-hsw/vlv here.
But since vlv was clearly broken by failing to initialize
dev_priv->gt_irq_mask correclty (mayb that explains the strange
RING_IMR clearing in the preinstall hook
At the moment we have the following interrupt enabling sequence:
1. irq preinstall hook
2. enabling the interrupt handler and calling irq postinstall hook
3. enable rps interrupts from the async work
And the folliwing disable sequence:
1. disabling the interrupt handler and calling the uninstall h
In order to track down a batch buffer and context which
caused the ring to hang, store reference to bo into the request struct.
Request can also cause gpu to hang after the batch in the flush section
in the ring. To detect this add start of the flush portion offset into the
request.
v2: Included c
After hang check timer has declared gpu to be hang,
rings are reset. In ring reset, when clearing
request list, do post mortem analysis to find out
the guilty batch buffer.
Select requests for further analysis by inspecting
the completed sequence number which has been updated
into the HWS page. If
After hang check timer has declared gpu to be hung,
rings are reset. In ring reset, when clearing
request list, do post mortem analysis to find out
the guilty batch buffer.
Select requests for further analysis by inspecting
the completed sequence number which has been updated
into the HWS page. If
On Tue, May 21, 2013 at 09:54:56PM +0200, Daniel Vetter wrote:
> Now this was broken in pretty fundamental ways:
> - M1/M2 have been consistently off by 2 and used doc values instead of
> the two less registers values our code expects.
> - M/N limits often were too small by seemingly arbitrary am
On Sun, May 26, 2013 at 05:48:15PM +0200, Daniel Vetter wrote:
> We can get at this easily through intel_crtc->config now.
>
> v2: Drop more stuff gcc spotted.
>
> v3: Drop even more stuff gcc spotted.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
__
On Tue, May 21, 2013 at 09:54:59PM +0200, Daniel Vetter wrote:
> Panel fitters on ivb/hsw are not created equal since not all of them
> support the new high-quality upscaling mode. To offset this the hw
> allows us to freely assign the pfits to pipes.
>
> Since our code currently doesn't support t
2013/6/12 Daniel Vetter :
> It's racy: There's no guarantee that we won't walk this code (due to a
> pch fifo underrun interrupt) while someone is changing the pointers
> around.
>
> The only reason we do this is to use the righ crtc for the pch fifo
> underrun accounting. But we never expose this
On Wed, Jun 05, 2013 at 01:34:16PM +0200, Daniel Vetter wrote:
> Currently still with an empty register state, this will follow in a
> next step. This one here just creates the new vfunc and uses it for
> cross-checking, initial state takeover and the dpll assert function.
>
> And add a FIXME for
On Wed, Jun 05, 2013 at 01:34:17PM +0200, Daniel Vetter wrote:
> Simply grew too big. This also makes the fixup and restore logic in
> setup_hw_state stand out a bit more clearly.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_displ
On Wed, Jun 05, 2013 at 01:34:18PM +0200, Daniel Vetter wrote:
> Simply grew too large and neede to be split up into parts.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_display.c | 44
> +---
> 1 f
On Wed, Jun 05, 2013 at 01:34:19PM +0200, Daniel Vetter wrote:
> Now that we have proper hw state reconstruction we should never have a
> case where we don't have the software dpll state properly set up. So
> add WARNs to the respective !pll cases in enable/disabel_shared_dpll.
>
> Signed-off-by:
On Wed, Jun 12, 2013 at 02:31:23PM +0100, Damien Lespiau wrote:
> On Wed, Jun 05, 2013 at 01:34:16PM +0200, Daniel Vetter wrote:
> > @@ -8621,6 +8657,17 @@ static void intel_cpu_pll_init(struct drm_device
> > *dev)
> > intel_ddi_pll_init(dev);
> > }
> >
> > +static bool ibx_pch_dpll
On Wed, Jun 12, 2013 at 04:39:14PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 12, 2013 at 02:31:23PM +0100, Damien Lespiau wrote:
> > On Wed, Jun 05, 2013 at 01:34:16PM +0200, Daniel Vetter wrote:
> > > @@ -8621,6 +8657,17 @@ static void intel_cpu_pll_init(struct drm_device
> > > *dev)
> > >
Daniel Vetter writes:
> The combination of Paulo's fifo underrun detection code and Egbert's
> hpd storm handling code unfortunately made the hpd storm handling code
> racy.
>
> To avoid duplicating tricky interrupt locking code over all platforms
> start with a bit of refactoring. This patc
On Wed, Jun 05, 2013 at 01:34:17PM +0200, Daniel Vetter wrote:
> Simply grew too big. This also makes the fixup and restore logic in
> setup_hw_state stand out a bit more clearly.
>
> Signed-off-by: Daniel Vetter
So I've managed to massively botch up patch ordering here, due to the lack
of refco
Daniel Vetter writes:
> Everywhere the same.
>
> Cc: Egbert Eich
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
[reviewed code deleted]
Reviewed-by: Egbert Eich
Daniel Vetter writes:
> The usual pattern for our sub-function irq_handlers is that they check
> for the no-irq case themselves. This results in more streamlined code
> in the upper irq handlers.
>
> Cc: Egbert Eich
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c
It's racy: There's no guarantee that we won't walk this code (due to a
pch fifo underrun interrupt) while someone is changing the pointers
around.
The only reason we do this is to use the righ crtc for the pch fifo
underrun accounting. But we never expose this to userspace, so
essentially no one r
On Wed, Jun 12, 2013 at 11:47:24AM +0200, Daniel Vetter wrote:
> We don't (yet) have proper pixel multiplier readout support on pch
> split platforms, so the cross check will naturally fail.
>
> v2: Fix spelling in the comment, spotted by Ville.
>
> v3: Since the ordering constraint is pretty tri
Daniel Vetter writes:
> Our interrupt handler (in hardird context) could race with the timer
Nitpick: s/d/q/
> (in softirq context), hence we need to hold the spinlock around the
> call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
>
> But as an optimization (an
On Wed, Jun 05, 2013 at 01:34:20PM +0200, Daniel Vetter wrote:
> Just the plumbing, all the modeset and enable code has not yet been
> switched over to use the new state. It seems to be decently broken
> anyway, at least wrt to handling of the special pixel mutliplier
> enabling sequence. Follow-up
On Wed, Jun 12, 2013 at 4:26 PM, Egbert Eich wrote:
> Daniel Vetter writes:
> > We already have a vfunc for this (and other parts of the hpd storm
> > handling code already use it).
> >
> > Cc: Egbert Eich
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 29
On Wed, Jun 12, 2013 at 4:59 PM, Egbert Eich wrote:
> > +assert_spin_locked(&dev_priv->irq_lock);
> > +
> > if (I915_HAS_HOTPLUG(dev)) {
> > hotplug_en = I915_READ(PORT_HOTPLUG_EN);
> > hotplug_en &= ~HOTPLUG_INT_EN_MASK;
>
>
> Didn't you want to do the same
On Wed, Jun 05, 2013 at 01:34:21PM +0200, Daniel Vetter wrote:
> We have a nice comment saying that the pixel multiplier only sticks
> once the vco is on and stable. The only problem is that the enable bit
> wasn't set at all. This patch fixes this and so brings the ilk+ pch
> pll code in line with
On Wed, Jun 05, 2013 at 01:34:24PM +0200, Daniel Vetter wrote:
> Just yet another prep step to be able to do all this up-front, before
> we've set up any of the shared dplls in the new state. This will
> eventually be useful for atomic modesetting.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: D
Daniel Vetter writes:
> We already have a vfunc for this (and other parts of the hpd storm
> handling code already use it).
>
> Cc: Egbert Eich
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 29 +++--
> 1 file changed, 11 insertions(+),
On Wed, Jun 05, 2013 at 02:21:50PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Hi
>
> So this series is a second version of the patch I sent on April 16th. Daniel
> asked to write some patches to properly initialize the interrupts we're
> touching
> on the PC8+ patches, so the first 5 p
On Wed, Jun 12, 2013 at 01:37:21PM +0200, Daniel Vetter wrote:
> The code to handle it is broken - there's simply no code to clear CS
> parser errors on gen5+. And behold, for all the other rings we also
> don't enable it!
>
> Leave the handling code itself in place just to be consistent with the
On Wed, Jun 12, 2013 at 10:13:41AM -0700, Ben Widawsky wrote:
> On Wed, Jun 12, 2013 at 01:37:21PM +0200, Daniel Vetter wrote:
> > The code to handle it is broken - there's simply no code to clear CS
> > parser errors on gen5+. And behold, for all the other rings we also
> > don't enable it!
> >
>
On Wed, Jun 12, 2013 at 07:18:38PM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2013 at 10:13:41AM -0700, Ben Widawsky wrote:
> > On Wed, Jun 12, 2013 at 01:37:21PM +0200, Daniel Vetter wrote:
> > > The code to handle it is broken - there's simply no code to clear CS
> > > parser errors on gen5+.
On Wed, Jun 12, 2013 at 8:19 PM, Ben Widawsky wrote:
> On Wed, Jun 12, 2013 at 07:18:38PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 12, 2013 at 10:13:41AM -0700, Ben Widawsky wrote:
>> > On Wed, Jun 12, 2013 at 01:37:21PM +0200, Daniel Vetter wrote:
>> > > The code to handle it is broken - there'
On Wed, Jun 12, 2013 at 08:32:44PM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2013 at 8:19 PM, Ben Widawsky wrote:
> > On Wed, Jun 12, 2013 at 07:18:38PM +0200, Daniel Vetter wrote:
> >> On Wed, Jun 12, 2013 at 10:13:41AM -0700, Ben Widawsky wrote:
> >> > On Wed, Jun 12, 2013 at 01:37:21PM +020
From: Ville Syrjälä
The specs are a bit unclear whether the per-plane trickle feed disable
control exists on VLV. There is another trickle feed disable control
in the MI_ARB register.
After some experimentation it turns out both the DSPCNTR trickle feed
bits and the MI_ARB bit can be toggled. Ho
On Wed, Jun 12, 2013 at 12:38:40AM +0100, Damien Lespiau wrote:
> On Tue, May 21, 2013 at 09:54:55PM +0200, Daniel Vetter wrote:
> > So don't try to store it in the DPLL_FP register.
> >
> > Otherwise it looks like the limits for pineview are correct: It has
> > it's own clock computation code, wh
On Wed, Jun 12, 2013 at 04:12:48PM +0100, Damien Lespiau wrote:
> On Wed, Jun 05, 2013 at 01:34:21PM +0200, Daniel Vetter wrote:
> > We have a nice comment saying that the pixel multiplier only sticks
> > once the vco is on and stable. The only problem is that the enable bit
> > wasn't set at all.
From: Paulo Zanoni
Hi
This week I sent a patch called "drm/i915: propagate errors from
intel_dp_init_connector" to fix a Haswell bug that was preventing my machine
from booting. Chris provided a nice suggestion for it, so this series should
implement his suggestion, but split in a few patches. W
From: Paulo Zanoni
By the time we call intel_dp_destroy (which destroys the connector)
the encoder may have been destroyed already, so if we use it we may be
reading some free memory. That happens in drm_mode_config_cleanup()
and also inside intel_dp_init_connector() when we detect a ghost eDP.
From: Paulo Zanoni
In case we detect a "ghost eDP", intel_edp_init_connector frees both
the connector and encoder and then returns. On Haswell, intel_ddi_init
then tries to use the freed encoder on the HDMI initialization path
since the following commit:
commit 21a8e6a4853b2ed39fa4c5188a710f2cf1
From: Paulo Zanoni
Because intel_dp_init_connector is too big for my poor little brain.
No functional changes.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 151 ++--
1 file changed, 82 insertions(+), 69 deletions(-)
diff --git a/drivers
From: Paulo Zanoni
Because calling intel_dp_encoder_destroy inside
intel_edp_init_connector is just wrong. This is the initialization
path, so we should properly unwind all the initialization through the
whole caller stack.
On the intel_dp_encoder_destroy function we do the following:
1 - Call i
From: Paulo Zanoni
Because calling intel_dp_destroy inside intel_edp_init_connector is
just wrong. This is the initialization path, so we should properly
unwind all the initialization through the whole caller stack.
On the intel_dp_destroy function we do the following:
1 - Free edid if it exists
From: Paulo Zanoni
We've been ignoring this return value, so print a nice backtrace in
case it's not what we expected.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dri
From: Paulo Zanoni
We currently print a DRM_DEBUG_KMS message on the happy path and don't
print anything on the "failed to allocate" path. On some desktop
environments (e.g., Unity) I see the "scheduling delayed FBC enable"
thousands and thousands of times on my dmesg.
So kill the useless messag
From: Paulo Zanoni
Because it's the function that destroys the connector, not the
encoder. And we already have intel_dp_encoder_destroy.
This has annoyed me for a long time.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
On Wed, Jun 12, 2013 at 10:15:12AM +0100, Chris Wilson wrote:
> Stéphane Marchesin found that fences for pinned objects (i.e. the
> scanout) were not being restored upon resume, leading to corruption on
> the display and reference counting issues. This is due to a bug in
>
> commit 312817a39f17dbb
From: Shobhit Kumar
v2: Modified and corrected the structures to be more in line for
kernel coding guidelines and rebased the code on Paulo's DP patchset
v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
v4: moving them to include/drm/drm_dp_helper.h and also already
icluding EDP_PSR
From: Shobhit Kumar
v2: reuse of just created is_edp_psr and put it at right place.
v3: move is_edp_psr above intel_edp_disable
Signed-off-by: Shobhit Kumar
Signed-off-by: Rodrigo Vivi
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 +
drivers/gpu/drm/i915/inte
From: Shobhit Kumar
Parse and store useful information in i915_dev_private
v2: Add to new vbt struct and call them psr_*
v3: Fix comment and variable name
Signed-off-by: Shobhit Kumar
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/intel_b
Prep patch for reuse aux_clock_divider with EDP_PSR_AUX_CTL setup.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 58 +++--
1 file changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i91
Adding Enable and Disable PSR functionalities. This includes setting the
PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host.
This patch is heavily based on initial PSR code by Sateesh Kavuri and
Adding support for PSR Status, PSR entry counter and performance counters.
Heavily based on initial work from Shobhit.
v2: Fix PSR Status Link bits by Paulo Zanoni.
CC: Paulo Zanoni
Credits-by: Shobhit Kumar
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 90
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 ++---
drivers/gpu/drm/i915/i915_drv.h | 12 +++
drivers/gpu/drm/i915/intel_dp.c | 68 -
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/driver
PSR must be enabled after transcoder and port are running.
And it is only available for HSW.
v2: move enable/disable to intel_ddi
v3: The spec suggests PSR should be disabled even before backlight (by pzanoni)
v4: also disabling and enabling whenever panel is disabled/enabled.
CC: Paulo Zanoni
S
Required function to disable PSR when going to console mode.
But also can be used whenever PSR mode entry conditions changed.
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_dp.c | 32 +++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
3
1 - 100 of 119 matches
Mail list logo
