On Sun, 2013-06-09 at 11:18 +0200, Daniel Vetter wrote:
> Hi stable maintainers,
>
> Please backport
>
> commit e3de42b68478a8c95dd27520e9adead2af9477a5
> Author: Imre Deak
> Date: Fri May 3 19:44:07 2013 +0200
>
> drm/i915: force full modeset if the connector is in DPMS OFF mode
>
> to
On Wed, Jun 12, 2013 at 11:42:56PM +0100, Chris Wilson wrote:
> On Wed, Jun 12, 2013 at 02:15:48PM -0700, Ben Widawsky wrote:
> > On Mon, Jun 10, 2013 at 01:54:50PM +0100, Chris Wilson wrote:
> > > In particular, we were reseting our GEM tracking before even attempting
> > > (and failing) to reset
Again we don't really support different settings, so don't let the
BIOS sneak stuff through.
Since the motivation for this patch series is to ensure we have the
correct gamma table mode selected also add the required write to the
GAMMA_MODE register to select the 8bit legacy table.
And since I fi
Same reasons as for the previous patch, just no bug report about
anything going wrong yet: We only support exactly the mode we program,
so don't leave any stale BIOS state behind.
Again this will be fun to properly track for fastboot.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
Dragging random garbage along from the BIOS isn't a good idea, since
we really only support exactly what we've set up.
In the specific case for the bug reporter the BIOS used the 10bit
gamma table, but since we only support an 8bit table the dark colors
ended up all wrong and the light ones all un
On Wed, Jun 12, 2013 at 02:13:26PM -0700, Ben Widawsky wrote:
> 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 conte
On Wed, Jun 12, 2013 at 02:15:48PM -0700, Ben Widawsky wrote:
> On Mon, Jun 10, 2013 at 01:54:50PM +0100, Chris Wilson wrote:
> > In particular, we were reseting our GEM tracking before even attempting
> > (and failing) to reset the chip. Do it with the other bookkeeping after
> > successfully rese
On Wed, Jun 12, 2013 at 03:06:51PM -0700, Jesse Barnes wrote:
> On Wed, 12 Jun 2013 00:48:25 +0100
> Chris Wilson wrote:
>
> > On Tue, Jun 11, 2013 at 04:01:21PM -0700, Stéphane Marchesin wrote:
> > >
> > > On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson
> > > wrote:
> > > > On Tue, Jun 11, 2013
On Wed, Jun 12, 2013 at 02:19:38PM -0700, Jesse Barnes wrote:
> On Wed, 12 Jun 2013 22:11:18 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > 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 f
On Wed, Jun 12, 2013 at 01:37:26PM +0200, Daniel Vetter wrote:
> 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 disab
On Wed, 12 Jun 2013 00:48:25 +0100
Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 04:01:21PM -0700, Stéphane Marchesin wrote:
> >
> > On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson
> > wrote:
> > > On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
> > >> During suspend all fenc
On Wed, 12 Jun 2013 22:11:18 +0300
ville.syrj...@linux.intel.com wrote:
> 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 experimentatio
On Mon, Jun 10, 2013 at 01:54:50PM +0100, Chris Wilson wrote:
> In particular, we were reseting our GEM tracking before even attempting
> (and failing) to reset the chip. Do it with the other bookkeeping after
> successfully reseting. Note that we can simplify the reset to always do
> the GPU reini
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
Signed-off-by: Rodrigo Vivi
---
src/sna/sna_accel.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 1663fe3..c1df7c9 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -14174,6 +14174,19 @@ static bo
PSR tracking engine in HSW doesn't detect automagically some directly copy area
operations through scanout so we have to kick it manually and reschedule it to
come back to normal operation as soon as possible.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/
This global value allows userspace know when PSR is enabled and active,
i.e. in SRD entry state.
This will allow userspace emit more busy_ioctl when doing directly copy_area
operations through scanout allowing forced psr exit.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
PSR is enabled by default but can be disabled.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 6 ++
4 files changed, 15 insertions(+)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 169 +---
1 file changed, 87 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a7f3bd1..c5ea419 100644
--- a/drivers/gpu/drm/i91
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
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
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
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
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
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
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
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
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: 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(
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
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
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
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 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
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
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
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
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.
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
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 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
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 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 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 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 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
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 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
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 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 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 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
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 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
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
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
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
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:
> 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 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)
> > >
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 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 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: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: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
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 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
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: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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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)
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 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
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 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
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
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
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/
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:
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
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
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
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
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?
1 - 100 of 119 matches
Mail list logo
