[lkp-robot] [lib/rbtree,drm/mm] 3e6e51217d: WARNING:at_lib/stackdepot.c:#depot_save_stack

2017-12-06 Thread kernel test robot

FYI, we noticed the following commit (built with gcc-7):

commit: 3e6e51217dd14dcda10d4bc9a38b1440e2d42c14 ("lib/rbtree,drm/mm: Add 
rbtree_replace_node_cached()")
git://anongit.freedesktop.org/drm-intel topic/core-for-CI

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 978de04a3c | 3e6e51217d |
+---+++
| boot_successes| 46 | 0  |
| boot_failures | 0  | 8  |
| WARNING:at_lib/stackdepot.c:#depot_save_stack | 0  | 8  |
| RIP:depot_save_stack  | 0  | 8  |
| BUG:kernel_hang_in_test_stage | 0  | 4  |
+---+++



[  278.198833] WARNING: CPU: 0 PID: 1 at lib/stackdepot.c:119 
depot_save_stack+0x22e/0x353
[  278.10] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.15.0-rc2-5-g3e6e512 #1
[  278.10] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  278.10] task: 9f2da405 task.stack: 18ee505d
[  278.10] RIP: 0010:depot_save_stack+0x22e/0x353
[  278.10] RSP: :88001f5bb9d8 EFLAGS: 00010086
[  278.10] RAX: 0022 RBX: ae4fc5be RCX: 88001f5a8000
[  278.10] RDX: 00221f5a8000 RSI: 810eb77c RDI: 0093
[  278.10] RBP: 0020 R08: e272d5c3 R09: 0004
[  278.10] R10:  R11: 65e7cb07 R12: 000fc5be
[  278.10] R13: 88001f5bba30 R14:  R15: 0286
[  278.10] FS:  () GS:81e36000() 
knlGS:
[  278.10] CS:  0010 DS:  ES:  CR0: 80050033
[  278.10] CR2:  CR3: 01e11000 CR4: 06b0
[  278.10] Call Trace:
[  278.10]  ? save_stack+0x7c/0x89
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? drm_mm_interval_tree_augment_rotate+0x23/0x2a
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? rb_erase+0x146/0x270
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_one_initcall+0x9d/0x158
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? kernel_init_freeable+0x11c/0x1cc
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? kernel_init+0x10/0x13d
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? ret_from_fork+0x24/0x30
[  278.10] Code: 8d 50 01 81 fa ff 1f 00 00 7e 27 80 3d 52 04 c0 00 00 0f 
85 fd 00 00 00 48 c7 c7 e2 9e d0 81 c6 05 3e 04 c0 00 01 e8 f1 53 d7 ff <0f> ff 
e9 e3 00 00 00 83 c0 02 89 15 64 7c 6d 01 48 c7 05 4d 7c 
[  278.10] ---[ end trace 4dd271b4182c6be2 ]---


To reproduce:

git 

Re: [PATCH v4 0/9] drm/i915: Implement HDCP

2017-12-06 Thread Ramalingam C

Sean,

Could you please share the level of functional testing is done on this 
code? like with Receiver/Repeaters and port type tested (DP/HDMI/DP over 
USB TypeC ?)


Whether Compliance test is attempted on this code?

Thanks

-Ram

On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

Welcome to version 4 of the patchset. I think we're nearing the finish line
(hopefully) now. This set addresses the review feedback from v3. I applied some
R-b's from v3 review, and converted others to Cc since other changes were made
to the patch, and I didn't want to speak for reviewers.

Thanks for all the review feedback!

Sean

Sean Paul (9):
   drm: Fix link-status kerneldoc line lengths
   drm/i915: Add more control to wait_for routines
   drm: Add Content Protection property
   drm: Add some HDCP related #defines
   drm/i915: Add HDCP framework + base implementation
   drm/i915: Make use of indexed write GMBUS feature
   drm/i915: Add function to output Aksv over GMBUS
   drm/i915: Implement HDCP for HDMI
   drm/i915: Implement HDCP for DisplayPort

  drivers/gpu/drm/drm_atomic.c |   8 +
  drivers/gpu/drm/drm_connector.c  |  87 -
  drivers/gpu/drm/drm_sysfs.c  |   1 +
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_drv.h  |   1 +
  drivers/gpu/drm/i915/i915_reg.h  |  85 
  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
  drivers/gpu/drm/i915/intel_ddi.c |  36 ++
  drivers/gpu/drm/i915/intel_display.c |   4 +
  drivers/gpu/drm/i915/intel_dp.c  | 244 +++-
  drivers/gpu/drm/i915/intel_drv.h | 106 -
  drivers/gpu/drm/i915/intel_hdcp.c| 735 +++
  drivers/gpu/drm/i915/intel_hdmi.c| 250 
  drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
  drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
  drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
  include/drm/drm_connector.h  |  16 +
  include/drm/drm_dp_helper.h  |  17 +
  include/drm/drm_hdcp.h   |  56 +++
  include/uapi/drm/drm_mode.h  |   4 +
  20 files changed, 1728 insertions(+), 43 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
  create mode 100644 include/drm/drm_hdcp.h



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


Re: [PATCH v4 4/9] drm: Add some HDCP related #defines

2017-12-06 Thread Ramalingam C

Looks Good to me.

Reviewed-by: Ramalingam C 

-Ram

On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.

Changes in v2:
- drm_hdcp.h gets MIT license (Daniel)
Changes in v3:
- None
Changes in v4:
- None

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
  include/drm/drm_dp_helper.h | 17 ++
  include/drm/drm_hdcp.h  | 56 +
  2 files changed, 73 insertions(+)
  create mode 100644 include/drm/drm_hdcp.h

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8b9ac321c3bd..4b2640d54c70 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -815,6 +815,23 @@
  #define DP_CEC_TX_MESSAGE_BUFFER   0x3020
  #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
  
+#define DP_AUX_HDCP_BKSV		0x68000

+#define DP_AUX_HDCP_RI_PRIME   0x68005
+#define DP_AUX_HDCP_AKSV   0x68007
+#define DP_AUX_HDCP_AN 0x6800C
+#define DP_AUX_HDCP_V_PRIME(h) (0x68014 + h * 4)
+#define DP_AUX_HDCP_BCAPS  0x68028
+# define DP_BCAPS_REPEATER_PRESENT BIT(1)
+# define DP_BCAPS_HDCP_CAPABLE BIT(0)
+#define DP_AUX_HDCP_BSTATUS0x68029
+# define DP_BSTATUS_REAUTH_REQ BIT(3)
+# define DP_BSTATUS_LINK_FAILURE   BIT(2)
+# define DP_BSTATUS_R0_PRIME_READY BIT(1)
+# define DP_BSTATUS_READY  BIT(0)
+#define DP_AUX_HDCP_BINFO  0x6802A
+#define DP_AUX_HDCP_KSV_FIFO   0x6802C
+#define DP_AUX_HDCP_AINFO  0x6803B
+
  /* DP 1.2 Sideband message defines */
  /* peer device type - DP 1.2a Table 2-92 */
  #define DP_PEER_DEVICE_NONE   0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index ..c9b2484240d4
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Sean Paul 
+ */
+
+#ifndef _DRM_HDCP_H_INCLUDED_
+#define _DRM_HDCP_H_INCLUDED_
+
+/* Period of hdcp checks (to ensure we're still authenticated) */
+#define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+
+/* Shared lengths/masks between HDMI/DVI/DisplayPort */
+#define DRM_HDCP_AN_LEN8
+#define DRM_HDCP_BSTATUS_LEN   2
+#define DRM_HDCP_KSV_LEN   5
+#define DRM_HDCP_RI_LEN2
+#define DRM_HDCP_V_PRIME_PART_LEN  4
+#define DRM_HDCP_V_PRIME_NUM_PARTS 5
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+
+/* Slave address for the HDCP registers in the receiver */
+#define DRM_HDCP_DDC_ADDR  0x3A
+
+/* HDCP register offsets for HDMI/DVI devices */
+#define DRM_HDCP_DDC_BKSV  0x00
+#define DRM_HDCP_DDC_RI_PRIME  0x08
+#define DRM_HDCP_DDC_AKSV  0x10
+#define DRM_HDCP_DDC_AN0x18
+#define DRM_HDCP_DDC_V_PRIME(h)(0x20 + h * 4)
+#define DRM_HDCP_DDC_BCAPS 0x40
+#define  DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT   BIT(6)
+#define  DRM_HDCP_DDC_BCAPS_KSV_FIFO_READY BIT(5)
+#define DRM_HDCP_DDC_BSTATUS   0x41
+#define DRM_HDCP_DDC_KSV_FIFO  0x43
+
+#endif


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


Re: [PATCH v4 5/9] drm/i915: Add HDCP framework + base implementation

2017-12-06 Thread Ramalingam C
As v3 implementation removes the mode set from the path of HDCP state 
change,


IMO that would have been preferred until we have the ville's changes 
mentioned by daniel.


Now once again modeset is brought back :(


And have we already thought about holding the modeset lock for 5+ Sec 
for HDCP authentication completion?


we might want to move the hdcp authentication itself to a deferred work, 
just to return the atomic_commit_tail call soon...


Of course even if this change is preferred, can be planned for phase2 too...


With this change looks good to me.

Reviewed-by: Ramalingam C 

--Ram

On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)
Changes in v4:
- Remove SKL_ prefix from most register names (Daniel)
- Move enable/disable back to modeset path (Daniel)
- s/get_random_long/get_random_u32/ (Daniel)
- Remove mode_config.mutex lock in prop_work (Daniel)
- Add intel_hdcp_init to handle init of conn components (Daniel)
- Actually check return value of attach_property
- Check Bksv is valid before trying to authenticate (Ram)

Cc: Chris Wilson 
Cc: Ramalingam C 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_reg.h  |  83 
  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
  drivers/gpu/drm/i915/intel_ddi.c |   7 +
  drivers/gpu/drm/i915/intel_display.c |   4 +
  drivers/gpu/drm/i915/intel_drv.h |  85 
  drivers/gpu/drm/i915/intel_hdcp.c| 735 +++
  7 files changed, 917 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42bc8bd4ff06..3facea4eefdb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,6 +107,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..4d66651219e3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8034,6 +8034,7 @@ enum {
  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
  #define   SKL_PCODE_CDCLK_CONTROL 0x7
  #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
  #define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8335,6 +8336,88 @@ enum skl_power_gate {
  #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
  #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
  
+

+/* HDCP Key Registers */
+#define HDCP_KEY_CONF  _MMIO(0x66c00)
+#define  HDCP_AKSV_SEND_TRIGGERBIT(31)
+#define  HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  HDCP_FUSE_ERROR   BIT(6)
+#define  HDCP_FUSE_DONEBIT(5)
+#define  HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  HDCP_KEY_LOAD_DONEBIT(0)
+#define HDCP_AKSV_LO   _MMIO(0x66c10)
+#define HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define HDCP_REP_CTL   _MMIO(0x66d00)
+#define  HDCP_DDIB_REP_PRESENT BIT(30)
+#define  HDCP_DDIA_REP_PRESENT BIT(29)
+#define  HDCP_DDIC_REP_PRESENT BIT(28)
+#define  HDCP_DDID_REP_PRESENT BIT(27)
+#define  HDCP_DDIF_REP_PRESENT BIT(26)
+#define  HDCP_DDIE_REP_PRESENT BIT(25)
+#define  HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  

Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Chunming Zhou

Looks ok to me, Reviewed-by: Chunming Zhou 


On 2017年12月07日 00:49, Lucas Stach wrote:

Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Thanks,
Lucas

Lucas Stach (2):
   drm: move amd_gpu_scheduler into common location
   drm/sched: move fence slab handling to module init/exit

  drivers/gpu/drm/Kconfig|   5 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
  drivers/gpu/drm/scheduler/Makefile |   4 +
  .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 ++---
  drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
  include/drm/gpu_scheduler.h| 173 
  .../drm/gpu_scheduler_trace.h  |  14 +-
  .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
  35 files changed, 529 insertions(+), 523 deletions(-)
  delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
  create mode 100644 drivers/gpu/drm/scheduler/Makefile
  rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
  rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
  create mode 100644 include/drm/gpu_scheduler.h
  rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
include/drm/gpu_scheduler_trace.h (82%)
  rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h (95%)



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


Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support

2017-12-06 Thread Chen-Yu Tsai
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
 wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 +++-
>  drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 ++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 238 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  29 -
>  5 files changed, 467 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 82a6ac57fbe3..2b37a6abbb1d 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -15,6 +15,7 @@ sun8i-mixer-y += sun8i_mixer.o 
> sun8i_ui_layer.o \
>
>  sun4i-tcon-y   += sun4i_crtc.o
>  sun4i-tcon-y   += sun4i_dotclock.o
> +sun4i-tcon-y   += sun4i_lvds.o
>  sun4i-tcon-y   += sun4i_tcon.o
>  sun4i-tcon-y   += sun4i_rgb.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index ..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> +   struct drm_connectorconnector;
> +   struct drm_encoder  encoder;
> +
> +   struct sun4i_tcon   *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> +   return container_of(connector, struct sun4i_lvds,
> +   connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> +   return container_of(encoder, struct sun4i_lvds,
> +   encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds =
> +   drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> +   .get_modes  = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   drm_panel_detach(tcon->panel);
> +   drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> +   .fill_modes = drm_helper_probe_single_connector_modes,
> +   .destroy= sun4i_lvds_connector_destroy,
> +   .reset  = drm_atomic_helper_connector_reset,
> +   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_prepare(tcon->panel);
> +   drm_panel_enable(tcon->panel);
> +   }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_disable(tcon->panel);
> +   drm_panel_unprepare(tcon->panel);
> +   }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> +   .disable= sun4i_lvds_encoder_disable,
> +   .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> +   .destroy= 

[Bug 95306] Random Blank(black) screens on "Carrizo"

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #74 from Kelly Anderson  ---
Initial results with 4.15rc2 looks good. In thirty minutes or so of usage no
black screens.  with 4.14.4 it would have black screened by now.

Kernel config snippet:

CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_PRE_VEGA=y
# CONFIG_DRM_AMD_DC_FBC is not set
CONFIG_DRM_AMD_DC_DCN1_0=y
# CONFIG_DEBUG_KERNEL_DC is not set

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 8/9] drm/i915: Implement HDCP for HDMI

2017-12-06 Thread Ramalingam C



On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Changes in v2:
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
Changes in v4:
- Remove SKL_ prefix from most register names (Daniel)
- Wrap sanity checks in WARN_ON (Daniel)
- Consolidate the enable/disable functions into one toggle fn
- Use intel_hdcp_init (Daniel)

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/i915_reg.h   |   1 +
  drivers/gpu/drm/i915/intel_ddi.c  |  29 +
  drivers/gpu/drm/i915/intel_drv.h  |   4 +
  drivers/gpu/drm/i915/intel_hdmi.c | 250 ++
  4 files changed, 284 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35bcc6c308f3..8e4e810b81ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8450,6 +8450,7 @@ enum skl_power_gate {
  #define  TRANS_DDI_EDP_INPUT_A_ONOFF  (4<<12)
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
  #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
  #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ab727f0b2696..f181f5840268 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1615,6 +1615,35 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
  }
  
+int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,

+bool enable)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (WARN_ON(!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain)))
+   return -ENXIO;
+
+   if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, ))) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   if (enable)
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   else
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
  bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
  {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3351785af867..3a5393866ed2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1379,6 +1379,10 @@ void intel_ddi_compute_min_voltage_level(struct 
drm_i915_private *dev_priv,
  u32 bxt_signal_levels(struct intel_dp *intel_dp);
  uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
  u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
+int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+bool enable);
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);


Above two declarations are left over!? You might want to remove it..

  
  unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,

   int plane, unsigned int height);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..382fd443fd0d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "intel_drv.h"
  #include 
@@ -873,6 +874,248 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
  }
  
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,

+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+  

Re: [PATCH v4 9/9] drm/i915: Implement HDCP for DisplayPort

2017-12-06 Thread Ramalingam C

Thanks for handling the reauth req from downstream.

you might want to fix the missed single occurance of "//"


On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.

Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the rest
of it.

Changes in v2:
- Moved intel_hdcp_check_link out of intel_dp_check_link and only call
   it on short pulse. Since intel_hdcp_check_link does its own locking,
   this ensures we don't deadlock when intel_dp_check_link is called
   holding connection_mutex.
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
Changes in v4:
- Use intel_hdcp_init (Daniel)
- Check for reauth requests in check_link (Ram)

Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/intel_dp.c | 244 ++--
  1 file changed, 237 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c603d4c903e1..0ec8b23d0332 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -36,7 +36,9 @@
  #include 
  #include 
  #include 
+#include 
  #include 
+#include 
  #include "intel_drv.h"
  #include 
  #include "i915_drv.h"
@@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
  }
  
+static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,

+ bool has_aux_irq,
+ int send_bytes,
+ uint32_t aux_clock_divider,
+ bool aksv_write)
+{
+   uint32_t val = 0;
+
+   if (aksv_write) {
+   send_bytes += 5;
+   val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+   }
+
+   return val | intel_dp->get_aux_send_ctl(intel_dp,
+   has_aux_irq,
+   send_bytes,
+   aux_clock_divider);
+}
+
  static int
  intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
-   uint8_t *recv, int recv_size)
+   uint8_t *recv, int recv_size, bool aksv_write)
  {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
  
  	while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, clock++))) {

-   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
- send_bytes,
- aux_clock_divider);
+   u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
+has_aux_irq,
+send_bytes,
+aux_clock_divider,
+aksv_write);
  
  		/* Must try at least 3 times according to DP spec */

for (try = 0; try < 5; try++) {
@@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (msg->buffer)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
  
-		ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);

+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
  
@@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)

if (WARN_ON(rxsize > 20))
return -E2BIG;
  
-		ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);

+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -4981,6 +5005,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
  }
  
+static

+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
+   uint8_t txbuf[4], rxbuf[2], reply = 0;
+   

Re: [PATCH v3 3/9] drm: Add Content Protection property

2017-12-06 Thread Ramalingam C



On Wednesday 06 December 2017 09:56 PM, Sean Paul wrote:

I'd rather keep the property as-is and expose an HDCP version property
alongside it (or perhaps something more elaborate that includes bksv and the
downstream bksvs). The reason I prefer that is it will also cover the 1.2 vs 1.4
difference that is a more immediate need.

HDCP specification wants to differentiate 2.2 vs <2.2 as 2.2 is not a backward 
compatible.
Why do we need to differentiate 1.2 and 1.4? Any use case?


Someone on the Chrome side asked me to surface the version, apparently
they care about 1.2 vs 1.4.

Sean, if you can get the reason for differentiating v1.2 and v1.4 at 
chrome, it will be educative info. - Thanks


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


Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Dieter Nützel

For the series:

Tested-by: Dieter Nützel 

on RX580 8GB

with UH, UV, Blender 2.79, smoketest (Vulkan), glmark2 (parallel with 
OpenCL (/opt/opencl-example>./run_tests.sh))


Dieter

Am 06.12.2017 17:49, schrieb Lucas Stach:

Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Thanks,
Lucas

Lucas Stach (2):
  drm: move amd_gpu_scheduler into common location
  drm/sched: move fence slab handling to module init/exit

 drivers/gpu/drm/Kconfig|   5 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
 drivers/gpu/drm/scheduler/Makefile |   4 +
 .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 
++---

 drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
 include/drm/gpu_scheduler.h| 173 
 .../drm/gpu_scheduler_trace.h  |  14 +-
 .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
 35 files changed, 529 insertions(+), 523 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
 create mode 100644 drivers/gpu/drm/scheduler/Makefile
 rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
 rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
 create mode 100644 include/drm/gpu_scheduler.h
 rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h =>
include/drm/gpu_scheduler_trace.h (82%)
 rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h 
(95%)

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


Re: [PATCH v3 10/15] ARM: dts: sun8i: a83t: Add display pipeline

2017-12-06 Thread Chen-Yu Tsai
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
 wrote:
> The display pipeline on the A83T is mainly composed of the mixers and
> TCONs, plus various encoders.
>
> Let's add the first mixer and TCON to the DTSI since the only board I have
> can use only the LVDS output on the first TCON. The other parts will be
> added eventually.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties

2017-12-06 Thread Chen-Yu Tsai
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
 wrote:
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
>
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++-
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 50cc72ee1168..d4259a4f5171 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -121,6 +121,14 @@ Required properties:
>  On SoCs other than the A33 and V3s, there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
>
> +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
> +need one more reset line:
> +   - 'lvds': The reset line driving the LVDS logic
> +
> +And on the SoCs newer than the A31 (sun6i and sun8i families), you
> +need one more clock line:
> +   - 'lvds-pll': The PLL that can be used to drive the LVDS clock

Is this referring to TCON0_LVDS_Clk_Sel, which can use the MIPI PLL
on the A33? Maybe the description should be more clear, like:

  - 'lvds-alt': An alternative clock separate from the TCON
that can be used to drive the LVDS clock.

ChenYu

> +
>  DRC
>  ---
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline

2017-12-06 Thread Chen-Yu Tsai
On Thu, Dec 7, 2017 at 5:59 AM, Rob Herring  wrote:
> On Tue, Dec 05, 2017 at 04:10:16PM +0100, Maxime Ripard wrote:
>> The A83T has two video pipelines in parallel that looks quite similar to
>> the other SoCs.
>>
>> The video planes are handled through a controller called the mixer, and the
>> video signal is then passed to the timing controller (TCON).
>>
>> And while there is two instances of the mixers and TCONs, they have a
>> significant number of differences. The TCONs are quite easy to deal with,
>> one is supposed to generate TV (in the broader term, so including things
>> like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
>> while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
>> call them TCON-TV and TCON-LCD, which seems more appropriate.
>>
>> However, the mixers differ mostly by their capabilities, with some features
>> being available only in the first one, or the number of planes they expose,
>> but also through their register layout. And while the capabilities could be
>> represented as properties, the register layout differences would need to
>> express all the registers offsets as properties, which is usually quite
>> bad. Especially since documentation on that hardware block is close to
>> non-existant and we don't even have the list of all those registers in the
>> first place.
>>
>> So let's call them mixer 0 and 1 in our compatibles, even though the name
>> is pretty bad...
>>
>> At the moment, we only have tested the code on a board that has a single
>> display output, so we're leaving the tcon-tv and mixer1 out.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>
> Reviewed-by: Rob Herring 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 14/15] ARM: dts: sun8i: a711: Reinstate the PMIC compatible

2017-12-06 Thread Chen-Yu Tsai
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
 wrote:
> When we added the regulator support in commit 90c5d7cdae64 ("ARM: dts:
> sun8i: a711: Add regulator support"), we also dropped the PMIC's
> compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
> DTSI, it obviously wasn't probing anymore.
>
> Re-add it so that everything works again.
>
> Fixes: 90c5d7cdae64 ("ARM: dts: sun8i: a711: Add regulator support")
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm: clean up internally created framebuffer on CRTC disable

2017-12-06 Thread Gurchetan Singh
When a CRTC is disabled and we used an internally created framebuffer,
this patch disables the cursor plane and drops the reference that was
introduced when we called drm_internal_framebuffer_create.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/drm_crtc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e654116..d732cca4879f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -101,12 +101,19 @@ EXPORT_SYMBOL(drm_crtc_from_index);
  */
 int drm_crtc_force_disable(struct drm_crtc *crtc)
 {
+   struct drm_framebuffer *fb;
struct drm_mode_set set = {
.crtc = crtc,
};
 
WARN_ON(drm_drv_uses_atomic_modeset(crtc->dev));
 
+   if (crtc->cursor && crtc->cursor->fb && crtc->cursor->fb->internal) {
+   fb = crtc->cursor->fb;
+   drm_plane_force_disable(crtc->cursor);
+   drm_framebuffer_unreference(fb);
+   }
+
return drm_mode_set_config_internal();
 }
 EXPORT_SYMBOL(drm_crtc_force_disable);
-- 
2.13.5

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


[GIT PULL] exynos-drm-fixes

2017-12-06 Thread Inki Dae
Hi Dave,
   Just a regression fixup and several cleanups.

   Please kindly let me know if there is any problem.

   Thanks,
   Inki Dae

The following changes since commit bd3a3a2e92624942a143e485c83e641b2492d828:

  Merge tag 'drm-misc-fixes-2017-12-06' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2017-12-07 08:29:26 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v4.15-rc3

for you to fetch changes up to 1cd6ae355bb2092a6a511558334564cb1f4ffd43:

  drm/exynos: remove unnecessary function declaration (2017-12-07 10:34:40 
+0900)


- fix page fault issue due to using wrong device object in prime import.
- drop NONCONTIG flag without IOMMU support.
- remove unnecessary members and declaration.


Inki Dae (2):
  drm/exynos: remove unnecessary descrptions
  drm/exynos: remove unnecessary function declaration

Marek Szyprowski (2):
  drm/exynos: Fix dma-buf import
  drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

 drivers/gpu/drm/exynos/exynos_drm_drv.c | 46 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  5 
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.h |  2 ++
 4 files changed, 39 insertions(+), 29 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 04/11] drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-06 Thread Inki Dae


2017년 12월 06일 03:24에 Noralf Trønnes 이(가) 쓴 글:
> This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
> It can also use drm_fb_helper_output_poll_changed() as its
> .output_poll_changed callback.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Noralf Trønnes 
> Acked-by: Daniel Vetter 

Seems you missed my ACK,
http://www.spinics.net/lists/intel-gfx/msg146188.html

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 --
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
>  4 files changed, 3 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 82b72425a42f..2f2bd6e37e62 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -89,11 +90,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
> struct drm_file *file)
>   file->driver_priv = NULL;
>  }
>  
> -static void exynos_drm_lastclose(struct drm_device *dev)
> -{
> - exynos_drm_fbdev_restore_mode(dev);
> -}
> -
>  static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
>   .fault = exynos_drm_gem_fault,
>   .open = drm_gem_vm_open,
> @@ -140,7 +136,7 @@ static struct drm_driver exynos_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
> | DRIVER_ATOMIC | DRIVER_RENDER,
>   .open   = exynos_drm_open,
> - .lastclose  = exynos_drm_lastclose,
> + .lastclose  = drm_fb_helper_lastclose,
>   .postclose  = exynos_drm_postclose,
>   .gem_free_object_unlocked = exynos_drm_gem_free_object,
>   .gem_vm_ops = _drm_gem_vm_ops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 8208df56a88f..0faaf829f5bf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -205,7 +205,7 @@ static struct drm_mode_config_helper_funcs 
> exynos_drm_mode_config_helpers = {
>  
>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>   .fb_create = exynos_user_fb_create,
> - .output_poll_changed = exynos_drm_output_poll_changed,
> + .output_poll_changed = drm_fb_helper_output_poll_changed,
>   .atomic_check = exynos_atomic_check,
>   .atomic_commit = drm_atomic_helper_commit,
>  };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index dfb66ecf417b..132dd52d0ac7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -270,24 +270,6 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
>   private->fb_helper = NULL;
>  }
>  
> -void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
> -{
> - struct exynos_drm_private *private = dev->dev_private;
> -
> - if (!private || !private->fb_helper)
> - return;
> -
> - drm_fb_helper_restore_fbdev_mode_unlocked(private->fb_helper);
> -}
> -
> -void exynos_drm_output_poll_changed(struct drm_device *dev)
> -{
> - struct exynos_drm_private *private = dev->dev_private;
> - struct drm_fb_helper *fb_helper = private->fb_helper;
> -
> - drm_fb_helper_hotplug_event(fb_helper);
> -}
> -
>  void exynos_drm_fbdev_suspend(struct drm_device *dev)
>  {
>   struct exynos_drm_private *private = dev->dev_private;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> index 645d1bb7f665..b33847223a85 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> @@ -19,8 +19,6 @@
>  
>  int exynos_drm_fbdev_init(struct drm_device *dev);
>  void exynos_drm_fbdev_fini(struct drm_device *dev);
> -void exynos_drm_fbdev_restore_mode(struct drm_device *dev);
> -void exynos_drm_output_poll_changed(struct drm_device *dev);
>  void exynos_drm_fbdev_suspend(struct drm_device *drm);
>  void exynos_drm_fbdev_resume(struct drm_device *drm);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 5/9] drm/i915: Add HDCP framework + base implementation

2017-12-06 Thread Sean Paul
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)
Changes in v4:
- Remove SKL_ prefix from most register names (Daniel)
- Move enable/disable back to modeset path (Daniel)
- s/get_random_long/get_random_u32/ (Daniel)
- Remove mode_config.mutex lock in prop_work (Daniel)
- Add intel_hdcp_init to handle init of conn components (Daniel)
- Actually check return value of attach_property
- Check Bksv is valid before trying to authenticate (Ram)

Cc: Chris Wilson 
Cc: Ramalingam C 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_reg.h  |  83 
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_ddi.c |   7 +
 drivers/gpu/drm/i915/intel_display.c |   4 +
 drivers/gpu/drm/i915/intel_drv.h |  85 
 drivers/gpu/drm/i915/intel_hdcp.c| 735 +++
 7 files changed, 917 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42bc8bd4ff06..3facea4eefdb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,6 +107,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..4d66651219e3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8034,6 +8034,7 @@ enum {
 #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
 #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
 #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
 #define   SKL_PCODE_CDCLK_CONTROL  0x7
 #define SKL_CDCLK_PREPARE_FOR_CHANGE   0x3
 #define SKL_CDCLK_READY_FOR_CHANGE 0x1
@@ -8335,6 +8336,88 @@ enum skl_power_gate {
 #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + SKL_PG1)
 #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
 
+
+/* HDCP Key Registers */
+#define HDCP_KEY_CONF  _MMIO(0x66c00)
+#define  HDCP_AKSV_SEND_TRIGGERBIT(31)
+#define  HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  HDCP_FUSE_ERROR   BIT(6)
+#define  HDCP_FUSE_DONEBIT(5)
+#define  HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  HDCP_KEY_LOAD_DONEBIT(0)
+#define HDCP_AKSV_LO   _MMIO(0x66c10)
+#define HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define HDCP_REP_CTL   _MMIO(0x66d00)
+#define  HDCP_DDIB_REP_PRESENT BIT(30)
+#define  HDCP_DDIA_REP_PRESENT BIT(29)
+#define  HDCP_DDIC_REP_PRESENT BIT(28)
+#define  HDCP_DDID_REP_PRESENT BIT(27)
+#define  HDCP_DDIF_REP_PRESENT BIT(26)
+#define  HDCP_DDIE_REP_PRESENT BIT(25)
+#define  HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  HDCP_DDID_SHA1_M0 (4 << 20)
+#define  HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  HDCP_SHA1_BUSYBIT(16)
+#define  HDCP_SHA1_READY   BIT(17)
+#define  HDCP_SHA1_COMPLETEBIT(18)
+#define  HDCP_SHA1_V_MATCH BIT(19)
+#define  HDCP_SHA1_TEXT_32 (1 << 1)
+#define  HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  HDCP_SHA1_TEXT_24 (4 << 1)
+#define  HDCP_SHA1_TEXT_16 (5 << 1)
+#define  HDCP_SHA1_TEXT_8  (6 << 1)
+#define  HDCP_SHA1_TEXT_0  (7 << 1)

[PATCH v4 3/9] drm: Add Content Protection property

2017-12-06 Thread Sean Paul
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Changes in v2:
 - Pimp kerneldoc for content_protection_property (Daniel)
 - Drop sysfs attribute
Changes in v3:
 - None
Changes in v4:
- Changed kerneldoc to recommend userspace polling (Daniel)
- Changed kerneldoc to briefly describe how to attach the property (Daniel)

Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
---
 drivers/gpu/drm/drm_atomic.c|  8 +
 drivers/gpu/drm/drm_connector.c | 78 +
 drivers/gpu/drm/drm_sysfs.c |  1 +
 include/drm/drm_connector.h | 16 +
 include/uapi/drm/drm_mode.h |  4 +++
 5 files changed, 107 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da5585e201..676025d755b2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == connector->content_protection_property) {
+   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
+   return -EINVAL;
+   }
+   state->content_protection = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == connector->content_protection_property) {
+   *val = state->content_protection;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f14b48e6e839..769213cb53e3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
+{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
 /**
  * DOC: standard connector properties
  *
@@ -764,6 +771,41 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *  after modeset, the kernel driver may set this to "BAD" and issue a
  *  hotplug uevent. Drivers should update this value using
  *  drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ * This property is used by userspace to request the kernel protect future
+ * content communicated over the link. When requested, kernel will apply
+ * the appropriate means of protection (most often HDCP), and use the
+ * property to tell userspace the protection is active.
+ *
+ * Drivers can set this up by calling
+ * drm_connector_attach_content_protection_property() on initialization.
+ *
+ * The value of this property can be one of the following:
+ *
+ * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
+ * The link is not protected, content is transmitted in the clear.
+ * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
+ * Userspace has requested content protection, but the link is not
+ * currently protected. When in this state, kernel should enable
+ * Content Protection as soon as possible.
+ * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
+ * 

[PATCH v4 9/9] drm/i915: Implement HDCP for DisplayPort

2017-12-06 Thread Sean Paul
This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.

Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the rest
of it.

Changes in v2:
- Moved intel_hdcp_check_link out of intel_dp_check_link and only call
  it on short pulse. Since intel_hdcp_check_link does its own locking,
  this ensures we don't deadlock when intel_dp_check_link is called
  holding connection_mutex.
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
Changes in v4:
- Use intel_hdcp_init (Daniel)
- Check for reauth requests in check_link (Ram)

Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_dp.c | 244 ++--
 1 file changed, 237 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c603d4c903e1..0ec8b23d0332 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -36,7 +36,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
+static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
+ bool has_aux_irq,
+ int send_bytes,
+ uint32_t aux_clock_divider,
+ bool aksv_write)
+{
+   uint32_t val = 0;
+
+   if (aksv_write) {
+   send_bytes += 5;
+   val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+   }
+
+   return val | intel_dp->get_aux_send_ctl(intel_dp,
+   has_aux_irq,
+   send_bytes,
+   aux_clock_divider);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
-   uint8_t *recv, int recv_size)
+   uint8_t *recv, int recv_size, bool aksv_write)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
 
while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
clock++))) {
-   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
- send_bytes,
- aux_clock_divider);
+   u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
+has_aux_irq,
+send_bytes,
+aux_clock_divider,
+aksv_write);
 
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
@@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (msg->buffer)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (WARN_ON(rxsize > 20))
return -E2BIG;
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -4981,6 +5005,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
+   uint8_t txbuf[4], rxbuf[2], reply = 0;
+   ssize_t dpcd_ret;
+   int ret;
+
+   /* Output An first, that's easy */
+   dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux, DP_AUX_HDCP_AN,

[PATCH v4 6/9] drm/i915: Make use of indexed write GMBUS feature

2017-12-06 Thread Sean Paul
This patch enables the indexed write feature of the GMBUS to concatenate
2 consecutive messages into one. The criteria for an indexed write is
that both messages are writes, the first is length == 1, and the second
is length > 0. The first message is sent out by the GMBUS as the slave
command, and the second one is sent via the GMBUS FIFO as usual.

Changes in v3:
- Added to series
Changes in v4:
- Combine indexed reads and writes (Ville)

Cc: Daniel Vetter 
Suggested-by: Ville Syrjälä 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_i2c.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 49fdf09f9919..d78ce758fbfa 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg,
 
 static int
 gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
-  unsigned short addr, u8 *buf, unsigned int len)
+  unsigned short addr, u8 *buf, unsigned int len,
+  u32 gmbus1_index)
 {
unsigned int chunk_size = len;
u32 val, loop;
@@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 
I915_WRITE_FW(GMBUS3, val);
I915_WRITE_FW(GMBUS1,
- GMBUS_CYCLE_WAIT |
+ gmbus1_index | GMBUS_CYCLE_WAIT |
  (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
  (addr << GMBUS_SLAVE_ADDR_SHIFT) |
  GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
@@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 }
 
 static int
-gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
+u32 gmbus1_index)
 {
u8 *buf = msg->buf;
unsigned int tx_size = msg->len;
@@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg)
do {
len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
 
-   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
+   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
+gmbus1_index);
if (ret)
return ret;
 
@@ -431,21 +434,21 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
struct i2c_msg *msg)
 }
 
 /*
- * The gmbus controller can combine a 1 or 2 byte write with a read that
- * immediately follows it by using an "INDEX" cycle.
+ * The gmbus controller can combine a 1 or 2 byte write with another read/write
+ * that immediately follows it by using an "INDEX" cycle.
  */
 static bool
-gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
+gmbus_is_index_xfer(struct i2c_msg *msgs, int i, int num)
 {
return (i + 1 < num &&
msgs[i].addr == msgs[i + 1].addr &&
!(msgs[i].flags & I2C_M_RD) &&
(msgs[i].len == 1 || msgs[i].len == 2) &&
-   (msgs[i + 1].flags & I2C_M_RD));
+   msgs[i + 1].len > 0);
 }
 
 static int
-gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
+gmbus_index_xfer(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
 {
u32 gmbus1_index = 0;
u32 gmbus5 = 0;
@@ -462,7 +465,10 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
struct i2c_msg *msgs)
if (gmbus5)
I915_WRITE_FW(GMBUS5, gmbus5);
 
-   ret = gmbus_xfer_read(dev_priv, [1], gmbus1_index);
+   if (msgs[1].flags & I2C_M_RD)
+   ret = gmbus_xfer_read(dev_priv, [1], gmbus1_index);
+   else
+   ret = gmbus_xfer_write(dev_priv, [1], gmbus1_index);
 
/* Clear GMBUS5 after each index transfer */
if (gmbus5)
@@ -486,13 +492,13 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
 
for (; i < num; i += inc) {
inc = 1;
-   if (gmbus_is_index_read(msgs, i, num)) {
-   ret = gmbus_xfer_index_read(dev_priv, [i]);
-   inc = 2; /* an index read is two msgs */
+   if (gmbus_is_index_xfer(msgs, i, num)) {
+   ret = gmbus_index_xfer(dev_priv, [i]);
+   inc = 2; /* an index transmission is two msgs */
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, [i], 0);
} else {
-   ret = gmbus_xfer_write(dev_priv, [i]);
+   ret = gmbus_xfer_write(dev_priv, [i], 0);
}
 
if (!ret)
-- 
2.15.1.424.g9478a66081-goog


[PATCH v4 7/9] drm/i915: Add function to output Aksv over GMBUS

2017-12-06 Thread Sean Paul
Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.

The way we do this is to initiate an indexed write where the index is
the Aksv register offset. We write dummy values to GMBUS3 as if we were
sending the key, and the hardware slips in the "real" values when it
goes out.

Changes in v2:
- None
Changes in v3:
- Uses new index write feature (Ville)
Changes in v4:
- None

Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_i2c.c | 47 +---
 3 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..6b39081c5e53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4049,6 +4049,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
*dev_priv);
 extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
 extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 unsigned int pin);
+extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
 
 extern struct i2c_adapter *
 intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4d66651219e3..35bcc6c308f3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3043,6 +3043,7 @@ enum i915_power_well_id {
 # define GPIO_DATA_PULLUP_DISABLE  (1 << 13)
 
 #define GMBUS0 _MMIO(dev_priv->gpio_mmio_base + 0x5100) /* 
clock/port select */
+#define   GMBUS_AKSV_SELECT(1<<11)
 #define   GMBUS_RATE_100KHZ(0<<8)
 #define   GMBUS_RATE_50KHZ (1<<8)
 #define   GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d78ce758fbfa..318a68ea577e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -478,7 +479,8 @@ gmbus_index_xfer(struct drm_i915_private *dev_priv, struct 
i2c_msg *msgs)
 }
 
 static int
-do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
+do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
+ u32 gmbus0_source)
 {
struct intel_gmbus *bus = container_of(adapter,
   struct intel_gmbus,
@@ -488,7 +490,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
int ret = 0;
 
 retry:
-   I915_WRITE_FW(GMBUS0, bus->reg0);
+   I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
 
for (; i < num; i += inc) {
inc = 1;
@@ -606,7 +608,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
if (ret < 0)
bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
} else {
-   ret = do_gmbus_xfer(adapter, msgs, num);
+   ret = do_gmbus_xfer(adapter, msgs, num, 0);
if (ret == -EAGAIN)
bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
}
@@ -616,6 +618,45 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
return ret;
 }
 
+int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
+{
+   struct intel_gmbus *bus = container_of(adapter, struct intel_gmbus,
+  adapter);
+   struct drm_i915_private *dev_priv = bus->dev_priv;
+   int ret;
+   u8 cmd = DRM_HDCP_DDC_AKSV ;
+   u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = sizeof(cmd),
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = sizeof(buf),
+   .buf = buf,
+   }
+   };
+
+   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
+   mutex_lock(_priv->gmbus_mutex);
+
+   /*
+* In order to output Aksv to the receiver, use an indexed write to
+* pass the i2c command, and tell GMBUS to use the HW-provided value
+* instead of sourcing GMBUS3 for the data.
+*/
+   ret = do_gmbus_xfer(adapter, msgs, ARRAY_SIZE(msgs), GMBUS_AKSV_SELECT);
+
+   

[PATCH v4 8/9] drm/i915: Implement HDCP for HDMI

2017-12-06 Thread Sean Paul
This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Changes in v2:
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
Changes in v4:
- Remove SKL_ prefix from most register names (Daniel)
- Wrap sanity checks in WARN_ON (Daniel)
- Consolidate the enable/disable functions into one toggle fn
- Use intel_hdcp_init (Daniel)

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ddi.c  |  29 +
 drivers/gpu/drm/i915/intel_drv.h  |   4 +
 drivers/gpu/drm/i915/intel_hdmi.c | 250 ++
 4 files changed, 284 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35bcc6c308f3..8e4e810b81ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8450,6 +8450,7 @@ enum skl_power_gate {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
 #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ab727f0b2696..f181f5840268 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1615,6 +1615,35 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
 }
 
+int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+bool enable)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (WARN_ON(!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain)))
+   return -ENXIO;
+
+   if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, ))) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   if (enable)
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   else
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
 {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3351785af867..3a5393866ed2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1379,6 +1379,10 @@ void intel_ddi_compute_min_voltage_level(struct 
drm_i915_private *dev_priv,
 u32 bxt_signal_levels(struct intel_dp *intel_dp);
 uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
 u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
+int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+bool enable);
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);
 
 unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,
   int plane, unsigned int height);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..382fd443fd0d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "intel_drv.h"
 #include 
@@ -873,6 +874,248 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
 }
 
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,
+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+  

[PATCH v4 2/9] drm/i915: Add more control to wait_for routines

2017-12-06 Thread Sean Paul
This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
 - need the value of the register after the wait_for
 - run arbitrary operation for the read portion

This patch also chooses the correct sleep function (based on
timers-howto.txt) for the polling interval the caller specifies.

Changes in v2:
- Added to the series
Changes in v3:
- Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
- Removed msleep option
Changes in v4:
- Removed ; for OP in _wait_for (Chris)
- Moved reg_value definition above ret (Chris)

Suggested-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Reviewed-by: Chris Wilson 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_drv.h| 17 ++---
 drivers/gpu/drm/i915/intel_uncore.c | 23 ---
 drivers/gpu/drm/i915/intel_uncore.h | 14 +-
 3 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 64426d3e078e..cbfe306cc5b7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,20 +41,21 @@
 #include 
 
 /**
- * _wait_for - magic (register) wait macro
+ * __wait_for - magic wait macro
  *
- * Does the right thing for modeset paths when run under kdgb or similar atomic
- * contexts. Note that it's important that we check the condition again after
- * having timed out, since the timeout could be due to preemption or similar 
and
- * we've never had a chance to check the condition before the timeout.
+ * Macro to help avoid open coding check/wait/timeout patterns. Note that it's
+ * important that we check the condition again after having timed out, since 
the
+ * timeout could be due to preemption or similar and we've never had a chance 
to
+ * check the condition before the timeout.
  */
-#define _wait_for(COND, US, Wmin, Wmax) ({ \
+#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
int ret__;  \
might_sleep();  \
for (;;) {  \
bool expired__ = time_after(jiffies, timeout__);\
+   OP; \
if (COND) { \
ret__ = 0;  \
break;  \
@@ -70,7 +71,9 @@
ret__;  \
 })
 
-#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
+#define _wait_for(COND, US, Wmin, Wmax)__wait_for(, (COND), (US), 
(Wmin), \
+  (Wmax))
+#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b4621271e7a2..2a3a77d398a0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
 }
 
 /**
- * intel_wait_for_register - wait until register matches expected state
+ * __intel_wait_for_register - wait until register matches expected state
  * @dev_priv: the i915 device
  * @reg: the register to read
  * @mask: mask to apply to register value
  * @value: expected value
- * @timeout_ms: timeout in millisecond
+ * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
+ * @slow_timeout_ms: slow timeout in millisecond
+ * @out_value: optional placeholder to hold registry value
  *
  * This routine waits until the target register @reg contains the expected
  * @value after applying the @mask, i.e. it waits until ::
@@ -1786,14 +1788,17 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
  *
  * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
  */
