[PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

[Doug Anderson]

Hi,

On Wed, Jun 22, 2016 at 6:47 PM, Yakir Yang  wrote:
> The document about rockchip platform make a mistaken in available
> compatible name of "rk3288-edp", we should correct it to "rk3288-dp"
> which correspond to the compatible name in driver.
>
> This mistaken was introduced in commit be91c36247089 ("dt-bindings:
> add document for rockchip variant of analogix_dp").
>
> Reported-by: Tomasz Figa 
> Signed-off-by: Yakir Yang 
> ---
> Hi all,
>
> This is an external patch for analogix_dp misc cleanup thread [0]
> [0]: https://patchwork.kernel.org/patch/9175613/
>
> BR,
> - Yakir
>
> Changes in v4: None
> Changes in v3:
> - Add this patch in v3
>
>  .../devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt   | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson 

[PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

[Doug Anderson]

Yakir,

On Wed, Jun 22, 2016 at 6:58 PM, Yakir Yang  wrote:
> For RK3399's GRF module, if we want to operate the graphic related grf
> registers, we need to enable the pclk_vio_grf which supply power for VIO
> GRF IOs, so it's better to introduce an optional grf clock in driver.
>
> Signed-off-by: Yakir Yang 
> ---
> Hi all,
>
> This is an external patch for analogix_dp misc cleanup thread [0]
> [0]: https://patchwork.kernel.org/patch/9175613/
>
> BR,
> - Yakir
>
> Changes in v4.1:
> - Fix compiled error, sorry.
>   "dp->cgfclk"  -->  'dp->grfclk'
>
> Changes in v4:
> - Check the the error code properly, 'EPROBE_DEFER' should be returned,
>   'ENOENT' should assign a NULL point to grfclk, other errors should be
>   regarded as failed. (Tomasz, Doug, reviewed at Google Gerrit)
> 
> [https://chromium-review.googlesource.com/#/c/351821/20/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>  at 249]
> - Add the document about optional 'grf' clock (Tomasz, Doug, reviewed at 
> Google Gerrit)
> [https://chromium-review.googlesource.com/#/c/351821/]
>
> Changes in v3:
> - Add this patch in v3
>
>  .../display/rockchip/analogix_dp-rockchip.txt  |  6 ++
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 23 
> +++---
>  2 files changed, 26 insertions(+), 3 deletions(-)

I probably would have split into two patches so the bindings was its
own patch, but I don't think it's strictly required.

In any case, this seems good to me.

Reviewed-by: Douglas Anderson 

[RFC PATCH v2 6/6] drm/rockchip: Add dmc notifier in vop driver

[hl]

t;  drm_crtc_vblank_off(crtc);
>>   
>>  /*
>> @@ -1243,7 +1279,7 @@ static int vop_create_crtc(struct vop *vop)
>>  ret = -ENOENT;
>>  goto err_cleanup_crtc;
>>  }
>> -
>> +vop->dmc_nb.notifier_call = dmc_notify;
>>  init_completion(>dsp_hold_completion);
>>  init_completion(>wait_update_complete);
>>  crtc->port = port;
>> @@ -1465,6 +1501,9 @@ static int vop_bind(struct device *dev, struct device 
>> *master, void *data)
>>  /* IRQ is initially disabled; it gets enabled in power_on */
>>  disable_irq(vop->irq);
>>   
>> +init_waitqueue_head(>wait_dmc_queue);
>> +vop->dmc_in_process = 0;
>> +
>>  ret = vop_create_crtc(vop);
>>  if (ret)
>>  return ret;
>>
>
>
>

-- 
Lin Huang

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160622/ad47f132/attachment.html>

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

--- Comment #5 from Alex Deucher  ---
You are using the amdgpu driver.  I suspect the problem is that you have radeon
blacklisted due to having installed fglrx previously.

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

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

Emil Velikov  changed:

   What|Removed |Added

 Attachment #124669|application/octet-stream|text/plain
  mime type||

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

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

Emil Velikov  changed:

   What|Removed |Added

 Attachment #124668|application/octet-stream|text/plain
  mime type||

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

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

--- Comment #3 from Neok  ---
> From: "bugzilla-daemon at freedesktop.org"  freedesktop.org>
>To: sounizan-neok at yahoo.com 
>Sent: Wednesday, June 22, 2016 7:56 PM
>Subject: [Bug 96634] Mesa or libGL very slow rendering with kabini vga card

>Comment # 1 on bug 96634 from Alex Deucher 

>The driver is not loaded in the logs attached.  Please attach a copy of your
>xorg log and dmesg output with the firmware installed.  Note that if you 
>are>using an initrd, you need to update that with the firmware as well.


I am sorry for my mistakes in setting up my system, producing wrong logs:
With the setup as reported in the new dmesg and Xorg log I indeed have the
case of very slow Cairo rendering.

Thank you for your quick response.


--
Best Regards
Neoklis - Ham Radio Call:5B4AZ
http://www.5b4az.org/

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

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

--- Comment #2 from Emil Velikov  ---
Note that closed source drivers overwrite multiple files - libGL.so and
libglx.so as a bare minimum.

In the log that you've attached - the AMD Proprietary libglx.so is used, which
won't work with the open source xf86-video-amdgpu or libGL (coming from mesa).

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

[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality

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

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

--- Comment #7 from Torbjörn Andersson  ---
Just in case the traces I made are useful in some way after all, I've gzipped
them and uploaded to
https://drive.google.com/open?id=0B364GtFAb7hUc21ONi15ODdmMTg

There are two files there, but they're just two different playthroughs of the
same scene.

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

DP link training and performance issues with HDMI USB-C dongle and Skylake

[Andy Lutomirski]

I have a Dell XPS 13 9350 (Skylake) and a Dell DA200 adapter.  The
latter is a Thunderbolt device that includes an HDMI port and connects
over USB Type C.  I believe that it's internally using DP Alternate
Mode.

When I plug it in on 4.7-rc4, I get spew like this:

[   90.718106] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   91.077604] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   91.437059] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   91.796479] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   92.156101] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   92.515647] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   92.875184] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   93.234735] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   93.594294] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   93.953812] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   94.313390] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   94.673043] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   95.032890] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   95.393016] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   95.752879] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   96.113074] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   96.473068] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   96.833185] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   97.193233] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   97.553138] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   97.913526] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   98.273525] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   98.634178] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   98.993859] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   99.354484] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[   99.714669] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  100.077412] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  100.432684] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  100.792499] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  101.152378] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  101.512265] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  101.872466] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  102.232284] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  102.592251] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  103.111283] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  103.466511] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  103.826082] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  104.191906] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  104.547038] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  104.911264] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  105.270679] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  105.625774] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  105.986064] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  106.350045] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  106.705325] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  107.064897] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  107.431263] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  107.790793] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  108.146016] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  108.506093] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  108.865924] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting
[  109.225629] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
to train DP, aborting

[PATCH v2] staging/android: prepare sw_sync files for de-staging

[Gustavo Padovan]

From: Gustavo Padovan 

remove file paths in the comments and add short description about each
file.

v2: remove file paths instead of just change them.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sw_sync.c| 2 +-
 drivers/staging/android/sync_debug.c | 2 +-
 drivers/staging/android/sync_debug.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/sw_sync.c 
b/drivers/staging/android/sw_sync.c
index 25196f5..a355e9b 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -1,5 +1,5 @@
 /*
- * drivers/dma-buf/sw_sync.c
+ * Sync File validation framework
  *
  * Copyright (C) 2012 Google, Inc.
  *
diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index b732ea3..03bcc6f 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -1,5 +1,5 @@
 /*
- * drivers/base/sync.c
+ * Sync File validation framework and debug information
  *
  * Copyright (C) 2012 Google, Inc.
  *
diff --git a/drivers/staging/android/sync_debug.h 
b/drivers/staging/android/sync_debug.h
index c14587c..63cfcff 100644
--- a/drivers/staging/android/sync_debug.h
+++ b/drivers/staging/android/sync_debug.h
@@ -1,5 +1,5 @@
 /*
- * include/linux/sync.h
+ * Sync File validation framework
  *
  * Copyright (C) 2012 Google, Inc.
  *
-- 
2.5.5

[drm-intel:topic/drm-misc 17/19] drivers/gpu/drm/vc4/vc4_drv.c:179:24: warning: unused variable 'connector'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad
commit: 398e97994f6d2d7165a4aa53c1a0903a2a7d3111 [17/19] drm/vc4: Remove 
open-coded drm_connector_register_all()
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 398e97994f6d2d7165a4aa53c1a0903a2a7d3111
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_drv.c: In function 'vc4_drm_bind':
>> drivers/gpu/drm/vc4/vc4_drv.c:179:24: warning: unused variable 'connector' 
>> [-Wunused-variable]
 struct drm_connector *connector;
   ^

vim +/connector +179 drivers/gpu/drm/vc4/vc4_drv.c

b3a15f6d Eric Anholt 2016-04-19  163return;
b3a15f6d Eric Anholt 2016-04-19  164  
b3a15f6d Eric Anholt 2016-04-19  165/* Since VC4 is a UMA device, the 
simplefb node may have been
b3a15f6d Eric Anholt 2016-04-19  166 * located anywhere in memory.
b3a15f6d Eric Anholt 2016-04-19  167 */
b3a15f6d Eric Anholt 2016-04-19  168ap->ranges[0].base = 0;
b3a15f6d Eric Anholt 2016-04-19  169ap->ranges[0].size = ~0;
b3a15f6d Eric Anholt 2016-04-19  170  
b3a15f6d Eric Anholt 2016-04-19  171remove_conflicting_framebuffers(ap, 
"vc4drmfb", false);
b3a15f6d Eric Anholt 2016-04-19  172kfree(ap);
b3a15f6d Eric Anholt 2016-04-19  173  }
b3a15f6d Eric Anholt 2016-04-19  174  
c8b75bca Eric Anholt 2015-03-02  175  static int vc4_drm_bind(struct device 
*dev)
c8b75bca Eric Anholt 2015-03-02  176  {
c8b75bca Eric Anholt 2015-03-02  177struct platform_device *pdev = 
to_platform_device(dev);
c8b75bca Eric Anholt 2015-03-02  178struct drm_device *drm;
c8b75bca Eric Anholt 2015-03-02 @179struct drm_connector *connector;
c8b75bca Eric Anholt 2015-03-02  180struct vc4_dev *vc4;
c8b75bca Eric Anholt 2015-03-02  181int ret = 0;
c8b75bca Eric Anholt 2015-03-02  182  
c8b75bca Eric Anholt 2015-03-02  183dev->coherent_dma_mask = 
DMA_BIT_MASK(32);
c8b75bca Eric Anholt 2015-03-02  184  
c8b75bca Eric Anholt 2015-03-02  185vc4 = devm_kzalloc(dev, sizeof(*vc4), 
GFP_KERNEL);
c8b75bca Eric Anholt 2015-03-02  186if (!vc4)
c8b75bca Eric Anholt 2015-03-02  187return -ENOMEM;

:: The code at line 179 was first introduced by commit
:: c8b75bca92cbf064b9fa125fc74a85994452e935 drm/vc4: Add KMS support for 
Raspberry Pi.

:: TO: Eric Anholt 
:: CC: Eric Anholt 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 55035 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160622/c1bdb6c2/attachment-0001.obj>

[Bug 96622] [radeonsi,apitrace] "Dreamfall Chapters: The longest Journey" shows visual corruption

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

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

Kai  changed:

   What|Removed |Added

Summary|[radeonsi] "Dreamfall   |[radeonsi,apitrace]
   |Chapters: The longest   |"Dreamfall Chapters: The
   |Journey" shows visual   |longest Journey" shows
   |corruption  |visual corruption

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

[Bug 96622] [radeonsi] "Dreamfall Chapters: The longest Journey" shows visual corruption

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

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

--- Comment #2 from Kai  ---
(In reply to Nicolai Hähnle from comment #1)
> Thanks for opening the separate report.

No need to thank me for that. It's easier for everybody this way. ;-) (Btw, I
marked bug 96602 as resolved yesterday, even though
<http://reviews.llvm.org/D21551> is not commited yet. That might have been a
bit rash. In case you need it open for tracking/remembering to ping D21551 if
needed, let me know and I reopen it.)

> Can you create an apitrace that shows the visual corruption?

Sure. You can find the trace in compressed form at
<http://dev.carbon-project.org/debian/mesa.bugs/96622/dfc.trace.xz>. Please
note, that you will need a password and user name to access the trace, since
it's ~ 1.2 GB in size even in compressed form (~ 2.6 GB uncompressed) and I
want to prevent needless downloads. According to my records you should already
have working login credentials from a prior report/trace. If you need me to
reset the password, just let me know (other known Mesa developers wanting to
have a look at the file, can contact me for credentials by private e-mail).

The trace shows my graphics settings for the game at the beginning to allow you
to recreate the setup, should you gain/have access to the game.

The first sequence after the loading screen doesn't show a glitch in the trace,
even though I saw some white pixels on the balcony while recording.

The corruption from attachment 124647 can be seen after the second loading
screen.

The trace was recorded with the same stack and game version as described in
comment #0.

Let me know, if you need anything else.

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

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, just a couple of display fixes, both stable stuff. Maybe we'll
be able to enable fbc by default one day.

BR,
Jani.

The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

  Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-06-22

for you to fetch changes up to 1e3fa0acfec677e915d7de5ac6e1f18cfa4f805b:

  drm/i915/fbc: Disable on HSW by default for now (2016-06-21 19:45:21 +0300)


Lyude (1):
  drm/i915/fbc: Disable on HSW by default for now

Mika Kahola (1):
  drm/i915: Revert DisplayPort fast link training feature

 drivers/gpu/drm/i915/intel_dp.c   |  3 ---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 26 ++
 drivers/gpu/drm/i915/intel_drv.h  |  2 --
 drivers/gpu/drm/i915/intel_fbc.c  |  3 +--
 4 files changed, 3 insertions(+), 31 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 96634] Mesa or libGL very slow rendering with kabini vga card

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

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

Alex Deucher  changed:

   What|Removed |Added

  Component|Mesa core   |DRM/Radeon
 QA Contact|mesa-dev at lists.freedesktop. |
   |org |
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
Product|Mesa|DRI
Version|11.2|unspecified

--- Comment #1 from Alex Deucher  ---
The driver is not loaded in the logs attached.  Please attach a copy of your
xorg log and dmesg output with the firmware installed.  Note that if you are
using an initrd, you need to update that with the firmware as well.

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

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding
 wrote:
> On Wed, Jun 22, 2016 at 04:08:52PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 22, 2016 at 3:32 PM, Thierry Reding
>>  wrote:
>> >> >> + *   wsp: (#0x20 | #0x9 | #0xA)+
>> >> >> + *
>> >> >> + * eg.:
>> >> >> + *  "crtc 0 plane1"  ->  Start CRC computations on plane1 of first 
>> >> >> CRTC
>> >> >> + *  "crtc 0 none"->  Stop CRC
>> >> >
>> >> > I've said this above, but again, it seems odd to me that you'd have to
>> >> > configure the CRC per-CRTC in one per-device file and read out the CRC
>> >> > from per-CRTC files.
>> >>
>> >> Not sure, I like that the per-crtc files just provide CRC data, and
>> >> that there's a separate control file that can be queried for the
>> >> current state.
>> >
>> > In my opinion that makes things needlessly complicated for userspace. If
>> > you want to query the state of a specific CRTC, you have to read out the
>> > entire file and parse each line to find the correct CRTC. On the other
>> > hand, chances are that you already need to know the path to the CRTC
>> > because you want to read the CRC out of the per-CRTC CRC file. In that
>> > case it would be much easier to simply concatenate the CRTC path and the
>> > CRC (or control) filename and read a single line (actually a single
>> > word) out of it to get at the same information.
>> >
>> > Furthermore if you have everything per-CRTC you no longer have to worry
>> > about pipe vs. index (that's always confusing because in the DRM core
>> > they're actually synonymous) because the CRTC path is canonical and will
>> > have the correct context.
>> >
>> > Per-CRTC directory with a single duplex file, or separate control and
>> > CRC files, is much simpler than the mix proposed here. No tokenization
>> > required when parsing in userspace, and no tokenization required to
>> > parse in the kernel either.
>>
>> Just jumping on this one here. I agree that if we remodel the
>> interface making the control file per-crtc would make sense. I think
>> separate control and read files makes sense, that's much less magic.
>
> Agreed, separate files would be a little simpler. I must admit that my
> proposal is partially motivated by a desire to avoid cumbersome naming
> of files. If we have separate files, what do you name them? crc for
> reading, crc_control for writing? crc_values for reading and crc for
> writing?
>
> Perhaps another way to avoid that would be to put the two files into a
> separate directory, as in:
>
> /sys/kernel/debug/dri//crtc-/crc/
> +-- control
> +-- data
>
> That's slightly on the deeply nested side, but on the other hand it
> nicely uses the filesystem for namespacing, which is what filesystems
> are really good at.

crtc-/crc/(control|data) sounds great.

>> And by reading the control file you can check what's the currently
>> selected source easily.
>
> Is that really a useful feature? If you're going to capture CRCs, you
> likely just want to set whatever you expect to receive irrespective of
> the current setting.

I think it's useful for hacking together your driver support, going
through tests it one more indirection. And I have a really bad
attention span ;-)

>> I'm not sure on the canonical CRTC path - right now we don't have that
>> in debugfs. I think just using index numbers is ok, we use those all
>> over the place already. Or maybe we could indeed add a new per-crtc
>> subdir in debugfs for this. Either way is fine with me.
>
> I can imagine that we'd like to expose a number of other per-CRTC
> properties (name, parts of the state, object ID, one day perhaps VBLANK
> counts, ...) this way, so a per-CRTC directory makes a lot of sense in
> my opinion.

Yeah, we might have room for more ... otoh for read-only debug
information I prefer big files that dump everything. Easier to extend.
But for tests/automation the one-value-per-file idea from sysfs, or at
least going much closer to that idea is a good idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Thierry Reding]

On Wed, Jun 22, 2016 at 04:08:52PM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 3:32 PM, Thierry Reding
>  wrote:
> >> >> + *   wsp: (#0x20 | #0x9 | #0xA)+
> >> >> + *
> >> >> + * eg.:
> >> >> + *  "crtc 0 plane1"  ->  Start CRC computations on plane1 of first CRTC
> >> >> + *  "crtc 0 none"->  Stop CRC
> >> >
> >> > I've said this above, but again, it seems odd to me that you'd have to
> >> > configure the CRC per-CRTC in one per-device file and read out the CRC
> >> > from per-CRTC files.
> >>
> >> Not sure, I like that the per-crtc files just provide CRC data, and
> >> that there's a separate control file that can be queried for the
> >> current state.
> >
> > In my opinion that makes things needlessly complicated for userspace. If
> > you want to query the state of a specific CRTC, you have to read out the
> > entire file and parse each line to find the correct CRTC. On the other
> > hand, chances are that you already need to know the path to the CRTC
> > because you want to read the CRC out of the per-CRTC CRC file. In that
> > case it would be much easier to simply concatenate the CRTC path and the
> > CRC (or control) filename and read a single line (actually a single
> > word) out of it to get at the same information.
> >
> > Furthermore if you have everything per-CRTC you no longer have to worry
> > about pipe vs. index (that's always confusing because in the DRM core
> > they're actually synonymous) because the CRTC path is canonical and will
> > have the correct context.
> >
> > Per-CRTC directory with a single duplex file, or separate control and
> > CRC files, is much simpler than the mix proposed here. No tokenization
> > required when parsing in userspace, and no tokenization required to
> > parse in the kernel either.
> 
> Just jumping on this one here. I agree that if we remodel the
> interface making the control file per-crtc would make sense. I think
> separate control and read files makes sense, that's much less magic.

Agreed, separate files would be a little simpler. I must admit that my
proposal is partially motivated by a desire to avoid cumbersome naming
of files. If we have separate files, what do you name them? crc for
reading, crc_control for writing? crc_values for reading and crc for
writing?

Perhaps another way to avoid that would be to put the two files into a
separate directory, as in:

/sys/kernel/debug/dri//crtc-/crc/
+-- control
+-- data

That's slightly on the deeply nested side, but on the other hand it
nicely uses the filesystem for namespacing, which is what filesystems
are really good at.

> And by reading the control file you can check what's the currently
> selected source easily.

Is that really a useful feature? If you're going to capture CRCs, you
likely just want to set whatever you expect to receive irrespective of
the current setting.

> I'm not sure on the canonical CRTC path - right now we don't have that
> in debugfs. I think just using index numbers is ok, we use those all
> over the place already. Or maybe we could indeed add a new per-crtc
> subdir in debugfs for this. Either way is fine with me.

I can imagine that we'd like to expose a number of other per-CRTC
properties (name, parts of the state, object ID, one day perhaps VBLANK
counts, ...) this way, so a per-CRTC directory makes a lot of sense in
my opinion.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160622/13f5f251/attachment.sig>

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Tue, Jun 21, 2016 at 01:06:41PM +0200, Tomeu Vizoso wrote:
> Adds a per-device debugfile "drm_crc_control" that allows selecting a
> source for frame checksums in each CRTC that supports them.
> 
> The checksums for each subsequent frame can be read from the per-CRTC
> file "drm_crtc_N_crc".
> 
> The code is taken from the i915 driver and other drivers can now provide
> frame CRCs by implementing the set_crc_source callback in
> drm_crtc_funcs.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
>  drivers/gpu/drm/drm_crtc.c |  28 ++-
>  drivers/gpu/drm/drm_debugfs.c  | 506 
> -
>  drivers/gpu/drm/drm_internal.h |  10 +
>  include/drm/drmP.h |   5 +
>  include/drm/drm_crtc.h |  72 ++
>  5 files changed, 611 insertions(+), 10 deletions(-)

I think we should finalize the internal and external api first, but this
needs a bit better documentation. For that I think it'd be good to extract
this to a new file like drm_debugfs_crc.[hc] and pull that into a new
section (maybe under the testing and validation section, next to the igt
howto) in drm-uapi.rst.

More doc bikeshedding below.

> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e7c862bd2f19..4dae42b122d9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -657,8 +657,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>  drm_num_crtcs(dev));
>   }
>   if (!crtc->name) {
> - drm_mode_object_unregister(dev, >base);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto err_unregister;
>   }
>  
>   crtc->base.properties = >properties;
> @@ -673,12 +673,30 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   if (cursor)
>   cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
>  
> +#ifdef CONFIG_DEBUG_FS
> + spin_lock_init(>crc.lock);
> + init_waitqueue_head(>crc.wq);
> + crtc->crc.debugfs_entries = kmalloc_array(DRM_MINOR_CNT,
> +   sizeof(*crtc->crc.debugfs_entries),
> +   GFP_KERNEL);
> +
> + ret = drm_debugfs_crtc_add(crtc);
> + if (ret)
> + goto err_free_name;
> +#endif
> +
>   if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>   drm_object_attach_property(>base, config->prop_active, 0);
>   drm_object_attach_property(>base, config->prop_mode_id, 
> 0);
>   }
>  
>   return 0;
> +
> +err_free_name:
> + kfree(crtc->name);
> +err_unregister:
> + drm_mode_object_unregister(dev, >base);
> + return ret;
>  }
>  EXPORT_SYMBOL(drm_crtc_init_with_planes);
>  
> @@ -699,6 +717,12 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
>* the indices on the drm_crtc after us in the crtc_list.
>*/
>  
> +#ifdef CONFIG_DEBUG_FS
> + drm_debugfs_crtc_remove(crtc);
> + kfree(crtc->crc.debugfs_entries);
> + kfree(crtc->crc.source);
> +#endif
> +
>   kfree(crtc->gamma_store);
>   crtc->gamma_store = NULL;
>  
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index fa10cef2ba37..cdc8836bc22a 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -30,6 +30,8 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -127,6 +129,259 @@ fail:
>  }
>  EXPORT_SYMBOL(drm_debugfs_create_files);
>  
> +static int
> +drm_add_fake_info_node(struct drm_minor *minor,
> +struct dentry *ent,
> +const void *key)
> +{
> + struct drm_info_node *node;
> +
> + node = kmalloc(sizeof(*node), GFP_KERNEL);
> + if (node == NULL) {
> + debugfs_remove(ent);
> + return -ENOMEM;
> + }
> +
> + node->minor = minor;
> + node->dent = ent;
> + node->info_ent = (void *) key;
> +
> + mutex_lock(>debugfs_lock);
> + list_add(>list, >debugfs_list);
> + mutex_unlock(>debugfs_lock);
> +
> + return 0;
> +}
> +
> +static int crc_control_show(struct seq_file *m, void *data)
> +{
> + struct drm_device *dev = m->private;
> + struct drm_crtc *crtc;
> +
> + drm_for_each_crtc(crtc, dev)
> + seq_printf(m, "crtc %d %s\n", crtc->index,
> +crtc->crc.source ? crtc->crc.source : "none");
> +
> + return 0;
> +}
> +
> +static int crc_control_open(struct inode *inode, struct file *file)
> +{
> + struct drm_device *dev = inode->i_private;
> +
> + return single_open(file, crc_control_show, dev);
> +}
> +
> +static int crc_control_update_crtc(struct drm_crtc *crtc, const char *source)
> +{
> + struct drm_crtc_crc *crc = >crc;
> + struct drm_crtc_crc_entry *entries;
> + int ret;
> +
> + if (!strcmp(source, "none"))
> + source = NULL;
> +
> + 

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Wed, Jun 22, 2016 at 3:32 PM, Thierry Reding
 wrote:
>> >> +const struct file_operations drm_crtc_crc_fops = {
>> >> + .owner = THIS_MODULE,
>> >> + .open = crtc_crc_open,
>> >> + .read = crtc_crc_read,
>> >> + .release = crtc_crc_release,
>> >> +};
>> >
>> > Do we want to support poll?
>>
>> Don't see the point of it, TBH.
>
> I have difficulty coming up with a concrete use-case, but given that we
> have most of the infrastructure to support it already, it might be nice
> to have. Could of course be added later on if there's a need.

O_NONBLOCK is definitely needed to be able to write testcases, so that
you can schedule flips and collect CRCs for them in parallel (e.g. to
validate atomic flips by making sure there's never an intermediate CRC
with garbage). I haven't seen a need yet for poll, and like you say
it's easy to add if we ever need it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC PATCH v2 6/6] drm/rockchip: Add dmc notifier in vop driver

[Chanwoo Choi]

Hi,

On 2016년 06월 06일 19:13, Lin Huang wrote:
> when in ddr frequency scaling process, vop can not do
> enable or disable operate, since dcf will base on vop vblank
> time to do frequency scaling and need to get vop irq if there
> have vop enabled. So need register to dmc notifier, and we can
> get the dmc status.

If you want to know when ddr frequency is chanaged,
you can use the DEVFREQ_TRANSITION_NOTIFIER notifier[1] (merged to v4.7-rc1)
which includes the following notification:
- DEVFREQ_PRECHANGE
- DEVFREQ_POSTCHANGE

[1] "PM / devfreq: Add new DEVFREQ_TRANSITION_NOTIFIER notifier"
- 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0fe3a66410a3ba96679be903f1e287d7a0a264a9

Thanks,
Chanwoo Choi

> 
> Signed-off-by: Lin Huang 
> ---
> 
> Changes in v2:
> - None
> 
> Changes in v1:
> - use wait_event instead usleep
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 43 
> +++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 1c4d5b5..8286048 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -31,6 +31,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_gem.h"
>  #include "rockchip_drm_fb.h"
> @@ -116,6 +118,10 @@ struct vop {
>  
>   const struct vop_data *data;
>  
> + struct notifier_block dmc_nb;
> + int dmc_in_process;
> + wait_queue_head_t   wait_dmc_queue;
> +
>   uint32_t *regsbak;
>   void __iomem *regs;
>  
> @@ -426,6 +432,21 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
> *vop)
>   spin_unlock_irqrestore(>irq_lock, flags);
>  }
>  
> +static int dmc_notify(struct notifier_block *nb, unsigned long event,
> +   void *data)
> +{
> + struct vop *vop = container_of(nb, struct vop, dmc_nb);
> +
> + if (event == DMCFREQ_ADJUST) {
> + vop->dmc_in_process = 1;
> + } else if (event == DMCFREQ_FINISH) {
> + vop->dmc_in_process = 0;
> + wake_up(>wait_dmc_queue);
> + }
> +
> + return NOTIFY_OK;
> +}
> +
>  static void vop_enable(struct drm_crtc *crtc)
>  {
>   struct vop *vop = to_vop(crtc);
> @@ -434,6 +455,13 @@ static void vop_enable(struct drm_crtc *crtc)
>   if (vop->is_enabled)
>   return;
>  
> + /*
> +  * if in dmc scaling frequency process, wait until it finish
> +  * use 100ms as timeout time.
> +  */
> + wait_event_timeout(vop->wait_dmc_queue,
> +!vop->dmc_in_process, HZ / 10);
> +
>   ret = pm_runtime_get_sync(vop->dev);
>   if (ret < 0) {
>   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
> @@ -485,6 +513,7 @@ static void vop_enable(struct drm_crtc *crtc)
>   enable_irq(vop->irq);
>  
>   drm_crtc_vblank_on(crtc);
> + rockchip_dmc_get(>dmc_nb);
>  
>   return;
>  
> @@ -505,6 +534,13 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>   return;
>  
>   /*
> +  * if in dmc scaling frequency process, wait until it finish
> +  * use 100ms as timeout time.
> +  */
> + wait_event_timeout(vop->wait_dmc_queue,
> +!vop->dmc_in_process, HZ / 10);
> +
> + /*
>* We need to make sure that all windows are disabled before we
>* disable that crtc. Otherwise we might try to scan from a destroyed
>* buffer later.
> @@ -517,7 +553,7 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>   VOP_WIN_SET(vop, win, enable, 0);
>   spin_unlock(>reg_lock);
>   }
> -
> + rockchip_dmc_put(>dmc_nb);
>   drm_crtc_vblank_off(crtc);
>  
>   /*
> @@ -1243,7 +1279,7 @@ static int vop_create_crtc(struct vop *vop)
>   ret = -ENOENT;
>   goto err_cleanup_crtc;
>   }
> -
> + vop->dmc_nb.notifier_call = dmc_notify;
>   init_completion(>dsp_hold_completion);
>   init_completion(>wait_update_complete);
>   crtc->port = port;
> @@ -1465,6 +1501,9 @@ static int vop_bind(struct device *dev, struct device 
> *master, void *data)
>   /* IRQ is initially disabled; it gets enabled in power_on */
>   disable_irq(vop->irq);
>  
> + init_waitqueue_head(>wait_dmc_queue);
> + vop->dmc_in_process = 0;
> +
>   ret = vop_create_crtc(vop);
>   if (ret)
>   return ret;
> 

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Wed, Jun 22, 2016 at 3:32 PM, Thierry Reding
 wrote:
>> >> + *   wsp: (#0x20 | #0x9 | #0xA)+
>> >> + *
>> >> + * eg.:
>> >> + *  "crtc 0 plane1"  ->  Start CRC computations on plane1 of first CRTC
>> >> + *  "crtc 0 none"->  Stop CRC
>> >
>> > I've said this above, but again, it seems odd to me that you'd have to
>> > configure the CRC per-CRTC in one per-device file and read out the CRC
>> > from per-CRTC files.
>>
>> Not sure, I like that the per-crtc files just provide CRC data, and
>> that there's a separate control file that can be queried for the
>> current state.
>
> In my opinion that makes things needlessly complicated for userspace. If
> you want to query the state of a specific CRTC, you have to read out the
> entire file and parse each line to find the correct CRTC. On the other
> hand, chances are that you already need to know the path to the CRTC
> because you want to read the CRC out of the per-CRTC CRC file. In that
> case it would be much easier to simply concatenate the CRTC path and the
> CRC (or control) filename and read a single line (actually a single
> word) out of it to get at the same information.
>
> Furthermore if you have everything per-CRTC you no longer have to worry
> about pipe vs. index (that's always confusing because in the DRM core
> they're actually synonymous) because the CRTC path is canonical and will
> have the correct context.
>
> Per-CRTC directory with a single duplex file, or separate control and
> CRC files, is much simpler than the mix proposed here. No tokenization
> required when parsing in userspace, and no tokenization required to
> parse in the kernel either.

Just jumping on this one here. I agree that if we remodel the
interface making the control file per-crtc would make sense. I think
separate control and read files makes sense, that's much less magic.
And by reading the control file you can check what's the currently
selected source easily.

I'm not sure on the canonical CRTC path - right now we don't have that
in debugfs. I think just using index numbers is ok, we use those all
over the place already. Or maybe we could indeed add a new per-crtc
subdir in debugfs for this. Either way is fine with me.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Thierry Reding]

drm_crtc_add_crc_entry(crtc, frame, , 1);
> >
> > instead of:
> >
> > drm_crtc_add_crc_entry(crtc, frame, crc, 0, 0, 0, 0);
> >
> > It would probably save poor users of the interface, such as myself, a
> > lot of headaches because they can't remember how many uint32_t:s the
> > function needs.
> 
> Sounds good to me, I don't really know how common multiple sources of
> complex CRC data will be in the future.

When you mention multiple sources, are the additional values meant to be
CRCs for additional sources? Or is it that some hardware generates more
than 32 bits for the CRC and drivers are supposed to split them up into
several values.

> 
> >> diff --git a/drivers/gpu/drm/drm_internal.h 
> >> b/drivers/gpu/drm/drm_internal.h
> >> index 38401d406532..e5b124d937f5 100644
> >> --- a/drivers/gpu/drm/drm_internal.h
> >> +++ b/drivers/gpu/drm/drm_internal.h
> >> @@ -100,6 +100,8 @@ int drm_debugfs_init(struct drm_minor *minor, int 
> >> minor_id,
> >>  int drm_debugfs_cleanup(struct drm_minor *minor);
> >>  int drm_debugfs_connector_add(struct drm_connector *connector);
> >>  void drm_debugfs_connector_remove(struct drm_connector *connector);
> >> +int drm_debugfs_crtc_add(struct drm_crtc *crtc);
> >> +void drm_debugfs_crtc_remove(struct drm_crtc *crtc);
> >
> > Oh... this isn't something that drivers are supposed to call?
> 
> Right, it's analogous to drm_debugfs_connector_add.

I recall seeing calls to this function from within the i915 driver,
wouldn't that cause the build to fail if i915 was built as a loadable
module?

> >> +  *
> >> +  * When CRC generation is enabled, the driver should call
> >> +  * drm_crtc_add_crc_entry() at each frame, providing any information
> >> +  * that characterizes the frame contents in the crcN arguments, as
> >> +  * provided from the configured source. Drivers should accept a 
> >> "auto"
> >> +  * source name that will select a default source for this CRTC.
> >
> > Would it be useful to provide some more aliases? "enable" and "on" for
> > "auto", "disable" and "off" for "none"?
> 
> Not sure, TBH, i like to keep my interfaces simple. Do you think this
> could be helpful?

I don't know. It's probably okay to not have the aliases, and it should
be trivial to add them later on if we see that people get annoyed by the
fact that they have to write "auto" instead of "on" or "enable".

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

[pull] amdgpu drm-fixes-4.7

[Alex Deucher]

Hi Dave,

A bit bigger than I would normally like, but most of the large changes are
for polaris support and since polaris went upstream in 4.7, I'd like
to get the fixes in so it's in good shape when the hw becomes available.
The major changes only touch the polaris code so there is little chance
for regressions on other asics.  The rest are just the usual collection
of bug fixes.

The following changes since commit 0ab15bdeb2943bd6491a35ec4eeb53a9a4436525:

  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-06-16 10:24:13 +1000)

are available in the git repository at:

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

for you to fetch changes up to 270d013659ddab52a6fd0eacae452c422d08aa39:

  drm/amd/powerplay: enable clock stretch feature for polaris (2016-06-21 
10:22:42 -0400)


Alex Deucher (1):
  drm/amdgpu: fix num_rbs exposed to userspace (v2)

Dan Carpenter (2):
  drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()
  drm/amdgpu: precedence bug in amdgpu_device_init()

Nicolas Iooss (1):
  drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value

Rex Zhu (12):
  drm/amd/powerplay: fix logic error.
  drm/amd/powerplay: fix bug that function parameter was incorect.
  drm/amd/powerplay: need to notify system bios pcie device ready
  drm/amd/powerplay: enable PowerContainment feature for polaris10/11.
  drm/amd/powerplay: initialize variables which were missed.
  drm/amd/powerplay: disable UVD SMU handshake for MCLK.
  drm/amd/powrplay: enable stutter_mode for polaris.
  drm/amd/powerplay: add avfs related define for polaris
  drm/amdgpu/atombios: add avfs struct for Polaris10/11
  drm/amd/powerplay: enable avfs feature for polaris
  drm/amdgpu/gfx8: update golden setting for polaris10
  drm/amd/powerplay: enable clock stretch feature for polaris

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |  28 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   3 +-
 drivers/gpu/drm/amd/include/atombios.h |  72 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   |   2 +
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |   6 +-
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 228 -
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h  |   3 +
 .../drm/amd/powerplay/hwmgr/polaris10_thermal.c|   6 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  |  18 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   |  43 
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.h   |  32 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  |   1 +
 .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h|   1 +
 drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h|   1 +
 drivers/gpu/drm/amd/powerplay/inc/smu74.h  |  75 ++-
 drivers/gpu/drm/amd/powerplay/inc/smu74_discrete.h |  42 +++-
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  50 +++--
 20 files changed, 461 insertions(+), 157 deletions(-)

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

[Thierry Reding]

On Wed, Jun 22, 2016 at 08:54:02AM +0800, Guodong Xu wrote:
> On 21 June 2016 at 21:34, Thierry Reding  wrote:
> > On Mon, Jun 20, 2016 at 11:59:03AM +0800, Xinliang Liu wrote:
> >> From: Guodong Xu 
> >>
> >> Add select HISI_KIRIN_DW_DSI to Kconfig.
> >> The DRM driver depends on dsi sub-driver.
> >>
> >> Signed-off-by: Zoltan Kuscsik 
> >> ---
> >>  drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >
> > You've got the Signed-off-by area messed up. If Guodong wrote this patch
> 
> Hi, Xinliang,
> 
> To clarify this, you don't need my Signed-off. Zoltan is the author,
> and I am just the person who ever integrated that patch into my local
> tree.

If Zoltan is the author, then his name should be in the From: line
above. As it is, git am will apply this with you as author. Also, see
section 11) in Documentation/SubmittingPatches on why you need to add
your S-o-b as well.

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

[PATCH v2 00/15] Runtime pm ref leak bonanza

[Lukas Wunner]

On Wed, Jun 15, 2016 at 05:11:54PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 01:37:35PM +0200, Lukas Wunner wrote:
> > On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote:
> > > On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter  wrote:
> > > > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
> > > >> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
> > > >> runtime pm ref leaks.
> > > >>
> > > >> Patches 1 to 8 are identical to v1.
> > > >>
> > > >> Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver
> > > >> unload. Based on feedback by Daniel Vetter, I've replaced this with
> > > >> a helper to turn off all CRTCs, which is called by nouveau, radeon
> > > >> and amdgpu on unload. In other words, this is now opt-in.
> > > >> So patch 9 of v1 is replaced with new patches 9 to 12.
> > > >>
> > > >> A by-product of patch 9 is a helper which turns off a *single* CRTC.
> > > >> This is open coded in three other places in the DRM tree and patches
> > > >> 13 to 15 refactor those to use the new helper.
> > > >
> > > > Yeah I think this makes much more sense. Please poke amd/nouveau folks 
> > > > for
> > > > reviews/acks, then I can merge.
> > > 
> > > The amdgpu, radeon, and drm patches are:
> > > Acked-by: Alex Deucher 
> > 
> > Great, thank you. That means all patches are either acked or reviewed:
> > 
> > * Patches 1, 2, 10 and 15 are
> >   Acked-by: Ben Skeggs 
> >   Message-ID: 
> >   Link: https://lists.freedesktop.org/archives/nouveau/2016-June/025350.html
> > 
> > * Patches 3 - 9 and 11 - 13 are
> >   Acked-by: Alex Deucher 
> >   Message-ID:  > mail.gmail.com>
> >   Link: 
> > https://lists.freedesktop.org/archives/dri-devel/2016-June/110876.html
> > 
> > * Patch 14 is
> >   Reviewed-by: Francisco Jerez 
> >   Message-ID: <87ziqrtml5.fsf at riseup.net>
> >   Link: 
> > https://lists.freedesktop.org/archives/dri-devel/2016-June/110588.html
> > 
> > 
> > Dave, Daniel, could one of you pick this up?
> > 
> > I've pushed another branch to GitHub which is amended with all the
> > Acked-by and Reviewed-by tags. It's also rebased on latest drm-next.
> > Otherwise this is identical to what I've posted. So in case you don't
> > want to apply all tags manually, you can cherry-pick from or merge
> > this branch (barring any objections of course):
> > https://github.com/l1k/linux/commits/drm_runpm_fixes_v2_acked
> > 
> > Thanks everyone!
> 
> Yeah will pick up later this week, right now I have a big drm-misc pull
> that's pending. Would like to get that landed first. Please ping me if
> your patches haven't landed in drm-misc by next week.

If you can be bothered to update your drm-misc pull: Ping!
(Otherwise I think Dave or Thierry/Sumit could pick it up instead.)

Thanks and have a pleasant vacation,

Lukas

[PATCH v2 00/15] Runtime pm ref leak bonanza

[Daniel Vetter]

On Wed, Jun 22, 2016 at 2:44 PM, Lukas Wunner  wrote:
>> Yeah will pick up later this week, right now I have a big drm-misc pull
>> that's pending. Would like to get that landed first. Please ping me if
>> your patches haven't landed in drm-misc by next week.
>
> If you can be bothered to update your drm-misc pull: Ping!
> (Otherwise I think Dave or Thierry/Sumit could pick it up instead.)

So much for my 5 second attention span :( I'll merge them right now,
but I think it's better to let them soak a bit more. Maybe Thierry can
send a pull request next week (if more patches show up). Note I'll
wait with pushing out until Dave merged the previous pull, to avoid a
mess in case another fixup is needed.

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

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Nicolas Boichat]

+Philipp

On Wed, Jun 22, 2016 at 11:54 AM, Archit Taneja  
wrote:
>
>
> On 6/22/2016 8:14 AM, Nicolas Boichat wrote:
>>
>> Hi Archit,
>>
>> Thanks for your reply.
>>
>> On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:


 ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
 that has an internal microcontroller.

 The only reason a Linux kernel driver is necessary is to reject
 resolutions that require more bandwidth than what is available on
 the DP side. DP bandwidth and lane count are reported by the bridge
 via 2 registers on I2C.
>>>
>>>
>>>
>>> How does the chip know when to enable/disable itself? Does it shutoff
>>> itself if there isn't anything on the HDMI link?
>>
>>
>> Not 100% sure of the internals (there is a closed source firmware in
>> the chip), but I believe the HDMI/DP part of the chip is switched on
>> whenever there is a DP over USB-C connector plugged in.
>>

 Signed-off-by: Nicolas Boichat 
 ---

 Hi,

 I tested this driver using the Mediatek HDMI controller (MT8173)
 upstream
 of the ANX bridge chip (Phillip sent a PULL request on June 13:
 git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
 ).

 I have 2 concerns, that I'm not sure how to address within the kernel
 DRM
 framework:
1. All other bridge drivers also have a connector attached to it.
 However, in
   this case, we cannot read the monitor EDID directly, so I'm not
 sure
 what
   I could put in a "get_modes" function. Instead, ANX7688 provides a
 I2C
   passthru/repeater, so the EDID is read on the Mediatek HDMI
 controller side.

   That leads to a somewhat strange layout, where we have:
   - MTK HDMI bridge/encoder
 - MTK connector (HDMI)
 - ANX7688 bridge
   - No connector
>>>
>>>
>>>
>>>
>>> You should ideally have one DP connector at the end of the chain:
>>>
>>>  - MTK HDMI bridge/encoder
>>>  - ANX7688 bridge
>>> - Connector (DP)
>>>
>>> In the dt-bindings for this board, hdmi's output port shouldn't be
>>> connected to a hdmi connector, but the input port of the ANX7688
>>> DP bridge. The output port of the bridge should be the one that
>>> connects to the DP connector.
>>
>>
>> Yes that's what I do (in the device tree).
>>
>> Actually, experimenting a bit more with the code, I realized that the
>> connector is always attached to the encoder, not the bridge, so the 2
>> layouts above are actually identical (from the userspace point of
>> view). Except that the connector name should be HDMI in one case, and
>> DP in the other. But I think that's mostly a cosmetic difference?
>
>
> Yeah, probably. I don't know what exactly the userspace does with
> the connector type, but it would be nice to represent it as a DP
> connector in case it makes any decisions based on it.

AFAICT does not matter... And, in any case, USB-C to HDMI adapters are
far more common (so we'd do HDMI->(DP over USB-C)->HDMI), so there
is a high change that advertising as DP would be wrong (and
advertising as HDMI would be correct by chance...).

>>
>>> One way I can think of fixing this is to make make the MTK hdmi
>>> encoder driver a bit smarter by observing the DT connections. If
>>> it's output port is connected to just a hdmi-connector, then
>>> things should be as before. If the output is connected to the DP
>>> bridge, then it should create a DP connector. The connector ops
>>> for the DP connector can still be the same as that of the HDMI
>>> connector before, but the phandle to the DDC bus would be in the
>>> DP device node in this case.
>>
>>
>> I think it'd be a bit weird to have the DDC bus phandle on the DP
>> connector, as we're not reading the EDID on the DP side of the bridge,
>> but on the HDMI side (and the bridge can do all sort of things to the
>> EDID: At the very least, I think it caches it).
>
>
> On the board, do the DDC lines join directly from the SoC pins to the
> DP connector, or does it go via the ANX7688 chip?

The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)

> Even with the current bindings (referred from the link below), the
> hdmi connector has the DDC node. Shouldn't it be the same in the DP
> case too? The DP connector, like before, is still manged by the HDMI
> driver, the only difference being the name and that it's two hops away
> in the DT bindings.
>
> https://patchwork.kernel.org/patch/9137089/

True, the bindings say so, but the current code actually looks for
ddc-i2c-bus property in whatever is connected on the endpoint (be it a
bridge or a connector).

And again, a bit odd as DP connector does not have true I2C lines...

Phillip? Any opinion?

>>
>>> This way, you can get around having the correct layout.
>>>
>>> Ideally, a bridge 

[PATCH] drm/ttm: wait for eviction in ttm_bo_force_list_clean

[Christian König]

From: Christian König 

Now that we can pipeline evictions we need to wait for
them to finish when we cleanup a memory domain.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5d93169..e340d0d6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1287,6 +1287,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
 {
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
+   struct fence *fence;
int ret;

/*
@@ -1307,6 +1308,23 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
spin_lock(>lru_lock);
}
spin_unlock(>lru_lock);
+
+   spin_lock(>move_lock);
+   fence = fence_get(man->move);
+   spin_unlock(>move_lock);
+
+   if (fence) {
+   ret = fence_wait(fence, false);
+   fence_put(fence);
+   if (ret) {
+   if (allow_errors) {
+   return ret;
+   } else {
+   pr_err("Cleanup eviction failed\n");
+   }
+   }
+   }
+
return 0;
 }

-- 
2.5.0

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 10:43 AM, Russell King  wrote:
> On Wed, Jun 22, 2016 at 10:23:36AM +0200, Daniel Vetter wrote:
>> On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
>> > On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
>> > > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell > > > canb.auug.org.au> wrote:
>> > > > Hi all,
>> > > >
>> > > > Today's linux-next merge of the drm-misc tree got a conflict in:
>> > > >
>> > > >   drivers/gpu/drm/sti/sti_drv.c
>> > > >
>> > > > between commit:
>> > > >
>> > > >   062993b15e8e ("drm: convert DT component matching to 
>> > > > component_match_add_release()")
>> > >
>> > > Why did that one end up in the arm tree? Should it go in through
>> > > drm-misc instead?
>> >
>> > Mine is part of a three part patch series which is part of the component
>> > helper updates (which I'm the author and maintainer of).
>> >
>> > Then someone came up with an alternative way of some of part of it.
>> >
>> > You can't merge the above DRM part, because that means you also need to
>> > merge patch 1, which is core component stuff.
>>
>> Makes sense, but generally in that case I ask Dave for an explicit ack for
>> merging through another tree to avoid confusion. Lack of that is why I
>> asked.
>
> It got posted to the appropriate mailing lists with CCs, including David.
> Just three people responded.
>
> One of the responses was that people didn't like the duplication.  I
> posted v2 the same day, the DT people didn't like the file location, so
> I went back to v1.  That then sparked someone to start working _against_
> me, cleaning up the existing duplication, and acknowledging that it'll
> cause _me_ problems.
>
> So, as it was done maliciously and intentionally to give these porblems,
> I'm not budging on this.  Sorry.
>
> There are times when working on the kernel is not very nice.  This is one
> of them.

Please don't jump the gun right away, I just wanted to figure out
what's going on and make sure collaboration and coordination is
working smoothly. At least from what I could see that discussion
didn't happen on dri-devel (or I missed it), so totally didn't know
what's up.

Also, please don't just charge ahead, at least here in the drm
subsystem we try hard to work together and be friendly, and in my
experience there's no isssue at all in getting acks for cases like
this. And really, the conflict with drm-misc seems to be trivial.

But immediately building a castle and marking an aggressive defensive
stance ("I'm not budging on this.") isn't helping anyone. Indeed I
think it's actively harming collaboration and our community,
especially in this case here where I think there wasn't even a problem
to begin with (on the drm side at least, like I said didn't know about
dt). I don't think this is acceptable conduct, next time around please
calm down first before replying in anger. I, and the drm community
here, would really appreciate this.

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

[PATCH V2 4/5] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Archit Taneja]

On 6/9/2016 9:55 PM, Peter Senna Tschudin wrote:
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
>Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Are these two chips always expected to be used together? I don't think
it's right to pair up two encoder chips into one driver just for one
board.

Is one device @0x72 and other @0x73? Or is only one of them an i2c
slave?

What's preventing us to create these as two different bridge drivers?
The drm framework allows us to daisy chain encoder bridges. The only
problem I see is that we don't have a clear-cut way to tell the bridge
driver whether we want it to create a connector for us or not. Because,
it looks like both can potentially create connectors. This isn't a big
problem either if we have DT. We just need to check whether our output
port is connected to another bridge or a connector.

Thanks,
Archit

>
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> CC: David Airlie 
> CC: Thierry Reding 
> CC: Thierry Reding 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>   - New commit message
>   - Removed 3 empty entry points
>   - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
>   - Added a lock for mode setting
>   - Removed a few blank lines
>   - Changed the order at Makefile and Kconfig
>
>   MAINTAINERS|   8 +
>   drivers/gpu/drm/bridge/Kconfig |  11 +
>   drivers/gpu/drm/bridge/Makefile|   1 +
>   drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 392 
> +
>   4 files changed, 412 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2ce5e91..2dd3d7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5010,6 +5010,14 @@ W: https://linuxtv.org
>   S:  Maintained
>   F:  drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M:   Martin Donnelly 
> +M:   Peter Senna Tschudin 
> +M:   Martyn Welch 
> +S:   Maintained
> +F:   drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F:   Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
>   GENERIC GPIO I2C DRIVER
>   M:  Haavard Skinnemoen 
>   S:  Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..93dae5bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
> Designware HDMI block.  This is used in conjunction with
> the i.MX6 HDMI driver.
>
> +config DRM_GE_B850V3_LVDS_DP
> + tristate "GE B850v3 LVDS to DP++ display bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + ---help---
> +  This is a driver for the display bridge of
> +  GE B850v3 that convert dual channel LVDS
> +  to DP++. This is used with the i.MX6 imx-ldb
> +  driver.
> +
>   config DRM_NXP_PTN3460
>   tristate "NXP PTN3460 DP/LVDS bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..47ea6c1 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
>   obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..c73cd77
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,392 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is 

[PULL] topic/drm-misc

[Daniel Vetter]

On Wed, Jun 22, 2016 at 11:21:57AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Again a pile of things all over
> - Conversion to rst from docbook from Jani. Looks real pretty, and the
>   source is now actually readable (compared to horrible, horrible docbook
>   xml)! https://01.org/linuxgraphics/gfx-docs/drm/
> - device register/unregister rework from Chris, with follow-up work from
>   Benjamin. Allows more drivers to demidlayer load/unload and others to
>   remove a bit of boilerplate.
> - master/auth related cleanup, with docs
> - some dma-buf polish, merged by Sumit
> - small stuff all over (like build fixes from Arnd)
> 
> Group maintainership seems to slowly take off, with both Thierry and Sumit
> pushing a few things. No hiccups thus far.
> 
> I'll be on vacation starting this Fri for two weeks, so pls take a look
> right away in case I need to fix up something. Thierry agreed to merge the
> oddball patches and if needed also try to send a pull request. So all
> covered. Pending stuff:
> - delayed fbdev init from Thierry
> - pixel format rework from Laurent
> - zpos from Benjamin
> 
> There's a small conflict with the arm tree and Benjamin's sti init rework.
> 
> I'd also like to backmerge this to drm-intel before I head off, so that
> Chris can move the i915 demidlayering forward.

Updated pull request.
-Daniel

The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:

  Merge tag 'topic/drm-misc-2016-06-15' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:32 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-06-22-updated

for you to fetch changes up to f510f34c12f65105146ace5561969e5003f6c007:

  drm/vc4: Remove unused connector (2016-06-22 12:41:47 +0200)


Arnd Bergmann (2):
  drm: rockchip: select DRM_GEM_CMA_HELPER
  drm/mediatek: Remove IOMMU_DMA select

Benjamin Gaignard (3):
  drm: Add callbacks for late registering
  drm: sti: use late_register and early_unregister callbacks
  drm: sti: rework init sequence

Chris Wilson (22):
  drm: Export drm_dev_init() for subclassing
  drm: Add a callback from connector registering
  drm: Make drm_connector_register() safe against multiple calls
  drm: Automatically unregister the connector during cleanup
  drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking
  drm: Minimally initialise drm_dp_aux
  drm: Automatically register/unregister all connectors
  drm: Protect drm_connector_register_all() under DRIVER_MODESET
  drm/i915: Move intel_connector->unregister to connector->early_unregister
  drm/i915: Move backlight unregistration to connector unregistration
  drm/i915: Avoid use-after-free of intel_encoder in 
intel_dp_connector_destrpy
  drm: Prevent NULL deref in drm_name_info()
  drm/arc: Remove redundant calls to drm_connector_register_all()
  drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()
  drm/hisilicon: Remove redundant calls to drm_connector_register_all()
  drm/mediatek: Remove redundant calls to drm_connector_register_all()
  drm/msm: Remove redundant calls to drm_connector_register_all()
  drm/rcar-du: Remove redundant calls to drm_connector_register_all()
  drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all()
  drm/vc4: Remove open-coded drm_connector_register_all()
  drm/sun4i: Remove open-coded drm_connector_register_all()
  drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

Daniel Vetter (27):
  drm: Nuke legacy maps debugfs files
  drm: Hide hw.lock cleanup in filp->release better
  drm: Link directly from drm_master to drm_device
  drm: Move master functions into drm_auth.c
  drm: Extract drm_master_open
  drm: Extract drm_master_relase
  drm/sti: Don't call drm_helper_disable_unused_functions
  drm: Only do the hw.lock cleanup in master_relase for !MODESET
  drm: Move authmagic cleanup into drm_master_release
  drm: Protect authmagic with master_mutex
  drm: Mark authmagic ioctls as unlocked
  drm: Mark set/drop master ioctl as unlocked.
  drm/omapdrm: don't call drm_helper_disable_unused_functions
  drm/crtc-helper: disable_unused_functions really isn't for atomic
  drm/amdkfd: Clean up inline handling
  drm: Move master pointer from drm_minor to drm_device
  drm: Clean up drm_crtc.h
  drm: Use dev->name as fallback for dev->unique
  drm/vgem: Stop calling drm_drv_set_unique
  drm: Don't call drm_dev_set_unique from platform drivers
  drm: Nuke SET_UNIQUE ioctl
  drm: Lobotomize set_busid nonsense for !pci drivers
  drm: Refactor drop/set master code a bit
  drm: Extract drm_is_current_master
  drm: Clear up master tracking booleans
  drm: document drm_auth.c
  drm/vc4: Remove 

[PULL] drm-intel-next

[Daniel Vetter]

On Wed, Jun 22, 2016 at 11:24:57AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> drm-intel-next-2016-06-20:
> - Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang
> - another attemp at nonblocking atomic plane updates
> - bugfixes and refactoring for GuC doorbell code (Dave Gordon)
> - GuC command submission enabled by default, if fw available (Dave Gordon)
> - more bxt w/a (Arun Siluvery)
> - bxt phy improvements (Imre Deak)
> - prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson)
> - skl/bkl w/a update from Mika Kuoppala
> - bunch of small improvements and fixes all over, as usual
> 
> As mentioned in the drm-misc pull I'll be on vacation for 2 weeks. I'll
> probably send you another (final for 4.8) feature pull right when I'm
> back, so a bit later than usual. Jani's also going on vacation in July,
> with some overlap with mine. So might be you need to apply a serious
> bugfix directly, but it's all seems calm, I don't think we need that. I'll
> take care of -fixes when I'm back until Jani's return.

Forgot to mention: There's 2x minor fallout from the atomic work,
specifically using atomic_commit for legacy page flips. Cursor can stall
sometimes, and there's some flickering/frontbuffer rendering going on
sometimes. Maarten and Chris are looking into it, but worst case it's a
simple revert of a one-liner - the entire patch series is intionally still
keeping all the legacy page flip stuff around.
-Daniel

> 
> Cheers, Daniel
> 
> 
> The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:
> 
>   Merge tag 'topic/drm-misc-2016-06-15' of 
> git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:32 
> +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-06-20
> 
> for you to fetch changes up to a02b01096def82df28363b0b9e7afdea9b5587fd:
> 
>   drm/i915: Update DRIVER_DATE to 20160620 (2016-06-20 00:30:34 +0200)
> 
> 
> - Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang
> - another attemp at nonblocking atomic plane updates
> - bugfixes and refactoring for GuC doorbell code (Dave Gordon)
> - GuC command submission enabled by default, if fw available (Dave Gordon)
> - more bxt w/a (Arun Siluvery)
> - bxt phy improvements (Imre Deak)
> - prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson)
> - skl/bkl w/a update from Mika Kuoppala
> - bunch of small improvements and fixes all over, as usual
> 
> 
> Ankitprasad Sharma (2):
>   drm/i915: Use insert_page for pwrite_fast
>   drm/i915: Support for pread/pwrite from/to non shmem backed objects
> 
> Chris Wilson (3):
>   drm/i915: Add support for mapping an object page by page
>   drm/i915: Introduce i915_gem_object_get_dma_address()
>   drm/i915: Serialise presentation with imported dmabufs
> 
> Dan Carpenter (1):
>   drm/i915/mocs: || vs | typo in get_mocs_settings()
> 
> Daniel Vetter (8):
>   Revert "drm/i915/ilk: Don't disable SSC source if it's in use"
>   Merge remote-tracking branch 'airlied/drm-next' into 
> drm-intel-next-queued
>   drm/i915: Signal drm events for atomic
>   drm/i915: Roll out the helper nonblock tracking
>   drm/i915: nonblocking commit
>   drm/i915: Move fb_bits updating later in atomic_commit
>   drm/i915: Use atomic commits for legacy page_flips
>   drm/i915: Update DRIVER_DATE to 20160620
> 
> Dave Gordon (13):
>   drm/i915/guc: fix GuC loading/submission check
>   drm/i915/guc: disable GuC submission earlier during GuC (re)load
>   drm/i915/guc: enable GuC loading & submission by default
>   drm/i915/guc: suppress GuC-related message on non-GuC platforms
>   drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions
>   drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions
>   drm/i915/guc: add doorbell map to debugfs/i915_guc_info
>   drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
>   drm/i915/guc: remove writes to GEN8_DRBREG registers
>   drm/i915/guc: move guc_ring_doorbell() nearer to callsite
>   drm/i915/guc: refactor doorbell management code
>   drm/i915/guc: replace assign_doorbell() with select_doorbell_register()
>   drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
> 
> David Weinehall (1):
>   drm/i915: only disable memory self-refresh on GMCH
> 
> Gerd Hoffmann (1):
>   drm/i915: use #defines for qemu subsystem ids
> 
> Imre Deak (6):
>   drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
>   drm/i915: Factor out intel_power_well_get/put
>   drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code
>   drm/i915/bxt: Set DDI PHY lane latency optimization during modeset
>   drm/i915/bxt: Rename broxton to bxt in 

[PULL] topic/drm-misc

[Daniel Vetter]

On Wed, Jun 22, 2016 at 11:21:57AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Again a pile of things all over
> - Conversion to rst from docbook from Jani. Looks real pretty, and the
>   source is now actually readable (compared to horrible, horrible docbook
>   xml)! https://01.org/linuxgraphics/gfx-docs/drm/
> - device register/unregister rework from Chris, with follow-up work from
>   Benjamin. Allows more drivers to demidlayer load/unload and others to
>   remove a bit of boilerplate.
> - master/auth related cleanup, with docs
> - some dma-buf polish, merged by Sumit
> - small stuff all over (like build fixes from Arnd)
> 
> Group maintainership seems to slowly take off, with both Thierry and Sumit
> pushing a few things. No hiccups thus far.
> 
> I'll be on vacation starting this Fri for two weeks, so pls take a look
> right away in case I need to fix up something. Thierry agreed to merge the
> oddball patches and if needed also try to send a pull request. So all
> covered. Pending stuff:
> - delayed fbdev init from Thierry
> - pixel format rework from Laurent
> - zpos from Benjamin
> 
> There's a small conflict with the arm tree and Benjamin's sti init rework.
> 
> I'd also like to backmerge this to drm-intel before I head off, so that
> Chris can move the i915 demidlayering forward.

ofc right when I hit send 0day reports the gcc warning I failed to spot.
Will respin with a fixup patch on top.
-Daniel

> 
> Cheers, Daniel
> 
> 
> The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:
> 
>   Merge tag 'topic/drm-misc-2016-06-15' of 
> git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:32 
> +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-06-22
> 
> for you to fetch changes up to fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad:
> 
>   drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference (2016-06-22 
> 10:07:28 +0200)
> 
> 
> Arnd Bergmann (2):
>   drm: rockchip: select DRM_GEM_CMA_HELPER
>   drm/mediatek: Remove IOMMU_DMA select
> 
> Benjamin Gaignard (3):
>   drm: Add callbacks for late registering
>   drm: sti: use late_register and early_unregister callbacks
>   drm: sti: rework init sequence
> 
> Chris Wilson (22):
>   drm: Export drm_dev_init() for subclassing
>   drm: Add a callback from connector registering
>   drm: Make drm_connector_register() safe against multiple calls
>   drm: Automatically unregister the connector during cleanup
>   drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking
>   drm: Minimally initialise drm_dp_aux
>   drm: Automatically register/unregister all connectors
>   drm: Protect drm_connector_register_all() under DRIVER_MODESET
>   drm/i915: Move intel_connector->unregister to 
> connector->early_unregister
>   drm/i915: Move backlight unregistration to connector unregistration
>   drm/i915: Avoid use-after-free of intel_encoder in 
> intel_dp_connector_destrpy
>   drm: Prevent NULL deref in drm_name_info()
>   drm/arc: Remove redundant calls to drm_connector_register_all()
>   drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()
>   drm/hisilicon: Remove redundant calls to drm_connector_register_all()
>   drm/mediatek: Remove redundant calls to drm_connector_register_all()
>   drm/msm: Remove redundant calls to drm_connector_register_all()
>   drm/rcar-du: Remove redundant calls to drm_connector_register_all()
>   drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all()
>   drm/vc4: Remove open-coded drm_connector_register_all()
>   drm/sun4i: Remove open-coded drm_connector_register_all()
>   drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference
> 
> Daniel Vetter (26):
>   drm: Nuke legacy maps debugfs files
>   drm: Hide hw.lock cleanup in filp->release better
>   drm: Link directly from drm_master to drm_device
>   drm: Move master functions into drm_auth.c
>   drm: Extract drm_master_open
>   drm: Extract drm_master_relase
>   drm/sti: Don't call drm_helper_disable_unused_functions
>   drm: Only do the hw.lock cleanup in master_relase for !MODESET
>   drm: Move authmagic cleanup into drm_master_release
>   drm: Protect authmagic with master_mutex
>   drm: Mark authmagic ioctls as unlocked
>   drm: Mark set/drop master ioctl as unlocked.
>   drm/omapdrm: don't call drm_helper_disable_unused_functions
>   drm/crtc-helper: disable_unused_functions really isn't for atomic
>   drm/amdkfd: Clean up inline handling
>   drm: Move master pointer from drm_minor to drm_device
>   drm: Clean up drm_crtc.h
>   drm: Use dev->name as fallback for dev->unique
>   drm/vgem: Stop calling drm_drv_set_unique
>   drm: Don't call drm_dev_set_unique from platform 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
 QA Contact||dri-devel at lists.freedesktop
   ||.org
  Component|DRM/Radeon  |Drivers/Gallium/r600

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

[PATCH] drm/ttm: wait for eviction in ttm_bo_force_list_clean

[Alex Deucher]

On Wed, Jun 22, 2016 at 8:16 AM, Christian König
 wrote:
> From: Christian König 
>
> Now that we can pipeline evictions we need to wait for
> them to finish when we cleanup a memory domain.
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 5d93169..e340d0d6 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1287,6 +1287,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>  {
> struct ttm_mem_type_manager *man = >man[mem_type];
> struct ttm_bo_global *glob = bdev->glob;
> +   struct fence *fence;
> int ret;
>
> /*
> @@ -1307,6 +1308,23 @@ static int ttm_bo_force_list_clean(struct 
> ttm_bo_device *bdev,
> spin_lock(>lru_lock);
> }
> spin_unlock(>lru_lock);
> +
> +   spin_lock(>move_lock);
> +   fence = fence_get(man->move);
> +   spin_unlock(>move_lock);
> +
> +   if (fence) {
> +   ret = fence_wait(fence, false);
> +   fence_put(fence);
> +   if (ret) {
> +   if (allow_errors) {
> +   return ret;
> +   } else {
> +   pr_err("Cleanup eviction failed\n");
> +   }
> +   }
> +   }
> +
> return 0;
>  }
>
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Remove unused connector

[Daniel Vetter]

Somehow I didn't spot this when pushing :(

Fixes: 398e97994f6d ("drm/vc4: Remove open-coded drm_connector_register_all()")
Acked-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 0d866523e667..9e88231b8906 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -176,7 +176,6 @@ static int vc4_drm_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm;
-   struct drm_connector *connector;
struct vc4_dev *vc4;
int ret = 0;

-- 
2.8.1

[PATCH] drm: Prevent NULL deref in drm_name_info()

[Eric Engestrom]

On Mon, Jun 20, 2016 at 07:53:33PM +0100, Chris Wilson wrote:
> If a driver does not have a parent, or never sets the unique name for
> itself, then we may proceed to chase a NULL dereference through
> debugfs/.../name.
> 
> Testcase: igt/vgem_basic/debugfs
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

Reviewed-by: Eric Engestrom 

linux-next: manual merge of the drm-misc tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/sti/sti_drv.c

between commit:

  062993b15e8e ("drm: convert DT component matching to 
component_match_add_release()")

from the arm tree and commit:

  84601dbdea36 ("drm: sti: rework init sequence")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sti/sti_drv.c
index 8abb57a94651,96bd3d08b2d4..
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
return dev->of_node == data;
  }

 +static void release_of(struct device *dev, void *data)
 +{
 +  of_node_put(data);
 +}
 +
+ static int sti_init(struct drm_device *ddev)
+ {
+   struct sti_private *private;
+ 
+   private = kzalloc(sizeof(*private), GFP_KERNEL);
+   if (!private)
+   return -ENOMEM;
+ 
+   ddev->dev_private = (void *)private;
+   dev_set_drvdata(ddev->dev, ddev);
+   private->drm_dev = ddev;
+ 
+   mutex_init(>commit.lock);
+   INIT_WORK(>commit.work, sti_atomic_work);
+ 
+   drm_mode_config_init(ddev);
+ 
+   sti_mode_config_init(ddev);
+ 
+   drm_kms_helper_poll_init(ddev);
+ 
+   return 0;
+ }
+ 
+ static void sti_cleanup(struct drm_device *ddev)
+ {
+   struct sti_private *private = ddev->dev_private;
+ 
+   if (private->fbdev) {
+   drm_fbdev_cma_fini(private->fbdev);
+   private->fbdev = NULL;
+   }
+ 
+   drm_kms_helper_poll_fini(ddev);
+   drm_vblank_cleanup(ddev);
+   kfree(private);
+   ddev->dev_private = NULL;
+ }
+ 
  static int sti_bind(struct device *dev)
  {
-   return drm_platform_init(_driver, to_platform_device(dev));
+   struct drm_device *ddev;
+   int ret;
+ 
+   ddev = drm_dev_alloc(_driver, dev);
+   if (!ddev)
+   return -ENOMEM;
+ 
+   ddev->platformdev = to_platform_device(dev);
+ 
+   ret = sti_init(ddev);
+   if (ret)
+   goto err_drm_dev_unref;
+ 
+   ret = component_bind_all(ddev->dev, ddev);
+   if (ret)
+   goto err_cleanup;
+ 
+   ret = drm_dev_register(ddev, 0);
+   if (ret)
+   goto err_register;
+ 
+   drm_mode_config_reset(ddev);
+ 
+   return 0;
+ 
+ err_register:
+   drm_mode_config_cleanup(ddev);
+ err_cleanup:
+   sti_cleanup(ddev);
+ err_drm_dev_unref:
+   drm_dev_unref(ddev);
+   return ret;
  }

  static void sti_unbind(struct device *dev)

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_fbc.c

between commit:

  1e3fa0acfec6 ("drm/i915/fbc: Disable on HSW by default for now")

from the drm-intel-fixes tree and commit:

  80788a0fbbdf ("drm/i915/fbc: sanitize i915.enable_fbc during FBC init")

from the drm-intel tree.

I fixed it up (since the former patch appears on both trees, I just
used the latter) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2016-06-20:
- Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang
- another attemp at nonblocking atomic plane updates
- bugfixes and refactoring for GuC doorbell code (Dave Gordon)
- GuC command submission enabled by default, if fw available (Dave Gordon)
- more bxt w/a (Arun Siluvery)
- bxt phy improvements (Imre Deak)
- prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson)
- skl/bkl w/a update from Mika Kuoppala
- bunch of small improvements and fixes all over, as usual

As mentioned in the drm-misc pull I'll be on vacation for 2 weeks. I'll
probably send you another (final for 4.8) feature pull right when I'm
back, so a bit later than usual. Jani's also going on vacation in July,
with some overlap with mine. So might be you need to apply a serious
bugfix directly, but it's all seems calm, I don't think we need that. I'll
take care of -fixes when I'm back until Jani's return.

Cheers, Daniel


The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:

  Merge tag 'topic/drm-misc-2016-06-15' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:32 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-06-20

for you to fetch changes up to a02b01096def82df28363b0b9e7afdea9b5587fd:

  drm/i915: Update DRIVER_DATE to 20160620 (2016-06-20 00:30:34 +0200)


- Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang
- another attemp at nonblocking atomic plane updates
- bugfixes and refactoring for GuC doorbell code (Dave Gordon)
- GuC command submission enabled by default, if fw available (Dave Gordon)
- more bxt w/a (Arun Siluvery)
- bxt phy improvements (Imre Deak)
- prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson)
- skl/bkl w/a update from Mika Kuoppala
- bunch of small improvements and fixes all over, as usual


Ankitprasad Sharma (2):
  drm/i915: Use insert_page for pwrite_fast
  drm/i915: Support for pread/pwrite from/to non shmem backed objects

Chris Wilson (3):
  drm/i915: Add support for mapping an object page by page
  drm/i915: Introduce i915_gem_object_get_dma_address()
  drm/i915: Serialise presentation with imported dmabufs

Dan Carpenter (1):
  drm/i915/mocs: || vs | typo in get_mocs_settings()

Daniel Vetter (8):
  Revert "drm/i915/ilk: Don't disable SSC source if it's in use"
  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
  drm/i915: Signal drm events for atomic
  drm/i915: Roll out the helper nonblock tracking
  drm/i915: nonblocking commit
  drm/i915: Move fb_bits updating later in atomic_commit
  drm/i915: Use atomic commits for legacy page_flips
  drm/i915: Update DRIVER_DATE to 20160620

Dave Gordon (13):
  drm/i915/guc: fix GuC loading/submission check
  drm/i915/guc: disable GuC submission earlier during GuC (re)load
  drm/i915/guc: enable GuC loading & submission by default
  drm/i915/guc: suppress GuC-related message on non-GuC platforms
  drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions
  drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions
  drm/i915/guc: add doorbell map to debugfs/i915_guc_info
  drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
  drm/i915/guc: remove writes to GEN8_DRBREG registers
  drm/i915/guc: move guc_ring_doorbell() nearer to callsite
  drm/i915/guc: refactor doorbell management code
  drm/i915/guc: replace assign_doorbell() with select_doorbell_register()
  drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

David Weinehall (1):
  drm/i915: only disable memory self-refresh on GMCH

Gerd Hoffmann (1):
  drm/i915: use #defines for qemu subsystem ids

Imre Deak (6):
  drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
  drm/i915: Factor out intel_power_well_get/put
  drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code
  drm/i915/bxt: Set DDI PHY lane latency optimization during modeset
  drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixes
  drm/i915/bxt: Sanitiy check the PHY lane power down status

Jani Nikula (1):
  drm/i915/dsi: fix bxt split screen and color issue

Lukas Wunner (1):
  drm/i915: Don't unregister fbdev's fb twice

Lyude (1):
  drm/i915/ilk: Don't disable SSC source if it's in use

Maarten Lankhorst (1):
  Reapply "drm/i915: Pass atomic states to fbc update, functions."

Mika Kuoppala (27):
  drm/i915/skl: Add WaDisableGafsUnitClkGating
  drm/i915/kbl: Init gen9 workarounds
  drm/i915/kbl: Add REVID macro
  drm/i915/kbl: Add WaSkipStolenMemoryFirstPage for A0
  drm/i915/gen9: Always apply 

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Again a pile of things all over
- Conversion to rst from docbook from Jani. Looks real pretty, and the
  source is now actually readable (compared to horrible, horrible docbook
  xml)! https://01.org/linuxgraphics/gfx-docs/drm/
- device register/unregister rework from Chris, with follow-up work from
  Benjamin. Allows more drivers to demidlayer load/unload and others to
  remove a bit of boilerplate.
- master/auth related cleanup, with docs
- some dma-buf polish, merged by Sumit
- small stuff all over (like build fixes from Arnd)

Group maintainership seems to slowly take off, with both Thierry and Sumit
pushing a few things. No hiccups thus far.

I'll be on vacation starting this Fri for two weeks, so pls take a look
right away in case I need to fix up something. Thierry agreed to merge the
oddball patches and if needed also try to send a pull request. So all
covered. Pending stuff:
- delayed fbdev init from Thierry
- pixel format rework from Laurent
- zpos from Benjamin

There's a small conflict with the arm tree and Benjamin's sti init rework.

I'd also like to backmerge this to drm-intel before I head off, so that
Chris can move the i915 demidlayering forward.

Cheers, Daniel


The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:

  Merge tag 'topic/drm-misc-2016-06-15' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:32 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-06-22

for you to fetch changes up to fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad:

  drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference (2016-06-22 
10:07:28 +0200)


Arnd Bergmann (2):
  drm: rockchip: select DRM_GEM_CMA_HELPER
  drm/mediatek: Remove IOMMU_DMA select

Benjamin Gaignard (3):
  drm: Add callbacks for late registering
  drm: sti: use late_register and early_unregister callbacks
  drm: sti: rework init sequence

Chris Wilson (22):
  drm: Export drm_dev_init() for subclassing
  drm: Add a callback from connector registering
  drm: Make drm_connector_register() safe against multiple calls
  drm: Automatically unregister the connector during cleanup
  drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking
  drm: Minimally initialise drm_dp_aux
  drm: Automatically register/unregister all connectors
  drm: Protect drm_connector_register_all() under DRIVER_MODESET
  drm/i915: Move intel_connector->unregister to connector->early_unregister
  drm/i915: Move backlight unregistration to connector unregistration
  drm/i915: Avoid use-after-free of intel_encoder in 
intel_dp_connector_destrpy
  drm: Prevent NULL deref in drm_name_info()
  drm/arc: Remove redundant calls to drm_connector_register_all()
  drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()
  drm/hisilicon: Remove redundant calls to drm_connector_register_all()
  drm/mediatek: Remove redundant calls to drm_connector_register_all()
  drm/msm: Remove redundant calls to drm_connector_register_all()
  drm/rcar-du: Remove redundant calls to drm_connector_register_all()
  drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all()
  drm/vc4: Remove open-coded drm_connector_register_all()
  drm/sun4i: Remove open-coded drm_connector_register_all()
  drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

Daniel Vetter (26):
  drm: Nuke legacy maps debugfs files
  drm: Hide hw.lock cleanup in filp->release better
  drm: Link directly from drm_master to drm_device
  drm: Move master functions into drm_auth.c
  drm: Extract drm_master_open
  drm: Extract drm_master_relase
  drm/sti: Don't call drm_helper_disable_unused_functions
  drm: Only do the hw.lock cleanup in master_relase for !MODESET
  drm: Move authmagic cleanup into drm_master_release
  drm: Protect authmagic with master_mutex
  drm: Mark authmagic ioctls as unlocked
  drm: Mark set/drop master ioctl as unlocked.
  drm/omapdrm: don't call drm_helper_disable_unused_functions
  drm/crtc-helper: disable_unused_functions really isn't for atomic
  drm/amdkfd: Clean up inline handling
  drm: Move master pointer from drm_minor to drm_device
  drm: Clean up drm_crtc.h
  drm: Use dev->name as fallback for dev->unique
  drm/vgem: Stop calling drm_drv_set_unique
  drm: Don't call drm_dev_set_unique from platform drivers
  drm: Nuke SET_UNIQUE ioctl
  drm: Lobotomize set_busid nonsense for !pci drivers
  drm: Refactor drop/set master code a bit
  drm: Extract drm_is_current_master
  drm: Clear up master tracking booleans
  drm: document drm_auth.c

Jani Nikula (7):
  Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl
  Documentation/gpu: split up the gpu 

[PATCH 07/10] drm: Revamp connector_list protection

[Daniel Vetter]

On Tue, Jun 21, 2016 at 11:10:32AM +0200, Daniel Vetter wrote:
> This is a pretty good horror show, but I think it's the best tradeoff:
> - Thanks to srcu and delayed freeing the locking doesn't leak out to
>   callers, hence no added headaches with locking inversions.
> - For core and drivers which hot-remove connectors all the connector
>   list walking details are hidden in a macro.
> - Other drivers which don't care about hot-removing can simply keep on
>   using the normal list walking macros.
> 
> The new design is:
> - New dev->mode_config.connector_list_lock to protect the
>   connector_list, and the connector_ida (since that's also
>   unprotected), plus num_connectors. This is a pure leaf lock, nothing
>   is allowed to nest within, nothing outside of connector init/cleanup
>   will ever need it.
> - Protect connector_list itself with srcu. This allows sleeping and
>   anything else. The only thing which is not allowed is calling
>   synchronize_srcu, or grabbing any locks or waiting on
>   waitqueues/completions/whatever which might call that. To make this
>   100% safe we opt to not have any calls to synchronize_srcu.
> - Protect against use-after-free of connectors using call_srcu, to
>   delay the kfree enough.
> - To protect against zombie connectors which are in progress of final
>   destruction use kref_get_unless_zero. This is safe since srcu
>   prevents against use-after-free, and that's the only guarantee we
>   need.
> 
> For this demo I only bothered converting i915, and there also not
> everything - I left the connector loops in the modeset code unchanged
> since those will all be converted over to
> drm_for_each_connector_in_state to make them work correctly for
> nonblocking atomic commits. Only loops outside of atomic commits
> should be converted to drm_for_each_connector.
> 
> Note that the i915 DP MST code still uses drm_modeset_lock_all(). But
> that's not because of drm core connector lifetime issues, but because
> the fbdev helper reuses core locks to mange its own lists and data
> structures. Thierry Reding has a patch series to gift fbdev its own
> lock, which will remedy this.
> 
> v2: Totally rewrite everything to pack it up in a neat
> iterator macro, with init/check/next extracted into helpers.
> 
> v3: Tiny rebase conflict.
> 
> Signed-off-by: Daniel Vetter 

Ok, CI pointed out a flaw in this: break (or worse goto) means that the
unreference and the read_unlock_srcu isn't done at the end, which means
leaks and lockdep complaints. break can be fixed, but goto is impossible
to fix with plain C ...

Not sure what do to now, since I'd really like to avoid leaking the
connector_list locking all over the place. It means lots of churn, and
also issues (if we go without srcu) with locking inversions.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c  | 57 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c |  2 +-
>  include/drm/drm_crtc.h  | 82 
> +++--
>  3 files changed, 109 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6a8f91e8821b..dc22c0bfbe99 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -44,6 +44,9 @@
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
>  
> +DEFINE_SRCU(drm_connector_list_srcu);
> +EXPORT_SYMBOL(drm_connector_list_srcu);
> +
>  static struct drm_framebuffer *
>  internal_framebuffer_create(struct drm_device *dev,
>   const struct drm_mode_fb_cmd2 *r,
> @@ -825,7 +828,7 @@ static void drm_connector_get_cmdline_mode(struct 
> drm_connector *connector)
> mode->interlace ?  " interlaced" : "");
>  }
>  
> -static void drm_connector_free(struct kref *kref)
> +static void drm_connector_kref_release(struct kref *kref)
>  {
>   struct drm_connector *connector =
>   container_of(kref, struct drm_connector, base.refcount);
> @@ -858,11 +861,10 @@ int drm_connector_init(struct drm_device *dev,
>   struct ida *connector_ida =
>   _connector_enum_list[connector_type].ida;
>  
> - drm_modeset_lock_all(dev);
> -
> + mutex_lock(>mode_config.connector_list_lock);
>   ret = drm_mode_object_get_reg(dev, >base,
> DRM_MODE_OBJECT_CONNECTOR,
> -   false, drm_connector_free);
> +   false, drm_connector_kref_release);
>   if (ret)
>   goto out_unlock;
>  
> @@ -899,11 +901,6 @@ int drm_connector_init(struct drm_device *dev,
>  
>   drm_connector_get_cmdline_mode(connector);
>  
> - /* We should add connectors at the end to avoid upsetting the connector
> -  * index too much. */
> - list_add_tail(>head, >connector_list);
> - config->num_connector++;
> -
>   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
>   drm_object_attach_property(>base,
>  

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

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

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

--- Comment #3 from Christian König  ---
Well feel free to provide patches. The relevant source is in
src/gallium/drivers/radeon/radeon_uvd.c.

Probably all the 32 and 16 bit fields set into the message and feedback buffer
in get_h264_msg(), get_h265_msg(), get_vc1_msg(), get_mpeg2_msg(),
get_mpeg4_msg() and ruvd_end_frame() needs to be byte swapped.

It should actually be pretty trivial to do so, it's just a huge bunch of work
nobody so far has time to work on.

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

[Bug 95015] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

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

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

--- Comment #9 from intermediadc at hotmail.com  
---
Same bug i face on quad g5 equiped
5450 1 gb and 6570 2gb (x86 vboards).

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

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

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

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

--- Comment #2 from intermediadc at hotmail.com  
---
and this is bad :-( we are many here with this issue
im facing it on e5500 freescale P5020 and on G5 Quad

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

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Philipp Zabel]

Hi Nicolas,

Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat:
> >> Actually, experimenting a bit more with the code, I realized that the
> >> connector is always attached to the encoder, not the bridge, so the 2
> >> layouts above are actually identical (from the userspace point of
> >> view). Except that the connector name should be HDMI in one case, and
> >> DP in the other. But I think that's mostly a cosmetic difference?
> >
> >
> > Yeah, probably. I don't know what exactly the userspace does with
> > the connector type, but it would be nice to represent it as a DP
> > connector in case it makes any decisions based on it.
> 
> AFAICT does not matter... And, in any case, USB-C to HDMI adapters are
> far more common (so we'd do HDMI->(DP over USB-C)->HDMI), so there
> is a high change that advertising as DP would be wrong (and
> advertising as HDMI would be correct by chance...).

If anything it should be represented as an USB-C connector, whatever
USB-C(DP)->HDMI->VGA adapter chain is connected externally shouldn't
matter.

> >>> One way I can think of fixing this is to make make the MTK hdmi
> >>> encoder driver a bit smarter by observing the DT connections. If
> >>> it's output port is connected to just a hdmi-connector, then
> >>> things should be as before. If the output is connected to the DP
> >>> bridge, then it should create a DP connector. The connector ops
> >>> for the DP connector can still be the same as that of the HDMI
> >>> connector before, but the phandle to the DDC bus would be in the
> >>> DP device node in this case.
> >>
> >>
> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
> >> connector, as we're not reading the EDID on the DP side of the bridge,
> >> but on the HDMI side (and the bridge can do all sort of things to the
> >> EDID: At the very least, I think it caches it).
>>
> > On the board, do the DDC lines join directly from the SoC pins to the
> > DP connector, or does it go via the ANX7688 chip?
> 
> The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)

The anx7688 should get the i2c-ddc-bus property then, and the driver
should use it to implement get_modes (or its bridge API equivalent, once
it exists).

> > Even with the current bindings (referred from the link below), the
> > hdmi connector has the DDC node. Shouldn't it be the same in the DP
> > case too? The DP connector, like before, is still manged by the HDMI
> > driver, the only difference being the name and that it's two hops away
> > in the DT bindings.
> >
> > https://patchwork.kernel.org/patch/9137089/
> 
> True, the bindings say so, but the current code actually looks for
> ddc-i2c-bus property in whatever is connected on the endpoint (be it a
> bridge or a connector).

The HDMI driver only handles this itself because there are no separate
connector drivers (or helpers) to do this. Ideally the HDMI driver
shouldn't have to parse the connector DT node.

> And again, a bit odd as DP connector does not have true I2C lines...
> 
> Phillip? Any opinion?

Make the HDMI driver leave the bridges' DT node alone and let the bridge
handle DDC, if that's where it is connected physically.

regards
Philipp

[PATCH 19/38] drm/hisilicon: Implement some semblance of vblank event handling

[Xinliang Liu]

On 21 June 2016 at 15:19, Daniel Vetter  wrote:
> On Tue, Jun 21, 2016 at 3:32 AM, Xinliang Liu  
> wrote:
>> My understanding is that drm_crtc_arm_vblank_event work together with
>> drm_crtc_handle_vblank (called in vblank interrupt).
>> Arm the event first in somewhere(like atomic_begin/flush) and then
>> send it out throuth drm_crtc_handle_vblank in vblank interrupt.
>> In the other way, drm_crtc_send_vblank_event work together with flip
>> interrupt. That's means event will be sent in flip interrupt
>> immediately.
>> Is this right?
>
> First part is right. Second part about drm_crtc_send_vblank event just
> sends out the vblank directly (using the last recorded vblank). The
> vblank subsystem doesn't itself interact with any interrupt.
>
> Note that there's kerneldoc for all of this. Please make sure it does
> describe things sufficiently well, and if not please send in patches
> to improve them.

Ok, I will take a look at the doc.

Thanks,
-xinliang

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

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Nicolas Boichat]

Hi Archit,

Thanks for your reply.

On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja  
wrote:
> Hi,
>
> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
>>
>> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
>> that has an internal microcontroller.
>>
>> The only reason a Linux kernel driver is necessary is to reject
>> resolutions that require more bandwidth than what is available on
>> the DP side. DP bandwidth and lane count are reported by the bridge
>> via 2 registers on I2C.
>
>
> How does the chip know when to enable/disable itself? Does it shutoff
> itself if there isn't anything on the HDMI link?

Not 100% sure of the internals (there is a closed source firmware in
the chip), but I believe the HDMI/DP part of the chip is switched on
whenever there is a DP over USB-C connector plugged in.

>>
>> Signed-off-by: Nicolas Boichat 
>> ---
>>
>> Hi,
>>
>> I tested this driver using the Mediatek HDMI controller (MT8173) upstream
>> of the ANX bridge chip (Phillip sent a PULL request on June 13:
>> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
>> ).
>>
>> I have 2 concerns, that I'm not sure how to address within the kernel DRM
>> framework:
>>   1. All other bridge drivers also have a connector attached to it.
>> However, in
>>  this case, we cannot read the monitor EDID directly, so I'm not sure
>> what
>>  I could put in a "get_modes" function. Instead, ANX7688 provides a
>> I2C
>>  passthru/repeater, so the EDID is read on the Mediatek HDMI
>> controller side.
>>
>>  That leads to a somewhat strange layout, where we have:
>>  - MTK HDMI bridge/encoder
>>- MTK connector (HDMI)
>>- ANX7688 bridge
>>  - No connector
>
>
>
> You should ideally have one DP connector at the end of the chain:
>
> - MTK HDMI bridge/encoder
> - ANX7688 bridge
>- Connector (DP)
>
> In the dt-bindings for this board, hdmi's output port shouldn't be
> connected to a hdmi connector, but the input port of the ANX7688
> DP bridge. The output port of the bridge should be the one that
> connects to the DP connector.

Yes that's what I do (in the device tree).

Actually, experimenting a bit more with the code, I realized that the
connector is always attached to the encoder, not the bridge, so the 2
layouts above are actually identical (from the userspace point of
view). Except that the connector name should be HDMI in one case, and
DP in the other. But I think that's mostly a cosmetic difference?

> One way I can think of fixing this is to make make the MTK hdmi
> encoder driver a bit smarter by observing the DT connections. If
> it's output port is connected to just a hdmi-connector, then
> things should be as before. If the output is connected to the DP
> bridge, then it should create a DP connector. The connector ops
> for the DP connector can still be the same as that of the HDMI
> connector before, but the phandle to the DDC bus would be in the
> DP device node in this case.

I think it'd be a bit weird to have the DDC bus phandle on the DP
connector, as we're not reading the EDID on the DP side of the bridge,
but on the HDMI side (and the bridge can do all sort of things to the
EDID: At the very least, I think it caches it).

> This way, you can get around having the correct layout.
>
> Ideally, a bridge driver shouldn't be the one that creates a
> connector. It may contain some of the connector functionality, but
> the connector creation should be managed by the kms driver.
> Almost all bridge drivers creating a connector in their .attach
> callbacks since they own some of the connector functionality (like
> reading EDID). That's something we're trying to fix by providing
> some more bridge api that kms drivers can use.
>
> Since this bridge driver doesn't have any connector functionality
> anyway, you should be okay.

Great, thanks for clarifying.

>>
>>  Resolution filtering works fine though, thanks to mode_fixup callback
>> on the
>>  bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
>> its
>>  connector mode_valid callback, so that invalid modes are not even
>> presented
>>  to userspace.
>>
>>   2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
>> bpc does
>>  not seem to be included in the mode setting itself. We could possibly
>> iterate
>>  over connectors on the DRM device, but then, IIUC,
>> connector->display_info.bpc
>>  indicates the _maximum_ bpc supported by the monitor.
>
>
> I'm not clear about this either. Some drivers set a bus format
> on the connector via drm_display_info_set_bus_formats in their
> get_modes connector op, and then retrieve it later.

Ah, interesting... Seems like we'd need a big switch/case to convert
from bus_format to bpp, though.

>>
>> Any pointers? Thanks!
>>
>> Best,
>>
>> Nicolas
>>
>>   drivers/gpu/drm/bridge/Kconfig|   9 ++
>>   drivers/gpu/drm/bridge/Makefile   |   1 +
>>   

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

[Xinliang Liu]

From: Guodong Xu 

Add select HISI_KIRIN_DW_DSI to Kconfig.
The DRM driver depends on dsi sub-driver.

v2: Add myself Signed-off-by, becuase others give me the right to
forward the patch.

Signed-off-by: Zoltan Kuscsik 
Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index ea0df6115f7e..499f64405dac 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
+   select HISI_KIRIN_DW_DSI
help
  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
  If M is selected the module will be called kirin-drm.
-- 
2.8.3

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

[Xinliang Liu]

On 22 June 2016 at 08:54, Guodong Xu  wrote:
> On 21 June 2016 at 21:34, Thierry Reding  wrote:
>> On Mon, Jun 20, 2016 at 11:59:03AM +0800, Xinliang Liu wrote:
>>> From: Guodong Xu 
>>>
>>> Add select HISI_KIRIN_DW_DSI to Kconfig.
>>> The DRM driver depends on dsi sub-driver.
>>>
>>> Signed-off-by: Zoltan Kuscsik 
>>> ---
>>>  drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> You've got the Signed-off-by area messed up. If Guodong wrote this patch
>
> Hi, Xinliang,
>
> To clarify this, you don't need my Signed-off. Zoltan is the author,
> and I am just the person who ever integrated that patch into my local
> tree.

OK, Guodong.
Thanks,
-xinliang

>
> -Guodong
>
>> that his Signed-off-by needs to be added. Your Signed-off by should also
>> be added because you forwarded the patch to the mailing list.
>>
>> Thierry

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

[Xinliang Liu]

Hi,

On 21 June 2016 at 21:34, Thierry Reding  wrote:
> On Mon, Jun 20, 2016 at 11:59:03AM +0800, Xinliang Liu wrote:
>> From: Guodong Xu 
>>
>> Add select HISI_KIRIN_DW_DSI to Kconfig.
>> The DRM driver depends on dsi sub-driver.
>>
>> Signed-off-by: Zoltan Kuscsik 
>> ---
>>  drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>
> You've got the Signed-off-by area messed up. If Guodong wrote this patch
> that his Signed-off-by needs to be added. Your Signed-off by should also
> be added because you forwarded the patch to the mailing list.

Thierry, yes, you are right. I should add a Signed-off-by in the patch.

Thanks,
-xinliang

>
> Thierry

[PATCH v3.1 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

[Yakir Yang]

The document about rockchip platform make a mistaken in available
compatible name of "rk3288-edp", we should correct it to "rk3288-dp"
which correspond to the compatible name in driver.

This mistaken was introduced in commit be91c36247089 ("dt-bindings:
add document for rockchip variant of analogix_dp").

Reported-by: Tomasz Figa 
Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

 .../devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 726c945..827cc36 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip RK3288 specific extensions to the Analogix Display Port
 

 Required properties:
-- compatible: "rockchip,rk3288-edp",
+- compatible: "rockchip,rk3288-dp",
  "rockchip,rk3399-edp";

 - reg: physical base address of the controller and length
-- 
1.9.1

[PATCH v3.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

[Yakir Yang]

For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.

Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 787dc51..6a83f1a 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -56,6 +56,7 @@ struct rockchip_dp_device {
struct drm_display_mode  mode;

struct clk   *pclk;
+   struct clk   *grfclk;
struct regmap*grf;
struct reset_control *rst;

@@ -151,11 +152,20 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)

dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");

+   if (dp->grfclk) {
+   ret = clk_prepare_enable(dp->grfclk);
+   if (ret < 0) {
+   dev_err(dp->dev, "failed to enable grfclk %d\n", ret);
+   return;
+   }
+   }
+
ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
-   if (ret != 0) {
+   if (ret != 0)
dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
-   return;
-   }
+
+   if (dp->grfclk)
+   clk_disable_unprepare(dp->grfclk);
 }

 static void rockchip_dp_drm_encoder_nop(struct drm_encoder *encoder)
@@ -235,6 +245,10 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->grf);
}

+   dp->grfclk = devm_clk_get(dev, "grf");
+   if (IS_ERR(dp->grfclk))
+   dp->grfclk = NULL;
+
dp->pclk = devm_clk_get(dev, "pclk");
if (IS_ERR(dp->pclk)) {
dev_err(dev, "failed to get pclk property\n");
-- 
1.9.1

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

On 21 June 2016 at 17:07, Thierry Reding  wrote:
> On Tue, Jun 21, 2016 at 01:06:41PM +0200, Tomeu Vizoso wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> [...]
>
>> +
>> +static int crc_control_show(struct seq_file *m, void *data)
>> +{
>> + struct drm_device *dev = m->private;
>> + struct drm_crtc *crtc;
>> +
>> + drm_for_each_crtc(crtc, dev)
>> + seq_printf(m, "crtc %d %s\n", crtc->index,
>> +crtc->crc.source ? crtc->crc.source : "none");
>> +
>> + return 0;
>> +}
>
> Why are these control files not per-CRTC? I'd imagine you could do
> something like control the CRC generation on writes and provide the
> sampled CRCs on reads.

We just thought there wasn't a strong point for breaking the existing
API in a fundamental way. The current proposal allows us to reuse more
code between the new and legacy CRC implementations in i915 and in
IGT.

>> + source = NULL;
>> +
>> + if (!crc->source && !source)
>> + return 0;
>> +
>> + if (crc->source && source && !strcmp(crc->source, source))
>> + return 0;
>> +
>> + /* Forbid changing the source without going back to "none". */
>> + if (crc->source && source)
>> + return -EINVAL;
>
> Why? It seems to me that if a driver doesn't support switching from one
> source to another directly, then it should internally handle that. After
> all the source parameter is already driver-specific, so it seems odd to
> impose this kind of policy on it at this level.

Hmm, I don't see when that would make sense for userspace. If
userspace has a source configured and changes directly to another, how
does it know what's the last CRC for the old source? I think that if
userspace does that it's shooting in its foot and it's good to give an
error.

>> +
>> + drm_for_each_crtc(crtc, dev)
>> + if (i++ == index)
>> + return crtc;
>> +
>> + return NULL;
>> +}
>
> This looks like a candidate for the core. I know that at least Tegra
> implements a variant of this, and I think i915 does, too.

And a few others. I would go this way but when I pinged danvet on irc
he didn't reply so I just went with the safe option.

>> +/*
>> + * Parse CRC command strings:
>> + *   command: wsp* object wsp+ (crtc | pipe) wsp+ source wsp*
>
> Should the "(crtc | pipe)" in the above be "object"?

In one case they are literals and in the other symbols.

>> + *   object: ('crtc' | 'pipe')
>
> Because you define that here?
>
>> + *   crtc: (0 | 1 | 2 | ...)
>> + *   pipe: (A | B | C)
>> + *   source: (none | plane1 | plane2 | ...)
>
> I wouldn't provide "plane1 | plane2 |" here, since the parameter is
> passed as-is to drivers, which may or may not support plane1 or plane2.

Agreed, feels more confusing than clarifying.

>> + *   wsp: (#0x20 | #0x9 | #0xA)+
>> + *
>> + * eg.:
>> + *  "crtc 0 plane1"  ->  Start CRC computations on plane1 of first CRTC
>> + *  "crtc 0 none"->  Stop CRC
>
> I've said this above, but again, it seems odd to me that you'd have to
> configure the CRC per-CRTC in one per-device file and read out the CRC
> from per-CRTC files.

Not sure, I like that the per-crtc files just provide CRC data, and
that there's a separate control file that can be queried for the
current state.

>
>> +entry->frame, entry->crc[0],
>> +entry->crc[1], entry->crc[2],
>> +entry->crc[3], entry->crc[4]);
>
> What about drivers that only support one uint32_t for the CRC? Do they
> also need to output all unused uint32_t:s?

Yeah, do you think that could be a problem?

>> +
>> + ret = copy_to_user(user_buf, buf, CRC_LINE_LEN);
>> + if (ret == CRC_LINE_LEN)
>> + return -EFAULT;
>>
>> + user_buf += CRC_LINE_LEN;
>> + n_entries--;
>> +
>> + spin_lock_irq(>lock);
>> + }
>> +
>> + spin_unlock_irq(>lock);
>> +
>> + return bytes_read;
>> +}
>> +
>> +const struct file_operations drm_crtc_crc_fops = {
>> + .owner = THIS_MODULE,
>> + .open = crtc_crc_open,
>> + .read = crtc_crc_read,
>> + .release = crtc_crc_release,
>> +};
>
> Do we want to support poll?

Don't see the point of it, TBH.

>> +
>> +static int drm_debugfs_crtc_add_for_minor(struct drm_crtc *crtc,
>> +   struct drm_minor *minor)
>> +{
>> + struct dentry *ent;
>> + char *name;
>> +
>> + if (!minor->debugfs_root)
>> + return -1;
>
> Can this ever happen? Perhaps turn this into a symbolic name if you
> really need it.

Sorry, can you explain what you mean by that?

>> +
>> + name = kasprintf(GFP_KERNEL, "drm_crtc_%d_crc", crtc->index);
>> + if (!name)
>> + return -ENOMEM;
>
> I think it might be preferable to move this all into per-CRTC debugfs
> directories, perhaps even collapse the 

[PATCH v3 0/10]

[Yakir Yang]

Archit,

On 06/21/2016 09:46 PM, Archit Taneja wrote:
>
>
> On 6/14/2016 5:15 PM, Yakir Yang wrote:
>> RK3399 and RK3288 shared the same eDP IP controller, only some light
>> difference with VOP configure and GRF configure.
>>
>> Also same misc fix to analogix_dp driver:
>> - Hotplug invalid which report by Dan Carpenter
>> - Make panel detect to an optional action
>> - correct the register bit define error in ANALOGIX_DP_PLL_REG_1
>>
>>
>> Changes in v3:
>> - Correct the misspell of "marcos" in commit message (Dominik, 
>> reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346312/9//COMMIT_MSG at 9]
>> - Add reviewed flag from Stéphane.
>>  [https://chromium-review.googlesource.com/#/c/346312/16]
>> - Add tested flag from Javier.
>> - Write a kerneldoc-style comment explaining the chips data fields 
>> (Tomasz, reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>  at 39]
>> - Drop the '.lcdcsel_mask' number in chips data field (Tomasz, 
>> reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>  at 382]
>> - Add acked flag from Mark.
>> - Add reviewed flag from Tomasz.
>>  [https://chromium-review.googlesource.com/#/c/346315/15]
>> - Add tested flag from Javier
>> - Make this hack code more clear (Tomasz, reviewed at Google Gerrit)
>>reg = ~reg & REF_CLK_MASK;  --->  reg ^= REF_CLK_MASK;
>> [https://chromium-review.googlesource.com/#/c/346852/7/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>  at 80]
>> - Add tested flag from Javier
>> - Give the "rk3399-edp" a separate line for clarity in document 
>> (Tomasz, reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346314/10/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
>>  at 5]
>> - Move 'output_type' setting before the return statement (Tomasz, 
>> reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346314/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>  at 154]
>> - Add the acked flag from Mark.
>> - Add the acked flag from Mark.
>> - Avoid to change any internal driver state in .mode_valid interface. 
>> (Tomasz, reviewed at Google Gerrit)
>> [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>  at 113]
>> - Hook the connector's color_formats in .get_modes directly. (Tomasz, 
>> reviewed at Google Gerrit)
>>  [https://chromium-review.googlesource.com/#/c/346317/15]
>> - Add the acked flag from Mark.
>> - Add the reviewed flag from Tomasz.
>>  [https://chromium-review.googlesource.com/#/c/346853/12]
>> - Add the acked flag from Mark.
>> - Add reviewed flag from Stéphane.
>>  [https://chromium-review.googlesource.com/#/c/346319/15]
>> - Add tested flag from Javier
>>
>> Changes in v2:
>> - new patch in v2
>> - rebase with drm-next, fix some conflicts
>> - new patch in v2
>>
>> Yakir Yang (10):
>>drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP
>>drm/rockchip: analogix_dp: split the lcdc select setting into device
>>  data
>>drm/bridge: analogix_dp: correct the register bit define error in
>>  ANALOGIX_DP_PLL_REG_1
>>drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit
>>  setting
>>drm/rockchip: analogix_dp: add rk3399 eDP support
>>drm/rockchip: analogix_dp: make panel detect to an optional action
>>drm/bridge: analogix_dp: passing the connector as an argument in
>>  .get_modes()
>>drm/rockchip: analogix_dp: correct the connector display color format
>>  and bpc
>>drm/rockchip: analogix_dp: update the comments about why need to
>>  hardcode VOP output mode
>>drm/bridge: analogix_dp: fix no drm hpd event when panel plug in
>
> Is the plan to take all the bridge+rockchip stuff via the rockchip pull
> request?
>

Yep, most of those patch need to rely on others, so it's better to 
collect all of them into one pull request ;)

Thanks,
- Yakir

> Thanks,
> Archit
>
>>
>>   .../bindings/display/bridge/analogix_dp.txt|   1 +
>>   .../display/rockchip/analogix_dp-rockchip.txt  |   3 +-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   6 +-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  12 +-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   5 +-
>>   drivers/gpu/drm/exynos/exynos_dp.c |   4 +-
>>   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 158 
>> ++---
>>   include/drm/bridge/analogix_dp.h   |   9 +-
>>   9 files changed, 141 insertions(+), 65 deletions(-)
>>
>

linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell  
> > wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >   drivers/gpu/drm/sti/sti_drv.c
> > >
> > > between commit:
> > >
> > >   062993b15e8e ("drm: convert DT component matching to 
> > > component_match_add_release()")
> > 
> > Why did that one end up in the arm tree? Should it go in through
> > drm-misc instead?
> 
> Mine is part of a three part patch series which is part of the component
> helper updates (which I'm the author and maintainer of).
> 
> Then someone came up with an alternative way of some of part of it.
> 
> You can't merge the above DRM part, because that means you also need to
> merge patch 1, which is core component stuff.

Makes sense, but generally in that case I ask Dave for an explicit ack for
merging through another tree to avoid confusion. Lack of that is why I
asked.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

[Daniel Vetter]

On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> We are only documenting that the read is outside of the lock, and do not
> require strict ordering on the operation. In this case the more relaxed
> lockless_dereference() will suffice.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Julia Lawall 
> Cc: Chris Wilson 
> Cc: Emil Velikov 

Applied to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0a06f9120b5a..ce54e985d91b 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> *fb_helper)
>  
>   /* Sometimes user space wants everything disabled, so don't steal the
>* display if there's a master. */
> - if (READ_ONCE(dev->master))
> + if (lockless_dereference(dev->master))
>   return false;
>  
>   drm_for_each_crtc(crtc, dev) {
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/3] drm/sun4i: Remove open-coded drm_connector_register_all()

[Daniel Vetter]

On Tue, Jun 21, 2016 at 10:28:03AM +0100, Chris Wilson wrote:
> drm_dev_register() will now register all known connectors, so we no
> longer have to do so manually.
> 
> Signed-off-by: Chris Wilson 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Chen-Yu Tsai 
> Cc: Daniel Vetter 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org

Merged all 3 to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 34 --
>  1 file changed, 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 68e9d85085fb..59cd8b27ee02 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -24,34 +24,6 @@
>  #include "sun4i_layer.h"
>  #include "sun4i_tcon.h"
>  
> -static int sun4i_drv_connector_plug_all(struct drm_device *drm)
> -{
> - struct drm_connector *connector, *failed;
> - int ret;
> -
> - mutex_lock(>mode_config.mutex);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - ret = drm_connector_register(connector);
> - if (ret) {
> - failed = connector;
> - goto err;
> - }
> - }
> - mutex_unlock(>mode_config.mutex);
> - return 0;
> -
> -err:
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - if (failed == connector)
> - break;
> -
> - drm_connector_unregister(connector);
> - }
> - mutex_unlock(>mode_config.mutex);
> -
> - return ret;
> -}
> -
>  static int sun4i_drv_enable_vblank(struct drm_device *drm, unsigned int pipe)
>  {
>   struct sun4i_drv *drv = drm->dev_private;
> @@ -187,14 +159,8 @@ static int sun4i_drv_bind(struct device *dev)
>   if (ret)
>   goto free_drm;
>  
> - ret = sun4i_drv_connector_plug_all(drm);
> - if (ret)
> - goto unregister_drm;
> -
>   return 0;
>  
> -unregister_drm:
> - drm_dev_unregister(drm);
>  free_drm:
>   drm_dev_unref(drm);
>   return ret;
> -- 
> 2.8.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 96620] build failure in igt_fb.c due to missing inttypes.h

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

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

Jani Nikula  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Jani Nikula  ---
(In reply to Mike Frysinger from comment #1)
> Created attachment 124646 [details] [review]
> fix

Care to post that to intel-gfx at lists.freedesktop.org please?
--subject-prefix="PATCH i-g-t".

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

linux-next: manual merge of the drm-misc tree with the arm tree

[Russell King]

On Wed, Jun 22, 2016 at 10:23:36AM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> > On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell  > > canb.auug.org.au> wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > > >
> > > >   drivers/gpu/drm/sti/sti_drv.c
> > > >
> > > > between commit:
> > > >
> > > >   062993b15e8e ("drm: convert DT component matching to 
> > > > component_match_add_release()")
> > > 
> > > Why did that one end up in the arm tree? Should it go in through
> > > drm-misc instead?
> > 
> > Mine is part of a three part patch series which is part of the component
> > helper updates (which I'm the author and maintainer of).
> > 
> > Then someone came up with an alternative way of some of part of it.
> > 
> > You can't merge the above DRM part, because that means you also need to
> > merge patch 1, which is core component stuff.
> 
> Makes sense, but generally in that case I ask Dave for an explicit ack for
> merging through another tree to avoid confusion. Lack of that is why I
> asked.

It got posted to the appropriate mailing lists with CCs, including David.
Just three people responded.

One of the responses was that people didn't like the duplication.  I
posted v2 the same day, the DT people didn't like the file location, so
I went back to v1.  That then sparked someone to start working _against_
me, cleaning up the existing duplication, and acknowledging that it'll
cause _me_ problems.

So, as it was done maliciously and intentionally to give these porblems,
I'm not budging on this.  Sorry.

There are times when working on the kernel is not very nice.  This is one
of them.

-- 
Russell King
ARM architecture Linux Kernel maintainer

[PATCH 01/10] drm/amd-kfd: Clean up inline handling

[Daniel Vetter]

On Tue, Jun 21, 2016 at 10:11:13PM +0300, Oded Gabbay wrote:
> On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter  
> wrote:
> > - inline functions need to be static inline, otherwise gcc can opt to
> >   not inline and the linker gets unhappy.
> > - no forward decls for inline functions, just include the right headers.
> >
> > Cc: Oded Gabbay 
> > Cc: Ben Goz 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 4 ++--
> >  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 ---
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > index ec4036a09f3e..a625b9137da2 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > @@ -187,12 +187,12 @@ int init_pipelines(struct device_queue_manager *dqm,
> >  unsigned int get_first_pipe(struct device_queue_manager *dqm);
> >  unsigned int get_pipes_num(struct device_queue_manager *dqm);
> >
> > -extern inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> > *pdd)
> > +static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> > *pdd)
> >  {
> > return (pdd->lds_base >> 16) & 0xFF;
> >  }
> >
> > -extern inline unsigned int
> > +static inline unsigned int
> >  get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
> >  {
> > return (pdd->lds_base >> 60) & 0x0E;
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > index d0d5f4baf72d..80113c335966 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > @@ -617,10 +617,7 @@ int kgd2kfd_resume(struct kfd_dev *kfd);
> >  int kfd_init_apertures(struct kfd_process *process);
> >
> >  /* Queue Context Management */
> > -inline uint32_t lower_32(uint64_t x);
> > -inline uint32_t upper_32(uint64_t x);
> >  struct cik_sdma_rlc_registers *get_sdma_mqd(void *mqd);
> > -inline uint32_t get_sdma_base_addr(struct cik_sdma_rlc_registers *m);
> >
> >  int init_queue(struct queue **q, struct queue_properties properties);
> >  void uninit_queue(struct queue *q);
> > --
> > 2.8.1
> >
> 
> Hi Daniel,
> Minor comment, please change the commit message title to "drm/amdkfd:
> ..." (without the "-" between amd and kfd), to make this patch
> consistent with all amdkfd patches.
> 
> With that change, this patch is:
> Reviewed-by: Oded Gabbay 

Fixed up and applied, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell  
wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
>   drivers/gpu/drm/sti/sti_drv.c
>
> between commit:
>
>   062993b15e8e ("drm: convert DT component matching to 
> component_match_add_release()")

Why did that one end up in the arm tree? Should it go in through
drm-misc instead?
-Daniel

> from the arm tree and commit:
>
>   84601dbdea36 ("drm: sti: rework init sequence")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/sti/sti_drv.c
> index 8abb57a94651,96bd3d08b2d4..
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
> return dev->of_node == data;
>   }
>
>  +static void release_of(struct device *dev, void *data)
>  +{
>  +  of_node_put(data);
>  +}
>  +
> + static int sti_init(struct drm_device *ddev)
> + {
> +   struct sti_private *private;
> +
> +   private = kzalloc(sizeof(*private), GFP_KERNEL);
> +   if (!private)
> +   return -ENOMEM;
> +
> +   ddev->dev_private = (void *)private;
> +   dev_set_drvdata(ddev->dev, ddev);
> +   private->drm_dev = ddev;
> +
> +   mutex_init(>commit.lock);
> +   INIT_WORK(>commit.work, sti_atomic_work);
> +
> +   drm_mode_config_init(ddev);
> +
> +   sti_mode_config_init(ddev);
> +
> +   drm_kms_helper_poll_init(ddev);
> +
> +   return 0;
> + }
> +
> + static void sti_cleanup(struct drm_device *ddev)
> + {
> +   struct sti_private *private = ddev->dev_private;
> +
> +   if (private->fbdev) {
> +   drm_fbdev_cma_fini(private->fbdev);
> +   private->fbdev = NULL;
> +   }
> +
> +   drm_kms_helper_poll_fini(ddev);
> +   drm_vblank_cleanup(ddev);
> +   kfree(private);
> +   ddev->dev_private = NULL;
> + }
> +
>   static int sti_bind(struct device *dev)
>   {
> -   return drm_platform_init(_driver, to_platform_device(dev));
> +   struct drm_device *ddev;
> +   int ret;
> +
> +   ddev = drm_dev_alloc(_driver, dev);
> +   if (!ddev)
> +   return -ENOMEM;
> +
> +   ddev->platformdev = to_platform_device(dev);
> +
> +   ret = sti_init(ddev);
> +   if (ret)
> +   goto err_drm_dev_unref;
> +
> +   ret = component_bind_all(ddev->dev, ddev);
> +   if (ret)
> +   goto err_cleanup;
> +
> +   ret = drm_dev_register(ddev, 0);
> +   if (ret)
> +   goto err_register;
> +
> +   drm_mode_config_reset(ddev);
> +
> +   return 0;
> +
> + err_register:
> +   drm_mode_config_cleanup(ddev);
> + err_cleanup:
> +   sti_cleanup(ddev);
> + err_drm_dev_unref:
> +   drm_dev_unref(ddev);
> +   return ret;
>   }
>
>   static void sti_unbind(struct device *dev)



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

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Archit Taneja]

On 6/22/2016 8:14 AM, Nicolas Boichat wrote:
> Hi Archit,
>
> Thanks for your reply.
>
> On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja  
> wrote:
>> Hi,
>>
>> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
>>>
>>> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
>>> that has an internal microcontroller.
>>>
>>> The only reason a Linux kernel driver is necessary is to reject
>>> resolutions that require more bandwidth than what is available on
>>> the DP side. DP bandwidth and lane count are reported by the bridge
>>> via 2 registers on I2C.
>>
>>
>> How does the chip know when to enable/disable itself? Does it shutoff
>> itself if there isn't anything on the HDMI link?
>
> Not 100% sure of the internals (there is a closed source firmware in
> the chip), but I believe the HDMI/DP part of the chip is switched on
> whenever there is a DP over USB-C connector plugged in.
>
>>>
>>> Signed-off-by: Nicolas Boichat 
>>> ---
>>>
>>> Hi,
>>>
>>> I tested this driver using the Mediatek HDMI controller (MT8173) upstream
>>> of the ANX bridge chip (Phillip sent a PULL request on June 13:
>>> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
>>> ).
>>>
>>> I have 2 concerns, that I'm not sure how to address within the kernel DRM
>>> framework:
>>>1. All other bridge drivers also have a connector attached to it.
>>> However, in
>>>   this case, we cannot read the monitor EDID directly, so I'm not sure
>>> what
>>>   I could put in a "get_modes" function. Instead, ANX7688 provides a
>>> I2C
>>>   passthru/repeater, so the EDID is read on the Mediatek HDMI
>>> controller side.
>>>
>>>   That leads to a somewhat strange layout, where we have:
>>>   - MTK HDMI bridge/encoder
>>> - MTK connector (HDMI)
>>> - ANX7688 bridge
>>>   - No connector
>>
>>
>>
>> You should ideally have one DP connector at the end of the chain:
>>
>>  - MTK HDMI bridge/encoder
>>  - ANX7688 bridge
>> - Connector (DP)
>>
>> In the dt-bindings for this board, hdmi's output port shouldn't be
>> connected to a hdmi connector, but the input port of the ANX7688
>> DP bridge. The output port of the bridge should be the one that
>> connects to the DP connector.
>
> Yes that's what I do (in the device tree).
>
> Actually, experimenting a bit more with the code, I realized that the
> connector is always attached to the encoder, not the bridge, so the 2
> layouts above are actually identical (from the userspace point of
> view). Except that the connector name should be HDMI in one case, and
> DP in the other. But I think that's mostly a cosmetic difference?

Yeah, probably. I don't know what exactly the userspace does with
the connector type, but it would be nice to represent it as a DP
connector in case it makes any decisions based on it.

>
>> One way I can think of fixing this is to make make the MTK hdmi
>> encoder driver a bit smarter by observing the DT connections. If
>> it's output port is connected to just a hdmi-connector, then
>> things should be as before. If the output is connected to the DP
>> bridge, then it should create a DP connector. The connector ops
>> for the DP connector can still be the same as that of the HDMI
>> connector before, but the phandle to the DDC bus would be in the
>> DP device node in this case.
>
> I think it'd be a bit weird to have the DDC bus phandle on the DP
> connector, as we're not reading the EDID on the DP side of the bridge,
> but on the HDMI side (and the bridge can do all sort of things to the
> EDID: At the very least, I think it caches it).

On the board, do the DDC lines join directly from the SoC pins to the
DP connector, or does it go via the ANX7688 chip?

Even with the current bindings (referred from the link below), the
hdmi connector has the DDC node. Shouldn't it be the same in the DP
case too? The DP connector, like before, is still manged by the HDMI
driver, the only difference being the name and that it's two hops away
in the DT bindings.

https://patchwork.kernel.org/patch/9137089/

>
>> This way, you can get around having the correct layout.
>>
>> Ideally, a bridge driver shouldn't be the one that creates a
>> connector. It may contain some of the connector functionality, but
>> the connector creation should be managed by the kms driver.
>> Almost all bridge drivers creating a connector in their .attach
>> callbacks since they own some of the connector functionality (like
>> reading EDID). That's something we're trying to fix by providing
>> some more bridge api that kms drivers can use.
>>
>> Since this bridge driver doesn't have any connector functionality
>> anyway, you should be okay.
>
> Great, thanks for clarifying.
>
>>>
>>>   Resolution filtering works fine though, thanks to mode_fixup callback
>>> on the
>>>   bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
>>> its
>>>   connector mode_valid callback, so that invalid modes 

linux-next: manual merge of the drm-misc tree with the arm tree

[Russell King]

On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell  
> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> >   drivers/gpu/drm/sti/sti_drv.c
> >
> > between commit:
> >
> >   062993b15e8e ("drm: convert DT component matching to 
> > component_match_add_release()")
> 
> Why did that one end up in the arm tree? Should it go in through
> drm-misc instead?

Mine is part of a three part patch series which is part of the component
helper updates (which I'm the author and maintainer of).

Then someone came up with an alternative way of some of part of it.

You can't merge the above DRM part, because that means you also need to
merge patch 1, which is core component stuff.

-- 
Russell King
ARM architecture Linux Kernel maintainer

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

[Guodong Xu]

On 21 June 2016 at 21:34, Thierry Reding  wrote:
> On Mon, Jun 20, 2016 at 11:59:03AM +0800, Xinliang Liu wrote:
>> From: Guodong Xu 
>>
>> Add select HISI_KIRIN_DW_DSI to Kconfig.
>> The DRM driver depends on dsi sub-driver.
>>
>> Signed-off-by: Zoltan Kuscsik 
>> ---
>>  drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>
> You've got the Signed-off-by area messed up. If Guodong wrote this patch

Hi, Xinliang,

To clarify this, you don't need my Signed-off. Zoltan is the author,
and I am just the person who ever integrated that patch into my local
tree.

-Guodong

> that his Signed-off-by needs to be added. Your Signed-off by should also
> be added because you forwarded the patch to the mailing list.
>
> Thierry

[PATCH v3 0/10]

[Archit Taneja]

On 6/22/2016 7:54 AM, Yakir Yang wrote:
> Archit,
>
> On 06/21/2016 09:46 PM, Archit Taneja wrote:
>>
>>
>> On 6/14/2016 5:15 PM, Yakir Yang wrote:
>>> RK3399 and RK3288 shared the same eDP IP controller, only some light
>>> difference with VOP configure and GRF configure.
>>>
>>> Also same misc fix to analogix_dp driver:
>>> - Hotplug invalid which report by Dan Carpenter
>>> - Make panel detect to an optional action
>>> - correct the register bit define error in ANALOGIX_DP_PLL_REG_1
>>>
>>>
>>> Changes in v3:
>>> - Correct the misspell of "marcos" in commit message (Dominik,
>>> reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346312/9//COMMIT_MSG at 9]
>>> - Add reviewed flag from Stéphane.
>>>  [https://chromium-review.googlesource.com/#/c/346312/16]
>>> - Add tested flag from Javier.
>>> - Write a kerneldoc-style comment explaining the chips data fields
>>> (Tomasz, reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>>  at 39]
>>>
>>> - Drop the '.lcdcsel_mask' number in chips data field (Tomasz,
>>> reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>>  at 382]
>>>
>>> - Add acked flag from Mark.
>>> - Add reviewed flag from Tomasz.
>>>  [https://chromium-review.googlesource.com/#/c/346315/15]
>>> - Add tested flag from Javier
>>> - Make this hack code more clear (Tomasz, reviewed at Google Gerrit)
>>>reg = ~reg & REF_CLK_MASK;  --->  reg ^= REF_CLK_MASK;
>>> [https://chromium-review.googlesource.com/#/c/346852/7/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>>  at 80]
>>>
>>> - Add tested flag from Javier
>>> - Give the "rk3399-edp" a separate line for clarity in document
>>> (Tomasz, reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346314/10/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
>>>  at 5]
>>>
>>> - Move 'output_type' setting before the return statement (Tomasz,
>>> reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346314/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>>  at 154]
>>>
>>> - Add the acked flag from Mark.
>>> - Add the acked flag from Mark.
>>> - Avoid to change any internal driver state in .mode_valid interface.
>>> (Tomasz, reviewed at Google Gerrit)
>>> [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>>  at 113]
>>>
>>> - Hook the connector's color_formats in .get_modes directly. (Tomasz,
>>> reviewed at Google Gerrit)
>>>  [https://chromium-review.googlesource.com/#/c/346317/15]
>>> - Add the acked flag from Mark.
>>> - Add the reviewed flag from Tomasz.
>>>  [https://chromium-review.googlesource.com/#/c/346853/12]
>>> - Add the acked flag from Mark.
>>> - Add reviewed flag from Stéphane.
>>>  [https://chromium-review.googlesource.com/#/c/346319/15]
>>> - Add tested flag from Javier
>>>
>>> Changes in v2:
>>> - new patch in v2
>>> - rebase with drm-next, fix some conflicts
>>> - new patch in v2
>>>
>>> Yakir Yang (10):
>>>drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP
>>>drm/rockchip: analogix_dp: split the lcdc select setting into device
>>>  data
>>>drm/bridge: analogix_dp: correct the register bit define error in
>>>  ANALOGIX_DP_PLL_REG_1
>>>drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit
>>>  setting
>>>drm/rockchip: analogix_dp: add rk3399 eDP support
>>>drm/rockchip: analogix_dp: make panel detect to an optional action
>>>drm/bridge: analogix_dp: passing the connector as an argument in
>>>  .get_modes()
>>>drm/rockchip: analogix_dp: correct the connector display color format
>>>  and bpc
>>>drm/rockchip: analogix_dp: update the comments about why need to
>>>  hardcode VOP output mode
>>>drm/bridge: analogix_dp: fix no drm hpd event when panel plug in
>>
>> Is the plan to take all the bridge+rockchip stuff via the rockchip pull
>> request?
>>
>
> Yep, most of those patch need to rely on others, so it's better to
> collect all of them into one pull request ;)

Cool. Sounds good.

Archit

>
> Thanks,
> - Yakir
>
>> Thanks,
>> Archit
>>
>>>
>>>   .../bindings/display/bridge/analogix_dp.txt|   1 +
>>>   .../display/rockchip/analogix_dp-rockchip.txt  |   3 +-
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   6 +-
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  12 +-
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   5 +-
>>>   drivers/gpu/drm/exynos/exynos_dp.c |   4 +-
>>>   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 158
>>> ++---
>>>   include/drm/bridge/analogix_dp.h   |   9 +-
>>>   9 files changed, 141 insertions(+), 65 deletions(-)

[PATCH] drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

[Chris Wilson]

We are only documenting that the read is outside of the lock, and do not
require strict ordering on the operation. In this case the more relaxed
lockless_dereference() will suffice.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Julia Lawall 
Cc: Chris Wilson 
Cc: Emil Velikov 
---
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0a06f9120b5a..ce54e985d91b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
*fb_helper)

/* Sometimes user space wants everything disabled, so don't steal the
 * display if there's a master. */
-   if (READ_ONCE(dev->master))
+   if (lockless_dereference(dev->master))
return false;

drm_for_each_crtc(crtc, dev) {
-- 
2.8.1

[RFC PATCH v2 4/6] PM / devfreq: event: support rockchip dfi controller

[Tomeu Vizoso]

On 6 June 2016 at 12:13, Lin Huang  wrote:
> on rk3399 platform, there is dfi conroller can monitor
> ddr load, base on this result, we can do ddr freqency
> scaling.

Hi Lin,

isn't the DDRMON in this SoC capable of raising interrupts when the
programmed utilization thresholds have been trespassed?

If so, then I think it would be more appropriate to do it similarly to
tegra-devfreq, instead of using devfreq-event and polling the hardware
at given intervals.

Regards,

Tomeu

> Signed-off-by: Lin Huang 
> Acked-by: Chanwoo Choi 
> ---
>
> Changes in v2:
> - use clk_disable_unprepare and clk_enable_prepare
> - remove clk_enable_prepare in probe
> - remove rockchip_dfi_remove function
>
> Changes in v1:
> - None
>
>  drivers/devfreq/event/Kconfig|   7 +
>  drivers/devfreq/event/Makefile   |   1 +
>  drivers/devfreq/event/rockchip-dfi.c | 253 
> +++
>  3 files changed, 261 insertions(+)
>  create mode 100644 drivers/devfreq/event/rockchip-dfi.c
>
> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
> index 1e8b4f4..96f2331 100644
> --- a/drivers/devfreq/event/Kconfig
> +++ b/drivers/devfreq/event/Kconfig
> @@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
>   (Platform Performance Monitoring Unit) counters to estimate the
>   utilization of each module.
>
> +config DEVFREQ_EVENT_ROCKCHIP_DFI
> +   bool "ROCKCHIP DFI DEVFREQ event Driver"
> +   depends on ARCH_ROCKCHIP
> +   help
> + This add the devfreq-event driver for Rockchip SoC. It provides DFI
> + (DDR Monitor Module) driver to count ddr load.
> +
>  endif # PM_DEVFREQ_EVENT
> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
> index 3d6afd3..dda7090 100644
> --- a/drivers/devfreq/event/Makefile
> +++ b/drivers/devfreq/event/Makefile
> @@ -2,3 +2,4 @@
>
>  obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
>  obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
> +obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
> diff --git a/drivers/devfreq/event/rockchip-dfi.c 
> b/drivers/devfreq/event/rockchip-dfi.c
> new file mode 100644
> index 000..96a0307
> --- /dev/null
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Lin Huang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RK3399_DMC_NUM_CH  2
> +
> +/* DDRMON_CTRL */
> +#define DDRMON_CTRL0x04
> +#define CLR_DDRMON_CTRL(0x1f << 0)
> +#define LPDDR4_EN  (0x10001 << 4)
> +#define HARDWARE_EN(0x10001 << 3)
> +#define LPDDR3_EN  (0x10001 << 2)
> +#define SOFTWARE_EN(0x10001 << 1)
> +#define TIME_CNT_EN(0x10001 << 0)
> +
> +#define DDRMON_CH0_COUNT_NUM   0x28
> +#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
> +#define DDRMON_CH1_COUNT_NUM   0x3c
> +#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
> +
> +/* pmu grf */
> +#define PMUGRF_OS_REG2 0x308
> +#define DDRTYPE_SHIFT  13
> +#define DDRTYPE_MASK   7
> +
> +enum {
> +   DDR3 = 3,
> +   LPDDR3 = 6,
> +   LPDDR4 = 7,
> +   UNUSED = 0xFF
> +};
> +
> +struct dmc_usage {
> +   u32 access;
> +   u32 total;
> +};
> +
> +struct rockchip_dfi {
> +   struct devfreq_event_dev *edev;
> +   struct devfreq_event_desc *desc;
> +   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
> +   struct device *dev;
> +   void __iomem *regs;
> +   struct regmap *regmap_pmu;
> +   struct clk *clk;
> +};
> +
> +static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev 
> *edev)
> +{
> +   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
> +   void __iomem *dfi_regs = info->regs;
> +   u32 val;
> +   u32 ddr_type;
> +
> +   /* get ddr type */
> +   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
> +   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> +
> +   /* clear DDRMON_CTRL setting */
> +   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
> +
> +   /* set ddr type to dfi */
> +   if (ddr_type == LPDDR3)
> +   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> +   else if (ddr_type == LPDDR4)
> +   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
> +
> +   /* enable count, use software mode */
> + 

[PATCH] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

vGEM buffers are useful for passing data between software clients and
hardware renders. By allowing the user to create and attach fences to
the exported vGEM buffers (on the dma-buf), the user can implement a
deferred renderer and queue hardware operations like flipping and then
signal the buffer readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).

This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.

Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris Wilson 
Cc: Sean Paul 
Cc: Zach Reizner 
---
 drivers/gpu/drm/vgem/Makefile |   2 +-
 drivers/gpu/drm/vgem/vgem_drv.c   |  34 ++
 drivers/gpu/drm/vgem/vgem_drv.h   |  18 
 drivers/gpu/drm/vgem/vgem_fence.c | 217 ++
 include/uapi/drm/vgem_drm.h   |  62 +++
 5 files changed, 332 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
 create mode 100644 include/uapi/drm/vgem_drm.h

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index 3f4c7b842028..bfcdea1330e6 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,4 @@
 ccflags-y := -Iinclude/drm
-vgem-y := vgem_drv.o
+vgem-y := vgem_drv.o vgem_fence.o

 obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index d7f962068ad0..c16e9c47c4da 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -84,6 +84,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = {
.close = drm_gem_vm_close,
 };

+static int vgem_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile;
+   int ret;
+
+   vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
+   if (!vfile)
+   return -ENOMEM;
+
+   file->driver_priv = vfile;
+
+   ret = vgem_fence_open(vfile);
+   if (ret) {
+   kfree(vfile);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile = file->driver_priv;
+
+   vgem_fence_close(vfile);
+   kfree(vfile);
+}
+
 /* ioctls */

 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
@@ -165,6 +193,8 @@ unref:
 }

 static struct drm_ioctl_desc vgem_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
@@ -287,9 +317,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,

 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .open   = vgem_open,
+   .preclose   = vgem_preclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
+   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops   = _driver_fops,

.dumb_create= vgem_gem_dumb_create,
@@ -344,5 +377,6 @@ module_init(vgem_init);
 module_exit(vgem_exit);

 MODULE_AUTHOR("Red Hat, Inc.");
+MODULE_AUTHOR("Intel Corporation");
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index 988cbaae7588..88ce21010e28 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -32,9 +32,27 @@
 #include 
 #include 

+#include 
+
+struct vgem_file {
+   struct idr fence_idr;
+   struct mutex fence_mutex;
+   u64 fence_context;
+   atomic_t fence_seqno;
+};
+
 #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
 struct drm_vgem_gem_object {
struct drm_gem_object base;
 };

+int vgem_fence_open(struct vgem_file *file);
+int vgem_fence_attach_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+int vgem_fence_signal_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+void vgem_fence_close(struct vgem_file *file);
+
 #endif
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
new file mode 100644
index ..46130e4a3506
--- /dev/null
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -0,0 +1,217 @@
+/*
+ * Copyright 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software")
+ * to deal in the 

[Bug 96620] build failure in igt_fb.c due to missing inttypes.h

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

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

yann  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs at lists.freede |dri-devel at 
lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT
 QA Contact|intel-gfx-bugs at lists.freede |
   |sktop.org   |

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

[Bug 96618] include headers that define major/minor/makedev funcs

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

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

yann  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs at lists.freede |dri-devel at 
lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT
 QA Contact|intel-gfx-bugs at lists.freede |
   |sktop.org   |

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

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

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

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

Christian König  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Christian König  ---
Yeah that is a known issue. Big endian systems are not really supported by the
hardware any more.

Because of this we would need to add manual byte swapping in the userspace
driver and nobody had the time yet to do so.

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

[Bug 96622] [radeonsi] "Dreamfall Chapters: The longest Journey" shows visual corruption

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

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

--- Comment #1 from Nicolai Hähnle  ---
Thanks for opening the separate report. Can you create an apitrace that shows
the visual corruption?

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

[PATCH v4.1 4/4] drm: rcar: use generic code for managing zpos plane property

[Laurent Pinchart]

From: Benjamin Gaignard 

version 4:
fix null pointer issue while setting zpos in plane reset function

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 
Signed-off--by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 --
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 13 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  2 --
 7 files changed, 7 insertions(+), 27 deletions(-)

Hi Benjamin,

(Trimming down the CC list of bit as most people are not interested in the
rcar-du-drm details)

I've rebased your zpos series on top of

git://linuxtv.org/media_tree.git vsp1

that includes two patches for the rcar-du-drm driver that conflict with your
series. The branch will be pushed as-is to Linus in v4.8 by Mauro, and can
thus be merged by Dave in his tree. This patch is the result of the rebase.

I haven't added my Tested-by tag yet as patch 1/4 in your series causes issues
with rcar-du-drm. I'll retest the whole series when a fix will be available.

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda736f9..28d2cb633c22 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467d96cf..c843c3134498 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 86c109b16876..6a99959ee76c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca870cc..dc9bb96241af 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b25dbfa..8b91dd3a46e4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 

[PATCH v4 1/4] drm: add generic zpos property

[Laurent Pinchart]

Hi Benjamin,

Thank you for the patch.

Could you please reply to Ville's comment to v1 of this patch (posted on April 
the 25th) ?

Please also see below for additional comments.

On Monday 13 Jun 2016 11:21:23 Benjamin Gaignard wrote:
> version 4:
> - make sure that normalized zpos value is stay
>   in the defined property range and warn user if not
> 
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 
> ---
>  Documentation/DocBook/gpu.tmpl  |  10 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic.c|   4 +
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 230 +
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  30 +
>  7 files changed, 284 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c

[snip]

> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> new file mode 100644
> index 000..9a5361a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -0,0 +1,230 @@

[snip]

> +/**
> + * drm_atomic_helper_crtc_normalize_zpos - calculate normalized zpos values
> + * @crtc: crtc with planes, which have to be considered for normalization
> + * @crtc_state: new atomic state to apply
> + *
> + * This function checks new states of all planes assigned to given crtc and
> + * calculates normalized zpos value for them. Planes are compared first by
> their
> + * zpos values, then by plane id (if zpos equals). Plane with lowest zpos
> value
> + * is at the bottom. The plane_state->normalized_zpos is then filled with
> unique
> + * values from 0 to number of active planes in crtc minus one.
> + *
> + * RETURNS
> + * Zero for success or -errno
> + */
> +int drm_atomic_helper_crtc_normalize_zpos(struct drm_crtc *crtc,
> +   struct drm_crtc_state *crtc_state)
> +{
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_device *dev = crtc->dev;
> + int total_planes = dev->mode_config.num_total_plane;
> + struct drm_plane_state **states;
> + struct drm_plane *plane;
> + int i, zpos, n = 0;
> + int ret = 0;
> +
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
> +  crtc->base.id, crtc->name);
> +
> + states = kmalloc_array(total_planes, sizeof(*states), GFP_TEMPORARY);
> + if (!states)
> + return -ENOMEM;
> +
> + /*
> +  * Normalization process might create new states for planes which
> +  * normalized_zpos has to be recalculated.
> +  */
> + drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask) {
> + struct drm_plane_state *plane_state =
> + drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto done;
> + }
> + states[n++] = plane_state;
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] processing zpos value %d\n",
> +  plane->base.id, plane->name,
> +  plane_state->zpos);
> + }
> +
> + sort(states, n, sizeof(*states), drm_atomic_state_zpos_cmp, NULL);
> +
> + for (i = 0, zpos = 0; i < n; i++, zpos++) {
> + plane = states[i]->plane;
> +
> + zpos = max_t(int, zpos, states[i]->zpos);
> +
> + WARN_ON(zpos > plane->zpos_property->values[1]);

This crashes if the plane doesn't have a zpos property. The simplest fix is to 
write the check as

WARN_ON(plane->zpos_property &&
zpos > plane->zpos_property->values[1]);

but I wonder how we should handle drivers that instantiate a zpos property for 
a subdev of the planes 

[Bug 96626] New account request

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

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

--- Comment #1 from Edward O'Callaghan  ---
Created attachment 124652
  --> https://bugs.freedesktop.org/attachment.cgi?id=124652=edit
SSH key

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

[Bug 96626] New account request

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

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

Bug ID: 96626
   Summary: New account request
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: funfunctor at folklore1984.net
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 124651
  --> https://bugs.freedesktop.org/attachment.cgi?id=124651=edit
GPG key

I would like to request an account with commit access to Mesa.

Real name: Edward O'Callaghan
Address: funfunctor at folklore1984.net
Preferred username: funfunctor

I could not connect to subkeys.pgp.net, but my key should be visible from
pgp.mit.edu.

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

[Bug 95015] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

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

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

--- Comment #8 from j.ribeirovega at outlook.com ---
I can confirm the exact same error with a PowerMac G5 Quad, only difference is
I have an AMD TURKS card. Card works in all slots except the x16 one.

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

[Bug 93727] [Regression] [r600g] Core profile is 3.2 instead of 3.3 in Big Endian PPC

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

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

--- Comment #2 from j.ribeirovega at outlook.com ---
Created attachment 124650
  --> https://bugs.freedesktop.org/attachment.cgi?id=124650=edit
glxinfo for mesa 11.2.0

Bug remains on mesa 11.2.0 on ubuntu 16.04.

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

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

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

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

Bug ID: 96625
   Summary: GPU lockup when using r600g VDPAU on powerpc
   Product: DRI
   Version: unspecified
  Hardware: PowerPC
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: j.ribeirovega at outlook.com

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

I installed a Radeon HD6670 on a PowerMac G5 Quad, hoping to use VDPAU to play
videos. 

When using mpv with opengl and vdpau hwdec and testing with a 720p sample from
samplevideos the gpu locks up and I am forced to reboot.

Attached dmesg after crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: