[PATCH drm-next v2] drm: udl: usb: Fix recursive Kconfig dependency

[Sedat Dilek]

In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.

In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:

$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL

Fix this by changing from select to depends on USB_SUPPORT in
"config DRM_USB".

This is a follow-up fix to df0b344300724e00db9fff7eb6406eb91f450b91
in Dave's drm-next GIT branch.

[ v2: Restore old status, but change from select to depends on USB_SUPPORT ]

Signed-off-by: Sedat Dilek 
---
 drivers/gpu/drm/Kconfig |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3a8c683..0cbdc45 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -22,9 +22,8 @@ menuconfig DRM
 config DRM_USB
tristate
depends on DRM
-   depends on USB_ARCH_HAS_HCD
+   depends on USB_SUPPORT && USB_ARCH_HAS_HCD
select USB
-   select USB_SUPPORT

 config DRM_KMS_HELPER
tristate
-- 
1.7.9.5

[PATCH drm-next] drm: udl: usb: Fix recursive Kconfig dependency

[Sedat Dilek]

In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.

In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:

$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL

Fix the issue by dropping "select USB_SUPPORT" from "config DRM_USB".

Signed-off-by: Sedat Dilek 
---
 drivers/gpu/drm/Kconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3a8c683..90e2808 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -24,7 +24,6 @@ config DRM_USB
depends on DRM
depends on USB_ARCH_HAS_HCD
select USB
-   select USB_SUPPORT

 config DRM_KMS_HELPER
tristate
-- 
1.7.9.5

[PATCH V3] drm: edid: add support for E-DDC

[Daniel Vetter]

On Fri, Aug 24, 2012 at 02:56:50PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
> 
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/drm_edid.c |   83 ---
>  1 files changed, 62 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..a10a130 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> int block, int len)
>  {
>   unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;

You can inline segFlags to the only place it's used.

>   int ret, retries = 5;
>  
>   /* The core i2c driver will automatically retry the transfer if the
> @@ -262,29 +264,68 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>* generate spurious NAKs and timeouts. Retrying the transfer
>* of the individual block a few times seems to overcome this.
>*/
> - do {
> - struct i2c_msg msgs[] = {
> - {
> - .addr   = DDC_ADDR,
> - .flags  = 0,
> - .len= 1,
> - .buf= ,
> - }, {
> - .addr   = DDC_ADDR,
> - .flags  = I2C_M_RD,
> - .len= len,
> - .buf= buf,
> + switch (segment) {
> + /* To reduce traffic on I2C, we request the i2c xfer
> +  * for segment addr only if 4 block edid data is
> +  * present.
> +  * 0 : DDC
> +  * 1 : E-DDC
> +  */

This comment is a bit misleading: We don't avoid the segment xfer to
reduce i2c traffic, but to avoid upsetting any non-compliant screens.

> + case 0:
> + do {

Keeping the loop as the outermost would imo be clearer and avoid
duplicating it (it also would make the patch a bit smaller). You could
even do a trick with the msgs array like this:

msgs[] = { full i2c xfer including segment addr}
xfers = 3;

/* Avoid sending the segment addr to not upset non-compliant ddc
 * monitors. */
if (!segments)
msgs++, len--;

i2c_transefer(adapter, msgs, len);

Also, I think it'd be good to set the IGNORE_NAK on the start addre
transfer, too (but in a separate patch). At least I think we've seen
screens out there that need this :(

Yours, Daniel

> + struct i2c_msg msgs[] = {
> + {
> + .addr   = DDC_ADDR,
> + .flags  = 0,
> + .len= 1,
> + .buf= ,
> + }, {
> + .addr   = DDC_ADDR,
> + .flags  = I2C_M_RD,
> + .len= len,
> + .buf= buf,
> + }
> + };
> + ret = i2c_transfer(adapter, msgs, 2);
> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent 
> adapter %s\n",
> + adapter->name);
> + break;
>   }
> - };
> - ret = i2c_transfer(adapter, msgs, 2);
> - if (ret == -ENXIO) {
> - DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> - adapter->name);
> - break;
> - }
> - } while (ret != 2 && --retries);
> + } while (ret != 2 && --retries);
> +
> + return ret == 2 ? 0 : -1;
> + case 1:
> + do {
> + struct i2c_msg msgs[] = {
> + { /*set segment pointer */
> + .addr   = DDC_SEGMENT_ADDR,
> + .flags  = segFlags,
> + .len= 1,
> + .buf= ,
> + }, { /*set offset */
> + .addr   = DDC_ADDR,
> + 

[Bug 54002] Massive screen corruption with MLAA on Cayman

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

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

--- Comment #13 from Vadim Girlin  2012-08-24 19:24:25 UTC 
---
(In reply to comment #12)
> (In reply to comment #11)
> I fully understand what the commit did. But I don't think MLAA should make the
> screen look like this, else nobody should enable it, so it's useless. Don't 
> you
> agree?

I think it should be enabled for some graphical applications only (games etc),
not for all applications by default. drirc allows to use different settings for
specific apps based on the executable name.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption with MLAA on Cayman

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

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

--- Comment #12 from Thomas Rohloff  2012-08-24 18:43:22 
UTC ---
(In reply to comment #11)
I fully understand what the commit did. But I don't think MLAA should make the
screen look like this, else nobody should enable it, so it's useless. Don't you
agree?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2] drm/exynos: make sure that hardware overlay for fimd is disabled

[Inki Dae]

Changelog v2:
wait for VSYNC instead of BACKPORCH.

Changelog v1:
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..478100e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data->enabled = false;
 }

+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+   int ret;
+
+   ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
+   VIDCON1_VSTATUS_VSYNC), 50);
+   if (ret < 0)
+   DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
 static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+   .wait_for_vblank = fimd_wait_for_vblank,
 };

 static struct exynos_drm_manager fimd_manager = {
-- 
1.7.4.1

[PATCH] drm/exynos: fixed a issue that plane isn't disabled when released

[Inki Dae]

when drm is released, drm framebuffers are released and all crtcs using
same framebuffer and also all gem buffers used but plane isn't disabled
so when crtc and encoder are turned on, overlay can access to invalid memory
because plane still has memory address released already.
this patch makes sure that each plane is disabled when released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 92f9acf..96a10c3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -214,12 +214,27 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
manager_ops->commit(manager->dev);
 }

+static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
+{
+   struct drm_plane *plane;
+   struct drm_device *dev = encoder->dev;
+
+   exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+
+   /* all planes connected to this encoder should be also disabled. */
+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->crtc == encoder->crtc)
+   plane->funcs->disable_plane(plane);
+   }
+}
+
 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
.dpms   = exynos_drm_encoder_dpms,
.mode_fixup = exynos_drm_encoder_mode_fixup,
.mode_set   = exynos_drm_encoder_mode_set,
.prepare= exynos_drm_encoder_prepare,
.commit = exynos_drm_encoder_commit,
+   .disable= exynos_drm_encoder_disable,
 };

 static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
-- 
1.7.4.1

[Bug 54002] Massive screen corruption with MLAA on Cayman

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

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

--- Comment #11 from Vadim Girlin  2012-08-24 18:26:44 UTC 
---
(In reply to comment #7)
> Created attachment 66074 [details]
> My .drirc
> 
> The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use 
> driver
> name for driconf section lookup ) which sounds a bit weird.
> So I'm uploading my .drirc

That commit makes mesa use real driver name ("r600") when it selects the device
section from drirc. Before that patch "dri" was used instead. As long as your
drirc doesn't have "dri" section (there are "r600" and "dri2"), then I think it
was not used at all, so defaults were used. And now the settings from the
"r600" section were activated after that commit.

Probably you tried to enable MLAA earlier, that's why it was turned on in your
drirc (but not active before that patch). I'm not sure how the MLAA should
work, but your screenshot looks really antialiased, so probably it works now.

You might want to try removing/renaming '.drirc' to use default settings again,
if you aren't sure how to restore correct settings manually. Also you might use
'driconf' utility that will create '.drirc' with default settings for you if it
doesn't exist.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption with MLAA on Cayman

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

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

Thomas Rohloff  changed:

   What|Removed |Added

Summary|Massive screen corruption   |Massive screen corruption
   |on Cayman   |with MLAA on Cayman

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #10 from Thomas Rohloff  2012-08-24 17:39:49 
UTC ---
with both, ""pp_jimenezmlaa_color" and "pp_jimenezmlaa" setted to 0 it seems to
be fixed completely. But I don't think activated MLAA should cause this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH V3] drm: edid: add support for E-DDC

[Shirish S]

  if (ret == -ENXIO) {
> > - DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > - adapter->name);
> > - break;
> > - }
> > - } while (ret != 2 && --retries);
> > + } while (ret != 2 && --retries);
> > +
> > + return ret == 2 ? 0 : -1;
> > + case 1:
> > + do {
> > + struct i2c_msg msgs[] = {
> > + { /*set segment pointer */
> > + .addr   = DDC_SEGMENT_ADDR,
> > + .flags  = segFlags,
> > + .len= 1,
> > + .buf= ,
> > + }, { /*set offset */
> > + .addr   = DDC_ADDR,
> > + .flags  = 0,
> > + .len= 1,
> > + .buf= ,
> > + }, { /*set data */
> > + .addr   = DDC_ADDR,
> > + .flags  = I2C_M_RD,
> > + .len= len,
> > + .buf= buf,
> > + }
> > + };
> > + ret = i2c_transfer(adapter, msgs, 3);
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > + adapter->name);
> > + break;
> > + }
> > +     } while (ret != 3 && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == 3 ? 0 : -1;
> > + }
> > + return -1;
> >  }
> >
> >  static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/a5ac9def/attachment-0001.html>

[ANNOUNCE] libdrm 2.4.39

[Marek Olšák]

Dave Airlie (1):
  radeon: add prime import/export support

Kenneth Graunke (1):
  intel: Use VG_CLEAR on the context destroy ioctl as well.

Marek Ol??k (3):
  radeon: fix allocation of MSAA surfaces on r600-r700
  radeon: align r600 msaa buffers to a multiple of macrotile size
* num samples
  configure: bump version for 2.4.39 release

Tobias Klausmann (1):
  tests/modetest: Add a forgotten return, needed for opensuse buildservice

V?ctor Manuel J?quez Leal (1):
  omap: include omap_drm.h independently

git tag: libdrm-2.4.39

http://dri.freedesktop.org/www/libdrm/libdrm-2.4.39.tar.bz2
MD5:  9a299e021d81bab6c82307582c78319d  libdrm-2.4.39.tar.bz2
SHA1: c0e841850d7164c63d36f486ca3a64040357660e  libdrm-2.4.39.tar.bz2
SHA256: 386b17388980504bca16ede81ceed4c77b12c3488f46ecb7f4d48e48512a733d
 libdrm-2.4.39.tar.bz2

http://dri.freedesktop.org/www/libdrm/libdrm-2.4.39.tar.gz
MD5:  0ae70ae6dc844d77d20c7fca73041dd3  libdrm-2.4.39.tar.gz
SHA1: 44914018a8f6909bffc2cfd47df1d9c9f030db25  libdrm-2.4.39.tar.gz
SHA256: ceba26bf02900c27eed6f88d263274375223a091c3e1960598775df28878
 libdrm-2.4.39.tar.gz

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #9 from Thomas Rohloff  2012-08-24 17:04:04 
UTC ---
Well, it's reduced to a minimum, not solved. Need some more testing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #8 from Thomas Rohloff  2012-08-24 17:00:50 
UTC ---
If I set "pp_jimenezmlaa_color" to "0" everything is fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #7 from Thomas Rohloff  2012-08-24 16:53:47 
UTC ---
Created attachment 66074
  --> https://bugs.freedesktop.org/attachment.cgi?id=66074
My .drirc

The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use driver
name for driconf section lookup ) which sounds a bit weird.
So I'm uploading my .drirc

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

drm/nouveau: Work around a crash during boot if noaccel is set.

[Ortwin Glück]

NB: still broken in 3.5 as well.

Signed-off-by: Ortwin Gl?ck 
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device 
*dev, int crtc)
struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;

+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR "NULL software engine\n");
+return;
+}
+
list_for_each_entry_safe(pch, tmp, >vblank, vblank.list) {
if (pch->vblank.head != crtc)
continue;

[Bug 38472] Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume

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

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





--- Comment #8 from Alex Deucher   2012-08-24 
16:42:47 ---
I think this is an issue with the drm fb helper.  Since fb doesn't handle
multiple heads we only expose the smallest to the fb layer so the "extra" space
on the larger heads never gets re-initialized on resume.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38472] Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume

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

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


Alan  changed:

   What|Removed |Added

 Kernel Version|3.0-rc5 |3.5.2




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36892] page faults / general protection faults under heavy 3d load

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

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





--- Comment #9 from Alan   2012-08-24 16:36:07 ---
The page allocation warnings are fine (and just warnings that perhaps the VM
needs further tuning)

The only oddity is this

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36892] page faults / general protection faults under heavy 3d load

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

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


Alan  changed:

   What|Removed |Added

  Attachment #78381|application/octet-stream|text/plain
  mime type||




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38472] Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume

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

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





--- Comment #7 from boris64   2012-08-24 
16:29:21 ---
Yes, it's still there on kernel-3.5.2

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36672] Kernel crashes when radeon is switched off with vga_switcheroo

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

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2012-08-24 
15:41:26 ---
Is this still an issue on a newer kernel?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 2/2] drm/radeon/atom: rework DIG modesetting on DCE3+

[alexdeuc...@gmail.com]

From: Alex Deucher 

The ordering is important and the current drm code
wasn't cutting it for modern DIG encoders.  We need
to have information about crtc before setting up
the encoders so I've shifted the ordering a bit.
Probably we'll need a full rework akin to danvet's
recent intel patchs.  This patch fixes numerous
issues with DP bridge chips and makes link training
much more reliable.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |  109 
 1 files changed, 47 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index f9bc27f..4a7f95e 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1379,6 +1379,8 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct drm_encoder *ext_encoder = radeon_get_external_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
struct radeon_connector *radeon_connector = NULL;
struct radeon_connector_atom_dig *radeon_dig_connector = NULL;
@@ -1390,19 +1392,37 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
*encoder, int mode)

switch (mode) {
case DRM_MODE_DPMS_ON:
-   /* some early dce3.2 boards have a bug in their transmitter 
control table */
-   if ((rdev->family == CHIP_RV710) || (rdev->family == 
CHIP_RV730) ||
-   ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
-   if (ASIC_IS_DCE6(rdev)) {
-   /* It seems we need to call 
ATOM_ENCODER_CMD_SETUP again
-* before reenabling encoder on DPMS ON, 
otherwise we never
-* get picture
-*/
-   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+   if (!connector)
+   dig->panel_mode = 
DP_PANEL_MODE_EXTERNAL_DP_MODE;
+   else
+   dig->panel_mode = 
radeon_dp_get_panel_mode(encoder, connector);
+
+   /* setup and enable the encoder */
+   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
+   atombios_dig_encoder_setup(encoder,
+  
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
+  dig->panel_mode);
+   if (ext_encoder) {
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE61(rdev))
+   
atombios_external_encoder_setup(encoder, ext_encoder,
+   
EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
}
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
-   } else {
+   } else if (ASIC_IS_DCE4(rdev)) {
+   /* setup and enable the encoder */
+   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
+   /* enable the transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
+   } else {
+   /* setup and enable the encoder and transmitter */
+   atombios_dig_encoder_setup(encoder, ATOM_ENABLE, 0);
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
+   /* some early dce3.2 boards have a bug in their 
transmitter control table */
+   if ((rdev->family != CHIP_RV710) || (rdev->family != 
CHIP_RV730))
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
}
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && 
connector) {
if (connector->connector_type == 
DRM_MODE_CONNECTOR_eDP) {
@@ -1420,10 +1440,19 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
*encoder, int mode)
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case 

[PATCH 1/2] drm/radeon: don't disable plls that are in use by other crtcs

[alexdeuc...@gmail.com]

From: Alex Deucher 

Some plls are shared for DP.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index bcc5cd3..6b274ff 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1722,9 +1722,22 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_atom_ss ss;
+   int i;

atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);

+   for (i = 0; i < rdev->num_crtc; i++) {
+   if (rdev->mode_info.crtcs[i] &&
+   rdev->mode_info.crtcs[i]->enabled &&
+   i != radeon_crtc->crtc_id &&
+   radeon_crtc->pll_id == rdev->mode_info.crtcs[i]->pll_id) {
+   /* one other crtc is using this pll don't turn
+* off the pll
+*/
+   goto done;
+   }
+   }
+
switch (radeon_crtc->pll_id) {
case ATOM_PPLL1:
case ATOM_PPLL2:
@@ -1741,6 +1754,7 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
default:
break;
}
+done:
radeon_crtc->pll_id = -1;
 }

-- 
1.7.7.5

[Bug 39612] radeon blocks with new style fencing

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||alan at lxorguk.ukuu.org.uk




--- Comment #3 from Alan   2012-08-24 15:33:20 ---
Is this still needing workarounds or can I close it ?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38472] Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume

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

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #6 from Alex Deucher   2012-08-24 
15:32:26 ---
Is this still an issue with a newer kernel?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38792] Radeon HD 5750: GPU lockup CP stall while browsing in Firefox

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

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


Alan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38622] [radeon cayman regresion] artefacts on screen

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38592] Booting Radeon KMS In Newer Kernels Causes Kernel Output To Be In The Center Of Screen

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 Kernel Version||2.6.37
 AssignedTo|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org




--- Comment #17 from Das   2011-07-04 04:31:09 ---
Created an attachment (id=64542)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=64542)
dmesg-37.6-(text)

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38472] Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Console/Framebuffers|Video(DRI - non Intel)
 AssignedTo|jsimmons at infradead.org  |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38432] radeon crash on startup (hd4330)

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(AGP)  |Video(DRI - non Intel)
 AssignedTo|airlied at linux.ie|drivers_video-dri at 
kernel-bu
   ||gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 38382] radeon: wait for empty RBBM fifo failed

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||DOCUMENTED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 37762] No display when resuming on HP DV6 dual radeon laptop

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH V3] drm: edid: add support for E-DDC

[Shirish S]

The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_edid.c |   83 ---
 1 files changed, 62 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..a10a130 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
int ret, retries = 5;

/* The core i2c driver will automatically retry the transfer if the
@@ -262,29 +264,68 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
 * generate spurious NAKs and timeouts. Retrying the transfer
 * of the individual block a few times seems to overcome this.
 */
-   do {
-   struct i2c_msg msgs[] = {
-   {
-   .addr   = DDC_ADDR,
-   .flags  = 0,
-   .len= 1,
-   .buf= ,
-   }, {
-   .addr   = DDC_ADDR,
-   .flags  = I2C_M_RD,
-   .len= len,
-   .buf= buf,
+   switch (segment) {
+   /* To reduce traffic on I2C, we request the i2c xfer
+* for segment addr only if 4 block edid data is
+* present.
+* 0 : DDC
+* 1 : E-DDC
+*/
+   case 0:
+   do {
+   struct i2c_msg msgs[] = {
+   {
+   .addr   = DDC_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= ,
+   }, {
+   .addr   = DDC_ADDR,
+   .flags  = I2C_M_RD,
+   .len= len,
+   .buf= buf,
+   }
+   };
+   ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent 
adapter %s\n",
+   adapter->name);
+   break;
}
-   };
-   ret = i2c_transfer(adapter, msgs, 2);
-   if (ret == -ENXIO) {
-   DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
-   adapter->name);
-   break;
-   }
-   } while (ret != 2 && --retries);
+   } while (ret != 2 && --retries);
+
+   return ret == 2 ? 0 : -1;
+   case 1:
+   do {
+   struct i2c_msg msgs[] = {
+   { /*set segment pointer */
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = segFlags,
+   .len= 1,
+   .buf= ,
+   }, { /*set offset */
+   .addr   = DDC_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= ,
+   }, { /*set data */
+   .addr   = DDC_ADDR,
+   .flags  = I2C_M_RD,
+   .len= len,
+   .buf= buf,
+   }
+   };
+   ret = i2c_transfer(adapter, msgs, 3);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent 
adapter %s\n",
+   adapter->name);
+   break;
+   }
+   } while (ret != 3 && --retries);

-   return ret == 2 ? 0 : -1;
+   return ret == 3 ? 0 : -1;
+   }
+   return -1;
 }

 static 

[PATCH V3] drm: edid: add support for E-DDC

[Shirish S]

This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V2:
Add switch for DDC and E-DDC

Based on drm-next branch


Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   87 
 1 files changed, 64 insertions(+), 23 deletions(-)

[PATCH] drm/prime: fixup the dma buf export cache locking

[Daniel Vetter]

On Fri, Aug 24, 2012 at 02:13:33PM +1000, Dave Airlie wrote:
> On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter  
> wrote:
> > Well, actually add some, because currently there's exactly none:
> > - in handle_to_fd we only take the file_priv's prime lock, but the
> >   underlying gem object we're exporting isn't per-file.
> > - in each driver's dma_buf->release callback we don't grab any locks
> >   at all.
> 
> Finally got to this patch and applied it to my test box and it
> explodes in the following
> 
> start X, bind udl as an output slave, set a mode on the udl, then kill
> the X server,
> 
> I get an oops on i915/radeon/nouveau, like

I have to admit that I don't see what's happening here :( But thinking
some more about the locking issues and race my patch tried to fix I
concluded that it's the wrong approach anyway - we still have ugly issues
left. The fundamental problem is that for the exporter we have 2
refcounts, the gem refcount and the dma_buf refcount, but we should only
destroy the gem object + it's dma_buf export if both are 0. And keep
everything around otherwise to avoid nasty issues with re-export or
reaping userspace-facing resources like the mmap_offset. But I haven't yet
grown clue how to handle this any better.

Slightly related: Jani discovered that we seem to have a leak, putting him
on cc just in case he's the one with clue ;-)

I've looked again at the other two patches inspired by this one, which fix
some races between gem names & gem flink. And I think those two are still
valid.

Yours, Daniel
> 
> [ 8046.363596] general protection fault:  [#1] SMP
> [ 8046.364012] Modules linked in: fuse lockd rfcomm sunrpc bnep
> tpm_bios ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
> ip6_tables nf_conntrack_
> ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_conexant arc4
> iwldvm mac80211 coretemp kvm_intel snd_hda_intel snd_hda_codec kvm
> btusb snd_hwdep bluet
> ooth iwlwifi i915 snd_seq snd_seq_device microcode snd_pcm cfg80211
> snd_page_alloc i2c_i801 lpc_ich e1000e mfd_core snd_timer wmi
> thinkpad_acpi snd soundcore
> rfkill video uinput sdhci_pci sdhci udl syscopyarea sysfillrect
> sysimgblt firewire_ohci mmc_core drm_usb firewire_core crc_itu_t
> yenta_socket radeon i2c_algo_
> bit drm_kms_helper ttm drm i2c_core
> [ 8046.364012] CPU 0
> [ 8046.364012] Pid: 6947, comm: Xorg Tainted: GW3.6.0-rc3+
> #7 LENOVO 406334M/406334M
> [ 8046.364012] RIP: 0010:[]  []
> i915_gem_unmap_dma_buf+0x5c/0xb0 [i915]
> [ 8046.364012] RSP: 0018:88002c22dc28  EFLAGS: 00010296
> [ 8046.364012] RAX: 0500 RBX: 880007d5d6d8 RCX: 
> 
> [ 8046.364012] RDX: 0500 RSI: 8800570ca000 RDI: 
> 88005b2ea5a8
> [ 8046.364012] RBP: 88002c22dc68 R08:  R09: 
> 
> [ 8046.364012] R10:  R11: 0001 R12: 
> 88005b2ea5a8
> [ 8046.364012] R13:  R14: 6b6b6b6b6b6b6b6b R15: 
> 8800570ca000
> [ 8046.364012] FS:  7f79955759c0() GS:880078c0()
> knlGS:
> [ 8046.364012] CS:  0010 DS:  ES:  CR0: 80050033
> [ 8046.364012] CR2: 0031808bab90 CR3: 01c0b000 CR4: 
> 07f0
> [ 8046.364012] DR0:  DR1:  DR2: 
> 
> [ 8046.364012] DR3:  DR6: 0ff0 DR7: 
> 0400
> [ 8046.364012] Process Xorg (pid: 6947, threadinfo 88002c22c000,
> task 88005d68)
> [ 8046.364012] Stack:
> [ 8046.364012]  880058d167b0 88000500 88002c22dc48
> 88005f6f0f50
> [ 8046.364012]  88005d9622f8 88005d962290 
> 
> [ 8046.364012]  88002c22dc78 81409182 88002c22dc98
> a002cfeb
> [ 8046.364012] Call Trace:
> [ 8046.364012]  [] dma_buf_unmap_attachment+0x22/0x40
> [ 8046.364012]  [] drm_prime_gem_destroy+0x2b/0x50 [drm]
> [ 8046.364012]  [] udl_gem_free_object+0x39/0x70 [udl]
> [ 8046.364012]  [] drm_gem_object_free+0x2a/0x30 [drm]
> [ 8046.364012]  []
> drm_gem_object_release_handle+0xa8/0xd0 [drm]
> [ 8046.364012]  [] idr_for_each+0xe5/0x180
> [ 8046.364012]  [] ? drm_gem_vm_open+0x70/0x70 [drm]
> [ 8046.364012]  [] ? trace_hardirqs_on+0xd/0x10
> [ 8046.364012]  [] drm_gem_release+0x24/0x40 [drm]
> [ 8046.364012]  [] drm_release+0x55a/0x5f0 [drm]
> [ 8046.364012]  [] __fput+0xfa/0x2d0
> [ 8046.364012]  [] fput+0xe/0x10
> [ 8046.364012]  [] task_work_run+0x69/0xa0
> [ 8046.364012]  [] do_exit+0xa0e/0xb20
> [ 8046.364012]  [] ? retint_swapgs+0x13/0x1b
> [ 8046.364012]  [] do_group_exit+0x4c/0xc0
> 
> which implies some reference count is off or some object is freed in
> the wrong order.
> 
> Dave.

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 37502] Kernels oops display in X leaves screen garbled

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Daniel Vetter]

On Fri, Aug 24, 2012 at 07:56:31AM -0400, Calvin Walton wrote:
> This board is incorrectly detected as having an LVDS connector,
> resulting in the VGA output (the only available output on the board)
> showing the console only in the top-left 1024x768 pixels, and an extra
> LVDS connector appearing in X.
> 
> It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
> chipset.
> 
> I've had this board for about a year, but this is the first time I
> noticed the issue because I've been running it headless for most of its
> life.
> 
> Signed-off-by: Calvin Walton 

Looks good, applied to -fixes.
-Daniel
> ---
> 
> This board:
> http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp
> 
> If you want any additional debug output from this machine, let me know
> what you would like and how to find it.
> 
> I think this patch would probably be a reasonable candidate for -stable?
> 
>  drivers/gpu/drm/i915/intel_lvds.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 08eb04c..2c58310 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
>   DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
>   },
>   },
> + {
> + .callback = intel_no_lvds_dmi_callback,
> + .ident = "Gigabyte GA-D525TUD",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., 
> Ltd."),
> + DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
> + },
> + },
>  
>   { } /* terminating entry */
>  };
> -- 
> 1.7.12
> 
> -- 
> Calvin Walton 
> 

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 37362] vgaswitcheroo : switch from intel to ati impossible

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||WILL_FIX_LATER




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 37032] DRM_RADEON=m with CONFIG_FB=y fails

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36892] page faults / general protection faults under heavy 3d load

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

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


Niels Ole Salscheider  changed:

   What|Removed |Added

  Attachment #61052|0   |1
is obsolete||
  Attachment #61062|0   |1
is obsolete||
  Attachment #61072|0   |1
is obsolete||
  Attachment #61082|0   |1
is obsolete||




--- Comment #8 from Niels Ole Salscheider   
2012-08-24 14:30:17 ---
Created an attachment (id=78381)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=78381)
dmesg output for 3.6-rc1

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36892] page faults / general protection faults under heavy 3d load

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

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


Niels Ole Salscheider  changed:

   What|Removed |Added

 Kernel Version|3.0-rc1 |3.6-rc1




--- Comment #7 from Niels Ole Salscheider   
2012-08-24 14:29:42 ---
I have just tried to run "sauerbraten" under 3.6-rc1. It seems to work fine,
but I get page allocation failure messages in dmesg, see attachment.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

[Marek Olšák]

Checking of the second colorbuffer was skipped on r700, because
CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff,
so we must set the number of samples of the second colorbuffer to 1 in order
to pass the CS checker.
The DRM version is bumped, because RESOLVE_BOX is always rejected without this
fix on r600.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/r600_cs.c |   19 +--
 drivers/gpu/drm/radeon/r600d.h   |8 
 drivers/gpu/drm/radeon/radeon_drv.c  |3 ++-
 drivers/gpu/drm/radeon/reg_srcs/r600 |1 -
 4 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 8866937..f37676d 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -63,6 +63,7 @@ struct r600_cs_track {
u32 cb_color_size_idx[8]; /* unused */
u32 cb_target_mask;
u32 cb_shader_mask;  /* unused */
+   boolis_resolve;
u32 cb_color_size[8];
u32 vgt_strmout_en;
u32 vgt_strmout_buffer_en;
@@ -321,6 +322,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)
track->cb_color_tile_offset[i] = 0x;
track->cb_color_mask[i] = 0x;
}
+   track->is_resolve = false;
track->nsamples = 16;
track->log_nsamples = 4;
track->cb_target_mask = 0x;
@@ -359,6 +361,8 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)
volatile u32 *ib = p->ib.ptr;
unsigned array_mode;
u32 format;
+   /* When resolve is used, the second colorbuffer has always 1 sample. */
+   unsigned nsamples = track->is_resolve && i == 1 ? 1 : track->nsamples;

size = radeon_bo_size(track->cb_color_bo[i]) - 
track->cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track->cb_color_info[i]);
@@ -382,7 +386,7 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)
array_check.group_size = track->group_size;
array_check.nbanks = track->nbanks;
array_check.npipes = track->npipes;
-   array_check.nsamples = track->nsamples;
+   array_check.nsamples = nsamples;
array_check.blocksize = r600_fmt_get_blocksize(format);
if (r600_get_array_mode_alignment(_check,
  _align, _align, 
_align, _align)) {
@@ -428,7 +432,7 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)

/* check offset */
tmp = r600_fmt_get_nblocksy(format, height) * 
r600_fmt_get_nblocksx(format, pitch) *
- r600_fmt_get_blocksize(format) * track->nsamples;
+ r600_fmt_get_blocksize(format) * nsamples;
switch (array_mode) {
default:
case V_0280A0_ARRAY_LINEAR_GENERAL:
@@ -799,6 +803,12 @@ static int r600_cs_track_check(struct radeon_cs_parser *p)
 */
if (track->cb_dirty) {
tmp = track->cb_target_mask;
+
+   /* We must check both colorbuffers for RESOLVE. */
+   if (track->is_resolve) {
+   tmp |= 0xff;
+   }
+
for (i = 0; i < 8; i++) {
if ((tmp >> (i * 4)) & 0xF) {
/* at least one component is enabled */
@@ -1288,6 +1298,11 @@ static int r600_cs_check_reg(struct radeon_cs_parser *p, 
u32 reg, u32 idx)
track->nsamples = 1 << tmp;
track->cb_dirty = true;
break;
+   case R_028808_CB_COLOR_CONTROL:
+   tmp = G_028808_SPECIAL_OP(radeon_get_ib_value(p, idx));
+   track->is_resolve = tmp == V_028808_SPECIAL_RESOLVE_BOX;
+   track->cb_dirty = true;
+   break;
case R_0280A0_CB_COLOR0_INFO:
case R_0280A4_CB_COLOR1_INFO:
case R_0280A8_CB_COLOR2_INFO:
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index bdb69a6..fa6f370 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -66,6 +66,14 @@
 #defineCC_RB_BACKEND_DISABLE   0x98F4
 #defineBACKEND_DISABLE(x)  ((x) << 
16)

+#define R_028808_CB_COLOR_CONTROL  0x28808
+#define   S_028808_SPECIAL_OP(x)   (((x) & 0x7) << 4)
+#define   G_028808_SPECIAL_OP(x)   (((x) >> 4) & 0x7)
+#define   C_028808_SPECIAL_OP  0xFF8F
+#define V_028808_SPECIAL_NORMAL 0x00
+#define V_028808_SPECIAL_DISABLE0x01
+#define V_028808_SPECIAL_RESOLVE_BOX0x07
+
 #defineCB_COLOR0_BASE  0x28040
 #define

[PATCH] drm/prime: fixup the dma buf export cache locking

[Dave Airlie]

On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter  
wrote:
> Well, actually add some, because currently there's exactly none:
> - in handle_to_fd we only take the file_priv's prime lock, but the
>   underlying gem object we're exporting isn't per-file.
> - in each driver's dma_buf->release callback we don't grab any locks
>   at all.

Finally got to this patch and applied it to my test box and it
explodes in the following

start X, bind udl as an output slave, set a mode on the udl, then kill
the X server,

I get an oops on i915/radeon/nouveau, like

[ 8046.363596] general protection fault:  [#1] SMP
[ 8046.364012] Modules linked in: fuse lockd rfcomm sunrpc bnep
tpm_bios ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
ip6_tables nf_conntrack_
ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_conexant arc4
iwldvm mac80211 coretemp kvm_intel snd_hda_intel snd_hda_codec kvm
btusb snd_hwdep bluet
ooth iwlwifi i915 snd_seq snd_seq_device microcode snd_pcm cfg80211
snd_page_alloc i2c_i801 lpc_ich e1000e mfd_core snd_timer wmi
thinkpad_acpi snd soundcore
rfkill video uinput sdhci_pci sdhci udl syscopyarea sysfillrect
sysimgblt firewire_ohci mmc_core drm_usb firewire_core crc_itu_t
yenta_socket radeon i2c_algo_
bit drm_kms_helper ttm drm i2c_core
[ 8046.364012] CPU 0
[ 8046.364012] Pid: 6947, comm: Xorg Tainted: GW3.6.0-rc3+
#7 LENOVO 406334M/406334M
[ 8046.364012] RIP: 0010:[]  []
i915_gem_unmap_dma_buf+0x5c/0xb0 [i915]
[ 8046.364012] RSP: 0018:88002c22dc28  EFLAGS: 00010296
[ 8046.364012] RAX: 0500 RBX: 880007d5d6d8 RCX: 
[ 8046.364012] RDX: 0500 RSI: 8800570ca000 RDI: 88005b2ea5a8
[ 8046.364012] RBP: 88002c22dc68 R08:  R09: 
[ 8046.364012] R10:  R11: 0001 R12: 88005b2ea5a8
[ 8046.364012] R13:  R14: 6b6b6b6b6b6b6b6b R15: 8800570ca000
[ 8046.364012] FS:  7f79955759c0() GS:880078c0()
knlGS:
[ 8046.364012] CS:  0010 DS:  ES:  CR0: 80050033
[ 8046.364012] CR2: 0031808bab90 CR3: 01c0b000 CR4: 07f0
[ 8046.364012] DR0:  DR1:  DR2: 
[ 8046.364012] DR3:  DR6: 0ff0 DR7: 0400
[ 8046.364012] Process Xorg (pid: 6947, threadinfo 88002c22c000,
task 88005d68)
[ 8046.364012] Stack:
[ 8046.364012]  880058d167b0 88000500 88002c22dc48
88005f6f0f50
[ 8046.364012]  88005d9622f8 88005d962290 

[ 8046.364012]  88002c22dc78 81409182 88002c22dc98
a002cfeb
[ 8046.364012] Call Trace:
[ 8046.364012]  [] dma_buf_unmap_attachment+0x22/0x40
[ 8046.364012]  [] drm_prime_gem_destroy+0x2b/0x50 [drm]
[ 8046.364012]  [] udl_gem_free_object+0x39/0x70 [udl]
[ 8046.364012]  [] drm_gem_object_free+0x2a/0x30 [drm]
[ 8046.364012]  []
drm_gem_object_release_handle+0xa8/0xd0 [drm]
[ 8046.364012]  [] idr_for_each+0xe5/0x180
[ 8046.364012]  [] ? drm_gem_vm_open+0x70/0x70 [drm]
[ 8046.364012]  [] ? trace_hardirqs_on+0xd/0x10
[ 8046.364012]  [] drm_gem_release+0x24/0x40 [drm]
[ 8046.364012]  [] drm_release+0x55a/0x5f0 [drm]
[ 8046.364012]  [] __fput+0xfa/0x2d0
[ 8046.364012]  [] fput+0xe/0x10
[ 8046.364012]  [] task_work_run+0x69/0xa0
[ 8046.364012]  [] do_exit+0xa0e/0xb20
[ 8046.364012]  [] ? retint_swapgs+0x13/0x1b
[ 8046.364012]  [] do_group_exit+0x4c/0xc0

which implies some reference count is off or some object is freed in
the wrong order.

Dave.

[Bug 46713] HDMI audio played back at a wrong rate

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

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

--- Comment #31 from Tvrtko Ursulin  2012-08-24 
13:46:28 UTC ---
Just testing with 3.6.0-rc3+ from today's GIT and I can reproduce some sort of
sound corruption depending on the video output resolution.

For example, 1360x768 and audio plays fine, while 1366x768 and it is bad.

avivotool register dump says this is the difference between good and bad setup:

-EVERGREEN_AUDIO_PLL1_DIV   000d0bd8
+EVERGREEN_AUDIO_PLL1_DIV   000d1ae2

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36892] page faults / general protection faults under heavy 3d load

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||alan at lxorguk.ukuu.org.uk




--- Comment #6 from Alan   2012-08-24 13:41:21 ---
Is this still seen on modern (3.2+) kernels ?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36672] Kernel crashes when radeon is switched off with vga_switcheroo

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36642] Oops on vgaswitcheroo from intel IGD to radeon DIS.

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||INSUFFICIENT_DATA




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #6 from Thomas Rohloff  2012-08-24 12:44:33 
UTC ---
Okay, found a good commit and am bisecting. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #7 from Alan   2012-08-24 12:44:13 ---
If this is still seen in modern (3.2+) kernels, please re-open thanks

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #5 from Thomas Rohloff  2012-08-24 12:12:28 
UTC ---
Created attachment 66063
  --> https://bugs.freedesktop.org/attachment.cgi?id=66063
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #4 from Thomas Rohloff  2012-08-24 12:11:38 
UTC ---
Created attachment 66062
  --> https://bugs.freedesktop.org/attachment.cgi?id=66062
Xorg.0.log

(In reply to comment #3)
> Can you isolate which update caused the problem?
I don't remember the version of mesa before and it's not in the emerge.log
(gentoo). But I'll try my best to get it. If you have any ideas feel free to
share them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/exynos: fixed a issue that plane isn't disabled when released

[Paul Menzel]

Dear Inki,


Am Freitag, den 24.08.2012, 18:27 +0900 schrieb Inki Dae:

You can shorten the commit summary by leaving out the word issue, which
is redundant. Maybe one of the following? I do not understand the
process of releasing so it might be wrong.

drm/exynos: Disable plane after release
drm/exynos: Disable plane when being released
drm/exynos: Fix disabling of plane when released

> when drm is released, drm framebuffers are released and all crtcs using
> same framebuffer and also all gem buffers used but plane isn't disabled
> so when crtc and encoder are turned on, overlay can access to invalid memory
> because plane still has memory address released already.
> this patch makes sure that each plane is disabled when released.

Please use sentences to make it easier to understand.

Also describe the solution. Maybe something like this.

This patch ensures that each plane is disabled when released, by
adding a new function and adding that to the helper functions.

Is there a report for that issue? Did you experience it in your setup?
Is this tested?

> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index 92f9acf..96a10c3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -214,12 +214,27 @@ static void exynos_drm_encoder_commit(struct 
> drm_encoder *encoder)
>   manager_ops->commit(manager->dev);
>  }
>  
> +static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct drm_plane *plane;
> + struct drm_device *dev = encoder->dev;
> +
> + exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
> +
> + /* all planes connected to this encoder should be also disabled. */
> + list_for_each_entry(plane, >mode_config.plane_list, head) {
> + if (plane->crtc == encoder->crtc)
> + plane->funcs->disable_plane(plane);
> + }
> +}
> +
>  static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
>   .dpms   = exynos_drm_encoder_dpms,
>   .mode_fixup = exynos_drm_encoder_mode_fixup,
>   .mode_set   = exynos_drm_encoder_mode_set,
>   .prepare= exynos_drm_encoder_prepare,
>   .commit = exynos_drm_encoder_commit,
> + .disable= exynos_drm_encoder_disable,
>  };
>  
>  static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/050eff0d/attachment.pgp>

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #3 from Michel D?nzer  2012-08-24 12:02:27 
UTC ---
> I just updated mesa, libdrm snd the xf86-video-radeon to the newest git
> versions and now my screen is massivly corrupted (see the attached image).

Can you isolate which update caused the problem?


> No information at dmesg nor Xorg.0.log available.

Please always attach them to bug reports anyway.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #2 from Thomas Rohloff  2012-08-24 11:34:30 
UTC ---
Created attachment 66060
  --> https://bugs.freedesktop.org/attachment.cgi?id=66060
radeontop

I just noticed that the GPU usage is very high (radeontop), so high that the
desktop gets unusable in the LOW power profile. It spins between 20 and 80%

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] Massive screen corruption on Cayman

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

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

--- Comment #1 from Thomas Rohloff  2012-08-24 11:25:09 
UTC ---
Created attachment 66059
  --> https://bugs.freedesktop.org/attachment.cgi?id=66059
bugs.freedesktop.org with the corruption

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54002] New: Massive screen corruption on Cayman

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

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

 Bug #: 54002
   Summary: Massive screen corruption on Cayman
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: v10lator at myway.de


Created attachment 66058
  --> https://bugs.freedesktop.org/attachment.cgi?id=66058
Corrupted desktop

I just updated mesa, libdrm snd the xf86-video-radeon to the newest git
versions and now my screen is massivly corrupted (see the attached image).
As you see this corruption isn't everywhere. By writing this text it flashed
(sometimes more corrupt, sometimes less, sometimes not at all).

No information at dmesg nor Xorg.0.log available.

Kernel in use: Unpatched 3.6-rc3

BTW: It's hard to write a bug report with a corrupted screen (will attach a
screenshot, too, so you got something to laugh).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] gma500: remove references to drm_display_info raw_edid field

[Alan Cox]

On Fri, 24 Aug 2012 09:42:44 +0300
Jani Nikula  wrote:

> Another reference to raw_edid field of struct drm_display_info was
> added in gma500 while the whole field was being removed, causing build
> failure. Remove the hopefully last references to raw_edid.
> 
> Reported-by: Fengguang Wu 
> Signed-off-by: Jani Nikula 

Signed-off-by: Alan Cox 

[PATCH] drm/exynos: Disable plane when released

[Inki Dae]

From: Inki Dae 

this patch ensures that each plane connected to encoder is disabled
when released, by adding disable callback function of encoder helper

we had faced with one issue that invalid memory is accessed by dma
once drm is released and then the dma is turned on again. actually,
in our case, page fault was incurred with iommu. the reason is that
a gem buffer accessed by the dma is also released once drm is released.

so this patch would fix this issue ensuring the dma is disabled
when released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 92f9acf..96a10c3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -214,12 +214,27 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
manager_ops->commit(manager->dev);
 }

+static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
+{
+   struct drm_plane *plane;
+   struct drm_device *dev = encoder->dev;
+
+   exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+
+   /* all planes connected to this encoder should be also disabled. */
+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->crtc == encoder->crtc)
+   plane->funcs->disable_plane(plane);
+   }
+}
+
 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
.dpms   = exynos_drm_encoder_dpms,
.mode_fixup = exynos_drm_encoder_mode_fixup,
.mode_set   = exynos_drm_encoder_mode_set,
.prepare= exynos_drm_encoder_prepare,
.commit = exynos_drm_encoder_commit,
+   .disable= exynos_drm_encoder_disable,
 };

 static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
-- 
1.7.5.4

[PATCH] drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

[Jerome Glisse]

On Fri, Aug 24, 2012 at 8:27 AM, Marek Ol??k  wrote:
> Checking of the second colorbuffer was skipped on r700, because
> CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff,
> so we must set the number of samples of the second colorbuffer to 1 in order
> to pass the CS checker.
> The DRM version is bumped, because RESOLVE_BOX is always rejected without this
> fix on r600.
>
> Signed-off-by: Marek Ol??k 

Reviewed-by: Jerome Glisse 

> ---
>  drivers/gpu/drm/radeon/r600_cs.c |   19 +--
>  drivers/gpu/drm/radeon/r600d.h   |8 
>  drivers/gpu/drm/radeon/radeon_drv.c  |3 ++-
>  drivers/gpu/drm/radeon/reg_srcs/r600 |1 -
>  4 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 8866937..f37676d 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -63,6 +63,7 @@ struct r600_cs_track {
> u32 cb_color_size_idx[8]; /* unused */
> u32 cb_target_mask;
> u32 cb_shader_mask;  /* unused */
> +   boolis_resolve;
> u32 cb_color_size[8];
> u32 vgt_strmout_en;
> u32 vgt_strmout_buffer_en;
> @@ -321,6 +322,7 @@ static void r600_cs_track_init(struct r600_cs_track 
> *track)
> track->cb_color_tile_offset[i] = 0x;
> track->cb_color_mask[i] = 0x;
> }
> +   track->is_resolve = false;
> track->nsamples = 16;
> track->log_nsamples = 4;
> track->cb_target_mask = 0x;
> @@ -359,6 +361,8 @@ static int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> volatile u32 *ib = p->ib.ptr;
> unsigned array_mode;
> u32 format;
> +   /* When resolve is used, the second colorbuffer has always 1 sample. 
> */
> +   unsigned nsamples = track->is_resolve && i == 1 ? 1 : track->nsamples;
>
> size = radeon_bo_size(track->cb_color_bo[i]) - 
> track->cb_color_bo_offset[i];
> format = G_0280A0_FORMAT(track->cb_color_info[i]);
> @@ -382,7 +386,7 @@ static int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> array_check.group_size = track->group_size;
> array_check.nbanks = track->nbanks;
> array_check.npipes = track->npipes;
> -   array_check.nsamples = track->nsamples;
> +   array_check.nsamples = nsamples;
> array_check.blocksize = r600_fmt_get_blocksize(format);
> if (r600_get_array_mode_alignment(_check,
>   _align, _align, 
> _align, _align)) {
> @@ -428,7 +432,7 @@ static int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
>
> /* check offset */
> tmp = r600_fmt_get_nblocksy(format, height) * 
> r600_fmt_get_nblocksx(format, pitch) *
> - r600_fmt_get_blocksize(format) * track->nsamples;
> + r600_fmt_get_blocksize(format) * nsamples;
> switch (array_mode) {
> default:
> case V_0280A0_ARRAY_LINEAR_GENERAL:
> @@ -799,6 +803,12 @@ static int r600_cs_track_check(struct radeon_cs_parser 
> *p)
>  */
> if (track->cb_dirty) {
> tmp = track->cb_target_mask;
> +
> +   /* We must check both colorbuffers for RESOLVE. */
> +   if (track->is_resolve) {
> +   tmp |= 0xff;
> +   }
> +
> for (i = 0; i < 8; i++) {
> if ((tmp >> (i * 4)) & 0xF) {
> /* at least one component is enabled */
> @@ -1288,6 +1298,11 @@ static int r600_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
> track->nsamples = 1 << tmp;
> track->cb_dirty = true;
> break;
> +   case R_028808_CB_COLOR_CONTROL:
> +   tmp = G_028808_SPECIAL_OP(radeon_get_ib_value(p, idx));
> +   track->is_resolve = tmp == V_028808_SPECIAL_RESOLVE_BOX;
> +   track->cb_dirty = true;
> +   break;
> case R_0280A0_CB_COLOR0_INFO:
> case R_0280A4_CB_COLOR1_INFO:
> case R_0280A8_CB_COLOR2_INFO:
> diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
> index bdb69a6..fa6f370 100644
> --- a/drivers/gpu/drm/radeon/r600d.h
> +++ b/drivers/gpu/drm/radeon/r600d.h
> @@ -66,6 +66,14 @@
>  #defineCC_RB_BACKEND_DISABLE   0x98F4
>  #defineBACKEND_DISABLE(x)  ((x) 
> << 16)
>
> +#define R_028808_CB_COLOR_CONTROL  0x28808
> +#define   S_028808_SPECIAL_OP(x)   (((x) & 0x7) << 4)
> +#define   G_028808_SPECIAL_OP(x)   (((x) >> 4) & 0x7)
> +#define   C_028808_SPECIAL_OP   

答复: 转发: Siliconmotion new kernel driver initial patch

[Aaron.Chen 陈俊杰]

Hi,

>What's with the #ifdef 0 or #ifdef 1?

>Why is there a bunch of ddkxxx something? Can those header files be squashed 
>together?

We have deleted all the "#ifdef 0 or #ifdef 1" and cut our codes into smaller 
parts in order to get reviewed easier. There are less ddkxxx something in this 
patch.

Subject: [PATCH] siliconmotion kernel driver initial patch

This is the initial patch for siliconmotion kernel driver. It can support SM750 
and SM718. It is a framebuffer driver.

Signed-off-by: Aaron Chen 
---
 drivers/video/Kconfig |   13 +
 drivers/video/Makefile|1 +
 drivers/video/lynxfb/Makefile |   63 ++
 drivers/video/lynxfb/ddk750.h |   31 +
 drivers/video/lynxfb/ddk750_chip.c|  586 
 drivers/video/lynxfb/ddk750_chip.h|   97 ++
 drivers/video/lynxfb/ddk750_display.c |  295 ++
 drivers/video/lynxfb/ddk750_display.h |  124 +++
 drivers/video/lynxfb/ddk750_dvi.c |  114 +++
 drivers/video/lynxfb/ddk750_dvi.h |   84 ++
 drivers/video/lynxfb/ddk750_help.c|   37 +
 drivers/video/lynxfb/ddk750_help.h|   42 +
 drivers/video/lynxfb/ddk750_hwi2c.c   |  290 ++
 drivers/video/lynxfb/ddk750_hwi2c.h   |   28 +
 drivers/video/lynxfb/ddk750_mode.c|  213 +
 drivers/video/lynxfb/ddk750_mode.h|   59 ++
 drivers/video/lynxfb/ddk750_power.c   |  243 +
 drivers/video/lynxfb/ddk750_power.h   |   85 ++
 drivers/video/lynxfb/ddk750_reg.h |  362 +++
 drivers/video/lynxfb/ddk750_sii164.c  |  435 +
 drivers/video/lynxfb/ddk750_sii164.h  |  187 
 drivers/video/lynxfb/ddk750_swi2c.c   |  522 ++
 drivers/video/lynxfb/ddk750_swi2c.h   |   98 ++
 drivers/video/lynxfb/lynx_accel.c |  417 
 drivers/video/lynxfb/lynx_accel.h |  161 
 drivers/video/lynxfb/lynx_cursor.c|  223 +
 drivers/video/lynxfb/lynx_cursor.h|   36 +
 drivers/video/lynxfb/lynx_drv.c   | 1688 +
 drivers/video/lynxfb/lynx_drv.h   |  271 ++
 drivers/video/lynxfb/lynx_help.h  |  115 +++
 drivers/video/lynxfb/lynx_hw750.c |  633 +
 drivers/video/lynxfb/lynx_hw750.h |  120 +++
 drivers/video/lynxfb/modedb.c |  238 +
 drivers/video/lynxfb/ver.h|   38 +
 34 files changed, 7949 insertions(+)


Aaron

--
???: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com] 
: 2012?8?14? 2:03
???: Aaron.Chen ???
??: linux-fbdev at vger.kernel.org; mill.chen ??; Mandy.Wang ???; Paul.Chen ??; 
dri-devel at lists.freedesktop.org; caesar.qiu ???; Sunny.Yang ??
??: Re: ??: Siliconmotion new kernel driver initial patch

On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen  ??? wrote:
> 
> Since there is no response for the last mail. Maybe it didn't sent 
> successfully. So I send it again. Here is the initial patch for siliconmotion 
> kernel driver.

What's with the #ifdef 0 or #ifdef 1?

Why is there a bunch of ddkxxx something? Can those header files be squashed 
together?
> 
> Aaron
> 


> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- next part --
A non-text attachment was scrubbed...
Name: 0001-siliconmotion-kernel-driver-initial-patch.patch
Type: application/octet-stream
Size: 256220 bytes
Desc: 0001-siliconmotion-kernel-driver-initial-patch.patch
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/b9303d69/attachment-0001.obj>

-next queue and EDID stuff

[Dave Airlie]

Hi guys (but mainly ajax)

I have a bunch of EDID and quirk stuff outstanding,

I've made a bundle on patchwork for it
https://patchwork.kernel.org/bundle/airlied/edid-review/

Dave.

[PATCH] gma500: remove references to drm_display_info raw_edid field

[Jani Nikula]

Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.

Reported-by: Fengguang Wu 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/gma500/cdv_intel_dp.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 9bacce3..c9abc06 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1554,7 +1554,6 @@ cdv_intel_dp_detect(struct drm_connector *connector, bool 
force)
edid = drm_get_edid(connector, _dp->adapter);
if (edid) {
intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
kfree(edid);
}
}
@@ -1634,8 +1633,6 @@ cdv_intel_dp_detect_audio(struct drm_connector *connector)
edid = drm_get_edid(connector, _dp->adapter);
if (edid) {
has_audio = drm_detect_monitor_audio(edid);
-
-   connector->display_info.raw_edid = NULL;
kfree(edid);
}
if (edp)
-- 
1.7.9.5

[PATCH] drm: gma500: Kill the GEM glue layer

[Dave Airlie]

On Thu, Aug 23, 2012 at 8:52 PM, Alan Cox  wrote:
> On Thu, 23 Aug 2012 12:03:59 +0200
> Laurent Pinchart  wrote:
>
>> Hi Alan,
>>
>> On Tuesday 17 July 2012 17:21:06 Alan Cox wrote:
>> > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote:
>> > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote:
>> > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote:
>> > > > > The private gem_create_mmap_offset() function is now
>> > > > > implemented in the DRM core as drm_gem_create_mmap_offset().
>> > > > > Use it and kill the private copy.
>> > > >
>> > > > That was always then plan so yes - I'll fold this into my tree
>> > > > and test it.
>> > >
>> > > Any update ?
>> >
>> > Sorry it fell off the bottom of the job list. I'll do it right now
>> > so it doesn't escape
>>
>> I still can't find the patch in drm-next. Does it have a bad tendency
>> to fell off ? :-)
>
> I sent to Dave along with the mode setting fixes and DP/eDP support.
> None of them are yet in the tree but I've not re-sent again as Dave
> seemed to be busy to trying to mend the -rc tree.
>

Okay just grabbed all the gma500 dp/edp and this and put them into -next.

Dave.

mgag200 hang on boot

[Dave Airlie]

On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski  wrote:
> mgag200 hangs like this on startup, on a Dell PowerEge 12g box.  The
> serial console says:

You can apply this

https://patchwork.kernel.org/patch/1298651/

it should be in stable at some point, I expect its the same bug, it
not get back to me.

Dave.

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

--- Comment #13 from Joseph Spiros  2012-08-24 
08:34:33 UTC ---
I'm running into this bug as well, with an iMac G5 containing a Radeon 9600
(rv350) chip. It's been a few months since this bug has seen any activity; is a
fix still forthcoming? Is there anything I can do to help? I am not familiar
with OpenGL or Mesa's codebase, but I can test on my hardware as needed. And,
well, if this bug has been abandoned, I'm willing to spend some time trying to
familiarize myself enough with the codebase to, at minimum, attempt an updated
patch based on the patches provided previously.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50360] flightgear has absymal performance with the llvm shader compiler

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

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

Vadim Girlin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Vadim Girlin  2012-08-24 08:02:59 UTC 
---
Fix pushed with commit 4acf71f01ea1edb253cd38cc059d4af1a2a40bf4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Calvin Walton]

This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.

It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
chipset.

I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.

Signed-off-by: Calvin Walton 
---

This board:
http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp

If you want any additional debug output from this machine, let me know
what you would like and how to find it.

I think this patch would probably be a reasonable candidate for -stable?

 drivers/gpu/drm/i915/intel_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 08eb04c..2c58310 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Gigabyte GA-D525TUD",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., 
Ltd."),
+   DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
+   },
+   },

{ } /* terminating entry */
 };
-- 
1.7.12

-- 
Calvin Walton 

[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?

[Takashi Iwai]

At Thu, 23 Aug 2012 20:44:32 -0500,
Ricardo Neri wrote:
> 
> Hi Takashi,
> 
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
> > At Tue, 21 Aug 2012 19:58:02 -0500,
> > Ricardo Neri wrote:
> >>
> >>
> >>
> >> On 08/21/2012 07:39 AM, Clark, Rob wrote:
> >>> On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen  >>> ti.com> wrote:
>  On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
> > Hello!
> >
> > I have been working on prototypes for the ASoC OMAP HDMI audio driver to
> > propagate events from the HDMI output (e.g., display getting
> > enabled/disabled/suspended). This for the users of the driver to react
> > to such events. For instance, if the display is disabled or disconected,
> > audio could be stopped, rerouted or whatever other decision the user
> > makes. This is needed because, if, for instance, the  HDMI IP goes off,
> > audio will stall and the audio users will only see a "playback write
> > error (DMA or IRQ trouble?)"
> >
> > In my prototypes I have used snd_soc_jack for this purpose and I have
> > some questions:
> >
> > *I see snd_soc_jack is used mostly for headsets and microphones with
> > actual external mechanical connections. Strictly, in my case I propagate
> > events originated by the OMAP display driver (changes in the power
> > state), and not from external events. Some of these events are generated
> > from an actual HDMI cable connection/disconnection, though.
> >
> > *Maybe the event should be propagated by omapdss/omapdrm/drm and the
> > entity in charge of the audio policy should listen those events instead.
> >
> > *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie ? ? 
> > Il y a 12 minutes ?
> 
> s
> > feasible for an audio driver to report events from an AV output.
> >
> > I was wondering about how much sense does it make to you guys use a
> > snd_soc_jack in this case?
> 
>  How does DRM handle audio? I made a quick grep, but I see the drm
>  drivers only enabling the audio in the HW, nothing else.
> >>>
> >>> I confess to not knowing too much about audio/alsa, but what does
> >>> audio driver need from hdmi?  Just hotplug events?
> >>
> >> At least for the case of the ASoC HDMI audio driver (but hopefully for
> >> other audio drivers as well), it needs to detect whether an HDMI output
> >> is available, if the display's current configuration supports audio
> >> (e.g., a 1080p display configured as VGA should be reported as not
> >> supporting audio). It also needs interfaces to
> >> configure/prepare/start/stop audio. Also, of course, needs to know if
> >> the display is off/on/suspended and when transitions occur. For OMAP,
> >> omapdss provide an interface for this functionality for ALSA or any
> >> other interested user.
> >>>
> >>>   From a quick look, it seems most of what the existing drm drivers are
> >>> doing is detecting if the display supports audio, and then turning
> >>> on/off the hw.. (and some infoframe stuff in some cases).
> >>
> >> Yes, it seems to me that every driver makes its own audio
> >> implementation, mainly focused on configuration. I could not find any
> >> audio common interface so that users like ALSA can take advantage of.
> >>
> >> Also, I could not see any ALSA driver using functionality provided by a
> >> drm driver.
> >>
> >> Maybe the lack of audio support in drm is because the audio users should
> >> not talk to drm directly but to a lower level component (omapdrm,
> >> omapdss?). However, today there exists video technology supports audio
> >> as well, such as DisplayPort or HDMI. Could it make more sense now to
> >> provide audio support?
> >
> > The reason is that the audio and video handling are already separated
> > in the hardware level, at least, for desktop graphics.
> 
> Separated in what sense? Do they have separate register banks in 
> independent power domains? Can audio an video work with complete 
> independence. What happens if someone decides to power off video. Is the 
> audio able to continue if required?

As Stephen already pointed, the functionality is independent in the
PCI hardware level.  The audio part even accepts and DMA is working
without connection to the actual output.

> > The audio infoframe is passed via ELD to the audio controller part
> > upon plug/unplugging via HD-audio unsolicited event, and the audio
> > driver sets up the stuff according to the given ELD.  Thus no extra
> > interface between drm and ALSA was required in the kernel API level,
> > so far.
> 
> I see that the unsolicited event is used only to parse the EDID, 
> correct? It also notifies about the jack status. Hence, if there the 
> cable is disconnected the application will know and act accordingly. Is 
> this understanding correct?

Correct.

> Also, I see that hda_pcm_ops does not have a trigger or start/stop 
> functions, how does it know when to start/stop audio. Maybe with 
> 

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #18 from Bryan Quigley  2012-08-24 
04:32:48 UTC ---
Created attachment 66047
  --> https://bugs.freedesktop.org/attachment.cgi?id=66047
3 outputs of syslog: before the patch, after, and after really bad

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #17 from Bryan Quigley  2012-08-24 
04:31:57 UTC ---
The patch doesn't seem to work.  It may have made the crash more likely to
bring the system down, but I'd have to do more testing to confirm that.

Attaching 3 syslog results in 1 file containing:
Before the patch
After the patch
After the patch - broke so much it needed a restart

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: edid: add support for E-DDC

[Daniel Vetter]

On Thu, Aug 23, 2012 at 07:06:53AM -0700, Shirish S wrote:
> Hello Daniel,
> 
> On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter  wrote:
> 
> > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrj?l? wrote:
> > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote:
> > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? <
> > > > ville.syrjala at linux.intel.com> wrote:
> > > >
> > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote:
> > > > Here are my earlier comments on Jean's patch:
> > > > >
> > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html
> > > > >
> > > > >
> > > >  If i am not wrong am doing exactly what you have said in you comments.
> > > >
> > > > This seems a bit wrong to me. The spec says that the ack for the
> > > > segment address is "don't care", but for the segment pointer the ack is
> > > > required (when segment != 0).
> > > > The variable segFlags is "dont care for block 0 and 1 wheras".
> > > >
> > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a
> > > > non E-DDC display, if we try to read segment != 0 from it. Of course
> > > > we shouldn't do that unless the display lied to us about what extension
> > > > blocks it provides.
> > > >
> > > > So I'm not sure if it would be better to trust that the display never
> > > > lies about the extension blocks, or if we should just assume all E-DDC
> > > > displays ack both segment addr and pointer. The no-ack feature seems
> > > > to there for backwards compatibility, for cases where the host always
> > > > sends the segment addr/pointer even when reading segment 0 (which your
> > > > code doesn't do).
> > > >
> > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split
> > > > into two flags (one for addr, other for data).
> > > >
> > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr)
> > > > and data pointer.
> > >
> > > I was referring to the addr and data phases of the segment pointer.
> > > According to the spec the ack for the addr is always optional. But I
> > > suppose no sane device would nak the addr, while acking the data.
> >
> > We've seen those. Really.
> >
> > Which is why the current i915 gmbus driver has a hack to never return a
> > NaK on the first i2c transfer. I guess we should fix this by properly
> > supporting the INGNORE_NAK field in our gmbus driver, and setting that on
> > the addr transfer field, too.
> >
> > Thanks for the comment, so are you ok with the current logic?
> 
> 
> > I concure with Ville that sending the segment i2c message only when we
> > actually need it, and not unconditionally. DDC is way to broken and
> > claiming that the spec says otherwise doesn't fix all the existing bad hw.
> >
> 
> Agreed, so do you want me to post another patch, in which i add a function
> only
> if the number of blocks is more than 2?
> Also i had some mistake in the patch set 1, hence i updated it.

I think adding the IGNORE_NAK on the addr i2c transaction would help
unconditionally - like I've said we've seen monitors that suggest that
this is required. And yeah, I think we should send the E-DDC segment
number only if the basic edid block indicates that more than 2 blocks are
availble (and again with IGNORE_NAK, just for paranoia's sake).


> Kindly have a look!

Will do.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #16 from Marek Ol??k  2012-08-24 01:14:51 UTC 
---
Created attachment 66040
  --> https://bugs.freedesktop.org/attachment.cgi?id=66040
possible fix

Could you please try this patch?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1

[Daniel Vetter]

On Thu, Aug 23, 2012 at 12:22:27PM -0700, Tejun Heo wrote:
> Hello,
> 
> On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote:
> > > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo  wrote:
> > > > This is an equivalent conversion and will ease scheduled removal of
> > > > WQ_NON_REENTRANT.
> > > > 
> > > > Signed-off-by: Tejun Heo 
> > > Reviewed-by: Chris Wilson 
> > 
> > Acked-by: Daniel Vetter  for merging through any
> > tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT
> > removal). Or should I just merge this through drm-intel-next?
> 
> I think it would be better to route this one through drm-intel-next.
> WQ_NON_REENTRANT won't be deprecated until after the next -rc1 anyway.

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

mgag200 hang on boot

[Andy Lutomirski]

mgag200 hangs like this on startup, on a Dell PowerEdge 12g box.  The
serial console says:

[4.399184] [drm] Initialized drm 1.1.0 20060810
[4.444054] [TTM] Zone  kernel: Available graphics memory: 16452270 kiB
[4.459610] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[4.466893] [TTM] Initializing pool allocator
[4.471768] [TTM] Initializing DMA pool allocator
[4.543626] fbcon: mgadrmfb (fb0) is primary device
udevadm settle - timeout of 120 seconds reached, the event queue contains:
  
/sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0
(1431)
  
/sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/controlD64
(2238)
  
/sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/card0
(2239)
  
/sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/i2c-0
(2245)
  
/sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/graphics/fb0
(2249)


This is 3.5.0, but the bug is not fixed in 3.5.2.  When the hang
happened, the actual vga output declared that it had no signal,
according to the iDRAC remote management.

The hang is:

[  579.919114] insmod  R  running task0  8873   8872 0x
[  579.919117]  8807af15b2b8 814ff9d7 0001
a01461a0
[  579.919123]  880809665a80 8807af15bfd8 8807af15bfd8
8807af15bfd8
[  579.919129]  8808028116a0 8808028116a0 1000
8807af15bfd8
[  579.919135] Call Trace:
[  579.919136]  [814ff9d7] ? __schedule+0x3b7/0x7c0
[  579.919140]  [81500215] preempt_schedule_irq+0x45/0x60
[  579.919144]  [81501796] retint_kernel+0x26/0x30
[  579.919149]  [a01435d8] ? mga_crtc_mode_set+0x1e38/0x1ee0 [mgag200]
[  579.919158]  [a014226c] ? mga_crtc_mode_set+0xacc/0x1ee0 [mgag200]
[  579.919165]  [8127c340] ? idr_get_new_above+0x10/0x40
[  579.919177]  [a0035e5e]
drm_crtc_helper_set_mode+0x36e/0x4f0 [drm_kms_helper]
[  579.919189]  [a0036e8f]
drm_crtc_helper_set_config+0x84f/0xb00 [drm_kms_helper]
[  579.919195]  [81500215] ? preempt_schedule_irq+0x45/0x60
[  579.919200]  [a0034ab8] drm_fb_helper_set_par+0x78/0xf0
[drm_kms_helper]
[  579.919206]  [812c6b3c] fbcon_init+0x52c/0x5b0
[  579.919211]  [8131ea5c] visual_init+0xbc/0x120
[  579.919215]  [813200dc] bind_con_driver+0x19c/0x330
[  579.919220]  [813202d1] take_over_console+0x61/0x70
[  579.919224]  [812c4e7b] fbcon_takeover+0x5b/0xb0
[  579.919227]  [812c9a8a] fbcon_event_notify+0x76a/0x870
[  579.919232]  [8150482d] notifier_call_chain+0x4d/0x70
[  579.919236]  [8106e418] __blocking_notifier_call_chain+0x58/0x80
[  579.919240]  [8106e456] blocking_notifier_call_chain+0x16/0x20
[  579.919244]  [812ba6eb] fb_notifier_call_chain+0x1b/0x20
[  579.919250]  [812bbc2a] register_framebuffer+0x1ba/0x2f0
[  579.919256]  [a0034d13]
drm_fb_helper_single_fb_probe+0x1e3/0x300 [drm_kms_helper]
[  579.919262]  [a003500b]
drm_fb_helper_initial_config+0x1db/0x250 [drm_kms_helper]
[  579.919268]  [8113a85b] ? __kmalloc+0x16b/0x1b0
[  579.919272]  [a0035198] ? drm_fb_helper_init+0x118/0x1f0
[drm_kms_helper]
[  579.919278]  [8113ad03] ? kmem_cache_alloc_trace+0x143/0x170
[  579.919282]  [a0143f94] mgag200_fbdev_init+0x84/0xb0 [mgag200]
[  579.919290]  [a01438d7] mgag200_modeset_init+0x1b7/0x230 [mgag200]
[  579.919297]  [a01406e1] mgag200_driver_load+0x3e1/0x4b0 [mgag200]
[  579.919305]  [a0158f31] drm_get_pci_dev+0x191/0x2b0 [drm]
[  579.919324]  [a01450a0] mga_pci_probe+0xac/0xb4 [mgag200]
[  579.919332]  [812a36fc] local_pci_probe+0x5c/0xd0
[  579.919339]  [812a41d9] pci_device_probe+0x109/0x130
[  579.919345]  [81345b8e] driver_probe_device+0x7e/0x220
[  579.919353]  [81345ddb] __driver_attach+0xab/0xb0
[  579.919358]  [81345d30] ? driver_probe_device+0x220/0x220
[  579.919363]  [81343fb6] bus_for_each_dev+0x56/0x90
[  579.919369]  [8134569e] driver_attach+0x1e/0x20
[  579.919373]  [81345250] bus_add_driver+0x1a0/0x270
[  579.919379]  [81346106] driver_register+0x76/0x130
[  579.919382]  [812a3ea6] __pci_register_driver+0x56/0xd0
[  579.919387]  [8150482d] ? notifier_call_chain+0x4d/0x70
[  579.919393]  [a015916a] drm_pci_init+0x11a/0x130 [drm]
[  579.919406]  [a00d8000] ? 0xa00d7fff
[  579.919413]  [a00d803c] mgag200_init+0x3c/0x1000 [mgag200]
[  579.919419]  [810001bf] do_one_initcall+0x3f/0x170
[  579.919424]  [8109a1ee] sys_init_module+0xbe/0x230
[  579.919430]  [815083d2] system_call_fastpath+0x16/0x1b'

insmod is taking 100% cpu.

Is there anything I can do to debug this?  I 

Re: mgag200 hang on boot

[Andy Lutomirski]

On Thu, Aug 23, 2012 at 4:22 PM, Dave Airlie airl...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski l...@amacapital.net wrote:
 mgag200 hangs like this on startup, on a Dell PowerEge 12g box.  The
 serial console says:

 You can apply this

 https://patchwork.kernel.org/patch/1298651/

Works for me.  Thanks.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?

[Ricardo Neri]

Hi Takashi,

On 08/22/2012 02:55 AM, Takashi Iwai wrote:

At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:




On 08/21/2012 07:39 AM, Clark, Rob wrote:

On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:

Hello!

I have been working on prototypes for the ASoC OMAP HDMI audio driver to
propagate events from the HDMI output (e.g., display getting
enabled/disabled/suspended). This for the users of the driver to react
to such events. For instance, if the display is disabled or disconected,
audio could be stopped, rerouted or whatever other decision the user
makes. This is needed because, if, for instance, the  HDMI IP goes off,
audio will stall and the audio users will only see a playback write
error (DMA or IRQ trouble?)

In my prototypes I have used snd_soc_jack for this purpose and I have
some questions:

*I see snd_soc_jack is used mostly for headsets and microphones with
actual external mechanical connections. Strictly, in my case I propagate
events originated by the OMAP display driver (changes in the power
state), and not from external events. Some of these events are generated
from an actual HDMI cable connection/disconnection, though.

*Maybe the event should be propagated by omapdss/omapdrm/drm and the
entity in charge of the audio policy should listen those events instead.

*I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie · · Il y a 
12 minutes ·


s

feasible for an audio driver to report events from an AV output.

I was wondering about how much sense does it make to you guys use a
snd_soc_jack in this case?


How does DRM handle audio? I made a quick grep, but I see the drm
drivers only enabling the audio in the HW, nothing else.


I confess to not knowing too much about audio/alsa, but what does
audio driver need from hdmi?  Just hotplug events?


At least for the case of the ASoC HDMI audio driver (but hopefully for
other audio drivers as well), it needs to detect whether an HDMI output
is available, if the display's current configuration supports audio
(e.g., a 1080p display configured as VGA should be reported as not
supporting audio). It also needs interfaces to
configure/prepare/start/stop audio. Also, of course, needs to know if
the display is off/on/suspended and when transitions occur. For OMAP,
omapdss provide an interface for this functionality for ALSA or any
other interested user.


  From a quick look, it seems most of what the existing drm drivers are
doing is detecting if the display supports audio, and then turning
on/off the hw.. (and some infoframe stuff in some cases).


Yes, it seems to me that every driver makes its own audio
implementation, mainly focused on configuration. I could not find any
audio common interface so that users like ALSA can take advantage of.

Also, I could not see any ALSA driver using functionality provided by a
drm driver.

Maybe the lack of audio support in drm is because the audio users should
not talk to drm directly but to a lower level component (omapdrm,
omapdss?). However, today there exists video technology supports audio
as well, such as DisplayPort or HDMI. Could it make more sense now to
provide audio support?


The reason is that the audio and video handling are already separated
in the hardware level, at least, for desktop graphics.


Separated in what sense? Do they have separate register banks in 
independent power domains? Can audio an video work with complete 
independence. What happens if someone decides to power off video. Is the 
audio able to continue if required?


The audio infoframe is passed via ELD to the audio controller part
upon plug/unplugging via HD-audio unsolicited event, and the audio
driver sets up the stuff according to the given ELD.  Thus no extra
interface between drm and ALSA was required in the kernel API level,
so far.


I see that the unsolicited event is used only to parse the EDID, 
correct? It also notifies about the jack status. Hence, if there the 
cable is disconnected the application will know and act accordingly. Is 
this understanding correct?


Also, I see that hda_pcm_ops does not have a trigger or start/stop 
functions, how does it know when to start/stop audio. Maybe with 
azx_pcm_trigger?


Sorry, I am not expert in HD-audio :)

Ricardo




Takashi


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?

[Stephen Warren]

On 08/23/2012 07:44 PM, Ricardo Neri wrote:
 On 08/22/2012 02:55 AM, Takashi Iwai wrote:
 At Tue, 21 Aug 2012 19:58:02 -0500,
 Ricardo Neri wrote:
...
 Maybe the lack of audio support in drm is because the audio users should
 not talk to drm directly but to a lower level component (omapdrm,
 omapdss?). However, today there exists video technology supports audio
 as well, such as DisplayPort or HDMI. Could it make more sense now to
 provide audio support?

 The reason is that the audio and video handling are already separated
 in the hardware level, at least, for desktop graphics.
 
 Separated in what sense? Do they have separate register banks in

For NVIDIA desktop GPUs, this is certainly true, and I think so for any
Intel Azalia/HDA controller. The separate register banks are in
different PCI functions on the chip. The Intel Azalia/HDA spec also
architects specific ways that the audio and video parts interact (i.e.
ELD representation of EDID data, unsolicited response messages when the
video state changes, etc.) Oh, I see Takashi mentioned this below.

 independent power domains?

Most likely yes.

 Can audio an video work with complete
 independence. What happens if someone decides to power off video. Is the
 audio able to continue if required?

I believe audio DMA isn't affect by the video state, but I'm not 100%
sure of that.

 The audio infoframe is passed via ELD to the audio controller part
 upon plug/unplugging via HD-audio unsolicited event, and the audio
 driver sets up the stuff according to the given ELD.  Thus no extra
 interface between drm and ALSA was required in the kernel API level,
 so far.
 
 I see that the unsolicited event is used only to parse the EDID,
 correct? It also notifies about the jack status. Hence, if there the
 cable is disconnected the application will know and act accordingly. Is
 this understanding correct?

The kernel will know, and then passes the information on to user-space.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50360] flightgear has absymal performance with the llvm shader compiler

[bugzilla-daemon]

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

Vadim Girlin pt...@yandex.ru changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Vadim Girlin pt...@yandex.ru 2012-08-24 08:02:59 UTC ---
Fix pushed with commit 4acf71f01ea1edb253cd38cc059d4af1a2a40bf4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

[bugzilla-daemon]

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

--- Comment #13 from Joseph Spiros jos...@josephspiros.com 2012-08-24 
08:34:33 UTC ---
I'm running into this bug as well, with an iMac G5 containing a Radeon 9600
(rv350) chip. It's been a few months since this bug has seen any activity; is a
fix still forthcoming? Is there anything I can do to help? I am not familiar
with OpenGL or Mesa's codebase, but I can test on my hardware as needed. And,
well, if this bug has been abandoned, I'm willing to spend some time trying to
familiarize myself enough with the codebase to, at minimum, attempt an updated
patch based on the patches provided previously.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: fixed a issue that plane isn't disabled when released

[Inki Dae]

when drm is released, drm framebuffers are released and all crtcs using
same framebuffer and also all gem buffers used but plane isn't disabled
so when crtc and encoder are turned on, overlay can access to invalid memory
because plane still has memory address released already.
this patch makes sure that each plane is disabled when released.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 92f9acf..96a10c3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -214,12 +214,27 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
manager_ops-commit(manager-dev);
 }
 
+static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
+{
+   struct drm_plane *plane;
+   struct drm_device *dev = encoder-dev;
+
+   exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+
+   /* all planes connected to this encoder should be also disabled. */
+   list_for_each_entry(plane, dev-mode_config.plane_list, head) {
+   if (plane-crtc == encoder-crtc)
+   plane-funcs-disable_plane(plane);
+   }
+}
+
 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
.dpms   = exynos_drm_encoder_dpms,
.mode_fixup = exynos_drm_encoder_mode_fixup,
.mode_set   = exynos_drm_encoder_mode_set,
.prepare= exynos_drm_encoder_prepare,
.commit = exynos_drm_encoder_commit,
+   .disable= exynos_drm_encoder_disable,
 };
 
 static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: make sure that hardware overlay for fimd is disabled

[Inki Dae]

Changelog v2:
wait for VSYNC instead of BACKPORCH.

Changelog v1:
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..478100e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data-enabled = false;
 }
 
+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+   int ret;
+
+   ret = wait_for((__raw_readl(ctx-regs + VIDCON1) 
+   VIDCON1_VSTATUS_VSYNC), 50);
+   if (ret  0)
+   DRM_DEBUG_KMS(vblank wait timed out.\n);
+}
+
 static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+   .wait_for_vblank = fimd_wait_for_vblank,
 };
 
 static struct exynos_drm_manager fimd_manager = {
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gma500: remove references to drm_display_info raw_edid field

[Alan Cox]

On Fri, 24 Aug 2012 09:42:44 +0300
Jani Nikula jani.nik...@intel.com wrote:

 Another reference to raw_edid field of struct drm_display_info was
 added in gma500 while the whole field was being removed, causing build
 failure. Remove the hopefully last references to raw_edid.
 
 Reported-by: Fengguang Wu fengguang...@intel.com
 Signed-off-by: Jani Nikula jani.nik...@intel.com

Signed-off-by: Alan Cox a...@linux.intel.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: fixed a issue that plane isn't disabled when released

[Paul Menzel]

Dear Inki,


Am Freitag, den 24.08.2012, 18:27 +0900 schrieb Inki Dae:

You can shorten the commit summary by leaving out the word issue, which
is redundant. Maybe one of the following? I do not understand the
process of releasing so it might be wrong.

drm/exynos: Disable plane after release
drm/exynos: Disable plane when being released
drm/exynos: Fix disabling of plane when released

 when drm is released, drm framebuffers are released and all crtcs using
 same framebuffer and also all gem buffers used but plane isn't disabled
 so when crtc and encoder are turned on, overlay can access to invalid memory
 because plane still has memory address released already.
 this patch makes sure that each plane is disabled when released.

Please use sentences to make it easier to understand.

Also describe the solution. Maybe something like this.

This patch ensures that each plane is disabled when released, by
adding a new function and adding that to the helper functions.

Is there a report for that issue? Did you experience it in your setup?
Is this tested?

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
  1 files changed, 15 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
 b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
 index 92f9acf..96a10c3 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
 @@ -214,12 +214,27 @@ static void exynos_drm_encoder_commit(struct 
 drm_encoder *encoder)
   manager_ops-commit(manager-dev);
  }
  
 +static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
 +{
 + struct drm_plane *plane;
 + struct drm_device *dev = encoder-dev;
 +
 + exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
 +
 + /* all planes connected to this encoder should be also disabled. */
 + list_for_each_entry(plane, dev-mode_config.plane_list, head) {
 + if (plane-crtc == encoder-crtc)
 + plane-funcs-disable_plane(plane);
 + }
 +}
 +
  static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
   .dpms   = exynos_drm_encoder_dpms,
   .mode_fixup = exynos_drm_encoder_mode_fixup,
   .mode_set   = exynos_drm_encoder_mode_set,
   .prepare= exynos_drm_encoder_prepare,
   .commit = exynos_drm_encoder_commit,
 + .disable= exynos_drm_encoder_disable,
  };
  
  static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] New: Massive screen corruption on Cayman

[bugzilla-daemon]

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

 Bug #: 54002
   Summary: Massive screen corruption on Cayman
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v10la...@myway.de


Created attachment 66058
  -- https://bugs.freedesktop.org/attachment.cgi?id=66058
Corrupted desktop

I just updated mesa, libdrm snd the xf86-video-radeon to the newest git
versions and now my screen is massivly corrupted (see the attached image).
As you see this corruption isn't everywhere. By writing this text it flashed
(sometimes more corrupt, sometimes less, sometimes not at all).

No information at dmesg nor Xorg.0.log available.

Kernel in use: Unpatched 3.6-rc3

BTW: It's hard to write a bug report with a corrupted screen (will attach a
screenshot, too, so you got something to laugh).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #1 from Thomas Rohloff v10la...@myway.de 2012-08-24 11:25:09 UTC 
---
Created attachment 66059
  -- https://bugs.freedesktop.org/attachment.cgi?id=66059
bugs.freedesktop.org with the corruption

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #2 from Thomas Rohloff v10la...@myway.de 2012-08-24 11:34:30 UTC 
---
Created attachment 66060
  -- https://bugs.freedesktop.org/attachment.cgi?id=66060
radeontop

I just noticed that the GPU usage is very high (radeontop), so high that the
desktop gets unusable in the LOW power profile. It spins between 20 and 80%

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer mic...@daenzer.net 2012-08-24 12:02:27 UTC 
---
 I just updated mesa, libdrm snd the xf86-video-radeon to the newest git
 versions and now my screen is massivly corrupted (see the attached image).

Can you isolate which update caused the problem?


 No information at dmesg nor Xorg.0.log available.

Please always attach them to bug reports anyway.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #4 from Thomas Rohloff v10la...@myway.de 2012-08-24 12:11:38 UTC 
---
Created attachment 66062
  -- https://bugs.freedesktop.org/attachment.cgi?id=66062
Xorg.0.log

(In reply to comment #3)
 Can you isolate which update caused the problem?
I don't remember the version of mesa before and it's not in the emerge.log
(gentoo). But I'll try my best to get it. If you have any ideas feel free to
share them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #5 from Thomas Rohloff v10la...@myway.de 2012-08-24 12:12:28 UTC 
---
Created attachment 66063
  -- https://bugs.freedesktop.org/attachment.cgi?id=66063
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

[Marek Olšák]

Checking of the second colorbuffer was skipped on r700, because
CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff,
so we must set the number of samples of the second colorbuffer to 1 in order
to pass the CS checker.
The DRM version is bumped, because RESOLVE_BOX is always rejected without this
fix on r600.

Signed-off-by: Marek Olšák mar...@gmail.com
---
 drivers/gpu/drm/radeon/r600_cs.c |   19 +--
 drivers/gpu/drm/radeon/r600d.h   |8 
 drivers/gpu/drm/radeon/radeon_drv.c  |3 ++-
 drivers/gpu/drm/radeon/reg_srcs/r600 |1 -
 4 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 8866937..f37676d 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -63,6 +63,7 @@ struct r600_cs_track {
u32 cb_color_size_idx[8]; /* unused */
u32 cb_target_mask;
u32 cb_shader_mask;  /* unused */
+   boolis_resolve;
u32 cb_color_size[8];
u32 vgt_strmout_en;
u32 vgt_strmout_buffer_en;
@@ -321,6 +322,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)
track-cb_color_tile_offset[i] = 0x;
track-cb_color_mask[i] = 0x;
}
+   track-is_resolve = false;
track-nsamples = 16;
track-log_nsamples = 4;
track-cb_target_mask = 0x;
@@ -359,6 +361,8 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)
volatile u32 *ib = p-ib.ptr;
unsigned array_mode;
u32 format;
+   /* When resolve is used, the second colorbuffer has always 1 sample. */
+   unsigned nsamples = track-is_resolve  i == 1 ? 1 : track-nsamples;
 
size = radeon_bo_size(track-cb_color_bo[i]) - 
track-cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track-cb_color_info[i]);
@@ -382,7 +386,7 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)
array_check.group_size = track-group_size;
array_check.nbanks = track-nbanks;
array_check.npipes = track-npipes;
-   array_check.nsamples = track-nsamples;
+   array_check.nsamples = nsamples;
array_check.blocksize = r600_fmt_get_blocksize(format);
if (r600_get_array_mode_alignment(array_check,
  pitch_align, height_align, 
depth_align, base_align)) {
@@ -428,7 +432,7 @@ static int r600_cs_track_validate_cb(struct 
radeon_cs_parser *p, int i)
 
/* check offset */
tmp = r600_fmt_get_nblocksy(format, height) * 
r600_fmt_get_nblocksx(format, pitch) *
- r600_fmt_get_blocksize(format) * track-nsamples;
+ r600_fmt_get_blocksize(format) * nsamples;
switch (array_mode) {
default:
case V_0280A0_ARRAY_LINEAR_GENERAL:
@@ -799,6 +803,12 @@ static int r600_cs_track_check(struct radeon_cs_parser *p)
 */
if (track-cb_dirty) {
tmp = track-cb_target_mask;
+
+   /* We must check both colorbuffers for RESOLVE. */
+   if (track-is_resolve) {
+   tmp |= 0xff;
+   }
+
for (i = 0; i  8; i++) {
if ((tmp  (i * 4))  0xF) {
/* at least one component is enabled */
@@ -1288,6 +1298,11 @@ static int r600_cs_check_reg(struct radeon_cs_parser *p, 
u32 reg, u32 idx)
track-nsamples = 1  tmp;
track-cb_dirty = true;
break;
+   case R_028808_CB_COLOR_CONTROL:
+   tmp = G_028808_SPECIAL_OP(radeon_get_ib_value(p, idx));
+   track-is_resolve = tmp == V_028808_SPECIAL_RESOLVE_BOX;
+   track-cb_dirty = true;
+   break;
case R_0280A0_CB_COLOR0_INFO:
case R_0280A4_CB_COLOR1_INFO:
case R_0280A8_CB_COLOR2_INFO:
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index bdb69a6..fa6f370 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -66,6 +66,14 @@
 #defineCC_RB_BACKEND_DISABLE   0x98F4
 #defineBACKEND_DISABLE(x)  ((x)  
16)
 
+#define R_028808_CB_COLOR_CONTROL  0x28808
+#define   S_028808_SPECIAL_OP(x)   (((x)  0x7)  4)
+#define   G_028808_SPECIAL_OP(x)   (((x)  4)  0x7)
+#define   C_028808_SPECIAL_OP  0xFF8F
+#define V_028808_SPECIAL_NORMAL 0x00
+#define V_028808_SPECIAL_DISABLE0x01
+#define V_028808_SPECIAL_RESOLVE_BOX0x07
+
 #defineCB_COLOR0_BASE  0x28040
 #define

Re: [PATCH] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Daniel Vetter]

On Fri, Aug 24, 2012 at 07:56:31AM -0400, Calvin Walton wrote:
 This board is incorrectly detected as having an LVDS connector,
 resulting in the VGA output (the only available output on the board)
 showing the console only in the top-left 1024x768 pixels, and an extra
 LVDS connector appearing in X.
 
 It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
 chipset.
 
 I've had this board for about a year, but this is the first time I
 noticed the issue because I've been running it headless for most of its
 life.
 
 Signed-off-by: Calvin Walton calvin.wal...@kepstin.ca

Looks good, applied to -fixes.
-Daniel
 ---
 
 This board:
 http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp
 
 If you want any additional debug output from this machine, let me know
 what you would like and how to find it.
 
 I think this patch would probably be a reasonable candidate for -stable?
 
  drivers/gpu/drm/i915/intel_lvds.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
 b/drivers/gpu/drm/i915/intel_lvds.c
 index 08eb04c..2c58310 100644
 --- a/drivers/gpu/drm/i915/intel_lvds.c
 +++ b/drivers/gpu/drm/i915/intel_lvds.c
 @@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
   DMI_MATCH(DMI_BOARD_NAME, MS-7469),
   },
   },
 + {
 + .callback = intel_no_lvds_dmi_callback,
 + .ident = Gigabyte GA-D525TUD,
 + .matches = {
 + DMI_MATCH(DMI_BOARD_VENDOR, Gigabyte Technology Co., 
 Ltd.),
 + DMI_MATCH(DMI_BOARD_NAME, D525TUD),
 + },
 + },
  
   { } /* terminating entry */
  };
 -- 
 1.7.12
 
 -- 
 Calvin Walton calvin.wal...@kepstin.ca
 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #7 from Alan a...@lxorguk.ukuu.org.uk  2012-08-24 12:44:13 ---
If this is still seen in modern (3.2+) kernels, please re-open thanks

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54002] Massive screen corruption on Cayman

[bugzilla-daemon]

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

--- Comment #6 from Thomas Rohloff v10la...@myway.de 2012-08-24 12:44:33 UTC 
---
Okay, found a good commit and am bisecting. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: fixup the dma buf export cache locking

[Daniel Vetter]

On Fri, Aug 24, 2012 at 02:13:33PM +1000, Dave Airlie wrote:
 On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
  Well, actually add some, because currently there's exactly none:
  - in handle_to_fd we only take the file_priv's prime lock, but the
underlying gem object we're exporting isn't per-file.
  - in each driver's dma_buf-release callback we don't grab any locks
at all.
 
 Finally got to this patch and applied it to my test box and it
 explodes in the following
 
 start X, bind udl as an output slave, set a mode on the udl, then kill
 the X server,
 
 I get an oops on i915/radeon/nouveau, like

I have to admit that I don't see what's happening here :( But thinking
some more about the locking issues and race my patch tried to fix I
concluded that it's the wrong approach anyway - we still have ugly issues
left. The fundamental problem is that for the exporter we have 2
refcounts, the gem refcount and the dma_buf refcount, but we should only
destroy the gem object + it's dma_buf export if both are 0. And keep
everything around otherwise to avoid nasty issues with re-export or
reaping userspace-facing resources like the mmap_offset. But I haven't yet
grown clue how to handle this any better.

Slightly related: Jani discovered that we seem to have a leak, putting him
on cc just in case he's the one with clue ;-)

I've looked again at the other two patches inspired by this one, which fix
some races between gem names  gem flink. And I think those two are still
valid.

Yours, Daniel
 
 [ 8046.363596] general protection fault:  [#1] SMP
 [ 8046.364012] Modules linked in: fuse lockd rfcomm sunrpc bnep
 tpm_bios ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
 ip6_tables nf_conntrack_
 ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_conexant arc4
 iwldvm mac80211 coretemp kvm_intel snd_hda_intel snd_hda_codec kvm
 btusb snd_hwdep bluet
 ooth iwlwifi i915 snd_seq snd_seq_device microcode snd_pcm cfg80211
 snd_page_alloc i2c_i801 lpc_ich e1000e mfd_core snd_timer wmi
 thinkpad_acpi snd soundcore
 rfkill video uinput sdhci_pci sdhci udl syscopyarea sysfillrect
 sysimgblt firewire_ohci mmc_core drm_usb firewire_core crc_itu_t
 yenta_socket radeon i2c_algo_
 bit drm_kms_helper ttm drm i2c_core
 [ 8046.364012] CPU 0
 [ 8046.364012] Pid: 6947, comm: Xorg Tainted: GW3.6.0-rc3+
 #7 LENOVO 406334M/406334M
 [ 8046.364012] RIP: 0010:[a0388e0c]  [a0388e0c]
 i915_gem_unmap_dma_buf+0x5c/0xb0 [i915]
 [ 8046.364012] RSP: 0018:88002c22dc28  EFLAGS: 00010296
 [ 8046.364012] RAX: 0500 RBX: 880007d5d6d8 RCX: 
 
 [ 8046.364012] RDX: 0500 RSI: 8800570ca000 RDI: 
 88005b2ea5a8
 [ 8046.364012] RBP: 88002c22dc68 R08:  R09: 
 
 [ 8046.364012] R10:  R11: 0001 R12: 
 88005b2ea5a8
 [ 8046.364012] R13:  R14: 6b6b6b6b6b6b6b6b R15: 
 8800570ca000
 [ 8046.364012] FS:  7f79955759c0() GS:880078c0()
 knlGS:
 [ 8046.364012] CS:  0010 DS:  ES:  CR0: 80050033
 [ 8046.364012] CR2: 0031808bab90 CR3: 01c0b000 CR4: 
 07f0
 [ 8046.364012] DR0:  DR1:  DR2: 
 
 [ 8046.364012] DR3:  DR6: 0ff0 DR7: 
 0400
 [ 8046.364012] Process Xorg (pid: 6947, threadinfo 88002c22c000,
 task 88005d68)
 [ 8046.364012] Stack:
 [ 8046.364012]  880058d167b0 88000500 88002c22dc48
 88005f6f0f50
 [ 8046.364012]  88005d9622f8 88005d962290 
 
 [ 8046.364012]  88002c22dc78 81409182 88002c22dc98
 a002cfeb
 [ 8046.364012] Call Trace:
 [ 8046.364012]  [81409182] dma_buf_unmap_attachment+0x22/0x40
 [ 8046.364012]  [a002cfeb] drm_prime_gem_destroy+0x2b/0x50 [drm]
 [ 8046.364012]  [a01f9cb9] udl_gem_free_object+0x39/0x70 [udl]
 [ 8046.364012]  [a001695a] drm_gem_object_free+0x2a/0x30 [drm]
 [ 8046.364012]  [a00171a8]
 drm_gem_object_release_handle+0xa8/0xd0 [drm]
 [ 8046.364012]  [81319b85] idr_for_each+0xe5/0x180
 [ 8046.364012]  [a0017100] ? drm_gem_vm_open+0x70/0x70 [drm]
 [ 8046.364012]  [810bea2d] ? trace_hardirqs_on+0xd/0x10
 [ 8046.364012]  [a0017804] drm_gem_release+0x24/0x40 [drm]
 [ 8046.364012]  [a0015e1a] drm_release+0x55a/0x5f0 [drm]
 [ 8046.364012]  [811a908a] __fput+0xfa/0x2d0
 [ 8046.364012]  [811a926e] fput+0xe/0x10
 [ 8046.364012]  [81076c89] task_work_run+0x69/0xa0
 [ 8046.364012]  [81056aee] do_exit+0xa0e/0xb20
 [ 8046.364012]  [816887d5] ? retint_swapgs+0x13/0x1b
 [ 8046.364012]  [81056f4c] do_group_exit+0x4c/0xc0
 
 which implies some reference count is off or some object is freed in
 the wrong order.
 
 Dave.

-- 
Daniel Vetter
Mail: dan...@ffwll.ch

[Bug 36642] Oops on vgaswitcheroo from intel IGD to radeon DIS.

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||INSUFFICIENT_DATA




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36672] Kernel crashes when radeon is switched off with vga_switcheroo

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36892] page faults / general protection faults under heavy 3d load

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||a...@lxorguk.ukuu.org.uk




--- Comment #6 from Alan a...@lxorguk.ukuu.org.uk  2012-08-24 13:41:21 ---
Is this still seen on modern (3.2+) kernels ?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

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

--- Comment #31 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-08-24 
13:46:28 UTC ---
Just testing with 3.6.0-rc3+ from today's GIT and I can reproduce some sort of
sound corruption depending on the video output resolution.

For example, 1360x768 and audio plays fine, while 1366x768 and it is bad.

avivotool register dump says this is the difference between good and bad setup:

-EVERGREEN_AUDIO_PLL1_DIV   000d0bd8
+EVERGREEN_AUDIO_PLL1_DIV   000d1ae2

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36892] page faults / general protection faults under heavy 3d load

[bugzilla-daemon]

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


Niels Ole Salscheider niels_...@salscheider-online.de changed:

   What|Removed |Added

 Kernel Version|3.0-rc1 |3.6-rc1




--- Comment #7 from Niels Ole Salscheider niels_...@salscheider-online.de  
2012-08-24 14:29:42 ---
I have just tried to run sauerbraten under 3.6-rc1. It seems to work fine,
but I get page allocation failure messages in dmesg, see attachment.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel