Not running the test is not failing.
Signed-off-by: Daniel Vetter
---
tests/kms_sink_crc_basic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 924aadaca610..4be115c2d51c 100644
--- a/tests/kms_sink_crc_basic.c
Less verbose code makes for clearer test logic.
Signed-off-by: Daniel Vetter
---
tests/kms_sink_crc_basic.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 4be115c2d51c..087b79db4b36 100644
--- a/t
On 5/21/2014 2:25 AM, Damien Lespiau wrote:
On Tue, May 20, 2014 at 09:46:01PM +0530, Shobhit Kumar wrote:
- UI is a period, so is homogeneous to time (s), but ui_num being in
s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or
could it be that UI = ui_den / ui_num? would
On Thu, May 22, 2014 at 09:51:22AM +0300, Imre Deak wrote:
> On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote:
> > On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote:
> > > And to answer more specifically...
> > >
> > > On Wed, 21 May 2014 20:54:03 +0300
> > > Ville Syrjälä wrote:
Before purging our pages (as opposed to copying back the contents from
the GPU), make sure that there is not an exposed CPU mmapping through
which the user can inspect the results.
Regression from
commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
Author: Chris Wilson
Date: Tue Mar 25 13:23:06 20
On Thu, May 22, 2014 at 09:16:52AM +0100, Chris Wilson wrote:
> Before purging our pages (as opposed to copying back the contents from
> the GPU), make sure that there is not an exposed CPU mmapping through
> which the user can inspect the results.
>
> Regression from
>
> commit 5537252b6b6d71fb1
Reviewed the code. Everything looks good, so
Reviewed-by: Sourab Gupta
On Wed, May 21, 2014 at 6:09 AM, Rodrigo Vivi wrote:
> needs a small rebase but everything looks good for me so
> Reviewed-by: Rodrigo Vivi
>
>
> On Tue, Apr 15, 2014 at 11:41 AM, wrote:
>
>> From: Ville Syrjälä
>>
>> Sta
Daniel keeps on ramping up the warning level of the DRM and our display
core to make it complain whenever the locking rules are not followed.
This caught
commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes
Date: Tue Mar 26 09:25:45 2013 -0700
drm/i915: enable VT switchless
On Thu, May 22, 2014 at 09:44:40AM +0100, Chris Wilson wrote:
> Daniel keeps on ramping up the warning level of the DRM and our display
> core to make it complain whenever the locking rules are not followed.
> This caught
>
> commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
> Author: Jesse Barnes
On Wed, May 21, 2014 at 03:40:15PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com]
> > Sent: Tuesday, May 20, 2014 12:56 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Mateo Lozano, Oscar
> > Subject: [PATCH 1/2] te
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_crtc.
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9 +++--
1 file changed, 7
Create and attach the drm property to set aspect ratio. If there is no user
specified value, then PAR_NONE/Automatic option is set by default. User can
select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would
come into effect with a mode set.
Signed-off-by: Vandana Kannan
---
dri
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.
V3: Addressing review comm
On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freedesktop.org
> ---
> driver
On Thu, May 22, 2014 at 04:50:49PM +0530, Vandana Kannan wrote:
> In case user has specified an input for aspect ratio through the property,
> then the user space value for PAR would take preference over the value from
> CEA mode list.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freed
On 07/05/2014 17:57, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mapping
On Wed, May 21, 2014 at 07:01:06PM +0300, Mika Kuoppala wrote:
> From: Mika Kuoppala
>
> for proper refcounting to take place as we use
> i915_add_request() for it.
>
> i915_add_request() also takes the context for the request
> from ring->last_context so move the null state batch
> submission a
On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freedesktop.org
Documentation
On 13/05/2014 14:54, Daniel Vetter wrote:
On Tue, May 13, 2014 at 04:46:10PM +0300, Imre Deak wrote:
On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote:
On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote:
In
commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae
Author: Imre Deak
Date:
On Tue, Apr 29, 2014 at 01:35:46PM +0300, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 96ae78d..d8b540b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -401,6 +401,8 @
From: Oscar Mateo
These patches contain refactoring and preparatory work for Execlists [1].
[1http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html]
http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html
Oscar Mateo (6):
drm/i915: s/intel_ring_buffer/intel_engine_
From: Oscar Mateo
This refactoring has been performed using the following Coccinelle
semantic script:
@@
struct intel_engine_cs r;
@@
(
- (r).obj
+ r.buffer->obj
|
- (r).virtual_start
+ r.buffer->virtual_start
|
- (r).head
+ r.buffer->head
|
From: Oscar Mateo
It's barely alive now anyway, so give it the "coup de grâce".
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_context.c | 14 --
3 files changed, 8 i
From: Oscar Mateo
As advanced by the previous patch, the ringbuffers and the engine
command streamers belong in different structs. This is so because,
while they used to be tightly coupled together, the new Logical
Ring Contexts (LRC for short) have a ringbuffer each.
In legacy code, we will use
From: Oscar Mateo
Manual cleanup after the previous Coccinelle script.
Yes, I could write another Coccinelle script to do this but I
don't want labor-replacing robots making an honest programmer's
work obsolete (also, I'm lazy).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_dma.c
From: Oscar Mateo
Up until now, contexts had one (and only one) backing object that was
used by the hardware to save/restore render ring contexts (via the
MI_SET_CONTEXT command). Other rings did not have or need this, so
our i915_hw_context struct had a 1:1 relationship with a a real HW
context.
On Thu, May 22, 2014 at 03:03:56PM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 01:35:46PM +0300, ville.syrj...@linux.intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 96ae78d..d8b540b 100644
> > --- a/drivers/gpu/drm/i915/
"Volkin, Bradley D" writes:
> On Wed, May 21, 2014 at 07:02:56AM -0700, Mika Kuoppala wrote:
>> +if (ring->id == RCS && !to->is_initialized && from == NULL) {
>> +ret = i915_gem_render_state_init(ring);
>> +if (ret)
>> +DRM_ERROR("init render state:
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Imre Deak
> Sent: Thursday, May 22, 2014 1:08 AM
>
> On Wed, 2014-05-21 at 18:05 +0200, Daniel Vetter wrote:
> > On Wed, May 21, 2014 at 5:56 PM, Babu, Ramesh
> wrote:
> > >> On Tue, May
On Tue, May 20, 2014 at 11:46:45AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 19:23:27 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Apparently we need to disable VCP unit clock gating around media reset
> > on g4x.
> >
> > Signed-off-by: Ville Syrjälä
>
From: Sourab Gupta
This patch series replaces Blitter ring based flips with MMIO based flips.
This is useful for Media power well residency optimization. These may be
enabled on architectures where Render and Blitter engines reside in different
power wells.
The blitter ring is currently being use
From: Sourab Gupta
Using MMIO based flips on Gen5+. The MMIO flips are useful for the Media power
well residency optimization. These maybe enabled on architectures where
Render and Blitter engines reside in different power wells.
The blitter ring is currently being used just for command streamer
From: Sourab Gupta
This patch fixes the race condition between flip done interrupt
from set base and mmio based page flip.
This patch is dependent on
http://lists.freedesktop.org/archives/intel-gfx/2014-April/043761.html
Also, for the details of the race condition please refer to the mentioned
From: Sourab Gupta
This patch is for using mmio flips by default on VLV.
The module parameter controlling use of MMIO flips allows us to
control the default behaviour, which is set true for VLV and false
elsewhere.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
From: Ville Syrjälä
Here's a rebased and slightly polished version of the two part
watermark update series. Several patches already got merged, so
we're down to 16 now.
Also the drm vblank series got merged as did the atomic sprite series,
so there's nothing else blocking this stuff anymore.
Pr
From: Ville Syrjälä
The new watermaek update mechanism requires interrupts to work
correctly. Because of this we need interrupts while disabling crtcs
during suspend. So move the irq disable to happen a bit later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file
From: Ville Syrjälä
Make sure we programmed the watermarks correctly, by reading out the
hardware state again after programming and comparing it with the
state we supposedly programmed into hardware. Dump the watermark
registers after a mismatch, very much like we for the pipe config.
The only di
From: Ville Syrjälä
Pull the LP0 validate out from intel_compute_pipe_wm() into a separate
function. We will have further need for such a function to validate
both the final watermarks and the intermediate watermarks we will be
using while the plane(s) transition between different configurations.
From: Ville Syrjälä
Because of the upcoming vblank interrupt driven watermark update
mechanism we will have use for vblank interrupts during plane
enabling/disabling. So don't call drm_vblank_off() until planes
are off, and call drm_vblank_on() just before we start to enable
the planes.
v2: Pimp
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 38 ++
1 file ch
From: Ville Syrjälä
Add a mechanism by which you can queue up watermark update to happen
after the vblank counter has reached a certain value. The vblank
interrupt handler will schedule a work which will do the actual
watermark programming in process context.
v2: Rebase and s/intel_crtc/crtc/
S
From: Ville Syrjälä
We need to perform watermark programming before and after changing the
plane configuration. Add two new vfuncs to do that. The pre phase is
supposed to switch over to the intermediate watermarks which are
computed so that they can deal with both the old and new plane
configura
From: Ville Syrjälä
Add a mutex to protect most of the watermark state. Will be useful when
we start to update watermarks asynchronously from plane updates, or
when we get finer grained locking for planes.
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dr
From: Ville Syrjälä
Switch the code over to using the two phase watermark update. The steps
generally follow this pattern:
1. Calculate new plane parameters for changed planes
2. Calculate new target and intermediate watermarks
3. Check that both the target and intermediate watermarks are valid
From: Ville Syrjälä
After we've disabled the planes, it seems like a good idea wait for
the vblank driven watermark updates to finish before we turn off the
vblank interrupts and eventually the entire pipe.
v2: Rebase and s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i91
From: Ville Syrjälä
Pull the code to locate the other active crtc out from
haswell_mode_set_planes_workaround() into a separate function.
This will have another use later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 +
1 file chang
From: Ville Syrjälä
When we switch between one active pipe and multiple active pipes, the
display FIFO gets repartitioned. Disable the LP1+ waterwarks while that
is happening to make sure we don't get any glitches on other active
pipes while doing a modeset on another other pipe.
Signed-off-by:
From: Ville Syrjälä
Currently ilk_disable_lp_wm() just disabled LP1+ watermarks directly.
However there's nothing preventing someone else from re-enabling them
immediately. To make sure sure LP1+ watermarks stay disabled for the
intended period, keep track which pipes require the LP1+ watermarks
From: Ville Syrjälä
ILK and IVB don't like switching between sprite only and primary only
configurations when LP1+ watermarks have been enabled in the recent
past. Like WaCxSRDisabledForSpriteScaling we can avoid the flash
by disabling LP1+ watermarks for one frame before the critical plane
recon
From: Ville Syrjälä
If we mark the LP1+ watermarks as disabled every time sprite scaling
is enabled, we end doing pointless work applying watermarks even though
nothing has changed. This is an artifact of the way
dev_priv->wm.lp_disabled affects the operation of
ilk_setup_pending_watermarks(). If
From: Ville Syrjälä
When the primary plane is disabled, pick the 5/6 DDB split to give the
sprite as much FIFO space as possible.
The normal heuristic of just looking at the highest valid WM level won't
necessarily pick the optimal split since both splits might have the same
number of levels ena
> -Original Message-
> From: Vetter, Daniel
> Sent: Tuesday, May 20, 2014 11:08 PM
>
> On 20/05/2014 16:57, Thierry Reding wrote:
> > On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> >> >On Tue, May 20, 2014 at 4:29 PM, Imre Deak
> wrote:
> >>> > >On Tue, 2014-05-20 at 05:5
From: Ville Syrjälä
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 25 ++---
drivers/gpu/drm/i915/intel_display.c | 2
From: Ville Syrjälä
Add a small static inline helper to grab the vblank wait queue based on
the drm_crtc.
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
include/drm/drmP.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76cca
Currently pipe CRC support is broken after gpu hangs. This tests for
this bug.
Signed-off-by: Daniel Vetter
---
tests/kms_pipe_crc_basic.c | 60 --
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pi
Currently broken ...
Signed-off-by: Daniel Vetter
---
tests/kms_pipe_crc_basic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 282c7f68150a..eedb3f399e45 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_ba
On Thu, 22 May 2014 09:51:22 +0300
Imre Deak wrote:
> On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote:
> > On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote:
> > > And to answer more specifically...
> > >
> > > On Wed, 21 May 2014 20:54:03 +0300
> > > Ville Syrjälä wrote:
> >
On Thu, 22 May 2014 09:44:40 +0100
Chris Wilson wrote:
> Daniel keeps on ramping up the warning level of the DRM and our display
> core to make it complain whenever the locking rules are not followed.
> This caught
>
> commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
> Author: Jesse Barnes
> Dat
From: Ville Syrjälä
If the object is already UC leave it as UC instead of automagically
promoting it to WT in i915_gem_object_pin_to_display_plane() when
the hardware is WT capable.
Supposedly the user wanted UC for a reason, so let's respect that.
Signed-off-by: Ville Syrjälä
---
Just somethi
On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Share the waitqueue that drm_irq uses when performing the vblank evade
> trick for atomic pipe updates.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/d
On platforms with shared interrupt enable bits (which are shared even
with the pipe CRC logic) there's some tricky corner cases. Add
information to make debugging those easier.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 insertions(+)
diff --
So apparently this is tricky.
We need to consider:
- We start out with all the hw enabling bits disabled, both the
individual fifo underrun interrupts and the shared display error
interrupts masked. Otherwise if the bios config is broken we'll blow
up with a NULL deref in our interrupt handl
Ville figured out that it needs a full display reset since apparently
a lot more goes down than just the GT. Until that's address it's
better to just diable gpu reset.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driv
Currently we do a full re-init of all interrupts after a gpu hang.
Which is pretty bad since we don't restore the interrupts we've
enabled at runtime correctly. Even with that addressed it's rather
horribly race.
But on g4x and later we only reset the gt and not the entire gpu.
Which means we only
No point in having this indirection.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4d44f09eb833..3cd659b47dd2 100644
---
From: Ville Syrjälä
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
v2: Keep intel_pipe_handle_vblank() (Chris)
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
drivers/gpu/drm/i
On 20 May 2014 12:25, Stephen Rothwell wrote:
> Hi Sumit,
>
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
> ("drm/i915: Introduce mapping of user pages into video memory (userptr)
> ioctl") from the drm-intel t
On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Share the waitqueue that drm_irq uses when performing the vblank evade
> > trick for atomic pipe updates.
> >
> > Suggest
On Thu, May 22, 2014 at 06:39:32PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a small static inline helper to grab the vblank wait queue based on
> the drm_crtc.
Maybe add that this is useful for drivers to do internal vblank waits
using wait event.
> Suggested-by
From: Ville Syrjälä
Add a small static inline helper to grab the vblank wait queue based on
the drm_crtc.
This is useful for drivers to do internal vblank waits using
wait_event() & co.
v2: Pimp commit message (Daniel)
Add kernel doc (Daniel)
Suggested-by: Daniel Vetter
Signed-off-by: Vil
If a subtest fails, cleanup_crtc() never gets called. Currently that
also causes igt_pipe_crc_free() to never be called, leading all
subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
Move the calls to igt_pipe_crc_{new,free} into igt_main so that
we don't need to worry about clos
On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote:
> Currently we do a full re-init of all interrupts after a gpu hang.
> Which is pretty bad since we don't restore the interrupts we've
> enabled at runtime correctly. Even with that addressed it's rather
> horribly race.
>
> But on g4x
On Thu, May 22, 2014 at 05:56:32PM +0200, Daniel Vetter wrote:
> So apparently this is tricky.
>
> We need to consider:
> - We start out with all the hw enabling bits disabled, both the
> individual fifo underrun interrupts and the shared display error
> interrupts masked. Otherwise if the bio
On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> If a subtest fails, cleanup_crtc() never gets called. Currently that
> also causes igt_pipe_crc_free() to never be called, leading all
> subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
> Move the calls to igt_pipe_cr
On Thu, May 22, 2014 at 05:56:31PM +0200, Daniel Vetter wrote:
> On platforms with shared interrupt enable bits (which are shared even
> with the pipe CRC logic) there's some tricky corner cases. Add
> information to make debugging those easier.
>
> Signed-off-by: Daniel Vetter
For patches 1,3,4
On Thu, May 22, 2014 at 08:01:09PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> > If a subtest fails, cleanup_crtc() never gets called. Currently that
> > also causes igt_pipe_crc_free() to never be called, leading all
> > subsequent subtests to also
On Thu, May 22, 2014 at 07:51:45PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote:
> > Currently we do a full re-init of all interrupts after a gpu hang.
> > Which is pretty bad since we don't restore the interrupts we've
> > enabled at runtime correctly
On Thu, May 22, 2014 at 10:06:37AM -0700, Matt Roper wrote:
> On Thu, May 22, 2014 at 08:01:09PM +0300, Ville Syrjälä wrote:
> > On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> > > If a subtest fails, cleanup_crtc() never gets called. Currently that
> > > also causes igt_pipe_crc_fre
If a subtest fails, cleanup_crtc() never gets called and then the
test_data_t structure for the test is lost, including the CRC file
descriptor that we never got a chance to release; this causes all
subsequent tests to fail with -EBUSY at igt_pipe_crc_new().
The split between permanent data_t and
2014-05-15 21:13 GMT-03:00 Rodrigo Vivi :
> v2: Avoid more than one setup. Removing initialization
> and trusting allocation. (By Paulo Zanoni).
> v3: rebase.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
I guess the commit message needs a little explanation, such as:
"Because our driv
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> All the other checks also check hw state, so checking our software
> refcounts for the plls looks a bit odd.
As I mentioned before, this contradicts your own previous review of
the patch that added this code. In addition, you said many times that
we sho
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Luckily the bit definitions match, but it's still confusing
> to use one when handling the other. So sprinkle some OCD over
> the #defines to make them match and use the right version in
> each place.
>
> Maybe we should unify these definitions completel
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Noticed while reading around.
That's because you killed the intel_tv.c caller in patch 06/66.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> SPLL would be a reference clock we could potentially share,
> especially if we want to use the SSC mode. But currently we
> don't, so let's rip out this complexity for a simpler conversion
> to the new display pll framework.
I'm really not a fan of this
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> The modeset sequence docs are very clear that we should disable the
> pipe before we switch off any ports, for both pch ports and the cpu
> edp port.
>
> In practice it doesn't seem to matter too much since for non-DP pch
> ports it only matters that the
On Thu, May 22, 2014 at 03:10:37PM -0300, Paulo Zanoni wrote:
> 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> > All the other checks also check hw state, so checking our software
> > refcounts for the plls looks a bit odd.
>
> As I mentioned before, this contradicts your own previous review of
> th
On Thu, May 22, 2014 at 06:05:34PM +0200, Daniel Vetter wrote:
> On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> > On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Share the waitqueue that drm_irq uses when p
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Well, the newly created intel_ddi_get_port_state.
>
> In general intel_ddi.c has way too intimate knowledge with everyone
> else as exemplified with all the encoder/connector noodling and the
> massive exported function list.
>
> As a first step explictl
On Thu, May 22, 2014 at 03:41:25PM -0300, Paulo Zanoni wrote:
> 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> > SPLL would be a reference clock we could potentially share,
> > especially if we want to use the SSC mode. But currently we
> > don't, so let's rip out this complexity for a simpler conver
On Thu, May 22, 2014 at 01:56:17PM +0100, Robert Beckett wrote:
> On 13/05/2014 14:54, Daniel Vetter wrote:
> >On Tue, May 13, 2014 at 04:46:10PM +0300, Imre Deak wrote:
> >>On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote:
> >>>On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote:
> >>>
On Thu, May 22, 2014 at 02:59:56PM +, Lin, Mengdong wrote:
> > -Original Message-
> > From: Vetter, Daniel
> > Sent: Tuesday, May 20, 2014 11:08 PM
> >
> > On 20/05/2014 16:57, Thierry Reding wrote:
> > > On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> > >> >On Tue, Ma
On Thu, May 22, 2014 at 9:26 PM, Daniel Vetter wrote:
> On Thu, May 22, 2014 at 03:10:37PM -0300, Paulo Zanoni wrote:
>> 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
>> > All the other checks also check hw state, so checking our software
>> > refcounts for the plls looks a bit odd.
>>
>> As I mentio
On Thu, May 22, 2014 at 07:55:52PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 05:56:32PM +0200, Daniel Vetter wrote:
> > So apparently this is tricky.
> >
> > We need to consider:
> > - We start out with all the hw enabling bits disabled, both the
> > individual fifo underrun interrup
On Thu, May 22, 2014 at 07:51:45PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote:
> > Currently we do a full re-init of all interrupts after a gpu hang.
> > Which is pretty bad since we don't restore the interrupts we've
> > enabled at runtime correctly
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> The connector->get_hw_state function is actually platform dependent.
> So move it out of the shared connector init functions. This allows us
> to drop another intel_ddi.c export.
>
> Signed-off-by: Daniel Vetter
The nice thing about the current code is
After upgrading to linux Kernel-3.14, the screen on my Dell Latitude
D630 was nearly unreadably dim. When I Boot the 3.13 kernel, my screen
is bright.
I opened a Bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1094066
and others have chimed in that they have the same problem.
I bisect
Currently we do a full re-init of all interrupts after a gpu hang.
Which is pretty bad since we don't restore the interrupts we've
enabled at runtime correctly. Even with that addressed it's rather
horribly race.
But on g4x and later we only reset the gt and not the entire gpu.
Which means we only
Fallout from an intermediate patch revision that I deemed worth saving.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i9
On Thu, May 22, 2014 at 08:30:23PM +0100, Chris Wilson wrote:
> On Thu, May 22, 2014 at 06:05:34PM +0200, Daniel Vetter wrote:
> > On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> > > On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
1 - 100 of 122 matches
Mail list logo
