nouveau-next 4.18

[Ben Skeggs]

Hey Dave,

The main thing here is the addition of support for Volta GV100 GPUs,
everything else basically restructuring display / graphics init code
to make it possible to fit Volta support in more nicely.

There's a bunch of improvements/fixes scattered in there for earlier
GPUs too, particularly graphics engine init on all GPUs from Fermi
onwards.

Ben.

The following changes since commit 1fafef9dfe127bdd4600eeaca302f0c1cb4ee5d0:

  Merge drm-fixes-for-v4.17-rc6-urgent into drm-next (2018-05-18 14:08:53 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-4.18

for you to fetch changes up to b520407382791c9e002ff78564a63b21744b9c7d:

  drm/nouveau/gr/gf100-: insert some WFIs during gr init (2018-05-18
15:01:47 +1000)


Arnd Bergmann (1):
  drm/nouveau: nouveau: use larger buffer in nvif_vmm_map

Arushi Singhal (1):
  drm/nouveau/clk: Use list_for_each_entry_from_reverse

Ben Skeggs (159):
  drm/nouveau/core: define FAULT subdev
  drm/nouveau/mc/gp100-: route fault buffer interrupts to FAULT
  drm/nouveau/fault: add infrastructure to support fault buffers
  drm/nouveau/fault/gp100: implement replayable fault buffer initialisation
  drm/nouveau/fb/gf100-: bump size of mmu debug buffers to match
big page size
  drm/nouveau/fb/gm200-: fix overwriting of big page setting
  drm/nouveau/disp/nv50-: delay subunit construction until oneinit
  drm/nouveau/disp/nv50-: fetch mask of available heads during oneinit
  drm/nouveau/disp/nv50-: fetch mask of available dacs during oneinit
  drm/nouveau/disp/nv50-: fetch mask of available sors during oneinit
  drm/nouveau/disp/nv50-: fetch mask of available piors during oneinit
  drm/nouveau/disp/nv50-: initialise from the engine, rather than
the user object
  drm/nouveau/disp/nv50-: replace user object with engine pointer
in channels
  drm/nouveau/disp/nv50-: simplify definition of overlay channels
  drm/nouveau/disp/nv50-: simplify definition of overlay immediate channels
  drm/nouveau/disp/nv50-: simplify definition of base channels
  drm/nouveau/disp/nv50-: simplify definition of cursor channels
  drm/nouveau/disp/nv50-: simplify definiton of core channels
  drm/nouveau/disp/nv50-: merge handling of pio and dma channels
  drm/nouveau/disp/nv50-: add channel interfaces to determine the user area
  drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts
  drm/nouveau/disp/nv50-: pass nvkm_memory objects for channel push buffers
  drm/nouveau/device: implement a generic method to query
device-specific properties
  drm/nouveau/device: support querying available engines of a specific type
  drm/nouveau/fifo: support channel count query
  drm/nouveau/fifo/gk104-: accept engine contexts for CE3 and up
  drm/nouveau/fifo/gk104-: allow fault recovery code to be called
by other subdevs
  drm/nouveau/fifo/gk104-: support querying engines available on
each runlist
  drm/nouveau/fifo/gk104-: require explicit runlist selection for
channel allocation
  drm/nouveau/fifo/gk104-: simplify definition of channel classes
  drm/nouveau/fifo/gk104-: add interfaces to support different
runlist layouts
  drm/nouveau/fifo/gk104-: poll for runlist update completion
  drm/nouveau/fifo/gk110-: support writing channel group runlist entries
  drm/nouveau/fifo/gk208-: write pbdma timeout regs during initialisation
  drm/nouveau/fifo/gm107-: write instance address in channel runlist entry
  drm/nouveau/fifo/gp100-: force individual channels into a channel group
  drm/nouveau/gr/gf100-: virtualise init_gpc_mmu + apply fixes from traces
  drm/nouveau/gr/gf100-: support firmware-provided sw_nonctx everywhere
  drm/nouveau/gr/gf100-: virtualise r405a14
  drm/nouveau/gr/gf100-: support clkgate_pack everywhere
  drm/nouveau/gr/gf100-: virtualise init_bios
  drm/nouveau/gr/gf100-: virtualise init_vsc_stream_master
  drm/nouveau/gr/gf100-: virtualise init_zcull
  drm/nouveau/gr/gf100-: virtualise init_num_active_ltcs
  drm/nouveau/gr/gf100-: virtualise init_rop_active_fbps
  drm/nouveau/gr/gf100-: implement another chunk of bios-provided init
  drm/nouveau/gr/gf100-: virtualise init_swdx_pes_mask
  drm/nouveau/gr/gf100: write 0x400124 during init
  drm/nouveau/gr/gf100-: virtualise init_fecs_exceptions + apply
fixes from traces
  drm/nouveau/gr/gf100-: virtualise init_ds_hww_esr_2
  drm/nouveau/gr/gf100-: virtualise init_40601c
  drm/nouveau/gr/gf100-: virtualise init_sked_hww_esr
  drm/nouveau/gr/gf100-: virtualise init_419cc0 + apply fixes from traces
  drm/nouveau/gr/gf100-: virtualise init_419eb4 + apply fixes from traces
  drm/nouveau/gr/gf100-: virtualise init_419c9c + apply fixes from traces
  drm/nouveau/gr/gf100-: virtualise init_ppc_exceptions
  

[git pull] drm fixes for v4.17-rc6

[Dave Airlie]

Hi Linus,

Pretty quiet week again, one vmwgfx regression fix, one core buffer
overflow fix,one vc4 leak fix and three i915 fixes.

Dave.

The following changes since commit 76ef6b28ea4f81c3d511866a9b31392caa833126:

  drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc6

for you to fetch changes up to 1827cad96d624ec127853a71cb931c74024e57d6:

  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-05-18
12:01:49 +1000)


i915, vc4, vmwgfx and core fixes


Chris Wilson (1):
  drm/i915/execlists: Use rmb() to order CSB reads

Dan Carpenter (1):
  drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

Dave Airlie (3):
  Merge tag 'drm-misc-fixes-2018-05-16' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Deepak Rawat (1):
  drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful

Eric Anholt (1):
  drm/vc4: Fix leak of the file_priv that stored the perfmon.

Haneen Mohammed (1):
  drm: Match sysfs name in link removal to link creation

Matthew Auld (1):
  drm/i915/userptr: reject zero user_size

Michel Thierry (1):
  drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

 drivers/gpu/drm/drm_drv.c   | 2 +-
 drivers/gpu/drm/drm_dumb_buffers.c  | 7 ---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 4 
 drivers/gpu/drm/i915/intel_lrc.c| 1 +
 drivers/gpu/drm/vc4/vc4_drv.c   | 1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 2 ++
 8 files changed, 19 insertions(+), 4 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Fix -WMissing-braces compile warning on android

[Jenny Cao]

use "{}" instead of "{0}" in empty struct defination to avoid missing-braces 
warning:
suggest braces around initialization of subobject [-Wmissing-braces]

Test: compilation on android with this warning free

Signed-off-by: Jenny Cao 
---
 amdgpu/amdgpu_cs.c | 4 ++--
 libsync.h  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 3c9be6c2e835..40e12a61d611 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -705,7 +705,7 @@ int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
 struct drm_amdgpu_cs_chunk *chunks,
 uint64_t *seq_no)
 {
-   union drm_amdgpu_cs cs = {0};
+   union drm_amdgpu_cs cs = {};
uint64_t *chunk_array;
int i, r;
if (num_chunks == 0)
@@ -750,7 +750,7 @@ int amdgpu_cs_fence_to_handle(amdgpu_device_handle dev,
  uint32_t what,
  uint32_t *out_handle)
 {
-   union drm_amdgpu_fence_to_handle fth = {0};
+   union drm_amdgpu_fence_to_handle fth = {};
int r;
 
fth.in.fence.ctx_id = fence->context->id;
diff --git a/libsync.h b/libsync.h
index f1a2f96d36bc..b4d3251c704d 100644
--- a/libsync.h
+++ b/libsync.h
@@ -85,7 +85,7 @@ static inline int sync_wait(int fd, int timeout)
 
 static inline int sync_merge(const char *name, int fd1, int fd2)
 {
-   struct sync_merge_data data = {0};
+   struct sync_merge_data data = {};
int ret;
 
data.fd2 = fd2;
-- 
1.9.1

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

[Bug 101976] glmark2 random blank or background only screen freeze over amdgpu rx550 AMD POLARIS12 due to dpm

[bugzilla-daemon]

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

Pablo Estigarribia  changed:

   What|Removed |Added

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

--- Comment #14 from Pablo Estigarribia  ---
Today reinstalled fedora 28 and did an upgrade.

Got 3 times the 'blank' screen just working on gnome session, same behaviour as
before. 

So looks like this bug is still open.

-- 
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 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

--- Comment #14 from Dieter Nützel  ---
(In reply to Jan Vesely from comment #13)
> Initial support for cl_khr_fp16 builtins has been added to libclc in r332677.
> It should be enough to run clpeak.
> clpeak still takes few mins to compile the kernels (~7mins on my carrizo
> laptop)

GREAT work Jan!

After 3 min and ~12 sec float start crunching on my X3470 Xeon
(only one core would be used for kernel compile => 3.6 GHz turbo mode)

My desktop was frozen during float 'Global memory bandwidth (GBPS)' compute
and partly frozen during 'Double-precision compute (GFLOPS)'.

Whole benchmark finished after 6 min and 17 secs.

/home/dieter> time clpeak

Platform: Clover
  Device: Radeon RX 580 Series (POLARIS10, DRM 3.23.0,
4.16.9-1.g4f45b1e-default, LLVM 7.0.0)
Driver version  : 18.2.0-devel (Linux x64)
Compute units   : 36
Clock frequency : 1411 MHz

Global memory bandwidth (GBPS)
  float   : 2.64
  float2  : 2.64
  float4  : 2.64
  float8  : 2.54
  float16 : 1.45

Single-precision compute (GFLOPS)
  float   : 6341.87
  float2  : 6131.34
  float4  : 6105.61
  float8  : 5933.91
  float16 : 5939.44

half-precision compute (GFLOPS)
  half   : 6307.47
  half2  : 6193.25
  half4  : 6114.34
  half8  : 5729.57
  half16 : 6047.90

Double-precision compute (GFLOPS)
  double   : 404.52
  double2  : 404.41
  double4  : 404.06
  double8  : 403.08
  double16 : 401.53

Integer compute (GIOPS)
  int   : 1222.75
  int2  : 1213.90
  int4  : 1210.72
  int8  : 1208.57
  int16 : 1213.99

Transfer bandwidth (GBPS)
  enqueueWriteBuffer : 8.78
  enqueueReadBuffer  : 4.86
  enqueueMapBuffer(for read) : 4871.79
memcpy from mapped ptr   : 4.94
  enqueueUnmap(after write)  : 3528.56
memcpy to mapped ptr : 4.94

Kernel launch latency : 293.57 us

206.285u 3.765s 6:17.14 55.6%   0+0k 0+0io 0pf+0w


For reference AMD 17.40
/home/dieter> time clpeak

Platform: AMD Accelerated Parallel Processing
  Device: Ellesmere
Driver version  : 2482.3 (Linux x64)
Compute units   : 36
Clock frequency : 1411 MHz

Global memory bandwidth (GBPS)
  float   : 202.59
  float2  : 209.30
  float4  : 209.63
  float8  : 162.15
  float16 : 138.41

Single-precision compute (GFLOPS)
  float   : 6342.71
  float2  : 6374.96
  float4  : 6178.29
  float8  : 5973.53
  float16 : 6018.79

half-precision compute (GFLOPS)
  half   : 6306.97
  half2  : 6366.06
  half4  : 6350.41
  half8  : 6154.31
  half16 : 6280.47

Double-precision compute (GFLOPS)
  double   : 404.64
  double2  : 404.38
  double4  : 398.54
  double8  : 403.25
  double16 : 401.53

Integer compute (GIOPS)
  int   : 1206.77
  int2  : 1221.26
  int4  : 1225.83
  int8  : 1225.88
  int16 : 1227.35

Transfer bandwidth (GBPS)
  enqueueWriteBuffer : 9.03
  enqueueReadBuffer  : 5.08
  enqueueMapBuffer(for read) : 149130.81
memcpy from mapped ptr   : 5.09
  enqueueUnmap(after write)  : 75882.81
memcpy to mapped ptr : 5.08

Kernel launch latency : 93.33 us

23.056u 1.592s 1:08.29 36.0%0+0k 0+0io 0pf+0w

-- 
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 v5 4/4] drm/rockchip: support dp training outside dp firmware

[Brian Norris]

On Thu, May 17, 2018 at 6:41 PM, hl  wrote:
> On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote:
>> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
>>> DP firmware uses fixed phy config values to do training, but some
>>> boards need to adjust these values to fit for their unique hardware
>>> design. So get phy config values from dts and use software link training
>>> instead of relying on firmware, if software training fail, keep firmware
>>> training as a fallback if sw training fails.
>>>
>>> Signed-off-by: Chris Zhong 
>>> Signed-off-by: Lin Huang 
>>> ---
>>> Changes in v2:
>>> - update patch following Enric suggest
>>> Changes in v3:
>>> - use variable fw_training instead sw_training_success
>>> - base on DP SPCE, if training fail use lower link rate to retry training
>>> Changes in v4:
>>> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
>>> follow Sean suggest
>>> Changes in v5:
>>> - fix some whitespcae issue
>>>
>>>   drivers/gpu/drm/rockchip/Makefile   |   3 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>>>   drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
>>> 
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>>>   6 files changed, 505 insertions(+), 13 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>>>
...
>>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
>>> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>>> new file mode 100644
>>> index 000..73c3290
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>>> @@ -0,0 +1,420 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
>>> + * Author: Chris Zhong 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "cdn-dp-core.h"
>>> +#include "cdn-dp-reg.h"
>>> +
>>> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
>>> +{
>>> +   struct cdn_dp_port *port = dp->port[dp->active_port];
>>> +   struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
>>
>> You ignored Brian's comment on the previous patch:
>>This is still antithetical to the PHY framework; you're assuming that
>>this is a particular type of PHY here.
>>
>> FWIW, the mediatek drm driver also assumes a certain PHY type. A quick grep 
>> of
>> drivers/ shows that the only other non-phy/ driver using this function
>> (pinctrl-tegra-xusb.c) also casts it.
>>
>> Sean
>
> Thanks Sean, except phy framework have new API to handle it, i have not
> idea how to do it in a better way.

Well, if Mediatek can do it for their MIPI and HDMI, then maybe we just do it...

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

Re: [PATCH libdrm 1/1] amdgpu: Take lock before removing devices from fd_tab hash table.

[Jan Vesely]

On Thu, 2018-05-10 at 19:33 -0400, Jan Vesely wrote:
> Close the file descriptors under lock as well.
> 
> Signed-off-by: Jan Vesely 
> ---
>  amdgpu/amdgpu_device.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
> index 983b19ab..f71fc050 100644
> --- a/amdgpu/amdgpu_device.c
> +++ b/amdgpu/amdgpu_device.c
> @@ -126,6 +126,13 @@ static int amdgpu_get_auth(int fd, int *auth)
>  
>  static void amdgpu_device_free_internal(amdgpu_device_handle dev)
>  {
> + pthread_mutex_lock(_mutex);
> + close(dev->fd);
> + if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
> + close(dev->flink_fd);
> + util_hash_table_remove(fd_tab, UINT_TO_PTR(dev->fd));
> + pthread_mutex_unlock(_mutex);
> +
>   amdgpu_vamgr_deinit(>vamgr_32);
>   amdgpu_vamgr_deinit(>vamgr);
>   amdgpu_vamgr_deinit(>vamgr_high_32);
> @@ -133,10 +140,6 @@ static void 
> amdgpu_device_free_internal(amdgpu_device_handle dev)
>   util_hash_table_destroy(dev->bo_flink_names);
>   util_hash_table_destroy(dev->bo_handles);
>   pthread_mutex_destroy(>bo_table_mutex);
> - util_hash_table_remove(fd_tab, UINT_TO_PTR(dev->fd));
> - close(dev->fd);
> - if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
> - close(dev->flink_fd);
>   free(dev->marketing_name);
>   free(dev);
>  }
ping.

Jan

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

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

--- Comment #13 from Jan Vesely  ---
Initial support for cl_khr_fp16 builtins has been added to libclc in r332677.
It should be enough to run clpeak.
clpeak still takes few mins to compile the kernels (~7mins on my carrizo
laptop)

-- 
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 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 96897, which changed state.

Bug 96897 Summary: clpeak OpenCL benchmark hangs during compilation on Clover 
RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=96897

   What|Removed |Added

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

-- 
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/4] drm/dp: Define payload size for DP SDP PPS packet

[Manasi Navare]

DP 1.4 spec defines DP secondary data packet for DSC
picture parameter set. This patch defines its payload size
according to the DP 1.4 specification.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentland 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c015649..d13e512 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -992,6 +992,7 @@ struct dp_sdp_header {
 
 #define EDP_SDP_HEADER_REVISION_MASK   0x1F
 #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
+#define DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 0x7F
 
 struct edp_vsc_psr {
struct dp_sdp_header sdp_header;
-- 
2.7.4

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

[PATCH v3 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

[Manasi Navare]

From: Gaurav K Singh 

This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder

v3:
Remove the duplicate define (Harry) (From Manasi)

v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific fields (Manasi)
* Move this struct definition to DRM (Manasi)
* Define DSC 1.2 parameters (Manasi)
* Use DSC_NUM_BUF_RANGES (Manasi)
* Call it drm_dsc_config (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
Signed-off-by: Gaurav K Singh 
Reviewed-by: Harry Wentland 
---
 include/drm/drm_dsc.h | 108 ++
 1 file changed, 108 insertions(+)

diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 73bd0f1..7f6209e 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -31,6 +31,114 @@
 /* VESA Display Stream Compression DSC 1.2 constants */
 #define DSC_NUM_BUF_RANGES 15
 
+/* Configuration for a single Rate Control model range */
+struct dsc_rc_range_parameters {
+   /* Min Quantization Parameters allowed for this range */
+   u8 range_min_qp;
+   /* Max Quantization Parameters allowed for this range */
+   u8 range_max_qp;
+   /* Bits/group offset to apply to target for this group */
+   u8 range_bpg_offset;
+};
+
+struct drm_dsc_config {
+   /* Bits / component for previous reconstructed line buffer */
+   u8 line_buf_depth;
+   /* Bits per component to code (must be 8, 10, or 12) */
+   u8 bits_per_component;
+   /*
+* Flag indicating to do RGB - YCoCg conversion
+* and back (should be 1 for RGB input)
+*/
+   bool convert_rgb;
+   u8 slice_count;
+   /* Slice Width */
+   u16 slice_width;
+   /* Slice Height */
+   u16 slice_height;
+   /*
+* 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
+* outside of DSC encode/decode algorithm)
+*/
+   bool enable422;
+   /* Picture Width */
+   u16 pic_width;
+   /* Picture Height */
+   u16 pic_height;
+   /* Offset to bits/group used by RC to determine QP adjustment */
+   u8 rc_tgt_offset_high;
+   /* Offset to bits/group used by RC to determine QP adjustment */
+   u8 rc_tgt_offset_low;
+   /* Bits/pixel target << 4 (ie., 4 fractional bits) */
+   u16 bits_per_pixel;
+   /*
+* Factor to determine if an edge is present based
+* on the bits produced
+*/
+   u8 rc_edge_factor;
+   /* Slow down incrementing once the range reaches this value */
+   u8 rc_quant_incr_limit1;
+   /* Slow down incrementing once the range reaches this value */
+   u8 rc_quant_incr_limit0;
+   /* Number of pixels to delay the initial transmission */
+   u16 initial_xmit_delay;
+   /* Number of pixels to delay the VLD on the decoder,not including SSM */
+   u16  initial_dec_delay;
+   /* Block prediction enable */
+   bool block_pred_enable;
+   /* Bits/group offset to use for first line of the slice */
+   u8 first_line_bpg_offset;
+   /* Value to use for RC model offset at slice start */
+   u16 initial_offset;
+   /* Thresholds defining each of the buffer ranges */
+   u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
+   /* Parameters for each of the RC ranges */
+   struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+   /* Total size of RC model */
+   u16 rc_model_size;
+   /* Minimum QP where flatness information is sent */
+   u8 flatness_min_qp;
+   /* Maximum QP where flatness information is sent */
+   u8 flatness_max_qp;
+   /* Initial value for scale factor */
+   u8 initial_scale_value;
+   /* Decrement scale factor every scale_decrement_interval groups */
+   u16 scale_decrement_interval;
+   /* Increment scale factor every scale_increment_interval groups */
+   u16 scale_increment_interval;
+   /* Non-first line BPG offset to use */
+   u16 nfl_bpg_offset;
+   /* BPG offset used to enforce slice bit */
+   u16 slice_bpg_offset;
+   /* Final RC linear transformation offset value */
+   u16 final_offset;
+   /* Enable on-off VBR (ie., disable stuffing bits) */
+   bool vbr_enable;
+   /* Mux word size (in bits) for SSM mode */
+   u8 mux_word_size;
+   /*
+* The (max) size in bytes of the "chunks" that are
+* used in slice multiplexing
+*/
+   u16 slice_chunk_size;
+   /* Rate Control buffer siz in bits */
+   u16 rc_bits;
+   /* DSC Minor Version */
+   u8 dsc_version_minor;
+   /* DSC Major version */
+ 

[PATCH v3 4/4] drm/dsc: Add helpers for DSC picture parameter set infoframes

[Manasi Navare]

According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload according to the DSC 1.2 specification.

v3:
* Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
(Daniel Vetter)

v2:
* Add EXPORT_SYMBOL for the drm functions (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
Acked-by: Harry Wentland 
---
 Documentation/gpu/drm-kms-helpers.rst |  12 ++
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_dsc.c | 231 ++
 include/drm/drm_dsc.h |  16 +++
 4 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dsc.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index e37557b..13837f7 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -205,6 +205,18 @@ MIPI DSI Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
:export:
 
+Display Stream Compression Helper Functions Reference
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+   :doc: dsc helpers
+
+.. kernel-doc:: include/drm/drm_dsc.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+   :export:
+
 Output Probing Helper Functions Reference
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8873d47..df70373 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o 
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
new file mode 100644
index 000..30e567f
--- /dev/null
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -0,0 +1,231 @@
+/*
+ *Copyright © 2018 Intel Corp
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ *
+ * Author:
+ * Manasi Navare 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsc helpers
+ *
+ * These functions contain some common logic and helpers to deal with VESA
+ * Display Stream Compression standard required for DSC on Display Port/eDP or
+ * MIPI display interfaces.
+ */
+
+/**
+ * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
+ * for DisplayPort as per the DP 1.4 spec.
+ * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
+ */
+void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
+{
+   memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
+
+   pps_sdp->pps_header.HB1 = DP_SDP_PPS;
+   pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
+}
+EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
+
+/**
+ * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * using the DSC configuration parameters in the order expected
+ * by the DSC Display Sink device. For the DSC, the sink device
+ * expects the PPS payload in the big 

[PATCH v3 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

[Manasi Navare]

This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.

v3:
* Add a comment for bits_per_component as per DSC spec (Harry Wentland)
v2:
* Fix the comments for kernel-doc

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
Reviewed-by: Harry Wentland 
---
 include/drm/drm_dsc.h | 442 ++
 1 file changed, 442 insertions(+)
 create mode 100644 include/drm/drm_dsc.h

diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
new file mode 100644
index 000..73bd0f1
--- /dev/null
+++ b/include/drm/drm_dsc.h
@@ -0,0 +1,442 @@
+/*
+ * Copyright (C) 2018 Intel Corp.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Manasi Navare 
+ */
+
+#ifndef DRM_DSC_H_
+#define DRM_DSC_H_
+
+#include 
+
+/* VESA Display Stream Compression DSC 1.2 constants */
+#define DSC_NUM_BUF_RANGES 15
+
+/**
+ * struct picture_parameter_set - Represents 128 bytes of Picture Parameter Set
+ *
+ * The VESA DSC standard defines picture parameter set (PPS) which display
+ * stream compression encoders must communicate to decoders.
+ * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields in
+ * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
+ * The PPS fields that span over more than a byte should be stored in Big 
Endian
+ * format.
+ */
+struct picture_parameter_set {
+   /**
+* @dsc_version_minor:
+* PPS0[3:0] - Contains Minor version of DSC
+*/
+   u8 dsc_version_minor:4;
+   /**
+* @dsc_version_major:
+* PPS0[7:4] - Contains major version of DSC
+*/
+   u8 dsc_version_major:4;
+   /**
+* @pps_identifier:
+* PPS1[7:0] - Application specific identifier that can be
+* used to differentiate between different PPS tables.
+*/
+   u8 pps_identifier;
+   /**
+* @pps2_reserved:
+* PPS2[7:0]- RESERVED Byte
+*/
+   u8 pps2_reserved;
+   /**
+* @linebuf_depth:
+* PPS3[3:0] - Contains linebuffer bit depth used to generate
+* the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
+* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
+* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
+*/
+   u8 linebuf_depth:4;
+   /**
+* @bits_per_component:
+* PPS3[7:4] - Bits per component for the original pixels
+* of the encoded picture.
+* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
+* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
+* allowed only when dsc_minor_version = 0x2)
+*/
+   u8 bits_per_component:4;
+   /**
+* @bpp_high:
+* PPS4[1:0] - These are the most significant 2 bits of
+* compressed BPP bits_per_pixel[9:0] syntax element.
+*/
+   u8 bpp_high:2;
+   /**
+* @vbr_enable:
+* PPS4[2] - 0 = VBR disabled, 1 = VBR enabled
+*/
+   u8 vbr_enable:1;
+   /**
+* @simple_422:
+* PPS4[3] - Indicates if decoder drops samples to
+* reconstruct the 4:2:2 picture.
+*/
+   u8 simple_422:1;
+   /**
+* @convert_rgb:
+* PPS4[4] - Indicates if DSC color space conversion is active
+*/
+   u8 convert_rgb:1;
+   /**
+* @block_pred_enable:
+* PPS4[5] - Indicates if BP is used to code any groups in picture
+  

Re: [PATCH hwc] drm_hwcomposer: Support assigning planes in ValidateDisplay

[Stefan Schake]

Hey Rob,

On Fri, May 18, 2018 at 12:08 AM, Rob Herring  wrote:
> In order to assign planes to layers in ValidateDisplay, testing
> compositing with a DRM atomic modeset test is needed as PresentDisplay
> is too late. This means most of PresentDisplay needs to be run from
> ValidateDisplay, so refactor PresentDisplay and plumb a test flag down
> the stack.
>
> Signed-off-by: Rob Herring 
> ---
> Based on my GL comp removal work. Adding atomic test path turned out to
> be easier than using the Planner directly.
>
>  drmdisplaycompositor.cpp |  4 +-
>  drmdisplaycompositor.h   |  2 +-
>  drmhwctwo.cpp| 79 ++--
>  drmhwctwo.h  |  1 +
>  4 files changed, 73 insertions(+), 13 deletions(-)
>
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index 2f9f6c6772da..ceee6b1a4bd6 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -469,7 +469,7 @@ void DrmDisplayCompositor::ApplyFrame(
>  }
>
>  int DrmDisplayCompositor::ApplyComposition(
> -std::unique_ptr composition) {
> +std::unique_ptr composition, bool test) {

Since ApplyComposition just calls CommitFrame which already has test
support, can we reuse that for a TestComposition function?

>int ret = 0;
>switch (composition->type()) {
>  case DRM_COMPOSITION_TYPE_FRAME:
> @@ -481,6 +481,8 @@ int DrmDisplayCompositor::ApplyComposition(
>ALOGE("Commit test failed for display %d, FIXME", display_);
>return ret;
>  }
> +if (test)
> +  return 0;

Then we could also drop this hunk.

>}
>
>ApplyFrame(std::move(composition), ret);
> diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
> index ed46873c3409..7c5ebb005dc4 100644
> --- a/drmdisplaycompositor.h
> +++ b/drmdisplaycompositor.h
> @@ -43,7 +43,7 @@ class DrmDisplayCompositor {
>int Init(DrmResources *drm, int display);
>
>std::unique_ptr CreateComposition() const;
> -  int ApplyComposition(std::unique_ptr composition);
> +  int ApplyComposition(std::unique_ptr composition, 
> bool test);

And this one.

>int Composite();
>void Dump(std::ostringstream *out) const;
>
> diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
> index deaf14363e8c..19f73e721154 100644
> --- a/drmhwctwo.cpp
> +++ b/drmhwctwo.cpp
> @@ -480,8 +480,7 @@ void DrmHwcTwo::HwcDisplay::AddFenceToRetireFence(int fd) 
> {
>}
>  }
>
> -HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
> -  supported(__func__);
> +HWC2::Error DrmHwcTwo::HwcDisplay::CreateComposition(bool test) {

This is called CreateComposition, but it also tests and even commits.
If this only sets up the DrmDisplayComposition, we could just have the
test and commit in Validate/Present respectively and drop the flag.
Unfortunately it also uses and mutates the layer state, and moving that
into Present/Validate from here looks more difficult.

>std::vector layers_map;
>layers_map.emplace_back();
>DrmCompositionDisplayLayersMap  = layers_map.back();
> @@ -494,7 +493,13 @@ HWC2::Error 
> DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
>uint32_t client_z_order = 0;
>std::map z_map;
>for (std::pair  : layers_) {
> -switch (l.second.validated_type()) {
> +HWC2::Composition comp_type;
> +if (test)
> +  comp_type = l.second.sf_type();
> +else
> +  comp_type = l.second.validated_type();
> +
> +switch (comp_type) {
>case HWC2::Composition::Device:
>  z_map.emplace(std::make_pair(l.second.z_order(), ));
>  break;
> @@ -510,6 +515,10 @@ HWC2::Error 
> DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
>if (use_client_layer)
>  z_map.emplace(std::make_pair(client_z_order, _layer_));
>
> +  if (z_map.empty())
> +return HWC2::Error::BadLayer;
> +
> +

Extra newline.

>// now that they're ordered by z, add them to the composition
>for (std::pair  : z_map) {
>  DrmHwcLayer layer;
> @@ -521,10 +530,6 @@ HWC2::Error 
> DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
>  }
>  map.layers.emplace_back(std::move(layer));
>}
> -  if (map.layers.empty()) {
> -*retire_fence = -1;
> -return HWC2::Error::None;
> -  }
>
>std::unique_ptr composition =
>compositor_.CreateComposition();
> @@ -555,13 +560,29 @@ HWC2::Error 
> DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
>  i = overlay_planes.erase(i);
>}
>
> -  AddFenceToRetireFence(composition->take_out_fence());
> +  if (!test)
> +AddFenceToRetireFence(composition->take_out_fence());
>
> -  ret = compositor_.ApplyComposition(std::move(composition));
> +  ret = compositor_.ApplyComposition(std::move(composition), test);
>if (ret) {
>  ALOGE("Failed to apply the frame composition ret=%d", ret);
>  return HWC2::Error::BadParameter;
>}
> +  return 

[PATCH hwc] drm_hwcomposer: Support assigning planes in ValidateDisplay

[Rob Herring]

In order to assign planes to layers in ValidateDisplay, testing
compositing with a DRM atomic modeset test is needed as PresentDisplay
is too late. This means most of PresentDisplay needs to be run from
ValidateDisplay, so refactor PresentDisplay and plumb a test flag down
the stack.

Signed-off-by: Rob Herring 
---
Based on my GL comp removal work. Adding atomic test path turned out to 
be easier than using the Planner directly.

 drmdisplaycompositor.cpp |  4 +-
 drmdisplaycompositor.h   |  2 +-
 drmhwctwo.cpp| 79 ++--
 drmhwctwo.h  |  1 +
 4 files changed, 73 insertions(+), 13 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index 2f9f6c6772da..ceee6b1a4bd6 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -469,7 +469,7 @@ void DrmDisplayCompositor::ApplyFrame(
 }
 
 int DrmDisplayCompositor::ApplyComposition(
-std::unique_ptr composition) {
+std::unique_ptr composition, bool test) {
   int ret = 0;
   switch (composition->type()) {
 case DRM_COMPOSITION_TYPE_FRAME:
@@ -481,6 +481,8 @@ int DrmDisplayCompositor::ApplyComposition(
   ALOGE("Commit test failed for display %d, FIXME", display_);
   return ret;
 }
+if (test)
+  return 0;
   }
 
   ApplyFrame(std::move(composition), ret);
diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
index ed46873c3409..7c5ebb005dc4 100644
--- a/drmdisplaycompositor.h
+++ b/drmdisplaycompositor.h
@@ -43,7 +43,7 @@ class DrmDisplayCompositor {
   int Init(DrmResources *drm, int display);
 
   std::unique_ptr CreateComposition() const;
-  int ApplyComposition(std::unique_ptr composition);
+  int ApplyComposition(std::unique_ptr composition, 
bool test);
   int Composite();
   void Dump(std::ostringstream *out) const;
 
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index deaf14363e8c..19f73e721154 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -480,8 +480,7 @@ void DrmHwcTwo::HwcDisplay::AddFenceToRetireFence(int fd) {
   }
 }
 
-HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
-  supported(__func__);
+HWC2::Error DrmHwcTwo::HwcDisplay::CreateComposition(bool test) {
   std::vector layers_map;
   layers_map.emplace_back();
   DrmCompositionDisplayLayersMap  = layers_map.back();
@@ -494,7 +493,13 @@ HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t 
*retire_fence) {
   uint32_t client_z_order = 0;
   std::map z_map;
   for (std::pair  : layers_) {
-switch (l.second.validated_type()) {
+HWC2::Composition comp_type;
+if (test)
+  comp_type = l.second.sf_type();
+else
+  comp_type = l.second.validated_type();
+
+switch (comp_type) {
   case HWC2::Composition::Device:
 z_map.emplace(std::make_pair(l.second.z_order(), ));
 break;
@@ -510,6 +515,10 @@ HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t 
*retire_fence) {
   if (use_client_layer)
 z_map.emplace(std::make_pair(client_z_order, _layer_));
 
+  if (z_map.empty())
+return HWC2::Error::BadLayer;
+
+
   // now that they're ordered by z, add them to the composition
   for (std::pair  : z_map) {
 DrmHwcLayer layer;
@@ -521,10 +530,6 @@ HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t 
*retire_fence) {
 }
 map.layers.emplace_back(std::move(layer));
   }
-  if (map.layers.empty()) {
-*retire_fence = -1;
-return HWC2::Error::None;
-  }
 
   std::unique_ptr composition =
   compositor_.CreateComposition();
@@ -555,13 +560,29 @@ HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t 
*retire_fence) {
 i = overlay_planes.erase(i);
   }
 
-  AddFenceToRetireFence(composition->take_out_fence());
+  if (!test)
+AddFenceToRetireFence(composition->take_out_fence());
 
-  ret = compositor_.ApplyComposition(std::move(composition));
+  ret = compositor_.ApplyComposition(std::move(composition), test);
   if (ret) {
 ALOGE("Failed to apply the frame composition ret=%d", ret);
 return HWC2::Error::BadParameter;
   }
+  return HWC2::Error::None;
+}
+
+HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t *retire_fence) {
+  supported(__func__);
+  HWC2::Error ret;
+
+  ret = CreateComposition(false);
+  if (ret == HWC2::Error::BadLayer) {
+  // Can we really have no client or device layers?
+  *retire_fence = -1;
+  return HWC2::Error::None;
+  }
+  if (ret != HWC2::Error::None)
+return ret;
 
   // The retire fence returned here is for the last frame, so return it and
   // promote the next retire fence
@@ -586,7 +607,7 @@ HWC2::Error 
DrmHwcTwo::HwcDisplay::SetActiveConfig(hwc2_config_t config) {
   compositor_.CreateComposition();
   composition->Init(drm_, crtc_, importer_.get(), planner_.get(), frame_no_);
   int ret = composition->SetDisplayMode(*mode);
-  ret = compositor_.ApplyComposition(std::move(composition));
+  ret = 

Re: [RFC] remoting KMS

[Daniel Vetter]

On Thu, May 17, 2018 at 11:18 PM, Thomas Hellstrom  wrote:
>
> On 05/17/2018 09:20 PM, Daniel Vetter wrote:
>>
>> On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom 
>> wrote:
>>>
>>> Hi!
>>>
>>> I'm currently working on a remoting KMS backend, and now I thought it
>>> would
>>> be a good time to get some feedback on a very rough design:
>>>
>>> The idea is that we want to be get enough information on the backend side
>>> of
>>> KMS to be able to remote the display system over VNC or something
>>> similar.
>>> Initially I'd plug in an open-source VNC server as the "reference"
>>> user-space.
>>>
>>> The solution should be general enough to plug into any driver, including
>>> VKMS, either mirroring an existing crtc/connector or adding a virtual
>>> one.
>>> The driver would typically only have to implement an efficient readback
>>> command, optionally with a diff-map or damage rect that tracks changed
>>> content for the VNC server to be able to do its work efficiently.
>>>
>>> This would all be forwarded to a user-space interface and protocol with a
>>> slightly more elaborate user-space event-mechanism than the one we have
>>> in
>>> drm now. In particular we want to be able to read partial events, and
>>> resume
>>> event reading after a partial event. We would also want to be able to
>>> send
>>> commands either through an ioctl() or using write(). Current test code is
>>> using write().
>>>
>>> Since the VNC server in our application typically will be system-wide, we
>>> need to resurrect a control-node functionality. I was trying to use sysfs
>>> attributes for this, but while sysfs supports rudimentary poll
>>> functionality. It's a bit too rudimentary and tracking client lifetime
>>> becomes racy. Perhaps control nodes renamed to "remoting" nodes or
>>> something
>>> similar. It might be that masters want to attach a VNC server to their
>>> current display and in that case we probably would want to expand primary
>>> nodes with this functionality as well.
>>>
>>> Now to the open-source  problem. As mentioned, the reference user-space
>>> will
>>> be a solution based on libvncserver. In fact there will be a small
>>> user-space interface library that libvncserver can interact with, similar
>>> to
>>> libdrm. However, I envision in the long run VMWare would be interested to
>>> use other remoting protocols with closed source protocol encoders, using
>>> the
>>> open source reference library. In theory, this solution would also allow
>>> for
>>> simple (open- or closed source) user-space display drivers, very similar
>>> to
>>> DisplayLink's evdi solution, even if that's not a use-case VMWare is
>>> currently interested in.
>>>
>>> Thoughts and comments appreciated.
>>
>> Just two very quick comments:
>>
>> - For the uapi - can't we just use v4l for the output side? That gives
>> you buffer handoff, syncing (v4l is gaining dma_fence support) and
>> pretty much everything you might want. And we've talked about building
>> kms->v4l pipelines in a bunch of other use-cases already (like feeding
>> into video encoders for widi and stuff like that). Would give you the
>> userspace for free, only thing we really need is to (maybe, not sure
>> you'd even need that) expose what kms output corresponds to what v4l
>> pipeline.
>
>
> Hi!
> Thanks for the comments.
>
> I'll take a look whether this is possible to accomplish with v4l. Hadn't
> thought of that. However, I doubt it will be possible to support all things
> we need to support. Initially we started looking at this in the context of
> readback connectors but buffer management and readbacks are only a subset of
> what we want to do. We also need to pipe a subset of the (atomic) state and
> its updates, the handling of which actually becomes the vast major part of
> the code.
> We also need to feed data back, similar to the vmwgfx update_layout ioctl,
> that sets suggested x and y position, preferred mode, and, on readback,
> obtain damage information. Perhaps it's possible to construct some kind of
> side-channel.

Ok, that's a slightly different use-case than what I thought off,
sounds like you want to keep the special cursor meaning for
virtualization. And that wouldn't go through v4l I think.

>> - You say "The solution should be general enough to plug into any
>> driver" - is the idea that any hw driver would automatically support
>> this?
>
> No, the initial idea is that any hw driver that wants to could use helpers
> and a readback implementation to support this

Is the helper idea just what you have in mind for vmwgfx, or does your
use-case require that you patch this to all kms drivers (kinda like
all kms drivers have fbcon)? +/- a bunch you'll probably not care
about. If you want this I guess you need to explain a bit more what's
the intended use-case, since it seems to be more than just piping any
random compositor than can run on kms into something like a vnc server
for forwarding.

>> Given that 

[radeon-alex:amd-staging-drm-next 114/431] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   100dd4c0f231fce76fa8115ad28d507e311d32bf
commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/431] ASoC: AMD: enable 
ACP3x drivers build
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2a6630b1095609b26a205b7c537594f3cde99c0a
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All error/warnings (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
>> 'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
>> 'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
>> function 'devm_ioremap'; did you mean 'of_ioremap'? 
>> [-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
 of_ioremap
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +28 sound/soc/amd/raven/acp3x.h

1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  25  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  26  static inline u32 
rv_readl(void __iomem *base_addr)
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  27  {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr 
- ACP3x_PHY_BASE_ADDRESS);
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  29  }
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  30  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  31  static inline void 
rv_writel(u32 val, void __iomem *base_addr)
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27  32  {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr - 
ACP3x_PHY_BASE_ADDRESS);

:: The code at line 28 was first introduced by commit
:: 1e29b93483a3e02f1126c5d9b16c4436f6a53c80 ASoC: AMD: add ACP3.0 PCI driver

:: TO: Maruthi Srinivas Bayyavarapu 
:: CC: Alex Deucher 

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


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

Re: [RFC] remoting KMS

[Thomas Hellstrom]

On 05/17/2018 09:20 PM, Daniel Vetter wrote:

On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom  wrote:

Hi!

I'm currently working on a remoting KMS backend, and now I thought it would
be a good time to get some feedback on a very rough design:

The idea is that we want to be get enough information on the backend side of
KMS to be able to remote the display system over VNC or something similar.
Initially I'd plug in an open-source VNC server as the "reference"
user-space.

The solution should be general enough to plug into any driver, including
VKMS, either mirroring an existing crtc/connector or adding a virtual one.
The driver would typically only have to implement an efficient readback
command, optionally with a diff-map or damage rect that tracks changed
content for the VNC server to be able to do its work efficiently.

This would all be forwarded to a user-space interface and protocol with a
slightly more elaborate user-space event-mechanism than the one we have in
drm now. In particular we want to be able to read partial events, and resume
event reading after a partial event. We would also want to be able to send
commands either through an ioctl() or using write(). Current test code is
using write().

Since the VNC server in our application typically will be system-wide, we
need to resurrect a control-node functionality. I was trying to use sysfs
attributes for this, but while sysfs supports rudimentary poll
functionality. It's a bit too rudimentary and tracking client lifetime
becomes racy. Perhaps control nodes renamed to "remoting" nodes or something
similar. It might be that masters want to attach a VNC server to their
current display and in that case we probably would want to expand primary
nodes with this functionality as well.

Now to the open-source  problem. As mentioned, the reference user-space will
be a solution based on libvncserver. In fact there will be a small
user-space interface library that libvncserver can interact with, similar to
libdrm. However, I envision in the long run VMWare would be interested to
use other remoting protocols with closed source protocol encoders, using the
open source reference library. In theory, this solution would also allow for
simple (open- or closed source) user-space display drivers, very similar to
DisplayLink's evdi solution, even if that's not a use-case VMWare is
currently interested in.

Thoughts and comments appreciated.

Just two very quick comments:

- For the uapi - can't we just use v4l for the output side? That gives
you buffer handoff, syncing (v4l is gaining dma_fence support) and
pretty much everything you might want. And we've talked about building
kms->v4l pipelines in a bunch of other use-cases already (like feeding
into video encoders for widi and stuff like that). Would give you the
userspace for free, only thing we really need is to (maybe, not sure
you'd even need that) expose what kms output corresponds to what v4l
pipeline.


Hi!
Thanks for the comments.

I'll take a look whether this is possible to accomplish with v4l. Hadn't 
thought of that. However, I doubt it will be possible to support all 
things we need to support. Initially we started looking at this in the 
context of readback connectors but buffer management and readbacks are 
only a subset of what we want to do. We also need to pipe a subset of 
the (atomic) state and its updates, the handling of which actually 
becomes the vast major part of the code.
We also need to feed data back, similar to the vmwgfx update_layout 
ioctl, that sets suggested x and y position, preferred mode, and, on 
readback, obtain damage information. Perhaps it's possible to construct 
some kind of side-channel.




- You say "The solution should be general enough to plug into any
driver" - is the idea that any hw driver would automatically support
this?
No, the initial idea is that any hw driver that wants to could use 
helpers and a readback implementation to support this



Given that prime-like setups are getting ever more common
(mobile is essentially all prime with display and offloaded rendering)
I think it'd be cleanest if we don't tie that virtual output to other
drivers, but bind things together using buffer sharing/dma-fences and
prime.


We do need a front end, though, I assume you're suggestion is that we 
add support to vkms only. That would work for the main VMware use-case, 
but not for a general use-case where a user would want to share his 
existing screen using VNC.



  Adding v4l output to vkms is actually something we've already
discussed a bit on irc, but with the use-case that you could just
watch what your desktop/window manager is doing under a specific
simulated setup (e.g. pll sharing constraints, or special plane
features, or whatever other specific thing you want to test your
compositor against but isn't supported on all physical hw/drivers).

Cheers, Daniel


Thanks,

Thomas


___
dri-devel 

Re: [DPU PATCH v2 5/6] drm/msm: hook up DPU with upstream DSI

[Sean Paul]

On Thu, Apr 19, 2018 at 04:52:03PM -0700, Jeykumar Sankaran wrote:
> Switch DPU from dsi-staging to upstream dsi driver. To make
> the switch atomic, this change includes:
> - remove dpu connector layers
> - clean up dpu connector dependencies in encoder/crtc
> - compile out writeback and display port drivers
> - compile out dsi-staging driver (separate patch submitted to
>   remove the driver)
> - adapt upstream device hierarchy
> 
> changes in v2:
>   - remove files not applicable upstream (Sean Paul)
>   - remove compiled out non-dsi display init (Sean Paul)
>   - split unrelated changes into separate patch set (Sean Paul)
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/Makefile   |1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  | 1184 
> 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h  |  555 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |9 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  179 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   10 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |8 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |6 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  489 +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|6 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   54 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   11 +
>  drivers/gpu/drm/msm/dpu_dbg.c  |3 -
>  drivers/gpu/drm/msm/msm_drv.c  |   47 +-
>  drivers/gpu/drm/msm/msm_drv.h  |   39 -
>  15 files changed, 158 insertions(+), 2443 deletions(-)
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h
> 

/snip

> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index c8c12d3..af8205f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -23,7 +23,6 @@
>  #include "dpu_hw_intf.h"
>  #include "dpu_hw_wb.h"
>  #include "dpu_encoder.h"
> -#include "dpu_connector.h"
>  
>  #define RESERVED_BY_OTHER(h, r) \
>   ((h)->rsvp && ((h)->rsvp->enc_id != (r)->enc_id))
> @@ -158,6 +157,18 @@ struct dpu_hw_mdp *dpu_rm_get_mdp(struct dpu_rm *rm)
>   return rm->hw_mdp;
>  }
>  
> +enum dpu_rm_topology_name
> +dpu_rm_get_topology_name(struct msm_display_topology topology)
> +{
> + int i;
> +
> + for (i = 0; i < DPU_RM_TOPOLOGY_MAX; i++)
> + if (RM_IS_TOPOLOGY_MATCH(g_top_table[i], topology))
> + return g_top_table[i].top_name;
> +
> + return DPU_RM_TOPOLOGY_NONE;
> +}
> +
>  void dpu_rm_init_hw_iter(
>   struct dpu_rm_hw_iter *iter,
>   uint32_t enc_id,
> @@ -954,20 +965,19 @@ static int _dpu_rm_populate_requirements(
>   struct drm_encoder *enc,
>   struct drm_crtc_state *crtc_state,
>   struct drm_connector_state *conn_state,
> - struct dpu_rm_requirements *reqs)
> + struct dpu_rm_requirements *reqs,
> + struct msm_display_topology req_topology)
>  {
>   const struct drm_display_mode *mode = _state->mode;
>   int i;
>  
>   memset(reqs, 0, sizeof(*reqs));
>  
> - reqs->top_ctrl = dpu_connector_get_property(conn_state,
> - CONNECTOR_PROP_TOPOLOGY_CONTROL);
>   dpu_encoder_get_hw_resources(enc, >hw_res, conn_state);
>  
>   for (i = 0; i < DPU_RM_TOPOLOGY_MAX; i++) {
>   if (RM_IS_TOPOLOGY_MATCH(g_top_table[i],
> - reqs->hw_res.topology)) {
> + req_topology)) {
>   reqs->topology = _top_table[i];
>   break;
>   }
> @@ -978,10 +988,6 @@ static int _dpu_rm_populate_requirements(
>   return -EINVAL;
>   }
>  
> - /* DSC blocks are hardwired for control path 0 and 1 */
> - if (reqs->topology->num_comp_enc)
> - reqs->top_ctrl |= BIT(DPU_RM_TOPCTL_DSPP);
> -
>   /**
>* Set the requirement based on caps if not set from user space
>* This will ensure to select LM tied with DS blocks
> @@ -1110,9 +1116,6 @@ void dpu_rm_release(struct dpu_rm *rm, struct 
> drm_encoder *enc)
>   goto end;
>   }
>  
> - top_ctrl = dpu_connector_get_property(conn->state,
> - CONNECTOR_PROP_TOPOLOGY_CONTROL);
> -
>   if (top_ctrl & BIT(DPU_RM_TOPCTL_RESERVE_LOCK)) {

../drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c: In function ‘dpu_rm_release’:
../drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:1119:15: warning: ‘top_ctrl’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]




>   DPU_DEBUG("rsvp[s%de%d] not releasing locked resources\n",
>   

Re: [Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

[Laurent Pinchart]

Hi Dave,

On Thursday, 17 May 2018 08:05:03 EEST Dave Airlie wrote:
> On 17 May 2018 at 14:42, Dave Airlie  wrote:
> > On 16 May 2018 at 01:37, Laurent Pinchart wrote:
> >> On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote:
> >>> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> >>> head:   c03987223c762e4a61142f0a9be6027bb181cdfa
> >>> commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch
> >>> 'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next config:
> >>> arm64-defconfig (attached as .config)
> >>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> >>> 
> >>> reproduce:
> >>> wget
> >>> 
> >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> >>> -O
> >>> ~/bin/make.cross chmod +x ~/bin/make.cross
> >>> 
> >>> git checkout 9037d4b98b255979c6636045794775f5a89cc623
> >>> # save the attached .config to linux build tree
> >>> make.cross ARCH=arm64
> >>> 
> >>> All errors (new ones prefixed by >>):
> >>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
> >> 
> >> 'rcar_du_vsp_plane_atomic_duplicate_state':
> >>> >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct
> >>> >> rcar_du_vsp_plane_state' has no member named 'alpha'
> >>> >> 
> >>>  copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
> >>>  ^~
> >>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:53: error: 'struct
> >>> rcar_du_vsp_plane_state' has no member named 'alpha' copy->alpha =
> >>> to_rcar_vsp_plane_state(plane->state)->alpha;
> >> 
> >> This error is caused by a conflict between commit 75a07f399cd4 (drm:
> >> rcar-du: Zero-out sg_tables when duplicating plane state) present in my
> >> R-Car DU pull request sent for the DRM tree and commit 301a9b8d5456
> >> ("drm/rcar-du: Convert to the new generic alpha property") present in
> >> drm-misc-next but not merged in the drm tree yet.
> >> 
> >> Dave, how would you like to handle this ? I can rebase my drm/du/next
> >> branch on top of your tree once you merge drm-misc-next and send a new
> >> pull request, but I'd like to avoid missing the v4.18 merge window.
> >> Another option would be to handle the error in the drm-misc-next merge.
> >> If there's an easier option, please let me know how I can help.
> > 
> > Is this broken in my tree now? since I seem to have both of these patches
> > and my local arm build succeeds.
> > 
> > Is there a merge from somewhere else confusing things?
> 
> Turns out my arm64 builds weren't setup properly, I've fixed them up and can
> now see builds failures.
> 
> I've applied both rcar-du fixes to drm-next.

Thank you. I've verified your for-next branch and everything seems fine now.

-- 
Regards,

Laurent Pinchart



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

[radeon-alex:amd-staging-drm-next 114/432] sound/soc//amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   d19e8ade9c3b04edf71a7ec439ba53ea2b8c76a3
commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/432] ASoC: AMD: enable 
ACP3x drivers build
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2a6630b1095609b26a205b7c537594f3cde99c0a
# save the attached .config to linux build tree
make.cross ARCH=sh 

All error/warnings (new ones prefixed by >>):

   sound/soc//amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc//amd/raven/pci-acp3x.c:58:8: error: implicit declaration of 
>> function 'pci_enable_msi'; did you mean 'pci_enable_sriov'? 
>> [-Werror=implicit-function-declaration]
 ret = pci_enable_msi(pci);
   ^~
   pci_enable_sriov
>> sound/soc//amd/raven/pci-acp3x.c:122:2: error: implicit declaration of 
>> function 'pci_disable_msi'; did you mean 'pci_disable_sriov'? 
>> [-Werror=implicit-function-declaration]
 pci_disable_msi(pci);
 ^~~
 pci_disable_sriov
   sound/soc//amd/raven/pci-acp3x.c: At top level:
>> sound/soc//amd/raven/pci-acp3x.c:159:1: warning: data definition has no type 
>> or storage class
module_pci_driver(acp3x_driver);
^
>> sound/soc//amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in 
>> declaration of 'module_pci_driver' [-Werror=implicit-int]
>> sound/soc//amd/raven/pci-acp3x.c:159:1: warning: parameter names (without 
>> types) in function declaration
   sound/soc//amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but 
not used [-Wunused-variable]
static struct pci_driver acp3x_driver  = {
 ^~~~
   cc1: some warnings being treated as errors

vim +58 sound/soc//amd/raven/pci-acp3x.c

1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   29  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   30  static int 
snd_acp3x_probe(struct pci_dev *pci,
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   31  
const struct pci_device_id *pci_id)
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   32  {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   33   int ret;
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   34   u32 addr, val;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   35   struct acp3x_dev_data 
*adata;
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   36   struct 
platform_device_info pdevinfo;
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   37   unsigned int irqflags;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   38  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   39   if 
(pci_enable_device(pci)) {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   40   
dev_err(>dev, "pci_enable_device failed\n");
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   41   return -ENODEV;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   42   }
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   43  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   44   ret = 
pci_request_regions(pci, "AMD ACP3x audio");
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   45   if (ret < 0) {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   46   
dev_err(>dev, "pci_request_regions failed\n");
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   47   goto 
disable_pci;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   48   }
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   49  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   50   adata = 
devm_kzalloc(>dev, sizeof(struct acp3x_dev_data),
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   51   
GFP_KERNEL);
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   52   if (adata == NULL) {
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   53   ret = -ENOMEM;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   54   goto 
release_regions;
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   55   }
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   56  
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   57   /* check for msi 
interrupt support */
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29  @58   ret = 
pci_enable_msi(pci);
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   59   if (ret)
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   60   /* msi is not 
enabled */
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   61   irqflags = 
IRQF_SHARED;
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   62   else
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   63   /* msi is 
enabled */
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   64   irqflags = 0;
5fa60ff2 Maruthi Srinivas Bayyavarapu 2017-03-29   65  
1e29b934 Maruthi Srinivas Bayyavarapu 2017-03-27   66   addr 

Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

[kbuild test robot]

Hi Neil,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Neil-Armstrong/Add-ChromeOS-EC-CEC-Support/20180516-180519
base:   git://linuxtv.org/media_tree.git master
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   drivers/media//platform/cros-ec-cec/cros-ec-cec.c: In function 
'cros_ec_cec_get_notifier':
>> drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: error: 
>> 'pci_bus_type' undeclared (first use in this function); did you mean 
>> 'pci_pcie_type'?
   d = bus_find_device_by_name(_bus_type, NULL,
^~~~
pci_pcie_type
   drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: note: each 
undeclared identifier is reported only once for each function it appears in

vim +231 drivers/media//platform/cros-ec-cec/cros-ec-cec.c

   217  
   218  static int cros_ec_cec_get_notifier(struct device *dev,
   219  struct cec_notifier **notify)
   220  {
   221  int i;
   222  
   223  for (i = 0 ; i < ARRAY_SIZE(cec_dmi_match_table) ; ++i) {
   224  const struct cec_dmi_match *m = _dmi_match_table[i];
   225  
   226  if (dmi_match(DMI_SYS_VENDOR, m->sys_vendor) &&
   227  dmi_match(DMI_PRODUCT_NAME, m->product_name)) {
   228  struct device *d;
   229  
   230  /* Find the device, bail out if not yet 
registered */
 > 231  d = bus_find_device_by_name(_bus_type, NULL,
   232  m->devname);
   233  if (!d)
   234  return -EPROBE_DEFER;
   235  
   236  *notify = cec_notifier_get_conn(d, m->conn);
   237  return 0;
   238  }
   239  }
   240  
   241  /* Hardware support must be added in the cec_dmi_match_table */
   242  dev_warn(dev, "CEC notifier not configured for this 
hardware\n");
   243  
   244  return -ENODEV;
   245  }
   246  

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


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

[tegra-drm:drm/tegra/for-next 27/35] drivers/gpu/host1x/job.c:103:33: error: 'struct host1x_job' has no member named 'num_cmdbufs'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head:   b9136bd01841a63b7706db69e1da8843c8622a9f
commit: c8d8568a8dbb4dc455ceaca7b95108d85b3d4798 [27/35] gpu: host1x: Use not 
explicitly sized types
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c8d8568a8dbb4dc455ceaca7b95108d85b3d4798
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from arch/arm64/include/asm/bug.h:37:0,
from include/linux/bug.h:5,
from arch/arm64/include/asm/ptrace.h:86,
from arch/arm64/include/asm/fpsimd.h:19,
from arch/arm64/include/asm/cpufeature.h:14,
from arch/arm64/include/asm/processor.h:42,
from include/linux/mutex.h:19,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from drivers/gpu/host1x/job.c:19:
   drivers/gpu/host1x/job.c: In function 'host1x_job_add_gather':
>> drivers/gpu/host1x/job.c:103:33: error: 'struct host1x_job' has no member 
>> named 'num_cmdbufs'
 WARN_ON(job->num_gathers >= job->num_cmdbufs);
^
   include/asm-generic/bug.h:112:25: note: in definition of macro 'WARN_ON'
 int __ret_warn_on = !!(condition);\
^

vim +103 drivers/gpu/host1x/job.c

  > 19  #include 
20  #include 
21  #include 
22  #include 
23  #include 
24  #include 
25  #include 
26  #include 
27  #include 
28  
29  #include "channel.h"
30  #include "dev.h"
31  #include "job.h"
32  #include "syncpt.h"
33  
34  #define HOST1X_WAIT_SYNCPT_OFFSET 0x8
35  
36  struct host1x_job *host1x_job_alloc(struct host1x_channel *ch,
37  u32 num_cmdbufs, u32 num_relocs)
38  {
39  struct host1x_job *job = NULL;
40  unsigned int num_unpins = num_cmdbufs + num_relocs;
41  u64 total;
42  void *mem;
43  
44  /* Check that we're not going to overflow */
45  total = sizeof(struct host1x_job) +
46  (u64)num_relocs * sizeof(struct host1x_reloc) +
47  (u64)num_unpins * sizeof(struct host1x_job_unpin_data) +
48  (u64)num_cmdbufs * sizeof(struct host1x_job_gather) +
49  (u64)num_unpins * sizeof(dma_addr_t) +
50  (u64)num_unpins * sizeof(u32 *);
51  if (total > ULONG_MAX)
52  return NULL;
53  
54  mem = job = kzalloc(total, GFP_KERNEL);
55  if (!job)
56  return NULL;
57  
58  kref_init(>ref);
59  job->channel = ch;
60  
61  /* Redistribute memory to the structs  */
62  mem += sizeof(struct host1x_job);
63  job->relocs = num_relocs ? mem : NULL;
64  mem += num_relocs * sizeof(struct host1x_reloc);
65  job->unpins = num_unpins ? mem : NULL;
66  mem += num_unpins * sizeof(struct host1x_job_unpin_data);
67  job->gathers = num_cmdbufs ? mem : NULL;
68  mem += num_cmdbufs * sizeof(struct host1x_job_gather);
69  job->addr_phys = num_unpins ? mem : NULL;
70  
71  job->reloc_addr_phys = job->addr_phys;
72  job->gather_addr_phys = >addr_phys[num_relocs];
73  
74  return job;
75  }
76  EXPORT_SYMBOL(host1x_job_alloc);
77  
78  struct host1x_job *host1x_job_get(struct host1x_job *job)
79  {
80  kref_get(>ref);
81  return job;
82  }
83  EXPORT_SYMBOL(host1x_job_get);
84  
85  static void job_free(struct kref *ref)
86  {
87  struct host1x_job *job = container_of(ref, struct host1x_job, 
ref);
88  
89  kfree(job);
90  }
91  
92  void host1x_job_put(struct host1x_job *job)
93  {
94  kref_put(>ref, job_free);
95  }
96  EXPORT_SYMBOL(host1x_job_put);
97  
98  void host1x_job_add_gather(struct host1x_job *job, struct host1x_bo *bo,
99 unsigned int words, unsigned int offset)
   100  {
   101  struct host1x_job_gather *gather = 
>gathers[job->num_gathers];
   102  
 > 103  WARN_ON(job->num_gathers >= job->num_cmdbufs);
   104  
   105  gather->words = words;
   106  gather->bo = 

Re: [RFC] remoting KMS

[Daniel Vetter]

On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom  wrote:
> Hi!
>
> I'm currently working on a remoting KMS backend, and now I thought it would
> be a good time to get some feedback on a very rough design:
>
> The idea is that we want to be get enough information on the backend side of
> KMS to be able to remote the display system over VNC or something similar.
> Initially I'd plug in an open-source VNC server as the "reference"
> user-space.
>
> The solution should be general enough to plug into any driver, including
> VKMS, either mirroring an existing crtc/connector or adding a virtual one.
> The driver would typically only have to implement an efficient readback
> command, optionally with a diff-map or damage rect that tracks changed
> content for the VNC server to be able to do its work efficiently.
>
> This would all be forwarded to a user-space interface and protocol with a
> slightly more elaborate user-space event-mechanism than the one we have in
> drm now. In particular we want to be able to read partial events, and resume
> event reading after a partial event. We would also want to be able to send
> commands either through an ioctl() or using write(). Current test code is
> using write().
>
> Since the VNC server in our application typically will be system-wide, we
> need to resurrect a control-node functionality. I was trying to use sysfs
> attributes for this, but while sysfs supports rudimentary poll
> functionality. It's a bit too rudimentary and tracking client lifetime
> becomes racy. Perhaps control nodes renamed to "remoting" nodes or something
> similar. It might be that masters want to attach a VNC server to their
> current display and in that case we probably would want to expand primary
> nodes with this functionality as well.
>
> Now to the open-source  problem. As mentioned, the reference user-space will
> be a solution based on libvncserver. In fact there will be a small
> user-space interface library that libvncserver can interact with, similar to
> libdrm. However, I envision in the long run VMWare would be interested to
> use other remoting protocols with closed source protocol encoders, using the
> open source reference library. In theory, this solution would also allow for
> simple (open- or closed source) user-space display drivers, very similar to
> DisplayLink's evdi solution, even if that's not a use-case VMWare is
> currently interested in.
>
> Thoughts and comments appreciated.

Just two very quick comments:

- For the uapi - can't we just use v4l for the output side? That gives
you buffer handoff, syncing (v4l is gaining dma_fence support) and
pretty much everything you might want. And we've talked about building
kms->v4l pipelines in a bunch of other use-cases already (like feeding
into video encoders for widi and stuff like that). Would give you the
userspace for free, only thing we really need is to (maybe, not sure
you'd even need that) expose what kms output corresponds to what v4l
pipeline.

- You say "The solution should be general enough to plug into any
driver" - is the idea that any hw driver would automatically support
this? Given that prime-like setups are getting ever more common
(mobile is essentially all prime with display and offloaded rendering)
I think it'd be cleanest if we don't tie that virtual output to other
drivers, but bind things together using buffer sharing/dma-fences and
prime. Adding v4l output to vkms is actually something we've already
discussed a bit on irc, but with the use-case that you could just
watch what your desktop/window manager is doing under a specific
simulated setup (e.g. pll sharing constraints, or special plane
features, or whatever other specific thing you want to test your
compositor against but isn't supported on all physical hw/drivers).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Andrey Grodzovsky]

On 05/17/2018 10:48 AM, Michel Dänzer wrote:

On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:

Hi Michele and others, I am trying to implement the approach bellow to
resolve AMDGPU's hang when commands are stuck in pipe during process exit.

I noticed that once I implemented the file_operation.flush callback
then during run of X, i see the flush callback gets called not only for
Xorg process but for other

processes such as 'xkbcomp' and even 'sh', it seems like Xorg passes his
FDs to children, Christian mentioned he remembered a discussion to
always set FD_CLOEXEC flag when opening the hardware device file, so

we suspect a bug in Xorg with regard to this behavior.

Try the libdrm patch below.

Note that the X server passes DRM file descriptors to DRI3 clients.


Tried it, didn't help. I still see other processes calling .flush for 
/dev/dri/card0


Thanks,
Andrey




diff --git a/xf86drm.c b/xf86drm.c
index 3a9d0ed2..c09437b0 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -405,7 +405,7 @@ wait_for_udev:
  }
  #endif

-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
  drmMsg("drmOpenDevice: open result is %d, (%s)\n",
 fd, fd < 0 ? strerror(errno) : "OK");
  if (fd >= 0)
@@ -425,7 +425,7 @@ wait_for_udev:
  chmod(buf, devmode);
  }
  }
-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
  drmMsg("drmOpenDevice: open result is %d, (%s)\n",
 fd, fd < 0 ? strerror(errno) : "OK");
  if (fd >= 0)
@@ -474,7 +474,7 @@ static int drmOpenMinor(int minor, int create, int type)
  };

  sprintf(buf, dev_name, DRM_DIR_NAME, minor);
-if ((fd = open(buf, O_RDWR, 0)) >= 0)
+if ((fd = open(buf, O_RDWR | O_CLOEXEC, 0)) >= 0)
  return fd;
  return -errno;
  }





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

Re: [PATCH] drm/scheduler: fix function name prefix in comments

[Alex Deucher]

On Wed, May 16, 2018 at 9:24 AM, Nayan Deshmukh
 wrote:
> That got missed while moving the files outside of amdgpu.
>
> Signed-off-by: Nayan Deshmukh 
> Reviewed-by: Christian König 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
> b/drivers/gpu/drm/scheduler/sched_fence.c
> index 69aab086b913..786b47f15783 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -87,7 +87,7 @@ static bool drm_sched_fence_enable_signaling(struct 
> dma_fence *f)
>  }
>
>  /**
> - * amd_sched_fence_free - free up the fence memory
> + * drm_sched_fence_free - free up the fence memory
>   *
>   * @rcu: RCU callback head
>   *
> @@ -103,7 +103,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu)
>  }
>
>  /**
> - * amd_sched_fence_release_scheduled - callback that fence can be freed
> + * drm_sched_fence_release_scheduled - callback that fence can be freed
>   *
>   * @fence: fence
>   *
> @@ -118,7 +118,7 @@ static void drm_sched_fence_release_scheduled(struct 
> dma_fence *f)
>  }
>
>  /**
> - * amd_sched_fence_release_finished - drop extra reference
> + * drm_sched_fence_release_finished - drop extra reference
>   *
>   * @f: fence
>   *
> --
> 2.14.3
>
> ___
> 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

[RFC] remoting KMS

[Thomas Hellstrom]

Hi!

I'm currently working on a remoting KMS backend, and now I thought it 
would be a good time to get some feedback on a very rough design:


The idea is that we want to be get enough information on the backend 
side of KMS to be able to remote the display system over VNC or 
something similar. Initially I'd plug in an open-source VNC server as 
the "reference" user-space.


The solution should be general enough to plug into any driver, including 
VKMS, either mirroring an existing crtc/connector or adding a virtual 
one. The driver would typically only have to implement an efficient 
readback command, optionally with a diff-map or damage rect that tracks 
changed content for the VNC server to be able to do its work efficiently.


This would all be forwarded to a user-space interface and protocol with 
a slightly more elaborate user-space event-mechanism than the one we 
have in drm now. In particular we want to be able to read partial 
events, and resume event reading after a partial event. We would also 
want to be able to send commands either through an ioctl() or using 
write(). Current test code is using write().


Since the VNC server in our application typically will be system-wide, 
we need to resurrect a control-node functionality. I was trying to use 
sysfs attributes for this, but while sysfs supports rudimentary poll 
functionality. It's a bit too rudimentary and tracking client lifetime 
becomes racy. Perhaps control nodes renamed to "remoting" nodes or 
something similar. It might be that masters want to attach a VNC server 
to their current display and in that case we probably would want to 
expand primary nodes with this functionality as well.


Now to the open-source  problem. As mentioned, the reference user-space 
will be a solution based on libvncserver. In fact there will be a small 
user-space interface library that libvncserver can interact with, 
similar to libdrm. However, I envision in the long run VMWare would be 
interested to use other remoting protocols with closed source protocol 
encoders, using the open source reference library. In theory, this 
solution would also allow for simple (open- or closed source) user-space 
display drivers, very similar to DisplayLink's evdi solution, even if 
that's not a use-case VMWare is currently interested in.


Thoughts and comments appreciated.

/Thomas



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

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

Jani Nikula  changed:

   What|Removed |Added

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

--- Comment #12 from Jani Nikula  ---
Thanks for the updates, closing.

-- 
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 v7 1/3] drm: Add writeback connector type

[Liviu Dudau]

From: Brian Starkey 

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Chances since v4:
 - Embed a drm_encoder inside the drm_writeback_connector to
   reduce the amount of boilerplate code required from the drivers
   that are using it.

Changes since v5:
 - Added Rob Clark's atomic_commit() vfunc to connector helper
   funcs, so that writeback jobs are committed from atomic helpers
 - Updated create_writeback_properties() signature to return an
   error code rather than a boolean false for failure.
 - Free writeback job with the connector state rather than when
   doing the cleanup_work()

Cc: linux-...@vger.kernel.org
Signed-off-by: Brian Starkey 
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov 
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: Rob Clark 
Signed-off-by: Liviu Dudau 
---
 Documentation/gpu/drm-kms.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 128 
 drivers/gpu/drm/drm_atomic_helper.c  |  30 +++
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_writeback.c  | 256 +++
 include/drm/drm_atomic.h |   3 +
 include/drm/drm_connector.h  |  13 ++
 include/drm/drm_mode_config.h|  15 ++
 include/drm/drm_modeset_helper_vtables.h |  11 +
 include/drm/drm_writeback.h  |  88 
 include/uapi/drm/drm_mode.h  |   1 +
 12 files changed, 558 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd44..809d403087f95 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -373,6 +373,15 @@ Connector Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:export:
 
+Writeback Connectors
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :export:
+
 Encoder Abstraction
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff4479b4..3d708959b224c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o
+   drm_syncobj.o drm_lease.o drm_writeback.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22dbc..3f1e4b894803b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -668,6 +669,45 @@ static void drm_atomic_crtc_print_state(struct drm_printer 
*p,
crtc->funcs->atomic_print_state(p, state);
 }
 
+/**
+ * drm_atomic_connector_check - check connector state
+ * @connector: connector to check
+ * @state: connector state to check
+ *
+ * Provides core sanity checks for connector state.
+ *
+ 

[PATCH v7 2/3] drm: writeback: Add out-fences for writeback connectors

[Liviu Dudau]

From: Brian Starkey 

Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.

A timeline is added to drm_writeback_connector for use by the writeback
out-fences.

In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.

Changes from v2:
 - Rebase onto Gustavo Padovan's v9 explicit sync series
 - Change out_fence_ptr type to s32 __user *
 - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
 - Store fence in drm_writeback_job
 Gustavo Padovan:
 - Move out_fence_ptr out of connector_state
 - Signal fence from drm_writeback_signal_completion instead of
   in driver directly

Changes from v3:
 - Rebase onto commit 7e9081c5aac7 ("drm/fence: fix memory overwrite
   when setting out_fence fd") (change out_fence_ptr to s32 __user *,
   for real this time.)
 - Update documentation around WRITEBACK_OUT_FENCE_PTR

Signed-off-by: Brian Starkey 
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_atomic.c|  99 ++---
 drivers/gpu/drm/drm_writeback.c | 108 +++-
 include/drm/drm_atomic.h|   8 +++
 include/drm/drm_connector.h |   8 +--
 include/drm/drm_mode_config.h   |   8 +++
 include/drm/drm_writeback.h |  43 -
 6 files changed, 258 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3f1e4b894803b..cc2f86c68b293 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -318,6 +318,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
drm_atomic_state *state,
return fence_ptr;
 }
 
+static int set_out_fence_for_connector(struct drm_atomic_state *state,
+   struct drm_connector *connector,
+   s32 __user *fence_ptr)
+{
+   unsigned int index = drm_connector_index(connector);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (put_user(-1, fence_ptr))
+   return -EFAULT;
+
+   state->connectors[index].out_fence_ptr = fence_ptr;
+
+   return 0;
+}
+
+static s32 __user *get_out_fence_for_connector(struct drm_atomic_state *state,
+  struct drm_connector *connector)
+{
+   unsigned int index = drm_connector_index(connector);
+   s32 __user *fence_ptr;
+
+   fence_ptr = state->connectors[index].out_fence_ptr;
+   state->connectors[index].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -705,6 +734,12 @@ static int drm_atomic_connector_check(struct drm_connector 
*connector,
return -EINVAL;
}
 
+   if (writeback_job->out_fence && !writeback_job->fb) {
+   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence 
without framebuffer\n",
+connector->base.id, connector->name);
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -1320,6 +1355,11 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
if (fb)
drm_framebuffer_unreference(fb);
return ret;
+   } else if (property == config->writeback_out_fence_ptr_property) {
+   s32 __user *fence_ptr = u64_to_user_ptr(val);
+
+   return set_out_fence_for_connector(state->state, connector,
+  fence_ptr);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1404,6 +1444,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
+   } else if (property == config->writeback_out_fence_ptr_property) {
+   *val = 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
@@ -2263,7 +2305,7 @@ static int setup_out_fence(struct drm_out_fence_state 
*fence_state,
return 0;
 }
 
-static int prepare_crtc_signaling(struct drm_device *dev,
+static int prepare_signaling(struct drm_device *dev,
  struct drm_atomic_state *state,
  struct drm_mode_atomic *arg,
  

[PATCH v7 3/3] drm: writeback: Add client capability for exposing writeback connectors

[Liviu Dudau]

Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.

Re-requested-by: Sean Paul 
Cc: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_ioctl.c   | 7 +++
 drivers/gpu/drm/drm_mode_config.c | 5 +
 include/drm/drm_file.h| 7 +++
 include/uapi/drm/drm.h| 9 +
 4 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af782911c505d..59951ff3e3630 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,13 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
+   if (!file_priv->atomic || !drm_core_check_feature(dev, 
DRIVER_ATOMIC))
+   return -EINVAL;
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->writeback_connectors = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index e5c653357024d..21e353bd3948e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
count = 0;
connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
drm_for_each_connector_iter(connector, _iter) {
+   /* only expose writeback connectors if userspace understands 
them */
+   if (!file_priv->writeback_connectors &&
+   (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
+   continue;
+
if (drm_lease_held(file_priv, connector->base.id)) {
if (count < card_res->count_connectors &&
put_user(connector->base.id, connector_id + count)) 
{
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5176c3797680c..2a09b3c8965c6 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -181,6 +181,13 @@ struct drm_file {
/** @atomic: True if client understands atomic properties. */
unsigned atomic:1;
 
+   /**
+* @writeback_connectors:
+*
+* True if client understands writeback connectors
+*/
+   unsigned writeback_connectors:1;
+
/**
 * @is_master:
 *
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff5945c8a0..59f27ea928b42 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,15 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
+ *
+ * If set to 1, the DRM core will expose special connectors to be used for
+ * writing back to memory the scene setup in the commit. Depends on client
+ * also supporting DRM_CLIENT_CAP_ATOMIC
+ */
+#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.17.0

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

[PATCH v7 0/3] drm: Introduce writeback connectors

[Liviu Dudau]

Hi,

This is v7 of the writeback connector series. This is just a refresh
of the v6 series in order to get it ready for merging into the kernel,
now that the userspace implementation has been reviewed and ACKed
by Sean Paul here [1].

For anyone that wants a refresh on what changed in v6, the series
can be found here [2]. The only change in v7 is that the userspace
capabilities patch does not depend on the cleanup patch that got NACKed.

Best regards,
Liviu


[1] 
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/3
[2] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html


Brian Starkey (2):
  drm: Add writeback connector type
  drm: writeback: Add out-fences for writeback connectors

Liviu Dudau (1):
  drm: writeback: Add client capability for exposing writeback
connectors

 Documentation/gpu/drm-kms.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 227 +-
 drivers/gpu/drm/drm_atomic_helper.c  |  30 ++
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_ioctl.c  |   7 +
 drivers/gpu/drm/drm_mode_config.c|   5 +
 drivers/gpu/drm/drm_writeback.c  | 360 +++
 include/drm/drm_atomic.h |  11 +
 include/drm/drm_connector.h  |  13 +
 include/drm/drm_file.h   |   7 +
 include/drm/drm_mode_config.h|  23 ++
 include/drm/drm_modeset_helper_vtables.h |  11 +
 include/drm/drm_writeback.h  | 129 
 include/uapi/drm/drm.h   |   9 +
 include/uapi/drm/drm_mode.h  |   1 +
 16 files changed, 837 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h

-- 
2.17.0

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

[Bug 199693] [bisect 08810a4119aaebf6318f209ec5dd9828e969cba4] (pci runtime) System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

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

Len Brown (l...@kernel.org) changed:

   What|Removed |Added

 CC||l...@kernel.org
   Assignee|drivers_video-dri@kernel-bu |r...@rjwysocki.net
   |gs.osdl.org |

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

Re: [PATCH v11 0/2] Enabling content-type setting for HDMI displays.

[Ville Syrjälä]

On Tue, May 15, 2018 at 04:59:26PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
> 
> Stanislav Lisovskiy (2):
>   drm: content-type property for HDMI connector
>   i915: content-type property for HDMI connector

Series pushed to drm-misc-next. Thanks for the patches.

PS. I fixed up a couple of checkpatch warns while applying
the patches. In the future please look through the reported
warnings and fix up the ones that aren't entirely crazy.

> 
>  Documentation/gpu/drm-kms.rst|   6 ++
>  Documentation/gpu/kms-properties.csv |   1 +
>  drivers/gpu/drm/drm_atomic.c |   4 +
>  drivers/gpu/drm/drm_connector.c  | 115 +++
>  drivers/gpu/drm/drm_edid.c   |   8 ++
>  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  18 +++--
>  include/drm/drm_connector.h  |  15 
>  include/drm/drm_mode_config.h|   5 ++
>  include/uapi/drm/drm_mode.h  |   7 ++
>  10 files changed, 174 insertions(+), 6 deletions(-)
> 
> -- 
> 2.17.0

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

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Michel Dänzer]

On 2018-05-17 05:33 PM, Andrey Grodzovsky wrote:
> 
> BTW, just out of interest, how the FDs are passed to clients ? Using
> sockets ?

Yes, via the socket used for the X11 display connection.


> Can you point me to the code which does it ?

xserver/dri3/dri3_request.c:dri3_send_open_reply() =>
xserver/os/io.c:WriteFdToClient()

Note that since dri3_send_open_reply passes TRUE for WriteFdToClient's
do_close parameter, the file descriptor is closed in the Xorg process
after sending it to the client.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/tegra: Add kerneldoc for UAPI

[Thierry Reding]

From: Thierry Reding 

Document the userspace ABI with kerneldoc to provide some information on
how to use it.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.c  |   4 +-
 include/uapi/drm/tegra_drm.h | 480 ++-
 2 files changed, 468 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 387ba1dfbe0d..e2987a19541d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -291,10 +291,10 @@ struct tegra_bo *tegra_bo_create(struct drm_device *drm, 
size_t size,
if (err < 0)
goto release;
 
-   if (flags & DRM_TEGRA_GEM_CREATE_TILED)
+   if (flags & DRM_TEGRA_GEM_TILED)
bo->tiling.mode = TEGRA_BO_TILING_MODE_TILED;
 
-   if (flags & DRM_TEGRA_GEM_CREATE_BOTTOM_UP)
+   if (flags & DRM_TEGRA_GEM_BOTTOM_UP)
bo->flags |= TEGRA_BO_BOTTOM_UP;
 
return bo;
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 99e15d82d1e9..86a7b1e7559d 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -29,146 +29,598 @@
 extern "C" {
 #endif
 
-#define DRM_TEGRA_GEM_CREATE_TILED (1 << 0)
-#define DRM_TEGRA_GEM_CREATE_BOTTOM_UP (1 << 1)
+#define DRM_TEGRA_GEM_TILED(1 << 0)
+#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 1)
+#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_TILED | \
+DRM_TEGRA_GEM_BOTTOM_UP)
 
+/**
+ * struct drm_tegra_gem_create - parameters for the GEM object creation IOCTL
+ */
 struct drm_tegra_gem_create {
+   /**
+* @size:
+*
+* The size, in bytes, of the buffer object to be created.
+*/
__u64 size;
+
+   /**
+* @flags:
+*
+* A bitmask of flags that influence the creation of GEM objects:
+*
+* DRM_TEGRA_GEM_TILED
+*   Use the 16x16 tiling format for this buffer.
+*
+* DRM_TEGRA_GEM_BOTTOM_UP
+*   The buffer has a bottom-up layout.
+*/
__u32 flags;
+
+   /**
+* @handle:
+*
+* Return location for the handle of the created GEM object.
+*/
__u32 handle;
 };
 
+/**
+ * struct drm_tegra_gem_mmap - parameters for the GEM mmap IOCTL
+ */
 struct drm_tegra_gem_mmap {
+   /**
+* @handle:
+*
+* Handle of the GEM object to obtain an mmap offset for.
+*/
__u32 handle;
+
+   /**
+* @pad:
+*
+* Structure padding that may be used in the future. Must be 0.
+*/
__u32 pad;
+
+   /**
+* @offset:
+*
+* Return location for the mmap offset for the given GEM object.
+*/
__u64 offset;
 };
 
+/**
+ * struct drm_tegra_syncpt_read - parameters for the read syncpoint IOCTL
+ */
 struct drm_tegra_syncpt_read {
+   /**
+* @id:
+*
+* ID of the syncpoint to read the current value from.
+*/
__u32 id;
+
+   /**
+* @value:
+*
+* Return location for the current syncpoint value.
+*/
__u32 value;
 };
 
+/**
+ * struct drm_tegra_syncpt_incr - parameters for the increment syncpoint IOCTL
+ */
 struct drm_tegra_syncpt_incr {
+   /**
+* @id:
+*
+* ID of the syncpoint to read the current value from.
+*/
__u32 id;
+
+   /**
+* @pad:
+*
+* Structure padding that may be used in the future. Must be 0.
+*/
__u32 pad;
 };
 
+/**
+ * struct drm_tegra_syncpt_wait - parameters for the wait syncpoint IOCTL
+ */
 struct drm_tegra_syncpt_wait {
+   /**
+* @id:
+*
+* ID of the syncpoint to wait on.
+*/
__u32 id;
+
+   /**
+* @thresh:
+*
+* Threshold value for which to wait.
+*/
__u32 thresh;
+
+   /**
+* @timeout:
+*
+* Timeout, in milliseconds, to wait.
+*/
__u32 timeout;
+
+   /**
+* @value:
+*
+* Return value for the current syncpoint value.
+*/
__u32 value;
 };
 
 #define DRM_TEGRA_NO_TIMEOUT   (0x)
 
+/**
+ * struct drm_tegra_open_channel - parameters for the open channel IOCTL
+ */
 struct drm_tegra_open_channel {
+   /**
+* @client:
+*
+* The client ID for this channel.
+*/
__u32 client;
+
+   /**
+* @pad:
+*
+* Structure padding that may be used in the future. Must be 0.
+*/
__u32 pad;
+
+   /**
+* @context:
+*
+* Return location for the application context of this channel. This
+* context needs to be passed to the DRM_TEGRA_CHANNEL_CLOSE or the
+* DRM_TEGRA_SUBMIT IOCTLs.
+*/
__u64 context;
 };
 

[PATCH 5/7] drm/tegra: gr3d: Track interface version

[Thierry Reding]

From: Thierry Reding 

Set the interface version implemented by the gr3d module. This allows
userspace to pass the correct command stream when programming the gr3d
module.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gr3d.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 28c4ef63065b..0d4dce978eb2 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -19,6 +20,10 @@
 #include "gem.h"
 #include "gr3d.h"
 
+struct gr3d_soc {
+   unsigned int version;
+};
+
 struct gr3d {
struct tegra_drm_client client;
struct host1x_channel *channel;
@@ -27,6 +32,8 @@ struct gr3d {
struct reset_control *rst_secondary;
struct reset_control *rst;
 
+   const struct gr3d_soc *soc;
+
DECLARE_BITMAP(addr_regs, GR3D_NUM_REGS);
 };
 
@@ -125,10 +132,22 @@ static const struct tegra_drm_client_ops gr3d_ops = {
.submit = tegra_drm_submit,
 };
 
+static const struct gr3d_soc tegra20_gr3d_soc = {
+   .version = 0x20,
+};
+
+static const struct gr3d_soc tegra30_gr3d_soc = {
+   .version = 0x30,
+};
+
+static const struct gr3d_soc tegra114_gr3d_soc = {
+   .version = 0x35,
+};
+
 static const struct of_device_id tegra_gr3d_match[] = {
-   { .compatible = "nvidia,tegra114-gr3d" },
-   { .compatible = "nvidia,tegra30-gr3d" },
-   { .compatible = "nvidia,tegra20-gr3d" },
+   { .compatible = "nvidia,tegra114-gr3d", .data = _gr3d_soc },
+   { .compatible = "nvidia,tegra30-gr3d", .data = _gr3d_soc },
+   { .compatible = "nvidia,tegra20-gr3d", .data = _gr3d_soc },
{ }
 };
 MODULE_DEVICE_TABLE(of, tegra_gr3d_match);
@@ -250,6 +269,8 @@ static int gr3d_probe(struct platform_device *pdev)
if (!gr3d)
return -ENOMEM;
 
+   gr3d->soc = of_device_get_match_data(>dev);
+
syncpts = devm_kzalloc(>dev, sizeof(*syncpts), GFP_KERNEL);
if (!syncpts)
return -ENOMEM;
@@ -303,6 +324,7 @@ static int gr3d_probe(struct platform_device *pdev)
gr3d->client.base.ops = _client_ops;
gr3d->client.base.dev = >dev;
gr3d->client.base.class = HOST1X_CLASS_GR3D;
+   gr3d->client.base.version = gr3d->soc->version;
gr3d->client.base.syncpts = syncpts;
gr3d->client.base.num_syncpts = 1;
 
-- 
2.17.0

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

[PATCH 6/7] drm/tegra: vic: Track interface version

[Thierry Reding]

From: Thierry Reding 

Set the interface version implemented by the VIC module. This allows
userspace to pass the correct command stream when programming the VIC
module.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/vic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index f5794dd49f3b..d739403045aa 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -25,6 +25,7 @@
 
 struct vic_config {
const char *firmware;
+   unsigned int version;
 };
 
 struct vic {
@@ -264,18 +265,21 @@ static const struct tegra_drm_client_ops vic_ops = {
 
 static const struct vic_config vic_t124_config = {
.firmware = NVIDIA_TEGRA_124_VIC_FIRMWARE,
+   .version = 0x40,
 };
 
 #define NVIDIA_TEGRA_210_VIC_FIRMWARE "nvidia/tegra210/vic04_ucode.bin"
 
 static const struct vic_config vic_t210_config = {
.firmware = NVIDIA_TEGRA_210_VIC_FIRMWARE,
+   .version = 0x21,
 };
 
 #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,
+   .version = 0x18,
 };
 
 static const struct of_device_id vic_match[] = {
@@ -337,6 +341,7 @@ static int vic_probe(struct platform_device *pdev)
vic->client.base.ops = _client_ops;
vic->client.base.dev = dev;
vic->client.base.class = HOST1X_CLASS_VIC;
+   vic->client.base.version = vic->config->version;
vic->client.base.syncpts = syncpts;
vic->client.base.num_syncpts = 1;
vic->dev = dev;
-- 
2.17.0

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

[PATCH 4/7] drm/tegra: gr2d: Track interface version

[Thierry Reding]

From: Thierry Reding 

Set the interface version implemented by the gr2d module. This allows
userspace to pass the correct command stream when programming the gr2d
module.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gr2d.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 9a8ea93016a9..d13752b0d915 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -7,16 +7,23 @@
  */
 
 #include 
+#include 
 
 #include "drm.h"
 #include "gem.h"
 #include "gr2d.h"
 
+struct gr2d_soc {
+   unsigned int version;
+};
+
 struct gr2d {
struct tegra_drm_client client;
struct host1x_channel *channel;
struct clk *clk;
 
+   const struct gr2d_soc *soc;
+
DECLARE_BITMAP(addr_regs, GR2D_NUM_REGS);
 };
 
@@ -123,9 +130,17 @@ static const struct tegra_drm_client_ops gr2d_ops = {
.submit = tegra_drm_submit,
 };
 
+static const struct gr2d_soc tegra20_gr2d_soc = {
+   .version = 0x20,
+};
+
+static const struct gr2d_soc tegra30_gr2d_soc = {
+   .version = 0x30,
+};
+
 static const struct of_device_id gr2d_match[] = {
-   { .compatible = "nvidia,tegra30-gr2d" },
-   { .compatible = "nvidia,tegra20-gr2d" },
+   { .compatible = "nvidia,tegra30-gr2d", .data = _gr2d_soc },
+   { .compatible = "nvidia,tegra20-gr2d", .data = _gr2d_soc },
{ },
 };
 MODULE_DEVICE_TABLE(of, gr2d_match);
@@ -158,6 +173,8 @@ static int gr2d_probe(struct platform_device *pdev)
if (!gr2d)
return -ENOMEM;
 
+   gr2d->soc = of_device_get_match_data(dev);
+
syncpts = devm_kzalloc(dev, sizeof(*syncpts), GFP_KERNEL);
if (!syncpts)
return -ENOMEM;
@@ -178,6 +195,7 @@ static int gr2d_probe(struct platform_device *pdev)
gr2d->client.base.ops = _client_ops;
gr2d->client.base.dev = dev;
gr2d->client.base.class = HOST1X_CLASS_GR2D;
+   gr2d->client.base.version = gr2d->soc->version;
gr2d->client.base.syncpts = syncpts;
gr2d->client.base.num_syncpts = 1;
 
-- 
2.17.0

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

[PATCH 0/7] drm/tegra: Preparation work for destaging ABI

[Thierry Reding]

From: Thierry Reding 

These patches are further preparation work to destage the job submission
ABI. Patch 1 fixes a typo in the argument to the close channel IOCTL and
isn't technically preparation work. Neither are patches 2 and 3 which do
some cleanup and add support for the rotation property. However, they do
touch areas close to the ABI and simplify subsequent patches.

Patches 4-6 add interface version information to the gr2d, gr3d and VIC
drivers which will be used by new ABI to let userspace know about which
interface it needs to program.

Finally, patch 7 adds kerneldoc for the current ABI.

Thierry

Thierry Reding (7):
  drm/tegra: Use proper arguments for DRM_TEGRA_CLOSE_CHANNEL IOCTL
  drm/tegra: gem: Fill in missing export info
  drm/tegra: dc: Support rotation property
  drm/tegra: gr2d: Track interface version
  drm/tegra: gr3d: Track interface version
  drm/tegra: vic: Track interface version
  drm/tegra: Add kerneldoc for UAPI

 drivers/gpu/drm/tegra/dc.c|  18 +-
 drivers/gpu/drm/tegra/drm.h   |   1 -
 drivers/gpu/drm/tegra/fb.c|  10 -
 drivers/gpu/drm/tegra/gem.c   |   6 +-
 drivers/gpu/drm/tegra/gr2d.c  |  22 +-
 drivers/gpu/drm/tegra/gr3d.c  |  28 +-
 drivers/gpu/drm/tegra/plane.c |   1 +
 drivers/gpu/drm/tegra/plane.h |   2 +
 drivers/gpu/drm/tegra/vic.c   |   5 +
 include/uapi/drm/tegra_drm.h  | 482 --
 10 files changed, 541 insertions(+), 34 deletions(-)

-- 
2.17.0

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

[PATCH 2/7] drm/tegra: gem: Fill in missing export info

[Thierry Reding]

From: Thierry Reding 

Set the owner and name of the exported DMA-BUF in addition to the
already filled-in fields.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 8b0b4ff64bb4..387ba1dfbe0d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -663,6 +663,8 @@ struct dma_buf *tegra_gem_prime_export(struct drm_device 
*drm,
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
+   exp_info.exp_name = KBUILD_MODNAME;
+   exp_info.owner = drm->driver->fops->owner;
exp_info.ops = _gem_prime_dmabuf_ops;
exp_info.size = gem->size;
exp_info.flags = flags;
-- 
2.17.0

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

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

[Daniel Stone]

On 17 May 2018 at 16:26, Russell King - ARM Linux  wrote:
> On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
>> On 30 March 2018 at 15:11, Daniel Stone  wrote:
>> > Since drm_framebuffer can now store GEM objects directly, place them
>> > there rather than in our own subclass. As this makes the framebuffer
>> > create_handle and destroy functions the same as the GEM framebuffer
>> > helper, we can reuse those.
>>
>> Ping - have you had a chance to look at this?
>
> I haven't, I've not moved any of my trees off 4.16 yet as I've been
> away on vacation, and also busy dealing with Spectre for 32-bit ARM.
>
> From a quick look, it seems fine, and as I guess the autobuilders
> haven't complained, it probably builds okay.  So it can probably
> be merged without much risk - if there are any problems I'll sort it
> out later.

Thanks Russell. I did do a build test locally as well which had no
complaints. I'll merge this through drm-misc.

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

[PATCH 3/7] drm/tegra: dc: Support rotation property

[Thierry Reding]

From: Thierry Reding 

Currently only the DRM_MODE_REFLECT_Y rotation is supported. The driver
already supports reflection on the Y axis via a custom flag which is not
very useful because it requires custom userspace. Replace that flag by a
standard rotation property that supports 0 degree rotation and Y axis
reflection.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c| 18 +-
 drivers/gpu/drm/tegra/drm.h   |  1 -
 drivers/gpu/drm/tegra/fb.c| 10 --
 drivers/gpu/drm/tegra/plane.c |  1 +
 drivers/gpu/drm/tegra/plane.h |  2 ++
 5 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 9f83a65b5ea9..e2e574202ca3 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -451,6 +451,7 @@ static int tegra_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
struct tegra_plane_state *plane_state = to_tegra_plane_state(state);
+   unsigned int rotation = DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y;
struct tegra_bo_tiling *tiling = _state->tiling;
struct tegra_plane *tegra = to_tegra_plane(plane);
struct tegra_dc *dc = to_tegra_dc(state->crtc);
@@ -498,6 +499,13 @@ static int tegra_plane_atomic_check(struct drm_plane 
*plane,
return -EINVAL;
}
 
+   rotation = drm_rotation_simplify(state->rotation, rotation);
+
+   if (rotation & DRM_MODE_REFLECT_Y)
+   plane_state->bottom_up = true;
+   else
+   plane_state->bottom_up = false;
+
/*
 * Tegra doesn't support different strides for U and V planes so we
 * error out if the user tries to display a framebuffer with such a
@@ -558,7 +566,7 @@ static void tegra_plane_atomic_update(struct drm_plane 
*plane,
window.dst.w = drm_rect_width(>state->dst);
window.dst.h = drm_rect_height(>state->dst);
window.bits_per_pixel = fb->format->cpp[0] * 8;
-   window.bottom_up = tegra_fb_is_bottom_up(fb);
+   window.bottom_up = state->bottom_up;
 
/* copy from state */
window.zpos = plane->state->normalized_zpos;
@@ -643,6 +651,14 @@ static struct drm_plane *tegra_primary_plane_create(struct 
drm_device *drm,
if (dc->soc->supports_blending)
drm_plane_create_zpos_property(>base, 0, 0, 255);
 
+   err = drm_plane_create_rotation_property(>base,
+DRM_MODE_ROTATE_0,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_REFLECT_Y);
+   if (err < 0)
+   dev_err(dc->dev, "failed to create rotation property: %d\n",
+   err);
+
return >base;
 }
 
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 4f41aaec8530..84930d13e28d 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -177,7 +177,6 @@ int drm_dp_aux_train(struct drm_dp_aux *aux, struct 
drm_dp_link *link,
 /* from fb.c */
 struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer *framebuffer,
unsigned int index);
-bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
 int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer,
struct tegra_bo_tiling *tiling);
 struct drm_framebuffer *tegra_fb_create(struct drm_device *drm,
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index e69434909a42..35827c729462 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -38,16 +38,6 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
return fb->planes[index];
 }
 
-bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer)
-{
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
-
-   if (fb->planes[0]->flags & TEGRA_BO_BOTTOM_UP)
-   return true;
-
-   return false;
-}
-
 int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer,
struct tegra_bo_tiling *tiling)
 {
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 176ef46c615c..271729b2c653 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -53,6 +53,7 @@ tegra_plane_atomic_duplicate_state(struct drm_plane *plane)
copy->tiling = state->tiling;
copy->format = state->format;
copy->swap = state->swap;
+   copy->bottom_up = state->bottom_up;
copy->opaque = state->opaque;
 
for (i = 0; i < 3; i++)
diff --git a/drivers/gpu/drm/tegra/plane.h b/drivers/gpu/drm/tegra/plane.h
index 6938719e7e5d..867b9c32b1b6 100644
--- a/drivers/gpu/drm/tegra/plane.h
+++ b/drivers/gpu/drm/tegra/plane.h
@@ -41,6 +41,8 @@ struct tegra_plane_state {
u32 format;
u32 swap;
 
+   bool 

[PATCH 1/7] drm/tegra: Use proper arguments for DRM_TEGRA_CLOSE_CHANNEL IOCTL

[Thierry Reding]

From: Thierry Reding 

A separate data structure exists for the DRM_TEGRA_CLOSE_CHANNEL IOCTL,
but it is currently unused. The IOCTL was using the data structure for
the DRM_TEGRA_OPEN_CHANNEL IOCTL.

Signed-off-by: Thierry Reding 
---
 include/uapi/drm/tegra_drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index d954f8c33321..99e15d82d1e9 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -193,7 +193,7 @@ struct drm_tegra_gem_get_flags {
 #define DRM_IOCTL_TEGRA_SYNCPT_INCR DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_SYNCPT_INCR, struct drm_tegra_syncpt_incr)
 #define DRM_IOCTL_TEGRA_SYNCPT_WAIT DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_SYNCPT_WAIT, struct drm_tegra_syncpt_wait)
 #define DRM_IOCTL_TEGRA_OPEN_CHANNEL DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_OPEN_CHANNEL, struct drm_tegra_open_channel)
-#define DRM_IOCTL_TEGRA_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_CLOSE_CHANNEL, struct drm_tegra_open_channel)
+#define DRM_IOCTL_TEGRA_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_CLOSE_CHANNEL, struct drm_tegra_close_channel)
 #define DRM_IOCTL_TEGRA_GET_SYNCPT DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GET_SYNCPT, struct drm_tegra_get_syncpt)
 #define DRM_IOCTL_TEGRA_SUBMIT DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_SUBMIT, 
struct drm_tegra_submit)
 #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
-- 
2.17.0

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

Re: [PATCH] drm/bridge: checkpatch strict minor updates

[Philippe CORNU]

Hi,
Applied on drm-misc-next.
Note: patch subject has been renamed "drm/bridge: spelling and coding 
style minor fixes" to comply with checkpatch (my bad ;-), hope it is 
better, Many thanks,
Philippe :-)

On 05/16/2018 11:43 AM, Daniel Vetter wrote:
> On Tue, May 15, 2018 at 10:37:36PM +0200, Philippe Cornu wrote:
>> Minor fixes detected with "scripts/checkpatch.pl --strict"
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>> Detected when merging "drm: clarify adjusted_mode documentation for bridges"
> 
> Acked-by: Daniel Vetter 
>>
>>   include/drm/drm_bridge.h | 10 +-
>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 9917651a7fdd..70131ab57e8f 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -97,7 +97,7 @@ struct drm_bridge_funcs {
>>  /**
>>   * @mode_fixup:
>>   *
>> - * This callback is used to validate and adjust a mode. The paramater
>> + * This callback is used to validate and adjust a mode. The parameter
>>   * mode is the display mode that should be fed to the next element in
>>   * the display chain, either the final _connector or the next
>>   * _bridge. The parameter adjusted_mode is the input mode the bridge
>> @@ -301,15 +301,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>> struct drm_bridge *bridge,
>>struct drm_bridge *previous);
>>   
>>   bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>> -const struct drm_display_mode *mode,
>> -struct drm_display_mode *adjusted_mode);
>> +   const struct drm_display_mode *mode,
>> +   struct drm_display_mode *adjusted_mode);
>>   enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
>> const struct drm_display_mode *mode);
>>   void drm_bridge_disable(struct drm_bridge *bridge);
>>   void drm_bridge_post_disable(struct drm_bridge *bridge);
>>   void drm_bridge_mode_set(struct drm_bridge *bridge,
>> -struct drm_display_mode *mode,
>> -struct drm_display_mode *adjusted_mode);
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode);
>>   void drm_bridge_pre_enable(struct drm_bridge *bridge);
>>   void drm_bridge_enable(struct drm_bridge *bridge);
>>   
>> -- 
>> 2.15.1
>>
>> ___
>> 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

[PATCH 5/7] gpu: host1x: Rename relocarray -> relocs for consistency

[Thierry Reding]

From: Thierry Reding 

All other array variables use a plural, and this is the only one using
the *array suffix. This is confusing, so rename it for consistency.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 4 ++--
 drivers/gpu/host1x/job.c| 8 
 include/linux/host1x.h  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e92e44e69871..f9d6c059792f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -418,13 +418,13 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct host1x_reloc *reloc;
struct tegra_bo *obj;
 
-   err = host1x_reloc_copy_from_user(>relocarray[num_relocs],
+   err = host1x_reloc_copy_from_user(>relocs[num_relocs],
  _relocs[num_relocs], drm,
  file);
if (err < 0)
goto fail;
 
-   reloc = >relocarray[num_relocs];
+   reloc = >relocs[num_relocs];
obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
refs[num_refs++] = >gem;
 
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 2be0bcaf8288..9d6d3e151291 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -60,7 +60,7 @@ struct host1x_job *host1x_job_alloc(struct host1x_channel *ch,
 
/* Redistribute memory to the structs  */
mem += sizeof(struct host1x_job);
-   job->relocarray = num_relocs ? mem : NULL;
+   job->relocs = num_relocs ? mem : NULL;
mem += num_relocs * sizeof(struct host1x_reloc);
job->unpins = num_unpins ? mem : NULL;
mem += num_unpins * sizeof(struct host1x_job_unpin_data);
@@ -115,7 +115,7 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
job->num_unpins = 0;
 
for (i = 0; i < job->num_relocs; i++) {
-   struct host1x_reloc *reloc = >relocarray[i];
+   struct host1x_reloc *reloc = >relocs[i];
struct sg_table *sgt;
dma_addr_t phys_addr;
 
@@ -203,7 +203,7 @@ static int do_relocs(struct host1x_job *job, struct 
host1x_job_gather *g)
 
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
-   struct host1x_reloc *reloc = >relocarray[i];
+   struct host1x_reloc *reloc = >relocs[i];
u32 reloc_addr = (job->reloc_addr_phys[i] +
  reloc->target.offset) >> reloc->shift;
u32 *target;
@@ -455,7 +455,7 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
 
fw.job = job;
fw.dev = dev;
-   fw.reloc = job->relocarray;
+   fw.reloc = job->relocs;
fw.num_relocs = job->num_relocs;
fw.class = job->class;
 
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 0632010f47fb..dcb6140d39d7 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -210,7 +210,7 @@ struct host1x_job {
unsigned int num_gathers;
 
/* Array of handles to be pinned & unpinned */
-   struct host1x_reloc *relocarray;
+   struct host1x_reloc *relocs;
unsigned int num_relocs;
struct host1x_job_unpin_data *unpins;
unsigned int num_unpins;
-- 
2.17.0

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

[PATCH 2/7] gpu: host1x: Store pointer to client in jobs

[Thierry Reding]

From: Thierry Reding 

Rather than storing some identifier derived from the application
context that can't be used concretely anywhere, store a pointer to the
client directly so that accesses can be made directly through that
client object.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 5 +++--
 drivers/gpu/host1x/cdma.c   | 2 +-
 drivers/gpu/host1x/cdma.h   | 2 +-
 include/linux/host1x.h  | 3 ++-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 33e479182773..e92e44e69871 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -317,6 +317,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 struct drm_tegra_submit *args, struct drm_device *drm,
 struct drm_file *file)
 {
+   struct host1x_client *client = >client->base;
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
struct drm_tegra_cmdbuf __user *user_cmdbufs;
@@ -348,8 +349,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
return -ENOMEM;
 
job->num_relocs = args->num_relocs;
-   job->client = (u32)args->context;
-   job->class = context->client->base.class;
+   job->client = client;
+   job->class = client->class;
job->serialize = true;
 
/*
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 28541b280739..cb590ba886ec 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -247,7 +247,7 @@ static void cdma_start_timer_locked(struct host1x_cdma 
*cdma,
 static void stop_cdma_timer_locked(struct host1x_cdma *cdma)
 {
cancel_delayed_work(>timeout.wq);
-   cdma->timeout.client = 0;
+   cdma->timeout.client = NULL;
 }
 
 /*
diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
index 286d49386be9..1825091bc0ed 100644
--- a/drivers/gpu/host1x/cdma.h
+++ b/drivers/gpu/host1x/cdma.h
@@ -58,7 +58,7 @@ struct buffer_timeout {
u32 syncpt_val; /* syncpt value when completed */
ktime_t start_ktime;/* starting time */
/* context timeout information */
-   int client;
+   struct host1x_client *client;
 };
 
 enum cdma_event {
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index f66bece1e1b7..0632010f47fb 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -202,7 +202,8 @@ struct host1x_job {
/* Channel where job is submitted to */
struct host1x_channel *channel;
 
-   u32 client;
+   /* client where the job originated */
+   struct host1x_client *client;
 
/* Gathers and their memory */
struct host1x_job_gather *gathers;
-- 
2.17.0

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

[PATCH 7/7] gpu: host1x: Track client version

[Thierry Reding]

From: Thierry Reding 

Userspace needs to know the version of the interface implemented by a
client so it can create the proper command streams. Allow individual
drivers to store this version along with the client so that it can be
returned to userspace upon opening a channel.

Signed-off-by: Thierry Reding 
---
 include/linux/host1x.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 89110d896d72..57d26406bdfd 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -49,6 +49,7 @@ struct host1x_client_ops {
  * @dev: pointer to struct device backing this host1x client
  * @ops: host1x client operations
  * @class: host1x class represented by this client
+ * @version: interface version implemented by this client
  * @channel: host1x channel associated with this client
  * @syncpts: array of syncpoints requested for this client
  * @num_syncpts: number of syncpoints requested for this client
@@ -61,6 +62,8 @@ struct host1x_client {
const struct host1x_client_ops *ops;
 
enum host1x_class class;
+   unsigned int version;
+
struct host1x_channel *channel;
 
struct host1x_syncpt **syncpts;
-- 
2.17.0

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

[PATCH 6/7] gpu: host1x: Use not explicitly sized types

[Thierry Reding]

From: Thierry Reding 

The number of words and the offset in a gather don't need to be
explicitly sized, so make them unsigned int instead.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/job.c | 13 -
 drivers/gpu/host1x/job.h |  4 ++--
 include/linux/host1x.h   |  4 ++--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 9d6d3e151291..1a8344dbdb2b 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -96,13 +96,16 @@ void host1x_job_put(struct host1x_job *job)
 EXPORT_SYMBOL(host1x_job_put);
 
 void host1x_job_add_gather(struct host1x_job *job, struct host1x_bo *bo,
-  u32 words, u32 offset)
+  unsigned int words, unsigned int offset)
 {
-   struct host1x_job_gather *cur_gather = >gathers[job->num_gathers];
+   struct host1x_job_gather *gather = >gathers[job->num_gathers];
+
+   WARN_ON(job->num_gathers >= job->num_cmdbufs);
+
+   gather->words = words;
+   gather->bo = bo;
+   gather->offset = offset;
 
-   cur_gather->words = words;
-   cur_gather->bo = bo;
-   cur_gather->offset = offset;
job->num_gathers++;
 }
 EXPORT_SYMBOL(host1x_job_add_gather);
diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
index 4bda51d503ec..188400e00192 100644
--- a/drivers/gpu/host1x/job.h
+++ b/drivers/gpu/host1x/job.h
@@ -20,10 +20,10 @@
 #define __HOST1X_JOB_H
 
 struct host1x_job_gather {
-   u32 words;
+   unsigned int words;
dma_addr_t base;
struct host1x_bo *bo;
-   u32 offset;
+   unsigned int offset;
bool handled;
 };
 
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index dcb6140d39d7..89110d896d72 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -251,8 +251,8 @@ struct host1x_job {
 
 struct host1x_job *host1x_job_alloc(struct host1x_channel *ch,
u32 num_cmdbufs, u32 num_relocs);
-void host1x_job_add_gather(struct host1x_job *job, struct host1x_bo *mem_id,
-  u32 words, u32 offset);
+void host1x_job_add_gather(struct host1x_job *job, struct host1x_bo *bo,
+  unsigned int words, unsigned int offset);
 struct host1x_job *host1x_job_get(struct host1x_job *job);
 void host1x_job_put(struct host1x_job *job);
 int host1x_job_pin(struct host1x_job *job, struct device *dev);
-- 
2.17.0

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

[PATCH 1/7] gpu: host1x: Remove wait check support

[Thierry Reding]

From: Thierry Reding 

The job submission userspace ABI doesn't support this and there are no
plans to implement it, so all of this code is dead and can be removed.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c|  62 +--
 drivers/gpu/host1x/dev.h   |   8 --
 drivers/gpu/host1x/hw/channel_hw.c |   3 +-
 drivers/gpu/host1x/hw/syncpt_hw.c  |  11 ---
 drivers/gpu/host1x/job.c   | 124 +
 drivers/gpu/host1x/syncpt.c|   6 --
 drivers/gpu/host1x/syncpt.h|   3 -
 include/linux/host1x.h |  15 +---
 include/trace/events/host1x.h  |  16 ++--
 9 files changed, 14 insertions(+), 234 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7afe2f635f74..33e479182773 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -313,46 +313,14 @@ static int host1x_reloc_copy_from_user(struct 
host1x_reloc *dest,
return 0;
 }
 
-static int host1x_waitchk_copy_from_user(struct host1x_waitchk *dest,
-struct drm_tegra_waitchk __user *src,
-struct drm_file *file)
-{
-   u32 cmdbuf;
-   int err;
-
-   err = get_user(cmdbuf, >handle);
-   if (err < 0)
-   return err;
-
-   err = get_user(dest->offset, >offset);
-   if (err < 0)
-   return err;
-
-   err = get_user(dest->syncpt_id, >syncpt);
-   if (err < 0)
-   return err;
-
-   err = get_user(dest->thresh, >thresh);
-   if (err < 0)
-   return err;
-
-   dest->bo = host1x_bo_lookup(file, cmdbuf);
-   if (!dest->bo)
-   return -ENOENT;
-
-   return 0;
-}
-
 int tegra_drm_submit(struct tegra_drm_context *context,
 struct drm_tegra_submit *args, struct drm_device *drm,
 struct drm_file *file)
 {
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 *user_cmdbufs;
struct drm_tegra_reloc __user *user_relocs;
-   struct drm_tegra_waitchk __user *user_waitchks;
struct drm_tegra_syncpt __user *user_syncpt;
struct drm_tegra_syncpt syncpt;
struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
@@ -364,7 +332,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
user_cmdbufs = u64_to_user_ptr(args->cmdbufs);
user_relocs = u64_to_user_ptr(args->relocs);
-   user_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 */
@@ -376,12 +343,11 @@ int tegra_drm_submit(struct tegra_drm_context *context,
return -EINVAL;
 
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
-  args->num_relocs, args->num_waitchks);
+  args->num_relocs);
if (!job)
return -ENOMEM;
 
job->num_relocs = args->num_relocs;
-   job->num_waitchk = args->num_waitchks;
job->client = (u32)args->context;
job->class = context->client->base.class;
job->serialize = true;
@@ -390,7 +356,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 * Track referenced BOs so that they can be unreferenced after the
 * submission is complete.
 */
-   num_refs = num_cmdbufs + num_relocs * 2 + num_waitchks;
+   num_refs = num_cmdbufs + num_relocs * 2;
 
refs = kmalloc_array(num_refs, sizeof(*refs), GFP_KERNEL);
if (!refs) {
@@ -481,30 +447,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,
}
}
 
-   /* copy and resolve waitchks from submit */
-   while (num_waitchks--) {
-   struct host1x_waitchk *wait = >waitchk[num_waitchks];
-   struct tegra_bo *obj;
-
-   err = host1x_waitchk_copy_from_user(
-   wait, _waitchks[num_waitchks], file);
-   if (err < 0)
-   goto fail;
-
-   obj = host1x_to_tegra_bo(wait->bo);
-   refs[num_refs++] = >gem;
-
-   /*
-* The unaligned offset will cause an unaligned write during
-* of the waitchks patching, corrupting the commands stream.
-*/
-   if (wait->offset & 3 ||
-   wait->offset >= obj->gem.size) {
-   err = -EINVAL;
-   goto fail;
-   }
-   }
-
if (copy_from_user(, user_syncpt, sizeof(syncpt))) {
err = -EFAULT;
goto fail;
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 

[PATCH 0/7] gpu: host1x: Preparation work for destaging ABI

[Thierry Reding]

From: Thierry Reding 

These couple of patches clean up some things in the host1x driver and
prepares the way for adding a revamped job submission ABI in a future
patch series.

The ultimate goal is to destage the job submission ABI, so that it is
enabled in default builds of the kernel (currently they are protected
by the STAGING option). The current staging ABI is no longer adequate
for existing use-cases, so we may want to remove it when destaging so
we don't have to keep maintaining it indefinitely. For now, the old
ABI will stick around at least until the new ABI is finalized.

Thierry

Thierry Reding (7):
  gpu: host1x: Remove wait check support
  gpu: host1x: Store pointer to client in jobs
  gpu: host1x: Cleanup loop variable usage
  gpu: host1x: Drop unnecessary host1x argument
  gpu: host1x: Rename relocarray -> relocs for consistency
  gpu: host1x: Use not explicitly sized types
  gpu: host1x: Track client version

 drivers/gpu/drm/tegra/drm.c|  71 ++
 drivers/gpu/host1x/cdma.c  |   2 +-
 drivers/gpu/host1x/cdma.h  |   2 +-
 drivers/gpu/host1x/debug.c |   2 +-
 drivers/gpu/host1x/dev.h   |   8 --
 drivers/gpu/host1x/hw/channel_hw.c |   5 +-
 drivers/gpu/host1x/hw/syncpt_hw.c  |  11 ---
 drivers/gpu/host1x/intr.c  |  16 ++--
 drivers/gpu/host1x/intr.h  |   8 +-
 drivers/gpu/host1x/job.c   | 149 -
 drivers/gpu/host1x/job.h   |   4 +-
 drivers/gpu/host1x/syncpt.c|  10 +-
 drivers/gpu/host1x/syncpt.h|   3 -
 include/linux/host1x.h |  27 ++
 include/trace/events/host1x.h  |  16 ++--
 15 files changed, 61 insertions(+), 273 deletions(-)

-- 
2.17.0

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

[PATCH 3/7] gpu: host1x: Cleanup loop variable usage

[Thierry Reding]

From: Thierry Reding 

Use unsigned int where possible and don't unnecessarily initialize the
loop variable.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/debug.c  | 2 +-
 drivers/gpu/host1x/intr.c   | 2 +-
 drivers/gpu/host1x/job.c| 4 ++--
 drivers/gpu/host1x/syncpt.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index dc77ec452ffc..329e4a3d8ae7 100644
--- a/drivers/gpu/host1x/debug.c
+++ b/drivers/gpu/host1x/debug.c
@@ -103,7 +103,7 @@ static void show_syncpts(struct host1x *m, struct output *o)
 
 static void show_all(struct host1x *m, struct output *o, bool show_fifo)
 {
-   int i;
+   unsigned int i;
 
host1x_hw_show_mlocks(m, o);
show_syncpts(m, o);
diff --git a/drivers/gpu/host1x/intr.c b/drivers/gpu/host1x/intr.c
index 8b4fad0ab35d..6028cf7b681f 100644
--- a/drivers/gpu/host1x/intr.c
+++ b/drivers/gpu/host1x/intr.c
@@ -144,7 +144,7 @@ static const action_handler 
action_handlers[HOST1X_INTR_ACTION_COUNT] = {
 static void run_handlers(struct list_head completed[HOST1X_INTR_ACTION_COUNT])
 {
struct list_head *head = completed;
-   int i;
+   unsigned int i;
 
for (i = 0; i < HOST1X_INTR_ACTION_COUNT; ++i, ++head) {
action_handler handler = action_handlers[i];
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 3cbfc6e37668..2be0bcaf8288 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -196,10 +196,10 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
 
 static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
-   int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
struct host1x_bo *cmdbuf = g->bo;
+   unsigned int i;
 
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -451,7 +451,7 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
struct host1x_firewall fw;
size_t size = 0;
size_t offset = 0;
-   int i;
+   unsigned int i;
 
fw.job = job;
fw.dev = dev;
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index a108669188e8..088c05dd884c 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -57,8 +57,8 @@ static struct host1x_syncpt *host1x_syncpt_alloc(struct 
host1x *host,
 struct host1x_client *client,
 unsigned long flags)
 {
-   int i;
struct host1x_syncpt *sp = host->syncpt;
+   unsigned int i;
char *name;
 
mutex_lock(>syncpt_mutex);
-- 
2.17.0

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

[PATCH 4/7] gpu: host1x: Drop unnecessary host1x argument

[Thierry Reding]

From: Thierry Reding 

Functions taking a pointer to a host1x syncpoint as an argument don't
need to specify a pointer to a host1x instance because it can be
obtained from the syncpoint.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/hw/channel_hw.c |  2 +-
 drivers/gpu/host1x/intr.c  | 14 ++
 drivers/gpu/host1x/intr.h  |  8 +---
 drivers/gpu/host1x/syncpt.c|  2 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index 4c9555038a95..d188f9068b91 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -164,7 +164,7 @@ static int channel_submit(struct host1x_job *job)
trace_host1x_channel_submitted(dev_name(ch->dev), prev_max, syncval);
 
/* schedule a submit complete interrupt */
-   err = host1x_intr_add_action(host, job->syncpt_id, syncval,
+   err = host1x_intr_add_action(host, sp, syncval,
 HOST1X_INTR_ACTION_SUBMIT_COMPLETE, ch,
 completed_waiter, NULL);
completed_waiter = NULL;
diff --git a/drivers/gpu/host1x/intr.c b/drivers/gpu/host1x/intr.c
index 6028cf7b681f..9629c009d10f 100644
--- a/drivers/gpu/host1x/intr.c
+++ b/drivers/gpu/host1x/intr.c
@@ -211,11 +211,11 @@ static void syncpt_thresh_work(struct work_struct *work)
host1x_syncpt_load(host->syncpt + id));
 }
 
-int host1x_intr_add_action(struct host1x *host, unsigned int id, u32 thresh,
-  enum host1x_intr_action action, void *data,
-  struct host1x_waitlist *waiter, void **ref)
+int host1x_intr_add_action(struct host1x *host, struct host1x_syncpt *syncpt,
+  u32 thresh, enum host1x_intr_action action,
+  void *data, struct host1x_waitlist *waiter,
+  void **ref)
 {
-   struct host1x_syncpt *syncpt;
int queue_was_empty;
 
if (waiter == NULL) {
@@ -234,19 +234,17 @@ int host1x_intr_add_action(struct host1x *host, unsigned 
int id, u32 thresh,
waiter->data = data;
waiter->count = 1;
 
-   syncpt = host->syncpt + id;
-
spin_lock(>intr.lock);
 
queue_was_empty = list_empty(>intr.wait_head);
 
if (add_waiter_to_queue(waiter, >intr.wait_head)) {
/* added at head of list - new threshold value */
-   host1x_hw_intr_set_syncpt_threshold(host, id, thresh);
+   host1x_hw_intr_set_syncpt_threshold(host, syncpt->id, thresh);
 
/* added as first waiter - enable interrupt */
if (queue_was_empty)
-   host1x_hw_intr_enable_syncpt_intr(host, id);
+   host1x_hw_intr_enable_syncpt_intr(host, syncpt->id);
}
 
spin_unlock(>intr.lock);
diff --git a/drivers/gpu/host1x/intr.h b/drivers/gpu/host1x/intr.h
index 1370c2bb75b8..6db96af484fe 100644
--- a/drivers/gpu/host1x/intr.h
+++ b/drivers/gpu/host1x/intr.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+struct host1x_syncpt;
 struct host1x;
 
 enum host1x_intr_action {
@@ -75,9 +76,10 @@ struct host1x_waitlist {
  *
  * This is a non-blocking api.
  */
-int host1x_intr_add_action(struct host1x *host, unsigned int id, u32 thresh,
-   enum host1x_intr_action action, void *data,
-   struct host1x_waitlist *waiter, void **ref);
+int host1x_intr_add_action(struct host1x *host, struct host1x_syncpt *syncpt,
+  u32 thresh, enum host1x_intr_action action,
+  void *data, struct host1x_waitlist *waiter,
+  void **ref);
 
 /*
  * Unreference an action submitted to host1x_intr_add_action().
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 088c05dd884c..a5dbf1ba4645 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -255,7 +255,7 @@ int host1x_syncpt_wait(struct host1x_syncpt *sp, u32 
thresh, long timeout,
}
 
/* schedule a wakeup when the syncpoint value is reached */
-   err = host1x_intr_add_action(sp->host, sp->id, thresh,
+   err = host1x_intr_add_action(sp->host, sp, thresh,
 HOST1X_INTR_ACTION_WAKEUP_INTERRUPTIBLE,
 , waiter, );
if (err)
-- 
2.17.0

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

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Andrey Grodzovsky]

Thanks Michel, will give it a try.

BTW, just out of interest, how the FDs are passed to clients ? Using 
sockets ? Can you point me to the code which does it ?


Andrey


On 05/17/2018 10:48 AM, Michel Dänzer wrote:

On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:

Hi Michele and others, I am trying to implement the approach bellow to
resolve AMDGPU's hang when commands are stuck in pipe during process exit.

I noticed that once I implemented the file_operation.flush callback
then during run of X, i see the flush callback gets called not only for
Xorg process but for other

processes such as 'xkbcomp' and even 'sh', it seems like Xorg passes his
FDs to children, Christian mentioned he remembered a discussion to
always set FD_CLOEXEC flag when opening the hardware device file, so

we suspect a bug in Xorg with regard to this behavior.

Try the libdrm patch below.

Note that the X server passes DRM file descriptors to DRI3 clients.


diff --git a/xf86drm.c b/xf86drm.c
index 3a9d0ed2..c09437b0 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -405,7 +405,7 @@ wait_for_udev:
  }
  #endif

-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
  drmMsg("drmOpenDevice: open result is %d, (%s)\n",
 fd, fd < 0 ? strerror(errno) : "OK");
  if (fd >= 0)
@@ -425,7 +425,7 @@ wait_for_udev:
  chmod(buf, devmode);
  }
  }
-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
  drmMsg("drmOpenDevice: open result is %d, (%s)\n",
 fd, fd < 0 ? strerror(errno) : "OK");
  if (fd >= 0)
@@ -474,7 +474,7 @@ static int drmOpenMinor(int minor, int create, int type)
  };

  sprintf(buf, dev_name, DRM_DIR_NAME, minor);
-if ((fd = open(buf, O_RDWR, 0)) >= 0)
+if ((fd = open(buf, O_RDWR | O_CLOEXEC, 0)) >= 0)
  return fd;
  return -errno;
  }





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

RE: linux-next: Signed-off-by missing for commits in the drm tree

[Koo, Anthony]

Hi Stephen,

Changes are Signed-off-by: Anthony Koo 

Thanks,
Anthony

-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au] 
Sent: Tuesday, May 15, 2018 7:19 PM
To: Dave Airlie ; DRI 
Cc: Linux-Next Mailing List ; Linux Kernel Mailing 
List ; Koo, Anthony ; 
Wentland, Harry ; Deucher, Alexander 

Subject: linux-next: Signed-off-by missing for commits in the drm tree

Hi all,

Commits

  f412e8307d0a ("drm/amd/display: Couple bug fixes in stats module")
  e09b6473c605 ("drm/amd/display: Rename encoder_info_packet to dc_info_packet")
  87943159f409 ("drm/amd/display: Only program MSA_TIMING_PARAM if it changed")

are missing a Signed-off-by from their author.

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

Re: [PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:38PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: David (ChunMing) Zhou 
> Cc: amd-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  6 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 36 
> +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 +--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
>  10 files changed, 40 insertions(+), 96 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:37PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: David (ChunMing) Zhou 
> Cc: amd-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 32 
> -
>  drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
>  drivers/gpu/drm/radeon/radeon_display.c | 30 ---
>  drivers/gpu/drm/radeon/radeon_fb.c  | 20 +-
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 +++---
>  drivers/gpu/drm/radeon/radeon_mode.h|  7 +--
>  6 files changed, 39 insertions(+), 67 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:36PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: David (ChunMing) Zhou 
> Cc: amd-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 10 +-
>  drivers/gpu/drm/radeon/radeon_device.c  |  4 ++--
>  drivers/gpu/drm/radeon/radeon_display.c | 31 
> +++--
>  drivers/gpu/drm/radeon/radeon_fb.c  |  8 
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 --
>  drivers/gpu/drm/radeon/radeon_mode.h|  1 -
>  6 files changed, 22 insertions(+), 43 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:35PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle function the same as the GEM framebuffer helper, we
> can reuse that.
> 
> Signed-off-by: Daniel Stone 
> Cc: Rob Clark 
> Cc: linux-arm-...@vger.kernel.org
> ---
>  drivers/gpu/drm/msm/msm_fb.c | 54 
> +---
>  1 file changed, 11 insertions(+), 43 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 20/24] drm/gma500: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:34PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Patrik Jakobsson 
> ---
>  drivers/gpu/drm/gma500/accel_2d.c  |  2 +-
>  drivers/gpu/drm/gma500/framebuffer.c   | 62 
> ++
>  drivers/gpu/drm/gma500/framebuffer.h   |  1 -
>  drivers/gpu/drm/gma500/gma_display.c   | 10 +++---
>  drivers/gpu/drm/gma500/gtt.h   |  2 ++
>  drivers/gpu/drm/gma500/oaktrail_crtc.c |  3 +-
>  6 files changed, 20 insertions(+), 60 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:33PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Russell King 
> ---
>  drivers/gpu/drm/armada/armada_fb.c | 23 ---
>  drivers/gpu/drm/armada/armada_fb.h |  3 +--
>  2 files changed, 5 insertions(+), 21 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
> 
> Signed-off-by: Daniel Stone 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 
> ---
>  1 file changed, 14 insertions(+), 26 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c| 38 
> +---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h|  1 -
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c |  4 ++--
>  3 files changed, 7 insertions(+), 36 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Peter Jones]

On Thu, May 17, 2018 at 09:22:23AM -0400, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
> 
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] 
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
> 
> When a VGA device is behind such a host bridge and the resource is
> translated efifb driver is trying to do ioremap against bus address
> rather than the resource address and is failing to probe.
> 
> efifb driver is having difficulty locating the base address from BAR
> address when
> 
> efifb: probing for efifb
> efifb: cannot reserve video memory at 0x1e00
> efifb: framebuffer at 0x1e00, using 1920k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> Use the host bridge offset information to convert bus address to
> resource address in the fixup.
> 
> Signed-off-by: Sinan Kaya 

Looks reasonable to me - Ard, do you want to take this up through the
EFI tree?

Signed-off-by: Peter Jones 

> ---
>  drivers/video/fbdev/efifb.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 46a4484..ea68d5c 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>  {
>   u64 base = screen_info.lfb_base;
>   u64 size = screen_info.lfb_size;
> + struct pci_bus_region region;
> + struct resource res;
>   int i;
>  
>   if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> @@ -439,6 +441,14 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>   if (!base)
>   return;
>  
> + region.start = base;
> + region.end = base + size - 1;
> + res.start = 0;
> + res.flags = IORESOURCE_MEM;
> + pcibios_bus_to_resource(dev->bus, , );
> + if (res.start)
> + base = res.start;
> +
>   for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
>   struct resource *res = >resource[i];
>  
> -- 
> 2.7.4
> 

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

Re: [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

[Thierry Reding]

On Thu, May 17, 2018 at 09:58:19AM -0400, Sean Paul wrote:
> On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote:
> > A FB with no object is something we should be shouting very loudly
> > about, not quietly logging as debug.
> > 
> > Signed-off-by: Daniel Stone 
> > Cc: CK Hu 
> > Cc: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index 2f4b0ffee598..ac010365d88b 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -95,10 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane 
> > *plane,
> > if (!fb)
> > return 0;
> >  
> > -   if (!mtk_fb_get_gem_obj(fb)) {
> > -   DRM_DEBUG_KMS("buffer is null\n");
> > -   return -EFAULT;
> > -   }
> > +   WARN_ON(!mtk_fb_get_gem_obj(fb));
> 
> We should presumably still bail out with an error, no?

I think we should just remove this WARN_ON(). Under what circumstances
would this case even happen? If the GEM object for a framebuffer doesn't
exist, then mtk_drm_mode_fb_create() will fail and no pointer to struct
drm_framebuffer will ever be returned. After that, the GEM object is
guaranteed to be there, so the above is effectively dead code.

Thierry


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

Re: [PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
> drm_framebuffer already holds per-plane pitch and offsets, which is
> filled out for us when we create the framebuffer. Nuke our local copy in
> the plane struct.
> 
> Signed-off-by: Daniel Stone 
> Cc: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_fb.c | 22 +-
>  1 file changed, 9 insertions(+), 13 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Michel Dänzer]

On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:
> Hi Michele and others, I am trying to implement the approach bellow to
> resolve AMDGPU's hang when commands are stuck in pipe during process exit.
> 
> I noticed that once I implemented the file_operation.flush callback 
> then during run of X, i see the flush callback gets called not only for
> Xorg process but for other
> 
> processes such as 'xkbcomp' and even 'sh', it seems like Xorg passes his
> FDs to children, Christian mentioned he remembered a discussion to
> always set FD_CLOEXEC flag when opening the hardware device file, so
> 
> we suspect a bug in Xorg with regard to this behavior.

Try the libdrm patch below.

Note that the X server passes DRM file descriptors to DRI3 clients.


diff --git a/xf86drm.c b/xf86drm.c
index 3a9d0ed2..c09437b0 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -405,7 +405,7 @@ wait_for_udev:
 }
 #endif

-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
 drmMsg("drmOpenDevice: open result is %d, (%s)\n",
fd, fd < 0 ? strerror(errno) : "OK");
 if (fd >= 0)
@@ -425,7 +425,7 @@ wait_for_udev:
 chmod(buf, devmode);
 }
 }
-fd = open(buf, O_RDWR, 0);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
 drmMsg("drmOpenDevice: open result is %d, (%s)\n",
fd, fd < 0 ? strerror(errno) : "OK");
 if (fd >= 0)
@@ -474,7 +474,7 @@ static int drmOpenMinor(int minor, int create, int type)
 };

 sprintf(buf, dev_name, DRM_DIR_NAME, minor);
-if ((fd = open(buf, O_RDWR, 0)) >= 0)
+if ((fd = open(buf, O_RDWR | O_CLOEXEC, 0)) >= 0)
 return fd;
 return -errno;
 }



-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/24] drm/omap: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:20PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_fb.c | 60 
> ++-
>  1 file changed, 15 insertions(+), 45 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Sandy Huang 
> Cc: Heiko Stübner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 36 
> +-
>  1 file changed, 6 insertions(+), 30 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
> 
> Signed-off-by: Daniel Stone 
> Cc: Sandy Huang 
> Cc: Heiko Stübner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 54 
> ++---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.h  |  3 --
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
>  3 files changed, 21 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index d7083c07c294..a4d0a00abcd9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -25,21 +25,6 @@
>  #include "rockchip_drm_gem.h"
>  #include "rockchip_drm_psr.h"
>  
> -#define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
> -
> -struct rockchip_drm_fb {
> - struct drm_framebuffer fb;
> -};
> -
> -struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
> -unsigned int plane)
> -{
> - if (plane >= ROCKCHIP_MAX_FB_BUFFER)
> - return NULL;
> -
> - return fb->obj[plane];
> -}
> -
>  static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>struct drm_file *file,
>unsigned int flags, unsigned int color,
> @@ -56,41 +41,40 @@ static const struct drm_framebuffer_funcs 
> rockchip_drm_fb_funcs = {
>   .dirty = rockchip_drm_fb_dirty,
>  };
>  
> -static struct rockchip_drm_fb *
> +static struct drm_framebuffer *
>  rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 
> *mode_cmd,
> struct drm_gem_object **obj, unsigned int num_planes)
>  {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
>   int ret;
>   int i;
>  
> - rockchip_fb = kzalloc(sizeof(*rockchip_fb), GFP_KERNEL);
> - if (!rockchip_fb)
> + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (!fb)
>   return ERR_PTR(-ENOMEM);
>  
> - drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
> + drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
>  
>   for (i = 0; i < num_planes; i++)
> - rockchip_fb->fb.obj[i] = obj[i];
> + fb->obj[i] = obj[i];
>  
> - ret = drm_framebuffer_init(dev, _fb->fb,
> -_drm_fb_funcs);
> + ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
>   if (ret) {
>   DRM_DEV_ERROR(dev->dev,
> "Failed to initialize framebuffer: %d\n",
> ret);
> - kfree(rockchip_fb);
> + kfree(fb);
>   return ERR_PTR(ret);
>   }
>  
> - return rockchip_fb;
> + return fb;
>  }
>  
>  static struct drm_framebuffer *
>  rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
>   const struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
>   struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];

The use of the ROCKCHIP_MAX_FB_BUFFER seems somewhat misguided here.
What if a given pixel format requires 4 planes? This function will just
silently ignore the last plane. Not sure that's a good idea. Currently I
don't know of any formats that require 4 planes, so this is probably not
an issue, but there's also no reason to limit this to anything less than
the 4 planes that's baked into the KMS ABI everywhere.

Anyway, just a random comment and it doesn't have anything to do with
this series, so:

Reviewed-by: Thierry Reding 


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

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

[bugzilla-daemon]

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

Joonas Lahtinen  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Joonas Lahtinen  ---
What exactly is being reported here? If there's a regression after a kernel
update, please provide a bisect between last known good and drm-tip.

There's nothing MDAPI related in the kernel and you're not specifying any link
to the testing suite, so this bug report is hardly useful.

Providing a dmesg with debug options from running just the failing subtest
would be a good start to guess something.

For proper bug reporting, please see:

https://01.org/linuxgraphics/documentation/how-report-bugs

-- 
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/vc4: Define a DRM format modifier for SAND tiling.

[Eric Anholt]

From: Dave Stevenson 

This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well.  By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.

Signed-off-by: Dave Stevenson 
Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Boris Brezillon 
Cc: Maxime Ripard 
---

I've separated this out from the display patch.  The vc4 display side
is waiting for the necessary i915 patch, which seems to be stuck.  We
really want to be using SAND for v4l2 decode into Mesa, even if we
can't get display, so if we can land this then at least I can go write
that.

 include/uapi/drm/drm_fourcc.h | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..64bf67abff7e 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -384,6 +384,23 @@ extern "C" {
 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
fourcc_mod_code(NVIDIA, 0x15)
 
+/*
+ * Some Broadcom modifiers take parameters, for example the number of
+ * vertical lines in the image. Reserve the lower 32 bits for modifier
+ * type, and the next 24 bits for parameters. Top 8 bits are the
+ * vendor code.
+ */
+#define __fourcc_mod_broadcom_param_shift 8
+#define __fourcc_mod_broadcom_param_bits 48
+#define fourcc_mod_broadcom_code(val, params) \
+   fourcc_mod_code(BROADCOM, __u64)params) << 
__fourcc_mod_broadcom_param_shift) | val))
+#define fourcc_mod_broadcom_param(m) \
+   ((int)(((m) >> __fourcc_mod_broadcom_param_shift) & \
+  ((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
+#define fourcc_mod_broadcom_mod(m) \
+   ((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) <<\
+__fourcc_mod_broadcom_param_shift))
+
 /*
  * Broadcom VC4 "T" format
  *
@@ -405,6 +422,48 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
 
+/*
+ * Broadcom SAND format
+ *
+ * This is the native format that the H.264 codec block uses.  For VC4
+ * HVS, it is only valid for H.264 (NV12/21) and RGBA modes.
+ *
+ * The image can be considered to be split into columns, and the
+ * columns are placed consecutively into memory.  The width of those
+ * columns can be either 32, 64, 128, or 256 pixels, but in practice
+ * only 128 pixel columns are used.
+ *
+ * The pitch between the start of each column is set to optimally
+ * switch between SDRAM banks. This is passed as the number of lines
+ * of column width in the modifier (we can't use the stride value due
+ * to various core checks that look at it , so you should set the
+ * stride to width*cpp).
+ *
+ * Note that the column height for this format modifier is the same
+ * for all of the planes, assuming that each column contains both Y
+ * and UV.  Some SAND-using hardware stores UV in a separate tiled
+ * image from Y to reduce the column height, which is not supported
+ * with these modifiers.
+ */
+
+#define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
+   fourcc_mod_broadcom_code(2, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(v) \
+   fourcc_mod_broadcom_code(3, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(v) \
+   fourcc_mod_broadcom_code(4, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(v) \
+   fourcc_mod_broadcom_code(5, v)
+
+#define DRM_FORMAT_MOD_BROADCOM_SAND32 \
+   DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND64 \
+   DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND128 \
+   DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND256 \
+   DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.17.0

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

Re: [PATCH v2] drm/vc4: plane: Expand the lower bits by repeating the higher bits

[Eric Anholt]

Maxime Ripard  writes:

> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
> pixman that fill the missing bits by repeating the higher significant bits.
> As such, we can't check the display output in a reliable way by doing a
> software composition and an hardware one and compare both.
>
> To prevent this, force the same behaviour so that we can do such things.

Pushed to drm-misc-next.  Thanks!


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

Re: [PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:17PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 30 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h |  1 -
>  drivers/gpu/drm/virtio/virtgpu_fb.c  |  8 
>  drivers/gpu/drm/virtio/virtgpu_plane.c   |  4 ++--
>  4 files changed, 11 insertions(+), 32 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 02/24] drm/cirrus: cirrus_framebuffer -> drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:16PM +0100, Daniel Stone wrote:
> Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
> we can drop it.
> 
> Signed-off-by: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.h   |  9 ++---
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 20 ++--
>  drivers/gpu/drm/cirrus/cirrus_main.c  | 20 ++--
>  drivers/gpu/drm/cirrus/cirrus_mode.c  | 12 +++-
>  4 files changed, 25 insertions(+), 36 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Daniel Stone]

Hi Heiko,

On 17 May 2018 at 14:42, Heiko Stübner  wrote:
> Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone:
>> On 30 March 2018 at 15:11, Daniel Stone  wrote:
>> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
>> > can remove it.
>> >
>> > Signed-off-by: Daniel Stone 
>> > Cc: Sandy Huang 
>> > Cc: Heiko Stübner 
>>
>> Ping?
>
> I only see the cover-letter (not listing all patches of the series)
> plus patches 4+5 of the series, nothing else.
>
> Both patches seem to reference other previous patches (1-3?)
> so could you point me at mboxes [patchwork] for those?

The series is available at:
https://patchwork.freedesktop.org/series/40944/

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

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

[Sean Paul]

On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
> 
> Signed-off-by: Daniel Stone 
> Cc: CK Hu 
> Cc: Philipp Zabel 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 
> ---
>  1 file changed, 14 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> index f130e37123b5..be5f6f1daf55 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> @@ -23,49 +23,37 @@
>  #include "mtk_drm_fb.h"
>  #include "mtk_drm_gem.h"
>  
> -/*
> - * mtk specific framebuffer structure.
> - *
> - * @fb: drm framebuffer object.
> - * @gem_obj: array of gem objects.
> - */
> -struct mtk_drm_fb {
> - struct drm_framebuffer  base;
> -};
> -
> -#define to_mtk_fb(x) container_of(x, struct mtk_drm_fb, base)
> -
>  static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
>   .create_handle = drm_gem_fb_create_handle,
>   .destroy = drm_gem_fb_destroy,
>  };
>  
> -static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct drm_device *dev,
> +static struct drm_framebuffer *mtk_drm_framebuffer_init(struct drm_device 
> *dev,
>   const struct drm_mode_fb_cmd2 *mode,
>   struct drm_gem_object *obj)
>  {
> - struct mtk_drm_fb *mtk_fb;
> + struct drm_framebuffer *fb;
>   int ret;
>  
>   if (drm_format_num_planes(mode->pixel_format) != 1)
>   return ERR_PTR(-EINVAL);
>  
> - mtk_fb = kzalloc(sizeof(*mtk_fb), GFP_KERNEL);
> - if (!mtk_fb)
> + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (!fb)
>   return ERR_PTR(-ENOMEM);
>  
> - drm_helper_mode_fill_fb_struct(dev, _fb->base, mode);
> + drm_helper_mode_fill_fb_struct(dev, fb, mode);
>  
> - mtk_fb->base.obj[0] = obj;
> + fb->obj[0] = obj;
>  
> - ret = drm_framebuffer_init(dev, _fb->base, _drm_fb_funcs);
> + ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
>   if (ret) {
>   DRM_ERROR("failed to initialize framebuffer\n");
> - kfree(mtk_fb);
> + kfree(fb);
>   return ERR_PTR(ret);
>   }
>  
> - return mtk_fb;
> + return fb;
>  }
>  
>  /*
> @@ -100,7 +88,7 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct 
> drm_device *dev,
>  struct drm_file *file,
>  const struct drm_mode_fb_cmd2 
> *cmd)
>  {
> - struct mtk_drm_fb *mtk_fb;
> + struct drm_framebuffer *fb;
>   struct drm_gem_object *gem;
>   unsigned int width = cmd->width;
>   unsigned int height = cmd->height;
> @@ -123,13 +111,13 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct 
> drm_device *dev,
>   goto unreference;
>   }
>  
> - mtk_fb = mtk_drm_framebuffer_init(dev, cmd, gem);
> - if (IS_ERR(mtk_fb)) {
> - ret = PTR_ERR(mtk_fb);
> + fb = mtk_drm_framebuffer_init(dev, cmd, gem);
> + if (IS_ERR(fb)) {
> + ret = PTR_ERR(fb);
>   goto unreference;
>   }
>  
> - return _fb->base;
> + return fb;
>  
>  unreference:
>   drm_gem_object_put_unlocked(gem);
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

[Sean Paul]

On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 

Reviewed-by: Sean Paul 

> Cc: CK Hu 
> Cc: Philipp Zabel 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c| 38 
> +---
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h|  1 -
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c |  4 ++--
>  3 files changed, 7 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> index 0d8d506695f9..f130e37123b5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -30,42 +31,13 @@
>   */
>  struct mtk_drm_fb {
>   struct drm_framebuffer  base;
> - /* For now we only support a single plane */
> - struct drm_gem_object   *gem_obj;
>  };
>  
>  #define to_mtk_fb(x) container_of(x, struct mtk_drm_fb, base)
>  
> -struct drm_gem_object *mtk_fb_get_gem_obj(struct drm_framebuffer *fb)
> -{
> - struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
> -
> - return mtk_fb->gem_obj;
> -}
> -
> -static int mtk_drm_fb_create_handle(struct drm_framebuffer *fb,
> - struct drm_file *file_priv,
> - unsigned int *handle)
> -{
> - struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
> -
> - return drm_gem_handle_create(file_priv, mtk_fb->gem_obj, handle);
> -}
> -
> -static void mtk_drm_fb_destroy(struct drm_framebuffer *fb)
> -{
> - struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
> -
> - drm_framebuffer_cleanup(fb);
> -
> - drm_gem_object_put_unlocked(mtk_fb->gem_obj);
> -
> - kfree(mtk_fb);
> -}
> -
>  static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
> - .create_handle = mtk_drm_fb_create_handle,
> - .destroy = mtk_drm_fb_destroy,
> + .create_handle = drm_gem_fb_create_handle,
> + .destroy = drm_gem_fb_destroy,
>  };
>  
>  static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct drm_device *dev,
> @@ -84,7 +56,7 @@ static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct 
> drm_device *dev,
>  
>   drm_helper_mode_fill_fb_struct(dev, _fb->base, mode);
>  
> - mtk_fb->gem_obj = obj;
> + mtk_fb->base.obj[0] = obj;
>  
>   ret = drm_framebuffer_init(dev, _fb->base, _drm_fb_funcs);
>   if (ret) {
> @@ -110,7 +82,7 @@ int mtk_fb_wait(struct drm_framebuffer *fb)
>   if (!fb)
>   return 0;
>  
> - gem = mtk_fb_get_gem_obj(fb);
> + gem = fb->obj[0];
>   if (!gem || !gem->dma_buf || !gem->dma_buf->resv)
>   return 0;
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> index 9b2ae345a4e9..7f976b196a15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> @@ -14,7 +14,6 @@
>  #ifndef MTK_DRM_FB_H
>  #define MTK_DRM_FB_H
>  
> -struct drm_gem_object *mtk_fb_get_gem_obj(struct drm_framebuffer *fb);
>  int mtk_fb_wait(struct drm_framebuffer *fb);
>  struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
>  struct drm_file *file,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index ac010365d88b..5370f926e63d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -95,7 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
>   if (!fb)
>   return 0;
>  
> - WARN_ON(!mtk_fb_get_gem_obj(fb));
> + WARN_ON(!fb->obj[0]);
>  
>   if (!state->crtc)
>   return 0;
> @@ -124,7 +124,7 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
>   if (!crtc || WARN_ON(!fb))
>   return;
>  
> - gem = mtk_fb_get_gem_obj(fb);
> + gem = fb->obj[0];
>   mtk_gem = to_mtk_gem_obj(gem);
>   addr = mtk_gem->dma_addr;
>   pitch = fb->pitches[0];
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

[Sean Paul]

On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote:
> A FB with no object is something we should be shouting very loudly
> about, not quietly logging as debug.
> 
> Signed-off-by: Daniel Stone 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 2f4b0ffee598..ac010365d88b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -95,10 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
>   if (!fb)
>   return 0;
>  
> - if (!mtk_fb_get_gem_obj(fb)) {
> - DRM_DEBUG_KMS("buffer is null\n");
> - return -EFAULT;
> - }
> + WARN_ON(!mtk_fb_get_gem_obj(fb));

We should presumably still bail out with an error, no?

>  
>   if (!state->crtc)
>   return 0;
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

[Sean Paul]

On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 

Reviewed-by: Sean Paul 

> Cc: Sandy Huang 
> Cc: Heiko Stübner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 36 
> +-
>  1 file changed, 6 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index e266539e04e5..d7083c07c294 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_fb.h"
> @@ -28,40 +29,15 @@
>  
>  struct rockchip_drm_fb {
>   struct drm_framebuffer fb;
> - struct drm_gem_object *obj[ROCKCHIP_MAX_FB_BUFFER];
>  };
>  
>  struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
>  unsigned int plane)
>  {
> - struct rockchip_drm_fb *rk_fb = to_rockchip_fb(fb);
> -
>   if (plane >= ROCKCHIP_MAX_FB_BUFFER)
>   return NULL;
>  
> - return rk_fb->obj[plane];
> -}
> -
> -static void rockchip_drm_fb_destroy(struct drm_framebuffer *fb)
> -{
> - struct rockchip_drm_fb *rockchip_fb = to_rockchip_fb(fb);
> - int i;
> -
> - for (i = 0; i < ROCKCHIP_MAX_FB_BUFFER; i++)
> - drm_gem_object_put_unlocked(rockchip_fb->obj[i]);
> -
> - drm_framebuffer_cleanup(fb);
> - kfree(rockchip_fb);
> -}
> -
> -static int rockchip_drm_fb_create_handle(struct drm_framebuffer *fb,
> -  struct drm_file *file_priv,
> -  unsigned int *handle)
> -{
> - struct rockchip_drm_fb *rockchip_fb = to_rockchip_fb(fb);
> -
> - return drm_gem_handle_create(file_priv,
> -  rockchip_fb->obj[0], handle);
> + return fb->obj[plane];
>  }
>  
>  static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
> @@ -75,9 +51,9 @@ static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>  }
>  
>  static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> - .destroy= rockchip_drm_fb_destroy,
> - .create_handle  = rockchip_drm_fb_create_handle,
> - .dirty  = rockchip_drm_fb_dirty,
> + .destroy   = drm_gem_fb_destroy,
> + .create_handle = drm_gem_fb_create_handle,
> + .dirty = rockchip_drm_fb_dirty,
>  };
>  
>  static struct rockchip_drm_fb *
> @@ -95,7 +71,7 @@ rockchip_fb_alloc(struct drm_device *dev, const struct 
> drm_mode_fb_cmd2 *mode_cm
>   drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
>  
>   for (i = 0; i < num_planes; i++)
> - rockchip_fb->obj[i] = obj[i];
> + rockchip_fb->fb.obj[i] = obj[i];
>  
>   ret = drm_framebuffer_init(dev, _fb->fb,
>  _drm_fb_funcs);
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Sean Paul]

On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
> 
> Signed-off-by: Daniel Stone 

Reviewed-by: Sean Paul 

> Cc: Sandy Huang 
> Cc: Heiko Stübner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 54 
> ++---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.h  |  3 --
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
>  3 files changed, 21 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index d7083c07c294..a4d0a00abcd9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -25,21 +25,6 @@
>  #include "rockchip_drm_gem.h"
>  #include "rockchip_drm_psr.h"
>  
> -#define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
> -
> -struct rockchip_drm_fb {
> - struct drm_framebuffer fb;
> -};
> -
> -struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
> -unsigned int plane)
> -{
> - if (plane >= ROCKCHIP_MAX_FB_BUFFER)
> - return NULL;
> -
> - return fb->obj[plane];
> -}
> -
>  static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>struct drm_file *file,
>unsigned int flags, unsigned int color,
> @@ -56,41 +41,40 @@ static const struct drm_framebuffer_funcs 
> rockchip_drm_fb_funcs = {
>   .dirty = rockchip_drm_fb_dirty,
>  };
>  
> -static struct rockchip_drm_fb *
> +static struct drm_framebuffer *
>  rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 
> *mode_cmd,
> struct drm_gem_object **obj, unsigned int num_planes)
>  {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
>   int ret;
>   int i;
>  
> - rockchip_fb = kzalloc(sizeof(*rockchip_fb), GFP_KERNEL);
> - if (!rockchip_fb)
> + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (!fb)
>   return ERR_PTR(-ENOMEM);
>  
> - drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
> + drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
>  
>   for (i = 0; i < num_planes; i++)
> - rockchip_fb->fb.obj[i] = obj[i];
> + fb->obj[i] = obj[i];
>  
> - ret = drm_framebuffer_init(dev, _fb->fb,
> -_drm_fb_funcs);
> + ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
>   if (ret) {
>   DRM_DEV_ERROR(dev->dev,
> "Failed to initialize framebuffer: %d\n",
> ret);
> - kfree(rockchip_fb);
> + kfree(fb);
>   return ERR_PTR(ret);
>   }
>  
> - return rockchip_fb;
> + return fb;
>  }
>  
>  static struct drm_framebuffer *
>  rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
>   const struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
>   struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
>   struct drm_gem_object *obj;
>   unsigned int hsub;
> @@ -129,13 +113,13 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
> drm_file *file_priv,
>   objs[i] = obj;
>   }
>  
> - rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
> - if (IS_ERR(rockchip_fb)) {
> - ret = PTR_ERR(rockchip_fb);
> + fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
> + if (IS_ERR(fb)) {
> + ret = PTR_ERR(fb);
>   goto err_gem_object_unreference;
>   }
>  
> - return _fb->fb;
> + return fb;
>  
>  err_gem_object_unreference:
>   for (i--; i >= 0; i--)
> @@ -159,13 +143,13 @@ rockchip_drm_framebuffer_init(struct drm_device *dev,
> const struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj)
>  {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
>  
> - rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, , 1);
> - if (IS_ERR(rockchip_fb))
> - return ERR_CAST(rockchip_fb);
> + fb = rockchip_fb_alloc(dev, mode_cmd, , 1);
> + if (IS_ERR(fb))
> + return ERR_CAST(fb);
>  
> - return _fb->fb;
> + return fb;
>  }
>  
>  void rockchip_drm_mode_config_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
> index 2fe47f1ee98f..f1265cb1aee8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
> @@ -22,7 +22,4 @@ rockchip_drm_framebuffer_init(struct drm_device *dev,
>  void 

Re: [PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:15PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.h   |  1 -
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  8 
>  drivers/gpu/drm/cirrus/cirrus_main.c  | 25 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c  |  4 ++--
>  4 files changed, 10 insertions(+), 28 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

[Sean Paul]

On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
> follow Sean suggest
> Changes in v5:
> - fix some whitespcae issue
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 505 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> 
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> + cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..d9d0d4d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>   }
> -
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> +   "Failed to idle video %d\n", ret);
> + goto out;
> + }
>   }
>  
>   ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>  
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to valid video %d\n", ret);
> + goto out;
> + }
>   }
> +
>  out:
>   mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
>   bool connected;
>   bool active;
>   bool suspended;
> + bool use_fw_training;
>  
>   const struct firmware *fw;  /* cdn dp firmware */
>   unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
>   u8 ports;
>   u8 lanes;
>   int active_port;
> + u8 train_set[4];
>  
>   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>   bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..73c3290
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

Re: [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

[Thierry Reding]

On Thu, May 17, 2018 at 02:11:16PM +0100, Daniel Stone wrote:
> Hi Thierry,
> 
> On 30 March 2018 at 15:11, Daniel Stone  wrote:
> > Since tegra_fb is now the same as drm_framebuffer, we can just replace
> > the type completely.
> >
> > Signed-off-by: Daniel Stone 
> > Cc: Thierry Reding 
> > Cc: linux-te...@vger.kernel.org
> 
> Did this still need some more testing, or is it OK to apply?

Sorry, this completely fell off the table. I've tested patches 11-15 and
they work fine. Applied all of them to drm/tegra/for-next.

Thanks,
Thierry


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

[bug report] drm/amd/pp: Change voltage/clk range for OD feature on VI

[Dan Carpenter]

Hello Rex Zhu,

The patch d389d607e608: "drm/amd/pp: Change voltage/clk range for OD
feature on VI" from Apr 18, 2018, leads to the following static
checker warning:

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872 
smu7_setup_voltage_range_from_vbios()
error: uninitialized symbol 'min_vddc'.

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
   857  static void smu7_setup_voltage_range_from_vbios(struct pp_hwmgr *hwmgr)
   858  {
   859  struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
   860  struct phm_ppt_v1_clock_voltage_dependency_table 
*dep_sclk_table;
   861  struct phm_ppt_v1_information *table_info =
   862  (struct phm_ppt_v1_information 
*)(hwmgr->pptable);
   863  uint32_t min_vddc, max_vddc;
   864  
   865  if (!table_info)
   866  return;
   867  
   868  dep_sclk_table = table_info->vdd_dep_on_sclk;
   869  
   870  atomctrl_get_voltage_range(hwmgr, _vddc, _vddc);

This doesn't necessarily initialize the parameters.

   871  
   872  if (min_vddc == 0 || min_vddc > 2000
   873  || min_vddc > dep_sclk_table->entries[0].vddc)
   874  min_vddc = dep_sclk_table->entries[0].vddc;
   875  
   876  if (max_vddc == 0 || max_vddc > 2000
   877  || max_vddc < 
dep_sclk_table->entries[dep_sclk_table->count-1].vddc)
   878  max_vddc = 
dep_sclk_table->entries[dep_sclk_table->count-1].vddc;
   879  
   880  data->odn_dpm_table.min_vddc = min_vddc;
   881  data->odn_dpm_table.max_vddc = max_vddc;
   882  }

See also:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872 
smu7_setup_voltage_range_from_vbios() error: uninitialized symbol 'min_vddc'.
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:876 
smu7_setup_voltage_range_from_vbios() error: uninitialized symbol 'max_vddc'.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1588 
vegam_populate_clock_stretcher_data_table() error: uninitialized symbol 'efuse'.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1725 
vegam_populate_avfs_parameters() error: uninitialized symbol 'tmp'.


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

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Heiko Stübner]

Hi Daniel,

Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone:
> On 30 March 2018 at 15:11, Daniel Stone  wrote:
> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> > can remove it.
> > 
> > Signed-off-by: Daniel Stone 
> > Cc: Sandy Huang 
> > Cc: Heiko Stübner 
> 
> Ping?

I only see the cover-letter (not listing all patches of the series)
plus patches 4+5 of the series, nothing else.

Both patches seem to reference other previous patches (1-3?)
so could you point me at mboxes [patchwork] for those?


Thanks
Heiko


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

Re: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

[Ramalingam C]

On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

Implements the link integrity check once in 500mSec.

Once encryption is enabled, an ongoing Link Integrity Check is performed by the
HDCP Receiver to check that cipher synchronization is maintained between the
HDCP Transmitter and the HDCP Receiver.

On the detection of synchronization lost, the HDCP Receiver must assert the
corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
register and it may initiate re-authentication.

v2:
  Rebased.
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_hdcp.c | 81
++-
include/drm/drm_hdcp.h|  8 
2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 005627746ca5..e2aec73aefe3 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -23,6 +23,8 @@

static int _intel_hdcp2_enable(struct intel_connector *connector);  static int
_intel_hdcp2_disable(struct intel_connector *connector);
+static void intel_hdcp2_check_work(struct work_struct *work); static
+int intel_hdcp2_check_link(struct intel_connector *connector);

static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim) @@ -
1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector)

hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
schedule_work(>hdcp_prop_work);
-
+   schedule_delayed_work(>hdcp2_check_work,
+ DRM_HDCP2_CHECK_PERIOD_MS);
return 0;
}
+
+static int intel_hdcp2_check_link(struct intel_connector *connector) {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret = 0;
+
+   if (!hdcp->hdcp_shim)
+   return -ENOENT;
+
+   mutex_lock(>hdcp_mutex);
+
+   if (hdcp->hdcp_value ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS)) {
+   DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
+  I915_READ(HDCP2_STATUS_DDI(port)));
+   ret = -ENXIO;
+   hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>hdcp_prop_work);
+   goto out;
+   }
+
+   ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);

Check " hdcp->hdcp_shim->check_2_2_link " for NULL.
check_2_2_link is essential func ptr. Dont think it will be good to 
check on each loop.

Wondering if I need to check for the essential func ptr at init itself.

--Ram



+   if (!ret) {
Here actually we are comparing the ret == DRM_HDCP_LINK_PROTECTED 
indirectly here.
I will make it explicit, hence we can have the enum definition at this 
patch itself.

+   if (hdcp->hdcp_value !=
DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>hdcp_prop_work);
+   }
+   goto out;
+   }
+
+   DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
+connector->base.name, connector->base.base.id);
+
+   ret = _intel_hdcp2_disable(connector);
+   if (ret) {
+   DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+
+   hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>hdcp_prop_work);
+   goto out;
+   }
+
+   ret = _intel_hdcp2_enable(connector);
+   if (ret) {
+   DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+
+   hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>hdcp_prop_work);
+   goto out;
+   }
+
+out:
+   mutex_unlock(>hdcp_mutex);
+   return ret;
+}
+
+static void intel_hdcp2_check_work(struct work_struct *work) {
+   

[PATCH v2] drm/vc4: plane: Expand the lower bits by repeating the higher bits

[Maxime Ripard]

The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.

This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we can't check the display output in a reliable way by doing a
software composition and an hardware one and compare both.

To prevent this, force the same behaviour so that we can do such things.

Signed-off-by: Maxime Ripard 
---
Changes from v1:
  - Change the pattern
  - Rebase on top of drm-misc-next and use the defines newly introduced

 drivers/gpu/drm/vc4/vc4_plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 3483c05cc3d6..6e8984aee613 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -544,6 +544,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
/* Control word */
vc4_dlist_write(vc4_state,
SCALER_CTL0_VALID |
+   VC4_SET_FIELD(SCALER_CTL0_RGBA_EXPAND_ROUND, 
SCALER_CTL0_RGBA_EXPAND) |
(format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
(format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |
-- 
2.17.0

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

[bug report] drm/exynos: Add driver for Exynos Scaler module

[Dan Carpenter]

Hello Andrzej Pietrasiewicz,

The patch 01fb9185dc18: "drm/exynos: Add driver for Exynos Scaler
module" from May 9, 2018, leads to the following static checker
warning:

drivers/gpu/drm/exynos/exynos_drm_scaler.c:402 scaler_task_done()
warn: signedness bug returning '(-22)'

drivers/gpu/drm/exynos/exynos_drm_scaler.c
   399  
   400  static inline bool scaler_task_done(u32 val)
   401  {
   402  return val & SCALER_INT_STATUS_FRAME_END ? 0 : -EINVAL;
   ^^^
   403  }
   404  

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

Re: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

[Ramalingam C]

On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

May be calling enable/disable sequence separately will be better :)


Implements a sequence of enabling and disabling the HDCP2.2 (auth and
encryption).

v2:
  Rebased.
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_hdcp.c | 75
+++
1 file changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 91cac643f083..005627746ca5 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -21,6 +21,9 @@
#define HDCP2_LC_RETRY_CNT  3
#define TIME_FOR_ENCRYPT_STATUS_CHANGE  32

+static int _intel_hdcp2_enable(struct intel_connector *connector);
+static int _intel_hdcp2_disable(struct intel_connector *connector);
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)  { @@ -
1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct intel_connector
*connector)

return ret;
}
+
+static int hdcp2_authenticate_and_encrypt(struct intel_connector
+*connector) {
+   int ret, i, tries = 3;
+
+   for (i = 0; i < tries; i++) {
+   ret = hdcp2_authenticate_sink(connector);
+   if (!ret)
+   break;
+
+   /* Clearing the mei hdcp session */
+   hdcp2_deauthenticate_port(>hdcp);
+   DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
+ i + 1, tries, ret);
+   }
+
+   if (i != tries) {
+
+   /*
+* Ensuring the required 200mSec min time interval between
+* Session Key Exchange and encryption.
+*/
+   msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
+   ret = hdcp2_enable_encryption(connector);
+   if (ret < 0) {
+   DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n",
ret);
+   hdcp2_deauthenticate_port(>hdcp);
+   }
+   }
+
+   return ret;
+}
+
+static int _intel_hdcp2_disable(struct intel_connector *connector) {
+   int ret;
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
+ connector->base.name, connector->base.base.id);
+
+   ret = hdcp2_disable_encryption(connector);

Check for return and print a message.
Caller will handle the error cases I guess. So we will just pass the 
error here.



+
+   hdcp2_deauthenticate_port(>hdcp);
+
+   return ret;
+}
+
+static int _intel_hdcp2_enable(struct intel_connector *connector) {
+   struct intel_hdcp *hdcp = >hdcp;
+   int ret;
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+   ret = hdcp2_authenticate_and_encrypt(connector);
+   if (ret) {
+   DRM_ERROR("HDCP2 Type%d  Enabling Failed. (%d)\n",
+  hdcp->content_type, ret);
+   return ret;
+   }
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+   hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>hdcp_prop_work);
+
+   return 0;
+}
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

;>https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

[Ramalingam C]

On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote:



On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
Behalf Of

Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port 
encryption


Implements the enable and disable functions for HDCP2.2 encryption 
of the

PORT.

v2:
  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_hdcp.c | 54
+++
1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index d70320da85e4..91cac643f083 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
 (enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES    5
#define HDCP2_LC_RETRY_CNT    3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE    32

static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port 
*intel_dig_port,

    const struct intel_hdcp_shim *shim) @@ -
1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct 
intel_connector

*connector)

return ret;
}
+
+static int hdcp2_enable_encryption(struct intel_connector 
*connector) {
+    struct intel_digital_port *intel_dig_port = 
conn_to_dig_port(connector);

+    struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+    struct intel_hdcp *hdcp = >hdcp;
+    enum port port = connector->encoder->port;
+    int ret;
+
+    if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)

Print a message saying "Encryption Already enabled" .

It doesn't serve any purpose uma. why do we need this?

+    return 0;
+
+    if (hdcp->hdcp_shim->toggle_signalling)

Check for "hdcp->hdcp_shim" as well.

Without hdcp_shim structure, we wont reach here.

+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+    if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+
+    /* Link is Authenticated. Now set for Encryption */
+    I915_WRITE(HDCP2_CTR_DDI(port),
+   I915_READ(HDCP2_CTR_DDI(port)) |
+   CTL_LINK_ENCRYPTION_REQ);
+    }
+
+    ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+  LINK_ENCRYPTION_STATUS,
+  LINK_ENCRYPTION_STATUS,
+  TIME_FOR_ENCRYPT_STATUS_CHANGE);

Print a message in case of timeout.

Yes. Since this timeout is unexpected, debug msg would help.
Sorry my bad, caller is already handling the error case. So such debug 
msg is needed only for disable sequence.



+    return ret;
+}
+
+static int hdcp2_disable_encryption(struct intel_connector *connector)
+{
+    struct intel_digital_port *intel_dig_port = 
conn_to_dig_port(connector);

+    struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+    struct intel_hdcp *hdcp = >hdcp;
+    enum port port = connector->encoder->port;
+    int ret;
+
+    if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS))

Put a info message saying "Already Disabled" .

I feel this msg wont help uma.



+    return 0;
+
+    I915_WRITE(HDCP2_CTR_DDI(port),
+   I915_READ(HDCP2_CTR_DDI(port)) &
~CTL_LINK_ENCRYPTION_REQ);
+
+    ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+  LINK_ENCRYPTION_STATUS, 0x0,
+  TIME_FOR_ENCRYPT_STATUS_CHANGE);

If this times out, do we still need to toggle the signalling ?
As per the Bspec Encryption will stop in a frame time. So 32mSec 
should be adequate.
So we need to toggle the hdcp signaling so that panel will know that 
unencrypted data is expected.



+
+    if (hdcp->hdcp_shim->toggle_signalling)

Check for validity of " hdcp->hdcp_shim".
hdcp_shim will be valid at this point. but where as toggling function 
is only for hdmi.


--Ram



+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+    return ret;
+}
--
2.7.4

___
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

[PATCH] drm/vc4: Introduce tracepoints for CL execution.

[Eric Anholt]

This has been useful for debugging the window movement lag in X11, and
I have patches to sysprof that watch these to produce nice
visualizations.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_gem.c   |  4 +++
 drivers/gpu/drm/vc4/vc4_irq.c   |  4 +++
 drivers/gpu/drm/vc4/vc4_trace.h | 58 +
 3 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 7910b9acedd6..7e98eb93bcc0 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -479,6 +479,7 @@ vc4_submit_next_bin_job(struct drm_device *dev)
 */
if (exec->ct0ca != exec->ct0ea) {
submit_cl(dev, 0, exec->ct0ca, exec->ct0ea);
+   trace_vc4_submit_cl(dev, exec->seqno, false);
} else {
struct vc4_exec_info *next;
 
@@ -513,6 +514,7 @@ vc4_submit_next_render_job(struct drm_device *dev)
vc4_flush_texture_caches(dev);
 
submit_cl(dev, 1, exec->ct1ca, exec->ct1ea);
+   trace_vc4_submit_cl(dev, exec->seqno, true);
 }
 
 void
@@ -1124,6 +1126,8 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct dma_fence *in_fence;
int ret = 0;
 
+   trace_vc4_submit_cl_begin(dev);
+
if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
 VC4_SUBMIT_CL_FIXED_RCL_ORDER |
 VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 4cd2ccfe15f4..d331ad136ae8 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -47,6 +47,7 @@
 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
+#include "vc4_trace.h"
 
 #define V3D_DRIVER_IRQS (V3D_INT_OUTOMEM | \
 V3D_INT_FLDONE | \
@@ -109,6 +110,7 @@ vc4_irq_finish_bin_job(struct drm_device *dev)
if (!exec)
return;
 
+   trace_vc4_finish_cl(dev, exec->seqno, false);
vc4_move_job_to_render(dev, exec);
next = vc4_first_bin_job(vc4);
 
@@ -147,6 +149,8 @@ vc4_irq_finish_render_job(struct drm_device *dev)
if (!exec)
return;
 
+   trace_vc4_finish_cl(dev, exec->seqno, true);
+
vc4->finished_seqno++;
list_move_tail(>head, >job_done_list);
 
diff --git a/drivers/gpu/drm/vc4/vc4_trace.h b/drivers/gpu/drm/vc4/vc4_trace.h
index deafb32923e1..d5f2b91035a5 100644
--- a/drivers/gpu/drm/vc4/vc4_trace.h
+++ b/drivers/gpu/drm/vc4/vc4_trace.h
@@ -55,6 +55,64 @@ TRACE_EVENT(vc4_wait_for_seqno_end,
  __entry->dev, __entry->seqno)
 );
 
+TRACE_EVENT(vc4_submit_cl_begin,
+   TP_PROTO(struct drm_device *dev),
+   TP_ARGS(dev),
+
+   TP_STRUCT__entry(
+__field(u32, dev)
+),
+
+   TP_fast_assign(
+  __entry->dev = dev->primary->index;
+  ),
+
+   TP_printk("dev=%u",
+ __entry->dev)
+);
+
+TRACE_EVENT(vc4_submit_cl,
+   TP_PROTO(struct drm_device *dev, uint64_t seqno, int ring),
+   TP_ARGS(dev, seqno, ring),
+
+   TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, seqno)
+__field(bool, ring)
+),
+
+   TP_fast_assign(
+  __entry->dev = dev->primary->index;
+  __entry->seqno = seqno;
+  __entry->ring = ring;
+  ),
+
+   TP_printk("dev=%u, seqno=%llu %s",
+ __entry->dev, __entry->seqno,
+ __entry->ring ? "RCL" : "BCL")
+);
+
+TRACE_EVENT(vc4_finish_cl,
+   TP_PROTO(struct drm_device *dev, uint64_t seqno, int ring),
+   TP_ARGS(dev, seqno, ring),
+
+   TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, seqno)
+__field(bool, ring)
+),
+
+   TP_fast_assign(
+  __entry->dev = dev->primary->index;
+  __entry->seqno = seqno;
+  __entry->ring = ring;
+  ),
+
+   TP_printk("dev=%u, seqno=%llu %s",
+ __entry->dev, __entry->seqno,
+ __entry->ring ? "RCL" : "BCL")
+);
+
 #endif /* _VC4_TRACE_H_ */
 
 /* This part must be outside protection */
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

[Daniel Stone]

Hi Ville,

On 23 March 2018 at 14:49, Daniel Stone  wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä  
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just to prevent changes of the obj
>> tiling mode as long as any fb exists that uses the object. So
>> doesn't actually matter how many planes the fb has.
>>
>> Naturally the story would be slightly difference if we supported
>> fbs using multiple different BOs, as each BO would need to get its
>> framebuffer_references adjusted.
>
> Yeah, fair enough. It looks a little bit weird (perhaps deserving of a
> comment) there. The reason to do that was just the general principle
> of having one reference per object pointer, especially when other
> drivers (ones which can have separate BOs in a single logical image)
> will and do refcount them separately. Having different refcounting
> semantics in shared structures depending on which driver is in use
> makes me itchy.

Absent any other comment, I've dropped this change and will keep a
single framebuffer_reference[s] for v2.

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

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

[Daniel Stone]

Hi Russell,

On 30 March 2018 at 15:11, Daniel Stone  wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.

Ping - have you had a chance to look at this?

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

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

[Daniel Stone]

Hi CK, Philipp,

On 30 March 2018 at 15:11, Daniel Stone  wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.

Did you get a chance to look at these three patches for Mediatek?

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

Re: [PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

[Daniel Stone]

On 30 March 2018 at 21:53, Sebastian Reichel
 wrote:
> On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
>> drm_framebuffer already holds per-plane pitch and offsets, which is
>> filled out for us when we create the framebuffer. Nuke our local copy in
>> the plane struct.
>>
>> Signed-off-by: Daniel Stone 
>> Cc: Tomi Valkeinen 
>
> Reviewed-by: Sebastian Reichel 

Thanks Sebastian! Tomi, are you planning to take this through drm-tip
if you're happy with it?

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

Re: [PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer

[Daniel Stone]

Hi Rob,

On 30 March 2018 at 15:11, Daniel Stone  wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle function the same as the GEM framebuffer helper, we
> can reuse that.

I didn't get to removing msm_framebuffer completely, because the
cleanup was a bit too painful. It still seems like a useful cleanup
though - could you please take a look?

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

Re: [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

[Daniel Stone]

Hi Thierry,

On 30 March 2018 at 15:11, Daniel Stone  wrote:
> Since tegra_fb is now the same as drm_framebuffer, we can just replace
> the type completely.
>
> Signed-off-by: Daniel Stone 
> Cc: Thierry Reding 
> Cc: linux-te...@vger.kernel.org

Did this still need some more testing, or is it OK to apply?

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

Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

[Ramalingam C]

On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

Implements the enable and disable functions for HDCP2.2 encryption of the
PORT.

v2:
  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_hdcp.c | 54
+++
1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index d70320da85e4..91cac643f083 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
 (enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES  5
#define HDCP2_LC_RETRY_CNT  3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32

static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim) @@ -
1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct intel_connector
*connector)

return ret;
}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector) {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret;
+
+   if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)

Print a message saying "Encryption Already enabled" .

It doesn't serve any purpose uma. why do we need this?

+   return 0;
+
+   if (hdcp->hdcp_shim->toggle_signalling)

Check for "hdcp->hdcp_shim" as well.

Without hdcp_shim structure, we wont reach here.

+   hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+   if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+
+   /* Link is Authenticated. Now set for Encryption */
+   I915_WRITE(HDCP2_CTR_DDI(port),
+  I915_READ(HDCP2_CTR_DDI(port)) |
+  CTL_LINK_ENCRYPTION_REQ);
+   }
+
+   ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS,
+ LINK_ENCRYPTION_STATUS,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);

Print a message in case of timeout.

Yes. Since this timeout is unexpected, debug msg would help.



+   return ret;
+}
+
+static int hdcp2_disable_encryption(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret;
+
+   if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS))

Put a info message saying "Already Disabled" .

I feel this msg wont help uma.



+   return 0;
+
+   I915_WRITE(HDCP2_CTR_DDI(port),
+  I915_READ(HDCP2_CTR_DDI(port)) &
~CTL_LINK_ENCRYPTION_REQ);
+
+   ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS, 0x0,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);

If this times out, do we still need to toggle the signalling ?
As per the Bspec Encryption will stop in a frame time. So 32mSec should 
be adequate.
So we need to toggle the hdcp signaling so that panel will know that 
unencrypted data is expected.



+
+   if (hdcp->hdcp_shim->toggle_signalling)

Check for validity of " hdcp->hdcp_shim".
hdcp_shim will be valid at this point. but where as toggling function is 
only for hdmi.


--Ram



+   hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+   return ret;
+}
--
2.7.4

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


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

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Daniel Stone]

On 30 March 2018 at 15:11, Daniel Stone  wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone 
> Cc: Sandy Huang 
> Cc: Heiko Stübner 

Ping?

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