mesa gles3 GIT: ubuntu (unity-3d) gnome-session usable with compiz

[Sedat Dilek]

Hi,

I am testing mesa gles3 GIT (up to 8d27a9f) here on my Ubuntu/precise system.

[ LINUX-KERNEL ]

$ cat /proc/version
Linux version 3.8.0-rc4-next20130121-2-iniza-generic
(sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro
4.6.3-1ubuntu5) ) #1 SMP Mon Jan 21 13:37:01 CET 2013

[ XSERVER ]

$ dpkg -l | grep -i xserver-xorg-core
ii  xserver-xorg-core
2:1.11.4-0ubuntu10.11   Xorg X server -
core server

[ DDX ]

[   158.494] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[   158.494] (II) Module intel: vendor="X.Org Foundation"
[   158.494]compiled for 1.11.3, module version = 2.20.19

[ MESA-DRI ]

$ LIBGL_DEBUG=verbose glxinfo | grep -i opengl
libGL: OpenDriver: trying /opt/xorg/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /opt/xorg/lib/dri/i965_dri.so
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/wearefam/.drirc: No such
file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/wearefam/.drirc: No such
file or directory.
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL version string: 3.0 Mesa 9.1-devel (git-8d27a9f)
OpenGL shading language version string: 1.30
OpenGL extensions:

[ /var/log/syslog ]

kernel: [   46.677606] traps: compiz[1949] trap invalid opcode
ip:7f05a7b3f4d0 sp:7fff99a05c88 error:0 in
libGL.so.1.2.0[7f05a7b3c000+7c000]
gnome-session[1883]: WARNING: Application 'compiz.desktop' killed by signal
gnome-session[1883]: WARNING: App 'compiz.desktop' respawning too quickly
kernel: [   49.010085] compiz[2011]: segfault at 7f5f9c0034c0 ip
7f5f9c0034c0 sp 7fffdec9b748 error 15
gnome-session[1883]: WARNING: App 'compiz.desktop' respawning too quickly
gnome-session[1883]: WARNING: Application 'compiz.desktop' killed by signal
gnome-session[1883]: WARNING: App 'compiz.desktop' respawning too quickly

Can you tell me what's going on or how to reveal why unity-3d fails
but ubuntu-2d gnome-session works fine?

I did also reset unity...

$ unity --reset

...which did not help!

NOTE: I am building here with LLVM/CLANG v3.2 if this matters!

My build-script is attached!

Regards,
- Sedat -
-- next part --
A non-text attachment was scrubbed...
Name: build_mesa.sh
Type: application/x-sh
Size: 3062 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/ab129424/attachment-0001.sh>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #5 from Andy Furniss  ---
(In reply to comment #3)
> As far as I can tell, all shaders end with an export instruction, with
> EndOfProgram bit set. I suspect an issue with number of color buffer export
> involved.
> 
> Can you apply this patch and report if the game still locks the gpu ?

The game runs OK with the patch.

-- 
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/20130121/2c9a450d/attachment.html>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

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

--- Comment #22 from Stefan D?singer  ---
Are you sure? I see nothing in the r300g git history that I'd expect to have
fixed this bug. Unless of course the hw does what ARB_depth_clamp requires when
you set CLIP_DISABLE and the rendering problems had nothing to do with
depth_clamp in the first place.

If the bug is indeed fixed a bisect for the commit fixing it might be
interesting.

-- 
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/20130121/1c178862/attachment.html>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #4 from vincent  ---
Created attachment 73411
  --> https://bugs.freedesktop.org/attachment.cgi?id=73411=edit
Disable llvm fs

-- 
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/20130121/92fd26ab/attachment.html>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #3 from vincent  ---
As far as I can tell, all shaders end with an export instruction, with
EndOfProgram bit set. I suspect an issue with number of color buffer export
involved.

Can you apply this patch and report if the game still locks the gpu ?

-- 
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/20130121/1ee57ea6/attachment.html>

[Bug 59614] [bisected] Black screen on boot with Radeon HD 6670

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

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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/20130121/6c933e6f/attachment-0001.html>

[Bug 59592] Radeon HD 5670: reproducable GPU lockups since kernel 3.8

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|XOrg CVS|git
  Component|DRM/Radeon  |Drivers/Gallium/r600

--- Comment #2 from Alex Deucher  ---
I think this is actually a mesa bug.  The kernel commit you bisected just
allows the problematic feature to be enabled in mesa.  The mesa commits are:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664

-- 
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/20130121/873b5ad7/attachment.html>

[Bug 59672] Problems initializing Radeon driver: lockup during IB test

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

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

--- Comment #2 from Alex Deucher  ---
Is this still an issue with Dave's latest drm pull request:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

-- 
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/20130121/7f5881c4/attachment.html>

[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7, 3.8-rcX

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

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

--- Comment #1 from Alex Deucher  ---
Is this still an issue with the latest bits from Dave's last pull request?
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

-- 
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/20130121/ce79ed74/attachment.html>

[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed

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

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





--- Comment #10 from Alex Deucher   2013-01-21 
21:06:07 ---
Are you still seeing this with a newer kernel?  3.0.34 is really old.

-- 
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 56534] All anti-aliasing methods buggy at cayman

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

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

--- Comment #6 from Alexandre Demers  ---
Should differents anti-aliasing methods be tracked in differents bugs?

-- 
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/20130121/85a2e334/attachment.html>

[PATCH] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets

[Daniel Vetter]

We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.

References: http://www.mail-archive.com/dri-devel at 
lists.freedesktop.org/msg33138.html
Cc: stable at vger.kernel.org
Cc: David Woodhouse 
Reported-and-tested-by: Mihai Moldovan 
Signed-off-by: Daniel Vetter 
---
 drivers/iommu/intel-iommu.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9743769..19854bf 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct pci_dev 
*dev)
 {
/*
 * Mobile 4 Series Chipset neglects to set RWBF capability,
-* but needs it:
+* but needs it. Same seems to hold for the desktop versions.
 */
printk(KERN_INFO "DMAR: Forcing write-buffer flush capability\n");
rwbf_quirk = 1;
 }

 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf);

 #define GGC 0x52
 #define GGC_MEMORY_SIZE_MASK   (0xf << 8)
-- 
1.7.10.4

[PATCH 09/10] drm/exynos: add G2D driver

[Rob Clark]

On Mon, Jan 21, 2013 at 7:33 PM, Inki Dae  wrote:
> 2013/1/21 Rob Clark :
>> I don't suppose you could send a libdrm patch to the list with an up
>> to date version of the g2dtest code so we can get it in libdrm tree?
>>
>
> We are planning on updating exynos drm for libdrm. At that time, the
> up to date version of the g2dtest will be posted.
> Joonyoung, let it post. And I will post other things except g2dtest.

thanks, I just want to make sure this doesn't get lost

BR,
-R

> Thanks,
> Inki Dae
>
>> BR,
>> -R
>>
>> On Fri, Mar 16, 2012 at 1:28 AM, Joonyoung Shim  
>> wrote:
>>> On 03/15/2012 07:50 PM, Dave Airlie wrote:
>
> G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
> G2D driver is exynos drm specific and supports only exynos4x12 series.
> user application fills command set in cmdlist and once dma start request
> these cmdlists are parsed and performed by dma.

 Where is this block documented or a pointer to the corresponding open
 userspace user code?
>>>
>>>
>>> I attach simple g2dtest program patch. The base of this patch is master
>>> branch of lastest libdrm git.
>>>
>>> This user progrem can test just solid color fill example.
>>> I will cleanup and update it for more operations later.
>>>
>>> Thanks.
>>>
>>>
 Again the ioctls look like they need to be depointered and use __u64.

 It would be nice if you could document how the command stream and engine
 work.

 How does userspace pass addresses to it? straight or via gem objects?
 how does it
 stop userspace blt to places it shouldn't etc.

 I'm getting the feeling this accel enabled driver needs a lot more of
 a commit message
 and lot more documentation on what it can be used for.

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

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

i915-related and general system freezes with specific kernel config // IOMMU

[Mihai Moldovan]

* On 20.01.2013 11:49 PM, Daniel Vetter wrote:
> Thanks for testing, I've just submitted the patch for review. It
> should included in a -fixes tree soon and the get backported to
> stable kernels.

Thanks. :)


> Please let me know when this works solidly for you, so that I can
> put it into a real patch and also submit it for inclusion.

No freeze for >24h, I guess we can conclude the quirk does indeed
fix the random freeze issue as well. :)
I'm all for inclusion.


I'm also currently testing a kernel without the Intel IOMMU feature. This seems
to work, too, but also disables Intel TXT and VT-d...
At least not seeing USB and PCI(e) issues. I'll leave the box running for some
more and will afterwards disable IOMMU as a whole to see if I hit USB and PCI(e)
issues again with that combination.

Best regards,



Mihai

[resending to include all previous CC's]

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4506 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/19f4967b/attachment-0001.bin>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

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

Piero Finizio  changed:

   What|Removed |Added

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

--- Comment #21 from Piero Finizio  ---
With last git-6eb0d3d and git-9bdf5be the bug disappeared, so I mark it as
Resolved.

-- 
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/20130121/08b10f3e/attachment.html>

[Bug 59672] Problems initializing Radeon driver: lockup during IB test

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

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

--- Comment #1 from Lucas Kannebley Tavares  ---
Created attachment 73398
  --> https://bugs.freedesktop.org/attachment.cgi?id=73398=edit
Backtrace upon reboot

I can't remove the module the modprobe (some resource got stuck) but there's a
backtrace printout if I attempt to reboot the machine.

-- 
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/20130121/d0043a2e/attachment.html>

[Bug 59672] Problems initializing Radeon driver: lockup during IB test

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

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

Lucas Kannebley Tavares  changed:

   What|Removed |Added

 CC||lucaskt at linux.vnet.ibm.com
Version|XOrg 6.7.0  |unspecified

-- 
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/20130121/9b98f10b/attachment.html>

[Bug 59672] New: Problems initializing Radeon driver: lockup during IB test

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

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

  Priority: medium
Bug ID: 59672
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Problems initializing Radeon driver: lockup during IB
test
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: lucaskt at linux.vnet.ibm.com
  Hardware: PowerPC
Status: NEW
   Version: XOrg 6.7.0
 Component: DRM/Radeon
   Product: DRI

Created attachment 73396
  --> https://bugs.freedesktop.org/attachment.cgi?id=73396=edit
modprobe radeon with drm.debug=1

Hi all,

I've been trying to get a evergreen adapter to work with the Radeon driver on a
ppc64 machine. And while attempting that, I'm running into what seems to be a
infinite loop while running the IB test on ring 3.
I'm using a 3.8.0-rc4 kernel from today.
Follows an excerpt from the logs, the entire modprobe log can be found
attached.

[  171.975487] [drm:evergreen_blit_init], evergreen blit allocated bo 0600
vs 0400 ps 0500
[  171.975631] radeon 0001:01:00.0: WB enabled
[  171.975636] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0xc001d32b0c00
[  171.975642] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0xc001d32b0c0c
[  171.992732] [drm] ring test on 0 succeeded in 0 usecs
[  171.992799] [drm] ring test on 3 succeeded in 1 usecs
[  171.993112] [drm:evergreen_irq_set], evergreen_irq_set: sw int gfx
[  171.993154] [drm] ib test on ring 0 succeeded in 0 usecs
[  171.993197] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  172.419617] [drm:evergreen_irq_set], r600_irq_set: sw int dma

[  182.399612] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  182.409618] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  182.419604] radeon 0001:01:00.0: GPU lockup CP stall for more than 1msec
[  182.419615] radeon 0001:01:00.0: GPU lockup (waiting for 0x0001
last fence id 0x)
[  182.419626] [drm:r600_dma_ib_test] *ERROR* radeon: fence wait failed (-35).
[  182.419634] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 3 (-35).

Do you guys have any idea what could be wrong, or what should be looked into? 

Thanks

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

[Bug 59592] Radeon HD 5670: reproducable GPU lockups since kernel 3.8

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

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

nine at detonation.org changed:

   What|Removed |Added

   Keywords||regression

-- 
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/20130121/6094ce4f/attachment.html>

[PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Arnd Bergmann]

While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.

Without this patch, building allyesconfig results in:

drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: 
No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No 
such file or directory

Signed-off-by: Arnd Bergmann 
Cc: Joonyoung Shim 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/exynos/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF

 config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
-   depends on DRM_EXYNOS && !FB_S3C
+   depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use Exynos FIMD for DRM.

@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D

 config DRM_EXYNOS_IPP
bool "Exynos DRM IPP"
-   depends on DRM_EXYNOS
+   depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use IPP feature for DRM.

-- 
1.7.10.4

[PATCH 00/15] ARM build regressions in v3.8

[Arnd Bergmann]

I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.

It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.

The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.

The same binutils update also broke the samsung
and w90x900 platforms.

A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.

Arnd

Arnd Bergmann (15):
  ARM: compressed/head.S: work around new binutils warning
  ARM: mvebu: build coherency_ll.S for arch=armv7-a
  ARM: samsung: fix assembly syntax for new gas
  ARM: w90x900: fix legacy assembly syntax
  ASoC: fsl: fiq and dma cannot both be modules
  clk: export __clk_get_name
  drm/exynos: don't include plat/gpio-cfg.h
  drm/exynos: fimd and ipp are broken on multiplatform
  media: coda: don't build on multiplatform
  mfd/vexpress: export vexpress_config_func_{put,get}
  mtd: davinci_nand: fix OF support
  USB: gadget/freescale: disable non-multiplatform drivers
  USB: ehci: make orion and mxc bus glues coexist
  samples/seccomp: be less stupid about cross compiling
  staging/omapdrm: don't build on multiplatform

 arch/arm/boot/compressed/Makefile|2 +-
 arch/arm/boot/compressed/head.S  |   12 
 arch/arm/mach-mvebu/coherency_ll.S   |1 +
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++--
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S |2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S|   12 ++--
 arch/arm/mach-s3c24xx/sleep-s3c2412.S|   12 ++--
 arch/arm/mach-w90x900/include/mach/entry-macro.S |4 ++--
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +-
 drivers/clk/clk.c|1 +
 drivers/gpu/drm/exynos/Kconfig   |4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |1 -
 drivers/media/platform/Kconfig   |2 +-
 drivers/mfd/vexpress-config.c|3 ++-
 drivers/mtd/nand/davinci_nand.c  |2 +-
 drivers/staging/omapdrm/Kconfig  |2 +-
 drivers/usb/gadget/Kconfig   |3 ++-
 drivers/usb/host/ehci-hcd.c  |   16 +++-
 samples/seccomp/Makefile |2 ++
 sound/soc/fsl/Kconfig|3 +++
 21 files changed, 76 insertions(+), 42 deletions(-)

-- 
1.7.10.4
Cc: Artem Bityutskiy 
Cc: Ben Dooks 
Cc: David Airlie 
Cc: Greg Kroah-Hartman 
Cc: James Morris 
Cc: Mark Brown 
Cc: Mauro Carvalho Chehab 
Cc: Mike Turquette 
Cc: Rob Clark 
Cc: Russell King 
Cc: Shawn Guo 
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-media at vger.kernel.org
Cc: linux-usb at vger.kernel.org

[PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Jerome Glisse]

On Mon, Jan 21, 2013 at 5:10 PM, Alex Deucher  wrote:
> On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher  
> wrote:
>> On Mon, Jan 21, 2013 at 3:50 PM,   wrote:
>>> From: Jerome Glisse 
>>>
>>> Aruba and newer gpu does not need the avivo cursor work around,
>>> quite the opposite this work around lead to corruption.
>>>
>>> Signed-off-by: Jerome Glisse 
>>> ---
>>>  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
>>> b/drivers/gpu/drm/radeon/radeon_cursor.c
>>> index ad6df62..30f71cc 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
>>> @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
>>> y = 0;
>>> }
>>>
>>> -   if (ASIC_IS_AVIVO(rdev)) {
>>> +   if (ASIC_IS_AVIVO(rdev) && (rdev->family < CHIP_ARUBA)) {
>>
>> I believe these issues were fixed on DCE6, but I'm verifying now.  SI
>> is dce6 as well so the check here should probably be:
>>
>> if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE6(rdev)) {
>
> Actually, the two patches are identical since:
> #define ASIC_IS_DCE6(rdev) ((rdev->family >= CHIP_ARUBA))
> but I think the DCE6 variant is clearer.  Once I verify with the hw
> team I'll add the patch with that change.
>
> Thanks!
>
> Alex
>

Yes they are identical, i meant that i considered doing it that way
but i did not have strong feeling. :)

Cheers,
Jerome

[PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Alex Deucher]

On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher  wrote:
> On Mon, Jan 21, 2013 at 3:50 PM,   wrote:
>> From: Jerome Glisse 
>>
>> Aruba and newer gpu does not need the avivo cursor work around,
>> quite the opposite this work around lead to corruption.
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>>  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
>> b/drivers/gpu/drm/radeon/radeon_cursor.c
>> index ad6df62..30f71cc 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
>> @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
>> y = 0;
>> }
>>
>> -   if (ASIC_IS_AVIVO(rdev)) {
>> +   if (ASIC_IS_AVIVO(rdev) && (rdev->family < CHIP_ARUBA)) {
>
> I believe these issues were fixed on DCE6, but I'm verifying now.  SI
> is dce6 as well so the check here should probably be:
>
> if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE6(rdev)) {

Actually, the two patches are identical since:
#define ASIC_IS_DCE6(rdev) ((rdev->family >= CHIP_ARUBA))
but I think the DCE6 variant is clearer.  Once I verify with the hw
team I'll add the patch with that change.

Thanks!

Alex

>
> Alex
>
>> int i = 0;
>> struct drm_crtc *crtc_p;
>>
>> --
>> 1.7.11.7
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Jerome Glisse]

On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher  wrote:
> On Mon, Jan 21, 2013 at 3:50 PM,   wrote:
>> From: Jerome Glisse 
>>
>> Aruba and newer gpu does not need the avivo cursor work around,
>> quite the opposite this work around lead to corruption.
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>>  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
>> b/drivers/gpu/drm/radeon/radeon_cursor.c
>> index ad6df62..30f71cc 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
>> @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
>> y = 0;
>> }
>>
>> -   if (ASIC_IS_AVIVO(rdev)) {
>> +   if (ASIC_IS_AVIVO(rdev) && (rdev->family < CHIP_ARUBA)) {
>
> I believe these issues were fixed on DCE6, but I'm verifying now.  SI
> is dce6 as well so the check here should probably be:
>
> if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE6(rdev)) {
>

Yeah i considered that too.

Cheers,
Jerome

thoughts on requiring multi-arch support for arm drm drivers?

[Laurent Pinchart]

Hi Rob,

On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
> One thing I've run into in the past when trying to make changes in drm
> core, and Daniel Vetter has mentioned the same, is that it is a bit of
> a pain to compile test things for the arm drivers that do not support
> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> the low hanging fruit (basically the drivers that just needed a
> Kconfig change).  But, IIRC some of the backlight related code in
> shmob had some non-trivial plat dependencies.

I've just compiled the shmob-drm driver without any error on x86_64. The CMA 
GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though 
(but that would only be an issue if we require no arch dependency at all, not 
with multiarch).

> And I think when tegra came in, it introduced some non-trivial plat
> dependencies.
> 
> What do others think about requiring multiarch or no arch dependencies
> for new drivers, and cleaning up existing drivers.  Even if it is at
> reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
> of the backlight code in shmob) or doesn't even work but is just for
> the purpose of being able to compile test the rest of the code?
> 
> Thoughts?

That sounds good to me, but would result in many drivers being exposed on x86 
even though they're useless on that platform. Would it make sense to add a new 
CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests 
only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || 
COMPILE_TEST.

I'm pretty sure I've seen a similar proposal quite recently but I can't 
remember where.

-- 
Regards,

Laurent Pinchart

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #2 from Andy Furniss  ---
Created attachment 73391
  --> https://bugs.freedesktop.org/attachment.cgi?id=73391=edit
compressed etqw shader dump while getting gpu lock.

-- 
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/20130121/f258fc97/attachment.html>

[PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Alex Deucher]

On Mon, Jan 21, 2013 at 3:50 PM,   wrote:
> From: Jerome Glisse 
>
> Aruba and newer gpu does not need the avivo cursor work around,
> quite the opposite this work around lead to corruption.
>
> Signed-off-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index ad6df62..30f71cc 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> y = 0;
> }
>
> -   if (ASIC_IS_AVIVO(rdev)) {
> +   if (ASIC_IS_AVIVO(rdev) && (rdev->family < CHIP_ARUBA)) {

I believe these issues were fixed on DCE6, but I'm verifying now.  SI
is dce6 as well so the check here should probably be:

if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE6(rdev)) {

Alex

> int i = 0;
> struct drm_crtc *crtc_p;
>
> --
> 1.7.11.7
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix cursor corruption on aruba and newer

[j.gli...@gmail.com]

From: Jerome Glisse 

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index ad6df62..30f71cc 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
y = 0;
}

-   if (ASIC_IS_AVIVO(rdev)) {
+   if (ASIC_IS_AVIVO(rdev) && (rdev->family < CHIP_ARUBA)) {
int i = 0;
struct drm_crtc *crtc_p;

-- 
1.7.11.7

[PATCH 1/1] drm/exynos: Make 'drm_hdmi_get_edid' static

[Sachin Kamat]

Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_hdmi.c:111:13: warning:
symbol 'drm_hdmi_get_edid' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
---
Compile tested on exynos-drm-fixes branch of Inki Dae's tree.
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 427d2de..2864453 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,7 +108,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
return false;
 }

-struct edid *drm_hdmi_get_edid(struct device *dev,
+static struct edid *drm_hdmi_get_edid(struct device *dev,
struct drm_connector *connector)
 {
struct drm_hdmi_context *ctx = to_context(dev);
-- 
1.7.4.1

[ANNOUNCE] libdrm 2.4.41

[Thomas Klausner]

Something's wrong with this tarball -- configure.ac references man/Makefile,
but no man/ directory is included.

Lesson: always run 'make distcheck' before releasing :)
 Thomas

On Wed, Jan 16, 2013 at 01:19:17PM +0100, Maarten Lankhorst wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Alex Deucher (1):
>   radeon: add new SI pci id
> 
> Ben Skeggs (2):
>   nouveau: disallow pushbuf BOs in multiple memory types
>   nouveau: expose channel engine selection on kepler chipsets
> 
> Chris Wilson (1):
>   intel: Remove the fence count contributions when clearing relocs
> 
> David Herrmann (4):
>   man: convert manpages to XML instead of plain troff
>   man: add drm.7 overview page
>   man: add drm-kms overview page
>   man: add drm-memory overview page
> 
> David Shao (1):
>   intel: Fix missing ETIME on BSD operating systems
> 
> Jerome Glisse (1):
>   drm/radeon: track global bo name and always return the same
> 
> Jesse Barnes (1):
>   man: disable man page building until David saves us all
> 
> Maarten Lankhorst (1):
>   configure.ac: bump version to 2.4.41 for release
> 
> Marcin Slusarz (1):
>   libdrm_nouveau.pc: don't include I${includedir}/nouveau
> 
> Maxime Villard (2):
>   libkms: fix memory leak in error path
>   libkms: return -EINVAL on fstat error
> 
> git tag: libdrm-2.4.41
> 
> http://dri.freedesktop.org/libdrm/libdrm-2.4.41.tar.bz2
> MD5:  9b1ebc4fd27867a386df5ed59fa3a2b1  libdrm-2.4.41.tar.bz2
> SHA1: e3dfcd45e1f5bd08e35a636382a59aa9f8cb5685  libdrm-2.4.41.tar.bz2
> SHA256: 5e2519f8a7c250dcddbdfa03d5f4b1b1701744f592691834fddf209e57f4c906  
> libdrm-2.4.41.tar.bz2
> 
> http://dri.freedesktop.org/libdrm/libdrm-2.4.41.tar.gz
> MD5:  1ceff52fa7979598a4463f0b6cf164de  libdrm-2.4.41.tar.gz
> SHA1: c34ce859b174cab617ce1e72a819debfcf3f143a  libdrm-2.4.41.tar.gz
> SHA256: 33c422dbae3c2113606c1909358e08a2f7ec1857b660a94191b8449c3f6a4727  
> libdrm-2.4.41.tar.gz
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQIcBAEBAgAGBQJQ9pp+AAoJEP5VjHKmcBPDx0QQAJaGl4AH7lmKnP7f0QMW2qD8
> VghS78h/HOnkL3gC+FrUu58roR0qDRBnKq+Y6EsWC02RoYoQJcZG05faJ34kvISc
> RzhMkSiOpSvDv+hNhy1Ti+w8wA+YN5V2QSMKUg6bklKTADg6ktAGwacwNj+Pk4I8
> flkEkIUYStHIqJbvo1HRXo6GH0l9Q+YopwaPxwUBW4zFVrtdEnPuEH6wl5fHpPlx
> ONsKRV0Hb9gAc5fWjjru6scDP5id1Ww9Kr4T3jC4ETA9beHKjWEuHWAWzfIHM3Fh
> m8x7eohm3xm1kBWcLr0mKqxqfZZXxXNyTnU03NMqp05niviXGp5YCgYJUPD4OZ7d
> j4eyaIPcKBwRXsB+/JOzXW4WrzI9v5oy2nR5q9UsefYr/ynAFx6srEjIw0sd4az4
> P11qXuPu04wTQkaQD02DoXZyJ48tMTQ78ZbkWpa/KhtphPfn3/tnPBnwEJTcWmgH
> 6B3AkCF6PebNrRSHaQ+THE/mSvieojcwRHRFtSnkFcaVQ4J5g9taCTvE1q4hPWVG
> R08+uXXE42sgETfayg4Hxp3ehVVfDZwufUck7l9ZMkJhIpuROxp+b1k+IhiBzIYs
> idYYLWRQxj4I399CJrtFGytBnZ0PgnFkMlTsnOCrLf91s54BJ7rXxS4/TaVcacC/
> dpDNac6ynRATMY7uBBCs
> =APPb
> -END PGP SIGNATURE-
> 
> ___
> xorg-announce mailing list
> xorg-announce at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-announce
> 

CDF discussions at FOSDEM

[Laurent Pinchart]

Hi Daniel,

On Thursday 17 January 2013 13:29:27 Daniel Vetter wrote:
> On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote:
> > On Fri, 11 Jan 2013, Laurent Pinchart wrote:
> >> Would anyone be interested in meeting at the FOSDEM to discuss the Common
> >> Display Framework ? There will be a CDF meeting at the ELC at the end of
> >> February, the FOSDEM would be a good venue for European developers.
> > 
> > Yes, count me in,
> 
> Jesse, Ville and me should also be around. Do we have a slot fixed already?

I've sent a mail to the FOSDEM organizers to request a hacking room for a 
couple of hours Sunday. I'll let you know as soon as I get a reply.

-- 
Regards,

Laurent Pinchart

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #1 from vincent  ---
Can you run etqw with R600_DUMP_SHADERS=1 and post the output please ?

-- 
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/20130121/33556cb5/attachment.html>

[PATCH] iommu/intel: disable DMAR for g4x integrated gfx

[David Woodhouse]

On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.

Acked-By: David Woodhouse 

It *really* winds me up that we never bother to test this hardware
before we ship it.

But I'm even *more* disappointed that we can't even diagnose it and
publish coherent errata *after* the fact. I'd really like to see each
quirk which disables features referencing a specific published erratum.
We really ought to be able to manage at least *that* much.

Rajesh?

-- 
dwmw2

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/50d43a6d/attachment-0001.bin>

[PATCH v16 RESEND 7/7] drm_modes: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 drivers/gpu/drm/drm_modes.c |   33 +
 include/drm/drmP.h  |4 
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 184a22d..fd53454 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 /**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode 
*vm,
 EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+   struct drm_display_mode *dmode, int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, , index);
+   if (ret)
+   return ret;
+
+   drm_display_mode_from_videomode(, dmode);
+
+   pr_debug("%s: got %dx%d display mode from %s\n",
+   of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+   drm_mode_debug_printmodeline(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5fbb0fe..e26ca59 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
 struct drm_file;
 struct drm_device;

+struct device_node;
 struct videomode;

 #include 
@@ -1458,6 +1459,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,

 extern int drm_display_mode_from_videomode(const struct videomode *vm,
   struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  int index);

 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

[PATCH v16 RESEND 6/7] drm_modes: add videomode helpers

[Steffen Trumtrar]

Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 drivers/gpu/drm/drm_modes.c |   37 +
 include/drm/drmP.h  |5 +
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..184a22d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);

+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+   struct drm_display_mode *dmode)
+{
+   dmode->hdisplay = vm->hactive;
+   dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+   dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+   dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+   dmode->vdisplay = vm->vactive;
+   dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+   dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+   dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+   dmode->clock = vm->pixelclock / 1000;
+
+   dmode->flags = 0;
+   if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+   dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+   else if (vm->dmt_flags & VESA_DMT_HSYNC_LOW)
+   dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+   if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
+   dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+   else if (vm->dmt_flags & VESA_DMT_VSYNC_LOW)
+   dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+   if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+   dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+   if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..5fbb0fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
 struct drm_file;
 struct drm_device;

+struct videomode;
+
 #include 
 #include 
 #include 
@@ -1454,6 +1456,9 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
  struct drm_cmdline_mode *cmd);

+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+  struct drm_display_mode *dmode);
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

[PATCH v16 RESEND 5/7] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 drivers/video/fbmon.c |   42 ++
 include/linux/fb.h|4 
 2 files changed, 46 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PPC_OF
 #include 
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode 
*vm,
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+   pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u 
%u\n",
+m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+m->right_margin, m->upper_margin, m->lower_margin,
+m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+   int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, , index);
+   if (ret)
+   return ret;
+
+   fb_videomode_from_videomode(, fb);
+
+   pr_debug("%s: got %dx%d display mode from %s\n",
+   of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+   dump_fb_videomode(fb);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
 struct device;
 struct file;
 struct videomode;
+struct device_node;

 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+extern int of_get_fb_videomode(struct device_node *np,
+  struct fb_videomode *fb,
+  int index);
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);

-- 
1.7.10.4

[PATCH v16 RESEND 4/7] fbmon: add videomode helpers

[Steffen Trumtrar]

Add a function to convert from the generic videomode to a fb_videomode.

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 drivers/video/fbmon.c |   52 +
 include/linux/fb.h|4 
 2 files changed, 56 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_PPC_OF
 #include 
 #include 
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct 
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
 }
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+   struct fb_videomode *fbmode)
+{
+   unsigned int htotal, vtotal;
+
+   fbmode->xres = vm->hactive;
+   fbmode->left_margin = vm->hback_porch;
+   fbmode->right_margin = vm->hfront_porch;
+   fbmode->hsync_len = vm->hsync_len;
+
+   fbmode->yres = vm->vactive;
+   fbmode->upper_margin = vm->vback_porch;
+   fbmode->lower_margin = vm->vfront_porch;
+   fbmode->vsync_len = vm->vsync_len;
+
+   /* prevent division by zero in KHZ2PICOS macro */
+   fbmode->pixclock = vm->pixelclock ?
+   KHZ2PICOS(vm->pixelclock / 1000) : 0;
+
+   fbmode->sync = 0;
+   fbmode->vmode = 0;
+   if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+   fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+   if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+   fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+   if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+   fbmode->vmode |= FB_VMODE_INTERLACED;
+   if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+   fbmode->vmode |= FB_VMODE_DOUBLE;
+   fbmode->flag = 0;
+
+   htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
+vm->hsync_len;
+   vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
+vm->vsync_len;
+   /* prevent division by zero */
+   if (htotal && vtotal) {
+   fbmode->refresh = vm->pixelclock / (htotal * vtotal);
+   /* a mode must have htotal and vtotal != 0 or it is invalid */
+   } else {
+   fbmode->refresh = 0;
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
 struct fb_info;
 struct device;
 struct file;
+struct videomode;

 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+extern int fb_videomode_from_videomode(const struct videomode *vm,
+  struct fb_videomode *fbmode);
+
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4

[PATCH v16 RESEND 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.

If no native mode is specified, the first subnode will be used.

For cases where the graphics driver knows there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Philipp Zabel 
Acked-by: Stephen Warren 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 .../devicetree/bindings/video/display-timing.txt   |  109 +
 drivers/video/Kconfig  |   15 ++
 drivers/video/Makefile |2 +
 drivers/video/of_display_timing.c  |  239 
 drivers/video/of_videomode.c   |   54 +
 include/video/of_display_timing.h  |   20 ++
 include/video/of_videomode.h   |   18 ++
 7 files changed, 457 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/video/of_display_timing.h
 create mode 100644 include/video/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timing.txt 
b/Documentation/devicetree/bindings/video/display-timing.txt
new file mode 100644
index 000..1500385
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -0,0 +1,109 @@
+display-timing bindings
+===
+
+display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+   lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+   - active high = drive pixel data on rising edge/
+   sample data on falling edge
+   - active low  = drive pixel data on falling edge/
+   sample data on rising edge
+   - ignored = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+
+All the optional properties that are not bool follow the following logic:
+<1>: high active
+<0>: low active
+omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vback_porch |  |   |
+  |  |?|  |   |
+  +--###--+---+
+  |  #?#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |<>#<---+--->#<>|<->|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #?#  |   |
+  +--###--+---+
+  |  |?|  |   |
+  |  ||vfront_porch|  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+  |  |?  

[PATCH v16 RESEND 2/7] video: add display_timing and videomode

[Steffen Trumtrar]

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Also, add helper functions to convert from display timings to a generic 
videomode
structure.

The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off

As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.

Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.

The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.

This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
---
 drivers/video/Kconfig  |6 ++
 drivers/video/Makefile |2 +
 drivers/video/display_timing.c |   24 
 drivers/video/videomode.c  |   39 +
 include/video/display_timing.h |  124 
 include/video/videomode.h  |   48 
 6 files changed, 243 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/video/display_timing.h
 create mode 100644 include/video/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
  This framework adds support for low-level control of the video 
  output switch.

+config DISPLAY_TIMING
+   bool
+
+config VIDEOMODE
+   bool
+
 menuconfig FB
tristate "Support for frame buffer devices"
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)  += vfb.o

 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..5e1822c
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+
+void display_timings_release(struct display_timings *disp)
+{
+   if (disp->timings) {
+   unsigned int i;
+
+   for (i = 0; i < disp->num_timings; i++)
+   kfree(disp->timings[i]);
+   kfree(disp->timings);
+   }
+   kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..21c47a2
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,39 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+   struct display_timing *dt;
+
+   dt = display_timings_get(disp, index);
+   if (!dt)
+   return -EINVAL;
+
+   vm->pixelclock = display_timing_get_value(>pixelclock, TE_TYP);
+   vm->hactive = display_timing_get_value(>hactive, TE_TYP);
+   vm->hfront_porch = display_timing_get_value(>hfront_porch, TE_TYP);
+   vm->hback_porch = display_timing_get_value(>hback_porch, TE_TYP);
+   vm->hsync_len = display_timing_get_value(>hsync_len, TE_TYP);
+
+   vm->vactive = display_timing_get_value(>vactive, TE_TYP);
+   vm->vfront_porch = display_timing_get_value(>vfront_porch, TE_TYP);
+   

[PATCH v16 RESEND 1/7] viafb: rename display_timing to via_display_timing

[Steffen Trumtrar]

The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/via/hw.c  |6 +++---
 drivers/video/via/hw.h  |2 +-
 drivers/video/via/lcd.c |2 +-
 drivers/video/via/share.h   |2 +-
 drivers/video/via/via_modesetting.c |8 
 drivers/video/via/via_modesetting.h |6 +++---
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
 }

-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
 {
-   struct display_timing timing;
+   struct via_display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;

timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct 
fb_var_screeninfo *var,
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
 {
-   struct display_timing crt_reg = var_to_timing(var,
+   struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var->xres, cyres ? cyres : var->yres);

if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
 extern int viafb_DVI_ON;
 extern int viafb_hotplug;

-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo 
*var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
-   struct display_timing timing;
+   struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;

diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
-   struct display_timing crtc;
+   struct via_display_timing crtc;
 };

 struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c 
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
 #include "debug.h"


-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
 {
-   struct display_timing raw;
+   struct via_display_timing raw;

raw.hor_total = timing->hor_total / 8 - 5;
raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing 
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
 }

-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
 {
-   struct display_timing raw;
+   struct via_display_timing raw;

raw.hor_total = timing->hor_total - 1;
raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h 
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
 #define VIA_PITCH_MAX  0x3FF8


-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
 };


-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
 void 

[PATCH v16 RESEND 0/7] of: add display helper

[Steffen Trumtrar]

Hi!

There was still no maintainer, that commented, ack'd, nack'd, apply'd the
series. So, this is just a resend.
The patches were tested with:

- v15 on Tegra by Thierry
- sh-mobile-lcdcfb by Laurent
- MX53QSB by Marek
- Exynos: smdk5250 by Leela
- AM335X EVM & AM335X EVM-SK by Afzal
- imx6q: sabrelite, sabresd by Philipp and me
- imx53: tqma53/mba53 by me


Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np->full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code

Changes since v14:
- fix "const struct *" warning
(reported by: Leela Krishna Amudala )
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7

Changes since v13:
- fix "const struct *" warning
(reported by: Laurent Pinchart )
- prevent division by zero in fb_videomode_from_videomode

Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix "const struct *" warnings
(reported by: Manjunathappa, Prakash )
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical

Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart

Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by

Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around

Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct 
foo))
- include headers were necessary
- misc minor bugfixes

Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes

Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions

Changes since v5:
- removed all display stuff and just describe timings

Changes since v4:
- refactored functions

Changes since v3:
- print error messages
- free alloced memory
- general cleanup

Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties ()
- functions to get display_mode or fb_videomode


Regards,
Steffen


Steffen Trumtrar (7):
  viafb: rename display_timing to via_display_timing
  video: add display_timing and videomode
  video: add of helper for display timings/videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timing.txt   |  109 +
 drivers/gpu/drm/drm_modes.c|   70 ++
 drivers/video/Kconfig  |   21 ++
 drivers/video/Makefile |4 +
 drivers/video/display_timing.c |   24 ++
 drivers/video/fbmon.c  |   94 
 drivers/video/of_display_timing.c  |  239 
 drivers/video/of_videomode.c   |   54 +
 drivers/video/via/hw.c |6 +-
 drivers/video/via/hw.h |2 +-
 drivers/video/via/lcd.c|2 +-
 drivers/video/via/share.h  |2 +-
 drivers/video/via/via_modesetting.c|8 +-
 drivers/video/via/via_modesetting.h|6 +-
 drivers/video/videomode.c  |   39 
 include/drm/drmP.h |9 +
 include/linux/fb.h |8 +
 include/video/display_timing.h |  124 ++
 include/video/of_display_timing.h  |   20 ++
 include/video/of_videomode.h 

New i915 warning from intel_dp_aux_ch

[Meelis Roos]

While testing out 3.8.0-rc4-00071-g9a92841 on a PC where I have 
ironlake_crtc_disable warning 
(https://bugzilla.kernel.org/show_bug.cgi?id=52061), I saw a new warning 
today that was not there with 3.8.0-rc3-00074. The previous warning is 
also still there.

EDID is occasionally wrong on this PC, probably some timing issue in 
trying to read it out.

It is not 100% reproducible - happened 3 out of 6 reboots. It happens 
together with the EDID warning - probably related. But since it is not 
always there, I do now knwo exactly since when it might be present.

I managed to capture drm.debug=0xe output, full dmesg with debug is 
below is the main one.

[0.270838] i915 :00:02.0: setting latency timer to 64
[0.283426] i915 :00:02.0: irq 40 for MSI/MSI-X
[0.283431] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.283470] [drm] Driver supports precise vblank timestamp query.
[0.283532] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[0.366758] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 
0x0015003f
[0.375148] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
remainder is 142
[0.375210] Raw EDID:
[0.375239]  00 ff ff ff ff ff ff 00 22 f0 49 29 00 00 00 00
[0.375275]  15 15 01 04 a5 33 1d 78 26 01 f5 a2 57 52 9f 27
[0.375312]  0a 50 54 a1 08 00 81 c0 81 80 95 00 b3 00 d1 c0
[0.375348]  01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
[0.375385]  45 00 fe 1f 11 00 00 1e 00 00 00 fd 00 32 4c 18
[0.375421]  5e 11 00 0a 0a 0a 0a 0a 20 20 20 20 20 00 00 00
[0.375458]  fc 00 48 50 20 4c 41 32 33 30 36 0a 20 20 20 00
[0.375495]  00 00 ff 00 43 4e 43 31 32 31 31 32 50 42 0a 20
[0.389465] [ cut here ]
[0.389502] WARNING: at drivers/gpu/drm/i915/intel_dp.c:410 
intel_dp_aux_ch+0x131/0x4e0()
[0.389563] Hardware name: HP Compaq 8100 Elite SFF PC
[0.389598] dp_aux_ch not started status 0x8025003f
[0.389632] Modules linked in:
[0.389671] Pid: 6, comm: kworker/u:0 Not tainted 3.8.0-rc4-00071-g9a92841 
#80
[0.389729] Call Trace:
[0.389762]  [] ? warn_slowpath_common+0x79/0xc0
[0.389801]  [] ? warn_slowpath_fmt+0x45/0x50
[0.389838]  [] ? intel_dp_aux_ch+0x131/0x4e0
[0.389877]  [] ? intel_dp_aux_native_write+0xa2/0xe0
[0.389916]  [] ? intel_dp_aux_ch+0x3f1/0x4e0
[0.389953]  [] ? intel_dp_set_link_train+0xbc/0x300
[0.389993]  [] ? intel_dp_aux_native_write+0xa2/0xe0
[0.390032]  [] ? intel_dp_start_link_train+0xf2/0x2f0
[0.390072]  [] ? intel_dp_check_link_status+0x91/0x180
[0.390113]  [] ? i915_hotplug_work_func+0x6e/0xa0
[0.390153]  [] ? process_one_work+0x120/0x430
[0.390686]  [] ? i915_error_work_func+0x100/0x100
[0.390725]  [] ? worker_thread+0x15d/0x450
[0.390762]  [] ? schedule_delayed_work+0x20/0x20
[0.390801]  [] ? kthread+0xb3/0xc0
[0.390837]  [] ? kthread_create_on_node+0x110/0x110
[0.390878]  [] ? ret_from_fork+0x7c/0xb0
[0.390917]  [] ? kthread_create_on_node+0x110/0x110
[0.390958] ---[ end trace 0f2d76d213a31275 ]---

[0.00] Linux version 3.8.0-rc4-00071-g9a92841 (mroos at prometheus) 
(gcc version 4.7.2 (Debian 4.7.2-5) ) #80 SMP Mon Jan 21 09:52:32 EET 2013
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc4-00071-g9a92841 
root=/dev/sda1 ro drm.debug=0xe
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xdb7ac43f] usable
[0.00] BIOS-e820: [mem 0xdb7ac440-0xdb7ae49f] ACPI NVS
[0.00] BIOS-e820: [mem 0xdb7ae4a0-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfed3] reserved
[0.00] BIOS-e820: [mem 0xfed45000-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000117ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 
786H1 v01.13 07/14/2011
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x118000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E3FFF write-protect
[0.00]   E4000-E write-back
[

[PATCH 09/33] drm: Convert to devm_ioremap_resource()

[Thierry Reding]

Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.

Signed-off-by: Thierry Reding 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c| 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 7 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 8 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c| 8 +++-
 drivers/gpu/drm/tegra/dc.c  | 8 +++-
 drivers/gpu/drm/tegra/hdmi.c| 6 +++---
 drivers/gpu/drm/tegra/host1x.c  | 6 +++---
 9 files changed, 27 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 67a83e6..411f69b7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1785,11 +1785,9 @@ static int fimc_probe(struct platform_device *pdev)

/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
-   if (!ctx->regs) {
-   dev_err(dev, "failed to map registers.\n");
-   return -ENXIO;
-   }
+   ctx->regs = devm_ioremap_resource(dev, ctx->regs_res);
+   if (IS_ERR(ctx->regs))
+   return PTR_ERR(ctx->regs);

/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..36493ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -913,11 +913,9 @@ static int fimd_probe(struct platform_device *pdev)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-   ctx->regs = devm_request_and_ioremap(>dev, res);
-   if (!ctx->regs) {
-   dev_err(dev, "failed to map registers\n");
-   return -ENXIO;
-   }
+   ctx->regs = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(ctx->regs))
+   return PTR_ERR(ctx->regs);

res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 36c3905..7329abd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1136,10 +1136,9 @@ static int g2d_probe(struct platform_device *pdev)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-   g2d->regs = devm_request_and_ioremap(>dev, res);
-   if (!g2d->regs) {
-   dev_err(dev, "failed to remap I/O memory\n");
-   ret = -ENXIO;
+   g2d->regs = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(g2d->regs)) {
+   ret = PTR_ERR(g2d->regs);
goto err_put_clk;
}

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 8140753..7841c3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1692,11 +1692,9 @@ static int gsc_probe(struct platform_device *pdev)

/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
-   if (!ctx->regs) {
-   dev_err(dev, "failed to map registers.\n");
-   return -ENXIO;
-   }
+   ctx->regs = devm_ioremap_resource(dev, ctx->regs_res);
+   if (IS_ERR(ctx->regs))
+   return PTR_ERR(ctx->regs);

/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index e9e83ef..a6da774 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -656,11 +656,9 @@ static int rotator_probe(struct platform_device *pdev)
platform_get_device_id(pdev)->driver_data;

rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   rot->regs = devm_request_and_ioremap(dev, rot->regs_res);
-   if (!rot->regs) {
-   dev_err(dev, "failed to map register\n");
-   return -ENXIO;
-   }
+   rot->regs = devm_ioremap_resource(dev, rot->regs_res);
+   if (IS_ERR(rot->regs))
+   return PTR_ERR(rot->regs);

rot->irq = platform_get_irq(pdev, 0);
if (rot->irq < 0) {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 

[Bug 58839] errors about too many fences printed while playing neverball

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

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

Michel D?nzer  changed:

   What|Removed |Added

 CC||maraeo at gmail.com

--- Comment #6 from Michel D?nzer  ---
Marek, any ideas? I'm also seeing this with radeonsi.

-- 
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/20130121/6cd83cfc/attachment.html>

[PATCH] drm/fb: avoid sleeping in unblank_screen() if oops in progress

[Daniel Vetter]

On Fri, Dec 14, 2012 at 12:01 PM, Konstantin Khlebnikov
 wrote:
> unblank_screen() can be called from interrupt context during oops.
> thus all ->fb_blank handlers should avoid sleeping in this situation.
>
> callstack:
> panic()
> bust_spinlocks(1)
> unblank_screen()
> vc->vc_sw->con_blank()
> fbcon_blank()
> fb_blank()
> info->fbops->fb_blank()
> drm_fb_helper_blank()
> drm_fb_helper_dpms()
> mutex_lock(>mode_config.mutex)
>
> Signed-off-by: Konstantin Khlebnikov 
> Cc: Andrew Morton 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org

Since the fb helper already has its own panic notifier it's imo better
to just bail out if there's an oops in progress. The panic notifier
itself completely lacks locking though. I'm working on some fb helper
cleanups, so I'll take care of this mess.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c |   25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 954d175..2c9f49f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -326,7 +326,7 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op 
> = {
>  static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
>  #endif
>
> -static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
> +static int drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
>  {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_device *dev = fb_helper->dev;
> @@ -334,10 +334,15 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
> int dpms_mode)
> struct drm_connector *connector;
> int i, j;
>
> +   if (oops_in_progress) {
> +   if (!mutex_trylock(>mode_config.mutex))
> +   return -EBUSY;
> +   } else
> +   mutex_lock(>mode_config.mutex);
> +
> /*
>  * For each CRTC in this fb, turn the connectors on/off.
>  */
> -   mutex_lock(>mode_config.mutex);
> for (i = 0; i < fb_helper->crtc_count; i++) {
> crtc = fb_helper->crtc_info[i].mode_set.crtc;
>
> @@ -353,6 +358,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
> dpms_mode)
> }
> }
> mutex_unlock(>mode_config.mutex);
> +   return 0;
>  }
>
>  int drm_fb_helper_blank(int blank, struct fb_info *info)
> @@ -360,24 +366,19 @@ int drm_fb_helper_blank(int blank, struct fb_info *info)
> switch (blank) {
> /* Display: On; HSync: On, VSync: On */
> case FB_BLANK_UNBLANK:
> -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
> -   break;
> +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
> /* Display: Off; HSync: On, VSync: On */
> case FB_BLANK_NORMAL:
> -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> -   break;
> +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> /* Display: Off; HSync: Off, VSync: On */
> case FB_BLANK_HSYNC_SUSPEND:
> -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> -   break;
> +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> /* Display: Off; HSync: On, VSync: Off */
> case FB_BLANK_VSYNC_SUSPEND:
> -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
> -   break;
> +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
> /* Display: Off; HSync: Off, VSync: Off */
> case FB_BLANK_POWERDOWN:
> -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
> -   break;
> +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
> }
> return 0;
>  }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
>> One thing I've run into in the past when trying to make changes in drm
>> core, and Daniel Vetter has mentioned the same, is that it is a bit of
>> a pain to compile test things for the arm drivers that do not support
>> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
>> the low hanging fruit (basically the drivers that just needed a
>> Kconfig change).  But, IIRC some of the backlight related code in
>> shmob had some non-trivial plat dependencies.
>
> I've just compiled the shmob-drm driver without any error on x86_64. The CMA
> GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though
> (but that would only be an issue if we require no arch dependency at all, not
> with multiarch).

ahh, ok.. maybe I should try again.  I'm pretty sure I was hitting
some issues around the backlight code before, but maybe that has been
fixed since then.

Anyways, if it builds for multi-platform, maybe you could send a patch
for the kconfig?

>> And I think when tegra came in, it introduced some non-trivial plat
>> dependencies.
>>
>> What do others think about requiring multiarch or no arch dependencies
>> for new drivers, and cleaning up existing drivers.  Even if it is at
>> reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
>> of the backlight code in shmob) or doesn't even work but is just for
>> the purpose of being able to compile test the rest of the code?
>>
>> Thoughts?
>
> That sounds good to me, but would result in many drivers being exposed on x86
> even though they're useless on that platform. Would it make sense to add a new
> CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests
> only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM ||
> COMPILE_TEST.
>

fwiw, CONFIG_OF seems to filter things out on x86..  but I could live
doing one arm build and one x86 build to compile test things.

CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to
build (ie. driver is known not to be functional).. sounds like that
will shortly not be an issue for tegra, and if shmobile already buids
on multiplatform, then maybe we won't need this.

BR,
-R

> I'm pretty sure I've seen a similar proposal quite recently but I can't
> remember where.
>
> --
> Regards,
>
> Laurent Pinchart
>

thoughts on requiring multi-arch support for arm drm drivers?

[Thierry Reding]

On Sun, Jan 20, 2013 at 04:42:55PM +0100, Daniel Vetter wrote:
> On Sun, Jan 20, 2013 at 4:08 PM, Rob Clark  wrote:
> > One thing I've run into in the past when trying to make changes in drm
> > core, and Daniel Vetter has mentioned the same, is that it is a bit of
> > a pain to compile test things for the arm drivers that do not support
> > CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> > the low hanging fruit (basically the drivers that just needed a
> > Kconfig change).  But, IIRC some of the backlight related code in
> > shmob had some non-trivial plat dependencies.  And I think when tegra
> > came in, it introduced some non-trivial plat dependencies.
> >
> > What do others think about requiring multiarch or no arch dependencies
> > for new drivers, and cleaning up existing drivers.  Even if it is at
> > reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
> > of the backlight code in shmob) or doesn't even work but is just for
> > the purpose of being able to compile test the rest of the code?
> >
> > Thoughts?
> 
> Definitely in favour of this. Also, I think the arm world _really_
> needs something like Wu Fenggungs 0-day kernel testing/building
> machines, which checks every commit pushed to around a 150 git kernel
> maintainer repos with randconfigs, sparse (and iirc other static
> checkers like cocinelle), and test-boots them on kvm. It's not just
> that every driver seems to need it's own special defconfig/platform to
> even be selectable in Kconfig, they also seem to randomly (and often)
> break compilation if you're on the wrong tree or don't have the
> exactly required golden config ...

That's true. Unfortunately due to the many repositories involved there
seem to be quite a few dependencies involved to get all the pieces to
build properly. linux-next is usually in pretty good shape, however.
I've been running an automated build over at least all ARM defconfigs in
linux-next for a few days and sent out patches for build failures. But
I'm not sure if I can keep that up, or at least not on a daily basis.

Obviously it doesn't help the DRM problem all that much. But I agree
with Rob that the only thing that will really help is multi-platform
support.

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

thoughts on requiring multi-arch support for arm drm drivers?

[Thierry Reding]

On Sun, Jan 20, 2013 at 09:08:34AM -0600, Rob Clark wrote:
> One thing I've run into in the past when trying to make changes in drm
> core, and Daniel Vetter has mentioned the same, is that it is a bit of
> a pain to compile test things for the arm drivers that do not support
> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> the low hanging fruit (basically the drivers that just needed a
> Kconfig change).  But, IIRC some of the backlight related code in
> shmob had some non-trivial plat dependencies.  And I think when tegra
> came in, it introduced some non-trivial plat dependencies.

I've talked to Stephen about this a few days ago and his (tentative)
plan is to support ARCH_MULTIPLATFORM in 3.9. I'm not sure if that's
soon enough for you. I think the one remaining platform dependency is
the tegra_periph_reset_{assert,deassert}() which should be gone with the
common clock framework changes which should go into 3.9. Stephen has
other work-in-progress patches for the rest, so I think chances are
actually pretty good to get this ready for 3.9.

> What do others think about requiring multiarch or no arch dependencies
> for new drivers, and cleaning up existing drivers.  Even if it is at
> reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
> of the backlight code in shmob) or doesn't even work but is just for
> the purpose of being able to compile test the rest of the code?

I imagine that on Tegra we could add dummy implementations for the reset
functions, which should allow it to build it for non-Tegra. However, I
don't think it's really worth the churn to do this now just to remove
them again in 3.9. The general direction would seem to be to require new
platforms to be multi-platform from the start, so any new drivers should
not cause the same pain anyway.

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

thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

On Mon, Jan 21, 2013 at 1:17 AM, Thierry Reding
 wrote:
> On Sun, Jan 20, 2013 at 09:08:34AM -0600, Rob Clark wrote:
>> One thing I've run into in the past when trying to make changes in drm
>> core, and Daniel Vetter has mentioned the same, is that it is a bit of
>> a pain to compile test things for the arm drivers that do not support
>> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
>> the low hanging fruit (basically the drivers that just needed a
>> Kconfig change).  But, IIRC some of the backlight related code in
>> shmob had some non-trivial plat dependencies.  And I think when tegra
>> came in, it introduced some non-trivial plat dependencies.
>
> I've talked to Stephen about this a few days ago and his (tentative)
> plan is to support ARCH_MULTIPLATFORM in 3.9. I'm not sure if that's
> soon enough for you. I think the one remaining platform dependency is
> the tegra_periph_reset_{assert,deassert}() which should be gone with the
> common clock framework changes which should go into 3.9. Stephen has
> other work-in-progress patches for the rest, so I think chances are
> actually pretty good to get this ready for 3.9.
>
>> What do others think about requiring multiarch or no arch dependencies
>> for new drivers, and cleaning up existing drivers.  Even if it is at
>> reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
>> of the backlight code in shmob) or doesn't even work but is just for
>> the purpose of being able to compile test the rest of the code?
>
> I imagine that on Tegra we could add dummy implementations for the reset
> functions, which should allow it to build it for non-Tegra. However, I
> don't think it's really worth the churn to do this now just to remove
> them again in 3.9. The general direction would seem to be to require new
> platforms to be multi-platform from the start, so any new drivers should
> not cause the same pain anyway.
>

Cool!  I think if we are good for multiarch for 3.9, that is probably
fine.  If it slip out longer than that, then we can do stub fxns as a
temporary solution.

BR,
-R


> Thierry

[PATCH] man: Fix typo and use $() for make expressions

[Thierry Reding]

On Fri, Jan 18, 2013 at 05:00:34PM +0100, David Herrmann wrote:
[...]
> Also ${} is pretty standard in makefiles, isn't it?

The curly braces are allowed and valid syntax, but I haven't seen many
uses of them. Historically only $() was a documented feature, while ${}
was accepted as equivalent but undocumented. Apparently ${} is more
common on BSD or in older makefiles. According to Wikipedia[0], the ${}
variant is "rarely used". While Wikipedia isn't necessarily an
authoritative source, it certainly corresponds with my experience in
this case.

Thierry

[0]: http://en.wikipedia.org/wiki/Make_(software)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/150fc99d/attachment.pgp>

[Bug 59649] New: [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7, 3.8-rcX

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

:00.0:  
R_000E50_SRBM_STATUS=0x200030C0
Jan 19 03:46:23 segfault kernel: [15064.658236] radeon :01:00.0:  
R_008674_CP_STALLED_STAT1 = 0x0100
Jan 19 03:46:23 segfault kernel: [15064.658242] radeon :01:00.0:  
R_008678_CP_STALLED_STAT2 = 0x1002
Jan 19 03:46:23 segfault kernel: [15064.658248] radeon :01:00.0:  
R_00867C_CP_BUSY_STAT = 0x00028482
Jan 19 03:46:23 segfault kernel: [15064.658254] radeon :01:00.0:  
R_008680_CP_STAT  = 0x80838645
Jan 19 03:46:23 segfault kernel: [15064.829116] radeon :01:00.0: Wait for
MC idle timedout !
Jan 19 03:46:23 segfault kernel: [15064.829123] radeon :01:00.0:  
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 19 03:46:23 segfault kernel: [15064.844133] radeon :01:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 19 03:46:23 segfault kernel: [15064.860144] radeon :01:00.0:  
R_008010_GRBM_STATUS=0xA0003030
Jan 19 03:46:23 segfault kernel: [15064.860150] radeon :01:00.0:  
R_008014_GRBM_STATUS2=0x0003
an 19 03:46:23 segfault kernel: [15064.860163] radeon :01:00.0:  
R_000E50_SRBM_STATUS=0x2000B0C0
Jan 19 03:46:23 segfault kernel: [15064.860169] radeon :01:00.0:  
R_008674_CP_STALLED_STAT1 = 0x
Jan 19 03:46:23 segfault kernel: [15064.860175] radeon :01:00.0:  
R_008678_CP_STALLED_STAT2 = 0x
Jan 19 03:46:23 segfault kernel: [15064.860181] radeon :01:00.0:  
R_00867C_CP_BUSY_STAT = 0x
Jan 19 03:46:23 segfault kernel: [15064.860191] radeon :01:00.0:  
R_008680_CP_STAT  = 0x8010
Jan 19 03:46:23 segfault kernel: [15064.861197] radeon :01:00.0: GPU reset
succeeded, trying to resume

Jan 19 04:39:23 segfault kernel: [ 2791.671107] [drm:r600_ib_test] *ERROR*
radeon: fence wait failed (-35).

Jan 19 04:39:23 segfault kernel: [ 2791.671115] [drm:radeon_ib_ring_tests]
*ERROR* radeon: failed testing IB on GFX ring (-35).

Then floods console with

[drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
radeon :01:00.0: couldn't schedule ib (over and over)

mesa-dri-drivers-9.0.1-3.fc18.x86_64
libdrm-2.4.40-1.fc18.x86_64

kernels: kernel-3.7.3-201.fc18.x86_64,
kernel-devel-3.8.0-0.rc3.git1.2.fc19.x86_64

I have not tried on 3.8-rc4 yet

Laptop:  Lenovo ThinkPad W500

-- 
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/20130121/53209b3d/attachment-0001.html>

[Bug 43751] [TTM] Out of kernel memory

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

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


ewhite  changed:

   What|Removed |Added

 CC||ewhite20 at etcsys.com




--- Comment #6 from ewhite   2013-01-21 04:48:13 ---
after about two days of up-time, xorg goes to 100% cpu.  shortly thereafter 
receive the following:
Jan 17 19:18:32 acan kernel: [TTM] Out of kernel memory
Jan 17 19:18:32 acan kernel: [TTM] Out of kernel memory
Jan 17 19:18:32 acan kernel: radeon :0f:00.0: object_init failed for (8192,
0x0006)
Jan 17 19:18:32 acan kernel: [drm:radeon_gem_object_create] *ERROR* Failed to
allocate GEM object (8192, 4, 4096, -12)

this has occurred with both nvidia FX1800 w/nouveau driver and ati FMV2250.

0f:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
FireMV 2250 [1002:719b] (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices [AMD] nee ATI Device [1002:0602]
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f500 (64-bit, non-prefetchable) [size=64K]
I/O ports at e000 [size=256]
[virtual] Expansion ROM at f502 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon

system is HP Z600 w/2 x X5650 and 12GB memory.

Linux acan 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012
(259fc87) x86_64 x86_64 x86_64 GNU/Linux

distribution is opensuse 12.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.

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

A bunch of intel and radeon fixes, along with two fixes to TTM code.

The correct fix for the Intel ironlake failure is in this, and should make 
things more stable, along with some misc radeon fixes.

Dave.

The following changes since commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82:

  udldrmfb: udl_get_edid: drop unneeded i-- (2013-01-14 08:45:27 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to 014b34409fb2015f63663b6cafdf557fdf289628:

  ttm: on move memory failure don't leave a node dangling (2013-01-21 13:45:23 
+1000)


Alex Deucher (2):
  drm/radeon: clear reset flags if engines are idle
  Revert "drm/radeon: do not move bo to different placement at each cs"

Chris Wilson (2):
  drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state
  drm/i915: Invalidate the relocation presumed_offsets along the slow path

Dave Airlie (4):
  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux 
into drm-next
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  ttm: don't destroy old mm_node on memcpy failure
  ttm: on move memory failure don't leave a node dangling

Jani Nikula (2):
  drm/i915/eDP: do not write power sequence registers for ghost eDP
  drm/i915: fix FORCEWAKE posting reads

Jerome Glisse (1):
  drm/radeon: improve semaphore debugging on lockup

Marek Ol??k (1):
  drm/radeon: allow FP16 color clear registers on r500

 drivers/gpu/drm/i915/i915_debugfs.c|  3 ++
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 +
 drivers/gpu/drm/i915/i915_irq.c| 11 +++
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 drivers/gpu/drm/i915/intel_dp.c| 47 --
 drivers/gpu/drm/i915/intel_pm.c| 17 +++
 drivers/gpu/drm/radeon/evergreen.c |  6 
 drivers/gpu/drm/radeon/ni.c|  6 
 drivers/gpu/drm/radeon/r600.c  |  6 
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_drv.c|  3 +-
 drivers/gpu/drm/radeon/radeon_object.c | 18 +++-
 drivers/gpu/drm/radeon/radeon_ring.c   |  2 ++
 drivers/gpu/drm/radeon/radeon_semaphore.c  |  4 +++
 drivers/gpu/drm/radeon/reg_srcs/rv515  |  2 ++
 drivers/gpu/drm/radeon/si.c|  6 
 drivers/gpu/drm/ttm/ttm_bo.c   |  1 +
 drivers/gpu/drm/ttm/ttm_bo_util.c  | 11 +--
 19 files changed, 140 insertions(+), 32 deletions(-)

[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed

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

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





--- Comment #9 from maolihappy <506330518 at qq.com>  2013-01-21 03:04:59 ---
 My hardware is rv770, and I try to avoid the ring_test. However, the dmesg
shows error on ib_test ad return to 0xCAFEDEAD. Could you tell me the reason of
this problem? Is the problem raised coz of my config?
Thanks and regads.

-- 
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 56534] All anti-aliasing methods buggy at cayman

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

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

--- Comment #5 from Alexandre Demers  ---
Forcing MLAA through driconf on Cayman 6950 crashes Gnome Shell if both mlaa
and mlaa color (2D) are set (tested with both set to 8). If one of them is not
set, Gnome Shell doesn't crashes.

MLAA color (2D) seems to have an effect on my Gnome Shell display.

-- 
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/20130121/1a9ae94a/attachment.html>

i965 (sandy-bridge): mesa-git DRI drivers is not linked against libdrm-git (libdrm_intel.so)

[Sedat Dilek]

DRM_XORG_LIBS_value=
> ac_cv_env_LIBKMS_XORG_CFLAGS_set=
> ac_cv_env_LIBKMS_XORG_CFLAGS_value=
> ac_cv_env_LIBKMS_XORG_LIBS_set=
> ac_cv_env_LIBKMS_XORG_LIBS_value=
> pkg_cv_INTEL_CFLAGS='-I/opt/xorg/include -I/opt/xorg/include/libdrm  '
> pkg_cv_INTEL_LIBS='-L/opt/xorg/lib -ldrm_intel -ldrm  '
> pkg_cv_LIBDRM_CFLAGS='-I/opt/xorg/include -I/opt/xorg/include/libdrm  '
> pkg_cv_LIBDRM_LIBS='-L/opt/xorg/lib -ldrm  '
> INTEL_CFLAGS='-I/opt/xorg/include -I/opt/xorg/include/libdrm  '
> INTEL_LIBS='-L/opt/xorg/lib -ldrm_intel -ldrm  '
> LIBDRM_CFLAGS='-I/opt/xorg/include -I/opt/xorg/include/libdrm  '
> LIBDRM_LIBS='-L/opt/xorg/lib -ldrm  '
> LIBDRM_XORG_CFLAGS=''
> LIBDRM_XORG_LIBS=''
> LIBKMS_XORG_CFLAGS=''
> LIBKMS_XORG_LIBS=''
>
> - Sedat -

So, the problem is caused by the usage of xorg.conf filename in
/etc/ld.so.conf.d/ directory.

The systemwide LIBDRM shared-libs (see
/etc/ld.so.conf.d/x86_64-linux-gnu.conf) have a higher position in the
ldconfig-cache and considered at rank #1 before mine.

Solve this by renaming xorg.conf -> a-local-xorg.conf (YUPP, the
filename matters!).

I have also built the Intel XORG video driver and executing...

 LIBGL_DEBUG=verbose LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri glxgears

...now uses i965_dri.so and intel_drv.so from my /opt/xorg installation.

Unfortunately, the generated libGL.so from gles3 mesa GIT tree is a
bit "buggy" (segfaults in FFX and unity-3d is unusable).
Handling of libGL.so version in Ubuntu is done a bit uncomfortably via
/usr/lib/x86_64-linux-gnu/mesa/ld.so.conf file.
But this is a different story...

Attached are my build-scripts with a lot of comments.
So, I hope I catched all problems with building LIBDRM/MESA with LLVM/CLANG.

A big thank-you to Edwin for the vital help.

- Sedat -

$ cat /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
/usr/lib/x86_64-linux-gnu/mesa

$ cat /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf_myXORG-1st
/usr/lib/x86_64-linux-gnu/mesa
/opt/xorg/lib
-- next part --
A non-text attachment was scrubbed...
Name: build_libdrm.sh
Type: application/x-sh
Size: 1689 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/9019a665/attachment-0003.sh>
-- next part --
A non-text attachment was scrubbed...
Name: build_mesa.sh
Type: application/x-sh
Size: 3025 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/9019a665/attachment-0004.sh>
-- next part --
A non-text attachment was scrubbed...
Name: build_xf86-video-intel.sh
Type: application/x-sh
Size: 1302 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130121/9019a665/attachment-0005.sh>

Re: [PATCH] drm/fb: avoid sleeping in unblank_screen() if oops in progress

[Daniel Vetter]

On Fri, Dec 14, 2012 at 12:01 PM, Konstantin Khlebnikov
khlebni...@openvz.org wrote:
 unblank_screen() can be called from interrupt context during oops.
 thus all -fb_blank handlers should avoid sleeping in this situation.

 callstack:
 panic()
 bust_spinlocks(1)
 unblank_screen()
 vc-vc_sw-con_blank()
 fbcon_blank()
 fb_blank()
 info-fbops-fb_blank()
 drm_fb_helper_blank()
 drm_fb_helper_dpms()
 mutex_lock(dev-mode_config.mutex)

 Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: David Airlie airl...@linux.ie
 Cc: dri-devel@lists.freedesktop.org

Since the fb helper already has its own panic notifier it's imo better
to just bail out if there's an oops in progress. The panic notifier
itself completely lacks locking though. I'm working on some fb helper
cleanups, so I'll take care of this mess.
-Daniel

 ---
  drivers/gpu/drm/drm_fb_helper.c |   25 +
  1 file changed, 13 insertions(+), 12 deletions(-)

 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index 954d175..2c9f49f 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -326,7 +326,7 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op 
 = {
  static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
  #endif

 -static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
 +static int drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
  {
 struct drm_fb_helper *fb_helper = info-par;
 struct drm_device *dev = fb_helper-dev;
 @@ -334,10 +334,15 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
 int dpms_mode)
 struct drm_connector *connector;
 int i, j;

 +   if (oops_in_progress) {
 +   if (!mutex_trylock(dev-mode_config.mutex))
 +   return -EBUSY;
 +   } else
 +   mutex_lock(dev-mode_config.mutex);
 +
 /*
  * For each CRTC in this fb, turn the connectors on/off.
  */
 -   mutex_lock(dev-mode_config.mutex);
 for (i = 0; i  fb_helper-crtc_count; i++) {
 crtc = fb_helper-crtc_info[i].mode_set.crtc;

 @@ -353,6 +358,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
 dpms_mode)
 }
 }
 mutex_unlock(dev-mode_config.mutex);
 +   return 0;
  }

  int drm_fb_helper_blank(int blank, struct fb_info *info)
 @@ -360,24 +366,19 @@ int drm_fb_helper_blank(int blank, struct fb_info *info)
 switch (blank) {
 /* Display: On; HSync: On, VSync: On */
 case FB_BLANK_UNBLANK:
 -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
 -   break;
 +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
 /* Display: Off; HSync: On, VSync: On */
 case FB_BLANK_NORMAL:
 -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
 -   break;
 +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
 /* Display: Off; HSync: Off, VSync: On */
 case FB_BLANK_HSYNC_SUSPEND:
 -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
 -   break;
 +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
 /* Display: Off; HSync: On, VSync: Off */
 case FB_BLANK_VSYNC_SUSPEND:
 -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
 -   break;
 +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
 /* Display: Off; HSync: Off, VSync: Off */
 case FB_BLANK_POWERDOWN:
 -   drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
 -   break;
 +   return drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
 }
 return 0;
  }

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



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/33] drm: Convert to devm_ioremap_resource()

[Thierry Reding]

Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.

Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c| 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 7 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 8 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c| 8 +++-
 drivers/gpu/drm/tegra/dc.c  | 8 +++-
 drivers/gpu/drm/tegra/hdmi.c| 6 +++---
 drivers/gpu/drm/tegra/host1x.c  | 6 +++---
 9 files changed, 27 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 67a83e6..411f69b7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1785,11 +1785,9 @@ static int fimc_probe(struct platform_device *pdev)
 
/* resource memory */
ctx-regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   ctx-regs = devm_request_and_ioremap(dev, ctx-regs_res);
-   if (!ctx-regs) {
-   dev_err(dev, failed to map registers.\n);
-   return -ENXIO;
-   }
+   ctx-regs = devm_ioremap_resource(dev, ctx-regs_res);
+   if (IS_ERR(ctx-regs))
+   return PTR_ERR(ctx-regs);
 
/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..36493ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -913,11 +913,9 @@ static int fimd_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
-   ctx-regs = devm_request_and_ioremap(pdev-dev, res);
-   if (!ctx-regs) {
-   dev_err(dev, failed to map registers\n);
-   return -ENXIO;
-   }
+   ctx-regs = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(ctx-regs))
+   return PTR_ERR(ctx-regs);
 
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 36c3905..7329abd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1136,10 +1136,9 @@ static int g2d_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
-   g2d-regs = devm_request_and_ioremap(pdev-dev, res);
-   if (!g2d-regs) {
-   dev_err(dev, failed to remap I/O memory\n);
-   ret = -ENXIO;
+   g2d-regs = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(g2d-regs)) {
+   ret = PTR_ERR(g2d-regs);
goto err_put_clk;
}
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 8140753..7841c3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1692,11 +1692,9 @@ static int gsc_probe(struct platform_device *pdev)
 
/* resource memory */
ctx-regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   ctx-regs = devm_request_and_ioremap(dev, ctx-regs_res);
-   if (!ctx-regs) {
-   dev_err(dev, failed to map registers.\n);
-   return -ENXIO;
-   }
+   ctx-regs = devm_ioremap_resource(dev, ctx-regs_res);
+   if (IS_ERR(ctx-regs))
+   return PTR_ERR(ctx-regs);
 
/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index e9e83ef..a6da774 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -656,11 +656,9 @@ static int rotator_probe(struct platform_device *pdev)
platform_get_device_id(pdev)-driver_data;
 
rot-regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   rot-regs = devm_request_and_ioremap(dev, rot-regs_res);
-   if (!rot-regs) {
-   dev_err(dev, failed to map register\n);
-   return -ENXIO;
-   }
+   rot-regs = devm_ioremap_resource(dev, rot-regs_res);
+   if (IS_ERR(rot-regs))
+   return PTR_ERR(rot-regs);
 
rot-irq = platform_get_irq(pdev, 0);
if (rot-irq  0) {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 

[Bug 58839] errors about too many fences printed while playing neverball

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 CC||mar...@gmail.com

--- Comment #6 from Michel Dänzer mic...@daenzer.net ---
Marek, any ideas? I'm also seeing this with radeonsi.

-- 
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 v16 RESEND 6/7] drm_modes: add videomode helpers

[Steffen Trumtrar]

Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 drivers/gpu/drm/drm_modes.c |   37 +
 include/drm/drmP.h  |5 +
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..184a22d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include linux/export.h
 #include drm/drmP.h
 #include drm/drm_crtc.h
+#include video/videomode.h
 
 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+   struct drm_display_mode *dmode)
+{
+   dmode-hdisplay = vm-hactive;
+   dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+   dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+   dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+   dmode-vdisplay = vm-vactive;
+   dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+   dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+   dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+   dmode-clock = vm-pixelclock / 1000;
+
+   dmode-flags = 0;
+   if (vm-dmt_flags  VESA_DMT_HSYNC_HIGH)
+   dmode-flags |= DRM_MODE_FLAG_PHSYNC;
+   else if (vm-dmt_flags  VESA_DMT_HSYNC_LOW)
+   dmode-flags |= DRM_MODE_FLAG_NHSYNC;
+   if (vm-dmt_flags  VESA_DMT_VSYNC_HIGH)
+   dmode-flags |= DRM_MODE_FLAG_PVSYNC;
+   else if (vm-dmt_flags  VESA_DMT_VSYNC_LOW)
+   dmode-flags |= DRM_MODE_FLAG_NVSYNC;
+   if (vm-data_flags  DISPLAY_FLAGS_INTERLACED)
+   dmode-flags |= DRM_MODE_FLAG_INTERLACE;
+   if (vm-data_flags  DISPLAY_FLAGS_DOUBLESCAN)
+   dmode-flags |= DRM_MODE_FLAG_DBLSCAN;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..5fbb0fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
 struct drm_file;
 struct drm_device;
 
+struct videomode;
+
 #include drm/drm_os_linux.h
 #include drm/drm_hashtab.h
 #include drm/drm_mm.h
@@ -1454,6 +1456,9 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
  struct drm_cmdline_mode *cmd);
 
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+  struct drm_display_mode *dmode);
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

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

[PATCH v16 RESEND 5/7] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 drivers/video/fbmon.c |   42 ++
 include/linux/fb.h|4 
 2 files changed, 46 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include linux/pci.h
 #include linux/slab.h
 #include video/edid.h
+#include video/of_videomode.h
 #include video/videomode.h
 #ifdef CONFIG_PPC_OF
 #include asm/prom.h
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode 
*vm,
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+   pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u 
%u\n,
+m-xres, m-yres, m-refresh, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+   int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, vm, index);
+   if (ret)
+   return ret;
+
+   fb_videomode_from_videomode(vm, fb);
+
+   pr_debug(%s: got %dx%d display mode from %s\n,
+   of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+   dump_fb_videomode(fb);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
 struct device;
 struct file;
 struct videomode;
+struct device_node;
 
 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
 
+extern int of_get_fb_videomode(struct device_node *np,
+  struct fb_videomode *fb,
+  int index);
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);
 
-- 
1.7.10.4

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

[PATCH v16 RESEND 4/7] fbmon: add videomode helpers

[Steffen Trumtrar]

Add a function to convert from the generic videomode to a fb_videomode.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 drivers/video/fbmon.c |   52 +
 include/linux/fb.h|4 
 2 files changed, 56 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include linux/pci.h
 #include linux/slab.h
 #include video/edid.h
+#include video/videomode.h
 #ifdef CONFIG_PPC_OF
 #include asm/prom.h
 #include asm/pci-bridge.h
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct 
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
 }
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+   struct fb_videomode *fbmode)
+{
+   unsigned int htotal, vtotal;
+
+   fbmode-xres = vm-hactive;
+   fbmode-left_margin = vm-hback_porch;
+   fbmode-right_margin = vm-hfront_porch;
+   fbmode-hsync_len = vm-hsync_len;
+
+   fbmode-yres = vm-vactive;
+   fbmode-upper_margin = vm-vback_porch;
+   fbmode-lower_margin = vm-vfront_porch;
+   fbmode-vsync_len = vm-vsync_len;
+
+   /* prevent division by zero in KHZ2PICOS macro */
+   fbmode-pixclock = vm-pixelclock ?
+   KHZ2PICOS(vm-pixelclock / 1000) : 0;
+
+   fbmode-sync = 0;
+   fbmode-vmode = 0;
+   if (vm-dmt_flags  VESA_DMT_HSYNC_HIGH)
+   fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+   if (vm-dmt_flags  VESA_DMT_HSYNC_HIGH)
+   fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+   if (vm-data_flags  DISPLAY_FLAGS_INTERLACED)
+   fbmode-vmode |= FB_VMODE_INTERLACED;
+   if (vm-data_flags  DISPLAY_FLAGS_DOUBLESCAN)
+   fbmode-vmode |= FB_VMODE_DOUBLE;
+   fbmode-flag = 0;
+
+   htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+   vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+   /* prevent division by zero */
+   if (htotal  vtotal) {
+   fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+   /* a mode must have htotal and vtotal != 0 or it is invalid */
+   } else {
+   fbmode-refresh = 0;
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
 struct fb_info;
 struct device;
 struct file;
+struct videomode;
 
 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
 
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+  struct fb_videomode *fbmode);
+
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4

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

[PATCH v16 RESEND 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.

If no native mode is specified, the first subnode will be used.

For cases where the graphics driver knows there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 .../devicetree/bindings/video/display-timing.txt   |  109 +
 drivers/video/Kconfig  |   15 ++
 drivers/video/Makefile |2 +
 drivers/video/of_display_timing.c  |  239 
 drivers/video/of_videomode.c   |   54 +
 include/video/of_display_timing.h  |   20 ++
 include/video/of_videomode.h   |   18 ++
 7 files changed, 457 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/video/of_display_timing.h
 create mode 100644 include/video/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timing.txt 
b/Documentation/devicetree/bindings/video/display-timing.txt
new file mode 100644
index 000..1500385
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -0,0 +1,109 @@
+display-timing bindings
+===
+
+display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+   lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+   - active high = drive pixel data on rising edge/
+   sample data on falling edge
+   - active low  = drive pixel data on falling edge/
+   sample data on rising edge
+   - ignored = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+
+All the optional properties that are not bool follow the following logic:
+1: high active
+0: low active
+omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+  +--+-+--+---+
+  |  |↑|  |   |
+  |  ||vback_porch |  |   |
+  |  |↓|  |   |
+  +--###--+---+
+  |  #↑#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |#---+---#|-|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #↓#  |   |
+  +--###--+---+
+  |  |↑|  |   |
+  |

[PATCH v16 RESEND 0/7] of: add display helper

[Steffen Trumtrar]

Hi!

There was still no maintainer, that commented, ack'd, nack'd, apply'd the
series. So, this is just a resend.
The patches were tested with:

- v15 on Tegra by Thierry
- sh-mobile-lcdcfb by Laurent
- MX53QSB by Marek
- Exynos: smdk5250 by Leela
- AM335X EVM  AM335X EVM-SK by Afzal
- imx6q: sabrelite, sabresd by Philipp and me
- imx53: tqma53/mba53 by me


Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np-full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code

Changes since v14:
- fix const struct * warning
(reported by: Leela Krishna Amudala l.kris...@samsung.com)
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7

Changes since v13:
- fix const struct * warning
(reported by: Laurent Pinchart 
laurent.pinch...@ideasonboard.com)
- prevent division by zero in fb_videomode_from_videomode

Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix const struct * warnings
(reported by: Manjunathappa, Prakash prakash...@ti.com)
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical

Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart

Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by

Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around

Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct 
foo))
- include headers were necessary
- misc minor bugfixes

Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes

Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions

Changes since v5:
- removed all display stuff and just describe timings

Changes since v4:
- refactored functions

Changes since v3:
- print error messages
- free alloced memory
- general cleanup

Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (min,typ,max)
- functions to get display_mode or fb_videomode


Regards,
Steffen


Steffen Trumtrar (7):
  viafb: rename display_timing to via_display_timing
  video: add display_timing and videomode
  video: add of helper for display timings/videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timing.txt   |  109 +
 drivers/gpu/drm/drm_modes.c|   70 ++
 drivers/video/Kconfig  |   21 ++
 drivers/video/Makefile |4 +
 drivers/video/display_timing.c |   24 ++
 drivers/video/fbmon.c  |   94 
 drivers/video/of_display_timing.c  |  239 
 drivers/video/of_videomode.c   |   54 +
 drivers/video/via/hw.c |6 +-
 drivers/video/via/hw.h |2 +-
 drivers/video/via/lcd.c|2 +-
 drivers/video/via/share.h  |2 +-
 drivers/video/via/via_modesetting.c|8 +-
 drivers/video/via/via_modesetting.h|6 +-
 drivers/video/videomode.c  |   39 
 include/drm/drmP.h |9 +
 include/linux/fb.h |8 +
 include/video/display_timing.h |  124 ++
 include/video/of_display_timing.h

[PATCH v16 RESEND 7/7] drm_modes: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 drivers/gpu/drm/drm_modes.c |   33 +
 include/drm/drmP.h  |4 
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 184a22d..fd53454 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include linux/export.h
 #include drm/drmP.h
 #include drm/drm_crtc.h
+#include video/of_videomode.h
 #include video/videomode.h
 
 /**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode 
*vm,
 EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+   struct drm_display_mode *dmode, int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, vm, index);
+   if (ret)
+   return ret;
+
+   drm_display_mode_from_videomode(vm, dmode);
+
+   pr_debug(%s: got %dx%d display mode from %s\n,
+   of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+   drm_mode_debug_printmodeline(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5fbb0fe..e26ca59 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
 struct drm_file;
 struct drm_device;
 
+struct device_node;
 struct videomode;
 
 #include drm/drm_os_linux.h
@@ -1458,6 +1459,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 
 extern int drm_display_mode_from_videomode(const struct videomode *vm,
   struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  int index);
 
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

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

[PATCH v16 RESEND 1/7] viafb: rename display_timing to via_display_timing

[Steffen Trumtrar]

The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 drivers/video/via/hw.c  |6 +++---
 drivers/video/via/hw.h  |2 +-
 drivers/video/via/lcd.c |2 +-
 drivers/video/via/share.h   |2 +-
 drivers/video/via/via_modesetting.c |8 
 drivers/video/via/via_modesetting.h |6 +++---
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
 }
 
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
 {
-   struct display_timing timing;
+   struct via_display_timing timing;
u16 dx = (var-xres - cxres) / 2, dy = (var-yres - cyres) / 2;
 
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct 
fb_var_screeninfo *var,
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
 {
-   struct display_timing crt_reg = var_to_timing(var,
+   struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var-xres, cyres ? cyres : var-yres);
 
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
 extern int viafb_DVI_ON;
 extern int viafb_hotplug;
 
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo 
*var, u16 cxres,
int panel_hres = plvds_setting_info-lcd_panel_hres;
int panel_vres = plvds_setting_info-lcd_panel_vres;
u32 clock;
-   struct display_timing timing;
+   struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
 
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
-   struct display_timing crtc;
+   struct via_display_timing crtc;
 };
 
 struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c 
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
 #include debug.h
 
 
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
 {
-   struct display_timing raw;
+   struct via_display_timing raw;
 
raw.hor_total = timing-hor_total / 8 - 5;
raw.hor_addr = timing-hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing 
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
 }
 
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
 {
-   struct display_timing raw;
+   struct via_display_timing raw;
 
raw.hor_total = timing-hor_total - 1;
raw.hor_addr = timing-hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h 
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
 #define VIA_PITCH_MAX  0x3FF8
 
 
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
 };
 
 
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing 

[PATCH v16 RESEND 2/7] video: add display_timing and videomode

[Steffen Trumtrar]

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Also, add helper functions to convert from display timings to a generic 
videomode
structure.

The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off

As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.

Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.

The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.

This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tested-by: Afzal Mohammed af...@ti.com
---
 drivers/video/Kconfig  |6 ++
 drivers/video/Makefile |2 +
 drivers/video/display_timing.c |   24 
 drivers/video/videomode.c  |   39 +
 include/video/display_timing.h |  124 
 include/video/videomode.h  |   48 
 6 files changed, 243 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/video/display_timing.h
 create mode 100644 include/video/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
  This framework adds support for low-level control of the video 
  output switch.
 
+config DISPLAY_TIMING
+   bool
+
+config VIDEOMODE
+   bool
+
 menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)  += vfb.o
 
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..5e1822c
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include video/display_timing.h
+
+void display_timings_release(struct display_timings *disp)
+{
+   if (disp-timings) {
+   unsigned int i;
+
+   for (i = 0; i  disp-num_timings; i++)
+   kfree(disp-timings[i]);
+   kfree(disp-timings);
+   }
+   kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..21c47a2
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,39 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include video/display_timing.h
+#include video/videomode.h
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+   struct display_timing *dt;
+
+   dt = display_timings_get(disp, index);
+   if (!dt)
+   return -EINVAL;
+
+   vm-pixelclock = display_timing_get_value(dt-pixelclock, TE_TYP);
+   vm-hactive = display_timing_get_value(dt-hactive, 

Re: CDF discussions at FOSDEM

[Laurent Pinchart]

Hi Daniel,

On Thursday 17 January 2013 13:29:27 Daniel Vetter wrote:
 On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote:
  On Fri, 11 Jan 2013, Laurent Pinchart wrote:
  Would anyone be interested in meeting at the FOSDEM to discuss the Common
  Display Framework ? There will be a CDF meeting at the ELC at the end of
  February, the FOSDEM would be a good venue for European developers.
  
  Yes, count me in,
 
 Jesse, Ville and me should also be around. Do we have a slot fixed already?

I've sent a mail to the FOSDEM organizers to request a hacking room for a 
couple of hours Sunday. I'll let you know as soon as I get a reply.

-- 
Regards,

Laurent Pinchart

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #1 from vincent v...@ovi.com ---
Can you run etqw with R600_DUMP_SHADERS=1 and post the output please ?

-- 
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: thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

On Mon, Jan 21, 2013 at 1:17 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 On Sun, Jan 20, 2013 at 09:08:34AM -0600, Rob Clark wrote:
 One thing I've run into in the past when trying to make changes in drm
 core, and Daniel Vetter has mentioned the same, is that it is a bit of
 a pain to compile test things for the arm drivers that do not support
 CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
 the low hanging fruit (basically the drivers that just needed a
 Kconfig change).  But, IIRC some of the backlight related code in
 shmob had some non-trivial plat dependencies.  And I think when tegra
 came in, it introduced some non-trivial plat dependencies.

 I've talked to Stephen about this a few days ago and his (tentative)
 plan is to support ARCH_MULTIPLATFORM in 3.9. I'm not sure if that's
 soon enough for you. I think the one remaining platform dependency is
 the tegra_periph_reset_{assert,deassert}() which should be gone with the
 common clock framework changes which should go into 3.9. Stephen has
 other work-in-progress patches for the rest, so I think chances are
 actually pretty good to get this ready for 3.9.

 What do others think about requiring multiarch or no arch dependencies
 for new drivers, and cleaning up existing drivers.  Even if it is at
 reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
 of the backlight code in shmob) or doesn't even work but is just for
 the purpose of being able to compile test the rest of the code?

 I imagine that on Tegra we could add dummy implementations for the reset
 functions, which should allow it to build it for non-Tegra. However, I
 don't think it's really worth the churn to do this now just to remove
 them again in 3.9. The general direction would seem to be to require new
 platforms to be multi-platform from the start, so any new drivers should
 not cause the same pain anyway.


Cool!  I think if we are good for multiarch for 3.9, that is probably
fine.  If it slip out longer than that, then we can do stub fxns as a
temporary solution.

BR,
-R


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

[PATCH 1/1] drm/exynos: Make 'drm_hdmi_get_edid' static

[Sachin Kamat]

Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_hdmi.c:111:13: warning:
symbol 'drm_hdmi_get_edid' was not declared. Should it be static?

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Compile tested on exynos-drm-fixes branch of Inki Dae's tree.
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 427d2de..2864453 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,7 +108,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
return false;
 }
 
-struct edid *drm_hdmi_get_edid(struct device *dev,
+static struct edid *drm_hdmi_get_edid(struct device *dev,
struct drm_connector *connector)
 {
struct drm_hdmi_context *ctx = to_context(dev);
-- 
1.7.4.1

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

Re: [ANNOUNCE] libdrm 2.4.41

[Thomas Klausner]

Something's wrong with this tarball -- configure.ac references man/Makefile,
but no man/ directory is included.

Lesson: always run 'make distcheck' before releasing :)
 Thomas

On Wed, Jan 16, 2013 at 01:19:17PM +0100, Maarten Lankhorst wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Alex Deucher (1):
   radeon: add new SI pci id
 
 Ben Skeggs (2):
   nouveau: disallow pushbuf BOs in multiple memory types
   nouveau: expose channel engine selection on kepler chipsets
 
 Chris Wilson (1):
   intel: Remove the fence count contributions when clearing relocs
 
 David Herrmann (4):
   man: convert manpages to XML instead of plain troff
   man: add drm.7 overview page
   man: add drm-kms overview page
   man: add drm-memory overview page
 
 David Shao (1):
   intel: Fix missing ETIME on BSD operating systems
 
 Jerome Glisse (1):
   drm/radeon: track global bo name and always return the same
 
 Jesse Barnes (1):
   man: disable man page building until David saves us all
 
 Maarten Lankhorst (1):
   configure.ac: bump version to 2.4.41 for release
 
 Marcin Slusarz (1):
   libdrm_nouveau.pc: don't include I${includedir}/nouveau
 
 Maxime Villard (2):
   libkms: fix memory leak in error path
   libkms: return -EINVAL on fstat error
 
 git tag: libdrm-2.4.41
 
 http://dri.freedesktop.org/libdrm/libdrm-2.4.41.tar.bz2
 MD5:  9b1ebc4fd27867a386df5ed59fa3a2b1  libdrm-2.4.41.tar.bz2
 SHA1: e3dfcd45e1f5bd08e35a636382a59aa9f8cb5685  libdrm-2.4.41.tar.bz2
 SHA256: 5e2519f8a7c250dcddbdfa03d5f4b1b1701744f592691834fddf209e57f4c906  
 libdrm-2.4.41.tar.bz2
 
 http://dri.freedesktop.org/libdrm/libdrm-2.4.41.tar.gz
 MD5:  1ceff52fa7979598a4463f0b6cf164de  libdrm-2.4.41.tar.gz
 SHA1: c34ce859b174cab617ce1e72a819debfcf3f143a  libdrm-2.4.41.tar.gz
 SHA256: 33c422dbae3c2113606c1909358e08a2f7ec1857b660a94191b8449c3f6a4727  
 libdrm-2.4.41.tar.gz
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAEBAgAGBQJQ9pp+AAoJEP5VjHKmcBPDx0QQAJaGl4AH7lmKnP7f0QMW2qD8
 VghS78h/HOnkL3gC+FrUu58roR0qDRBnKq+Y6EsWC02RoYoQJcZG05faJ34kvISc
 RzhMkSiOpSvDv+hNhy1Ti+w8wA+YN5V2QSMKUg6bklKTADg6ktAGwacwNj+Pk4I8
 flkEkIUYStHIqJbvo1HRXo6GH0l9Q+YopwaPxwUBW4zFVrtdEnPuEH6wl5fHpPlx
 ONsKRV0Hb9gAc5fWjjru6scDP5id1Ww9Kr4T3jC4ETA9beHKjWEuHWAWzfIHM3Fh
 m8x7eohm3xm1kBWcLr0mKqxqfZZXxXNyTnU03NMqp05niviXGp5YCgYJUPD4OZ7d
 j4eyaIPcKBwRXsB+/JOzXW4WrzI9v5oy2nR5q9UsefYr/ynAFx6srEjIw0sd4az4
 P11qXuPu04wTQkaQD02DoXZyJ48tMTQ78ZbkWpa/KhtphPfn3/tnPBnwEJTcWmgH
 6B3AkCF6PebNrRSHaQ+THE/mSvieojcwRHRFtSnkFcaVQ4J5g9taCTvE1q4hPWVG
 R08+uXXE42sgETfayg4Hxp3ehVVfDZwufUck7l9ZMkJhIpuROxp+b1k+IhiBzIYs
 idYYLWRQxj4I399CJrtFGytBnZ0PgnFkMlTsnOCrLf91s54BJ7rXxS4/TaVcacC/
 dpDNac6ynRATMY7uBBCs
 =APPb
 -END PGP SIGNATURE-
 
 ___
 xorg-announce mailing list
 xorg-annou...@lists.x.org
 http://lists.x.org/mailman/listinfo/xorg-announce
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Laurent Pinchart]

Hi Rob,

On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
 One thing I've run into in the past when trying to make changes in drm
 core, and Daniel Vetter has mentioned the same, is that it is a bit of
 a pain to compile test things for the arm drivers that do not support
 CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
 the low hanging fruit (basically the drivers that just needed a
 Kconfig change).  But, IIRC some of the backlight related code in
 shmob had some non-trivial plat dependencies.

I've just compiled the shmob-drm driver without any error on x86_64. The CMA 
GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though 
(but that would only be an issue if we require no arch dependency at all, not 
with multiarch).

 And I think when tegra came in, it introduced some non-trivial plat
 dependencies.
 
 What do others think about requiring multiarch or no arch dependencies
 for new drivers, and cleaning up existing drivers.  Even if it is at
 reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
 of the backlight code in shmob) or doesn't even work but is just for
 the purpose of being able to compile test the rest of the code?
 
 Thoughts?

That sounds good to me, but would result in many drivers being exposed on x86 
even though they're useless on that platform. Would it make sense to add a new 
CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests 
only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || 
COMPILE_TEST.

I'm pretty sure I've seen a similar proposal quite recently but I can't 
remember where.

-- 
Regards,

Laurent Pinchart

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

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Rob,

 On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
 One thing I've run into in the past when trying to make changes in drm
 core, and Daniel Vetter has mentioned the same, is that it is a bit of
 a pain to compile test things for the arm drivers that do not support
 CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
 the low hanging fruit (basically the drivers that just needed a
 Kconfig change).  But, IIRC some of the backlight related code in
 shmob had some non-trivial plat dependencies.

 I've just compiled the shmob-drm driver without any error on x86_64. The CMA
 GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though
 (but that would only be an issue if we require no arch dependency at all, not
 with multiarch).

ahh, ok.. maybe I should try again.  I'm pretty sure I was hitting
some issues around the backlight code before, but maybe that has been
fixed since then.

Anyways, if it builds for multi-platform, maybe you could send a patch
for the kconfig?

 And I think when tegra came in, it introduced some non-trivial plat
 dependencies.

 What do others think about requiring multiarch or no arch dependencies
 for new drivers, and cleaning up existing drivers.  Even if it is at
 reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
 of the backlight code in shmob) or doesn't even work but is just for
 the purpose of being able to compile test the rest of the code?

 Thoughts?

 That sounds good to me, but would result in many drivers being exposed on x86
 even though they're useless on that platform. Would it make sense to add a new
 CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests
 only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM ||
 COMPILE_TEST.


fwiw, CONFIG_OF seems to filter things out on x86..  but I could live
doing one arm build and one x86 build to compile test things.

CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to
build (ie. driver is known not to be functional).. sounds like that
will shortly not be an issue for tegra, and if shmobile already buids
on multiplatform, then maybe we won't need this.

BR,
-R

 I'm pretty sure I've seen a similar proposal quite recently but I can't
 remember where.

 --
 Regards,

 Laurent Pinchart

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com ---
Created attachment 73391
  -- https://bugs.freedesktop.org/attachment.cgi?id=73391action=edit
compressed etqw shader dump while getting gpu lock.

-- 
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 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Arnd Bergmann]

While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.

Without this patch, building allyesconfig results in:

drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: 
No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No 
such file or directory

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Inki Dae inki@samsung.com
Cc: Seung-Woo Kim sw0312@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/exynos/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
 
 config DRM_EXYNOS_FIMD
bool Exynos DRM FIMD
-   depends on DRM_EXYNOS  !FB_S3C
+   depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
 
 config DRM_EXYNOS_IPP
bool Exynos DRM IPP
-   depends on DRM_EXYNOS
+   depends on DRM_EXYNOS  !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use IPP feature for DRM.
 
-- 
1.7.10.4

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

[PATCH 00/15] ARM build regressions in v3.8

[Arnd Bergmann]

I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.

It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.

The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.

The same binutils update also broke the samsung
and w90x900 platforms.

A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.

Arnd

Arnd Bergmann (15):
  ARM: compressed/head.S: work around new binutils warning
  ARM: mvebu: build coherency_ll.S for arch=armv7-a
  ARM: samsung: fix assembly syntax for new gas
  ARM: w90x900: fix legacy assembly syntax
  ASoC: fsl: fiq and dma cannot both be modules
  clk: export __clk_get_name
  drm/exynos: don't include plat/gpio-cfg.h
  drm/exynos: fimd and ipp are broken on multiplatform
  media: coda: don't build on multiplatform
  mfd/vexpress: export vexpress_config_func_{put,get}
  mtd: davinci_nand: fix OF support
  USB: gadget/freescale: disable non-multiplatform drivers
  USB: ehci: make orion and mxc bus glues coexist
  samples/seccomp: be less stupid about cross compiling
  staging/omapdrm: don't build on multiplatform

 arch/arm/boot/compressed/Makefile|2 +-
 arch/arm/boot/compressed/head.S  |   12 
 arch/arm/mach-mvebu/coherency_ll.S   |1 +
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++--
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S |2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S|   12 ++--
 arch/arm/mach-s3c24xx/sleep-s3c2412.S|   12 ++--
 arch/arm/mach-w90x900/include/mach/entry-macro.S |4 ++--
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +-
 drivers/clk/clk.c|1 +
 drivers/gpu/drm/exynos/Kconfig   |4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |1 -
 drivers/media/platform/Kconfig   |2 +-
 drivers/mfd/vexpress-config.c|3 ++-
 drivers/mtd/nand/davinci_nand.c  |2 +-
 drivers/staging/omapdrm/Kconfig  |2 +-
 drivers/usb/gadget/Kconfig   |3 ++-
 drivers/usb/host/ehci-hcd.c  |   16 +++-
 samples/seccomp/Makefile |2 ++
 sound/soc/fsl/Kconfig|3 +++
 21 files changed, 76 insertions(+), 42 deletions(-)

-- 
1.7.10.4
Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: David Airlie airl...@linux.ie
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: James Morris james.l.mor...@oracle.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Rob Clark r...@ti.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Shawn Guo shawn@linaro.org
Cc: alsa-de...@alsa-project.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59592] Radeon HD 5670: reproducable GPU lockups since kernel 3.8

[bugzilla-daemon]

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

n...@detonation.org changed:

   What|Removed |Added

   Keywords||regression

-- 
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 59672] New: Problems initializing Radeon driver: lockup during IB test

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 59672
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Problems initializing Radeon driver: lockup during IB
test
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: luca...@linux.vnet.ibm.com
  Hardware: PowerPC
Status: NEW
   Version: XOrg 6.7.0
 Component: DRM/Radeon
   Product: DRI

Created attachment 73396
  -- https://bugs.freedesktop.org/attachment.cgi?id=73396action=edit
modprobe radeon with drm.debug=1

Hi all,

I've been trying to get a evergreen adapter to work with the Radeon driver on a
ppc64 machine. And while attempting that, I'm running into what seems to be a
infinite loop while running the IB test on ring 3.
I'm using a 3.8.0-rc4 kernel from today.
Follows an excerpt from the logs, the entire modprobe log can be found
attached.

[  171.975487] [drm:evergreen_blit_init], evergreen blit allocated bo 0600
vs 0400 ps 0500
[  171.975631] radeon 0001:01:00.0: WB enabled
[  171.975636] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0xc001d32b0c00
[  171.975642] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0xc001d32b0c0c
[  171.992732] [drm] ring test on 0 succeeded in 0 usecs
[  171.992799] [drm] ring test on 3 succeeded in 1 usecs
[  171.993112] [drm:evergreen_irq_set], evergreen_irq_set: sw int gfx
[  171.993154] [drm] ib test on ring 0 succeeded in 0 usecs
[  171.993197] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  172.419617] [drm:evergreen_irq_set], r600_irq_set: sw int dma

[  182.399612] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  182.409618] [drm:evergreen_irq_set], r600_irq_set: sw int dma
[  182.419604] radeon 0001:01:00.0: GPU lockup CP stall for more than 1msec
[  182.419615] radeon 0001:01:00.0: GPU lockup (waiting for 0x0001
last fence id 0x)
[  182.419626] [drm:r600_dma_ib_test] *ERROR* radeon: fence wait failed (-35).
[  182.419634] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 3 (-35).

Do you guys have any idea what could be wrong, or what should be looked into? 

Thanks

-- 
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 59672] Problems initializing Radeon driver: lockup during IB test

[bugzilla-daemon]

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

Lucas Kannebley Tavares luca...@linux.vnet.ibm.com changed:

   What|Removed |Added

 CC||luca...@linux.vnet.ibm.com
Version|XOrg 6.7.0  |unspecified

-- 
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 59672] Problems initializing Radeon driver: lockup during IB test

[bugzilla-daemon]

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

--- Comment #1 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Created attachment 73398
  -- https://bugs.freedesktop.org/attachment.cgi?id=73398action=edit
Backtrace upon reboot

I can't remove the module the modprobe (some resource got stuck) but there's a
backtrace printout if I attempt to reboot the machine.

-- 
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] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets

[Daniel Vetter]

We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.

References: 
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Cc: sta...@vger.kernel.org
Cc: David Woodhouse dw...@infradead.org
Reported-and-tested-by: Mihai Moldovan io...@ionic.de
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/iommu/intel-iommu.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9743769..19854bf 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct pci_dev 
*dev)
 {
/*
 * Mobile 4 Series Chipset neglects to set RWBF capability,
-* but needs it:
+* but needs it. Same seems to hold for the desktop versions.
 */
printk(KERN_INFO DMAR: Forcing write-buffer flush capability\n);
rwbf_quirk = 1;
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf);
 
 #define GGC 0x52
 #define GGC_MEMORY_SIZE_MASK   (0xf  8)
-- 
1.7.10.4

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

Re: [PATCH] iommu/intel: disable DMAR for g4x integrated gfx

[David Woodhouse]

On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
 DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
 So don't bother, but instead disable it by default to allow distros to
 unconditionally enable DMAR support.

Acked-By: David Woodhouse david.woodho...@intel.com

It *really* winds me up that we never bother to test this hardware
before we ship it.

But I'm even *more* disappointed that we can't even diagnose it and
publish coherent errata *after* the fact. I'd really like to see each
quirk which disables features referencing a specific published erratum.
We really ought to be able to manage at least *that* much.

Rajesh?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

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

Piero Finizio andabat...@yahoo.it changed:

   What|Removed |Added

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

--- Comment #21 from Piero Finizio andabat...@yahoo.it ---
With last git-6eb0d3d and git-9bdf5be the bug disappeared, so I mark it as
Resolved.

-- 
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 56534] All anti-aliasing methods buggy at cayman

[bugzilla-daemon]

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

--- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Should differents anti-aliasing methods be tracked in differents bugs?

-- 
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: fix cursor corruption on aruba and newer

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index ad6df62..30f71cc 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
y = 0;
}
 
-   if (ASIC_IS_AVIVO(rdev)) {
+   if (ASIC_IS_AVIVO(rdev)  (rdev-family  CHIP_ARUBA)) {
int i = 0;
struct drm_crtc *crtc_p;
 
-- 
1.7.11.7

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

[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed

[bugzilla-daemon]

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





--- Comment #10 from Alex Deucher alexdeuc...@gmail.com  2013-01-21 21:06:07 
---
Are you still seeing this with a newer kernel?  3.0.34 is really old.

-- 
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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7, 3.8-rcX

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Is this still an issue with the latest bits from Dave's last pull request?
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

-- 
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 59672] Problems initializing Radeon driver: lockup during IB test

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Is this still an issue with Dave's latest drm pull request:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

-- 
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/radeon: fix cursor corruption on aruba and newer

[Alex Deucher]

On Mon, Jan 21, 2013 at 3:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 Aruba and newer gpu does not need the avivo cursor work around,
 quite the opposite this work around lead to corruption.

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index ad6df62..30f71cc 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
 y = 0;
 }

 -   if (ASIC_IS_AVIVO(rdev)) {
 +   if (ASIC_IS_AVIVO(rdev)  (rdev-family  CHIP_ARUBA)) {

I believe these issues were fixed on DCE6, but I'm verifying now.  SI
is dce6 as well so the check here should probably be:

if (ASIC_IS_AVIVO(rdev)  !ASIC_IS_DCE6(rdev)) {

Alex

 int i = 0;
 struct drm_crtc *crtc_p;

 --
 1.7.11.7

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

[Bug 59592] Radeon HD 5670: reproducable GPU lockups since kernel 3.8

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Product|DRI |Mesa
Version|XOrg CVS|git
  Component|DRM/Radeon  |Drivers/Gallium/r600

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
I think this is actually a mesa bug.  The kernel commit you bisected just
allows the problematic feature to be enabled in mesa.  The mesa commits are:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664

-- 
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 59614] [bisected] Black screen on boot with Radeon HD 6670

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

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

-- 
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 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #3 from vincent v...@ovi.com ---
As far as I can tell, all shaders end with an export instruction, with
EndOfProgram bit set. I suspect an issue with number of color buffer export
involved.

Can you apply this patch and report if the game still locks the gpu ?

-- 
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 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #4 from vincent v...@ovi.com ---
Created attachment 73411
  -- https://bugs.freedesktop.org/attachment.cgi?id=73411action=edit
Disable llvm fs

-- 
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/radeon: fix cursor corruption on aruba and newer

[Jerome Glisse]

On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jan 21, 2013 at 3:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 Aruba and newer gpu does not need the avivo cursor work around,
 quite the opposite this work around lead to corruption.

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index ad6df62..30f71cc 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
 y = 0;
 }

 -   if (ASIC_IS_AVIVO(rdev)) {
 +   if (ASIC_IS_AVIVO(rdev)  (rdev-family  CHIP_ARUBA)) {

 I believe these issues were fixed on DCE6, but I'm verifying now.  SI
 is dce6 as well so the check here should probably be:

 if (ASIC_IS_AVIVO(rdev)  !ASIC_IS_DCE6(rdev)) {


Yeah i considered that too.

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

Re: [PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Alex Deucher]

On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jan 21, 2013 at 3:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 Aruba and newer gpu does not need the avivo cursor work around,
 quite the opposite this work around lead to corruption.

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index ad6df62..30f71cc 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
 y = 0;
 }

 -   if (ASIC_IS_AVIVO(rdev)) {
 +   if (ASIC_IS_AVIVO(rdev)  (rdev-family  CHIP_ARUBA)) {

 I believe these issues were fixed on DCE6, but I'm verifying now.  SI
 is dce6 as well so the check here should probably be:

 if (ASIC_IS_AVIVO(rdev)  !ASIC_IS_DCE6(rdev)) {

Actually, the two patches are identical since:
#define ASIC_IS_DCE6(rdev) ((rdev-family = CHIP_ARUBA))
but I think the DCE6 variant is clearer.  Once I verify with the hw
team I'll add the patch with that change.

Thanks!

Alex


 Alex

 int i = 0;
 struct drm_crtc *crtc_p;

 --
 1.7.11.7

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

Re: [PATCH] drm/radeon: fix cursor corruption on aruba and newer

[Jerome Glisse]

On Mon, Jan 21, 2013 at 5:10 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jan 21, 2013 at 4:22 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jan 21, 2013 at 3:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 Aruba and newer gpu does not need the avivo cursor work around,
 quite the opposite this work around lead to corruption.

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/radeon_cursor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index ad6df62..30f71cc 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -241,7 +241,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
 y = 0;
 }

 -   if (ASIC_IS_AVIVO(rdev)) {
 +   if (ASIC_IS_AVIVO(rdev)  (rdev-family  CHIP_ARUBA)) {

 I believe these issues were fixed on DCE6, but I'm verifying now.  SI
 is dce6 as well so the check here should probably be:

 if (ASIC_IS_AVIVO(rdev)  !ASIC_IS_DCE6(rdev)) {

 Actually, the two patches are identical since:
 #define ASIC_IS_DCE6(rdev) ((rdev-family = CHIP_ARUBA))
 but I think the DCE6 variant is clearer.  Once I verify with the hw
 team I'll add the patch with that change.

 Thanks!

 Alex


Yes they are identical, i meant that i considered doing it that way
but i did not have strong feeling. :)

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #5 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #3)
 As far as I can tell, all shaders end with an export instruction, with
 EndOfProgram bit set. I suspect an issue with number of color buffer export
 involved.
 
 Can you apply this patch and report if the game still locks the gpu ?

The game runs OK with the patch.

-- 
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 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Inki Dae]

Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.

Thanks,
Inki Dae

2013/1/22 Arnd Bergmann a...@arndb.de:
 While the exynos DRM support in principle can work on
 multiplatform, the FIMD and IPP sections of it both
 include the plat/map-base.h header file, which is
 not available on multiplatform. Rather than disabling
 the entire driver, we can just conditionally build
 these two parts.

 Without this patch, building allyesconfig results in:

 drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: 
 No such file or directory
 drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: 
 No such file or directory

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Joonyoung Shim jy0922.s...@samsung.com
 Cc: Inki Dae inki@samsung.com
 Cc: Seung-Woo Kim sw0312@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: David Airlie airl...@linux.ie
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/exynos/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
 index 1d1f1e5..046bcda 100644
 --- a/drivers/gpu/drm/exynos/Kconfig
 +++ b/drivers/gpu/drm/exynos/Kconfig
 @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF

  config DRM_EXYNOS_FIMD
 bool Exynos DRM FIMD
 -   depends on DRM_EXYNOS  !FB_S3C
 +   depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
 help
   Choose this option if you want to use Exynos FIMD for DRM.

 @@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D

  config DRM_EXYNOS_IPP
 bool Exynos DRM IPP
 -   depends on DRM_EXYNOS
 +   depends on DRM_EXYNOS  !ARCH_MULTIPLATFORM
 help
   Choose this option if you want to use IPP feature for DRM.

 --
 1.7.10.4

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

Re: [PATCH 09/10] drm/exynos: add G2D driver

[Inki Dae]

2013/1/21 Rob Clark robdcl...@gmail.com:
 I don't suppose you could send a libdrm patch to the list with an up
 to date version of the g2dtest code so we can get it in libdrm tree?


We are planning on updating exynos drm for libdrm. At that time, the
up to date version of the g2dtest will be posted.
Joonyoung, let it post. And I will post other things except g2dtest.

Thanks,
Inki Dae

 BR,
 -R

 On Fri, Mar 16, 2012 at 1:28 AM, Joonyoung Shim jy0922.s...@samsung.com 
 wrote:
 On 03/15/2012 07:50 PM, Dave Airlie wrote:

 G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
 G2D driver is exynos drm specific and supports only exynos4x12 series.
 user application fills command set in cmdlist and once dma start request
 these cmdlists are parsed and performed by dma.

 Where is this block documented or a pointer to the corresponding open
 userspace user code?


 I attach simple g2dtest program patch. The base of this patch is master
 branch of lastest libdrm git.

 This user progrem can test just solid color fill example.
 I will cleanup and update it for more operations later.

 Thanks.


 Again the ioctls look like they need to be depointered and use __u64.

 It would be nice if you could document how the command stream and engine
 work.

 How does userspace pass addresses to it? straight or via gem objects?
 how does it
 stop userspace blt to places it shouldn't etc.

 I'm getting the feeling this accel enabled driver needs a lot more of
 a commit message
 and lot more documentation on what it can be used for.

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



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

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