[Bug 91571] AMD graphics hardware hangs with an homogeneous coloured screen or blank screen, and with chirp coming from the graphics card

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=91571

Alberto Salvia Novella  changed:

   What|Removed |Added

URL||https://bugs.launchpad.net/
   ||linux/+bug/881526

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 91571] New: AMD graphics hardware hangs with an homogeneous coloured screen or blank screen, and with chirp coming from the graphics card

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=91571

Bug ID: 91571
   Summary: AMD graphics hardware hangs with an homogeneous
coloured screen or blank screen, and with chirp coming
from the graphics card
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.0-29.39
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: es20490446e at gmail.com
Regression: No

In Ubuntu happens at random to many users, both using the proprietary and libre
driver. More frequently running videos on YouTube with the HTML5 player
(https://www.youtube.com/html5) or with the XBMC home theatre software.

Because this normally happens after first boot, but not in posterior ones, I
greatly suspect this is a hardware bug.

Probably this is happening because of the GPU passing from a cold state to a
warm state too fast, under graphic demanding operations as watching videos are.

And Windows users won't be experiencing this as the GPU stays in a lower power
state.

/var/log/kern.log (provided by another user):
Oct 25 14:53:46 lt9630 kernel: [ 737.900416] INFO: rcu_sched_state detected
stall on CPU 2 (t=15000 jiffies)
Oct 25 14:55:46 lt9630 kernel: [ 857.813946] [fglrx] ASIC hang happened
Oct 25 14:55:46 lt9630 kernel: [ 857.813950] Pid: 1149, comm: Xorg Tainted: P C
3.0.0-12-generic #20-Ubuntu
Oct 25 14:55:46 lt9630 kernel: [ 857.813951] Call Trace:
Oct 25 14:55:46 lt9630 kernel: [ 857.813985] []
KCL_DEBUG_OsDump+0xe/0x10 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814003] []
firegl_hardwareHangRecovery+0x1c/0x50 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814036] [] ?
_ZN4Asic9WaitUntil15ResetASICIfHungEv+0x9/0x10 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814068] [] ?
_ZN4Asic9WaitUntil15WaitForCompleteEv+0x6c/0xb0 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814099] [] ?
_ZN15ExecutableUnits10CPRingIdleE15idle_WaitMethod12_QS_CP_RING_+0xe4$
Oct 25 14:55:46 lt9630 kernel: [ 857.814127] [] ?
_ZN10CMMSurfaceD1Ev+0xcb/0xe0 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814158] [] ?
_ZN15ExecutableUnits7PM4idleE15idle_WaitMethod+0x4b/0x90 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814187] [] ?
_ZN15QS_PRIVATE_CORE9QsPM4idleE15idle_WaitMethod+0x31/0x60 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814215] [] ?
_ZN10QS_PRIVATE11synchronizeEv+0x2a/0x30 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814243] [] ?
_Z8uCWDDEQCmjjPvjS_+0x3b5/0x10c0 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814246] [] ?
down+0x2e/0x50
Oct 25 14:55:46 lt9630 kernel: [ 857.814266] [] ?
firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814285] [] ?
firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814288] [] ?
security_capable+0x2a/0x30
Oct 25 14:55:46 lt9630 kernel: [ 857.814306] [] ?
firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814322] [] ?
firegl_ioctl+0x1e8/0x250 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814333] [] ?
ip_firegl_unlocked_ioctl+0xe/0x20 [fglrx]
Oct 25 14:55:46 lt9630 kernel: [ 857.814335] [] ?
do_vfs_ioctl+0x8a/0x340
Oct 25 14:55:46 lt9630 kernel: [ 857.814338] [] ?
vfs_read+0x10d/0x180
Oct 25 14:55:46 lt9630 kernel: [ 857.814339] [] ?
sys_ioctl+0x91/0xa0
Oct 25 14:55:46 lt9630 kernel: [ 857.814342] [] ?
system_call_fastpath+0x16/0x1b
Oct 25 14:55:46 lt9630 kernel: [ 857.814345] pubdev:0xa02fd600, num of
device:1 , name:fglrx, major 8, minor 88.
Oct 25 14:55:46 lt9630 kernel: [ 857.814346] device 0 : 0x88019b85 .

Oct 25 14:55:46 lt9630 kernel: [ 857.814345] pubdev:0xa02fd600, num of
device:1 , name:fglrx, major 8, minor 88.
Oct 25 14:55:46 lt9630 kernel: [ 857.814346] device 0 : 0x88019b85 .
Oct 25 14:55:46 lt9630 kernel: [ 857.814348] Asic ID:0x6779, revision:0x3c,
MMIOReg:0xc90012b8.
Oct 25 14:55:46 lt9630 kernel: [ 857.814349] FB phys addr: 0xc000, MC
:0xf, Total FB size :0x4000.
Oct 25 14:55:46 lt9630 kernel: [ 857.814351] gart table MC:0xf0f8fd000,
Physical:0xcf8fd000, size:0x402000.
Oct 25 14:55:46 lt9630 kernel: [ 857.814353] mc_node :FB, total 1 zones
Oct 25 14:55:46 lt9630 kernel: [ 857.814354] MC start:0xf,
Physical:0xc000, size:0xfd0.
Oct 25 14:55:46 lt9630 kernel: [ 857.814356] Mapped heap -- Offset:0x0,
size:0xf8fd000, reference count:33, mapping count:0,
Oct 25 14:55:46 lt9630 kernel: [ 857.814357] Mapped heap -- Offset:0x0,
size:0x100, reference count:1, mapping count:0,
Oct 25 14:55:46 lt9630 kernel: [ 857.814359] Mapped heap -- Offset:0xf8fd000,
size:0x403000, reference count:1, mapping count:0,
Oct 25 14:55:46 lt9630 kernel: [ 857.814360] mc_node :INV_FB, total 1 zones
Oct 25 14:55:46 lt9630 kernel: [ 857.814362] MC start:0xf0fd0,

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Chris Wilson]

On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor buffer the X cursor code does a a)
> > > disable cursor b) update cursor image c) enable cursor cycle.
> > 
> > Notably not -intel on which the bug has been observed. And more
> > importantly, the slow downs don't seem to correlate with cursor change,
> > just cursor movement.
> > -Chris
> > 
> > -- 
> > Chris Wilson, Intel Open Source Technology Centre
> 
> It seems that the simple fix for this case (movement only) is to just
> skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
> the transitional plane helper when newfb == oldfb.  I just posted a
> small patch that makes that change (and solves the cursor lag for me).
> 
> This won't solve the case if userspace uses a different framebuffer for
> each update (while trying to update faster than the refresh rate).  Is
> there any existing userspace that behaves this way that we can test
> with?

-modesetting and say moving the cursor in/out of an xterm very fast. or
similarly with

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 5b45618..3873893 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -5182,7 +5182,6 @@ sna_cursors_init(ScreenPtr screen, struct sna *sna)
cursor_info->MaxWidth = sna->cursor.max_size;
cursor_info->MaxHeight = sna->cursor.max_size;
cursor_info->Flags = (HARDWARE_CURSOR_TRUECOLOR_AT_8BPP |
- HARDWARE_CURSOR_UPDATE_UNHIDDEN |
  HARDWARE_CURSOR_ARGB);

cursor_info->RealizeCursor = sna_realize_cursor;


-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 05/13] drm/plane-helper: Fix transitional helper kerneldocs

[Matt Roper]

drm_plane_helper_{update,disable} are not specific to primary planes;
fix some copy/paste summaries to avoid confusion.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_plane_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 0dce064..0d2068d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -492,7 +492,7 @@ out:
 }

 /**
- * drm_plane_helper_update() - Helper for primary plane update
+ * drm_plane_helper_update() - Transitional helper for plane update
  * @plane: plane object to update
  * @crtc: owning CRTC of owning plane
  * @fb: framebuffer to flip onto plane
@@ -549,7 +549,7 @@ int drm_plane_helper_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 EXPORT_SYMBOL(drm_plane_helper_update);

 /**
- * drm_plane_helper_disable() - Helper for primary plane disable
+ * drm_plane_helper_disable() - Transitional helper for plane disable
  * @plane: plane to disable
  *
  * Provides a default plane disable handler using the atomic plane update
-- 
1.8.5.1

[PATCH 04/13] drm/plane-helper: Add transitional helper for .set_plane().

[Matt Roper]

Add a transitional helper for planes' .set_property() entrypoint,
similar to what we already have for .update_plane() and
.disable_plane().  This allows drivers that are still in the process of
transitioning to implement and exercise the .atomic_set_property()
driver entrypoint that will eventually be used by atomic.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_plane_helper.c | 105 +
 include/drm/drm_plane_helper.h |   3 ++
 2 files changed, 108 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 7a5814a..0dce064 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -586,3 +586,108 @@ int drm_plane_helper_disable(struct drm_plane *plane)
return drm_plane_helper_commit(plane, plane_state, plane->fb);
 }
 EXPORT_SYMBOL(drm_plane_helper_disable);
+
+/**
+ * drm_plane_helper_set_property() - Transitional helper for property updates
+ * @plane: plane object to update
+ * @prop: property to update
+ * @val: value to set property to
+ *
+ * Provides a default plane property handler using the atomic plane update
+ * functions.  Drivers in the process of transitioning to atomic should
+ * replace their plane.set_property() entrypoint with this function and
+ * then implement the plane.atomic_set_property() entrypoint.
+ *
+ * This is useful for piecewise transitioning of a driver to the atomic 
helpers.
+ *
+ * Note that this helper assumes that no hardware programming should be
+ * performed if the plane is disabled.  When the plane is not attached to a
+ * crtc, we just swap in the validated plane state and return; there's no
+ * call to atomic_begin()/atomic_update()/atomic_flush().
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_plane_helper_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+   struct drm_plane_state *plane_state;
+   struct drm_plane_helper_funcs *plane_funcs = plane->helper_private;
+   struct drm_crtc_helper_funcs *crtc_funcs;
+   int ret;
+
+   /*
+* Drivers may not have an .atomic_set_property() handler if they have
+* no driver-specific properties, but they generally wouldn't setup a
+* .set_property() handler (pointing to this function) for the plane in
+* that case either; throw a warning since this is probably a mistake.
+*/
+   if (WARN_ON(!plane->funcs->atomic_set_property))
+   return -EINVAL;
+
+   if (plane->funcs->atomic_duplicate_state)
+   plane_state = plane->funcs->atomic_duplicate_state(plane);
+   else if (plane->state)
+   plane_state = drm_atomic_helper_plane_duplicate_state(plane);
+   else
+   plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
+   if (!plane_state)
+   return -ENOMEM;
+   plane_state->plane = plane;
+
+   /*
+* Update the state object with the new property value we want to
+* set.  If the property is not recognized as a driver-specific 
property,
+* -EINVAL will be returned here.
+*/
+   ret = plane->funcs->atomic_set_property(plane, plane_state, prop, val);
+   if (ret)
+   goto out;
+
+   /*
+* Check that the updated plane state is actually programmable (e.g.,
+* doesn't violate hardware constraints).
+*/
+   if (plane_funcs->atomic_check) {
+   ret = plane_funcs->atomic_check(plane, plane_state);
+   if (ret)
+   goto out;
+   }
+
+   /* Point of no return, commit sw state. */
+   swap(plane->state, plane_state);
+
+   /*
+* If the plane is disabled, we're done.  No hardware programming is
+* attempted when the plane is disabled.
+*/
+   if (!plane->crtc)
+   goto out;
+
+   /* Start hardware transaction to commit new state to hardware */
+   crtc_funcs = plane->crtc->helper_private;
+   if (crtc_funcs && crtc_funcs->atomic_begin)
+   crtc_funcs->atomic_begin(plane->crtc);
+   plane_funcs->atomic_update(plane, plane_state);
+   if (crtc_funcs && crtc_funcs->atomic_flush)
+   crtc_funcs->atomic_flush(plane->crtc);
+
+   /*
+* Since we're not using full atomic yet, we still need to update the 
shadow
+* property value that's managed by the DRM core since that's where the
+* property values will be read back from.
+*/
+   drm_object_property_set_value(>base, prop, val);
+
+out:
+   if (plane_state) {
+   if (plane->funcs->atomic_destroy_state)
+   plane->funcs->atomic_destroy_state(plane, plane_state);
+   else
+   drm_atomic_helper_plane_destroy_state(plane, 

[PATCH v10 3/9] ASoC: kirkwood: accept the DAI definitions from a graph of ports

[Jean-Francois Moine]

By default, both output ports 0 (I2S) and 1 (S/PDIF) are defined.
A graph of port permits to define only the really connected ports of
the board and to identify the remote ends.

Signed-off-by: Jean-Francois Moine 
---
 .../devicetree/bindings/sound/mvebu-audio.txt  | 30 
 sound/soc/kirkwood/kirkwood-i2s.c  | 41 ++
 sound/soc/kirkwood/kirkwood.h  |  3 +-
 3 files changed, 67 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt 
b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
index cb8c07c..ae81bf1 100644
--- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt
+++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
@@ -23,6 +23,19 @@ Required properties:
"internal" for the internal clock
"extclk" for the external clock

+Optional nodes:
+
+- port: one or two ports.
+  Each port must contain the following property:
+
+  - port-type: must be "i2s" or "spdif"
+
+  and the following node:
+
+  - endpoint: reference of the remote endpoint - see [1]
+
+[1] Documentation/devicetree/bindings/graph.txt
+
 Example:

 i2s1: audio-controller at b4000 {
@@ -31,4 +44,21 @@ i2s1: audio-controller at b4000 {
interrupts = <21>, <22>;
clocks = <_clk 13>;
clock-names = "internal";
+
+   port at 0 {
+   port-type = "spdif";
+   audio1_spdif0: endpoint at 0 {
+   remote-endpoint = <_out>;
+   };
+   audio1_spdif1: endpoint at 1 {
+   remote-endpoint = <_spdif>;
+   };
+   };
+   port at 1 {
+   port-type = "i2s";
+   audio1_i2s: endpoint {
+   remote-endpoint = <_i2s>;
+   };
+   };
+
 };
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c 
b/sound/soc/kirkwood/kirkwood-i2s.c
index 357f963..8e62bb8 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -466,13 +466,42 @@ static const struct snd_soc_component_driver 
kirkwood_i2s_component = {
 };

 /* create the DAIs */
-static int kirkwood_i2s_create_dais(struct kirkwood_dma_data *priv)
+static int kirkwood_i2s_create_dais(struct device_node *np,
+   struct kirkwood_dma_data *priv)
 {
-   int i, ndai, dai[2];
+   struct device_node *of_port;
+   const char *name;
+   int i, ret, ndai, dai[2];

-   ndai = 2;
-   dai[0] = 0; /* i2s(0) - spdif(1) */
-   dai[1] = 1;
+   ndai = 0;
+   if (np) {
+   for_each_child_of_node(np, of_port) {
+   if (!of_port->name ||
+of_node_cmp(of_port->name, "port") != 0)
+   continue;
+   ret = of_property_read_string(of_port,
+   "port-type",
+   );
+   if (ret)
+   continue;
+   if (strcmp(name, "i2s") == 0) {
+   dai[ndai] = 0;
+   } else if (strcmp(name, "spdif") == 0) {
+   dai[ndai] = 1;
+   } else {
+   continue;
+   }
+   if (++ndai >= 2)
+   break;
+   }
+   }
+   if (ndai == 0) {/* no DT or no port */
+   ndai = 2;
+   dai[0] = 0; /* i2s(0) - spdif(1) */
+   dai[1] = 1;
+   } else {
+   priv->is_graph = 1; /* graph of the ports */
+   }
for (i = 0; i < ndai; i++) {
memcpy(>dais[i], _i2s_dai_i2s_ext,
sizeof(priv->dais[0]));
@@ -570,7 +599,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device 
*pdev)
priv->ctl_rec |= KIRKWOOD_RECCTL_BURST_128;
}

-   ndais = kirkwood_i2s_create_dais(priv);
+   ndais = kirkwood_i2s_create_dais(np, priv);

err = snd_soc_register_component(>dev, _i2s_component,
 priv->dais, ndais);
diff --git a/sound/soc/kirkwood/kirkwood.h b/sound/soc/kirkwood/kirkwood.h
index a24d2c2..b4cbefe 100644
--- a/sound/soc/kirkwood/kirkwood.h
+++ b/sound/soc/kirkwood/kirkwood.h
@@ -141,7 +141,8 @@ struct kirkwood_dma_data {
struct snd_pcm_substream *substream_play;
struct snd_pcm_substream *substream_rec;
int irq;
-   int burst;
+   short burst;
+   short is_graph;
 };

 extern struct snd_soc_platform_driver kirkwood_soc_platform;
-- 
2.1.4

[Bug 88408] Black screen in Nuclear Dawn

[bugzilla-dae...@freedesktop.org]

IDirect3DDevice9::CreatePixelShader: shaderapi's centroid mask (0x000E)
differs from mask derived from shader name (0x001F) for shader ps-file
shadow_ps20b ps-index 0 ps-combo 0
IDirect3DDevice9::CreatePixelShader: shaderapi's centroid mask (0x00E0)
differs from mask derived from shader name (0x00C0) for shader ps-file
water_ps20b ps-index 1272 ps-combo 0
IDirect3DDevice9::CreatePixelShader: shaderapi's centroid mask (0x00E0)
differs from mask derived from shader name (0x00C0) for shader ps-file
water_ps20b ps-index 1272 ps-combo 1
IDirect3DDevice9::CreatePixelShader: shaderapi's centroid mask (0x00E0)
differs from mask derived from shader name (0x00C0) for shader ps-file
water_ps20b ps-index 20 ps-combo 0
IDirect3DDevice9::CreatePixelShadeFontconfig error:
"/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix
element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70:
non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78:
saw unknown, expected number
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(nd_linux)/version(1.0)
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Steam_SetMinidumpSteamID:  Caching Steam ID:  7656119703242 [API loaded
yes]
Steam_SetMinidumpSteamID:  Setting Steam ID:  7656119703242
Game update: AppID 17710 "Nuclear Dawn", ProcID 1108, IP 127.0.0.1:27015
warning: Unknown nb_ctl request:  4
warning: Unknown nb_ctl request:  4
warning: Unknown nb_ctl request:  4
warning: Unknown nb_ctl request:  4
warning: Unknown nb_ctl request:  4
warning: Unknown nb_ctl request:  4
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Game removed: AppID 17710 "Nuclear Dawn", ProcID 1108 
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
Installing breakpad exception handler for appid(steam)/version(1421377901)
process 983: The last reference on a connection was dropped without closing the
connection. This is a bug in an application. See dbus_connection_unref()
documentation for details.
Most likely, the application was supposed to call dbus_connection_close(),
since this is a private connection.
Requested Force create but SharedObjectMutex already created
Forced create but already created for SharedObjectEvent
Forced create but already created for SharedObjectEvent
[2015-01-19 20:27:37] Startup - updater built Jan 15 2015 18:27:06
[2015-01-19 20:27:37] Opted in to client beta 'publicbeta' via beta file
You are in the 'publicbeta' client beta.
[2015-01-19 20:27:38] Verifying installation...
[2015-01-19 20:27:38] Verification complete
[2015-01-19 20:31:30] Shutdown

As you can see, i can't do nothing with it. So i will begin building 32 bit
version of apitrace. Stay tuned.

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

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Sjoerd Simons]

On Mon, 2015-01-19 at 15:01 -0200, Gustavo Padovan wrote:
> 2015-01-19 Thierry Reding :
> 
> > On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote:
> > > Hello Thierry,
> > > 
> > > On 01/05/2015 02:50 PM, Thierry Reding wrote:
> > > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
> > > >> >
> > > >> > Ajay's series don't apply cleanly anymore because it has been a 
> > > >> > while since
> > > >> > he posted it but he can rebase on top of 3.19-rc1 once it is 
> > > >> > released and
> > > >> > re-resend.
> > > >> >
> > > >> 
> > > >> Do you have any plans to rebase this so it's ready for merging?
> > > >> 
> > > >> Thierry, Daniel, Dave - whose tree would this be best to merge through?
> > > > 
> > > > The plan is for me to take the bridge patches through the drm/panel
> > > > tree. I'm going to look at these patches again later this week but from
> > > > a very quick peek there don't seem to be any major issues left.
> > > >
> > > 
> > > I know you probably are very busy but it would be great if you can take a 
> > > look
> > > to this series to avoid another kernel release to be missed since we are 
> > > already
> > > at v3.19-rc5.
> > > 
> > > Only this version was posted 2 months ago and the first version of the 
> > > series
> > > was sent on May, 2014 so it has been on the list for almost a year now...
> > > 
> > > Tomi and Laurent had already agreed with the DT binging so I think that 
> > > we can
> > > already merge these and if there are any remaining issues, those can be 
> > > fixed
> > > during the 3.20 -rc cycle.
> > 
> > I see only a single Tested-by on this series and that seems to be with a
> > bunch of out-of-tree patches applied on top. Does this now actually work
> > applied on top of upstream? Also it seems like many people actually want
> > this to get merged but there's been no Reviewed-bys and only a single
> > Tested-by? Is that as good as it's going to get?
> 
> I've been using this series on top of exynos-drm for more than a month and it 
> works fine for me so..
> 
> Tested-by: Gustavo Padovan 

Same here, just test-booted on my snow with just these patch on top of
3.19-rc5 and got a nicely working display. 

Tested-by: Sjoerd Simons 

-- 
Sjoerd Simons 
Collabora Ltd.
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/f0d3ea45/attachment.bin>

[PATCH v10 2/9] ASoC: kirkwood: check the DAI type from the DAI name

[Jean-Francois Moine]

When the DAIs are created from a graph of ports, their types are not tied
to their ID.

Signed-off-by: Jean-Francois Moine 
---
 sound/soc/kirkwood/kirkwood-i2s.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/kirkwood/kirkwood-i2s.c 
b/sound/soc/kirkwood/kirkwood-i2s.c
index 62d9c12..357f963 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -263,7 +263,7 @@ static int kirkwood_i2s_play_trigger(struct 
snd_pcm_substream *substream,
case SNDRV_PCM_TRIGGER_START:
/* configure */
ctl = priv->ctl_play;
-   if (dai->id == 0)
+   if (dai->name[0] == 'i')
ctl &= ~KIRKWOOD_PLAYCTL_SPDIF_EN;  /* i2s */
else
ctl &= ~KIRKWOOD_PLAYCTL_I2S_EN;/* spdif */
@@ -331,7 +331,7 @@ static int kirkwood_i2s_rec_trigger(struct 
snd_pcm_substream *substream,
case SNDRV_PCM_TRIGGER_START:
/* configure */
ctl = priv->ctl_rec;
-   if (dai->id == 0)
+   if (dai->name[0] == 'i')
ctl &= ~KIRKWOOD_RECCTL_SPDIF_EN;   /* i2s */
else
ctl &= ~KIRKWOOD_RECCTL_I2S_EN; /* spdif */
-- 
2.1.4

[PATCH] drm/radeon: remove unreachable code

[Deucher, Alexander]

> -Original Message-
> From: Nicholas Mc Guire [mailto:der.herr at hofr.at]
> Sent: Monday, January 19, 2015 8:11 AM
> To: Deucher, Alexander
> Cc: Koenig, Christian; David Airlie; dri-devel at lists.freedesktop.org; 
> linux-
> kernel at vger.kernel.org; Nicholas Mc Guire
> Subject: [PATCH] drm/radeon: remove unreachable code
> 
> Signed-off-by: Nicholas Mc Guire 

NACK.  I want to leave this in place for the future.  When we support 
dynamically adjusting the disp clock we'll need to update the sclk for ds mode.

Alex

> ---
> 
> As the if (CISLAND_MINIMUM_ENGINE_CLOCK !=
> CISLAND_MINIMUM_ENGINE_CLOCK) is never
> satisfied - the entire else branch is never going to be executed and could be
> removed - provided this is not simply a bug and needs to be fixed...
> 
> Patch is against 3.19.0-rc5 -next-20150119
> 
> Patch was only compile tested with x86_64_defconfig + CONFIG_DRM=m,
> CONFIG_DRM_RADEON=m
> 
>  drivers/gpu/drm/radeon/ci_dpm.c |7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c
> index f373a81..28db529 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -3805,13 +3805,8 @@ static void
> ci_find_dpm_states_clocks_in_dpm_table(struct radeon_device *rdev,
>   break;
>   }
> 
> - if (i >= sclk_table->count) {
> + if (i >= sclk_table->count)
>   pi->need_update_smu7_dpm_table |=
> DPMTABLE_OD_UPDATE_SCLK;
> - } else {
> - /* XXX check display min clock requirements */
> - if (CISLAND_MINIMUM_ENGINE_CLOCK !=
> CISLAND_MINIMUM_ENGINE_CLOCK)
> - pi->need_update_smu7_dpm_table |=
> DPMTABLE_UPDATE_SCLK;
> - }
> 
>   for (i = 0; i < mclk_table->count; i++) {
>   if (mclk == mclk_table->dpm_levels[i].value)
> --
> 1.7.10.4

[PATCH v10 1/9] ASoC: kirkwood: dynamically build the DAI array

[Jean-Francois Moine]

This patch prepares the driver to the creation of the DAIs from a graph
of ports.

Signed-off-by: Jean-Francois Moine 
---
 sound/soc/kirkwood/kirkwood-i2s.c | 108 ++
 sound/soc/kirkwood/kirkwood.h |   1 +
 2 files changed, 40 insertions(+), 69 deletions(-)

diff --git a/sound/soc/kirkwood/kirkwood-i2s.c 
b/sound/soc/kirkwood/kirkwood-i2s.c
index def7d82..62d9c12 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -438,49 +438,8 @@ static const struct snd_soc_dai_ops kirkwood_i2s_dai_ops = 
{
.set_fmt= kirkwood_i2s_set_fmt,
 };

-static struct snd_soc_dai_driver kirkwood_i2s_dai[2] = {
-{
-   .name = "i2s",
-   .id = 0,
-   .playback = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-   SNDRV_PCM_RATE_96000,
-   .formats = KIRKWOOD_I2S_FORMATS,
-   },
-   .capture = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-   SNDRV_PCM_RATE_96000,
-   .formats = KIRKWOOD_I2S_FORMATS,
-   },
-   .ops = _i2s_dai_ops,
-},
-{
-   .name = "spdif",
-   .id = 1,
-   .playback = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-   SNDRV_PCM_RATE_96000,
-   .formats = KIRKWOOD_SPDIF_FORMATS,
-   },
-   .capture = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-   SNDRV_PCM_RATE_96000,
-   .formats = KIRKWOOD_SPDIF_FORMATS,
-   },
-   .ops = _i2s_dai_ops,
-},
-};
-
-static struct snd_soc_dai_driver kirkwood_i2s_dai_extclk[2] = {
-{
+/* DAI sample for I2S and external clock */
+static struct snd_soc_dai_driver kirkwood_i2s_dai_i2s_ext = {
.name = "i2s",
.id = 0,
.playback = {
@@ -500,42 +459,52 @@ static struct snd_soc_dai_driver 
kirkwood_i2s_dai_extclk[2] = {
.formats = KIRKWOOD_I2S_FORMATS,
},
.ops = _i2s_dai_ops,
-},
-{
-   .name = "spdif",
-   .id = 1,
-   .playback = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_CONTINUOUS,
-   .rate_min = 5512,
-   .rate_max = 192000,
-   .formats = KIRKWOOD_SPDIF_FORMATS,
-   },
-   .capture = {
-   .channels_min = 1,
-   .channels_max = 2,
-   .rates = SNDRV_PCM_RATE_CONTINUOUS,
-   .rate_min = 5512,
-   .rate_max = 192000,
-   .formats = KIRKWOOD_SPDIF_FORMATS,
-   },
-   .ops = _i2s_dai_ops,
-},
 };

 static const struct snd_soc_component_driver kirkwood_i2s_component = {
.name   = DRV_NAME,
 };

+/* create the DAIs */
+static int kirkwood_i2s_create_dais(struct kirkwood_dma_data *priv)
+{
+   int i, ndai, dai[2];
+
+   ndai = 2;
+   dai[0] = 0; /* i2s(0) - spdif(1) */
+   dai[1] = 1;
+   for (i = 0; i < ndai; i++) {
+   memcpy(>dais[i], _i2s_dai_i2s_ext,
+   sizeof(priv->dais[0]));
+   priv->dais[i].id = i;
+   if (dai[i] == 1) {
+   priv->dais[i].name = "spdif";
+   priv->dais[i].playback.formats =
+   KIRKWOOD_SPDIF_FORMATS;
+   priv->dais[i].capture.formats =
+   KIRKWOOD_SPDIF_FORMATS;
+   }
+   if (IS_ERR(priv->extclk)) {
+   priv->dais[i].playback.rates =
+   SNDRV_PCM_RATE_44100 |
+   SNDRV_PCM_RATE_48000 |
+   SNDRV_PCM_RATE_96000;
+   priv->dais[i].capture.rates =
+   SNDRV_PCM_RATE_44100 |
+   SNDRV_PCM_RATE_48000 |
+   SNDRV_PCM_RATE_96000;
+   }
+   }
+   return ndai;
+}
+
 static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 {
struct kirkwood_asoc_platform_data *data = pdev->dev.platform_data;
-   struct snd_soc_dai_driver *soc_dai = kirkwood_i2s_dai;
struct kirkwood_dma_data *priv;
struct resource *mem;
struct device_node *np = pdev->dev.of_node;
-   int err;
+   int err, ndais;

priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if 

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Javier Martinez Canillas]

Hello Thierry,

On 01/19/2015 05:30 PM, Thierry Reding wrote:
>> 
>> I know you probably are very busy but it would be great if you can take a 
>> look
>> to this series to avoid another kernel release to be missed since we are 
>> already
>> at v3.19-rc5.
>> 
>> Only this version was posted 2 months ago and the first version of the series
>> was sent on May, 2014 so it has been on the list for almost a year now...
>> 
>> Tomi and Laurent had already agreed with the DT binging so I think that we 
>> can
>> already merge these and if there are any remaining issues, those can be fixed
>> during the 3.20 -rc cycle.
> 
> I see only a single Tested-by on this series and that seems to be with a
> bunch of out-of-tree patches applied on top. Does this now actually work
> applied on top of upstream? Also it seems like many people actually want
> this to get merged but there's been no Reviewed-bys and only a single
> Tested-by? Is that as good as it's going to get?
>

Good point, I provided some feedback on an early version of the series but I'm 
not
an DRM expert so I couldn't review it in detail to provide my Reviewed-by.

I did provide my Tested-by a long time ago though but looking at the patches it
seems those were dropped so here goes again:

For the whole series on an Exynos5420 Peach Pit and an Exynos5250 Snow 
Chromebooks:

Tested-by: Javier Martinez Canillas 

> Also I think the last update was that Ajay was going to resend this
> based on v3.19-rc1 or something. Is that still going to happen?
> Otherwise I can probably try to apply as-is, but not sure how well it
> will.
>

Ajay,

Are you going to rebase and resend this series with all the provided tags? 
Gustavo
and I have a rebased branch on top of 3.19-rc5 and one of us can post your 
series if
you are not planning to do it.

Laurent and Tomi,

You said that you are OK with the DT bindings now, does that count as an 
Acked-by or
Reviewed-by for you at least for the DT bindings changes in the series?

> Thierry
> 

Best regards,
Javier

[PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Michel Dänzer]

From: Michel Dänzer 

If the image size would ever read as 0, pci_get_rom_size could keep
processing the same image over and over again.

Reported-by: Federico 
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---

v2:
* Use unsigned instead of u16 for the local length variable (not sure if
  the multiplication by 512 could overflow otherwise)
* Integrate length condition into while statement
* Add stable tag

 drivers/pci/rom.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index f955edb..eb0ad53 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
*rom, size_t size)
 {
void __iomem *image;
int last_image;
+   unsigned length;

image = rom;
do {
@@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
*rom, size_t size)
if (readb(pds + 3) != 'R')
break;
last_image = readb(pds + 21) & 0x80;
-   /* this length is reliable */
-   image += readw(pds + 16) * 512;
-   } while (!last_image);
+   length = readw(pds + 16);
+   image += length * 512;
+   } while (length && !last_image);

/* never return a size larger than the PCI resource window */
/* there are known ROMs that get the size wrong */
-- 
2.1.4

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Thierry Reding]

On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote:
> Hello Thierry,
> 
> On 01/05/2015 02:50 PM, Thierry Reding wrote:
> > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
> >> >
> >> > Ajay's series don't apply cleanly anymore because it has been a while 
> >> > since
> >> > he posted it but he can rebase on top of 3.19-rc1 once it is released and
> >> > re-resend.
> >> >
> >> 
> >> Do you have any plans to rebase this so it's ready for merging?
> >> 
> >> Thierry, Daniel, Dave - whose tree would this be best to merge through?
> > 
> > The plan is for me to take the bridge patches through the drm/panel
> > tree. I'm going to look at these patches again later this week but from
> > a very quick peek there don't seem to be any major issues left.
> >
> 
> I know you probably are very busy but it would be great if you can take a look
> to this series to avoid another kernel release to be missed since we are 
> already
> at v3.19-rc5.
> 
> Only this version was posted 2 months ago and the first version of the series
> was sent on May, 2014 so it has been on the list for almost a year now...
> 
> Tomi and Laurent had already agreed with the DT binging so I think that we can
> already merge these and if there are any remaining issues, those can be fixed
> during the 3.20 -rc cycle.

I see only a single Tested-by on this series and that seems to be with a
bunch of out-of-tree patches applied on top. Does this now actually work
applied on top of upstream? Also it seems like many people actually want
this to get merged but there's been no Reviewed-bys and only a single
Tested-by? Is that as good as it's going to get?

Also I think the last update was that Ajay was going to resend this
based on v3.19-rc1 or something. Is that still going to happen?
Otherwise I can probably try to apply as-is, but not sure how well it
will.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/bb07cee3/attachment.sig>

[PATCH v3 3/3] ARM: dts: add Panel device support for exynos3250-rinato

[Hyungwon Hwang]

From: Inki Dae 

This patch adds MIPI-DSI and MIPI-DSI based S6E63J0X03 AMOLED panel
device nodes for Exynos3250 Rinato board.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Acked-by: Kyungmin Park 
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary DT properties of flip-*
 arch/arm/boot/dts/exynos3250-rinato.dts | 116 
 1 file changed, 116 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 8b033b5..659068f 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,122 @@
};
 };

+_0 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clock-frequency = <2400>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 1 {
+   reg = <1>;
+
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   samsung,burst-clock-frequency = <25000>;
+   samsung,esc-clock-frequency = <2000>;
+   };
+   };
+   };
+
+   panel at 0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 0>;
+   te-gpios = < 6 0>;
+   power-on-delay= <30>;
+   power-off-delay= <120>;
+   reset-delay = <5>;
+   init-delay = <100>;
+   panel-width-mm = <29>;
+   panel-height-mm = <29>;
+
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <320>;
+   vactive = <320>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <150>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+
+   port {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
+_0 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clock-frequency = <2400>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 1 {
+   reg = <1>;
+
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   samsung,burst-clock-frequency = <25000>;
+   samsung,esc-clock-frequency = <2000>;
+   };
+   };
+   };
+
+   panel at 0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 0>;
+   te-gpios = < 6 0>;
+   power-on-delay= <30>;
+   power-off-delay= <120>;
+   reset-delay = <5>;
+   init-delay = <100>;
+   panel-width-mm = <29>;
+   panel-height-mm = <29>;
+
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <320>;
+   vactive = <320>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <150>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+
+   port {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
  {
status = "okay";

--
1.9.1

[PATCH v3 2/3] drm/panel: add s6e63j0x03 LCD panel driver

[Hyungwon Hwang]

From: Inki Dae 

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63-inch physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Acked-by: Kyungmin Park 
---
Changes for v2:
- Change the gamma table to 2-dimensional array
- Change the way to make index for brightness
- Make command functions to an array so that it can be called simply
- Change command id for reading device ID
- Change the way to handle the error condition
- Remove power variable, and use the same name variable in bl_dev
- Add the state FB_BLANK_NORMAL to represent the state which the panel
is working but blanked
- Miscellaneous changes to increase the readability and follow the
  coding-style standard
Changes for v3:
- Add DT binding documentation
- Add the code getting DT properties of 'panel-width-mm' and 'panel-height-mm'
- Remove the code getting unnecessary DT properties flip-*
 .../bindings/panel/samsung,s6e63j0x03.txt  |  55 +++
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-s6e63j0x03.c   | 546 +
 4 files changed, 608 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..f8215e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,55 @@
+Samsung S6E63J0X03 1.63" 320x320 TFT LCD panel
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio 
pin
+
+Optional properties:
+  - display-timings: timings for the connected panel as described by [1]
+  - power-on-delay: delay after turning regulators on [ms]
+  - power-off-delay: delay after turning regulators off [ms]
+  - reset-delay: delay after reset sequence [ms]
+  - panel-width-mm: physical panel width [mm]
+  - panel-height-mm: physical panel height [mm]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+panel at 0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 0>;
+   te-gpios = < 6 0>;
+   power-on-delay= <30>;
+   power-off-delay= <120>;
+   reset-delay = <5>;
+   init-delay = <100>;
+   panel-width-mm = <29>;
+   panel-height-mm = <29>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <320>;
+   vactive = <320>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <150>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+};
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3df9b9b..8fa7610 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,4 +46,10 @@ config DRM_PANEL_S6E3HA2
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E63J0X03
+   tristate "S6E63J0X03 DSI video mode panel"
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 16ff312..9054da1 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_S6E3HA2) += panel-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_S6E63J0X03) += panel-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
new file mode 100644
index 000..51cf1f6
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
@@ -0,0 +1,546 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * 

[PATCH v3 1/3] ARM: dts: add fimd device support for exynos3250-rinato

[Hyungwon Hwang]

From: Inki Dae 

This patch adds fimd device node which is a display controller
for Exynos3250 Rinato board.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Acked-by: Kyungmin Park 
---
Changes for v2:
- None
Changes for v3:
- None
 arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 6ac1e4e..8b033b5 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,17 @@
};
 };

+ {
+   status = "okay";
+
+   i80-if-timings {
+   cs-setup = <0>;
+   wr-setup = <0>;
+   wr-act = <1>;
+   wr-hold = <0>;
+   };
+};
+
 _0 {
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1

[PATCH 01/29] drm/exynos/fimd: only finish pageflip if START == START_S

[Daniel Stone]

Hi,

On 12 January 2015 at 21:13, Gustavo Padovan  wrote:

> 2014-12-30 Inki Dae :
> > On 2014년 12월 18일 22:58, Gustavo Padovan wrote:
> > > +* This works around a race between a page_flip request and the
> latency
> > > +* between vblank interrupt and this irq_handler:
> > > +*   => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts
> irq
> > > +*   | => fimd_win_commit(0) writes new BUF_START[0]
> > > +*   |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> > > +*   => fimd_irq_handler()
> > > +*   exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> > > +*   and unmaps "old" fb
> > > +*   ==> but, since BUF_START_S[0] still points to that "old" fb...
> > > +*   ==> FIMD iommu fault
> > > +*/
> > > +   start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
> > > +   start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
> > > +   if (start == start_s)
> > > exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
> > And what if 'start_s' has a value different from one of 'start'? Is it
> > ok to skip finish_pageflip request this time? Shouldn't it ensure to
> > wait for that until 'start_s' has a value same as one of 'start'?
>
> I think it is okay to skip finish_pageflip, but we could return directly
> if they are different, so we keep the wait_vsync_queue running until the
> next
> irq happens or it timeouts. How does this look to you?
>

Right, you'd need to keep the vblank IRQ alive until start == start_s.

As an aside, there is currently some refcounting code (e.g. in the DPMS off
and/or framebuffer final-unref paths if I remember correctly) which assumes
that waiting one vblank is enough to be able to unpin resources. Obviously,
as this patch shows, this is not actually true. This patch doesn't make
this any better or worse; just something to bear in mind. (I have WIP code
which fixes this.)

Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/295c8d95/attachment.html>

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Gustavo Padovan]

2015-01-19 Thierry Reding :

> On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote:
> > Hello Thierry,
> > 
> > On 01/05/2015 02:50 PM, Thierry Reding wrote:
> > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
> > >> >
> > >> > Ajay's series don't apply cleanly anymore because it has been a while 
> > >> > since
> > >> > he posted it but he can rebase on top of 3.19-rc1 once it is released 
> > >> > and
> > >> > re-resend.
> > >> >
> > >> 
> > >> Do you have any plans to rebase this so it's ready for merging?
> > >> 
> > >> Thierry, Daniel, Dave - whose tree would this be best to merge through?
> > > 
> > > The plan is for me to take the bridge patches through the drm/panel
> > > tree. I'm going to look at these patches again later this week but from
> > > a very quick peek there don't seem to be any major issues left.
> > >
> > 
> > I know you probably are very busy but it would be great if you can take a 
> > look
> > to this series to avoid another kernel release to be missed since we are 
> > already
> > at v3.19-rc5.
> > 
> > Only this version was posted 2 months ago and the first version of the 
> > series
> > was sent on May, 2014 so it has been on the list for almost a year now...
> > 
> > Tomi and Laurent had already agreed with the DT binging so I think that we 
> > can
> > already merge these and if there are any remaining issues, those can be 
> > fixed
> > during the 3.20 -rc cycle.
> 
> I see only a single Tested-by on this series and that seems to be with a
> bunch of out-of-tree patches applied on top. Does this now actually work
> applied on top of upstream? Also it seems like many people actually want
> this to get merged but there's been no Reviewed-bys and only a single
> Tested-by? Is that as good as it's going to get?

I've been using this series on top of exynos-drm for more than a month and it 
works fine for me so..

Tested-by: Gustavo Padovan 

Gustavo

[PATCH 1/2] of: Add vendor prefix for Shanghai AVIC Optoelectronics Co., Ltd.

[Thierry Reding]

On Thu, Dec 18, 2014 at 04:43:42PM +0100, Philipp Zabel wrote:
> Shanghai AVIC Optoelectronics Co., Ltd. is a subsidiary of Tianma
> Microelectronics Co., Ltd. and designs and manufactures TFT LCDs.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Series applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/8f16582d/attachment.sig>

[PATCH v2] dri2: Reuse unused flags in GetBuffers protocol to pass last SBC

[Chris Wilson]

Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
when the current back buffer was defined. As this may require ddx
support, only set the value if enabled by the ddx and report the new
semantics via a DRI2GetParam request.

Signed-off-by: Chris Wilson 
---
 configure.ac   |  2 +-
 hw/xfree86/dri2/dri2.c | 25 +
 hw/xfree86/dri2/dri2.h |  1 +
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index b593fc7..e49c35e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -768,7 +768,7 @@ RECORDPROTO="recordproto >= 1.13.99.1"
 SCRNSAVERPROTO="scrnsaverproto >= 1.1"
 RESOURCEPROTO="resourceproto >= 1.2.0"
 DRIPROTO="xf86driproto >= 2.1.0"
-DRI2PROTO="dri2proto >= 2.8"
+DRI2PROTO="dri2proto >= 2.9"
 DRI3PROTO="dri3proto >= 1.0"
 XINERAMAPROTO="xineramaproto"
 BIGFONTPROTO="xf86bigfontproto >= 1.2.0"
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 2c0367e..d70a632 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -49,6 +49,8 @@
 #include "damage.h"
 #include "xf86.h"

+#include  /* for parameter names */
+
 CARD8 dri2_major;   /* version of DRI2 supported by DDX */
 CARD8 dri2_minor;

@@ -115,6 +117,7 @@ typedef struct _DRI2Screen {
 unsigned int lastSequence;
 int prime_id;
 int scheduleSwap0;
+int bufferAge;

 DRI2CreateBufferProcPtr CreateBuffer;
 DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1117,6 +1120,9 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
 return BadDrawable;
 }

+if (ds->bufferAge)
+pSrcBuffer->flags = *swap_target;
+
 /* Old DDX or PRIME, just blit */
 if (!ds->scheduleSwap0 || pPriv->prime_id) {
 BoxRec box;
@@ -1562,6 +1568,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)

 if (info->version >= 10) {
 ds->scheduleSwap0 = info->scheduleSwap0;
+ds->bufferAge = info->bufferAge;
 }

 /*
@@ -1684,10 +1691,20 @@ DRI2GetParam(ClientPtr client,

 switch (high_byte) {
 case 0:
-/* Parameter names whose high_byte is 0 are reserved for the X
- * server. The server currently recognizes no parameters.
- */
-goto not_recognized;
+   /* Parameter names whose high_byte is 0 are reserved for the X
+* server.
+*/
+   switch (param) {
+   case DRI2ParamXHasBufferAge:
+   *value = ds->bufferAge;
+   break;
+   default:
+   goto not_recognized;
+   }
+
+   *is_param_recognized = TRUE;
+   return Success;
+
 case 1:
 /* Parameter names whose high byte is 1 are reserved for the DDX. */
 if (ds->GetParam)
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1cf4288..e76f7a8 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -255,6 +255,7 @@ typedef struct {

 /* added in version 10 */
 int scheduleSwap0;
+int bufferAge;
 } DRI2InfoRec, *DRI2InfoPtr;

 extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
-- 
2.1.4

[xorg 3/3] dri2: Reuse unused flags in GetBuffers protocol to pass last SBC

[Chris Wilson]

On Mon, Jan 19, 2015 at 11:00:40AM +, Chris Wilson wrote:
> @@ -1104,6 +1107,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
> CARD64 target_msc,
>   * it as early as possible, just to be sure.
>   */
>  *swap_target = pPriv->swap_count + pPriv->swapsPending + 1;
> +if (ds->bufferAge)
> +pSrcBuffer->flags = *swap_target;

I made the cardinal sin of trying to tidy the patch up at the last
moment and moved this hunk before the definition of pSrcBuffer.

Sighs.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/radeon: remove unreachable code

[Nicholas Mc Guire]

Signed-off-by: Nicholas Mc Guire 
---

As the if (CISLAND_MINIMUM_ENGINE_CLOCK != CISLAND_MINIMUM_ENGINE_CLOCK) is 
never
satisfied - the entire else branch is never going to be executed and could be 
removed - provided this is not simply a bug and needs to be fixed...

Patch is against 3.19.0-rc5 -next-20150119

Patch was only compile tested with x86_64_defconfig + CONFIG_DRM=m,
CONFIG_DRM_RADEON=m

 drivers/gpu/drm/radeon/ci_dpm.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index f373a81..28db529 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3805,13 +3805,8 @@ static void 
ci_find_dpm_states_clocks_in_dpm_table(struct radeon_device *rdev,
break;
}

-   if (i >= sclk_table->count) {
+   if (i >= sclk_table->count)
pi->need_update_smu7_dpm_table |= DPMTABLE_OD_UPDATE_SCLK;
-   } else {
-   /* XXX check display min clock requirements */
-   if (CISLAND_MINIMUM_ENGINE_CLOCK != 
CISLAND_MINIMUM_ENGINE_CLOCK)
-   pi->need_update_smu7_dpm_table |= DPMTABLE_UPDATE_SCLK;
-   }

for (i = 0; i < mclk_table->count; i++) {
if (mclk == mclk_table->dpm_levels[i].value)
-- 
1.7.10.4

[PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Alex Deucher]

On Mon, Jan 19, 2015 at 3:53 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> If the image size would ever read as 0, pci_get_rom_size could keep
> processing the same image over and over again.
>
> Reported-by: Federico 
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>
> v2:
> * Use unsigned instead of u16 for the local length variable (not sure if
>   the multiplication by 512 could overflow otherwise)
> * Integrate length condition into while statement
> * Add stable tag
>
>  drivers/pci/rom.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
> index f955edb..eb0ad53 100644
> --- a/drivers/pci/rom.c
> +++ b/drivers/pci/rom.c
> @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
> *rom, size_t size)
>  {
> void __iomem *image;
> int last_image;
> +   unsigned length;
>
> image = rom;
> do {
> @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
> *rom, size_t size)
> if (readb(pds + 3) != 'R')
> break;
> last_image = readb(pds + 21) & 0x80;
> -   /* this length is reliable */
> -   image += readw(pds + 16) * 512;
> -   } while (!last_image);
> +   length = readw(pds + 16);
> +   image += length * 512;
> +   } while (length && !last_image);
>
> /* never return a size larger than the PCI resource window */
> /* there are known ROMs that get the size wrong */
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Ville Syrjälä]

On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> On 19/01/2015 10:08, Ville Syrjälä wrote:
> > On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> >> Matt, all,
> >>
> >> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> >> very unusual way, as if it has a lot of inertia.  It will lag behind and
> >> then overshoot the expected position.
> >>
> >> I reproduced this bug on all my machines which use the drm/i915 drivers
> >> and it affects all forms of mouse pointers including both touchpads and
> >> usb mice.  The patch is present in linux-next 20150116.
> >>
> >>commit ea2c67bb4affa84080c616920f3899f123786e56
> >>Author: Matt Roper 
> >>Date:   Tue Dec 23 10:41:52 2014 -0800
> >>
> >>drm/i915: Move to atomic plane helpers (v9)
> > I guess this is caused by the atomic code refusing to update the plane
> > more than once per vrefresh. So we need to allow the fps>vrefresh rate
> > case to remove the regression.
> >
> > The old cursor code had basically a gross hack to allow this. It just
> > unpinned the old fb before the display engine was done with it, and
> > _after_ unpinning it flipped to the new buffer (with the obvious extra
> > delay of the flip happening on the next vblank). So there was no
> > guarantee the old buffer was still around (or had the correct content)
> > while the display engine was still scanning it out. So to fix this
> > properly we need a vblank worker of some sort.
> >
> > The other issues we nee to know which fb is being scanned out at which
> > point to unpin the correct old buffer. For that we can use the hardware
> > frame counter. We could use some other mechanims too (SURFLIVE, flip
> > counter etc.) but the frame counter is the most ubiqitious method we
> > have.
> >
> > The one extra problem is gen2 doesn't have even the frame counter, so
> > some extra care would be needed there. I'm thinking for gen2 we might
> > allow the driver to call into the vblank core code to update the cooked
> > counter at any time based on the scanline counter and monotonic timestamp.
> > That combined with the vblank evade mechanism should make reasonably sure
> > we have an up to date notion of which frame is currently getting scanned
> > out.
> >
> > We need the extra call into the vblank core since just after the vblank
> > start, the vblank interrupt handler may not have executed yet (especially
> > since gen2 vblank irq fires actually at the frame start which is a delayed
> > version of the vblank start, even though the flip happes at vblank start).
> > So we need an explicit call to make sure the cooked counter is already
> > updated before the irq handler has executed. I have some changes lined
> > up for the vblank code which I think could help make sure he extra call
> > won't increment the counter spuriously, but I have to clean those up a
> > bit before sending them out.
> >
> There's also an issue in (most) X drivers which exaberates this issues: 
> When changing the cursor buffer the X cursor code does a a) disable 
> cursor b) update cursor image c) enable cursor cycle. With latest 
> upstream we /should/ be able to not block for just moving the cursor 
> though when nothing crazy happens. Checking for that would be good.
> 
> For the real thing: Rob Clark also noticed this on msm with his atomic, 
> I think we need a hint flag (only used internally) so that the 
> legacy2atomic helpers and the driver core can correctly pass around 
> semantics and we could recover the optimization. As long as we don't 
> allow this hint flag to be set by userspace we could just completely 
> drop the vblank wait - that would be buggy, but so is the old legacy 
> implementation.

Yeah, I suppose some kind of quick kludge to restore the old behaviour
would an acceptable short term solution. And as long as it's not visible
to the outside world, we can replace it anytime with a more robust
solution.

-- 
Ville Syrjälä
Intel OTC

[Bug 91551] nouveau HDMI audio regression

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=91551

--- Comment #1 from dura  ---
Created attachment 163821
  --> https://bugzilla.kernel.org/attachment.cgi?id=163821=edit
eld with bogus nv50_display.c

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 91551] New: nouveau HDMI audio regression

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=91551

Bug ID: 91551
   Summary: nouveau HDMI audio regression
   Product: Drivers
   Version: 2.5
Kernel Version: 3.18.2
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: dura at duradsl.duckdns.org
Regression: No

Created attachment 163811
  --> https://bugzilla.kernel.org/attachment.cgi?id=163811=edit
patch for kernel 3.18.2

Multichannel LPCM HDMI audio no longer works on my Nvidia GTX 570. HDMI audio
is limited to stereo. The culprit is this commit:
drm/gt214-/kms: fix hda eld regression
d889c52427d48c05f163f2f39b2cfc12e17e5266
Reverting this commit with the attached patch fixes the problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Daniel Vetter]

On 19/01/2015 10:08, Ville Syrjälä wrote:
> On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
>> Matt, all,
>>
>> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
>> very unusual way, as if it has a lot of inertia.  It will lag behind and
>> then overshoot the expected position.
>>
>> I reproduced this bug on all my machines which use the drm/i915 drivers
>> and it affects all forms of mouse pointers including both touchpads and
>> usb mice.  The patch is present in linux-next 20150116.
>>
>>commit ea2c67bb4affa84080c616920f3899f123786e56
>>Author: Matt Roper 
>>Date:   Tue Dec 23 10:41:52 2014 -0800
>>
>>drm/i915: Move to atomic plane helpers (v9)
> I guess this is caused by the atomic code refusing to update the plane
> more than once per vrefresh. So we need to allow the fps>vrefresh rate
> case to remove the regression.
>
> The old cursor code had basically a gross hack to allow this. It just
> unpinned the old fb before the display engine was done with it, and
> _after_ unpinning it flipped to the new buffer (with the obvious extra
> delay of the flip happening on the next vblank). So there was no
> guarantee the old buffer was still around (or had the correct content)
> while the display engine was still scanning it out. So to fix this
> properly we need a vblank worker of some sort.
>
> The other issues we nee to know which fb is being scanned out at which
> point to unpin the correct old buffer. For that we can use the hardware
> frame counter. We could use some other mechanims too (SURFLIVE, flip
> counter etc.) but the frame counter is the most ubiqitious method we
> have.
>
> The one extra problem is gen2 doesn't have even the frame counter, so
> some extra care would be needed there. I'm thinking for gen2 we might
> allow the driver to call into the vblank core code to update the cooked
> counter at any time based on the scanline counter and monotonic timestamp.
> That combined with the vblank evade mechanism should make reasonably sure
> we have an up to date notion of which frame is currently getting scanned
> out.
>
> We need the extra call into the vblank core since just after the vblank
> start, the vblank interrupt handler may not have executed yet (especially
> since gen2 vblank irq fires actually at the frame start which is a delayed
> version of the vblank start, even though the flip happes at vblank start).
> So we need an explicit call to make sure the cooked counter is already
> updated before the irq handler has executed. I have some changes lined
> up for the vblank code which I think could help make sure he extra call
> won't increment the counter spuriously, but I have to clean those up a
> bit before sending them out.
>
There's also an issue in (most) X drivers which exaberates this issues: 
When changing the cursor buffer the X cursor code does a a) disable 
cursor b) update cursor image c) enable cursor cycle. With latest 
upstream we /should/ be able to not block for just moving the cursor 
though when nothing crazy happens. Checking for that would be good.

For the real thing: Rob Clark also noticed this on msm with his atomic, 
I think we need a hint flag (only used internally) so that the 
legacy2atomic helpers and the driver core can correctly pass around 
semantics and we could recover the optimization. As long as we don't 
allow this hint flag to be set by userspace we could just completely 
drop the vblank wait - that would be buggy, but so is the old legacy 
implementation.
-Daniel
Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: Badenerstrasse 549, 8048 Zurich, Switzerland

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

[bugzilla-dae...@freedesktop.org]

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

--- Comment #21 from Arthur Marsh  ---
Created attachment 112458
  --> https://bugs.freedesktop.org/attachment.cgi?id=112458=edit
2015011922dmesg.txt - lockup with 3.19.0-rc5 and 848x480 resolution video

First lock-up with lower than 720p resolution video playback

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

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Javier Martinez Canillas]

Hello Thierry,

On 01/05/2015 02:50 PM, Thierry Reding wrote:
> On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
>> >
>> > Ajay's series don't apply cleanly anymore because it has been a while since
>> > he posted it but he can rebase on top of 3.19-rc1 once it is released and
>> > re-resend.
>> >
>> 
>> Do you have any plans to rebase this so it's ready for merging?
>> 
>> Thierry, Daniel, Dave - whose tree would this be best to merge through?
> 
> The plan is for me to take the bridge patches through the drm/panel
> tree. I'm going to look at these patches again later this week but from
> a very quick peek there don't seem to be any major issues left.
>

I know you probably are very busy but it would be great if you can take a look
to this series to avoid another kernel release to be missed since we are already
at v3.19-rc5.

Only this version was posted 2 months ago and the first version of the series
was sent on May, 2014 so it has been on the list for almost a year now...

Tomi and Laurent had already agreed with the DT binging so I think that we can
already merge these and if there are any remaining issues, those can be fixed
during the 3.20 -rc cycle.

> Thierry
>

Thanks a lot and best regards,
Javier

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Ville Syrjälä]

On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> Matt, all,
> 
> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> very unusual way, as if it has a lot of inertia.  It will lag behind and
> then overshoot the expected position.
> 
> I reproduced this bug on all my machines which use the drm/i915 drivers
> and it affects all forms of mouse pointers including both touchpads and
> usb mice.  The patch is present in linux-next 20150116.
> 
>   commit ea2c67bb4affa84080c616920f3899f123786e56
>   Author: Matt Roper 
>   Date:   Tue Dec 23 10:41:52 2014 -0800
>   
>   drm/i915: Move to atomic plane helpers (v9)

I guess this is caused by the atomic code refusing to update the plane
more than once per vrefresh. So we need to allow the fps>vrefresh rate
case to remove the regression.

The old cursor code had basically a gross hack to allow this. It just
unpinned the old fb before the display engine was done with it, and
_after_ unpinning it flipped to the new buffer (with the obvious extra
delay of the flip happening on the next vblank). So there was no
guarantee the old buffer was still around (or had the correct content)
while the display engine was still scanning it out. So to fix this
properly we need a vblank worker of some sort.

The other issues we nee to know which fb is being scanned out at which
point to unpin the correct old buffer. For that we can use the hardware
frame counter. We could use some other mechanims too (SURFLIVE, flip
counter etc.) but the frame counter is the most ubiqitious method we
have.

The one extra problem is gen2 doesn't have even the frame counter, so
some extra care would be needed there. I'm thinking for gen2 we might
allow the driver to call into the vblank core code to update the cooked
counter at any time based on the scanline counter and monotonic timestamp.
That combined with the vblank evade mechanism should make reasonably sure
we have an up to date notion of which frame is currently getting scanned
out.

We need the extra call into the vblank core since just after the vblank
start, the vblank interrupt handler may not have executed yet (especially
since gen2 vblank irq fires actually at the frame start which is a delayed
version of the vblank start, even though the flip happes at vblank start).
So we need an explicit call to make sure the cooked counter is already
updated before the irq handler has executed. I have some changes lined
up for the vblank code which I think could help make sure he extra call
won't increment the counter spuriously, but I have to clean those up a
bit before sending them out.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Chris Wilson]

On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> There's also an issue in (most) X drivers which exaberates this
> issues: When changing the cursor buffer the X cursor code does a a)
> disable cursor b) update cursor image c) enable cursor cycle.

Notably not -intel on which the bug has been observed. And more
importantly, the slow downs don't seem to correlate with cursor change,
just cursor movement.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[mesa 9/9] glx/dri2: Implement getBufferAge

[Chris Wilson]

Within the DRI2GetBuffers return packet there is a 4-byte field that is
currently unused by any driver, i.e. flags. With the co-operation of a
suitably modified X server, we can pass the last SBC on which the buffer
was defined (i.e. the last SwapBuffers for which it was used) and 0 if
it is fresh (with a slight loss of precision). We can then compare the
flags field of the DRIBuffer against the current swap buffers count and
so compute the age of the back buffer (thus satisfying
GLX_EXT_buffer_age).

As we reuse a driver specific field within the DRI2GetBuffers packet, we
first query whether the X/DDX are ready to supply the new value using a
DRI2GetParam request.

Another caveat is that we need to complete the SwapBuffers/GetBuffers
roundtrip before reporting the back buffer age so that it tallies
against the buffer used for rendering. As with all things X, there is a
race between the query and the rendering where the buffer may be
invalidated by the server. However, for the primary usecase (that of a
compositing manager), the DRI2Drawable is only accessible to a single
client mitigating the impact of the issue.

Signed-off-by: Chris Wilson 
---
 configure.ac   |  2 +-
 src/glx/dri2_glx.c | 65 ++
 2 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 870435c..ca1da86 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,7 +65,7 @@ LIBDRM_INTEL_REQUIRED=2.4.52
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
 LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
 LIBDRM_FREEDRENO_REQUIRED=2.4.57
-DRI2PROTO_REQUIRED=2.6
+DRI2PROTO_REQUIRED=2.9
 DRI3PROTO_REQUIRED=1.0
 PRESENTPROTO_REQUIRED=1.0
 LIBUDEV_REQUIRED=151
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 0577804..b43f115 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -917,6 +917,67 @@ dri2GetBuffersWithFormat(__DRIdrawable * driDrawable,
 }

 static int
+dri2HasBufferAge(int screen, struct glx_display * priv)
+{
+   const struct dri2_display *const pdp =
+  (struct dri2_display *)priv->dri2Display;
+   CARD64 value;
+
+   if (pdp->driMajor <= 1 && pdp->driMinor < 4)
+  return 0;
+
+   value = 0;
+   if (!DRI2GetParam(priv->dpy, RootWindow(priv->dpy, screen),
+ DRI2ParamXHasBufferAge, ))
+  return 0;
+
+   return value;
+}
+
+static int
+dri2GetBufferAge(__GLXDRIdrawable *pdraw)
+{
+   struct dri2_drawable *priv = (struct dri2_drawable *) pdraw;
+   int i, age = 0;
+
+   if (priv->swap_pending) {
+  unsigned int attachments[5];
+  DRI2Buffer *buffers;
+
+  for (i = 0; i < priv->bufferCount; i++)
+  attachments[i] = priv->buffers[i].attachment;
+
+  buffers = DRI2GetBuffers(priv->base.psc->dpy, priv->base.xDrawable,
+   >width, >height,
+   attachments, i, );
+  if (buffers == NULL)
+  return 0;
+
+  process_buffers(priv, buffers, i);
+  free(buffers);
+
+  dri2XcbSwapBuffersComplete(priv);
+   }
+
+   if (!priv->have_back)
+  return 0;
+
+   for (i = 0; i < priv->bufferCount; i++) {
+  if (priv->buffers[i].attachment != __DRI_BUFFER_BACK_LEFT)
+  continue;
+
+  if (priv->buffers[i].flags == 0)
+  continue;
+
+  age = priv->last_swap_sbc - priv->buffers[i].flags + 1;
+  if (age < 0)
+  age = 0;
+   }
+
+   return age;
+}
+
+static int
 dri2SetSwapInterval(__GLXDRIdrawable *pdraw, int interval)
 {
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
@@ -1290,6 +1351,10 @@ dri2CreateScreen(int screen, struct glx_display * priv)
psp->setSwapInterval = NULL;
psp->getSwapInterval = NULL;
psp->getBufferAge = NULL;
+   if (dri2HasBufferAge(screen, priv)) {
+  psp->getBufferAge = dri2GetBufferAge;
+  __glXEnableDirectExtension(>base, "GLX_EXT_buffer_age");
+   }

if (pdp->driMinor >= 2) {
   psp->getDrawableMSC = dri2DrawableGetMSC;
-- 
2.1.4

[mesa 8/9] glx/dri2: Move the wait after SwapBuffers into the next GetBuffers

[Chris Wilson]

As the SBC from the reply from SwapBuffers is not used immediately and
can be easily determined by counting the new of SwapBuffers requests
made by the client, we can defer the synchronisation point to the
pending GetBuffers round trip. (We force the invalidation event in order
to require the GetBuffers round trip - we know that all X servers will
send the invalidation after SwapBuffers and that invalidation will
arrive before the SwapBuffers reply, so no extra roundtrips are forced.)

An important side-effect is demonstrated in the next patch where we can
detect when the buffers are stale before querying properties.

Signed-off-by: Chris Wilson 
---
 src/glx/dri2_glx.c | 73 --
 1 file changed, 38 insertions(+), 35 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 462d560..0577804 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -93,6 +93,10 @@ struct dri2_drawable
int have_back;
int have_fake_front;
int swap_interval;
+   int swap_pending;
+
+   xcb_dri2_swap_buffers_cookie_t swap_buffers_cookie;
+   int64_t last_swap_sbc;

uint64_t previous_time;
unsigned frames;
@@ -778,50 +782,51 @@ static void show_fps(struct dri2_drawable *draw)
}
 }

-static int64_t
-dri2XcbSwapBuffers(Display *dpy,
-  __GLXDRIdrawable *pdraw,
+static void
+dri2XcbSwapBuffers(struct dri2_drawable *priv,
   int64_t target_msc,
   int64_t divisor,
   int64_t remainder)
 {
-   xcb_dri2_swap_buffers_cookie_t swap_buffers_cookie;
-   xcb_dri2_swap_buffers_reply_t *swap_buffers_reply;
+   xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
uint32_t target_msc_hi, target_msc_lo;
uint32_t divisor_hi, divisor_lo;
uint32_t remainder_hi, remainder_lo;
-   int64_t ret = 0;
-   xcb_connection_t *c = XGetXCBConnection(dpy);

split_counter(target_msc, _msc_hi, _msc_lo);
split_counter(divisor, _hi, _lo);
split_counter(remainder, _hi, _lo);

-   swap_buffers_cookie =
-  xcb_dri2_swap_buffers_unchecked(c, pdraw->xDrawable,
+   priv->swap_buffers_cookie =
+  xcb_dri2_swap_buffers_unchecked(c, priv->base.xDrawable,
   target_msc_hi, target_msc_lo,
   divisor_hi, divisor_lo,
   remainder_hi, remainder_lo);
+   xcb_flush(c);
+   priv->swap_pending++;

-   /* Immediately wait on the swapbuffers reply.  If we didn't, we'd have
-* to do so some time before reusing a (non-pageflipped) backbuffer.
-* Otherwise, the new rendering could get ahead of the X Server's
-* dispatch of the swapbuffer and you'd display garbage.
-*
-* We use XSync() first to reap the invalidate events through the event
-* filter, to ensure that the next drawing doesn't use an invalidated
-* buffer.
-*/
-   XSync(dpy, False);
+   /* Force a synchronous completion prior to the next rendering */
+   dri2InvalidateBuffers(priv->base.psc->dpy, priv->base.xDrawable);
+}
+
+static void dri2XcbSwapBuffersComplete(struct dri2_drawable *priv)
+{
+   xcb_dri2_swap_buffers_reply_t *swap_buffers_reply;
+
+   if (!priv->swap_pending)
+  return;
+
+   priv->swap_pending = 0;

swap_buffers_reply =
-  xcb_dri2_swap_buffers_reply(c, swap_buffers_cookie, NULL);
-   if (swap_buffers_reply) {
-  ret = merge_counter(swap_buffers_reply->swap_hi,
-  swap_buffers_reply->swap_lo);
-  free(swap_buffers_reply);
-   }
-   return ret;
+xcb_dri2_swap_buffers_reply(XGetXCBConnection(priv->base.psc->dpy),
+   priv->swap_buffers_cookie, NULL);
+   if (swap_buffers_reply == NULL)
+  return;
+
+   priv->last_swap_sbc = merge_counter(swap_buffers_reply->swap_hi,
+   swap_buffers_reply->swap_lo);
+   free(swap_buffers_reply);
 }

 static int64_t
@@ -833,11 +838,10 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 struct dri2_screen *psc = (struct dri2_screen *) priv->base.psc;
 struct dri2_display *pdp =
(struct dri2_display *)dpyPriv->dri2Display;
-int64_t ret = 0;

 /* Check we have the right attachments */
 if (!priv->have_back)
-   return ret;
+   return 0;

 /* Old servers can't handle swapbuffers */
 if (!pdp->swapAvailable) {
@@ -850,19 +854,14 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   flags |= __DRI2_FLUSH_CONTEXT;
dri2Flush(psc, ctx, priv, flags, __DRI2_THROTTLE_SWAPBUFFER);

-   ret = dri2XcbSwapBuffers(pdraw->psc->dpy, pdraw,
-target_msc, divisor, remainder);
+   dri2XcbSwapBuffers(priv, target_msc, divisor, remainder);
 }

 if (psc->show_fps_interval) {
show_fps(priv);
 }

-/* Old servers don't send invalidate events */
-if 

[mesa 7/9] glx/dri2: Add DRI2GetParam()

[Chris Wilson]

Available since the inclusion of dri2proto 1.4 is a DRI2 request to
query and set certain parameters about the X/DDX configuration. This
implements the getter request.

Signed-off-by: Chris Wilson 
---
 src/glx/dri2.c | 29 +
 src/glx/dri2.h |  4 
 2 files changed, 33 insertions(+)

diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index cc6c164..6d9403e 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -546,4 +546,33 @@ DRI2CopyRegion(Display * dpy, XID drawable, XserverRegion 
region,
SyncHandle();
 }

+Bool
+DRI2GetParam(Display * dpy, XID drawable, CARD32 param, CARD64 *value)
+{
+   XExtDisplayInfo *info = DRI2FindDisplay(dpy);
+   xDRI2GetParamReply rep;
+   xDRI2GetParamReq *req;
+
+   XextCheckExtension(dpy, info, dri2ExtensionName, False);
+
+   LockDisplay(dpy);
+   GetReq(DRI2GetParam, req);
+   req->reqType = info->codes->major_opcode;
+   req->dri2ReqType = X_DRI2GetParam;
+   req->drawable = drawable;
+   req->param = param;
+
+   if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) {
+  UnlockDisplay(dpy);
+  SyncHandle();
+  return False;
+   }
+
+   *value = (CARD64)rep.value_hi << 32 | rep.value_lo;
+   UnlockDisplay(dpy);
+   SyncHandle();
+
+   return rep.is_param_recognized;
+}
+
 #endif /* GLX_DIRECT_RENDERING */
diff --git a/src/glx/dri2.h b/src/glx/dri2.h
index 4be5bf8..a5b23f0 100644
--- a/src/glx/dri2.h
+++ b/src/glx/dri2.h
@@ -88,4 +88,8 @@ DRI2CopyRegion(Display * dpy, XID drawable,
XserverRegion region,
CARD32 dest, CARD32 src);

+extern Bool
+DRI2GetParam(Display * dpy, XID drawable,
+CARD32 param, CARD64 *value);
+
 #endif
-- 
2.1.4

[xf86-video-nouveau] dri2: Enable BufferAge support

[Chris Wilson]

For enable BufferAge support, we just have to be not using the
DRI2Buffer->flags field for any purpose (i.e. it is always expected to
be 0, as it is now) and to be sure to swap the flags field whenever we
exchange buffers. As nouveau does not exactly support TripleBuffer, we
don't have to worry about setting the copying the flags field when
injecting the third buffer.

Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Mario Kleiner 
---
 src/nouveau_dri2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index e3445b2..428ef92 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -711,6 +711,7 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned int 
frame,
}

SWAP(s->dst->name, s->src->name);
+   SWAP(s->dst->flags, s->src->flags);
SWAP(nouveau_pixmap(dst_pix)->bo, nouveau_pixmap(src_pix)->bo);

DamageRegionProcessPending(draw);
@@ -1003,6 +1004,12 @@ nouveau_dri2_init(ScreenPtr pScreen)
dri2.DestroyBuffer2 = nouveau_dri2_destroy_buffer2;
dri2.CopyRegion2 = nouveau_dri2_copy_region2;
 #endif
+
+#if DRI2INFOREC_VERSION >= 10
+   dri2.version = 10;
+   dri2.bufferAge = 1;
+#endif
+
return DRI2ScreenInit(pScreen, );
 }

-- 
2.1.4

[xf86-video-ati] dri2: Enable BufferAge support

[Chris Wilson]

For BufferAge support, we just have to guarrantee that we were not using
the DRI2Buffer->flags field for anything else (i.e. it is always 0) and
then to make sure that we exchange the flags field after buffer
exchanges. radeon does not support TripleBuffering so we do not have to
worry about perserving the flags when injecting the third buffer.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
Cc: Jerome Glisse 
Cc: Alex Deucher 
Cc: Michel Dänzer 
---
 src/radeon_dri2.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 0fbe96c..091cd06 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -764,6 +764,11 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
DRI2BufferPtr front, DRI2BufferPt
 front->name = back->name;
 back->name = tmp;

+/* Swap flags so BufferAge works */
+tmp = front->flags;
+front->flags = back->flags;
+back->flags = tmp;
+
 /* Swap pixmap bos */
 front_bo = radeon_get_pixmap_bo(front_priv->pixmap);
 back_bo = radeon_get_pixmap_bo(back_priv->pixmap);
@@ -1647,6 +1652,11 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
 dri2_info.CopyRegion2 = radeon_dri2_copy_region2;
 #endif

+#if DRI2INFOREC_VERSION >= 10
+dri2_info.version = 10;
+dri2_info.bufferAge = 1;
+#endif
+
 info->dri2.enabled = DRI2ScreenInit(pScreen, _info);
 return info->dri2.enabled;
 }
-- 
2.1.4

[xorg 3/3] dri2: Reuse unused flags in GetBuffers protocol to pass last SBC

[Chris Wilson]

Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
when the current back buffer was defined. As this may require ddx
support, only set the value if enabled by the ddx and report the new
semantics via a DRI2GetParam request.

Signed-off-by: Chris Wilson 
---
 configure.ac   |  2 +-
 hw/xfree86/dri2/dri2.c | 24 
 hw/xfree86/dri2/dri2.h |  1 +
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index b593fc7..e49c35e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -768,7 +768,7 @@ RECORDPROTO="recordproto >= 1.13.99.1"
 SCRNSAVERPROTO="scrnsaverproto >= 1.1"
 RESOURCEPROTO="resourceproto >= 1.2.0"
 DRIPROTO="xf86driproto >= 2.1.0"
-DRI2PROTO="dri2proto >= 2.8"
+DRI2PROTO="dri2proto >= 2.9"
 DRI3PROTO="dri3proto >= 1.0"
 XINERAMAPROTO="xineramaproto"
 BIGFONTPROTO="xf86bigfontproto >= 1.2.0"
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 2c0367e..a998034 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -49,6 +49,8 @@
 #include "damage.h"
 #include "xf86.h"

+#include  /* for parameter names */
+
 CARD8 dri2_major;   /* version of DRI2 supported by DDX */
 CARD8 dri2_minor;

@@ -115,6 +117,7 @@ typedef struct _DRI2Screen {
 unsigned int lastSequence;
 int prime_id;
 int scheduleSwap0;
+int bufferAge;

 DRI2CreateBufferProcPtr CreateBuffer;
 DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1104,6 +1107,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
  * it as early as possible, just to be sure.
  */
 *swap_target = pPriv->swap_count + pPriv->swapsPending + 1;
+if (ds->bufferAge)
+pSrcBuffer->flags = *swap_target;

 for (i = 0; i < pPriv->bufferCount; i++) {
 if (pPriv->buffers[i]->attachment == DRI2BufferFrontLeft)
@@ -1562,6 +1567,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)

 if (info->version >= 10) {
 ds->scheduleSwap0 = info->scheduleSwap0;
+ds->bufferAge = info->bufferAge;
 }

 /*
@@ -1684,10 +1690,20 @@ DRI2GetParam(ClientPtr client,

 switch (high_byte) {
 case 0:
-/* Parameter names whose high_byte is 0 are reserved for the X
- * server. The server currently recognizes no parameters.
- */
-goto not_recognized;
+   /* Parameter names whose high_byte is 0 are reserved for the X
+* server.
+*/
+   switch (param) {
+   case DRI2ParamXHasBufferAge:
+   *value = ds->bufferAge;
+   break;
+   default:
+   goto not_recognized;
+   }
+
+   *is_param_recognized = TRUE;
+   return Success;
+
 case 1:
 /* Parameter names whose high byte is 1 are reserved for the DDX. */
 if (ds->GetParam)
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1cf4288..e76f7a8 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -255,6 +255,7 @@ typedef struct {

 /* added in version 10 */
 int scheduleSwap0;
+int bufferAge;
 } DRI2InfoRec, *DRI2InfoPtr;

 extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
-- 
2.1.4

[xorg 2/3] dri2: Pass swap-interval=0 ScheduleSwap requests to the ddx

[Chris Wilson]

Allow the DDXes to opt-in and handle swap-interval=0 requests for
themselves, for example by using asynchronous pageflips, rather than
forcing a blit. This has the important side-effect of also
disambiguating CopyRegion calls to always be client requests.

References: http://lists.x.org/archives/xorg-devel/2011-June/023102.html
References: http://lists.x.org/archives/xorg-devel/2012-February/029336.html
Signed-off-by: Chris Wilson 
---
 hw/xfree86/dri2/dri2.c | 14 ++
 hw/xfree86/dri2/dri2.h |  5 -
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index f9f594d..2c0367e 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -114,6 +114,7 @@ typedef struct _DRI2Screen {
 int fd;
 unsigned int lastSequence;
 int prime_id;
+int scheduleSwap0;

 DRI2CreateBufferProcPtr CreateBuffer;
 DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1116,8 +1117,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
 return BadDrawable;
 }

-/* Old DDX or no swap interval, just blit */
-if (!ds->ScheduleSwap || !pPriv->swap_interval || pPriv->prime_id) {
+/* Old DDX or PRIME, just blit */
+if (!ds->scheduleSwap0 || pPriv->prime_id) {
 BoxRec box;
 RegionRec region;

@@ -1139,7 +1140,9 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
  * In the simple glXSwapBuffers case, all params will be 0, and we just
  * need to schedule a swap for the last swap target + the swap interval.
  */
-if (target_msc == 0 && divisor == 0 && remainder == 0) {
+if (pPriv->swap_interval == 0) {
+   target_msc = 0;
+} else if (target_msc == 0 && divisor == 0 && remainder == 0) {
 /* If the current vblank count of the drawable's crtc is lower
  * than the count stored in last_swap_target from a previous swap
  * then reinitialize last_swap_target to the current crtc's msc,
@@ -1162,7 +1165,6 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
  * number of pending swaps.
  */
 target_msc = pPriv->last_swap_target + pPriv->swap_interval;
-
 }

 pPriv->swapsPending++;
@@ -1558,6 +1560,10 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 ds->CopyRegion2 = info->CopyRegion2;
 }

+if (info->version >= 10) {
+ds->scheduleSwap0 = info->scheduleSwap0;
+}
+
 /*
  * if the driver doesn't provide an AuthMagic function or the info struct
  * version is too low, call through LegacyAuthMagic
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1e7afdd..1cf4288 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -205,7 +205,7 @@ typedef int (*DRI2GetParamProcPtr) (ClientPtr client,
 /**
  * Version of the DRI2InfoRec structure defined in this header
  */
-#define DRI2INFOREC_VERSION 9
+#define DRI2INFOREC_VERSION 10

 typedef struct {
 unsigned int version;   /**< Version of this struct */
@@ -252,6 +252,9 @@ typedef struct {
 DRI2CreateBuffer2ProcPtr CreateBuffer2;
 DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
 DRI2CopyRegion2ProcPtr CopyRegion2;
+
+/* added in version 10 */
+int scheduleSwap0;
 } DRI2InfoRec, *DRI2InfoPtr;

 extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
-- 
2.1.4

[xorg 1/3] dri2: Allow GetBuffers to match any format

[Chris Wilson]

Since the introduction of DRI2GetBuffersWithFormat, the old
DRI2GetBuffers interface would always recreate all buffers all the time
as it was no longer agnostic to the format value being set by the DDXes.
This causes an issue with clients intermixing the two requests,
rendering any sharing or caching of buffers (e.g. for triple buffering)
void.

Signed-off-by: Chris Wilson 
---
 hw/xfree86/dri2/dri2.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 43a1899..f9f594d 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -464,14 +464,16 @@ find_attachment(DRI2DrawablePtr pPriv, unsigned 
attachment)
 static Bool
 allocate_or_reuse_buffer(DrawablePtr pDraw, DRI2ScreenPtr ds,
  DRI2DrawablePtr pPriv,
- unsigned int attachment, unsigned int format,
+ unsigned int attachment,
+ int has_format, unsigned int format,
  int dimensions_match, DRI2BufferPtr * buffer)
 {
 int old_buf = find_attachment(pPriv, attachment);

 if ((old_buf < 0)
 || attachment == DRI2BufferFrontLeft
-|| !dimensions_match || (pPriv->buffers[old_buf]->format != format)) {
+|| !dimensions_match
+|| (has_format && pPriv->buffers[old_buf]->format != format)) {
 *buffer = create_buffer(ds, pDraw, attachment, format);
 return TRUE;

@@ -549,7 +551,8 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height,
 const unsigned format = (has_format) ? *(attachments++) : 0;

 if (allocate_or_reuse_buffer(pDraw, ds, pPriv, attachment,
- format, dimensions_match, [i]))
+ has_format, format, dimensions_match,
+ [i]))
 buffers_changed = 1;

 if (buffers[i] == NULL)
@@ -584,7 +587,7 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height,

 if (need_real_front > 0) {
 if (allocate_or_reuse_buffer(pDraw, ds, pPriv, DRI2BufferFrontLeft,
- front_format, dimensions_match,
+ has_format, front_format, 
dimensions_match,
  [i]))
 buffers_changed = 1;

@@ -595,7 +598,7 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height,

 if (need_fake_front > 0) {
 if (allocate_or_reuse_buffer(pDraw, ds, pPriv, DRI2BufferFakeFrontLeft,
- front_format, dimensions_match,
+ has_format, front_format, 
dimensions_match,
  [i]))
 buffers_changed = 1;

-- 
2.1.4

[dri2proto] Declare DRI2ParamXHasBufferAge

[Chris Wilson]

In order for X/DDX to reuse a driver specific field of the DRI2GetBuffers
reply, we need to declare the change in semantics. To indicate that the
flags field now continues the last swap buffers count instead, we
introduce the has-buffer-age parameter.

Signed-off-by: Chris Wilson 
---
 configure.ac  |  2 +-
 dri2proto.h   |  2 ++
 dri2proto.txt | 11 ---
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5fadf56..9f4c4a0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.8], 
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([DRI2Proto], [2.9], 
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])

 # Require xorg-macros: XORG_DEFAULT_OPTIONS
diff --git a/dri2proto.h b/dri2proto.h
index 128b807..086dc96 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -340,6 +340,8 @@ typedef struct {
 } xDRI2GetParamReq;
 #define sz_xDRI2GetParamReq 12

+#define DRI2ParamXHasBufferAge 0
+
 typedef struct {
 BYTEtype; /*X_Reply*/
 BOOLis_param_recognized;
diff --git a/dri2proto.txt b/dri2proto.txt
index 9921301..9daa58e 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -454,9 +454,14 @@ The name of this extension is "DRI2".
the screen associated with 'drawable'.

Parameter names in which the value of the most significant byte is
-   0 are reserved for the X server. Currently, no such parameter names
-   are defined. (When any such names are defined, they will be defined in
-   this extension specification and its associated headers).
+   0 are reserved for the X server. The complete list of known parameter
+names for the X server are:
+
+0 - DRI2ParamXHasBufferAge
+
+Query whether the X server and DDX support passing the
+buffers last swap buffer count in the flags field of
+the DRI2GetBuffers reply.

Parameter names in which the byte's value is 1 are reserved for the
DDX. Such names are private to each driver and shall be defined in the
-- 
2.1.4

Implement GLX_EXT_buffer_age for DRI2

[Chris Wilson]

In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
last swap buffer count that the back buffer was defined for. For
simplicity, we can reuse an existing field in the DRI2GetBuffers reply
that is not used by current drivers, the flags. Since we change the
interpretation of this flag, we also declare the semantic change with a
DRI2 parameter and depend upon the DDX to enable the change
responsibility (which is just a matter of reviewing whether the flags
field has ever been used for a non-zero value).

Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=701801

This series add the core support to X, mesa and -ati/-nouveau.

[dri2proto] Declare DRI2ParamXHasBufferAge
[xorg 1/3] dri2: Allow GetBuffers to match any format
[xorg 2/3] dri2: Pass swap-interval=0 ScheduleSwap requests to the
[xorg 3/3] dri2: Reuse unused flags in GetBuffers protocol to pass
[xf86-video-ati] dri2: Enable BufferAge support
[xf86-video-nouveau] dri2: Enable BufferAge support
[mesa 7/9] glx/dri2: Add DRI2GetParam()
[mesa 8/9] glx/dri2: Move the wait after SwapBuffers into the next
[mesa 9/9] glx/dri2: Implement getBufferAge

[PATCH] drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb

[Rodrigo Vivi]

Thanks for the fix.

Tested-by: Rodrigo Vivi 

On Mon, Jan 19, 2015 at 8:31 AM, Matt Roper  
wrote:
> When commiting a plane update where the framebuffer doesn't change, we
> can skip the prepare_fb/cleanup_fb steps.  This also allows us to avoid
> an unnecessary vblank wait at the end of the operation when we're just
> moving a plane and not changing its image (e.g., for a cursor).
>
> At the moment, i915 is the only upstream driver using the transitional
> plane helpers, and thus the only driver affected by this change.
>
> Reported-by: Jeremiah Mahler 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88540
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_plane_helper.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index f24c4cf..7a5814a 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -435,7 +435,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> goto out;
> }
>
> -   if (plane_funcs->prepare_fb && plane_state->fb) {
> +   if (plane_funcs->prepare_fb && plane_state->fb &&
> +   plane_state->fb != old_fb) {
> ret = plane_funcs->prepare_fb(plane, plane_state->fb);
> if (ret)
> goto out;
> @@ -456,6 +457,13 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> crtc_funcs[i]->atomic_flush(crtc[i]);
> }
>
> +   /*
> +* If we only moved the plane and didn't change fb's, there's no need 
> to
> +* wait for vblank.
> +*/
> +   if (plane->state->fb == old_fb)
> +   goto out;
> +
> for (i = 0; i < 2; i++) {
> if (!crtc[i])
> continue;
> --
> 1.8.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br

[PATCH v2] drm: imx: imx-tve: Check and propagate the errors

[Philipp Zabel]

Hi Fabio,

thank you for the patch.

Am Samstag, den 17.01.2015, 19:49 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> In the case of errors we should propagate them.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Fixed a typo on my FSL address
> 
>  drivers/gpu/drm/imx/imx-tve.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
> index a729f4f7..a281723 100644
> --- a/drivers/gpu/drm/imx/imx-tve.c
> +++ b/drivers/gpu/drm/imx/imx-tve.c
> @@ -191,10 +191,18 @@ static int tve_setup_vga(struct imx_tve *tve)
>   /* set gain to (1 + 10/128) to provide 0.7V peak-to-peak amplitude */
>   ret = regmap_update_bits(tve->regmap, TVE_TVDAC0_CONT_REG,
>TVE_TVDAC_GAIN_MASK, 0x0a);
> + if (ret)
> + return ret;
> +
>   ret = regmap_update_bits(tve->regmap, TVE_TVDAC1_CONT_REG,
>TVE_TVDAC_GAIN_MASK, 0x0a);
> + if (ret)
> + return ret;
> +
>   ret = regmap_update_bits(tve->regmap, TVE_TVDAC2_CONT_REG,
>TVE_TVDAC_GAIN_MASK, 0x0a);
> + if (ret)
> + return ret;
>  
>   /* set configuration register */
>   mask = TVE_DATA_SOURCE_MASK | TVE_INP_VIDEO_FORM;

Oh yes. I think the idea here was that if any regmap_* call fails, all
of them should fail, and since the return value of tve_setup_vga is not
checked, the proper return value was not a concern.

> @@ -210,10 +218,8 @@ static int tve_setup_vga(struct imx_tve *tve)
>   }
>  
>   /* set test mode (as documented) */
> - ret = regmap_update_bits(tve->regmap, TVE_TST_MODE_REG,
> + return regmap_update_bits(tve->regmap, TVE_TST_MODE_REG,
>TVE_TVDAC_TEST_MODE_MASK, 1);
> -
> - return 0;
>  }
>  
>  static enum drm_connector_status imx_tve_connector_detect(
> @@ -671,6 +677,8 @@ static int imx_tve_bind(struct device *dev, struct device 
> *master, void *data)
>  
>   /* disable cable detection for VGA mode */
>   ret = regmap_write(tve->regmap, TVE_CD_CONT_REG, 0);
> + if (ret)
> + return ret;
>  
>   ret = imx_tve_register(drm, tve);
>   if (ret)

How about adding the following change:

-8<-
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index ad77a11..76a4509 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -212,10 +212,8 @@ static int tve_setup_vga(struct imx_tve *tve)
mask |= TVE_TV_OUT_MODE_MASK | TVE_SYNC_CH_0_EN;
val  |= TVE_TV_OUT_RGB   | TVE_SYNC_CH_0_EN;
ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG, mask, val);
-   if (ret < 0) {
-   dev_err(tve->dev, "failed to set configuration: %d\n", ret);
+   if (ret)
return ret;
-   }

/* set test mode (as documented) */
return regmap_update_bits(tve->regmap, TVE_TST_MODE_REG,
@@ -341,9 +339,11 @@ static void imx_tve_encoder_mode_set(struct drm_encoder 
*encoder,
}

if (tve->mode == TVE_MODE_VGA)
-   tve_setup_vga(tve);
+   ret = tve_setup_vga(tve);
else
-   tve_setup_tvout(tve);
+   ret = tve_setup_tvout(tve);
+   if (ret)
+   dev_err(tve->dev, "failed to set configuration: %d\n", ret);
 }

 static void imx_tve_encoder_commit(struct drm_encoder *encoder)
-- 
2.1.4
->8-

regards
Philipp

[Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Matt Roper]

On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > There's also an issue in (most) X drivers which exaberates this
> > issues: When changing the cursor buffer the X cursor code does a a)
> > disable cursor b) update cursor image c) enable cursor cycle.
> 
> Notably not -intel on which the bug has been observed. And more
> importantly, the slow downs don't seem to correlate with cursor change,
> just cursor movement.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

It seems that the simple fix for this case (movement only) is to just
skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
the transitional plane helper when newfb == oldfb.  I just posted a
small patch that makes that change (and solves the cursor lag for me).

This won't solve the case if userspace uses a different framebuffer for
each update (while trying to update faster than the refresh rate).  Is
there any existing userspace that behaves this way that we can test
with?


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb

[Matt Roper]

When commiting a plane update where the framebuffer doesn't change, we
can skip the prepare_fb/cleanup_fb steps.  This also allows us to avoid
an unnecessary vblank wait at the end of the operation when we're just
moving a plane and not changing its image (e.g., for a cursor).

At the moment, i915 is the only upstream driver using the transitional
plane helpers, and thus the only driver affected by this change.

Reported-by: Jeremiah Mahler 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88540
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_plane_helper.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index f24c4cf..7a5814a 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -435,7 +435,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
goto out;
}

-   if (plane_funcs->prepare_fb && plane_state->fb) {
+   if (plane_funcs->prepare_fb && plane_state->fb &&
+   plane_state->fb != old_fb) {
ret = plane_funcs->prepare_fb(plane, plane_state->fb);
if (ret)
goto out;
@@ -456,6 +457,13 @@ int drm_plane_helper_commit(struct drm_plane *plane,
crtc_funcs[i]->atomic_flush(crtc[i]);
}

+   /*
+* If we only moved the plane and didn't change fb's, there's no need to
+* wait for vblank.
+*/
+   if (plane->state->fb == old_fb)
+   goto out;
+
for (i = 0; i < 2; i++) {
if (!crtc[i])
continue;
-- 
1.8.5.1

[Bug 88574] VA-API on RV610 crashes my system

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 88574
   Summary: VA-API on RV610 crashes my system
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: user142 at hotmail.com

when I start VLC like this:
export LIBVA_DRIVER_NAME=gallium
vlc
and then inside VLC select VA-API as hardware acceleration and then open a
video, my screen goes black after a few seconds and my system becomes
unresponsive and I have to force poweroff by long pressing the power button.

I am using Arch Linux with the 3.18.2 Kernel and Mesa 10.4.2
My graphics card: Advanced Micro Devices, Inc. [AMD/ATI] RV610/M74 [Mobility
Radeon HD 2400 XT]

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

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

[bugzilla-dae...@freedesktop.org]

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

--- Comment #20 from Arthur Marsh  ---
Created attachment 112447
  --> https://bugs.freedesktop.org/attachment.cgi?id=112447=edit
2015011907dmesg.txt - lockup with vlc and 3.19.0-rc5

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

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

[bugzilla-dae...@freedesktop.org]

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

--- Comment #19 from Arthur Marsh  ---
A further run of the same video with kernel 3.19.0-rc5, doing some skipping of
the the video.

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

[Bug 88408] Black screen in Nuclear Dawn

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from José Fonseca  ---
My guess apitrace is not working because the game is 32bits, but only the
64bits binaries of apitrace are installed.

There are detailed instructions of how to trace Linux Steam games on
https://github.com/apitrace/apitrace/wiki/Steam

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

[Bug 88558] radeonsi crash with mesa 10.4.2

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Hannu  ---
(In reply to Michel Dänzer from comment #1)
> Did this happen when you were doing anything in particular?

I wasn't using the computer myself and didn't pay attention to it, probably it
crashed while playing in steam or watching flash video. I'll see if it can be
reproduced with the same video testing as in bug 85647.

Those VM_CONTEXT1_PROTECTION_FAULT_ADDR messages start at 16:41 and then at
17:17 it says "ring 3 stalled" and at that point screen went black, SSH into
the box worked and I could get the journalctl report.

Jan 18 16:41:35  kernel: radeon :01:00.0: GPU fault detected: 147
0x04124802
Jan 18 16:41:35  kernel: radeon :01:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00096D20
Jan 18 16:41:35  kernel: radeon :01:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x12048002
Jan 18 16:41:35  kernel: VM fault (0x02, vmid 9) at page 617760, read from TC
(72)
--
Jan 18 17:17:19  kernel: radeon :01:00.0: GPU fault detected: 147
0x00b24801
Jan 18 17:17:19  kernel: radeon :01:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FD37C05
Jan 18 17:17:19  kernel: radeon :01:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x12048001
Jan 18 17:17:19  kernel: VM fault (0x01, vmid 9) at page 265518085, read from
TC (72)
Jan 18 17:17:29  kernel: radeon :01:00.0: ring 3 stalled for more than
10191msec

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

[Bug 88556] Plasmashell 5 crash.

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|glsl-compiler
   Assignee|dri-devel at lists.freedesktop |idr at freedesktop.org
   |.org|
 QA Contact||intel-3d-bugs at lists.freedes
   ||ktop.org

--- Comment #3 from Michel Dänzer  ---
Looks like the crash is in the GLSL compiler code.

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

[Bug 88558] radeonsi crash with mesa 10.4.2

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Michel Dänzer  ---
Did this happen when you were doing anything in particular?

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

[Bug 88408] Black screen in Nuclear Dawn

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Michel Dänzer  ---
(In reply to Iwo from comment #5)
> LD_PRELOAD=/usr/lib/glxtrace.so apitrace trace --api gl steam

'apitrace trace' overrides LD_PRELOAD, try just

 LD_PRELOAD=/usr/lib/glxtrace.so steam

You could also try googling for more information about creating apitraces with
Steam games.

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

[PATCH] drm/vmwgfx: Replace the hw mutex with a hw spinlock

[Thomas Hellstrom]

Fixes a case where we call vmw_fifo_idle() from within a wait function with
task state !TASK_RUNNING, which is illegal.

In addition, make the locking fine-grained, so that it is performed once
for every read- and write operation. This is of course more costly, but we
don't perform much register access in the timing critical paths anyway. Instead
we have the extra benefit of being sure that we don't forget the hw lock around
register accesses. I think currently the kms code was quite buggy w r t this.

This fixes Red Hat Bugzilla Bug 1180796

Cc: stable at vger.kernel.org
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 28 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   | 25 
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 18 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c  | 36 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c   | 25 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 --
 7 files changed, 56 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 7b5d221..6c6b655 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -406,11 +406,9 @@ int vmw_3d_resource_inc(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
--dev_priv->num_3d_resources;
} else if (unhide_svga) {
-   mutex_lock(_priv->hw_mutex);
vmw_write(dev_priv, SVGA_REG_ENABLE,
  vmw_read(dev_priv, SVGA_REG_ENABLE) &
  ~SVGA_REG_ENABLE_HIDE);
-   mutex_unlock(_priv->hw_mutex);
}

mutex_unlock(_priv->release_mutex);
@@ -433,13 +431,10 @@ void vmw_3d_resource_dec(struct vmw_private *dev_priv,
mutex_lock(_priv->release_mutex);
if (unlikely(--dev_priv->num_3d_resources == 0))
vmw_release_device(dev_priv);
-   else if (hide_svga) {
-   mutex_lock(_priv->hw_mutex);
+   else if (hide_svga)
vmw_write(dev_priv, SVGA_REG_ENABLE,
  vmw_read(dev_priv, SVGA_REG_ENABLE) |
  SVGA_REG_ENABLE_HIDE);
-   mutex_unlock(_priv->hw_mutex);
-   }

n3d = (int32_t) dev_priv->num_3d_resources;
mutex_unlock(_priv->release_mutex);
@@ -600,12 +595,14 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
dev_priv->dev = dev;
dev_priv->vmw_chipset = chipset;
dev_priv->last_read_seqno = (uint32_t) -100;
-   mutex_init(_priv->hw_mutex);
mutex_init(_priv->cmdbuf_mutex);
mutex_init(_priv->release_mutex);
mutex_init(_priv->binding_mutex);
rwlock_init(_priv->resource_lock);
ttm_lock_init(_priv->reservation_sem);
+   spin_lock_init(_priv->hw_lock);
+   spin_lock_init(_priv->waiter_lock);
+   spin_lock_init(_priv->cap_lock);

for (i = vmw_res_context; i < vmw_res_max; ++i) {
idr_init(_priv->res_idr[i]);
@@ -626,14 +623,11 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)

dev_priv->enable_fb = enable_fbdev;

-   mutex_lock(_priv->hw_mutex);
-
vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
svga_id = vmw_read(dev_priv, SVGA_REG_ID);
if (svga_id != SVGA_ID_2) {
ret = -ENOSYS;
DRM_ERROR("Unsupported SVGA ID 0x%x\n", svga_id);
-   mutex_unlock(_priv->hw_mutex);
goto out_err0;
}

@@ -683,10 +677,8 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
dev_priv->prim_bb_mem = dev_priv->vram_size;

ret = vmw_dma_masks(dev_priv);
-   if (unlikely(ret != 0)) {
-   mutex_unlock(_priv->hw_mutex);
+   if (unlikely(ret != 0))
goto out_err0;
-   }

/*
 * Limit back buffer size to VRAM size.  Remove this once
@@ -695,8 +687,6 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
if (dev_priv->prim_bb_mem > dev_priv->vram_size)
dev_priv->prim_bb_mem = dev_priv->vram_size;

-   mutex_unlock(_priv->hw_mutex);
-
vmw_print_capabilities(dev_priv->capabilities);

if (dev_priv->capabilities & SVGA_CAP_GMR2) {
@@ -1160,9 +1150,7 @@ static int vmw_master_set(struct drm_device *dev,
if (unlikely(ret != 0))
return ret;
vmw_kms_save_vga(dev_priv);
-   mutex_lock(_priv->hw_mutex);
vmw_write(dev_priv, SVGA_REG_TRACES, 0);
-   mutex_unlock(_priv->hw_mutex);
}

if (active) {
@@ -1196,9 +1184,7 @@ out_no_active_lock:
if (!dev_priv->enable_fb) {