[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

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

--- Comment #1 from joshua.r.marshall.1991 at gmail.com ---
My distro kernel version is at 3.14.5

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

[Bug 77471] New: VESA VGA to radeondri handoff results in boot hang

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

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

Bug ID: 77471
   Summary: VESA VGA to radeondri handoff results in boot hang
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc8
  Hardware: x86-64
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: joshua.r.marshall.1991 at gmail.com
Regression: No

Created attachment 138461
  --> https://bugzilla.kernel.org/attachment.cgi?id=138461=edit
The kernel config I'm using

Suspecting a kernel memory leak involving radeon stuffs, I pulled down the
kernel source, used "make localyesconfig" to automatically configure the kernel
from my distro's configuration, did the typical procedure to make the kernel
boot as per archlinux instructions and past experiance.  During boot of the new
kernel, a line saying the handoff from VESA VGA was handing off to radeondri
for the framebuffer switchoff prints, CPU goes to 100% (from what I can tell --
fan speeds up and CPU kicks off heat) and does not progress.  Even given a half
hour, this doesn't change.

I'm not sure how to proceed other than filing this report.

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

looking for i915 direct programming sample application

[Gábor Bereczki]

Hello i915 Community,

I am looking after a "Hello world!" like simple skeleton program, from
which I could learn how to open the GPU device, how to set up memories,
etc, how to pass and execute ringbuffer. How to check resulting frame
buffer. I guess there could be such user space application, that is used
e.g for testing the driver.

Why am I asking for such a weird thing? Why isnt OpenCL , Mesa or Cairo
good for me?

Well, first of all I am a machine code enthusiast and would love to run my
own handcrafted code on the EUs. :)
Second, I am investigating if I could optimize traditional telecom
algorithms to the Intel GPU. Stuff like FFT, DFT, Goertzel , Czebishev
filters and so on.
(and yes I am checking  OpenCL, too)
Your help, as always, is very much appreciated.
With regards,

Gabor Bereczki
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/91241d7d/attachment.html>

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

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

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

--- Comment #3 from David Heidelberger (okias)  
---
When issuing: "vbetool dpms on" without touching keys, screen goes just pure
white. After pressing button, screen goes off again.

Seems like it goes from "any_state -> off" instead of "any_state -> on".

-- 
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/20140607/0cd89ede/attachment.html>

[PATCHv3 2/3] list: Fix order of arguments for hlist_add_after(_rcu)

[Ken Helias]

From: Ken Helias 

All other add functions for lists have the new item as first argument and the
position where it is added as second argument. This was changed for no good
reason in this function and makes using it unnecessary confusing.

The name was changed to let old code generate a compile errors instead of
using the wrong parameter order.

Signed-off-by: Ken Helias 
Cc: Linux NICS 
Cc: "Paul E. McKenney" 
Cc: dri-devel at lists.freedesktop.org
Cc: e1000-devel at lists.sourceforge.net
Cc: netdev at vger.kernel.org
Cc: devel at driverdev.osuosl.org
Cc: linux-fsdevel at vger.kernel.org
Cc: b.a.t.m.a.n at lists.open-mesh.org
Cc: bridge at lists.linux-foundation.org
---
Patch based on "Add linux-next specific files for 20140606"

v3:
renamed from hlist_add_after* to hlist_add_behind

v2:
Splitted into two patches
reduced number of Cc

 Documentation/RCU/whatisRCU.txt  | 2 +-
 drivers/gpu/drm/drm_hashtab.c| 2 +-
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c   | 2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
 drivers/staging/lustre/lustre/libcfs/hash.c  | 4 ++--
 fs/namespace.c   | 2 +-
 fs/notify/inode_mark.c   | 2 +-
 fs/notify/vfsmount_mark.c| 2 +-
 include/linux/list.h | 4 ++--
 include/linux/rculist.h  | 8 
 net/batman-adv/fragmentation.c   | 2 +-
 net/bridge/br_multicast.c| 2 +-
 net/ipv4/fib_trie.c  | 2 +-
 net/ipv6/addrlabel.c | 2 +-
 net/xfrm/xfrm_policy.c   | 4 ++--
 15 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 49b8551..e48c57f 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -818,7 +818,7 @@ RCU pointer/list update:
list_add_tail_rcu
list_del_rcu
list_replace_rcu
-   hlist_add_after_rcu
+   hlist_add_behind_rcu
hlist_add_before_rcu
hlist_add_head_rcu
hlist_del_rcu
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 7e4bae7..c3b80fd 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -125,7 +125,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
parent = >head;
}
if (parent) {
-   hlist_add_after_rcu(parent, >head);
+   hlist_add_behind_rcu(>head, parent);
} else {
hlist_add_head_rcu(>head, h_list);
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1bb470b..7c3e596 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1437,7 +1437,7 @@ static int i40e_update_ethtool_fdir_entry(struct i40e_vsi 
*vsi,

/* add filter to the list */
if (parent)
-   hlist_add_after(>fdir_node, >fdir_node);
+   hlist_add_behind(>fdir_node, >fdir_node);
else
hlist_add_head(>fdir_node,
   >fdir_filter_list);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 23e4e6a..89b7a10 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -2518,7 +2518,7 @@ static int ixgbe_update_ethtool_fdir_entry(struct 
ixgbe_adapter *adapter,

/* add filter to the list */
if (parent)
-   hlist_add_after(>fdir_node, >fdir_node);
+   hlist_add_behind(>fdir_node, >fdir_node);
else
hlist_add_head(>fdir_node,
   >fdir_filter_list);
diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c 
b/drivers/staging/lustre/lustre/libcfs/hash.c
index 6d2b455..6db7391 100644
--- a/drivers/staging/lustre/lustre/libcfs/hash.c
+++ b/drivers/staging/lustre/lustre/libcfs/hash.c
@@ -351,7 +351,7 @@ cfs_hash_dh_hnode_add(struct cfs_hash *hs, struct 
cfs_hash_bd *bd,
cfs_hash_dhead_t, dh_head);

if (dh->dh_tail != NULL) /* not empty */
-   hlist_add_after(dh->dh_tail, hnode);
+   hlist_add_behind(hnode, dh->dh_tail);
else /* empty list */
hlist_add_head(hnode, >dh_head);
dh->dh_tail = hnode;
@@ -406,7 +406,7 @@ cfs_hash_dd_hnode_add(struct cfs_hash *hs, struct 
cfs_hash_bd *bd,
cfs_hash_dhead_dep_t, dd_head);

if (dh->dd_tail != NULL) /* not empty */
-   hlist_add_after(dh->dd_tail, hnode);
+   hlist_add_behind(hnode, dh->dd_tail);
else /* 

[PATCH] drm: fix uninitialized acquire_ctx fields

[Ville Syrjälä]

On Sat, Jun 07, 2014 at 08:29:13AM -0400, Rob Clark wrote:
> The acquire ctx will typically be declared on the stack, which means we
> could have garbage values for any uninitialized field.  In this case, it
> was triggering WARN_ON()s because 'contended' had garbage value.
> 
> Go ahead and use memset() to be more future-proof.
> 
> Reported-by: Ville Syrj?l? 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 7c2497d..4e8b244 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -64,6 +64,7 @@
>  void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
>   uint32_t flags)
>  {
> + memset(ctx, 0, sizeof(ctx));
  ^^^
*ctx

with that fixed:
Reviewed-by: Ville Syrj?l? 
Tested-by: Ville Syrj?l? 

>   ww_acquire_init(>ww_ctx, _ww_class);
>   INIT_LIST_HEAD(>locked);
>  }
> -- 
> 1.9.3

-- 
Ville Syrj?l?
Intel OTC

ast2400 woes

[Benjamin Herrenschmidt]

On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:

> IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO
> use the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42,
> can it be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
> 
> On my AST2400 at least, even when MMIO is disabled, 0x3c3 still
> responds so it works but is that valid for all chips ? Or do I need
> to favor the PIO path if PIO is available in that case for older
> chipsets ?

Note: I have it working now with a couple of patches that i'll send
when I've cleaned them up, though I still need answers to the earlier
questions so we can make sure we don't break earlier chipset support
on x86.

However, YC, the Endian control bits in extended CRTC register A2 seem
to have no effect at all. With a big endian kernel I get the wrong
endian on graphics regardless of the setting of that register !

Is endian swapping supported on the AST2400 ?

Also what is the exact effect of that register ? Does it affect access
from PCI to the framebuffer or does it affect the way the CRTC consumes
pixels from the framebuffer ? Is is supposed to have an effect on
register accesses ?

Cheers,
Ben.

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #5 from dex+fdobugzilla at dragonslave.de ---
Looking at strings from vbios:

>113-MSITV303MS.1D0 C63101 CURACAO XT GDDR5 64MX32 2GB 150E/150M 

This is the 4G variant:
http://www.msi.com/product/vga/R9_270X_GAMING_4G.html

-- 
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/20140607/5d9be8d4/attachment.html>

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #4 from Alex Deucher  ---
(In reply to comment #3)
> Created attachment 100616 [details]
> Next try. This time without od.

That worked.  thanks!

-- 
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/20140607/8d6dbf48/attachment.html>

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #3 from dex+fdobugzilla at dragonslave.de ---
Created attachment 100616
  --> https://bugs.freedesktop.org/attachment.cgi?id=100616=edit
Next try. This time without od.

-- 
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/20140607/27847834/attachment.html>

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #2 from Alex Deucher  ---
looks like the vbios didn't get dumped properly.  Try this:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

-- 
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/20140607/0a55006d/attachment.html>

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

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

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

--- Comment #1 from dex+fdobugzilla at dragonslave.de ---
Created attachment 100615
  --> https://bugs.freedesktop.org/attachment.cgi?id=100615=edit
Videobios via od -x  /sys/class/drm/card0/device/rom

-- 
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/20140607/1995707f/attachment-0001.html>

[Bug 79773] New: Enabling DPM results in crash for R270X PITCAIRN

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

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

  Priority: medium
Bug ID: 79773
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Enabling DPM results in crash for R270X PITCAIRN
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: dex+fdobugzilla at dragonslave.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 100614
  --> https://bugs.freedesktop.org/attachment.cgi?id=100614=edit
Relevant dmesg

Kernel: 3.15.0-rc7-00118-ga4bf79e

As soon as the radeon module gets loaded with dpm=1 (the default)
and Xorg is started the system crashes.

-- 
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/20140607/5aa3acc4/attachment.html>

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #8 from Alex Deucher  ---
You might try a bios update if one is available for your board.

-- 
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/20140607/35929d9d/attachment.html>

[RFC PATCH] drm/gk208/gr: adjust a couple of init values

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---

MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b
MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03
MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c
MMIO32 W 0x17e920 0x00090d08 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 <= 0x90d08

And then later when it writes these values into memory,

MMIO32 R 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb030a0c
MMIO32 R 0x17e920 0x00090d08 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90d08
RAMIN32 1b5080 7fce1080 <= 17e91c
RAMIN32 1b5084 7fce1084 <= b030a0c
MMIO32 W 0x07 0x0001 PFIFO_FLUSH.FLUSH_CTRL <= { TRIGGER }
MMIO32 R 0x07 0x PFIFO_FLUSH.FLUSH_CTRL => { 0 }
RAMIN32 1b5088 7fce1088 <= 17e920
RAMIN32 1b508c 7fce108c <= 90d08

So perhaps the mmio_list needs to grow a mask option (and have it store the
mask)? Not sure what any of this means, and doing this didn't fix
anything. So... this is more informational than to be applied
necessarily. Although the values that 337.25 writes on the GK208 I was testing
on (GT630, 10de:1284) were different than what you were writing in (at least
for the first reg).

 drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
index 8de4a42..b0bc5db 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
@@ -537,6 +537,7 @@ nv108_grctx_generate_mods(struct nvc0_graph_priv *priv, 
struct nvc0_grctx *info)
u32 magic[GPC_MAX][2];
u32 offset;
int gpc;
+   u32 r17e91c, r17e920;

mmio_data(0x003000, 0x0100, NV_MEM_ACCESS_RW | NV_MEM_ACCESS_SYS);
mmio_data(0x008000, 0x0100, NV_MEM_ACCESS_RW | NV_MEM_ACCESS_SYS);
@@ -571,8 +572,10 @@ nv108_grctx_generate_mods(struct nvc0_graph_priv *priv, 
struct nvc0_grctx *info)
offset += 0x07ff * priv->tpc_nr[gpc];
}

-   mmio_list(0x17e91c, 0x0b040a0b, 0, 0);
-   mmio_list(0x17e920, 0x00090d08, 0, 0);
+   r17e91c = nv_rd32(priv, 0x17e91c);
+   r17e920 = nv_rd32(priv, 0x17e920);
+   mmio_list(0x17e91c, (r17e91c & ~0x000f000f) | 0x0003000c, 0, 0);
+   mmio_list(0x17e920, (r17e920 & ~0x0f0f) | 0x0d08, 0, 0);
 }

 struct nouveau_oclass *
-- 
1.8.5.5

[PATCH] drm/gk208/gr: add missing registers to grctx init

[Ilia Mirkin]

This fixes hangs on GK208 which happen instantaneously on trying to use a
geometry shader.

Signed-off-by: Ilia Mirkin 
Cc: stable at vger.kernel.org # v3.14+
---

ctxnvf0 also writes to these registers (although slightly diff values), so I
think this is right. So I guess trap 4 is whatever this 406 subengine is...

 drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
index 48351b4..8de4a42 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv108.c
@@ -545,10 +545,12 @@ nv108_grctx_generate_mods(struct nvc0_graph_priv *priv, 
struct nvc0_grctx *info)
mmio_list(0x408010, 0x8000,  0, 0);
mmio_list(0x419004, 0x,  8, 1);
mmio_list(0x419008, 0x,  0, 0);
+   mmio_list(0x4064cc, 0x8000,  0, 0);
mmio_list(0x408004, 0x,  8, 0);
mmio_list(0x408008, 0x8030,  0, 0);
mmio_list(0x418808, 0x,  8, 0);
mmio_list(0x41880c, 0x8030,  0, 0);
+   mmio_list(0x4064c8, 0x00c20200,  0, 0);
mmio_list(0x418810, 0x8000, 12, 2);
mmio_list(0x419848, 0x1000, 12, 2);

-- 
1.8.5.5

[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

-- 
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/20140607/02e0e0df/attachment.html>

[Bug 79520] mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1

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

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

--- Comment #17 from Savyasachee Jha  ---
Okay, after upgrading to mesa, mesa-libgl and ati-dri 10.2.1, there's been no
problem. Thanks for all the help!

-- 
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/20140607/535cae18/attachment.html>

[PATCH] drm: fix uninitialized acquire_ctx fields (v2)

[Rob Clark]

The acquire ctx will typically be declared on the stack, which means we
could have garbage values for any uninitialized field.  In this case, it
was triggering WARN_ON()s because 'contended' had garbage value.

Go ahead and use memset() to be more future-proof.

v2: now with extra brown paper bag

Reported-by: Ville Syrj?l? 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_modeset_lock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 7c2497d..0dc57d5 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -64,6 +64,7 @@
 void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags)
 {
+   memset(ctx, 0, sizeof(*ctx));
ww_acquire_init(>ww_ctx, _ww_class);
INIT_LIST_HEAD(>locked);
 }
-- 
1.9.3

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

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

--- Comment #4 from Marti Raudsepp  ---
Created attachment 100599
  --> https://bugs.freedesktop.org/attachment.cgi?id=100599=edit
gdm-Xorg-:1.log

Oh, after waiting long enough, I also see the following messages in Xorg log...
There are multiple such traces in the attached file.

[mi] EQ overflowing.  Additional events will be discarded until existing events
are processed.

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x48) [0x584b08]
1: /usr/bin/Xorg (mieqEnqueue+0x22b) [0x566b7b]
2: /usr/bin/Xorg (QueuePointerEvents+0x52) [0x44cc72]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f417ddd9000+0x60ba)
[0x7f417dddf0ba]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f417ddd9000+0x657d)
[0x7f417dddf57d]
5: /usr/bin/Xorg (0x40+0x72f08) [0x472f08]
6: /usr/bin/Xorg (0x40+0x9b4b0) [0x49b4b0]
7: /usr/lib/libpthread.so.0 (0x7f4184c61000+0xf4b0) [0x7f4184c704b0]
8: /usr/lib/libpthread.so.0 (0x7f4184c61000+0xe38c) [0x7f4184c6f38c]
9: /usr/lib/libpthread.so.0 (0x7f4184c61000+0x9b3c) [0x7f4184c6ab3c]
10: /usr/lib/libpthread.so.0 (pthread_mutex_lock+0x6a) [0x7f4184c6a91a]
11: /usr/lib/libEGL.so.1 (eglCreateImageKHR+0x3e) [0x7f4181976fde]
12: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_pixmap+0xf1) [0x7f4181b95e21]
13: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f417e3f6000+0x4bac0)
[0x7f417e441ac0]
14: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f417e3f6000+0x4be26)
[0x7f417e441e26]
15: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f417e3f6000+0x42819)
[0x7f417e438819]
16: /usr/bin/Xorg (0x40+0x1554c3) [0x5554c3]
17: /usr/bin/Xorg (0x40+0x15628f) [0x55628f]
18: /usr/bin/Xorg (DRI2GetBuffersWithFormat+0x10) [0x556690]
19: /usr/lib/xorg/modules/extensions/libglx.so (0x7f417e862000+0x2c661)
[0x7f417e88e661]
20: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x6886a)
[0x7f417d1c286a]
21: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x6693a)
[0x7f417d1c093a]
22: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x1bfade)
[0x7f417d319ade]
23: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x1c0c48)
[0x7f417d31ac48]
24: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x192a70)
[0x7f417d2eca70]
25: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x1a6a85)
[0x7f417d300a85]
26: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x17b627)
[0x7f417d2d5627]
27: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x1627fc)
[0x7f417d2bc7fc]
28: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0x178684)
[0x7f417d2d2684]
29: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f417d15a000+0xa2433)
[0x7f417d1fc433]
30: /usr/lib/libEGL.so.1 (0x7f418197+0x10ffe) [0x7f4181980ffe]
31: /usr/lib/libEGL.so.1 (eglMakeCurrent+0x1cd) [0x7f418197940d]
32: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_make_current+0x48)
[0x7f4181b95c08]
33: /usr/lib/libglamor.so.0 (glamor_block_handler+0x69) [0x7f418152dc69]
34: /usr/bin/Xorg (_CallCallbacks+0x34) [0x43ad64]
35: /usr/bin/Xorg (WriteToClient+0x1a6) [0x588096]
36: /usr/lib/xorg/modules/extensions/libglx.so (0x7f417e862000+0x11761)
[0x7f417e873761]
37: /usr/lib/xorg/modules/extensions/libglx.so (0x7f417e862000+0x251d0)
[0x7f417e8871d0]
38: /usr/bin/Xorg (0x40+0x35c8e) [0x435c8e]
39: /usr/bin/Xorg (0x40+0x39aaa) [0x439aaa]
40: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7f41838ce000]
41: /usr/bin/Xorg (0x40+0x2507e) [0x42507e]

[mi] These backtraces from mieqEnqueue may point to a culprit higher up the
stack.
[mi] mieq is *NOT* the cause.  It is a victim.


-- 
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/20140607/6a94a6bd/attachment-0001.html>

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

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

--- Comment #3 from Marti Raudsepp  ---
Also occurs with mesa 10.2.1.

-- 
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/20140607/e81f1b10/attachment.html>

ast2400 woes

[Benjamin Herrenschmidt]

On Fri, 2014-06-06 at 21:31 +1000, Benjamin Herrenschmidt wrote:

> The spec is pretty tricky to read but seems to indicate that the above
> offset should also work for PIO if needed, however, it seems like the
> X driver is pretty happy to use MMIO unconditionally for them.
> 
> Any objection on me sending you a patch to send (almost) everybody to
> use the MMIO path ?
> 
> The only remaining "issues" with PIO is the EnableVGA / IsVGAEnabled
> path which still uses PIO in X.
> 
> Now, at least on the AST2400, the register in question is also on MMIO
> (3c3, aka VGA_ENABLE_PORT in the above list), but I don't know whether
> that works on all the older chipsets. (YC Chen on CC might have an opinion).

Ok, I think we need YC Chen answers here. Basically from what I can
tell those old "IO" registers and those new "MMIO" ones only differ
by that offset of 0x340.

The question thus boils down to:

 - Are the "3xx" versions only MMIO or PIO as well ?

 - Are the "3xx" version always available on all chips ?

 - Is MMIO always available on all chips ?

IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO
use the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42,
can it be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?

On my AST2400 at least, even when MMIO is disabled, 0x3c3 still
responds so it works but is that valid for all chips ? Or do I need
to favor the PIO path if PIO is available in that case for older
chipsets ?

Thanks !

Cheers,
Ben.

[PATCH] drm: fix uninitialized acquire_ctx fields

[Rob Clark]

The acquire ctx will typically be declared on the stack, which means we
could have garbage values for any uninitialized field.  In this case, it
was triggering WARN_ON()s because 'contended' had garbage value.

Go ahead and use memset() to be more future-proof.

Reported-by: Ville Syrj?l? 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_modeset_lock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 7c2497d..4e8b244 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -64,6 +64,7 @@
 void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags)
 {
+   memset(ctx, 0, sizeof(ctx));
ww_acquire_init(>ww_ctx, _ww_class);
INIT_LIST_HEAD(>locked);
 }
-- 
1.9.3

[PATCH 9/9] drm/tilcdc: replace late_initcall with module_init

[Guido Martínez]

Use module_init instead of late_initcall, as is the norm for modular
drivers.

module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
but it does not explain why. Tests show it's working properly with
module_init.

Signed-off-by: Guido Mart?nez 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 702315f..80e6697 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -629,7 +629,7 @@ static void __exit tilcdc_drm_fini(void)
tilcdc_tfp410_fini();
 }

-late_initcall(tilcdc_drm_init);
+module_init(tilcdc_drm_init);
 module_exit(tilcdc_drm_fini);

 MODULE_AUTHOR("Rob Clark 

[PATCH 8/9] drm/tilcdc: remove submodule destroy calls

[Guido Martínez]

The TI tilcdc driver is designed with a notion of submodules. Currently,
at unload time, these submodules are iterated and destroyed.

Now that the tilcdc remove order is fixed, this can be handled perfectly
by the kernel using the device infrastructure, since each submodule
is a kernel driver itself, and they are only destroy()'ed at unload
time. Therefore we move the destroy() functionality to each submodule's
remove().

Also, remove some checks in the unloading process since the new code
guarantees the resources are allocated and need a release.

Signed-off-by: Guido Mart?nez 
---
 drivers/gpu/drm/tilcdc/Module.symvers  |  0
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  6 --
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 36 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 26 +---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 34 
 6 files changed, 50 insertions(+), 53 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers

diff --git a/drivers/gpu/drm/tilcdc/Module.symvers 
b/drivers/gpu/drm/tilcdc/Module.symvers
new file mode 100644
index 000..e69de29
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0644429..702315f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -120,7 +120,6 @@ static int cpufreq_transition(struct notifier_block *nb,
 static int tilcdc_unload(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-   struct tilcdc_module *mod, *cur;

drm_fbdev_cma_fini(priv->fbdev);
drm_kms_helper_poll_fini(dev);
@@ -149,11 +148,6 @@ static int tilcdc_unload(struct drm_device *dev)

pm_runtime_disable(dev->dev);

-   list_for_each_entry_safe(mod, cur, _list, list) {
-   DBG("destroying module: %s", mod->name);
-   mod->funcs->destroy(mod);
-   }
-
kfree(priv);

return 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0938036..7596c14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -98,7 +98,6 @@ struct tilcdc_module;
 struct tilcdc_module_ops {
/* create appropriate encoders/connectors: */
int (*modeset_init)(struct tilcdc_module *mod, struct drm_device *dev);
-   void (*destroy)(struct tilcdc_module *mod);
 #ifdef CONFIG_DEBUG_FS
/* create debugfs nodes (can be NULL): */
int (*debugfs_init)(struct tilcdc_module *mod, struct drm_minor *minor);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index b085dcc..2f6efae 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -282,21 +282,8 @@ static int panel_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev)
return 0;
 }

-static void panel_destroy(struct tilcdc_module *mod)
-{
-   struct panel_module *panel_mod = to_panel_module(mod);
-
-   if (panel_mod->timings)
-   display_timings_release(panel_mod->timings);
-
-   tilcdc_module_cleanup(mod);
-   kfree(panel_mod->info);
-   kfree(panel_mod);
-}
-
 static const struct tilcdc_module_ops panel_module_ops = {
.modeset_init = panel_modeset_init,
-   .destroy = panel_destroy,
 };

 /*
@@ -372,6 +359,7 @@ static int panel_probe(struct platform_device *pdev)
return -ENOMEM;

mod = _mod->base;
+   pdev->dev.platform_data = mod;

tilcdc_module_init(mod, "panel", _module_ops);

@@ -379,17 +367,16 @@ static int panel_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl))
dev_warn(>dev, "pins are not configured\n");

-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(>dev, "could not get panel timings\n");
-   goto fail;
+   goto fail_free;
}

panel_mod->info = of_get_panel_info(node);
if (!panel_mod->info) {
dev_err(>dev, "could not get panel info\n");
-   goto fail;
+   goto fail_timings;
}

mod->preferred_bpp = panel_mod->info->bpp;
@@ -400,13 +387,26 @@ static int panel_probe(struct platform_device *pdev)

return 0;

-fail:
-   panel_destroy(mod);
+fail_timings:
+   display_timings_release(panel_mod->timings);
+
+fail_free:
+   kfree(panel_mod);
+   tilcdc_module_cleanup(mod);
return ret;
 }

 static int panel_remove(struct platform_device *pdev)
 {
+   struct tilcdc_module *mod = dev_get_platdata(>dev);
+   struct panel_module *panel_mod = to_panel_module(mod);
+
+   display_timings_release(panel_mod->timings);
+
+   tilcdc_module_cleanup(mod);
+   kfree(panel_mod->info);
+   kfree(panel_mod);
+
   

[PATCH 7/9] drm/tilcdc: fix double kfree

[Guido Martínez]

display_timings_release calls kfree on the display_timings object passed
to it. Calling kfree after it is wrong. SLUB debug showed the following
warning:


=
BUG kmalloc-64 (Tainted: GW): Object already free

-

Disabling lock debugging due to kernel taint
INFO: Allocated in of_get_display_timings+0x2c/0x214 age=601 cpu=0
pid=884
 __slab_alloc.constprop.79+0x2e0/0x33c
 kmem_cache_alloc+0xac/0xdc
 of_get_display_timings+0x2c/0x214
 panel_probe+0x7c/0x314 [tilcdc]
 platform_drv_probe+0x18/0x48
 [..snip..]
INFO: Freed in panel_destroy+0x18/0x3c [tilcdc] age=0 cpu=0 pid=907
 __slab_free+0x34/0x330
 panel_destroy+0x18/0x3c [tilcdc]
 tilcdc_unload+0xd0/0x118 [tilcdc]
 drm_dev_unregister+0x24/0x98
 [..snip..]

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 1943b2f..b085dcc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -286,10 +286,8 @@ static void panel_destroy(struct tilcdc_module *mod)
 {
struct panel_module *panel_mod = to_panel_module(mod);

-   if (panel_mod->timings) {
+   if (panel_mod->timings)
display_timings_release(panel_mod->timings);
-   kfree(panel_mod->timings);
-   }

tilcdc_module_cleanup(mod);
kfree(panel_mod->info);
-- 
2.0.0.rc2

[PATCH 6/9] drm/tilcdc: fix release order on exit

[Guido Martínez]

Unregister resources in the correct order on tilcdc_drm_fini, which is
the reverse order they were registered during tilcdc_drm_init.

This also means unregistering the driver before releasing its resources.

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index de34657..0644429 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -629,10 +629,10 @@ static int __init tilcdc_drm_init(void)
 static void __exit tilcdc_drm_fini(void)
 {
DBG("fini");
-   tilcdc_tfp410_fini();
-   tilcdc_slave_fini();
-   tilcdc_panel_fini();
platform_driver_unregister(_platform_driver);
+   tilcdc_panel_fini();
+   tilcdc_slave_fini();
+   tilcdc_tfp410_fini();
 }

 late_initcall(tilcdc_drm_init);
-- 
2.0.0.rc2

[PATCH 5/9] drm/tilcdc: panel: fix leak when unloading the module

[Guido Martínez]

The driver did not unregister the allocated framebuffer, which caused
memory leaks (and memory manager WARNs) when unloading. Also, the
framebuffer device under /dev still existed after unloading.

Add a call to drm_fbdev_cma_fini when unloading the module to prevent
both issues.

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 171a820..de34657 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -122,6 +122,7 @@ static int tilcdc_unload(struct drm_device *dev)
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_module *mod, *cur;

+   drm_fbdev_cma_fini(priv->fbdev);
drm_kms_helper_poll_fini(dev);
drm_mode_config_cleanup(dev);
drm_vblank_cleanup(dev);
-- 
2.0.0.rc2

[PATCH 4/9] drm/tilcdc: tfp410: fix dangling sysfs connector node

[Guido Martínez]

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver, otherwise
we will get a warning about a duplicate filename in sysfs.

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index c38b56b..ce75ac8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -167,6 +167,7 @@ struct tfp410_connector {
 static void tfp410_connector_destroy(struct drm_connector *connector)
 {
struct tfp410_connector *tfp410_connector = 
to_tfp410_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(tfp410_connector);
 }
-- 
2.0.0.rc2

[PATCH 3/9] drm/tilcdc: slave: fix dangling sysfs connector node

[Guido Martínez]

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   tda998x 0-0070: found TDA19988
   [ cut here ]
   WARNING: CPU: 0 PID: 825 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-HDMI-A-1'
   Modules linked in: [..]
   CPU: 0 PID: 825 Comm: modprobe Not tainted 3.15.0-rc4-00027-g9dcdef4 #82
   [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
   [] (show_stack) from [] (warn_slowpath_common+0x68/0x88)
   [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
   [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74)
   [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [] (sysfs_do_create_link_sd.isra.2) from [] 
(device_add+0x338/0x520)
   [] (device_add) from [] 
(device_create_groups_vargs+0xa0/0xc4)
   [] (device_create_groups_vargs) from [] 
(device_create+0x24/0x2c)
   [] (device_create) from [] 
(drm_sysfs_connector_add+0x64/0x204)
   [] (drm_sysfs_connector_add) from [] 
(slave_modeset_init+0x120/0x1bc [tilcdc])
   [] (slave_modeset_init [tilcdc]) from [] 
(tilcdc_load+0x214/0x4c0 [tilcdc])
   [] (tilcdc_load [tilcdc]) from [] 
(drm_dev_register+0xa4/0x104)
  [..snip..]
   ---[ end trace 4df8d614936ebdee ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: 
-17

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index a37924e..28c8478 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -176,6 +176,7 @@ struct slave_connector {
 static void slave_connector_destroy(struct drm_connector *connector)
 {
struct slave_connector *slave_connector = to_slave_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(slave_connector);
 }
-- 
2.0.0.rc2

[PATCH 2/9] drm/tilcdc: panel: fix dangling sysfs connector node

[Guido Martínez]

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   [ cut here ]
   WARNING: CPU: 0 PID: 824 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-LVDS-1'
   Modules linked in: [...]
   CPU: 0 PID: 824 Comm: modprobe Not tainted 3.15.0-rc4-00027-g6484f96-dirty 
#81
   [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
   [] (show_stack) from [] (warn_slowpath_common+0x68/0x88)
   [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
   [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74)
   [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [] (sysfs_do_create_link_sd.isra.2) from [] 
(device_add+0x338/0x520)
   [] (device_add) from [] 
(device_create_groups_vargs+0xa0/0xc4)
   [] (device_create_groups_vargs) from [] 
(device_create+0x24/0x2c)
   [] (device_create) from [] 
(drm_sysfs_connector_add+0x64/0x204)
   [] (drm_sysfs_connector_add) from [] 
(panel_modeset_init+0xb8/0x134 [tilcdc])
   [] (panel_modeset_init [tilcdc]) from [] 
(tilcdc_load+0x214/0x4c0 [tilcdc])
   [] (tilcdc_load [tilcdc]) from [] 
(drm_dev_register+0xa4/0x104)
  [ .. snip .. ]
   ---[ end trace b2d09cd9578b0497 ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: 
-17

Signed-off-by: Guido Mart?nez 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 86c6732..1943b2f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -151,6 +151,7 @@ struct panel_connector {
 static void panel_connector_destroy(struct drm_connector *connector)
 {
struct panel_connector *panel_connector = to_panel_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(panel_connector);
 }
-- 
2.0.0.rc2

[PATCH 1/9] drm/i2c: tda998x: move drm_i2c_encoder_destroy call

[Guido Martínez]

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.

Signed-off-by: Guido Mart?nez 
Signed-off-by: Ezequiel Garc?a 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 219c7e8..d06eff6 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1183,7 +1183,6 @@ static void
 tda998x_encoder_destroy(struct drm_encoder *encoder)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   drm_i2c_encoder_destroy(encoder);

/* disable all IRQs and free the IRQ handler */
cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
@@ -1193,6 +1192,7 @@ tda998x_encoder_destroy(struct drm_encoder *encoder)

if (priv->cec)
i2c_unregister_device(priv->cec);
+   drm_i2c_encoder_destroy(encoder);
kfree(priv);
 }

-- 
2.0.0.rc2

[PATCH 0/9] tilcdc driver fixes

[Guido Martínez]

The tilcdc driver could be compiled as a module, but was severely broken
and could not be used as such. This patchset attempts to fix the issues
preventing a proper load/unload of the module.

Issues included dangling sysfs nodes, dangling devices, memory leaks and
a double kfree.

It now seems to be working ok. We have tested this by loading and
unloading the driver repeteadly, with both panel and slave connectors
and found no flaws.

There is still one warning left on tilcdc_crtc_destroy, caused by
destroying the connector while still in an ON status. We don't know why
this happens or why it's an issue, so we did not fix it.

The first 7 patches are bug fixes which and should probably be applied
in the stable trees. The last two are clean-ups.

The series applies cleanly over -next and 3.15-rc8, and will be resent
for v3.16-rc1, once it's out.

Guido Mart?nez (9):
  drm/i2c: tda998x: move drm_i2c_encoder_destroy call
  drm/tilcdc: panel: fix dangling sysfs connector node
  drm/tilcdc: slave: fix dangling sysfs connector node
  drm/tilcdc: tfp410: fix dangling sysfs connector node
  drm/tilcdc: panel: fix leak when unloading the module
  drm/tilcdc: fix release order on exit
  drm/tilcdc: fix double kfree
  drm/tilcdc: remove submodule destroy calls
  drm/tilcdc: replace late_initcall with module_init

 drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
 drivers/gpu/drm/tilcdc/Module.symvers  |  0
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
 7 files changed, 59 insertions(+), 60 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers

-- 
2.0.0.rc2

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

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

--- Comment #2 from Marti Raudsepp  ---
Created attachment 100574
  --> https://bugs.freedesktop.org/attachment.cgi?id=100574=edit
steam.desktop.log

-- 
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/20140607/bb79c49a/attachment.html>

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

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

--- Comment #1 from Marti Raudsepp  ---
Created attachment 100573
  --> https://bugs.freedesktop.org/attachment.cgi?id=100573=edit
gdm-Xorg-:0.log

-- 
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/20140607/7921b7bf/attachment.html>

[Bug 79756] New: [Radeon] Resizing Steam windows freezes Xorg

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

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

  Priority: medium
Bug ID: 79756
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [Radeon] Resizing Steam windows freezes Xorg
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: marti at juffo.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 100572
  --> https://bugs.freedesktop.org/attachment.cgi?id=100572=edit
kernel.log

The gauntlet continues... After solving bug 79325, Steam now starts, but when I
try to resize any Steam windows, Xorg freezes: it does not react to keyboard
input (VT switching or num lock) and killing Steam doesn't unlock it. But the
mouse cursor still responds to mouse movements.

There is nothing in Xorg logs after the freeze. 

xorg-server 1.15.1
linux 3.15-rc8
linux-firmware a4f3bc03f1e7b1f25cc52328981c2a35871e55a1 (with PITCAIRN_mc2.bin)
xf86-video-ati 7.3.0
Tried ati-dri/mesa versions 10.2.0rc5 as well as 10.1.3
Tried glamor-egl git a4fbc7732a1e56de385f50b778aafbdd186e015c as well as 0.6.0
(patched with cccfea4454949e3e376be42bb230603848997195 per bug 79325)

gdb dump at the time of freeze:
(gdb) thread apply all bt

Thread 2 (Thread 0x7f34a3efd700 (LWP 630)):
#0  0x7f34ae00cb2f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f34a65679cb in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#2  0x7f34a6567117 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#3  0x7f34ae008124 in start_thread () from /usr/lib/libpthread.so.0
#4  0x7f34acd374bd in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f34aeac5880 (LWP 553)):
#0  0x7f34ae00f38c in __lll_lock_wait () from /usr/lib/libpthread.so.0
#1  0x7f34ae00ab3c in _L_lock_553 () from /usr/lib/libpthread.so.0
#2  0x7f34ae00a91a in pthread_mutex_lock () from /usr/lib/libpthread.so.0
#3  0x7f34aad16fae in eglCreateImageKHR () from /usr/lib/libEGL.so.1
#4  0x7f34aaf35e21 in glamor_egl_create_textured_pixmap () from
/usr/lib/xorg/modules/libglamoregl.so
#5  0x7f34a77e1ac0 in ?? () from
/usr/lib/xorg/modules/drivers/radeon_drv.so
#6  0x7f34a77e1e26 in ?? () from
/usr/lib/xorg/modules/drivers/radeon_drv.so
#7  0x7f34a77d8819 in ?? () from
/usr/lib/xorg/modules/drivers/radeon_drv.so
#8  0x005554c3 in ?? ()
#9  0x0055628f in ?? ()
#10 0x00556690 in DRI2GetBuffersWithFormat ()
#11 0x7f34a7c2e661 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#12 0x7f34a656383a in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#13 0x7f34a656190a in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#14 0x7f34a66baa2e in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#15 0x7f34a66bbb98 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#16 0x7f34a668d9c0 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#17 0x7f34a66a19d5 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#18 0x7f34a6676577 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#19 0x7f34a665d74c in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#20 0x7f34a66735d4 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#21 0x7f34a659d403 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
#22 0x7f34aad20fee in ?? () from /usr/lib/libEGL.so.1
#23 0x7f34aad193c5 in eglMakeCurrent () from /usr/lib/libEGL.so.1
#24 0x7f34aaf35c08 in glamor_egl_make_current () from
/usr/lib/xorg/modules/libglamoregl.so
#25 0x7f34aa8cdc69 in glamor_block_handler () from /usr/lib/libglamor.so.0
#26 0x0043ad64 in _CallCallbacks ()
#27 0x00588096 in WriteToClient ()
#28 0x7f34a7c13761 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#29 0x7f34a7c271d0 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#30 0x00435c8e in ?? ()
#31 0x00439aaa in ?? ()
#32 0x7f34acc6e000 in __libc_start_main () from /usr/lib/libc.so.6
#33 0x0042507e in _start ()

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)

[Andrew Morton]

On Fri, 6 Jun 2014 10:22:51 -0700 "Paul E. McKenney"  wrote:

> On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote:
> > From: Behalf Of Ken Helias
> > > All other add functions for lists have the new item as first argument and 
> > > the
> > > position where it is added as second argument. This was changed for no 
> > > good
> > > reason in this function and makes using it unnecessary confusing.
> > > 
> > > Also the naming of the arguments in hlist_add_after was confusing. It was
> > > changed to use the same names as hlist_add_after_rcu.
> > ...
> > > -static inline void hlist_add_after_rcu(struct hlist_node *prev,
> > > -struct hlist_node *n)
> > > +static inline void hlist_add_after_rcu(struct hlist_node *n,
> > > +struct hlist_node *prev)
> > 
> > It is rather a shame that the change doesn't generate a compilation
> > error for old source files.
> 
> I am also a bit concerned by this.
> 

yup.  hlist_add_behind()?