[Bug 84106] GPU faults with Xonotic 0.7

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

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

--- Comment #3 from smoki  ---
 Reproducible on Kabini, does not happen with llvm 3.5 so it is probably
current  llvm regression.

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

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #97 from ?ukasz Krzy?ak  ---
Mesa-git with patch v4
startx output:

 X.Org X Server 1.16.0
Release Date: 2014-07-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.15.5-2-ARCH x86_64
Current Operating System: Linux pecet 3.16.2-1-ARCH #1 SMP PREEMPT Sat Sep 6
13:12:51 CEST 2014 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux
root=UUID=b02f6229-160f-4999-9979-82f4e15dacff rw quiet
Build Date: 31 July 2014  11:53:19AM

Current version of pixman: 0.32.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Sep 20 02:13:24 2014
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] Kernel modesetting enabled.

Screen stays blank and on

After kill -9 on Xorg.bin:

 [root at pecet ~]# kill -9 425[root at pecet ~]# XIO:  fatal IO error 2 (No 
such
file or directory) on X server ":0"
  after 18 requests (18 known processed) with 0 events remaining.
xset:  unable to open display ":0"
xsetroot:  unable to open display ':0'
startkde: Starting up...
xprop:  unable to open display ':0'
xprop:  unable to open display ':0'
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit4: Can not connect to the X Server.
kdeinit4: Might not terminate at end of session.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
kded4: cannot connect to X server :0
kded(476): Communication problem with  "kded" , it probably crashed.
Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message did not
receive a reply (timeout by message bus)" "

kcminit_startup: cannot connect to X server :0
unnamed app(481): Cannot connect to the X server
ksmserver: cannot connect to X server :0
startkde: Shutting down...
klauncher: Exiting on signal 1
startkde: Running shutdown scripts...
xprop:  unable to open display ':0'
xprop:  unable to open display ':0'
startkde: Done.

and monitor turns off
Dmesg output:
  243.740994] radeon :01:00.0: ring 0 stalled for more than 211963msec 
243.741009] radeon :01:00.0: GPU lockup (waiting for 0x0003
last fence id 0x0001 on ring 0)

Second run of startx causes hard hangup - monitor turns on, startx output ends
with KMS Kernel mode setting enabled, after few seconds monitor disables and
system stops responding to ssh

Mesa-git built from master with options:
./autogen.sh --prefix=/usr \ --sysconfdir=/etc \
 --with-dri-driverdir=/usr/lib/xorg/modules/dri \
 --with-gallium-drivers=radeonsi \
 --with-dri-drivers=radeon \
 --with-egl-platforms=x11,drm,wayland \
 --enable-llvm-shared-libs \
 --disable-gallium-egl \
 --disable-gallium-gbm \
 --enable-egl \
 --enable-gbm \
 --enable-gallium-llvm \
 --enable-shared-glapi \
 --enable-glx-tls \
 --enable-dri \
 --enable-glx \
 --enable-osmesa \
 --enable-gles1 \
 --enable-gles2 \
 --enable-texture-float \
 --enable-xa \
 --enable-vdpau \
 --enable-xvmc \
 --enable-dri3 \
 --enable-omx \
 --enable-opencl \
 --enable-opencl-icd \
 --with-clang-libdir=/usr/lib

-- 
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/20140919/018f708b/attachment-0001.html>

[Bug 84017] HD 4670 only works with MSI disabled

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

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

--- Comment #9 from Christoph Brill  ---
I played with the cmdline "radeon.msi" and couldn't get any of the PCI-MSI-edge
counters to show anything else than 0. No matter which value used and no matter
if any 3D operation was done.

I haven't touched "pci=nomsi". It looks like MSI is not working at all on this
chipset ...

-- 
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/20140919/0b778c29/attachment.html>

[Bug 84106] GPU faults with Xonotic 0.7

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

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

--- Comment #2 from darkbasic  ---
'relief mapping' causes the GPU faults, anyway even without this setting the
framerate still drops to 0 in some points of the benchmark

-- 
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/20140919/bee77bf1/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #96 from Tom Stellard  ---
What happens if you try only this patch:
https://bugs.freedesktop.org/attachment.cgi?id=106097

Also do you see any output when you start X?  The best way to check is to ssh
into the system and then run startx.

-- 
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/20140919/2dfcdc49/attachment.html>

[Bug 84106] GPU faults with Xonotic 0.7

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

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

--- Comment #1 from darkbasic  ---
I forgot to say you have to run Xonotic with the Phoronix Test Suite "Ultimate"
settings (which should be everything maxed out).

-- 
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/20140919/73b4eb0d/attachment.html>

[Bug 84106] New: GPU faults with Xonotic 0.7

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

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

  Priority: medium
Bug ID: 84106
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU faults with Xonotic 0.7
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: darkbasic at linuxsystems.it
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

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

I have an HD 7950 with latest graphic stack from git, including LLVM 3.6 git
from today. kernel is drm-next-3.18-wip from today
(3.17.0-rc5-drm-next-3.18-wip).
I was running some benchmarks
(http://openbenchmarking.org/result/1409197-SO-1407298SO78) while I noticed
sometimes the picture froze and then after a second or two it kept running the
benchmark ultra fast. when the benchmark finished I noticed lots of GPU faults
in dmesg: https://paste.lugons.org/show/5981/

-- 
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/20140919/81fb4dc3/attachment-0001.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #95 from ?ukasz Krzy?ak  ---
Created attachment 106563
  --> https://bugs.freedesktop.org/attachment.cgi?id=106563=edit
xorg.log with mesa-git and patch 5

-- 
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/20140919/a8a514f3/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #94 from ?ukasz Krzy?ak  ---
Created attachment 106562
  --> https://bugs.freedesktop.org/attachment.cgi?id=106562=edit
kernel logs with patch v5

-- 
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/20140919/8a25cade/attachment.html>

[BUG] nouveau regression: ext monitor dead after resume

[Ortwin Glück]

On 09/19/2014 07:01 PM, Ilia Mirkin wrote:
> Thanks! Hopefully you still have those kernels handy, as your logs got
> cut off.

Yeah, I noticed and hoped it wouldn't matter as it is mostly the boot log 
that's 
been cut off until syslog came up (it's from /var/log/messages). So 
suspend/resume cycle should be complete. But I can give it another try on 
Monday 
when I'm back in the office.

Ortwin

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #93 from ?ukasz Krzy?ak  ---
Hello
I've got Radeon HD 7870 XT running under arch linux. It works fine on catalyst
drivers, but fails on OS driver.
Without patches from this bug (patch 3&4 or 5) my computer hangs. Signal to
monitor is off and monitor suspends, logging through ssh is impossible, system
logs are cut before launching X.
After applying patch (3&4 or 5) screen goes black, but monitor doesn't go to
suspend. I can log in with ssh, after killing Xorg.bin console is visible and
operational. Aftr killing X kernel logs show 

 1868.387061] radeon :01:00.0: ring 0 stalled for more than 395470msec
[ 1868.387066] radeon :01:00.0: GPU lockup (waiting for 0x0005
last fence id 0x0001 on ring 0)
[ 1868.695731] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

Stack trace of running X shows it's waiting for some fence inside radeon dri.
I'm attaching dmesg and xorg log after starting and killing X server with patch
5.

-- 
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/20140919/c47d507a/attachment.html>

[PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 08:11 PM, Joonyoung Shim wrote:
> Hi,
> 
> On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
>> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
 The patch replaces legacy functions
 drm_plane_init() / drm_crtc_init() with
 drm_universal_plane_init() and drm_crtc_init_with_planes().
 It allows to replace fake primary plane with the real one.

 Signed-off-by: Andrzej Hajda 
 ---
 Hi Inki,

 I have tested this patch with trats board, it looks OK.
 As a side effect it should solve fb refcounting issues
 reported by me and Daniel Drake.

 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
  4 files changed, 47 insertions(+), 41 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..d2f713e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
   * Exynos specific crtc structure.
   *
   * @drm_crtc: crtc object.
 - * @drm_plane: pointer of private plane object for this crtc
   * @manager: the manager associated with this crtc
   * @pipe: a crtc index created at load() with a new crtc object creation
   *and the crtc object would be set to private->crtc array
 @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
   */
  struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
 -  struct drm_plane*plane;
struct exynos_drm_manager   *manager;
unsigned intpipe;
unsigned intdpms;
 @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
 *crtc)
  
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  
 -  exynos_plane_commit(exynos_crtc->plane);
 +  exynos_plane_commit(crtc->primary);
  
if (manager->ops->commit)
manager->ops->commit(manager);
  
 -  exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
 +  exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
  }
  
  static bool
 @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
 -  struct drm_plane *plane = exynos_crtc->plane;
 +  struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
 -  int ret;
  
/*
 * copy the mode data adjusted by mode_fixup() into crtc->mode
 @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
 */
memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
  
 -  crtc_w = crtc->primary->fb->width - x;
 -  crtc_h = crtc->primary->fb->height - y;
 +  crtc_w = fb->width - x;
 +  crtc_h = fb->height - y;
  
if (manager->ops->mode_set)
manager->ops->mode_set(manager, >mode);
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 -  if (ret)
 -  return ret;
 -
 -  plane->crtc = crtc;
 -  plane->fb = crtc->primary->fb;
 -  drm_framebuffer_reference(plane->fb);
 -
 -  return 0;
 +  return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
  struct drm_framebuffer *old_fb)
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 -  struct drm_plane *plane = exynos_crtc->plane;
 +  struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
 @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
 drm_crtc *crtc, int x, int y,
return -EPERM;
}
  
 -  crtc_w = crtc->primary->fb->width - x;
 -  crtc_h = crtc->primary->fb->height - y;
 +  crtc_w = fb->width - x;
 +  crtc_h = fb->height - y;
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 +  ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
 +  

[PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>>> The patch replaces legacy functions
>>> drm_plane_init() / drm_crtc_init() with
>>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>>> It allows to replace fake primary plane with the real one.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> Hi Inki,
>>>
>>> I have tested this patch with trats board, it looks OK.
>>> As a side effect it should solve fb refcounting issues
>>> reported by me and Daniel Drake.
>>>
>>> Regards
>>> Andrzej
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>>>  4 files changed, 47 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index b68e58f..d2f713e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>>>   * Exynos specific crtc structure.
>>>   *
>>>   * @drm_crtc: crtc object.
>>> - * @drm_plane: pointer of private plane object for this crtc
>>>   * @manager: the manager associated with this crtc
>>>   * @pipe: a crtc index created at load() with a new crtc object creation
>>>   * and the crtc object would be set to private->crtc array
>>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>>>   */
>>>  struct exynos_drm_crtc {
>>> struct drm_crtc drm_crtc;
>>> -   struct drm_plane*plane;
>>> struct exynos_drm_manager   *manager;
>>> unsigned intpipe;
>>> unsigned intdpms;
>>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
>>> *crtc)
>>>  
>>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>>  
>>> -   exynos_plane_commit(exynos_crtc->plane);
>>> +   exynos_plane_commit(crtc->primary);
>>>  
>>> if (manager->ops->commit)
>>> manager->ops->commit(manager);
>>>  
>>> -   exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>>> +   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>>>  }
>>>  
>>>  static bool
>>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>>> drm_display_mode *mode,
>>>  {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>>> -   struct drm_plane *plane = exynos_crtc->plane;
>>> +   struct drm_framebuffer *fb = crtc->primary->fb;
>>> unsigned int crtc_w;
>>> unsigned int crtc_h;
>>> -   int ret;
>>>  
>>> /*
>>>  * copy the mode data adjusted by mode_fixup() into crtc->mode
>>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
>>> struct drm_display_mode *mode,
>>>  */
>>> memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>>  
>>> -   crtc_w = crtc->primary->fb->width - x;
>>> -   crtc_h = crtc->primary->fb->height - y;
>>> +   crtc_w = fb->width - x;
>>> +   crtc_h = fb->height - y;
>>>  
>>> if (manager->ops->mode_set)
>>> manager->ops->mode_set(manager, >mode);
>>>  
>>> -   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>>> crtc_w, crtc_h,
>>> -   x, y, crtc_w, crtc_h);
>>> -   if (ret)
>>> -   return ret;
>>> -
>>> -   plane->crtc = crtc;
>>> -   plane->fb = crtc->primary->fb;
>>> -   drm_framebuffer_reference(plane->fb);
>>> -
>>> -   return 0;
>>> +   return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>>  }
>>>  
>>>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
>>> int y,
>>>   struct drm_framebuffer *old_fb)
>>>  {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> -   struct drm_plane *plane = exynos_crtc->plane;
>>> +   struct drm_framebuffer *fb = crtc->primary->fb;
>>> unsigned int crtc_w;
>>> unsigned int crtc_h;
>>> int ret;
>>> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
>>> drm_crtc *crtc, int x, int y,
>>> return -EPERM;
>>> }
>>>  
>>> -   crtc_w = crtc->primary->fb->width - x;
>>> -   crtc_h = crtc->primary->fb->height - y;
>>> +   crtc_w = fb->width - x;
>>> +   crtc_h = fb->height - y;
>>>  
>>> -   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>>> crtc_w, crtc_h,
>>> -   x, y, crtc_w, crtc_h);
>>> +   ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>>> +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>> if (ret)
>>> return ret;
>>>  
>>> @@ -279,6 +268,7 @@ 

[PATCH v3 1/5] drm/rockchip: Add basic drm driver

[Rob Clark]

On Fri, Sep 19, 2014 at 1:47 AM, Mark yao  wrote:
> diff --git a/include/uapi/drm/rockchip_drm.h b/include/uapi/drm/rockchip_drm.h
> new file mode 100644
> index 000..8f8e60e
> --- /dev/null
> +++ b/include/uapi/drm/rockchip_drm.h
> @@ -0,0 +1,97 @@
> +/*
> + *
> + * Copyright (c) Fuzhou Rockchip Electronics Co.Ltd
> + * Authors:
> + *   Mark Yao 
> + *
> + * base on exynos_drm.h
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#ifndef _UAPI_ROCKCHIP_DRM_H
> +#define _UAPI_ROCKCHIP_DRM_H
> +
> +#include 
> +
> +/**
> + * User-desired buffer creation information structure.
> + *
> + * @size: user-desired memory allocation size.
> + * @flags: user request for setting memory type or cache attributes.
> + * @handle: returned a handle to created gem object.
> + * - this handle will be set by gem module of kernel side.
> + */
> +struct drm_rockchip_gem_create {
> +   uint64_t size;
> +   uint32_t flags;
> +   uint32_t handle;
> +};
> +
> +/**
> + * A structure for getting buffer offset.
> + *
> + * @handle: a pointer to gem object created.
> + * @pad: just padding to be 64-bit aligned.
> + * @offset: relatived offset value of the memory region allocated.
> + * - this value should be set by user.
> + */
> +struct drm_rockchip_gem_map_off {
> +   uint32_t handle;
> +   uint32_t pad;
> +   uint64_t offset;
> +};
> +
> +/**
> + * A structure for mapping buffer.
> + *
> + * @handle: a handle to gem object created.
> + * @pad: just padding to be 64-bit aligned.
> + * @size: memory size to be mapped.
> + * @mapped: having user virtual address mmaped.
> + *  - this variable would be filled by rockchip gem module
> + *  of kernel side with user virtual address which is allocated
> + *  by do_mmap().
> + */
> +struct drm_rockchip_gem_mmap {
> +   uint32_t handle;
> +   uint32_t pad;
> +   uint64_t size;
> +   uint64_t mapped;
> +};

Could we do without the mmap ioctl?  It has been a source of problems
in other drivers, and the ioctl to get mmap offset, plus normal mmap()
on drm device file should be sufficient

BR,
-R


> +/**
> + * A structure to gem information.
> + *
> + * @handle: a handle to gem object created.
> + * @flags: flag value including memory type and cache attribute and
> + *  this value would be set by driver.
> + * @size: size to memory region allocated by gem and this size would
> + *  be set by driver.
> + */
> +struct drm_rockchip_gem_info {
> +   uint32_t handle;
> +   uint32_t flags;
> +   uint64_t size;
> +};
> +
> +#define DRM_ROCKCHIP_GEM_CREATE0x00
> +#define DRM_ROCKCHIP_GEM_MAP_OFFSET0x01
> +#define DRM_ROCKCHIP_GEM_MMAP  0x02
> +#define DRM_ROCKCHIP_GEM_GET   0x04
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + \
> +   DRM_ROCKCHIP_GEM_CREATE, struct drm_rockchip_gem_create)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_MAP_OFFSET  DRM_IOWR(DRM_COMMAND_BASE + \
> +   DRM_ROCKCHIP_GEM_MAP_OFFSET, struct drm_rockchip_gem_map_off)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE + \
> +   DRM_ROCKCHIP_GEM_MMAP, struct drm_rockchip_gem_mmap)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
> +   DRM_ROCKCHIP_GEM_GET, struct drm_rockchip_gem_info)
> +#endif /* _UAPI_ROCKCHIP_DRM_H */

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Fri, Sep 19, 2014 at 6:24 PM, Tomi Valkeinen  
wrote:
> On 18/09/14 08:50, Ajay kumar wrote:
>
 Why do we need a complex graph when it can be handled using a simple 
 phandle?