-int intel_wait_for_register(struct drm_i915_private *dev_priv,
+int __intel_wait_for_register(struct drm_i915_private *dev_priv,
i915_reg_t reg,
u32 mask,
u32 value,
-   unsigned int timeout_ms)
+   unsigned int fast_timeout_us,
+   unsigned int slow_timeout_ms,
+   u32 *out_value)
 {
unsigned fw =
 

[PATCH v4 4/9] drm: Add some HDCP related #defines

2017-12-06 Thread Sean Paul
In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.

Changes in v2:
- drm_hdcp.h gets MIT license (Daniel)
Changes in v3:
- None
Changes in v4:
- None

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 include/drm/drm_dp_helper.h | 17 ++
 include/drm/drm_hdcp.h  | 56 +
 2 files changed, 73 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8b9ac321c3bd..4b2640d54c70 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -815,6 +815,23 @@
 #define DP_CEC_TX_MESSAGE_BUFFER   0x3020
 #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
 
+#define DP_AUX_HDCP_BKSV   0x68000
+#define DP_AUX_HDCP_RI_PRIME   0x68005
+#define DP_AUX_HDCP_AKSV   0x68007
+#define DP_AUX_HDCP_AN 0x6800C
+#define DP_AUX_HDCP_V_PRIME(h) (0x68014 + h * 4)
+#define DP_AUX_HDCP_BCAPS  0x68028
+# define DP_BCAPS_REPEATER_PRESENT BIT(1)
+# define DP_BCAPS_HDCP_CAPABLE BIT(0)
+#define DP_AUX_HDCP_BSTATUS0x68029
+# define DP_BSTATUS_REAUTH_REQ BIT(3)
+# define DP_BSTATUS_LINK_FAILURE   BIT(2)
+# define DP_BSTATUS_R0_PRIME_READY BIT(1)
+# define DP_BSTATUS_READY  BIT(0)
+#define DP_AUX_HDCP_BINFO  0x6802A
+#define DP_AUX_HDCP_KSV_FIFO   0x6802C
+#define DP_AUX_HDCP_AINFO  0x6803B
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index ..c9b2484240d4
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Sean Paul 
+ */
+
+#ifndef _DRM_HDCP_H_INCLUDED_
+#define _DRM_HDCP_H_INCLUDED_
+
+/* Period of hdcp checks (to ensure we're still authenticated) */
+#define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+
+/* Shared lengths/masks between HDMI/DVI/DisplayPort */
+#define DRM_HDCP_AN_LEN8
+#define DRM_HDCP_BSTATUS_LEN   2
+#define DRM_HDCP_KSV_LEN   5
+#define DRM_HDCP_RI_LEN2
+#define DRM_HDCP_V_PRIME_PART_LEN  4
+#define DRM_HDCP_V_PRIME_NUM_PARTS 5
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+
+/* Slave address for the HDCP registers in the receiver */
+#define DRM_HDCP_DDC_ADDR  0x3A
+
+/* HDCP register offsets for HDMI/DVI devices */
+#define DRM_HDCP_DDC_BKSV  0x00
+#define DRM_HDCP_DDC_RI_PRIME  0x08
+#define DRM_HDCP_DDC_AKSV  0x10
+#define DRM_HDCP_DDC_AN0x18
+#define DRM_HDCP_DDC_V_PRIME(h)(0x20 + h * 4)
+#define DRM_HDCP_DDC_BCAPS 0x40
+#define  DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT   BIT(6)
+#define  DRM_HDCP_DDC_BCAPS_KSV_FIFO_READY BIT(5)
+#define DRM_HDCP_DDC_BSTATUS   0x41
+#define DRM_HDCP_DDC_KSV_FIFO  0x43
+
+#endif
-- 
2.15.1.424.g9478a66081-goog

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


[PATCH v4 0/9] drm/i915: Implement HDCP

2017-12-06 Thread Sean Paul
Welcome to version 4 of the patchset. I think we're nearing the finish line
(hopefully) now. This set addresses the review feedback from v3. I applied some
R-b's from v3 review, and converted others to Cc since other changes were made
to the patch, and I didn't want to speak for reviewers.

Thanks for all the review feedback!

Sean

Sean Paul (9):
  drm: Fix link-status kerneldoc line lengths
  drm/i915: Add more control to wait_for routines
  drm: Add Content Protection property
  drm: Add some HDCP related #defines
  drm/i915: Add HDCP framework + base implementation
  drm/i915: Make use of indexed write GMBUS feature
  drm/i915: Add function to output Aksv over GMBUS
  drm/i915: Implement HDCP for HDMI
  drm/i915: Implement HDCP for DisplayPort

 drivers/gpu/drm/drm_atomic.c |   8 +
 drivers/gpu/drm/drm_connector.c  |  87 -
 drivers/gpu/drm/drm_sysfs.c  |   1 +
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_reg.h  |  85 
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_ddi.c |  36 ++
 drivers/gpu/drm/i915/intel_display.c |   4 +
 drivers/gpu/drm/i915/intel_dp.c  | 244 +++-
 drivers/gpu/drm/i915/intel_drv.h | 106 -
 drivers/gpu/drm/i915/intel_hdcp.c| 735 +++
 drivers/gpu/drm/i915/intel_hdmi.c| 250 
 drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
 drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
 drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
 include/drm/drm_connector.h  |  16 +
 include/drm/drm_dp_helper.h  |  17 +
 include/drm/drm_hdcp.h   |  56 +++
 include/uapi/drm/drm_mode.h  |   4 +
 20 files changed, 1728 insertions(+), 43 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
 create mode 100644 include/drm/drm_hdcp.h

-- 
2.15.1.424.g9478a66081-goog

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


[PATCH v4 1/9] drm: Fix link-status kerneldoc line lengths

2017-12-06 Thread Sean Paul
I'm adding some stuff below it and it's killing my editor's vibe.

Changes in v2:
- Added to the series
Changes in v3:
- None
Changes in v4:
- None

Cc: Manasi Navare 
Acked-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_connector.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..f14b48e6e839 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -759,10 +759,11 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  * should update this value using drm_mode_connector_set_tile_property().
  * Userspace cannot change this property.
  * link-status:
- *  Connector link-status property to indicate the status of link. The 
default
- *  value of link-status is "GOOD". If something fails during or after 
modeset,
- *  the kernel driver may set this to "BAD" and issue a hotplug uevent. 
Drivers
- *  should update this value using 
drm_mode_connector_set_link_status_property().
+ *  Connector link-status property to indicate the status of link. The
+ *  default value of link-status is "GOOD". If something fails during or
+ *  after modeset, the kernel driver may set this to "BAD" and issue a
+ *  hotplug uevent. Drivers should update this value using
+ *  drm_mode_connector_set_link_status_property().
  *
  * Connectors also have one standardized atomic property:
  *
-- 
2.15.1.424.g9478a66081-goog

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


Re: [PATCH 4/5] drm/i915: Introduce a non-blocking power domain for vblank interrupts

2017-12-06 Thread Rodrigo Vivi
On Wed, Dec 06, 2017 at 10:47:40PM +, Dhinakaran Pandiyan wrote:
> When DC states are enabled and PSR is active, the hardware enters DC5/DC6
> states resulting in frame counter resets. The frame counter resets mess
> up the vblank counting logic. So in order to disable DC states when
> vblank interrupts are required and to disallow DC states when vblanks
> interrupts are already enabled, introduce a new power domain. Since this
> power domain reference needs to be acquired and released in atomic context,
> the corresponding _get() and _put() methods skip the power_domain mutex.

\o/

> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |   5 ++
>  drivers/gpu/drm/i915/intel_drv.h|   3 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 125 
> +++-
>  3 files changed, 128 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 18d42885205b..ba9107ec1ed1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -397,6 +397,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_C,
>   POWER_DOMAIN_AUX_D,
>   POWER_DOMAIN_GMBUS,
> + POWER_DOMAIN_VBLANK,
>   POWER_DOMAIN_MODESET,
>   POWER_DOMAIN_INIT,
>  
> @@ -1475,6 +1476,10 @@ struct i915_power_well {
>   bool has_vga:1;
>   bool has_fuses:1;
>   } hsw;
> + struct {
> + spinlock_t lock;
> + bool was_disabled;
> + } dc_off;

what about a more generic name here?
something like

+   struct {
+   spinlock_t lock;
+   bool was_disabled;
+   } atomic;
+   is_atomic; //or needs_atomic

so...

>   };
>   const struct i915_power_well_ops *ops;
>  };
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 30f791f89d64..93ca503f18bb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1865,7 +1865,8 @@ void chv_phy_powergate_lanes(struct intel_encoder 
> *encoder,
>bool override, unsigned int mask);
>  bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy 
> phy,
> enum dpio_channel ch, bool override);
> -
> +bool intel_display_power_vblank_get(struct drm_i915_private *dev_priv);
> +void intel_display_power_vblank_put(struct drm_i915_private *dev_priv);
>  
>  /* intel_pm.c */
>  void intel_init_clock_gating(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index f88f2c070c5f..f1807bd74242 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -126,6 +126,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "AUX_D";
>   case POWER_DOMAIN_GMBUS:
>   return "GMBUS";
> + case POWER_DOMAIN_VBLANK:
> + return "VBLANK";
>   case POWER_DOMAIN_INIT:
>   return "INIT";
>   case POWER_DOMAIN_MODESET:
> @@ -196,10 +198,17 @@ bool __intel_display_power_is_enabled(struct 
> drm_i915_private *dev_priv,
>   if (power_well->always_on)
>   continue;
>  
> - if (!power_well->hw_enabled) {
> + if (power_well->id == SKL_DISP_PW_DC_OFF)
> + spin_lock(_well->dc_off.lock);

... instead of a specif pw check here you would have

+   if (power_well->is_atomic)
+   spin_lock(_well->atomic.lock)

> +
> + if (!power_well->hw_enabled)
>   is_enabled = false;
> +
> + if (power_well->id == SKL_DISP_PW_DC_OFF)
> + spin_unlock(_well->dc_off.lock);
> +
> + if (!is_enabled)
>   break;
> - }
>   }
>  
>   return is_enabled;
> @@ -724,6 +733,7 @@ static void gen9_dc_off_power_well_disable(struct 
> drm_i915_private *dev_priv,
>   skl_enable_dc6(dev_priv);
>   else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
>   gen9_enable_dc5(dev_priv);
> + power_well->dc_off.was_disabled = true;
>  }
>  
>  static void i9xx_power_well_sync_hw_noop(struct drm_i915_private *dev_priv,
> @@ -1441,6 +1451,77 @@ static void chv_pipe_power_well_disable(struct 
> drm_i915_private *dev_priv,
>   chv_set_pipe_power_well(dev_priv, power_well, false);
>  }
>  
> +/**
> + * intel_display_power_vblank_get - acquire a VBLANK power domain reference 
> atomically
> + * @dev_priv: i915 device instance
> + *
> + * This function gets a POWER_DOMAIN_VBLANK reference without blocking and
> + * returns true if the DC_OFF power well was disabled since this function was
> + * 

[PATCH 2/5] drm/vblank: Restoring vblank counts after device runtime PM events.

2017-12-06 Thread Dhinakaran Pandiyan
The HW frame counter can get reset when devices enters low power
states and this messes up any following vblank count updates. So, compute
the missed vblank interrupts for that low power state duration using time
stamps. This is similar to _crtc_vblank_on() except that it doesn't enable
vblank interrupts because this function is expected to be called from
the driver _enable_vblank() vfunc.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 30 ++
 include/drm/drm_vblank.h |  1 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7eee82c06ed8..69d537cea149 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1230,6 +1230,36 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_vblank_on);
 
+void drm_crtc_vblank_restore(struct drm_device *dev, unsigned int pipe)
+{
+   ktime_t t_vblank;
+   struct drm_vblank_crtc *vblank;
+   int framedur_ns;
+   u64 diff_ns;
+   u32 cur_vblank, diff = 1;
+   int count = DRM_TIMESTAMP_MAXRETRIES;
+
+   if (WARN_ON(pipe >= dev->num_crtcs))
+   return;
+
+   vblank = >vblank[pipe];
+   framedur_ns = vblank->framedur_ns;
+
+   do {
+   cur_vblank = __get_vblank_counter(dev, pipe);
+   drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
+   } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
+
+   diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
+   if (framedur_ns)
+   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
+
+   DRM_DEBUG_VBL("computing missed vblanks %lld/%d=%d after HW counter 
reset hw_diff=%d\n",
+ diff_ns, framedur_ns, diff, cur_vblank - vblank->last);
+   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
+}
+EXPORT_SYMBOL(drm_crtc_vblank_restore);
+
 static void drm_legacy_vblank_pre_modeset(struct drm_device *dev,
  unsigned int pipe)
 {
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 848b463a0af5..aafcbef91bd7 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -180,6 +180,7 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
 u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
+void drm_crtc_vblank_restore(struct drm_device *dev, unsigned int pipe);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.11.0

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


[PATCH 5/5] drm/i915: Use the vblank power domain disallow or disable DC states.

2017-12-06 Thread Dhinakaran Pandiyan
Disable DC states before enabling vblank interrupts and conversely
enable DC states after disabling. Since the frame counter may have got
reset between disabling and enabling, use drm_crtc_vblank_restore() to
compute the missed vblanks.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_irq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7cac07db89b9..c595b934e2dc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2964,6 +2964,9 @@ static int gen8_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
struct drm_i915_private *dev_priv = to_i915(dev);
unsigned long irqflags;
 
+   if (intel_display_power_vblank_get(dev_priv))
+   drm_crtc_vblank_restore(dev, pipe);
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -3015,6 +3018,7 @@ static void gen8_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   intel_display_power_vblank_put(dev_priv);
 }
 
 static void ibx_irq_reset(struct drm_i915_private *dev_priv)
-- 
2.11.0

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


[PATCH 1/5] drm/vblank: Do not update vblank counts if vblanks are already disabled.

2017-12-06 Thread Dhinakaran Pandiyan
Updating the vblank counts requires register reads and these reads may not
return meaningful values after the vblank interrupts are disabled as the
device may go to low power state. An additional change would be to allow
the driver to save the vblank counts before entering a low power state, but
that's for the future.

Also, disable vblanks after reading the HW counter in the case where
_crtc_vblank_off() is disabling vblanks.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 32d9bcf5be7f..7eee82c06ed8 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -347,23 +347,14 @@ void drm_vblank_disable_and_save(struct drm_device *dev, 
unsigned int pipe)
spin_lock_irqsave(>vblank_time_lock, irqflags);
 
/*
-* Only disable vblank interrupts if they're enabled. This avoids
-* calling the ->disable_vblank() operation in atomic context with the
-* hardware potentially runtime suspended.
-*/
-   if (vblank->enabled) {
-   __disable_vblank(dev, pipe);
-   vblank->enabled = false;
-   }
-
-   /*
-* Always update the count and timestamp to maintain the
+* Update the count and timestamp to maintain the
 * appearance that the counter has been ticking all along until
 * this time. This makes the count account for the entire time
 * between drm_crtc_vblank_on() and drm_crtc_vblank_off().
 */
drm_update_vblank_count(dev, pipe, false);
-
+   __disable_vblank(dev, pipe);
+   vblank->enabled = false;
spin_unlock_irqrestore(>vblank_time_lock, irqflags);
 }
 
@@ -1122,8 +1113,12 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
  pipe, vblank->enabled, vblank->inmodeset);
 
/* Avoid redundant vblank disables without previous
-* drm_crtc_vblank_on(). */
-   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset)
+* drm_crtc_vblank_on() and only disable them if they're enabled. This
+* avoids calling the ->disable_vblank() operation in atomic context
+* with the hardware potentially runtime suspended.
+*/
+   if ((drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset) 
&&
+   vblank->enabled)
drm_vblank_disable_and_save(dev, pipe);
 
wake_up(>queue);
-- 
2.11.0

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


[PATCH 3/5] drm/i915: Use an atomic_t array to track power domain use count.

2017-12-06 Thread Dhinakaran Pandiyan
Convert the power_domains->domain_use_count array that tracks per-domain
use count to atomic_t type. This is needed to be able to read/write the use
counts outside of the power domain mutex.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 28294470ae31..2a4ed54688d7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2805,7 +2805,7 @@ static int i915_power_domain_info(struct seq_file *m, 
void *unused)
for_each_power_domain(power_domain, power_well->domains)
seq_printf(m, "  %-23s %d\n",
 intel_display_power_domain_str(power_domain),
-power_domains->domain_use_count[power_domain]);
+
atomic_read(_domains->domain_use_count[power_domain]));
}
 
mutex_unlock(_domains->lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14e66c5..18d42885205b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1489,7 +1489,7 @@ struct i915_power_domains {
int power_well_count;
 
struct mutex lock;
-   int domain_use_count[POWER_DOMAIN_NUM];
+   atomic_t domain_use_count[POWER_DOMAIN_NUM];
struct i915_power_well *power_wells;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..f88f2c070c5f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1451,7 +1451,7 @@ __intel_display_power_get_domain(struct drm_i915_private 
*dev_priv,
for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
intel_power_well_get(dev_priv, power_well);
 
-   power_domains->domain_use_count[domain]++;
+   atomic_inc(_domains->domain_use_count[domain]);
 }
 
 /**
@@ -1537,10 +1537,9 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
 
mutex_lock(_domains->lock);
 
-   WARN(!power_domains->domain_use_count[domain],
-"Use count on domain %s is already zero\n",
+   WARN(atomic_dec_return(_domains->domain_use_count[domain]) < 0,
+"Use count on domain %s was already zero\n",
 intel_display_power_domain_str(domain));
-   power_domains->domain_use_count[domain]--;
 
for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
intel_power_well_put(dev_priv, power_well);
@@ -3044,7 +3043,7 @@ static void intel_power_domains_dump_info(struct 
drm_i915_private *dev_priv)
for_each_power_domain(domain, power_well->domains)
DRM_DEBUG_DRIVER("  %-23s %d\n",
 intel_display_power_domain_str(domain),
-
power_domains->domain_use_count[domain]);
+
atomic_read(_domains->domain_use_count[domain]));
}
 }
 
@@ -3087,7 +3086,7 @@ void intel_power_domains_verify_state(struct 
drm_i915_private *dev_priv)
 
domains_count = 0;
for_each_power_domain(domain, power_well->domains)
-   domains_count += 
power_domains->domain_use_count[domain];
+   domains_count += 
atomic_read(_domains->domain_use_count[domain]);
 
if (power_well->count != domains_count) {
DRM_ERROR("power well %s refcount/domain refcount 
mismatch "
-- 
2.11.0

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


[PATCH 4/5] drm/i915: Introduce a non-blocking power domain for vblank interrupts

2017-12-06 Thread Dhinakaran Pandiyan
When DC states are enabled and PSR is active, the hardware enters DC5/DC6
states resulting in frame counter resets. The frame counter resets mess
up the vblank counting logic. So in order to disable DC states when
vblank interrupts are required and to disallow DC states when vblanks
interrupts are already enabled, introduce a new power domain. Since this
power domain reference needs to be acquired and released in atomic context,
the corresponding _get() and _put() methods skip the power_domain mutex.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 125 +++-
 3 files changed, 128 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18d42885205b..ba9107ec1ed1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -397,6 +397,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_C,
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
+   POWER_DOMAIN_VBLANK,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_INIT,
 
@@ -1475,6 +1476,10 @@ struct i915_power_well {
bool has_vga:1;
bool has_fuses:1;
} hsw;
+   struct {
+   spinlock_t lock;
+   bool was_disabled;
+   } dc_off;
};
const struct i915_power_well_ops *ops;
 };
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 30f791f89d64..93ca503f18bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1865,7 +1865,8 @@ void chv_phy_powergate_lanes(struct intel_encoder 
*encoder,
 bool override, unsigned int mask);
 bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy phy,
  enum dpio_channel ch, bool override);
-
+bool intel_display_power_vblank_get(struct drm_i915_private *dev_priv);
+void intel_display_power_vblank_put(struct drm_i915_private *dev_priv);
 
 /* intel_pm.c */
 void intel_init_clock_gating(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f88f2c070c5f..f1807bd74242 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -126,6 +126,8 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "AUX_D";
case POWER_DOMAIN_GMBUS:
return "GMBUS";
+   case POWER_DOMAIN_VBLANK:
+   return "VBLANK";
case POWER_DOMAIN_INIT:
return "INIT";
case POWER_DOMAIN_MODESET:
@@ -196,10 +198,17 @@ bool __intel_display_power_is_enabled(struct 
drm_i915_private *dev_priv,
if (power_well->always_on)
continue;
 
-   if (!power_well->hw_enabled) {
+   if (power_well->id == SKL_DISP_PW_DC_OFF)
+   spin_lock(_well->dc_off.lock);
+
+   if (!power_well->hw_enabled)
is_enabled = false;
+
+   if (power_well->id == SKL_DISP_PW_DC_OFF)
+   spin_unlock(_well->dc_off.lock);
+
+   if (!is_enabled)
break;
-   }
}
 
return is_enabled;
@@ -724,6 +733,7 @@ static void gen9_dc_off_power_well_disable(struct 
drm_i915_private *dev_priv,
skl_enable_dc6(dev_priv);
else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
gen9_enable_dc5(dev_priv);
+   power_well->dc_off.was_disabled = true;
 }
 
 static void i9xx_power_well_sync_hw_noop(struct drm_i915_private *dev_priv,
@@ -1441,6 +1451,77 @@ static void chv_pipe_power_well_disable(struct 
drm_i915_private *dev_priv,
chv_set_pipe_power_well(dev_priv, power_well, false);
 }
 
+/**
+ * intel_display_power_vblank_get - acquire a VBLANK power domain reference 
atomically
+ * @dev_priv: i915 device instance
+ *
+ * This function gets a POWER_DOMAIN_VBLANK reference without blocking and
+ * returns true if the DC_OFF power well was disabled since this function was
+ * called the last time.
+ */
+bool intel_display_power_vblank_get(struct drm_i915_private *dev_priv)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   bool needs_restore = false;
+
+   if (!HAS_CSR(dev_priv) || !dev_priv->psr.source_ok)
+   return false;
+
+   /* The corresponding CRTC should be active by the time driver turns on
+* vblank interrupts, which in turn means the enabled pipe power domain
+* would have acquired the device runtime pm reference.
+*/
+   

[Bug 102962] GPU crash running Overwatch in wine-staging

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102962

--- Comment #8 from Józef Kucia  ---
(In reply to Tobias Auerochs from comment #2)
> As I mentioned, it causes a GPU crash, meaning the entire graphics session
> freezes, other than mouse cursor, I'm not referring to wine simply crashing.
> 
> I'm not familiar with advanced OpenGL (specifically what wine requires to
> implement d3d11) and if that would ever be allowed to cause a GPU crash at
> all to begin with.

OpenGL applications can cause GPU hangs quite easily.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99851

--- Comment #57 from erhar...@mailbox.org ---
Had some time to test kernels 4.14.4 and 4.15-rc2. Sadly nothing new concerning
this issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline

2017-12-06 Thread Rob Herring
On Tue, Dec 05, 2017 at 04:10:16PM +0100, Maxime Ripard wrote:
> The A83T has two video pipelines in parallel that looks quite similar to
> the other SoCs.
> 
> The video planes are handled through a controller called the mixer, and the
> video signal is then passed to the timing controller (TCON).
> 
> And while there is two instances of the mixers and TCONs, they have a
> significant number of differences. The TCONs are quite easy to deal with,
> one is supposed to generate TV (in the broader term, so including things
> like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
> while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
> call them TCON-TV and TCON-LCD, which seems more appropriate.
> 
> However, the mixers differ mostly by their capabilities, with some features
> being available only in the first one, or the number of planes they expose,
> but also through their register layout. And while the capabilities could be
> represented as properties, the register layout differences would need to
> express all the registers offsets as properties, which is usually quite
> bad. Especially since documentation on that hardware block is close to
> non-existant and we don't even have the list of all those registers in the
> first place.
> 
> So let's call them mixer 0 and 1 in our compatibles, even though the name
> is pretty bad...
> 
> At the moment, we only have tested the code on a board that has a single
> display output, so we're leaving the tcon-tv and mixer1 out.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 

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


Re: [PATCH v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties

2017-12-06 Thread Rob Herring
On Tue, Dec 05, 2017 at 04:10:15PM +0100, Maxime Ripard wrote:
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
> 
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++-
>  1 file changed, 8 insertions(+)

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 01/15] dt-bindings: panel: lvds: Document power-supply property

2017-12-06 Thread Rob Herring
On Tue, Dec 05, 2017 at 04:10:13PM +0100, Maxime Ripard wrote:
> The power-supply property is used by a vast majority of panels, including
> panel-simple. Let's document it as a common property
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
>  3 files changed, 8 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

2017-12-06 Thread Brian Norris
Hi Nickey, others,

I just want to highlight a thing or two here. Otherwise, my
'Reviewed-by' still basically stands (FWIW).

On Wed, Dec 06, 2017 at 05:08:21PM +0800, Nickey Yang wrote:
> Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
> MIPI DSI host controller bridge.
> 
> Signed-off-by: Nickey Yang 
> Signed-off-by: Brian Norris 
> Reviewed-by: Brian Norris 
> Reviewed-by: Sean Paul 
> ---
> change:
> 
> v2:
>add err_pllref, remove unnecessary encoder.enable & disable
>correct spelling mistakes
> v3:
>call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
>fix typo, use of_device_get_match_data(),
>change some ‘bind()’ logic into 'probe()'
>add 'dev_set_drvdata()'
> v4:
>   return -EINVAL when can not get best_freq
>   add a clarifying comment when get vco
>   add review tag
> v5:
>   keep our power domain enabled while touching GRF
> v6:
>   change func dw_mipi_encoder_disable name to
>   dw_mipi_dsi_encoder_disable

We noticed a regression w.r.t. pm_runtime_*() handling using this patch,
hence the pm_runtime changes in v5/v6. We actually need to keep our
power domain enabled in the mode_set() function, where we start to
configure some Rockchip-specific registers (GRF). More on that below.

> 
>  drivers/gpu/drm/rockchip/Kconfig|2 +-
>  drivers/gpu/drm/rockchip/Makefile   |2 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  785 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
>  6 files changed, 789 insertions(+), 1353 deletions(-)
>  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> 

...

> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> new file mode 100644
> index 000..66ab6fe
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> @@ -0,0 +1,785 @@

...

> +static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
> +  struct drm_display_mode *mode,
> +  struct drm_display_mode *adjusted)
> +{
> + struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
> + const struct rockchip_dw_dsi_chip_data *cdata = dsi->cdata;
> + int val, ret, mux;
> +
> + mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node,
> + >encoder);
> + if (mux < 0)
> + return;
> + /*
> +  * For the RK3399, the clk of grf must be enabled before writing grf
> +  * register. And for RK3288 or other soc, this grf_clk must be NULL,
> +  * the clk_prepare_enable return true directly.
> +  */
> + ret = clk_prepare_enable(dsi->grf_clk);
> + if (ret) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
> + return;
> + }
> + pm_runtime_get_sync(dsi->dev);

What happens if there's a clk_prepare_enable() failure or failure to
retrieve the endpoint ID earlier in this function? You won't call
pm_runtime_get_*()...but might we still see a call to
dw_mipi_dsi_encoder_disable(), which would mean we get unbalanced
runtime PM status?

Also (and more importantly), is it fair to do all of this in mode_set()?
I believe Archit asked about this before, and the reason we're doing
this stuff in mode_set() now (where previously, the Rockchip driver was
doing it in ->enable()) is because when Philippe extracted the synopsys
bridge driver, that code migrated to ->mode_set().

But, I'm reading the comments on drm_encoder_helper_funcs::mode_set, and
I see:

/**
 * @mode_set:
 *
 * This callback is used to update the display mode of an encoder.
 *
 * Note that the display pipe is completely off when this function is
 * called. Drivers which need hardware to be running before they program
 * the new display mode (because they implement runtime PM) should not
 * use this hook, because the helper library calls it only once and not
 * every time the display pipeline is suspend using either DPMS or the
 * new "ACTIVE" property. Such drivers should instead move all their
 * encoder setup into the @enable callback.

That sounds like perhaps the synopsys driver should be moving to use
->enable() instead, so the Rockchip driver can do that as well?

At any rate, I haven't found any real problem with using mode_set() so
far, but I was just curious what the recommended practice was.

> + val = cdata->dsi0_en_bit << 16;
> + if (mux)
> + val |= cdata->dsi0_en_bit;
> + 

[Bug 102962] GPU crash running Overwatch in wine-staging

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102962

--- Comment #7 from sander.s...@gmail.com ---
I can look into providing additional information for this issue. However I'm
not familiar with the process of debugging or log gathering for GPU crashes.
Any information on the subject is welcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

2017-12-06 Thread Rob Herring
On Tue, Dec 05, 2017 at 04:03:56PM +0530, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode.
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 77 
> ++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 77a7cec15f5b..f556aaafdf22 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,12 @@ Required properties:
>  - #size-cells: Should be 0. There are cases where it makes sense to use a
>different value here. See below.
>  
> +Optional properties:
> +- clock-master: A DSI host controller may be used in conjunction with 
> another DSI
> +  host to drive the same peripheral. Hardware supporting such a configuration
> +  generally requires the data on both the busses to be driven by the same 
> clock.
> +  The DSI host instance controlling this clock should contain this property.

Be explicit this is a boolean.

> +
>  DSI peripheral
>  ==
>  
> @@ -61,6 +67,17 @@ primary control bus, but are also connected to a DSI bus 
> (mostly for the data
>  path). Connections between such peripherals and a DSI host can be represented
>  using the graph bindings [1], [2].
>  
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the 
> display).
> +The graph bindings should be used to represent the multiple DSI busses that 
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked 
> to
> +an input endpoint of the DSI peripheral.
> +
> +
>  [1] Documentation/devicetree/bindings/graph.txt
>  [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -70,6 +87,8 @@ Examples
>with different virtual channel configurations.
>  - (4) is an example of a peripheral on a I2C control bus connected with to
>a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> +  which uses I2C as its primary control bus.
>  
>  1)
>   dsi-host {
> @@ -157,3 +176,61 @@ Examples
>   };
>   };
>   };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port@0 {

Need reg property and #{address,size}-cells.

> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> +  * this DSI instance drives the clock for both the host
> +  * controllers
> +  */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port@0 {

Drop unit-address.

> + dsi0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port@0 {

Drop unit-address.

> + dsi1_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

2017-12-06 Thread Rob Herring
On Tue, Dec 05, 2017 at 04:03:55PM +0530, Archit Taneja wrote:
> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus. Add an
> example for such peripherals.
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 75 
> --
>  1 file changed, 68 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 973c27273772..77a7cec15f5b 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
> connected to a DSI
>  host. Experience shows that this is true for the large majority of setups.
>  
>  DSI host
> -
> +
>  
>  In addition to the standard properties and those defined by the parent bus of
>  a DSI host, the following properties apply to a node representing a DSI host.
> @@ -30,11 +30,15 @@ Required properties:
>different value here. See below.
>  
>  DSI peripheral
> ---
> +==
>  
> -Peripherals are represented as child nodes of the DSI host's node. Properties
> -described here apply to all DSI peripherals, but individual bindings may want
> -to define additional, device-specific properties.
> +Peripherals with DSI as control bus
> +
> +
> +Peripherals with the DSI bus as the primary control path are represented as
> +child nodes of the DSI host's node. Properties described here apply to all 
> DSI
> +peripherals, but individual bindings may want to define additional,
> +device-specific properties.

Are there any panels with no control bus? I've never seen one, but it 
should be possible if LVDS panels can power on without commands. 

>  Required properties:
>  - reg: The virtual channel number of a DSI peripheral. Must be in the range
> @@ -49,9 +53,25 @@ case two alternative representations can be chosen:
>property is the number of the first virtual channel and the second cell is
>the number of consecutive virtual channels.
>  
> -Example
> 
> +Peripherals with a different control bus
> +
> +
> +There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
> +primary control bus, but are also connected to a DSI bus (mostly for the data
> +path). Connections between such peripherals and a DSI host can be represented
> +using the graph bindings [1], [2].
> +
> +[1] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> +Examples
> +
> +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
> +  with different virtual channel configurations.
> +- (4) is an example of a peripheral on a I2C control bus connected with to
> +  a DSI host using of-graph bindings.
> +
> +1)
>   dsi-host {
>   ...
>  
> @@ -67,6 +87,7 @@ Example
>   ...
>   };
>  
> +2)
>   dsi-host {
>   ...
>  
> @@ -82,6 +103,7 @@ Example
>   ...
>   };
>  
> +3)
>   dsi-host {
>   ...
>  
> @@ -96,3 +118,42 @@ Example
>  
>   ...
>   };
> +
> +4)
> + i2c-host {
> + ...
> +
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ...
> +
> + port@0 {

Drop unit-address and #*-cells.

> + bridge_mipi_in: endpoint {
> + remote-endpoint = 
> <_mipi_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi-host {
> + ...
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ...
> +
> + port@0 {

Drop unit-address and #*-cells.

> + host_mipi_out: endpoint {
> + remote-endpoint = <_mipi_in>;
> + };
> + };
> + };
> + };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

2017-12-06 Thread Brian Norris
On Wed, Dec 06, 2017 at 05:08:19PM +0800, Nickey Yang wrote:
> From: Brian Norris 
> 
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> 
> Signed-off-by: Brian Norris 
> Signed-off-by: Nickey Yang 
> Link:https://patchwork.kernel.org/patch/10078493/
> 
> ---
> Changes
> 
> v4:
> - Add From tag,update subject line
> - keep patch "drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove"
>   in this piece together.
> 
> v5:
> - remove Review & Ack tag
> - fix remove() directly referencing the static
>   dw_mipi_dsi_stm_plat_data struct.

You've gotten this back into basically the shape I sent v1 in, so I
guess this deserves an:

Acked-by: Brian Norris 

:)

Only net changes: you renamed the 'dsi' field to 'dmd' (Dwc Mipi
Device?), and my 'return 0' changed back to the original 'return ret' at
the end of probe(). Doesn't make any functional difference, so fine with
me.

If everybody's just as happy with this as with the first
version...should it just be applied now, regardless of the status of the
next 2 patches? Could help reduce the discussion (and confusion)
surface.

Regards,
Brian

>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
> ++-
>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 10 +---
>  include/drm/bridge/dw_mipi_dsi.h  | 17 -
>  3 files changed, 30 insertions(+), 33 deletions(-)
...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-fixes

2017-12-06 Thread Daniel Vetter
Hi Dave,

drm-misc-fixes-2017-12-06:

Just the connector_iter corner-case regression fix.

Enjoy your time off next week!

Cheers, Daniel

The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:

  Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-12-06

for you to fetch changes up to a703c55004e1c5076d57e43771b3e7796ea0:

  drm: safely free connectors from connector_iter (2017-12-06 10:22:55 +0100)


Just the connector_iter corner-case regression fix.


Daniel Vetter (1):
  drm: safely free connectors from connector_iter

 drivers/gpu/drm/drm_connector.c   | 28 ++--
 drivers/gpu/drm/drm_mode_config.c |  2 ++
 include/drm/drm_connector.h   |  8 
 3 files changed, 36 insertions(+), 2 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Andrey Grodzovsky

Tested with amdgpu libdrm tests and desktop login with glxgears.

Thanks,

Andrey


On 12/06/2017 02:51 PM, Alex Deucher wrote:

On Wed, Dec 6, 2017 at 11:49 AM, Lucas Stach  wrote:

Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Series is:
Acked-by: Alex Deucher 


Thanks,
Lucas

Lucas Stach (2):
   drm: move amd_gpu_scheduler into common location
   drm/sched: move fence slab handling to module init/exit

  drivers/gpu/drm/Kconfig|   5 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
  drivers/gpu/drm/scheduler/Makefile |   4 +
  .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 ++---
  drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
  include/drm/gpu_scheduler.h| 173 
  .../drm/gpu_scheduler_trace.h  |  14 +-
  .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
  35 files changed, 529 insertions(+), 523 deletions(-)
  delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
  create mode 100644 drivers/gpu/drm/scheduler/Makefile
  rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
  rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
  create mode 100644 include/drm/gpu_scheduler.h
  rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
include/drm/gpu_scheduler_trace.h (82%)
  rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h (95%)

--
2.11.0

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


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


Re: [PATCH v2 7/7] dt-bindings: tda998x: add the calibration gpio

2017-12-06 Thread Rob Herring
On Wed, Dec 6, 2017 at 6:35 AM, Russell King  wrote:
> Add the optional calibration gpio for integrated TDA9950 CEC support.
> This GPIO corresponds with the interrupt from the TDA998x, as the
> calibration requires driving the interrupt pin low.
>
> Signed-off-by: Russell King 
> ---
>  Documentation/devicetree/bindings/display/bridge/tda998x.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104001

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 136012
  --> https://bugs.freedesktop.org/attachment.cgi?id=136012=edit
dmesg with 4.15.0-rc2 amd-staging-drm-next

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Alex Deucher
On Wed, Dec 6, 2017 at 11:49 AM, Lucas Stach  wrote:
> Hi all,
>
> second try to move the AMDGPU scheduler into a common location, this
> time rebased onto drm-next-4.16-wip.
>
> I've tested my etnaviv series on top of this and things seem to work
> fine. I checked that AMDGPU still builds, but I don't have any means
> to actually runtime test this currently, so I would be very happy to
> receive some tested-bys from the AMD side.
>
> Alex, if this looks good please pull this in so it gets your usual
> testing.

Series is:
Acked-by: Alex Deucher 

>
> Thanks,
> Lucas
>
> Lucas Stach (2):
>   drm: move amd_gpu_scheduler into common location
>   drm/sched: move fence slab handling to module init/exit
>
>  drivers/gpu/drm/Kconfig|   5 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
>  drivers/gpu/drm/scheduler/Makefile |   4 +
>  .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 
> ++---
>  drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
>  include/drm/gpu_scheduler.h| 173 
>  .../drm/gpu_scheduler_trace.h  |  14 +-
>  .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
>  35 files changed, 529 insertions(+), 523 deletions(-)
>  delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
>  create mode 100644 drivers/gpu/drm/scheduler/Makefile
>  rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
>  rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
>  create mode 100644 include/drm/gpu_scheduler.h
>  rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
> include/drm/gpu_scheduler_trace.h (82%)
>  rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h (95%)
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103769] Unity based games do not start

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103769

--- Comment #6 from bartos.p...@gmail.com ---
Yes, the problem is still there, tested with mesa git 9f9177d, llvm git e58aca6
(and clang 9f9177d).
Unfortunately I am unable to provide backtrace with symbols now since I've
upgraded to Fedora 27 and have problems with building debuginfo package.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[pull] amdgpu, radeon, and ttm drm-next-4.16

2017-12-06 Thread Alex Deucher
Hi Dave,

First feature request for 4.16.  Highlights:
- RV and Vega header cleanups
- TTM operation context support
- 48 bit GPUVM fixes for Vega/RV
- More smatch fixes
- ECC support for vega10
- Resizeable BAR support
- Multi-display sync support in DC
- SR-IOV fixes
- Various scheduler improvements
- GPU reset fixes and vram lost tracking
- Clean up DC/powerplay interfaces
- DCN display fixes
- Various DC fixes

The following changes since commit ca797d29cd63e7b71b4eea29aff3b1cefd1ecb59:

  Merge tag 'drm-intel-next-2017-11-17-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2017-12-04 10:56:53 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.16

for you to fetch changes up to 3997eea57caf542e9327df9b6bb2882a57c4c421:

  drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed() (2017-12-06 
12:48:34 -0500)


Alex Deucher (5):
  drm/amd/display: add mod_freesync_user_enable to dm_connector_state
  drm/amdgpu/gfx8: use cached values for raster config in clear state
  drm/amdgpu/gfx7: use cached values for raster config in clear state
  drm/amdgpu/gfx6: use cached values for raster config in clear state
  drm/amdgpu/gmc9: make some ECC messages debug only

Andrew Jiang (10):
  drm/amd/display: Reject PPLib clock values if they are invalid
  drm/amd/display: Don't use dc_link in link_encoder
  drm/amd/display: Report pitch_alignment for DCN
  drm/amd/display: Loosen plane_info and scaling_info checks
  drm/amd/display: Remove legacy unused workaround
  drm/amd/display: Add update flags in to determine surface update type
  drm/amd/display: Rename pitch_alignment to linear_pitch_alignment
  drm/amd/display: Add check update surfaces for stream wrapper
  drm/amd/display: Set full update flag in dcn_validate_bandwidth
  drm/amd/display: Set OPP default values in init_hw

Andrey Grodzovsky (6):
  drm/amdgpu: Avoid accessing job->entity after the job is scheduled.
  drm/amdgpu: Add SPSC queue to scheduler.
  drm/amdgpu: Fix deadlock during GPU reset.
  drm/amdgpu: Remove job->s_entity to avoid keeping reference to stale 
pointer.
  drm/amdgpu: Implement BO size validation V2
  drm/amdgpu: Get rid of dep_sync as a seperate object.

Anthony Koo (4):
  drm/amd/display: Add APU cap in dc_caps
  drm/amd/display: DMCU FW loading from PSP
  drm/amd/display: Move hdr_metadata from plane to stream
  drm/amd/display: DMCU and ABM maintenance and refactor

Arun Pandey (1):
  drm/amd/display: Added Opp and Diags Interface for P to I

Bhawanpreet Lakha (1):
  drm/amd/display: Atomic freesync ASSERT fix

Charlene Liu (2):
  drm/amd/display: correct DP is always in full range or bt609
  drm/amd/display: Do post_update_surfaces on new state

Christian König (51):
  drm/amdgpu: use the actual placement for pin accounting
  drm/amdgpu: always bind pinned BOs
  drm/amdgpu: fix pin domain compatibility check
  drm/amdgpu: don't wait interruptible while binding GART space
  drm/amdgpu: remove extra parameter from amdgpu_ttm_bind() v2
  drm/amdgpu: fix indentation in amdgpu_display.h
  drm/amdgpu: nuke amdgpu_ttm_is_bound() v2
  drm/amdgpu: move GART recovery into GTT manager v2
  drm/amdgpu: resize VRAM BAR for CPU access v6
  drm/amdgpu: rename amdgpu_ttm_bind to amdgpu_ttm_alloc_gart
  drm/amdgpu: don't use ttm_bo_move_ttm in amdgpu_ttm_bind v2
  drm/ttm: move unlocking out of ttm_bo_cleanup_memtype_use
  drm/ttm: consistently use reservation_object_unlock
  drm/ttm: user reservation object wrappers v2
  drm/ttm: remove ttm_bo_unreserve_ticket
  drm/amdgpu: remove nonsense const u32 cast on ARRAY_SIZE result
  drm/amdgpu: cleanup vm_size handling
  drm/ttm: make unlocking in ttm_bo_cleanup_refs optional v3
  drm/ttm: optimize ttm_mem_evict_first v5
  drm/amdgpu: require a root bus window above 4GB for BAR resize
  drm/ttm: fix ttm_mem_evict_first once more
  drm/ttm: completely rework ttm_bo_delayed_delete
  drm/ttm: cleanup coding style in ttm_bo_api.h
  drm/ttm: cleanup ttm_bo_driver.h
  drm/ttm: remove cur_placement
  drm/amdgpu: always make gart.table_addr 64bit
  drm/amdgpu: remove VRAM size reduction v2
  drm/amdgpu: align GTT start to 4GB v2
  drm/amdgpu: fix VCE buffer placement restrictions v2
  drm/ttm: add operation ctx to ttm_bo_validate v2
  drm/ttm: use an operation ctx for ttm_bo_init_reserved
  drm/ttm: use an operation context for ttm_bo_mem_space v2
  drm/ttm: use the operation context inside TTM
  drm/ttm: add context to driver move callback as well
  drm/ttm: add number of bytes moved to the operation context
  staging: vboxvideo: adapt to new TTM interface
  drm/amdgpu: forward operation context to 

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels

2017-12-06 Thread Noralf Trønnes


Den 29.11.2017 04.01, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---
  MAINTAINERS   |   6 +
  drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/st7735r.c | 237 ++
  4 files changed, 254 insertions(+)
  create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a174632..9c7707e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4462,6 +4462,12 @@ S:   Maintained
  F:drivers/gpu/drm/tinydrm/st7586.c
  F:Documentation/devicetree/bindings/display/st7586.txt
  
+DRM DRIVER FOR SITRONIX ST7735R PANELS

+M: David Lechner 


I know we haven't done this in the other tinydrm drivers, but I think
we should start adding which tree the development is happening in:

T:    git git://anongit.freedesktop.org/drm/drm-misc


+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7735r.c
+F: Documentation/devicetree/bindings/display/st7735r.txt
+
  DRM DRIVER FOR TDFX VIDEO CARDS
  S:Orphan / Obsolete
  F:drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 90c5bd5..b0e567d 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -52,3 +52,13 @@ config TINYDRM_ST7586
  * LEGO MINDSTORMS EV3
  
  	  If M is selected the module will be called st7586.

+
+config TINYDRM_ST7735R
+   tristate "DRM support for Sitronix ST7735R display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver Sitronix ST7735R with one of the following LCDs:
+ * JD-T18003-T01 1.8" 128x160 TFT
+
+ If M is selected the module will be called st7735r.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 8aeee53..49a1119 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_TINYDRM_ILI9225)   += ili9225.o
  obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
  obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
  obj-$(CONFIG_TINYDRM_ST7586)  += st7586.o
+obj-$(CONFIG_TINYDRM_ST7735R)  += st7735r.o
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
new file mode 100644
index 000..6435b00
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -0,0 +1,237 @@
+/*
+ * DRM driver for Sitronix ST7735R panels
+ *
+ * Copyright 2017 David Lechner 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ST7735R_FRMCTR10xb1
+#define ST7735R_FRMCTR20xb2
+#define ST7735R_FRMCTR30xb3
+#define ST7735R_INVCTR 0xb4
+#define ST7735R_PWCTR1 0xc0
+#define ST7735R_PWCTR2 0xc1
+#define ST7735R_PWCTR3 0xc2
+#define ST7735R_PWCTR4 0xc3
+#define ST7735R_PWCTR5 0xc4
+#define ST7735R_VMCTR1 0xc5
+#define ST7735R_GAMCTRP1   0xe0
+#define ST7735R_GAMCTRN1   0xe1
+
+#define ST7735R_MY BIT(7)
+#define ST7735R_MX BIT(6)
+#define ST7735R_MV BIT(5)
+
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct drm_framebuffer *fb = pipe->plane.fb;
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+   mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+   mipi_dbi_command(mipi, 

[Bug 103769] Unity based games do not start

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103769

--- Comment #5 from letha...@gmail.com ---
other unity games affected:
candle
silence
grow home
pulse
mousecraft
wasteland 2
broforce
habitat
munin
the last tinker
agatha christie the abc murders
plague inc evolved
pillars of eternity
monochroma
foosball
superhot
layers of fear
glare
space hilk ascension
hitmango
leisure suit larry reloaded
action henk
never alone kisima ingitchuna
interplanetary
cities skylines
cities skylines snowfall
cities in motion 2
star horizon
oddworld




I tried to env variable: 
R600_DEBUG=vs,tcs,tes,gs,ps,cs ./SUPERHOT.x86_64
but there was no debug output (not like the variable with glxgears...)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 09/15] drm/sun4i: Add A83T support

2017-12-06 Thread Jernej Škrabec
Hi,

Dne torek, 05. december 2017 ob 16:42:55 CET je Jernej Škrabec napisal(a):
> Hi Maxime,
> 
> Dne torek, 05. december 2017 ob 16:10:21 CET je Maxime Ripard napisal(a):
> > Add support for the A83T display pipeline.
> > 
> > Reviewed-by: Chen-Yu Tsai 
> > Signed-off-by: Maxime Ripard 
> > ---
> > 
> >  drivers/gpu/drm/sun4i/sun4i_drv.c   |  1 +
> >  drivers/gpu/drm/sun4i/sun4i_tcon.c  |  5 +
> >  drivers/gpu/drm/sun4i/sun8i_mixer.c |  9 +
> >  3 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c index 49215d91c853..6f5e721b545e
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -347,6 +347,7 @@ static const struct of_device_id sun4i_drv_of_table[]
> > =
> > { { .compatible = "allwinner,sun6i-a31s-display-engine" },
> > 
> > { .compatible = "allwinner,sun7i-a20-display-engine" },
> > { .compatible = "allwinner,sun8i-a33-display-engine" },
> > 
> > +   { .compatible = "allwinner,sun8i-a83t-display-engine" },
> > 
> > { .compatible = "allwinner,sun8i-v3s-display-engine" },
> > { }
> >  
> >  };
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 92f4738101e6..9b757450555f
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -1132,6 +1132,10 @@ static const struct sun4i_tcon_quirks
> > sun8i_a33_quirks = { .has_lvds_pll  = true,
> > 
> >  };
> > 
> > +static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
> > +   /* nothing is supported */
> > +};
> > +
> > 
> >  static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
> >  
> > /* nothing is supported */
> >  
> >  };
> > 
> > @@ -1144,6 +1148,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
> > 
> > { .compatible = "allwinner,sun6i-a31s-tcon", .data = 
_a31s_quirks
> > },
> > 
> > { .compatible = "allwinner,sun7i-a20-tcon", .data = _a20_quirks }, {
> > .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks }, +
{
> > .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
> > _a83t_lcd_quirks }, { .compatible = "allwinner,sun8i-v3s-tcon",
> > .data
> > = _v3s_quirks }, { }
> > 
> >  };
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index ff235e3228ce..6829bec4ba68
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -477,6 +477,11 @@ static int sun8i_mixer_remove(struct platform_device
> > *pdev) return 0;
> > 
> >  }
> > 
> > +static const struct sun8i_mixer_cfg sun8i_a83t_mixer_cfg = {
> > +   .vi_num = 1,
> > +   .ui_num = 3,
> > +};
> > +
> 
> I think you should expand that structure with:
> .ccsc = 0,
> .scaler_mask = 0xf,
> .mod_rate = 15000,

I guess you could set higher clock if CLK_SET_RATE_PARENT flag is set to de_clk 
in A83T CCU driver. BSP sets it to 500 MHz, which is a bit high...

Best regards,
Jernej

> 
> Best regards,
> Jernej
> 
> >  static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
> >  
> > .vi_num = 2,
> > .ui_num = 1,
> > 
> > @@ -487,6 +492,10 @@ static const struct sun8i_mixer_cfg
> > sun8i_v3s_mixer_cfg = {
> > 
> >  static const struct of_device_id sun8i_mixer_of_table[] = {
> >  
> > {
> > 
> > +   .compatible = "allwinner,sun8i-a83t-de2-mixer-0",
> > +   .data = _a83t_mixer_cfg,
> > +   },
> > +   {
> > 
> > .compatible = "allwinner,sun8i-v3s-de2-mixer",
> > .data = _v3s_mixer_cfg,
> > 
> > },
> > 
> > --
> > git-series 0.9.1


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


[Bug 103791] Tearing after screen wakeup/on

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #17 from Michel Dänzer  ---
Thanks. I think I see what's happening, but I need some time to think about how
to address it.

Meanwhile, you should be able to re-enable TearFree by forcing a modeset, e.g.
by re-enabling the TearFree property:

xrandr --output DisplayPort-0 --set TearFree on

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 7/7] dt-bindings: tda998x: add the calibration gpio

2017-12-06 Thread Russell King
Add the optional calibration gpio for integrated TDA9950 CEC support.
This GPIO corresponds with the interrupt from the TDA998x, as the
calibration requires driving the interrupt pin low.

Signed-off-by: Russell King 
---
 Documentation/devicetree/bindings/display/bridge/tda998x.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index 24cc2466185a..1a4eaca40d94 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -27,6 +27,9 @@ Required properties;
in question is used. The implementation allows one or two DAIs. If two
DAIs are defined, they must be of different type.
 
+  - nxp,calib-gpios: calibration GPIO, which must correspond with the
+   gpio used for the TDA998x interrupt pin.
+
 [1] Documentation/sound/alsa/soc/DAI.txt
 [2] include/dt-bindings/display/tda998x.h
 
-- 
2.7.4

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


[PATCH v2 4/7] drm/i2c: tda998x: always disable and clear interrupts at probe

2017-12-06 Thread Russell King
Always disable and clear interrupts at probe time to ensure that the
TDA998x is in a sane state.  This ensures that the interrupt line,
which is also the CEC clock calibration signal, is always deasserted.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 661cb8915f2f..e294f5b50236 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1547,6 +1547,15 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
cec_write(priv, REG_CEC_FRO_IM_CLK_CTRL,
CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
 
+   /* ensure interrupts are disabled */
+   cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
+
+   /* clear pending interrupts */
+   cec_read(priv, REG_CEC_RXSHPDINT);
+   reg_read(priv, REG_INT_FLAGS_0);
+   reg_read(priv, REG_INT_FLAGS_1);
+   reg_read(priv, REG_INT_FLAGS_2);
+
/* initialize the optional IRQ */
priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
if (!priv->cec)
@@ -1558,11 +1567,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
/* init read EDID waitqueue and HDP work */
init_waitqueue_head(>wq_edid);
 
-   /* clear pending interrupts */
-   reg_read(priv, REG_INT_FLAGS_0);
-   reg_read(priv, REG_INT_FLAGS_1);
-   reg_read(priv, REG_INT_FLAGS_2);
-
irq_flags =
irqd_get_trigger_type(irq_get_irq_data(client->irq));
irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
-- 
2.7.4

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


[PATCH v2 6/7] drm/i2c: tda998x: add CEC support

2017-12-06 Thread Russell King
The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
onto the same die.  Add support for the TDA9950 CEC engine to the
TDA998x driver.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 209 +++---
 2 files changed, 196 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 3a232f5ff0a1..096d2139e733 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select CEC_NOTIFIER
select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index e294f5b50236..3ad39d018ab6 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -16,8 +16,10 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 
 struct tda998x_audio_port {
@@ -55,6 +59,7 @@ struct tda998x_priv {
struct platform_device *audio_pdev;
struct mutex audio_mutex;
 
+   struct mutex edid_mutex;
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
 
@@ -67,6 +72,9 @@ struct tda998x_priv {
struct drm_connector connector;
 
struct tda998x_audio_port audio_port[2];
+   struct tda9950_glue cec_glue;
+   struct gpio_desc *calib;
+   struct cec_notifier *cec_notify;
 };
 
 #define conn_to_tda998x_priv(x) \
@@ -345,6 +353,12 @@ struct tda998x_priv {
 #define REG_CEC_INTSTATUS0xee/* read */
 # define CEC_INTSTATUS_CEC   (1 << 0)
 # define CEC_INTSTATUS_HDMI  (1 << 1)
+#define REG_CEC_CAL_XOSC_CTRL10xf2
+# define CEC_CAL_XOSC_CTRL1_ENA_CALBIT(0)
+#define REG_CEC_DES_FREQ2 0xf5
+# define CEC_DES_FREQ2_DIS_AUTOCAL BIT(7)
+#define REG_CEC_CLK   0xf6
+# define CEC_CLK_FRO  0x11
 #define REG_CEC_FRO_IM_CLK_CTRL   0xfb/* read/write */
 # define CEC_FRO_IM_CLK_CTRL_GHOST_DIS (1 << 7)
 # define CEC_FRO_IM_CLK_CTRL_ENA_OTP   (1 << 6)
@@ -359,6 +373,7 @@ struct tda998x_priv {
 # define CEC_RXSHPDLEV_HPD(1 << 1)
 
 #define REG_CEC_ENAMODS   0xff/* read/write */
+# define CEC_ENAMODS_EN_CEC_CLK   (1 << 7)
 # define CEC_ENAMODS_DIS_FRO  (1 << 6)
 # define CEC_ENAMODS_DIS_CCLK (1 << 5)
 # define CEC_ENAMODS_EN_RXSENS(1 << 2)
@@ -417,6 +432,114 @@ cec_read(struct tda998x_priv *priv, u8 addr)
return val;
 }
 
+static void cec_enamods(struct tda998x_priv *priv, u8 mods, bool enable)
+{
+   int val = cec_read(priv, REG_CEC_ENAMODS);
+
+   if (val < 0)
+   return;
+
+   if (enable)
+   val |= mods;
+   else
+   val &= ~mods;
+
+   cec_write(priv, REG_CEC_ENAMODS, val);
+}
+
+static void tda998x_cec_set_calibration(struct tda998x_priv *priv, bool enable)
+{
+   if (enable) {
+   u8 val;
+
+   cec_write(priv, 0xf3, 0xc0);
+   cec_write(priv, 0xf4, 0xd4);
+
+   /* Enable automatic calibration mode */
+   val = cec_read(priv, REG_CEC_DES_FREQ2);
+   val &= ~CEC_DES_FREQ2_DIS_AUTOCAL;
+   cec_write(priv, REG_CEC_DES_FREQ2, val);
+
+   /* Enable free running oscillator */
+   cec_write(priv, REG_CEC_CLK, CEC_CLK_FRO);
+   cec_enamods(priv, CEC_ENAMODS_DIS_FRO, false);
+
+   cec_write(priv, REG_CEC_CAL_XOSC_CTRL1,
+ CEC_CAL_XOSC_CTRL1_ENA_CAL);
+   } else {
+   cec_write(priv, REG_CEC_CAL_XOSC_CTRL1, 0);
+   }
+}
+
+/*
+ * Calibration for the internal oscillator: we need to set calibration mode,
+ * and then pulse the IRQ line low for a 10ms ± 1% period.
+ */
+static void tda998x_cec_calibration(struct tda998x_priv *priv)
+{
+   struct gpio_desc *calib = priv->calib;
+
+   mutex_lock(>edid_mutex);
+   if (priv->hdmi->irq > 0)
+   disable_irq(priv->hdmi->irq);
+   gpiod_direction_output(calib, 1);
+   tda998x_cec_set_calibration(priv, true);
+
+   local_irq_disable();
+   gpiod_set_value(calib, 0);
+   mdelay(10);
+   gpiod_set_value(calib, 1);
+   local_irq_enable();
+
+   tda998x_cec_set_calibration(priv, false);
+   gpiod_direction_input(calib);
+   if (priv->hdmi->irq > 0)
+   enable_irq(priv->hdmi->irq);
+   mutex_unlock(>edid_mutex);
+}
+
+static int tda998x_cec_hook_init(void *data)
+{
+   struct tda998x_priv *priv = data;
+   struct gpio_desc *calib;
+
+   

[PATCH v2 3/7] drm/i2c: tda998x: fix error cleanup paths

2017-12-06 Thread Russell King
If tda998x_get_audio_ports() fails, and we requested the interrupt, we
fail to free the interrupt before returning failure.  Rework the failure
cleanup code and exit paths so that we always clean up properly after an
error, and always propagate the error code.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 4aeac2127974..661cb8915f2f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1499,10 +1499,15 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
 
/* read version: */
rev_lo = reg_read(priv, REG_VERSION_LSB);
+   if (rev_lo < 0) {
+   dev_err(>dev, "failed to read version: %d\n", rev_lo);
+   return rev_lo;
+   }
+
rev_hi = reg_read(priv, REG_VERSION_MSB);
-   if (rev_lo < 0 || rev_hi < 0) {
-   ret = rev_lo < 0 ? rev_lo : rev_hi;
-   goto fail;
+   if (rev_hi < 0) {
+   dev_err(>dev, "failed to read version: %d\n", rev_hi);
+   return rev_hi;
}
 
priv->rev = rev_lo | rev_hi << 8;
@@ -1526,7 +1531,7 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
default:
dev_err(>dev, "found unsupported device: %04x\n",
priv->rev);
-   goto fail;
+   return -ENXIO;
}
 
/* after reset, enable DDC: */
@@ -1568,7 +1573,7 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
dev_err(>dev,
"failed to request IRQ#%u: %d\n",
client->irq, ret);
-   goto fail;
+   goto err_irq;
}
 
/* enable HPD irq */
@@ -1591,19 +1596,19 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
 
ret = tda998x_get_audio_ports(priv, np);
if (ret)
-   goto fail;
+   goto err_audio;
 
if (priv->audio_port[0].format != AFMT_UNUSED)
tda998x_audio_codec_init(priv, >dev);
 
return 0;
-fail:
-   /* if encoder_init fails, the encoder slave is never registered,
-* so cleanup here:
-*/
-   if (priv->cec)
-   i2c_unregister_device(priv->cec);
-   return -ENXIO;
+
+err_audio:
+   if (client->irq)
+   free_irq(client->irq, priv);
+err_irq:
+   i2c_unregister_device(priv->cec);
+   return ret;
 }
 
 static void tda998x_encoder_prepare(struct drm_encoder *encoder)
-- 
2.7.4

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


[PATCH] drm/sun4i: Fix uninitialized variables in vi layer

2017-12-06 Thread Jernej Skrabec
min_scale and max_scale in sun8i_vi_layer_atomic_check() can be used
without initialization.

Fix that.

Fixes:  b862a648de3b (drm/sun4i: Add support for HW scaling to DE2)

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index e39af8d377d0..40c3b303068a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -253,6 +253,9 @@ static int sun8i_vi_layer_atomic_check(struct drm_plane 
*plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
+   min_scale = DRM_PLANE_HELPER_NO_SCALING;
+   max_scale = DRM_PLANE_HELPER_NO_SCALING;
+
if (layer->mixer->cfg->scaler_mask & BIT(layer->channel)) {
min_scale = SUN8I_VI_SCALER_SCALE_MIN;
max_scale = SUN8I_VI_SCALER_SCALE_MAX;
-- 
2.15.1

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


[PATCH] video: hd44780: Add hd44780 lcd display driver

2017-12-06 Thread Lars Poeschel
This adds a console driver for hd44780 based character lcd displays and
clones. The driver currently supports 20x4 character displays with
character ROMs A00 and A02.
The hardware wirings to the display have to be supplied to the kernel in
the devicetree. The binding doc has the necessary information.
There are also tons of these cheap displays sold with a serial
interface. Many of them use a simple pcf8574 gpio expanders. An example
for using that kind of display is also in the binding doc.

Signed-off-by: Lars Poeschel 
---
 .../bindings/video/console/hd44780con.txt  |  42 ++
 drivers/video/console/Kconfig  |  13 +
 drivers/video/console/Makefile |   1 +
 drivers/video/console/hd44780con.c | 676 +
 4 files changed, 732 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/console/hd44780con.txt
 create mode 100644 drivers/video/console/hd44780con.c

diff --git a/Documentation/devicetree/bindings/video/console/hd44780con.txt 
b/Documentation/devicetree/bindings/video/console/hd44780con.txt
new file mode 100644
index ..261301eb0c68
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/console/hd44780con.txt
@@ -0,0 +1,42 @@
+Console display driver for Hitachi HD44780 based displays and clones
+
+Required properties:
+- compatible : "hit,hd44780"
+- rs-gpios : GPIO reference for the register select line of the display
+- rw-gpios : GPIO reference for the r/w line of the display
+- e-gpios : GPIO reference for the enable line of the display
+- bl-gpios : GPIO reference for the backlight of the display
+- data-gpios : GPIO reference for the data lines of the display. Currently
+   only the 4 bit mode is supported by the driver. So you have
+   to connect the 4 data lines to DB4 - DB7 of the display.
+- charset-rom : Either "a00" or "a02". The datasheet mentions these two
+   charset roms to be available. Supply the one you have here.
+
+Example:
+
+hd44780con: hd44780@27 {
+   compatible ="hit,hd44780";
+   rs-gpios =  < 0 GPIO_ACTIVE_HIGH>;
+   rw-gpios =  < 1 GPIO_ACTIVE_HIGH>;
+   e-gpios =   < 2 GPIO_ACTIVE_HIGH>;
+   bl-gpios =  < 3 GPIO_ACTIVE_HIGH>;
+   data-gpios =< 4 GPIO_ACTIVE_HIGH>,
+   < 5 GPIO_ACTIVE_HIGH>,
+   < 6 GPIO_ACTIVE_HIGH>,
+   < 7 GPIO_ACTIVE_HIGH>;
+   charset-rom =   "a00";
+};
+
+
+These hd44780 displays often come with some sort of serial interface. The
+cheap ones often only have a pcf8574 gpio expander from nxp on it. You
+connect to your controller via i2c and gpio expander drives the raw lines
+of your display. Such a display would need a devicetree entry for the
+pcf8574 that looks like this:
+
+gpiom27: gpio27@27 {
+   reg = <0x27>;
+   compatible = "nxp,pcf8574";
+   gpio-controller;
+   #gpio-cells = <2>;
+};
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..204e6ddf1417 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -161,5 +161,18 @@ config STI_CONSOLE
   machines.  Say Y here to build support for it into your kernel.
   The alternative is to use your primary serial port as a console.
 
+config HD44780_CONSOLE
+tristate "Hitachi HD44780 20x4 character display as console"
+depends on GPIOLIB
+default n
+help
+  This is a driver that lets you use the cheap lcd 20x4 character
+  display with i2c serial interface using a pcf8574at chip as a
+  console output device. The display is a simple single color
+  character display. It is often referred to as HD44780. To use this
+  driver, you have to connect it to an I2C bus with the lcm1602
+  device. This device contains the pcf8574at chip.
+  This driver only supports the 20x4 character version of the
+  display at the moment.
 endmenu
 
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index db07b784bd2c..1d3df4173280 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_DUMMY_CONSOLE)   += dummycon.o
 obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
 obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
+obj-$(CONFIG_HD44780_CONSOLE) += hd44780con.o
 obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
 obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
 
diff --git a/drivers/video/console/hd44780con.c 
b/drivers/video/console/hd44780con.c
new file mode 100644
index ..c5195410f3bc
--- /dev/null
+++ b/drivers/video/console/hd44780con.c
@@ -0,0 +1,676 @@
+/*
+ *  console driver for hitachi hd44780 20x4 character displays
+ *
+ *  This is a driver allowing you to use a HD44780 character lcd display
+ *  as console output device. Currently only 

[PATCH v2 5/7] drm/i2c: tda9950: add CEC driver

2017-12-06 Thread Russell King
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
but is also integrated into HDMI transceivers such as the TDA9989 and
TDA19989.

The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol.  The driver just has to read and write
the messages, and handle error conditions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 507 ++
 include/linux/platform_data/tda9950.h |  16 ++
 4 files changed, 529 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 include/linux/platform_data/tda9950.h

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index a6c92beb410a..3a232f5ff0a1 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
help
  Support for NXP Semiconductors TDA998X HDMI encoders.
 
+config DRM_I2C_NXP_TDA9950
+   tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+   select CEC_NOTIFIER
+   select CEC_CORE
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index b20100c18ffb..a962f6f08568 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
 
 tda998x-y := tda998x_drv.o
 obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index ..6f7a37ddda05
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,507 @@
+/*
+ *  TDA9950 Consumer Electronics Control driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface.  The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction.  See the TDA9950 data sheet for details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   REG_CSR = 0x00,
+   CSR_BUSY = BIT(7),
+   CSR_INT  = BIT(6),
+   CSR_ERR  = BIT(5),
+
+   REG_CER = 0x01,
+
+   REG_CVR = 0x02,
+
+   REG_CCR = 0x03,
+   CCR_RESET = BIT(7),
+   CCR_ON= BIT(6),
+
+   REG_ACKH = 0x04,
+   REG_ACKL = 0x05,
+
+   REG_CCONR = 0x06,
+   CCONR_ENABLE_ERROR = BIT(4),
+   CCONR_RETRY_MASK = 7,
+
+   REG_CDR0 = 0x07,
+
+   CDR1_REQ = 0x00,
+   CDR1_CNF = 0x01,
+   CDR1_IND = 0x81,
+   CDR1_ERR = 0x82,
+   CDR1_IER = 0x83,
+
+   CDR2_CNF_SUCCESS= 0x00,
+   CDR2_CNF_OFF_STATE  = 0x80,
+   CDR2_CNF_BAD_REQ= 0x81,
+   CDR2_CNF_CEC_ACCESS = 0x82,
+   CDR2_CNF_ARB_ERROR  = 0x83,
+   CDR2_CNF_BAD_TIMING = 0x84,
+   CDR2_CNF_NACK_ADDR  = 0x85,
+   CDR2_CNF_NACK_DATA  = 0x86,
+};
+
+struct tda9950_priv {
+   struct i2c_client *client;
+   struct device *hdmi;
+   struct cec_adapter *adap;
+   struct tda9950_glue *glue;
+   u16 addresses;
+   struct cec_msg rx_msg;
+   struct cec_notifier *notify;
+   bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg;
+   u8 buf[cnt + 1];
+   int ret;
+
+   buf[0] = addr;
+   memcpy(buf + 1, p, cnt);
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.len = cnt + 1;
+   msg.buf = buf;
+
+   dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+   ret = i2c_transfer(client->adapter, , 1);
+   if (ret < 0)
+   dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
addr);
+   return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+   tda9950_write_range(client, addr, , 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg[2];
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = cnt;
+   msg[1].buf = p;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+   if (ret < 0)
+   dev_err(>dev, "Error %d reading from cec:0x%x\n", ret, 
addr);
+
+   dev_dbg(>dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+   return ret;
+}
+
+static u8 

[PATCH v2 1/7] drm/i2c: tda998x: move mutex/waitqueue/timer/work init early

2017-12-06 Thread Russell King
Move the mutex, waitqueue, timer and detect work initialisation early
in the driver's initialisation, rather than being after we've registered
the CEC device.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 127815253a84..7f4dbca7f7f4 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1476,7 +1476,11 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
u32 video;
int rev_lo, rev_hi, ret;
 
-   mutex_init(>audio_mutex); /* Protect access from audio thread */
+   mutex_init(>mutex);   /* protect the page access */
+   mutex_init(>audio_mutex); /* protect access from audio thread */
+   init_waitqueue_head(>edid_delay_waitq);
+   timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
+   INIT_WORK(>detect_work, tda998x_detect_work);
 
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
@@ -1490,11 +1494,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
if (!priv->cec)
return -ENODEV;
 
-   mutex_init(>mutex);   /* protect the page access */
-   init_waitqueue_head(>edid_delay_waitq);
-   timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
-   INIT_WORK(>detect_work, tda998x_detect_work);
-
/* wake up the device: */
cec_write(priv, REG_CEC_ENAMODS,
CEC_ENAMODS_EN_RXSENS | CEC_ENAMODS_EN_HDMI);
-- 
2.7.4

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


[PATCH v2 0/7] TDA998x CEC support

2017-12-06 Thread Russell King - ARM Linux
Hi,

This patch series adds CEC support to the DRM TDA998x driver.  The
TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
address from the HDMI encoder.

Implementation of the CEC part is separate to allow independent CEC
implementations, or independent HDMI implementations (since the
TDA9950 may be a separate device.)

 .../devicetree/bindings/display/bridge/tda998x.txt |   3 +
 drivers/gpu/drm/i2c/Kconfig|   6 +
 drivers/gpu/drm/i2c/Makefile   |   1 +
 drivers/gpu/drm/i2c/tda9950.c  | 507 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 246 --
 include/linux/platform_data/tda9950.h  |  16 +
 6 files changed, 751 insertions(+), 28 deletions(-)

v2: updated DT property.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/7] drm/i2c: tda998x: move CEC device initialisation later

2017-12-06 Thread Russell King
We no longer use the CEC client to access the CEC part itself, so we can
move this later in the initialisation sequence.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7f4dbca7f7f4..4aeac2127974 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
priv->cec_addr = 0x34 + (client->addr & 0x03);
priv->current_page = 0xff;
priv->hdmi = client;
-   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
-   if (!priv->cec)
-   return -ENODEV;
 
/* wake up the device: */
cec_write(priv, REG_CEC_ENAMODS,
@@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
 
/* initialize the optional IRQ */
+   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
+   if (!priv->cec)
+   return -ENODEV;
+
if (client->irq) {
unsigned long irq_flags;
 
-- 
2.7.4

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


[Bug 95306] Random Blank(black) screens on "Carrizo"

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #73 from Andrew  ---
i also noticed that the grub screen is in high resolution (probably 1024 )
without me specifying any params. Also the boot messages are flying in the high
resolution, until something is loaded and then all goes dark

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/nouveau/bar/gf100: fix hang when calling ->fini() before ->init()

2017-12-06 Thread Jon Hunter

On 06/12/17 09:22, Guillaume Tucker wrote:
> On 05/12/17 18:32, Ben Skeggs wrote:
>> On Wed, Dec 6, 2017 at 12:30 AM, Jon Hunter  wrote:
>>
>>>
>>> On 04/12/17 18:37, Guillaume Tucker wrote:
 If the firmware fails to load then ->fini() will be called before the
 device has been initialised, causing the kernel to hang while trying
 to write to a register.  Add a test in ->fini() to avoid this issue.

 This fixes a kernel hang on tegra124.

 Fixes: b17de35a2ebbe ("drm/nouveau/bar: implement bar1 teardown")
 Signed-off-by: Guillaume Tucker 
 CC: Ben Skeggs 
 ---
  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
>>> b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
 index a3ba7f50198b..95e2aba64aad 100644
 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
 +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
 @@ -43,9 +43,12 @@ gf100_bar_bar1_wait(struct nvkm_bar *base)
  }

  void
 -gf100_bar_bar1_fini(struct nvkm_bar *bar)
 +gf100_bar_bar1_fini(struct nvkm_bar *base)
  {
 - nvkm_mask(bar->subdev.device, 0x001704, 0x8000, 0x);
 + struct nvkm_device *device = base->subdev.device;
 +
 + if (base->subdev.oneinit)
 + nvkm_mask(device, 0x001704, 0x8000, 0x);
  }

  void
>>>
>>> I have tested this and it works for me. Thanks for fixing this! Would be
>>> good to get Ben's ACK, but you can have my ...
>>>
>> I'd love to get a good explanation as to why it hangs without this
>> change,
>> as, on the surface, it's not immediately obvious as to why it's hanging.
> 
> To be fair I'm not entirely sure either why this causes a hang, I
> haven't read the TRM...  The iomem has been mapped at this point,
> so accessing the register should work.  One clue is when you look
> at _bar1_init(), the 0x1704 register is initialised with
> some (device instance?) memory address.  So it's possible that
> the hardware does something special when you set this to 0 as in
> _bar1_fini(), which may fail in particular if it was previously
> not initialised with a valid address.
> 
> This is merely guesswork, would be interested to find out the
> real explanation though.

OK, well that's no good. It's a good pointer, but we need to make sure
we understand the root of this hang. I will see if I have sometime to
dig into this further, maybe next week.

Cheers
Jon

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


[Bug 95306] Random Blank(black) screens on "Carrizo"

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #72 from Andrew  ---
Created attachment 136007
  --> https://bugs.freedesktop.org/attachment.cgi?id=136007=edit
log files with amdgpu.cg_mask set

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 95306] Random Blank(black) screens on "Carrizo"

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #71 from Andrew  ---
adding amdgpu.cg_mask=0xFFFB semed to keep  boot messages for a bit longer,
but then again - black screen of beauty :(
adding powerplay) made no difference

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/4] drm/etnaviv: lock BOs after all other submit work is done

2017-12-06 Thread Lucas Stach
Populating objects, adding them to the GPU VM and patching/validating
the command stream might take a lot of CPU time. There is no reason to
hold all object reservations during that time.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index ae0bf3e94580..f3001476bc06 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -515,10 +515,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
if (ret)
goto err_submit_objects;
 
-   ret = submit_lock_objects(submit, );
-   if (ret)
-   goto err_submit_objects;
-
if (!etnaviv_cmd_validate_one(gpu, stream, args->stream_size / 4,
  relocs, args->nr_relocs)) {
ret = -EINVAL;
@@ -533,10 +529,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
}
}
 
-   ret = submit_fence_sync(submit);
-   if (ret)
-   goto err_submit_objects;
-
ret = submit_pin_objects(submit);
if (ret)
goto err_submit_objects;
@@ -553,6 +545,14 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
memcpy(submit->cmdbuf.vaddr, stream, args->stream_size);
submit->cmdbuf.user_size = ALIGN(args->stream_size, 8);
 
+   ret = submit_lock_objects(submit, );
+   if (ret)
+   goto err_submit_objects;
+
+   ret = submit_fence_sync(submit);
+   if (ret)
+   goto err_submit_objects;
+
ret = etnaviv_sched_push_job(>sched_entity[args->pipe], submit);
if (ret)
goto err_submit_objects;
-- 
2.11.0

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


[PATCH 1/4] drm/etnaviv: hook up DRM GPU scheduler

2017-12-06 Thread Lucas Stach
This hooks in the DRM GPU scheduler. No improvement yet, as all the
dependency handling is still done in etnaviv_gem_submit. This just
replaces the actual GPU submit by passing through the scheduler.

Allows to get rid of the retire worker, as this is now driven by the
scheduler.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/Kconfig  |   1 +
 drivers/gpu/drm/etnaviv/Makefile |   3 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|  16 
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|   7 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|   1 +
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  11 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 115 +---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  14 +--
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 125 +++
 drivers/gpu/drm/etnaviv/etnaviv_sched.h  |  22 +
 10 files changed, 222 insertions(+), 93 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sched.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sched.h

diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index 3f58b4077767..e5bfeca361bd 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -11,6 +11,7 @@ config DRM_ETNAVIV
select WANT_DEV_COREDUMP
select CMA if HAVE_DMA_CONTIGUOUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS
+   select DRM_SCHED
help
  DRM driver for Vivante GPUs.
 
diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 1281c8d4fae5..9bb780c22501 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -12,6 +12,7 @@ etnaviv-y := \
etnaviv_iommu_v2.o \
etnaviv_iommu.o \
etnaviv_mmu.o \
-   etnaviv_perfmon.o
+   etnaviv_perfmon.o \
+   etnaviv_sched.o
 
 obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv.o
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 6faf4042db23..8a73414682b2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -101,12 +101,25 @@ static void load_gpu(struct drm_device *dev)
 
 static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_file_private *ctx;
+   int i;
 
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
+   for (i = 0; i < ETNA_MAX_PIPES; i++) {
+   struct etnaviv_gpu *gpu = priv->gpu[i];
+
+   if (gpu) {
+   drm_sched_entity_init(>sched,
+   >sched_entity[i],
+   >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL],
+   32, NULL);
+   }
+   }
+
file->driver_priv = ctx;
 
return 0;
@@ -126,6 +139,9 @@ static void etnaviv_postclose(struct drm_device *dev, 
struct drm_file *file)
if (gpu->lastctx == ctx)
gpu->lastctx = NULL;
mutex_unlock(>lock);
+
+   drm_sched_entity_fini(>sched,
+ >sched_entity[i]);
}
}
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index a54f0b758a5c..1f055d931c6c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct etnaviv_cmdbuf;
 struct etnaviv_gpu;
@@ -42,11 +43,11 @@ struct etnaviv_gem_object;
 struct etnaviv_gem_submit;
 
 struct etnaviv_file_private {
-   /* currently we don't do anything useful with this.. but when
-* per-context address spaces are supported we'd keep track of
+   /*
+* When per-context address spaces are supported we'd keep track of
 * the context's page-tables here.
 */
-   int dummy;
+   struct drm_sched_entity sched_entity[ETNA_MAX_PIPES];
 };
 
 struct etnaviv_drm_private {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index c30964152381..ae352f2a77f9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -101,6 +101,7 @@ struct etnaviv_gem_submit_bo {
  * make it easier to unwind when things go wrong, etc).
  */
 struct etnaviv_gem_submit {
+   struct drm_sched_job sched_job;
struct kref refcount;
struct etnaviv_gpu *gpu;
struct dma_fence *out_fence, *in_fence;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 919c8dc39f32..0bc89e4daade 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ 

[PATCH 0/4] Etnaviv GPU scheduler

2017-12-06 Thread Lucas Stach
Hi all,

this hooks up the AMDGPU/DRM GPU scheduler in etnaviv. This depends on both
the etnaviv job lifetime fixes series, as well as the AMDGPU scheduler move.
Please keep this in mind while reviewing.

The scheduler has 4 main benefits to etnaviv:
1. Cross GPU/device synchronization is handled in the kernel without blocking
   the submitting userspace process.
2. Fairness in GPU time is improved, as all processes get to submit to the
   HW in a round robin fashion. Before this a single application could
   pretty much DoS the GPU by submitting jobs with minimal dependencies.
3. GPU resets loose a lot less state. The scheduler keeps track of the
   HW submitted jobs and replays innocent jobs after a GPU reset. Thus
   isolation between different processes using the GPU is improved as
   a process hanging the GPU will not impact other jobs anymore.
4. It provides useful tracepoints to keep track of the GPU execution.

Regards,
Lucas

Lucas Stach (4):
  drm/etnaviv: hook up DRM GPU scheduler
  drm/etnaviv: move dependency handling to scheduler
  drm/etnaviv: lock BOs after all other submit work is done
  drm/etnaviv: replace hangcheck with scheduler timeout

 drivers/gpu/drm/etnaviv/Kconfig  |   1 +
 drivers/gpu/drm/etnaviv/Makefile |   3 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|  16 ++
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|   7 +-
 drivers/gpu/drm/etnaviv/etnaviv_dump.c   |  21 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|   4 +
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  65 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 250 +--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  28 +--
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 169 ++
 drivers/gpu/drm/etnaviv/etnaviv_sched.h  |  34 
 11 files changed, 339 insertions(+), 259 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sched.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sched.h

-- 
2.11.0

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


[PATCH 4/4] drm/etnaviv: replace hangcheck with scheduler timeout

2017-12-06 Thread Lucas Stach
This replaces the etnaviv internal hangcheck logic with the job timeout
handling provided by the DRM scheduler. This simplifies the driver further
and allows to replay jobs after a GPU reset, so only minimal state is lost.

This introduces a user-visible change in that we don't allow jobs to run
indefinitely as long as they make progress anymore, as this introduces
quality of service issues when multiple processes are using the GPU.
Userspace is now responsible to flush jobs in a way that the finish in a
reasonable time, where reasonable is currently defined as less than 500ms.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_dump.c   | 21 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 89 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 11 +---
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 43 +++---
 drivers/gpu/drm/etnaviv/etnaviv_sched.h  | 12 
 6 files changed, 63 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c 
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 6d0909c589d1..48aef6cf6a42 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -20,9 +20,13 @@
 #include "etnaviv_gem.h"
 #include "etnaviv_gpu.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_sched.h"
 #include "state.xml.h"
 #include "state_hi.xml.h"
 
+static bool etnaviv_dump_core = true;
+module_param_named(dump_core, etnaviv_dump_core, bool, 0600);
+
 struct core_dump_iterator {
void *start;
struct etnaviv_dump_object_header *hdr;
@@ -121,10 +125,16 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
struct etnaviv_vram_mapping *vram;
struct etnaviv_gem_object *obj;
struct etnaviv_gem_submit *submit;
+   struct drm_sched_job *s_job;
unsigned int n_obj, n_bomap_pages;
size_t file_size, mmu_size;
__le64 *bomap, *bomap_start;
 
+   /* Only catch the first event, or when manually re-armed */
+   if (!etnaviv_dump_core)
+   return;
+   etnaviv_dump_core = false;
+
mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
 
/* We always dump registers, mmu, ring and end marker */
@@ -135,10 +145,13 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mmu_size + gpu->buffer.size;
 
/* Add in the active command buffers */
-   list_for_each_entry(submit, >active_submit_list, node) {
+   spin_lock(>sched.job_list_lock);
+   list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
+   submit = to_etnaviv_submit(s_job);
file_size += submit->cmdbuf.size;
n_obj++;
}
+   spin_unlock(>sched.job_list_lock);
 
/* Add in the active buffer objects */
list_for_each_entry(vram, >mmu->mappings, mmu_node) {
@@ -180,10 +193,14 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
  gpu->buffer.size,
  etnaviv_cmdbuf_get_va(>buffer));
 
-   list_for_each_entry(submit, >active_submit_list, node)
+   spin_lock(>sched.job_list_lock);
+   list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
+   submit = to_etnaviv_submit(s_job);
etnaviv_core_dump_mem(, ETDUMP_BUF_CMD,
  submit->cmdbuf.vaddr, submit->cmdbuf.size,
  etnaviv_cmdbuf_get_va(>cmdbuf));
+   }
+   spin_unlock(>sched.job_list_lock);
 
/* Reserve space for the bomap */
if (n_bomap_pages) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index f3001476bc06..bd5bf7910d12 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -543,7 +543,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
goto err_submit_objects;
 
memcpy(submit->cmdbuf.vaddr, stream, args->stream_size);
-   submit->cmdbuf.user_size = ALIGN(args->stream_size, 8);
 
ret = submit_lock_objects(submit, );
if (ret)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d5d5cfab8477..6b22726f072d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -37,9 +37,6 @@ static const struct platform_device_id gpu_ids[] = {
{ },
 };
 
-static bool etnaviv_dump_core = true;
-module_param_named(dump_core, etnaviv_dump_core, bool, 0600);
-
 /*
  * Driver functions:
  */
@@ -913,38 +910,24 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct 
seq_file *m)
 }
 #endif
 
-/*
- * Hangcheck detection for locked gpu:
- */
-static void recover_worker(struct work_struct *work)
+void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
 {
-   struct etnaviv_gpu *gpu = 

[PATCH 2/4] drm/etnaviv: move dependency handling to scheduler

2017-12-06 Thread Lucas Stach
Move the fence dependency handling to the scheduler where it belongs.
Jobs with unsignaled dependencies just get to sit in the scheduler queue
without holding any locks.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|  3 ++
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 37 +++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 48 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  3 --
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 45 ++
 5 files changed, 69 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index ae352f2a77f9..93e696fcc14f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -94,6 +94,9 @@ struct etnaviv_gem_submit_bo {
u32 flags;
struct etnaviv_gem_object *obj;
struct etnaviv_vram_mapping *mapping;
+   struct dma_fence *excl;
+   unsigned int nr_shared;
+   struct dma_fence **shared;
 };
 
 /* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 0bc89e4daade..ae0bf3e94580 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -170,29 +170,34 @@ static int submit_lock_objects(struct etnaviv_gem_submit 
*submit,
return ret;
 }
 
-static int submit_fence_sync(const struct etnaviv_gem_submit *submit)
+static int submit_fence_sync(struct etnaviv_gem_submit *submit)
 {
-   unsigned int context = submit->gpu->fence_context;
int i, ret = 0;
 
for (i = 0; i < submit->nr_bos; i++) {
-   struct etnaviv_gem_object *etnaviv_obj = submit->bos[i].obj;
+   struct etnaviv_gem_submit_bo *bo = >bos[i];
+   struct reservation_object *robj = bo->obj->resv;
bool write = submit->bos[i].flags & ETNA_SUBMIT_BO_WRITE;
-   bool explicit = !!(submit->flags & ETNA_SUBMIT_NO_IMPLICIT);
 
-   ret = etnaviv_gpu_fence_sync_obj(etnaviv_obj, context, write,
-explicit);
-   if (ret)
-   break;
-   }
+   if (!write) {
+   ret = reservation_object_reserve_shared(robj);
+   if (ret)
+   return ret;
+   }
+
+   if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
+   return 0;
+
+   if (write) {
+   ret = reservation_object_get_fences_rcu(robj, >excl,
+   >nr_shared,
+   >shared);
+   if (ret)
+   return ret;
+   } else {
+   submit->bos[i].excl = 
reservation_object_get_excl_rcu(robj);
+   }
 
-   if (submit->flags & ETNA_SUBMIT_FENCE_FD_IN) {
-   /*
-* Wait if the fence is from a foreign context, or if the fence
-* array contains any fence from a foreign context.
-*/
-   if (!dma_fence_match_context(submit->in_fence, context))
-   ret = dma_fence_wait(submit->in_fence, true);
}
 
return ret;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index bfa54abbbdd1..d5d5cfab8477 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1078,54 +1078,6 @@ static struct dma_fence *etnaviv_gpu_fence_alloc(struct 
etnaviv_gpu *gpu)
return >base;
 }
 
-int etnaviv_gpu_fence_sync_obj(struct etnaviv_gem_object *etnaviv_obj,
-   unsigned int context, bool exclusive, bool explicit)
-{
-   struct reservation_object *robj = etnaviv_obj->resv;
-   struct reservation_object_list *fobj;
-   struct dma_fence *fence;
-   int i, ret;
-
-   if (!exclusive) {
-   ret = reservation_object_reserve_shared(robj);
-   if (ret)
-   return ret;
-   }
-
-   if (explicit)
-   return 0;
-
-   /*
-* If we have any shared fences, then the exclusive fence
-* should be ignored as it will already have been signalled.
-*/
-   fobj = reservation_object_get_list(robj);
-   if (!fobj || fobj->shared_count == 0) {
-   /* Wait on any existing exclusive fence which isn't our own */
-   fence = reservation_object_get_excl(robj);
-   if (fence && fence->context != context) {
-   ret = dma_fence_wait(fence, true);
-   if (ret)
-   return ret;
-   }
-  

[pull] amdgpu and ttm drm-fixes-4.15

2017-12-06 Thread Alex Deucher
Hi Dave,

Fixes for 4.15:
- Add licenses to files that were missing it
- huge page fixes for ttm

The following changes since commit 503505bfea19b7d69e2572297e6defa0f9c2404e:

  Merge branch 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2017-12-01 09:15:57 +1000)

are available in the git repository at:

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

for you to fetch changes up to e60bb46b5754727c7643cc5bb7b005c49f869930:

  drm/ttm: swap consecutive allocated pooled pages v4 (2017-12-06 09:28:31 
-0500)


Alex Deucher (2):
  drm/amdgpu: add license to Makefiles
  drm/amdgpu: add license to files where it was missing

Christian König (2):
  drm/ttm: swap consecutive allocated cached pages v3
  drm/ttm: swap consecutive allocated pooled pages v4

Roger He (5):
  drm/ttm: use NUM_PAGES_TO_ALLOC always
  drm/ttm: add page order in page pool
  drm/ttm: add set_pages_wb for handling page order more than zero
  drm/ttm: add page order support in ttm_pages_put
  drm/ttm: roundup the shrink request to prevent skip huge pool

 drivers/gpu/drm/amd/acp/Makefile   | 21 +
 drivers/gpu/drm/amd/amdgpu/Makefile| 22 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  | 24 +-
 drivers/gpu/drm/amd/amdkfd/Makefile| 22 -
 drivers/gpu/drm/amd/display/Makefile   | 21 +
 drivers/gpu/drm/amd/display/amdgpu_dm/Makefile | 21 +
 drivers/gpu/drm/amd/display/dc/Makefile| 21 +
 drivers/gpu/drm/amd/display/dc/basics/Makefile | 21 +
 drivers/gpu/drm/amd/display/dc/bios/Makefile   | 21 +
 drivers/gpu/drm/amd/display/dc/calcs/Makefile  | 21 +
 drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 22 +
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dc_helper.c | 22 +
 drivers/gpu/drm/amd/display/dc/dce/Makefile| 21 +
 drivers/gpu/drm/amd/display/dc/dce100/Makefile | 21 +
 .../drm/amd/display/dc/dce100/dce100_resource.c|  2 +-
 .../drm/amd/display/dc/dce100/dce100_resource.h| 23 +
 drivers/gpu/drm/amd/display/dc/dce110/Makefile | 21 +
 .../drm/amd/display/dc/dce110/dce110_resource.c|  2 +-
 .../display/dc/dce110/dce110_timing_generator_v.c  | 23 +
 drivers/gpu/drm/amd/display/dc/dce112/Makefile | 21 +
 drivers/gpu/drm/amd/display/dc/dce120/Makefile | 23 -
 drivers/gpu/drm/amd/display/dc/dce80/Makefile  | 21 +
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile  | 21 +
 drivers/gpu/drm/amd/display/dc/dml/Makefile| 21 +
 drivers/gpu/drm/amd/display/dc/gpio/Makefile   | 21 +
 drivers/gpu/drm/amd/display/dc/i2caux/Makefile | 21 +
 .../gpu/drm/amd/display/dc/inc/hw/link_encoder.h   | 22 +
 .../gpu/drm/amd/display/dc/inc/hw/stream_encoder.h | 22 +
 drivers/gpu/drm/amd/display/dc/irq/Makefile| 21 +
 drivers/gpu/drm/amd/display/dc/virtual/Makefile| 21 +
 .../gpu/drm/amd/display/modules/freesync/Makefile  | 21 +
 drivers/gpu/drm/amd/lib/Makefile   | 21 +
 drivers/gpu/drm/amd/powerplay/Makefile | 22 -
 drivers/gpu/drm/amd/powerplay/hwmgr/Makefile   | 22 -
 .../gpu/drm/amd/powerplay/hwmgr/pp_overdriver.c| 24 +-
 drivers/gpu/drm/amd/powerplay/inc/smu72.h  | 24 +-
 drivers/gpu/drm/amd/powerplay/inc/smu72_discrete.h | 24 +-
 drivers/gpu/drm/amd/powerplay/smumgr/Makefile  | 22 -
 drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h| 24 +-
 drivers/gpu/drm/ttm/ttm_page_alloc.c   | 98 --
 42 files changed, 875 insertions(+), 38 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Lucas Stach
Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Thanks,
Lucas

Lucas Stach (2):
  drm: move amd_gpu_scheduler into common location
  drm/sched: move fence slab handling to module init/exit

 drivers/gpu/drm/Kconfig|   5 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
 drivers/gpu/drm/scheduler/Makefile |   4 +
 .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 ++---
 drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
 include/drm/gpu_scheduler.h| 173 
 .../drm/gpu_scheduler_trace.h  |  14 +-
 .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
 35 files changed, 529 insertions(+), 523 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
 create mode 100644 drivers/gpu/drm/scheduler/Makefile
 rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
 rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
 create mode 100644 include/drm/gpu_scheduler.h
 rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
include/drm/gpu_scheduler_trace.h (82%)
 rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h (95%)

-- 
2.11.0

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


[PATCH v2 1/2] drm: move amd_gpu_scheduler into common location

2017-12-06 Thread Lucas Stach
This moves and renames the AMDGPU scheduler to a common location in DRM
in order to facilitate re-use by other drivers. This is mostly a straight
forward rename with no code changes.

One notable exception is the function to_drm_sched_fence(), which is no
longer a inline header function to avoid the need to export the
drm_sched_fence_ops_scheduled and drm_sched_fence_ops_finished structures.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/Kconfig|   5 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
 drivers/gpu/drm/scheduler/Makefile |   4 +
 .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 ++---
 drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 118 
 include/drm/gpu_scheduler.h| 176 
 .../drm/gpu_scheduler_trace.h  |  14 +-
 .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
 35 files changed, 530 insertions(+), 517 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
 create mode 100644 drivers/gpu/drm/scheduler/Makefile
 rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
 rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (59%)
 create mode 100644 include/drm/gpu_scheduler.h
 rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
include/drm/gpu_scheduler_trace.h (82%)
 rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h (95%)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4d9f21831741..ee38a3db1890 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -149,6 +149,10 @@ config DRM_VM
bool
depends on DRM && MMU
 
+config DRM_SCHED
+   tristate
+   depends on DRM
+
 source "drivers/gpu/drm/i2c/Kconfig"
 
 source "drivers/gpu/drm/arm/Kconfig"
@@ -178,6 +182,7 @@ config DRM_AMDGPU
depends on DRM && PCI && MMU
select FW_LOADER
 select DRM_KMS_HELPER
+   select DRM_SCHED
 select DRM_TTM
select POWER_SUPPLY
select HWMON
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e9500844333e..1f6ba9e34e31 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
 obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
+obj-$(CONFIG_DRM_SCHED)+= scheduler/
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 78d609123420..5f690f023e75 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -115,10 +115,7 @@ amdgpu-y += \
 amdgpu-y += amdgpu_cgs.o
 
 # GPU scheduler
-amdgpu-y += \
-   ../scheduler/gpu_scheduler.o \
-   ../scheduler/sched_fence.o \
-   amdgpu_job.o
+amdgpu-y += amdgpu_job.o
 
 # ACP componet
 ifneq ($(CONFIG_DRM_AMD_ACP),)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5e2958a79928..5c8648ec2cd2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "dm_pp_interface.h"
@@ -68,7 +69,6 @@
 #include "amdgpu_vcn.h"
 

[Bug 104143] r600/sb: clobbers gl_Position -> gl_FragCoord

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104143

--- Comment #9 from Gert Wollny  ---
Patch: https://patchwork.freedesktop.org/patch/192036/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/2] drm/sched: move fence slab handling to module init/exit

2017-12-06 Thread Lucas Stach
This is the only part of the scheduler which must not be called from
different drivers. Move it to module init/exit so it is done a single
time when loading the scheduler.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  8 
 drivers/gpu/drm/scheduler/sched_fence.c | 12 
 include/drm/gpu_scheduler.h |  3 ---
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1d8011bca182..51b76688ab90 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -912,10 +912,6 @@ static int __init amdgpu_init(void)
if (r)
goto error_fence;
 
-   r = drm_sched_fence_slab_init();
-   if (r)
-   goto error_sched;
-
if (vgacon_text_force()) {
DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
return -EINVAL;
@@ -928,9 +924,6 @@ static int __init amdgpu_init(void)
/* let modprobe override vga console setting */
return pci_register_driver(pdriver);
 
-error_sched:
-   amdgpu_fence_slab_fini();
-
 error_fence:
amdgpu_sync_fini();
 
@@ -944,7 +937,6 @@ static void __exit amdgpu_exit(void)
pci_unregister_driver(pdriver);
amdgpu_unregister_atpx_handler();
amdgpu_sync_fini();
-   drm_sched_fence_slab_fini();
amdgpu_fence_slab_fini();
 }
 
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index f6f2955890c4..69aab086b913 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -29,7 +29,7 @@
 
 static struct kmem_cache *sched_fence_slab;
 
-int drm_sched_fence_slab_init(void)
+static int __init drm_sched_fence_slab_init(void)
 {
sched_fence_slab = kmem_cache_create(
"drm_sched_fence", sizeof(struct drm_sched_fence), 0,
@@ -39,14 +39,12 @@ int drm_sched_fence_slab_init(void)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(drm_sched_fence_slab_init);
 
-void drm_sched_fence_slab_fini(void)
+static void __exit drm_sched_fence_slab_fini(void)
 {
rcu_barrier();
kmem_cache_destroy(sched_fence_slab);
 }
-EXPORT_SYMBOL_GPL(drm_sched_fence_slab_fini);
 
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence)
 {
@@ -185,3 +183,9 @@ struct drm_sched_fence *drm_sched_fence_create(struct 
drm_sched_entity *entity,
 
return fence;
 }
+
+module_init(drm_sched_fence_slab_init);
+module_exit(drm_sched_fence_slab_fini);
+
+MODULE_DESCRIPTION("DRM GPU scheduler");
+MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index d29da4cbb042..dfd54fb94e10 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -155,9 +155,6 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,
 void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
 struct drm_sched_rq *rq);
 
-int drm_sched_fence_slab_init(void);
-void drm_sched_fence_slab_fini(void);
-
 struct drm_sched_fence *drm_sched_fence_create(
struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
-- 
2.11.0

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


[PATCH] drm/fb-helper: Fix a potential NULL dereference

2017-12-06 Thread Dan Carpenter
We recently modified drm_fb_helper_single_add_all_connectors() to allow
NULL "fb_helper" pointers.  But  the problem is that it gets
dereferenced before we checked for NULL.

Fixes: c777990fb45b ("drm/fb-helper: Handle function NULL argument")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6654f2f87775..f73457e5bbbc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -178,7 +178,6 @@ EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
  */
 int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
 {
-   struct drm_device *dev = fb_helper->dev;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
int i, ret = 0;
@@ -187,7 +186,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
return 0;
 
mutex_lock(_helper->lock);
-   drm_connector_list_iter_begin(dev, _iter);
+   drm_connector_list_iter_begin(fb_helper->dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
if (ret)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 95306] Random Blank(black) screens on "Carrizo"

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #70 from Andrew  ---
this bug/thread looks very simillar to what i ahve been expiriencing once i
tried to move from fglx + fedora 22 to over amdgpu + fedora27.
Please take a look@ the bug i filed :
https://bugzilla.redhat.com/show_bug.cgi?id=1520676

// i'll shamelessly x-ref these 2 threads.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/9] drm: Add Content Protection property

2017-12-06 Thread Sean Paul
On Tue, Dec 5, 2017 at 12:11 PM, C, Ramalingam  wrote:
>
>
>
> Best Regards,
> Ramalingam C
>
>> -Original Message-
>> From: Sean Paul [mailto:seanp...@chromium.org]
>> Sent: Tuesday, December 5, 2017 8:07 PM
>> To: C, Ramalingam 
>> Cc: dri-devel ; Hans Verkuil
>> 
>> Subject: Re: [PATCH v3 3/9] drm: Add Content Protection property
>>
>> On Tue, Dec 5, 2017 at 9:04 AM, Ramalingam C 
>> wrote:
>> >
>> >
>> > On Tuesday 05 December 2017 01:37 PM, Hans Verkuil wrote:
>> >
>> > On 12/05/2017 06:15 AM, Sean Paul wrote:
>> >
>> > This patch adds a new optional connector property to allow userspace
>> > to enable protection over the content it is displaying. This will
>> > typically be implemented by the driver using HDCP.
>> >
>> > The property is a tri-state with the following values:
>> > - OFF: Self explanatory, no content protection
>> > - DESIRED: Userspace requests that the driver enable protection
>> > - ENABLED: Once the driver has authenticated the link, it sets this
>> > value
>> >
>> > The driver is responsible for downgrading ENABLED to DESIRED if the
>> > link becomes unprotected. The driver should also maintain the
>> > desiredness of protection across hotplug/dpms/suspend.
>> >
>> > If this looks familiar, I posted [1] this 3 years ago. We have been
>> > using this in ChromeOS across exynos, mediatek, and rockchip over that
>> > time.
>> >
>> > Changes in v2:
>> >  - Pimp kerneldoc for content_protection_property (Daniel)
>> >  - Drop sysfs attribute
>> > Changes in v3:
>> >  - None
>> >
>> > Cc: Daniel Vetter 
>> > Signed-off-by: Sean Paul 
>> >
>> > [1]
>> > https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.
>> > html
>> > ---
>> >  drivers/gpu/drm/drm_atomic.c|  8 +
>> >  drivers/gpu/drm/drm_connector.c | 71
>> > +
>> >  drivers/gpu/drm/drm_sysfs.c |  1 +
>> >  include/drm/drm_connector.h | 16 ++
>> >  include/uapi/drm/drm_mode.h |  4 +++
>> >  5 files changed, 100 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic.c
>> > b/drivers/gpu/drm/drm_atomic.c index c2da5585e201..676025d755b2 100644
>> > --- a/drivers/gpu/drm/drm_atomic.c
>> > +++ b/drivers/gpu/drm/drm_atomic.c
>> > @@ -1196,6 +1196,12 @@ static int
>> > drm_atomic_connector_set_property(struct
>> > drm_connector *connector,
>> >   state->picture_aspect_ratio = val;
>> >   } else if (property == connector->scaling_mode_property) {
>> >   state->scaling_mode = val;
>> > + } else if (property == connector->content_protection_property) { if
>> > + (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
>> DRM_DEBUG_KMS("only
>> > + drivers can set CP Enabled\n"); return -EINVAL; }
>> > + state->content_protection = val;
>> >   } else if (connector->funcs->atomic_set_property) {
>> >   return connector->funcs->atomic_set_property(connector,
>> >   state, property, val);
>> > @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct
>> > drm_connector *connector,
>> >   *val = state->picture_aspect_ratio;
>> >   } else if (property == connector->scaling_mode_property) {
>> >   *val = state->scaling_mode;
>> > + } else if (property == connector->content_protection_property) {
>> > + *val = state->content_protection;
>> >   } else if (connector->funcs->atomic_get_property) {
>> >   return connector->funcs->atomic_get_property(connector,
>> >   state, property, val);
>> > diff --git a/drivers/gpu/drm/drm_connector.c
>> > b/drivers/gpu/drm/drm_connector.c index f14b48e6e839..8626aa8f485e
>> > 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list
>> > drm_tv_subconnector_enum_list[] = {
>> > DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>> >   drm_tv_subconnector_enum_list)
>> >
>> > +static struct drm_prop_enum_list drm_cp_enum_list[] = {
>> > +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
>> > +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
>> > +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" }, };
>> > +DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>> drm_cp_enum_list)
>> > +
>> >  /**
>> >   * DOC: standard connector properties
>> >   *
>> > @@ -764,6 +771,34 @@
>> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>> >   *  after modeset, the kernel driver may set this to "BAD" and issue a
>> >   *  hotplug uevent. Drivers should update this value using
>> >   *  drm_mode_connector_set_link_status_property().
>> > + * Content Protection:
>> > + * This property is used by userspace to request the kernel protect
>> > + future
>> > + * content communicated over the link. When requested, kernel will
>> > + apply
>> > + * the appropriate means of protection (most often HDCP), and use the
>> > + * property to tell userspace the 

Re: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

2017-12-06 Thread kbuild test robot
Hi Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15-rc2 next-20171206]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-swap-consecutive-allocated-pooled-pages-v4/20171206-191635
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x014-201749 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/ttm/ttm_page_alloc.c: In function 'ttm_get_pages':
>> drivers/gpu//drm/ttm/ttm_page_alloc.c:924:2: error: 'first' undeclared 
>> (first use in this function)
 first = count;
 ^
   drivers/gpu//drm/ttm/ttm_page_alloc.c:924:2: note: each undeclared 
identifier is reported only once for each function it appears in

vim +/first +924 drivers/gpu//drm/ttm/ttm_page_alloc.c

   919  
   920  INIT_LIST_HEAD();
   921  r = ttm_page_pool_get_pages(pool, , flags, cstate,
   922  npages - count, 0);
   923  
 > 924  first = count;
   925  list_for_each_entry(p, , lru) {
   926  struct page *tmp = p;
   927  
   928  /* Swap the pages if we detect consecutive order */
   929  if (count > first && pages[count - 1] == tmp - 1)
   930  swap(tmp, pages[count - 1]);
   931  pages[count++] = tmp;
   932  }
   933  
   934  if (r) {
   935  /* If there is any pages in the list put them back to
   936   * the pool.
   937   */
   938  pr_debug("Failed to allocate extra pages for large 
request\n");
   939  ttm_put_pages(pages, count, flags, cstate);
   940  return r;
   941  }
   942  
   943  return 0;
   944  }
   945  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104090

--- Comment #12 from Hein-Pieter van Braam  ---
How do I establish whether that is what is happening or not? It sure looks like
that's what's going on though.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] gpu: drm: sti: Adopt SPDX identifiers

2017-12-06 Thread Benjamin Gaignard
2017-12-06 15:26 GMT+01:00 Vincent ABRIOU :
> Benjamin,
>
> The patch is fine for me:
>
> Acked-by: Vincent Abriou 
>
> Vincent

Thanks,

Pushed in drm-misc-next

Benjamin

>
> On 12/06/2017 12:29 PM, Benjamin Gaignard wrote:
>> Add SPDX identifiers to files under sti directory
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>   drivers/gpu/drm/sti/sti_awg_utils.c| 2 +-
>>   drivers/gpu/drm/sti/sti_awg_utils.h| 2 +-
>>   drivers/gpu/drm/sti/sti_compositor.c   | 2 +-
>>   drivers/gpu/drm/sti/sti_compositor.h   | 2 +-
>>   drivers/gpu/drm/sti/sti_crtc.c | 2 +-
>>   drivers/gpu/drm/sti/sti_crtc.h | 2 +-
>>   drivers/gpu/drm/sti/sti_cursor.c   | 2 +-
>>   drivers/gpu/drm/sti/sti_cursor.h   | 2 +-
>>   drivers/gpu/drm/sti/sti_drv.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_drv.h  | 2 +-
>>   drivers/gpu/drm/sti/sti_dvo.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_gdp.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_gdp.h  | 2 +-
>>   drivers/gpu/drm/sti/sti_hda.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
>>   drivers/gpu/drm/sti/sti_hdmi.h | 2 +-
>>   drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 2 +-
>>   drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h | 2 +-
>>   drivers/gpu/drm/sti/sti_hqvdp.c| 2 +-
>>   drivers/gpu/drm/sti/sti_hqvdp_lut.h| 2 +-
>>   drivers/gpu/drm/sti/sti_mixer.c| 2 +-
>>   drivers/gpu/drm/sti/sti_mixer.h| 2 +-
>>   drivers/gpu/drm/sti/sti_plane.c| 2 +-
>>   drivers/gpu/drm/sti/sti_plane.h| 2 +-
>>   drivers/gpu/drm/sti/sti_tvout.c| 2 +-
>>   drivers/gpu/drm/sti/sti_vid.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_vid.h  | 2 +-
>>   drivers/gpu/drm/sti/sti_vtg.c  | 2 +-
>>   drivers/gpu/drm/sti/sti_vtg.h  | 2 +-
>>   29 files changed, 29 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sti/sti_awg_utils.c 
>> b/drivers/gpu/drm/sti/sti_awg_utils.c
>> index 2da7d6866d5d..7c5a7830b6e8 100644
>> --- a/drivers/gpu/drm/sti/sti_awg_utils.c
>> +++ b/drivers/gpu/drm/sti/sti_awg_utils.c
>> @@ -1,7 +1,7 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2014
>>* Author: Vincent Abriou  for STMicroelectronics.
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include "sti_awg_utils.h"
>> diff --git a/drivers/gpu/drm/sti/sti_awg_utils.h 
>> b/drivers/gpu/drm/sti/sti_awg_utils.h
>> index 45d599bd570a..258a568f050b 100644
>> --- a/drivers/gpu/drm/sti/sti_awg_utils.h
>> +++ b/drivers/gpu/drm/sti/sti_awg_utils.h
>> @@ -1,7 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>>   /*
>>* Copyright (C) STMicroelectronics SA 2014
>>* Author: Vincent Abriou  for STMicroelectronics.
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #ifndef _STI_AWG_UTILS_H_
>> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
>> b/drivers/gpu/drm/sti/sti_compositor.c
>> index 6e4bf68262db..021b8fcaa0b9 100644
>> --- a/drivers/gpu/drm/sti/sti_compositor.c
>> +++ b/drivers/gpu/drm/sti/sti_compositor.c
>> @@ -1,9 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2014
>>* Authors: Benjamin Gaignard 
>>*  Fabien Dessenne 
>>*  for STMicroelectronics.
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include 
>> diff --git a/drivers/gpu/drm/sti/sti_compositor.h 
>> b/drivers/gpu/drm/sti/sti_compositor.h
>> index 2952a2d25a52..ac4bb3834810 100644
>> --- a/drivers/gpu/drm/sti/sti_compositor.h
>> +++ b/drivers/gpu/drm/sti/sti_compositor.h
>> @@ -1,9 +1,9 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>>   /*
>>* Copyright (C) STMicroelectronics SA 2014
>>* Authors: Benjamin Gaignard 
>>*  Fabien Dessenne 
>>*  for STMicroelectronics.
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #ifndef _STI_COMPOSITOR_H_
>> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
>> index e8a4d48e985a..21e50d7b1f86 100644
>> --- a/drivers/gpu/drm/sti/sti_crtc.c
>> +++ b/drivers/gpu/drm/sti/sti_crtc.c
>> @@ -1,9 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2014
>>* Authors: Benjamin Gaignard 
>>*  Fabien Dessenne 
>>*  for STMicroelectronics.
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include 
>> diff --git a/drivers/gpu/drm/sti/sti_crtc.h b/drivers/gpu/drm/sti/sti_crtc.h

Re: [PATCH] gpu: drm: stm: Adopt SPDX identifiers

2017-12-06 Thread Benjamin Gaignard
2017-12-06 15:26 GMT+01:00 Vincent ABRIOU :
> Benjamin,
>
> The patch is fine for me:
>
> Acked-by: Vincent Abriou 
>
> Vincent

Thanks,

Pushed in drm-misc-next

Benjamin

>
> On 12/06/2017 12:29 PM, Benjamin Gaignard wrote:
>> Add SPDX identifiers to files under stm directory
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>   drivers/gpu/drm/stm/drv.c | 3 +--
>>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 3 +--
>>   drivers/gpu/drm/stm/ltdc.c| 3 +--
>>   drivers/gpu/drm/stm/ltdc.h| 3 +--
>>   4 files changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
>> index c857663eafc2..2d6e9ca0450b 100644
>> --- a/drivers/gpu/drm/stm/drv.c
>> +++ b/drivers/gpu/drm/stm/drv.c
>> @@ -1,3 +1,4 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2017
>>*
>> @@ -5,8 +6,6 @@
>>*  Yannick Fertre 
>>*  Fabien Dessenne 
>>*  Mickael Reulier 
>> - *
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include 
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
>> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index e5b6310240fe..2e53410189f8 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -1,10 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2017
>>*
>>* Authors: Philippe Cornu 
>>*  Yannick Fertre 
>> - *
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include 
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 735c9081202a..34b91d049481 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -1,3 +1,4 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>   /*
>>* Copyright (C) STMicroelectronics SA 2017
>>*
>> @@ -5,8 +6,6 @@
>>*  Yannick Fertre 
>>*  Fabien Dessenne 
>>*  Mickael Reulier 
>> - *
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #include 
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index ae437557d715..d5da74d24995 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>>   /*
>>* Copyright (C) STMicroelectronics SA 2017
>>*
>> @@ -5,8 +6,6 @@
>>*  Yannick Fertre 
>>*  Fabien Dessenne 
>>*  Mickael Reulier 
>> - *
>> - * License terms:  GNU General Public License (GPL), version 2
>>*/
>>
>>   #ifndef _LTDC_H_
>>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] video: hd44780: Add hd44780 lcd display driver

2017-12-06 Thread Geert Uytterhoeven
Hi Lars,

On Wed, Dec 6, 2017 at 2:52 PM, Lars Poeschel  wrote:
> This adds a console driver for hd44780 based character lcd displays and
> clones. The driver currently supports 20x4 character displays with
> character ROMs A00 and A02.
> The hardware wirings to the display have to be supplied to the kernel in
> the devicetree. The binding doc has the necessary information.
> There are also tons of these cheap displays sold with a serial
> interface. Many of them use a simple pcf8574 gpio expanders. An example
> for using that kind of display is also in the binding doc.
>
> Signed-off-by: Lars Poeschel 

Thanks for your patch!

> ---
>  .../bindings/video/console/hd44780con.txt  |  42 ++
>  drivers/video/console/Kconfig  |  13 +
>  drivers/video/console/Makefile |   1 +
>  drivers/video/console/hd44780con.c | 676 
> +

I'm wondering if you could implement this on top of the existing charlcd
framework:

drivers/auxdisplay/charlcd.c
include/misc/charlcd.h

which can use the existing hd44780 backend:

Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
drivers/auxdisplay/hd44780.c

That way it can be used on other character LCDs, like the one supported by
drivers/auxdisplay/panel.c.

Thanks!

P.S. I did something similar a long time ago, cfr.
 https://github.com/geertu/hd44780/blob/master/lcdcon.c

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [PATCH v3 4/9] drm: Add some HDCP related #defines

2017-12-06 Thread Alex Deucher
On Tue, Dec 5, 2017 at 6:12 PM, Chris Wilson  wrote:
> Quoting Sean Paul (2017-12-05 05:15:03)
>> In preparation for implementing HDCP in i915, add some HDCP related
>> register offsets and defines. The dpcd register offsets will go in
>> drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
>> will get stuffed in drm_hdcp.h, which is new.
>>
>> Changes in v2:
>> - drm_hdcp.h gets MIT license (Daniel)
>
> Speaking of licences, what's the right spdx for drm files?
> SPDX-License-Identifier: (GPL-2.0+ OR MIT) ?
> It looks like we've already grown quite a few BSD-unfriendly files...

Should be MIT.

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


[Bug 104143] r600/sb: clobbers gl_Position -> gl_FragCoord

2017-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104143

--- Comment #8 from Gert Wollny  ---
I found the problem: 

if KC0[0].x == index (=0):  

1  x: ADD_INTT0.x,  KC0[0].x, [0xfffe -nan].x
2  x: MOVA_INT   __.x,  T0.x

Address register is now -2 and hence,  in the next step R1 is unconditionally
written, and this is actually the gl_Vertex value ...

3  z: MOVR[3+AR].z,  0
   w: MOVR[3+AR].w,  [0x3dcd 0.1].x

that is here used to evaluate the gl_Posuition. 

5  x: MUL_IEEE   T0.x,  KC0[1].w, R1.x
   y: MUL_IEEE   T0.y,  KC0[1].z, R1.x
6  t: MULADD_IEEET0.y,  KC0[2].z, R1.y, T0.y   SCL_212
...

In the un-optimized shader R[3+AR].w is only written to if (KC0[0].x >= 2), and
hence AR >= 0;

I.e. the sb optimizer is to aggressive in optimizing away the conditional
blocks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] gpu: drm: sti: Adopt SPDX identifiers

2017-12-06 Thread Vincent ABRIOU
Benjamin,

The patch is fine for me:

Acked-by: Vincent Abriou 

Vincent

On 12/06/2017 12:29 PM, Benjamin Gaignard wrote:
> Add SPDX identifiers to files under sti directory
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>   drivers/gpu/drm/sti/sti_awg_utils.c| 2 +-
>   drivers/gpu/drm/sti/sti_awg_utils.h| 2 +-
>   drivers/gpu/drm/sti/sti_compositor.c   | 2 +-
>   drivers/gpu/drm/sti/sti_compositor.h   | 2 +-
>   drivers/gpu/drm/sti/sti_crtc.c | 2 +-
>   drivers/gpu/drm/sti/sti_crtc.h | 2 +-
>   drivers/gpu/drm/sti/sti_cursor.c   | 2 +-
>   drivers/gpu/drm/sti/sti_cursor.h   | 2 +-
>   drivers/gpu/drm/sti/sti_drv.c  | 2 +-
>   drivers/gpu/drm/sti/sti_drv.h  | 2 +-
>   drivers/gpu/drm/sti/sti_dvo.c  | 2 +-
>   drivers/gpu/drm/sti/sti_gdp.c  | 2 +-
>   drivers/gpu/drm/sti/sti_gdp.h  | 2 +-
>   drivers/gpu/drm/sti/sti_hda.c  | 2 +-
>   drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
>   drivers/gpu/drm/sti/sti_hdmi.h | 2 +-
>   drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 2 +-
>   drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h | 2 +-
>   drivers/gpu/drm/sti/sti_hqvdp.c| 2 +-
>   drivers/gpu/drm/sti/sti_hqvdp_lut.h| 2 +-
>   drivers/gpu/drm/sti/sti_mixer.c| 2 +-
>   drivers/gpu/drm/sti/sti_mixer.h| 2 +-
>   drivers/gpu/drm/sti/sti_plane.c| 2 +-
>   drivers/gpu/drm/sti/sti_plane.h| 2 +-
>   drivers/gpu/drm/sti/sti_tvout.c| 2 +-
>   drivers/gpu/drm/sti/sti_vid.c  | 2 +-
>   drivers/gpu/drm/sti/sti_vid.h  | 2 +-
>   drivers/gpu/drm/sti/sti_vtg.c  | 2 +-
>   drivers/gpu/drm/sti/sti_vtg.h  | 2 +-
>   29 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sti/sti_awg_utils.c 
> b/drivers/gpu/drm/sti/sti_awg_utils.c
> index 2da7d6866d5d..7c5a7830b6e8 100644
> --- a/drivers/gpu/drm/sti/sti_awg_utils.c
> +++ b/drivers/gpu/drm/sti/sti_awg_utils.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2014
>* Author: Vincent Abriou  for STMicroelectronics.
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include "sti_awg_utils.h"
> diff --git a/drivers/gpu/drm/sti/sti_awg_utils.h 
> b/drivers/gpu/drm/sti/sti_awg_utils.h
> index 45d599bd570a..258a568f050b 100644
> --- a/drivers/gpu/drm/sti/sti_awg_utils.h
> +++ b/drivers/gpu/drm/sti/sti_awg_utils.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>   /*
>* Copyright (C) STMicroelectronics SA 2014
>* Author: Vincent Abriou  for STMicroelectronics.
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #ifndef _STI_AWG_UTILS_H_
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
> b/drivers/gpu/drm/sti/sti_compositor.c
> index 6e4bf68262db..021b8fcaa0b9 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -1,9 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2014
>* Authors: Benjamin Gaignard 
>*  Fabien Dessenne 
>*  for STMicroelectronics.
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include 
> diff --git a/drivers/gpu/drm/sti/sti_compositor.h 
> b/drivers/gpu/drm/sti/sti_compositor.h
> index 2952a2d25a52..ac4bb3834810 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.h
> +++ b/drivers/gpu/drm/sti/sti_compositor.h
> @@ -1,9 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>   /*
>* Copyright (C) STMicroelectronics SA 2014
>* Authors: Benjamin Gaignard 
>*  Fabien Dessenne 
>*  for STMicroelectronics.
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #ifndef _STI_COMPOSITOR_H_
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index e8a4d48e985a..21e50d7b1f86 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -1,9 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2014
>* Authors: Benjamin Gaignard 
>*  Fabien Dessenne 
>*  for STMicroelectronics.
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include 
> diff --git a/drivers/gpu/drm/sti/sti_crtc.h b/drivers/gpu/drm/sti/sti_crtc.h
> index 3f2d89a3634d..d87c488212d6 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.h
> +++ b/drivers/gpu/drm/sti/sti_crtc.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>   /*
>* Copyright (C) 

Re: [PATCH] gpu: drm: stm: Adopt SPDX identifiers

2017-12-06 Thread Vincent ABRIOU
Benjamin,

The patch is fine for me:

Acked-by: Vincent Abriou 

Vincent

On 12/06/2017 12:29 PM, Benjamin Gaignard wrote:
> Add SPDX identifiers to files under stm directory
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>   drivers/gpu/drm/stm/drv.c | 3 +--
>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 3 +--
>   drivers/gpu/drm/stm/ltdc.c| 3 +--
>   drivers/gpu/drm/stm/ltdc.h| 3 +--
>   4 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index c857663eafc2..2d6e9ca0450b 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2017
>*
> @@ -5,8 +6,6 @@
>*  Yannick Fertre 
>*  Fabien Dessenne 
>*  Mickael Reulier 
> - *
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include 
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index e5b6310240fe..2e53410189f8 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -1,10 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2017
>*
>* Authors: Philippe Cornu 
>*  Yannick Fertre 
> - *
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 735c9081202a..34b91d049481 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
>* Copyright (C) STMicroelectronics SA 2017
>*
> @@ -5,8 +6,6 @@
>*  Yannick Fertre 
>*  Fabien Dessenne 
>*  Mickael Reulier 
> - *
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #include 
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index ae437557d715..d5da74d24995 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>   /*
>* Copyright (C) STMicroelectronics SA 2017
>*
> @@ -5,8 +6,6 @@
>*  Yannick Fertre 
>*  Fabien Dessenne 
>*  Mickael Reulier 
> - *
> - * License terms:  GNU General Public License (GPL), version 2
>*/
>   
>   #ifndef _LTDC_H_
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 5/7] drm/i2c: tda9950: add CEC driver

2017-12-06 Thread Hans Verkuil
Hi Russell,

Some small comments below:

On 12/06/17 13:35, Russell King wrote:
> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
> but is also integrated into HDMI transceivers such as the TDA9989 and
> TDA19989.
> 
> The TDA9950 contains a command processor which handles retransmissions
> and the low level bus protocol.  The driver just has to read and write
> the messages, and handle error conditions.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/Kconfig   |   5 +
>  drivers/gpu/drm/i2c/Makefile  |   1 +
>  drivers/gpu/drm/i2c/tda9950.c | 507 
> ++
>  include/linux/platform_data/tda9950.h |  16 ++
>  4 files changed, 529 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>  create mode 100644 include/linux/platform_data/tda9950.h
> 
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index a6c92beb410a..3a232f5ff0a1 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
>   help
> Support for NXP Semiconductors TDA998X HDMI encoders.
>  
> +config DRM_I2C_NXP_TDA9950
> + tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
> + select CEC_NOTIFIER
> + select CEC_CORE
> +
>  endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index b20100c18ffb..a962f6f08568 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>  
>  tda998x-y := tda998x_drv.o
>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
> new file mode 100644
> index ..6f7a37ddda05
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/tda9950.c
> @@ -0,0 +1,507 @@
> +/*
> + *  TDA9950 Consumer Electronics Control driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control
> + * interface.  The host interface is similar to a mailbox: the data
> + * registers starting at REG_CDR0 are written to send a command to the
> + * internal CPU, and replies are read from these registers.
> + *
> + * As the data registers represent a mailbox, they must be accessed
> + * as a single I2C transaction.  See the TDA9950 data sheet for details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + REG_CSR = 0x00,
> + CSR_BUSY = BIT(7),
> + CSR_INT  = BIT(6),
> + CSR_ERR  = BIT(5),
> +
> + REG_CER = 0x01,
> +
> + REG_CVR = 0x02,
> +
> + REG_CCR = 0x03,
> + CCR_RESET = BIT(7),
> + CCR_ON= BIT(6),
> +
> + REG_ACKH = 0x04,
> + REG_ACKL = 0x05,
> +
> + REG_CCONR = 0x06,
> + CCONR_ENABLE_ERROR = BIT(4),
> + CCONR_RETRY_MASK = 7,
> +
> + REG_CDR0 = 0x07,
> +
> + CDR1_REQ = 0x00,
> + CDR1_CNF = 0x01,
> + CDR1_IND = 0x81,
> + CDR1_ERR = 0x82,
> + CDR1_IER = 0x83,
> +
> + CDR2_CNF_SUCCESS= 0x00,
> + CDR2_CNF_OFF_STATE  = 0x80,
> + CDR2_CNF_BAD_REQ= 0x81,
> + CDR2_CNF_CEC_ACCESS = 0x82,
> + CDR2_CNF_ARB_ERROR  = 0x83,
> + CDR2_CNF_BAD_TIMING = 0x84,
> + CDR2_CNF_NACK_ADDR  = 0x85,
> + CDR2_CNF_NACK_DATA  = 0x86,
> +};
> +
> +struct tda9950_priv {
> + struct i2c_client *client;
> + struct device *hdmi;
> + struct cec_adapter *adap;
> + struct tda9950_glue *glue;
> + u16 addresses;
> + struct cec_msg rx_msg;
> + struct cec_notifier *notify;
> + bool open;
> +};
> +
> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, 
> int cnt)
> +{
> + struct i2c_msg msg;
> + u8 buf[cnt + 1];
> + int ret;
> +
> + buf[0] = addr;
> + memcpy(buf + 1, p, cnt);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = cnt + 1;
> + msg.buf = buf;
> +
> + dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
> +
> + ret = i2c_transfer(client->adapter, , 1);
> + if (ret < 0)
> + dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
> addr);
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
> +{
> + tda9950_write_range(client, addr, , 1);
> +}
> +
> +static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
> cnt)
> +{
> + struct i2c_msg msg[2];
> + int ret;
> +
> + msg[0].addr = client->addr;
> + msg[0].flags = 0;
> + msg[0].len = 1;
> + msg[0].buf = 
> + msg[1].addr = client->addr;
> + msg[1].flags = I2C_M_RD;
> + msg[1].len = 

Re: [PATCH v2 4/7] drm/i2c: tda998x: always disable and clear interrupts at probe

2017-12-06 Thread Hans Verkuil
On 12/06/17 13:35, Russell King wrote:
> Always disable and clear interrupts at probe time to ensure that the
> TDA998x is in a sane state.  This ensures that the interrupt line,
> which is also the CEC clock calibration signal, is always deasserted.
> 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 661cb8915f2f..e294f5b50236 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1547,6 +1547,15 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   cec_write(priv, REG_CEC_FRO_IM_CLK_CTRL,
>   CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
> CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
>  
> + /* ensure interrupts are disabled */
> + cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
> +
> + /* clear pending interrupts */
> + cec_read(priv, REG_CEC_RXSHPDINT);
> + reg_read(priv, REG_INT_FLAGS_0);
> + reg_read(priv, REG_INT_FLAGS_1);
> + reg_read(priv, REG_INT_FLAGS_2);
> +
>   /* initialize the optional IRQ */
>   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
>   if (!priv->cec)
> @@ -1558,11 +1567,6 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   /* init read EDID waitqueue and HDP work */
>   init_waitqueue_head(>wq_edid);
>  
> - /* clear pending interrupts */
> - reg_read(priv, REG_INT_FLAGS_0);
> - reg_read(priv, REG_INT_FLAGS_1);
> - reg_read(priv, REG_INT_FLAGS_2);
> -
>   irq_flags =
>   irqd_get_trigger_type(irq_get_irq_data(client->irq));
>   irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
> 

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


Re: [PATCH v2 3/7] drm/i2c: tda998x: fix error cleanup paths

2017-12-06 Thread Hans Verkuil
On 12/06/17 13:35, Russell King wrote:
> If tda998x_get_audio_ports() fails, and we requested the interrupt, we
> fail to free the interrupt before returning failure.  Rework the failure
> cleanup code and exit paths so that we always clean up properly after an
> error, and always propagate the error code.
> 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++-
>  1 file changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 4aeac2127974..661cb8915f2f 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1499,10 +1499,15 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>  
>   /* read version: */
>   rev_lo = reg_read(priv, REG_VERSION_LSB);
> + if (rev_lo < 0) {
> + dev_err(>dev, "failed to read version: %d\n", rev_lo);
> + return rev_lo;
> + }
> +
>   rev_hi = reg_read(priv, REG_VERSION_MSB);
> - if (rev_lo < 0 || rev_hi < 0) {
> - ret = rev_lo < 0 ? rev_lo : rev_hi;
> - goto fail;
> + if (rev_hi < 0) {
> + dev_err(>dev, "failed to read version: %d\n", rev_hi);
> + return rev_hi;
>   }
>  
>   priv->rev = rev_lo | rev_hi << 8;
> @@ -1526,7 +1531,7 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   default:
>   dev_err(>dev, "found unsupported device: %04x\n",
>   priv->rev);
> - goto fail;
> + return -ENXIO;
>   }
>  
>   /* after reset, enable DDC: */
> @@ -1568,7 +1573,7 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   dev_err(>dev,
>   "failed to request IRQ#%u: %d\n",
>   client->irq, ret);
> - goto fail;
> + goto err_irq;
>   }
>  
>   /* enable HPD irq */
> @@ -1591,19 +1596,19 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>  
>   ret = tda998x_get_audio_ports(priv, np);
>   if (ret)
> - goto fail;
> + goto err_audio;
>  
>   if (priv->audio_port[0].format != AFMT_UNUSED)
>   tda998x_audio_codec_init(priv, >dev);
>  
>   return 0;
> -fail:
> - /* if encoder_init fails, the encoder slave is never registered,
> -  * so cleanup here:
> -  */
> - if (priv->cec)
> - i2c_unregister_device(priv->cec);
> - return -ENXIO;
> +
> +err_audio:
> + if (client->irq)
> + free_irq(client->irq, priv);
> +err_irq:
> + i2c_unregister_device(priv->cec);
> + return ret;
>  }
>  
>  static void tda998x_encoder_prepare(struct drm_encoder *encoder)
> 

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


Re: [PATCH v2 2/7] drm/i2c: tda998x: move CEC device initialisation later

2017-12-06 Thread Hans Verkuil
On 12/06/17 13:35, Russell King wrote:
> We no longer use the CEC client to access the CEC part itself, so we can
> move this later in the initialisation sequence.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 7f4dbca7f7f4..4aeac2127974 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   priv->cec_addr = 0x34 + (client->addr & 0x03);
>   priv->current_page = 0xff;
>   priv->hdmi = client;
> - priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
> - if (!priv->cec)
> - return -ENODEV;
>  
>   /* wake up the device: */
>   cec_write(priv, REG_CEC_ENAMODS,
> @@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
> CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
>  
>   /* initialize the optional IRQ */
> + priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
> + if (!priv->cec)
> + return -ENODEV;
> +

I'd move this up to before the 'initialize the optional IRQ' comment, since
that should stay with the 'if (client->irq) {' line below.

>   if (client->irq) {
>   unsigned long irq_flags;
>  
> 

After that change you can add my:

Acked-by: Hans Verkuil 

Regards,

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


Re: [PATCH v2 1/7] drm/i2c: tda998x: move mutex/waitqueue/timer/work init early

2017-12-06 Thread Hans Verkuil
On 12/06/17 13:35, Russell King wrote:
> Move the mutex, waitqueue, timer and detect work initialisation early
> in the driver's initialisation, rather than being after we've registered
> the CEC device.
> 
> Signed-off-by: Russell King 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 127815253a84..7f4dbca7f7f4 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1476,7 +1476,11 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   u32 video;
>   int rev_lo, rev_hi, ret;
>  
> - mutex_init(>audio_mutex); /* Protect access from audio thread */
> + mutex_init(>mutex);   /* protect the page access */
> + mutex_init(>audio_mutex); /* protect access from audio thread */
> + init_waitqueue_head(>edid_delay_waitq);
> + timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
> + INIT_WORK(>detect_work, tda998x_detect_work);
>  
>   priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
>   priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
> @@ -1490,11 +1494,6 @@ static int tda998x_create(struct i2c_client *client, 
> struct tda998x_priv *priv)
>   if (!priv->cec)
>   return -ENODEV;
>  
> - mutex_init(>mutex);   /* protect the page access */
> - init_waitqueue_head(>edid_delay_waitq);
> - timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
> - INIT_WORK(>detect_work, tda998x_detect_work);
> -
>   /* wake up the device: */
>   cec_write(priv, REG_CEC_ENAMODS,
>   CEC_ENAMODS_EN_RXSENS | CEC_ENAMODS_EN_HDMI);
> 

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


Re: [PATCH v2 6/7] drm/i2c: tda998x: add CEC support

2017-12-06 Thread Hans Verkuil
Hi Russell,

Thanks for this patch series!

On 12/06/17 13:35, Russell King wrote:
> The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
> onto the same die.  Add support for the TDA9950 CEC engine to the
> TDA998x driver.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/Kconfig   |   1 +
>  drivers/gpu/drm/i2c/tda998x_drv.c | 209 
> +++---
>  2 files changed, 196 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index 3a232f5ff0a1..096d2139e733 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -22,6 +22,7 @@ config DRM_I2C_SIL164
>  config DRM_I2C_NXP_TDA998X
>   tristate "NXP Semiconductors TDA998X HDMI encoder"
>   default m if DRM_TILCDC
> + select CEC_NOTIFIER

I believe this should be 'select CEC_CORE if CEC_NOTIFIER', conform the
other drivers that do something similar.

Otherwise if tda9950 is configured as a module, and this as built-in, then
cec is built as a module as well and this can't find the cec functions from
the module.

Regards,

Hans

>   select SND_SOC_HDMI_CODEC if SND_SOC
>   help
> Support for NXP Semiconductors TDA998X HDMI encoders.
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index e294f5b50236..3ad39d018ab6 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -16,8 +16,10 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +31,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  
>  struct tda998x_audio_port {
> @@ -55,6 +59,7 @@ struct tda998x_priv {
>   struct platform_device *audio_pdev;
>   struct mutex audio_mutex;
>  
> + struct mutex edid_mutex;
>   wait_queue_head_t wq_edid;
>   volatile int wq_edid_wait;
>  
> @@ -67,6 +72,9 @@ struct tda998x_priv {
>   struct drm_connector connector;
>  
>   struct tda998x_audio_port audio_port[2];
> + struct tda9950_glue cec_glue;
> + struct gpio_desc *calib;
> + struct cec_notifier *cec_notify;
>  };
>  
>  #define conn_to_tda998x_priv(x) \
> @@ -345,6 +353,12 @@ struct tda998x_priv {
>  #define REG_CEC_INTSTATUS  0xee/* read */
>  # define CEC_INTSTATUS_CEC (1 << 0)
>  # define CEC_INTSTATUS_HDMI(1 << 1)
> +#define REG_CEC_CAL_XOSC_CTRL10xf2
> +# define CEC_CAL_XOSC_CTRL1_ENA_CAL  BIT(0)
> +#define REG_CEC_DES_FREQ2 0xf5
> +# define CEC_DES_FREQ2_DIS_AUTOCAL BIT(7)
> +#define REG_CEC_CLK   0xf6
> +# define CEC_CLK_FRO  0x11
>  #define REG_CEC_FRO_IM_CLK_CTRL   0xfb/* read/write */
>  # define CEC_FRO_IM_CLK_CTRL_GHOST_DIS (1 << 7)
>  # define CEC_FRO_IM_CLK_CTRL_ENA_OTP   (1 << 6)
> @@ -359,6 +373,7 @@ struct tda998x_priv {
>  # define CEC_RXSHPDLEV_HPD(1 << 1)
>  
>  #define REG_CEC_ENAMODS   0xff/* read/write */
> +# define CEC_ENAMODS_EN_CEC_CLK   (1 << 7)
>  # define CEC_ENAMODS_DIS_FRO  (1 << 6)
>  # define CEC_ENAMODS_DIS_CCLK (1 << 5)
>  # define CEC_ENAMODS_EN_RXSENS(1 << 2)
> @@ -417,6 +432,114 @@ cec_read(struct tda998x_priv *priv, u8 addr)
>   return val;
>  }
>  
> +static void cec_enamods(struct tda998x_priv *priv, u8 mods, bool enable)
> +{
> + int val = cec_read(priv, REG_CEC_ENAMODS);
> +
> + if (val < 0)
> + return;
> +
> + if (enable)
> + val |= mods;
> + else
> + val &= ~mods;
> +
> + cec_write(priv, REG_CEC_ENAMODS, val);
> +}
> +
> +static void tda998x_cec_set_calibration(struct tda998x_priv *priv, bool 
> enable)
> +{
> + if (enable) {
> + u8 val;
> +
> + cec_write(priv, 0xf3, 0xc0);
> + cec_write(priv, 0xf4, 0xd4);
> +
> + /* Enable automatic calibration mode */
> + val = cec_read(priv, REG_CEC_DES_FREQ2);
> + val &= ~CEC_DES_FREQ2_DIS_AUTOCAL;
> + cec_write(priv, REG_CEC_DES_FREQ2, val);
> +
> + /* Enable free running oscillator */
> + cec_write(priv, REG_CEC_CLK, CEC_CLK_FRO);
> + cec_enamods(priv, CEC_ENAMODS_DIS_FRO, false);
> +
> + cec_write(priv, REG_CEC_CAL_XOSC_CTRL1,
> +   CEC_CAL_XOSC_CTRL1_ENA_CAL);
> + } else {
> + cec_write(priv, REG_CEC_CAL_XOSC_CTRL1, 0);
> + }
> +}
> +
> +/*
> + * Calibration for the internal oscillator: we need to set calibration mode,
> + * and then pulse the IRQ line low for a 10ms ± 1% period.
> + */
> +static void tda998x_cec_calibration(struct tda998x_priv *priv)
> +{
> + struct gpio_desc *calib = priv->calib;
> +
> + mutex_lock(>edid_mutex);
> + if (priv->hdmi->irq > 0)
> + disable_irq(priv->hdmi->irq);
> + 

Re: [RESEND PATCH 4/4] drm/meson: Add missing VPU init

2017-12-06 Thread Chris Wilson
Quoting Neil Armstrong (2017-12-06 12:03:59)
> On 06/12/2017 13:02, Chris Wilson wrote:
> > Quoting Neil Armstrong (2017-12-06 11:54:28)
> >> The VPU init misses these configurations values.
> >>
> >> Signed-off-by: Neil Armstrong 
> >> ---
> >>  drivers/gpu/drm/meson/meson_drv.c   | 9 +
> >>  drivers/gpu/drm/meson/meson_registers.h | 4 
> >>  2 files changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> >> b/drivers/gpu/drm/meson/meson_drv.c
> >> index 3b804fd..f9ad0e9 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.c
> >> +++ b/drivers/gpu/drm/meson/meson_drv.c
> >> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
> >> .max_register   = 0x1000,
> >>  };
> >>  
> >> +static void meson_vpu_init(struct meson_drm *priv)
> >> +{
> >> +   writel_relaxed(0x21, priv->io_base + 
> >> _REG(VPU_RDARB_MODE_L1C1));
> >> +   writel_relaxed(0x1, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
> >> +   writel_relaxed(0x90, priv->io_base + 
> >> _REG(VPU_RDARB_MODE_L2C1));
> >> +   writel_relaxed(0x2, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
> >> +}
> > 
> >> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
> >> b/drivers/gpu/drm/meson/meson_registers.h
> >> index 2847381..bca8714 100644
> >> --- a/drivers/gpu/drm/meson/meson_registers.h
> >> +++ b/drivers/gpu/drm/meson/meson_registers.h
> >> @@ -1363,6 +1363,10 @@
> >>  #define VPU_PROT3_STAT_1 0x277a
> >>  #define VPU_PROT3_STAT_2 0x277b
> >>  #define VPU_PROT3_REQ_ONOFF 0x277c
> >> +#define VPU_RDARB_MODE_L1C1 0x2790
> >> +#define VPU_RDARB_MODE_L1C2 0x2799
> > 
> > Hmm, not naturally aligned for writel. Is the register width correct,
> > address correct, or this really is an unaligned iowrite?
> 
> The registers are aligned with the documentation, then are used with the 
> _REG() macro
> to align them with the bus (on top of the file).

Oh, that surprised me.
Acked-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND PATCH 4/4] drm/meson: Add missing VPU init

2017-12-06 Thread Neil Armstrong
On 06/12/2017 13:02, Chris Wilson wrote:
> Quoting Neil Armstrong (2017-12-06 11:54:28)
>> The VPU init misses these configurations values.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/meson/meson_drv.c   | 9 +
>>  drivers/gpu/drm/meson/meson_registers.h | 4 
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index 3b804fd..f9ad0e9 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
>> .max_register   = 0x1000,
>>  };
>>  
>> +static void meson_vpu_init(struct meson_drm *priv)
>> +{
>> +   writel_relaxed(0x21, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
>> +   writel_relaxed(0x1, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
>> +   writel_relaxed(0x90, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
>> +   writel_relaxed(0x2, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
>> +}
> 
>> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
>> b/drivers/gpu/drm/meson/meson_registers.h
>> index 2847381..bca8714 100644
>> --- a/drivers/gpu/drm/meson/meson_registers.h
>> +++ b/drivers/gpu/drm/meson/meson_registers.h
>> @@ -1363,6 +1363,10 @@
>>  #define VPU_PROT3_STAT_1 0x277a
>>  #define VPU_PROT3_STAT_2 0x277b
>>  #define VPU_PROT3_REQ_ONOFF 0x277c
>> +#define VPU_RDARB_MODE_L1C1 0x2790
>> +#define VPU_RDARB_MODE_L1C2 0x2799
> 
> Hmm, not naturally aligned for writel. Is the register width correct,
> address correct, or this really is an unaligned iowrite?

The registers are aligned with the documentation, then are used with the _REG() 
macro
to align them with the bus (on top of the file).

Neil

> 
>> +#define VPU_RDARB_MODE_L2C1 0x279d
>> +#define VPU_WRARB_MODE_L2C1 0x27a2
> 
> Similarly,
> -Chris
> 

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


Re: [RESEND PATCH 4/4] drm/meson: Add missing VPU init

2017-12-06 Thread Chris Wilson
Quoting Neil Armstrong (2017-12-06 11:54:28)
> The VPU init misses these configurations values.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_drv.c   | 9 +
>  drivers/gpu/drm/meson/meson_registers.h | 4 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 3b804fd..f9ad0e9 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
> .max_register   = 0x1000,
>  };
>  
> +static void meson_vpu_init(struct meson_drm *priv)
> +{
> +   writel_relaxed(0x21, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
> +   writel_relaxed(0x1, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
> +   writel_relaxed(0x90, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
> +   writel_relaxed(0x2, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
> +}

> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
> b/drivers/gpu/drm/meson/meson_registers.h
> index 2847381..bca8714 100644
> --- a/drivers/gpu/drm/meson/meson_registers.h
> +++ b/drivers/gpu/drm/meson/meson_registers.h
> @@ -1363,6 +1363,10 @@
>  #define VPU_PROT3_STAT_1 0x277a
>  #define VPU_PROT3_STAT_2 0x277b
>  #define VPU_PROT3_REQ_ONOFF 0x277c
> +#define VPU_RDARB_MODE_L1C1 0x2790
> +#define VPU_RDARB_MODE_L1C2 0x2799

Hmm, not naturally aligned for writel. Is the register width correct,
address correct, or this really is an unaligned iowrite?

> +#define VPU_RDARB_MODE_L2C1 0x279d
> +#define VPU_WRARB_MODE_L2C1 0x27a2

Similarly,
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >