[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #10 from Andy Furniss  ---
Built llvm with GCC now and Tentative fix works for me.

-- 
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/20141118/875c6269/attachment.html>

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #9 from Andy Furniss  ---
oops, failed there trying to obsolete - didn't mean to do comment 8

-- 
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/20141118/b4b50e5c/attachment-0001.html>

[Bug 86432] llvm Unreal Elemental rendering regression

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

t;#33 0x55c2e2 main (/usr/bin/clang+0x55c2e2)
>#34 0x7fa42a26b36d __libc_start_main 
>/sources/eglibc-2.15/csu/libc-start.c:258:0
>#35 0x5545d5 _start (/usr/bin/clang+0x5545d5)
>Stack dump:
>0.  Program arguments: /usr/bin/clang -cc1 -triple 
>x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name 
>AMDGPUISelLowering.cpp -mrelocation-model pic -pic-level 2 -mthread-model 
>posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables 
>-fuse-init-array -target-cpu x86-64 -target-linker-version 2.23 
>-momit-leaf-frame-pointer -dwarf-column-info -ffunction-sections 
>-fdata-sections -coverage-file 
>/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.o 
>-resource-dir /usr/bin/../lib/clang/3.6.0 -dependency-file 
>/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.d.tmp 
>-MP -MT 
>/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.o -MT 
>/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.d -D 
>_DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D 
>__STDC_LIMIT_MACROS -I /mnt/sdb1/Src64/llvm/include -I 
>/mnt/sdb1/Src64/llvm/lib/Target/R600 -internal-isystem 
>/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2
> -internal-isystem 
>/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu
> -internal-isystem 
>/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
> -internal-isystem /usr/local/include -internal-isystem 
>/usr/bin/../lib/clang/3.6.0/include -internal-externc-isystem /include 
>-internal-externc-isystem /usr/include -O3 -Wcast-qual -Wno-long-long -Wall -W 
>-Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default 
>-Wno-uninitialized -Wno-missing-field-initializers -Wno-comment -pedantic 
>-std=c++11 -fdeprecated-macro -fdebug-compilation-dir 
>/mnt/sdb1/Src64/llvm/lib/Target/R600 -ferror-limit 19 -fmessage-length 239 
>-fvisibility-inlines-hidden -mstackrealign -fno-rtti -fobjc-runtime=gcc 
>-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp 
>-o /mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.o 
>-x c++ AMDGPUISelLowering.cpp 
>1.  AMDGPUISelLowering.cpp:97:1: current parser token 'EVT'
>2.  AMDGPUISelLowering.cpp:87:27: LLVM IR generation of declaration 
>'llvm::AMDGPUTargetLowering::getEquivalentMemType'
>3.  AMDGPUISelLowering.cpp:87:27: Generating code for declaration 
>'llvm::AMDGPUTargetLowering::getEquivalentMemType'
>clang: error: unable to execute command: Aborted
>clang: error: clang frontend command failed due to signal (use -v to see 
>invocation)
>clang version 3.6.0 (http://llvm.org/git/clang.git 
>f98071d4eacb44e7f36b4fd9878f415524a6efda) (http://llvm.org/git/llvm.git 
>ab9c404bbdceead0ced57d5e805eeeb28941de35)
>Target: x86_64-unknown-linux-gnu
>Thread model: posix
>clang: note: diagnostic msg: PLEASE submit a bug report to 
>http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
>and associated run script.
>clang: note: diagnostic msg: 
>
>
>PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>Preprocessed source(s) and associated run script(s) are located at:
>clang: note: diagnostic msg: /tmp/AMDGPUISelLowering-03f4c1.cpp
>clang: note: diagnostic msg: /tmp/AMDGPUISelLowering-03f4c1.sh
>clang: note: diagnostic msg: 
>
>
>/bin/rm: cannot remove 
>â/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.d.tmpâ:
> No such file or directory
>/mnt/sdb1/Src64/llvm/Makefile.rules:1514: recipe for target 
>'/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.o' 
>failed
>make[3]: *** 
>[/mnt/sdb1/Src64/llvm/lib/Target/R600/Release+Asserts/AMDGPUISelLowering.o] 
>Error 1
>make[3]: Leaving directory '/mnt/sdb1/Src64/llvm/lib/Target/R600'
>/mnt/sdb1/Src64/llvm/Makefile.rules:932: recipe for target 'R600/.makeall' 
>failed
>make[2]: *** [R600/.makeall] Error 2
>make[2]: Leaving directory '/mnt/sdb1/Src64/llvm/lib/Target'
>/mnt/sdb1/Src64/llvm/Makefile.rules:932: recipe for target 'Target/.makeall' 
>failed
>make[1]: *** [Target/.makeall] Error 2
>make[1]: Leaving directory '/mnt/sdb1/Src64/llvm/lib'
>/mnt/sdb1/Src64/llvm/Makefile.rules:883: recipe for target 'all' failed
>make: *** [all] Error 1
>

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

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #7 from Andy Furniss  ---
(In reply to Andy Furniss from comment #6)
> Created attachment 109694 [details]
> clang build fail with Tentative fix
> 
> I get a build fail with this - I build OK same tree without patch.
> 
> clang is roughly from same tree, though I deleted tools/clang when doing the
> bisect and haven't reinstated yet.

Never mind - I've upgraded GCC - for whatever reason it didn't care or error
initially even though I cleaned + git clean -dfx + git reset hard
origin/master.

Now I do it and it bails early in the configure -

We detected a missing feature in the standard C++ library that was known to be
missing in libstdc++4.6 and implemented in libstdc++4.7. There are numerous
C++11 problems with 4.6's library, and we don't support GCCs or libstdc++ older
than 4.7. You will need to update your system and ensure Clang uses the newer
standard library.

Which is confusing as I've just upgraded from gcc 4.8.3 to 4.9.2.

Maybe I need to try rebuilding llvm/clang with gcc.

-- 
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/20141118/d943a267/attachment.html>

[PATCH 2/2] drm/exynos: use drm generic mmap interface

[Tobias Jakobi]

Inki Dae wrote:
> Hi Tomasz,
> 
> Yes, of course.
> 
> We will fix it soon. For this, I mentioned earlier,
> http://web.archiveorange.com/archive/v/hhSc574WhqJAKgdBq7KL
> 
> Thanks,
> Inki Dae


Hello,

it looks like libdrm git master is still using the EXYNOS_GEM_MMAP ioctl
that was removed by this patch. Is there any news on the patches for libdrm?

With best wishes,
Tobias

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #6 from Andy Furniss  ---
Created attachment 109694
  --> https://bugs.freedesktop.org/attachment.cgi?id=109694=edit
clang build fail with Tentative fix

I get a build fail with this - I build OK same tree without patch.

clang is roughly from same tree, though I deleted tools/clang when doing the
bisect and haven't reinstated yet.

-- 
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/20141118/d8220ec6/attachment-0001.html>

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Michael Marineau]

On 3.18-rc kernel's I have been intermittently experiencing GPU
lockups shortly after startup, accompanied with one or both of the
following errors:

nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
nouveau E[ DRM] GPU lockup - switching to software fbcon

I was able to trace the issue with bisect to commit
809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
fences for readable objects". The lockups appear to have cleared up
since reverting that and a few related followup commits:

809e9447: "drm/nouveau: use shared fences for readable objects"
055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
nouveau_fence_sync"
15a996bb: "drm/nouveau: assign fence_chan->name correctly"

For reference here is what the driver reports about my hardware:
nouveau :01:00.0: enabling device (0006 -> 0007)
nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0e7290a2
nouveau  [  DEVICE][:01:00.0] Chipset: GK107 (NVE7)
nouveau  [  DEVICE][:01:00.0] Family : NVE0
nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
nouveau  [   VBIOS][:01:00.0] ... appears to be valid
nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
nouveau  [   VBIOS][:01:00.0] BIT signature found
nouveau  [   VBIOS][:01:00.0] version 80.07.c7.04.01
nouveau :01:00.0: irq 39 for MSI/MSI-X
nouveau  [ PMC][:01:00.0] MSI interrupts enabled
nouveau  [ PFB][:01:00.0] RAM type: GDDR5
nouveau  [ PFB][:01:00.0] RAM size: 2048 MiB
nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
nouveau  [  PTHERM][:01:00.0] FAN control: none / external
nouveau  [  PTHERM][:01:00.0] fan management: automatic
nouveau  [  PTHERM][:01:00.0] internal sensor: yes
nouveau  [ CLK][:01:00.0] 07: core 270-405 MHz memory 838 MHz
nouveau  [ CLK][:01:00.0] 0a: core 270-925 MHz memory 1560 MHz
nouveau  [ CLK][:01:00.0] 0e: core 270-925 MHz memory 4000 MHz
nouveau  [ CLK][:01:00.0] 0f: core 270-925 MHz memory 5016 MHz
nouveau  [ CLK][:01:00.0] --: core 405 MHz memory 680 MHz
nouveau  [ DRM] VRAM: 2048 MiB
nouveau  [ DRM] GART: 1048576 MiB
nouveau  [ DRM] TMDS table version 2.0
nouveau  [ DRM] DCB version 4.0
nouveau  [ DRM] DCB outp 00: 04810fb6 0f230010
nouveau  [ DRM] DCB outp 01: 01821fd6 0f420020
nouveau  [ DRM] DCB outp 02: 01021f12 00020020
nouveau  [ DRM] DCB outp 03: 08832fc6 0f420010
nouveau  [ DRM] DCB outp 04: 08032f02 00020010
nouveau  [ DRM] DCB outp 05: 02843f62 00020010
nouveau  [ DRM] DCB conn 00: 00020047
nouveau  [ DRM] DCB conn 01: 02208146
nouveau  [ DRM] DCB conn 02: 01104246
nouveau  [ DRM] DCB conn 03: 00410361
nouveau  [ DRM] MM: using COPY for buffer copies
nouveau  [ DRM] allocated 2880x1800 fb: 0x8, bo 88046b26f800

-- 
Michael Marineau

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Inki Dae]

On 2014년 11월 18일 12:20, Inki Dae wrote:
> This patch fixes a infinite loop issue incurred when
> it doesn't have a pair of crtc and connector drivers,
> which was reported by Kevin Hilman like below,
>   http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
> 
> cdev->conn_dev could be NULL by exynos_drm_component_del call in case
> that connector driver is failed while probing after compoments to crtc
> and connector drivers are added to specific drm_compoment_list.
> In this case, exynos_drm_match_add returns -EPROBE_DEFER error and
> Exynos drm driver will try the defered probe over and over again.
> 
> This patch makes the deferred probe is tried up to 3 times in maximum.
> However, this is considered only for Exynos drm so I think other SoC
> drivers could also produce same issue. Therefore, the best way to resolve
> this issue, infinite loop incurred by defered probe, would be that dd core
> is fixed up corrrectly.

Ignore this patch. I will post other patch set soon, which supports full
separated sub driver modules.

Thanks,
Inki Dae

> 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index eab12f0..4d84f3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -38,6 +38,8 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> +#define MAX_TRY_PROBE_DEFER  3
> +
>  static struct platform_device *exynos_drm_pdev;
>  
>  static DEFINE_MUTEX(drm_component_lock);
> @@ -481,6 +483,7 @@ static struct component_match 
> *exynos_drm_match_add(struct device *dev)
>   struct component_match *match = NULL;
>   struct component_dev *cdev;
>   unsigned int attach_cnt = 0;
> + static unsigned int try_probe_defer;
>  
>   mutex_lock(_component_lock);
>  
> @@ -527,6 +530,11 @@ out_lock:
>  
>   mutex_unlock(_component_lock);
>  
> + if (++try_probe_defer > MAX_TRY_PROBE_DEFER) {
> + try_probe_defer = 0;
> + return ERR_PTR(-ENODEV);
> + }
> +
>   return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
>  }
>  
> 

[Intel-gfx] [PATCH 2/5] drm: add helper to get crtc timings (v3)

[Ville Syrjälä]

On Tue, Nov 18, 2014 at 09:12:49AM -0800, Matt Roper wrote:
> From: Gustavo Padovan 
> 
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
> 
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
> 
> v3 (by Matt):
>  - Add missing kerneldoc (Daniel)
>  - Use drm_mode_copy() (Jani)
> 
> Cc: dri-devel at lists.freedesktop.org
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c   | 32 ++--
>  drivers/gpu/drm/i915/intel_display.c |  6 +++---
>  include/drm/drm_crtc.h   |  2 ++
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 56737e7..be1a485 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>  EXPORT_SYMBOL(drm_mode_set_config_internal);
>  
>  /**
> + * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
> + * @mode: mode to query
> + * @hdisplay: hdisplay value to fill in
> + * @vdisplay: vdisplay value to fill in
> + *
> + * The vdisplay value will be doubled if the specified mode is a stereo mode 
> of
> + * the appropriate layout.
> + */
> +void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> + int *hdisplay, int *vdisplay)
> +{
> + struct drm_display_mode adjusted;
> +
> + drm_mode_copy(, mode);
> + drm_mode_stereo_double();

Hmm. The mode may not have the crtc_ timings populated at all here, so
drm_mode_stereo_double() might just double some zeroes/garbage.

I don't recall anymore if I had some clever idea how to do this. I was
hoping we can avoid duplicating the stereo doubling logic in more than
once place, but maybe it's just easier to admit defeat?

I guess the options are:
1) duplciate some stereo doubling logic
2) populate the required crtc_ timings here as well
3) keep using drm_mode_set_crtcinfo() but remove the offending stuff
   from the copied mode so that it doesn't interfere with the results
4) add more flags to drm_mode_set_crtcinfo() that prevent the offending
   stuff from affecting the results

> + *hdisplay = adjusted.crtc_hdisplay;
> + *vdisplay = adjusted.crtc_vdisplay;
> +}
> +EXPORT_SYMBOL(drm_crtc_get_hv_timing);
> +
> +/**
>   * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
>   * CRTC viewport
>   * @crtc: CRTC that framebuffer will be displayed on
> @@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc 
> *crtc,
>  {
>   int hdisplay, vdisplay;
>  
> - hdisplay = mode->hdisplay;
> - vdisplay = mode->vdisplay;
> -
> - if (drm_mode_is_stereo(mode)) {
> - struct drm_display_mode adjusted = *mode;
> -
> - drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
> - hdisplay = adjusted.crtc_hdisplay;
> - vdisplay = adjusted.crtc_vdisplay;
> - }
> + drm_crtc_get_hv_timing(mode, , );
>  
>   if (crtc->invert_dimensions)
>   swap(hdisplay, vdisplay);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 320bf4c..a967623 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>* computation to clearly distinguish it from the adjusted mode, which
>* can be changed by the connectors in the below retry loop.
>*/
> - drm_mode_set_crtcinfo(_config->requested_mode, CRTC_STEREO_DOUBLE);
> - pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
> - pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
> + drm_crtc_get_hv_timing(_config->requested_mode,
> +_config->pipe_src_w,
> +_config->pipe_src_h);
>  
>  encoder_retry:
>   /* Ensure the port clock defaults are reset when retrying. */
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7b28ab0..23236f6 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
>  extern void drm_plane_cleanup(struct drm_plane *plane);
>  extern unsigned int drm_plane_index(struct drm_plane *plane);
>  extern void drm_plane_force_disable(struct drm_plane *plane);
> +extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> +int *hdisplay, int *vdisplay);
>  extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
>  int x, int y,
>  const struct drm_display_mode *mode,
> -- 
> 1.8.5.1
> 
> ___
> Intel-gfx mailing list
> 

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #5 from Marek Olšák  ---
(In reply to Matt Arsenault from comment #4)
> Created attachment 109693 [details] [review]
> Tentative fix
> 
> I think this is because I was assuming this would only ever see ordered
> comparisons. This tries disabling the combine for unordered compares

Your patch fixes this issue.

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

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

Matt Arsenault  changed:

   What|Removed |Added

 CC||arsenm2 at gmail.com

--- Comment #4 from Matt Arsenault  ---
Created attachment 109693
  --> https://bugs.freedesktop.org/attachment.cgi?id=109693=edit
Tentative fix

I think this is because I was assuming this would only ever see ordered
comparisons. This tries disabling the combine for unordered compares

-- 
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/20141118/a319ad4f/attachment.html>

[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

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

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

jbart  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #3 from jbart  ---
I rescind my previous comment, the same issue has happened again. The bug is
spurious, I can't reliably reproduce it yet.

As for bisection I can definitely give it a shot, but it's pointless until I
can reproduce the issue at will...

-- 
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/20141118/c790b0f5/attachment.html>

[BUG] blocked task after exynos_drm_init

[Inki Dae]

On 2014년 11월 18일 19:42, Andrzej Hajda wrote:
> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> On last next (next-20141104, next-20141105) booting locks after
>> initializing Exynos DRM (Trats2 board):
>>
>> [2.028283] [drm] Initialized drm 1.1.0 20060810
>> [  240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
>> [  240.510825]   Not tainted 3.18.0-rc3-next-20141105 #794
>> [  240.516418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>> [  240.524173] swapper/0   D c052534c 0 1  0 0x
>> [  240.530527] [] (__schedule) from [] 
>> (schedule_preempt_disabled+0x14/0x20)
>> [  240.539030] [] (schedule_preempt_disabled) from [] 
>> (mutex_lock_nested+0x1c4/0x464)
>> [  240.548320] [] (mutex_lock_nested) from [] 
>> (__driver_attach+0x48/0x98)
>> [  240.556562] [] (__driver_attach) from [] 
>> (bus_for_each_dev+0x54/0x88)
>> [  240.564717] [] (bus_for_each_dev) from [] 
>> (bus_add_driver+0xe4/0x200)
>> [  240.572876] [] (bus_add_driver) from [] 
>> (driver_register+0x78/0xf4)
>> [  240.580864] [] (driver_register) from [] 
>> (exynos_drm_platform_probe+0x34/0x234)
>> [  240.589890] [] (exynos_drm_platform_probe) from [] 
>> (platform_drv_probe+0x48/0xa4)
>> [  240.599090] [] (platform_drv_probe) from [] 
>> (driver_probe_device+0x13c/0x37c)
>> [  240.607940] [] (driver_probe_device) from [] 
>> (__driver_attach+0x94/0x98)
>> [  240.616360] [] (__driver_attach) from [] 
>> (bus_for_each_dev+0x54/0x88)
>> [  240.624517] [] (bus_for_each_dev) from [] 
>> (bus_add_driver+0xe4/0x200)
>> [  240.632679] [] (bus_add_driver) from [] 
>> (driver_register+0x78/0xf4)
>> [  240.640667] [] (driver_register) from [] 
>> (exynos_drm_init+0x70/0xa0)
>> [  240.648739] [] (exynos_drm_init) from [] 
>> (do_one_initcall+0xac/0x1f0)
>> [  240.656914] [] (do_one_initcall) from [] 
>> (kernel_init_freeable+0x10c/0x1d8)
>> [  240.665591] [] (kernel_init_freeable) from [] 
>> (kernel_init+0x8/0xec)
>> [  240.673661] [] (kernel_init) from [] 
>> (ret_from_fork+0x14/0x2c)
>> [  240.681196] 3 locks held by swapper/0/1:
>> [  240.685091]  #0:  (>mutex){..}, at: [] 
>> __driver_attach+0x48/0x98
>> [  240.692732]  #1:  (>mutex){..}, at: [] 
>> __driver_attach+0x58/0x98
>> [  240.700367]  #2:  (>mutex){..}, at: [] 
>> __driver_attach+0x48/0x98
> 
> 
> This is caused by patch moving platform devices to
> /sys/devices/platform[1]. Since this patch registering platform
> drivers/devices in probe of platform device causes deadlocks. I guess
> now all driver registration should be moved to exynos_drm_init and it
> seems better location for it IMHO.

Thanks. It might be a chance that we could separate sub drivers of
Exynos drm into independent modules so that they can be called
independently because if we move them to exynos_drm_init then the
deferred probe wouldn't work correctly.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
> [1]: http://www.spinics.net/lists/devicetree/msg56101.html
> 
> 
> 
>>
>> Full dmesg and config attached.
>>
>> Best regards,
>> Krzysztof
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Inki Dae]

On 2014년 11월 18일 19:23, Javier Martinez Canillas wrote:
> Hello Inki,
> 
>> Right, but at least, we could avoid kernel booting failure which is very
>> critical. Please know that this patch is temporary to avoid the kernel
>> booting failure although deferred probe request of Exynos drm could be
>> broken. For this, I will look into dd core to find out more generic way:
>> I suspect that this might be incurred in case that a driver is probed in
>> probe context of other driver or it might be really dd core bug.
>>
> 
> I gave a try to your patch on top of today's linux-next and I still
> see the same boot failure reported by Kevin on a Exynos5420 Peach Pit
> so $subject does not fix the issue. The boot message is [0] fyi.
> 
> By digging a bit I noticed that this happens when the
> exynos_drm_platform_probe() calls platform_driver_register() to
> register the Exynos fimd platform driver. The problem is that in
> __driver_attach() the call to device_lock(dev->parent) never returns
> and the thread sleeps forever waiting for the device parent mutex to
> be released.
> 
> Do you have any ideas why this could happen?

As I mentioned above, I guess this issue could be incurred when a driver
is probed in probe context of other driver. Actually, we had faced with
same issue but we couldn't see this issue anymore for some time. Anyway,
we need more checking.

Thanks,
Inki Dae

> 
> If I modify __driver_attach() to only grab the device lock and not its
> parent lock, then the thread is able to hold its own mutex and the
> platform driver registration succeeds but then I see the infinite loop
> that was reported before and the workaround in $subject indeed avoids
> to happen.
> 
> So we have two issues here and your patch is only a workaround for the later.
> 
> Best regards,
> Javier
> 
> [0]:
> [1.324091] [drm] Initialized drm 1.1.0 20060810
> [  240.158665] random: nonblocking pool is initialized
> [  240.162202] INFO: task swapper/0:1 blocked for more than 120 seconds.
> [  240.168493]   Not tainted 3.18.0-rc4-next-20141117-1-g85466f9 #22
> [  240.175256] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  240.183064] swapper/0   D c045bb00 0 1  0 0x
> [  240.189410] [] (__schedule) from []
> (schedule_preempt_disabled+0x14/0x20)
> [  240.197904] [] (schedule_preempt_disabled) from
> [] (__mutex_lock_slowpath+0x19c/0x3f4)
> [  240.207531] [] (__mutex_lock_slowpath) from []
> (mutex_lock+0xc/0x24)
> [  240.215599] [] (mutex_lock) from []
> (__driver_attach+0x44/0x90)
> [  240.223239] [] (__driver_attach) from []
> (bus_for_each_dev+0x54/0x88)
> [  240.231387] [] (bus_for_each_dev) from []
> (bus_add_driver+0xd8/0x1cc)
> [  240.239541] [] (bus_add_driver) from []
> (driver_register+0x78/0xf4)
> [  240.247523] [] (driver_register) from []
> (exynos_drm_platform_probe+0x34/0x188)
> [  240.256546] [] (exynos_drm_platform_probe) from
> [] (platform_drv_probe+0x48/0x98)
> [  240.265739] [] (platform_drv_probe) from []
> (driver_probe_device+0x114/0x234)
> [  240.274588] [] (driver_probe_device) from []
> (__driver_attach+0x8c/0x90)
> [  240.283003] [] (__driver_attach) from []
> (bus_for_each_dev+0x54/0x88)
> [  240.291158] [] (bus_for_each_dev) from []
> (bus_add_driver+0xd8/0x1cc)
> [  240.299311] [] (bus_add_driver) from []
> (driver_register+0x78/0xf4)
> [  240.307293] [] (driver_register) from []
> (exynos_drm_init+0x84/0xd0)
> [  240.315362] [] (exynos_drm_init) from []
> (do_one_initcall+0x80/0x1d0)
> [  240.323521] [] (do_one_initcall) from []
> (kernel_init_freeable+0x108/0x1d4)
> [  240.332191] [] (kernel_init_freeable) from []
> (kernel_init+0x8/0xe4)
> [  240.340261] [] (kernel_init) from []
> (ret_from_fork+0x14/0x3c)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

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

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

--- Comment #6 from Andreas Grois  ---
Created attachment 109679
  --> https://bugs.freedesktop.org/attachment.cgi?id=109679=edit
Screenshot of HUD with drm-next-3.19 and Mesa from git

I've tested the latest git version of mesa combined with a drm-next-3.19
kernel, and indeed the issue seems to be fixed with this combination.
There are some very minor stutters still, but those are hardly noticable and
I'm not certain if they are related to the bug, or caused by something else
(disk activity,...).

-- 
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/20141118/127bbe8a/attachment.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Gustavo Padovan]

2014-11-18 Kevin Hilman :

> Javier Martinez Canillas  writes:
> 
> > The Exynos DRM driver register its sub-devices platform drivers in
> > the probe function but after commit 43c0767 ("of/platform: Move
> > platform devices under /sys/devices/platform"), this is causing
> > a deadlock in __driver_attach(). Fix this by moving the platform
> > drivers registration to exynos_drm_init().
> >
> > Suggested-by: Andrzej Hajda 
> > Signed-off-by: Javier Martinez Canillas 
> > ---
> >
> > This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman 
> > [1].
> >
> > Inki Dae said that he will fix it property by separating the Exynos DRM
> > driver in different sub-modules but I post this patch as RFC anyways so
> > others can test if this fixes their boot issue.
> 
> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
> it proceeds to panic in the workqueue code called by the asoc max98090
> codec[1].
> 
> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
> but I still don't have display output.
> 
> Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
> would really be nice if your linux-next work was tested on these
> publically-available 542x/5800 platforms (peach-pi, peach-pit,
> odroid-xu3) which would also allow lots of others to help you test and
> validate.

It would also be good to add drm-exynos-next to the daily linux-next build.
Currently drm-exynos-next is ahead of linux-next. This patch from Javier for
example only applies on linux-next.

Gustavo

[PATCH 1/5] drm: add helper to get crtc timings (v4)

[Matt Roper]

From: Gustavo Padovan 

We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.

v2 (by Matt): Use new stereo doubling function (suggested by Ville)

v3 (by Matt):
 - Add missing kerneldoc (Daniel)
 - Use drm_mode_copy() (Jani)

v4 (by Matt):
 - Drop stereo doubling function again; add 'stereo only' flag
   to drm_mode_set_crtcinfo() instead (Ville)

Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c   | 32 ++--
 drivers/gpu/drm/drm_modes.c  | 24 ++--
 drivers/gpu/drm/i915/intel_display.c |  6 +++---
 include/drm/drm_crtc.h   |  2 ++
 include/drm/drm_modes.h  |  3 +++
 5 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..6202611 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set 
*set)
 EXPORT_SYMBOL(drm_mode_set_config_internal);

 /**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+   int *hdisplay, int *vdisplay)
+{
+   struct drm_display_mode adjusted;
+
+   drm_mode_copy(, mode);
+   drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE_ONLY);
+   *hdisplay = adjusted.crtc_hdisplay;
+   *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
  * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
  * CRTC viewport
  * @crtc: CRTC that framebuffer will be displayed on
@@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 {
int hdisplay, vdisplay;

-   hdisplay = mode->hdisplay;
-   vdisplay = mode->vdisplay;
-
-   if (drm_mode_is_stereo(mode)) {
-   struct drm_display_mode adjusted = *mode;
-
-   drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
-   hdisplay = adjusted.crtc_hdisplay;
-   vdisplay = adjusted.crtc_vdisplay;
-   }
+   drm_crtc_get_hv_timing(mode, , );

if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..fd5479b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -765,18 +765,22 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, 
int adjust_flags)
}
}

-   if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
-   p->crtc_vdisplay *= 2;
-   p->crtc_vsync_start *= 2;
-   p->crtc_vsync_end *= 2;
-   p->crtc_vtotal *= 2;
+   if (!(adjust_flags & CRTC_NO_DBLSCAN)) {
+   if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
+   p->crtc_vdisplay *= 2;
+   p->crtc_vsync_start *= 2;
+   p->crtc_vsync_end *= 2;
+   p->crtc_vtotal *= 2;
+   }
}

-   if (p->vscan > 1) {
-   p->crtc_vdisplay *= p->vscan;
-   p->crtc_vsync_start *= p->vscan;
-   p->crtc_vsync_end *= p->vscan;
-   p->crtc_vtotal *= p->vscan;
+   if (!(adjust_flags & CRTC_NO_VSCAN)) {
+   if (p->vscan > 1) {
+   p->crtc_vdisplay *= p->vscan;
+   p->crtc_vsync_start *= p->vscan;
+   p->crtc_vsync_end *= p->vscan;
+   p->crtc_vtotal *= p->vscan;
+   }
}

if (adjust_flags & CRTC_STEREO_DOUBLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
 * computation to clearly distinguish it from the adjusted mode, which
 * can be changed by the connectors in the below retry loop.
 */
-   drm_mode_set_crtcinfo(_config->requested_mode, CRTC_STEREO_DOUBLE);
-   pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
-   pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
+   drm_crtc_get_hv_timing(_config->requested_mode,
+  _config->pipe_src_w,
+  _config->pipe_src_h);

 encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h 

[PATCH v13 3/3] 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

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: None

Changes in v13: 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 v13 2/3] 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

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: None

Changes in v13: 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 v13 1/3] 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 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
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 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend.

Changes in v12:
- fix compile problem with drm-next
Adviced by Daniel Kurtz
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem

Changes in v13:
- fix vop compile warning.
Adviced by Daniel Vetter
- directly call rockchip_drm_load before register instead of
call ->load at the middle of drm register.

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  485 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1459 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  201 
 14 files changed, 3034 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

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f..3f1624b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ 

[PATCH v13 0/3] 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. Future patches will add additional encoders/connectors,
such as eDP, 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.
- add vop 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 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem.

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.
- fix mail info style.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend

Changes in v12:
- fix compile problem with drm-next
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem

Changes in v13:
- fix vop compile warning.
Adviced by Daniel Vetter
- directly call rockchip_drm_load before register instead of
call ->load at the middle of drm register.

Mark yao (3):
  drm: rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  485 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  294 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1459 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  201 +++
 16 files changed, 3111 insertions(+)

-- 
1.7.9.5

[PATCH] drm/i2c: tda998x: Allow for different audio sample rates

[Russell King - ARM Linux]

On Tue, Nov 18, 2014 at 05:39:30PM +, Andrew Jackson wrote:
> On HDMI, the audio data are carried across the HDMI link which is
> driven by the TDMS clock. The TDMS clock is dependent on the video pixel
> rate.
> 
> This patch sets the denominator (Cycle Time Stamp) appropriately
> allowing the driver to send audio to a wider range of HDMI sinks
> (i.e. monitors).

This is actually pointless, because we don't use "manual" CTS mode.

If the clocks for the video and audio are coherent, then you can program
both the N and CTS values to allow the sink to properly recover the
synchronous audio clock.

However, in most cases, the audio and video clocks are not coherent, and
since the recovered audio clock has to match the source audio clock, the
only way this can be done is by the TDA998x (or in fact other HDMI
encoder) to measure the audio clock rate and generate the CTS value
itself.

This is the mode we drive the TDA998x - so the programmed CTS value is
irrelevant.

See the HDMI spec, section 7.2 for a discussion about this, especially
non-coherent clocks.

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

[PATCH 2/2] drm/radeon: Move radeon_cursor_move(_locked) to replace forward declaration

[Michel Dänzer]

From: Michel Dänzer 

No functional change.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_cursor.c | 220 -
 1 file changed, 109 insertions(+), 111 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fd4bddf..85f38ee 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -117,7 +117,115 @@ static void radeon_show_cursor(struct drm_crtc *crtc)
}
 }

-static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y);
+static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y)
+{
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc->dev->dev_private;
+   int xorigin = 0, yorigin = 0;
+   int w = radeon_crtc->cursor_width;
+
+   if (ASIC_IS_AVIVO(rdev)) {
+   /* avivo cursor are offset into the total surface */
+   x += crtc->x;
+   y += crtc->y;
+   }
+   DRM_DEBUG("x %d y %d c->x %d c->y %d\n", x, y, crtc->x, crtc->y);
+
+   if (x < 0) {
+   xorigin = min(-x, radeon_crtc->max_cursor_width - 1);
+   x = 0;
+   }
+   if (y < 0) {
+   yorigin = min(-y, radeon_crtc->max_cursor_height - 1);
+   y = 0;
+   }
+
+   /* fixed on DCE6 and newer */
+   if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE6(rdev)) {
+   int i = 0;
+   struct drm_crtc *crtc_p;
+
+   /*
+* avivo cursor image can't end on 128 pixel boundary or
+* go past the end of the frame if both crtcs are enabled
+*
+* NOTE: It is safe to access crtc->enabled of other crtcs
+* without holding either the mode_config lock or the other
+* crtc's lock as long as write access to this flag _always_
+* grabs all locks.
+*/
+   list_for_each_entry(crtc_p, >dev->mode_config.crtc_list, 
head) {
+   if (crtc_p->enabled)
+   i++;
+   }
+   if (i > 1) {
+   int cursor_end, frame_end;
+
+   cursor_end = x - xorigin + w;
+   frame_end = crtc->x + crtc->mode.crtc_hdisplay;
+   if (cursor_end >= frame_end) {
+   w = w - (cursor_end - frame_end);
+   if (!(frame_end & 0x7f))
+   w--;
+   } else {
+   if (!(cursor_end & 0x7f))
+   w--;
+   }
+   if (w <= 0) {
+   w = 1;
+   cursor_end = x - xorigin + w;
+   if (!(cursor_end & 0x7f)) {
+   x--;
+   WARN_ON_ONCE(x < 0);
+   }
+   }
+   }
+   }
+
+   if (ASIC_IS_DCE4(rdev)) {
+   WREG32(EVERGREEN_CUR_POSITION + radeon_crtc->crtc_offset, (x << 
16) | y);
+   WREG32(EVERGREEN_CUR_HOT_SPOT + radeon_crtc->crtc_offset, 
(xorigin << 16) | yorigin);
+   WREG32(EVERGREEN_CUR_SIZE + radeon_crtc->crtc_offset,
+  ((w - 1) << 16) | (radeon_crtc->cursor_height - 1));
+   } else if (ASIC_IS_AVIVO(rdev)) {
+   WREG32(AVIVO_D1CUR_POSITION + radeon_crtc->crtc_offset, (x << 
16) | y);
+   WREG32(AVIVO_D1CUR_HOT_SPOT + radeon_crtc->crtc_offset, 
(xorigin << 16) | yorigin);
+   WREG32(AVIVO_D1CUR_SIZE + radeon_crtc->crtc_offset,
+  ((w - 1) << 16) | (radeon_crtc->cursor_height - 1));
+   } else {
+   if (crtc->mode.flags & DRM_MODE_FLAG_DBLSCAN)
+   y *= 2;
+
+   WREG32(RADEON_CUR_HORZ_VERT_OFF + radeon_crtc->crtc_offset,
+  (RADEON_CUR_LOCK
+   | (xorigin << 16)
+   | yorigin));
+   WREG32(RADEON_CUR_HORZ_VERT_POSN + radeon_crtc->crtc_offset,
+  (RADEON_CUR_LOCK
+   | (x << 16)
+   | y));
+   /* offset is from DISP(2)_BASE_ADDRESS */
+   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
(radeon_crtc->legacy_cursor_offset +
+ (yorigin 
* 256)));
+   }
+
+   radeon_crtc->cursor_x = x;
+   radeon_crtc->cursor_y = y;
+
+   return 0;
+}
+
+int radeon_crtc_cursor_move(struct drm_crtc *crtc,
+   int x, int y)
+{
+   int ret;
+
+   radeon_lock_cursor(crtc, true);
+   ret = 

[PATCH 1/2] drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor

[Michel Dänzer]

From: Michel Dänzer 

The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.

Reviewed-by: Alex Deucher 
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_cursor.c  | 51 ++---
 drivers/gpu/drm/radeon/radeon_display.c |  2 +-
 drivers/gpu/drm/radeon/radeon_mode.h| 16 +++
 3 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 9630e8d..fd4bddf 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -117,8 +117,10 @@ static void radeon_show_cursor(struct drm_crtc *crtc)
}
 }

+static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y);
+
 static void radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object 
*obj,
- uint64_t gpu_addr)
+ uint64_t gpu_addr, int hot_x, int hot_y)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
@@ -142,13 +144,28 @@ static void radeon_set_cursor(struct drm_crtc *crtc, 
struct drm_gem_object *obj,
/* offset is from DISP(2)_BASE_ADDRESS */
WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
radeon_crtc->legacy_cursor_offset);
}
+
+   if (hot_x != radeon_crtc->cursor_hot_x ||
+   hot_y != radeon_crtc->cursor_hot_y) {
+   int x, y;
+
+   x = radeon_crtc->cursor_x + radeon_crtc->cursor_hot_x - hot_x;
+   y = radeon_crtc->cursor_y + radeon_crtc->cursor_hot_y - hot_y;
+
+   radeon_cursor_move_locked(crtc, x, y);
+
+   radeon_crtc->cursor_hot_x = hot_x;
+   radeon_crtc->cursor_hot_y = hot_y;
+   }
 }

-int radeon_crtc_cursor_set(struct drm_crtc *crtc,
-  struct drm_file *file_priv,
-  uint32_t handle,
-  uint32_t width,
-  uint32_t height)
+int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
+   struct drm_file *file_priv,
+   uint32_t handle,
+   uint32_t width,
+   uint32_t height,
+   int32_t hot_x,
+   int32_t hot_y)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
@@ -192,7 +209,7 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
radeon_crtc->cursor_height = height;

radeon_lock_cursor(crtc, true);
-   radeon_set_cursor(crtc, obj, gpu_addr);
+   radeon_set_cursor(crtc, obj, gpu_addr, hot_x, hot_y);
radeon_show_cursor(crtc);
radeon_lock_cursor(crtc, false);

@@ -215,8 +232,7 @@ fail:
return ret;
 }

-int radeon_crtc_cursor_move(struct drm_crtc *crtc,
-   int x, int y)
+static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
@@ -281,7 +297,6 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
}
}

-   radeon_lock_cursor(crtc, true);
if (ASIC_IS_DCE4(rdev)) {
WREG32(EVERGREEN_CUR_POSITION + radeon_crtc->crtc_offset, (x << 
16) | y);
WREG32(EVERGREEN_CUR_HOT_SPOT + radeon_crtc->crtc_offset, 
(xorigin << 16) | yorigin);
@@ -308,7 +323,21 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
(radeon_crtc->legacy_cursor_offset +
  (yorigin 
* 256)));
}
-   radeon_lock_cursor(crtc, false);
+
+   radeon_crtc->cursor_x = x;
+   radeon_crtc->cursor_y = y;

return 0;
 }
+
+int radeon_crtc_cursor_move(struct drm_crtc *crtc,
+   int x, int y)
+{
+   int ret;
+
+   radeon_lock_cursor(crtc, true);
+   ret = radeon_cursor_move_locked(crtc, x, y);
+   radeon_lock_cursor(crtc, false);
+
+   return ret;
+}
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 00ead8c..b233dcd 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -634,7 +634,7 @@ radeon_crtc_set_config(struct drm_mode_set *set)
return ret;
 }
 static const struct drm_crtc_funcs radeon_crtc_funcs = {
-   .cursor_set = 

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

[Mark yao]

On 2014年11月18日 16:32, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
>> From: Mark yao 
>>
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>> Signed-off-by: Mark Yao 
>> Signed-off-by: Daniel Kurtz 
>> Acked-by: Daniel Vetter 
>> Reviewed-by: Rob Clark 
>> ---
>> 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
>>
>> Changes in v4:
>> Adviced by David Herrmann
>> - remove drm_platform_*() usage, use register drm device directly.
> Minor fixup for that part below.
>
> [snip]
>
>> +static int rockchip_drm_bind(struct device *dev)
>> +{
>> +struct drm_device *drm;
>> +int ret;
>> +
>> +drm = drm_dev_alloc(_drm_driver, dev);
>> +if (!drm)
>> +return -ENOMEM;
>> +
>> +ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
>> +if (ret)
>> +goto err_free;
> Please call rockchip_drm_load here directly and don't put it as the ->load
> function into the driver vtable. The point of the alloc/register split is
> that the driver can be completely set up _before_ we register anything.
> But for backwards compat and historical reasons ->load is called somewhere
> in the middle (so that you could access the minor nodes if needed, since
> some drivers do that).
>
> Cheers, Daniel
OK, got it.

[PATCH] drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

[Andrew Jackson]

Fetching the EDID from a connected monitor is an automated thing
with NXP TDA19988. But on some boards the fetching fails for the
first time silently without any indication that an error has occured.
More than that, subsequent fetches of the EDID succeed until the
monitor(s) are unplugged.

Add a function to validate the read EDID and retry if the block
retrieved is not valid.

Signed-off-by: Andrew Jackson 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/i2c/tda998x_drv.c |   36 
 1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..025adc0 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1066,11 +1066,36 @@ static int read_edid_block(struct tda998x_priv *priv, 
uint8_t *buf, int blk)
return 0;
 }

+static int
+read_validate_edid_block(struct tda998x_priv *priv, uint8_t *buf, int blk)
+{
+   bool print_bad_edid = drm_debug & DRM_UT_KMS;
+   int ret;
+   int retries = 1;
+
+   do
+   {
+   bool print_bad = print_bad_edid && (retries == 0);
+
+   ret = read_edid_block(priv, buf, blk);
+   /* Fail on I2C error */
+   if (ret)
+   break;
+
+   /* But retry checksum errored blocks */
+   if (drm_edid_block_valid(buf, blk, print_bad))
+   break;
+   else
+   ret = -EINVAL;
+   } while (retries-- > 0);
+
+   return ret;
+}
+
 static uint8_t *do_get_edid(struct tda998x_priv *priv)
 {
int j, valid_extensions = 0;
uint8_t *block, *new;
-   bool print_bad_edid = drm_debug & DRM_UT_KMS;

if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1079,10 +1104,7 @@ static uint8_t *do_get_edid(struct tda998x_priv *priv)
reg_clear(priv, REG_TX4, TX4_PD_RAM);

/* base block fetch */
-   if (read_edid_block(priv, block, 0))
-   goto fail;
-
-   if (!drm_edid_block_valid(block, 0, print_bad_edid))
+   if (read_validate_edid_block(priv, block, 0))
goto fail;

/* if there's no extensions, we're done */
@@ -1096,10 +1118,8 @@ static uint8_t *do_get_edid(struct tda998x_priv *priv)

for (j = 1; j <= block[0x7e]; j++) {
uint8_t *ext_block = block + (valid_extensions + 1) * 
EDID_LENGTH;
-   if (read_edid_block(priv, ext_block, j))
-   goto fail;

-   if (!drm_edid_block_valid(ext_block, j, print_bad_edid))
+   if (read_validate_edid_block(priv, ext_block, j))
goto fail;

valid_extensions++;
-- 
1.7.1

[PATCH] drm/i2c: tda998x: Allow for different audio sample rates

[Andrew Jackson]

On HDMI, the audio data are carried across the HDMI link which is
driven by the TDMS clock. The TDMS clock is dependent on the video pixel
rate.

This patch sets the denominator (Cycle Time Stamp) appropriately
allowing the driver to send audio to a wider range of HDMI sinks
(i.e. monitors).

Signed-off-by: Andrew Jackson 
---
 drivers/gpu/drm/i2c/tda998x_drv.c |   22 ++
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..da0d504 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -640,7 +640,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
struct drm_display_mode *mode, struct tda998x_encoder_params *p)
 {
uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv;
-   uint32_t n;
+   uint32_t n, cts;

/* Enable audio ports */
reg_write(priv, REG_ENA_AP, p->audio_cfg);
@@ -696,9 +696,23 @@ tda998x_configure_audio(struct tda998x_priv *priv,
n = 128 * p->audio_sample_rate / 1000;

/* Write the CTS and N values */
-   buf[0] = 0x44;
-   buf[1] = 0x42;
-   buf[2] = 0x01;
+   if ((n > 0) && (mode->clock > 0)) {
+   /*
+* For non-coherent clocks, the average CTS value is
+* calculated as:
+*  fTMDS * n / (128 * fs)
+* which simplifies to:
+*  fTMDS / 1000
+* (See sections 7.2.2 and 7.2.3 of the HDMI specification.)
+* NB mode->clock is in kHz.
+*/
+   cts = mode->clock;
+   } else {
+   cts = 82500;
+   }
+   buf[0] = cts;
+   buf[1] = cts >> 8;
+   buf[2] = cts >> 16;
buf[3] = n;
buf[4] = n >> 8;
buf[5] = n >> 16;
-- 
1.7.1

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #3 from Andy Furniss  ---
(In reply to Marek Olšák from comment #2)
> Created attachment 109675 [details] [review]
> workaround
> 
> Can you test this LLVM patch. It's not a final fix.

It doesn't apply to head, so testing reset on the bad commit - Yes it does
workaround the issue.

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

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Inki Dae]

On 2014년 11월 18일 16:58, Sjoerd Simons wrote:
> On Tue, 2014-11-18 at 12:20 +0900, Inki Dae wrote:
>> This patch makes the deferred probe is tried up to 3 times in maximum.
>> However, this is considered only for Exynos drm so I think other SoC
>> drivers could also produce same issue. Therefore, the best way to resolve
>> this issue, infinite loop incurred by defered probe, would be that dd core
>> is fixed up corrrectly.
> 
> At first sight this seems to make little to no sense. Unless i'm
> mistaken this would cause the exynos drm probe return -ENODEV to the dd
> core, causing it to stop trying to probe. Which obviously breaks your
> infinite loop, it also breaks situations where the probe needs to be
> retried more then 3 times. 

Right, but at least, we could avoid kernel booting failure which is very
critical. Please know that this patch is temporary to avoid the kernel
booting failure although deferred probe request of Exynos drm could be
broken. For this, I will look into dd core to find out more generic way:
I suspect that this might be incurred in case that a driver is probed in
probe context of other driver or it might be really dd core bug.

Thanks,
Inki Dae

> 
> I suspect with this patch once exynos DRM is loaded and actually validly
> needs to defer (iotw when the required modules do exist but simply
> aren't loaded just yet), it still jumps into an infinite loop which you
> break after 3 tries after which the display will simply never come up
> even if everything is in place because the core doesn't know it should
> re-probe
> 
> 
> 
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c |8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index eab12f0..4d84f3a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -38,6 +38,8 @@
>>  #define DRIVER_MAJOR1
>>  #define DRIVER_MINOR0
>>  
>> +#define MAX_TRY_PROBE_DEFER 3
>> +
>>  static struct platform_device *exynos_drm_pdev;
>>  
>>  static DEFINE_MUTEX(drm_component_lock);
>> @@ -481,6 +483,7 @@ static struct component_match 
>> *exynos_drm_match_add(struct device *dev)
>>  struct component_match *match = NULL;
>>  struct component_dev *cdev;
>>  unsigned int attach_cnt = 0;
>> +static unsigned int try_probe_defer;
>>  
>>  mutex_lock(_component_lock);
>>  
>> @@ -527,6 +530,11 @@ out_lock:
>>  
>>  mutex_unlock(_component_lock);
>>  
>> +if (++try_probe_defer > MAX_TRY_PROBE_DEFER) {
>> +try_probe_defer = 0;
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>>  return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
>>  }
>>  
> 
> 

[Bug 86287] X does not start with kernel 3.17.2 but starts with 3.16.6 (radeon driver).

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

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

Lukasz Krotowski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #6 from Lukasz Krotowski  ---
I've tried to bisect only to find that vanilla kernels work fine. I've built my
distro kernel with most of it's patches removed (keeping only essential ones)
and it also works fine. So I suppose this bug does not belong here.

-- 
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/20141118/f7338eef/attachment.html>

Long radeon stalls on recent kernels

[Andy Lutomirski]

On Tue, Nov 18, 2014 at 4:34 PM, Andy Lutomirski  wrote:
> On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski  
> wrote:
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  
>> wrote:
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:

 I have a Caicos card, like this:

 [3.077260] [drm] radeon kernel modesetting enabled.
 [3.077338] checking generic (e000 60) vs hw (e000
 1000)
 [3.077339] fb: switching to radeondrmfb from EFI VGA
 [3.077377] Console: switching to colour dummy device 80x25
 [3.078881] [drm] initializing kernel modesetting (CAICOS
 0x1002:0x6779 0x174B:0xE164).
 [3.078903] [drm] register mmio base: 0xF4A2
 [3.078904] [drm] register mmio size: 131072
 [3.078982] ATOM BIOS: C26401
 [3.079572] radeon :09:00.0: VRAM: 1024M 0x -
 0x3FFF (1024M used)
 [3.079574] radeon :09:00.0: GTT: 1024M 0x4000 -
 0x7FFF
 [3.079576] [drm] Detected VRAM RAM=1024M, BAR=256M
 [3.079577] [drm] RAM width 64bits DDR
 [3.079755] [TTM] Zone  kernel: Available graphics memory: 8186568 kiB
 [3.079757] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [3.079757] [TTM] Initializing pool allocator
 [3.079773] [TTM] Initializing DMA pool allocator
 [3.080011] [drm] radeon: 1024M of VRAM memory ready
 [3.080012] [drm] radeon: 1024M of GTT memory ready.
 [3.080049] [drm] Loading CAICOS Microcode
 [3.080330] [drm] Internal thermal controller without fan control
 [3.081425] [drm] radeon: power management initialized
 [3.081551] [drm] GART: num cpu pages 262144, num gpu pages 262144
 [3.082589] [drm] enabling PCIE gen 2 link speeds, disable with
 radeon.pcie_gen2=0
 [3.085030] [drm] PCIE GART of 1024M enabled (table at
 0x00274000).
 [3.085221] radeon :09:00.0: WB enabled
 [3.085224] radeon :09:00.0: fence driver on ring 0 use gpu
 addr 0x4c00 and cpu addr 0x88043d914c00
 [3.085225] radeon :09:00.0: fence driver on ring 3 use gpu
 addr 0x4c0c and cpu addr 0x88043d914c0c
 [3.097438] radeon :09:00.0: fence driver on ring 5 use gpu
 addr 0x00072118 and cpu addr 0xc900128b2118
 [3.097441] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [3.097442] [drm] Driver supports precise vblank timestamp query.
 [3.097514] radeon :09:00.0: irq 56 for MSI/MSI-X
 [3.097544] radeon :09:00.0: radeon: using MSI.
 [3.097614] [drm] radeon: irq initialized.

 On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
 graphics intensive seems to cause my system to become unusable for
 tens of seconds.  Pointing Firefox at Google Maps is a big offender --
 it can take several minutes for me to move my mouse far enough to
 close the tab and get my computer back.

 On bootup, I get this warning:
 [drm:btc_dpm_set_power_state] *ERROR*
 rv770_restrict_performance_levels_before_switch failed

 Setting radeon.dpm=0 seems to work around this problem at the cost of
 giving my rather slow graphics.

 Are there known issues here?
>>>
>>>
>>> Can you bisect the kernel, or at least isolate which kernel version first
>>> introduced the problem?
>>
>> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
>> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>>
>> With radeon.dpm=0, I can still trigger short stalls (around one
>> second), but I seem unable to trigger long stalls easily.  (I say
>> easily because, just as I was typing this email, my system stalled for
>> about a minute.)
>
> I could be wrong here, but I think that radeon.dpm=0,
> power_profile=default is okay, but radeon.dpm=0, power_profile=high is
> bad.

I'm wrong again.  power_profile=default is also bad.

Grr.

--Andy

Long radeon stalls on recent kernels

[Andy Lutomirski]

On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski  wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> I have a Caicos card, like this:
>>>
>>> [3.077260] [drm] radeon kernel modesetting enabled.
>>> [3.077338] checking generic (e000 60) vs hw (e000
>>> 1000)
>>> [3.077339] fb: switching to radeondrmfb from EFI VGA
>>> [3.077377] Console: switching to colour dummy device 80x25
>>> [3.078881] [drm] initializing kernel modesetting (CAICOS
>>> 0x1002:0x6779 0x174B:0xE164).
>>> [3.078903] [drm] register mmio base: 0xF4A2
>>> [3.078904] [drm] register mmio size: 131072
>>> [3.078982] ATOM BIOS: C26401
>>> [3.079572] radeon :09:00.0: VRAM: 1024M 0x -
>>> 0x3FFF (1024M used)
>>> [3.079574] radeon :09:00.0: GTT: 1024M 0x4000 -
>>> 0x7FFF
>>> [3.079576] [drm] Detected VRAM RAM=1024M, BAR=256M
>>> [3.079577] [drm] RAM width 64bits DDR
>>> [3.079755] [TTM] Zone  kernel: Available graphics memory: 8186568 kiB
>>> [3.079757] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [3.079757] [TTM] Initializing pool allocator
>>> [3.079773] [TTM] Initializing DMA pool allocator
>>> [3.080011] [drm] radeon: 1024M of VRAM memory ready
>>> [3.080012] [drm] radeon: 1024M of GTT memory ready.
>>> [3.080049] [drm] Loading CAICOS Microcode
>>> [3.080330] [drm] Internal thermal controller without fan control
>>> [3.081425] [drm] radeon: power management initialized
>>> [3.081551] [drm] GART: num cpu pages 262144, num gpu pages 262144
>>> [3.082589] [drm] enabling PCIE gen 2 link speeds, disable with
>>> radeon.pcie_gen2=0
>>> [3.085030] [drm] PCIE GART of 1024M enabled (table at
>>> 0x00274000).
>>> [3.085221] radeon :09:00.0: WB enabled
>>> [3.085224] radeon :09:00.0: fence driver on ring 0 use gpu
>>> addr 0x4c00 and cpu addr 0x88043d914c00
>>> [3.085225] radeon :09:00.0: fence driver on ring 3 use gpu
>>> addr 0x4c0c and cpu addr 0x88043d914c0c
>>> [3.097438] radeon :09:00.0: fence driver on ring 5 use gpu
>>> addr 0x00072118 and cpu addr 0xc900128b2118
>>> [3.097441] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [3.097442] [drm] Driver supports precise vblank timestamp query.
>>> [3.097514] radeon :09:00.0: irq 56 for MSI/MSI-X
>>> [3.097544] radeon :09:00.0: radeon: using MSI.
>>> [3.097614] [drm] radeon: irq initialized.
>>>
>>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
>>> graphics intensive seems to cause my system to become unusable for
>>> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
>>> it can take several minutes for me to move my mouse far enough to
>>> close the tab and get my computer back.
>>>
>>> On bootup, I get this warning:
>>> [drm:btc_dpm_set_power_state] *ERROR*
>>> rv770_restrict_performance_levels_before_switch failed
>>>
>>> Setting radeon.dpm=0 seems to work around this problem at the cost of
>>> giving my rather slow graphics.
>>>
>>> Are there known issues here?
>>
>>
>> Can you bisect the kernel, or at least isolate which kernel version first
>> introduced the problem?
>
> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>
> With radeon.dpm=0, I can still trigger short stalls (around one
> second), but I seem unable to trigger long stalls easily.  (I say
> easily because, just as I was typing this email, my system stalled for
> about a minute.)

I could be wrong here, but I think that radeon.dpm=0,
power_profile=default is okay, but radeon.dpm=0, power_profile=high is
bad.

--Andy

>
> --Andy
>
>>
>>
>> --
>> Earthling Michel Dänzer|  http://www.amd.com
>> Libre software enthusiast  |Mesa and X developer
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC



-- 
Andy Lutomirski
AMA Capital Management, LLC

[BUG] blocked task after exynos_drm_init

[Grant Likely]

On Tue, Nov 18, 2014 at 12:29 PM, Javier Martinez Canillas
 wrote:
> [adding Kevin to cc list]
>
> Hello Inki,
>
> On Tue, Nov 18, 2014 at 11:52 AM, Inki Dae  wrote:
>> On 2014년 11월 18일 19:42, Andrzej Hajda wrote:
>>> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
 Hi,

 On last next (next-20141104, next-20141105) booting locks after
 initializing Exynos DRM (Trats2 board):

 [2.028283] [drm] Initialized drm 1.1.0 20060810
 [  240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
 [  240.510825]   Not tainted 3.18.0-rc3-next-20141105 #794
 [  240.516418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
 this message.
 [  240.524173] swapper/0   D c052534c 0 1  0 0x
 [  240.530527] [] (__schedule) from [] 
 (schedule_preempt_disabled+0x14/0x20)
 [  240.539030] [] (schedule_preempt_disabled) from [] 
 (mutex_lock_nested+0x1c4/0x464)
 [  240.548320] [] (mutex_lock_nested) from [] 
 (__driver_attach+0x48/0x98)
 [  240.556562] [] (__driver_attach) from [] 
 (bus_for_each_dev+0x54/0x88)
 [  240.564717] [] (bus_for_each_dev) from [] 
 (bus_add_driver+0xe4/0x200)
 [  240.572876] [] (bus_add_driver) from [] 
 (driver_register+0x78/0xf4)
 [  240.580864] [] (driver_register) from [] 
 (exynos_drm_platform_probe+0x34/0x234)
 [  240.589890] [] (exynos_drm_platform_probe) from [] 
 (platform_drv_probe+0x48/0xa4)
 [  240.599090] [] (platform_drv_probe) from [] 
 (driver_probe_device+0x13c/0x37c)
 [  240.607940] [] (driver_probe_device) from [] 
 (__driver_attach+0x94/0x98)
 [  240.616360] [] (__driver_attach) from [] 
 (bus_for_each_dev+0x54/0x88)
 [  240.624517] [] (bus_for_each_dev) from [] 
 (bus_add_driver+0xe4/0x200)
 [  240.632679] [] (bus_add_driver) from [] 
 (driver_register+0x78/0xf4)
 [  240.640667] [] (driver_register) from [] 
 (exynos_drm_init+0x70/0xa0)
 [  240.648739] [] (exynos_drm_init) from [] 
 (do_one_initcall+0xac/0x1f0)
 [  240.656914] [] (do_one_initcall) from [] 
 (kernel_init_freeable+0x10c/0x1d8)
 [  240.665591] [] (kernel_init_freeable) from [] 
 (kernel_init+0x8/0xec)
 [  240.673661] [] (kernel_init) from [] 
 (ret_from_fork+0x14/0x2c)
 [  240.681196] 3 locks held by swapper/0/1:
 [  240.685091]  #0:  (>mutex){..}, at: [] 
 __driver_attach+0x48/0x98
 [  240.692732]  #1:  (>mutex){..}, at: [] 
 __driver_attach+0x58/0x98
 [  240.700367]  #2:  (>mutex){..}, at: [] 
 __driver_attach+0x48/0x98
>>>
>>>
>>> This is caused by patch moving platform devices to
>>> /sys/devices/platform[1]. Since this patch registering platform
>>> drivers/devices in probe of platform device causes deadlocks. I guess
>>> now all driver registration should be moved to exynos_drm_init and it
>>> seems better location for it IMHO.
>>
>> Thanks. It might be a chance that we could separate sub drivers of
>> Exynos drm into independent modules so that they can be called
>> independently because if we move them to exynos_drm_init then the
>> deferred probe wouldn't work correctly.
>>
>
> I don't understand why registering the platform drivers in the
> exynos_drm_init() will make deferred probing to not work correctly?
> AFAICT it does not matter where the driver is registered since if the
> driver probe function is called when the driver is attached and fails
> with -EPROBE_DEFER, it will be added to the deferred list and the
> probe function will be retried when other drivers are registered due
> devices being added (e.g: by OF when matching a compatible string). Or
> maybe I'm missing something here?

It's only by luck that it even worked before.

I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent.

g.

>
> By the way, I tried moving the platform 

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> Hi
> 
> On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
>  wrote:
> > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> >> > From: Thierry Reding 
> >> >
> >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> >> > different semantics on different drivers it seems like a good idea to
> >> > start to more rigorously document userspace ABI to avoid these things
> >> > in the future.
> >> >
> >> > This is a first draft of what such documentation could look like. Not
> >> > all IOCTLs are documented and some explanation about the other system
> >> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> >> > send this out for early review to see if the direction is reasonable.
> >> > If so my plan is to continue to chip away at this as I find time.
> >> >
> >> > Signed-off-by: Thierry Reding 
> >>
> >> Imo for ioctls the right thing to do is having proper manpages, not
> >> kerneldoc or DocBook sections. manpages really lend themselves well to
> >> specify all the different facets of a single interface.
> >
> > I don't think I've ever seen manpages document IOCTLs at this level of
> > detail. The intention of this is to add documentation about the IOCTLs
> > at the kernel/userspace transition. Keeping this in the kernel has the
> > advantage that it's a whole lot easier to keep updated, much like what
> > we do with the other kerneldoc.
> >
> > That doesn't mean we shouldn't have manpages, but I think both are for
> > the most part orthogonal, even though they may describe various facets
> > of the same interfaces.
> 
> tty_ioctl(4)
> console_ioctl(4)
> 
> I think a similar man-page ala drm_ioctl(4) makes a lot of sense.
> 
> >> Also, we already have some skeleton of that in libdrm, so I think
> >> extending that would be best.
> >
> > One other reason why I don't think libdrm is the best fit for this is
> > that libdrm is just one userspace implementation abstracting away the
> > interfaces that this describes. Not everyone will use libdrm. So in my
> > opinion its great if libdrm documents the API that it exposes, but I
> > don't think it should document the kernel interfaces that it uses. The
> > kernel exposes them, so it should provide the documentation for it as
> > well.
> 
> I don't mind documenting this in the kernel-doc. But if we start
> something like drm_ioctl(4) (I pushed some more generic man-pages to
> libdrm a few years ago), we have this documented in 2 places, which is
> always annoying for updates.

I wonder if it would somehow be possible to generate manpages from the
DocBook to avoid this duplication. One of the things that
DRM_IOCTL_MODE_CREATE_DUMB showed is that both drivers and userspace can
interpret things wrongly, and I fear that if all we have is a manpage to
document the IOCTLs, people writing the drivers may not be tempted
enough to read that manpage. So I think we want documentation for both
driver and userspace developers.

Documenting this within the kernel is also pretty easy. I know that I'll
be much more tempted to do it within the kernel than if I have to switch
to some other repository, build system and whatnot.

Perhaps in this case having two places where it's documented isn't all
that bad. It's ABI after all, so the documentation never needs to
change. Theoretically.

> And even if people don't use libdrm, I think it's totally acceptable
> to ship man-pages with libdrm. Distributions are free to provide
> drm-man-pages as stand-alone package (which is _really_ easy to
> generate from libdrm).

I guess one other home for these could be the man-pages project on
kernel.org. It's what carries most (all?) of the Linux kernel-specific
man-pages (like the tty_ioctl and console_ioctl ones that you referred
to).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/07915ba6/attachment-0001.sig>

Long radeon stalls on recent kernels

[Andy Lutomirski]

On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  wrote:
> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>
>> I have a Caicos card, like this:
>>
>> [3.077260] [drm] radeon kernel modesetting enabled.
>> [3.077338] checking generic (e000 60) vs hw (e000
>> 1000)
>> [3.077339] fb: switching to radeondrmfb from EFI VGA
>> [3.077377] Console: switching to colour dummy device 80x25
>> [3.078881] [drm] initializing kernel modesetting (CAICOS
>> 0x1002:0x6779 0x174B:0xE164).
>> [3.078903] [drm] register mmio base: 0xF4A2
>> [3.078904] [drm] register mmio size: 131072
>> [3.078982] ATOM BIOS: C26401
>> [3.079572] radeon :09:00.0: VRAM: 1024M 0x -
>> 0x3FFF (1024M used)
>> [3.079574] radeon :09:00.0: GTT: 1024M 0x4000 -
>> 0x7FFF
>> [3.079576] [drm] Detected VRAM RAM=1024M, BAR=256M
>> [3.079577] [drm] RAM width 64bits DDR
>> [3.079755] [TTM] Zone  kernel: Available graphics memory: 8186568 kiB
>> [3.079757] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [3.079757] [TTM] Initializing pool allocator
>> [3.079773] [TTM] Initializing DMA pool allocator
>> [3.080011] [drm] radeon: 1024M of VRAM memory ready
>> [3.080012] [drm] radeon: 1024M of GTT memory ready.
>> [3.080049] [drm] Loading CAICOS Microcode
>> [3.080330] [drm] Internal thermal controller without fan control
>> [3.081425] [drm] radeon: power management initialized
>> [3.081551] [drm] GART: num cpu pages 262144, num gpu pages 262144
>> [3.082589] [drm] enabling PCIE gen 2 link speeds, disable with
>> radeon.pcie_gen2=0
>> [3.085030] [drm] PCIE GART of 1024M enabled (table at
>> 0x00274000).
>> [3.085221] radeon :09:00.0: WB enabled
>> [3.085224] radeon :09:00.0: fence driver on ring 0 use gpu
>> addr 0x4c00 and cpu addr 0x88043d914c00
>> [3.085225] radeon :09:00.0: fence driver on ring 3 use gpu
>> addr 0x4c0c and cpu addr 0x88043d914c0c
>> [3.097438] radeon :09:00.0: fence driver on ring 5 use gpu
>> addr 0x00072118 and cpu addr 0xc900128b2118
>> [3.097441] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [3.097442] [drm] Driver supports precise vblank timestamp query.
>> [3.097514] radeon :09:00.0: irq 56 for MSI/MSI-X
>> [3.097544] radeon :09:00.0: radeon: using MSI.
>> [3.097614] [drm] radeon: irq initialized.
>>
>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
>> graphics intensive seems to cause my system to become unusable for
>> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
>> it can take several minutes for me to move my mouse far enough to
>> close the tab and get my computer back.
>>
>> On bootup, I get this warning:
>> [drm:btc_dpm_set_power_state] *ERROR*
>> rv770_restrict_performance_levels_before_switch failed
>>
>> Setting radeon.dpm=0 seems to work around this problem at the cost of
>> giving my rather slow graphics.
>>
>> Are there known issues here?
>
>
> Can you bisect the kernel, or at least isolate which kernel version first
> introduced the problem?

With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
3.16, and 3.18-rc4+.  I haven't tried other versions.

With radeon.dpm=0, I can still trigger short stalls (around one
second), but I seem unable to trigger long stalls easily.  (I say
easily because, just as I was typing this email, my system stalled for
about a minute.)

--Andy

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



-- 
Andy Lutomirski
AMA Capital Management, LLC

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

--- Comment #25 from Marek Olšák  ---
My explanations for this bug are:

1) CMASK allocation is wrong. We should try and overallocate it.

2) CMASK contains garbage, which can hang the hardware. Either the clear_buffer
function isn't reliable (it uses CP DMA) or CMASK was corrupted by eviction. Or
an out-of-bounds access from some other source corrupted it.

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

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

--- Comment #24 from MirceaKitsune  ---
(In reply to Marek Olšák from comment #23)

I can't test latest Mesa with Second Life, due to another bug in current GIT
master: http://bugs.freedesktop.org/show_bug.cgi?id=86089 So I manually
integrated your patch in the latest commit which doesn't have that issue
(6212d2402df4ad0658cbb98ce889e35ef5f32fa3) and tested with it.

The problem is indeed solved! I can now enable Advanced Lighting and all
related shaders without any issues in Second Life. Turning shaders on in
Stuntrally also doesn't produce the crash any longer. Thank you for the patch!
I will wait for it to be included and use an updated release afterward.

-- 
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/20141118/67c92fbd/attachment.html>

[RFC] drm: Start documenting userspace ABI

[David Herrmann]

Hi

On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
 wrote:
> On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
>> > From: Thierry Reding 
>> >
>> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
>> > different semantics on different drivers it seems like a good idea to
>> > start to more rigorously document userspace ABI to avoid these things
>> > in the future.
>> >
>> > This is a first draft of what such documentation could look like. Not
>> > all IOCTLs are documented and some explanation about the other system
>> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
>> > send this out for early review to see if the direction is reasonable.
>> > If so my plan is to continue to chip away at this as I find time.
>> >
>> > Signed-off-by: Thierry Reding 
>>
>> Imo for ioctls the right thing to do is having proper manpages, not
>> kerneldoc or DocBook sections. manpages really lend themselves well to
>> specify all the different facets of a single interface.
>
> I don't think I've ever seen manpages document IOCTLs at this level of
> detail. The intention of this is to add documentation about the IOCTLs
> at the kernel/userspace transition. Keeping this in the kernel has the
> advantage that it's a whole lot easier to keep updated, much like what
> we do with the other kerneldoc.
>
> That doesn't mean we shouldn't have manpages, but I think both are for
> the most part orthogonal, even though they may describe various facets
> of the same interfaces.

tty_ioctl(4)
console_ioctl(4)

I think a similar man-page ala drm_ioctl(4) makes a lot of sense.

>> Also, we already have some skeleton of that in libdrm, so I think
>> extending that would be best.
>
> One other reason why I don't think libdrm is the best fit for this is
> that libdrm is just one userspace implementation abstracting away the
> interfaces that this describes. Not everyone will use libdrm. So in my
> opinion its great if libdrm documents the API that it exposes, but I
> don't think it should document the kernel interfaces that it uses. The
> kernel exposes them, so it should provide the documentation for it as
> well.

I don't mind documenting this in the kernel-doc. But if we start
something like drm_ioctl(4) (I pushed some more generic man-pages to
libdrm a few years ago), we have this documented in 2 places, which is
always annoying for updates.

And even if people don't use libdrm, I think it's totally acceptable
to ship man-pages with libdrm. Distributions are free to provide
drm-man-pages as stand-alone package (which is _really_ easy to
generate from libdrm).

Thanks
David

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

[Mark Yao]

From: 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

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: 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 v12 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark Yao]

From: 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

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: 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 v12 1/3] drm: rockchip: Add basic drm driver

[Mark Yao]

From: Mark yao 

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

Signed-off-by: Mark Yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
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 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend.

Changes in v12:
- fix compile problem with drm-next
Adviced by Daniel Kurtz
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  482 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1459 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  201 
 14 files changed, 3031 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

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f..3f1624b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -167,6 +167,8 @@ config DRM_SAVAGE

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

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

[PATCH v12 0/3] 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. Future patches will add additional encoders/connectors,
such as eDP, 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.
- add vop 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 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem.

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.
- fix mail info style.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend

Changes in v12:
- fix compile problem with drm-next
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem


Mark yao (3):
  drm: rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  482 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  294 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1459 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  201 +++
 16 files changed, 3108 insertions(+)

-- 
1.7.9.5

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #23 from kb at spatium.org ---
Created attachment 158001
  --> https://bugzilla.kernel.org/attachment.cgi?id=158001=edit
dmesg #3

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

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #22 from kb at spatium.org ---
I've also added this line
DRM_DEBUG_KMS("in patched branch: %u\n", ref_div_max);
add the end of your patch, i.e. after 
ref_div_max = min(ref_div_max, pll->reference_freq / in_min);
just to make sure the new code gets hit.
I see this in dmesg
[   23.002707] [drm:radeon_compute_pll_avivo] in patched branch: 13
and I'm attaching the full output as well. Hope it gives you some more ideas.

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

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

Laurent carlier  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #19 from Laurent carlier  ---
Fixed with current mesa trunk, so closing

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

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > different semantics on different drivers it seems like a good idea to
> > start to more rigorously document userspace ABI to avoid these things
> > in the future.
> > 
> > This is a first draft of what such documentation could look like. Not
> > all IOCTLs are documented and some explanation about the other system
> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > send this out for early review to see if the direction is reasonable.
> > If so my plan is to continue to chip away at this as I find time.
> > 
> > Signed-off-by: Thierry Reding 
> 
> Imo for ioctls the right thing to do is having proper manpages, not
> kerneldoc or DocBook sections. manpages really lend themselves well to
> specify all the different facets of a single interface.

I don't think I've ever seen manpages document IOCTLs at this level of
detail. The intention of this is to add documentation about the IOCTLs
at the kernel/userspace transition. Keeping this in the kernel has the
advantage that it's a whole lot easier to keep updated, much like what
we do with the other kerneldoc.

That doesn't mean we shouldn't have manpages, but I think both are for
the most part orthogonal, even though they may describe various facets
of the same interfaces.

> Also, we already have some skeleton of that in libdrm, so I think
> extending that would be best.

One other reason why I don't think libdrm is the best fit for this is
that libdrm is just one userspace implementation abstracting away the
interfaces that this describes. Not everyone will use libdrm. So in my
opinion its great if libdrm documents the API that it exposes, but I
don't think it should document the kernel interfaces that it uses. The
kernel exposes them, so it should provide the documentation for it as
well.

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

[RFC] drm: Start documenting userspace ABI

[Daniel Vetter]

On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> different semantics on different drivers it seems like a good idea to
> start to more rigorously document userspace ABI to avoid these things
> in the future.
> 
> This is a first draft of what such documentation could look like. Not
> all IOCTLs are documented and some explanation about the other system
> calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> send this out for early review to see if the direction is reasonable.
> If so my plan is to continue to chip away at this as I find time.
> 
> Signed-off-by: Thierry Reding 

Imo for ioctls the right thing to do is having proper manpages, not
kerneldoc or DocBook sections. manpages really lend themselves well to
specify all the different facets of a single interface.

Also, we already have some skeleton of that in libdrm, so I think
extending that would be best.
-Daniel

> ---
>  Documentation/DocBook/drm.tmpl | 700 
> -
>  include/uapi/drm/drm.h |  95 --
>  2 files changed, 773 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ffe0d9b41826..bc125c043032 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3831,8 +3831,706 @@ int num_ioctls;
>  
>
>  
> +
> +  DRM Userspace ABI
> +  
> +
> +  This third part of the DRM Developer's Guide documents userspace
> +  interfaces. DRM devices can be accessed using standard file operations
> +  such as open(), close(), ioctl() or mmap(). How these translate to the
> +  DRM drivers is explained in the following chapters.
> +
> +
> +  For driver-specific userspace interfaces (buffer allocation and
> +  management, command stream submission, ...) refer to the 
> driver-specific
> +  sections in .
> +
> +  
> +  
> +DRM IOCTLs
> +
> +  A number of IOCTLs can be performed on a DRM device node. Many of them
> +  are generic and apply to all devices, others are considered legacy and
> +  should no longer be used in new userspace applications.
> +
> +
> +  Identification
> +  
> +DRM_IOCTL_VERSION - query driver name and version
> +
> +  After opening a DRM device, userspace applications will typically
> +  want to identify the driver bound to the device. They can use this
> +  IOCTL to obtain information about the driver in the form of a
> +  drm_version structure.
> +
> +!Finclude/uapi/drm/drm.h drm_version
> +
> +  Returns 0 on success or one of the following error codes on
> +  failure:
> +
> +
> +  
> +EFAULT
> +
> +  
> +If data cannot be copied to any of the
> +name,
> +date or
> +desc fields.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_GET_UNIQUE - get unique device name
> +
> +  Each device has a unique name associated with it. This is useful to
> +  differentiate between two devices driven by the same driver. Unique
> +  names of devices can be obtained with this IOCTL and the result is
> +  returned in a drm_unique structure.
> +
> +!Finclude/uapi/drm/drm.h drm_unique
> +
> +  Returns 0 on success or one of the following error codes on 
> failure:
> +
> +
> +  
> +EFAULT
> +
> +  
> +If the device's unique name cannot be copied to the
> +unique field.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_SET_VERSION - request interface version
> +
> +  Request a specific interface or driver version. The values passed 
> in
> +  the drm_set_version structure are matched
> +  against the DRM interface and driver versions.
> +
> +!Finclude/uapi/drm/drm.h drm_set_version
> +
> +  Returns 0 on success or one of the following error codes on 
> failure:
> +
> +
> +  
> +EINVAL
> +
> +  
> +If the interface version in the kernel is incompatible with
> +that requested by the userspace application or if the driver
> +is not compatible with the version requested by the userspace
> +application.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_GET_CAP - query device capabilities
> +
> +  DRM drivers vary in terms of which functionality that they support.
> +  Even within one driver, certain 

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

[Daniel Vetter]

On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
> Hi Daniel,
> 
> On Tue, 18 Nov 2014 09:32:34 +0100
> Daniel Vetter  wrote:
> 
> > On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > > From: Mark yao 
> > > 
> > > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> > > 
> > > Signed-off-by: Mark Yao 
> > > Signed-off-by: Daniel Kurtz 
> > > Acked-by: Daniel Vetter 
> > > Reviewed-by: Rob Clark 
> > > ---
> > > 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 
> > > 
> > > Changes in v4:
> > > Adviced by David Herrmann
> > > - remove drm_platform_*() usage, use register drm device directly.
> > 
> > Minor fixup for that part below.
> > 
> > [snip]
> > 
> > > +static int rockchip_drm_bind(struct device *dev)
> > > +{
> > > + struct drm_device *drm;
> > > + int ret;
> > > +
> > > + drm = drm_dev_alloc(_drm_driver, dev);
> > > + if (!drm)
> > > + return -ENOMEM;
> > > +
> > > + ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
> > > + if (ret)
> > > + goto err_free;
> > 
> > Please call rockchip_drm_load here directly and don't put it as the ->load
> > function into the driver vtable. The point of the alloc/register split is
> > that the driver can be completely set up _before_ we register anything.
> > But for backwards compat and historical reasons ->load is called somewhere
> > in the middle (so that you could access the minor nodes if needed, since
> > some drivers do that).
> 
> I tried to do the same in the atmel-hlcdc DRM driver, but I need the
> primary drm_minor to register the connectors (see this kernel
> backtrace [1]), which means I either initialize the connector in the
> wrong place (currently part of the drm load process), or I just can't
> call atmel_hlcdc_dc_load before registering the drm device...

Hm right, wonder who that works with rockchip tbh.

We did split up the drm_connector setup into _init and register, so if you
want to do this then you need to move the call to drm_connector_register
below the call to drm_dev_register.

We should probably have a drm_connectors_register_all helper which does
this for all connectors on the connector list. And also grabs the
appropriate lock.

I guess it's somewhat obvious that no one yet actually tried this ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

From: Thierry Reding 

After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
different semantics on different drivers it seems like a good idea to
start to more rigorously document userspace ABI to avoid these things
in the future.

This is a first draft of what such documentation could look like. Not
all IOCTLs are documented and some explanation about the other system
calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
send this out for early review to see if the direction is reasonable.
If so my plan is to continue to chip away at this as I find time.

Signed-off-by: Thierry Reding 
---
 Documentation/DocBook/drm.tmpl | 700 -
 include/uapi/drm/drm.h |  95 --
 2 files changed, 773 insertions(+), 22 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ffe0d9b41826..bc125c043032 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3831,8 +3831,706 @@ int num_ioctls;

   
 
+
+  DRM Userspace ABI
+  
+
+  This third part of the DRM Developer's Guide documents userspace
+  interfaces. DRM devices can be accessed using standard file operations
+  such as open(), close(), ioctl() or mmap(). How these translate to the
+  DRM drivers is explained in the following chapters.
+
+
+  For driver-specific userspace interfaces (buffer allocation and
+  management, command stream submission, ...) refer to the driver-specific
+  sections in .
+
+  
+  
+DRM IOCTLs
+
+  A number of IOCTLs can be performed on a DRM device node. Many of them
+  are generic and apply to all devices, others are considered legacy and
+  should no longer be used in new userspace applications.
+
+
+  Identification
+  
+DRM_IOCTL_VERSION - query driver name and version
+
+  After opening a DRM device, userspace applications will typically
+  want to identify the driver bound to the device. They can use this
+  IOCTL to obtain information about the driver in the form of a
+  drm_version structure.
+
+!Finclude/uapi/drm/drm.h drm_version
+
+  Returns 0 on success or one of the following error codes on
+  failure:
+
+
+  
+EFAULT
+
+  
+If data cannot be copied to any of the
+name,
+date or
+desc fields.
+  
+
+  
+
+  
+  
+DRM_IOCTL_GET_UNIQUE - get unique device name
+
+  Each device has a unique name associated with it. This is useful to
+  differentiate between two devices driven by the same driver. Unique
+  names of devices can be obtained with this IOCTL and the result is
+  returned in a drm_unique structure.
+
+!Finclude/uapi/drm/drm.h drm_unique
+
+  Returns 0 on success or one of the following error codes on failure:
+
+
+  
+EFAULT
+
+  
+If the device's unique name cannot be copied to the
+unique field.
+  
+
+  
+
+  
+  
+DRM_IOCTL_SET_VERSION - request interface version
+
+  Request a specific interface or driver version. The values passed in
+  the drm_set_version structure are matched
+  against the DRM interface and driver versions.
+
+!Finclude/uapi/drm/drm.h drm_set_version
+
+  Returns 0 on success or one of the following error codes on failure:
+
+
+  
+EINVAL
+
+  
+If the interface version in the kernel is incompatible with
+that requested by the userspace application or if the driver
+is not compatible with the version requested by the userspace
+application.
+  
+
+  
+
+  
+  
+DRM_IOCTL_GET_CAP - query device capabilities
+
+  DRM drivers vary in terms of which functionality that they support.
+  Even within one driver, certain devices may not support the same
+  functionality as others. The DRM_IOCTL_GET_CAP
+  IOCTL can be used to query such capabilities at runtime.
+
+
+  The following is a list of available capabilities. Userspace
+  applications set the capability to one of
+  these before performing the IOCTL. The kernel returns the capability
+  value in the value field. Typically this
+  will be a boolean (0 or 1) value that denotes whether or not the
+  device supports the given capability. In other cases the returned
+  value is numerical and the 

[Bug 83611] Kernel NULL pointer dereference when using tlp on a laptop with AMD video card.

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

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

--- Comment #6 from Alex Deucher  ---
Fix is upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8efe82ca908400785253c8f0dfcf301e6bd93488

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

[Bug 85771] unable to handle kernel NULL pointer dereference in dce6_bandwidth_update

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

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #6 from Alex Deucher  ---
(In reply to Frederik Himpe from comment #5)
> Will this patch be included in Linux 3.18?

Yes.  It's already upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8efe82ca908400785253c8f0dfcf301e6bd93488

-- 
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/20141118/644f68e1/attachment.html>

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #2 from Marek Olšák  ---
Created attachment 109675
  --> https://bugs.freedesktop.org/attachment.cgi?id=109675=edit
workaround

Can you test this LLVM patch. It's not a final fix.

-- 
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/20141118/f75ab6a3/attachment.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

The Exynos DRM driver register its sub-devices platform drivers in
the probe function but after commit 43c0767 ("of/platform: Move
platform devices under /sys/devices/platform"), this is causing
a deadlock in __driver_attach(). Fix this by moving the platform
drivers registration to exynos_drm_init().

Suggested-by: Andrzej Hajda 
Signed-off-by: Javier Martinez Canillas 
---

This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].

Inki Dae said that he will fix it property by separating the Exynos DRM
driver in different sub-modules but I post this patch as RFC anyways so
others can test if this fixes their boot issue.

[0]: https://lkml.org/lkml/2014/11/6/125
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg39050.html

 drivers/gpu/drm/exynos/exynos_drm_drv.c | 163 
 1 file changed, 79 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e277d4f..5386fea 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -559,15 +559,58 @@ static const struct component_master_ops exynos_drm_ops = 
{
 static int exynos_drm_platform_probe(struct platform_device *pdev)
 {
struct component_match *match;
-   int ret;

pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

+   match = exynos_drm_match_add(>dev);
+   if (IS_ERR(match))
+   return PTR_ERR(match);
+
+   return component_master_add_with_match(>dev, _drm_ops,
+  match);
+}
+
+static int exynos_drm_platform_remove(struct platform_device *pdev)
+{
+   component_master_del(>dev, _drm_ops);
+   return 0;
+}
+
+static struct platform_driver exynos_drm_platform_driver = {
+   .probe  = exynos_drm_platform_probe,
+   .remove = exynos_drm_platform_remove,
+   .driver = {
+   .name   = "exynos-drm",
+   .pm = _drm_pm_ops,
+   },
+};
+
+static int exynos_drm_init(void)
+{
+   int ret;
+
+   /*
+* Register device object only in case of Exynos SoC.
+*
+* Below codes resolves temporarily infinite loop issue incurred
+* by Exynos drm driver when using multi-platform kernel.
+* So these codes will be replaced with more generic way later.
+*/
+   if (!of_machine_is_compatible("samsung,exynos3") &&
+   !of_machine_is_compatible("samsung,exynos4") &&
+   !of_machine_is_compatible("samsung,exynos5"))
+   return -ENODEV;
+
+   exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
+   NULL, 0);
+   if (IS_ERR(exynos_drm_pdev))
+   return PTR_ERR(exynos_drm_pdev);
+
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(_driver);
if (ret < 0)
-   return ret;
+   goto err_unregister_pdev;
 #endif

 #ifdef CONFIG_DRM_EXYNOS_DP
@@ -591,21 +634,10 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
goto err_unregister_mixer_drv;
 #endif

-   match = exynos_drm_match_add(>dev);
-   if (IS_ERR(match)) {
-   ret = PTR_ERR(match);
-   goto err_unregister_hdmi_drv;
-   }
-
-   ret = component_master_add_with_match(>dev, _drm_ops,
-   match);
-   if (ret < 0)
-   goto err_unregister_hdmi_drv;
-
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(_driver);
if (ret < 0)
-   goto err_del_component_master;
+   goto err_unregister_hdmi_drv;
 #endif

 #ifdef CONFIG_DRM_EXYNOS_FIMC
@@ -636,9 +668,27 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
goto err_unregister_ipp_drv;
 #endif

-   return ret;
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   ret = exynos_drm_probe_vidi();
+   if (ret < 0)
+   goto err_unregister_ipp_dev;
+#endif
+
+   ret = platform_driver_register(_drm_platform_driver);
+   if (ret)
+   goto err_remove_vidi;
+
+   return 0;
+
+err_remove_vidi:
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   exynos_drm_remove_vidi();
+err_unregister_pd:
+#endif

 #ifdef CONFIG_DRM_EXYNOS_IPP
+err_unregister_ipp_dev:
+   exynos_platform_device_ipp_unregister();
 err_unregister_ipp_drv:
platform_driver_unregister(_driver);
 err_unregister_gsc_drv:
@@ -661,11 +711,9 @@ err_unregister_g2d_drv:

 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
-err_del_component_master:
+err_unregister_hdmi_drv:
 #endif
-   component_master_del(>dev, _drm_ops);

-err_unregister_hdmi_drv:
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_driver);
 err_unregister_mixer_drv:
@@ -686,11 

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Gustavo Padovan  writes:

> 2014-11-18 Kevin Hilman :
>
>> Javier Martinez Canillas  writes:
>> 
>> > The Exynos DRM driver register its sub-devices platform drivers in
>> > the probe function but after commit 43c0767 ("of/platform: Move
>> > platform devices under /sys/devices/platform"), this is causing
>> > a deadlock in __driver_attach(). Fix this by moving the platform
>> > drivers registration to exynos_drm_init().
>> >
>> > Suggested-by: Andrzej Hajda 
>> > Signed-off-by: Javier Martinez Canillas > > collabora.co.uk>
>> > ---
>> >
>> > This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman 
>> > [1].
>> >
>> > Inki Dae said that he will fix it property by separating the Exynos DRM
>> > driver in different sub-modules but I post this patch as RFC anyways so
>> > others can test if this fixes their boot issue.
>> 
>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>> it proceeds to panic in the workqueue code called by the asoc max98090
>> codec[1].
>> 
>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>> but I still don't have display output.
>> 
>> Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
>> would really be nice if your linux-next work was tested on these
>> publically-available 542x/5800 platforms (peach-pi, peach-pit,
>> odroid-xu3) which would also allow lots of others to help you test and
>> validate.
>
> It would also be good to add drm-exynos-next to the daily linux-next build.
> Currently drm-exynos-next is ahead of linux-next. This patch from Javier for
> example only applies on linux-next.

Which tree is the drm-exynos-next branch in?

Kevin

[PATCH v3 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 66838a5..695f406 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

[PATCH v3 2/3] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..66838a5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };

 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+   if (panel->desc->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+>desc->bus_format, 1);

return num;
 }
-- 
1.9.1

[PATCH v3 1/3] drm: add bus_formats and nbus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_crtc.c | 30 ++
 include/drm/drm_crtc.h |  7 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..17e3acf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,36 @@ static void drm_mode_remove(struct drm_connector 
*connector,
drm_mode_destroy(connector->dev, mode);
 }

+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 
*fmts,
+unsigned int num_fmts)
+{
+   u32 *formats = NULL;
+
+   if (!fmts && num_fmts)
+   return -EINVAL;
+
+   if (fmts && num_fmts) {
+   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = formats;
+   info->num_bus_formats = num_fmts;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..2e0a3e8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *fmts, unsigned int 
nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[PATCH v3 0/3] drm: describe display bus format

[Boris Brezillon]

Hello,

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris Brezillon (3):
  drm: add bus_formats and nbus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 30 ++
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  7 +++
 3 files changed, 43 insertions(+)

-- 
1.9.1

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

[Boris Brezillon]

Hi Daniel,

On Tue, 18 Nov 2014 09:32:34 +0100
Daniel Vetter  wrote:

> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > From: Mark yao 
> > 
> > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> > 
> > Signed-off-by: Mark Yao 
> > Signed-off-by: Daniel Kurtz 
> > Acked-by: Daniel Vetter 
> > Reviewed-by: Rob Clark 
> > ---
> > 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 
> > 
> > Changes in v4:
> > Adviced by David Herrmann
> > - remove drm_platform_*() usage, use register drm device directly.
> 
> Minor fixup for that part below.
> 
> [snip]
> 
> > +static int rockchip_drm_bind(struct device *dev)
> > +{
> > +   struct drm_device *drm;
> > +   int ret;
> > +
> > +   drm = drm_dev_alloc(_drm_driver, dev);
> > +   if (!drm)
> > +   return -ENOMEM;
> > +
> > +   ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
> > +   if (ret)
> > +   goto err_free;
> 
> Please call rockchip_drm_load here directly and don't put it as the ->load
> function into the driver vtable. The point of the alloc/register split is
> that the driver can be completely set up _before_ we register anything.
> But for backwards compat and historical reasons ->load is called somewhere
> in the middle (so that you could access the minor nodes if needed, since
> some drivers do that).

I tried to do the same in the atmel-hlcdc DRM driver, but I need the
primary drm_minor to register the connectors (see this kernel
backtrace [1]), which means I either initialize the connector in the
wrong place (currently part of the drm load process), or I just can't
call atmel_hlcdc_dc_load before registering the drm device...

Regards,

Boris

[1]http://code.bulix.org/fi7trt-87436


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Bug 64376] Drop down List

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

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

Smruti  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|NOTABUG |FIXED

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

[Bug 64376] Drop down List

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

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

Smruti  changed:

   What|Removed |Added

Summary|radeon fatal error during   |Drop down List
   |GPU init (Radeon 5850, KVM  |
   |GPU passthrough)|

-- 
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/20141118/84b68a3b/attachment.html>

[PATCH 1/2] drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor

[Alex Deucher]

On Tue, Nov 18, 2014 at 4:00 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> The cursor_set2 hook provides the cursor hotspot position within the
> cursor image. When the hotspot position changes, we can adjust the cursor
> position such that the hotspot doesn't move on the screen. This prevents
> the cursor from appearing to intermittently jump around on the screen
> when the position of the hotspot within the cursor image changes.
>
> Reviewed-by: Alex Deucher 
> Signed-off-by: Michel Dänzer 

Series applied to my -next tree.

Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_cursor.c  | 51 
> ++---
>  drivers/gpu/drm/radeon/radeon_display.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_mode.h| 16 +++
>  3 files changed, 52 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index 9630e8d..fd4bddf 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -117,8 +117,10 @@ static void radeon_show_cursor(struct drm_crtc *crtc)
> }
>  }
>
> +static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y);
> +
>  static void radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object 
> *obj,
> - uint64_t gpu_addr)
> + uint64_t gpu_addr, int hot_x, int hot_y)
>  {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> struct radeon_device *rdev = crtc->dev->dev_private;
> @@ -142,13 +144,28 @@ static void radeon_set_cursor(struct drm_crtc *crtc, 
> struct drm_gem_object *obj,
> /* offset is from DISP(2)_BASE_ADDRESS */
> WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
> radeon_crtc->legacy_cursor_offset);
> }
> +
> +   if (hot_x != radeon_crtc->cursor_hot_x ||
> +   hot_y != radeon_crtc->cursor_hot_y) {
> +   int x, y;
> +
> +   x = radeon_crtc->cursor_x + radeon_crtc->cursor_hot_x - hot_x;
> +   y = radeon_crtc->cursor_y + radeon_crtc->cursor_hot_y - hot_y;
> +
> +   radeon_cursor_move_locked(crtc, x, y);
> +
> +   radeon_crtc->cursor_hot_x = hot_x;
> +   radeon_crtc->cursor_hot_y = hot_y;
> +   }
>  }
>
> -int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> -  struct drm_file *file_priv,
> -  uint32_t handle,
> -  uint32_t width,
> -  uint32_t height)
> +int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
> +   struct drm_file *file_priv,
> +   uint32_t handle,
> +   uint32_t width,
> +   uint32_t height,
> +   int32_t hot_x,
> +   int32_t hot_y)
>  {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> struct radeon_device *rdev = crtc->dev->dev_private;
> @@ -192,7 +209,7 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> radeon_crtc->cursor_height = height;
>
> radeon_lock_cursor(crtc, true);
> -   radeon_set_cursor(crtc, obj, gpu_addr);
> +   radeon_set_cursor(crtc, obj, gpu_addr, hot_x, hot_y);
> radeon_show_cursor(crtc);
> radeon_lock_cursor(crtc, false);
>
> @@ -215,8 +232,7 @@ fail:
> return ret;
>  }
>
> -int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> -   int x, int y)
> +static int radeon_cursor_move_locked(struct drm_crtc *crtc, int x, int y)
>  {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> struct radeon_device *rdev = crtc->dev->dev_private;
> @@ -281,7 +297,6 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> }
> }
>
> -   radeon_lock_cursor(crtc, true);
> if (ASIC_IS_DCE4(rdev)) {
> WREG32(EVERGREEN_CUR_POSITION + radeon_crtc->crtc_offset, (x 
> << 16) | y);
> WREG32(EVERGREEN_CUR_HOT_SPOT + radeon_crtc->crtc_offset, 
> (xorigin << 16) | yorigin);
> @@ -308,7 +323,21 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
> (radeon_crtc->legacy_cursor_offset +
>   
> (yorigin * 256)));
> }
> -   radeon_lock_cursor(crtc, false);
> +
> +   radeon_crtc->cursor_x = x;
> +   radeon_crtc->cursor_y = y;
>
> return 0;
>  }
> +
> +int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> +   int x, int y)
> +{
> +   int ret;
> +
> +   radeon_lock_cursor(crtc, true);
> +   ret = radeon_cursor_move_locked(crtc, x, y);
> +   radeon_lock_cursor(crtc, false);
> +
> +   return ret;
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> 

[BUG] blocked task after exynos_drm_init

[Javier Martinez Canillas]

[adding Kevin to cc list]

Hello Inki,

On Tue, Nov 18, 2014 at 11:52 AM, Inki Dae  wrote:
> On 2014년 11월 18일 19:42, Andrzej Hajda wrote:
>> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> On last next (next-20141104, next-20141105) booting locks after
>>> initializing Exynos DRM (Trats2 board):
>>>
>>> [2.028283] [drm] Initialized drm 1.1.0 20060810
>>> [  240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
>>> [  240.510825]   Not tainted 3.18.0-rc3-next-20141105 #794
>>> [  240.516418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>>> this message.
>>> [  240.524173] swapper/0   D c052534c 0 1  0 0x
>>> [  240.530527] [] (__schedule) from [] 
>>> (schedule_preempt_disabled+0x14/0x20)
>>> [  240.539030] [] (schedule_preempt_disabled) from [] 
>>> (mutex_lock_nested+0x1c4/0x464)
>>> [  240.548320] [] (mutex_lock_nested) from [] 
>>> (__driver_attach+0x48/0x98)
>>> [  240.556562] [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x54/0x88)
>>> [  240.564717] [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0xe4/0x200)
>>> [  240.572876] [] (bus_add_driver) from [] 
>>> (driver_register+0x78/0xf4)
>>> [  240.580864] [] (driver_register) from [] 
>>> (exynos_drm_platform_probe+0x34/0x234)
>>> [  240.589890] [] (exynos_drm_platform_probe) from [] 
>>> (platform_drv_probe+0x48/0xa4)
>>> [  240.599090] [] (platform_drv_probe) from [] 
>>> (driver_probe_device+0x13c/0x37c)
>>> [  240.607940] [] (driver_probe_device) from [] 
>>> (__driver_attach+0x94/0x98)
>>> [  240.616360] [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x54/0x88)
>>> [  240.624517] [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0xe4/0x200)
>>> [  240.632679] [] (bus_add_driver) from [] 
>>> (driver_register+0x78/0xf4)
>>> [  240.640667] [] (driver_register) from [] 
>>> (exynos_drm_init+0x70/0xa0)
>>> [  240.648739] [] (exynos_drm_init) from [] 
>>> (do_one_initcall+0xac/0x1f0)
>>> [  240.656914] [] (do_one_initcall) from [] 
>>> (kernel_init_freeable+0x10c/0x1d8)
>>> [  240.665591] [] (kernel_init_freeable) from [] 
>>> (kernel_init+0x8/0xec)
>>> [  240.673661] [] (kernel_init) from [] 
>>> (ret_from_fork+0x14/0x2c)
>>> [  240.681196] 3 locks held by swapper/0/1:
>>> [  240.685091]  #0:  (>mutex){..}, at: [] 
>>> __driver_attach+0x48/0x98
>>> [  240.692732]  #1:  (>mutex){..}, at: [] 
>>> __driver_attach+0x58/0x98
>>> [  240.700367]  #2:  (>mutex){..}, at: [] 
>>> __driver_attach+0x48/0x98
>>
>>
>> This is caused by patch moving platform devices to
>> /sys/devices/platform[1]. Since this patch registering platform
>> drivers/devices in probe of platform device causes deadlocks. I guess
>> now all driver registration should be moved to exynos_drm_init and it
>> seems better location for it IMHO.
>
> Thanks. It might be a chance that we could separate sub drivers of
> Exynos drm into independent modules so that they can be called
> independently because if we move them to exynos_drm_init then the
> deferred probe wouldn't work correctly.
>

I don't understand why registering the platform drivers in the
exynos_drm_init() will make deferred probing to not work correctly?
AFAICT it does not matter where the driver is registered since if the
driver probe function is called when the driver is attached and fails
with -EPROBE_DEFER, it will be added to the deferred list and the
probe function will be retried when other drivers are registered due
devices being added (e.g: by OF when matching a compatible string). Or
maybe I'm missing something here?

By the way, I tried moving the platform driver registration to
exynos_drm_init() as suggested by Andrzej and it fixed both the issue
reported in $subject (which is the same reported by Kevin) and the
infinite loop you were tried to fix with your "drm/exynos: fix
infinite loop issue incurred by no pair" patch.

I didn't have display working but that is expected since the machine
is a Peach Pit that has a eDP/LVDS bridge and needs out-of-tree
patches.

I also reverted a few patches on linux-next that said to be fixing
infinite loop issues,  these are:

7afbfcc drm/exynos: fix possible infinite loop issue (in fact I had to
revert this to move the registration from the probe function)
f7c2f36f drm/exynos: resolve infinite loop issue on non multi-platform
06a2f5c drm/exynos: resolve infinite loop issue on multi-platform

And I didn't have the infinite loop issue, so I wonder if those
patches are really necessary or were trying to fix the cause explained
by Andrzej.

Best regards,
Javier

[Bug 85771] unable to handle kernel NULL pointer dereference in dce6_bandwidth_update

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

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

--- Comment #5 from Frederik Himpe  ---
Will this patch be included in Linux 3.18?

-- 
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/20141118/0398ebcb/attachment.html>

[PATCH 3/3] drm/msm: add multiple CRTC and overlay support

[Stephane Viau]

MDP5 currently support one single CRTC with its private pipe.
This change allows the configuration of multiple CRTCs with
the possibility to attach several public planes to these CRTCs.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 265 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 325 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 121 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  13 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  48 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  48 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 107 +++--
 9 files changed, 804 insertions(+), 125 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 51045b0..135c0e5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -25,6 +25,7 @@ msm-y := \
mdp/mdp4/mdp4_kms.o \
mdp/mdp4/mdp4_plane.o \
mdp/mdp5/mdp5_cfg.o \
+   mdp/mdp5/mdp5_ctl.o \
mdp/mdp5/mdp5_crtc.o \
mdp/mdp5/mdp5_encoder.o \
mdp/mdp5/mdp5_irq.o \
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 00c8271..d0c98f9 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -24,6 +24,7 @@
  */
 extern const struct mdp5_cfg_hw *mdp5_cfg;

+#define MAX_CTL8
 #define MAX_BASES  8
 #define MAX_SMP_BLOCKS 44
 #define MAX_CLIENTS32
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index ebe2e60..fff012a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2014 The Linux Foundation. All rights reserved.
  * Copyright (C) 2013 Red Hat
  * Author: Rob Clark 
  *
@@ -22,16 +23,24 @@
 #include "drm_crtc_helper.h"
 #include "drm_flip_work.h"

+#define SSPP_MAX   (SSPP_RGB3 + 1) /* TODO: Add SSPP_MAX in mdp5.xml.h */
+
 struct mdp5_crtc {
struct drm_crtc base;
char name[8];
struct drm_plane *plane;
-   struct drm_plane *planes[8];
+   struct drm_plane *planes[SSPP_MAX];
+   int plane_count;
int id;
bool enabled;

-   /* which mixer/encoder we route output to: */
-   int mixer;
+   /* layer mixer used for this CRTC (+ its lock): */
+#define GET_LM_ID(crtc_id) ((crtc_id == 3) ? 5 : crtc_id)
+   int lm;
+   spinlock_t lm_lock; /* protect REG_MDP5_LM_* registers */
+
+   /* CTL used for this CRTC: */
+   void *ctl;

/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
@@ -58,6 +67,7 @@ struct mdp5_crtc {
struct mdp_irq err;
 };
 #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
+#define is_private_plane(mdp5_crtc, drm_plane) (drm_plane == 
(mdp5_crtc)->plane)

 static struct mdp5_kms *get_kms(struct drm_crtc *crtc)
 {
@@ -73,26 +83,35 @@ static void request_pending(struct drm_crtc *crtc, uint32_t 
pending)
mdp_irq_register(_kms(crtc)->base, _crtc->vblank);
 }

-static void crtc_flush(struct drm_crtc *crtc)
+#define mdp5_lm_get_flush(lm)  mdp_ctl_flush_mask_lm(lm)
+
+static void crtc_flush(struct drm_crtc *crtc, u32 flush_mask)
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
-   struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   int id = mdp5_crtc->id;
-   uint32_t i, flush = 0;
+
+   DBG("%s: flush=%08x", mdp5_crtc->name, flush_mask);
+   mdp5_ctl_commit(mdp5_crtc->ctl, flush_mask);
+}
+
+/*
+ * flush updates, to make sure hw is updated to new scanout fb,
+ * so that we can safely queue unref to current fb (ie. next
+ * vblank we know hw is done w/ previous scanout_fb).
+ */
+static void crtc_flush_all(struct drm_crtc *crtc)
+{
+   struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
+   uint32_t i, flush_mask = 0;

for (i = 0; i < ARRAY_SIZE(mdp5_crtc->planes); i++) {
struct drm_plane *plane = mdp5_crtc->planes[i];
-   if (plane) {
-   enum mdp5_pipe pipe = mdp5_plane_pipe(plane);
-   flush |= pipe2flush(pipe);
-   }
+   if (plane)
+   flush_mask |= mdp5_plane_get_flush(plane);
}
-   flush |= mixer2flush(mdp5_crtc->id);
-   flush |= MDP5_CTL_FLUSH_CTL;
+   flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl);
+   flush_mask |= mdp5_lm_get_flush(mdp5_crtc->lm);

-   DBG("%s: flush=%08x", mdp5_crtc->name, flush);
-
-   mdp5_write(mdp5_kms, REG_MDP5_CTL_FLUSH(id), flush);
+   

[PATCH 2/3] drm/msm/mdp5: introduce mdp5_cfg module

[Stephane Viau]

The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 215 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  88 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 211 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  39 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c |   9 +-
 6 files changed, 354 insertions(+), 209 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 6283dcb..51045b0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -24,6 +24,7 @@ msm-y := \
mdp/mdp4/mdp4_irq.o \
mdp/mdp4/mdp4_kms.o \
mdp/mdp4/mdp4_plane.o \
+   mdp/mdp5/mdp5_cfg.o \
mdp/mdp5/mdp5_crtc.o \
mdp/mdp5/mdp5_encoder.o \
mdp/mdp5/mdp5_irq.o \
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
new file mode 100644
index 000..62e77d1
--- /dev/null
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -0,0 +1,215 @@
+/*
+ * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "mdp5_kms.h"
+#include "mdp5_cfg.h"
+
+struct mdp5_cfg_handler {
+   int revision;
+   struct mdp5_cfg config;
+};
+
+/* mdp5_cfg must be exposed (used in mdp5.xml.h) */
+const struct mdp5_cfg_hw *mdp5_cfg = NULL;
+
+const struct mdp5_cfg_hw msm8x74_config = {
+   .name = "msm8x74",
+   .smp = {
+   .mmb_count = 22,
+   .mmb_size = 4096,
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   },
+   .pipe_vig = {
+   .count = 3,
+   .base = { 0x01200, 0x01600, 0x01a00 },
+   },
+   .pipe_rgb = {
+   .count = 3,
+   .base = { 0x01e00, 0x02200, 0x02600 },
+   },
+   .pipe_dma = {
+   .count = 2,
+   .base = { 0x02a00, 0x02e00 },
+   },
+   .lm = {
+   .count = 5,
+   .base = { 0x03200, 0x03600, 0x03a00, 0x03e00, 0x04200 },
+   .nb_stages = 5,
+   },
+   .dspp = {
+   .count = 3,
+   .base = { 0x04600, 0x04a00, 0x04e00 },
+   },
+   .ad = {
+   .count = 2,
+   .base = { 0x13100, 0x13300 }, /* NOTE: no ad in v1.0 */
+   },
+   .intf = {
+   .count = 4,
+   .base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
+   },
+   .max_clk = 2,
+};
+
+const struct mdp5_cfg_hw apq8084_config = {
+   .name = "apq8084",
+   .smp = {
+   .mmb_count = 44,
+   .mmb_size = 8192,
+   .reserved_state[0] = GENMASK(7, 0), /* first 8 MMBs */
+   .reserved[CID_RGB0] = 2,
+   .reserved[CID_RGB1] = 2,
+   .reserved[CID_RGB2] = 2,
+   .reserved[CID_RGB3] = 2,
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   },
+   .pipe_vig = {
+   .count = 4,
+   .base = { 0x01200, 0x01600, 0x01a00, 0x01e00 },
+   },
+   .pipe_rgb = {
+   .count = 4,
+   .base = { 0x02200, 0x02600, 0x02a00, 0x02e00 },
+   },
+   .pipe_dma = {
+   .count = 2,
+   .base = { 0x03200, 0x03600 },
+   },
+   .lm = {
+   .count = 6,
+   .base = { 0x03a00, 0x03e00, 0x04200, 0x04600, 0x04a00, 0x04e00 
},
+   .nb_stages = 5,
+   },
+   .dspp = {
+   .count = 4,
+   .base = { 0x05200, 0x05600, 0x05a00, 0x05e00 },
+
+   },
+   .ad = {
+   .count = 3,
+   .base = { 0x13500, 0x13700, 0x13900 },
+   },
+   .intf = {
+   .count = 5,
+   .base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
+   },
+   .max_clk = 32000,
+};
+
+static const struct mdp5_cfg_handler cfg_handlers[] = {
+   { .revision = 0, .config = { .hw = _config } },
+   { 

[PATCH 1/3] drm/msm/mdp5: make SMP module dynamically configurable

[Stephane Viau]

The Shared Memory Pool (SMP) has its own limitation, features and
state. Some examples are:
 - the number of Memory Macro Block (MMB) and their size
 - the number of lines that can be fetched
 - the state of MMB currently allocated
 - the computation of number of blocks required per plane
 - client IDs ...

In order to avoid private data to be overwritten by other modules,
let's make these private to the SMP module.

Some of these depend on the hardware configuration, let's add them
to the mdp5_config struct.

In some hw configurations, some MMBs are statically tied to RGB
pipes and cannot be re-allocated dynamically. This change
introduces the concept of MMB static usage and makes sure that
dynamic MMB requests are dimensioned accordingly.

A note on passing a pipe pointer, instead of client IDs:
Client IDs are SMP-related information. Passing PIPE information
to SMP lets SMP module to find out which SMP client(s) are used.
This allows the SMP module to access the PIPE pointer, which can
be used for FIFO watermark configuration.
By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers
are part of the PIPE registers, their functionality is to reflect
the behavior of the SMP block. These registers access is now
restricted to the SMP module.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  28 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  34 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  92 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   | 242 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h   |  22 +--
 5 files changed, 265 insertions(+), 153 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index f2c15bd..0d6306d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -30,6 +30,10 @@ const struct mdp5_config *mdp5_cfg;

 static const struct mdp5_config msm8x74_config = {
.name = "msm8x74",
+   .smp = {
+   .mmb_count = 22,
+   .mmb_size = 4096,
+   },
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
@@ -67,6 +71,15 @@ static const struct mdp5_config msm8x74_config = {

 static const struct mdp5_config apq8084_config = {
.name = "apq8084",
+   .smp = {
+   .mmb_count = 44,
+   .mmb_size = 8192,
+   .reserved_state[0] = GENMASK(7, 0), /* first 8 MMBs */
+   .reserved[CID_RGB0] = 2,
+   .reserved[CID_RGB1] = 2,
+   .reserved[CID_RGB2] = 2,
+   .reserved[CID_RGB3] = 2,
+   },
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
@@ -222,11 +235,15 @@ static void mdp5_destroy(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct msm_mmu *mmu = mdp5_kms->mmu;
+   void *smp = mdp5_kms->smp_priv;

if (mmu) {
mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
mmu->funcs->destroy(mmu);
}
+   if (smp)
+   mdp5_smp_destroy(smp);
+
kfree(mdp5_kms);
 }

@@ -363,6 +380,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
struct mdp5_kms *mdp5_kms;
struct msm_kms *kms = NULL;
struct msm_mmu *mmu;
+   void *priv;
int i, ret;

mdp5_kms = kzalloc(sizeof(*mdp5_kms), GFP_KERNEL);
@@ -377,7 +395,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
kms = _kms->base.base;

mdp5_kms->dev = dev;
-   mdp5_kms->smp_blk_cnt = config->smp_blk_cnt;

mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys", "MDP5");
if (IS_ERR(mdp5_kms->mmio)) {
@@ -429,6 +446,13 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
/* TODO: compute core clock rate at runtime */
clk_set_rate(mdp5_kms->src_clk, mdp5_kms->hw_cfg->max_clk);

+   priv = mdp5_smp_init(mdp5_kms->dev, _kms->hw_cfg->smp);
+   if (IS_ERR(priv)) {
+   ret = PTR_ERR(priv);
+   goto fail;
+   }
+   mdp5_kms->smp_priv = priv;
+
/* make sure things are off before attaching iommu (bootloader could
 * have left things on, in which case we'll start getting faults if
 * we don't disable):
@@ -489,8 +513,6 @@ static struct mdp5_platform_config *mdp5_get_config(struct 
platform_device *dev)
/* TODO */
 #endif
config.iommu = iommu_domain_alloc(_bus_type);
-   /* TODO get from DT: */
-   config.smp_blk_cnt = 22;

return 
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index bdbdcda..753659b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -23,12 +23,22 @@
 #include "mdp/mdp_kms.h"
 /* dynamic offsets used 

[PATCH 0/3] Update SMP, add CFG and Overlay support

[Stephane Viau]

This patch set updates the SMP config for MDP5, introduces a Config module for
easier platform config update and allows MDP5 driver to use multiple CRTCs as
well as multiple planes (overlay).

Stephane Viau (3):
  drm/msm/mdp5: make SMP module dynamically configurable
  drm/msm/mdp5: introduce mdp5_cfg module
  drm/msm: add multiple CRTC and overlay support

 drivers/gpu/drm/msm/Makefile|   2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 215 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  89 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 265 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 325 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 121 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  13 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 251 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  97 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 175 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 247 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h |  22 +-
 12 files changed, 1379 insertions(+), 443 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

--- Comment #23 from Marek Olšák  ---
Created attachment 109669
  --> https://bugs.freedesktop.org/attachment.cgi?id=109669=edit
verify the bisected commit

Can you test the attached patch with Mesa master? It will help to verify that
the bisected commit is the culprit.

-- 
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/20141118/5eb259b6/attachment.html>

[Bug 86432] llvm Unreal Elemental rendering regression

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

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

--- Comment #1 from Andy Furniss  ---
radeonsi R9270X I am getting mainly black screen with just a few frames/blocks
correct since llvm commit -

6f485c0bc532ae7954ca5e0f3fe50a5558b64883 is the first bad commit
commit 6f485c0bc532ae7954ca5e0f3fe50a5558b64883
Author: Matt Arsenault 
Date:   Thu Nov 13 23:03:09 2014 +

R600/SI: Fix fmin_legacy / fmax_legacy matching for SI

select_cc is expanded on SI, so this was never matched.

-- 
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/20141118/dc6c7326/attachment.html>

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Inki Dae]

This patch fixes a infinite loop issue incurred when
it doesn't have a pair of crtc and connector drivers,
which was reported by Kevin Hilman like below,
  http://www.spinics.net/lists/linux-samsung-soc/msg39050.html

cdev->conn_dev could be NULL by exynos_drm_component_del call in case
that connector driver is failed while probing after compoments to crtc
and connector drivers are added to specific drm_compoment_list.
In this case, exynos_drm_match_add returns -EPROBE_DEFER error and
Exynos drm driver will try the defered probe over and over again.

This patch makes the deferred probe is tried up to 3 times in maximum.
However, this is considered only for Exynos drm so I think other SoC
drivers could also produce same issue. Therefore, the best way to resolve
this issue, infinite loop incurred by defered probe, would be that dd core
is fixed up corrrectly.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..4d84f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -38,6 +38,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0

+#define MAX_TRY_PROBE_DEFER3
+
 static struct platform_device *exynos_drm_pdev;

 static DEFINE_MUTEX(drm_component_lock);
@@ -481,6 +483,7 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
+   static unsigned int try_probe_defer;

mutex_lock(_component_lock);

@@ -527,6 +530,11 @@ out_lock:

mutex_unlock(_component_lock);

+   if (++try_probe_defer > MAX_TRY_PROBE_DEFER) {
+   try_probe_defer = 0;
+   return ERR_PTR(-ENODEV);
+   }
+
return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
 }

-- 
1.7.9.5

[Bug 86357] [RadeonSI] GPU lockup with mesa 10.3.3 / kernel 3.17.2

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

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

--- Comment #3 from madcatx at atlas.cz ---
I haven't tried any of the fixes suggested there yet. I did however updated to
3.17.3 and the box survived yesteday without crashing. Is there anything in
3.17.3 that could have fixed or at least partially mitigagted the problem?
Should I stick with 3.17.2 until you have save more definitive clue as to what
is causing this?

It usually takes a few hours for the crash to happen so I might just have been
lucky though. I'll keep an eye on this report my findings in the "BUG 85647"
thread.

Thanks...

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

[BUG] blocked task after exynos_drm_init

[Andrzej Hajda]

On 11/18/2014 11:52 AM, Inki Dae wrote:
> On 2014년 11월 18일 19:42, Andrzej Hajda wrote:
>> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> On last next (next-20141104, next-20141105) booting locks after
>>> initializing Exynos DRM (Trats2 board):
>>>
>>> [2.028283] [drm] Initialized drm 1.1.0 20060810
>>> [  240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
>>> [  240.510825]   Not tainted 3.18.0-rc3-next-20141105 #794
>>> [  240.516418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>>> this message.
>>> [  240.524173] swapper/0   D c052534c 0 1  0 0x
>>> [  240.530527] [] (__schedule) from [] 
>>> (schedule_preempt_disabled+0x14/0x20)
>>> [  240.539030] [] (schedule_preempt_disabled) from [] 
>>> (mutex_lock_nested+0x1c4/0x464)
>>> [  240.548320] [] (mutex_lock_nested) from [] 
>>> (__driver_attach+0x48/0x98)
>>> [  240.556562] [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x54/0x88)
>>> [  240.564717] [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0xe4/0x200)
>>> [  240.572876] [] (bus_add_driver) from [] 
>>> (driver_register+0x78/0xf4)
>>> [  240.580864] [] (driver_register) from [] 
>>> (exynos_drm_platform_probe+0x34/0x234)
>>> [  240.589890] [] (exynos_drm_platform_probe) from [] 
>>> (platform_drv_probe+0x48/0xa4)
>>> [  240.599090] [] (platform_drv_probe) from [] 
>>> (driver_probe_device+0x13c/0x37c)
>>> [  240.607940] [] (driver_probe_device) from [] 
>>> (__driver_attach+0x94/0x98)
>>> [  240.616360] [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x54/0x88)
>>> [  240.624517] [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0xe4/0x200)
>>> [  240.632679] [] (bus_add_driver) from [] 
>>> (driver_register+0x78/0xf4)
>>> [  240.640667] [] (driver_register) from [] 
>>> (exynos_drm_init+0x70/0xa0)
>>> [  240.648739] [] (exynos_drm_init) from [] 
>>> (do_one_initcall+0xac/0x1f0)
>>> [  240.656914] [] (do_one_initcall) from [] 
>>> (kernel_init_freeable+0x10c/0x1d8)
>>> [  240.665591] [] (kernel_init_freeable) from [] 
>>> (kernel_init+0x8/0xec)
>>> [  240.673661] [] (kernel_init) from [] 
>>> (ret_from_fork+0x14/0x2c)
>>> [  240.681196] 3 locks held by swapper/0/1:
>>> [  240.685091]  #0:  (>mutex){..}, at: [] 
>>> __driver_attach+0x48/0x98
>>> [  240.692732]  #1:  (>mutex){..}, at: [] 
>>> __driver_attach+0x58/0x98
>>> [  240.700367]  #2:  (>mutex){..}, at: [] 
>>> __driver_attach+0x48/0x98
>>
>>
>> This is caused by patch moving platform devices to
>> /sys/devices/platform[1]. Since this patch registering platform
>> drivers/devices in probe of platform device causes deadlocks. I guess
>> now all driver registration should be moved to exynos_drm_init and it
>> seems better location for it IMHO.
> 
> Thanks. It might be a chance that we could separate sub drivers of
> Exynos drm into independent modules so that they can be called
> independently because if we move them to exynos_drm_init then the
> deferred probe wouldn't work correctly.

For full separation of sub-drivers component matching code should be
fixed first. Now it usually works because components are probed before
exynos_drm_match_add and this is because components are probed during
sub-driver registrations.

Regards
Andrzej

> 
> Thanks,
> Inki Dae
> 
>>
>> Regards
>> Andrzej
>>
>> [1]: http://www.spinics.net/lists/devicetree/msg56101.html
>>
>>
>>
>>>
>>> Full dmesg and config attached.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Javier Martinez Canillas]

Hello Andrzej,

On Tue, Nov 18, 2014 at 11:48 AM, Andrzej Hajda  wrote:
>> So we have two issues here and your patch is only a workaround for the later.
>
> This is the same issue Krzysztof reported two weeks ago and I answered
> him with my diagnosis[1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/39804
>

Great, thanks a lot for finding the cause of this issue!

> Regards
> Andrzej
>

Best regards,
Javier

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  wrote:
> This series is based on master branch of Linus tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> Changes since V2:
> -- Address comments from Jingoo Han for ps8622 driver
> -- Address comments from Daniel, Rob and Thierry regarding
>bridge chaining
> -- Address comments from Thierry regarding the names for
>new drm_panel functions
>
> Changes since V3:
> -- Remove hotplug based initialization of exynos_dp
> -- Make exynos_dp work directly with drm_panel, remove
>dependency on panel_binder
> -- Minor cleanups in panel_binder and panel_lvds driver
>
> Changes since V4:
> -- Use gpiod interface for panel-lvds and ps8622 drivers.
> -- Address comments from Javier.
> -- Fix compilation issues when PANEL_BINDER is selected as module.
> -- Split Documentation patches from driver patches.
> -- Rebase on top of the tree.
>
> Changes since V5:
> -- Modify bridge drivers to support driver model.
> -- Drop the concept of bridge chain(sincle there are no 2 real 
> bridges)
>Hence drop bridge-panel_binder layer.
> -- Drop panel-lvds driver and accomodate the required changes in
>panel-simple driver.
> -- Use gpiod interface in ptn3460 driver.
> -- Address all comments by Thierry Reding for V5 series.
> -- Address comments from Sean Paul for exynos_dp_commit issue.
>
> Changes since V6:
> -- Panel patches were seperated and they are merged already.
> -- Fix few issues with ptn3460, before modifying the bridge core.
> -- Modify drm_bridge as per Thierry's comments for V6 series.
> -- Add drm_bridge changes minimally without breaking existing code.
> -- Add new features for ptn3460, step-by-step.
> -- Address comments from Thierry and Andreas for ptn3460 and ps8622.
> -- Split documentation patches from driver patches.
>
> Changes since V7:
> -- Address comments from Tomi and Laurent:
> -- Use videoports and endpoints to represent the connection 
> between
>encoder, bridge and the panel, instead of using phandles.
> -- Address comments from Daniel:
> -- Make the patch description more descriptive.
> -- remove device pointer from drm_bridge, and just use
>device_node instead.
> -- don't pass encoder pointer to bridge_attach.
> -- Address comments from Sean Paul:
> -- Remove bridge from mode_config, and pull out drm_bridge
>functions from drm_crtc.c to drm_bridge.c
>
> Note: This patchset creates the following Kconfig ambiguity.
>   Any pointers to fix the same are welcome.
>
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on 
> DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
> DRM_PTN3460
> drivers/gpu/drm/bridge/Kconfig:1:   symbol DRM_PTN3460 depends on I2C
> drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on 
> FB_CYBER2000
> drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB
>
> Ajay Kumar (13):
>   [PATCH V8 1/14] drm/bridge: ptn3460: Few trivial cleanups
>   [PATCH V8 2/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
>   [PATCH V8 3/14] drm/bridge: make bridge registration independent of drm flow
>   [PATCH V8 4/14] drm/bridge: ptn3460: Convert to i2c driver model
>   [PATCH V8 5/14] drm/exynos: dp: support drm_bridge
>   [PATCH V8 6/14] drm/bridge: ptn3460: support drm_panel
>   [PATCH V8 7/14] drm/bridge: ptn3460: probe connector at the end of bridge 
> attach
>   [PATCH V8 8/14] drm/bridge: ptn3460: use gpiod interface
>   [PATCH V8 9/14] Documentation: drm: bridge: move to video/bridge
>   [PATCH V8 10/14] Documentation: devicetree: Add vendor prefix for parade
>   [PATCH V8 11/14] Documentation: bridge: Add documentation for ps8622 DT 
> properties
>   [PATCH V8 13/14] ARM: dts: snow: represent the connection between bridge 
> and panel
> using videoport and endpoints
>   [PATCH V8 14/14] ARM: dts: peach-pit: represent the connection between 
> bridge and
> panel using videoport and endpoints
>
> Vincent Palatin (1):
>   [PATCH V8 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
>
>  .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 -
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  .../devicetree/bindings/video/bridge/ps8622.txt|   31 +
>  

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Andrzej Hajda]

On 11/18/2014 11:23 AM, Javier Martinez Canillas wrote:
> Hello Inki,
> 
>> Right, but at least, we could avoid kernel booting failure which is very
>> critical. Please know that this patch is temporary to avoid the kernel
>> booting failure although deferred probe request of Exynos drm could be
>> broken. For this, I will look into dd core to find out more generic way:
>> I suspect that this might be incurred in case that a driver is probed in
>> probe context of other driver or it might be really dd core bug.
>>
> 
> I gave a try to your patch on top of today's linux-next and I still
> see the same boot failure reported by Kevin on a Exynos5420 Peach Pit
> so $subject does not fix the issue. The boot message is [0] fyi.
> 
> By digging a bit I noticed that this happens when the
> exynos_drm_platform_probe() calls platform_driver_register() to
> register the Exynos fimd platform driver. The problem is that in
> __driver_attach() the call to device_lock(dev->parent) never returns
> and the thread sleeps forever waiting for the device parent mutex to
> be released.
> 
> Do you have any ideas why this could happen?
> 
> If I modify __driver_attach() to only grab the device lock and not its
> parent lock, then the thread is able to hold its own mutex and the
> platform driver registration succeeds but then I see the infinite loop
> that was reported before and the workaround in $subject indeed avoids
> to happen.
> 
> So we have two issues here and your patch is only a workaround for the later.

This is the same issue Krzysztof reported two weeks ago and I answered
him with my diagnosis[1].

[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/39804

Regards
Andrzej

> 
> Best regards,
> Javier
> 
> [0]:
> [1.324091] [drm] Initialized drm 1.1.0 20060810
> [  240.158665] random: nonblocking pool is initialized
> [  240.162202] INFO: task swapper/0:1 blocked for more than 120 seconds.
> [  240.168493]   Not tainted 3.18.0-rc4-next-20141117-1-g85466f9 #22
> [  240.175256] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  240.183064] swapper/0   D c045bb00 0 1  0 0x
> [  240.189410] [] (__schedule) from []
> (schedule_preempt_disabled+0x14/0x20)
> [  240.197904] [] (schedule_preempt_disabled) from
> [] (__mutex_lock_slowpath+0x19c/0x3f4)
> [  240.207531] [] (__mutex_lock_slowpath) from []
> (mutex_lock+0xc/0x24)
> [  240.215599] [] (mutex_lock) from []
> (__driver_attach+0x44/0x90)
> [  240.223239] [] (__driver_attach) from []
> (bus_for_each_dev+0x54/0x88)
> [  240.231387] [] (bus_for_each_dev) from []
> (bus_add_driver+0xd8/0x1cc)
> [  240.239541] [] (bus_add_driver) from []
> (driver_register+0x78/0xf4)
> [  240.247523] [] (driver_register) from []
> (exynos_drm_platform_probe+0x34/0x188)
> [  240.256546] [] (exynos_drm_platform_probe) from
> [] (platform_drv_probe+0x48/0x98)
> [  240.265739] [] (platform_drv_probe) from []
> (driver_probe_device+0x114/0x234)
> [  240.274588] [] (driver_probe_device) from []
> (__driver_attach+0x8c/0x90)
> [  240.283003] [] (__driver_attach) from []
> (bus_for_each_dev+0x54/0x88)
> [  240.291158] [] (bus_for_each_dev) from []
> (bus_add_driver+0xd8/0x1cc)
> [  240.299311] [] (bus_add_driver) from []
> (driver_register+0x78/0xf4)
> [  240.307293] [] (driver_register) from []
> (exynos_drm_init+0x84/0xd0)
> [  240.315362] [] (exynos_drm_init) from []
> (do_one_initcall+0x80/0x1d0)
> [  240.323521] [] (do_one_initcall) from []
> (kernel_init_freeable+0x108/0x1d4)
> [  240.332191] [] (kernel_init_freeable) from []
> (kernel_init+0x8/0xe4)
> [  240.340261] [] (kernel_init) from []
> (ret_from_fork+0x14/0x3c)
> 

[BUG] blocked task after exynos_drm_init

[Andrzej Hajda]

On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
> Hi,
> 
> On last next (next-20141104, next-20141105) booting locks after
> initializing Exynos DRM (Trats2 board):
> 
> [2.028283] [drm] Initialized drm 1.1.0 20060810
> [  240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
> [  240.510825]   Not tainted 3.18.0-rc3-next-20141105 #794
> [  240.516418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  240.524173] swapper/0   D c052534c 0 1  0 0x
> [  240.530527] [] (__schedule) from [] 
> (schedule_preempt_disabled+0x14/0x20)
> [  240.539030] [] (schedule_preempt_disabled) from [] 
> (mutex_lock_nested+0x1c4/0x464)
> [  240.548320] [] (mutex_lock_nested) from [] 
> (__driver_attach+0x48/0x98)
> [  240.556562] [] (__driver_attach) from [] 
> (bus_for_each_dev+0x54/0x88)
> [  240.564717] [] (bus_for_each_dev) from [] 
> (bus_add_driver+0xe4/0x200)
> [  240.572876] [] (bus_add_driver) from [] 
> (driver_register+0x78/0xf4)
> [  240.580864] [] (driver_register) from [] 
> (exynos_drm_platform_probe+0x34/0x234)
> [  240.589890] [] (exynos_drm_platform_probe) from [] 
> (platform_drv_probe+0x48/0xa4)
> [  240.599090] [] (platform_drv_probe) from [] 
> (driver_probe_device+0x13c/0x37c)
> [  240.607940] [] (driver_probe_device) from [] 
> (__driver_attach+0x94/0x98)
> [  240.616360] [] (__driver_attach) from [] 
> (bus_for_each_dev+0x54/0x88)
> [  240.624517] [] (bus_for_each_dev) from [] 
> (bus_add_driver+0xe4/0x200)
> [  240.632679] [] (bus_add_driver) from [] 
> (driver_register+0x78/0xf4)
> [  240.640667] [] (driver_register) from [] 
> (exynos_drm_init+0x70/0xa0)
> [  240.648739] [] (exynos_drm_init) from [] 
> (do_one_initcall+0xac/0x1f0)
> [  240.656914] [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x10c/0x1d8)
> [  240.665591] [] (kernel_init_freeable) from [] 
> (kernel_init+0x8/0xec)
> [  240.673661] [] (kernel_init) from [] 
> (ret_from_fork+0x14/0x2c)
> [  240.681196] 3 locks held by swapper/0/1:
> [  240.685091]  #0:  (>mutex){..}, at: [] 
> __driver_attach+0x48/0x98
> [  240.692732]  #1:  (>mutex){..}, at: [] 
> __driver_attach+0x58/0x98
> [  240.700367]  #2:  (>mutex){..}, at: [] 
> __driver_attach+0x48/0x98


This is caused by patch moving platform devices to
/sys/devices/platform[1]. Since this patch registering platform
drivers/devices in probe of platform device causes deadlocks. I guess
now all driver registration should be moved to exynos_drm_init and it
seems better location for it IMHO.

Regards
Andrzej

[1]: http://www.spinics.net/lists/devicetree/msg56101.html



> 
> Full dmesg and config attached.
> 
> Best regards,
> Krzysztof
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Javier Martinez Canillas]

Hello Inki,

> Right, but at least, we could avoid kernel booting failure which is very
> critical. Please know that this patch is temporary to avoid the kernel
> booting failure although deferred probe request of Exynos drm could be
> broken. For this, I will look into dd core to find out more generic way:
> I suspect that this might be incurred in case that a driver is probed in
> probe context of other driver or it might be really dd core bug.
>

I gave a try to your patch on top of today's linux-next and I still
see the same boot failure reported by Kevin on a Exynos5420 Peach Pit
so $subject does not fix the issue. The boot message is [0] fyi.

By digging a bit I noticed that this happens when the
exynos_drm_platform_probe() calls platform_driver_register() to
register the Exynos fimd platform driver. The problem is that in
__driver_attach() the call to device_lock(dev->parent) never returns
and the thread sleeps forever waiting for the device parent mutex to
be released.

Do you have any ideas why this could happen?

If I modify __driver_attach() to only grab the device lock and not its
parent lock, then the thread is able to hold its own mutex and the
platform driver registration succeeds but then I see the infinite loop
that was reported before and the workaround in $subject indeed avoids
to happen.

So we have two issues here and your patch is only a workaround for the later.

Best regards,
Javier

[0]:
[1.324091] [drm] Initialized drm 1.1.0 20060810
[  240.158665] random: nonblocking pool is initialized
[  240.162202] INFO: task swapper/0:1 blocked for more than 120 seconds.
[  240.168493]   Not tainted 3.18.0-rc4-next-20141117-1-g85466f9 #22
[  240.175256] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  240.183064] swapper/0   D c045bb00 0 1  0 0x
[  240.189410] [] (__schedule) from []
(schedule_preempt_disabled+0x14/0x20)
[  240.197904] [] (schedule_preempt_disabled) from
[] (__mutex_lock_slowpath+0x19c/0x3f4)
[  240.207531] [] (__mutex_lock_slowpath) from []
(mutex_lock+0xc/0x24)
[  240.215599] [] (mutex_lock) from []
(__driver_attach+0x44/0x90)
[  240.223239] [] (__driver_attach) from []
(bus_for_each_dev+0x54/0x88)
[  240.231387] [] (bus_for_each_dev) from []
(bus_add_driver+0xd8/0x1cc)
[  240.239541] [] (bus_add_driver) from []
(driver_register+0x78/0xf4)
[  240.247523] [] (driver_register) from []
(exynos_drm_platform_probe+0x34/0x188)
[  240.256546] [] (exynos_drm_platform_probe) from
[] (platform_drv_probe+0x48/0x98)
[  240.265739] [] (platform_drv_probe) from []
(driver_probe_device+0x114/0x234)
[  240.274588] [] (driver_probe_device) from []
(__driver_attach+0x8c/0x90)
[  240.283003] [] (__driver_attach) from []
(bus_for_each_dev+0x54/0x88)
[  240.291158] [] (bus_for_each_dev) from []
(bus_add_driver+0xd8/0x1cc)
[  240.299311] [] (bus_add_driver) from []
(driver_register+0x78/0xf4)
[  240.307293] [] (driver_register) from []
(exynos_drm_init+0x84/0xd0)
[  240.315362] [] (exynos_drm_init) from []
(do_one_initcall+0x80/0x1d0)
[  240.323521] [] (do_one_initcall) from []
(kernel_init_freeable+0x108/0x1d4)
[  240.332191] [] (kernel_init_freeable) from []
(kernel_init+0x8/0xe4)
[  240.340261] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #37 from Hannu  ---
Created attachment 109668
  --> https://bugs.freedesktop.org/attachment.cgi?id=109668=edit
check space after r600_need_dma_space()

By the way, at some point while testing I noticed that si_dma_copy_tile() does
not check that it actually got the space it wanted after this call:

r600_need_dma_space(>b, ncopy * 9);


void r600_need_dma_space(struct r600_common_context *ctx, unsigned num_dw)
{
/* The number of dwords we already used in the DMA so far. */
num_dw += ctx->rings.dma.cs->cdw;
/* Flush if there's not enough space. */
if (num_dw > RADEON_MAX_CMDBUF_DWORDS) {
ctx->rings.dma.flush(ctx, RADEON_FLUSH_ASYNC, NULL);
}
}

So I added check after r600_need_dma_space():

r600_need_dma_space(>b, ncopy * 9);
if (((ncopy * 9) + cs->cdw) > RADEON_MAX_CMDBUF_DWORDS) {
return 0;
}

and then goto fallback if returns 0, but it crashed anyway so I skipped that as
irrelevant to this bug. (diff attached)

-- 
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/20141118/cec71580/attachment.html>

[PULL resend] amdkfd-v6

[Oded Gabbay]

Hi Dave,

Resending the pull request of amdkfd for 3.19 per your request.

Change from original pull-request is removing the line "default m" from the
Kconfig file of amdkfd.

Here is the link to the previous pull request:
http://lists.freedesktop.org/archives/dri-devel/2014-November/072053.html

Thanks,
Oded

The following changes since commit a015c1e92639cd65ebb49350abdf5ad15bce4448:

  iommu/amd: fix accounting of device_state (2014-11-10 10:57:36 +0200)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux amdkfd-v6

for you to fetch changes up to ecd5c9821c39626fa7c03e9c397586b24cb11b79:

  amdkfd: Implement the Get Version IOCTL (2014-11-02 12:18:29 +0200)


Alexey Skidanov (1):
  amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (2):
  amdkfd: Add interrupt handling module
  amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (7):
  amdkfd: Add queue module
  amdkfd: Add mqd_manager module
  amdkfd: Add kernel queue module
  amdkfd: Add module parameter of scheduling policy
  amdkfd: Add packet manager module
  amdkfd: Add process queue manager module
  amdkfd: Add device queue manager module

Evgeny Pinchuk (2):
  amdkfd: Add topology module to amdkfd
  amdkfd: Implement the Get Clock Counters IOCTL

Oded Gabbay (12):
  drm/radeon: reduce number of free VMIDs and pipes in KV
  drm/radeon/cik: Don't touch int of pipes 1-7
  drm/radeon: Report doorbell configuration to amdkfd
  drm/radeon: adding synchronization for GRBM GFX
  drm/radeon: Add radeon <--> amdkfd interface
  Update MAINTAINERS and CREDITS files with amdkfd info
  amdkfd: Add IOCTL set definitions of amdkfd
  amdkfd: Add amdkfd skeleton driver
  amdkfd: Add basic modules to amdkfd
  amdkfd: Add binding/unbinding calls to amd_iommu driver
  amdkfd: Implement the create/destroy/update queue IOCTLs
  amdkfd: Implement the Get Version IOCTL

 CREDITS|7 +
 MAINTAINERS|   10 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/amd/amdkfd/Kconfig |9 +
 drivers/gpu/drm/amd/amdkfd/Makefile|   14 +
 drivers/gpu/drm/amd/amdkfd/cik_regs.h  |  221 
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  576 +
 drivers/gpu/drm/amd/amdkfd/kfd_crat.h  |  294 +
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  307 +
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 1059 +
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  146 +++
 drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c  |  255 
 drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c   |  355 ++
 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c |  176 +++
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |  347 ++
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h  |   69 ++
 drivers/gpu/drm/amd/amdkfd/kfd_module.c|  159 +++
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c   |  346 ++
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h   |   91 ++
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c|  565 +
 drivers/gpu/drm/amd/amdkfd/kfd_pasid.c |   97 ++
 drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers.h   |  405 +++
 drivers/gpu/drm/amd/amdkfd/kfd_pm4_opcodes.h   |  107 ++
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  598 ++
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  415 +++
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |  342 ++
 drivers/gpu/drm/amd/amdkfd/kfd_queue.c |   85 ++
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  | 1235 
 drivers/gpu/drm/amd/amdkfd/kfd_topology.h  |  168 +++
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|  185 +++
 drivers/gpu/drm/radeon/Makefile|1 +
 drivers/gpu/drm/radeon/cik.c   |  155 +--
 drivers/gpu/drm/radeon/cik_reg.h   |  136 +++
 drivers/gpu/drm/radeon/cikd.h  |   53 +-
 drivers/gpu/drm/radeon/radeon.h|   10 +
 drivers/gpu/drm/radeon/radeon_device.c |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c|5 +
 drivers/gpu/drm/radeon/radeon_kfd.c|  563 +
 drivers/gpu/drm/radeon/radeon_kfd.h|   47 +
 drivers/gpu/drm/radeon/radeon_kms.c|7 +
 include/uapi/linux/kfd_ioctl.h |  154 +++
 42 files changed, 9714 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/amd/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_regs.h
 create mode 

[PATCH 2/5] drm: add helper to get crtc timings (v2)

[Jani Nikula]

On Tue, 18 Nov 2014, Matt Roper  wrote:
> From: Gustavo Padovan 
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> Cc: dri-devel at lists.freedesktop.org
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c   | 22 --
>  drivers/gpu/drm/i915/intel_display.c |  6 +++---
>  include/drm/drm_crtc.h   |  2 ++
>  3 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 56737e7..64ec23b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2493,6 +2493,17 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>  }
>  EXPORT_SYMBOL(drm_mode_set_config_internal);
>  
> +void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> + int *hdisplay, int *vdisplay)
> +{
> + struct drm_display_mode adjusted = *mode;

I'd prefer using drm_mode_copy(). It doesn't matter here and now, but if
it starts to matter in the future the problems will be hard to track.

BR,
Jani.


> +
> + drm_mode_stereo_double();
> + *hdisplay = adjusted.crtc_hdisplay;
> + *vdisplay = adjusted.crtc_vdisplay;
> +}
> +EXPORT_SYMBOL(drm_crtc_get_hv_timing);
> +
>  /**
>   * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
>   * CRTC viewport
> @@ -2510,16 +2521,7 @@ int drm_crtc_check_viewport(const struct drm_crtc 
> *crtc,
>  {
>   int hdisplay, vdisplay;
>  
> - hdisplay = mode->hdisplay;
> - vdisplay = mode->vdisplay;
> -
> - if (drm_mode_is_stereo(mode)) {
> - struct drm_display_mode adjusted = *mode;
> -
> - drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
> - hdisplay = adjusted.crtc_hdisplay;
> - vdisplay = adjusted.crtc_vdisplay;
> - }
> + drm_crtc_get_hv_timing(mode, , );
>  
>   if (crtc->invert_dimensions)
>   swap(hdisplay, vdisplay);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 320bf4c..a967623 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>* computation to clearly distinguish it from the adjusted mode, which
>* can be changed by the connectors in the below retry loop.
>*/
> - drm_mode_set_crtcinfo(_config->requested_mode, CRTC_STEREO_DOUBLE);
> - pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
> - pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
> + drm_crtc_get_hv_timing(_config->requested_mode,
> +_config->pipe_src_w,
> +_config->pipe_src_h);
>  
>  encoder_retry:
>   /* Ensure the port clock defaults are reset when retrying. */
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7b28ab0..23236f6 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
>  extern void drm_plane_cleanup(struct drm_plane *plane);
>  extern unsigned int drm_plane_index(struct drm_plane *plane);
>  extern void drm_plane_force_disable(struct drm_plane *plane);
> +extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> +int *hdisplay, int *vdisplay);
>  extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
>  int x, int y,
>  const struct drm_display_mode *mode,
> -- 
> 1.8.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Javier Martinez Canillas  writes:

> The Exynos DRM driver register its sub-devices platform drivers in
> the probe function but after commit 43c0767 ("of/platform: Move
> platform devices under /sys/devices/platform"), this is causing
> a deadlock in __driver_attach(). Fix this by moving the platform
> drivers registration to exynos_drm_init().
>
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Javier Martinez Canillas 
> ---
>
> This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].
>
> Inki Dae said that he will fix it property by separating the Exynos DRM
> driver in different sub-modules but I post this patch as RFC anyways so
> others can test if this fixes their boot issue.

It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
it proceeds to panic in the workqueue code called by the asoc max98090
codec[1].

If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
but I still don't have display output.

Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
would really be nice if your linux-next work was tested on these
publically-available 542x/5800 platforms (peach-pi, peach-pit,
odroid-xu3) which would also allow lots of others to help you test and
validate.

Kevin

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

[Daniel Vetter]

On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> From: Mark yao 
> 
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> 
> Signed-off-by: Mark Yao 
> Signed-off-by: Daniel Kurtz 
> Acked-by: Daniel Vetter 
> Reviewed-by: Rob Clark 
> ---
> 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 
> 
> Changes in v4:
> Adviced by David Herrmann
> - remove drm_platform_*() usage, use register drm device directly.

Minor fixup for that part below.

[snip]

> +static int rockchip_drm_bind(struct device *dev)
> +{
> + struct drm_device *drm;
> + int ret;
> +
> + drm = drm_dev_alloc(_drm_driver, dev);
> + if (!drm)
> + return -ENOMEM;
> +
> + ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
> + if (ret)
> + goto err_free;

Please call rockchip_drm_load here directly and don't put it as the ->load
function into the driver vtable. The point of the alloc/register split is
that the driver can be completely set up _before_ we register anything.
But for backwards compat and historical reasons ->load is called somewhere
in the middle (so that you could access the minor nodes if needed, since
some drivers do that).

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

[PATCH 2/5] drm: add helper to get crtc timings (v3)

[Matt Roper]

From: Gustavo Padovan 

We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.

v2 (by Matt): Use new stereo doubling function (suggested by Ville)

v3 (by Matt):
 - Add missing kerneldoc (Daniel)
 - Use drm_mode_copy() (Jani)

Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c   | 32 ++--
 drivers/gpu/drm/i915/intel_display.c |  6 +++---
 include/drm/drm_crtc.h   |  2 ++
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..be1a485 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set 
*set)
 EXPORT_SYMBOL(drm_mode_set_config_internal);

 /**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+   int *hdisplay, int *vdisplay)
+{
+   struct drm_display_mode adjusted;
+
+   drm_mode_copy(, mode);
+   drm_mode_stereo_double();
+   *hdisplay = adjusted.crtc_hdisplay;
+   *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
  * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
  * CRTC viewport
  * @crtc: CRTC that framebuffer will be displayed on
@@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 {
int hdisplay, vdisplay;

-   hdisplay = mode->hdisplay;
-   vdisplay = mode->vdisplay;
-
-   if (drm_mode_is_stereo(mode)) {
-   struct drm_display_mode adjusted = *mode;
-
-   drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
-   hdisplay = adjusted.crtc_hdisplay;
-   vdisplay = adjusted.crtc_vdisplay;
-   }
+   drm_crtc_get_hv_timing(mode, , );

if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
 * computation to clearly distinguish it from the adjusted mode, which
 * can be changed by the connectors in the below retry loop.
 */
-   drm_mode_set_crtcinfo(_config->requested_mode, CRTC_STEREO_DOUBLE);
-   pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
-   pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
+   drm_crtc_get_hv_timing(_config->requested_mode,
+  _config->pipe_src_w,
+  _config->pipe_src_h);

 encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b28ab0..23236f6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
 extern void drm_plane_cleanup(struct drm_plane *plane);
 extern unsigned int drm_plane_index(struct drm_plane *plane);
 extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+  int *hdisplay, int *vdisplay);
 extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
   int x, int y,
   const struct drm_display_mode *mode,
-- 
1.8.5.1

[PATCH] drm/exynos: fix infinite loop issue incurred by no pair

[Sjoerd Simons]

On Tue, 2014-11-18 at 12:20 +0900, Inki Dae wrote:
> This patch makes the deferred probe is tried up to 3 times in maximum.
> However, this is considered only for Exynos drm so I think other SoC
> drivers could also produce same issue. Therefore, the best way to resolve
> this issue, infinite loop incurred by defered probe, would be that dd core
> is fixed up corrrectly.

At first sight this seems to make little to no sense. Unless i'm
mistaken this would cause the exynos drm probe return -ENODEV to the dd
core, causing it to stop trying to probe. Which obviously breaks your
infinite loop, it also breaks situations where the probe needs to be
retried more then 3 times. 

I suspect with this patch once exynos DRM is loaded and actually validly
needs to defer (iotw when the required modules do exist but simply
aren't loaded just yet), it still jumps into an infinite loop which you
break after 3 tries after which the display will simply never come up
even if everything is in place because the core doesn't know it should
re-probe



> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index eab12f0..4d84f3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -38,6 +38,8 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> +#define MAX_TRY_PROBE_DEFER  3
> +
>  static struct platform_device *exynos_drm_pdev;
>  
>  static DEFINE_MUTEX(drm_component_lock);
> @@ -481,6 +483,7 @@ static struct component_match 
> *exynos_drm_match_add(struct device *dev)
>   struct component_match *match = NULL;
>   struct component_dev *cdev;
>   unsigned int attach_cnt = 0;
> + static unsigned int try_probe_defer;
>  
>   mutex_lock(_component_lock);
>  
> @@ -527,6 +530,11 @@ out_lock:
>  
>   mutex_unlock(_component_lock);
>  
> + if (++try_probe_defer > MAX_TRY_PROBE_DEFER) {
> + try_probe_defer = 0;
> + return ERR_PTR(-ENODEV);
> + }
> +
>   return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
>  }
>  


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

[Intel-gfx] [PATCH 2/5] drm: add helper to get crtc timings (v2)

[Daniel Vetter]

On Mon, Nov 17, 2014 at 06:10:36PM -0800, Matt Roper wrote:
> From: Gustavo Padovan 
> 
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
> 
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
> 
> Cc: dri-devel at lists.freedesktop.org
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c   | 22 --
>  drivers/gpu/drm/i915/intel_display.c |  6 +++---
>  include/drm/drm_crtc.h   |  2 ++
>  3 files changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 56737e7..64ec23b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2493,6 +2493,17 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>  }
>  EXPORT_SYMBOL(drm_mode_set_config_internal);
>  

Kerneldoc missing.
-Daniel

> +void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> + int *hdisplay, int *vdisplay)
> +{
> + struct drm_display_mode adjusted = *mode;
> +
> + drm_mode_stereo_double();
> + *hdisplay = adjusted.crtc_hdisplay;
> + *vdisplay = adjusted.crtc_vdisplay;
> +}
> +EXPORT_SYMBOL(drm_crtc_get_hv_timing);
> +
>  /**
>   * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
>   * CRTC viewport
> @@ -2510,16 +2521,7 @@ int drm_crtc_check_viewport(const struct drm_crtc 
> *crtc,
>  {
>   int hdisplay, vdisplay;
>  
> - hdisplay = mode->hdisplay;
> - vdisplay = mode->vdisplay;
> -
> - if (drm_mode_is_stereo(mode)) {
> - struct drm_display_mode adjusted = *mode;
> -
> - drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
> - hdisplay = adjusted.crtc_hdisplay;
> - vdisplay = adjusted.crtc_vdisplay;
> - }
> + drm_crtc_get_hv_timing(mode, , );
>  
>   if (crtc->invert_dimensions)
>   swap(hdisplay, vdisplay);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 320bf4c..a967623 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>* computation to clearly distinguish it from the adjusted mode, which
>* can be changed by the connectors in the below retry loop.
>*/
> - drm_mode_set_crtcinfo(_config->requested_mode, CRTC_STEREO_DOUBLE);
> - pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
> - pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
> + drm_crtc_get_hv_timing(_config->requested_mode,
> +_config->pipe_src_w,
> +_config->pipe_src_h);
>  
>  encoder_retry:
>   /* Ensure the port clock defaults are reset when retrying. */
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7b28ab0..23236f6 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
>  extern void drm_plane_cleanup(struct drm_plane *plane);
>  extern unsigned int drm_plane_index(struct drm_plane *plane);
>  extern void drm_plane_force_disable(struct drm_plane *plane);
> +extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
> +int *hdisplay, int *vdisplay);
>  extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
>  int x, int y,
>  const struct drm_display_mode *mode,
> -- 
> 1.8.5.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #36 from Michel Dänzer  ---
Thanks for all your testing, BTW!

-- 
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/20141118/db46b4bc/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #35 from Hannu  ---
(In reply to Michel Dänzer from comment #34)
> (In reply to Hannu from comment #33)
> > I'll try "fix that only disables DMA if 1D tiling is involved" from bug 
> > 83500, 
> 
> You can save the time for that, given that it didn't fully fix the problem
> for the reporter of that bug.
> 
> 
> > if that doesn't work I give up and use the fix I did in comment 26.
> 
> Why don't you just use the fix I pushed to resolve this report? :) I
> deliberately didn't keep the second si_dma_copy_buffer path enabled because
> I know (from experience trying to port the DMA code to CIK) that it doesn't
> properly check for all cases it can't handle. I don't think that path is
> very relevant in practice anyway.

OK, I'll stop testing for now.

-- 
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/20141118/1790cfe2/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #34 from Michel Dänzer  ---
(In reply to Hannu from comment #33)
> I'll try "fix that only disables DMA if 1D tiling is involved" from bug 
> 83500, 

You can save the time for that, given that it didn't fully fix the problem for
the reporter of that bug.


> if that doesn't work I give up and use the fix I did in comment 26.

Why don't you just use the fix I pushed to resolve this report? :) I
deliberately didn't keep the second si_dma_copy_buffer path enabled because I
know (from experience trying to port the DMA code to CIK) that it doesn't
properly check for all cases it can't handle. I don't think that path is very
relevant in practice anyway.

-- 
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/20141118/96f53e42/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #33 from Hannu  ---
Tested with a 23 minute full screen flash video same as before.

Mesa 10.4.0-devel and linux 3.18.0-rc5 again: second replay of the video
crashed.

So no luck with that, I'll try "fix that only disables DMA if 1D tiling is
involved" from bug 83500, if that doesn't work I give up and use the fix I did
in comment 26.

-- 
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/20141118/105d4d82/attachment-0001.html>

[Bug 86196] Massive Chalice crashes on startup

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

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

--- Comment #3 from Michel Dänzer  ---
Which version of LLVM are you using? The failing shader seems to compile fine
with a current LLVM SVN snapshot (which will in time be released as 3.6).

-- 
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/20141118/021be3e3/attachment.html>

[Bug 86287] X does not start with kernel 3.17.2 but starts with 3.16.6 (radeon driver).

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
Version|git |unspecified
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

--- Comment #5 from Michel Dänzer  ---
Can you bisect the kernel?

-- 
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/20141118/58a07ba5/attachment.html>

[Bug 86357] [RadeonSI] GPU lockup with mesa 10.3.3 / kernel 3.17.2

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

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

--- Comment #2 from Michel Dänzer  ---
(In reply to Andreas Grois from comment #1)
> This might be a duplicate of
> https://bugs.freedesktop.org/show_bug.cgi?id=85647

Does the fix from that help?

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

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #32 from Hannu  ---
mesa 10.3.2 original debian package without changes and linux 3.18.0-rc5
crashed after a few minutes when playing the video. That is worse than before,
it has usually crashed after four to six replays of the video.

I'll start testing mesa 10.4.0-devel with rc5 again, probably it was a random
fluke that it lasted ten replays, longest this far has been seven replays
without the bypassed si_dma_copy_tile().

-- 
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/20141118/4acaa781/attachment.html>

[PATCH] drm/msm: Don't split an IB at the end of ring buffer.

[kiran.pad...@smartplayin.com]

Hi Ganesan,

On Thursday, October 30, 2014 10:33pm, "Ganesan, Aravind"  said:

> Splitting the command sequence for an IB1 submission at the end of
> the ring buffer can hang the GPU.  To fix this, if there isn't
> enough contiguous space at the end to fit the full command sequence,
> insert NOPs at the end, and write the sequence at the start, as space
> becomes available.
> 
> Signed-off-by: Aravind Ganesan 
> ---
> Resend in patch-set format and with dri-devel at lists.freedesktop.org on
> the CC.
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 45
> ++---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h |  8 +++---
>  2 files changed, 46 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 1fe7c8d..51901df 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -281,10 +281,49 @@ static uint32_t ring_freewords(struct msm_gpu *gpu)
>   return (rptr + (size - 1) - wptr) % size;
>  }
> 
> -void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
> +void adreno_wait_ring_contiguous(struct msm_gpu *gpu,
> + uint32_t ndwords)
>  {
> - if (spin_until(ring_freewords(gpu) >= ndwords))
> - DRM_ERROR("%s: timeout waiting for ringbuffer space\n", 
> gpu->name);
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + uint32_t size = gpu->rb->size/4;
> + uint32_t wptr;
> + uint32_t rptr;
> +
> + /* Wait for free space and then check if they are contiguous */
> + if(spin_until(ring_freewords(gpu)>= ndwords)){
There are some checkpatch errors,

ERROR: spaces required around that '>=' (ctx:VxW)
#42: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:293:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){
 ^
ERROR: space required before the open brace '{'
#42: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:293:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){

ERROR: space required before the open parenthesis '('
#42: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:293:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){


> + DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
> + gpu->name);
> + return;
> + }
> +
> + wptr = get_wptr(gpu->rb);
> + rptr = adreno_gpu->memptrs->rptr;
> +
> + /* We have enough space in the ring for ndwords. Three conditions
> +  * indicates we have contigous space:
> +  * (1) wptr can be equal to size, ring has wrapped and wptr is 0
> +  * (see OUT_RING), meaning we have enough space.
> +  * (2) We have enough space in the ring, wptr < rptr indicates
> +  * enough contiguous space
> +  * (3) wptr + ndwords < size - 1 implies enough space in the ring.
> +  */
> + if((wptr == size) || (wptr < rptr) || (wptr + ndwords < size - 1))

ERROR: space required before the open parenthesis '('
#59: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:310:
+   if((wptr == size) || (wptr < rptr) || (wptr + ndwords < size - 1))

> + return;
> +
> + /* Fill the end of ring with no-ops
> +  * */
> + OUT_RING(gpu->rb, CP_TYPE3_PKT | (((size - wptr - 1) - 1) << 16) |
> + ((CP_NOP & 0xFF) << 8));
> + gpu->rb->cur = gpu->rb->start;
> +
> + /* We have reset cur pointer to start. If ring_freewords returns
> +  * greater than ndwords, then we have contigous space.
> +  * */
> + if(spin_until(ring_freewords(gpu)>= ndwords)){

ERROR: spaces required around that '>=' (ctx:VxW)
#71: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:322:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){
 ^

ERROR: space required before the open brace '{'
#71: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:322:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){

ERROR: space required before the open parenthesis '('
#71: FILE: drivers/gpu/drm/msm/adreno/adreno_gpu.c:322:
+   if(spin_until(ring_freewords(gpu)>= ndwords)){


> + DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
> + gpu->name);
> + return;
> + }
>  }
> 
>  static const char *iommu_ports[] = {
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 3fa06b3..47ba8f5 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -247,7 +247,7 @@ void adreno_idle(struct msm_gpu *gpu);
>  void adreno_show(struct msm_gpu *gpu, struct seq_file *m);
>  #endif
>  void adreno_dump(struct msm_gpu *gpu);
> -void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords);
> +void adreno_wait_ring_contiguous(struct msm_gpu *gpu, uint32_t ndwords);
> 
>  int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
>   struct adreno_gpu 

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

--- Comment #22 from MirceaKitsune  ---
(In reply to Michel Dänzer from comment #21)

I did several tests multiple times to be sure, and it seems like it. No matter
how much I stress the viewer (a lot of avatars / geometry on the screen)
nothing bad happens with commit 56d9a397aa2dbee6b12e1bbe56be39f426e1e34d. But
the moment I switch to commit edbbfac6cfc634e697d7f981155a5072c52d77ac, it only
takes a bit of content for the GPU to instantly hiccup and only recover if I
move the view down really quick.

Note however that with both of these commits, the scene becomes black when I
enable Advanced Lighting, and I can only see floating text. But that seems to
be a completely unrelated issue, likely added temporarily during this time then
fixed relatively soon... probably something to do with lighting.

-- 
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/20141118/67a53916/attachment.html>

[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

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

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

--- Comment #5 from Michel Dänzer  ---
Is it still bad with a kernel from Alex Deucher's drm-next-3.19 tree and Mesa
Git master? If so, can you attach a HUD screenshot corresponding to that?

-- 
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/20141118/18616870/attachment.html>

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||greg at chown.ath.cx

--- Comment #21 from Michel Dänzer  ---
(In reply to MirceaKitsune from comment #20)
> edbbfac6cfc634e697d7f981155a5072c52d77ac is the first bad commit
> commit edbbfac6cfc634e697d7f981155a5072c52d77ac
> Author: Grigori Goronzy 
> Date:   Wed Sep 11 01:41:40 2013 +0200
> 
> r600g: fast color clears for single-sample buffers


Thank you for bisecting. So you can reliably reproduce the problem with that
commit, but not with its parent commit
56d9a397aa2dbee6b12e1bbe56be39f426e1e34d?

Grigori, any ideas?

-- 
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/20141118/a6ea5d35/attachment.html>

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

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

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

--- Comment #5 from Emil Velikov  ---
>From bug 86418:
I tried launching the Second Life viewer (Kokua 3.7.8 x64) using the latest GIT
version of MESA, and noticed the viewer crashes as soon as it's time to render
the world. The crash only happens when Basic Shaders are enabled.

-- 
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/20141118/fe065211/attachment.html>