>>>
>>> Maybe in your case you can handle it with simple phandle. Can you
>>> guarantee that it's enough for everyone, on all platforms?
>> Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
>> this. In case of both, the phandle to bridge node is passed to the
>> exynos_dp node.
>>
>>> The point of the ports/endpoint graph is to also support more
>>> complicated scenarios. If you now create ps8622 bindings that do not
>>> support those graphs, the no one else using ps8622 can use
>>> ports/endpoint graphs either.
>>>
>>> Btw, is there an example how the bridge with these bindings is used in a
>>> board's .dts file? I couldn't find any example with a quick search. So
>>> it's unclear to me what the "simple phandle" actually is.
>> Please refer to the following link:
>> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
>> Let me know if you still think we would need to describe it as a complex 
>> graph!
>
> Yes, I think so. I'm not the DRM maintainer, though.
>
> I think we have two options:
>
> 1) Describe the video component connections with the ports/endpoints
> properly for all new display device bindings, and know that it's
> (hopefully) future proof and covers even the more complex boards that
> use the devices.
>
> or
>
> 2) Use some simple methods to describe the links, like single phandle as
> you do, knowing that we can't support more complex boards in the future.
I am not really able to understand, what's stopping us from using this
bridge on a board with "complex" display connections. To use ps8622 driver,
one needs to "attach" it to the DRM framework. For this, the DRM driver
would need the DT node for ps8622 bridge. For which I use a phandle.

If some XYZ platform wishes to pick the DT node via a different method,
they are always welcome to do it. Just because I am not specifying a
video port/endpoint in the DT binding example, would it mean that platform
cannot make use of ports in future? If that is the case, I can add something
like this:
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/panel/samsung,ld9040.txt#L61

Regards,
Ajay kumar

> I see some exynos boards already using the ports/endpoints, like
> arch/arm/boot/dts/exynos4412-trats2.dts. Why not use it for all new
> display devices?
>
>  Tomi
>
>

[BUG] nouveau regression: ext monitor dead after resume

[Ortwin Glück]

On 19.09.2014 17:58, Ilia Mirkin wrote:
> git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^

Thanks again. I confirm that Bugzilla 83550 is the same issue. I have attached 
the captured logs
there for reference.

Ortwin

[PATCH 5/5] drm/i915: remove intel_pipe_set_base()

[Gustavo Padovan]

2014-09-19 Ville Syrj?l? :

> On Thu, Sep 18, 2014 at 04:43:16PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > After some refactor intel_primary_plane_setplane() does the same
> > as intel_pipe_set_base() so we can get rid of it and replace the calls
> > with intel_primary_plane_setplane().
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 79 
> > 
> >  1 file changed, 8 insertions(+), 71 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 6c61c8f..2477587 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2763,74 +2763,6 @@ static void intel_update_pipe_size(struct intel_crtc 
> > *crtc)
> > crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
> >  }
> >  
> > -static int
> > -intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> > -   struct drm_framebuffer *fb)
> > -{
> > -   struct drm_device *dev = crtc->dev;
> > -   struct drm_i915_private *dev_priv = dev->dev_private;
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > -   enum pipe pipe = intel_crtc->pipe;
> > -   struct drm_framebuffer *old_fb = crtc->primary->fb;
> > -   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > -   struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
> > -   int ret;
> > -
> > -   if (intel_crtc_has_pending_flip(crtc)) {
> > -   DRM_ERROR("pipe is still busy with an old pageflip\n");
> > -   return -EBUSY;
> > -   }
> > -
> > -   /* no fb bound */
> > -   if (!fb) {
> > -   DRM_ERROR("No FB bound\n");
> > -   return 0;
> > -   }
> > -
> > -   if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
> > -   DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
> > - plane_name(intel_crtc->plane),
> > - INTEL_INFO(dev)->num_pipes);
> > -   return -EINVAL;
> > -   }
> > -
> > -   mutex_lock(>struct_mutex);
> > -   ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> > -   if (ret == 0)
> > -   i915_gem_track_fb(old_obj, obj,
> > - INTEL_FRONTBUFFER_PRIMARY(pipe));
> > -   mutex_unlock(>struct_mutex);
> > -   if (ret != 0) {
> > -   DRM_ERROR("pin & fence failed\n");
> > -   return ret;
> > -   }
> > -
> > -   intel_update_pipe_size(intel_crtc);
> > -
> > -   dev_priv->display.update_primary_plane(crtc, fb, x, y);
> > -
> > -   if (intel_crtc->active)
> > -   intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
> > -
> > -   crtc->primary->fb = fb;
> > -   crtc->x = x;
> > -   crtc->y = y;
> > -
> > -   if (old_fb) {
> > -   if (intel_crtc->active && old_fb != fb)
> > -   intel_wait_for_vblank(dev, intel_crtc->pipe);
> > -   mutex_lock(>struct_mutex);
> > -   intel_unpin_fb_obj(old_obj);
> > -   mutex_unlock(>struct_mutex);
> > -   }
> > -
> > -   mutex_lock(>struct_mutex);
> > -   intel_update_fbc(dev);
> > -   mutex_unlock(>struct_mutex);
> > -
> > -   return 0;
> > -}
> > -
> >  static void intel_fdi_normal_train(struct drm_crtc *crtc)
> >  {
> > struct drm_device *dev = crtc->dev;
> > @@ -9797,6 +9729,7 @@ static int intel_crtc_commit_page_flip(struct 
> > drm_crtc *crtc,
> > struct drm_framebuffer *old_fb = crtc->primary->fb;
> > struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > +   struct drm_plane *primary = crtc->primary;
> > enum pipe pipe = intel_crtc->pipe;
> > struct intel_unpin_work *work;
> > struct intel_engine_cs *ring;
> > @@ -9938,7 +9871,9 @@ free_work:
> > if (ret == -EIO) {
> >  out_hang:
> > intel_crtc_wait_for_pending_flips(crtc);
> > -   ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
> > +   ret = primary->funcs->update_plane(primary, crtc, fb,
> > +  0, 0, 0, 0,
> > +  crtc->x, crtc->y, 0, 0);
> 
> I think we want page flips to not change the current plane setup so
> these should be:
> intel_plane->crtc_x/y/w/h
> intel_plane->src_x/y/w/h

Okay.

> 
> > if (ret == 0 && event) {
> > spin_lock_irq(>event_lock);
> > drm_send_vblank_event(dev, pipe, event);
> > @@ -11475,11 +11410,13 @@ static int intel_crtc_set_config(struct 
> > drm_mode_set *set)
> >  set->x, set->y, set->fb);
> > } else if (config->fb_changed) {
> > struct intel_crtc *intel_crtc = to_intel_crtc(set->crtc);
> > +   struct drm_plane *primary = set->crtc->primary;
> >  
> > intel_crtc_wait_for_pending_flips(set->crtc);
> >  
> > -   ret = intel_pipe_set_base(set->crtc,
> > - set->x, 

[PATCH v2] drm/exynos: switch to universal plane API

[Daniel Drake]

On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda  wrote:
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> Additionally the patch leaves cleanup of crtcs to core,
> this way planes and crtcs are cleaned in correct order.
>
> Signed-off-by: Andrzej Hajda 

Thanks Andrzej! With your patch the crashes I was seeing are gone.

Daniel

[PATCH] drm/exynos: init vblank with real number of crtcs

[Daniel Vetter]

On Fri, Sep 19, 2014 at 02:57:20PM +0200, Andrzej Hajda wrote:
> Initialization of vblank with MAX_CRTC caused attempts
> to disabling vblanks for non-existing crtcs in case
> drm used fewer crtcs. The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 9b00e4e..dc4affd 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
> unsigned long flags)
>   /* init kms poll for handling hpd */
>   drm_kms_helper_poll_init(dev);
>  
> - ret = drm_vblank_init(dev, MAX_CRTC);
> - if (ret)
> - goto err_mode_config_cleanup;
> -
>   /* setup possible_clones. */
>   exynos_drm_encoder_setup(dev);
>  
> @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
> unsigned long flags)
>   /* Try to bind all sub drivers. */
>   ret = component_bind_all(dev->dev, dev);
>   if (ret)
> - goto err_cleanup_vblank;
> + goto err_mode_config_cleanup;
> +
> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc);

Hm, I wonder whether we should have a drm_mode_vblank_init which dtrt here
for kms drivers? Suggestions for a better name welcome ;-)
-Daniel

> + if (ret)
> + goto err_unbind_all;
>  
>   /* Probe non kms sub drivers and virtual display driver. */
>   ret = exynos_drm_device_subdrv_probe(dev);
>   if (ret)
> - goto err_unbind_all;
> + goto err_cleanup_vblank;
>  
>   /* force connectors detection */
>   drm_helper_hpd_irq_event(dev);
>  
>   return 0;
>  
> -err_unbind_all:
> - component_unbind_all(dev->dev, dev);
>  err_cleanup_vblank:
>   drm_vblank_cleanup(dev);
> +err_unbind_all:
> + component_unbind_all(dev->dev, dev);
>  err_mode_config_cleanup:
>   drm_mode_config_cleanup(dev);
>   drm_release_iommu_mapping(dev);
> @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
>   exynos_drm_fbdev_fini(dev);
>   drm_kms_helper_poll_fini(dev);
>  
> - component_unbind_all(dev->dev, dev);
>   drm_vblank_cleanup(dev);
> + component_unbind_all(dev->dev, dev);
>   drm_mode_config_cleanup(dev);
>   drm_release_iommu_mapping(dev);
>  
> -- 
> 1.9.1
> 

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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen]

On 19/09/14 16:59, Ajay kumar wrote:

> I am not really able to understand, what's stopping us from using this
> bridge on a board with "complex" display connections. To use ps8622 driver,
> one needs to "attach" it to the DRM framework. For this, the DRM driver

Remember that when we talk about DT bindings, there's no such thing as
DRM. We talk about hardware. The same bindings need to work on any
operating system.

> would need the DT node for ps8622 bridge. For which I use a phandle.

A complex one could be for example a case where you have two different
panels connected to ps8622, and you can switch between the two panels
with, say, a gpio. How do you present that with a simple phandle?

In the exynos5420-peach-pit.dts, which you linked earlier, I see a
"panel" property in the ps8625 node. That's missing from the bindings in
this patch. Why is that? How is the panel linked in this version?

> If some XYZ platform wishes to pick the DT node via a different method,
> they are always welcome to do it. Just because I am not specifying a
> video port/endpoint in the DT binding example, would it mean that platform
> cannot make use of ports in future? If that is the case, I can add something

All the platforms share the same bindings for ps8622. If you now specify
that ps8622 bindings use a simple phandle, then anyone who uses ps8622
should support that.

Of course the bindings can be extended in the future. In that case the
drivers need to support both the old and the new bindings, which is
always a hassle.

Generally speaking, I sense that we have different views of how display
devices and drivers are structured. You say "If some XYZ platform wishes
to pick the DT node via a different method, they are always welcome to
do it.". This sounds to me that you see the connections between display
devices as something handled by a platform specific driver.

I, on the other hand, see connections between display devices as common
properties.

Say, we could have a display board, with a panel and an encoder and
maybe some other components, which takes parallel RGB as input. The same
display board could as well be connected to an OMAP board or to an
Exynos board.

I think the exact same display-board.dtsi file, which describes the
devices and connections in the display board, should be usable on both
OMAP and Exynos platforms. This means we need to have a common way to
describe video devices, just as we have for other things.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140919/e1a5e59f/attachment-0001.sig>

[alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

On 09/19/2014 04:24 PM, Tomi Valkeinen wrote:
> On 17/09/14 10:51, Jyri Sarha wrote:
>> On 09/17/2014 04:06 AM, Dave Airlie wrote:
>>> On 17 September 2014 06:40, Jyri Sarha  wrote:
 Changes since v2:
 - Change compatible property from "ti,gpio-clock" to
 "ti,gpio-gate-clock"
 - Some minor cleanups

 The code has a functional dependency to:
 http://www.mail-archive.com/linux-omap at vger.kernel.org/msg109264.html

 Without the above patch the audio card does not probe.

 The code has been rebased on top of Linux 3.17-rc5. The patches
 bellow, the above dependency, and couple of commits to add BBB HDMI
 audio
 support to omap2plus_defconfig can be pulled from:

 https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>>>
>>> How do you intend to get this merge, sending patchsets like this without
>>> indication to maintainers on a merge strategy is kinda messy.
>>>
>>> I'm not sure how maintained tilcdc is.
>>>
>>
>> Well, it is used but AFAIK the people who have been working with it the
>> most have left TI. I think eventually someone at TI needs to take it
>> over, but I do not know anything about that.
>>
>> I was hoping that because the change to tilcdc is quite minimal it could
>> go in via you. I am sure I could get a reviewed-by and tested-by from
>> from Darren how has bit more experience with tilcdc and maybe from Tomi
>> too if that helps. (Adding Tomi to cc).
>>
>> The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself
>> just adds the audio configuration to pda998x pdata and fills the swap,
>> and mirr parameters with default values (they are usually coming in hard
>> coded at the beginning of tda998x_create()).
>
> I think Dave's point was that the series touches three different
> subsystems, and you didn't give any thoughts about how this could be merged.
>
> Must this be merged in one piece, because xxx depends on yyy etc? Can
> these all be merged separately, via respective trees? If in one piece,
> you could ask acks from Mr x and Mr y, for the parts they maintain. Etc.
> And of course, it'd be good to include all the maintainers (At least
> Mike was missing).
>
> I think the clock patch could be handled totally separate, as it's in no
> way related to HDMI. The video and audio part may be handled together,
> if they have dependencies.
>

There should be no build time breakage no matter what is the merging 
order. The BBB HDMI audio functionality simply does not work before all 
the pieces are in.

1. The audio device does not probe if the ti,gpio-gate-clock is misssing.
2. The audio device probes, but there is no sound coming out if the 
tilcdc_slave change is missing.
3. Without ASoC or DTS changes there is no audio device.

Best regards,
Jyri

[PATCH 5/5] drm/i915: remove intel_pipe_set_base()

[Ville Syrjälä]

On Thu, Sep 18, 2014 at 04:43:16PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> After some refactor intel_primary_plane_setplane() does the same
> as intel_pipe_set_base() so we can get rid of it and replace the calls
> with intel_primary_plane_setplane().
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 79 
> 
>  1 file changed, 8 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 6c61c8f..2477587 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2763,74 +2763,6 @@ static void intel_update_pipe_size(struct intel_crtc 
> *crtc)
>   crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
>  }
>  
> -static int
> -intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> - struct drm_framebuffer *fb)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> - struct drm_framebuffer *old_fb = crtc->primary->fb;
> - struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> - struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
> - int ret;
> -
> - if (intel_crtc_has_pending_flip(crtc)) {
> - DRM_ERROR("pipe is still busy with an old pageflip\n");
> - return -EBUSY;
> - }
> -
> - /* no fb bound */
> - if (!fb) {
> - DRM_ERROR("No FB bound\n");
> - return 0;
> - }
> -
> - if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
> - DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
> -   plane_name(intel_crtc->plane),
> -   INTEL_INFO(dev)->num_pipes);
> - return -EINVAL;
> - }
> -
> - mutex_lock(>struct_mutex);
> - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> - if (ret == 0)
> - i915_gem_track_fb(old_obj, obj,
> -   INTEL_FRONTBUFFER_PRIMARY(pipe));
> - mutex_unlock(>struct_mutex);
> - if (ret != 0) {
> - DRM_ERROR("pin & fence failed\n");
> - return ret;
> - }
> -
> - intel_update_pipe_size(intel_crtc);
> -
> - dev_priv->display.update_primary_plane(crtc, fb, x, y);
> -
> - if (intel_crtc->active)
> - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
> -
> - crtc->primary->fb = fb;
> - crtc->x = x;
> - crtc->y = y;
> -
> - if (old_fb) {
> - if (intel_crtc->active && old_fb != fb)
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> - mutex_lock(>struct_mutex);
> - intel_unpin_fb_obj(old_obj);
> - mutex_unlock(>struct_mutex);
> - }
> -
> - mutex_lock(>struct_mutex);
> - intel_update_fbc(dev);
> - mutex_unlock(>struct_mutex);
> -
> - return 0;
> -}
> -
>  static void intel_fdi_normal_train(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
> @@ -9797,6 +9729,7 @@ static int intel_crtc_commit_page_flip(struct drm_crtc 
> *crtc,
>   struct drm_framebuffer *old_fb = crtc->primary->fb;
>   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_plane *primary = crtc->primary;
>   enum pipe pipe = intel_crtc->pipe;
>   struct intel_unpin_work *work;
>   struct intel_engine_cs *ring;
> @@ -9938,7 +9871,9 @@ free_work:
>   if (ret == -EIO) {
>  out_hang:
>   intel_crtc_wait_for_pending_flips(crtc);
> - ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
> + ret = primary->funcs->update_plane(primary, crtc, fb,
> +0, 0, 0, 0,
> +crtc->x, crtc->y, 0, 0);

I think we want page flips to not change the current plane setup so
these should be:
intel_plane->crtc_x/y/w/h
intel_plane->src_x/y/w/h

>   if (ret == 0 && event) {
>   spin_lock_irq(>event_lock);
>   drm_send_vblank_event(dev, pipe, event);
> @@ -11475,11 +11410,13 @@ static int intel_crtc_set_config(struct 
> drm_mode_set *set)
>set->x, set->y, set->fb);
>   } else if (config->fb_changed) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(set->crtc);
> + struct drm_plane *primary = set->crtc->primary;
>  
>   intel_crtc_wait_for_pending_flips(set->crtc);
>  
> - ret = intel_pipe_set_base(set->crtc,
> -   set->x, set->y, set->fb);
> + ret = primary->funcs->update_plane(primary, set->crtc, set->fb,
> +  

[BUG] nouveau regression: ext monitor dead after resume

[Ortwin Glück]

On 18.09.2014 16:58, Ilia Mirkin wrote:
> This has been reported a few times already -- probably the same thing
> as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550

Ah, thanks. I would like to try with that commit reverted, but unfortunately it 
no longer reverts
cleanly, and my attempts to make a sensible merge were futile. If you can send 
me a patch that
reverts the changes on 3.17-rc5 or 3.16 I am glad to try it out and give you 
the requested feedback.

Ortwin

[PATCH 2/3] drm/radeon: add command submission IDs

[Christian König]

Am 19.09.2014 um 15:40 schrieb Jerome Glisse:
> On Fri, Sep 19, 2014 at 10:03:43AM +0200, Christian K?nig wrote:
>> Hi Jerome,
>>
>> this is exactly the approach which we wanted to avoid. And according to Alex
>> it was actually you guys (I think Dave) who noted that this is probably not
>> such a good idea.
>>
>> The issue is that by telling userspace the ring specific sequence number we
>> nail down the order of execution. E.g. a scheduler who want to change the
>> order in which IBs are submitted to the hardware can't do so any more
>> because we already gave userspace a sequence number to identify the command
>> submission.
> Well for curent code this design does work, for hw where you want to have the
> hw/driver do some scheduling this can still be achieve by having a seq number
> per ring per process.

Correct, for current design we could do so but we have more long term 
goals with that in mind. I will reorder my work a bit which should make 
it more clear why we need the original fence and not only the sequence 
for this.

>
>> Additional to that for hardware inter device synchronization we want to
>> refer to a certain kernel object and not just the fence number. So we can
>> only use some kind of handle based approach, e.g. as discussed before we
>> want to be able to turn this sequence number in a FD fence.
> Inter-device is not an issue here. For inter-device you want to convert this
> seq number to an fd at which point you can create a fence structure with the
> proper information ie create a structure only if it is needed.
>
> Really this is the only sane design if we start allocating structure for each
> cs (well for each cs userspace cares) this gonna play bad with memory 
> pressure.
Mhm, what's the matter with this?

My implementation only allocates a single ring buffer for each client 
which automatically resizes, apart from that we only have the fence 
structure which is allocated anyway and released when automatically as 
soon as all users goes away.

And the scheduler implementation the Intel guys are working on would use 
even more memory. As long as everything as accounted to the correct 
process I don't really see a problem with that.

Regards,
Christian.

>
> Cheers,
> J?r?me
>
>> Regards,
>> Christian.
>>
>> Am 19.09.2014 um 06:06 schrieb Jerome Glisse:
>>> On Thu, Sep 18, 2014 at 11:11:57PM -0400, Jerome Glisse wrote:
 On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
>> From: Christian K?nig 
>>
>> This patch adds a new 64bit ID as a result to each command submission.
> NAK for design reasons.
>
> First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> I know that hooking up to fence make life easy but this is not how it
> should be done.
>
> What you want to expose is the per ring 32bit seq value and report to user
> space the value and the ring id. To handle the wrap around you add a uniq
> 32bit wrap counter which is incremented every 1 << 30 or some big number
> seq value number (but must be smaller than 1 << 31). Then you use 
> arithmetic
> to determine if a cs seq number is done or not (ie the seq wrap around
> counter diff should not be bigger then 2 or 3) and the seq number should
> obviously be after again using arithmetic diff like jiffies code.
>
> All this being hidden in the kernel all the user space have to know is :
> 32 bit seq value per ring
> 32 bit ring uniq id
> 32 wrap counter per ring
>
> With such scheme you never allocate anything or worry about any fence.
> Way simpler and less code.
>
> Cheers,
> J?r?me
 Because code is clearer than words attached is a patch of what i am 
 thinking
 about. The arithmetic should be right as well as the coherency and proper
 memory barrier. Thought it is completely untested and will require couple
 fixes for properly checking userspace arguments and other aspect (see FIXME
 in patches).

 There is no allocation, it is a pretty small patch, and it provide a fast
 ligthweight solution. While the new ioctl argument and return value can be
 improved (like reporting more information to userspace like for instance
 warning userspace when it is querying very old fences). I think the overall
 design is sound.

 Let me know.
>>> Ok actually after a beer (given that planet express manual for Bender, which
>>> also apply to me, clearly stipulate to expect malfunction if not properly
>>> inebriate) it became clear that by reversing the problem i could make it a
>>> lot simpler. So attached is an even simpler patch that handle gracefully 
>>> user
>>> space querying for very old fence (ie that could have wrap around).
>>>
>>> Code explains it all.
>>>
 Cheers,
 J?r?me

>> Signed-off-by: Christian K?nig 
>> ---
>>   

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

[Tomi Valkeinen]

On 19/09/14 16:12, Nishanth Menon wrote:
> On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
>> On 16/09/14 23:40, Jyri Sarha wrote:
>>> The added ti,gpio-gate-clock is a basic clock that can be enabled and
>>> disabled trough a gpio output. The DT binding document for the clock
>>> is also added. For EPROBE_DEFER handling the registering of the clock
>>> has to be delayed until of_clk_get() call time.
>>>
>>> Signed-off-by: Jyri Sarha 
>>> ---
>>>  .../bindings/clock/ti/gpio-gate-clock.txt  |   21 ++
>>>  drivers/clk/ti/Makefile|2 +-
>>>  drivers/clk/ti/gpio.c  |  202 
>>> 
>>>  3 files changed, 224 insertions(+), 1 deletion(-)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>>>  create mode 100644 drivers/clk/ti/gpio.c
>>
>> Why is this a TI clock? Sounds like a generic one to me.
> 
> Like thread: https://lkml.org/lkml/2014/9/5/284 ?

Right, I should've read the earlier versions before making any smart
comments =).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140919/2e818de5/attachment.sig>

[alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Tomi Valkeinen]

On 17/09/14 10:51, Jyri Sarha wrote:
> On 09/17/2014 04:06 AM, Dave Airlie wrote:
>> On 17 September 2014 06:40, Jyri Sarha  wrote:
>>> Changes since v2:
>>> - Change compatible property from "ti,gpio-clock" to
>>> "ti,gpio-gate-clock"
>>> - Some minor cleanups
>>>
>>> The code has a functional dependency to:
>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg109264.html
>>>
>>> Without the above patch the audio card does not probe.
>>>
>>> The code has been rebased on top of Linux 3.17-rc5. The patches
>>> bellow, the above dependency, and couple of commits to add BBB HDMI
>>> audio
>>> support to omap2plus_defconfig can be pulled from:
>>>
>>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>>
>> How do you intend to get this merge, sending patchsets like this without
>> indication to maintainers on a merge strategy is kinda messy.
>>
>> I'm not sure how maintained tilcdc is.
>>
> 
> Well, it is used but AFAIK the people who have been working with it the
> most have left TI. I think eventually someone at TI needs to take it
> over, but I do not know anything about that.
> 
> I was hoping that because the change to tilcdc is quite minimal it could
> go in via you. I am sure I could get a reviewed-by and tested-by from
> from Darren how has bit more experience with tilcdc and maybe from Tomi
> too if that helps. (Adding Tomi to cc).
> 
> The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself
> just adds the audio configuration to pda998x pdata and fills the swap,
> and mirr parameters with default values (they are usually coming in hard
> coded at the beginning of tda998x_create()).

I think Dave's point was that the series touches three different
subsystems, and you didn't give any thoughts about how this could be merged.

Must this be merged in one piece, because xxx depends on yyy etc? Can
these all be merged separately, via respective trees? If in one piece,
you could ask acks from Mr x and Mr y, for the parts they maintain. Etc.
And of course, it'd be good to include all the maintainers (At least
Mike was missing).

I think the clock patch could be handled totally separate, as it's in no
way related to HDMI. The video and audio part may be handled together,
if they have dependencies.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140919/8a4f0157/attachment.sig>

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #31 from Alex Deucher  ---
(In reply to comment #30)
> Created attachment 106554 [details]
> lspci -vnn for Daniel's amilo

You have the same configuration as Patrick.

(In reply to comment #29)
> I tested the patches from 2014-09-17 against 3.17-rc5.
> 
> When I applied both patches,  the backlight was not turned off, when the
> kernel switched into graphics mode. 
> The kernel worked very well.

Great.  I'll make sure the patches get upstream.  Thanks for testing.

-- 
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/20140919/938ed274/attachment.html>

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

[Tomi Valkeinen]

On 16/09/14 23:40, Jyri Sarha wrote:
> The added ti,gpio-gate-clock is a basic clock that can be enabled and
> disabled trough a gpio output. The DT binding document for the clock
> is also added. For EPROBE_DEFER handling the registering of the clock
> has to be delayed until of_clk_get() call time.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/clock/ti/gpio-gate-clock.txt  |   21 ++
>  drivers/clk/ti/Makefile|2 +-
>  drivers/clk/ti/gpio.c  |  202 
> 
>  3 files changed, 224 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>  create mode 100644 drivers/clk/ti/gpio.c

Why is this a TI clock? Sounds like a generic one to me.

In any case, this should go through Mike.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140919/260fb198/attachment.sig>

X.Org looking for projects and mentors for the Outreach Program for Women

[Peter Hutterer]

Just a reminder, if you have projects that are suitable for the OPW please
add them to the wiki page or, if you can't access the wiki, send me a
summary and I'll add it.

http://www.x.org/wiki/XorgOPW/

Prospective participants can start submitting applications on Sep 22 and
it'd be great if we had a nice range of projects available by then.
Note that unlike GSoC, the scope is not limited to coding (see below).

Cheers,
   Peter


On Fri, Sep 05, 2014 at 09:01:44AM +1000, Peter Hutterer wrote:
> Hi everyone,
> 
> X.Org will join the Outreach Program for Women (OPW) in Round 9 (December
> 2014 - March 2015). The OPW is "open to anyone who was
> assigned female at birth and anyone who identifies as a woman, genderqueer,
> genderfluid, or genderfree regardless of gender presentation or assigned sex
> at birth." 
> For more details on the program see 
> https://wiki.gnome.org/OutreachProgramForWomen
> 
> We've secured funding for one participant and are currently looking for
> suitable projects and mentors. The scope of the program is "not limited to
> coding, but include user experience design, graphic design, documentation,
> web development, marketing, translation and other types of tasks needed to
> sustain a FOSS project."
> 
> So if you are interested in mentoring or you can think of a suitable
> project, please add it to the wiki page or alternatively email me.
> http://www.x.org/wiki/XorgOPW/
> 
> If you are interested in participating and you can think of a suitable
> project, please do the same and we'll try our best to find a mentor for you.
> 
> The applications will open on September 22, so let's get some good projects
> up there by then!
> 
> Cheers,
>Peter, on behalf of the X.Org BoD
> 

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen]

On 18/09/14 08:50, Ajay kumar wrote:

>>> Why do we need a complex graph when it can be handled using a simple 
>>> phandle?
>>
>> Maybe in your case you can handle it with simple phandle. Can you
>> guarantee that it's enough for everyone, on all platforms?
> Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
> this. In case of both, the phandle to bridge node is passed to the
> exynos_dp node.
> 
>> The point of the ports/endpoint graph is to also support more
>> complicated scenarios. If you now create ps8622 bindings that do not
>> support those graphs, the no one else using ps8622 can use
>> ports/endpoint graphs either.
>>
>> Btw, is there an example how the bridge with these bindings is used in a
>> board's .dts file? I couldn't find any example with a quick search. So
>> it's unclear to me what the "simple phandle" actually is.
> Please refer to the following link:
> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
> Let me know if you still think we would need to describe it as a complex 
> graph!

Yes, I think so. I'm not the DRM maintainer, though.

I think we have two options:

1) Describe the video component connections with the ports/endpoints
properly for all new display device bindings, and know that it's
(hopefully) future proof and covers even the more complex boards that
use the devices.

or

2) Use some simple methods to describe the links, like single phandle as
you do, knowing that we can't support more complex boards in the future.

I see some exynos boards already using the ports/endpoints, like
arch/arm/boot/dts/exynos4412-trats2.dts. Why not use it for all new
display devices?

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140919/9823e300/attachment-0001.sig>

[PATCH 2/2] ARM: tegra: Add lp_parent clock to dsi

[Sean Paul]

This patch adds the lp_parent clk to the dsi node for
tegra114. The TRM states that PLLP should be used
upstream of the low power dsi clock.

Signed-off-by: Sean Paul 
---
 arch/arm/boot/dts/tegra114.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 80b8edd..20f78e7 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -99,7 +99,8 @@
clocks = <_car TEGRA114_CLK_DSIA>,
 <_car TEGRA114_CLK_DSIALP>,
 <_car TEGRA114_CLK_PLL_D_OUT0>;
-   clock-names = "dsi", "lp", "parent";
+<_car TEGRA114_CLK_PLL_P>;
+   clock-names = "dsi", "lp", "parent", "lp_parent";
resets = <_car 48>;
reset-names = "dsi";
nvidia,mipi-calibrate = < 0x060>; /* DSIA & DSIB 
pads */
-- 
2.0.0

[PATCH 1/2] drm/tegra: Set the dsi lp clk parent and rate

[Sean Paul]

Per NVidia, this clock rate should be around 70MHz in
order to properly sample reads on data lane 0. In order
to achieve this rate, we need to reparent the clock from
clk_m which can only achieve 12MHz. Add parent_lp to the
dts bindings and set the parent & rate on init.

Signed-off-by: Sean Paul 
---
 .../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt  | 10 --
 drivers/gpu/drm/tegra/dsi.c| 18 ++
 drivers/gpu/drm/tegra/dsi.h|  3 +++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index b48f4ef..fef2918 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -191,6 +191,10 @@ of the following host1x client modules:
   - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
   - nvidia,edid: supplies a binary EDID blob
   - nvidia,panel: phandle of a display panel
+  - clock-names: Can include the following entries:
+- lp_parent: The parent clock for lp
+  - clocks: Must contain an entry for each optional entry in clock-names.
+See ../clocks/clock-bindings.txt for details.

 - sor: serial output resource

@@ -360,8 +364,10 @@ Example:
compatible = "nvidia,tegra20-dsi";
reg = <0x5430 0x0004>;
clocks = <_car TEGRA20_CLK_DSI>,
-<_car TEGRA20_CLK_PLL_D_OUT0>;
-   clock-names = "dsi", "parent";
+<_car TEGRA124_CLK_DSIALP>,
+<_car TEGRA20_CLK_PLL_D_OUT0>,
+<_car TEGRA124_CLK_PLL_P>;
+   clock-names = "dsi", "lp", "parent", "lp_parent";
resets = <_car 48>;
reset-names = "dsi";
status = "disabled";
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index f787445..c0258ae 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -837,6 +837,7 @@ static int tegra_dsi_probe(struct platform_device *pdev)
struct tegra_dsi *dsi;
struct resource *regs;
int err;
+   struct clk *lp_parent;

dsi = devm_kzalloc(>dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -879,6 +880,23 @@ static int tegra_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->clk_lp);
}

+   lp_parent = devm_clk_get(>dev, "lp_parent");
+   if (!IS_ERR(lp_parent)) {
+   err = clk_set_parent(dsi->clk_lp, lp_parent);
+   if (err < 0) {
+   dev_err(>dev, "cannot set lp clock parent\n");
+   return err;
+   }
+   } else {
+   dev_info(>dev, "no lp clock parent, using hw default\n");
+   }
+
+   err = clk_set_rate(dsi->clk_lp, DSI_LP_CLK_RATE);
+   if (err < 0) {
+   dev_err(>dev, "cannot set low-power clock rate\n");
+   return err;
+   }
+
err = clk_prepare_enable(dsi->clk_lp);
if (err < 0) {
dev_err(>dev, "cannot enable low-power clock\n");
diff --git a/drivers/gpu/drm/tegra/dsi.h b/drivers/gpu/drm/tegra/dsi.h
index 5ce610d..a332caf 100644
--- a/drivers/gpu/drm/tegra/dsi.h
+++ b/drivers/gpu/drm/tegra/dsi.h
@@ -127,4 +127,7 @@ enum tegra_dsi_format {
TEGRA_DSI_FORMAT_24P,
 };

+/* default lp clock rate */
+#define DSI_LP_CLK_RATE(70 * 1000 * 1000)
+
 #endif
-- 
2.0.0

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #30 from Daniel Kirsten  ---
Created attachment 106554
  --> https://bugs.freedesktop.org/attachment.cgi?id=106554=edit
lspci -vnn for Daniel's amilo

-- 
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/20140919/4de4560f/attachment.html>

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #29 from Daniel Kirsten  ---
I tested the patches from 2014-09-17 against 3.17-rc5.

When I applied both patches,  the backlight was not turned off, when the kernel
switched into graphics mode. 
The kernel worked very well.

Without the patches, the backlight was turned off, when the kernel switched
into graphics mode.

Daniel

-- 
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/20140919/a19f3992/attachment.html>

multi-planar tiled fourcc's in mesa and drm

[Rob Clark]

So, lucky me, I have a scenario where I get to deal with NV12MT.  Hurray!

I know there has been some reluctance in the past to combine tiling
and color format, since in theory that could lead to a combinatorial
explosion in formats.  And, as long as the buffer usage is entirely
within a single driver, you can approximately hide tiling (or
compressed, etc) permutations of a color format.  On the other hand,
there is already some precedence for fourcc or format values to
represent tiled formats at the interface level (in kernel, v4l, and in
userspace, and gstreamer and openmax).

But in this scenario, sharing buffer between other devices (video
decoder/encoder) and drm/kms (msm) and mesa (freedreno) via
EGL_EXT_image_dma_buf_import[1], I sort of don't really have any other
way to pass around tiling flags.  So I would propose adding custom
fourcc's only in the more limited cases where formats are exchanged
between devices.  This should avoid an explosion of color_format *
tiling_format.

For the kms part, it would mean merging a small patch to allow addfb2
for NV12MT[2].

For the mesa part, it looks like there is a bit of work needed to
teach egl about multi-planar buffers, buffers where offset[n] != 0,
etc.  I'll start with patches to teach egl how to import plain NV12
buffers.  But once that is done, for it to be much use to me I'll need
NV12MT, which means adding a new gallium format and
__DRI_IMAGE_FOURCC_NV12MT.

Also, I'm still a bit undecided on how to represent multi-planar
formats (ie. single pipe_resource encapsulating each of the planes?
or pipe_resource per plane but teach pipe_sampler_view about textures
which have multiple pipe_resource's, one for per plane).

Anyways, I'll start working on the mesa egl bits next week.  First
step is just add an 'offset' parameter to 'struct winsys_handle',
which should hopefully be non-controversial.  After that, I need to
decide how to handle multi-planar, and I think that hinges on how
folks want to handle multi-planar in gallium.  Ie. if one
pipe_resource per plane, then winsys_handle doesn't need any further
change (but we need changes elsewhere), otherwise winsys_handle needs
to have an array of handles.

Anyways, I'd appreciate feedback.

BR,
-R

[1] 
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
[2] http://lists.freedesktop.org/archives/dri-devel/2014-July/064828.html

[PATCH 2/5] drm/i915: move checks of intel_crtc_cursor_set_obj() out

[Ville Syrjälä]

On Thu, Sep 18, 2014 at 04:43:13PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Move checks inside intel_crtc_cursor_set_obj() to
> intel_check_cursor_plane(), we only use they there so move them out to
> make the merge of intel_crtc_cursor_set_obj() into
> intel_check_cursor_plane() easier.
> 
> This is another step toward the atomic modesetting support and unification
> of plane operations such pin/unpin of fb objects on i915.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 66 
> 
>  1 file changed, 44 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1fd9b70..a68befb 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8377,7 +8377,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
> *crtc,
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   enum pipe pipe = intel_crtc->pipe;
> - unsigned old_width, stride;
> + unsigned old_width;
>   uint32_t addr;
>   int ret;
>  
> @@ -8389,30 +8389,11 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
> *crtc,
>   goto finish;
>   }
>  
> - /* Check for which cursor types we support */
> - if (!cursor_size_ok(dev, width, height)) {
> - DRM_DEBUG("Cursor dimension not supported\n");
> - return -EINVAL;
> - }
> -
> - stride = roundup_pow_of_two(width) * 4;
> - if (obj->base.size < stride * height) {
> - DRM_DEBUG_KMS("buffer is too small\n");
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
>   /* we only need to pin inside GTT if cursor is non-phy */
>   mutex_lock(>struct_mutex);
>   if (!INTEL_INFO(dev)->cursor_needs_physical) {
>   unsigned alignment;
>  
> - if (obj->tiling_mode) {
> - DRM_DEBUG_KMS("cursor cannot be tiled\n");
> - ret = -EINVAL;
> - goto fail_locked;
> - }

Hmm. I was going to say this check needs to remain here due to
struct_mutex getting dropped between check() and here. But it looks
like these days obj->framebuffer_references should protect us from
anyone changing the tiling mode while the object is wrapped in
framebuffer. So seems moving it should still work fine.

> -
>   /*
>* Global gtt pte registers are special registers which actually
>* forward writes to a chunk of system memory. Which means that
> @@ -8488,7 +8469,6 @@ fail_unpin:
>   i915_gem_object_unpin_from_display_plane(obj);
>  fail_locked:
>   mutex_unlock(>struct_mutex);
> -fail:
>   drm_gem_object_unreference_unlocked(>base);

That unref looks like a leftover from the days before universal
planes. Should be just removed AFAICS and the stale comments about
reference consumption should be removed. Please send a separate patch
for this stuff.

>   return ret;
>  }
> @@ -12039,16 +12019,58 @@ intel_check_cursor_plane(struct drm_plane *plane,
>struct intel_plane_state *state)
>  {
>   struct drm_crtc *crtc = state->crtc;
> + struct drm_device *dev = crtc->dev;
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_rect *dest = >dst;
>   struct drm_rect *src = >src;
>   const struct drm_rect *clip = >clip;
> + struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> + int crtc_w, crtc_h;
> + unsigned stride;
> + int ret;
>  
> - return drm_plane_helper_check_update(plane, crtc, fb,
> + ret = drm_plane_helper_check_update(plane, crtc, fb,
>   src, dest, clip,
>   DRM_PLANE_HELPER_NO_SCALING,
>   DRM_PLANE_HELPER_NO_SCALING,
>   true, true, >visible);
> + if (ret)
> + return ret;
> +
> + crtc_w = drm_rect_width(>orig_dst);
> + crtc_h = drm_rect_height(>orig_dst);

Could move these a bit later since they're not needed immediately.

> +
> + /* if we want to turn off the cursor ignore width and height */
> + if (!obj)
> + return 0;
> +
> + if (fb == crtc->cursor->fb)
> + return 0;
> +
> + /* Check for which cursor types we support */
> + if (!cursor_size_ok(dev, crtc_w, crtc_h)) {
> + DRM_DEBUG("Cursor dimension not supported\n");
> + return -EINVAL;
> + }
> +
> + stride = roundup_pow_of_two(crtc_w) * 4;
> + if (obj->base.size < stride * crtc_h) {
> + DRM_DEBUG_KMS("buffer is too small\n");
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + /* we only need to pin inside GTT if cursor is non-phy */
> + 

[PATCH v5 05/11] drm: add Atmel HLCDC Display Controller support

[David Herrmann]

Hi

On Mon, Sep 8, 2014 at 10:43 AM, Boris BREZILLON
 wrote:
[snip]
> +static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
> +{
> +   int ret;
> +
> +   ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> +   if (ret)
> +   return ret;
> +
> +   ret = drm_platform_init(_hlcdc_dc_driver, pdev);
> +   if (ret)
> +   return ret;

Please avoid any use of drm_platform_*(). Use drm_dev_alloc(),
drm_dev_register() directly. See my response on
  "[PATCH v3 1/5] drm/rockchip: Add basic drm driver":
for details. Also have a look at the tegra driver how to do it.

> +
> +   return 0;
> +}
> +
> +static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
> +{
> +   drm_put_dev(platform_get_drvdata(pdev));

Same here: please use dev_dev_*() directly:

drm_dev_unregister(ddev);
drm_dev_unref(ddev);


Thanks
David

[PATCH v3 1/5] drm/rockchip: Add basic drm driver

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 7:47 AM, Mark yao  wrote:
[snip]
> +static int rockchip_drm_bind(struct device *dev)
> +{
> +   return drm_platform_init(_drm_driver, 
> to_platform_device(dev));

Please avoid drm_platform_*() usage. We're about to drop all the
drm_bus midlayers. See the tegra driver how to do it, but basically
just this:

struct drm_device *ddev;

ddev = drm_dev_alloc(_drm_driver, _platform_device(dev)->dev);
if (!ddev)
return -ENOMEM;

r = drm_dev_set_unique(ddev, dev_name(>dev));
if (r < 0) {
drm_dev_unref(ddev);
return r;
}

r = drm_dev_register(ddev);
if (r < 0) {
drm_dev_unref(ddev);
return r;
}

> +}
> +
> +static void rockchip_drm_unbind(struct device *dev)
> +{
> +   drm_put_dev(dev_get_drvdata(dev));

Please use:

struct drm_device *ddev = dev_get_drvdata(dev);

drm_dev_unregister(ddev);
drm_dev_unref(ddev);


Thanks
David

[PATCH v2] drm/exynos: switch to universal plane API

[Andrzej Hajda]

The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Additionally the patch leaves cleanup of crtcs to core,
this way planes and crtcs are cleaned in correct order.

Signed-off-by: Andrzej Hajda 
---
Hi Inki, Joonyoung,

This is 2nd version of the patch with addressed comments of Joonyoung.

Regards
Andrzej
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 62 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  1 -
 drivers/gpu/drm/exynos/exynos_mixer.c |  2 -
 7 files changed, 46 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..8e38e9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,7 +32,6 @@ enum exynos_crtc_mode {
  * Exynos specific crtc structure.
  *
  * @drm_crtc: crtc object.
- * @drm_plane: pointer of private plane object for this crtc
  * @manager: the manager associated with this crtc
  * @pipe: a crtc index created at load() with a new crtc object creation
  * and the crtc object would be set to private->crtc array
@@ -46,7 +45,6 @@ enum exynos_crtc_mode {
  */
 struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
-   struct drm_plane*plane;
struct exynos_drm_manager   *manager;
unsigned intpipe;
unsigned intdpms;
@@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)

exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);

-   exynos_plane_commit(exynos_crtc->plane);
+   exynos_plane_commit(crtc->primary);

if (manager->ops->commit)
manager->ops->commit(manager);

-   exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
+   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
 }

 static bool
@@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
-   struct drm_plane *plane = exynos_crtc->plane;
+   struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
-   int ret;

/*
 * copy the mode data adjusted by mode_fixup() into crtc->mode
@@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 */
memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));

-   crtc_w = crtc->primary->fb->width - x;
-   crtc_h = crtc->primary->fb->height - y;
+   crtc_w = fb->width - x;
+   crtc_h = fb->height - y;

if (manager->ops->mode_set)
manager->ops->mode_set(manager, >mode);

-   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
crtc_w, crtc_h,
-   x, y, crtc_w, crtc_h);
-   if (ret)
-   return ret;
-
-   plane->crtc = crtc;
-   plane->fb = crtc->primary->fb;
-   drm_framebuffer_reference(plane->fb);
-
-   return 0;
+   return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+crtc_w, crtc_h, x, y, crtc_w, crtc_h);
 }

 static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
  struct drm_framebuffer *old_fb)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_plane *plane = exynos_crtc->plane;
+   struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
@@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
drm_crtc *crtc, int x, int y,
return -EPERM;
}

-   crtc_w = crtc->primary->fb->width - x;
-   crtc_h = crtc->primary->fb->height - y;
+   crtc_w = fb->width - x;
+   crtc_h = fb->height - y;

-   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
crtc_w, crtc_h,
-   x, y, crtc_w, crtc_h);
+   ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
if (ret)
return ret;

@@ -304,8 +293,7 @@ static int exynos_drm_crtc_set_property(struct drm_crtc 
*crtc,
exynos_drm_crtc_commit(crtc);
break;
case CRTC_MODE_BLANK:
-   exynos_plane_dpms(exynos_crtc->plane,
- 

[PATCH] drm/exynos: init vblank with real number of crtcs

[Andrzej Hajda]

Initialization of vblank with MAX_CRTC caused attempts
to disabling vblanks for non-existing crtcs in case
drm used fewer crtcs. The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9b00e4e..dc4affd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);

-   ret = drm_vblank_init(dev, MAX_CRTC);
-   if (ret)
-   goto err_mode_config_cleanup;
-
/* setup possible_clones. */
exynos_drm_encoder_setup(dev);

@@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
unsigned long flags)
/* Try to bind all sub drivers. */
ret = component_bind_all(dev->dev, dev);
if (ret)
-   goto err_cleanup_vblank;
+   goto err_mode_config_cleanup;
+
+   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+   if (ret)
+   goto err_unbind_all;

/* Probe non kms sub drivers and virtual display driver. */
ret = exynos_drm_device_subdrv_probe(dev);
if (ret)
-   goto err_unbind_all;
+   goto err_cleanup_vblank;

/* force connectors detection */
drm_helper_hpd_irq_event(dev);

return 0;

-err_unbind_all:
-   component_unbind_all(dev->dev, dev);
 err_cleanup_vblank:
drm_vblank_cleanup(dev);
+err_unbind_all:
+   component_unbind_all(dev->dev, dev);
 err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);
@@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
exynos_drm_fbdev_fini(dev);
drm_kms_helper_poll_fini(dev);

-   component_unbind_all(dev->dev, dev);
drm_vblank_cleanup(dev);
+   component_unbind_all(dev->dev, dev);
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);

-- 
1.9.1

[Intel-gfx] [PATCH] intel: Don't leak the test page in an has_userptr() error path

[Damien Lespiau]

On Fri, Sep 19, 2014 at 02:31:56PM +0100, Tvrtko Ursulin wrote:
> 
> Reviewed-by: Tvrtko Ursulin 
> 

Thanks for the review, pushed the patch.

-- 
Damien

[Intel-gfx] [PATCH] intel: Don't leak the test page in an has_userptr() error path

[Tvrtko Ursulin]

Reviewed-by: Tvrtko Ursulin 

On 09/17/2014 01:37 PM, Damien Lespiau wrote:
> When handling the error on GEM_CLOSE, we weren't freeing the allocated
> page. Plug that.
>
> Signed-off-by: Damien Lespiau 
> ---
>   intel/intel_bufmgr_gem.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index f378e5c..ce35bd4 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3383,9 +3383,8 @@ retry:
>
>   close_bo.handle = userptr.handle;
>   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_GEM_CLOSE, _bo);
> - if (ret == 0) {
> - free(ptr);
> - } else {
> + free(ptr);
> + if (ret) {
>   fprintf(stderr, "Failed to release test userptr object! (%d) "
>   "i915 kernel driver may not be sane!\n", errno);
>   return false;
>

[PATCH 1/5] drm/i915: Merge of visible and !visible paths for primary planes

[Ville Syrjälä]

On Thu, Sep 18, 2014 at 04:43:12PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Fold intel_pipe_set_base() in the update primary plane path merging
> pieces of code that are common to both paths.
> 
> Basically the the pin/unpin procedures are the same for both paths
> and some checks can also be shared (some of the were moved to the
> check() stage)
> 
> v2: take Ville's comments:
>   - remove unnecessary plane check
>   - move mutex lock to inside the conditional
>   - make the pin fail message a debug one
>   - add a fixme for the fastboot hack
>   - call intel_frontbuffer_flip() after FBC update
> 
> v3: take more Ville's comments:
>   - fold update code under if (intel_crtc->active), and do the
>   visible/!visible split inside.
>   - check ret inside the same conditional we assign it
> 
> v4: don't use intel_enable_primary_hw_plane(), the primary_enabled
> check inside will break page flips
> 
> Suggested-by: Ville Syrj?l? 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 141 
> +--
>  1 file changed, 84 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5b05ddb..1fd9b70 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11792,12 +11792,23 @@ intel_check_primary_plane(struct drm_plane *plane,
>   struct drm_rect *dest = >dst;
>   struct drm_rect *src = >src;
>   const struct drm_rect *clip = >clip;
> + int ret;
>  
> - return drm_plane_helper_check_update(plane, crtc, fb,
> + ret = drm_plane_helper_check_update(plane, crtc, fb,
>   src, dest, clip,
>   DRM_PLANE_HELPER_NO_SCALING,
>   DRM_PLANE_HELPER_NO_SCALING,
>   false, true, >visible);
> + if (ret)
> + return ret;
> +
> + /* no fb bound */
> + if (state->visible && !fb) {
> + DRM_ERROR("No FB bound\n");
> + return -EINVAL;
> + }
> +
> + return 0;
>  }
>  
>  static int
> @@ -11809,6 +11820,8 @@ intel_commit_primary_plane(struct drm_plane *plane,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + struct drm_framebuffer *old_fb = plane->fb;
>   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
>   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
>   struct intel_plane *intel_plane = to_intel_plane(plane);
> @@ -11817,67 +11830,28 @@ intel_commit_primary_plane(struct drm_plane *plane,
>  
>   intel_crtc_wait_for_pending_flips(crtc);
>  
> - /*
> -  * If clipping results in a non-visible primary plane, we'll disable
> -  * the primary plane.  Note that this is a bit different than what
> -  * happens if userspace explicitly disables the plane by passing fb=0
> -  * because plane->fb still gets set and pinned.
> -  */
> - if (!state->visible) {
> - mutex_lock(>struct_mutex);
> -
> - /*
> -  * Try to pin the new fb first so that we can bail out if we
> -  * fail.
> -  */
> - if (plane->fb != fb) {
> - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> - if (ret) {
> - mutex_unlock(>struct_mutex);
> - return ret;
> - }
> - }
> -
> - i915_gem_track_fb(old_obj, obj,
> -   INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
> -
> - if (intel_crtc->primary_enabled)
> - intel_disable_primary_hw_plane(plane, crtc);
> -
> -
> - if (plane->fb != fb)
> - if (plane->fb)
> - intel_unpin_fb_obj(old_obj);
> + if (intel_crtc_has_pending_flip(crtc)) {
> + DRM_ERROR("pipe is still busy with an old pageflip\n");
> + return -EBUSY;
> + }
>  
> + if (plane->fb != fb) {
> + mutex_lock(>struct_mutex);
> + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> + if (ret == 0)
> + i915_gem_track_fb(old_obj, obj,
> +   INTEL_FRONTBUFFER_PRIMARY(pipe));
>   mutex_unlock(>struct_mutex);
> -
> - } else {
> - if (intel_crtc && intel_crtc->active &&
> - intel_crtc->primary_enabled) {
> - /*
> -  * FBC does not work on some platforms for rotated
> -  * planes, so disable it when rotation is not 0 and
> -  * update 

[Bug 83505] AMD A4-5300 APU : radeon.dpm=1 get random reboots with 3.16.1 kernel.

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

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

Rpnpif  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Rpnpif  ---
After one week without random reboots, I think that this bug is fixed in
3.16.2.
Thank you.

-- 
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/20140919/fe9f84ea/attachment.html>

[PATCH v3 5/5] drm/rockchip: Add support for Rockchip Soc EDP

[Mark yao]

This adds support for Rockchip soc edp found on rk3288

Signed-off-by: Mark Yao 
Signed-off-by: Jeff Chen 
---
Changes in v2:
- fix code sytle
- use some define from drm_dp_helper.h
- use panel-simple driver for primary display.
- remove unnecessary clock clk_24m_parent.

Changes in v3: None

 drivers/gpu/drm/rockchip/Kconfig |9 +
 drivers/gpu/drm/rockchip/Makefile|2 +
 drivers/gpu/drm/rockchip/rockchip_edp_core.c |  853 ++
 drivers/gpu/drm/rockchip/rockchip_edp_core.h |  309 +++
 drivers/gpu/drm/rockchip/rockchip_edp_reg.c  | 1202 ++
 drivers/gpu/drm/rockchip/rockchip_edp_reg.h  |  345 
 6 files changed, 2720 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_core.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_core.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_reg.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 7146c80..04b1f8c 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -17,3 +17,12 @@ config DRM_ROCKCHIP
  management to userspace. This driver does not provides
  2D or 3D acceleration; acceleration is performed by other
  IP found on the SoC.
+
+config ROCKCHIP_EDP
+   bool "Rockchip edp support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option if you have a Rockchip eDP.
+ Rockchip rk3288 SoC has eDP TX Controller can be used.
+ If you have an Embedded DisplayPort Panel, say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 6e6d468..a0fc3a1 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,4 +7,6 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o rockchip_drm_vop.o

+rockchipdrm-$(CONFIG_ROCKCHIP_EDP) += rockchip_edp_core.o rockchip_edp_reg.o
+
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_edp_core.c 
b/drivers/gpu/drm/rockchip/rockchip_edp_core.c
new file mode 100644
index 000..5450d1fa
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_edp_core.c
@@ -0,0 +1,853 @@
+/*
+* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+* Author:
+*  Andy yan 
+*  Jeff chen 
+*
+* based on exynos_dp_core.c
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the
+* Free Software Foundation; either version 2 of the License, or (at your
+* option) any later version.
+*/
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rockchip_edp_core.h"
+
+#define connector_to_edp(c) \
+   container_of(c, struct rockchip_edp_device, connector)
+
+#define encoder_to_edp(c) \
+   container_of(c, struct rockchip_edp_device, encoder)
+
+static struct rockchip_edp_soc_data soc_data[2] = {
+   /* rk3288 */
+   {.grf_soc_con6 = 0x025c,
+.grf_soc_con12 = 0x0274},
+   /* no edp switching needed */
+   {.grf_soc_con6 = -1,
+.grf_soc_con12 = -1},
+};
+
+static const struct of_device_id rockchip_edp_dt_ids[] = {
+   {.compatible = "rockchip,rk3288-edp",
+.data = (void *)_data[0] },
+   {}
+};
+
+MODULE_DEVICE_TABLE(of, rockchip_edp_dt_ids);
+
+static int rockchip_edp_clk_enable(struct rockchip_edp_device *edp)
+{
+   int ret = 0;
+
+   if (!edp->clk_on) {
+   ret = clk_prepare_enable(edp->pclk);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable edp pclk %d\n", ret);
+   goto err_pclk;
+   }
+
+   ret = clk_prepare_enable(edp->clk_edp);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable clk_edp %d\n", ret);
+   goto err_clk_edp;
+   }
+
+   ret = clk_set_rate(edp->clk_24m, 2400);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot set edp clk_24m %d\n",
+   ret);
+   goto err_clk_24m;
+   }
+
+   ret = clk_prepare_enable(edp->clk_24m);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable edp clk_24m %d\n",
+   ret);
+   goto err_clk_24m;
+   }
+
+   edp->clk_on = true;
+   }
+
+   return 0;
+
+err_clk_24m:
+   clk_disable_unprepare(edp->clk_edp);
+err_clk_edp:
+   clk_disable_unprepare(edp->pclk);
+err_pclk:
+   edp->clk_on = false;
+
+   return 

[PATCH v3 4/5] dt-bindings: video: Add documentation for rockchip edp

[Mark yao]

Add binding documentation for Rockchip SoC EDP driver.

Signed-off-by: Jeff Chen 
Signed-off-by: Mark Yao 
---
Changes in v2:
- add edp reset
- add panel node
- add port for display-subsystem

Changes in v3: None

 .../devicetree/bindings/video/rockchip-edp.txt |   50 
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-edp.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-edp.txt 
b/Documentation/devicetree/bindings/video/rockchip-edp.txt
new file mode 100644
index 000..515e806
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-edp.txt
@@ -0,0 +1,50 @@
+Rockchip RK3288 EDP interface
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "clk_edp"
+   "clk_edp_24m"
+   "pclk_edp"
+- resets: Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+- reset-names: Must include the name "edp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- rockchip,panel: required a simple panel node as described by
+   Documentation/devicetree/bindings/panel/simple-panel.txt
+
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   edp: edp at ff97 {
+   compatible = "rockchip,rk3288-edp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < SCLK_EDP_24M>, < 
PCLK_EDP_CTRL>;
+   clock-names = "clk_edp", "clk_edp_24m", "pclk_edp";
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "edp";
+   rockchip,panel = <>;
+   ports {
+   edp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v3 3/5] dt-bindings: video: Add documentation for rockchip vop

[Mark yao]

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

 .../devicetree/bindings/video/rockchip-vop.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_vop: for ddr buffer transfer.
+   hclk_vop: for ahb bus to R/W the phy regs.
+   dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - axi
+  - ahb
+  - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+   vopb: vopb at ff93 {
+   compatible = "rockchip,rk3288-vop";
+   reg = <0xff93 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v3 2/5] dt-bindings: video: Add for rockchip display subsytem

[Mark yao]

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt 
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  of vop devices. vop definitions as defined in
+  Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
+};
-- 
1.7.9.5

[PATCH] drm/exynos: switch to universal plane API

[Andrzej Hajda]

On 09/19/2014 01:11 PM, Joonyoung Shim wrote:
> Hi,
>
> On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
>> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
 The patch replaces legacy functions
 drm_plane_init() / drm_crtc_init() with
 drm_universal_plane_init() and drm_crtc_init_with_planes().
 It allows to replace fake primary plane with the real one.

 Signed-off-by: Andrzej Hajda 
 ---
 Hi Inki,

 I have tested this patch with trats board, it looks OK.
 As a side effect it should solve fb refcounting issues
 reported by me and Daniel Drake.

 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
  4 files changed, 47 insertions(+), 41 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..d2f713e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
   * Exynos specific crtc structure.
   *
   * @drm_crtc: crtc object.
 - * @drm_plane: pointer of private plane object for this crtc
   * @manager: the manager associated with this crtc
   * @pipe: a crtc index created at load() with a new crtc object creation
   *and the crtc object would be set to private->crtc array
 @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
   */
  struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
 -  struct drm_plane*plane;
struct exynos_drm_manager   *manager;
unsigned intpipe;
unsigned intdpms;
 @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
 *crtc)
  
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  
 -  exynos_plane_commit(exynos_crtc->plane);
 +  exynos_plane_commit(crtc->primary);
  
if (manager->ops->commit)
manager->ops->commit(manager);
  
 -  exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
 +  exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
  }
  
  static bool
 @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
 -  struct drm_plane *plane = exynos_crtc->plane;
 +  struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
 -  int ret;
  
/*
 * copy the mode data adjusted by mode_fixup() into crtc->mode
 @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
 */
memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
  
 -  crtc_w = crtc->primary->fb->width - x;
 -  crtc_h = crtc->primary->fb->height - y;
 +  crtc_w = fb->width - x;
 +  crtc_h = fb->height - y;
  
if (manager->ops->mode_set)
manager->ops->mode_set(manager, >mode);
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 -  if (ret)
 -  return ret;
 -
 -  plane->crtc = crtc;
 -  plane->fb = crtc->primary->fb;
 -  drm_framebuffer_reference(plane->fb);
 -
 -  return 0;
 +  return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
  struct drm_framebuffer *old_fb)
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 -  struct drm_plane *plane = exynos_crtc->plane;
 +  struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
 @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
 drm_crtc *crtc, int x, int y,
return -EPERM;
}
  
 -  crtc_w = crtc->primary->fb->width - x;
 -  crtc_h = crtc->primary->fb->height - y;
 +  crtc_w = fb->width - x;
 +  crtc_h = fb->height - y;
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 +  ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
 +

[PATCH v3 1/5] drm/rockchip: Add basic drm driver

[Mark yao]

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark yao 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   19 +
 drivers/gpu/drm/rockchip/Makefile |   10 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  502 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  231 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  405 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   76 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1372 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
 include/uapi/drm/rockchip_drm.h   |   97 ++
 15 files changed, 3271 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
 create mode 100644 include/uapi/drm/rockchip_drm.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..7146c80
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,19 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM && ROCKCHIP_IOMMU
+   select ARM_DMA_USE_IOMMU
+   select IOMMU_API
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you have a Rockchip soc chipset.
+ This driver provides kernel mode setting and buffer
+ management to userspace. This driver does not provides
+ 2D or 3D acceleration; acceleration is performed by other
+ IP found on the SoC.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
new file mode 100644
index 000..6e6d468
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for the drm device driver.  This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip
+
+rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
+   rockchip_drm_gem.o rockchip_drm_vop.o
+
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
new file mode 100644
index 000..f84dcd8
--- /dev/null

[PATCH v3 0/5] Add drm driver for Rockchip Socs

[Mark yao]

This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices, eDP. Future patches will add additional encoders/connectors,
such as HDMI.

The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
ARM_DMA_USE_IOMMU.

Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use panel-simple driver for primary display.
- add vop and edp reset.

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Tested on rk3288 pinky board, use eDP encoders/connector, boot and display OK

Mark yao (5):
  drm/rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop
  dt-bindings: video: Add documentation for rockchip edp
  drm/rockchip: Add support for Rockchip Soc EDP

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-edp.txt |   50 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   28 +
 drivers/gpu/drm/rockchip/Makefile  |   12 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  502 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|  120 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  201 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  231 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  405 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   76 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1387 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  187 +++
 drivers/gpu/drm/rockchip/rockchip_edp_core.c   |  853 
 drivers/gpu/drm/rockchip/rockchip_edp_core.h   |  309 +
 drivers/gpu/drm/rockchip/rockchip_edp_reg.c| 1202 +
 drivers/gpu/drm/rockchip/rockchip_edp_reg.h|  345 +
 include/uapi/drm/rockchip_drm.h|   97 ++
 22 files changed, 6133 insertions(+)

-- 
1.7.9.5

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #28 from Alex Deucher  ---
(In reply to comment #26)
> (In reply to comment #25)
> 
> The pci-id of the VGA Controller is 01:00.0 for my Amilo.

That's the bus id.  I need the output of lspci -vnn

-- 
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/20140919/0ae06254/attachment-0001.html>

[BUG] nouveau regression: ext monitor dead after resume

[Ilia Mirkin]

On Fri, Sep 19, 2014 at 12:52 PM, Ortwin Gl?ck  wrote:
> On 19.09.2014 17:58, Ilia Mirkin wrote:
>> git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
>
> Thanks again. I confirm that Bugzilla 83550 is the same issue. I have 
> attached the captured logs
> there for reference.

Thanks! Hopefully you still have those kernels handy, as your logs got
cut off. Try booting with log_buf_len=100M to increase the
"scrollback" buffer (I assume you have oodles of RAM). Or grab the
kernel logs from your system.

  -ilia

[PATCH] drm/exynos: switch to universal plane API

[Andrzej Hajda]

On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
> Hi Andrzej,
>
> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>> The patch replaces legacy functions
>> drm_plane_init() / drm_crtc_init() with
>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>> It allows to replace fake primary plane with the real one.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi Inki,
>>
>> I have tested this patch with trats board, it looks OK.
>> As a side effect it should solve fb refcounting issues
>> reported by me and Daniel Drake.
>>
>> Regards
>> Andrzej
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>>  4 files changed, 47 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index b68e58f..d2f713e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>>   * Exynos specific crtc structure.
>>   *
>>   * @drm_crtc: crtc object.
>> - * @drm_plane: pointer of private plane object for this crtc
>>   * @manager: the manager associated with this crtc
>>   * @pipe: a crtc index created at load() with a new crtc object creation
>>   *  and the crtc object would be set to private->crtc array
>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>>   */
>>  struct exynos_drm_crtc {
>>  struct drm_crtc drm_crtc;
>> -struct drm_plane*plane;
>>  struct exynos_drm_manager   *manager;
>>  unsigned intpipe;
>>  unsigned intdpms;
>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>>  
>>  exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>  
>> -exynos_plane_commit(exynos_crtc->plane);
>> +exynos_plane_commit(crtc->primary);
>>  
>>  if (manager->ops->commit)
>>  manager->ops->commit(manager);
>>  
>> -exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>> +exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>>  }
>>  
>>  static bool
>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>> drm_display_mode *mode,
>>  {
>>  struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>  struct exynos_drm_manager *manager = exynos_crtc->manager;
>> -struct drm_plane *plane = exynos_crtc->plane;
>> +struct drm_framebuffer *fb = crtc->primary->fb;
>>  unsigned int crtc_w;
>>  unsigned int crtc_h;
>> -int ret;
>>  
>>  /*
>>   * copy the mode data adjusted by mode_fixup() into crtc->mode
>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>> drm_display_mode *mode,
>>   */
>>  memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>  
>> -crtc_w = crtc->primary->fb->width - x;
>> -crtc_h = crtc->primary->fb->height - y;
>> +crtc_w = fb->width - x;
>> +crtc_h = fb->height - y;
>>  
>>  if (manager->ops->mode_set)
>>  manager->ops->mode_set(manager, >mode);
>>  
>> -ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>> crtc_w, crtc_h,
>> -x, y, crtc_w, crtc_h);
>> -if (ret)
>> -return ret;
>> -
>> -plane->crtc = crtc;
>> -plane->fb = crtc->primary->fb;
>> -drm_framebuffer_reference(plane->fb);
>> -
>> -return 0;
>> +return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>  }
>>  
>>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
>> int y,
>>struct drm_framebuffer *old_fb)
>>  {
>>  struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> -struct drm_plane *plane = exynos_crtc->plane;
>> +struct drm_framebuffer *fb = crtc->primary->fb;
>>  unsigned int crtc_w;
>>  unsigned int crtc_h;
>>  int ret;
>> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
>> drm_crtc *crtc, int x, int y,
>>  return -EPERM;
>>  }
>>  
>> -crtc_w = crtc->primary->fb->width - x;
>> -crtc_h = crtc->primary->fb->height - y;
>> +crtc_w = fb->width - x;
>> +crtc_h = fb->height - y;
>>  
>> -ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>> crtc_w, crtc_h,
>> -x, y, crtc_w, crtc_h);
>> +ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>  if (ret)
>>  return ret;
>>  
>> @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc 
>> *crtc)
>>  
>>  private->crtc[exynos_crtc->pipe] = NULL;
>>  
>> +

[PATCH] drm/radeon: Update IH_RB_RPTR register after each processed interrupt

[Michel Dänzer]

From: Michel D?nzer 

This might decrease the chance of IH ring buffer overflows.

Signed-off-by: Michel D?nzer 
---

I think this patch should wait for after 3.17.

 drivers/gpu/drm/radeon/cik.c   | 2 +-
 drivers/gpu/drm/radeon/evergreen.c | 2 +-
 drivers/gpu/drm/radeon/r600.c  | 2 +-
 drivers/gpu/drm/radeon/si.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b46bc0f..717b6ca 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8251,6 +8251,7 @@ restart_ih:
/* wptr/rptr are in bytes! */
rptr += 16;
rptr &= rdev->ih.ptr_mask;
+   WREG32(IH_RB_RPTR, rptr);
}
if (queue_hotplug)
schedule_work(>hotplug_work);
@@ -8259,7 +8260,6 @@ restart_ih:
if (queue_thermal)
schedule_work(>pm.dpm.thermal.work);
rdev->ih.rptr = rptr;
-   WREG32(IH_RB_RPTR, rdev->ih.rptr);
atomic_set(>ih.lock, 0);

/* make sure wptr hasn't changed while processing */
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index b091370..e50807c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5137,6 +5137,7 @@ restart_ih:
/* wptr/rptr are in bytes! */
rptr += 16;
rptr &= rdev->ih.ptr_mask;
+   WREG32(IH_RB_RPTR, rptr);
}
if (queue_hotplug)
schedule_work(>hotplug_work);
@@ -5145,7 +5146,6 @@ restart_ih:
if (queue_thermal && rdev->pm.dpm_enabled)
schedule_work(>pm.dpm.thermal.work);
rdev->ih.rptr = rptr;
-   WREG32(IH_RB_RPTR, rdev->ih.rptr);
atomic_set(>ih.lock, 0);

/* make sure wptr hasn't changed while processing */
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index a6598c3..0ec0f945 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4058,6 +4058,7 @@ restart_ih:
/* wptr/rptr are in bytes! */
rptr += 16;
rptr &= rdev->ih.ptr_mask;
+   WREG32(IH_RB_RPTR, rptr);
}
if (queue_hotplug)
schedule_work(>hotplug_work);
@@ -4066,7 +4067,6 @@ restart_ih:
if (queue_thermal && rdev->pm.dpm_enabled)
schedule_work(>pm.dpm.thermal.work);
rdev->ih.rptr = rptr;
-   WREG32(IH_RB_RPTR, rdev->ih.rptr);
atomic_set(>ih.lock, 0);

/* make sure wptr hasn't changed while processing */
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index ba68896..e763840 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6665,13 +6665,13 @@ restart_ih:
/* wptr/rptr are in bytes! */
rptr += 16;
rptr &= rdev->ih.ptr_mask;
+   WREG32(IH_RB_RPTR, rptr);
}
if (queue_hotplug)
schedule_work(>hotplug_work);
if (queue_thermal && rdev->pm.dpm_enabled)
schedule_work(>pm.dpm.thermal.work);
rdev->ih.rptr = rptr;
-   WREG32(IH_RB_RPTR, rdev->ih.rptr);
atomic_set(>ih.lock, 0);

/* make sure wptr hasn't changed while processing */
-- 
2.1.0

[PATCH] drm/radeon: Make IH ring overflow debugging output more useful

[Michel Dänzer]

From: Michel D?nzer 

Use the same format for all ring indices, and fix the calculation of the
post-overflow RPTR.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/cik.c   | 4 ++--
 drivers/gpu/drm/radeon/evergreen.c | 4 ++--
 drivers/gpu/drm/radeon/r600.c  | 4 ++--
 drivers/gpu/drm/radeon/si.c| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 87a7489..b46bc0f 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7756,8 +7756,8 @@ static inline u32 cik_get_ih_wptr(struct radeon_device 
*rdev)
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
 */
-   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, %d, 
%d)\n",
-   wptr, rdev->ih.rptr, (wptr + 16) + rdev->ih.ptr_mask);
+   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, 0x%08X, 
0x%08X)\n",
+wptr, rdev->ih.rptr, (wptr + 16) & rdev->ih.ptr_mask);
rdev->ih.rptr = (wptr + 16) & rdev->ih.ptr_mask;
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 6a50b03..b091370 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4754,8 +4754,8 @@ static u32 evergreen_get_ih_wptr(struct radeon_device 
*rdev)
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
 */
-   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, %d, 
%d)\n",
-   wptr, rdev->ih.rptr, (wptr + 16) + rdev->ih.ptr_mask);
+   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, 0x%08X, 
0x%08X)\n",
+wptr, rdev->ih.rptr, (wptr + 16) & rdev->ih.ptr_mask);
rdev->ih.rptr = (wptr + 16) & rdev->ih.ptr_mask;
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 007c903..a6598c3 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3807,8 +3807,8 @@ static u32 r600_get_ih_wptr(struct radeon_device *rdev)
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
 */
-   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, %d, 
%d)\n",
-   wptr, rdev->ih.rptr, (wptr + 16) + rdev->ih.ptr_mask);
+   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, 0x%08X, 
0x%08X)\n",
+wptr, rdev->ih.rptr, (wptr + 16) & rdev->ih.ptr_mask);
rdev->ih.rptr = (wptr + 16) & rdev->ih.ptr_mask;
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 9e591ad..ba68896 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6322,8 +6322,8 @@ static inline u32 si_get_ih_wptr(struct radeon_device 
*rdev)
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
 */
-   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, %d, 
%d)\n",
-   wptr, rdev->ih.rptr, (wptr + 16) + rdev->ih.ptr_mask);
+   dev_warn(rdev->dev, "IH ring buffer overflow (0x%08X, 0x%08X, 
0x%08X)\n",
+wptr, rdev->ih.rptr, (wptr + 16) & rdev->ih.ptr_mask);
rdev->ih.rptr = (wptr + 16) & rdev->ih.ptr_mask;
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
-- 
2.1.0

[PATCH 1/2] cirrus: add missing drm_connector_register call

[Gerd Hoffmann]

On Fr, 2014-09-19 at 10:37 +0200, David Herrmann wrote:
> Hi
> 
> On Fri, Sep 19, 2014 at 10:11 AM, Gerd Hoffmann  wrote:
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
> > b/drivers/gpu/drm/cirrus/cirrus_mode.c
> > index e1c5c32..c7c5a9d 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> > @@ -555,6 +555,7 @@ static struct drm_connector *cirrus_vga_init(struct 
> > drm_device *dev)
> >
> > drm_connector_helper_add(connector, 
> > _vga_connector_helper_funcs);
> >
> > +   drm_connector_register(connector);
> 
> Error checking?

Hmm, I see plenty of calls like this in the kernel.

Also: What should happen on error?  The driver itself and cirrusdrmfb
works just fine without that, so I don't feel like failing driver
initialization because of that, as that would break the console ...

> And should probably include "Cc:  # v3.15+".

Commit 2ee39452fa2fff1e8edb954ccb7e0daee9646557 (v3.17 merge window)
exposes the bug, so stable kernels are working just fine.

cheers,
  Gerd

[PATCH] drm/radeon: Clear RB_OVERFLOW bit earlier

[Michel Dänzer]

From: Michel D?nzer 

Otherwise the bit remains set in rdev->ih.rptr, so the wptr can never
match that and we still have an infinite loop.

This fix allows me to successfully recover from an IH ring buffer
overflow.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/cik.c   | 2 +-
 drivers/gpu/drm/radeon/evergreen.c | 2 +-
 drivers/gpu/drm/radeon/r600.c  | 2 +-
 drivers/gpu/drm/radeon/si.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 13367f4..87a7489 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7751,6 +7751,7 @@ static inline u32 cik_get_ih_wptr(struct radeon_device 
*rdev)
wptr = RREG32(IH_RB_WPTR);

if (wptr & RB_OVERFLOW) {
+   wptr &= ~RB_OVERFLOW;
/* When a ring buffer overflow happen start parsing interrupt
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
@@ -7761,7 +7762,6 @@ static inline u32 cik_get_ih_wptr(struct radeon_device 
*rdev)
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
WREG32(IH_RB_CNTL, tmp);
-   wptr &= ~RB_OVERFLOW;
}
return (wptr & rdev->ih.ptr_mask);
 }
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index dbca60c..6a50b03 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4749,6 +4749,7 @@ static u32 evergreen_get_ih_wptr(struct radeon_device 
*rdev)
wptr = RREG32(IH_RB_WPTR);

if (wptr & RB_OVERFLOW) {
+   wptr &= ~RB_OVERFLOW;
/* When a ring buffer overflow happen start parsing interrupt
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
@@ -4759,7 +4760,6 @@ static u32 evergreen_get_ih_wptr(struct radeon_device 
*rdev)
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
WREG32(IH_RB_CNTL, tmp);
-   wptr &= ~RB_OVERFLOW;
}
return (wptr & rdev->ih.ptr_mask);
 }
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e8bf0ea..007c903 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3802,6 +3802,7 @@ static u32 r600_get_ih_wptr(struct radeon_device *rdev)
wptr = RREG32(IH_RB_WPTR);

if (wptr & RB_OVERFLOW) {
+   wptr &= ~RB_OVERFLOW;
/* When a ring buffer overflow happen start parsing interrupt
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
@@ -3812,7 +3813,6 @@ static u32 r600_get_ih_wptr(struct radeon_device *rdev)
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
WREG32(IH_RB_CNTL, tmp);
-   wptr &= ~RB_OVERFLOW;
}
return (wptr & rdev->ih.ptr_mask);
 }
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 23ff34a..9e591ad 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6317,6 +6317,7 @@ static inline u32 si_get_ih_wptr(struct radeon_device 
*rdev)
wptr = RREG32(IH_RB_WPTR);

if (wptr & RB_OVERFLOW) {
+   wptr &= ~RB_OVERFLOW;
/* When a ring buffer overflow happen start parsing interrupt
 * from the last not overwritten vector (wptr + 16). Hopefully
 * this should allow us to catchup.
@@ -6327,7 +6328,6 @@ static inline u32 si_get_ih_wptr(struct radeon_device 
*rdev)
tmp = RREG32(IH_RB_CNTL);
tmp |= IH_WPTR_OVERFLOW_CLEAR;
WREG32(IH_RB_CNTL, tmp);
-   wptr &= ~RB_OVERFLOW;
}
return (wptr & rdev->ih.ptr_mask);
 }
-- 
2.1.0

[BUG] nouveau regression: ext monitor dead after resume

[Ilia Mirkin]

On Fri, Sep 19, 2014 at 10:41 AM, Ortwin Gl?ck  wrote:
>
>
> On 18.09.2014 16:58, Ilia Mirkin wrote:
>> This has been reported a few times already -- probably the same thing
>> as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
>
> Ah, thanks. I would like to try with that commit reverted, but unfortunately 
> it no longer reverts
> cleanly, and my attempts to make a sensible merge were futile. If you can 
> send me a patch that
> reverts the changes on 3.17-rc5 or 3.16 I am glad to try it out and give you 
> the requested feedback.

git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^

[build, confirm it works, grab logs]

git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758

[build, confirm it's broken, grab logs]

It's not the sort of change that's really revertable...

  -ilia

[PATCH 2/3] drm/radeon: add command submission IDs

[Jerome Glisse]

On Fri, Sep 19, 2014 at 04:29:35PM +0200, Christian K?nig wrote:
> Am 19.09.2014 um 15:40 schrieb Jerome Glisse:
> >On Fri, Sep 19, 2014 at 10:03:43AM +0200, Christian K?nig wrote:
> >>Hi Jerome,
> >>
> >>this is exactly the approach which we wanted to avoid. And according to Alex
> >>it was actually you guys (I think Dave) who noted that this is probably not
> >>such a good idea.
> >>
> >>The issue is that by telling userspace the ring specific sequence number we
> >>nail down the order of execution. E.g. a scheduler who want to change the
> >>order in which IBs are submitted to the hardware can't do so any more
> >>because we already gave userspace a sequence number to identify the command
> >>submission.
> >Well for curent code this design does work, for hw where you want to have the
> >hw/driver do some scheduling this can still be achieve by having a seq number
> >per ring per process.
> 
> Correct, for current design we could do so but we have more long term goals
> with that in mind. I will reorder my work a bit which should make it more
> clear why we need the original fence and not only the sequence for this.

Well yes i am eagger to understand why a simple solution is not the one people
are aiming for. I should add that if you are working on a new kernel driver to
support new hardware there is one thing you should definitly do and that is
getting rid of implicit synchronization support. If you do so then there is no
longer the need to allocate a fence whatsoever. That was my whole point in the
dma fence discussion. With explicit fencing all you need is to give some seq
number back to userspace.

Note that memory placement obviously is another beast and if hardware you are
targetting for have more scheduling capabilities that it is obvious that the
way we do thing now is pointless ie there is no need to associate fence with
buffer object and buffer should be move as a preamble to each cs.

> 
> >
> >>Additional to that for hardware inter device synchronization we want to
> >>refer to a certain kernel object and not just the fence number. So we can
> >>only use some kind of handle based approach, e.g. as discussed before we
> >>want to be able to turn this sequence number in a FD fence.
> >Inter-device is not an issue here. For inter-device you want to convert this
> >seq number to an fd at which point you can create a fence structure with the
> >proper information ie create a structure only if it is needed.
> >
> >Really this is the only sane design if we start allocating structure for each
> >cs (well for each cs userspace cares) this gonna play bad with memory 
> >pressure.
> Mhm, what's the matter with this?
> 
> My implementation only allocates a single ring buffer for each client which
> automatically resizes, apart from that we only have the fence structure
> which is allocated anyway and released when automatically as soon as all
> users goes away.

This is already too much, as i said with explicit synchronization there is never
a need for any allocation. All what is needed is a seq number.

> 
> And the scheduler implementation the Intel guys are working on would use
> even more memory. As long as everything as accounted to the correct process
> I don't really see a problem with that.

Does not mean you have to copy their bad choices.

> 
> Regards,
> Christian.
> 
> >
> >Cheers,
> >J?r?me
> >
> >>Regards,
> >>Christian.
> >>
> >>Am 19.09.2014 um 06:06 schrieb Jerome Glisse:
> >>>On Thu, Sep 18, 2014 at 11:11:57PM -0400, Jerome Glisse wrote:
> On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> >On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> >>From: Christian K?nig 
> >>
> >>This patch adds a new 64bit ID as a result to each command submission.
> >NAK for design reasons.
> >
> >First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> >I know that hooking up to fence make life easy but this is not how it
> >should be done.
> >
> >What you want to expose is the per ring 32bit seq value and report to 
> >user
> >space the value and the ring id. To handle the wrap around you add a uniq
> >32bit wrap counter which is incremented every 1 << 30 or some big number
> >seq value number (but must be smaller than 1 << 31). Then you use 
> >arithmetic
> >to determine if a cs seq number is done or not (ie the seq wrap around
> >counter diff should not be bigger then 2 or 3) and the seq number should
> >obviously be after again using arithmetic diff like jiffies code.
> >
> >All this being hidden in the kernel all the user space have to know is :
> >32 bit seq value per ring
> >32 bit ring uniq id
> >32 wrap counter per ring
> >
> >With such scheme you never allocate anything or worry about any fence.
> >Way simpler and less code.
> >
> >Cheers,
> >J?r?me
> Because code is clearer than words attached is a patch of what i am 
> 

[Bug 83616] System crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

Dieter N?tzel  changed:

   What|Removed |Added

 Attachment #105923|0   |1
is obsolete||

--- Comment #14 from Dieter N?tzel  ---
Comment on attachment 105923
  --> https://bugs.freedesktop.org/attachment.cgi?id=105923
Xorg.0.log-drm-next-3.18-wip

My second bug is fixed with:

3840a65 drm/radeon: fix AGP userptr handling

-- 
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/20140919/388b2b81/attachment.html>

[Bug 83616] System crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

Dieter N?tzel  changed:

   What|Removed |Added

 Attachment #105922|0   |1
is obsolete||

--- Comment #13 from Dieter N?tzel  ---
Comment on attachment 105922
  --> https://bugs.freedesktop.org/attachment.cgi?id=105922
dmesg-drm-next-3.18-wip.log

My second bug is fixed with:

3840a65 drm/radeon: fix AGP userptr handling

-- 
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/20140919/d8247a4b/attachment.html>

[PATCH 1/2] cirrus: add missing drm_connector_register call

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 10:11 AM, Gerd Hoffmann  wrote:
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
> b/drivers/gpu/drm/cirrus/cirrus_mode.c
> index e1c5c32..c7c5a9d 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> @@ -555,6 +555,7 @@ static struct drm_connector *cirrus_vga_init(struct 
> drm_device *dev)
>
> drm_connector_helper_add(connector, 
> _vga_connector_helper_funcs);
>
> +   drm_connector_register(connector);

Error checking?

And should probably include "Cc:  # v3.15+".

Thanks
David

> return connector;
>  }
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page

[Michel Dänzer]

From: Michel D?nzer 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83996
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/rs400.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index 6c1fc33..c5799f16 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -221,9 +221,9 @@ void rs400_gart_set_page(struct radeon_device *rdev, 
unsigned i,
entry = (lower_32_bits(addr) & PAGE_MASK) |
((upper_32_bits(addr) & 0xff) << 4);
if (flags & RADEON_GART_PAGE_READ)
-   addr |= RS400_PTE_READABLE;
+   entry |= RS400_PTE_READABLE;
if (flags & RADEON_GART_PAGE_WRITE)
-   addr |= RS400_PTE_WRITEABLE;
+   entry |= RS400_PTE_WRITEABLE;
if (!(flags & RADEON_GART_PAGE_SNOOP))
entry |= RS400_PTE_UNSNOOPED;
entry = cpu_to_le32(entry);
-- 
2.1.0

[Bug 84089] [radeonsi] hd 7790 need more sGPRS for ps

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

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

Iaroslav Andrusyak  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

-- 
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/20140919/318616a6/attachment.html>

[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object

[Michel Dänzer]

On 18.09.2014 19:22, Maarten Lankhorst wrote:
> Op 18-09-14 om 05:26 schreef Michel D?nzer:
>> On 17.09.2014 21:35, Maarten Lankhorst wrote:
>>> diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c 
>>> b/drivers/gpu/drm/radeon/radeon_semaphore.c
>>> index 4d4b0773638a..68311da39c09 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_semaphore.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
>>> @@ -124,27 +124,39 @@ void radeon_semaphore_sync_fence(struct 
>>> radeon_semaphore *semaphore,
>>> *
>>> * Sync to the fence using this semaphore object
>>> */
>>> -void radeon_semaphore_sync_resv(struct radeon_semaphore *sema,
>>> -struct reservation_object *resv,
>>> -bool shared)
>>> +int radeon_semaphore_sync_resv(struct radeon_device *rdev,
>>> +   struct radeon_semaphore *sema,
>>> +   struct reservation_object *resv,
>>> +   bool shared, bool intr)
>>
>> The callers of this function would be more readable if it took flags instead 
>> of the shared and intr bools.
> This does not match the rest of the TTM design. Things like
> ttm_bo_reserve take separate bools, not flags.

So? :)


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[Bug 84089] New: [radeonsi] hd 7790 need more sGPRS for ps

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

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

  Priority: medium
Bug ID: 84089
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi] hd 7790 need more sGPRS for ps
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: pontostroy at gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Many games with high shaders usage fails with
si_state_draw.c:312:si_pipe_shader_ps: Assertion `num_sgprs <= 104' failed.
Unigine Valley won't start on low settings, but work with wine on low\medium.


I changed  num_sgprs <= 104 to num_sgprs <= 204 and add fprint for num_sgprs
and user_sgprs

USER 9, NUM 40
USER2 9, NUM2 40
-
USER 9, NUM 32
USER2 9, NUM2 32
-
USER 9, NUM 24
USER2 9, NUM2 24
-
USER 9, NUM 32
USER2 9, NUM2 32
-
USER 9, NUM 96
USER2 9, NUM2 96
-
USER 9, NUM 96
USER2 9, NUM2 96
-
USER 9, NUM 72
USER2 9, NUM2 72
-
USER 9, NUM 64
USER2 9, NUM2 64
-
USER 9, NUM 64
USER2 9, NUM2 64
-
USER 9, NUM 72
USER2 9, NUM2 72
-
USER 9, NUM 16
USER2 9, NUM2 16
-
USER 9, NUM 64
USER2 9, NUM2 64
-
USER 9, NUM 112
USER2 9, NUM2 112
-
USER 9, NUM 64
USER2 9, NUM2 64
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 56
USER2 9, NUM2 56
-
USER 9, NUM 80
USER2 9, NUM2 80
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 56
USER2 9, NUM2 56
-
USER 9, NUM 40
USER2 9, NUM2 40
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 56
USER2 9, NUM2 56
-
USER 9, NUM 80
USER2 9, NUM2 80
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 64
USER2 9, NUM2 64
-
USER 9, NUM 56
USER2 9, NUM2 56
-
USER 9, NUM 80
USER2 9, NUM2 80
-
USER 9, NUM 32
USER2 9, NUM2 32
-
USER 9, NUM 40
USER2 9, NUM2 40
-
USER 9, NUM 72
USER2 9, NUM2 72
-
USER 9, NUM 104
USER2 9, NUM2 104
-
USER 9, NUM 24
USER2 9, NUM2 24
-
USER 9, NUM 32
USER2 9, NUM2 32
-
USER 9, NUM 32
USER2 9, NUM2 32
-
USER 9, NUM 56
USER2 9, NUM2 56
-
USER 9, NUM 96
USER2 9, NUM2 96
-
USER 9, NUM 24
USER2 9, NUM2 24
-
USER 9, NUM 112
USER2 9, NUM2 112
-
USER 9, NUM 112
USER2 9, NUM2 112
-
USER 9, NUM 96
USER2 9, NUM2 96
-
USER 9, NUM 112
USER2 9, NUM2 112
-
USER 9, NUM 16
USER2 9, NUM2 16
-


112 ist ?he largest number of that I have seen.

-- 
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/20140919/b8f10163/attachment.html>

[PATCH 2/2] bochs: add missing drm_connector_register call

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 9d7346b..6b7efcf3 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -250,6 +250,7 @@ static void bochs_connector_init(struct drm_device *dev)
   DRM_MODE_CONNECTOR_VIRTUAL);
drm_connector_helper_add(connector,
 _connector_connector_helper_funcs);
+   drm_connector_register(connector);
 }


-- 
1.8.3.1

[PATCH 1/2] cirrus: add missing drm_connector_register call

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index e1c5c32..c7c5a9d 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -555,6 +555,7 @@ static struct drm_connector *cirrus_vga_init(struct 
drm_device *dev)

drm_connector_helper_add(connector, _vga_connector_helper_funcs);

+   drm_connector_register(connector);
return connector;
 }

-- 
1.8.3.1

[PATCH 2/3] drm/radeon: add command submission IDs

[Christian König]

Hi Jerome,

this is exactly the approach which we wanted to avoid. And according to 
Alex it was actually you guys (I think Dave) who noted that this is 
probably not such a good idea.

The issue is that by telling userspace the ring specific sequence number 
we nail down the order of execution. E.g. a scheduler who want to change 
the order in which IBs are submitted to the hardware can't do so any 
more because we already gave userspace a sequence number to identify the 
command submission.

Additional to that for hardware inter device synchronization we want to 
refer to a certain kernel object and not just the fence number. So we 
can only use some kind of handle based approach, e.g. as discussed 
before we want to be able to turn this sequence number in a FD fence.

Regards,
Christian.

Am 19.09.2014 um 06:06 schrieb Jerome Glisse:
> On Thu, Sep 18, 2014 at 11:11:57PM -0400, Jerome Glisse wrote:
>> On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
>>> On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
 From: Christian K?nig 

 This patch adds a new 64bit ID as a result to each command submission.
>>> NAK for design reasons.
>>>
>>> First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
>>> I know that hooking up to fence make life easy but this is not how it
>>> should be done.
>>>
>>> What you want to expose is the per ring 32bit seq value and report to user
>>> space the value and the ring id. To handle the wrap around you add a uniq
>>> 32bit wrap counter which is incremented every 1 << 30 or some big number
>>> seq value number (but must be smaller than 1 << 31). Then you use arithmetic
>>> to determine if a cs seq number is done or not (ie the seq wrap around
>>> counter diff should not be bigger then 2 or 3) and the seq number should
>>> obviously be after again using arithmetic diff like jiffies code.
>>>
>>> All this being hidden in the kernel all the user space have to know is :
>>> 32 bit seq value per ring
>>> 32 bit ring uniq id
>>> 32 wrap counter per ring
>>>
>>> With such scheme you never allocate anything or worry about any fence.
>>> Way simpler and less code.
>>>
>>> Cheers,
>>> J?r?me
>> Because code is clearer than words attached is a patch of what i am thinking
>> about. The arithmetic should be right as well as the coherency and proper
>> memory barrier. Thought it is completely untested and will require couple
>> fixes for properly checking userspace arguments and other aspect (see FIXME
>> in patches).
>>
>> There is no allocation, it is a pretty small patch, and it provide a fast
>> ligthweight solution. While the new ioctl argument and return value can be
>> improved (like reporting more information to userspace like for instance
>> warning userspace when it is querying very old fences). I think the overall
>> design is sound.
>>
>> Let me know.
> Ok actually after a beer (given that planet express manual for Bender, which
> also apply to me, clearly stipulate to expect malfunction if not properly
> inebriate) it became clear that by reversing the problem i could make it a
> lot simpler. So attached is an even simpler patch that handle gracefully user
> space querying for very old fence (ie that could have wrap around).
>
> Code explains it all.
>
>> Cheers,
>> J?r?me
>>
>>>
 Signed-off-by: Christian K?nig 
 ---
   drivers/gpu/drm/radeon/Makefile |   2 +-
   drivers/gpu/drm/radeon/radeon.h |  13 +-
   drivers/gpu/drm/radeon/radeon_cs.c  |  13 ++
   drivers/gpu/drm/radeon/radeon_kms.c |  41 +++
   drivers/gpu/drm/radeon/radeon_seq.c | 229 
 
   include/uapi/drm/radeon_drm.h   |   1 +
   6 files changed, 277 insertions(+), 22 deletions(-)
   create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c

 diff --git a/drivers/gpu/drm/radeon/Makefile 
 b/drivers/gpu/drm/radeon/Makefile
 index 8cc9f68..21ee928 100644
 --- a/drivers/gpu/drm/radeon/Makefile
 +++ b/drivers/gpu/drm/radeon/Makefile
 @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
 \
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o 
 \
 -  radeon_sync.o
 +  radeon_sync.o radeon_seq.o
   
   # add async DMA block
   radeon-y += \
 diff --git a/drivers/gpu/drm/radeon/radeon.h 
 b/drivers/gpu/drm/radeon/radeon.h
 index b3b4e96..dbfd346 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct 
 radeon_fence *a,
   }
   
   /*
 + * Userspace command submission identifier generation
 + */
 +struct radeon_seq;
 +
 +uint64_t radeon_seq_push(struct radeon_seq 

[PATCH v2 1/5] drm/rockchip: Add basic drm driver

[yaozq]

On 2014?09?18? 22:53, Daniel Vetter wrote:
> On Thu, Sep 18, 2014 at 04:52:14PM +0200, Daniel Vetter wrote:
>> On Thu, Sep 18, 2014 at 05:36:31PM +0800, Mark yao wrote:
>>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>>
>>> Signed-off-by: Mark yao 
>>> ---
>>> Changes in v2:
>>> - use the component framework to defer main drm driver probe
>>>until all VOP devices have been probed.
>>> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>>>master device and each vop device can shared the drm dma mapping.
>>> - use drm_crtc_init_with_planes and drm_universal_plane_init.
>>> - remove unnecessary middle layers.
>>> - add cursor set, move funcs to rockchip drm crtc.
>>> - use vop reset at first init
>>> - reference framebuffer when used and unreference when swap out vop
>>>
>>> +static const struct drm_crtc_funcs rockchip_crtc_funcs = {
>>> +   .set_config = drm_crtc_helper_set_config,
>>> +   .page_flip = rockchip_drm_crtc_page_flip,
>>> +   .destroy = rockchip_drm_crtc_destroy,
>>> +   .cursor_set = vop_crtc_cursor_set,
>>> +   .cursor_move = vop_crtc_cursor_move,
>> If you expose your cursor plane as a universal you don't need to implement
>> these two cursor functions at all. Actually the core never calls them, see
>> drm_mode_cursor_universal. So if you want to expose cursors, please use
>> universal cursor plane support (like i915).
>>
>> In general that's how new drivers should expose cursors since without
>> universal planes support cursors will not be supported with the atomic
>> ioctl. Since your cursor code just calls the relevant plane functions that
>> should even simplify your driver ;-)
> Actually you already initialize with cursor universal planes, so all this
> code can simply be removed.
> -Daniel
I see, drm_mode_cursor_universal is nice, I would test and use it.
-Mark

[PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi Andrzej,

On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
> 
> I have tested this patch with trats board, it looks OK.
> As a side effect it should solve fb refcounting issues
> reported by me and Daniel Drake.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>  4 files changed, 47 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b68e58f..d2f713e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>   * Exynos specific crtc structure.
>   *
>   * @drm_crtc: crtc object.
> - * @drm_plane: pointer of private plane object for this crtc
>   * @manager: the manager associated with this crtc
>   * @pipe: a crtc index created at load() with a new crtc object creation
>   *   and the crtc object would be set to private->crtc array
> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>   */
>  struct exynos_drm_crtc {
>   struct drm_crtc drm_crtc;
> - struct drm_plane*plane;
>   struct exynos_drm_manager   *manager;
>   unsigned intpipe;
>   unsigned intdpms;
> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>  
>   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>  
> - exynos_plane_commit(exynos_crtc->plane);
> + exynos_plane_commit(crtc->primary);
>  
>   if (manager->ops->commit)
>   manager->ops->commit(manager);
>  
> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>  }
>  
>  static bool
> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>   struct exynos_drm_manager *manager = exynos_crtc->manager;
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
>   unsigned int crtc_w;
>   unsigned int crtc_h;
> - int ret;
>  
>   /*
>* copy the mode data adjusted by mode_fixup() into crtc->mode
> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>*/
>   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>  
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>  
>   if (manager->ops->mode_set)
>   manager->ops->mode_set(manager, >mode);
>  
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> - if (ret)
> - return ret;
> -
> - plane->crtc = crtc;
> - plane->fb = crtc->primary->fb;
> - drm_framebuffer_reference(plane->fb);
> -
> - return 0;
> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> +  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>  }
>  
>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int 
> y,
> struct drm_framebuffer *old_fb)
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
>   unsigned int crtc_w;
>   unsigned int crtc_h;
>   int ret;
> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
> drm_crtc *crtc, int x, int y,
>   return -EPERM;
>   }
>  
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>  
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> + ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>   if (ret)
>   return ret;
>  
> @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
>  
>   private->crtc[exynos_crtc->pipe] = NULL;
>  
> + crtc->primary->funcs->destroy(crtc->primary);

This is unnecessary.

>   drm_crtc_cleanup(crtc);
>   

[PATCH 2/3] drm/radeon: add command submission IDs

[Jerome Glisse]

On Fri, Sep 19, 2014 at 10:03:43AM +0200, Christian K?nig wrote:
> Hi Jerome,
> 
> this is exactly the approach which we wanted to avoid. And according to Alex
> it was actually you guys (I think Dave) who noted that this is probably not
> such a good idea.
> 
> The issue is that by telling userspace the ring specific sequence number we
> nail down the order of execution. E.g. a scheduler who want to change the
> order in which IBs are submitted to the hardware can't do so any more
> because we already gave userspace a sequence number to identify the command
> submission.

Well for curent code this design does work, for hw where you want to have the
hw/driver do some scheduling this can still be achieve by having a seq number
per ring per process.

> 
> Additional to that for hardware inter device synchronization we want to
> refer to a certain kernel object and not just the fence number. So we can
> only use some kind of handle based approach, e.g. as discussed before we
> want to be able to turn this sequence number in a FD fence.

Inter-device is not an issue here. For inter-device you want to convert this
seq number to an fd at which point you can create a fence structure with the
proper information ie create a structure only if it is needed.

Really this is the only sane design if we start allocating structure for each
cs (well for each cs userspace cares) this gonna play bad with memory pressure.

Cheers,
J?r?me

> 
> Regards,
> Christian.
> 
> Am 19.09.2014 um 06:06 schrieb Jerome Glisse:
> >On Thu, Sep 18, 2014 at 11:11:57PM -0400, Jerome Glisse wrote:
> >>On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> >>>On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> From: Christian K?nig 
> 
> This patch adds a new 64bit ID as a result to each command submission.
> >>>NAK for design reasons.
> >>>
> >>>First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> >>>I know that hooking up to fence make life easy but this is not how it
> >>>should be done.
> >>>
> >>>What you want to expose is the per ring 32bit seq value and report to user
> >>>space the value and the ring id. To handle the wrap around you add a uniq
> >>>32bit wrap counter which is incremented every 1 << 30 or some big number
> >>>seq value number (but must be smaller than 1 << 31). Then you use 
> >>>arithmetic
> >>>to determine if a cs seq number is done or not (ie the seq wrap around
> >>>counter diff should not be bigger then 2 or 3) and the seq number should
> >>>obviously be after again using arithmetic diff like jiffies code.
> >>>
> >>>All this being hidden in the kernel all the user space have to know is :
> >>>32 bit seq value per ring
> >>>32 bit ring uniq id
> >>>32 wrap counter per ring
> >>>
> >>>With such scheme you never allocate anything or worry about any fence.
> >>>Way simpler and less code.
> >>>
> >>>Cheers,
> >>>J?r?me
> >>Because code is clearer than words attached is a patch of what i am thinking
> >>about. The arithmetic should be right as well as the coherency and proper
> >>memory barrier. Thought it is completely untested and will require couple
> >>fixes for properly checking userspace arguments and other aspect (see FIXME
> >>in patches).
> >>
> >>There is no allocation, it is a pretty small patch, and it provide a fast
> >>ligthweight solution. While the new ioctl argument and return value can be
> >>improved (like reporting more information to userspace like for instance
> >>warning userspace when it is querying very old fences). I think the overall
> >>design is sound.
> >>
> >>Let me know.
> >Ok actually after a beer (given that planet express manual for Bender, which
> >also apply to me, clearly stipulate to expect malfunction if not properly
> >inebriate) it became clear that by reversing the problem i could make it a
> >lot simpler. So attached is an even simpler patch that handle gracefully user
> >space querying for very old fence (ie that could have wrap around).
> >
> >Code explains it all.
> >
> >>Cheers,
> >>J?r?me
> >>
> >>>
> Signed-off-by: Christian K?nig 
> ---
>   drivers/gpu/drm/radeon/Makefile |   2 +-
>   drivers/gpu/drm/radeon/radeon.h |  13 +-
>   drivers/gpu/drm/radeon/radeon_cs.c  |  13 ++
>   drivers/gpu/drm/radeon/radeon_kms.c |  41 +++
>   drivers/gpu/drm/radeon/radeon_seq.c | 229 
>  
>   include/uapi/drm/radeon_drm.h   |   1 +
>   6 files changed, 277 insertions(+), 22 deletions(-)
>   create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
> 
> diff --git a/drivers/gpu/drm/radeon/Makefile 
> b/drivers/gpu/drm/radeon/Makefile
> index 8cc9f68..21ee928 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
>   rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
>  

[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io

[Dave Airlie]

On 13 September 2014 00:28, Bjorn Helgaas  wrote:
> On Fri, Sep 12, 2014 at 5:19 AM, Bruno Pr?mont
>  wrote:
>> Bjorn,
>>
>> What is missing to get these two patches pushed to Linus?
>
> Sorry, I've been working on some other regressions and overlooked this
> one.  If you open a bugzilla report and mark it as a regression, that
> will help keep this on my radar.

My MBP is crying? can we get these merged, I can handle if if you want
to ack them for me!

Dave.

[PATCH] drm/radeon: Clear RB_OVERFLOW bit earlier

[Alex Deucher]

On Thu, Sep 18, 2014 at 11:07 PM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> Otherwise the bit remains set in rdev->ih.rptr, so the wptr can never
> match that and we still have an infinite loop.
>
> This fix allows me to successfully recover from an IH ring buffer
> overflow.
>
> Signed-off-by: Michel D?nzer 


All three patches applied to my -fixes tree.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c   | 2 +-
>  drivers/gpu/drm/radeon/evergreen.c | 2 +-
>  drivers/gpu/drm/radeon/r600.c  | 2 +-
>  drivers/gpu/drm/radeon/si.c| 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 13367f4..87a7489 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7751,6 +7751,7 @@ static inline u32 cik_get_ih_wptr(struct radeon_device 
> *rdev)
> wptr = RREG32(IH_RB_WPTR);
>
> if (wptr & RB_OVERFLOW) {
> +   wptr &= ~RB_OVERFLOW;
> /* When a ring buffer overflow happen start parsing interrupt
>  * from the last not overwritten vector (wptr + 16). Hopefully
>  * this should allow us to catchup.
> @@ -7761,7 +7762,6 @@ static inline u32 cik_get_ih_wptr(struct radeon_device 
> *rdev)
> tmp = RREG32(IH_RB_CNTL);
> tmp |= IH_WPTR_OVERFLOW_CLEAR;
> WREG32(IH_RB_CNTL, tmp);
> -   wptr &= ~RB_OVERFLOW;
> }
> return (wptr & rdev->ih.ptr_mask);
>  }
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index dbca60c..6a50b03 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -4749,6 +4749,7 @@ static u32 evergreen_get_ih_wptr(struct radeon_device 
> *rdev)
> wptr = RREG32(IH_RB_WPTR);
>
> if (wptr & RB_OVERFLOW) {
> +   wptr &= ~RB_OVERFLOW;
> /* When a ring buffer overflow happen start parsing interrupt
>  * from the last not overwritten vector (wptr + 16). Hopefully
>  * this should allow us to catchup.
> @@ -4759,7 +4760,6 @@ static u32 evergreen_get_ih_wptr(struct radeon_device 
> *rdev)
> tmp = RREG32(IH_RB_CNTL);
> tmp |= IH_WPTR_OVERFLOW_CLEAR;
> WREG32(IH_RB_CNTL, tmp);
> -   wptr &= ~RB_OVERFLOW;
> }
> return (wptr & rdev->ih.ptr_mask);
>  }
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index e8bf0ea..007c903 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3802,6 +3802,7 @@ static u32 r600_get_ih_wptr(struct radeon_device *rdev)
> wptr = RREG32(IH_RB_WPTR);
>
> if (wptr & RB_OVERFLOW) {
> +   wptr &= ~RB_OVERFLOW;
> /* When a ring buffer overflow happen start parsing interrupt
>  * from the last not overwritten vector (wptr + 16). Hopefully
>  * this should allow us to catchup.
> @@ -3812,7 +3813,6 @@ static u32 r600_get_ih_wptr(struct radeon_device *rdev)
> tmp = RREG32(IH_RB_CNTL);
> tmp |= IH_WPTR_OVERFLOW_CLEAR;
> WREG32(IH_RB_CNTL, tmp);
> -   wptr &= ~RB_OVERFLOW;
> }
> return (wptr & rdev->ih.ptr_mask);
>  }
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index 23ff34a..9e591ad 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -6317,6 +6317,7 @@ static inline u32 si_get_ih_wptr(struct radeon_device 
> *rdev)
> wptr = RREG32(IH_RB_WPTR);
>
> if (wptr & RB_OVERFLOW) {
> +   wptr &= ~RB_OVERFLOW;
> /* When a ring buffer overflow happen start parsing interrupt
>  * from the last not overwritten vector (wptr + 16). Hopefully
>  * this should allow us to catchup.
> @@ -6327,7 +6328,6 @@ static inline u32 si_get_ih_wptr(struct radeon_device 
> *rdev)
> tmp = RREG32(IH_RB_CNTL);
> tmp |= IH_WPTR_OVERFLOW_CLEAR;
> WREG32(IH_RB_CNTL, tmp);
> -   wptr &= ~RB_OVERFLOW;
> }
> return (wptr & rdev->ih.ptr_mask);
>  }
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page

[Alex Deucher]

On Thu, Sep 18, 2014 at 9:22 PM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83996
> Signed-off-by: Michel D?nzer 

Added to my -fixes tree.

Alex

> ---
>  drivers/gpu/drm/radeon/rs400.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
> index 6c1fc33..c5799f16 100644
> --- a/drivers/gpu/drm/radeon/rs400.c
> +++ b/drivers/gpu/drm/radeon/rs400.c
> @@ -221,9 +221,9 @@ void rs400_gart_set_page(struct radeon_device *rdev, 
> unsigned i,
> entry = (lower_32_bits(addr) & PAGE_MASK) |
> ((upper_32_bits(addr) & 0xff) << 4);
> if (flags & RADEON_GART_PAGE_READ)
> -   addr |= RS400_PTE_READABLE;
> +   entry |= RS400_PTE_READABLE;
> if (flags & RADEON_GART_PAGE_WRITE)
> -   addr |= RS400_PTE_WRITEABLE;
> +   entry |= RS400_PTE_WRITEABLE;
> if (!(flags & RADEON_GART_PAGE_SNOOP))
> entry |= RS400_PTE_UNSNOOPED;
> entry = cpu_to_le32(entry);
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 71051] Cannot suspend with radeon drivers.

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

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

--- Comment #12 from Michel D?nzer  ---
(In reply to Hin-Tak Leung from comment #11)
> photo of the double-pointer corruption

Looks like you're using an old version of xf86-video-modesetting, or another
generic driver which doesn't correctly handle 128x128 hardware cursors. Please
use the radeon driver from a current version of xf86-video-ati; with glamor
enabled, that also provides X-Video support.

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

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

[Nishanth Menon]

On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
> On 16/09/14 23:40, Jyri Sarha wrote:
>> The added ti,gpio-gate-clock is a basic clock that can be enabled and
>> disabled trough a gpio output. The DT binding document for the clock
>> is also added. For EPROBE_DEFER handling the registering of the clock
>> has to be delayed until of_clk_get() call time.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  .../bindings/clock/ti/gpio-gate-clock.txt  |   21 ++
>>  drivers/clk/ti/Makefile|2 +-
>>  drivers/clk/ti/gpio.c  |  202 
>> 
>>  3 files changed, 224 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>>  create mode 100644 drivers/clk/ti/gpio.c
> 
> Why is this a TI clock? Sounds like a generic one to me.

Like thread: https://lkml.org/lkml/2014/9/5/284 ?
> 
> In any case, this should go through Mike.
> 
yep - should have been posted independent of this series :).



-- 
Regards,
Nishanth Menon

[Bug 71051] Cannot suspend with radeon drivers.

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

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

--- Comment #11 from Hin-Tak Leung  ---
Created attachment 150881
  --> https://bugzilla.kernel.org/attachment.cgi?id=150881=edit
photo of the double-pointer corruption

It is very confusing - the arrow is fake, and the squashed text cursor 3 lines
above is the correct one. Both are smaller than intended. This double-pointer
is very confusing and worse than the usual 'pointer + block' corruption.
( see https://bugzilla.redhat.com/attachment.cgi?id=937273
in https://bugzilla.redhat.com/show_bug.cgi?id=1141491#c0 )

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

[Bug 71051] Cannot suspend with radeon drivers.

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

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

--- Comment #10 from Hin-Tak Leung  ---
Created attachment 150871
  --> https://bugzilla.kernel.org/attachment.cgi?id=150871=edit
The wake from hibernate, suspend and wake dmesg.

The wake from hibernate, suspend and wake dmesg, mentioned in the last comment.
screen does not turn on until after the 2nd wake.

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

[Bug 71051] Cannot suspend with radeon drivers.

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

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

--- Comment #9 from Hin-Tak Leung  ---
(In reply to Alex Deucher from comment #8)
> Created attachment 150801 [details]
> possible fix for mullins
> 
> This patch may fix Hin-Tak's issue, but won't affect the original reporter.

Yes, it does fix my suspend problem. Thanks for the quick response. Please feel
free to add a 'Tested-By:'.


The screen stays blank after wake on hibernate though, with these messages:

Sep 19 04:42:48 localhost kernel: [drm:cik_ring_test] *ERROR* radeon: ring 1
test failed (scratch(0x3010C)=0xCAFEDEAD)
Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR*
displayport link status failed
Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* clock
recovery failed
Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR*
displayport link status failed
Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* clock
recovery failed

Somehow blindly suspending (by accident, pressing the power button for too
short a duration) aand waking brings it back, interestingly.

The corrupted mouse pointer also changed from the usual 'squashed + block' 
( photo attached to https://bugzilla.redhat.com/show_bug.cgi?id=1141491#c0)
to a phantom double pointer, which is extremely confusing now.

I'll attach the full dmesg of the 'wake from hibernate + suspend + wake from
suspend', and the double pointer picture below. And while I am at it, is there
any patches to get x-video I should try?

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

[Bug 83996] [drm:r100_ring_test] *ERROR* radeon: ring test failed - since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]

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

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

--- Comment #5 from Michel D?nzer  ---
(In reply to comment #4)
> This fixes the bug. Thank you all so much!

Great, thank you for testing it.

> Will I see the commit in -rc6 ?

Not sure it'll make rc6, but hopefully before 3.17 final.

-- 
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/20140919/bb37dd61/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

Tom Stellard  changed:

   What|Removed |Added

 Attachment #106097|0   |1
is obsolete||
 Attachment #106113|0   |1
is obsolete||

--- Comment #92 from Tom Stellard  ---
Created attachment 106530
  --> https://bugs.freedesktop.org/attachment.cgi?id=106530=edit
Fix v5

Can you try this patch?  I've merged Michel's patch with mine and it works on
my Verde.

Even if this patch works for you could you still post the output when running
glxgears?

-- 
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/20140919/7dce49a4/attachment.html>

[Bug 75276] Implement VGPR Register Spilling

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

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

Tom Stellard  changed:

   What|Removed |Added

  Attachment #99254|0   |1
is obsolete||

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

Here is a patch to test.

-- 
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/20140919/3382ce0f/attachment.html>

[PATCH 2/3] drm/radeon: add command submission IDs

[Jerome Glisse]

On Thu, Sep 18, 2014 at 11:11:57PM -0400, Jerome Glisse wrote:
> On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> > > From: Christian K?nig 
> > > 
> > > This patch adds a new 64bit ID as a result to each command submission.
> > 
> > NAK for design reasons.
> > 
> > First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> > I know that hooking up to fence make life easy but this is not how it
> > should be done.
> > 
> > What you want to expose is the per ring 32bit seq value and report to user
> > space the value and the ring id. To handle the wrap around you add a uniq
> > 32bit wrap counter which is incremented every 1 << 30 or some big number
> > seq value number (but must be smaller than 1 << 31). Then you use arithmetic
> > to determine if a cs seq number is done or not (ie the seq wrap around
> > counter diff should not be bigger then 2 or 3) and the seq number should
> > obviously be after again using arithmetic diff like jiffies code.
> > 
> > All this being hidden in the kernel all the user space have to know is :
> > 32 bit seq value per ring
> > 32 bit ring uniq id
> > 32 wrap counter per ring
> > 
> > With such scheme you never allocate anything or worry about any fence.
> > Way simpler and less code.
> > 
> > Cheers,
> > J?r?me
> 
> Because code is clearer than words attached is a patch of what i am thinking
> about. The arithmetic should be right as well as the coherency and proper
> memory barrier. Thought it is completely untested and will require couple
> fixes for properly checking userspace arguments and other aspect (see FIXME
> in patches).
> 
> There is no allocation, it is a pretty small patch, and it provide a fast
> ligthweight solution. While the new ioctl argument and return value can be
> improved (like reporting more information to userspace like for instance
> warning userspace when it is querying very old fences). I think the overall
> design is sound.
> 
> Let me know.

Ok actually after a beer (given that planet express manual for Bender, which
also apply to me, clearly stipulate to expect malfunction if not properly
inebriate) it became clear that by reversing the problem i could make it a
lot simpler. So attached is an even simpler patch that handle gracefully user
space querying for very old fence (ie that could have wrap around).

Code explains it all.

> 
> Cheers,
> J?r?me
> 
> > 
> > 
> > > 
> > > Signed-off-by: Christian K?nig 
> > > ---
> > >  drivers/gpu/drm/radeon/Makefile |   2 +-
> > >  drivers/gpu/drm/radeon/radeon.h |  13 +-
> > >  drivers/gpu/drm/radeon/radeon_cs.c  |  13 ++
> > >  drivers/gpu/drm/radeon/radeon_kms.c |  41 +++
> > >  drivers/gpu/drm/radeon/radeon_seq.c | 229 
> > > 
> > >  include/uapi/drm/radeon_drm.h   |   1 +
> > >  6 files changed, 277 insertions(+), 22 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
> > > 
> > > diff --git a/drivers/gpu/drm/radeon/Makefile 
> > > b/drivers/gpu/drm/radeon/Makefile
> > > index 8cc9f68..21ee928 100644
> > > --- a/drivers/gpu/drm/radeon/Makefile
> > > +++ b/drivers/gpu/drm/radeon/Makefile
> > > @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> > >   rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
> > > \
> > >   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> > >   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o 
> > > \
> > > - radeon_sync.o
> > > + radeon_sync.o radeon_seq.o
> > >  
> > >  # add async DMA block
> > >  radeon-y += \
> > > diff --git a/drivers/gpu/drm/radeon/radeon.h 
> > > b/drivers/gpu/drm/radeon/radeon.h
> > > index b3b4e96..dbfd346 100644
> > > --- a/drivers/gpu/drm/radeon/radeon.h
> > > +++ b/drivers/gpu/drm/radeon/radeon.h
> > > @@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct 
> > > radeon_fence *a,
> > >  }
> > >  
> > >  /*
> > > + * Userspace command submission identifier generation
> > > + */
> > > +struct radeon_seq;
> > > +
> > > +uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence 
> > > *fence);
> > > +struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t 
> > > id);
> > > +void radeon_seq_destroy(struct radeon_seq **seq);
> > > +
> > > +/*
> > >   * Tiling registers
> > >   */
> > >  struct radeon_surface_reg {
> > > @@ -946,7 +955,9 @@ struct radeon_vm_manager {
> > >   * file private structure
> > >   */
> > >  struct radeon_fpriv {
> > > - struct radeon_vmvm;
> > > + struct radeon_vmvm;
> > > + struct mutexseq_lock;
> > > + struct radeon_seq   *seq;
> > >  };
> > >  
> > >  /*
> > > diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> > > b/drivers/gpu/drm/radeon/radeon_cs.c
> > > index b8f20a5..0c0f0b3 100644
> > > --- a/drivers/gpu/drm/radeon/radeon_cs.c
> > > +++ 

[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io

[Bjorn Helgaas]

On Fri, Sep 19, 2014 at 09:26:58AM +1000, Dave Airlie wrote:
> On 13 September 2014 00:28, Bjorn Helgaas  wrote:
> > On Fri, Sep 12, 2014 at 5:19 AM, Bruno Pr?mont
> >  wrote:
> >> Bjorn,
> >>
> >> What is missing to get these two patches pushed to Linus?
> >
> > Sorry, I've been working on some other regressions and overlooked this
> > one.  If you open a bugzilla report and mark it as a regression, that
> > will help keep this on my radar.
> 
> My MBP is crying? can we get these merged, I can handle if if you want
> to ack them for me!

Yep, it's in linux-next and I'll send Linus a pull request for the tag [1]
tomorrow.  I meant to send it tonight, but I had to fix my for-linus branch
to remove a duplicate commit and I don't want to send the pull request
immediately afterwards.

Bjorn

[1] 
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/tag/?h=for-linus=pci-v3.17-fixes-2

[PATCH 2/3] drm/radeon: add command submission IDs

[Jerome Glisse]

On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> > From: Christian K?nig 
> > 
> > This patch adds a new 64bit ID as a result to each command submission.
> 
> NAK for design reasons.
> 
> First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> I know that hooking up to fence make life easy but this is not how it
> should be done.
> 
> What you want to expose is the per ring 32bit seq value and report to user
> space the value and the ring id. To handle the wrap around you add a uniq
> 32bit wrap counter which is incremented every 1 << 30 or some big number
> seq value number (but must be smaller than 1 << 31). Then you use arithmetic
> to determine if a cs seq number is done or not (ie the seq wrap around
> counter diff should not be bigger then 2 or 3) and the seq number should
> obviously be after again using arithmetic diff like jiffies code.
> 
> All this being hidden in the kernel all the user space have to know is :
> 32 bit seq value per ring
> 32 bit ring uniq id
> 32 wrap counter per ring
> 
> With such scheme you never allocate anything or worry about any fence.
> Way simpler and less code.
> 
> Cheers,
> J?r?me

Because code is clearer than words attached is a patch of what i am thinking
about. The arithmetic should be right as well as the coherency and proper
memory barrier. Thought it is completely untested and will require couple
fixes for properly checking userspace arguments and other aspect (see FIXME
in patches).

There is no allocation, it is a pretty small patch, and it provide a fast
ligthweight solution. While the new ioctl argument and return value can be
improved (like reporting more information to userspace like for instance
warning userspace when it is querying very old fences). I think the overall
design is sound.

Let me know.

Cheers,
J?r?me

> 
> 
> > 
> > Signed-off-by: Christian K?nig 
> > ---
> >  drivers/gpu/drm/radeon/Makefile |   2 +-
> >  drivers/gpu/drm/radeon/radeon.h |  13 +-
> >  drivers/gpu/drm/radeon/radeon_cs.c  |  13 ++
> >  drivers/gpu/drm/radeon/radeon_kms.c |  41 +++
> >  drivers/gpu/drm/radeon/radeon_seq.c | 229 
> > 
> >  include/uapi/drm/radeon_drm.h   |   1 +
> >  6 files changed, 277 insertions(+), 22 deletions(-)
> >  create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
> > 
> > diff --git a/drivers/gpu/drm/radeon/Makefile 
> > b/drivers/gpu/drm/radeon/Makefile
> > index 8cc9f68..21ee928 100644
> > --- a/drivers/gpu/drm/radeon/Makefile
> > +++ b/drivers/gpu/drm/radeon/Makefile
> > @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> > rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
> > \
> > trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> > ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o 
> > \
> > -   radeon_sync.o
> > +   radeon_sync.o radeon_seq.o
> >  
> >  # add async DMA block
> >  radeon-y += \
> > diff --git a/drivers/gpu/drm/radeon/radeon.h 
> > b/drivers/gpu/drm/radeon/radeon.h
> > index b3b4e96..dbfd346 100644
> > --- a/drivers/gpu/drm/radeon/radeon.h
> > +++ b/drivers/gpu/drm/radeon/radeon.h
> > @@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct 
> > radeon_fence *a,
> >  }
> >  
> >  /*
> > + * Userspace command submission identifier generation
> > + */
> > +struct radeon_seq;
> > +
> > +uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence 
> > *fence);
> > +struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t id);
> > +void radeon_seq_destroy(struct radeon_seq **seq);
> > +
> > +/*
> >   * Tiling registers
> >   */
> >  struct radeon_surface_reg {
> > @@ -946,7 +955,9 @@ struct radeon_vm_manager {
> >   * file private structure
> >   */
> >  struct radeon_fpriv {
> > -   struct radeon_vmvm;
> > +   struct radeon_vmvm;
> > +   struct mutexseq_lock;
> > +   struct radeon_seq   *seq;
> >  };
> >  
> >  /*
> > diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> > b/drivers/gpu/drm/radeon/radeon_cs.c
> > index b8f20a5..0c0f0b3 100644
> > --- a/drivers/gpu/drm/radeon/radeon_cs.c
> > +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> > @@ -413,6 +413,19 @@ static void radeon_cs_parser_fini(struct 
> > radeon_cs_parser *parser, int error, bo
> > unsigned i;
> >  
> > if (!error) {
> > +   if (parser->chunk_flags &&
> > +   parser->chunk_flags->length_dw > 4) {
> > +   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
> > +   uint32_t __user *to = parser->chunk_flags->user_ptr;
> > +   uint64_t id;
> > +
> > +   mutex_lock(>seq_lock);
> > +   id = radeon_seq_push(>seq, parser->ib.fence);
> > +   mutex_unlock(>seq_lock);
> > +
> > +   copy_to_user([3], ,