date:20160721

https://bugs.freedesktop.org/show_bug.cgi?id=97029

Bug ID: 97029
   Summary: cik_sdma_copy_texture broken on Carrizo (mesa 12)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: darktjm at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 125240
  --> https://bugs.freedesktop.org/attachment.cgi?id=125240=edit
xwd output with bug

Mesa 12 corrupts large image displays in X on my hardware, using
xf86-video-amdgpu 1.1.0 (glamor).  To reproduce, xwd | xwud.  The xwd capture
is garbled (see attached), and xwud sprays the garbled mess in disconnected
chunks to its right.  I noticed this in pre-12 git as well, but didn't report
because I have limited net access and limited machine availability and hoped
someone better equipped would discover and deal with it.  The commit which
caused this is 70934de00eb42ba6fc43d104875962dfb260a1b3.  Removing the call to
cik_sdma_copy_texture "fixes" it.  This was observed on two different machines,
but similar hardware (A10 Carrizo).  Verfied still broken as of
4f89cf4941db0a5cd8a85b94312184cf8e4f.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/8f2b771c/attachment.html>

[PATCH/V2] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

2016-07-21 Thread Dave Airlie

On 21 July 2016 at 15:22, Masanari Iida  wrote:
> Boot the system without this entry generates following warning.
> fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
>
> After apply this patch, no more conflict message.
> fb: switching to mgag200drmfb from EFI VGA
>
> Compile and tested on DL360 Gen9 and it works both console and X.


NAK, that's totally wrong, that mga driver isn't for g200 server chips.

The conflicting fb hw message is harmless.

Dave.

Misc libdrm fixes

On 21 July 2016 at 14:12, Andreas Boll  wrote:
> While packaging the latest libdrm release I've fixed some issues noticed by
> Debian's Lintian.
>
> Please review.
>
I'm a huge fan of patches 1 and 4 :-)

There's a couple of minor suggestions and with those the series is
Reviewed-by: Emil Velikov 

Thanks !
Emil

[PATCH libdrm 2/6] automake: Pick up all Android files for distribution

On 21 July 2016 at 14:12, Andreas Boll  wrote:
> Currently only some Android Makefiles are included in the release tarball.
> Add all remaining files to be more consistent.
>
Since Android folk never fully bought the idea of using actual
releases/release tarballs, one could just drop all the existing
Android.mk instances from the Makefiles.

If the Debian build system warnings about files not included in the
tarball go ahead with this patch.

Thanks
Emil

[PATCH libdrm 3/6] libdrm: Fix drm.h include path in virtgpu drm header file

On 21 July 2016 at 14:12, Andreas Boll  wrote:
> A similar change was made to mesa's copy of virtgpu_drm.h by the
> following commit:
>
Please sync this using the approach shown in commit
c745e541a9d8dfd3fb5e1ac57297e58d34d9328f.

Namely:
 - Use make header_install and copy the resulting file over.
 - Mention the tree/branch and sha where it is based on.

Adding details about the kernel changes are a bonus, but not necessary
unless they remove/change existing code.

Thanks
Emil

[Bug 96398] [radeonsi tessellation] Single-pixel rasterization issue (Shadow of Mordor)

https://bugs.freedesktop.org/show_bug.cgi?id=96398

--- Comment #7 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Nicolai HÃ¤hnle from comment #5)
> Can you produce an apitrace?

http://atom-symbol.net/f/2016-07-21/ShadowOfMordor.trace.xz

The issue should manifest itself in some frames at the end of the trace.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/02352d16/attachment-0001.html>

[PATCH] drm/imx: imx-ldb: store LVDS bus configuration in ldb channel

2016-07-21 Thread Philipp Zabel

The code in imx_ldb_encoder_mode_set crashes trying to access the
crtc->state->state drm_atomic_state pointer if that was previously
cleared by drm_atomic_helper_swap_state.
Instead of trying to walk all connectors during encoder mode_set to
determine the LVDS bus format from panel or external bridge connector
display info, store it in imx_crtc_state during encoder atomic_check,
where it is already known, and just retrieve it from imx_crtc_state
during encoder mode_set.

Fixes: 49f98bc4d44a4 ("drm/imx: store internal bus configuration in crtc state")
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm.h |  1 +
 drivers/gpu/drm/imx/imx-ldb.c | 22 +-
 2 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index bdaa381..5e2f68a 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -19,6 +19,7 @@ struct imx_crtc_state {
u32 bus_flags;
int di_hsync_pin;
int di_vsync_pin;
+   u32 ldb_bus_format;
 };

 static inline struct imx_crtc_state *to_imx_crtc_state(struct drm_crtc_state 
*s)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index dc2b420..871dff9 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -262,7 +262,10 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder 
*encoder,
unsigned long serial_clk;
unsigned long di_clk = mode->clock * 1000;
int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
-   u32 bus_format = imx_ldb_ch->bus_format;
+   struct drm_crtc_state *crtc_state = encoder->crtc->state;
+   struct imx_crtc_state *imx_crtc_state = to_imx_crtc_state(crtc_state);
+   u32 bus_format = imx_ldb_ch->bus_format ?:
+imx_crtc_state->ldb_bus_format;

if (mode->clock > 17) {
dev_warn(ldb->dev,
@@ -297,22 +300,6 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder 
*encoder,
ldb->ldb_ctrl &= ~LDB_DI1_VS_POL_ACT_LOW;
}

-   if (!bus_format) {
-   struct drm_connector_state *conn_state;
-   struct drm_connector *connector;
-   int i;
-
-   for_each_connector_in_state(encoder->crtc->state->state,
-   connector, conn_state, i) {
-   struct drm_display_info *di = >display_info;
-
-   if (conn_state->crtc == encoder->crtc &&
-   di->num_bus_formats) {
-   bus_format = di->bus_formats[0];
-   break;
-   }
-   }
-   }
imx_ldb_ch_set_bus_format(imx_ldb_ch, bus_format);
 }

@@ -404,6 +391,7 @@ static int imx_ldb_encoder_atomic_check(struct drm_encoder 
*encoder,

imx_crtc_state->di_hsync_pin = 2;
imx_crtc_state->di_vsync_pin = 3;
+   imx_crtc_state->ldb_bus_format = bus_format;

return 0;
 }
-- 
2.8.1

[PATCH v2 4/4] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.

Changes since original patch series:
 - Remove mutex_lock/mutex_unlock since they don't do anything and we're
   not touching global state
 - Move skl_write_cursor_wm/skl_write_plane_wm functions into
   intel_pm.c, make externally visible
 - Add skl_write_plane_wm calls to skl_update_plane
 - Fix conditional for for loop in skl_write_plane_wm (level < max_level
   should be level <= max_level)
 - Make diagram in commit more accurate to what's actually happening
 - Add Fixes:

Changes since v1:
 - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
   then just Skylake
 - Update description to make it clear this patch doesn't fix everything
 - Check if pipes were actually changed before writing watermarks

Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude 
Cc: stable at vger.kernel.org
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c |  5 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 54 ++--
 drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
 4 files changed, 49 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 78beb7e..d93d014 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = x_offset;
intel_crtc->adjusted_y = y_offset;

+   skl_write_plane_wm(intel_crtc, 0);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
@@ -10242,6 +10244,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;

+   if (IS_GEN9(dev_priv))
+   skl_write_cursor_wm(intel_crtc);
+
if (plane_state && plane_state->visible) {
cntl = MCURSOR_GAMMA_ENABLE;
switch (plane_state->base.crtc_w) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851..f1f54d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1709,6 +1709,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void skl_write_cursor_wm(struct intel_crtc *intel_crtc);

[PATCH v2 3/4] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55237ea..9421d92 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3817,7 +3817,6 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
reallocated[pipe] = true;
}

-
/*
 * Second pass: flush the pipes that are having their allocation
 * reduced, but overlapping with a previous allocation.
-- 
2.7.4

[PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
moving between screens will introduce a rather noticable lag for users.

Signed-off-by: Lyude 
Cc: stable at vger.kernel.org
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 31 +--
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c97724d..9e1e045 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1597,6 +1597,7 @@ struct skl_ddb_allocation {

 struct skl_wm_values {
unsigned dirty_pipes;
+   bool ddb_changed;
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 56ddd71..55237ea 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3789,6 +3789,12 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
new_ddb = _values->ddb;
cur_ddb = _priv->wm.skl_hw.ddb;

+   /* We only ever need to flush when the ddb allocations change */
+   if (!new_values->ddb_changed)
+   return;
+
+   new_values->ddb_changed = false;
+
/*
 * First pass: flush the pipes with the new allocation contained into
 * the old space.
@@ -3893,6 +3899,22 @@ pipes_modified(struct drm_atomic_state *state)
return ret;
 }

+static bool
+skl_pipe_ddb_changed(struct skl_ddb_allocation *old,
+struct skl_ddb_allocation *new,
+enum pipe pipe)
+{
+   if (memcmp(>pipe[pipe], >pipe[pipe],
+  sizeof(old->pipe[pipe])) != 0 ||
+   memcmp(>plane[pipe], >plane[pipe],
+  sizeof(old->plane[pipe])) != 0 ||
+   memcmp(>y_plane[pipe], >y_plane[pipe],
+  sizeof(old->y_plane[pipe])) != 0)
+   return true;
+
+   return false;
+}
+
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
@@ -3900,7 +3922,8 @@ skl_compute_ddb(struct drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct intel_crtc *intel_crtc;
-   struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
+   struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
+   struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
uint32_t realloc_pipes = pipes_modified(state);
int ret;

@@ -3938,9 +3961,13 @@ skl_compute_ddb(struct drm_atomic_state *state)
if (IS_ERR(cstate))
return PTR_ERR(cstate);

-   ret = skl_allocate_pipe_ddb(cstate, ddb);
+   ret = skl_allocate_pipe_ddb(cstate, new_ddb);
if (ret)
return ret;
+
+   if (!intel_state->wm_results.ddb_changed &&
+   skl_pipe_ddb_changed(old_ddb, new_ddb, intel_crtc->pipe))
+   intel_state->wm_results.ddb_changed = true;
}

return 0;
-- 
2.7.4

[PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper 

When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' 
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper 
Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: stable at vger.kernel.org
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_pm.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 64d628c..56ddd71 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3946,6 +3946,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
 }

+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+   memcpy(dst->plane[pipe], src->plane[pipe],
+  sizeof(dst->plane[pipe]));
+   memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+  sizeof(dst->plane_trans[pipe]));
+
+   dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+   memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+  sizeof(dst->ddb.y_plane[pipe]));
+   memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+  sizeof(dst->ddb.plane[pipe]));
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4018,8 +4036,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = _priv->wm.skl_results;
+   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = >wm.skl.optimal;
+   int pipe;

if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4031,8 +4051,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);

-   /* store the new configuration */
-   dev_priv->wm.skl_hw = *results;
+   /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+   for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+   skl_copy_wm_for_pipe(hw_vals, results, pipe);

