date:20170905

[PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

2017-09-05 Thread Dhinakaran Pandiyan

Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
set power states for downstream sinks. Apart from giving us the ability
to set power state for individual sinks, this fixes the below test for
me

$ xrandr --display :0 --output DP-2-2-8 --off
$ xrandr --display :0 --output DP-2-2-1 --off
$ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
$ xrandr --display :0 --output DP-2-2-1 --auto

Cc: Ville Syrjälä 
Cc: Lyude 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_ddi.c| 6 --
 drivers/gpu/drm/i915/intel_dp_mst.c | 8 
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1da3bb2cc4b4..8aebacc0aa31 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   if (!link_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+   if (old_crtc_state && old_conn_state)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
}
 
val = I915_READ(DDI_BUF_CTL(port));
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8e3aad0ea60b..81e63724e24b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -167,12 +167,11 @@ static void intel_mst_post_disable_dp(struct 
intel_encoder *encoder,
intel_dp->active_mst_links--;
 
intel_mst->connector = NULL;
-   if (intel_dp->active_mst_links == 0) {
+   if (intel_dp->active_mst_links == 0)
intel_dig_port->base.post_disable(_dig_port->base,
  NULL, NULL);
-
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
-   }
+   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
+false);
 }
 
 static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
@@ -197,6 +196,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
 
+   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
pipe_config, NULL);
-- 
2.11.0

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

[PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes

2017-09-05 Thread Dhinakaran Pandiyan

The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions allow
the source to reqest any node in a mst path or a whole path to be
powered down or up. This allows drivers to target a specific sink in the
MST topology, an improvement over just power managing the imediate
downstream device. Secondly, since the request-reply protocol waits for an
ACK, we can be sure that a downstream sink has enough time to respond to a
power up/down request.

Cc: Lyude 
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 73 +++
 include/drm/drm_dp_mst_helper.h   |  2 +
 2 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 41b492f99955..a9f12708a046 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct 
drm_dp_sideband_msg_req_body *req,
memcpy([idx], req->u.i2c_write.bytes, 
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+
+   case DP_POWER_DOWN_PHY:
+   case DP_POWER_UP_PHY:
+   buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
+   idx++;
+   break;
}
raw->cur_len = idx;
 }
@@ -538,6 +544,22 @@ static bool drm_dp_sideband_parse_query_payload_ack(struct 
drm_dp_sideband_msg_r
return false;
 }
 
+
+static bool drm_dp_sideband_parse_power_updown_phy_ack(struct 
drm_dp_sideband_msg_rx *raw,
+  struct 
drm_dp_sideband_msg_reply_body *repmsg)
+{
+   int idx = 1;
+
+   repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) & 0xf;
+   idx++;
+   if (idx > raw->curlen) {
+   DRM_DEBUG_KMS("power up/down phy parse length fail %d %d\n",
+ idx, raw->curlen);
+   return false;
+   }
+   return true;
+}
+
 static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body 
*msg)
 {
@@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct 
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
case DP_ALLOCATE_PAYLOAD:
return drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
+   case DP_POWER_DOWN_PHY:
+   case DP_POWER_UP_PHY:
+   return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
default:
DRM_ERROR("Got unknown reply 0x%02x\n", msg->req_type);
return false;
@@ -693,6 +718,22 @@ static int build_allocate_payload(struct 
drm_dp_sideband_msg_tx *msg, int port_n
return 0;
 }
 
+static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
+ int port_num, bool power_up)
+{
+   struct drm_dp_sideband_msg_req_body req;
+
+   if (power_up)
+   req.req_type = DP_POWER_UP_PHY;
+   else
+   req.req_type = DP_POWER_DOWN_PHY;
+
+   req.u.port_num.port_number = port_num;
+   drm_dp_encode_sideband_req(, msg);
+   msg->path_msg = true;
+   return 0;
+}
+
 static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_vcpi *vcpi)
 {
@@ -1724,6 +1765,38 @@ static int drm_dp_payload_send_msg(struct 
drm_dp_mst_topology_mgr *mgr,
return ret;
 }
 
+int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr *mgr,
+struct drm_dp_mst_port *port, bool power_up)
+{
+   struct drm_dp_sideband_msg_tx *txmsg;
+   int len, ret;
+
+   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
+   if (!txmsg)
+   return -ENOMEM;
+
+   port = drm_dp_get_validated_port_ref(mgr, port);
+   if (!port)
+   return -EINVAL;
+
+   txmsg->dst = port->parent;
+   len = build_power_updown_phy(txmsg, port->port_num, power_up);
+   drm_dp_queue_down_tx(mgr, txmsg);
+
+   ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
+   if (ret > 0) {
+   if (txmsg->reply.reply_type == 1)
+   ret = -EINVAL;
+   else
+   ret = 0;
+   }
+   kfree(txmsg);
+   drm_dp_put_port(port);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_send_power_updown_phy);
+
 static int drm_dp_create_payload_step1(struct drm_dp_mst_topology_mgr *mgr,
   int id,
   struct drm_dp_payload *payload)
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

2017-09-05 Thread bugzilla-daemon

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

--- Comment #39 from Shmerl  ---
For the reference, I just tested it with Linux 4.13.0 using amdgpu display code
branch from AMD. Unfortunately the freeze still happens with it.

-- 
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 100596] [BXT/GLK/SKL/KBL/BDW/IVB/HSW/BSW/BYT] gem_userptr_blits/map-fixed-invalidate* showing bad address

2017-09-05 Thread bugzilla-daemon

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #15 from Chris Wilson  ---
https://patchwork.freedesktop.org/patch/169425/

-- 
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 102552] Null dereference due to not checking return value of util_format_description

2017-09-05 Thread bugzilla-daemon

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

--- Comment #2 from Ilia Mirkin  ---
What format is this happening with? There should be a description for every
format, maybe except PIPE_FORMAT_NONE.

-- 
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 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

2017-09-05 Thread bugzilla-daemon

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

Bug ID: 102553
   Summary: Venus PRO R9 M265X amdgpu: Kernel OOPS
si_dpm_set_power_state unable to handle kernel NULL
pointer dereference
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mercuri...@yahoo.es

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

Hi all

When you try to change the DPM "governor" to "battery" using this command:

echo "battery" > /sys/class/drm/card0/device/power_dpm_state

You will get a kernel OOPS

OS: Gentoo

Kernel:
 ~ $ uname -a
Linux localhost.localdomain 4.13.0-gentoo #2 SMP PREEMPT Tue Sep 5 19:43:50
CEST 2017 x86_64 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz GenuineIntel
GNU/Linux
m

lspci of my graphic card:
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus PRO
[Radeon HD 8850M / R9 M265X]

lspci -n:
01:00.0 0380: 1002:6823




partial dmesg output:

[ 1861.111097] BUG: unable to handle kernel NULL pointer dereference at
  (null)
[ 1861.111929] IP:   (null)
[ 1861.112733] PGD 3cb980067 
[ 1861.112734] P4D 3cb980067 
[ 1861.113516] PUD 343b2f067 
[ 1861.114286] PMD 0 

[ 1861.116531] Oops: 0010 [#1] PREEMPT SMP
[ 1861.117296] Modules linked in:
[ 1861.118053] CPU: 4 PID: 4384 Comm: bash Not tainted 4.13.0-gentoo #2
[ 1861.118803] Hardware name: TOSHIBA SATELLITE P50-B-11M/VG20SQ, BIOS 1.50
12/09/2014
[ 1861.119547] task: 880307a33000 task.stack: c9894000
[ 1861.120295] RIP: 0010:  (null)
[ 1861.121365] RSP: 0018:c9897cc8 EFLAGS: 00010202
[ 1861.122300] RAX: 81ea12e0 RBX: 88041b8f RCX:
0078
[ 1861.123101] RDX: 0078 RSI: 0007 RDI:
88041b8f
[ 1861.123938] RBP: c9897d50 R08: 0002 R09:
00018c04
[ 1861.124720] R10:  R11: 88041b940044 R12:

[ 1861.125507] R13: 88041b94 R14: 88041b941988 R15:
0003
[ 1861.126293] FS:  7fefa79d6700() GS:88042fb0()
knlGS:
[ 1861.127096] CS:  0010 DS:  ES:  CR0: 80050033
[ 1861.127903] CR2:  CR3: 0002e9266000 CR4:
001406e0
[ 1861.128718] Call Trace:
[ 1861.129530]  ? si_dpm_set_power_state+0xc49/0x11e0
[ 1861.130354]  amdgpu_pm_compute_clocks+0x289/0x600
[ 1861.131177]  amdgpu_set_dpm_state+0x79/0x110
[ 1861.131990]  dev_attr_store+0x13/0x20
[ 1861.132804]  sysfs_kf_write+0x32/0x40
[ 1861.133624]  kernfs_fop_write+0x112/0x190
[ 1861.134466]  __vfs_write+0x23/0x130
[ 1861.135324]  ? preempt_count_add+0x99/0xb0
[ 1861.136163]  ? _raw_write_unlock+0x11/0x30
[ 1861.136992]  ? __this_cpu_preempt_check+0x13/0x20
[ 1861.137804]  ? __sb_start_write+0x50/0xe0
[ 1861.138613]  vfs_write+0xaf/0x180
[ 1861.139405]  SyS_write+0x41/0xb0
[ 1861.140189]  ? __context_tracking_exit.part.2+0x2e/0xf0
[ 1861.140980]  do_syscall_64+0x6f/0x160
[ 1861.141764]  entry_SYSCALL64_slow_path+0x25/0x25
[ 1861.142557] RIP: 0033:0x7fefa7092b40
[ 1861.143346] RSP: 002b:7ffcd158b488 EFLAGS: 0246 ORIG_RAX:
0001
[ 1861.144158] RAX: ffda RBX: 0008 RCX:
7fefa7092b40
[ 1861.144975] RDX: 0008 RSI: 006c5b00 RDI:
0001
[ 1861.145794] RBP: 006c5b00 R08: 7fefa734d760 R09:
7fefa79d6700
[ 1861.146617] R10: 0097 R11: 0246 R12:
0008
[ 1861.147442] R13: 0001 R14: 7fefa734c600 R15:

[ 1861.148267] Code:  Bad RIP value.
[ 1861.149090] RIP:   (null) RSP: c9897cc8
[ 1861.149925] CR2: 
[ 1861.157732] ---[ end trace 4f6879609b5f474d ]---

-- 
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 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

2017-09-05 Thread Eric Anholt

Daniel Vetter  writes:

> On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:
>> If we cannot find a panel, assume that the output from the
>> PL111 is connected directly to a "dumb" VGA connector,
>> so look up the connector from that bridge.
>> 
>> Signed-off-by: Linus Walleij 
>> ---
>> This is how the new API is used in the PL111.
>> ---
>>  drivers/gpu/drm/pl111/Kconfig | 1 +
>>  drivers/gpu/drm/pl111/pl111_drv.c | 3 +++
>>  2 files changed, 4 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
>> index e5e2abd66491..82cb3e60ddc8 100644
>> --- a/drivers/gpu/drm/pl111/Kconfig
>> +++ b/drivers/gpu/drm/pl111/Kconfig
>> @@ -8,6 +8,7 @@ config DRM_PL111
>>  select DRM_GEM_CMA_HELPER
>>  select DRM_BRIDGE
>>  select DRM_PANEL_BRIDGE
>> +select DRM_DUMB_VGA_DAC
>>  select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>>  help
>>Choose this option for DRM support for the PL111 CLCD controller.
>> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
>> b/drivers/gpu/drm/pl111/pl111_drv.c
>> index f5bc6f160e60..6db423bbd84e 100644
>> --- a/drivers/gpu/drm/pl111/pl111_drv.c
>> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
>> @@ -67,6 +67,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "pl111_drm.h"
>>  #include "pl111_versatile.h"
>> @@ -128,6 +129,8 @@ static int pl111_modeset_init(struct drm_device *dev)
>>  if (panel) {
>>  priv->panel = panel;
>>  priv->connector = panel->connector;
>> +} else {
>> +priv->connector = drm_dumb_vga_get_connector(bridge);
>
> Why do you need to set this? The only code I could find tries to set
> polarity values from bus_flags, and for VGA I'd assume you want to instead
> key this off the mode?
>
> Wrt the more general problem: They way we solve this in the i915 atomic
> framework is that the various ->fixup calls fill out relevant fields in
> the drm_crtc_state. I guess we could add an ->atomic_check to bridges, add
> a bus_flags to drm_crtc_state (or maybe just let everyone patch up
> adjusted_mode->flags) instead?

It seems to me like the bus_flags/format should be specific to each link
in the display output chain, rather than global to it.


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

[Bug 102552] Null dereference due to not checking return value of util_format_description

2017-09-05 Thread bugzilla-daemon

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

Pauk Denis  changed:

   What|Removed |Added

 CC||pauk.de...@gmail.com

--- Comment #1 from Pauk Denis  ---
Created attachment 133978
  --> https://bugs.freedesktop.org/attachment.cgi?id=133978=edit
gallium/{r600,radeonsi}: Fix segfault with color format

Possible fix for r600/radionsi

-- 
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 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

2017-09-05 Thread bugzilla-daemon

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

--- Comment #5 from Hector Velazquez 
 ---
Created attachment 133977
  --> https://bugs.freedesktop.org/attachment.cgi?id=133977=edit
Output (Legacy test)

-- 
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 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

2017-09-05 Thread bugzilla-daemon

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

--- Comment #4 from Hector Velazquez 
 ---
Created attachment 133976
  --> https://bugs.freedesktop.org/attachment.cgi?id=133976=edit
Output (Atomic test)

-- 
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 102552] Null dereference due to not checking return value of util_format_description

2017-09-05 Thread bugzilla-daemon

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

Bug ID: 102552
   Summary: Null dereference due to not checking return value of
util_format_description
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: pauk.de...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

In case unsupported format util_format_description return NULL, and dereference
will produce segffault.

-- 
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 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

2017-09-05 Thread bugzilla-daemon

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

--- Comment #3 from Hector Velazquez 
 ---
Created attachment 133975
  --> https://bugs.freedesktop.org/attachment.cgi?id=133975=edit
Dmesg.log

-- 
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 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

2017-09-05 Thread bugzilla-daemon

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

--- Comment #2 from Hector Velazquez 
 ---
The following tests show new FAIL on HSW 

Tests List:

igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic
igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy


==
Output
==

(kms_cursor_legacy:5828) igt-debugfs-DEBUG: CRC mismatch at index 0: 0x87acf6a4
!= 0xcdacf93b
(kms_cursor_legacy:5828) igt-debugfs-CRITICAL: Test assertion failure function
igt_assert_crc_equal, file igt_debugfs.c:325:
(kms_cursor_legacy:5828) igt-debugfs-CRITICAL: Failed assertion: !mismatch
(kms_cursor_legacy:5828) igt-core-INFO: Stack trace:
(kms_cursor_legacy:5828) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(kms_cursor_legacy:5828) igt-core-INFO:   #1 [igt_assert_crc_equal+0x5d]
(kms_cursor_legacy:5828) igt-core-INFO:   #2 [flip_vs_cursor_busy_crc+0x3d5]
(kms_cursor_legacy:5828) igt-core-INFO:   #3 [__real_main1411+0x12aa]
(kms_cursor_legacy:5828) igt-core-INFO:   #4 [main+0x33]
(kms_cursor_legacy:5828) igt-core-INFO:   #5 [__libc_start_main+0xf1]
(kms_cursor_legacy:5828) igt-core-INFO:   #6 [_start+0x29]
(kms_cursor_legacy:5828) igt-core-INFO:   #7 [+0x29]
  END  
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [igt_assert_crc_equal+0x5d]
  #2 [flip_vs_cursor_busy_crc+0x3d5]
  #3 [__real_main1411+0x12aa]
  #4 [main+0x33]
  #5 [__libc_start_main+0xf1]
  #6 [_start+0x29]
  #7 [+0x29]
Subtest flip-vs-cursor-busy-crc-atomic: FAIL (9.852s)
(kms_cursor_legacy:5828) igt-core-DEBUG: Exiting with status code 99


This is my configuration:

==
Graphic stack
==

Component: drm
tag: libdrm-2.4.81-52-g05a830d
commit: 05a830d382382905d87b55af90aa109fb76e4c16

Component: cairo
tag: 1.15.6-30-gc29db4f
commit: c29db4f0de52727406a8b62f4da9a382084b5a79

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-234-g490b386
commit: 490b386ae36d393cdea514882a2437c6e964c13f

Component: piglit
tag: piglit-v1
commit: dab15137044c34023b1a843e72e781b03b17548b

==
 Software
==
kernel version  : 4.13.0-drm-tip-ww36-commit-9dd459e+
hostname: gfx-desktop
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 4.6
bios release date   : 03/02/2017
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-234-g490b386
intel-gpu-tools (commit): 490b386

==
 Hardware
==
platform   : Haswell-Nuc
motherboard id : D54250WYK
form factor: Desktop
cpu family : Core i5
cpu family id  : 6
cpu information: Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
gpu card   : Intel Corporation Haswell-ULT Integrated Graphics
Controller (rev 09) (prog-if 00 [VGA controller])
memory ram : 1.83 GB
max memory ram : 16 GB
cpu thread : 4
cpu core   : 2
cpu model  : 69
cpu stepping   : 1
socket : Socket LGA1150
signature  : Type 0, Family 6, Model 69, Stepping 1
hard drive : 223GiB (240GB)
current cd clock frequency : 45 kHz
maximum cd clock frequency : 45 kHz
displays connected : DP-1

-- 
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 3/4] drm: Drop drm_get_link_status_name()

2017-09-05 Thread Manasi Navare

On Fri, Sep 01, 2017 at 07:53:27PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> drm_get_link_status_name() isn't used so kill it.
> 
> Fixes the following sparse warning:
> drm_connector.c:618:1: warning: symbol 'drm_get_link_status_name' was not 
> declared. Should it be static?
>

Thanks for catching this warning.
Verified that this fixes the warning and hence drm_get_link_status_name not 
needed.

Reviewed-by: Manasi Navare 

Manasi
 
> Cc: Manasi Navare 
> Fixes: 40ee6fbef75f ("drm: Add a new connector atomic property for link 
> status")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_connector.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ba9f36cef68c..bb2e60f5feb6 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -615,7 +615,6 @@ static const struct drm_prop_enum_list 
> drm_link_status_enum_list[] = {
>   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
>   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
>  };
> -DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>  
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
> -- 
> 2.13.5
> 
> ___
> 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 101160] Venus PRO R9 M265X amdgpu: ring 0 test failed

2017-09-05 Thread bugzilla-daemon

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

mercuriete  changed:

   What|Removed |Added

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

--- Comment #6 from mercuriete  ---
with kernel 4.13 it seems its fixed.

~ $ uname -a
Linux localhost.localdomain 4.13.0-gentoo #2 SMP PREEMPT Tue Sep 5 19:43:50
CEST 2017 x86_64 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz GenuineIntel
GNU/Linux

I will close 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: [Intel-gfx] [PATCH 2/2] drm/i915: Constify load detect mode

2017-09-05 Thread Ville Syrjälä

On Mon, May 22, 2017 at 09:42:01AM +0200, Daniel Vetter wrote:
> On Thu, May 18, 2017 at 10:38:37PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Make the mode used for load detection const, and adjust all relevant
> > functions to accept a const mode.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Daniel Vetter 

Thanks. Pushed to dinq.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102338] QXL driver causes oops on boot, kernel 4.12

2017-09-05 Thread bugzilla-daemon

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

kris...@collabora.co.uk changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |kris...@collabora.co.uk
   |.org|

-- 
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/4] drm/bridge: adv7511: Properly update EDID when no EDID was found

2017-09-05 Thread John Stultz

On Tue, Sep 5, 2017 at 5:10 AM, Lars-Peter Clausen  wrote:
> Currently adv7511_get_modes() bails out early when no EDID could be
> retrieved. This leaves the previous EDID in place, which is typically not
> the intended behavior and might confuse applications. Instead the EDID
> should be cleared when no EDID could be retrieved.
>
> All functions that are called after the EDID check handle the case where
> the EDID is NULL just fine and exhibit the expected behavior, so just drop
> the check.
>
> Signed-off-by: Lars-Peter Clausen 

No objections from me. Ran these on my HiKey board ontop of Linus's
HEAD, and everything seemed ok.

So for the whole patchset:
Tested-by: John Stultz 

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

[Bug 102338] QXL driver causes oops on boot, kernel 4.12

2017-09-05 Thread bugzilla-daemon

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

--- Comment #3 from Takashi Iwai  ---
(In reply to Takashi Iwai from comment #2)
> Now we hit this on openSUSE Tumbleweed, 4.12.9 & later, too.
>   https://bugs.freedesktop.org/show_bug.cgi?id=102338

Doh, a recursive call.  The right one is:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1057241

-- 
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 102338] QXL driver causes oops on boot, kernel 4.12

2017-09-05 Thread bugzilla-daemon

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

Takashi Iwai  changed:

   What|Removed |Added

 CC||ti...@suse.de

--- Comment #2 from Takashi Iwai  ---
Now we hit this on openSUSE Tumbleweed, 4.12.9 & later, too.
  https://bugs.freedesktop.org/show_bug.cgi?id=102338

I quickly bisected and it pointed to the commit
3538e80a869be74764ae7db484b371894f04d0f8
drm: qxl: Atomic phase 1: Implement mode_set_nofb

-- 
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 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-05 Thread Laurent Pinchart

Hi Maciej,

On Tuesday, 5 September 2017 16:01:54 EEST Maciej Purski wrote:
> Hi Laurent,
> 
> Thank you for your reply. The problem was already discussed when adding
> sil8620 driver. It can be solved later. I'm CC-ing Andrzej Hajda, as he
> used to discuss it with you.

I'm afraid it can't be solved later. DT bindings are supposed to be a stable 
ABI, we can't merge a binding that we already know isn't correct.

> https://patchwork.freedesktop.org/patch/114224/
> https://lists.freedesktop.org/archives/dri-devel/2015-December/096756.html
> 
> Regards,
> 
>   Maciej
> 
> On 31/08/17 15:30, Laurent Pinchart wrote:
> > Hi Maciej,
> > 
> > Thank you for the patch.
> > 
> > On Thursday, 31 August 2017 15:27:13 EEST Maciej Purski wrote:
> >> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> >> It is controlled via I2C bus. Its interaction with other
> >> devices in video pipeline is performed mainly on HW level.
> >> The only interaction it does on device driver level is
> >> filtering-out unsupported video modes, it exposes drm_bridge
> >> interface to perform this operation.
> >> 
> >> This patch is based on the code refactored by Tomasz Stanislawski
> >> , which was initially developed by:
> >> Adam Hampson 
> >> Erik Gilling 
> >> Shankar Bandal 
> >> Dharam Kumar 
> >> 
> >> Signed-off-by: Maciej Purski 
> >> ---
> >> Changes in v2:
> >> - use bulk_requlators instead of single one
> >> - substitute some of the magic values with macros
> >> - improve coding style
> >> - improved error handling in sii9234_probe()
> >> ---
> >> 
> >>   .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
> >>   drivers/gpu/drm/bridge/Kconfig |   8 +
> >>   drivers/gpu/drm/bridge/Makefile|   1 +
> >>   drivers/gpu/drm/bridge/sii9234.c   | 993
> >>   ++
> >>   4 files changed, 1036 insertions(+)
> >>   create mode 100644
> >> 
> >> Documentation/devicetree/bindings/display/bridge/sii9234.txt create mode
> >> 100644 drivers/gpu/drm/bridge/sii9234.c
> >> 
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> >> b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
> >> mode 100644
> >> index 000..3ce7413
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> >> @@ -0,0 +1,34 @@
> >> +Silicon Image SiI9234 HDMI/MHL bridge bindings
> >> +
> >> +Required properties:
> >> +  - compatible : "sil,sii9234".
> >> +  - reg : I2C address for TPI interface, use 0x39
> >> +  - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
> >> +  - iovcc18-supply : I/O Supply Voltage (1.8V)
> >> +  - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
> >> +  - cvcc12-supply : Digital Core Supply Voltage (1.2V)
> >> +  - interrupts, interrupt-parent: interrupt specifier of INT pin
> >> +  - reset-gpios: gpio specifier of RESET pin (active low)
> >> +  - video interfaces: Device node can contain video interface port
> >> +  node for HDMI encoder according to [1].
> >> +
> >> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > 
> > Doesn't this chip have two ports, one input connected to the SoC and one
> > output connected to an HDMI connector ? If so there should be two ports in
> > DT too.
> > 
> >> +Example:
> >> +  sii9234@39 {
> >> +  compatible = "sil,sii9234";
> >> +  reg = <0x39>;
> >> +  avcc33-supply = <>;
> >> +  iovcc18-supply = <>;
> >> +  avcc12-supply = <>;
> >> +  cvcc12-supply = <>;
> >> +  reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> >> +  interrupt-parent = <>;
> >> +  interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
> >> +
> >> +  port {
> >> +  mhl_to_hdmi: endpoint {
> >> +  remote-endpoint = <_to_mhl>;
> > 
> > It would be useful to include the remote DT nodes in the example too.
> > 
> >> +  };
> >> +  };
> >> +  };


-- 
Regards,

Laurent Pinchart

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

2017-09-05 Thread bugzilla-daemon

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

--- Comment #38 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #37)
> No, I can't reproduce the issue with the trace on my system. I should
> probably set up a wine install at some point.

Let me know if you need a GOG key for TW3. I've spoken to GOG Linux folks, and
they are willing to help Mesa developers with this.

-- 
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 v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-05 Thread Maciej Purski

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
 .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 993 +
 4 files changed, 1036 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
 
+config DRM_SII9234
+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..b70d69a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,993 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A

[PATCH v3 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

2017-09-05 Thread Maciej Purski

Add HDMI and Sil9234 MHL converter to Trats2 board.
Following in SoC devices have been enabled:
- HDMI (HDMI signal encoder),
- Mixer (video buffer scanout device),
- I2C_5 bus (used for HDMI DDC)
- I2C_8 bus (used for HDMI_PHY control).

Based on previous work by:
Tomasz Stanislawski 

Signed-off-by: Maciej Purski 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 112 
 1 file changed, 112 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 35e9b94..742e02a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Samsung Trats 2 based on Exynos4412";
@@ -97,6 +98,34 @@
gpio = < 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   vsil12: voltage-regulator-6 {
+   compatible = "regulator-fixed";
+   regulator-name = "VSIL_1.2V";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   vin-supply = <_reg>;
+   };
+
+   vcc33mhl: voltage-regulator-7 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3.3_MHL";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vcc18mhl: voltage-regulator-8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1.8_MHL";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
};
 
gpio-keys {
@@ -229,6 +258,36 @@
};
};
 
+   i2c-mhl {
+   compatible = "i2c-gpio";
+   gpios = < 4 GPIO_ACTIVE_HIGH  6 GPIO_ACTIVE_HIGH>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <_mhl_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   sii9234: hdmi-bridge@39 {
+   compatible = "sil,sii9234";
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+   reg = <0x39>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
+   };
+
camera: camera {
pinctrl-0 = <_port_a_clk_active _port_b_clk_active>;
pinctrl-names = "default";
@@ -522,6 +581,29 @@
status = "okay";
 };
 
+ {
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+   vdd-supply = <_reg>;
+   vdd_osc-supply = <_reg>;
+   vdd_pll-supply = <_reg>;
+   ddc = <_5>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   hdmi_to_mhl: endpoint {
+   remote-endpoint = <_to_hdmi>;
+   };
+   };
+   };
+};
+
  {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
@@ -600,6 +682,11 @@
};
 };
 
+
+_5 {
+   status = "okay";
+};
+
 _7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -894,12 +981,20 @@
};
 };
 
+_8 {
+   status = "okay";
+};
+
  {
pinctrl-0 = <_bus>;
pinctrl-names = "default";
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
 _0 {
num-slots = <1>;
broken-cd;
@@ -926,6 +1021,18 @@
pinctrl-names = "default";
pinctrl-0 = <>;
 
+   mhl_int: mhl-int {
+   samsung,pins = "gpf3-5";
+   samsung,pin-pud = ;
+   };
+
+   i2c_mhl_bus: i2c-mhl-bus {
+   samsung,pins = "gpf0-4", "gpf0-6";
+   samsung,pin-function = ;
+

[PATCH v3 0/2] add Silicon Image SiI9234 driver

2017-09-05 Thread Maciej Purski

Hi everyone,

These patches are a continuation of work by Tomasz Stanislawski on sii9324 
driver, which was described
in th following letter:
https://lists.freedesktop.org/archives/dri-devel/2014-April/057481.html

The main differences from the previous code are:
* driver moved to /gpu/drm/bridge/ and integrated with drm/bridge subsystem
* added filtering-out unsupported display modes
* changed gpio interface to up-to-date
* changed interrupt handling
* improve code style
* add hdmi and sii9324 to exynos4412-trats2 device tree

All comments are welcome.

Regards,
Maciej Purski

Changes in v3:
- change sii9234 device tree node name
- use defines from dt-bindings/pinctrl/samsung.h

Changes in v2:
- regulators used in driver now model all physical regulators
  used by the device
- substitute some of the magic values with macros
- improve coding style
- improve error handling in sii9234_probe()
- fix commit message

Maciej Purski (2):
  drm/bridge: add Silicon Image SiI9234 driver
  ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

 .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
 arch/arm/boot/dts/exynos4412-trats2.dts| 111 +++
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 993 +
 5 files changed, 1147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

-- 
2.7.4

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

Re: [PATCH 01/14] drm/cirrus: split out bo unpinning from cirrus_bo_push_sysram

2017-09-05 Thread Varad Gautam

Hi Gabriel,

On Mon, Sep 4, 2017 at 4:11 PM, Gabriel Krisman Bertazi
 wrote:
> Varad Gautam  writes:
>
>
>>  int cirrus_bo_push_sysram(struct cirrus_bo *bo)
>>  {
>>   int i, ret;
>> - if (!bo->pin_count) {
>> +
>> + ret = cirrus_bo_reserve(bo, false);
>> + if (ret)
>> + return ret;
>> +
>> + if (bo->pin_count) {
>>   DRM_ERROR("unpin bad %p\n", bo);
>> - return 0;
>> + goto out;
>>   }
>> - bo->pin_count--;
>> - if (bo->pin_count)
>> - return 0;
>
> Can you adjust this to also use your version of cirrus_bo_unpin()?
>
> Also, If I'm not mistaken, this hunk unbalances pin_count, since you
> no longer decrement it after unpinning.
>

Do you mean we also need to call bo_unpin() from push_sysram?

With this patch, we unpin immediately before calling push_sysram(),
and only allow non-pinned bo-s to be moved to sysram (pin_count
decrements in cirrus_bo_unpin preserving pinning state). With atomic
handlers later (patch 10+), pin-unpin happens from prepare/cleanup_fb,
and a later prepare_fb calls push_sysram() on the bo - so the
pin_count maintains.

Thanks,
Varad

>>
>>   if (bo->kmap.virtual)
>>   ttm_bo_kunmap(>kmap);
>> @@ -400,9 +432,12 @@ int cirrus_bo_push_sysram(struct cirrus_bo *bo)
>>   ret = ttm_bo_validate(>bo, >placement, false, false);
>>   if (ret) {
>>   DRM_ERROR("pushing to VRAM failed\n");
>> - return ret;
>> + goto out;
>>   }
>> - return 0;
>> +
>> +out:
>> + cirrus_bo_unreserve(bo);
>> + return ret;
>>  }
>>
>>  int cirrus_mmap(struct file *filp, struct vm_area_struct *vma)
>
> --
> Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-05 Thread Maciej Purski


Hi Laurent,

Thank you for your reply. The problem was already discussed when adding sil8620 
driver.
It can be solved later. I'm CC-ing Andrzej Hajda, as he used to discuss it with 
you.

https://patchwork.freedesktop.org/patch/114224/
https://lists.freedesktop.org/archives/dri-devel/2015-December/096756.html

Regards,

Maciej

On 31/08/17 15:30, Laurent Pinchart wrote:


Hi Maciej,

Thank you for the patch.

On Thursday, 31 August 2017 15:27:13 EEST Maciej Purski wrote:

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
Changes in v2:
- use bulk_requlators instead of single one
- substitute some of the magic values with macros
- improve coding style
- improved error handling in sii9234_probe()
---
  .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
  drivers/gpu/drm/bridge/Kconfig |   8 +
  drivers/gpu/drm/bridge/Makefile|   1 +
  drivers/gpu/drm/bridge/sii9234.c   | 993 ++
  4 files changed, 1036 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/display/bridge/sii9234.txt create mode
100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

Doesn't this chip have two ports, one input connected to the SoC and one
output connected to an HDMI connector ? If so there should be two ports in DT
too.


+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;

It would be useful to include the remote DT nodes in the example too.


+   };
+   };
+   };


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

[PATCH 1/4] drm/bridge: adv7511: Properly update EDID when no EDID was found

2017-09-05 Thread Lars-Peter Clausen

Currently adv7511_get_modes() bails out early when no EDID could be
retrieved. This leaves the previous EDID in place, which is typically not
the intended behavior and might confuse applications. Instead the EDID
should be cleared when no EDID could be retrieved.

All functions that are called after the EDID check handle the case where
the EDID is NULL just fine and exhibit the expected behavior, so just drop
the check.

Signed-off-by: Lars-Peter Clausen 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index b2431aee7887..fb8f4cd29e15 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -591,8 +591,6 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
 
kfree(adv7511->edid);
adv7511->edid = edid;
-   if (!edid)
-   return 0;
 
drm_mode_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
-- 
2.11.0

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

[PATCH 4/4] drm/bridge: adv7511: Constify HDMI CODEC platform data

2017-09-05 Thread Lars-Peter Clausen

The HDMI codec platform data is global driver state shared by all
instances. As such it should not be modified (and is not), to make this
explicit declare it as const.

Signed-off-by: Lars-Peter Clausen 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index 67469c26bae8..1b4783d45c53 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -210,7 +210,7 @@ static const struct hdmi_codec_ops adv7511_codec_ops = {
.get_dai_id = adv7511_hdmi_i2s_get_dai_id,
 };
 
-static struct hdmi_codec_pdata codec_data = {
+static const struct hdmi_codec_pdata codec_data = {
.ops = _codec_ops,
.max_i2s_channels = 2,
.i2s = 1,
-- 
2.11.0

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

[PATCH 2/4] drm/bridge: adv7511: Remove private copy of the EDID

2017-09-05 Thread Lars-Peter Clausen

The adv7511 driver keeps a private copy of the EDID in its driver state
struct. But this copy is only used in adv7511_get_modes() where it is also
retrieved, so there is no need to keep this extra copy around.

If a need to access the EDID elsewhere in the driver ever arises the copy
that is stored in the connector can be used. This copy is accessible
through drm_connector_get_edid().

Note, this patch removes the NULL check of the EDID before passing it to
drm_detect_hdmi_monitor(), but that is fine since the function correctly
handles the case where the EDID is NULL.

Signed-off-by: Lars-Peter Clausen 
---
 drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 --
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 16 ++--
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..12ef2d8ee110 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -328,8 +328,6 @@ struct adv7511 {
enum adv7511_sync_polarity hsync_polarity;
bool rgb;
 
-   struct edid *edid;
-
struct gpio_desc *gpio_pd;
 
struct regulator_bulk_data *supplies;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index fb8f4cd29e15..94d598d8aedf 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -199,17 +199,14 @@ static const uint16_t adv7511_csc_ycbcr_to_rgb[] = {
 
 static void adv7511_set_config_csc(struct adv7511 *adv7511,
   struct drm_connector *connector,
-  bool rgb)
+  bool rgb, bool hdmi_mode)
 {
struct adv7511_video_config config;
bool output_format_422, output_format_ycbcr;
unsigned int mode;
uint8_t infoframe[17];
 
-   if (adv7511->edid)
-   config.hdmi_mode = drm_detect_hdmi_monitor(adv7511->edid);
-   else
-   config.hdmi_mode = false;
+   config.hdmi_mode = hdmi_mode;
 
hdmi_avi_infoframe_init(_infoframe);
 
@@ -589,13 +586,14 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
if (!adv7511->powered)
__adv7511_power_off(adv7511);
 
-   kfree(adv7511->edid);
-   adv7511->edid = edid;
 
drm_mode_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
 
-   adv7511_set_config_csc(adv7511, connector, adv7511->rgb);
+   adv7511_set_config_csc(adv7511, connector, adv7511->rgb,
+  drm_detect_hdmi_monitor(edid));
+
+   kfree(edid);
 
return count;
 }
@@ -1156,8 +1154,6 @@ static int adv7511_remove(struct i2c_client *i2c)
 
i2c_unregister_device(adv7511->i2c_edid);
 
-   kfree(adv7511->edid);
-
return 0;
 }
 
-- 
2.11.0

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

[PATCH 3/4] drm/bridge: adv7511: Enable connector polling when no interrupt is specified

2017-09-05 Thread Lars-Peter Clausen

Fall back to polling the connector for connect and disconnect events when
no interrupt is specified. Otherwise these events will not be noticed and
monitor hotplug does not work.

Signed-off-by: Lars-Peter Clausen 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 94d598d8aedf..bd7dbae1119e 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -829,7 +829,11 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
return -ENODEV;
}
 
-   adv->connector.polled = DRM_CONNECTOR_POLL_HPD;
+   if (adv->i2c_main->irq)
+   adv->connector.polled = DRM_CONNECTOR_POLL_HPD;
+   else
+   adv->connector.polled = DRM_CONNECTOR_POLL_CONNECT |
+   DRM_CONNECTOR_POLL_DISCONNECT;
 
ret = drm_connector_init(bridge->dev, >connector,
 _connector_funcs,
-- 
2.11.0

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

2017-09-05 Thread bugzilla-daemon

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

--- Comment #37 from Samuel Pitoiset  ---
(In reply to Shmerl from comment #34)
> (In reply to Samuel Pitoiset from comment #27)
> > An apitrace that reproduces the issue would be very useful.
> 
> Hi Samuel. Any luck with reproducing or narrowing down this problem? The
> uploaded trace is going to expire soon. Let me know if you need another one,
> or anything else to help.

No, I can't reproduce the issue with the trace on my system. I should probably
set up a wine install at some point.

-- 
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] drm/exynos/hdmi: Fix unsafe list iteration

2017-09-05 Thread Maciej Purski

Function hdmi_mode_fixup() used bare list_for_each entry, which was
unsafe and caused memory corruption detected by kasan.
It now uses drm_for_each_connector_iter macro, which is now recommended
by the documentation and safe.

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 214fa5e..0109ff4 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -944,22 +944,27 @@ static bool hdmi_mode_fixup(struct drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct drm_connector *connector;
struct drm_display_mode *m;
+   struct drm_connector_list_iter conn_iter;
int mode_ok;
 
drm_mode_set_crtcinfo(adjusted_mode, 0);
 
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->encoder == encoder)
break;
}
+   if (connector)
+   drm_connector_get(connector);
+   drm_connector_list_iter_end(_iter);
 
-   if (connector->encoder != encoder)
+   if (!connector)
return true;
 
mode_ok = hdmi_mode_valid(connector, adjusted_mode);
 
if (mode_ok == MODE_OK)
-   return true;
+   goto cleanup;
 
/*
 * Find the most suitable mode and copy it to adjusted_mode.
@@ -979,6 +984,9 @@ static bool hdmi_mode_fixup(struct drm_encoder *encoder,
}
}
 
+cleanup:
+   drm_connector_put(connector);
+
return true;
 }
 
-- 
2.7.4

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

Re: [PATCH] drm/ttm: Fix configuration error around populate_and_map() functions

2017-09-05 Thread Christian König


Am 05.09.2017 um 13:32 schrieb Tom St Denis:

Fixed kbuild errors when IOMMU/SWIOTLB are disabled.

Signed-off-by: Tom St Denis 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6a660d196d87..052e1f102113 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -920,6 +920,7 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
  }
  EXPORT_SYMBOL(ttm_pool_unpopulate);
  
+#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)

  int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
  {
unsigned i;
@@ -960,6 +961,7 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, 
struct ttm_dma_tt *tt)
ttm_pool_unpopulate(>ttm);
  }
  EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
+#endif
  
  int ttm_page_alloc_debugfs(struct seq_file *m, void *data)

  {



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

[PATCH] drm/ttm: Fix configuration error around populate_and_map() functions

2017-09-05 Thread Tom St Denis

Fixed kbuild errors when IOMMU/SWIOTLB are disabled.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6a660d196d87..052e1f102113 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -920,6 +920,7 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
 }
 EXPORT_SYMBOL(ttm_pool_unpopulate);
 
+#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
unsigned i;
@@ -960,6 +961,7 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, 
struct ttm_dma_tt *tt)
ttm_pool_unpopulate(>ttm);
 }
 EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
+#endif
 
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
-- 
2.12.0

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

Re: [PATCH v2 0/6] Host1x and VIC support for Tegra186

2017-09-05 Thread Daniel Vetter

On Tue, Sep 05, 2017 at 11:43:00AM +0300, Mikko Perttunen wrote:
> Hi,
> 
> not many changes in v2:
> 
> Changed address-cells and size-cells for the Host1x device tree node
> to have value 1, since all subdevices fit in the lower 4G. Also dropped
> the incorrect change about this from the dt-bindings patch. Thanks to
> Rob for pointing this out.
> 
> Mikko
> 
> Notes for v1:
> 
> Hi everyone,
> 
> this series adds basic support for the Host1x channel engine and the
> VIC 2d compositor unit on Tegra186. The first three patches do the
> required device tree changes, the fourth patch updates the device tree
> binding documentation, and the two remaining patches add the actual
> implementation, almost all of which is in Host1x itself.
> 
> The Tegra186 Host1x is a relatively large update over previous
> generations, which can be seen in the diffstat. The biggest change is
> that Host1x is now contains separate hypervisor and vm register
> apertures to support virtualization at the hardware level. This driver,
> however, currently assumes that this instance of Linux is the sole
> operating system having access to the hardware.
> 
> This combined with increased numbers of supported channels and
> syncpoints have caused a number of register space changes that are
> responsible for most of the updated code.
> 
> The series has been tested on the Jetson TX1 (T210) and TX2 (T186)
> using the host1x_test test suite available at
> 
> http://github.com/cyndis/host1x_test
> 
> The series itself is available at
> 
> http://github.com/cyndis/linux, branch host1x-t186-1

Since this is new hw support, is there also open source userspace using
all this?

Thanks, Daniel

> 
> Cheers,
> Mikko
> 
> Mikko Perttunen (6):
>   arm64: tegra: Add #power-domain-cells for BPMP
>   arm64: tegra: Add host1x on Tegra186
>   arm64: tegra: Add VIC on Tegra186
>   dt-bindings: host1x: Add Tegra186 information
>   gpu: host1x: Add Tegra186 support
>   drm/tegra: Add Tegra186 support for VIC
> 
>  .../display/tegra/nvidia,tegra20-host1x.txt|   4 +
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi   |  31 
>  drivers/gpu/drm/tegra/drm.c|   1 +
>  drivers/gpu/drm/tegra/vic.c|  10 ++
>  drivers/gpu/host1x/Makefile|   3 +-
>  drivers/gpu/host1x/dev.c   |  60 ++-
>  drivers/gpu/host1x/dev.h   |   4 +
>  drivers/gpu/host1x/hw/cdma_hw.c|  49 +++---
>  drivers/gpu/host1x/hw/debug_hw.c   | 137 +---
>  drivers/gpu/host1x/hw/debug_hw_1x01.c  | 154 ++
>  drivers/gpu/host1x/hw/debug_hw_1x06.c  | 133 +++
>  drivers/gpu/host1x/hw/host1x01.c   |   2 +
>  drivers/gpu/host1x/hw/host1x02.c   |   2 +
>  drivers/gpu/host1x/hw/host1x04.c   |   2 +
>  drivers/gpu/host1x/hw/host1x05.c   |   2 +
>  drivers/gpu/host1x/hw/host1x06.c   |  44 +
>  drivers/gpu/host1x/hw/host1x06.h   |  26 +++
>  drivers/gpu/host1x/hw/host1x06_hardware.h  | 142 
>  drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h |  32 
>  drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 181 
> +
>  drivers/gpu/host1x/hw/hw_host1x06_vm.h |  47 ++
>  drivers/gpu/host1x/hw/intr_hw.c|  29 ++--
>  22 files changed, 926 insertions(+), 169 deletions(-)
>  create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x01.c
>  create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x06.c
>  create mode 100644 drivers/gpu/host1x/hw/host1x06.c
>  create mode 100644 drivers/gpu/host1x/hw/host1x06.h
>  create mode 100644 drivers/gpu/host1x/hw/host1x06_hardware.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_uclass.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_vm.h
> 
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] drm: gma500: fix logic error

2017-09-05 Thread Daniel Vetter

On Tue, Sep 05, 2017 at 09:47:26AM +0200, Arnd Bergmann wrote:
> gcc-8 points out a condition that almost certainly doesn't
> do what the author had in mind:
> 
> drivers/gpu/drm/gma500/mdfld_intel_display.c: In function 
> 'mdfldWaitForPipeEnable':
> drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: error: bitwise 
> comparison always evaluates to false [-Werror=tautological-compare]
> 
> This changes it to a simple bit mask operation to check
> whether the bit is set.
> 
> Fixes: 026abc333205 ("gma500: initial medfield merge")
> Signed-off-by: Arnd Bergmann 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c 
> b/drivers/gpu/drm/gma500/mdfld_intel_display.c
> index 531e4450c000..5c066448be5b 100644
> --- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
> +++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
> @@ -99,7 +99,7 @@ void mdfldWaitForPipeEnable(struct drm_device *dev, int 
> pipe)
>   /* Wait for for the pipe enable to take effect. */
>   for (count = 0; count < COUNT_MAX; count++) {
>   temp = REG_READ(map->conf);
> - if ((temp & PIPEACONF_PIPE_STATE) == 1)
> + if (temp & PIPEACONF_PIPE_STATE)
>   break;
>   }
>  }
> -- 
> 2.9.0
> 

-- 
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: [PATCHv7 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

2017-09-05 Thread Daniel Vetter

On Tue, Sep 05, 2017 at 03:12:32PM +0800, Hean-Loong, Ong wrote:
> From: Ong Hean Loong 
> 
> Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
> The driver only supports the Intel Arria10 devkit and its variants.
> This driver can be either loaded staticlly or in modules.
> The OF device tree binding is located at:
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> 
> Signed-off-by: Ong Hean Loong 
> ---
> V7:
> *Fix Comments. Fix indentation in Makefile
> 
> V6:
> *Fix Comments. Commit comments need to be discriptive
> 
> V5:
> *Fix Comments. Remove dem_kfree and bits per symbol
> 
> V4:
> *No fixes.
> 
> V3:
> *Changes to fixing drm_simple_pipe
> *Used drm_fb_cma_get_gem_addr
> 
> V2:
> *Adding drm_simple_display_pipe_init
> 
> ---
> ---
>  drivers/gpu/drm/Kconfig   |   2 +
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/ivip/Kconfig  |  14 +++
>  drivers/gpu/drm/ivip/Makefile |   9 ++
>  drivers/gpu/drm/ivip/intel_vip_conn.c |  96 +
>  drivers/gpu/drm/ivip/intel_vip_core.c | 162 
>  drivers/gpu/drm/ivip/intel_vip_drv.h  |  52 +
>  drivers/gpu/drm/ivip/intel_vip_of.c   | 194 
> ++
>  8 files changed, 530 insertions(+)
>  create mode 100644 drivers/gpu/drm/ivip/Kconfig
>  create mode 100644 drivers/gpu/drm/ivip/Makefile
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a8..38a184d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -195,6 +195,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
>  
>  source "drivers/gpu/drm/i915/Kconfig"
>  
> +source "drivers/gpu/drm/ivip/Kconfig"
> +
>  config DRM_VGEM
>   tristate "Virtual GEM provider"
>   depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e..4162a0e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
>  obj-$(CONFIG_DRM_MGA)+= mga/
>  obj-$(CONFIG_DRM_I810)   += i810/
>  obj-$(CONFIG_DRM_I915)   += i915/
> +obj-$(CONFIG_DRM_IVIP) += ivip/
>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
>  obj-$(CONFIG_DRM_VC4)  += vc4/
>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
> new file mode 100644
> index 000..bf2d995
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Kconfig
> @@ -0,0 +1,14 @@
> +config DRM_IVIP
> +tristate "Intel FGPA Video and Image Processing"
> +depends on DRM && OF
> +select DRM_GEM_CMA_HELPER
> +select DRM_KMS_HELPER
> +select DRM_KMS_FB_HELPER
> +select DRM_KMS_CMA_HELPER
> +help
> +   Choose this option if you have an Intel FPGA Arria 10 system
> +   and above with an Intel Display Port IP. This does not support
> +   legacy Intel FPGA Cyclone V display port. Currently only 
> single
> +   frame buffer is supported. Note that ACPI and X_86 
> architecture
> +   is not supported for Arria10. If M is selected the module 
> will be
> +   called ivip.
> diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
> new file mode 100644
> index 000..cc55b04
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the drm device driver.  This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +ccflags-y := -Iinclude/drm
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> + intel_vip_conn.o
> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c 
> b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 000..c88df23
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,96 @@
> +/*
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR

Re: [PATCH v4] drm/bridge/sii8620: add remote control support

2017-09-05 Thread Maciej Purski


Hi Hans,

According to my tests, when pressing 'Press and Hold' key, the messages 
received are
always the same until the button is released. The second message is received 
after
~550 ms and each next message is received every ~100 ms.

Regards,

Maciej

On 27/08/2017 14:40, Hans Verkuil wrote:


Hi Maciej,

On 24/08/17 10:58, Maciej Purski wrote:

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Before I Ack this I would like to know how this behaves w.r.t. autorepeat.

If you keep pressing a remote key, what RCP messages do you receive and
at what time intervals? If that's similar to what CEC does, then it is
very likely that the same rules apply and I will have to review this patch
again with that in mind.

See the commit log for the patching fixing the CEC 'Press and Hold' behavior:

https://git.linuxtv.org/media_tree.git/commit/drivers/media/cec/cec-adap.c?id=a9a249a2c997506a64eaee22f1458fda893f62a8

If you have access to the HDMI 2.0 specification, then that spec describes the 
CEC
'Press and Hold' behavior in detail.

Regards,

Hans


Signed-off-by: Maciej Purski 
---

Changes in v2:
- use RC subsystem (including CEC keymap)
- RC device initialized in attach drm_bridge callback and
   removed in detach callback. This is necessary, because RC_CORE,
   which is needed during rc_dev init, is loaded after sii8620.
   DRM bridge is binded later which solves the problem.
- add RC_CORE dependency

Changes in v3:
- fix error handling in init_rcp and in attach callback

Changes in v4:
- usage of rc-core API compatible with upcoming changes
- fix error handling in init_rcp
- fix commit message
---
  drivers/gpu/drm/bridge/Kconfig   |  2 +-
  drivers/gpu/drm/bridge/sil-sii8620.c | 96 ++--
  include/drm/bridge/mhl.h |  4 ++
  3 files changed, 96 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..6ef901c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
  
  config DRM_SIL_SII8620

tristate "Silicon Image SII8620 HDMI/MHL bridge"
-   depends on OF
+   depends on OF && RC_CORE
select DRM_KMS_HELPER
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..ecb26c4 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -28,6 +28,8 @@
  #include 
  #include 
  
+#include 

+
  #include "sil-sii8620.h"
  
  #define SII8620_BURST_BUF_LEN 288

@@ -58,6 +60,7 @@ enum sii8620_mt_state {
  struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct rc_dev *rc_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
  }
  
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)

+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
struct sii8620_mt_msg *msg)
  {
@@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
  }
  
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)

+{
+   bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
+
+   scancode &= MHL_RCP_KEY_ID_MASK;
+
+   if (!ctx->rc_dev) {
+   dev_dbg(ctx->dev, "RCP input device not initialized\n");
+   return false;
+   }
+
+   if (pressed)
+   rc_keydown(ctx->rc_dev, RC_PROTO_CEC, scancode, 0);
+   else
+   rc_keyup(ctx->rc_dev);
+
+   return true;
+}
+
  static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
  {
u8 ints[MHL_INT_SIZE];
@@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
  
  static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)

  {
-   struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
+   struct sii8620_mt_msg *msg;
u8 buf[2];
  
-	if (!msg)

-   return;
-
sii8620_read_buf(ctx, REG_MSC_MR_MSC_MSG_RCVD_1ST_DATA, buf, 2);
  
  	switch (buf[0]) {

case MHL_MSC_MSG_RAPK:
+   msg = sii8620_msc_msg_first(ctx);
+   if (!msg)
+   return;

[Bug 102543] [BAT][HSW] igt@tools_test@tools_test - Unclaimed read from register 0x[4c]400c

2017-09-05 Thread bugzilla-daemon

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #1 from Chris Wilson  ---
That looks entirely to be a test bug, intel_reg_read reading unknown registers
which is then caught by the kernel on its next mmio. Since the kernel is not
aware of a third party messing around with registers, it takes the blame upon
itself.

-- 
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 5/6] gpu: host1x: Add Tegra186 support

2017-09-05 Thread Mikko Perttunen

Add support for the implementation of Host1x present on the Tegra186.
The register space has been shuffled around a little bit, requiring
addition of some chip-specific code sections. Tegra186 also adds
several new features, most importantly the hypervisor, but those are
not yet supported with this commit.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/Makefile|   3 +-
 drivers/gpu/host1x/dev.c   |  60 +++-
 drivers/gpu/host1x/dev.h   |   4 +
 drivers/gpu/host1x/hw/cdma_hw.c|  49 ---
 drivers/gpu/host1x/hw/debug_hw.c   | 137 +--
 drivers/gpu/host1x/hw/debug_hw_1x01.c  | 154 +
 drivers/gpu/host1x/hw/debug_hw_1x06.c  | 133 ++
 drivers/gpu/host1x/hw/host1x01.c   |   2 +
 drivers/gpu/host1x/hw/host1x02.c   |   2 +
 drivers/gpu/host1x/hw/host1x04.c   |   2 +
 drivers/gpu/host1x/hw/host1x05.c   |   2 +
 drivers/gpu/host1x/hw/host1x06.c   |  44 ++
 drivers/gpu/host1x/hw/host1x06.h   |  26 
 drivers/gpu/host1x/hw/host1x06_hardware.h  | 142 +++
 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h |  32 +
 drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 181 +
 drivers/gpu/host1x/hw/hw_host1x06_vm.h |  47 +++
 drivers/gpu/host1x/hw/intr_hw.c|  29 ++--
 18 files changed, 880 insertions(+), 169 deletions(-)
 create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x01.c
 create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x06.c
 create mode 100644 drivers/gpu/host1x/hw/host1x06.c
 create mode 100644 drivers/gpu/host1x/hw/host1x06.h
 create mode 100644 drivers/gpu/host1x/hw/host1x06_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_uclass.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_vm.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index a1d9974cfcb5..4fb61bd57aee 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -11,6 +11,7 @@ host1x-y = \
hw/host1x01.o \
hw/host1x02.o \
hw/host1x04.o \
-   hw/host1x05.o
+   hw/host1x05.o \
+   hw/host1x06.o
 
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 2c58a390123a..6a4ff2d59496 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -39,6 +39,17 @@
 #include "hw/host1x02.h"
 #include "hw/host1x04.h"
 #include "hw/host1x05.h"
+#include "hw/host1x06.h"
+
+void host1x_hypervisor_writel(struct host1x *host1x, u32 v, u32 r)
+{
+   writel(v, host1x->hv_regs + r);
+}
+
+u32 host1x_hypervisor_readl(struct host1x *host1x, u32 r)
+{
+   return readl(host1x->hv_regs + r);
+}
 
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
 {
@@ -104,7 +115,19 @@ static const struct host1x_info host1x05_info = {
.dma_mask = DMA_BIT_MASK(34),
 };
 
+static const struct host1x_info host1x06_info = {
+   .nb_channels = 63,
+   .nb_pts = 576,
+   .nb_mlocks = 24,
+   .nb_bases = 16,
+   .init = host1x06_init,
+   .sync_offset = 0x0,
+   .dma_mask = DMA_BIT_MASK(34),
+   .has_hypervisor = true,
+};
+
 static const struct of_device_id host1x_of_match[] = {
+   { .compatible = "nvidia,tegra186-host1x", .data = _info, },
{ .compatible = "nvidia,tegra210-host1x", .data = _info, },
{ .compatible = "nvidia,tegra124-host1x", .data = _info, },
{ .compatible = "nvidia,tegra114-host1x", .data = _info, },
@@ -117,8 +140,9 @@ MODULE_DEVICE_TABLE(of, host1x_of_match);
 static int host1x_probe(struct platform_device *pdev)
 {
const struct of_device_id *id;
+   const struct host1x_info *info;
struct host1x *host;
-   struct resource *regs;
+   struct resource *regs, *hv_regs = NULL;
int syncpt_irq;
int err;
 
@@ -126,10 +150,28 @@ static int host1x_probe(struct platform_device *pdev)
if (!id)
return -EINVAL;
 
-   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!regs) {
-   dev_err(>dev, "failed to get registers\n");
-   return -ENXIO;
+   info = id->data;
+
+   if (info->has_hypervisor) {
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vm");
+   if (!regs) {
+   dev_err(>dev, "failed to get vm registers\n");
+   return -ENXIO;
+   }
+
+   hv_regs = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "hypervisor");
+   if (!hv_regs) {
+

[PATCH v2 3/6] arm64: tegra: Add VIC on Tegra186

2017-09-05 Thread Mikko Perttunen

Add a node for the Video Image Compositor on the Tegra186.

Signed-off-by: Mikko Perttunen 
---
v2:
- Fixed reg property in accordance with changed parent cells.

 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b1a3e404c7be..584bce64d41f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -371,6 +371,18 @@
#size-cells = <1>;
 
ranges = <0x1500 0x0 0x1500 0x0100>;
+
+   vic@1534 {
+   compatible = "nvidia,tegra186-vic";
+   reg = <0x1534 0x4>;
+   interrupts = ;
+   clocks = < TEGRA186_CLK_VIC>;
+   clock-names = "vic";
+   resets = < TEGRA186_RESET_VIC>;
+   reset-names = "vic";
+
+   power-domains = < TEGRA186_POWER_DOMAIN_VIC>;
+   };
};
 
gpu@1700 {
-- 
2.14.1

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

[PATCH v2 2/6] arm64: tegra: Add host1x on Tegra186

2017-09-05 Thread Mikko Perttunen

Add the node for Host1x on the Tegra186, without any subdevices
for now.

Signed-off-by: Mikko Perttunen 
---
v2:
- Changed address-cells and size-cells to 1 and fixed the ranges
  property correspondingly.

 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index a964d246c0e9..b1a3e404c7be 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -355,6 +355,24 @@
nvidia,bpmp = <>;
};
 
+   host1x@13e0 {
+   compatible = "nvidia,tegra186-host1x", "simple-bus";
+   reg = <0x0 0x13e0 0x0 0x1>,
+ <0x0 0x13e1 0x0 0x1>;
+   reg-names = "hypervisor", "vm";
+   interrupts = ,
+;
+   clocks = < TEGRA186_CLK_HOST1X>;
+   clock-names = "host1x";
+   resets = < TEGRA186_RESET_HOST1X>;
+   reset-names = "host1x";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   ranges = <0x1500 0x0 0x1500 0x0100>;
+   };
+
gpu@1700 {
compatible = "nvidia,gp10b";
reg = <0x0 0x1700 0x0 0x100>,
-- 
2.14.1

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

[PATCH v2 0/6] Host1x and VIC support for Tegra186

2017-09-05 Thread Mikko Perttunen

Hi,

not many changes in v2:

Changed address-cells and size-cells for the Host1x device tree node
to have value 1, since all subdevices fit in the lower 4G. Also dropped
the incorrect change about this from the dt-bindings patch. Thanks to
Rob for pointing this out.

Mikko

Notes for v1:

Hi everyone,

this series adds basic support for the Host1x channel engine and the
VIC 2d compositor unit on Tegra186. The first three patches do the
required device tree changes, the fourth patch updates the device tree
binding documentation, and the two remaining patches add the actual
implementation, almost all of which is in Host1x itself.

The Tegra186 Host1x is a relatively large update over previous
generations, which can be seen in the diffstat. The biggest change is
that Host1x is now contains separate hypervisor and vm register
apertures to support virtualization at the hardware level. This driver,
however, currently assumes that this instance of Linux is the sole
operating system having access to the hardware.

This combined with increased numbers of supported channels and
syncpoints have caused a number of register space changes that are
responsible for most of the updated code.

The series has been tested on the Jetson TX1 (T210) and TX2 (T186)
using the host1x_test test suite available at

http://github.com/cyndis/host1x_test

The series itself is available at

http://github.com/cyndis/linux, branch host1x-t186-1

Cheers,
Mikko

Mikko Perttunen (6):
  arm64: tegra: Add #power-domain-cells for BPMP
  arm64: tegra: Add host1x on Tegra186
  arm64: tegra: Add VIC on Tegra186
  dt-bindings: host1x: Add Tegra186 information
  gpu: host1x: Add Tegra186 support
  drm/tegra: Add Tegra186 support for VIC

 .../display/tegra/nvidia,tegra20-host1x.txt|   4 +
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   |  31 
 drivers/gpu/drm/tegra/drm.c|   1 +
 drivers/gpu/drm/tegra/vic.c|  10 ++
 drivers/gpu/host1x/Makefile|   3 +-
 drivers/gpu/host1x/dev.c   |  60 ++-
 drivers/gpu/host1x/dev.h   |   4 +
 drivers/gpu/host1x/hw/cdma_hw.c|  49 +++---
 drivers/gpu/host1x/hw/debug_hw.c   | 137 +---
 drivers/gpu/host1x/hw/debug_hw_1x01.c  | 154 ++
 drivers/gpu/host1x/hw/debug_hw_1x06.c  | 133 +++
 drivers/gpu/host1x/hw/host1x01.c   |   2 +
 drivers/gpu/host1x/hw/host1x02.c   |   2 +
 drivers/gpu/host1x/hw/host1x04.c   |   2 +
 drivers/gpu/host1x/hw/host1x05.c   |   2 +
 drivers/gpu/host1x/hw/host1x06.c   |  44 +
 drivers/gpu/host1x/hw/host1x06.h   |  26 +++
 drivers/gpu/host1x/hw/host1x06_hardware.h  | 142 
 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h |  32 
 drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 181 +
 drivers/gpu/host1x/hw/hw_host1x06_vm.h |  47 ++
 drivers/gpu/host1x/hw/intr_hw.c|  29 ++--
 22 files changed, 926 insertions(+), 169 deletions(-)
 create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x01.c
 create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x06.c
 create mode 100644 drivers/gpu/host1x/hw/host1x06.c
 create mode 100644 drivers/gpu/host1x/hw/host1x06.h
 create mode 100644 drivers/gpu/host1x/hw/host1x06_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_uclass.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_vm.h

-- 
2.14.1

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

[PATCH v2 1/6] arm64: tegra: Add #power-domain-cells for BPMP

2017-09-05 Thread Mikko Perttunen

Add #power-domain-cells for the BPMP node on Tegra186 so that the power
domain provider may be used.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 0b0552c9f7dd..a964d246c0e9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -443,6 +443,7 @@
shmem = <_bpmp_tx _bpmp_rx>;
#clock-cells = <1>;
#reset-cells = <1>;
+   #power-domain-cells = <1>;
 
bpmp_i2c: i2c {
compatible = "nvidia,tegra186-bpmp-i2c";
-- 
2.14.1

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

[PATCH v2 6/6] drm/tegra: Add Tegra186 support for VIC

2017-09-05 Thread Mikko Perttunen

Add Tegra186 support for VIC - no changes are required except for new
firmware and compatibility string.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c |  1 +
 drivers/gpu/drm/tegra/vic.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3ba659a5940d..e3331a2bc082 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1281,6 +1281,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra210-sor", },
{ .compatible = "nvidia,tegra210-sor1", },
{ .compatible = "nvidia,tegra210-vic", },
+   { .compatible = "nvidia,tegra186-vic", },
{ /* sentinel */ }
 };
 
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 2448229fa653..6697a21a250d 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -270,9 +270,16 @@ static const struct vic_config vic_t210_config = {
.firmware = NVIDIA_TEGRA_210_VIC_FIRMWARE,
 };
 
+#define NVIDIA_TEGRA_186_VIC_FIRMWARE "nvidia/tegra186/vic04_ucode.bin"
+
+static const struct vic_config vic_t186_config = {
+   .firmware = NVIDIA_TEGRA_186_VIC_FIRMWARE,
+};
+
 static const struct of_device_id vic_match[] = {
{ .compatible = "nvidia,tegra124-vic", .data = _t124_config },
{ .compatible = "nvidia,tegra210-vic", .data = _t210_config },
+   { .compatible = "nvidia,tegra186-vic", .data = _t186_config },
{ },
 };
 
@@ -405,3 +412,6 @@ MODULE_FIRMWARE(NVIDIA_TEGRA_124_VIC_FIRMWARE);
 #if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
 MODULE_FIRMWARE(NVIDIA_TEGRA_210_VIC_FIRMWARE);
 #endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
+MODULE_FIRMWARE(NVIDIA_TEGRA_186_VIC_FIRMWARE);
+#endif
-- 
2.14.1

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

[PATCH v2 4/6] dt-bindings: host1x: Add Tegra186 information

2017-09-05 Thread Mikko Perttunen

Add the Tegra186-specific hypervisor-related register range
properties.

Signed-off-by: Mikko Perttunen 
---
v2:
- Dropped incorrect note about cells properties.

 .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt   | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 74e1e8add5a1..844e0103fb0d 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -3,6 +3,10 @@ NVIDIA Tegra host1x
 Required properties:
 - compatible: "nvidia,tegra-host1x"
 - reg: Physical base address and length of the controller's registers.
+  For pre-Tegra186, one entry describing the whole register area.
+  For Tegra186, one entry for each entry in reg-names:
+"vm" - VM region assigned to Linux
+"hypervisor" - Hypervisor region (only if Linux acts as hypervisor)
 - interrupts: The interrupt outputs from the controller.
 - #address-cells: The number of cells used to represent physical base addresses
   in the host1x address space. Should be 1.
-- 
2.14.1

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

[PATCH] drm: exynos: include linux/irq.h

2017-09-05 Thread Arnd Bergmann

I ran into a build error on x86:

drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_conf_irq':
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:706:2: error: implicit 
declaration of function 'irq_set_status_flags'; did you mean 
'dquot_state_flag'? [-Werror=implicit-function-declaration]
  irq_set_status_flags(irq, IRQ_NOAUTOEN);

Adding the missing include fixes the error.

Fixes: b37d53a0382c ("drm/exynos/decon5433: move TE handling to DECON")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 730b8d9db187..6be5b53c3b27 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.0

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

[PATCH v2 2/6] gpu: host1x: Enable gather filter

2017-09-05 Thread Mikko Perttunen

The gather filter is a feature present on Tegra124 and newer where the
hardware prevents GATHERed command buffers from executing commands
normally reserved for the CDMA pushbuffer which is maintained by the
kernel driver.

This commit enables the gather filter on all supporting hardware.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/hw/channel_hw.c  | 22 ++
 drivers/gpu/host1x/hw/hw_host1x04_channel.h | 12 
 drivers/gpu/host1x/hw/hw_host1x05_channel.h | 12 
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index 0161da331702..5c0dc6bb51d1 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -181,10 +181,32 @@ static int channel_submit(struct host1x_job *job)
return err;
 }
 
+static void enable_gather_filter(struct host1x *host,
+struct host1x_channel *ch)
+{
+#if HOST1X_HW >= 6
+   u32 val;
+
+   if (!host->hv_regs)
+   return;
+
+   val = host1x_hypervisor_readl(
+   host, HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(ch->id / 32));
+   val |= BIT(ch->id % 32);
+   host1x_hypervisor_writel(
+   host, val, HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(ch->id / 32));
+#elif HOST1X_HW >= 4
+   host1x_ch_writel(ch,
+HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(1),
+HOST1X_CHANNEL_CHANNELCTRL);
+#endif
+}
+
 static int host1x_channel_init(struct host1x_channel *ch, struct host1x *dev,
   unsigned int index)
 {
ch->regs = dev->regs + index * HOST1X_CHANNEL_SIZE;
+   enable_gather_filter(dev, ch);
return 0;
 }
 
diff --git a/drivers/gpu/host1x/hw/hw_host1x04_channel.h 
b/drivers/gpu/host1x/hw/hw_host1x04_channel.h
index 95e6f96142b9..2e8b635aa660 100644
--- a/drivers/gpu/host1x/hw/hw_host1x04_channel.h
+++ b/drivers/gpu/host1x/hw/hw_host1x04_channel.h
@@ -117,5 +117,17 @@ static inline u32 host1x_channel_dmactrl_dmainitget(void)
 }
 #define HOST1X_CHANNEL_DMACTRL_DMAINITGET \
host1x_channel_dmactrl_dmainitget()
+static inline u32 host1x_channel_channelctrl_r(void)
+{
+   return 0x98;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL \
+   host1x_channel_channelctrl_r()
+static inline u32 host1x_channel_channelctrl_kernel_filter_gbuffer_f(u32 v)
+{
+   return (v & 0x1) << 2;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(v) \
+   host1x_channel_channelctrl_kernel_filter_gbuffer_f(v)
 
 #endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x05_channel.h 
b/drivers/gpu/host1x/hw/hw_host1x05_channel.h
index fce6e2c1ff4c..abbbc2641ce6 100644
--- a/drivers/gpu/host1x/hw/hw_host1x05_channel.h
+++ b/drivers/gpu/host1x/hw/hw_host1x05_channel.h
@@ -117,5 +117,17 @@ static inline u32 host1x_channel_dmactrl_dmainitget(void)
 }
 #define HOST1X_CHANNEL_DMACTRL_DMAINITGET \
host1x_channel_dmactrl_dmainitget()
+static inline u32 host1x_channel_channelctrl_r(void)
+{
+   return 0x98;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL \
+   host1x_channel_channelctrl_r()
+static inline u32 host1x_channel_channelctrl_kernel_filter_gbuffer_f(u32 v)
+{
+   return (v & 0x1) << 2;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(v) \
+   host1x_channel_channelctrl_kernel_filter_gbuffer_f(v)
 
 #endif
-- 
2.14.1

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

[PATCH v2 4/6] gpu: host1x: Disassemble more instructions

2017-09-05 Thread Mikko Perttunen

The disassembler for debug dumps was missing some newer host1x opcodes.
Add disassembly support for these.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/hw/debug_hw.c  | 57 ---
 drivers/gpu/host1x/hw/debug_hw_1x01.c |  3 +-
 drivers/gpu/host1x/hw/debug_hw_1x06.c |  3 +-
 3 files changed, 57 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 1e67667e308c..de2a0ba7a32d 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -30,6 +30,13 @@ enum {
HOST1X_OPCODE_IMM   = 0x04,
HOST1X_OPCODE_RESTART   = 0x05,
HOST1X_OPCODE_GATHER= 0x06,
+   HOST1X_OPCODE_SETSTRMID = 0x07,
+   HOST1X_OPCODE_SETAPPID  = 0x08,
+   HOST1X_OPCODE_SETPYLD   = 0x09,
+   HOST1X_OPCODE_INCR_W= 0x0a,
+   HOST1X_OPCODE_NONINCR_W = 0x0b,
+   HOST1X_OPCODE_GATHER_W  = 0x0c,
+   HOST1X_OPCODE_RESTART_W = 0x0d,
HOST1X_OPCODE_EXTEND= 0x0e,
 };
 
@@ -38,11 +45,16 @@ enum {
HOST1X_OPCODE_EXTEND_RELEASE_MLOCK  = 0x01,
 };
 
-static unsigned int show_channel_command(struct output *o, u32 val)
+#define INVALID_PAYLOAD0x
+
+static unsigned int show_channel_command(struct output *o, u32 val,
+u32 *payload)
 {
-   unsigned int mask, subop, num;
+   unsigned int mask, subop, num, opcode;
+
+   opcode = val >> 28;
 
-   switch (val >> 28) {
+   switch (opcode) {
case HOST1X_OPCODE_SETCLASS:
mask = val & 0x3f;
if (mask) {
@@ -97,6 +109,42 @@ static unsigned int show_channel_command(struct output *o, 
u32 val)
val >> 14 & 0x1, val & 0x3fff);
return 1;
 
+   case HOST1X_OPCODE_SETSTRMID:
+   host1x_debug_cont(o, "SETSTRMID(offset=%06x)\n",
+ val & 0x3f);
+   return 0;
+
+   case HOST1X_OPCODE_SETAPPID:
+   host1x_debug_cont(o, "SETAPPID(appid=%02x)\n", val & 0xff);
+   return 0;
+
+   case HOST1X_OPCODE_SETPYLD:
+   *payload = val & 0x;
+   host1x_debug_cont(o, "SETPYLD(data=%04x)\n", *payload);
+   return 0;
+
+   case HOST1X_OPCODE_INCR_W:
+   case HOST1X_OPCODE_NONINCR_W:
+   host1x_debug_cont(o, "%s(offset=%06x, ",
+ opcode == HOST1X_OPCODE_INCR_W ?
+   "INCR_W" : "NONINCR_W",
+ val & 0x3f);
+   if (*payload == 0) {
+   host1x_debug_cont(o, "[])\n");
+   return 0;
+   } else if (*payload == INVALID_PAYLOAD) {
+   host1x_debug_cont(o, "unknown)\n");
+   return 0;
+   } else {
+   host1x_debug_cont(o, "[");
+   return *payload;
+   }
+
+   case HOST1X_OPCODE_GATHER_W:
+   host1x_debug_cont(o, "GATHER_W(count=%04x, addr=[",
+ val & 0x3fff);
+   return 2;
+
case HOST1X_OPCODE_EXTEND:
subop = val >> 24 & 0xf;
if (subop == HOST1X_OPCODE_EXTEND_ACQUIRE_MLOCK)
@@ -122,6 +170,7 @@ static void show_gather(struct output *o, phys_addr_t 
phys_addr,
/* Map dmaget cursor to corresponding mem handle */
u32 offset = phys_addr - pin_addr;
unsigned int data_count = 0, i;
+   u32 payload = INVALID_PAYLOAD;
 
/*
 * Sometimes we're given different hardware address to the same
@@ -139,7 +188,7 @@ static void show_gather(struct output *o, phys_addr_t 
phys_addr,
 
if (!data_count) {
host1x_debug_output(o, "%08x: %08x: ", addr, val);
-   data_count = show_channel_command(o, val);
+   data_count = show_channel_command(o, val, );
} else {
host1x_debug_cont(o, "%08x%s", val,
data_count > 1 ? ", " : "])\n");
diff --git a/drivers/gpu/host1x/hw/debug_hw_1x01.c 
b/drivers/gpu/host1x/hw/debug_hw_1x01.c
index 09e1aa7bb5dd..7d1401c6c193 100644
--- a/drivers/gpu/host1x/hw/debug_hw_1x01.c
+++ b/drivers/gpu/host1x/hw/debug_hw_1x01.c
@@ -78,6 +78,7 @@ static void host1x_debug_show_channel_fifo(struct host1x 
*host,
   struct output *o)
 {
u32 val, rd_ptr, wr_ptr, start, end;
+   u32 payload = INVALID_PAYLOAD;
unsigned int data_count = 0;
 
host1x_debug_output(o, "%u: fifo:\n", ch->id);
@@ -112,7 +113,7 @@ static void host1x_debug_show_channel_fifo(struct host1x 
*host,
 
if (!data_count) {
host1x_debug_output(o, "%08x: ",

[PATCH v2 1/6] gpu: host1x: Enable Tegra186 syncpoint protection

2017-09-05 Thread Mikko Perttunen

Since Tegra186 the Host1x hardware allows syncpoints to be assigned to
specific channels, preventing any other channels from incrementing
them.

Enable this feature where available and assign syncpoints to channels
when submitting a job. Syncpoints are currently never unassigned from
channels since that would require extra work and is unnecessary with
the current channel allocation model.

Signed-off-by: Mikko Perttunen 
---

Notes:
v2:
- Changed from set_protection(bool) to enable_protection
- Added some comments
- Added missing check for hv_regs being NULL in
  enable_protection

 drivers/gpu/host1x/dev.h   | 15 +
 drivers/gpu/host1x/hw/channel_hw.c |  3 +++
 drivers/gpu/host1x/hw/syncpt_hw.c  | 46 ++
 drivers/gpu/host1x/syncpt.c|  8 +++
 4 files changed, 72 insertions(+)

diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index def802c0a6bf..7497cc5ead9e 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -79,6 +79,9 @@ struct host1x_syncpt_ops {
u32 (*load)(struct host1x_syncpt *syncpt);
int (*cpu_incr)(struct host1x_syncpt *syncpt);
int (*patch_wait)(struct host1x_syncpt *syncpt, void *patch_addr);
+   void (*assign_channel)(struct host1x_syncpt *syncpt,
+  struct host1x_channel *channel);
+   void (*enable_protection)(struct host1x *host);
 };
 
 struct host1x_intr_ops {
@@ -186,6 +189,18 @@ static inline int host1x_hw_syncpt_patch_wait(struct 
host1x *host,
return host->syncpt_op->patch_wait(sp, patch_addr);
 }
 
+static inline void host1x_hw_syncpt_assign_channel(struct host1x *host,
+  struct host1x_syncpt *sp,
+  struct host1x_channel *ch)
+{
+   return host->syncpt_op->assign_channel(sp, ch);
+}
+
+static inline void host1x_hw_syncpt_enable_protection(struct host1x *host)
+{
+   return host->syncpt_op->enable_protection(host);
+}
+
 static inline int host1x_hw_intr_init_host_sync(struct host1x *host, u32 cpm,
void (*syncpt_thresh_work)(struct work_struct *))
 {
diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index 8447a56c41ca..0161da331702 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -147,6 +147,9 @@ static int channel_submit(struct host1x_job *job)
 
syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
 
+   /* assign syncpoint to channel */
+   host1x_hw_syncpt_assign_channel(host, sp, ch);
+
job->syncpt_end = syncval;
 
/* add a setclass for modules that require it */
diff --git a/drivers/gpu/host1x/hw/syncpt_hw.c 
b/drivers/gpu/host1x/hw/syncpt_hw.c
index 7b0270d60742..dc7a44614fef 100644
--- a/drivers/gpu/host1x/hw/syncpt_hw.c
+++ b/drivers/gpu/host1x/hw/syncpt_hw.c
@@ -106,6 +106,50 @@ static int syncpt_patch_wait(struct host1x_syncpt *sp, 
void *patch_addr)
return 0;
 }
 
+/**
+ * syncpt_assign_channel() - Assign syncpoint to channel
+ * @sp: syncpoint
+ * @ch: channel
+ *
+ * On chips with the syncpoint protection feature (Tegra186+), assign @sp to
+ * @ch, preventing other channels from incrementing the syncpoints. If @ch is
+ * NULL, unassigns the syncpoint.
+ *
+ * On older chips, do nothing.
+ */
+static void syncpt_assign_channel(struct host1x_syncpt *sp,
+ struct host1x_channel *ch)
+{
+#if HOST1X_HW >= 6
+   struct host1x *host = sp->host;
+
+   if (!host->hv_regs)
+   return;
+
+   host1x_sync_writel(host,
+  HOST1X_SYNC_SYNCPT_CH_APP_CH(ch ? ch->id : 0xff),
+  HOST1X_SYNC_SYNCPT_CH_APP(sp->id));
+#endif
+}
+
+/**
+ * syncpt_enable_protection() - Enable syncpoint protection
+ * @host: host1x instance
+ *
+ * On chips with the syncpoint protection feature (Tegra186+), enable this
+ * feature. On older chips, do nothing.
+ */
+static void syncpt_enable_protection(struct host1x *host)
+{
+#if HOST1X_HW >= 6
+   if (!host->hv_regs)
+   return;
+
+   host1x_hypervisor_writel(host, HOST1X_HV_SYNCPT_PROT_EN_CH_EN,
+HOST1X_HV_SYNCPT_PROT_EN);
+#endif
+}
+
 static const struct host1x_syncpt_ops host1x_syncpt_ops = {
.restore = syncpt_restore,
.restore_wait_base = syncpt_restore_wait_base,
@@ -113,4 +157,6 @@ static const struct host1x_syncpt_ops host1x_syncpt_ops = {
.load = syncpt_load,
.cpu_incr = syncpt_cpu_incr,
.patch_wait = syncpt_patch_wait,
+   .assign_channel = syncpt_assign_channel,
+   .enable_protection = syncpt_enable_protection,
 };
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 048ac9e344ce..4c7a4c8b2ad2 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@

[PATCH v2 6/6] drm/tegra: Use u64_to_user_ptr helper

2017-09-05 Thread Mikko Perttunen

Use the u64_to_user_ptr helper macro to cast IOCTL argument u64 values
to user pointers instead of writing out the cast manually.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e3331a2bc082..72d5c0021540 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -388,18 +388,21 @@ int tegra_drm_submit(struct tegra_drm_context *context,
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
unsigned int num_waitchks = args->num_waitchks;
-   struct drm_tegra_cmdbuf __user *cmdbufs =
-   (void __user *)(uintptr_t)args->cmdbufs;
-   struct drm_tegra_reloc __user *relocs =
-   (void __user *)(uintptr_t)args->relocs;
-   struct drm_tegra_waitchk __user *waitchks =
-   (void __user *)(uintptr_t)args->waitchks;
+   struct drm_tegra_cmdbuf __user *cmdbufs;
+   struct drm_tegra_reloc __user *relocs;
+   struct drm_tegra_waitchk __user *waitchks;
+   struct drm_tegra_syncpt __user *user_syncpt;
struct drm_tegra_syncpt syncpt;
struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
struct host1x_syncpt *sp;
struct host1x_job *job;
int err;
 
+   cmdbufs = u64_to_user_ptr(args->cmdbufs);
+   relocs = u64_to_user_ptr(args->relocs);
+   waitchks = u64_to_user_ptr(args->waitchks);
+   user_syncpt = u64_to_user_ptr(args->syncpts);
+
/* We don't yet support other than one syncpt_incr struct per submit */
if (args->num_syncpts != 1)
return -EINVAL;
@@ -520,8 +523,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
}
}
 
-   if (copy_from_user(, (void __user *)(uintptr_t)args->syncpts,
-  sizeof(syncpt))) {
+   if (copy_from_user(, user_syncpt, sizeof(syncpt))) {
err = -EFAULT;
goto fail;
}
-- 
2.14.1

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

[PATCH v2 0/6] Miscellaneous improvements to Host1x and TegraDRM

2017-09-05 Thread Mikko Perttunen

New in v2:
- Changes in syncpoint protection and u64_to_user_ptr patches.
  See the patches for notes.
- Added patch to support more opcodes in the debug dump 
  disassembly.
- Added patch to fix an incorrect comment.

Thanks,
Mikko

Patch v1 notes:

Hi all,

here are some new features and improvements.

Patch 1 enables syncpoint protection which prevents channels from
touching syncpoints not belonging to them on Tegra186.

Patch 2 enables the gather filter which prevents userspace command
buffers from using CDMA commands usually reserved for the kernel.
A test is available at git://github.com/cyndis/host1x_test, branch
gather-filter.

Patch 3 greatly improves formatting of debug dumps spewed by host1x
in case of job timeouts. They are now actually readable by humans
without use of additional scripts.

Patch 4 is a simple aesthetical fix to the TegraDRM submit path.

Everything was tested on TX1 and TX2 and should be applied on the
previously posted Tegra186 support series.

Cheers,
Mikko

Mikko Perttunen (6):
  gpu: host1x: Enable Tegra186 syncpoint protection
  gpu: host1x: Enable gather filter
  gpu: host1x: Improve debug disassembly formatting
  gpu: host1x: Disassemble more instructions
  gpu: host1x: Fix incorrect comment for channel_request
  drm/tegra: Use u64_to_user_ptr helper

 drivers/gpu/drm/tegra/drm.c |  18 ++---
 drivers/gpu/host1x/channel.c|   3 +-
 drivers/gpu/host1x/debug.c  |  14 +++-
 drivers/gpu/host1x/debug.h  |  14 ++--
 drivers/gpu/host1x/dev.h|  15 +
 drivers/gpu/host1x/hw/channel_hw.c  |  25 +++
 drivers/gpu/host1x/hw/debug_hw.c| 101 ++--
 drivers/gpu/host1x/hw/debug_hw_1x01.c   |  11 +--
 drivers/gpu/host1x/hw/debug_hw_1x06.c   |  12 ++--
 drivers/gpu/host1x/hw/hw_host1x04_channel.h |  12 
 drivers/gpu/host1x/hw/hw_host1x05_channel.h |  12 
 drivers/gpu/host1x/hw/syncpt_hw.c   |  46 +
 drivers/gpu/host1x/syncpt.c |   8 +++
 13 files changed, 246 insertions(+), 45 deletions(-)

-- 
2.14.1

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

[PATCH v2 5/6] gpu: host1x: Fix incorrect comment for channel_request

2017-09-05 Thread Mikko Perttunen

This function actually doesn't sleep in the version that was merged.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/channel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index db9b91d1384c..2fb93c27c1d9 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -128,8 +128,7 @@ static struct host1x_channel *acquire_unused_channel(struct 
host1x *host)
  * host1x_channel_request() - Allocate a channel
  * @device: Host1x unit this channel will be used to send commands to
  *
- * Allocates a new host1x channel for @device. If there are no free channels,
- * this will sleep until one becomes available. May return NULL if CDMA
+ * Allocates a new host1x channel for @device. May return NULL if CDMA
  * initialization fails.
  */
 struct host1x_channel *host1x_channel_request(struct device *dev)
-- 
2.14.1

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

[PATCH v2 3/6] gpu: host1x: Improve debug disassembly formatting

2017-09-05 Thread Mikko Perttunen

The host1x driver prints out "disassembly" dumps of the command FIFO
and gather contents on submission timeouts. However, the output has
been quite difficult to read with unnecessary newlines and occasional
missing parentheses.

Fix these problems by using pr_cont to remove unnecessary newlines
and by fixing other small issues.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
This uses pr_cont, which there are currently talks of being replaced
with something better. I kept using it here for now until there is
some conclusion of what's the best way to replace it.

 drivers/gpu/host1x/debug.c| 14 ++-
 drivers/gpu/host1x/debug.h| 14 ---
 drivers/gpu/host1x/hw/debug_hw.c  | 46 ++-
 drivers/gpu/host1x/hw/debug_hw_1x01.c |  8 +++---
 drivers/gpu/host1x/hw/debug_hw_1x06.c |  9 ---
 5 files changed, 61 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index 2aae0e63214c..dc77ec452ffc 100644
--- a/drivers/gpu/host1x/debug.c
+++ b/drivers/gpu/host1x/debug.c
@@ -40,7 +40,19 @@ void host1x_debug_output(struct output *o, const char *fmt, 
...)
len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
va_end(args);
 
-   o->fn(o->ctx, o->buf, len);
+   o->fn(o->ctx, o->buf, len, false);
+}
+
+void host1x_debug_cont(struct output *o, const char *fmt, ...)
+{
+   va_list args;
+   int len;
+
+   va_start(args, fmt);
+   len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
+   va_end(args);
+
+   o->fn(o->ctx, o->buf, len, true);
 }
 
 static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo)
diff --git a/drivers/gpu/host1x/debug.h b/drivers/gpu/host1x/debug.h
index 4595b2e0799f..990cce47e737 100644
--- a/drivers/gpu/host1x/debug.h
+++ b/drivers/gpu/host1x/debug.h
@@ -24,22 +24,28 @@
 struct host1x;
 
 struct output {
-   void (*fn)(void *ctx, const char *str, size_t len);
+   void (*fn)(void *ctx, const char *str, size_t len, bool cont);
void *ctx;
char buf[256];
 };
 
-static inline void write_to_seqfile(void *ctx, const char *str, size_t len)
+static inline void write_to_seqfile(void *ctx, const char *str, size_t len,
+   bool cont)
 {
seq_write((struct seq_file *)ctx, str, len);
 }
 
-static inline void write_to_printk(void *ctx, const char *str, size_t len)
+static inline void write_to_printk(void *ctx, const char *str, size_t len,
+  bool cont)
 {
-   pr_info("%s", str);
+   if (cont)
+   pr_cont("%s", str);
+   else
+   pr_info("%s", str);
 }
 
 void __printf(2, 3) host1x_debug_output(struct output *o, const char *fmt, 
...);
+void __printf(2, 3) host1x_debug_cont(struct output *o, const char *fmt, ...);
 
 extern unsigned int host1x_debug_trace_cmdbuf;
 
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 770d92e62d69..1e67667e308c 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -40,48 +40,59 @@ enum {
 
 static unsigned int show_channel_command(struct output *o, u32 val)
 {
-   unsigned int mask, subop;
+   unsigned int mask, subop, num;
 
switch (val >> 28) {
case HOST1X_OPCODE_SETCLASS:
mask = val & 0x3f;
if (mask) {
-   host1x_debug_output(o, "SETCL(class=%03x, offset=%03x, 
mask=%02x, [",
+   host1x_debug_cont(o, "SETCL(class=%03x, offset=%03x, 
mask=%02x, [",
val >> 6 & 0x3ff,
val >> 16 & 0xfff, mask);
return hweight8(mask);
}
 
-   host1x_debug_output(o, "SETCL(class=%03x)\n", val >> 6 & 0x3ff);
+   host1x_debug_cont(o, "SETCL(class=%03x)\n", val >> 6 & 0x3ff);
return 0;
 
case HOST1X_OPCODE_INCR:
-   host1x_debug_output(o, "INCR(offset=%03x, [",
+   num = val & 0x;
+   host1x_debug_cont(o, "INCR(offset=%03x, [",
val >> 16 & 0xfff);
-   return val & 0x;
+   if (!num)
+   host1x_debug_cont(o, "])\n");
+
+   return num;
 
case HOST1X_OPCODE_NONINCR:
-   host1x_debug_output(o, "NONINCR(offset=%03x, [",
+   num = val & 0x;
+   host1x_debug_cont(o, "NONINCR(offset=%03x, [",
val >> 16 & 0xfff);
-   return val & 0x;
+   if (!num)
+   host1x_debug_cont(o, "])\n");
+
+   return num;
 
case HOST1X_OPCODE_MASK:
mask = val & 0x;
-

[PATCH] drm: gma500: fix logic error

2017-09-05 Thread Arnd Bergmann

gcc-8 points out a condition that almost certainly doesn't
do what the author had in mind:

drivers/gpu/drm/gma500/mdfld_intel_display.c: In function 
'mdfldWaitForPipeEnable':
drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: error: bitwise comparison 
always evaluates to false [-Werror=tautological-compare]

This changes it to a simple bit mask operation to check
whether the bit is set.

Fixes: 026abc333205 ("gma500: initial medfield merge")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c 
b/drivers/gpu/drm/gma500/mdfld_intel_display.c
index 531e4450c000..5c066448be5b 100644
--- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
+++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
@@ -99,7 +99,7 @@ void mdfldWaitForPipeEnable(struct drm_device *dev, int pipe)
/* Wait for for the pipe enable to take effect. */
for (count = 0; count < COUNT_MAX; count++) {
temp = REG_READ(map->conf);
-   if ((temp & PIPEACONF_PIPE_STATE) == 1)
+   if (temp & PIPEACONF_PIPE_STATE)
break;
}
 }
-- 
2.9.0

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

[PATCHv7 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

2017-09-05 Thread Hean-Loong, Ong

From: Ong Hean Loong 

Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt

Signed-off-by: Ong Hean Loong 
---
V7:
*Fix Comments. Fix indentation in Makefile

V6:
*Fix Comments. Commit comments need to be discriptive

V5:
*Fix Comments. Remove dem_kfree and bits per symbol

V4:
*No fixes.

V3:
*Changes to fixing drm_simple_pipe
*Used drm_fb_cma_get_gem_addr

V2:
*Adding drm_simple_display_pipe_init

---
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/ivip/Kconfig  |  14 +++
 drivers/gpu/drm/ivip/Makefile |   9 ++
 drivers/gpu/drm/ivip/intel_vip_conn.c |  96 +
 drivers/gpu/drm/ivip/intel_vip_core.c | 162 
 drivers/gpu/drm/ivip/intel_vip_drv.h  |  52 +
 drivers/gpu/drm/ivip/intel_vip_of.c   | 194 ++
 8 files changed, 530 insertions(+)
 create mode 100644 drivers/gpu/drm/ivip/Kconfig
 create mode 100644 drivers/gpu/drm/ivip/Makefile
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a8..38a184d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
 
 source "drivers/gpu/drm/i915/Kconfig"
 
+source "drivers/gpu/drm/ivip/Kconfig"
+
 config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..4162a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..bf2d995
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only 
single
+ frame buffer is supported. Note that ACPI and X_86 
architecture
+ is not supported for Arria10. If M is selected the module 
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver.  This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+   intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c 
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..c88df23
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,96 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+

[PATCHv7 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite

2017-09-05 Thread Hean-Loong, Ong

From: Ong Hean Loong 

Intel FPGA Video and Image Processing Suite Frame Buffer II
driver config for Arria 10 devkit and its variants

Signed-off-by: Ong, Hean Loong 
---
 arch/arm/configs/socfpga_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/socfpga_defconfig 
b/arch/arm/configs/socfpga_defconfig
index 2620ce7..255f553 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -111,6 +111,12 @@ CONFIG_MFD_ALTERA_A10SR=y
 CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_DRM=m
+CONFIG_DRM_IVIP=m
+CONFIG_DRM_IVIP_OF=m
+CONFIG_FB=y
+CONFIG_FB_SIMPLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=m
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
-- 
2.7.4

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

[PATCHv7] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite

2017-09-05 Thread Hean-Loong, Ong

From: Ong Hean Loong 

Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height and memory port width.
The device tree binding only supports the Intel Arria10
devkit and its variants. Vendor name retained as altr.

Signed-off-by: Ong, Hean Loong 
---

V7:
*Fix OF graph for better description
*Add description for encoder

V6:
*Description have not describe DT device in general

V5:
*remove bindings for bits per symbol as it has only one value which is 8

V4:
*fix properties that does not describe the values

V3:
*OF graph not in accordance to graph.txt

V2:
*Remove Linux driver description

V1:
*Missing vendor prefix

---
---
 .../devicetree/bindings/display/altr,vip-fb2.txt   | 74 ++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt

diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt 
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..bf0055d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,74 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+   registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+   on the frame reader
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+   Port 0  Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Example:
+
+
+   +--+
+   |FPGA  |++
+   +-+ +--+   ||  DP|
++-+|  VIP| | DP   |   +>  Connector |
+| ||  Frame  | | Controller   |   |||
+| D   +>  Buffer | +--+   |++
+| D   || | +--+   |
+| R   || | | DP   |   |
+| |+-+ | Encoder  |   |
+| ||   +--+   |
++-++--+
+
+
+framebuffer@10280 {
+compatible = "altr,vip-frame-buffer-2.0";
+reg = <0x0001 0x0280 0x0040>;
+altr,max-width = <1280>;
+altr,max-height = <720>;
+altr,mem-port-width = <128>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+reg = <1>;
+fb_output: endpoint {
+remote-endpoint = <_encoder_input>;
+};
+};
+};
+};
+
-- 
2.7.4

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

[PATCHv7 0/3] Intel FPGA Video and Image Processing Suite

2017-09-05 Thread Hean-Loong, Ong

From: Ong Hean Loong 

The FPGA FrameBuffer Soft IP could be seen  as the GPU and
the DRM driver patch here is allocating memory for
information to be streamed from the ARM/Linux to the display port.
Basically the driver just wraps the information such as the pixels to
be drawn by the FPGA FrameBuffer 2.

The piece of hardware in discussion is the SoC FPGA where Linux runs
on the ARM chip and the FGPA is driven by its NIOS soft core with its
own proprietary firmware.

For example the application from the ARM Linux would have to write
information on the /dev/fb0 with the information stored in the SDRAM
to be fetched by the FPGA framebuffer IP and displayed on the Display
Port Monitor.

Ong Hean Loong (3):
  ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
  ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
  ARM:drm ivip Intel FPGA Video and Image Processing Suite

 .../devicetree/bindings/display/altr,vip-fb2.txt   |  84 +
 arch/arm/configs/socfpga_defconfig |   6 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/ivip/Kconfig   |  14 ++
 drivers/gpu/drm/ivip/Makefile  |   9 +
 drivers/gpu/drm/ivip/intel_vip_conn.c  |  96 ++
 drivers/gpu/drm/ivip/intel_vip_core.c  | 162 +
 drivers/gpu/drm/ivip/intel_vip_drv.h   |  52 ++
 drivers/gpu/drm/ivip/intel_vip_of.c| 194 +
 10 files changed, 587 insertions(+), 33 deletions(-)
 create mode 100644 drivers/gpu/drm/ivip/Kconfig
 create mode 100644 drivers/gpu/drm/ivip/Makefile
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c

-- 
2.7.4

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

Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-05 Thread Hoegeun Kwon


On 09/04/2017 04:36 PM, Daniel Vetter wrote:

On Fri, Sep 01, 2017 at 04:36:25PM +0300, Ville Syrjälä wrote:

On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:

If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon 
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.

A bit more strict, it's up to drivers when exactly the vblank interrupt
fires. Some fire at vblank start, some at the end, some somewhen around
that. The only rule is that the vblank must not fire before the point of
no return for another page_flip call, i.e. after the vblank event goes
out, the next page_flip (or atomic ioctl) must go to the next vblank.

So yeah both positive and negative deltas make perfect sense.
-Daniel


Thanks Ville and Daniel,

Your response has been really helpful.
Thanks so much.

Best regards,
Hoegeun


Best regards,
Hoegeun

  drivers/gpu/drm/drm_vblank.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
  
  	DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",

--
1.9.1

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

--
Ville Syrjälä
Intel OTC
___
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: [RFC 1/7] drm/omap: Use devm_kzalloc() to allocate omap_drm_private

2017-09-05 Thread Peter Ujfalusi

Hi Laurent,

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 2017-09-04 17:19, Laurent Pinchart wrote:
>> Ah, OK, so the current way is buggy as well.
>>
>> How do you plan to fix that?
>> I think this should work:
>>
>> struct omap_drm_private {
>>  /* First member in the private struct! */
>> +struct drm_device ddev;
>> ...
>> };
>>
>> Use drm_dev_init(>ddev, ...); to initialize the drm_device instead
>> of drm_dev_alloc()
>>
>> then priv->ddev.dev_private = priv;
>>
>> in this case the drm_dev_unref() would free up our omap_drm_private, right?
> 
> That's the idea, yes. I got a local patch for that in my tree.

Hrm, so what is the difference between what I do in this patch and the
described fix?
To be precise what is the difference between:

struct drm_device *ddev = platform_get_drvdata(pdev);
struct omap_drm_private *priv = ddev->dev_private;
...
drm_dev_unref(ddev);
...
devm would free priv

compared to

struct omap_drm_private {
/* First member in the private struct! */
struct drm_device ddev;

};

struct drm_device *ddev = platform_get_drvdata(pdev);
struct omap_drm_private *priv = ddev->dev_private;
...
/* Here we would free priv since >ddev == ddev */
drm_dev_unref(ddev);

The drm_dev_unregister() is provided as a protection for the issue you
are describing, the comment suggest that at least:
 * This should be called first in the device teardown code to make sure
 * userspace can't access the device instance any more.

and we do call it. As the first step.

> 
>> I think this is what other DRM drivers are doing, not all, but i915 does
>> this at least.
>>
>> But by the description most of the DRM drivers are doing this wrong, right?
> 
> Correct, most drivers get it wrong. We'll have to fix it, but given that we 
> have race conditions in the core that prevent proper hot-unplug support at 
> the 
> moment, I didn't want to start pushing for fixing drivers. Once we get the 
> core sorted out, it will be time to address the other side of the issue.
> 

- Péter

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

Re: [PATCH] drm/atomic: Move drm_crtc_commit to drm_crtc_state, v4.

2017-09-05 Thread Daniel Vetter

On Mon, Sep 04, 2017 at 05:04:56PM +0200, Maarten Lankhorst wrote:
> Most code only cares about the current commit or previous commit.
> Fortuantely we already have a place to track those. Move it to
> drm_crtc_state where it belongs. :)
> 
> The per-crtc commit_list is kept for places where we have to look
> deeper than the current or previous commit for checking whether to stall
> on unpin. This is used in drm_atomic_helper_setup_commit and
> intel_has_pending_fb_unpin.
> 
> Changes since v1:
> - Update kerneldoc for drm_crtc.commit_list. (danvet)
> Changes since v2:
> - Remove drm_atomic_helper_async_check hunk. (pinchartl)
> Changes since v3:
> - Fix use-after-free in drm_atomic_helper_commit_cleanup_done().
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Vetter 

Might be good to drop this, or at least annoate that the r-b is for v3,
just for next time around. But I looked at the patch again, r-b: me still
holds I think. But then I missed the bug in v4 ...
-Daniel


> ---
>  drivers/gpu/drm/drm_atomic.c|  7 
>  drivers/gpu/drm/drm_atomic_helper.c | 82 
> -
>  include/drm/drm_atomic.h|  1 -
>  include/drm/drm_crtc.h  | 23 +--
>  4 files changed, 54 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2fd383d7253a..2cce48f203e0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -163,13 +163,6 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   crtc->funcs->atomic_destroy_state(crtc,
> state->crtcs[i].state);
>  
> - if (state->crtcs[i].commit) {
> - kfree(state->crtcs[i].commit->event);
> - state->crtcs[i].commit->event = NULL;
> - drm_crtc_commit_put(state->crtcs[i].commit);
> - }
> -
> - state->crtcs[i].commit = NULL;
>   state->crtcs[i].ptr = NULL;
>   state->crtcs[i].state = NULL;
>   }
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4e53aae9a1fb..80c138cbde9a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1262,12 +1262,12 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
>  void drm_atomic_helper_wait_for_flip_done(struct drm_device *dev,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_crtc_state *unused;
> + struct drm_crtc_state *new_crtc_state;
>   struct drm_crtc *crtc;
>   int i;
>  
> - for_each_new_crtc_in_state(old_state, crtc, unused, i) {
> - struct drm_crtc_commit *commit = old_state->crtcs[i].commit;
> + for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> + struct drm_crtc_commit *commit = new_crtc_state->commit;
>   int ret;
>  
>   if (!commit)
> @@ -1731,7 +1731,7 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   kref_init(>ref);
>   commit->crtc = crtc;
>  
> - state->crtcs[i].commit = commit;
> + new_crtc_state->commit = commit;
>  
>   ret = stall_checks(crtc, nonblock);
>   if (ret)
> @@ -1769,22 +1769,6 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
>  
> -
> -static struct drm_crtc_commit *preceeding_commit(struct drm_crtc *crtc)
> -{
> - struct drm_crtc_commit *commit;
> - int i = 0;
> -
> - list_for_each_entry(commit, >commit_list, commit_entry) {
> - /* skip the first entry, that's the current commit */
> - if (i == 1)
> - return commit;
> - i++;
> - }
> -
> - return NULL;
> -}
> -
>  /**
>   * drm_atomic_helper_wait_for_dependencies - wait for required preceeding 
> commits
>   * @old_state: atomic state object with old state structures
> @@ -1800,17 +1784,13 @@ static struct drm_crtc_commit 
> *preceeding_commit(struct drm_crtc *crtc)
>  void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state 
> *old_state)
>  {
>   struct drm_crtc *crtc;
> - struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc_state *old_crtc_state;
>   struct drm_crtc_commit *commit;
>   int i;
>   long ret;
>  
> - for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> - spin_lock(>commit_lock);
> - commit = preceeding_commit(crtc);
> - if (commit)
> - drm_crtc_commit_get(commit);
> - spin_unlock(>commit_lock);
> + for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> + commit = old_crtc_state->commit;
>

Re: [PATCH 0/4] RFC: drm: Allow driver-specific ioctls to be registered

2017-09-05 Thread Daniel Vetter

On Mon, Sep 04, 2017 at 07:06:54PM +0300, marius vlad wrote:
> There isn't any dark plot behind it.
> 
> For instance, in our use case, a DPU (Display Process Unit) which has a
> blit feature (using DRM_RENDER_ALLOW) can be implemented cleanly
> in a separate driver and not being dependent on the DRM core driver. If the
> blit
> feature is present/enabled, we can dynamically register the ioctls at
> run-time.
> 
> There are other means to mitigate this, but we thought this would
> beneficial
> to other drivers as well.
> 
> Other SoC drivers like Exynos (G2D) provide this feature by inventing it's
> own sub-driver
> system/layer and have all the sub-drivers built-in.

With all the desktop drivers we simply have a feature flag that describes
which engines are there, and use that to filter out invalid operations.

On arm-soc with it's love for a metric ton of DT tons for everything you
should be able to do the same, it's just a bit more work to get all the of
nodes you need.

If you want a separate driver, imo register a full separate drm_device
instance with everything. But imo the arm-soc design love for heavily
split up drivers really doesn't make much sense, at least for IP all
designed by the same company. Imo look at msm or etnaviv for what I think
are reasonable drm drivers for arm-soc platforms, don't look at exynos.
-Daniel

> 
> 
> On Mon, Sep 4, 2017 at 6:25 PM, Daniel Vetter  wrote:
> 
> > On Mon, Sep 04, 2017 at 06:16:41PM +0300, Marius Vlad wrote:
> > > From: Marius Vlad 
> > >
> > > Currently driver-specific ioctls have to be declared static and are
> > confined to
> > > DRM core driver. This patch series provides the means to remove those
> > constrains
> > > and allow to register driver-specific ioctls dynamically by keeping a
> > list of
> > > registered ioctls in struct drm_driver, then each component of the
> > driver can
> > > then register its own specific ioctls using this interface.
> > >
> > > The driver must assign ioctl_register/ioctl_deregister in
> > > its drm_driver structure in order to make use of it.
> > >
> > > While SoC drivers benefit the most from this approach (by not polluting
> > DRM core
> > > driver and allowing sub drivers to implement and register driver-specific
> > > ioctls dynamically), further patches shows how easy is to convert
> > drm/i915 to
> > > this approach by registering GEM and perf ioctls separately.
> >
> > What exactly is the problem you're trying to solve?
> >
> > This awefully smells like some neat way to make loading driver modules for
> > blob userspace easy ... And I can't think of any other thing you could use
> > this for.
> >
> > And even for the blob userspace use case: Create a separate drm driver
> > instance, share buffers and fences with dma_buf and dma_fence, and you're
> > all good. I really have no idea what this is good for, but maybe I'm
> > missing something?
> > -Daniel
> >
> > >
> > > Marius Vlad (4):
> > >   drm/gpu: Support registering driver-specific ioctls dynamically
> > >   drm/i915: Convert i915 to use ioctl_register/ioctl_deregister.
> > >   drm/i915: Register perf_ ioctls directly in i915_perf file.
> > >   drm/i915: Register GEM ioctls directly in i915_gem file.
> > >
> > >  drivers/gpu/drm/drm_drv.c|   1 +
> > >  drivers/gpu/drm/drm_ioctl.c  |  99 ++
> > --
> > >  drivers/gpu/drm/i915/i915_drv.c  | 107 +++---
> > -
> > >  drivers/gpu/drm/i915/i915_gem.c  |  52 +++
> > >  drivers/gpu/drm/i915/i915_perf.c |  21 
> > >  include/drm/drm_drv.h|  34 +
> > >  include/drm/drm_ioctl.h  |   6 +++
> > >  7 files changed, 249 insertions(+), 71 deletions(-)
> > >
> > > --
> > > 2.9.3
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
> 
> 
> 
> -- 
> Marius Vlad

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

64 matches

Mail list logo