date:20130320

[Bug 10642] via DRM Unimplemented DMA HEADER command (HALCYON_CMDB)

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

James Simmons  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from James Simmons  ---
Mesa is not supported at this time.

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

[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Orion Poplawski  ---
The problem is also present in mesa 9.0.3.  With that I also get the following
in dmesg:

Mar 20 13:51:28 aspen kernel: [162904.454217] [drm:r100_cs_track_check] *ERROR*
[drm] No buffer for z buffer !
Mar 20 13:51:28 aspen kernel: [162904.454224] [drm:radeon_cs_ib_chunk] *ERROR*
Invalid command stream !

But I don't seem to get that with 9.1.

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

[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Orion Poplawski  ---
Downgrading from llvm-libs-3.2-2.fc18 and mesa 9.1-1.fc18 to
llvm-libs-3.1-11.fc18 and mesa 9.0.1-1.fc18 appears to fix the issue.

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

[Bug 62577] [r600g] GPU lockup when playing WoW with HD6450 without htile enabled

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Alex Deucher  ---
Is this a regression?  if so can you bisect?

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

[Bug 62578] New: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 62578
  Assignee: dri-devel at lists.freedesktop.org
   Summary: r300: Implementation error: Render targets are too big
in r300_set_framebuffer_state, refusing to bind
framebuffer state!
  Severity: major
Classification: Unclassified
OS: All
  Reporter: orion at cora.nwra.com
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.1
 Component: Drivers/DRI/r300
   Product: Mesa

Created attachment 76846
  --> https://bugs.freedesktop.org/attachment.cgi?id=76846=edit
Xorg.0.log

Running KDE 4.10.1 on Fedora 18.  After login, screen flickers a bit but
nothing is displayed other than the background image.

.xsession-errors contains:
OpenGL vendor string:   X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RV370
OpenGL version string:  2.1 Mesa 9.1
OpenGL shading language version string: 1.20
Driver: R300G
GPU class:  R300
OpenGL version: 2.1
GLSL version:   1.20
Mesa version:   9.1
Linux kernel version:   3.8.3
Direct rendering:   yes
Requires strict binding:yes
GLSL shaders:   limited
Texture NPOT support:   limited
Virtual Machine:no
r300: Implementation error: Render targets are too big in
r300_set_framebuffer_state, refusing to bind framebuffer state!

this r300 messages keeps repeating.

kernel 3.8.3-203.fc18.i686.PAE

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV370
5B60 [Radeon X300 (PCIE)]

Just updated from Fedora 16 where this system was working fine.

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

[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #13 from Pavel Ondra?ka  ---
BTW i did a quick tests piglit run with your patch on my RV530 with no
regressions (no fixes either except 2 tests in EXT_framebuffer_multisample
group, however those seems to be fairly random... )

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

[Bug 62577] New: [r600g] GPU lockup when playing WoW with HD6450 without htile enabled

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 62577
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600g] GPU lockup when playing WoW with HD6450
without htile enabled
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: rankincj at googlemail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 76845
  --> https://bugs.freedesktop.org/attachment.cgi?id=76845=edit
dmesg output showing GPU lockup

Just tried to play WoW against Mesa git, having already set R600_HYPERZ=0 to
work around bug #61747. This resulted in a GPU lockup after a few minutes.

git HEAD is:

commit d24819dce8cf6dac23f27df46fabbf756a732229
Author: Kenneth Graunke 
Date:   Mon Mar 11 11:10:34 2013 -0700

i965/vs: Add IR dumping for immediates.

This makes dump_instructions more useful.

Signed-off-by: Kenneth Graunke 
Reviewed-by: Eric Anholt 

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

[Bug 62573] Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Benjamin  ---
If I am debugging it with gdb, it won't go past the loading screen for the main
menu. The last thing gdb says is "0xf776e425 in __kernel_vsyscall ()
". I don't know what that means.

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

[Bug 62573] Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Benjamin  ---
Yeah, it's segfaulting. It is 32-bit running on 64-bit Ubuntu, but I do have
multiarch support (and TF2 works fine, which is nearly the same engine and also
32-bit).

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

[Bug 62573] Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Benjamin  ---
Created attachment 76843
  --> https://bugs.freedesktop.org/attachment.cgi?id=76843=edit
Xorg.0.log

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

[Bug 62573] Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Benjamin  ---
Created attachment 76842
  --> https://bugs.freedesktop.org/attachment.cgi?id=76842=edit
dmesg

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

[Bug 62573] Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.  Also is this a 32-bit game
running on a 64-bit distro?  What do you mean by crash?  segfault?  system
hangs?  If it's a segfault or something like that can you get a backtrace with
gdb?

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

[GIT PULL] exynos-drm-fixes

2013-03-20 Thread Inki Dae

Hi Dave,

This pull request includes bug fixes and code cleanups.
And it considers some restrictions to G2D hardware.
With this, the malfunction and page fault issues to g2d driver
would be fixed.

If there is any problem, please kindly let me know.

Thanks,
Inki Dae

The following changes since commit 8698080ee092bdbd6ee2cd5e7f707ceea2812bd8:

  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-03-11 
13:53:58 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-fixes

Alexandru Gheorghiu (1):
  drm/exynos: Replaced kzalloc & memcpy with kmemdup

Inki Dae (1):
  drm/exynos: Add a new function to get gem buffer size

Leela Krishna Amudala (1):
  drm/exynos: fimd: calculate the correct address offset

Sachin Kamat (1):
  drm/exynos: Make mixer_check_timing static

Vikas Sajjan (1):
  drm/exynos: modify the compatible string for exynos fimd

YoungJun Cho (6):
  drm/exynos: Fix error routine to getting dma addr.
  drm/exynos: clear node object type at gem unmap
  drm/exynos: Fix G2D core malfunctioning issue
  drm/exynos: Clean up some G2D codes for readability
  drm/exynos: Deal with g2d buffer info more efficiently
  drm/exynos: Check g2d cmd list for g2d restrictions

 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   21 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  |  370 ++
 drivers/gpu/drm/exynos/exynos_drm_gem.c  |   21 ++
 drivers/gpu/drm/exynos/exynos_drm_gem.h  |5 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +-
 drivers/gpu/drm/exynos/exynos_mixer.c|2 +-
 6 files changed, 365 insertions(+), 60 deletions(-)

[Bug 62573] New: Half-Life 2: Deathmatch native version crashes

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 62573
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Half-Life 2: Deathmatch native version crashes
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: brpylko at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

As the title says, the native version of HL2:DM crashes on joining or creating
a server (when it loads a map I think). This does not happen under Wine nor
TF2. On the github page ValveSoftware/Source-1-Games I was told that the
problem lies in libgallium.

glxinfo reports the renderer as "Gallium 0.4 on AMD PALM", the version as "3.0
Mesa 9.2-devel", and the shading language version as "1.30" on my machine.

Would it help to post more output from glxinfo?

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

[Nouveau] nouveau lockdep splat

2013-03-20 Thread Lijo Antony

On 03/20/2013 10:35 AM, Lijo Antony wrote:
> I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git
> bisect in that mail is incorrect). While investigating, I found this
> issue was introduced during 3.9 merge window. For me this comes when I
> connect my TV via HDMI.

FWIW, git bisect gave this log,

git bisect start 'drivers/gpu/'
# good: [e450fcc6669705ef49784080ac6dd8513df37763] drm/tegra: Add list 
of framebuffers to debugfs
git bisect good e450fcc6669705ef49784080ac6dd8513df37763
# bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1
git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8
# good: [bab588fcfb6335c767d811a8955979f5440328e0] Merge tag 'soc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good bab588fcfb6335c767d811a8955979f5440328e0
# good: [be88298b0a3f771a4802f20c5e66af74bfd1dff1] drm/tilcdc: only 
build on arm
git bisect good be88298b0a3f771a4802f20c5e66af74bfd1dff1
# bad: [4d53233a36fdda567cd4d080e27e1ee4b669ddd1] drm: don't use 
idr_remove_all()
git bisect bad 4d53233a36fdda567cd4d080e27e1ee4b669ddd1
# good: [9afa3195b96da7d2320ec44d19fbfbded7a15571] Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
git bisect good 9afa3195b96da7d2320ec44d19fbfbded7a15571
# good: [496ad9aa8ef448058e36ca7a787c61f2e63f0f54] new helper: 
file_inode(file)
git bisect good 496ad9aa8ef448058e36ca7a787c61f2e63f0f54
# bad: [d895cb1af15c04c522a25c79cc429076987c089b] Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad d895cb1af15c04c522a25c79cc429076987c089b
# bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 
'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb

-lijo

[Bug 60963] [r300g] Anno1701: some models are red

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Pavel Ondra?ka  ---
Created attachment 76840
  --> https://bugs.freedesktop.org/attachment.cgi?id=76840=edit
RADEON_DEBUG=noopt,fp,vp output

(In reply to comment #1)
> Could you post a dump with RADEON_DEBUG=noopt,vp,fp

New log attached. However there is something bad going on. There are two bugs
affecting this game. This one and bug 60965, however when I reported them, this
bug used to disappeared with RADEON_DEBUG=noopt and bug 60965 didn't. Now when
I use RADEON_DEBUG=noopt, the corruption from bug 60965 is much worse and is
all over the place. The change did happened with 
f6c061261885fed0c83c437e9459ba79618f1b3a is the first bad commit
commit f6c061261885fed0c83c437e9459ba79618f1b3a
Author: Brian Paul 
Date:   Fri Mar 1 15:16:15 2013 -0700

st/mesa: convert ir_triop_lrp to TGSI_OPCODE_LRP

AFAICT, all gallium drivers implement TGSI_OPCODE_LRP.
Tested with softpipe, llvmpipe, svga drivers.

Reviewed-by: Matt Turner 

without RADEON_DEBUG=noopt the corruption is still the same, so my guess is
that r300 compiler somehow doesn't like TGSI_OPCODE_LRP, optimizes is away a
little bit, but not completely.

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

gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo

2013-03-20 Thread Jiri Kosina

On Tue, 19 Mar 2013, Alan Stern wrote:

> > > That might be misleading.  It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them.  If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> > 
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which obviously makes it impossible
> > for me to reproduce the issue. To test that theory, is there a quick
> > way to force-enable a given interrupt, short of just hacking up a 2nd
> > dummy irq handler in my driver?
> 
> I don't know of any way.  In fact, I have been thinking of writing a 
> test driver module, with a module parameter telling it which IRQ number 
> to register for.  It seems like the sort of thing that would be useful 
> to have, from time to time.

Ok, so how about this?
Daniel, is it enough to make the problem appear on your system (by 
building this into the kernel and booting with dummy-irq.irq=16)?

Thanks.





From: Jiri Kosina 
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver

This module accepts a single 'irq' parameter, which it should register for.

Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.

Suggested-by: Alan Stern 
Signed-off-by: Jiri Kosina 
---
 drivers/misc/Kconfig |8 ++
 drivers/misc/Makefile|1 +
 drivers/misc/dummy-irq.c |   59 ++
 3 files changed, 68 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/dummy-irq.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..db24b79 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
  TC can be used for other purposes, such as PWM generation and
  interval timing.

+config DUMMY_IRQ
+   tristate "Dummy IRQ handler"
+   default n
+   ---help---
+ This module accepts a single 'irq' parameter, which it should 
register for.
+ Its sole purpose is to help with debugging of IRQ sharing problems, by
+ force-enabling IRQ that would otherwise be disabled.
+
 config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
 obj-$(CONFIG_BMP085)   += bmp085.o
 obj-$(CONFIG_BMP085_I2C)   += bmp085-i2c.o
 obj-$(CONFIG_BMP085_SPI)   += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
 obj-$(CONFIG_ICS932S401)   += ics932s401.o
 obj-$(CONFIG_LKDTM)+= lkdtm.o
 obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..4fc13e0
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs cause the IRQ to be disabled.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+   static int count = 0;
+
+   if (count == 0) {
+   printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
+   count++;
+   }
+
+   return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+   if (request_irq(irq, _interrupt, IRQF_SHARED, "dummy_irq", )) 
{
+   printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+   return -EIO;
+   }
+   printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+   return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+   printk(KERN_INFO "dummy-irq unloaded\n");
+   free_irq(irq, );
+   return;
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param_named(irq, irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");

-- 
Jiri Kosina
SUSE Labs

[PATCH v2] drm/exynos: enable FIMD clocks

2013-03-20 Thread Vikas Sajjan

While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.

By calling clk_prepare_enable() for FIMD clocks fixes the issue.

this patch also replaces clk_disable() with clk_disable_unprepare()
during exit.

Signed-off-by: Vikas Sajjan 
---
Changes since v1:
- added error checking for clk_prepare_enable() and also replaced 
clk_disable() with clk_disable_unprepare() during exit.
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..014d750 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -934,6 +934,19 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}

+   ret = clk_prepare_enable(ctx->lcd_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable 'sclk_fimd' clock\n");
+   return ret;
+   }
+
+   ret = clk_prepare_enable(ctx->bus_clk);
+   if (ret) {
+   clk_disable_unprepare(ctx->lcd_clk);
+   dev_err(dev, "failed to enable 'fimd' clock\n");
+   return ret;
+   }
+
ctx->vidcon0 = pdata->vidcon0;
ctx->vidcon1 = pdata->vidcon1;
ctx->default_win = pdata->default_win;
@@ -981,8 +994,8 @@ static int fimd_remove(struct platform_device *pdev)
if (ctx->suspended)
goto out;

-   clk_disable(ctx->lcd_clk);
-   clk_disable(ctx->bus_clk);
+   clk_disable_unprepare(ctx->lcd_clk);
+   clk_disable_unprepare(ctx->bus_clk);

pm_runtime_set_suspended(dev);
pm_runtime_put_sync(dev);
-- 
1.7.9.5

[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]

2013-03-20 Thread Greg KH

On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote:
> On Wed, 20 Mar 2013, Alan Stern wrote:
> 
> > > Ok, so how about this?
> > > Daniel, is it enough to make the problem appear on your system (by 
> > > building this into the kernel and booting with dummy-irq.irq=16)?
> > > 
> > > Thanks.
> > > 
> > > From: Jiri Kosina 
> > > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
> > > 
> > > This module accepts a single 'irq' parameter, which it should register 
> > > for.
> > > 
> > > Its sole purpose is to help with debugging of IRQ sharing problems, by
> > > force-enabling IRQ that would otherwise be disabled.
> > > 
> > > Suggested-by: Alan Stern 
> > > Signed-off-by: Jiri Kosina 
> > 
> > This is just what I was thinking of.  Three extremely minor 
> > suggestions...
> 
> Thanks Alan. Updated version below.
> 
> Greg, willing to merge this simple debugging facility?

Yes, I'll take it, give me a few days to catch up with my pending queue,
don't worry, it's not lost.

greg k-h

[Nouveau] nouveau lockdep splat

2013-03-20 Thread Borislav Petkov

On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote:
> # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb

This is a merge commit which means something went wrong along the way of
the bisection.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH v4 17/21] modetest: Give the CRTC ID to the -P option

2013-03-20 Thread Laurent Pinchart

Hi Rob,

On Tuesday 19 March 2013 14:21:32 Rob Clark wrote:
> On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart wrote:
> > Planes are associated with CRTCs, not connectors. Don't try to be too
> > clever, use the CRTC ID in the -P option. This prepares for splitting
> > CRTC and planes setup.
> 
> hmm, I was thinking that it would be nice to someday make modetest clever
> enough to deal w/ connector names instead of connector-id..

That's a good idea (and it shouldn't be too difficult to implement).

> this kinda goes in the opposite direction.

Please note that I use the CRTC ID instead of the connector ID for planes 
setup only. Planes are associated with a CRTC, not a connector. I thus thought 
it made sense to use the CRTC ID in the argument.

If you think that's a bad idea I can drop the patch. Should modetest then 
associate the planes with the CRTC currently associated with the given 
connector ?

-- 
Regards,

Laurent Pinchart

[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #12 from Pavel Ondra?ka  ---
(In reply to comment #11)
> Created attachment 76797 [details] [review]
> Possible fix v3
> 
> Does this patch help?

Yes, this one fixes it.

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

[Bug 61182] r600g causes KWin crashes with kernel 3.8

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #15 from Eugene Shalygin  ---
(In reply to comment #14)
Also tried both suggestions. Both changes together allows me to run `kwin
--replace` with active kwin_gles. However, when I connect a second screen, it
crashes (signal 7) with the same backtrace. When I toggle desktop effects, it
crashes also.

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

[PATCH v2 0/7] xfree86: Handle drm race condition

2013-03-20 Thread Chris Wilson

On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote:
> Is the drmSetInterfaceVersion call really needed here? If I look at 
> DRM_IOCTL_GET_UNIQUE,
> I don't see any requirement of drm master or anything, so it looks to me like 
> for this specific race
> the drmSetInterfaceVersion call can be skipped entirely without any side 
> effects.
> This would end up with cleaner code here, and drop the master requirement 
> entirely.

Indeed, it does look like drmSetVersion() at that point is overkill.
Instead we will hit the race later in the drivers. For the purposes of
clearer code, we could happily lose that drmSetVersion().

> Of course there's still a race that needs to be investigated, and is 
> currently not completely understood, I think.

We are all in agreement. Ultimately we want to root cause the race, in
the meantime we need a fallback to make sure that no desktop is left
behind!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

freeze with drm/i915

2013-03-20 Thread Daniel Vetter

On Wed, Mar 20, 2013 at 12:34 PM, Francesco Allertsen
 wrote:
> I have experienced since few kernel releases some freezes of my PC. The
> freeze is totally random, it can happen two times in one hour or nothing
> for an entire week, and the open programs are never the same (except
> maybe for Chromium).
>
> Last week I had the time to bisect the problem to try to solve it,
> because I found that since few releases I get the following report on
> dmesg:

Yeah, that's a different issue and actually a long-standing bug in our
display code, at least on ironlake. Which seems to be your system (I
can never remember the marketing names, lspci -nn would clarify ...).
We've only recently added the more obnoxious warning for it. So not
really a regression. Also, this only tends to happen with a DP screen.

Note that on ironlake the known hard-hang is caused by enabling rc6
(disabled by default). So if you have that set, please disable it.

If that's not your hang I think we should try to capture the dying
breadths of your system with netconsole to check whether anything
interesting is in there.

Thanks, Daniel

>
> [   15.993547] [ cut here ]
> [   15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
> intel_wait_for_pipe_off+0x11b/0x126 [i915]()
> [   15.993579] Hardware name: 5129CTO
> [   15.993581] pipe_off wait timed out
> [   15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) 
> vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel 
> snd_hda_codec snd_hwdep drm_kms_helper
> [   15.993593] Pid: 1566, comm: X Tainted: G   O 3.8.1 #1
> [   15.993595] Call Trace:
> [   15.993604]  [] warn_slowpath_common+0x68/0x7d
> [   15.993617]  [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915]
> [   15.993621]  [] warn_slowpath_fmt+0x2b/0x2f
> [   15.993635]  [] intel_wait_for_pipe_off+0x11b/0x126 [i915]
> [   15.993649]  [] intel_disable_pipe+0x115/0x11d [i915]
> [   15.993662]  [] ironlake_crtc_disable+0xb2/0x688 [i915]
> [   15.993677]  [] intel_set_mode+0x398/0x7b0 [i915]
> [   15.993683]  [] ? should_resched+0x8/0x22
> [   15.993688]  [] ? _cond_resched+0xd/0x21
> [   15.993694]  [] ? __getblk+0x28/0x282
> [   15.993697]  [] ? __find_get_block_slow+0x11c/0x12a
> [   15.993713]  [] intel_crtc_set_config+0x4de/0x651 [i915]
> [   15.993718]  [] drm_mode_setcrtc+0x34b/0x39d
> [   15.993721]  [] ? drm_mode_setplane+0x27a/0x27a
> [   15.993725]  [] drm_ioctl+0x275/0x323
> [   15.993727]  [] ? drm_mode_setplane+0x27a/0x27a
> [   15.993730]  [] ? drm_version+0x8b/0x8b
> [   15.993734]  [] vfs_ioctl+0x20/0x2a
> [   15.993736]  [] do_vfs_ioctl+0x3eb/0x429
> [   15.993740]  [] ? fsnotify_modify+0x48/0x53
> [   15.993743]  [] ? wait_on_retry_sync_kiocb+0x44/0x44
> [   15.993745]  [] ? vfs_write+0x8a/0xac
> [   15.993748]  [] sys_ioctl+0x41/0x60
> [   15.993751]  [] syscall_call+0x7/0xb
> [   15.993753] ---[ end trace fe4cfed2900ae9cb ]---
>
> Then after the bisect the following is the first commit that trigger
> this warning:
>
> 284637d9229dc1115947bb04008730844afbc059 is the first bad commit
> commit 284637d9229dc1115947bb04008730844afbc059
> Author: Daniel Vetter 
> Date:   Mon Jul 9 09:51:57 2012 +0200
>
> drm/i915: WARN if the pipe won't turn off
>
> This seems to be the symptom of a few neat bugs, hence be more
> obnoxious when this fails.
>
> So, it seems that there is some other bug somewhere. If you have any
> idea or you need more tests from me I'm happy to figure it out.
>
> Currently I am using the kernel 3.8.1, but I would like to test the
> latest git soon if someone has already solved it or not. My laptop is a
> Lenovo X201s and this is my video card:
>
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor 
> Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
> Subsystem: Lenovo Device 215a
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 44
> Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 1800 [size=8]
> Expansion ROM at  [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0f00c  Data: 41d1
> Capabilities: [d0] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [a4] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: i915
>
> If you need more information please just let me know.
>
> Thank you.
>
> Regards,
>

gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo

2013-03-20 Thread Alan Stern

On Wed, 20 Mar 2013, Jiri Kosina wrote:

> > I don't know of any way.  In fact, I have been thinking of writing a 
> > test driver module, with a module parameter telling it which IRQ number 
> > to register for.  It seems like the sort of thing that would be useful 
> > to have, from time to time.
> 
> Ok, so how about this?
> Daniel, is it enough to make the problem appear on your system (by 
> building this into the kernel and booting with dummy-irq.irq=16)?
> 
> Thanks.
> 
> 
> 
> 
> 
> From: Jiri Kosina 
> Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
> 
> This module accepts a single 'irq' parameter, which it should register for.
> 
> Its sole purpose is to help with debugging of IRQ sharing problems, by
> force-enabling IRQ that would otherwise be disabled.
> 
> Suggested-by: Alan Stern 
> Signed-off-by: Jiri Kosina 

This is just what I was thinking of.  Three extremely minor 
suggestions...

> +static irqreturn_t dummy_interrupt(int irq, void *dev_id)
> +{
> + static int count = 0;
> +
> + if (count == 0) {
> + printk("dummy-irq: interrupt occured on IRQ %d\n", irq);

You probably should put a severity level here.  KERN_INFO?

> + count++;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +static int __init dummy_irq_init(void)
> +{
> + if (request_irq(irq, _interrupt, IRQF_SHARED, "dummy_irq", )) 
> {
> + printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
> + return -EIO;
> + }
> + printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
> + return 0;
> +}
> +
> +static void __exit dummy_irq_exit(void)
> +{
> + printk(KERN_INFO "dummy-irq unloaded\n");
> + free_irq(irq, );
> + return;

A return statement isn't needed here.

> +}
> +
> +module_init(dummy_irq_init);
> +module_exit(dummy_irq_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jiri Kosina");
> +module_param_named(irq, irq, uint, 0444);

module_param is good enough when the parameter's name is the same as 
the variable's name.

> +MODULE_PARM_DESC(irq, "The IRQ to register for");

Alan Stern

freeze with drm/i915

2013-03-20 Thread Francesco Allertsen

Hello everyone,

I have experienced since few kernel releases some freezes of my PC. The
freeze is totally random, it can happen two times in one hour or nothing
for an entire week, and the open programs are never the same (except
maybe for Chromium).

Last week I had the time to bisect the problem to try to solve it,
because I found that since few releases I get the following report on
dmesg:

[   15.993547] [ cut here ]
[   15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
intel_wait_for_pipe_off+0x11b/0x126 [i915]()
[   15.993579] Hardware name: 5129CTO
[   15.993581] pipe_off wait timed out
[   15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) 
vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel 
snd_hda_codec snd_hwdep drm_kms_helper
[   15.993593] Pid: 1566, comm: X Tainted: G   O 3.8.1 #1
[   15.993595] Call Trace:
[   15.993604]  [] warn_slowpath_common+0x68/0x7d
[   15.993617]  [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915]
[   15.993621]  [] warn_slowpath_fmt+0x2b/0x2f
[   15.993635]  [] intel_wait_for_pipe_off+0x11b/0x126 [i915]
[   15.993649]  [] intel_disable_pipe+0x115/0x11d [i915]
[   15.993662]  [] ironlake_crtc_disable+0xb2/0x688 [i915]
[   15.993677]  [] intel_set_mode+0x398/0x7b0 [i915]
[   15.993683]  [] ? should_resched+0x8/0x22
[   15.993688]  [] ? _cond_resched+0xd/0x21
[   15.993694]  [] ? __getblk+0x28/0x282
[   15.993697]  [] ? __find_get_block_slow+0x11c/0x12a
[   15.993713]  [] intel_crtc_set_config+0x4de/0x651 [i915]
[   15.993718]  [] drm_mode_setcrtc+0x34b/0x39d
[   15.993721]  [] ? drm_mode_setplane+0x27a/0x27a
[   15.993725]  [] drm_ioctl+0x275/0x323
[   15.993727]  [] ? drm_mode_setplane+0x27a/0x27a
[   15.993730]  [] ? drm_version+0x8b/0x8b
[   15.993734]  [] vfs_ioctl+0x20/0x2a
[   15.993736]  [] do_vfs_ioctl+0x3eb/0x429
[   15.993740]  [] ? fsnotify_modify+0x48/0x53
[   15.993743]  [] ? wait_on_retry_sync_kiocb+0x44/0x44
[   15.993745]  [] ? vfs_write+0x8a/0xac
[   15.993748]  [] sys_ioctl+0x41/0x60
[   15.993751]  [] syscall_call+0x7/0xb
[   15.993753] ---[ end trace fe4cfed2900ae9cb ]---

Then after the bisect the following is the first commit that trigger
this warning:

284637d9229dc1115947bb04008730844afbc059 is the first bad commit
commit 284637d9229dc1115947bb04008730844afbc059
Author: Daniel Vetter 
Date:   Mon Jul 9 09:51:57 2012 +0200

drm/i915: WARN if the pipe won't turn off

This seems to be the symptom of a few neat bugs, hence be more
obnoxious when this fails.

So, it seems that there is some other bug somewhere. If you have any
idea or you need more tests from me I'm happy to figure it out.

Currently I am using the kernel 3.8.1, but I would like to test the
latest git soon if someone has already solved it or not. My laptop is a
Lenovo X201s and this is my video card:

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated 
Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 215a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c  Data: 41d1
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915

If you need more information please just let me know.

Thank you.

Regards,
Francesco

[PULL] drm-intel-fixes

2013-03-20 Thread Daniel Vetter

Hi Dave,

Bunch of fixes, all pretty high-priority
- Fix execbuf argument checking (Kees Cook)
- Optionally obfuscate kernel addresses in dumps (Kees Cook)
- Two patches from Takashi Iwai to fix DP link training regressions he's
  seen.
- intel-gfx is no longer subscribers-only (well, just no longer moderated
  in an annoying way for non-subscribers), update MAINTAINERS
- gm45 gmbus irq fallout fix (Jiri Kosina)

Cheers, Daniel


The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4:

  drm/i915: stop using GMBUS IRQs on Gen4 chips (2013-03-20 00:03:16 +0100)


Daniel Vetter (1):
  MAINTAINERS: intel-gfx is no longer subscribers-only

Jiri Kosina (1):
  drm/i915: stop using GMBUS IRQs on Gen4 chips

Kees Cook (2):
  drm/i915: restrict kernel address leak in debugfs
  drm/i915: bounds check execbuffer relocation count

Takashi Iwai (2):
  Revert "drm/i915: try to train DP even harder"
  drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()

 MAINTAINERS|2 +-
 drivers/gpu/drm/i915/i915_debugfs.c|2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 ---
 drivers/gpu/drm/i915/intel_dp.c|   14 --
 drivers/gpu/drm/i915/intel_i2c.c   |   11 ++-
 5 files changed, 32 insertions(+), 8 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 0/7] xfree86: Handle drm race condition

2013-03-20 Thread Maarten Lankhorst

Op 20-03-13 09:40, Maarten Lankhorst schreef:
> Hey,
>
> Op 19-03-13 22:13, Chris Wilson schreef:
>> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>>> The drmSetMaster call is needed, but the spinning is really just waiting 
>>> for the workqueue to run.
>>>
>>> bryce's patch never worked, it just caused it to try drmsetinterfaceversion 
>>> for a few seconds before timing out. That call
>>> was failing because his patch series never tried to obtain drm master.
>> You missed that the series Bryce posted did contain the drmSetMaster()
>> call inside the loop to retry drmSetVersion(). :)
>>
>>
> Oh I must have missed that.
>
> Is the drmSetInterfaceVersion call really needed here? If I look at 
> DRM_IOCTL_GET_UNIQUE,
> I don't see any requirement of drm master or anything, so it looks to me like 
> for this specific race
> the drmSetInterfaceVersion call can be skipped entirely without any side 
> effects.
> This would end up with cleaner code here, and drop the master requirement 
> entirely.
>
> Of course there's still a race that needs to be investigated, and is 
> currently not completely understood, I think.
>
Or worse, is that drmGetBusId call there even useful? From digging at the 
kernel it seems it's a per master value.
So if a device is hotplugged, it wouldn't be set yet. If someone else holds 
master, it wouldn't be set either.
In fact it would only be ever set from DRIOpenDRMMaster, but that call only 
happens a lot later, if it even happens at all.

It seems to me like opening the fd there should be removed entirely, and the 
bus id should be retrieved from the udev event instead.

I'll try to get something working for this.

~Maarten

Xen guest paravirtualized framebuffer with GEM

2013-03-20 Thread Ben Guthro

Background:
In order for me to properly ask this question, let me first describe what we
are trying to accomplish.

We (Citrix XenClient Enterprise team http://www.citrix.com/xenclient ) are
attempting to use Xen, in combination with GEM to get a zero copy
paravirtualized rendering path from a guest framebuffer running on a local
machine where the guest takes up a full screen window in Xorg.

The intent here is to ultimately
a. Get GEM to manage the memory in GTT space
b. Get the guest framebuffer to render into that memory
c. Get that memory displayed on an X window

The approach we have taken thus far is
1. Modify libdrm/i915 kernel driver to have a new ioctl that will return an
array of pfns for the pages in a gem object

2. Modify Xen to allow access to pages from multiple domains, similar to
the suggestion in this thread:
http://www.gossamer-threads.com/lists/xen/devel/215894?do=post_view_threaded#215894

3. Modify qemu to
a. Create a gem object.
b. Map the gem object.
c. Pin the gem object.
d. Get the pfns of the gem object, as described in 1.
e. Add these pfns to the guest's framebuffer

And so we come to the problem - how do you get this buffer on screen?

Ideally, this would be mapped to some GL buffer, so we could use the
standard GLX calls to manipulate this data.

However, since all of the APIs are hardware agnostic, I'm struggling to see
a path that allows us to take this GEM object, and create something we can
actually get on the screen.

The following post from Jessie Barnes provided some suggestions, but I'm
not sure it is entirely what we want:
http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_

I also just also came across Chris Wilson's new proposed userptr ioctl.
https://patchwork.kernel.org/patch/2139711/
This seems very similar to what we did with the Xen specific
modification...but it is still not obvious to me how to take such an object
and turn it into something usable with OpenGL.

So this is my question -
>From a high level, does this sound like an approach that is viable?
If so - how would you recommend we go about that last bit about getting the
gem
object on screen?

If not - where do you see the architecture falling over?

Is there an easier way to do what we are trying to do?

Thanks for any insight you can provide.

Ben
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/8dbea643/attachment.html>

[PATCHv2 0/3] PCI Speed Cap Fixes for ppc64

2013-03-20 Thread Jerome Glisse

On Wed, Mar 20, 2013 at 1:24 AM, Lucas Kannebley Tavares
 wrote:
> This patch series first implements a function called pcie_get_speed_cap_mask
> in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
> it removes the latter and fixes all references to it. And ultimately, it
> implements an architecture-specific version of the same function for ppc64.
>
> The refactor is done because the function that was used by drm is more
> architecture goo than module-specific. Whilst the function also needed a
> platform-specific implementation to get PCIE Gen2 speeds on ppc64.

Looks good to me but we probably want some one from the pci side to take a look

Reviewed-by: Jerome Glisse 

>
> Lucas Kannebley Tavares (3):
>   pci: added pcie_get_speed_cap_mask function
>   drm: removed drm_pcie_get_speed_cap_mask function
>   ppc64: implemented pcibios_get_speed_cap_mask
>
>  arch/powerpc/platforms/pseries/pci.c |   35 +++
>  drivers/gpu/drm/drm_pci.c|   38 -
>  drivers/gpu/drm/radeon/evergreen.c   |5 ++-
>  drivers/gpu/drm/radeon/r600.c|5 ++-
>  drivers/gpu/drm/radeon/rv770.c   |5 ++-
>  drivers/pci/pci.c|   44 
> ++
>  include/drm/drmP.h   |6 
>  include/linux/pci.h  |6 
>  8 files changed, 94 insertions(+), 50 deletions(-)
>
> --
> 1.7.4.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/omap: Add device tree support to DMM

2013-03-20 Thread Rob Clark

On Tue, Mar 19, 2013 at 4:36 PM, Andy Gross  wrote:
> Added in detection/support for DMM devices when booting with device
> tree.
>
> Signed-off-by: Andy Gross 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..d84f37c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "omap_dmm_tiler.h"
>  #include "omap_dmm_priv.h"
> @@ -968,6 +969,14 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
>  };
>  #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id omap_dmm_of_match[] = {
> +   {.compatible = "ti,dmm", },
> +   {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_dmm_of_match);
> +#endif
> +
>  struct platform_driver omap_dmm_driver = {
> .probe = omap_dmm_probe,
> .remove = omap_dmm_remove,
> @@ -977,6 +986,7 @@ struct platform_driver omap_dmm_driver = {
>  #ifdef CONFIG_PM
> .pm = _dmm_pm_ops,
>  #endif
> +   .of_match_table = of_match_ptr(omap_dmm_of_match),
> },
>  };
>
> --
> 1.7.5.4
>

[Nouveau] nouveau lockdep splat

2013-03-20 Thread Lijo Antony

On 03/20/2013 12:40 AM, Peter Hurley wrote:
>>
>> with the hope of having the right people on CC now (finally, thanks
>> Lucas :-)), here's the same splat on -rc3. Someone better take a look
>> soonish, please:
>
> Also happens in next (on nv50 hardware).

I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git 
bisect in that mail is incorrect). While investigating, I found this 
issue was introduced during 3.9 merge window. For me this comes when I 
connect my TV via HDMI. But for a couple of tags during bisecting, I 
have seen the same during boot also.

-lijo

[PATCH v2 0/7] xfree86: Handle drm race condition

2013-03-20 Thread Maarten Lankhorst

Hey,

Op 19-03-13 22:13, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>> The drmSetMaster call is needed, but the spinning is really just waiting for 
>> the workqueue to run.
>>
>> bryce's patch never worked, it just caused it to try drmsetinterfaceversion 
>> for a few seconds before timing out. That call
>> was failing because his patch series never tried to obtain drm master.
> You missed that the series Bryce posted did contain the drmSetMaster()
> call inside the loop to retry drmSetVersion(). :)
>
>
Oh I must have missed that.

Is the drmSetInterfaceVersion call really needed here? If I look at 
DRM_IOCTL_GET_UNIQUE,
I don't see any requirement of drm master or anything, so it looks to me like 
for this specific race
the drmSetInterfaceVersion call can be skipped entirely without any side 
effects.
This would end up with cleaner code here, and drop the master requirement 
entirely.

Of course there's still a race that needs to be investigated, and is currently 
not completely understood, I think.

~Maarten

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

Maarten Lankhorst  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Maarten Lankhorst  ---
The size increase only happens if radeonsi is built too, and can be countered
with the shared libgallium patch.

The original bug described here is fixed with these 2 commits:

36320bfa54b758b34 - radeon/llvm: Link against libgallium.la to fix an undefined
symbol
7c3d8301afed46cf9 - radeon/llvm: Do not link against libgallium when building
statically.

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

[PATCHv2 3/3] ppc64: implemented pcibios_get_speed_cap_mask

2013-03-20 Thread Benjamin Herrenschmidt

On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote:
> Implementation of a architecture-specific pcibios_get_speed_cap_mask.
> This implementation detects bus capabilities based on OF
> ibm,pcie-link-speed-stats property.

The problem with your approach is that it's not a runtime detection...

If the pseries machine is compiled into the kernel binary, it will
override pcibios_get_speed_cap_mask() using the device-tree, regardless
of whether the machine is currently booted on a pseries machine or not.

This wouldn't be a big problem if the pseries
pcibios_get_speed_cap_mask() was capable of doing a fallback to the
generic one if the device-tree property is absent but that isn't the
case.

I think what you need to do is:

  - Make it so the generic one can be called by the override. This can
look a bit tricky but it's better that way. One way to do it is to have
the actual implementation be in a __pci_* variant called by the weak
pcibios_* variant

  - Move the powerpc on to arch/powerpc/kernel/pci-common.c and make
it call a ppc_md.pcibios_get_speed_cap_mask(). If the hook is absent
(NULL), make it call the generic one

  - pseries can then populate the hook in ppc_md. with its custom
variant.

Cheers,
Ben.

[Bug 60963] [r300g] Anno1701: some models are red

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Tom Stellard  ---
Could you post a dump with RADEON_DEBUG=noopt,vp,fp

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

[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black

2013-03-20 Thread bugzilla-dae...@freedesktop.org

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

Tom Stellard  changed:

   What|Removed |Added

  Attachment #74520|0   |1
is obsolete||

--- Comment #11 from Tom Stellard  ---
Created attachment 76797
  --> https://bugs.freedesktop.org/attachment.cgi?id=76797=edit
Possible fix v3

Does this patch help?

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

[PATCHv2 3/3] ppc64: implemented pcibios_get_speed_cap_mask

2013-03-20 Thread Lucas Kannebley Tavares

Implementation of a architecture-specific pcibios_get_speed_cap_mask.
This implementation detects bus capabilities based on OF
ibm,pcie-link-speed-stats property.

Signed-off-by: Lucas Kannebley Tavares 
---
 arch/powerpc/platforms/pseries/pci.c |   35 ++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/pci.c 
b/arch/powerpc/platforms/pseries/pci.c
index 0b580f4..4da8deb 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -108,3 +109,37 @@ static void fixup_winbond_82c105(struct pci_dev* dev)
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
 fixup_winbond_82c105);
+
+int pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+   struct device_node *dn, *pdn;
+   const uint32_t *pcie_link_speed_stats = NULL;
+
+   *mask = 0;
+   dn = pci_bus_to_OF_node(dev->bus);
+
+   /* Find nearest ibm,pcie-link-speed-stats, walking up the device tree */
+   for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
+   pcie_link_speed_stats = (const uint32_t *) of_get_property(pdn,
+   "ibm,pcie-link-speed-stats", NULL);
+   if (pcie_link_speed_stats != NULL)
+   break;
+   }
+
+   if (pcie_link_speed_stats == NULL) {
+   dev_info(>dev, "no ibm,pcie-link-speed-stats property\n");
+   return -EINVAL;
+   }
+
+   switch (pcie_link_speed_stats[0]) {
+   case 0x02:
+   *mask |= PCIE_SPEED_50;
+   case 0x01:
+   *mask |= PCIE_SPEED_25;
+   case 0x00:
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
-- 
1.7.4.4

[PATCHv2 2/3] drm: removed drm_pcie_get_speed_cap_mask function

2013-03-20 Thread Lucas Kannebley Tavares

This function was moved to the pci subsystem where it fits better, as
this is much more of a generic pci task, than a drm specific one. All
references to the function (all in the radeon driver) are updated.

This is the second step in moving function drm_pcie_get_speed_cap_mask
from the drm subsystem to the pci one.

Signed-off-by: Lucas Kannebley Tavares 
---
 drivers/gpu/drm/drm_pci.c  |   38 
 drivers/gpu/drm/radeon/evergreen.c |5 ++-
 drivers/gpu/drm/radeon/r600.c  |5 ++-
 drivers/gpu/drm/radeon/rv770.c |5 ++-
 include/drm/drmP.h |6 -
 5 files changed, 9 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..ba70844 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -439,44 +439,6 @@ int drm_pci_init(struct drm_driver *driver, struct 
pci_driver *pdriver)
return 0;
 }

-int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
-{
-   struct pci_dev *root;
-   u32 lnkcap, lnkcap2;
-
-   *mask = 0;
-   if (!dev->pdev)
-   return -EINVAL;
-
-   root = dev->pdev->bus->self;
-
-   /* we've been informed via and serverworks don't make the cut */
-   if (root->vendor == PCI_VENDOR_ID_VIA ||
-   root->vendor == PCI_VENDOR_ID_SERVERWORKS)
-   return -EINVAL;
-
-   pcie_capability_read_dword(root, PCI_EXP_LNKCAP, );
-   pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, );
-
-   if (lnkcap2) {  /* PCIe r3.0-compliant */
-   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
-   *mask |= DRM_PCIE_SPEED_25;
-   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
-   *mask |= DRM_PCIE_SPEED_50;
-   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
-   *mask |= DRM_PCIE_SPEED_80;
-   } else {/* pre-r3.0 */
-   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
-   *mask |= DRM_PCIE_SPEED_25;
-   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
-   *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
-   }
-
-   DRM_INFO("probing gen 2 caps for device %x:%x = %x/%x\n", root->vendor, 
root->device, lnkcap, lnkcap2);
-   return 0;
-}
-EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);
-
 #else

 int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver)
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..6ba204d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "radeon.h"
 #include "radeon_asic.h"
@@ -3871,11 +3872,11 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
*rdev)
if (ASIC_IS_X2(rdev))
return;

-   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, );
+   ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, );
if (ret != 0)
return;

-   if (!(mask & DRM_PCIE_SPEED_50))
+   if (!(mask & PCIE_SPEED_50))
return;

speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0740db3..89a7387 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "radeon.h"
@@ -4371,11 +4372,11 @@ static void r600_pcie_gen2_enable(struct radeon_device 
*rdev)
if (rdev->family <= CHIP_R600)
return;

-   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, );
+   ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, );
if (ret != 0)
return;

-   if (!(mask & DRM_PCIE_SPEED_50))
+   if (!(mask & PCIE_SPEED_50))
return;

speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index d63fe1d..81c7f1c 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "radeon.h"
 #include "radeon_asic.h"
@@ -1254,11 +1255,11 @@ static void rv770_pcie_gen2_enable(struct radeon_device 
*rdev)
if (ASIC_IS_X2(rdev))
return;

-   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, );
+   ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, );
if (ret != 0)
return;

-   if (!(mask & DRM_PCIE_SPEED_50))
+   if (!(mask & PCIE_SPEED_50))
return;

DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0\n");
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..39b2872 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1788,12 +1788,6 @@ extern int drm_get_pci_dev(struct

[PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

2013-03-20 Thread Lucas Kannebley Tavares

Added function to gather the speed cap for a device and return a mask to
supported speeds. The function is divided into an interface and a weak
implementation so that architecture-specific functions can be called.

This is the first step in moving function drm_pcie_get_speed_cap_mask
from the drm subsystem to the pci one.

Signed-off-by: Lucas Kannebley Tavares 
---
 drivers/pci/pci.c   |   44 
 include/linux/pci.h |6 ++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b099e00..d94ab79 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3931,6 +3931,50 @@ static int __init pci_setup(char *str)
 }
 early_param("pci", pci_setup);

+int __weak pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+   struct pci_dev *root;
+   u32 lnkcap, lnkcap2;
+
+   *mask = 0;
+   if (!dev)
+   return -EINVAL;
+
+   root = dev->bus->self;
+
+   /* we've been informed via and serverworks don't make the cut */
+   if (root->vendor == PCI_VENDOR_ID_VIA ||
+   root->vendor == PCI_VENDOR_ID_SERVERWORKS)
+   return -EINVAL;
+
+   pcie_capability_read_dword(root, PCI_EXP_LNKCAP, );
+   pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, );
+
+   if (lnkcap2) {  /* PCIe r3.0-compliant */
+   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
+   *mask |= PCIE_SPEED_25;
+   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
+   *mask |= PCIE_SPEED_50;
+   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
+   *mask |= PCIE_SPEED_80;
+   } else {/* pre-r3.0 */
+   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
+   *mask |= PCIE_SPEED_25;
+   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
+   *mask |= (PCIE_SPEED_25 | PCIE_SPEED_50);
+   }
+
+   dev_info(>dev, "probing gen 2 caps for device %x:%x = %x/%x\n",
+   root->vendor, root->device, lnkcap, lnkcap2);
+   return 0;
+}
+
+int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+   return pcibios_get_speed_cap_mask(dev, mask);
+}
+EXPORT_SYMBOL(pcie_get_speed_cap_mask);
+
 EXPORT_SYMBOL(pci_reenable_device);
 EXPORT_SYMBOL(pci_enable_device_io);
 EXPORT_SYMBOL(pci_enable_device_mem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2461033a..24a2f63 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1861,4 +1861,10 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct 
pci_dev *pdev)
  */
 struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);

+#define PCIE_SPEED_25 1
+#define PCIE_SPEED_50 2
+#define PCIE_SPEED_80 4
+
+extern int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *speed_mask);
+
 #endif /* LINUX_PCI_H */
-- 
1.7.4.4

[PATCHv2 0/3] PCI Speed Cap Fixes for ppc64

2013-03-20 Thread Lucas Kannebley Tavares

This patch series first implements a function called pcie_get_speed_cap_mask 
in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then 
it removes the latter and fixes all references to it. And ultimately, it
implements an architecture-specific version of the same function for ppc64.

The refactor is done because the function that was used by drm is more 
architecture goo than module-specific. Whilst the function also needed a 
platform-specific implementation to get PCIE Gen2 speeds on ppc64.

Lucas Kannebley Tavares (3):
  pci: added pcie_get_speed_cap_mask function
  drm: removed drm_pcie_get_speed_cap_mask function
  ppc64: implemented pcibios_get_speed_cap_mask

 arch/powerpc/platforms/pseries/pci.c |   35 +++
 drivers/gpu/drm/drm_pci.c|   38 -
 drivers/gpu/drm/radeon/evergreen.c   |5 ++-
 drivers/gpu/drm/radeon/r600.c|5 ++-
 drivers/gpu/drm/radeon/rv770.c   |5 ++-
 drivers/pci/pci.c|   44 ++
 include/drm/drmP.h   |6 
 include/linux/pci.h  |6 
 8 files changed, 94 insertions(+), 50 deletions(-)

-- 
1.7.4.4

Re: [PATCH v2 3/4] drm/omap: Make fixed resolution panels work

2013-03-20 Thread Tomi Valkeinen

On 2013-03-19 08:45, Archit Taneja wrote:

 I was trying to come up with a macro which could add default ops to the
 omap_dss_driver. It isn't straight forward as I thought, because you
 need to choose either the default op, or the panel driver's op if it
 exists. For example, I can't create a macro which adds an op for
 get_timings() to all panel drivers, the panel drivers which already this
 op defined will have 2 instances of get_timings() in the omap_dss_driver
 struct.

Yep, I noticed the same a few days ago.

 I have been looking around in the kernel to see how undeclared ops in a
 struct are generally dealt with. Till now, I've noticed that the code
 which uses this ops takes the responsibility to check whether they are
 NULL or not.
 
 The easiest way would be to have these default funcs inlined in a
 header, and every panel driver's omap_dss_driver struct fills in the
 default op. This way we can make the driver ops const. Do you have any
 idea of a macro which could do the same as above, and leads to less
 addition of code?

Why would they need to be inlined?

Another option would be to create global funcs that are used to call the
ops. So instead of:

dssdev-dssdrv-foo(dssdev)

the user would call this function:

int dss_foo(struct omap_dss_device *dssdev)
{
if (dssdev-dssdrv-foo == NULL)
return 0; /* or error, depending on case */
return dssdev-dssdrv-foo(dssdev);
}

But that'd require adding a bunch of functions, and changing all the
callers.

I think the safest way to fix this for now is to add the checks into
omapdrm as you do in your original patch. If we go for some other route,
I fear that omapfb/omap_vout could be affected, as it could presume that
an op being NULL or non-NULL means something. If we change the ops to be
always non-NULL, we should go over the uses of those ops to verify they
work correctly.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[bisected][3.9.0-rc3] NULL ptr dereference from nv50_disp_intr()

2013-03-20 Thread Peter Hurley

On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
the user X session is coming up:


BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [0001] 0x0
PGD 0 
Oops: 0010 [#1] PREEMPT SMP 
Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ...snip...
CPU 3 
Pid: 0, comm: swapper/3 Not tainted 3.9.0-rc3-xeon #rc3 Dell Inc. Precision 
WorkStation T5400  /0RW203
RIP: 0010:[0001]  [0001] 0x0
RSP: 0018:8802afcc3d80  EFLAGS: 00010087
RAX: 88029f6e5808 RBX: 0001 RCX: 
RDX: 0096 RSI: 0001 RDI: 88029f6e5808
RBP: 8802afcc3dc8 R08:  R09: 0004
R10: 002c R11: 88029e559a98 R12: 8802a376cb78
R13: 88029f6e57e0 R14: 88029f6e57f8 R15: 88029f6e5808
FS:  () GS:8802afcc() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0001 CR3: 00029fa67000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper/3 (pid: 0, threadinfo 8802a355e000, task 8802a3535c40)
Stack:
 a0159d8a 0082 88029f6e5820 0001
 88029f71aa00   0400
 0400 8802afcc3e38 a01843b5 8802afcc3df8
Call Trace:
 IRQ 
 [a0159d8a] ? nouveau_event_trigger+0xaa/0xe0 [nouveau]
 [a01843b5] nv50_disp_intr+0xc5/0x200 [nouveau]
 [816fbacc] ? _raw_spin_unlock_irqrestore+0x2c/0x50
 [816ff98d] ? notifier_call_chain+0x4d/0x70
 [a017a105] nouveau_mc_intr+0xb5/0x110 [nouveau]
 [a01d45ff] nouveau_irq_handler+0x6f/0x80 [nouveau]
 [810eec95] handle_irq_event_percpu+0x75/0x260
 [810eeec8] handle_irq_event+0x48/0x70
 [810f205a] handle_fasteoi_irq+0x5a/0x100
 [810182f2] handle_irq+0x22/0x40
 [8170561a] do_IRQ+0x5a/0xd0
 [816fc2ad] common_interrupt+0x6d/0x6d
 EOI 
 [810449b6] ? native_safe_halt+0x6/0x10
 [8101ea1d] default_idle+0x3d/0x170
 [8101f736] cpu_idle+0x116/0x130
 [816e2a06] start_secondary+0x251/0x258
Code:  Bad RIP value.
RIP  [0001] 0x0
 RSP 8802afcc3d80
CR2: 0001
---[ end trace 907323cb8ce6f301 ]---



git bisect from 3.8.0 (good) to 3.9.0-rc3 (bad) blames (bisect log
attached):

1d7c71a3e2f77336df536855b0efd2dc5bdeb41b is the first bad commit
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
Author: Ben Skeggs bske...@redhat.com
Date:   Thu Jan 31 09:23:34 2013 +1000

drm/nouveau/disp: port vblank handling to event interface

This removes the nastiness with the interactions between display and
software engines when handling vblank semaphore release interrupts.

Now, all the semantics are handled in one place (sw) \o/.

Signed-off-by: Ben Skeggs bske...@redhat.com

:04 04 fbd44f8566271415fd2775ab4b6346efef7e82fe 
a0730be0f35feaa1476b1447b1d65c4b3b3c0686 M  drivers


On this hardware:
nouveau  [  DEVICE][:02:00.0] BOOT0  : 0x084e00a2
nouveau  [  DEVICE][:02:00.0] Chipset: G84 (NV84)
nouveau  [  DEVICE][:02:00.0] Family : NV50
nouveau  [   VBIOS][:02:00.0] checking PRAMIN for image...
nouveau  [   VBIOS][:02:00.0] ... appears to be valid
nouveau  [   VBIOS][:02:00.0] using image from PRAMIN
nouveau  [   VBIOS][:02:00.0] BIT signature found
nouveau  [   VBIOS][:02:00.0] version 60.84.63.00.11
nouveau  [ PFB][:02:00.0] RAM type: DDR2
nouveau  [ PFB][:02:00.0] RAM size: 256 MiB
nouveau  [ PFB][:02:00.0]ZCOMP: 1892 tags
nouveau  [ DRM] VRAM: 256 MiB
nouveau  [ DRM] GART: 512 MiB
nouveau  [ DRM] BIT BIOS found
nouveau  [ DRM] Bios version 60.84.63.00
nouveau  [ DRM] TMDS table version 2.0
nouveau  [ DRM] DCB version 4.0
nouveau  [ DRM] DCB outp 00: 02000300 0028
nouveau  [ DRM] DCB outp 01: 01000302 0030
nouveau  [ DRM] DCB outp 02: 04011310 0028
nouveau  [ DRM] DCB outp 03: 02011312 0030
nouveau  [ DRM] DCB conn 00: 1030
nouveau  [ DRM] DCB conn 01: 2130
nouveau  [ DRM] 2 available performance level(s)
nouveau  [ DRM] 0: core 208MHz shader 416MHz memory 100MHz voltage 1200mV 
fanspeed 100%
nouveau  [ DRM] 1: core 460MHz shader 920MHz memory 400MHz voltage 1200mV 
fanspeed 100%
nouveau  [ DRM] c: core 459MHz shader 918MHz memory 399MHz voltage 1200mV
nouveau  [ DRM] MM: using CRYPT for buffer copies
nouveau  [ DRM] allocated 1680x1050 fb: 0x6, bo 88029ef50400
fbcon: nouveaufb (fb0) is primary device
nouveau :02:00.0: fb0: nouveaufb frame buffer device
nouveau :02:00.0: registered panic notifier
[drm] Initialized nouveau 1.1.0 20120801 for :02:00.0 on minor 0


02:00.0 VGA compatible controller: NVIDIA

Re: drm/i915: new warning (regression) in 3.7.10 and 3.8.3

2013-03-20 Thread Richard Cochran

On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
 
 Another pesky BIOS which changes the display state behind our back on lid
 closing! Should be duct-tapped over with
 
 commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Nov 23 18:16:34 2012 +0100
 
 drm/i915: force restore on lid open
 
 which is in 3.8.

But that warning was from a 3.8.3 kernel. Any other ideas?

Thanks,
Richard

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

Re: [Nouveau] nouveau lockdep splat

2013-03-20 Thread Peter Hurley

[ adding Ben Skeggs and Dave Airlie ]

On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
 On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
  Dropping Tegra ML, it's not the place where Nouveau mails should go.
  Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
 
 Ok,
 
 with the hope of having the right people on CC now (finally, thanks
 Lucas :-)), here's the same splat on -rc3. Someone better take a look
 soonish, please:

Also happens in next (on nv50 hardware).

 [0.541078] [drm] No driver support for vblank timestamp query.
 [0.541272] nouveau  [ DRM] 3 available performance level(s)
 [0.541276] nouveau  [ DRM] 0: core 135MHz shader 270MHz memory 135MHz 
 voltage 900mV
 [0.541280] nouveau  [ DRM] 1: core 405MHz shader 810MHz memory 405MHz 
 voltage 900mV
 [0.541284] nouveau  [ DRM] 3: core 520MHz shader 1230MHz memory 
 790MHz voltage 900mV
 [0.541287] nouveau  [ DRM] c: core 405MHz shader 810MHz memory 405MHz 
 voltage 900mV
 [0.559846] nouveau  [ DRM] MM: using COPY for buffer copies
 [0.625371] nouveau  [ DRM] allocated 1920x1080 fb: 0x7, bo 
 88043b54f000
 [0.625441] fbcon: nouveaufb (fb0) is primary device
 [0.62] 
 [0.625556] =
 [0.625556] [ INFO: possible recursive locking detected ]
 [0.625557] 3.9.0-rc3+ #25 Not tainted
 [0.625557] -
 [0.625558] swapper/0/1 is trying to acquire lock:
 [0.625562]  (dmac-lock){+.+...}, at: [8141bb63] 
 evo_wait+0x43/0xf0
 [0.625562] 
 [0.625562] but task is already holding lock:
 [0.625564]  (dmac-lock){+.+...}, at: [8141bb63] 
 evo_wait+0x43/0xf0
 [0.625565] 
 [0.625565] other info that might help us debug this:
 [0.625565]  Possible unsafe locking scenario:
 [0.625565] 
 [0.625565]CPU0
 [0.625565]
 [0.625566]   lock(dmac-lock);
 [0.625567]   lock(dmac-lock);
 [0.625567] 
 [0.625567]  *** DEADLOCK ***
 [0.625567] 
 [0.625567]  May be due to missing lock nesting notation
 [0.625567] 
 [0.625568] 10 locks held by swapper/0/1:
 [0.625570]  #0:  (__lockdep_no_validate__){..}, at: 
 [814337cb] __driver_attach+0x5b/0xb0
 [0.625572]  #1:  (__lockdep_no_validate__){..}, at: 
 [814337d9] __driver_attach+0x69/0xb0
 [0.625575]  #2:  (drm_global_mutex){+.+.+.}, at: [8135a8e6] 
 drm_get_pci_dev+0xc6/0x2d0
 [0.625578]  #3:  (registration_lock){+.+.+.}, at: [812c8fc5] 
 register_framebuffer+0x25/0x310
 [0.625581]  #4:  (fb_info-lock){+.+.+.}, at: [812c7ed6] 
 lock_fb_info+0x26/0x60
 [0.625583]  #5:  (console_lock){+.+.+.}, at: [812c915a] 
 register_framebuffer+0x1ba/0x310
 [0.625585]  #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: 
 [810695c2] __blocking_notifier_call_chain+0x42/0x80
 [0.625587]  #7:  (dev-mode_config.mutex){+.+.+.}, at: 
 [8135e61a] drm_modeset_lock_all+0x2a/0x70
 [0.625589]  #8:  (crtc-mutex){+.+.+.}, at: [8135e644] 
 drm_modeset_lock_all+0x54/0x70
 [0.625591]  #9:  (dmac-lock){+.+...}, at: [8141bb63] 
 evo_wait+0x43/0xf0
 [0.625591] 
 [0.625591] stack backtrace:
 [0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
 [0.625593] Call Trace:
 [0.625595]  [810953fb] __lock_acquire+0x76b/0x1c20
 [0.625597]  [8137f4ec] ? dcb_table+0x1ac/0x2a0
 [0.625599]  [81096e1a] lock_acquire+0x8a/0x120
 [0.625600]  [8141bb63] ? evo_wait+0x43/0xf0
 [0.625602]  [81615432] ? mutex_lock_nested+0x292/0x330
 [0.625603]  [8161520e] mutex_lock_nested+0x6e/0x330
 [0.625605]  [8141bb63] ? evo_wait+0x43/0xf0
 [0.625606]  [810976eb] ? mark_held_locks+0x9b/0x100
 [0.625607]  [8141bb63] evo_wait+0x43/0xf0
 [0.625609]  [8141e603] nv50_display_flip_next+0x713/0x7a0
 [0.625611]  [8161562e] ? mutex_unlock+0xe/0x10
 [0.625612]  [8141bc47] ? evo_kick+0x37/0x40
 [0.625613]  [8141e88e] nv50_crtc_commit+0x10e/0x230
 [0.625615]  [8134c295] drm_crtc_helper_set_mode+0x365/0x510
 [0.625617]  [8134d68e] drm_crtc_helper_set_config+0xa4e/0xb70
 [0.625618]  [8135f731] drm_mode_set_config_internal+0x31/0x70
 [0.625619]  [8134b791] drm_fb_helper_set_par+0x71/0xf0
 [0.625621]  [812d4234] fbcon_init+0x514/0x5a0
 [0.625623]  [8132cbfc] visual_init+0xbc/0x120
 [0.625624]  [8132f2b3] do_bind_con_driver+0x163/0x320
 [0.625625]  [8132f541] do_take_over_console+0x61/0x70
 [0.625627]  [812d2853] do_fbcon_takeover+0x63/0xc0
 [0.625628]  [812d652d] fbcon_event_notify+0x5fd/0x700
 [0.625629]  [8161c91d] notifier_call_chain+0x4d/0x70
 [0.625630]

Re: [PATCH v2 0/7] xfree86: Handle drm race condition

2013-03-20 Thread Maarten Lankhorst

Hey,

Op 19-03-13 22:13, Chris Wilson schreef:
 On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
 The drmSetMaster call is needed, but the spinning is really just waiting for 
 the workqueue to run.

 bryce's patch never worked, it just caused it to try drmsetinterfaceversion 
 for a few seconds before timing out. That call
 was failing because his patch series never tried to obtain drm master.
 You missed that the series Bryce posted did contain the drmSetMaster()
 call inside the loop to retry drmSetVersion(). :)


Oh I must have missed that.

Is the drmSetInterfaceVersion call really needed here? If I look at 
DRM_IOCTL_GET_UNIQUE,
I don't see any requirement of drm master or anything, so it looks to me like 
for this specific race
the drmSetInterfaceVersion call can be skipped entirely without any side 
effects.
This would end up with cleaner code here, and drop the master requirement 
entirely.

Of course there's still a race that needs to be investigated, and is currently 
not completely understood, I think.

~Maarten

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

82 matches

Mail list logo