mutex_unlock(_priv->wm.wm_mutex);
 }
-- 
2.7.4

[PATCH v2 0/4] drm/i915/skl: Finally fix watermarks

To Sebastian Reichel:
I *think* I may have found the problem. Looked at
./scripts/get_maintainer.pl and apparently it's defaults aren't
actually expected to work well with `git send-email`. I've added
--norolestats and hopefully that should fix the issue. If the email
format issue still seems to be coming up let me know.

New version of the original patchset from

https://patchwork.freedesktop.org/series/10108/

Notable changes across the patchset (per-patch descriptions noted in each
patch's description):
 - Dropped "drm/i915/skl: Always wait for pipes to update after a flush" -
   turns out it wasn't actually fixing anything (on drm-intel/drm-intel-nightly
   anyway)
 - Dropped "drm/i915/skl: Actually reuse wm values when pipes don't change" -
   this was a silly mistake

Lyude (3):
  drm/i915/skl: Only flush pipes when we change the ddb allocation
  drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()
  drm/i915/skl: Update plane watermarks atomically during plane updates

Matt Roper (1):
  drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |   5 ++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 114 +--
 drivers/gpu/drm/i915/intel_sprite.c  |   2 +
 5 files changed, 105 insertions(+), 19 deletions(-)

-- 
2.7.4

[PATCH v2 4/7] drm/bridge: Add RGB to VGA bridge support

2016-07-21 Thread Archit Taneja

Hi,

On 07/20/2016 03:28 PM, Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn't do anything but expose the modes available on the
> screen, either based on the EDIDs if available, or based on the XGA
> standards.

Our eventual aim is to separate out the connectors from the bridge
drivers wherever possible. In the future, a KMS driver using the
bridge would be responsible for establishing the links between
the bridge and encoder, and the encoder and connector.

If in the future we remove the connector pieces from this driver
to create a separate generic VGA connector driver, we'll end up
with a bridge driver whose main functionality is to convert RGB
signals to VGA. The EDID parts would move to the VGA connector
driver. In your platform's case, there is no software needed
to translate RGB to VGA, but maybe in the future, we might need
to add an optional regulator in the driver to support another
platform. Therefore, the bridge driver would still be handy to
have.

Keeping this in consideration, I think this driver (and the DT
binding) should be called "dumb-rgb-to-vga-bridge", or
"rgb-to-vga-bridge" since that's what the bridge HW primarily
does.

Thanks,
Archit

>
> Signed-off-by: Maxime Ripard 
> ---
>   .../bindings/display/bridge/dumb-vga.txt   |  54 +
>   drivers/gpu/drm/bridge/Kconfig |   6 +
>   drivers/gpu/drm/bridge/Makefile|   1 +
>   drivers/gpu/drm/bridge/dumb-vga.c  | 232 
> +
>   4 files changed, 293 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/bridge/dumb-vga.txt
>   create mode 100644 drivers/gpu/drm/bridge/dumb-vga.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt 
> b/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt
> new file mode 100644
> index ..0056ffa2b31d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt
> @@ -0,0 +1,54 @@
> +Passive RGB to VGA bridge
> +-
> +
> +This binding is aimed for entirely passive RGB to VGA bridges that do not
> +require any configuration.
> +
> +Required properties:
> +
> +- compatible: Must be "dumb-vga-bridge"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modeled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +
> +Example
> +---
> +
> +bridge {
> + compatible = "dumb-vga-bridge";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_con_in>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a141921445f4..4a6560714397 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -17,6 +17,12 @@ config DRM_ANALOGIX_ANX78XX
> the HDMI output of an application processor to MyDP
> or DisplayPort.
>
> +config DRM_DUMB_VGA
> + tristate "Dumb RGB to VGA Bridge support"
> + select DRM_KMS_HELPER
> + help
> +   Support for passive RGB to VGA bridges
> +
>   config DRM_DW_HDMI
>   tristate
>   select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index bfec9f8cb9d2..413d783828bb 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
>   ccflags-y := -Iinclude/drm
>
>   obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +obj-$(CONFIG_DRM_DUMB_VGA) += dumb-vga.o
>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/dumb-vga.c 
> b/drivers/gpu/drm/bridge/dumb-vga.c
> new file mode 100644
> index ..c197be591fb6
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dumb-vga.c
> @@ -0,0

[Bug 97025] flip queue failed: Device or resource busy

https://bugs.freedesktop.org/show_bug.cgi?id=97025

Bug ID: 97025
   Summary: flip queue failed: Device or resource busy
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: linux at bernd-steinhauser.de

Since last week I have random freezes with the amdgpu driver (running on
Kaveri).

Once the issue occurs the display freezes. It's not fixable by switch to VT2
and back.

In Xorg.0.log I can find multiple times:
[ 92357.021] (WW) AMDGPU(0): flip queue failed: Device or resource busy
[ 92357.021] (WW) AMDGPU(0): Page flip failed: Device or resource busy
[ 92357.021] (EE) AMDGPU(0): present flip failed

No related messages in the journal or dmesg afaics.

It does not seem to be related to a specific event (like a video playing), but
just happens out of nowhere.
I didn't find a way to reproduce it specifically.

Possibly related packages that I built in that time:
* dev-lang/llvm-scm::arbor 2016-06-11 07:42:19 UTC
* dev-lang/llvm-scm::arbor 2016-06-19 07:29:42 UTC
* x11-dri/mesa-12.0.0-rc4::x11 2016-06-21 21:40:48 UTC
* dev-lang/llvm-scm::arbor 2016-07-02 11:57:34 UTC
* dev-lang/clang-scm::arbor 2016-07-02 12:43:00 UTC
* dev-lang/llvm-3.8.0-r1::arbor 2016-07-12 20:04:14 UTC
* dev-lang/clang-3.8.0::arbor 2016-07-12 20:48:27 UTC
* x11-dri/mesa-12.0.0::x11 2016-07-13 04:42:47 UTC
* x11-dri/mesa-12.0.1::x11 2016-07-17 14:25:44 UTC
* x11-server/xorg-server-1.18.4::x11 2016-07-20 16:06:18 UTC

I couldn't get mesa 12 to built with llvm-scm anymore, so I downgraded.
Still, I doubt it's related.

It's hard to be certain about this, but it could have been a regressing coming
with mesa 12 and possibly mesa-12.0.0.
I'm pretty sure I haven't seen the freeze before 12.0.0 final, but it's hard to
be certain about this with an issue so random.

In case it matters, my xorg settings are: 
Section "Device"
Identifier  "AMDGPU"
Driver  "amdgpu"
Option  "TearFree" "Off"
Option  "EnablePageFlip" "On"
Option  "DRI" "3"
EndSection

IIRC, this is now standard, so nothing special here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/b5ed0b1b/attachment.html>

[PATCH libdrm 6/6] radeon: Fix typo in stderr message

Signed-off-by: Andreas Boll 
---
 radeon/radeon_cs_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index cdec64e..23f33af 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -323,7 +323,7 @@ static int cs_gem_end(struct radeon_cs_int *cs,
 return -EPIPE;
 }
 if (cs->section_ndw != cs->section_cdw) {
-fprintf(stderr, "CS section size missmatch start at (%s,%s,%d) %d vs 
%d\n",
+fprintf(stderr, "CS section size mismatch start at (%s,%s,%d) %d vs 
%d\n",
 cs->section_file, cs->section_func, cs->section_line, 
cs->section_ndw, cs->section_cdw);
 fprintf(stderr, "CS section end at (%s,%s,%d)\n",
 file, func, line);
-- 
2.8.1

[PATCH libdrm 5/6] man: Fix typo

Signed-off-by: Andreas Boll 
---
 man/drm-kms.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/drm-kms.xml b/man/drm-kms.xml
index 5f04157..ae38dc8 100644
--- a/man/drm-kms.xml
+++ b/man/drm-kms.xml
@@ -126,7 +126,7 @@
   
 Framebuffers are abstract memory objects
   that provide a source of pixel data to scanout to a CRTC.
-  Applications explicitely request the creation of framebuffers
+  Applications explicitly request the creation of framebuffers
   and can control their behavior. Framebuffers rely on the
   underneath memory manager for low-level memory operations.
   When creating a framebuffer, applications pass a memory 
handle
-- 
2.8.1

[PATCH libdrm 4/6] automake: Include virtgpu_drm.h in the release tarball.

The plan is to use this version of virtgpu_drm.h in mesa and drop mesa's
local copy.
To actually use this header it needs to be shipped in the tarball.

This was missed in c745e541a9d8dfd3fb5e1ac57297e58d34d9328f

Signed-off-by: Andreas Boll 
---
 Makefile.sources | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.sources b/Makefile.sources
index 1a1f0fe..a57036a 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -33,7 +33,8 @@ LIBDRM_INCLUDE_H_FILES := \
include/drm/sis_drm.h \
include/drm/tegra_drm.h \
include/drm/vc4_drm.h \
-   include/drm/via_drm.h
+   include/drm/via_drm.h \
+   include/drm/virtgpu_drm.h

 LIBDRM_INCLUDE_VMWGFX_H_FILES := \
include/drm/vmwgfx_drm.h
-- 
2.8.1

[PATCH libdrm 3/6] libdrm: Fix drm.h include path in virtgpu drm header file

A similar change was made to mesa's copy of virtgpu_drm.h by the
following commit:

commit c1bf71f77c9d4bc83fa7dc987b56f98350430d7c
Author: Emil Velikov 
Date:   Wed Oct 28 11:47:18 2015 +

virgl: fix drm.h include path

The drm/ prefix is required, if using the kernel provided headers. As
most distros don't ship them it and we already depend on libdrm (which
adds the relevant -I flag) just drop the drm/ from the include.

Once a libdrm release with the virtgpu_drm.h header is released, we can
drop our local copy of the file.

Signed-off-by: Emil Velikov 
Reviewed-by: Dave Airlie 

This matches the include path used by all other drm header files.

Signed-off-by: Andreas Boll 
---
 include/drm/virtgpu_drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/virtgpu_drm.h b/include/drm/virtgpu_drm.h
index abf11c5..6a43f8d 100644
--- a/include/drm/virtgpu_drm.h
+++ b/include/drm/virtgpu_drm.h
@@ -25,7 +25,7 @@
 #define VIRTGPU_DRM_H

 #include 
-#include "drm/drm.h"
+#include "drm.h"

 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
-- 
2.8.1

[PATCH libdrm 2/6] automake: Pick up all Android files for distribution

Currently only some Android Makefiles are included in the release tarball.
Add all remaining files to be more consistent.

Signed-off-by: Andreas Boll 
---
 Makefile.am| 2 +-
 amdgpu/Makefile.am | 2 +-
 tests/Makefile.am  | 2 ++
 tests/proptest/Makefile.am | 2 ++
 tests/util/Makefile.am | 2 ++
 5 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index feecba7..dce2cf6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -120,7 +120,7 @@ libdrm_la_SOURCES = $(LIBDRM_FILES)
 libdrmincludedir = ${includedir}
 libdrminclude_HEADERS = $(LIBDRM_H_FILES)

-EXTRA_DIST = Android.mk
+EXTRA_DIST = CleanSpec.mk Android.mk

 klibdrmincludedir = ${includedir}/libdrm
 klibdrminclude_HEADERS = $(LIBDRM_INCLUDE_H_FILES)
diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index cf7bc1b..169788f 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -44,4 +44,4 @@ pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm_amdgpu.pc

 TESTS = amdgpu-symbol-check
-EXTRA_DIST = $(TESTS)
+EXTRA_DIST = Android.mk $(TESTS)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 58feb12..33a1d42 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -73,3 +73,5 @@ TESTS +=  \
 endif

 check_PROGRAMS += $(TESTS)
+
+EXTRA_DIST = Android.mk
diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
index 3fde46b..6b7ae7c 100644
--- a/tests/proptest/Makefile.am
+++ b/tests/proptest/Makefile.am
@@ -19,3 +19,5 @@ proptest_SOURCES = $(PROPTEST_FILES)
 proptest_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/tests/util/libutil.la
+
+EXTRA_DIST = Android.mk
diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am
index f8e0b17..92acfb3 100644
--- a/tests/util/Makefile.am
+++ b/tests/util/Makefile.am
@@ -11,3 +11,5 @@ libutil_la_CFLAGS = \
$(CAIRO_CFLAGS)

 libutil_la_SOURCES = $(UTIL_FILES)
+
+EXTRA_DIST = Android.mk
-- 
2.8.1

[PATCH libdrm 1/6] radeon: Wire up radeon-symbol-check to make check

This was missed in 552de225bf2740ba0cb52312c21353d71d934b8c

Signed-off-by: Andreas Boll 
---
 radeon/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/radeon/Makefile.am b/radeon/Makefile.am
index 25c03d3..31f19e5 100644
--- a/radeon/Makefile.am
+++ b/radeon/Makefile.am
@@ -43,4 +43,5 @@ libdrm_radeoninclude_HEADERS = $(LIBDRM_RADEON_H_FILES)
 pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm_radeon.pc

+TESTS = radeon-symbol-check
 EXTRA_DIST = Android.mk $(LIBDRM_RADEON_BOF_FILES) $(TESTS)
-- 
2.8.1

Misc libdrm fixes

While packaging the latest libdrm release I've fixed some issues noticed by
Debian's Lintian.

Please review.

Thanks,
Andreas

[PATCH/V2] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

2016-07-21 Thread Masanari Iida

Boot the system without this entry generates following warning.
fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver

After apply this patch, no more conflict message.
fb: switching to mgag200drmfb from EFI VGA

Compile and tested on DL360 Gen9 and it works both console and X.

Signed-off-by: Masanari Iida 
Suggested-by: Shane Seymour 
---
 include/drm/drm_pciids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 8bc073d297db..3e16dfc2e08d 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -743,6 +743,7 @@
 #define mga_PCI_IDS \
{0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
+   {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
{0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
{0, 0, 0}
-- 
2.9.2.368.g08bb350

[PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

2016-07-21 Thread Masanari Iida

I made mistake to type shane's e-mail address, so I will send version
2.  Sorry for the noise.
Masanari

On Thu, Jul 21, 2016 at 2:12 PM, Masanari Iida  wrote:
> Boot the system without this entry generates following warning.
> fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
>
> After apply this patch, no more conflict message.
> fb: switching to mgag200drmfb from EFI VGA
>
> Compile and tested on DL360 Gen9 and it works both console and X.
>
> Signed-off-by: Masanari Iida 
> Suggested-by: Shane Seymour 
> ---
>  include/drm/drm_pciids.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
> index 8bc073d297db..3e16dfc2e08d 100644
> --- a/include/drm/drm_pciids.h
> +++ b/include/drm/drm_pciids.h
> @@ -743,6 +743,7 @@
>  #define mga_PCI_IDS \
> {0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> {0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> +   {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> {0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
> {0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
> {0, 0, 0}
> --
> 2.9.2.368.g08bb350
>

[PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

2016-07-21 Thread Masanari Iida

Boot the system without this entry generates following warning.
fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver

After apply this patch, no more conflict message.
fb: switching to mgag200drmfb from EFI VGA

Compile and tested on DL360 Gen9 and it works both console and X.

Signed-off-by: Masanari Iida 
Suggested-by: Shane Seymour 
---
 include/drm/drm_pciids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 8bc073d297db..3e16dfc2e08d 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -743,6 +743,7 @@
 #define mga_PCI_IDS \
{0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
+   {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
{0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
{0, 0, 0}
-- 
2.9.2.368.g08bb350

[PATCH] GPU-DRM-Exynos: Delete an unnecessary check before the function call "vunmap"

2016-07-21 Thread Sean Paul

On Thu, Jul 21, 2016 at 1:42 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Thu, 21 Jul 2016 19:23:25 +0200
>
> The vunmap() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

Applied to drm-misc

> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index dd09117..4cfb39d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -269,8 +269,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device 
> *dev,
> struct exynos_drm_gem *exynos_gem = exynos_fbd->exynos_gem;
> struct drm_framebuffer *fb;
>
> -   if (exynos_gem->kvaddr)
> -   vunmap(exynos_gem->kvaddr);
> +   vunmap(exynos_gem->kvaddr);
>
> /* release drm framebuffer and real buffer */
> if (fb_helper->fb && fb_helper->fb->funcs) {
> --
> 2.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

2016-07-21 Thread Ville Syrjälä

On Thu, Jul 21, 2016 at 01:32:48PM +0300, Joonas Lahtinen wrote:
> Was not this implemented once and then dropped for some reason?

Dunno.

> 
> On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville SyrjÃ¤lÃ¤ 
> > 
> > Add "bad-rotation" subtest to make sure the kernel rejects some
> > invalid rotation values (0 and specifying multiple angles at one).
> > 
> > Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> > ---
> > Â tests/kms_rotation_crc.c | 33 +
> > Â 1 file changed, 33 insertions(+)
> > 
> > diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> > index 6cc15337fff9..e10a0a770437 100644
> > --- a/tests/kms_rotation_crc.c
> > +++ b/tests/kms_rotation_crc.c
> > @@ -237,6 +237,31 @@ static void wait_for_pageflip(int fd)
> > Â   igt_assert(drmHandleEvent(fd, ) == 0);
> > Â }
> > Â 
> > +static void test_bad_prop_value(data_t *data)
> > +{
> > +   igt_display_t *display = >display;
> > +   int valid_tests = 0;
> > +   enum pipe pipe;
> > +   igt_plane_t *plane;
> > +   int ret;
> > +
> > +   for_each_pipe(display, pipe)Â Â {
> > +   for_each_plane_on_pipe(display, pipe, plane) {
> > +   igt_require(igt_plane_supports_rotation(plane));
> > +
> > +   ret = drmModeObjectSetProperty(display->drm_fd,
> > +   Â Â Â Â Â Â Â 
> > plane->drm_plane->plane_id,
> > +   Â Â Â Â Â Â Â 
> > DRM_MODE_OBJECT_PLANE,
> > +   Â Â Â Â Â Â Â 
> > plane->rotation_property,
> > +   Â Â Â Â Â Â Â data->rotation);
> > +
> > +   igt_assert_eq(ret, -EINVAL);
> > +   valid_tests++;
> > +   }
> > +   }
> > +   igt_require_f(valid_tests, "no valid crtc/connector combinations 
> > found\n");
> > +}
> > +
> > Â static void test_plane_rotation(data_t *data, enum igt_plane plane_type)
> > Â {
> > Â   igt_display_t *display = >display;
> > @@ -508,6 +533,14 @@ igt_main
> > Â 
> > Â   igt_display_init(, data.gfx_fd);
> > Â   }
> > +   igt_subtest_f("bad-rotation") {
> > +   data.rotation = 0;
> > +   test_bad_prop_value();
> > +
> > +   data.rotation = IGT_ROTATION_0 | IGT_ROTATION_180;
> > +   test_bad_prop_value();
> > +   }
> > +
> > Â   igt_subtest_f("primary-rotation-180") {
> > Â   data.rotation = IGT_ROTATION_180;
> > Â   test_plane_rotation(, IGT_PLANE_PRIMARY);
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[Bug 97022] Garbage in windows while running a game windowed

https://bugs.freedesktop.org/show_bug.cgi?id=97022

--- Comment #2 from Peter Mulholland  ---
So far I have only produced this bug with two of our games - The Witcher 2, and
Overlord (due to be released today).

Witcher 2 causes the display corruption seen in the screenshot. Overlord
produces corruption quickly followed by a system lockup. Alt-SysRq-B rebooted
the system, and I have attached the last written messages to kern.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/a15ed02f/attachment-0001.html>

[Bug 97022] Garbage in windows while running a game windowed

https://bugs.freedesktop.org/show_bug.cgi?id=97022

--- Comment #1 from Peter Mulholland  ---
Created attachment 125228
  --> https://bugs.freedesktop.org/attachment.cgi?id=125228=edit
Part of kern.log that was written at lockup

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/29f22aff/attachment.html>

[PATCH v2 4/4] drm/i915/skl: Update plane watermarks atomically during plane updates

2016-07-21 Thread Matt Roper

On Thu, Jul 21, 2016 at 03:23:40PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
> 
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
> 
> With this in mind, up until now we've been updating watermarks on skl
> like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
>   or
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
> Now we update watermarks atomically like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks() (wm values aren't written yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
>   }
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks() (actual wm values aren't written
>   yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
>   - write new wm values
> - end vblank evasion
>   }
> 
> So this patch moves all of the watermark writes into the right place;
> inside of the vblank evasion where we update all of the registers for
> each plane. While this patch doesn't fix everything, it does allow us to
> update the watermark values in the way the hardware expects us to.
> 
> Changes since original patch series:
>  - Remove mutex_lock/mutex_unlock since they don't do anything and we're
>not touching global state
>  - Move skl_write_cursor_wm/skl_write_plane_wm functions into
>intel_pm.c, make externally visible
>  - Add skl_write_plane_wm calls to skl_update_plane
>  - Fix conditional for for loop in skl_write_plane_wm (level < max_level
>should be level <= max_level)
>  - Make diagram in commit more accurate to what's actually happening
>  - Add Fixes:
> 
> Changes since v1:
>  - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
>then just Skylake
>  - Update description to make it clear this patch doesn't fix everything
>  - Check if pipes were actually changed before writing watermarks
> 
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude 
> Cc: stable at vger.kernel.org
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  5 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 54 
> ++--
>  drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
>  4 files changed, 49 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 78beb7e..d93d014 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   intel_crtc->adjusted_x = x_offset;
>   intel_crtc->adjusted_y = y_offset;
>  
> + skl_write_plane_wm(intel_crtc, 0);
> +
>   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
>   I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
>   I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
> @@ -10242,6 +10244,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
> u32 base,
>   int pipe = intel_crtc->pipe;
>   uint32_t cntl = 0;
>  
> + if (IS_GEN9(dev_priv))
> + skl_write_cursor_wm(intel_crtc);
> +
>   if (plane_state && plane_state->visible) {
>   cntl = MCURSOR_GAMMA_ENABLE;
>   switch (plane_state->base.crtc_w) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e74d851..f1f54d9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1709,6

[PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

2016-07-21 Thread Matt Roper

On Thu, Jul 21, 2016 at 03:23:38PM -0400, Lyude wrote:
> Manual pipe flushes are only necessary in order to make sure that we prevent
> pipes with changed ddb allocations from overlapping from one another at
> any point in time. Additionally, forcing us to wait for the next vblank
> every time we have to update the watermark values because the cursor was
> moving between screens will introduce a rather noticable lag for users.
> 
> Signed-off-by: Lyude 
> Cc: stable at vger.kernel.org
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c | 31 +--
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c97724d..9e1e045 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1597,6 +1597,7 @@ struct skl_ddb_allocation {
>  
>  struct skl_wm_values {
>   unsigned dirty_pipes;
> + bool ddb_changed;
>   struct skl_ddb_allocation ddb;
>   uint32_t wm_linetime[I915_MAX_PIPES];
>   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 56ddd71..55237ea 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3789,6 +3789,12 @@ static void skl_flush_wm_values(struct 
> drm_i915_private *dev_priv,
>   new_ddb = _values->ddb;
>   cur_ddb = _priv->wm.skl_hw.ddb;
>  
> + /* We only ever need to flush when the ddb allocations change */

I'd expand the comment a bit here since the logic is non-obvious.  In
general, we could still have WM changes (which need a flush) even if the
DDB doesn't change.  However in such cases, we'll be doing a normal
flush as part of update_plane, update_primary_plane, or update_cursor so
there's no need to do an extra, early flush here.  The whole three-step
flush dance is only needed to ensure proper inter-pipe ordering when the
inter-pipe DDB allocation changes; the three-step handling we have here
still isn't happening at the right time during the atomic commit, but
fixing that up is something that one of your later patches will
presumably address.

> + if (!new_values->ddb_changed)
> + return;
> +
> + new_values->ddb_changed = false;
> +
>   /*
>* First pass: flush the pipes with the new allocation contained into
>* the old space.
> @@ -3893,6 +3899,22 @@ pipes_modified(struct drm_atomic_state *state)
>   return ret;
>  }
>  
> +static bool
> +skl_pipe_ddb_changed(struct skl_ddb_allocation *old,
> +  struct skl_ddb_allocation *new,
> +  enum pipe pipe)
> +{
> + if (memcmp(>pipe[pipe], >pipe[pipe],
> +sizeof(old->pipe[pipe])) != 0 ||
> + memcmp(>plane[pipe], >plane[pipe],
> +sizeof(old->plane[pipe])) != 0 ||
> + memcmp(>y_plane[pipe], >y_plane[pipe],
> +sizeof(old->y_plane[pipe])) != 0)
> + return true;

I think I may have misled you when we talked on IRC the other day.
Given the assumption that proper flushing happens during vblank evasion
(via the update_{primary,plane,cursor} functions) that should cover all
of our flushing needs except for the intra-pipe DDB changes where we
need special ordering.  So given that this patch isn't yet tackling the
problems with inter-pipe DDB and is only concerned with cases where the
list of active CRTC's isn't changing, I believe you only need to test
the pipe allocation here and the {plane,y_plane} allocations shouldn't
really matter.  Even if the plane allocations change, I think we should
still have a sequence of:

update_wm() {
write WM's
write DDB
}
flush_wm_values() {
skip flushing because DDB pipe[] alloc didn't change
}
vblank evasion {
update_*() {
write plane registers
flush (plane, WM, and DDB)
}
}

Actually, I feel we could almost drop the skl_flush_wm_values() function
completely in this patch.  Even in the cross-pipe allocation change case
all pipes would get flushed they'd just be flushed in the wrong order,
possibly causing underruns.  However the way we're handling flushing
right now is already wrong and can/will cause underruns, so we wouldn't
really be making the situation worse than it already is, just a
different kind of wrong.  Then it would be simpler to follow up with
another patch that handles all of the pipe updates in the proper order
to solve that final problem.

Matt

> +
> + return false;
> +}
> +
>  static int
>  skl_compute_ddb(struct drm_atomic_state *state)
>  {
> @@ -3900,7 +3922,8 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   struct

[PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

2016-07-21 Thread Joonas Lahtinen

Was not this implemented once and then dropped for some reason?

On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
> 
> Add "bad-rotation" subtest to make sure the kernel rejects some
> invalid rotation values (0 and specifying multiple angles at one).
> 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> ---
> Â tests/kms_rotation_crc.c | 33 +
> Â 1 file changed, 33 insertions(+)
> 
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 6cc15337fff9..e10a0a770437 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -237,6 +237,31 @@ static void wait_for_pageflip(int fd)
> Â igt_assert(drmHandleEvent(fd, ) == 0);
> Â }
> Â 
> +static void test_bad_prop_value(data_t *data)
> +{
> + igt_display_t *display = >display;
> + int valid_tests = 0;
> + enum pipe pipe;
> + igt_plane_t *plane;
> + int ret;
> +
> + for_each_pipe(display, pipe)Â Â {
> + for_each_plane_on_pipe(display, pipe, plane) {
> + igt_require(igt_plane_supports_rotation(plane));
> +
> + ret = drmModeObjectSetProperty(display->drm_fd,
> + Â Â Â Â Â Â Â 
> plane->drm_plane->plane_id,
> + Â Â Â Â Â Â Â 
> DRM_MODE_OBJECT_PLANE,
> + Â Â Â Â Â Â Â 
> plane->rotation_property,
> + Â Â Â Â Â Â Â data->rotation);
> +
> + igt_assert_eq(ret, -EINVAL);
> + valid_tests++;
> + }
> + }
> + igt_require_f(valid_tests, "no valid crtc/connector combinations 
> found\n");
> +}
> +
> Â static void test_plane_rotation(data_t *data, enum igt_plane plane_type)
> Â {
> Â igt_display_t *display = >display;
> @@ -508,6 +533,14 @@ igt_main
> Â 
> Â igt_display_init(, data.gfx_fd);
> Â }
> + igt_subtest_f("bad-rotation") {
> + data.rotation = 0;
> + test_bad_prop_value();
> +
> + data.rotation = IGT_ROTATION_0 | IGT_ROTATION_180;
> + test_bad_prop_value();
> + }
> +
> Â igt_subtest_f("primary-rotation-180") {
> Â data.rotation = IGT_ROTATION_180;
> Â test_plane_rotation(, IGT_PLANE_PRIMARY);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

[PATCH 7/7] drm/i915: Add horizontal mirroring support for CHV pipe B planes

2016-07-21 Thread Joonas Lahtinen

On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
> 
> The primary and sprite planes on CHV pipe B support horizontal
> mirroring. Expose it to the world.
> 
> Sadly the hardware ignores the mirror bit when the rotate bit is
> set, so we'll have to reject the 180+X case.
> 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 

Seems to match spec. Maybe add your own T-b, as you have obviously
tested on hardware.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> ---
> Â drivers/gpu/drm/i915/intel_atomic_plane.c |Â Â 8 
> Â drivers/gpu/drm/i915/intel_display.cÂ Â Â Â Â Â | 10 ++
> Â drivers/gpu/drm/i915/intel_sprite.cÂ Â Â Â Â Â Â | 10 ++
> Â 3 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index c19eb9a0cd4a..0a019eacfede 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -180,6 +180,14 @@ static int intel_plane_atomic_check(struct drm_plane 
> *plane,
> Â }
> Â }
> Â 
> + /* CHV ignores the mirror bit when the rotate bit is set :( */
> + if (IS_CHERRYVIEW(plane->dev) &&
> + Â Â Â Â state->rotation & BIT(DRM_ROTATE_180) &&
> + Â Â Â Â state->rotation & BIT(DRM_REFLECT_X)) {
> + DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
> + return -EINVAL;
> + }
> +
> Â intel_state->visible = false;
> Â ret = intel_plane->check_plane(plane, crtc_state, intel_state);
> Â if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 88a7c4173715..edb1809a642d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2677,6 +2677,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
> *primary,
> Â if (rotation & BIT(DRM_ROTATE_180))
> Â dspcntr |= DISPPLANE_ROTATE_180;
> Â 
> + if (rotation & BIT(DRM_REFLECT_X))
> + dspcntr |= DISPPLANE_MIRROR;
> +
> Â if (IS_G4X(dev))
> Â dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
> Â 
> @@ -2700,6 +2703,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
> *primary,
> Â linear_offset +=
> Â (crtc_state->pipe_src_h - 1) * fb->pitches[0] +
> Â (crtc_state->pipe_src_w - 1) * cpp;
> + } else if (rotation & BIT(DRM_REFLECT_X)) {
> + x += (crtc_state->pipe_src_w - 1);
> + linear_offset += (crtc_state->pipe_src_w - 1) * cpp;
> Â }
> Â 
> Â intel_crtc->adjusted_x = x;
> @@ -14295,6 +14301,10 @@ static struct drm_plane 
> *intel_primary_plane_create(struct drm_device *dev,
> Â supported_rotations =
> Â BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
> Â BIT(DRM_ROTATE_180) | BIT(DRM_ROTATE_270);
> + } else if (IS_CHERRYVIEW(dev) && pipe == PIPE_B) {
> + supported_rotations =
> + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180) |
> + BIT(DRM_REFLECT_X);
> Â } else if (INTEL_INFO(dev)->gen >= 4) {
> Â supported_rotations =
> Â BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 14173f53f520..4d6cd1a02e34 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -436,6 +436,9 @@ vlv_update_plane(struct drm_plane *dplane,
> Â if (rotation & BIT(DRM_ROTATE_180))
> Â sprctl |= SP_ROTATE_180;
> Â 
> + if (rotation & BIT(DRM_REFLECT_X))
> + sprctl |= SP_MIRROR;
> +
> Â /* Sizes are 0 based */
> Â src_w--;
> Â src_h--;
> @@ -451,6 +454,9 @@ vlv_update_plane(struct drm_plane *dplane,
> Â x += src_w;
> Â y += src_h;
> Â linear_offset += src_h * fb->pitches[0] + src_w * cpp;
> + } else if (rotation & BIT(DRM_REFLECT_X)) {
> + x += src_w;
> + linear_offset += src_w * cpp;
> Â }
> Â 
> Â if (key->flags) {
> @@ -1128,6 +1134,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
> pipe, int plane)
> Â supported_rotations =
> Â BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
> Â BIT(DRM_ROTATE_180) | BIT(DRM_ROTATE_270);
> + } else if (IS_CHERRYVIEW(dev) && pipe == PIPE_B) {
> + supported_rotations =
> + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180) |
> + BIT(DRM_REFLECT_X);
> Â } else {
> Â supported_rotations =
> Â BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

[Bug 97022] Garbage in windows while running a game windowed

https://bugs.freedesktop.org/show_bug.cgi?id=97022

Bug ID: 97022
Summary: Garbage in windows while running a game windowed
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: peter.mulholland at vpltd.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 125226
--> https://bugs.freedesktop.org/attachment.cgi?id=125226=edit
Photograph of screen when the problem occurs

This is an odd one, as of posting I have only managed to reproduce this when
using a Virtual Programming OpenGL 3.2 based game, such as The Witcher 2. I
have not been able to reproduce it with Valve's Source games.

For example, If you run The Witcher 2 in windowed mode, and allow it to get to
the menu screen, doing anything with another window (such as resizing) causes
the display to turn to junk. Eventually the whole X11 display will be corrupt,
and only rebooting the system will clear it. Text mode TTY's are unaffected.

Occasionally, rather than corruption, the system will lock up, requiring a hard
reset or magic sysrq reset. I could not find a way to consistently reproduce
this though, whereas I can consistently reproduce the corruption.

Specs:
Xubuntu 16.04.1 LTS
Kernel 4.0.0-31-generic, x86_64
Mesa 12.1.0-devel (Padoka PPA)
DRM 2.43.0
GPU Radeon HD 7750 (CAPE VERDE PCI 1002:683F), 1GB VRAM
Xorg 1.18.3
Desktop Xfce4 4.12, using builtin compositor

Disabling the compositor makes no difference. Restarting Xorg when the fault
occurs makes no difference.

The bug is not present in the 11.2.0 release of Mesa shipped with Ubuntu 16.04
by default.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/4d29497e/attachment.html>

[PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

2016-07-21 Thread Lyude Paul

Two things for this one:
1. I completely messed up the description on this patchset, this was for fixing
underruns on pipe disablement. I'm impressed I wrote up that whole description
without realizing that at all, lol.
2. This patch may not actually be necessary. On the original git branch I was
testing this on it was required to prevent underruns on pipe disables, but
trying this on nightly I don't seem to reproduce those underruns even when I
remove this patch, so I guess we can drop this from the series

On Wed, 2016-07-20 at 17:27 -0700, Matt Roper wrote:
> On Wed, Jul 20, 2016 at 05:00:00PM -0400, Lyude wrote:
> > 
> > As we've learned, all watermark updates on Skylake have to be strictly
> > atomic or things fail. While the bspec doesn't mandate that we need to
> > wait for pipes to finish after the third iteration of flushes, not doing
> > so gives us the opportunity to break this atomicity later. This example
> > assumes that we're lucky enough not to be interrupted by the scheduler
> > at any point during this:
> > 
> > Â - Start with pipe A and pipe B enabled
> > Â - Enable pipe C
> > Â - Flush pipe A in pass 1, wait until update finishes
> > Â - Flush pipe B in pass 3, continue without waiting for next vblank
> > Â - Start another wm update
> > Â - We enter the next vblank for pipe B before we finish writing all the
> > Â Â Â vm values
> > Â - *Underrun*
> > 
> > As such, we always need to wait for each pipe we flush to update so as
> > to never break this atomicity.
> 
> I'm not sure I follow this commit.Â Â If we're enabling a new pipe, the
> the allocation for A and B are generally going to shrink, so they'll
> usually be flushed in passes 1 and 2, not 3.
> 
> My understanding is that the problem that still remains (now that your
> first three patches have made progress towards fixing underruns) is that
> our DDB updates and flushes (which come from update_watermarks) happen
> pre-evasion, whereas the watermarks themselves now happen under evasion.
> We really want both the new DDB value and the new watermark value to be
> written together and take effect on the same vblank.Â Â I think the
> problem is that you might have a shrinking DDB allocation (e.g., because
> a new pipe was added or you changed a mode that changed the DDB balance)
> which some of the existing WM values exceed.Â Â You can have a sequence
> like this:
> 
> Â  - update_wm:
> Â Â Â Â Â - write new (smaller) DDB
> Â Â Â Â Â - flush DDB
> Â  - vblank happens, old (big) wm + new (small) ddb = underrun
> Â  - vblank evasion:
> Â Â Â Â Â - write new plane regs and WM's
> Â Â Â Â Â - flush
> Â  - post-evasion vblank happens, underrun is corrected
> 
> I think ultimately we want to move the DDB register writes into the
> update functions that happen under evasion, just like you did for the WM
> registers.Â Â However just doing this the straightforward way won't
> satisfy our requirements about pipe update ordering (the three passes
> you see today in skl_flush_wm_values).Â Â To make that work, I think the
> general approach is that we need to basically replace the
> for_each_crtc_in_state() loop in intel_atomic_commit_tail() with some
> new CRTC iterator that processes CRTC's in a more intelligent ordering.
> We've computed our DDB changes during the atomic check phase, so we
> already know which allocations are shrinking, growing, etc. and we
> should be able to calculate an appropriate CRTC ordering at the same
> time.
> 
> With an intelligent CRTC iterator that follows the pre-computed pipe
> ordering rules (and adds the necessary vblank waits between each
> "phase"), I think we should be able to just write both DDB and WM values
> in the skl_update_primary_plane() and similar functions and let the
> existing flushes that happen take care of flushing them out at the
> appropriate time.Â Â Of course I've kicked that idea around in my head for
> a while, but haven't had time to actually write any code for it, so I
> may be completely overlooking some stumbling block that makes it much
> more complicated than I'm envisioning.
> 
> 
> Matt
> 
> > 
> > 
> > Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> > Signed-off-by: Lyude 
> > Cc: stable at vger.kernel.org
> > Cc: Ville SyrjÃ¤lÃ¤ 
> > Cc: Daniel Vetter 
> > Cc: Radhakrishna Sripada 
> > Cc: Hans de Goede  
> > Cc: Matt Roper 
> > ---
> > Â drivers/gpu/drm/i915/intel_pm.c | 17 +++--
> > Â 1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 788db86..2e31df4 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3859,8 +3859,11 @@ static void skl_flush_wm_values(struct
> > drm_i915_private *dev_priv,
> > Â   /*
> > Â   Â * Third pass: flush the pipes that got more space allocated.
> > Â   Â *
> > -   Â * We don't need to actively wait for the update here, next vblank
> > -   Â * will just get more DDB space

Some more VC4 vblank fixes and timestamping improvements.

2016-07-21 Thread Eric Anholt

Mario Kleiner  writes:

> Hi Eric and all,
>
> this batch prevents setting modes one shouldn't set,
> adds precise vblank timestamping for interlaced video
> modes, and one fix for vblank en/disable during crtc
> en/disable.
>
> All successfully tested, also with timing measurement equipment,
> on the RPi 2B.

This all seems pretty reasonable to me.  My question for modesetting
gurus would be: Is mode_fixup the place to be filtering out
unsupportable modes from the user (or their displays)?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/accf388d/attachment.sig>

ATPX changes in drm-next-4.8 and D3cold handling

2016-07-21 Thread Peter Wu

Hi Alex,

There are a couple of changes for 4.8 that try to detect whether the
"power_cntl" flag is present. Originally attributed to a firmware bug,
it seems that the detection is performed too late resulting in flags
that are always zero
(https://bugzilla.kernel.org/show_bug.cgi?id=115321).  What PX platform
are these patches tested with, did they have the same issue?


In case you missed it, Dave's D3cold patches were succeeded by changes
in PCI core. Relevant commits in the pci/pm branch:

006d44e PCI: Add runtime PM support for PCIe ports
16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan
d963f65 PCI: Power on bridges before scanning new devices
9d26d3a PCI: Put PCIe ports into D3 during suspend
43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports

With these changes, the nouveau driver had to disable use of the _DSM
ACPI method (comparable to ATPX), otherwise both interfaces are used
which could cause issues like being unable to resume the device.
Also note that pcieport currently only handles D3cold for devices with a
BIOS date in 2015 (or newer), you need to detect this with an approach
like http://www.spinics.net/lists/linux-pci/msg52602.html

We also found that the Nvidia HDMI audio device (function 1) would
prevent the pcieport from sleeping. For modern Nvidia hardware this is
apparently not an issue because these somehow hide the audio device, but
it might be an issue for AMD hardware. See also
https://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

[PATCH] drm/ttm: partial revert "cleanup ttm_tt_(unbind|destroy)"

2016-07-21 Thread Christian König

From: Christian KÃ¶nig 

We still need to unbind explicitely during a move.

This partial reverts commit ff20caa0bcbfef9f7686f8d1868a3b990921afd6.

Signed-off-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c |  1 +
 drivers/gpu/drm/ttm/ttm_tt.c  | 15 ---
 include/drm/ttm/ttm_bo_driver.h   |  9 +
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 0c389a5..6c412c3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -53,6 +53,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
int ret;

if (old_mem->mem_type != TTM_PL_SYSTEM) {
+   ttm_tt_unbind(ttm);
ttm_bo_free_old_node(bo);
ttm_flag_masked(_mem->placement, TTM_PL_FLAG_SYSTEM,
TTM_PL_MASK_MEM);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index d28d4333..fa42dc3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -172,9 +172,7 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
return;

if (ttm->state == tt_bound) {
-   ret = ttm->func->unbind(ttm);
-   BUG_ON(ret);
-   ttm->state = tt_unbound;
+   ttm_tt_unbind(ttm);
}

if (ttm->state == tt_unbound)
@@ -255,6 +253,17 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
 }
 EXPORT_SYMBOL(ttm_dma_tt_fini);

+void ttm_tt_unbind(struct ttm_tt *ttm)
+{
+   int ret;
+
+   if (ttm->state == tt_bound) {
+   ret = ttm->func->unbind(ttm);
+   BUG_ON(ret);
+   ttm->state = tt_unbound;
+   }
+}
+
 int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem)
 {
int ret = 0;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 141cefb..e7d81a8 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -628,6 +628,15 @@ extern int ttm_tt_bind(struct ttm_tt *ttm, struct 
ttm_mem_reg *bo_mem);
 extern void ttm_tt_destroy(struct ttm_tt *ttm);

 /**
+ * ttm_ttm_unbind:
+ *
+ * @ttm: The struct ttm_tt.
+ *
+ * Unbind a struct ttm_tt.
+ */
+extern void ttm_tt_unbind(struct ttm_tt *ttm);
+
+/**
  * ttm_tt_swapin:
  *
  * @ttm: The struct ttm_tt.
-- 
2.5.0

[PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

2016-07-21 Thread CK Hu

Hi, Bibby:

On Thu, 2016-07-21 at 11:21 +0800, Bibby Hsieh wrote:
> Hi, CK
> 
> I'm appreciate your comments.
> 
> 

[snip...]

> > >  
> > > @@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct 
> > > mtk_ddp_comp *ovl)
> > >   if (state->pending_config) {
> > >   mtk_ddp_comp_config(ovl, state->pending_width,
> > >   state->pending_height,
> > > - state->pending_vrefresh);
> > > + state->pending_vrefresh, 0);
> > 
> > Why set bpc as 0 here? Maybe you have a assumption that OVL don't care
> > the bpc parameter. If one day OVL care it and we do not review here, the
> > bugs happen.
> > 
> Pass 0 means don't care, I will modify mtk_od_config() and
> mtk_gamma_config() to filter this condition.

Using 0 as 'don't care' looks tricky. Please add comments to describe
this.

> > >  
> > >   state->pending_config = false;
> > >   }

Regards,
CK

[Bug 91136] [tahiti xt] portal2/dota2 glitchy without R600_DEBUG=switch_on_eop

https://bugs.freedesktop.org/show_bug.cgi?id=91136

--- Comment #8 from vinod reddy  ---
Comment on attachment 116766
  --> https://bugs.freedesktop.org/attachment.cgi?id=116766
dmesg

fgn kjnhnbf hnhbfnhdujn nbirne  lkcmfnih nthtuhufbn nhtufojnnu
nhbbburehruhfgbn jnjjhujnufgnb

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/463efe8e/attachment.html>

[PATCH v3 1/2] drm/mediatek: Add gamma correction

2016-07-21 Thread Bibby Hsieh

Hi, CK

I'm appreciate your comments.

On Fri, 2016-07-15 at 17:11 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> Some comments inline.
> 
> On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> > 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 +++
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   89 
> > ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +++
> >  4 files changed, 106 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..ee219bb 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -409,6 +409,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> > }
> > if (pending_planes)
> > mtk_crtc->pending_planes = true;
> > +   if (crtc->state->color_mgmt_changed)
> > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > +
> >  }
> >  
> >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -418,6 +422,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset  = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > +   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> >  };
> >  
> >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -569,6 +574,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > if (ret < 0)
> > goto unprepare;
> >  
> > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > +   drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > + MTK_LUT_SIZE);
> > priv->crtc[pipe] = _crtc->base;
> > priv->num_pipes++;
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > index 81e5566..d332564 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > @@ -19,6 +19,7 @@
> >  #include "mtk_drm_plane.h"
> >  
> >  #define OVL_LAYER_NR   4
> > +#define MTK_LUT_SIZE   512
> >  
> >  int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> >  void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int 
> > pipe);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 3970fcf..56c5894 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -24,6 +24,7 @@
> >  #include "mtk_drm_drv.h"
> >  #include "mtk_drm_plane.h"
> >  #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_crtc.h"
> >  
> >  #define DISP_OD_EN 0x
> >  #define DISP_OD_INTEN  0x0008
> > @@ -38,6 +39,21 @@
> >  #define DISP_COLOR_WIDTH   0x0c50
> >  #define DISP_COLOR_HEIGHT  0x0c54
> >  
> > +#define DISP_AAL_EN0x000
> > +#define DISP_AAL_SIZE  0x030
> > +
> > +#define DISP_GAMMA_EN  0x000
> > +#define DISP_GAMMA_CFG 0x020
> > +#define DISP_GAMMA_SIZE0x030
> > +#define DISP_GAMMA_LUT 0x700
> 
> It's better that the digits of register address of OD, COLOR, AAL, and
> GAMMA are the same. Maybe you can align all to 4 digits.
> 
Ok, will fix.
> > +
> > +#define LUT_10BIT_MASK 0x3ff
> > +
> > +#define AAL_EN BIT(0)
> > +
> > +#define GAMMA_EN   BIT(0)
> > +#define GAMMA_LUT_EN   BIT(1)
> > +
> >  #defineOD_RELAY_MODE   BIT(0)
> >  
> >  #defineUFO_BYPASS  BIT(2)
> > @@ -76,6 +92,61 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> > writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> >  }
> >  
> > +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> > +  unsigned int h, unsigned int vrefresh)
> > +{
> > +   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> > +}
> > +
> > +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(AAL_EN, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> > +{
> > +   writel_relaxed(0x0, comp->regs  + DISP_AAL_EN);
> > +}
> 
> I think AAL is somewhat different from GAMMA and this patch include 3
> modifications:
> 
> 1. AAL

[PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

2016-07-21 Thread Bibby Hsieh

Hi, CK

I'm appreciate your comments.


On Mon, 2016-07-18 at 10:33 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> Some comments inline.
> 
> On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote:
> > Some panels only accept bpc (bit per color) 6-bit.
> > But, the default bpc in mt8173 display data path is 8-bit.
> > If we didn't enable dithering function to convert bpc,
> > display cannot show the smooth grayscale image.
> > 
> > In mt8173, the dithering function in OD (OverDrive) and
> > GAMMA module, we have to config them with
> > connector->display_mode.bpc when CRTC initial.
> > 
> > 1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
> > 2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
> > i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
> > so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
> > 3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.
> > 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
> >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   21 ++--
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   77 
> > +++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |6 +--
> >  5 files changed, 92 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 8f62671f..019b7ca 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
> >  }
> >  
> >  static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
> > -  unsigned int h, unsigned int vrefresh)
> > +  unsigned int h, unsigned int vrefresh,
> > +  unsigned int bpc)
> >  {
> > if (w != 0 && h != 0)
> > writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > index 5fb80cb..0df05f9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > @@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
> >  }
> >  
> >  static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> > -   unsigned int height, unsigned int vrefresh)
> > +   unsigned int height, unsigned int vrefresh,
> > +   unsigned int bpc)
> >  {
> > unsigned int threshold;
> > unsigned int reg;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index ee219bb..18c9d0d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -222,7 +222,9 @@ static void mtk_crtc_ddp_clk_disable(struct 
> > mtk_drm_crtc *mtk_crtc)
> >  static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> >  {
> > struct drm_crtc *crtc = _crtc->base;
> > -   unsigned int width, height, vrefresh;
> > +   struct drm_connector *connector;
> > +   struct drm_encoder *encoder;
> > +   unsigned int width, height, vrefresh, bpc = 0;
> > int ret;
> > int i;
> >  
> > @@ -234,6 +236,19 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
> > *mtk_crtc)
> > height = crtc->state->adjusted_mode.vdisplay;
> > vrefresh = crtc->state->adjusted_mode.vrefresh;
> >  
> > +   drm_for_each_encoder(encoder, crtc->dev) {
> > +   if (encoder->crtc != crtc)
> > +   continue;
> > +
> > +   drm_for_each_connector(connector, crtc->dev) {
> > +   if (connector->encoder != encoder)
> > +   continue;
> > +   if (connector->display_info.bpc >= 3 &&
> 
> I think you should left this HW constrain in mtk_od_config() and
> mtk_gamma_config(). Here just calculate the expected bpc.
> 
Ok, I will do that.
> > +   (bpc == 0 || bpc > connector->display_info.bpc))
> 
> I think bpc should be initialized as HW default bpc and you can remove
> this condiction 'bpc == 0' because we should set bpc to HW default bpc
> while all connnector bpc is greater than HW default bpc.
> 
Ok, will do.
> > +   bpc = connector->display_info.bpc;
> > +   }
> > +   }
> > +
> > ret = pm_runtime_get_sync(crtc->dev->dev);
> > if (ret < 0) {
> > DRM_ERROR("Failed to enable power domain: %d\n", ret);
> > @@ -266,7 +281,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
> > *mtk_crtc)
> > for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> >  
> > -   mtk_ddp_comp_config(comp, width, height, vrefresh);
> > +

[PATCH v6 4/4] drm: rcar: use generic code for managing zpos plane property

version 4:
fix null pointer issue while setting zpos in plane reset function

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Laurent Pinchart 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
 5 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index e39fcef..7316fc7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 6bb032d..f03eb55 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca..a74f8ed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
-- 
1.9.1

[PATCH v6 3/4] drm/exynos: use generic code for managing zpos plane property

From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b39d521..7f1a49d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
void *mapping;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 77f12c0..7f32419 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private *dev_priv =

[PATCH v6 2/4] drm: sti: use generic zpos for plane

remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_cursor.c |  4 +--
 drivers/gpu/drm/sti/sti_gdp.c|  4 +--
 drivers/gpu/drm/sti/sti_hqvdp.c  |  4 +--
 drivers/gpu/drm/sti/sti_mixer.c  |  9 ++---
 drivers/gpu/drm/sti/sti_plane.c  | 78 +++-
 drivers/gpu/drm/sti/sti_plane.h  |  7 +---
 6 files changed, 38 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index a263bbb..3b53f7f 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -349,8 +349,8 @@ struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_cursor_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_cursor_late_register,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index bf63086..b8d942c 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -886,8 +886,8 @@ struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_gdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_gdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index b032322..b5ee783 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1254,8 +1254,8 @@ struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_hqvdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_hqvdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 1885c7a..7d9aea8 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -239,13 +239,10 @@ static void sti_mixer_set_background_area(struct 
sti_mixer *mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;

-   if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
-   return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -278,8 +275,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer, 
struct sti_plane *plane)
break;
}

-   mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
-   plane_id = plane_id << (3 * (depth - 1));
+   mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+   plane_id = plane_id << (3 * depth);

DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
 sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 0cf3335..ca4b371 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -96,59 +87,46 @@

[PATCH v6 1/4] drm: add generic zpos property

From: Marek Szyprowski 

version 6:
- add zpos in gpu documentation file
- merge Ville patch about zpos initial value and API improvement.
  I have split Ville patch between zpos core and drivers

version 5:
- remove zpos range check and comeback to 0 to N-1
  normalization algorithm

version 4:
- make sure that normalized zpos value is stay
  in the defined property range and warn user if not

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 Documentation/gpu/kms-properties.csv |   1 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c |   4 +
 drivers/gpu/drm/drm_atomic_helper.c  |   7 +
 drivers/gpu/drm/drm_blend.c  | 240 +++
 drivers/gpu/drm/drm_crtc_internal.h  |   4 +
 include/drm/drm_crtc.h   |  30 +
 7 files changed, 287 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index b6fcaf6..3587ea2 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ DRM,Generic,ârotationâ,BITMASK,"{ 0, ""rotate-0"" }, { 1, 
""rotate-90"" }, {
 ,,âCRTC_Hâ,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination) 
height (atomic)
 ,,âFB_IDâ,OBJECT,DRM_MODE_OBJECT_FB,Plane,Scanout framebuffer (atomic)
 ,,âCRTC_IDâ,OBJECT,DRM_MODE_OBJECT_CRTC,Plane,CRTC that plane is attached 
to (atomic)
+,,âzposâ,RANGE,"Min=0, Max=UINT_MAX",Plane,Zorder of the plane
 ,DVI-I,âsubconnectorâ,ENUM,"{ âUnknownâ, âDVI-Dâ, âDVI-Aâ 
}",Connector,TBD
 ,,âselect subconnectorâ,ENUM,"{ âAutomaticâ, âDVI-Dâ, âDVI-Aâ 
}",Connector,TBD
 ,TV,âsubconnectorâ,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", 
""Component"", ""SCART"" }",Connector,TBD
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f..7fbcf3f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9359be4..8ddd8bc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -712,6 +712,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == plane->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -768,6 +770,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == plane->zpos_property) {
+   *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index de7fddc..20be86d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 

+#include "drm_crtc_internal.h"
+
 /**
  * DOC: overview
  *
@@

[PATCH v6 0/4] Generic zpos property

version 6:
add zpos in Documentation/gpu/kms-properties.csv
merge Ville's patch (splitted between all the commits)
it simplify the API and fix bug. Thanks

version 5:
rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
exist anymore.
rework sti patch because some plane functions have changed since v4

version 4:
make sure that normalized zpos value is stay in the defined property 
range and warn user if not.
Fix NULL pointer bug in rcar-du while setting zpos value.
No changes in the other drivers.

version 3:
use kmalloc_array instead of kmalloc.
Correct normalize_zpos computation (comeback to Mareck original code)

version 2:
add a zpos property into drm_plane structure to simplify code.
This allow to get/set zpos value in core and not in drivers code.
Fix various remarks.

version 1:
refactor Marek's patches to have per plane zpos property instead of only
one in core.

Benjamin Gaignard (2):
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 Documentation/gpu/kms-properties.csv  |   1 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   4 +
 drivers/gpu/drm/drm_atomic_helper.c   |   7 +
 drivers/gpu/drm/drm_blend.c   | 240 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c |   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  78 --
 drivers/gpu/drm/sti/sti_plane.h   |   7 +-
 include/drm/drm_crtc.h|  30 
 21 files changed, 341 insertions(+), 147 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
-- 
1.9.1

[PATCH v1 1/2] drm/panel: simple-panel: add the delay timing for Sharp LQ123P1JX31

2016-07-21 Thread Sean Paul

On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:
> According to page 16 of Sharp LQ123P1JX31 datasheet, we need to add the
> missing delay timing. Panel prepare time should be t1 (0.5ms~10ms) plus
> t3 (0ms~100ms), and panel enable time should equal to t7 (0ms~50ms), and
> panel unprepare time should be t11 (1ms~50ms) plus t12 (500ms~).
>
> Signed-off-by: Yakir Yang 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 85143d1..f178998 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1384,6 +1384,11 @@ static const struct panel_desc sharp_lq123p1jx31 = {
> .width = 259,
> .height = 173,
> },
> +   .delay = {
> +   .prepare = 110,
> +   .enable = 50,
> +   .unprepare = 550,
> +   },
>  };
>
>  static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
> --
> 1.9.1
>
>

[PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

2016-07-21 Thread Sean Paul

On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:
> Some panels (like Sharp LQ123P1JX31) need to be turn off when eDP
> controller stop to send valid video signal, otherwhise panel would
> go burn in, and keep flicker and flicker.
>
> So it's better to turn off the panel when eDP need to disable, and
> we need to turn on the panel in connector->detect() callback, so
> that driver would detect panel status rightly.
>
> Signed-off-by: Yakir Yang 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 32715da..ea059b3 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -961,6 +961,14 @@ analogix_dp_detect(struct drm_connector *connector, bool 
> force)
>  {
> struct analogix_dp_device *dp = to_dp(connector);
>
> +   /*
> +* Panle would prepare for several times here, but don't worry it

s/Panle/Panel/

> +* would only enable the hardware at the first prepare time.


Errr, this shouldn't go in detect. How about putting this in
bridge_enable instead?

> +*/
> +   if (dp->plat_data->panel)
> +   if (drm_panel_prepare(dp->plat_data->panel))

Personally, I don't like doing work in a conditional since you're
throwing the return code away. Could you break this out into:

ret = drm_panel_prepare(dp->plat_data->panel);
if (ret)
  DRM_ERROR("failed to setup the panel ret=%d\n", ret);

> +   DRM_ERROR("failed to setup the panel\n");
> +
> if (analogix_dp_detect_hpd(dp))
> return connector_status_disconnected;
>
> @@ -1063,7 +1071,8 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
> return;
>
> if (dp->plat_data->panel) {
> -   if (drm_panel_disable(dp->plat_data->panel)) {
> +   if (drm_panel_disable(dp->plat_data->panel) ||
> +   drm_panel_unprepare(dp->plat_data->panel)) {

Same comment here, please break this out into separate statements for
better readability/logging.

> DRM_ERROR("failed to disable the panel\n");
> return;
> }
> @@ -1333,13 +1342,6 @@ int analogix_dp_bind(struct device *dev, struct 
> drm_device *drm_dev,
>
> phy_power_on(dp->phy);
>
> -   if (dp->plat_data->panel) {
> -   if (drm_panel_prepare(dp->plat_data->panel)) {
> -   DRM_ERROR("failed to setup the panel\n");
> -   return -EBUSY;
> -   }
> -   }
> -
> analogix_dp_init_dp(dp);
>
> ret = devm_request_threaded_irq(>dev, dp->irq,
> --
> 1.9.1
>
>

linux-next: Tree for Jul 21 (gpu/virtio)

2016-07-21 Thread Randy Dunlap

On 07/20/16 23:56, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160720:
> 

on x86_64, when CONFIG_FB is not enabled:

ERROR: "remove_conflicting_framebuffers" [drivers/gpu/drm/virtio/virtio-gpu.ko] 
undefined!


-- 
~Randy

Radeon r480x polaris support -what kernel git to use?

2016-07-21 Thread Jarkko Korpi

As the title says. 

How to fetch the most recent changes to the hardware? I don't want to use 
4.7.rc7 but more recent.



-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/beec951f/attachment.html>

[PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

2016-07-21 Thread Chris Wilson

On Wed, Jul 20, 2016 at 04:28:40PM -0700, Kristian HÃ¸gsberg wrote:
> Why is this useful if only root can use it?

> > When performing driver testing, one factor we want to test is how we
> > handle a foreign fence that is never signaled. We can wait on that fence
> > indefinitely, in which case the driver appears hung, or we can take some
> > remedial action (with risks regarding the state of any shared content).
> > Whatever the action choosen by the driver, in order to perform the test
> > we want to disable the safety feature of vgem fence (which is then used
> > to test implicit dma-buf fencing). This is regarded as a highly
> > dangerous feature and so hidden behind an expert config option and only
> > available to root when enabled.

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 97003] [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders

https://bugs.freedesktop.org/show_bug.cgi?id=97003

--- Comment #4 from kudahkukarek at gmail.com ---
(In reply to Michel DÃ¤nzer from comment #3)
> valgrind doesn't understand some (not very) recent AMD specific instructions
> yet. I build everything with -march=amdfam10 -mtune=native to avoid this.

Ok, I'll recompile wine and try again.

> Right, but video memory leaks are usually accompanied by corresponding
> system memory leaks, which can be caught by valgrind.

True, the game does noticeably leak system memory (1.5+ GiB footprint with
precompiled shaders vs 500 MB with mono)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/33674e65/attachment.html>

[Bug 97003] [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders

https://bugs.freedesktop.org/show_bug.cgi?id=97003

--- Comment #3 from Michel DÃ¤nzer  ---
(In reply to kudahkukarek from comment #2)
> It does not launch under valgrind for me, it dies from unknown instruction
> in ntdll (log attached)
> 
> vex x86->IR: unhandled instruction bytes: 0x36 0x89 0x50 0xC

valgrind doesn't understand some (not very) recent AMD specific instructions
yet. I build everything with -march=amdfam10 -mtune=native to avoid this.


> Also to clarify, "ERR08 : Memory overrun." refers to GPU's video memory
> running out, the game does not cause system OOM.

Right, but video memory leaks are usually accompanied by corresponding system
memory leaks, which can be caught by valgrind.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160721/70cf2ccf/attachment.html>

[PATCH libdrm] Simplify the RELEASING steps based on current release.sh.

On 20 July 2016 at 20:27, Eric Anholt  wrote:
> Since release.sh creates and pushes a libdrm-$VERSION tag for us,
> there's no need to also have the user manually generating a $VERSION
> tag as well.
>
> I also dropped the "optional" part of distcheck.  You shouldn't have
> pushed master with a version bump that hasn't passed distcheck.
> ---
>  RELEASING | 26 ++
>  1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/RELEASING b/RELEASING
> index 62c5be9fafe9..262ca08d26c4 100644
> --- a/RELEASING
> +++ b/RELEASING
> @@ -9,21 +9,14 @@ However, this is up to whoever is driving the feature in 
> question.
>
>  Follow these steps to release a new version of libdrm:
>
> -  1) Ensure that there are no local, uncommitted/unpushed
> - modifications. You're probably in a good state if both "git diff
> - HEAD" and "git log master..origin/master" give no output.
> -
Nice. release.sh already checks this for us - no point in listing it
here afaict.

> -  2) Bump the version number in configure.ac. We seem to have settled
> +  1) Bump the version number in configure.ac. We seem to have settled
>   for 2.4.x as the versioning scheme for libdrm, so just bump the
>   micro version.
>
> -  3) Run autoconf and then re-run ./configure so the build system
> +  2) Run autoconf and then re-run ./configure so the build system
>   picks up the new version number.
>
I have sent some patches [1] for release.sh that make this step
obsolete. If you can weight-in on the topic that'll be appreciated.

[1] https://patchwork.freedesktop.org/series/9382/
Patch 9/10 in particular

> -  4) (optional step, release.sh will make distcheck for you, but it can be
> -  heart warming to verify that make distcheck passes)
> -
> - Verify that the code passes "make distcheck".  Running "make
> +  3) Verify that the code passes "make distcheck".  Running "make
>   distcheck" should result in no warnings or errors and end with a
>   message of the form:
>
Note: There's still a few warnings which we should squash one of these days.

> @@ -36,20 +29,13 @@ Follow these steps to release a new version of libdrm:
>   Make sure that the version number reported by distcheck and in
>   the tarball names matches the number you bumped to in configure.ac.
>
> -  5) Commit the configure.ac change and make an annotated tag for that
> - commit with the version number of the release as the name and a
> - message of "libdrm X.Y.Z".  For example, for the 2.4.16 release
> - the command is:
> -
> -   git tag -a 2.4.16 -m "libdrm 2.4.16"
> -
Yes please. The duplicate [but not quite] tag have always confused me.

Fwiw:
Reviewed-by: Emil Velikov 

-Emil

[Bug 97003] [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders