Video screen corruption after resume from suspend2ram

[Richard Weinberger]

Hi!

I'm facing a strange issue on my Laptop (Lenovo T430, UEFI boot).
Sometimes after resuming from suspend2ram the system freezes after 0 to 2 
minutes
and my screen corrupts as shown on this photo:
http://git.infradead.org/~rw/crash_suspend.jpg

The screen corruption always shows the same pattern, little read dots forming 
more or less
squares all across the screen.

Facts I know so far:

a) It happens with all kernels (tested with any kernel between 3.7 and Linus' 
as of today)

b) It happens only sometimes, every one or two weeks, I suspend my laptop about 
2-10 times a day

c) It happens after I've upgraded my Laptop's memory from 4GiB to 16GiB. The 
ram is fine, so far it passed
all tests and I've never had any kind of crash/corruption except the suspend 
thing. And I actually
use all of it because I run many KVM guests on my Laptop, etc...

d) /var/log/messages contains a lot of 0x00 exactly at the time of the crash. 
Maybe the page cache faces
also an corruption, i.e.
---cut---
  32 30 31 35 2d 30 31 2d  33 31 54 31 36 3a 34 32  |2015-01-31T16:42|
0010  3a 34 37 2e 38 31 30 31  35 30 2b 30 31 3a 30 30  |:47.810150+01:00|
0020  20 73 61 6e 64 70 75 70  70 79 20 63 6f 6c 6c 65  | sandpuppy colle|
0030  63 74 64 5b 31 37 30 32  5d 3a 20 72 72 64 74 6f  |ctd[1702]: rrdto|
0040  6f 6c 20 70 6c 75 67 69  6e 3a 20 72 72 64 5f 75  |ol plugin: rrd_u|
0050  70 64 61 74 65 5f 72 20  28 73 61 6e 64 70 75 70  |pdate_r (sandpup|
0060  70 79 2f 69 72 71 2f 69  72 71 2d 54 48 52 2e 72  |py/irq/irq-THR.r|
0070  72 64 29 20 66 61 69 6c  65 64 3a 20 73 61 6e 64  |rd) failed: sand|
0080  70 75 70 70 79 2f 69 72  71 2f 69 72 71 2d 54 48  |puppy/irq/irq-TH|
0090  52 2e 72 72 64 3a 20 69  6c 6c 65 67 61 6c 20 61  |R.rrd: illegal a|
00a0  74 74 65 6d 70 74 20 74  6f 20 75 70 64 61 74 65  |ttempt to update|
00b0  20 75 73 69 6e 67 20 74  69 6d 65 20 31 34 32 32  | using time 1422|
00c0  37 31 38 39 36 37 20 77  68 65 6e 20 6c 61 73 74  |718967 when last|
00d0  20 75 70 64 61 74 65 20  74 69 6d 65 20 69 73 20  | update time is |
00e0  31 34 32 32 37 31 38 39  36 37 20 28 6d 69 6e 69  |1422718967 (mini|
00f0  6d 75 6d 20 6f 6e 65 20  73 65 63 6f 6e 64 20 73  |mum one second s|
0100  74 65 70 29 0a 00 00 00  00 00 00 00 00 00 00 00  |tep)|
0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0410  00 00 00 00 32 30 31 35  2d 30 31 2d 33 31 54 31  |2015-01-31T1|
0420  36 3a 34 35 3a 35 31 2e  38 31 32 30 35 30 2b 30  |6:45:51.812050+0|
0430  31 3a 30 30 20 73 61 6e  64 70 75 70 70 79 20 72  |1:00 sandpuppy r|
0440  73 79 73 6c 6f 67 64 3a  20 5b 6f 72 69 67 69 6e  |syslogd: [origin|
0450  20 73 6f 66 74 77 61 72  65 3d 22 72 73 79 73 6c  | software="rsysl|
0460  6f 67 64 22 20 73 77 56  65 72 73 69 6f 6e 3d 22  |ogd" swVersion="|
0470  38 2e 34 2e 32 22 20 78  2d 70 69 64 3d 22 31 35  |8.4.2" x-pid="15|
0480  36 38 22 20 78 2d 69 6e  66 6f 3d 22 68 74 74 70  |68" x-info="http|
0490  3a 2f 2f 77 77 77 2e 72  73 79 73 6c 6f 67 2e 63  |://www.rsyslog.c|
04a0  6f 6d 22 5d 20 73 74 61  72 74 0a |om"] start.|
04ab
---cut---

The laptop crashed at 16:42 after resume, I had to power cycle it, at 16:45 it 
was up
again and rsyslog began logging. Between this log lines are 0x00s.

Can it be that something like that is hitting us again?

commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6
Author: Dave Airlie 
Date:   Wed Mar 28 10:48:49 2012 +0100

drm/i915: suspend fbdev device around suspend/hibernate

Looking at hibernate overwriting I though it looked like a cursor,
so I tracked down this missing piece to stop the cursor blink
timer. I've no idea if this is sufficient to fix the hibernate
problems people are seeing, but please test it.

Both radeon and nouveau have done this for a long time.

I've run this personally all night hib/resume cycles with no fails.

dmesg and lspci output are attached.
Attached suspend.log is the content of /var/log/messages between suspend -> 
resume and crash.

Thanks,
//richard

-- next part --
[0.00] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.7-7-vanilla (geeko at buildhost) (gcc version 
4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP Wed Dec 
17 18:00:44 UTC 2014 (762f27a)
[0.00] Command line: initrd=\initrd-3.16.7-7-vanilla 
root=/dev/mapper/system-root splash=verbose resume=/dev/mapper/system-swap
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008] usable
[0.00] BIOS-e820: [mem 0x0009-0x000b] reserved
[0.00] BIOS-e820: [mem 

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #26 from Chernovsky Oleg  ---
Ah, forgot the last reg

0x648   0x (0)

P.S. tried to increase wait delay with no success

-- 
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/20150131/4a49fb43/attachment.html>

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #25 from Chernovsky Oleg  ---
(In reply to Christian König from comment #24)
> Now take a look at si_set_uvd_clocks in si.c. Especially try to figure out
> if the first or the second call to radeon_uvd_send_upll_ctlreq fails.
> 
> Additional to that please install radeontool and get me the content of the
> CG_UPLL_* registers. E.g. I need the output of:
> 
> radeontool regmatch 0x634
> radeontool regmatch 0x638
> radeontool regmatch 0x63c
> radeontool regmatch 0x644
> radeontool regmatch 0x648
> radeontool regmatch 0x650
> 
> Thanks,
> Christian.

It's the first call to this function in si_set_uvd_clocks that's failing.
Doesn't work in bypass mode? Or maybe too low mdelay before call?

[2.237380] [drm] At call 1
[3.278457] [drm] At call 2
[3.288474] [drm] Passed!

Registers dump:
0x634   0x0706 (1798)
0x638   0x021e0403 (35521539)
0x63c   0x100ece38 (269405752)
0x644   0x0082 (8519680)
0x648   0x (0)

-- 
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/20150131/57658b43/attachment.html>

[PATCH v2] drm/vgem: implement virtual GEM

[Ben Widawsky]

On Sat, Jan 31, 2015 at 11:02:05AM -0500, Rob Clark wrote:
> On Fri, Jan 30, 2015 at 1:05 PM, Zach Reizner  wrote:
> > This patch implements the virtual GEM driver with PRIME sharing which
> > allows vgem to import a gem object from other drivers for the purpose
> > of mmap-ing them to userspace. The mmap is done using the mmap
> > operation exported by other drivers.
> >
> > v2: remove platform_device and do not attach to dma bufs
> >
> > Reviewed-by: Stéphane Marchesin 
> > Signed-off-by: Adam Jackson 
> > Signed-off-by: Ben Widawsky 
> > Signed-off-by: Zach Reizner 
> 
> couple small suggestions/comments below, but with those addressed,
> 
> Reviewed-by: Rob Clark 
> 
> > ---
> >  drivers/gpu/drm/Kconfig |   9 +
> >  drivers/gpu/drm/Makefile|   1 +
> >  drivers/gpu/drm/vgem/Makefile   |   4 +
> >  drivers/gpu/drm/vgem/vgem_dma_buf.c |  96 +
> >  drivers/gpu/drm/vgem/vgem_drv.c | 390 
> > 
> >  drivers/gpu/drm/vgem/vgem_drv.h |  57 ++
> >  6 files changed, 557 insertions(+)
> >  create mode 100644 drivers/gpu/drm/vgem/Makefile
> >  create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
> >  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
> >  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
> >
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > new file mode 100644
> > index 000..e20f4a4
> > --- /dev/null
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -0,0 +1,390 @@
> > +/*
> > + * Copyright 2011 Red Hat, Inc.
> > + * Copyright © 2014 The Chromium OS Authors
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software")
> > + * to deal in the software without restriction, including without 
> > limitation
> > + * on the rights to use, copy, modify, merge, publish, distribute, sub
> > + * license, and/or sell copies of the Software, and to permit persons to 
> > whom
> > + * them Software is furnished to do so, subject to the following 
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT 
> > SHALL
> > + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, 
> > WHETHER
> > + * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN
> > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> > SOFTWARE.
> > + *
> > + * Authors:
> > + * Adam Jackson 
> > + * Ben Widawsky 
> > + */
> > +
> > +/**
> > + * This is vgem, a (non-hardware-backed) GEM service.  This is used by 
> > Mesa's
> > + * software renderer and the X server for efficient buffer sharing.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "vgem_drv.h"
> > +
> > +#define DRIVER_NAME"vgem"
> > +#define DRIVER_DESC"Virtual GEM provider"
> > +#define DRIVER_DATE"20120112"
> > +#define DRIVER_MAJOR   1
> > +#define DRIVER_MINOR   0
> > +
> > +void vgem_gem_put_pages(struct drm_vgem_gem_object *obj)
> > +{
> > +   int num_pages = obj->base.size / PAGE_SIZE;
> > +   int i;
> > +
> > +   for (i = 0; i < num_pages; i++) {
> > +   if (obj->pages[i] == NULL)
> > +   break;
> 
> seems like other than this break statement, you could use
> drm_gem_put_pages()..  not entirely sure why you'd encounter a null
> page, but if there is a legit reason for that, then just add the check
> in drm_gem_put_pages() (plus maybe a comment) and use that..
> 

First, this code predated drm_gem_put_pages, so it was probably just an
oversight that a consolidated function existed. As for the NULL, it's because
the cleanup of failed vgem get_pages() just calls vgem put_pages() (you can't
have sparsely populated entries, but the last n pointers can be NULL). If the
helpers just dtrt, then it should use that.

> > +   page_cache_release(obj->pages[i]);
> > +   }
> > +
> > +   drm_free_large(obj->pages);
> > +   obj->pages = NULL;
> > +}
> > +
> > +static void vgem_gem_free_object(struct drm_gem_object *obj)
> > +{
> > +   struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
> > +
> > +   drm_gem_free_mmap_offset(obj);
> > +
> > +   if (vgem_obj->use_dma_buf && obj->dma_buf) {
> > +   dma_buf_put(obj->dma_buf);
> > +   obj->dma_buf = NULL;
> > +   }
> > +
> > +   drm_gem_object_release(obj);
> > +
> > +   if (vgem_obj->pages)
> > +   vgem_gem_put_pages(vgem_obj);
> > +
> > +

Can't gmake libdrm-2.4.59 on OmniOS

[CodeSwim OS Development]

I'm trying to build libdrm and have an issue when I gmake after
configuring.  Steps to reproduce:

# uname -a
SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc

# cd libdrm-2.4.59

# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/ggrep
checking for egrep... /usr/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking build system type... i386-pc-solaris2.11
checking host system type... i386-pc-solaris2.11
checking how to print strings... print -r
checking for a sed that does not truncate output... /usr/bin/gsed
checking for fgrep... /usr/bin/ggrep -F
checking for ld used by gcc... /bin/ld
checking if the linker (/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p
checking the name lister (/usr/bin/nm -p) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786240
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i386-pc-solaris2.11 file names to
i386-pc-solaris2.11 format... func_convert_file_noop
checking how to convert i386-pc-solaris2.11 file names to toolchain
format... func_convert_file_noop
checking for /bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... print -r --
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... solaris2.11 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PTHREADSTUBS... yes
checking for clock_gettime... yes
checking for open_memstream... no
checking for supported warning flags...
checking whether gcc supports -Wall... yes
checking whether gcc supports -Wextra... yes
checking whether gcc supports -Wsign-compare... yes
checking whether gcc supports -Werror-implicit-function-declaration... yes
checking whether gcc supports -Wpointer-arith... yes
checking whether gcc supports -Wwrite-strings... yes
checking whether gcc supports -Wstrict-prototypes... yes
checking whether gcc supports -Wmissing-prototypes... yes
checking whether 

[PATCH] drm/rockchip: fix clk enable disable mismatch in vop_crtc_mode_set

[Daniel Kurtz]

On Jan 31, 2015 5:37 PM, "Heiko Stübner"  wrote:
>
> Am Samstag, 31. Januar 2015, 13:43:23 schrieb Daniel Kurtz:
> > Hi Heiko,
> >
> > On Sat, Jan 31, 2015 at 3:28 AM, Heiko Stübner  wrote:
> > > The function disables the dclk at the beginning, so don't simply
return
> > > when an error happens, but instead enable the clock again, so that
> > > enable and disable calls are balanced.
> >
> > This function is a bit of a disaster, and needs fixing some day.
> > AFAICT, the dclk_rst is actually ignored if dclk is disabled, so that
> > part doesn't even work.
> >
> > > ret_clk is introduced to hold the clk_enable result and not mangle the
> > > original error code.
> > >
> > > Signed-off-by: Heiko Stuebner 
> > >
> > > ---
> > >
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
> > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 04b619a..c0387f7
> > > 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > @@ -852,7 +852,7 @@ static int vop_crtc_mode_set(struct drm_crtc
*crtc,
> > >
> > > u16 vsync_len = adjusted_mode->vsync_end -
> > > adjusted_mode->vsync_start;
> > > u16 vact_st = adjusted_mode->vtotal -
adjusted_mode->vsync_start;
> > > u16 vact_end = vact_st + vdisplay;
> > >
> > > -   int ret;
> > > +   int ret, ret_clk;
> > >
> > > uint32_t val;
> > >
> > > /*
> > >
> > > @@ -874,7 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc
*crtc,
> > >
> > > default:
> > > DRM_ERROR("unsupport connector_type[%d]\n",
> > >
> > >   vop->connector_type);
> > >
> > > -   return -EINVAL;
> > > +   ret = -EINVAL;
> > > +   goto out;
> > >
> > > };
> > > VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
> > >
> > > @@ -897,7 +898,7 @@ static int vop_crtc_mode_set(struct drm_crtc
*crtc,
> > >
> > > ret = vop_crtc_mode_set_base(crtc, x, y, fb);
> > > if (ret)
> > >
> > > -   return ret;
> > > +   goto out;
> > >
> > > /*
> > >
> > >  * reset dclk, take all mode config affect, so the clk would
run
> > >  in
> > >
> > > @@ -908,13 +909,14 @@ static int vop_crtc_mode_set(struct drm_crtc
*crtc,
> > >
> > > reset_control_deassert(vop->dclk_rst);
> > >
> > > clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
> > >
> > > -   ret = clk_enable(vop->dclk);
> > > -   if (ret < 0) {
> > > -   dev_err(vop->dev, "failed to enable dclk - %d\n",
ret);
> > > -   return ret;
> > > +out:
> > > +   ret_clk = clk_enable(vop->dclk);
> > > +   if (ret_clk < 0) {
> > > +   dev_err(vop->dev, "failed to enable dclk - %d\n",
> > > ret_clk);
> > > +   return ret_clk;
> >
> > Doesn't this swallow ret ?  I thought the point was to still return
> > the original error?
>
> I think if even the reenabling of the clock fails, there must be something
> _really_ wrong with the system [enabled before and all] - so if this also
> returns an error after the core functionality failed already, it doesn't
> really matter anymore which error we return :-) .
>
> The original point was to not overwrite the actual error (in ret) in the
case
> where clk_enable simply returns 0 .

Yeah, that makes more sense :-).

Reviewed-by: Daniel Kurtz 

>
>
> Heiko
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150131/03a324ce/attachment.html>

[Bug 88887] Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTerminator

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

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

--- Comment #1 from smoki  ---

 Yes i tried that game few days ago and can reproduce that with llvm 3.5, but
it works if mesa use (is compiled against) llvm 3.6 or llvm 3.7svn

-- 
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/20150131/5a43b996/attachment-0001.html>

[Bug 88887] Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTerminator

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

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

Bug ID: 7
   Summary: Grim Fandango Remastered segfaults within
radeon_llvm_compile->...->llvm::BasicBlock::getTermina
tor
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: NightNord at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 112998
  --> https://bugs.freedesktop.org/attachment.cgi?id=112998=edit
Backtrace for all threads

Crash within
#0  0xf62be474 in llvm::BasicBlock::getTerminator() () from
/usr/lib32/libLLVM-3.5.so
...
#9  0xf723bdae in radeon_llvm_compile () from /usr/lib32/dri/radeonsi_dri.so
...
#22 0x081b1014 in zg_RenderContext_DrawIndexedPrimitives ()
...


Full backtrace attached.
Crashes just after an intro movie, 100% reproducable.

There is a message in the game's log: "No matching vertex attribute
'vs_TexCoord' in shader 'color_quad' for QuadVertex::TexCoord" just before the
movie end.

Mesa version: Mesa 10.5.0 devel (on earlier versions too, tested up to 10.3.7)
LLVM version: 3.5.1
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]
xf86-video-ati: recent git version

-- 
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/20150131/45a3f8d6/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #28 from Lorenzo Bona  ---
I'm really sorry.

I've made more tests today and I can confirm it's my fault. 
I've probably messed up my .config. So this can be marked as not a bug. Sorry
for wasting your time.

BTW since yesterday morning git updates, as you can see, I'm facing glitch (or
whatever they are).

Should I open a new bug or I can edit the obj of this one?

-- 
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/20150131/4e46e669/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

Lorenzo Bona  changed:

   What|Removed |Added

 Attachment #112974|text/plain  |image/jpeg
  mime type||

-- 
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/20150131/5014befe/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

Lorenzo Bona  changed:

   What|Removed |Added

 Attachment #112973|text/plain  |image/jpeg
  mime type||

-- 
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/20150131/cacd/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

Lorenzo Bona  changed:

   What|Removed |Added

 Attachment #112972|text/plain  |image/jpeg
  mime type||

-- 
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/20150131/b653235f/attachment.html>

[Bug 88786] Radeon Hawaii crash on a 32-bit kernel

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

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

Woody Suwalski  changed:

   What|Removed |Added

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

--- Comment #14 from Woody Suwalski  ---
The V3 patch permits to boot to X (albait with acceleration turned off)

-- 
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/20150131/68a67e7e/attachment.html>

[Bug 88786] Radeon Hawaii crash on a 32-bit kernel

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

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

--- Comment #13 from Woody Suwalski  ---
Created attachment 112997
  --> https://bugs.freedesktop.org/attachment.cgi?id=112997=edit
dmesg with the latest patch, system is functional now

With the V3 patch system boots and is functional.
A secondary problem could be investigated:
radeon :01:00.0: disabling GPU acceleration

This problem was expected, and probably deserves a separate bug...

-- 
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/20150131/0e0d8f74/attachment-0001.html>

[PATCH 11/11] ARM: dts: rockchip: add vga encoder and enable lvds on rk3288-firefly

[Heiko Stuebner]

Add the sda7123 simple vga encoder, connect it to the vop outputs
and enable the lvds controller with the correct settings.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288-firefly.dtsi | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi 
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index e6f873a..9d383ea 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -159,6 +159,27 @@
regulator-always-on;
vin-supply = <_5v>;
};
+
+   sda7123: vga-encoder {
+   compatible = "adi,adv7123";
+   ddc-i2c-bus = <>;
+   enable-gpio = < 17 GPIO_ACTIVE_HIGH>;
+   rockchip,rgb-bridge = <>;
+   vaa-supply = <_io>;
+
+   vga_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vga_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_vga>;
+   };
+   vga_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_vga>;
+   };
+   };
+   };
 };

  {
@@ -331,6 +352,16 @@
status = "okay";
 };

+ {
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+   status = "okay";
+};
+
  {
pcfg_output_high: pcfg-output-high {
output-high;
@@ -477,10 +508,24 @@
status = "okay";
 };

+_out {
+   vopb_out_vga: endpoint at 9 {
+   reg = <9>;
+   remote-endpoint = <_in_vopb>;
+   };
+};
+
  {
status = "okay";
 };

+_out {
+   vopl_out_vga: endpoint at 9 {
+   reg = <9>;
+   remote-endpoint = <_in_vopl>;
+   };
+};
+
 _mmu {
status = "okay";
 };
-- 
2.1.1

[PATCH 10/11] ARM: dts: rockchip: add rk3288 lvds node

[Heiko Stuebner]

Add the basic node for the lvds controller of rk3288 and hook it into the
display-subsystem hirarchy.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 846d961..d063892 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -615,6 +615,11 @@
reg = <0>;
remote-endpoint = <_in_vopb>;
};
+
+   vopb_out_lvds: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};

@@ -646,6 +651,11 @@
reg = <0>;
remote-endpoint = <_in_vopl>;
};
+
+   vopl_out_lvds: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};

@@ -658,6 +668,32 @@
status = "disabled";
};

+   lvds: lvds at ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>;
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   lvds_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lvds_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+   };
+   };
+
hdmi: hdmi at ff98 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff98 0x2>;
-- 
2.1.1

[PATCH 09/11] ARM: dts: rockchip: add rk3288 lcdc0 pinmux settings

[Heiko Stuebner]

Add pinctrl settings for the configurable lcdc0 signals dclk, den, hsync
and vsync. The lcdc0 data pin configuration is not software controlable.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d771f68..846d961 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -910,6 +910,15 @@
};
};

+   lcdc0 {
+   lcdc0_ctl: lcdc0-ctl {
+   rockchip,pins = <1 24 RK_FUNC_1 
_pull_none>,
+   <1 25 RK_FUNC_1 
_pull_none>,
+   <1 26 RK_FUNC_1 
_pull_none>,
+   <1 27 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
sdmmc {
sdmmc_clk: sdmmc-clk {
rockchip,pins = <6 20 RK_FUNC_1 
_pull_none>;
-- 
2.1.1

[PATCH 08/11] drm/rockchip: enable rgb ouput of vops for vga and tv connectors

[Heiko Stuebner]

The socs itself do not contain encoders for either vga or tv output.
Therefore these will be realized by external components and thus use the
rgb output.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c0387f7..b744888 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -863,6 +863,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,

switch (vop->connector_type) {
case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_VGA:
+   case DRM_MODE_CONNECTOR_TV:
VOP_CTRL_SET(vop, rgb_en, 1);
break;
case DRM_MODE_CONNECTOR_eDP:
-- 
2.1.1

[PATCH 07/11] drm/rockchip: attach rgb bridge to encoders needing it

[Heiko Stuebner]

On SoCs like the rk3288 the lvds controller needs to be configured even for
just providing rgb data to an attached encoder. As internals of the
rockchip drm driver should not leak into the implementation of generic
i2c encoders etc, go through the list of encoders and attach any necessary
rgb bridges when building the drm device in the load callback.

Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/video/rockchip-vop.txt | 16 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 32 ++
 2 files changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
index d15351f..b7762ed 100644
--- a/Documentation/devicetree/bindings/video/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -32,6 +32,11 @@ Required properties:
 - port: A port node with endpoint definitions as defined in
   Documentation/devicetree/bindings/media/video-interfaces.txt.

+Optional properties in encoder nodes:
+- rockchip,rgb-bridge: if a separate controller is regulating access
+   to the rgb output interface it should be referenced
+   in the encoder node.
+
 Example:
 SoC specific DT entry:
vopb: vopb at ff93 {
@@ -56,3 +61,14 @@ SoC specific DT entry:
};
};
};
+
+Additional entries when a rgb-bridge is used:
+
+   lvds: lvds at ff96c000 {
+   ...
+   };
+
+   external-encoder {
+   ...
+   rockchip,rgb-bridge = <>;
+   };
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 30da781..86a3e61 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -130,6 +130,7 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
struct dma_iommu_mapping *mapping;
struct device *dev = drm_dev->dev;
struct drm_connector *connector;
+   struct drm_encoder *encoder;
int ret;

private = devm_kzalloc(drm_dev->dev, sizeof(*private), GFP_KERNEL);
@@ -173,6 +174,37 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
goto err_detach_device;

/*
+* Attach rgb bridge to encoders needing it.
+*/
+   list_for_each_entry(encoder, _dev->mode_config.encoder_list, head) {
+   struct device_node *rgb_node;
+
+   if (!encoder->of_node)
+   continue;
+
+   rgb_node = of_parse_phandle(encoder->of_node,
+   "rockchip,rgb-bridge", 0);
+   if (rgb_node) {
+   struct drm_bridge *bridge;
+
+   bridge = of_drm_find_bridge(rgb_node);
+   of_node_put(rgb_node);
+   if (!bridge) {
+   ret = -EPROBE_DEFER;
+   goto err_unbind;
+   }
+
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, bridge);
+   if (ret) {
+   DRM_ERROR("Failed to attach bridge to drm\n");
+   goto err_unbind;
+   }
+   }
+   }
+
+   /*
 * All components are now added, we can publish the connector sysfs
 * entries to userspace.  This will generate hotplug events and so
 * userspace will expect to be able to access DRM at this point.
-- 
2.1.1

[PATCH 06/11] drm/rockchip: lvds: register a bridge when no panel is set

[Heiko Stuebner]

On socs using the lvds components it also controls the use of the
general rgb outputs and must thus be configured for things like
external encoders.

Therefore register a drm_bridge in this case, an encoder can attach to.

Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/video/rockchip-lvds.txt|   8 +-
 drivers/gpu/drm/rockchip/rockchip_lvds.c   | 167 ++---
 2 files changed, 153 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
index 1616d7e..6ab69b4 100644
--- a/Documentation/devicetree/bindings/video/rockchip-lvds.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
@@ -15,8 +15,6 @@ Required properties:
 - avdd3v3-supply: regulator phandle for 3.3V analog power

 - rockchip,grf: phandle to the general register files syscon
-- rockchip,panel: phandle to a panel node as described by
-   Documentation/devicetree/bindings/panel/*

 - rockchip,data-mapping: should be "vesa" or "jeida",
This describes how the color bits are laid out in the
@@ -28,6 +26,12 @@ Required properties:
 - ports: contain a port node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.

+Optional properties:
+- rockchip,panel: phandle to a panel node as described by
+   Documentation/devicetree/bindings/panel/*
+   If no panel reference is set the lvds will act like a
+   bridge for other outbound interfaces.
+
 Example:
lvds: lvds at ff96c000 {
compatible = "rockchip,rk3288-lvds";
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index a01a3cb..46308fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -42,6 +42,9 @@
 #define encoder_to_lvds(c) \
container_of(c, struct rockchip_lvds, encoder)

+#define bridge_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, bridge)
+
 /*
  * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
  */
@@ -67,6 +70,7 @@ struct rockchip_lvds {
struct drm_panel *panel;
struct drm_connector connector;
struct drm_encoder encoder;
+   struct drm_bridge bridge;

struct mutex suspend_lock;
int suspend;
@@ -247,11 +251,10 @@ rockchip_lvds_encoder_mode_fixup(struct drm_encoder 
*encoder,
return true;
 }

-static void rockchip_lvds_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted)
+static void rockchip_lvds_mode_set(struct rockchip_lvds *lvds,
+  struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted)
 {
-   struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
u32 h_bp = mode->htotal - mode->hsync_start;
u8 pin_hsync = (mode->flags & DRM_MODE_FLAG_PHSYNC) ? 1 : 0;
u8 pin_dclk = (mode->flags & DRM_MODE_FLAG_PCSYNC) ? 1 : 0;
@@ -346,32 +349,52 @@ static void rockchip_lvds_encoder_mode_set(struct 
drm_encoder *encoder,
dsb();
 }

-static void rockchip_lvds_encoder_prepare(struct drm_encoder *encoder)
+static void rockchip_lvds_encoder_mode_set(struct drm_encoder *encoder,
+  struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted)
+{
+   rockchip_lvds_mode_set(encoder_to_lvds(encoder), mode, adjusted);
+}
+
+static int rockchip_lvds_set_vop_source(struct rockchip_lvds *lvds,
+   struct drm_encoder *encoder)
 {
-   struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
u32 val;
int ret;

-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   lvds->connector.connector_type,
-   ROCKCHIP_OUT_MODE_P888);
-   if (ret < 0) {
-   dev_err(lvds->dev, "Could not set crtc mode config: %d\n", ret);
-   return;
-   }
-
ret = rockchip_drm_encoder_get_mux_id(lvds->dev->of_node, encoder);
if (ret < 0)
-   return;
+   return ret;

if (ret)
val = RK3288_LVDS_SOC_CON6_SEL_VOP_LIT |
  (RK3288_LVDS_SOC_CON6_SEL_VOP_LIT << 16);
else
val = RK3288_LVDS_SOC_CON6_SEL_VOP_LIT << 16;
+
ret = regmap_write(lvds->grf, lvds->soc_data->grf_soc_con6, val);
-   if (ret != 0) {
-   dev_err(lvds->dev, "Could not write to GRF: %d\n", ret);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static void rockchip_lvds_encoder_prepare(struct drm_encoder *encoder)
+{
+   struct rockchip_lvds *lvds = 

[PATCH 05/11] drm/rockchip: Add support for Rockchip Soc LVDS

[Heiko Stuebner]

From: Mark Yao 

This adds support for Rockchip soc lvds found on rk3288

Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/Kconfig |   9 +
 drivers/gpu/drm/rockchip/Makefile|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 629 +++
 drivers/gpu/drm/rockchip/rockchip_lvds.h | 107 ++
 4 files changed, 746 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 1e84628..23d460b 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -26,3 +26,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_LVDS
+   tristate "Rockchip lvds support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support lvds, rgb, dual lvds output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8541304 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..a01a3cb
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,629 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
+ */
+struct rockchip_lvds_soc_data {
+   int grf_soc_con6;
+   int grf_soc_con7;
+};
+
+struct rockchip_lvds {
+   void *base;
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct clk *pclk;
+   const struct rockchip_lvds_soc_data *soc_data;
+
+   struct regulator_bulk_data supplies[3];
+
+   int output;
+   int format;
+
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct mutex suspend_lock;
+   int suspend;
+};
+
+static inline void lvds_writel(struct rockchip_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   writel_relaxed(val, lvds->regs + offset + 0x100);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+   if (!s)
+   return -EINVAL;
+
+   if (strncmp(s, "jeida", 6) == 0)
+   return LVDS_FORMAT_JEIDA;
+   else if (strncmp(s, "vesa", 6) == 0)
+   return LVDS_FORMAT_VESA;
+
+   return -EINVAL;
+}
+
+static inline int lvds_name_to_output(const char *s)
+{
+   if (!s)
+   return -EINVAL;
+
+   if (strncmp(s, "rgb", 3) == 0)
+   return DISPLAY_OUTPUT_RGB;
+   else if (strncmp(s, "lvds", 4) == 0)
+   return DISPLAY_OUTPUT_LVDS;
+   else if (strncmp(s, "duallvds", 8) == 0)
+   return DISPLAY_OUTPUT_DUAL_LVDS;
+
+   return -EINVAL;
+}
+
+static int rockchip_lvds_poweron(struct rockchip_lvds *lvds)
+{
+   int ret;
+
+   ret = regulator_bulk_enable(ARRAY_SIZE(lvds->supplies),
+   lvds->supplies);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable(lvds->pclk);
+  

[PATCH 04/11] dt-bindings: Add documentation for rockchip lvds

[Heiko Stuebner]

From: Mark Yao 

Add binding documentation for Rockchip SoC LVDS driver.

Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/video/rockchip-lvds.txt| 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-lvds.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
new file mode 100644
index 000..1616d7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
@@ -0,0 +1,59 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+- rockchip,panel: phandle to a panel node as described by
+   Documentation/devicetree/bindings/panel/*
+
+- rockchip,data-mapping: should be "vesa" or "jeida",
+   This describes how the color bits are laid out in the
+   serialized LVDS signal.
+- rockchip,data-width : should be <18> or <24>;
+- rockchip,output: should be "rgb", "lvds" or "duallvds",
+   This describes the output face.
+
+- ports: contain a port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   lvds: lvds at ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <>;
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,panel = <>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+   ports {
+   lvds_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lvds_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+   };
+   };
-- 
2.1.1

[PATCH 03/11] drm: add driver for simple vga encoders

[Heiko Stuebner]

There exist simple vga encoders without any type of management interface
and just maybe a simple gpio for turning it on or off. Examples for these
are the Analog Devices ADV7123, Chipsea CS7123 or Micronas SDA7123.

Add a generic encoder driver for those that can be used by drm drivers
using the component framework.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/i2c/Kconfig  |   6 +
 drivers/gpu/drm/i2c/Makefile |   2 +
 drivers/gpu/drm/i2c/vga-simple.c | 325 +++
 3 files changed, 333 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/vga-simple.c

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..319f2cb 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -31,4 +31,10 @@ config DRM_I2C_NXP_TDA998X
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

+config DRM_VGA_SIMPLE
+   tristate "Generic simple vga encoder"
+   help
+ Support for vga encoder chips without any special settings
+ and at most a power-control gpio.
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb5..858961f 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o

 tda998x-y := tda998x_drv.o
 obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+
+obj-$(CONFIG_DRM_VGA_SIMPLE) += vga-simple.o
diff --git a/drivers/gpu/drm/i2c/vga-simple.c b/drivers/gpu/drm/i2c/vga-simple.c
new file mode 100644
index 000..bb9d19c
--- /dev/null
+++ b/drivers/gpu/drm/i2c/vga-simple.c
@@ -0,0 +1,325 @@
+/*
+ * Simple vga encoder driver
+ *
+ * Copyright (C) 2014 Heiko Stuebner 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define connector_to_vga_simple(x) container_of(x, struct vga_simple, 
connector)
+#define encoder_to_vga_simple(x) container_of(x, struct vga_simple, encoder)
+
+struct vga_simple {
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct device *dev;
+   struct i2c_adapter *ddc;
+
+   struct regulator *vaa_reg;
+   struct gpio_desc *enable_gpio;
+
+   struct mutex enable_lock;
+   bool enabled;
+};
+
+/*
+ * Connector functions
+ */
+
+enum drm_connector_status vga_simple_detect(struct drm_connector *connector,
+   bool force)
+{
+   struct vga_simple *vga = connector_to_vga_simple(connector);
+
+   if (!vga->ddc)
+   return connector_status_unknown;
+
+   if (drm_probe_ddc(vga->ddc))
+   return connector_status_connected;
+
+   return connector_status_disconnected;
+}
+
+void vga_simple_connector_destroy(struct drm_connector *connector)
+{
+   drm_connector_unregister(connector);
+   drm_connector_cleanup(connector);
+}
+
+struct drm_connector_funcs vga_simple_connector_funcs = {
+   .dpms = drm_helper_connector_dpms,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .detect = vga_simple_detect,
+   .destroy = vga_simple_connector_destroy,
+};
+
+/*
+ * Connector helper functions
+ */
+
+static int vga_simple_connector_get_modes(struct drm_connector *connector)
+{
+   struct vga_simple *vga = connector_to_vga_simple(connector);
+   struct edid *edid;
+   int ret = 0;
+
+   if (!vga->ddc)
+   return 0;
+
+   edid = drm_get_edid(connector, vga->ddc);
+   if (edid) {
+   drm_mode_connector_update_edid_property(connector, edid);
+   ret = drm_add_edid_modes(connector, edid);
+   kfree(edid);
+   }
+
+   return ret;
+}
+
+static int vga_simple_connector_mode_valid(struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   return MODE_OK;
+}
+
+static struct drm_encoder
+*vga_simple_connector_best_encoder(struct drm_connector *connector)
+{
+   struct vga_simple *vga = connector_to_vga_simple(connector);
+
+   return >encoder;
+}
+
+static struct drm_connector_helper_funcs vga_simple_connector_helper_funcs = {
+   .get_modes = vga_simple_connector_get_modes,
+   .best_encoder = vga_simple_connector_best_encoder,
+   .mode_valid = vga_simple_connector_mode_valid,
+};
+
+/*
+ * Encoder functions
+ */
+
+static void vga_simple_encoder_destroy(struct drm_encoder *encoder)
+{
+   

[PATCH 02/11] drm: add bindings for simple vga encoders

[Heiko Stuebner]

Add the necessary devicetree binding document for simple vga encoders.

Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/drm/i2c/vga-simple.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/i2c/vga-simple.txt

diff --git a/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt 
b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
new file mode 100644
index 000..271df9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for generic vga encoders
+
+Required properties;
+  - compatible: must be "adi,adv7123"
+
+Optional properties:
+  - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - enable-gpio: GPIO pin to enable or disable the encoder
+  - vaa-supply: regulator for the analog power supply
+
+Example:
+
+   adv7123: vga-encoder {
+   compatible = "adi,adv7123";
+   ddc-i2c-bus = <>;
+   vaa-supply = <_io>;
+   enable-gpio = < 17 GPIO_ACTIVE_HIGH>;
+   };
-- 
2.1.1

[PATCH 01/11] drm/encoder: allow encoders to remember their of_node

[Heiko Stuebner]

Add an of_node field to struct drm_encoder to let encoders optionally
remember from which devicetree node they originated.

Signed-off-by: Heiko Stuebner 
---
 include/drm/drm_crtc.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cc369f3..0448732 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -527,6 +527,7 @@ struct drm_encoder_funcs {
 /**
  * struct drm_encoder - central DRM encoder structure
  * @dev: parent DRM device
+ * @of_node: device node pointer to the bridge
  * @head: list management
  * @base: base KMS object
  * @name: encoder name
@@ -543,6 +544,9 @@ struct drm_encoder_funcs {
  */
 struct drm_encoder {
struct drm_device *dev;
+#ifdef CONFIG_OF
+   struct device_node *of_node;
+#endif
struct list_head head;

struct drm_mode_object base;
-- 
2.1.1

[PATCH 00/11] drm/rockchip: add support for lvds controller and external encoders

[Heiko Stuebner]

This series adds support for the lvds encoder present on rk3288 soc and
allows external connectors to use the generic rgb pins.

On the older socs (rk3188, rk3066, etc) these pins where accessible by
anyone, while on the rk3288 the lvds controller controls access to them.

So while on the old socs an external encoder was explicitly connected
to one of the two lcd-controllers, on the rk3288 the lvds in between
can toggle which controller should be the source.

To facilitate this the lvds encoder can use two modes. When a panel is
attached it acts as encoder and without panel it just registers a bridge
that can be used later.

The bridge association to an encoder is done via a rockchip,rgb-bridge
property in the encoder node itself and handled in rockchip_drm_load
to not leak rockchip-specific handling into generic encoder drivers.


As example on how this can work, I've included a driver for simple
(dumb) vga encoders, like the adv7123 (and clones) as used on the
rk3288-firefly board. This same encoder is used on the Rayeager-px2
board but there connected directly to the rgb pins of the rk3066
which will hopefully also be supported in the future.

I've named this currently vga-simply (inspired by panel-simple), because
so far I have found the adv7123 (and two clones) but I guess there will
be more dumb vga encoders around that only differ in minimal things.


Similarly, most of the rk3288-based TV-boxes use a rk1000 i2c tv encoder
connected in a similar way - and again directly connected on the
rk3188-radxarock.


Caveats:
- the i2c subdirectory is probably not the right one for my vga encoder
  so if somebody could suggest where this should live, I'd be very happy
- I'm not sure if I'm abusing some drm-APIs in a wrong way :-)


Heiko Stuebner (9):
  drm/encoder: allow encoders to remember their of_node
  drm: add bindings for simple vga encoders
  drm: add driver for simple vga encoders
  drm/rockchip: lvds: register a bridge when no panel is set
  drm/rockchip: attach rgb bridge to encoders needing it
  drm/rockchip: enable rgb ouput of vops for vga and tv connectors
  ARM: dts: rockchip: add rk3288 lcdc0 pinmux settings
  ARM: dts: rockchip: add rk3288 lvds node
  ARM: dts: rockchip: add vga encoder and enable lvds on rk3288-firefly

Mark Yao (2):
  dt-bindings: Add documentation for rockchip lvds
  drm/rockchip: Add support for Rockchip Soc LVDS

 .../devicetree/bindings/drm/i2c/vga-simple.txt |  18 +
 .../devicetree/bindings/video/rockchip-lvds.txt|  63 ++
 .../devicetree/bindings/video/rockchip-vop.txt |  16 +
 arch/arm/boot/dts/rk3288-firefly.dtsi  |  45 ++
 arch/arm/boot/dts/rk3288.dtsi  |  45 ++
 drivers/gpu/drm/i2c/Kconfig|   6 +
 drivers/gpu/drm/i2c/Makefile   |   2 +
 drivers/gpu/drm/i2c/vga-simple.c   | 325 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  32 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c   | 756 +
 drivers/gpu/drm/rockchip/rockchip_lvds.h   | 107 +++
 include/drm/drm_crtc.h |   4 +
 15 files changed, 1431 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-lvds.txt
 create mode 100644 drivers/gpu/drm/i2c/vga-simple.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

-- 
2.1.1

[patch] drm/nouveau: indent an if statement

[Ben Skeggs]

On Fri, Jan 30, 2015 at 6:27 PM, Dan Carpenter  
wrote:
> This if statement is correct but it wasn't indented, so it looked like
> some code was missing.
Thanks Dan, applied (along with a fix for the owner thing you mentioned).

Ben.

>
> Signed-off-by: Dan Carpenter 
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.c
> index 42cac13..f20e4ca 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.c
> @@ -182,7 +182,7 @@ mxm_show_unmatched(struct nvkm_mxm *mxm, u8 *data, void 
> *info)
>  {
> u64 desc = *(u64 *)data;
> if ((desc & 0xf0) != 0xf0)
> -   nv_info(mxm, "unmatched output device 0x%016llx\n", desc);
> +   nv_info(mxm, "unmatched output device 0x%016llx\n", desc);
> return true;
>  }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 88886] GPU fault detected on luxmark luxball HDR test with AMD Tahiti

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

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

--- Comment #1 from commiethebeastie at gmail.com ---
Created attachment 112996
  --> https://bugs.freedesktop.org/attachment.cgi?id=112996=edit
GPU fault detected photo

-- 
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/20150131/dd4472a1/attachment.html>

[Bug 88886] GPU fault detected on luxmark luxball HDR test with AMD Tahiti

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

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

Bug ID: 6
   Summary: GPU fault detected on luxmark luxball HDR test with
AMD Tahiti
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: commiethebeastie at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Luxmark 3.1b1 Luxball HDR test.

agd5f drm-next-3.20-wip kernel

System doesn`t respond to sysrq "B" key.

Latest mesa-git with llvm-3.7svn build.

-- 
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/20150131/0eae2399/attachment.html>

[PATCH] drm/rockchip: vop: power off until vop standby take effect

[Mark Yao]

Vop standby will take effect end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.

we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76 ++-
 1 file changed, 63 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb25836..47ea61f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -89,6 +89,7 @@ struct vop {
/* mutex vsync_ work */
struct mutex vsync_mutex;
bool vsync_work_pending;
+   struct completion dsp_hold_completion;

const struct vop_data *data;

@@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
}
 }

+static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
+{
+   unsigned long flags;
+
+   BUG_ON(!vop->is_enabled);
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(1));
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
+static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   BUG_ON(!vop->is_enabled);
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(0));
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -454,26 +483,36 @@ static void vop_disable(struct drm_crtc *crtc)

drm_vblank_off(crtc->dev, vop->pipe);

-   disable_irq(vop->irq);
-
/*
-* TODO: Since standby doesn't take effect until the next vblank,
-* when we turn off dclk below, the vop is probably still active.
+* Vop standby will take effect until end of current frame,
+* if dsp hold valid irq happen, it means standby complete.
+*
+* we must wait standby complete when we want to disable aclk,
+* if not, memory bus maybe dead.
 */
+   reinit_completion(>dsp_hold_completion);
+   vop_dsp_hold_valid_irq_enable(vop);
+
spin_lock(>reg_lock);

VOP_CTRL_SET(vop, standby, 1);

spin_unlock(>reg_lock);

+   wait_for_completion(>dsp_hold_completion);
+
+   vop_dsp_hold_valid_irq_disable(vop);
+
+   disable_irq(vop->irq);
+
vop->is_enabled = false;
+
/*
-* disable dclk to stop frame scan, so we can safely detach iommu,
+* vop standby complete, so iommu detach is safe.
 */
-   clk_disable(vop->dclk);
-
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);

+   clk_disable(vop->dclk);
clk_disable(vop->aclk);
clk_disable(vop->hclk);
 }
@@ -1086,6 +1125,7 @@ static irqreturn_t vop_isr(int irq, void *data)
struct vop *vop = data;
uint32_t intr0_reg, active_irqs;
unsigned long flags;
+   int ret = IRQ_NONE;

/*
 * INTR_CTRL0 register has interrupt status, enable and clear bits, we
@@ -1104,15 +1144,24 @@ static irqreturn_t vop_isr(int irq, void *data)
if (!active_irqs)
return IRQ_NONE;

-   /* Only Frame Start Interrupt is enabled; other irqs are spurious. */
-   if (!(active_irqs & FS_INTR)) {
-   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
-   return IRQ_NONE;
+   if (active_irqs & DSP_HOLD_VALID_INTR) {
+   if (!completion_done(>dsp_hold_completion))
+   complete(>dsp_hold_completion);
+   active_irqs &= ~DSP_HOLD_VALID_INTR;
+   ret = IRQ_HANDLED;
}

-   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   if (active_irqs & FS_INTR) {
+   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   active_irqs &= ~FS_INTR;
+   ret = (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   }

-   return (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   /* Unhandled irqs are spurious. */
+   if (active_irqs)
+   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
+
+   return ret;
 }

 static int vop_create_crtc(struct vop *vop)
@@ -1194,6 +1243,7 @@ static int vop_create_crtc(struct vop *vop)
goto err_cleanup_crtc;
}

+   init_completion(>dsp_hold_completion);
crtc->port = port;
vop->pipe = drm_crtc_index(crtc);
rockchip_register_crtc_funcs(drm_dev, _crtc_funcs, vop->pipe);
-- 
1.7.9.5

[Bug 69670] KWin crashes when switching to OpenGL 3.1 + Raster

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

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

--- Comment #7 from smoki  ---

 Pretty much old bug, is this still an issue with current mesa?

-- 
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/20150131/77e912c3/attachment.html>

[Bug 73792] UVD usage with HD makes X11 quite unstable on Samsung ATIV Book Lite 9 (A4-1450 CPU, KABINI graphics))

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

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

--- Comment #4 from smoki  ---

 I guess this one had been fixed long ago.

 Richard, if you can please recheck this with more current graphic stack.

-- 
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/20150131/38788f86/attachment.html>

[Bug 78790] Game Tesseract: Crash on shaders and out of registers LLVM errors

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

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

--- Comment #2 from smoki  ---

 This works fine for me now in current llvm3.7+mesa git.

-- 
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/20150131/a355e80e/attachment.html>

[Bug 84147] (piglit) gl-3.0-multidrawarrays-vertexid produce GPU fault

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

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

smoki  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/20150131/e532d28b/attachment.html>

[Bug 84147] (piglit) gl-3.0-multidrawarrays-vertexid produce GPU fault

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

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

--- Comment #2 from smoki  ---

 Just checked, this works now with current llvm+mesa git.

 Closing.

-- 
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/20150131/667f67ed/attachment-0001.html>

[PATCH v2 2/3] Documentation: DT bindings: add more Tegra chip compatible strings

[Eduardo Valentin]

Hey Paul!

On Fri, Jan 30, 2015 at 03:11:04PM -0700, Paul Walmsley wrote:
> Align compatible strings for several IP blocks present on Tegra chips
> with the latest doctrine from the DT maintainers:
> 
> http://marc.info/?l=devicetree=142255654213019=2
> 
> The primary objective here is to avoid checkpatch warnings, per:
> 
> http://marc.info/?l=linux-tegra=142201349727836=2
> 
> DT binding text files have been updated for the following IP blocks:
> 
> - PCIe
> - SOR
> - SoC timers
> - AHB "gizmo"
> - APB_MISC
> - pinmux control
> - UART
> - PWM
> - I2C
> - SPI
> - RTC
> - PMC
> - eFuse
> - AHCI
> - HDA
> - XUSB_PADCTRL
> - SDHCI
> - SOC_THERM
> - AHUB
> - I2S
> - EHCI
> - USB PHY
> 
> N.B. The nvidia,tegra20-timer compatible string is removed from the
> nvidia,tegra30-timer.txt documentation file because it's already
> mentioned in the nvidia,tegra20-timer.txt documentation file.
> 
> This second version takes into account the following requests from
> Rob Herring :
> 
> - Per-IP block patches have been combined into a single patch
> 
> - Explicit documentation about which compatible strings are actually
>   matched by the driver has been removed.  In its place is implicit
>   documentation that loosely follows Rob's prescribed format:
> 
>   "Must contain '"nvidia,-pcie", "nvidia,tegra20-pcie"' where
> is tegra30, tegra132, ..." [...]  "You should attempt to
>document known values of  if you use it"
> 
> 
> Signed-off-by: Paul Walmsley 
> Cc: Alexandre Courbot 
> Cc: Dylan Reid 
> Cc: Eduardo Valentin 
> Cc: Greg Kroah-Hartman 
> Cc: Hans de Goede 
> Cc: Ian Campbell <ijc+devicetree at hellion.org.uk>
> Cc: Jingchang Lu 
> Cc: John Crispin 
> Cc: Kumar Gala 
> Cc: Linus Walleij 
> Cc: Mark Rutland 
> Cc: Mikko Perttunen 
> Cc: Murali Karicheri 
> Cc: Paul Walmsley 
> Cc: Pawel Moll 
> Cc: Peter De Schrijver 
> Cc: Peter Hurley 
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: Sean Paul 
> Cc: Stephen Warren 
> Cc: Takashi Iwai 
> Cc: Tejun Heo 
> Cc: "Terje Bergström" 
> Cc: Thierry Reding 
> Cc: Tuomas Tynkkynen 
> Cc: Wolfram Sang 
> Cc: Zhang Rui 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-i2c at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-pci at vger.kernel.org
> Cc: linux-pm at vger.kernel.org
> Cc: linux-pwm at vger.kernel.org
> Cc: linux-tegra at vger.kernel.org
> ---
>  .../bindings/arm/tegra/nvidia,tegra20-ahb.txt  |5 -
>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt  |6 +-
>  .../devicetree/bindings/ata/tegra-sata.txt |4 +++-
>  .../bindings/fuse/nvidia,tegra20-fuse.txt  |   10 +-
>  .../bindings/gpu/nvidia,tegra20-host1x.txt |8 ++--
>  .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt |   10 +-
>  .../bindings/misc/nvidia,tegra20-apbmisc.txt   |9 -
>  .../bindings/mmc/nvidia,tegra20-sdhci.txt  |6 +-
>  .../bindings/pci/nvidia,tegra20-pcie.txt   |8 
>  .../bindings/pinctrl/nvidia,tegra124-pinmux.txt|3 ++-
>  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|4 +++-
>  .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |7 ---
>  .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt |4 +++-
>  .../devicetree/bindings/serial/of-serial.txt   |5 -
>  .../bindings/sound/nvidia,tegra30-ahub.txt |5 -
>  .../bindings/sound/nvidia,tegra30-hda.txt  |4 +++-
>  .../bindings/sound/nvidia,tegra30-i2s.txt  |5 -
>  .../bindings/spi/nvidia,tegra114-spi.txt   |4 +++-
>  .../devicetree/bindings/thermal/tegra-soctherm.txt |4 +++-



> diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt 
> b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
> index ecf3ed76cd46..6b68cd150405 100644
> --- a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
> +++ b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
> @@ -7,7 +7,9 @@ notifications. It is also used to manage emergency shutdown 
> in an
>  overheating situation.
>  
>  Required properties :
> -- compatible : "nvidia,tegra124-soctherm".
> +- compatible : For Tegra124, must contain "nvidia,tegra124-soctherm".
> +  For Tegra132, must contain "nvidia,tegra132-soctherm".
> +  For Tegra210, must contain "nvidia,tegra210-soctherm".
>  - reg : Should contain 1 entry:
>- SOCTHERM register set
>  - interrupts : Defines the interrupt used by SOCTHERM

Considering that this is going into a single patch, you may add my

Acked-by: Eduardo Valentin 

for what concerns the thermal bindings.

Cheers,

Eduardo Valentin
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150131/c3e0a929/attachment-0001.sig>

[Bug 76223] [radeonsi] luxmark segfault

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

 0x7f45c9c47f38, 0x7f45c9c22028 [ORD=120]
[ID=194]
  0x7f45c9c47f38: i32 = or 0x7f45c9c47e30, 0x7f45c9c47b18 [ORD=99]
[ID=191]
0x7f45c9c47e30: i32 = srl 0x7f45c9c47d28, 0x7f45c9c22340
[ORD=98] [ID=187]
  0x7f45c9c47d28: i32 = xor 0x7f45c9c47c20, 0x7f45c9c43a10
[ORD=97] [ID=183]


  0x7f45c9c22340: i32 = Constant<11> [ID=26]
0x7f45c9c47b18: i32 = and 0x7f45c9c48250, 0x7f45c9c21e18
[ORD=95] [ID=173]
  0x7f45c9c48250: i32 = shl 0x7f45c9c43800, 0x7f45c9c42fc0
[ORD=94] [ID=168]


  0x7f45c9c21e18: i32 = Constant<-2097152> [ID=24]
  0x7f45c9c22028: i32 = Constant<3> [ID=25]
0x7f45c9c47f38: i32 = or 0x7f45c9c47e30, 0x7f45c9c47b18 [ORD=99]
[ID=191]
  0x7f45c9c47e30: i32 = srl 0x7f45c9c47d28, 0x7f45c9c22340 [ORD=98]
[ID=187]
0x7f45c9c47d28: i32 = xor 0x7f45c9c47c20, 0x7f45c9c43a10
[ORD=97] [ID=183]
  0x7f45c9c47c20: i32 = shl 0x7f45c9c43a10, 0x7f45c9c22028
[ORD=96] [ID=178]


  0x7f45c9c43a10: i32 = or 0x7f45c9c43908, 0x7f45c9c435f0
[ORD=65] [ID=174]


0x7f45c9c22340: i32 = Constant<11> [ID=26]
  0x7f45c9c47b18: i32 = and 0x7f45c9c48250, 0x7f45c9c21e18 [ORD=95]
[ID=173]
0x7f45c9c48250: i32 = shl 0x7f45c9c43800, 0x7f45c9c42fc0
[ORD=94] [ID=168]
  0x7f45c9c43800: i32 = xor 0x7f45c9c436f8, 0x7f45c9c22550
[ORD=63] [ID=163]


  0x7f45c9c42fc0: i32 = Constant<6> [ID=30]
0x7f45c9c21e18: i32 = Constant<-2097152> [ID=24]
  0x7f45c9c22340: i32 = Constant<11> [ID=26]
0x7f45c9c49a30: i32 = and 0x7f45c9c4a410, 0x7f45c9c21e18 [ORD=119]
[ID=190]
  0x7f45c9c4a410: i32 = shl 0x7f45c9c47d28, 0x7f45c9c42fc0 [ORD=118]
[ID=186]
0x7f45c9c47d28: i32 = xor 0x7f45c9c47c20, 0x7f45c9c43a10 [ORD=97]
[ID=183]
  0x7f45c9c47c20: i32 = shl 0x7f45c9c43a10, 0x7f45c9c22028 [ORD=96]
[ID=178]
0x7f45c9c43a10: i32 = or 0x7f45c9c43908, 0x7f45c9c435f0
[ORD=65] [ID=174]
  0x7f45c9c43908: i32 = srl 0x7f45c9c43800, 0x7f45c9c22340
[ORD=64] [ID=169]


  0x7f45c9c435f0: i32 = and 0x7f45c9c43dc0, 0x7f45c9c21e18
[ORD=61] [ID=151]


0x7f45c9c22028: i32 = Constant<3> [ID=25]
  0x7f45c9c43a10: i32 = or 0x7f45c9c43908, 0x7f45c9c435f0 [ORD=65]
[ID=174]
0x7f45c9c43908: i32 = srl 0x7f45c9c43800, 0x7f45c9c22340
[ORD=64] [ID=169]
  0x7f45c9c43800: i32 = xor 0x7f45c9c436f8, 0x7f45c9c22550
[ORD=63] [ID=163]


  0x7f45c9c22340: i32 = Constant<11> [ID=26]
0x7f45c9c435f0: i32 = and 0x7f45c9c43dc0, 0x7f45c9c21e18
[ORD=61] [ID=151]
  0x7f45c9c43dc0: i32 = shl 0x7f45c9c22238, 0x7f45c9c42fc0
[ORD=60] [ID=146]


  0x7f45c9c21e18: i32 = Constant<-2097152> [ID=24]
0x7f45c9c42fc0: i32 = Constant<6> [ID=30]
  0x7f45c9c21e18: i32 = Constant<-2097152> [ID=24]
  0x7f45c9c41ea8: i64 = Constant<16777215> [ID=27]
In function: Init

-- 
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/20150131/dac3fc62/attachment.html>

[Bug 79155] [Tesseract Game] Global Illumination: Medium Causes Color Distortion

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

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

--- Comment #7 from smoki  ---

 This is fixed for me in current llvm-3.7 + mesa git.

 mmstickman, you might wanna recheck this for you card and eventually to close
this bug.

-- 
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/20150131/80815ff7/attachment.html>

[PATCH v2] drm/vgem: implement virtual GEM

[Ben Widawsky]

On Fri, Jan 30, 2015 at 10:05:45AM -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace. The mmap is done using the mmap
> operation exported by other drivers.
> 
> v2: remove platform_device and do not attach to dma bufs
> 
> Reviewed-by: Stéphane Marchesin 
> Signed-off-by: Adam Jackson 
> Signed-off-by: Ben Widawsky 
> Signed-off-by: Zach Reizner 

Looks good to me.

[snip]

[PATCH] drm/rockchip: vop: power off until vop standby take effect

[Heiko Stübner]

Hi Mark,

Am Samstag, 31. Januar 2015, 16:41:38 schrieb Mark Yao:
> Vop standby will take effect end of current frame,
> if dsp_hold_valid_irq happen, it means vop standby complete.
> 
> we must wait standby complete when we want to disable aclk,
> if not, memory bus maybe dead.
> 
> Signed-off-by: Mark Yao 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76
> ++- 1 file changed, 63 insertions(+), 13
> deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index fb25836..47ea61f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -89,6 +89,7 @@ struct vop {
>   /* mutex vsync_ work */
>   struct mutex vsync_mutex;
>   bool vsync_work_pending;
> + struct completion dsp_hold_completion;
> 
>   const struct vop_data *data;
> 
> @@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
>   }
>  }
> 
> +static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
> +{
> + unsigned long flags;
> +
> + BUG_ON(!vop->is_enabled);

BUG_ON is generally not well liked in general error handling - i.e. in the
 !vop->is_enabled
bad things may happen, but this may not always be the case. And BUG_ON 
effectively kills the machine.

You could simply use a WARN_ON, so people see that something really strange is 
going on but can still try to recover things.


> +
> + spin_lock_irqsave(>irq_lock, flags);
> +
> + vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
> +DSP_HOLD_VALID_INTR_EN(1));
> +
> + spin_unlock_irqrestore(>irq_lock, flags);
> +}
> +
> +static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
> +{
> + unsigned long flags;
> +
> + BUG_ON(!vop->is_enabled);

same here

> +
> + spin_lock_irqsave(>irq_lock, flags);
> +
> + vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
> +DSP_HOLD_VALID_INTR_EN(0));
> +
> + spin_unlock_irqrestore(>irq_lock, flags);
> +}
> +
>  static void vop_enable(struct drm_crtc *crtc)
>  {
>   struct vop *vop = to_vop(crtc);


except the above
Reviewed-by: Heiko Stuebner 

[but take it with a grain of salt, as I'm still new to drm-land :-) ]


Heiko

[PATCH] drm/rockchip: fix clk enable disable mismatch in vop_crtc_mode_set

[Daniel Kurtz]

Hi Heiko,

On Sat, Jan 31, 2015 at 3:28 AM, Heiko Stübner  wrote:
> The function disables the dclk at the beginning, so don't simply return
> when an error happens, but instead enable the clock again, so that
> enable and disable calls are balanced.

This function is a bit of a disaster, and needs fixing some day.
AFAICT, the dclk_rst is actually ignored if dclk is disabled, so that
part doesn't even work.

>
> ret_clk is introduced to hold the clk_enable result and not mangle the
> original error code.
>
> Signed-off-by: Heiko Stuebner 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 04b619a..c0387f7 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -852,7 +852,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> u16 vsync_len = adjusted_mode->vsync_end - adjusted_mode->vsync_start;
> u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
> u16 vact_end = vact_st + vdisplay;
> -   int ret;
> +   int ret, ret_clk;
> uint32_t val;
>
> /*
> @@ -874,7 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> default:
> DRM_ERROR("unsupport connector_type[%d]\n",
>   vop->connector_type);
> -   return -EINVAL;
> +   ret = -EINVAL;
> +   goto out;
> };
> VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
>
> @@ -897,7 +898,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
>
> ret = vop_crtc_mode_set_base(crtc, x, y, fb);
> if (ret)
> -   return ret;
> +   goto out;
>
> /*
>  * reset dclk, take all mode config affect, so the clk would run in
> @@ -908,13 +909,14 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> reset_control_deassert(vop->dclk_rst);
>
> clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
> -   ret = clk_enable(vop->dclk);
> -   if (ret < 0) {
> -   dev_err(vop->dev, "failed to enable dclk - %d\n", ret);
> -   return ret;
> +out:
> +   ret_clk = clk_enable(vop->dclk);
> +   if (ret_clk < 0) {
> +   dev_err(vop->dev, "failed to enable dclk - %d\n", ret_clk);
> +   return ret_clk;

Doesn't this swallow ret ?  I thought the point was to still return
the original error?


> }
>
> -   return 0;
> +   return ret;
>  }
>
>  static void vop_crtc_commit(struct drm_crtc *crtc)
> --
> 2.1.1

[PATCH v2] drm/vgem: implement virtual GEM

[Rob Clark]

On Sat, Jan 31, 2015 at 1:13 PM, Ben Widawsky  wrote:
> On Sat, Jan 31, 2015 at 11:02:05AM -0500, Rob Clark wrote:
>> On Fri, Jan 30, 2015 at 1:05 PM, Zach Reizner  wrote:
>> > This patch implements the virtual GEM driver with PRIME sharing which
>> > allows vgem to import a gem object from other drivers for the purpose
>> > of mmap-ing them to userspace. The mmap is done using the mmap
>> > operation exported by other drivers.
>> >
>> > v2: remove platform_device and do not attach to dma bufs
>> >
>> > Reviewed-by: Stéphane Marchesin 
>> > Signed-off-by: Adam Jackson 
>> > Signed-off-by: Ben Widawsky 
>> > Signed-off-by: Zach Reizner 
>>
>> couple small suggestions/comments below, but with those addressed,
>>
>> Reviewed-by: Rob Clark 
>>
>> > ---
>> >  drivers/gpu/drm/Kconfig |   9 +
>> >  drivers/gpu/drm/Makefile|   1 +
>> >  drivers/gpu/drm/vgem/Makefile   |   4 +
>> >  drivers/gpu/drm/vgem/vgem_dma_buf.c |  96 +
>> >  drivers/gpu/drm/vgem/vgem_drv.c | 390 
>> > 
>> >  drivers/gpu/drm/vgem/vgem_drv.h |  57 ++
>> >  6 files changed, 557 insertions(+)
>> >  create mode 100644 drivers/gpu/drm/vgem/Makefile
>> >  create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
>> >  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
>> >  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
>> >
>>
>> [snip]
>>
>> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
>> > b/drivers/gpu/drm/vgem/vgem_drv.c
>> > new file mode 100644
>> > index 000..e20f4a4
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> > @@ -0,0 +1,390 @@
>> > +/*
>> > + * Copyright 2011 Red Hat, Inc.
>> > + * Copyright © 2014 The Chromium OS Authors
>> > + *
>> > + * Permission is hereby granted, free of charge, to any person obtaining a
>> > + * copy of this software and associated documentation files (the 
>> > "Software")
>> > + * to deal in the software without restriction, including without 
>> > limitation
>> > + * on the rights to use, copy, modify, merge, publish, distribute, sub
>> > + * license, and/or sell copies of the Software, and to permit persons to 
>> > whom
>> > + * them Software is furnished to do so, subject to the following 
>> > conditions:
>> > + *
>> > + * The above copyright notice and this permission notice (including the 
>> > next
>> > + * paragraph) shall be included in all copies or substantial portions of 
>> > the
>> > + * Software.
>> > + *
>> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
>> > EXPRESS OR
>> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
>> > MERCHANTIBILITY,
>> > + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT 
>> > SHALL
>> > + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, 
>> > WHETHER
>> > + * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR 
>> > IN
>> > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
>> > SOFTWARE.
>> > + *
>> > + * Authors:
>> > + * Adam Jackson 
>> > + * Ben Widawsky 
>> > + */
>> > +
>> > +/**
>> > + * This is vgem, a (non-hardware-backed) GEM service.  This is used by 
>> > Mesa's
>> > + * software renderer and the X server for efficient buffer sharing.
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "vgem_drv.h"
>> > +
>> > +#define DRIVER_NAME"vgem"
>> > +#define DRIVER_DESC"Virtual GEM provider"
>> > +#define DRIVER_DATE"20120112"
>> > +#define DRIVER_MAJOR   1
>> > +#define DRIVER_MINOR   0
>> > +
>> > +void vgem_gem_put_pages(struct drm_vgem_gem_object *obj)
>> > +{
>> > +   int num_pages = obj->base.size / PAGE_SIZE;
>> > +   int i;
>> > +
>> > +   for (i = 0; i < num_pages; i++) {
>> > +   if (obj->pages[i] == NULL)
>> > +   break;
>>
>> seems like other than this break statement, you could use
>> drm_gem_put_pages()..  not entirely sure why you'd encounter a null
>> page, but if there is a legit reason for that, then just add the check
>> in drm_gem_put_pages() (plus maybe a comment) and use that..
>>
>
> First, this code predated drm_gem_put_pages, so it was probably just an
> oversight that a consolidated function existed. As for the NULL, it's because
> the cleanup of failed vgem get_pages() just calls vgem put_pages() (you can't
> have sparsely populated entries, but the last n pointers can be NULL). If the
> helpers just dtrt, then it should use that.

yeah, ok, that makes sense..

The helpers dtrt.. drm_gem_get_pages() cleans up properly if it fails
part way through.  So should be a drop-in replacement, and make the
new driver that much smaller :-)

BR,
-R

>
>> > +   page_cache_release(obj->pages[i]);
>> > +   }
>> > +
>> > +   drm_free_large(obj->pages);
>> > +   obj->pages = NULL;
>> > +}
>> > +
>> > +static void vgem_gem_free_object(struct drm_gem_object *obj)
>> > +{
>> > +   struct 

[PATCH v2 0/12] Those patches is used for dw_hdmi audio support

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:23:51AM -0500, Yakir Yang wrote:
> We found Designware hdmi driver only support audio clock config, we can not 
> play sound through it.
> To add Designware HDMI Audio support, we make those patch set:
>  1): modify n/cts config order, according to dw_hdmi document.
>  2): add Audio Sample Channel Status config interfaces to dw_hdmi driver.
>  3): add audio support for more display resolutions(eg. 800x600).
>  4): add audio support for No-CEA display resolutions.
>  5): fixed dw_hdmi irq bug, add irq control to suspend/resume interfaces.
>  6): add suspend/resume callback for dw_hdmi rockchip driver.
>  7): filter interlace mode in rockchip vop driver.
>  8): add hdmi audio config interfaces to dw_hdmi driver.
>  9): creat "dw_hdmi-audio" platform device in dw_hdmi driver.
> 10): add codec driver for hdmi audio, callback dw_hdmi audio config functions.
> 11): add sound driver for hdmi audio, creat hdmi audio sound card.
> 12): add dt-bings file and add hdmi_audio node to corresponding dt file.

I think the overall issue with this patch is working out how to support
both the iMX6 version of this IP, and the Rockchip version of the IP.

These two hardware IPs seem to be configured at synthesis time with
entirely different audio architectures, which change which registers
are available, and sometimes which bits in the registers are present,
which makes it more difficult to come up with a unified audio driver.

Also, I think that it would be a good idea to start documenting which
registers are available in which versions of the IP in dw_hdmi.h,
otherwise I can see that it's going to be very easy for someone to
assume that some register or bit which is available in one IP is
present on all.

The CONFIGx_ID register values for the iMX6 SoC are:

CONFIG0_ID 0x8f
CONFIG1_ID 0x01
CONFIG2_ID 0xf2
CONFIG3_ID 0x02

CONFIG0_ID appears to contain bits which indicate whether the IP
supports I2S and SPDIF mode.  Presumably your IP has bit 4 set for I2S,
and maybe bit 5 for SPDIF?

CONFIG1_ID bit 0 indicates whether the AHB interface is present, which
is presumably zero for your IP?

CONFIG3_ID bit 0 indicates whether "generic parallel audio, GPAUD" is
present.

Could you provide (in addition to the values printed in the message I
requested in another reply) the values of the CONFIGx_ID registers
please, and whether any of the bits in there are documented as being
applicable to audio.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:32:23AM -0500, Yakir Yang wrote:
> +static void hdmi_config_audio(struct dw_hdmi *hdmi,
> +   struct hdmi_audio_fmt *aud_fmt)
> +{
> + if (aud_fmt)
> + hdmi->aud_fmt = *aud_fmt;
> +
> + hdmi_modb(hdmi, AUDIO_CONF0_INTERFACE_II2S,
> +   AUDIO_CONF0_INTERFACE_MSK, HDMI_AUD_CONF0);
> +
> + hdmi_modb(hdmi, hdmi->aud_fmt.chan_num, AUDIO_CONF0_I2SINEN_MSK,
> +   HDMI_AUD_CONF0);
> +
> + hdmi_modb(hdmi, hdmi->aud_fmt.word_length, AUDIO_CONF1_DATWIDTH_MSK,
> +   HDMI_AUD_CONF1);
> +
> + hdmi_modb(hdmi, hdmi->aud_fmt.dai_fmt, AUDIO_CONF1_DATAMODE_MSK,
> +   HDMI_AUD_CONF1);

These registers are not defined on iMX6 SoCs, so this probably needs to be
conditionalised with the dw-hdmi IP version.

> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
> +{
> + if (hdmi->audio_enable)
> + return;
> +
> + mutex_lock(>audio_mutex);
> + hdmi->audio_enable = true;
> + hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
> + mutex_unlock(>audio_mutex);

This is racy.  The test needs to be within the mutex-protected region.

> +}
> +
> +void hdmi_audio_clk_disable(struct dw_hdmi *hdmi)
> +{
> + if (!hdmi->audio_enable)
> + return;
> +
> + mutex_lock(>audio_mutex);
> + hdmi_modb(hdmi, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
> +   HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
> + hdmi->audio_enable = false;
> + mutex_unlock(>audio_mutex);

Ditto.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 07/12] drm: bridge/dw_hdmi: enable audio support for No-CEA display resolutions

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:31:33AM -0500, Yakir Yang wrote:
> If the monitor support audio, so we should support audio for it, even if
> the display resolution is No-CEA mode.

I can't find where it was documented at the moment, but I seem to remember
reading somewhere that the iMX6 SoC version of this IP doesn't support
audio with non-CEA modes - though, maybe that's a result of the limited
TMDS clocks which are supported.

This is a change which will need testing on iMX6.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 02/12] drm: bridge/dw_hdmi: add audio sample channel status setting

[Russell King - ARM Linux]

On Sat, Jan 31, 2015 at 06:22:19AM -0500, Yang Kuankuan wrote:
> 
> On 01/31/2015 06:08 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 30, 2015 at 06:27:10AM -0500, Yakir Yang wrote:
> >>When transmitting IEC60985 linear PCM audio, we configure the
> >>Aduio Sample Channel Status information of all the channel
> >>status bits in the IEC60958 frame.
> >>
> >>Signed-off-by: Yakir Yang 
> >>---
> >>Changes in v2:
> >>- Add audio sample channel status setting
> >See my comments on
> >
> >"[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting"
> >
> >sent immediately prior to this series.  This patch appears to be a copy of
> >that patch.
> >
> "[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting"
> 
>  should not be send, it's my mistaken, i will remove it.

Please see my comments on the above patch for comments on _this_ patch.
All my comments on the mistakenly sent 01/11 also apply to 02/12.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 06/12] drm: bridge/dw_hdmi: add audio support for more display resolutions

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:30:39AM -0500, Yakir Yang wrote:
> Add more n/cts values, in that case we can support audio for more
> display resolutions (128 * SampleRate = PixelClock * N / CTS).

Where do these come from?  The iMX6 manuals give the set which are
already in the driver, and says that others are not supported - to
quote...

"Table below shows the CTS and N values for the supported standard.
All other TMDS clocks are not supported, the TMDS clocks divided or
multiplied by 1,001 coefficients are not supported."

and the table lists values for TMDS clocks of 25.2, 27, 54, 74.25,
148.5 and 297MHz.

This will need to be tested on iMX6 to validate whether it works.
If it doesn't work, we need to conditionalise the new TMDS clocks
with the IP version.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 04/12] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:28:59AM -0500, Yakir Yang wrote:
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2:
> - Add suspend/resume support for dw_hdmi_rockchip driver
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index d236faa..2f8bacb 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -323,9 +323,22 @@ static int dw_hdmi_rockchip_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> +static int dw_hdmi_rockchip_suspend(struct platform_device *pdev,
> + pm_message_t state)
> +{
> + return dw_hdmi_suspend(pdev, state);
> +}
> +
> +static int dw_hdmi_rockchip_resume(struct platform_device *pdev)
> +{
> + return dw_hdmi_resume(pdev);
> +}
> +
>  static struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
>   .probe  = dw_hdmi_rockchip_probe,
>   .remove = dw_hdmi_rockchip_remove,
> + .resume = dw_hdmi_rockchip_resume,
> + .suspend = dw_hdmi_rockchip_suspend,
>   .driver = {
>   .name = "dwhdmi-rockchip",
>   .of_match_table = dw_hdmi_rockchip_dt_ids,

Using the power management operations (setting the .pm member in
the embedded struct device_driver) is preferred over using the
.resume and .suspend methods.

Please update this patch to use the preferred method.  Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 03/12] drm: bridge/dw_hdmi: add irq control to suspend/resume

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:28:00AM -0500, Yakir Yang wrote:
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 2ded957..13f26af 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -1745,6 +1745,49 @@ void dw_hdmi_unbind(struct device *dev, struct device 
> *master, void *data)
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
>  
> +int dw_hdmi_suspend(struct platform_device *pdev, pm_message_t state)
> +{
...
> +int dw_hdmi_resume(struct platform_device *pdev)
> +{

Please arrange for these functions to take a struct device rather than
a struct platform_device.  The generic part of this driver should remain
bus-agnostic.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 02/12] drm: bridge/dw_hdmi: add audio sample channel status setting

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:27:10AM -0500, Yakir Yang wrote:
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2:
> - Add audio sample channel status setting

See my comments on

"[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting"

sent immediately prior to this series.  This patch appears to be a copy of
that patch.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 01/12] drm: bridge/dw_hdmi: adjust n/cts setting order

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:25:30AM -0500, Yakir Yang wrote:
> For Designerware HDMI, the following write sequence is recommended:
> 1. aud_n3 (set bit ncts_atomic_write if desired)
> 2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
> 3. aud_cts2 (required in CTS_manual)
> 4. aud_cts1 (required in CTS_manual)
> 5. aud_n3 (bit ncts_atomic_write with same value as in step 1.)
> 6. aud_n2
> 7. aud_n1
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2:
> - adjust n/cts setting order
> 
>  drivers/gpu/drm/bridge/dw_hdmi.c | 37 +
>  drivers/gpu/drm/bridge/dw_hdmi.h |  6 ++
>  2 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index cd6a706..423addc 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -177,26 +177,31 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
> data, unsigned int reg,
>   hdmi_modb(hdmi, data << shift, mask, reg);
>  }
>  
> -static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
> -  unsigned int value)
> +static void hdmi_regenerate_n_cts(struct dw_hdmi *hdmi, unsigned int n,
> +   unsigned int cts)
>  {
> - hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
> - hdmi_writeb(hdmi, (value >> 8) & 0xff, HDMI_AUD_N2);
> - hdmi_writeb(hdmi, (value >> 16) & 0x0f, HDMI_AUD_N3);
> + /* set ncts_atomic_write */
> + hdmi_modb(hdmi, HDMI_AUD_N3_NCTS_ATOMIC_WRITE_SET,
> +   HDMI_AUD_N3_NCTS_ATOMIC_WRITE_MASK, HDMI_AUD_N3);

Bits 7:4 of N3 are marked up in the iMX6 manuals as "reserved".  We need
some clarification from FSL whether this matters, but at the moment my
opinion on that is this should be conditionalised against the IP version.

Setting bit 7 as you do above may not cause any harm on iMX6, but on the
other hand, we shouldn't be setting bits which are marked as reserved.

> +
> + /* set cts manual */
> + hdmi_modb(hdmi, HDMI_AUD_CTS3_CTS_MANUAL,
> +   HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
>  
>   /* nshift factor = 0 */
>   hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
> -}
> -
> -static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
> -{
> - /* Must be set/cleared first */
> - hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
>  
> - hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
> + /* set cts values */
> + hdmi_modb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK),
> +   HDMI_AUD_CTS3_AUDCTS19_16_MASK, HDMI_AUD_CTS3);
>   hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
> - hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> - HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
> + hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
> +
> + /* set n values */
> + hdmi_modb(hdmi, (n >> 16) & HDMI_AUD_N3_AUDN19_16_MASK,
> +   HDMI_AUD_N3_AUDN19_16_MASK, HDMI_AUD_N3);
> + hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
> + hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);

This is definitely moving things in the right direction.  However, I would
ask that the read-modify-writes to HDMI_AUD_N3 are open-coded rather than
using hdmi_modb(), and consolidated.  We really don't need to keep
re-reading this register.

I'd also like to check that this does not cause a regression on iMX6 SoCs
with my audio driver; I'm aware that there are some issues to do with how
these registers are written, and the published errata workaround in the
iMX6 errata documentation doesn't seem to always work.

>  }
>  
>  static unsigned int hdmi_compute_n(unsigned int freq, unsigned long 
> pixel_clk,
> @@ -355,8 +360,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
>   __func__, hdmi->sample_rate, hdmi->ratio,
>   pixel_clk, clk_n, clk_cts);
>  
> - hdmi_set_clock_regenerator_n(hdmi, clk_n);
> - hdmi_regenerate_cts(hdmi, clk_cts);
> + hdmi_regenerate_n_cts(hdmi, clk_n, clk_cts);
> + hdmi_set_schnl(hdmi);

I'd prefer the addition of hdmi_set_schnl() to be in the patch which adds
that new function.  However, as I mentioned in my reply to that patch,
other versions of this IP do not have these registers, and it may not be
safe to write to them.  We need to find a way to know whether this IP
has the AHB DMA support or not and act accordingly.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] drm/vgem: implement virtual GEM

[Rob Clark]

On Fri, Jan 30, 2015 at 1:05 PM, Zach Reizner  wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace. The mmap is done using the mmap
> operation exported by other drivers.
>
> v2: remove platform_device and do not attach to dma bufs
>
> Reviewed-by: Stéphane Marchesin 
> Signed-off-by: Adam Jackson 
> Signed-off-by: Ben Widawsky 
> Signed-off-by: Zach Reizner 

couple small suggestions/comments below, but with those addressed,

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/Kconfig |   9 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/vgem/Makefile   |   4 +
>  drivers/gpu/drm/vgem/vgem_dma_buf.c |  96 +
>  drivers/gpu/drm/vgem/vgem_drv.c | 390 
> 
>  drivers/gpu/drm/vgem/vgem_drv.h |  57 ++
>  6 files changed, 557 insertions(+)
>  create mode 100644 drivers/gpu/drm/vgem/Makefile
>  create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
>  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
>  create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
>

[snip]

> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> new file mode 100644
> index 000..e20f4a4
> --- /dev/null
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -0,0 +1,390 @@
> +/*
> + * Copyright 2011 Red Hat, Inc.
> + * Copyright © 2014 The Chromium OS Authors
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software")
> + * to deal in the software without restriction, including without limitation
> + * on the rights to use, copy, modify, merge, publish, distribute, sub
> + * license, and/or sell copies of the Software, and to permit persons to whom
> + * them Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER
> + * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Adam Jackson 
> + * Ben Widawsky 
> + */
> +
> +/**
> + * This is vgem, a (non-hardware-backed) GEM service.  This is used by Mesa's
> + * software renderer and the X server for efficient buffer sharing.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "vgem_drv.h"
> +
> +#define DRIVER_NAME"vgem"
> +#define DRIVER_DESC"Virtual GEM provider"
> +#define DRIVER_DATE"20120112"
> +#define DRIVER_MAJOR   1
> +#define DRIVER_MINOR   0
> +
> +void vgem_gem_put_pages(struct drm_vgem_gem_object *obj)
> +{
> +   int num_pages = obj->base.size / PAGE_SIZE;
> +   int i;
> +
> +   for (i = 0; i < num_pages; i++) {
> +   if (obj->pages[i] == NULL)
> +   break;

seems like other than this break statement, you could use
drm_gem_put_pages()..  not entirely sure why you'd encounter a null
page, but if there is a legit reason for that, then just add the check
in drm_gem_put_pages() (plus maybe a comment) and use that..

> +   page_cache_release(obj->pages[i]);
> +   }
> +
> +   drm_free_large(obj->pages);
> +   obj->pages = NULL;
> +}
> +
> +static void vgem_gem_free_object(struct drm_gem_object *obj)
> +{
> +   struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
> +
> +   drm_gem_free_mmap_offset(obj);
> +
> +   if (vgem_obj->use_dma_buf && obj->dma_buf) {
> +   dma_buf_put(obj->dma_buf);
> +   obj->dma_buf = NULL;
> +   }
> +
> +   drm_gem_object_release(obj);
> +
> +   if (vgem_obj->pages)
> +   vgem_gem_put_pages(vgem_obj);
> +
> +   vgem_obj->pages = NULL;
> +
> +   kfree(vgem_obj);
> +}
> +
> +int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
> +{
> +   struct address_space *mapping;
> +   gfp_t gfpmask = GFP_KERNEL;
> +   int num_pages, i, ret = 0;
> +
> +   if (obj->pages || obj->use_dma_buf)
> +   return 0;
> +
> +   num_pages = obj->base.size / PAGE_SIZE;
> +   obj->pages = drm_malloc_ab(num_pages, sizeof(struct page *));
> +   if (obj->pages == NULL)
> +   return -ENOMEM;
> +
> +   mapping = obj->base.filp->f_path.dentry->d_inode->i_mapping;

again, seems like you could use drm_gem_get_pages().. although you get
the mapping in a slightly different way.. not 

[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 06:19:46AM -0500, Yakir Yang wrote:
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.

It appears that the iMX6 version of the DW-HDMI IP does not have these
registers.  These registers are quite possibly only available on IPs
which do not have the built-in AHB DMA, since the channel status bits
are encoded into the samples in memory.

Can you report what identifying information your version of this IP
outputs please?  On iMX6, I get:

dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1

for iMX6Quad, and for iMX6Solo:

dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0x1a:0xa0:0xc1

Thanks.

Further comments below.

> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 423addc..2ded957 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -204,6 +204,47 @@ static void hdmi_regenerate_n_cts(struct dw_hdmi *hdmi, 
> unsigned int n,
>   hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
>  }
>  
> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> +{
> + u8 aud_schnl_samplerate;
> +
> + switch (hdmi->sample_rate) {
> + case 32000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> + break;
> + case 44100:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + case 48000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> + break;
> + case 88200:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> + break;
> + case 96000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> + break;
> + case 176400:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> + break;
> + case 192000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> + break;
> + case 768000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> + break;
> + default:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + }
> +
> + /* set channel status register */
> + hdmi_modb(hdmi, aud_schnl_samplerate,
> +   HDMI_FC_AUDSCHNLS7_SMPRATE_MASK, HDMI_FC_AUDSCHNLS7);
> + hdmi_writeb(hdmi, ((~aud_schnl_samplerate) << 4) | 0x2,
> + HDMI_FC_AUDSCHNLS8);
> +}
> +

You should not split patches up like this - this patch introduces a new
static function, which is never used until a subsequent patch.  If this
patch were to be merged, it would introduce a new build warning.

Please ensure that each patch in the series can be applied in sequence
without causing a regression.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/rockchip: fix clk enable disable mismatch in vop_crtc_mode_set

[Heiko Stübner]

Am Samstag, 31. Januar 2015, 13:43:23 schrieb Daniel Kurtz:
> Hi Heiko,
> 
> On Sat, Jan 31, 2015 at 3:28 AM, Heiko Stübner  wrote:
> > The function disables the dclk at the beginning, so don't simply return
> > when an error happens, but instead enable the clock again, so that
> > enable and disable calls are balanced.
> 
> This function is a bit of a disaster, and needs fixing some day.
> AFAICT, the dclk_rst is actually ignored if dclk is disabled, so that
> part doesn't even work.
> 
> > ret_clk is introduced to hold the clk_enable result and not mangle the
> > original error code.
> > 
> > Signed-off-by: Heiko Stuebner 
> > 
> > ---
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 04b619a..c0387f7
> > 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -852,7 +852,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> > 
> > u16 vsync_len = adjusted_mode->vsync_end -
> > adjusted_mode->vsync_start;
> > u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
> > u16 vact_end = vact_st + vdisplay;
> > 
> > -   int ret;
> > +   int ret, ret_clk;
> > 
> > uint32_t val;
> > 
> > /*
> > 
> > @@ -874,7 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> > 
> > default:
> > DRM_ERROR("unsupport connector_type[%d]\n",
> > 
> >   vop->connector_type);
> > 
> > -   return -EINVAL;
> > +   ret = -EINVAL;
> > +   goto out;
> > 
> > };
> > VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
> > 
> > @@ -897,7 +898,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> > 
> > ret = vop_crtc_mode_set_base(crtc, x, y, fb);
> > if (ret)
> > 
> > -   return ret;
> > +   goto out;
> > 
> > /*
> > 
> >  * reset dclk, take all mode config affect, so the clk would run
> >  in
> > 
> > @@ -908,13 +909,14 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> > 
> > reset_control_deassert(vop->dclk_rst);
> > 
> > clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
> > 
> > -   ret = clk_enable(vop->dclk);
> > -   if (ret < 0) {
> > -   dev_err(vop->dev, "failed to enable dclk - %d\n", ret);
> > -   return ret;
> > +out:
> > +   ret_clk = clk_enable(vop->dclk);
> > +   if (ret_clk < 0) {
> > +   dev_err(vop->dev, "failed to enable dclk - %d\n",
> > ret_clk);
> > +   return ret_clk;
> 
> Doesn't this swallow ret ?  I thought the point was to still return
> the original error?

I think if even the reenabling of the clock fails, there must be something 
_really_ wrong with the system [enabled before and all] - so if this also 
returns an error after the core functionality failed already, it doesn't 
really matter anymore which error we return :-) .

The original point was to not overwrite the actual error (in ret) in the case 
where clk_enable simply returns 0 .


Heiko

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #24 from Christian König  ---
(In reply to Chernovsky Oleg from comment #23)
> Wow! Pls forget my last comment completely.
> 
> Just tried to watch H264 video and it was slow as hell :(

Which is the espected result if you don't setup the clocks :)

In this case the UVD block runs with the default 100Mhz instead of the desired
400,500,900 or whatever the power tables say we should programm it to. At least
we now knew that the input frequency works well.

Now take a look at si_set_uvd_clocks in si.c. Especially try to figure out if
the first or the second call to radeon_uvd_send_upll_ctlreq fails.

Additional to that please install radeontool and get me the content of the
CG_UPLL_* registers. E.g. I need the output of:

radeontool regmatch 0x634
radeontool regmatch 0x638
radeontool regmatch 0x63c
radeontool regmatch 0x644
radeontool regmatch 0x648
radeontool regmatch 0x650

Thanks,
Christian.

-- 
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/20150131/33d56756/attachment.html>

[PATCH 0/5] drm: add missing dependencies

[Dave Airlie]

On 28 January 2015 at 23:48, Arnd Bergmann  wrote:
> I did lots of randconfig tests over time, which resulted in many patches,
> five of which are for drm. In each of these cases, the Kconfig dependencies
> are incomplete, which can lead to broken builds, and specifying the
> complete dependencies solves it.
>
> The patches are all independent from one another and solve separate
> issues. Please apply.

Thanks Arnd, I've taken these all into drm-next in case any is wondering.

Dave.

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

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

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

--- Comment #12 from Christian König  ---
(In reply to Mike S. from comment #11)
> Thanks for the info. It hasn't happened again so far.
> 
> > ... you are driving the PLL so close to the edge ...
> Can you please explain what you mean? Are you saying that the higher fb_div
> & ref_div are pushing the PLL harder or faster?

If you want details you should probably read them up on Wikipedia, but I will
try to explain it in a few sentences.

The basic problem is how to generate a stable but still programmable frequency
in electronics.

On the one hand you have crystals which are usually very stable over a long
period of time, but to change the frequency of a crystal you would need to
change it's size and/or the material it is made of. Clearly not something you
can do with software.

On the other hand you have voltage controllable oscillators (VCO), which have
the nice feature that you can push a certain voltage into them and get a
certain frequency in return. Problem with those is that they are not
temperature stable, e.g. you set up a certain voltage to get 100Mhz and after a
while the electronics has warmed up and you suddenly get 101Mhz or 99Mhz or
something like this.

The solution is a PLL, it compares a very stable input frequency to a frequency
generated with a VCO and based on the difference adjusts the input voltage of
the VCO. This way the VCO frequency is slowly adjusted to the stable input
frequency and also stable over time when the electronics warms up.

Imagine that you now put a counter between the VCO output and the comparator
input that counts to 3 before forwarding the VCO frequency to the comparator.
This way when you input a frequency of 100Mhz you get 300Mhz as output
frequency. This counter is easily adjustable with software and called the
feedback divider.

So in the end you've got 300Mhz. But what do we do when for example we want
150Mhz? For this the electronics got a so called post divider it's also
software configurable and when for example when you have 300Mhz VCO frequency
and set the divider to 2 you get 150Mhz at the PLL output.

The voltage given as input to the VCO needs to be in certain limits. The upper
limit is easily understandable imagine that you push 20V into a 5V circuit all
you usually get is blue smoke and useless electronics. The lower limit usually
isn't so easily explainable, just keep in mind that the electronics need a
certain voltage to start up. More rarely you also got voltage gaps where the
VCO won't produce a stable output etc...

So to stay within those limits you add a third divider which is put between the
input frequency and the comparator. This divider is called the reference
divider.

Driving the PLL at the edge now means that at some point the VCO is to close to
one of it's limits. E.g. when it startup the VCO usually doesn't match the
input frequency at all and because of this the voltage input jumps around quite
a bit. So it sometimes works and sometimes doesn't. Or it initially works but
after the electronics has warmed up the VCO is suddenly out of range etc
etc

Maybe that were a few more sentences than I expected, hopefully it was still
understandable.

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

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

[Yang Kuankuan]

On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:32:23AM -0500, Yakir Yang wrote:
>> +static void hdmi_config_audio(struct dw_hdmi *hdmi,
>> +  struct hdmi_audio_fmt *aud_fmt)
>> +{
>> +if (aud_fmt)
>> +hdmi->aud_fmt = *aud_fmt;
>> +
>> +hdmi_modb(hdmi, AUDIO_CONF0_INTERFACE_II2S,
>> +  AUDIO_CONF0_INTERFACE_MSK, HDMI_AUD_CONF0);
>> +
>> +hdmi_modb(hdmi, hdmi->aud_fmt.chan_num, AUDIO_CONF0_I2SINEN_MSK,
>> +  HDMI_AUD_CONF0);
>> +
>> +hdmi_modb(hdmi, hdmi->aud_fmt.word_length, AUDIO_CONF1_DATWIDTH_MSK,
>> +  HDMI_AUD_CONF1);
>> +
>> +hdmi_modb(hdmi, hdmi->aud_fmt.dai_fmt, AUDIO_CONF1_DATAMODE_MSK,
>> +  HDMI_AUD_CONF1);
> These registers are not defined on iMX6 SoCs, so this probably needs to be
> conditionalised with the dw-hdmi IP version.
okay, i will fixed what you have suggest in cover-letter first.

Thanks. : )
>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
>> +{
>> +if (hdmi->audio_enable)
>> +return;
>> +
>> +mutex_lock(>audio_mutex);
>> +hdmi->audio_enable = true;
>> +hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>> +mutex_unlock(>audio_mutex);
> This is racy.  The test needs to be within the mutex-protected region.
This function will be called by other driver (dw-hdmi-audio), both 
modify the variable "hdmi->audio_enable", so i add the mutex-protected.
>
>> +}
>> +
>> +void hdmi_audio_clk_disable(struct dw_hdmi *hdmi)
>> +{
>> +if (!hdmi->audio_enable)
>> +return;
>> +
>> +mutex_lock(>audio_mutex);
>> +hdmi_modb(hdmi, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>> +  HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>> +hdmi->audio_enable = false;
>> +mutex_unlock(>audio_mutex);
> Ditto.
>

[Bug 88456] Brütal Legend lockup

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

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

Laurent carlier  changed:

   What|Removed |Added

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

--- Comment #6 from Laurent carlier  ---
No more lockups here anymore

-- 
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/20150131/530adfa6/attachment.html>

[PATCH v2 06/12] drm: bridge/dw_hdmi: add audio support for more display resolutions

[Yang Kuankuan]

On 01/31/2015 06:20 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:30:39AM -0500, Yakir Yang wrote:
>> Add more n/cts values, in that case we can support audio for more
>> display resolutions (128 * SampleRate = PixelClock * N / CTS).
> Where do these come from?  The iMX6 manuals give the set which are
> already in the driver, and says that others are not supported - to
> quote...
>
> "Table below shows the CTS and N values for the supported standard.
> All other TMDS clocks are not supported, the TMDS clocks divided or
> multiplied by 1,001 coefficients are not supported."
>
> and the table lists values for TMDS clocks of 25.2, 27, 54, 74.25,
> 148.5 and 297MHz.
>
> This will need to be tested on iMX6 to validate whether it works.
> If it doesn't work, we need to conditionalise the new TMDS clocks
> with the IP version.
>
I just want to add audio support for some No-CEA display resolutions, 
and actually it can works on rk3288 platform.
If it can not work on iMX6 platform, i will add IP verison select in 
next version v3.

Thanks.  : )

[PATCH v2 04/12] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

[Yang Kuankuan]

On 01/31/2015 06:13 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:28:59AM -0500, Yakir Yang wrote:
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v2:
>> - Add suspend/resume support for dw_hdmi_rockchip driver
>>
>>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> index d236faa..2f8bacb 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -323,9 +323,22 @@ static int dw_hdmi_rockchip_remove(struct 
>> platform_device *pdev)
>>  return 0;
>>   }
>>   
>> +static int dw_hdmi_rockchip_suspend(struct platform_device *pdev,
>> +pm_message_t state)
>> +{
>> +return dw_hdmi_suspend(pdev, state);
>> +}
>> +
>> +static int dw_hdmi_rockchip_resume(struct platform_device *pdev)
>> +{
>> +return dw_hdmi_resume(pdev);
>> +}
>> +
>>   static struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
>>  .probe  = dw_hdmi_rockchip_probe,
>>  .remove = dw_hdmi_rockchip_remove,
>> +.resume = dw_hdmi_rockchip_resume,
>> +.suspend = dw_hdmi_rockchip_suspend,
>>  .driver = {
>>  .name = "dwhdmi-rockchip",
>>  .of_match_table = dw_hdmi_rockchip_dt_ids,
> Using the power management operations (setting the .pm member in
> the embedded struct device_driver) is preferred over using the
> .resume and .suspend methods.
>
> Please update this patch to use the preferred method.  Thanks.
>
Okay, I will fixed it in next version v3.

Thanks. : )

[PATCH v2 02/12] drm: bridge/dw_hdmi: add audio sample channel status setting

[Yang Kuankuan]

On 01/31/2015 06:08 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:27:10AM -0500, Yakir Yang wrote:
>> When transmitting IEC60985 linear PCM audio, we configure the
>> Aduio Sample Channel Status information of all the channel
>> status bits in the IEC60958 frame.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v2:
>> - Add audio sample channel status setting
> See my comments on
>
> "[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting"
>
> sent immediately prior to this series.  This patch appears to be a copy of
> that patch.
>
"[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting"

  should not be send, it's my mistaken, i will remove it.

Thanks.  : )

[PATCH v2 03/12] drm: bridge/dw_hdmi: add irq control to suspend/resume

[Yang Kuankuan]

On 01/31/2015 06:11 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:28:00AM -0500, Yakir Yang wrote:
>> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
>> b/drivers/gpu/drm/bridge/dw_hdmi.c
>> index 2ded957..13f26af 100644
>> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
>> @@ -1745,6 +1745,49 @@ void dw_hdmi_unbind(struct device *dev, struct device 
>> *master, void *data)
>>   }
>>   EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
>>   
>> +int dw_hdmi_suspend(struct platform_device *pdev, pm_message_t state)
>> +{
> ...
>> +int dw_hdmi_resume(struct platform_device *pdev)
>> +{
> Please arrange for these functions to take a struct device rather than
> a struct platform_device.  The generic part of this driver should remain
> bus-agnostic.
>
> Thanks.
okay, is it good to replace "struct platform_device" with "struct device" ?

Thanks : )

[PATCH 01/11] drm: bridge/dw_hdmi: add audio sample channel status setting

[Yang Kuankuan]

On 01/31/2015 05:59 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2015 at 06:19:46AM -0500, Yakir Yang wrote:
>> When transmitting IEC60985 linear PCM audio, we configure the
>> Aduio Sample Channel Status information of all the channel
>> status bits in the IEC60958 frame.
> It appears that the iMX6 version of the DW-HDMI IP does not have these
> registers.  These registers are quite possibly only available on IPs
> which do not have the built-in AHB DMA, since the channel status bits
> are encoded into the samples in memory.
>
> Can you report what identifying information your version of this IP
> outputs please?  On iMX6, I get:
>
> dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
>
> for iMX6Quad, and for iMX6Solo:
>
> dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0x1a:0xa0:0xc1
>
> Thanks.
>
> Further comments below.

Here are the IP version on rk3288:
 dwhdmi-rockchip ff98.hdmi: Detected HDMI controller 
0x20:0xa:0xa0:0xc1

attache the register description:

*5.2.5.50 fc_audschnls0 to fc_audschnls8*
 When transmitting IEC60958 linear PCM audio, this registers allow 
to configure the channel status
 information of all the channel status bits in the IEC60958 frame. 
For the moment this configuration is only
 used when the I2S audio interface, General Purpose Audio (GPA), or 
AHB audio DMA (AHBAUDDMA)
 interface is active (for S/PDIF interface this information comes 
from the stream). Information configured is
 the following:
 IEC Copyright indication
 CGMS-A
 PCM audio mode
 Category code
 Source number
 Channel number for first right sample
 Channel number for second right sample
 Channel number for third right sample
 Channel number for fourth right sample
 Channel number for first left sample
 Channel number for second left sample
 Channel number for third left sample
 Channel number for fourth left sample
 Clock accuracy
 Sampling frequency
 Original sampling frequency
 Word length configuration

Thks for you reply, : )

Best Regards.
>
>> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
>> b/drivers/gpu/drm/bridge/dw_hdmi.c
>> index 423addc..2ded957 100644
>> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
>> @@ -204,6 +204,47 @@ static void hdmi_regenerate_n_cts(struct dw_hdmi *hdmi, 
>> unsigned int n,
>>  hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
>>   }
>>   
>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
>> +{
>> +u8 aud_schnl_samplerate;
>> +
>> +switch (hdmi->sample_rate) {
>> +case 32000:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
>> +break;
>> +case 44100:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
>> +break;
>> +case 48000:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
>> +break;
>> +case 88200:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
>> +break;
>> +case 96000:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
>> +break;
>> +case 176400:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
>> +break;
>> +case 192000:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
>> +break;
>> +case 768000:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
>> +break;
>> +default:
>> +aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
>> +break;
>> +}
>> +
>> +/* set channel status register */
>> +hdmi_modb(hdmi, aud_schnl_samplerate,
>> +  HDMI_FC_AUDSCHNLS7_SMPRATE_MASK, HDMI_FC_AUDSCHNLS7);
>> +hdmi_writeb(hdmi, ((~aud_schnl_samplerate) << 4) | 0x2,
>> +HDMI_FC_AUDSCHNLS8);
>> +}
>> +
> You should not split patches up like this - this patch introduces a new
> static function, which is never used until a subsequent patch.  If this
> patch were to be merged, it would introduce a new build warning.
>
> Please ensure that each patch in the series can be applied in sequence
> without causing a regression.
>
> Thanks.
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150131/96c7e293/attachment-0001.html>

[Bug 88456] Brütal Legend lockup

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

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

--- Comment #5 from Clément Guérin  ---
I can't confirm myself because I don't have access to my desktop pc, but if
someone else can confirm, I'll close this. Awesome!

Is this commit related?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=2397a721291457c146c7f4bcd48adcb3b2d979bd

-- 
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/20150131/8eca7797/attachment-0001.html>