[Bug 110639] enc->enc_pic.enc_pic_order_cnt_type always zero even if pic->pic_order_cnt_type non-zero that application set

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110639

Bug ID: 110639
   Summary: enc->enc_pic.enc_pic_order_cnt_type always zero even
if  pic->pic_order_cnt_type non-zero that application
set
   Product: Mesa
   Version: 18.0
  Hardware: ARM
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: wangfengju...@huawei.com
QA Contact: dri-devel@lists.freedesktop.org

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

when process yuv encode to h264, player set pic_order_cnt_type non-zero value,
but h264 SPS pic_order_cnt_type member always zero.

I have found that enc->enc_pic.pc.enc_pic_order_cnt_type always print zero in
mesa/src/gallium/drivers/radeon/radeon_vce_52.c:452.

but add enc->enc_pic.pc.enc_pic_order_cnt_type = pic->pic_order_cnt_type;at fun
get_pic_control_param in mesa/src/gallium/drivers/radeon/radeon_vce_52.c:92 can
resove the bug.

Please help to check and commit if the above method is right.

ps:
(gdb) bt
#0  pic_control (enc=0xaacc2d30) at radeon_vce_52.c:527
#1  0xbf1620b0 in config (enc=0xaacc2d30) at radeon_vce_52.c:452
#2  0xbf164d34 in rvce_begin_frame (encoder=0xaacc2d30,
source=0xaabfbc50, picture=0xaabe2828) at radeon_vce.c:292
#3  0xbef076f0 in vlVaEndPicture (ctx=0xaaae0c80, context_id=2) at
picture.c:700
#4  0xbf695cb8 in vaEndPicture (dpy=0xaaae0b10, context=2) at
va.c:1520
#5  0xf258 in avcenc_render_picture () at
src/va_encode_impl.cpp:831
#6  0xaaab1030 in encode_picture (is_idr=1, slice_type=2) at
src/va_encode_impl.cpp:1482
#7  0xaaab16e0 in vaapi_encode_yuv_to_h264 (frame_index=0) at
src/va_encode_impl.cpp:1613
#8  0xaaab17a4 in vaapi_encode_frame (frame_index=0) at
src/va_encode_impl.cpp:1640
#9  0xbba4 in va_encode_frame (frame_index=0) at
src/va_encode_api2.cpp:118
#10 0xaaab26dc in main (argc=5, argv=0xf678) at
demo/test_va_encode.cpp:164

Thanks.

-- 
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: [v2 5/5] drm/mediatek: add mt8183 dsi driver support

2019-05-07 Thread CK Hu
Hi, Jitao:

On Tue, 2019-04-16 at 14:05 +0800, Jitao Shi wrote:
> Add mt8183 dsi driver data. Enable size control and
> reg commit control.
> 

Reviewed-by: CK Hu 

> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 458a700ce74c..f0b36ec38e4f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1104,11 +1104,19 @@ static const struct mtk_dsi_driver_data 
> mt2701_dsi_driver_data = {
>   .reg_cmdq_off = 0x180,
>  };
>  
> +static const struct mtk_dsi_driver_data mt8183_dsi_driver_data = {
> + .reg_cmdq_off = 0x200,
> + .has_shadow_ctl = true,
> + .has_size_ctl = true,
> +};
> +
>  static const struct of_device_id mtk_dsi_of_match[] = {
>   { .compatible = "mediatek,mt2701-dsi",
> .data = _dsi_driver_data },
>   { .compatible = "mediatek,mt8173-dsi",
> .data = _dsi_driver_data },
> + { .compatible = "mediatek,mt8183-dsi",
> +   .data = _dsi_driver_data },
>   { },
>  };
>  


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

Re: [v2 4/5] drm/mediatek: add frame size control

2019-05-07 Thread CK Hu
Hi, Jitao:

On Tue, 2019-04-16 at 14:05 +0800, Jitao Shi wrote:
> Our new DSI chip has frame size control.
> So add the driver data to control for different chips.
> 

Reviewed-by: CK Hu 

> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index be42405a0a78..458a700ce74c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -78,6 +78,7 @@
>  #define DSI_VBP_NL   0x24
>  #define DSI_VFP_NL   0x28
>  #define DSI_VACT_NL  0x2C
> +#define DSI_SIZE_CON 0x38
>  #define DSI_HSA_WC   0x50
>  #define DSI_HBP_WC   0x54
>  #define DSI_HFP_WC   0x58
> @@ -162,6 +163,7 @@ struct phy;
>  struct mtk_dsi_driver_data {
>   const u32 reg_cmdq_off;
>   bool has_shadow_ctl;
> + bool has_size_ctl;
>  };
>  
>  struct mtk_dsi {
> @@ -430,6 +432,9 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>   writel(vm->vfront_porch, dsi->regs + DSI_VFP_NL);
>   writel(vm->vactive, dsi->regs + DSI_VACT_NL);
>  
> + if (dsi->driver_data->has_size_ctl)
> + writel(vm->vactive << 16 | vm->hactive, dsi->regs + 
> DSI_SIZE_CON);
> +
>   horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
>  
>   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)


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

Re: [v2 3/5] drm/mediatek: add dsi reg commit control

2019-05-07 Thread CK Hu
Hi, Jitao:

On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> New DSI IP has shadow register and working reg. The register
> values are writen to shadow register. And then trigger with
> commit reg, the register values will be moved working register.

This patch looks good, but the message is not complete. The message make
us believe you use shadow register to work, but actually, shadow
register is default turn on in new DSI IP and you want to turn off it.

Regards,
CK

> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 573e6bec6d36..be42405a0a78 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -131,6 +131,10 @@
>  #define VM_CMD_ENBIT(0)
>  #define TS_VFP_ENBIT(5)
>  
> +#define DSI_SHADOW_DEBUG 0x190U
> +#define FORCE_COMMIT BIT(0)
> +#define BYPASS_SHADOWBIT(1)
> +
>  #define CONFIG   (0xff << 0)
>  #define SHORT_PACKET 0
>  #define LONG_PACKET  2
> @@ -157,6 +161,7 @@ struct phy;
>  
>  struct mtk_dsi_driver_data {
>   const u32 reg_cmdq_off;
> + bool has_shadow_ctl;
>  };
>  
>  struct mtk_dsi {
> @@ -594,6 +599,11 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> +
> + if (dsi->driver_data->has_shadow_ctl)
> + writel(FORCE_COMMIT | BYPASS_SHADOW,
> +dsi->regs + DSI_SHADOW_DEBUG);
> +
>   mtk_dsi_reset_engine(dsi);
>   mtk_dsi_phy_timconfig(dsi);
>  


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

Re: [v2 2/5] drm/mediatek: CMDQ reg address of mt8173 is different with mt2701

2019-05-07 Thread CK Hu
On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> Config the different CMDQ reg address in driver data.
> 
For MT8173, you change reg_cmd_off from 0x180 to 0x200, so this patch is
a bug fix. You should add a 'Fixes' tag.

> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 39 +++---
>  1 file changed, 30 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6c4ac37f983d..573e6bec6d36 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -131,7 +131,6 @@
>  #define VM_CMD_ENBIT(0)
>  #define TS_VFP_ENBIT(5)
>  
> -#define DSI_CMDQ00x180
>  #define CONFIG   (0xff << 0)
>  #define SHORT_PACKET 0
>  #define LONG_PACKET  2
> @@ -156,6 +155,10 @@
>  
>  struct phy;
>  
> +struct mtk_dsi_driver_data {
> + const u32 reg_cmdq_off;
> +};
> +
>  struct mtk_dsi {
>   struct mtk_ddp_comp ddp_comp;
>   struct device *dev;
> @@ -182,6 +185,7 @@ struct mtk_dsi {
>   bool enabled;
>   u32 irq_data;
>   wait_queue_head_t irq_wait_queue;
> + struct mtk_dsi_driver_data *driver_data;
>  };
>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -934,6 +938,7 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const 
> struct mipi_dsi_msg *msg)
>   const char *tx_buf = msg->tx_buf;
>   u8 config, cmdq_size, cmdq_off, type = msg->type;
>   u32 reg_val, cmdq_mask, i;
> + u32 reg_cmdq_off = dsi->driver_data->reg_cmdq_off;
>  
>   if (MTK_DSI_HOST_IS_READ(type))
>   config = BTA;
> @@ -953,9 +958,11 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const 
> struct mipi_dsi_msg *msg)
>   }
>  
>   for (i = 0; i < msg->tx_len; i++)
> - writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
> + mtk_dsi_mask(dsi, (reg_cmdq_off + cmdq_off + i) & (~0x3U),
> +  (0xffUL << (((i + cmdq_off) & 3U) * 8U)),
> +  tx_buf[i] << (((i + cmdq_off) & 3U) * 8U));

You say you would follow Nicolas' suggestion here.

>  
> - mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
> + mtk_dsi_mask(dsi, reg_cmdq_off, cmdq_mask, reg_val);
>   mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
>  }
>  
> @@ -1074,10 +1081,27 @@ static const struct component_ops 
> mtk_dsi_component_ops = {
>   .unbind = mtk_dsi_unbind,
>  };
>  
> +static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
> + .reg_cmdq_off = 0x200,
> +};
> +
> +static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
> + .reg_cmdq_off = 0x180,
> +};
> +
> +static const struct of_device_id mtk_dsi_of_match[] = {
> + { .compatible = "mediatek,mt2701-dsi",
> +   .data = _dsi_driver_data },
> + { .compatible = "mediatek,mt8173-dsi",
> +   .data = _dsi_driver_data },
> + { },
> +};
> +
>  static int mtk_dsi_probe(struct platform_device *pdev)
>  {
>   struct mtk_dsi *dsi;
>   struct device *dev = >dev;
> + const struct of_device_id *of_id;
>   struct resource *regs;
>   int irq_num;
>   int comp_id;
> @@ -1101,6 +1125,9 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   if (ret)
>   goto err_unregister_host;
>  
> + of_id = of_match_device(mtk_dsi_of_match, >dev);
> + dsi->driver_data = of_id->data;

Maybe use of_device_get_match_data() is a more simple way. You could
refer to [1].

[1]
https://elixir.bootlin.com/linux/v5.1/source/drivers/gpu/drm/mediatek/mtk_disp_ovl.c#L300

Regards,
CK

> +
>   dsi->engine_clk = devm_clk_get(dev, "engine");
>   if (IS_ERR(dsi->engine_clk)) {
>   ret = PTR_ERR(dsi->engine_clk);
> @@ -1193,12 +1220,6 @@ static int mtk_dsi_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> -static const struct of_device_id mtk_dsi_of_match[] = {
> - { .compatible = "mediatek,mt2701-dsi" },
> - { .compatible = "mediatek,mt8173-dsi" },
> - { },
> -};
> -
>  struct platform_driver mtk_dsi_driver = {
>   .probe = mtk_dsi_probe,
>   .remove = mtk_dsi_remove,


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

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107978

Shmerl  changed:

   What|Removed |Added

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

--- Comment #59 from Shmerl  ---
Closing, since it's already fixed in the released kernels.

-- 
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 109619] Add new alias for R600_TEX_ANISO for radeonsi

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109619

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
Fixed by:

commit 024232b26c203d593533e488b5131e7a787b2ac1
Author: Timothy Arceri 
Date:   Tue May 7 10:18:54 2019 +1000

radeonsi: add an AMD_TEX_ANISO environment variable

This brings it inline with the recently added AMD_DEBUG.

Reviewed-by: Marek Olšák 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109619

-- 
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 110637] Enabling OpenCL in Libreoffice kills Vega 64

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110637

Bug ID: 110637
   Summary: Enabling OpenCL in Libreoffice kills Vega 64
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mezin.alexan...@gmail.com

Created attachment 144191
  --> https://bugs.freedesktop.org/attachment.cgi?id=144191=edit
kernel log

Open LibreOffice, enable OpenCL in settings, restart it.
Result:

[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=698,
emitted seq=700
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process
soffice.bin pid 2517 thread soffice.bi:cs0 pid 2545
amdgpu :67:00.0: GPU reset begin!
amdgpu :67:00.0: GPU BACO reset
amdgpu: [powerplay] Failed message: 0x5, input parameter: 0x200, error
code: 0x
amdgpu :67:00.0: GPU reset succeeded, trying to resume
[drm] PCIE GART of 512M enabled (table at 0x00F40090).
[drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* VRAM is lost!
[drm] PSP is resuming...
[drm] reserve 0x40 from 0xf400d0 for PSP TMR SIZE
[drm] UVD and UVD ENC initialized successfully.
[drm] VCE initialized successfully.
[drm] recover vram bo from shadow start
[drm] recover vram bo from shadow done
[drm] Skip scheduling IBs!
[drm] Skip scheduling IBs!
amdgpu :67:00.0: GPU reset(2) succeeded!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
...

Also the same problem with multiple games, so probably not OpenCL-related, just
the easiest way to trigger it.

linux 5.1.arch1-1 (same results with 5.0.13, will also retest with 4.9)
linux-firmware 20190502.92e17d0-1 (same results with 20190424.4b6cf2b-1)
opencl-mesa 19.0.3-1
libdrm 2.4.98-1
libreoffice-fresh 6.2.3-2

GNOME on X.org with modesetting driver

Sapphire Vega 64 Nitro+, no overclocking

-- 
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 109345] drm-next-2018-12-14 -Linux PPC

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109345

--- Comment #35 from Ilia Mirkin  ---
If I had to put money on one of the left-over commits, I'd go with

commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
Author: Aaron Ma 
Date:   Sat Sep 1 02:20:00 2018 +0800

vgaarb: Keep adding VGA device in queue

If failed to find the deivice owning the boot framebuffer,
try to use the first VGA device instead of the last one.

Usually the 1st device is integrated GPU who owns the boot framebuffer.

Signed-off-by: Aaron Ma 
Acked-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
Link:
https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-email-aaron...@canonical.com

Which seems to change the vgaarb logic wrt which device is the primary.

-- 
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 109345] drm-next-2018-12-14 -Linux PPC

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109345

--- Comment #34 from Christian Zigotzky  ---
Hi All,

Allan successfully tested the eighth test kernel on his X5000 today.

He wrote:

Christian
DRM8 boots to Firepro. Can you ascertain anything as yet as to where the issue
lies?

Cheers

ace

--

This step has been marked as good because the eighth test kernel boots to
FirePro.

Next step:

git bisect good

Output:

Bisecting: 2 revisions left to test after this (roughly 2 steps)
[43cf1fc0e27e2f7eeb5d6c15fd023813a5b49987] drm: fix deadlock of syncobj v6

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm9

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian

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

Re: [PATCH v3 5/5] drm: don't block fb changes for async plane updates

2019-05-07 Thread Sean Paul
On Wed, Mar 13, 2019 at 09:20:26PM -0300, Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are performed in the old_state.
> 
> In the case of async updates, the preparation is also done in the
> new_state but the cleanups are done in the new_state (because updates
> are performed in place, i.e. in the current state).
> 
> The current code blocks async udpates when the fb is changed, turning
> async updates into sync updates, slowing down cursor updates and
> introducing regressions in igt tests with errors of type:
> 
> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> expect to complete approximately 15360 updates, with the threshold set
> at 7680"
> 
> Fb changes in async updates were prevented to avoid the following scenario:
> 
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
> Where we have a single call to prepare fb2 but double cleanup call to fb2.
> 
> To solve the above problems, instead of blocking async fb changes, we
> place the old framebuffer in the new_state object, so when the code
> performs cleanups in the new_state it will cleanup the old_fb and we
> will have the following scenario instead:
> 
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> 
> Where calls to prepare/cleanup are balanced.
> 
> Cc:  # v4.14+

I'm not convinced this should be cc: stable, seems more in the improvement
category than a bug fix.

> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> Suggested-by: Boris Brezillon 
> Signed-off-by: Helen Koike 
> Reviewed-by: Boris Brezillon 
> Reviewed-by: Nicholas Kazlauskas 
> 
> ---
> Hello,
> 
> I added a TODO in drm_atomic_helper_async_commit() regarding doing a
> full state swap(), Boris and Nicholas, let me know if this is ok and if
> I can keep your Reviewed-by tags)
> 
> As mentioned in the cover letter, I tested in almost all platforms with
> igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
> regressions. But I couldn't test on MSM and AMD because I don't have
> the hardware I would appreciate if anyone could help me testing those.
> 
> Thanks!
> Helen
> 
> Changes in v3:
> - Add Reviewed-by tags
> - Add TODO in drm_atomic_helper_async_commit()
> 
> Changes in v2:
> - Change the order of the patch in the series, add this as the last one.
> - Add documentation
> - s/ballanced/balanced
> 
>  drivers/gpu/drm/drm_atomic_helper.c  | 22 --
>  include/drm/drm_modeset_helper_vtables.h |  5 +
>  2 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2453678d1186..de5812c362b5 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   old_plane_state->crtc != new_plane_state->crtc)
>   return -EINVAL;
>  
> - /*
> -  * FIXME: Since prepare_fb and cleanup_fb are always called on
> -  * the new_plane_state for async updates we need to block framebuffer
> -  * changes. This prevents use of a fb that's been cleaned up and
> -  * double cleanups from occuring.
> -  */
> - if (old_plane_state->fb != new_plane_state->fb)
> - return -EINVAL;
> -
>   funcs = plane->helper_private;
>   if (!funcs->atomic_async_update)
>   return -EINVAL;
> @@ -1647,6 +1638,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_check);
>   * drm_atomic_async_check() succeeds. Async commits are not supposed to swap
>   * the states like normal sync commits, but just do in-place changes on the
>   * current state.
> + *
> + * TODO: Implement full swap instead of doing in-place changes.
>   */
>  void drm_atomic_helper_async_commit(struct drm_device *dev,
>   struct drm_atomic_state *state)
> @@ -1657,6 +1650,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
> *dev,
>   int i;
>  
>   for_each_new_plane_in_state(state, plane, plane_state, i) {
> + struct drm_framebuffer *new_fb = plane_state->fb;
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
>   funcs = plane->helper_private;
>   funcs->atomic_async_update(plane, plane_state);
>  
> @@ -1665,11 +1661,17 @@ void drm_atomic_helper_async_commit(struct drm_device 
> *dev,
>* plane->state in-place, make sure at least common
>

Re: [RFC PATCH 0/5] cgroup support for GPU devices

2019-05-07 Thread Welty, Brian

On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
> 
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> *  control allocation of device memory (reuse of memcg)
>> and with future work, we could extend to:
>> *  track and control share of GPU time (reuse of cpu/cpuacct)
>> *  apply mask of allowed execution engines (reuse of cpusets)
>>
>> Instead of introducing a new cgroup subsystem for GPU devices, a new
>> framework is proposed to allow devices to register with existing cgroup
>> controllers, which creates per-device cgroup_subsys_state within the
>> cgroup.  This gives device drivers their own private cgroup controls
>> (such as memory limits or other parameters) to be applied to device
>> resources instead of host system resources.
>> Device drivers (GPU or other) are then able to reuse the existing cgroup
>> controls, instead of inventing similar ones.
> 
> I'm really skeptical about this approach.  When creating resource
> controllers, I think what's the most important and challenging is
> establishing resource model - what resources are and how they can be
> distributed.  This patchset is going the other way around - building
> out core infrastructure for bolierplates at a significant risk of
> mixing up resource models across different types of resources.
> 
> IO controllers already implement per-device controls.  I'd suggest
> following the same interface conventions and implementing a dedicated
> controller for the subsystem.
>
Okay, thanks for feedback.  Preference is clear to see this done as
dedicated cgroup controller.

Part of my proposal was an attempt for devices with "mem like" and "cpu 
like" attributes to be managed by common controller.   We can ignore this
idea for cpu attributes, as those can just go in a GPU controller.

There might still be merit in having a 'device mem' cgroup controller.
The resource model at least is then no longer mixed up with host memory.
RDMA community seemed to have some interest in a common controller at
least for device memory aspects.
Thoughts on this?   I believe could still reuse the 'struct mem_cgroup' data
structure.  There should be some opportunity to reuse charging APIs and
have some nice integration with HMM for charging to device memory, depending
on backing store.

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

[PATCH 2/3] drm/msm/dpu: Avoid a null de-ref while recovering from kms init fail

2019-05-07 Thread Jordan Crouse
In the failure path for dpu_kms_init() it is possible to get to the MMU
destroy function with uninitialized MMU structs. Check for NULl and skip
if needed.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 885bf88..1beaf29 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -56,7 +56,7 @@ static const char * const iommu_ports[] = {
 #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
 
 static int dpu_kms_hw_init(struct msm_kms *kms);
-static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
+static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
 
 static unsigned long dpu_iomap_size(struct platform_device *pdev,
const char *name)
@@ -725,17 +725,20 @@ static const struct msm_kms_funcs kms_funcs = {
 #endif
 };
 
-static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
+static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
 {
struct msm_mmu *mmu;
 
+   if (!dpu_kms->base.aspace)
+   return;
+
mmu = dpu_kms->base.aspace->mmu;
 
mmu->funcs->detach(mmu, (const char **)iommu_ports,
ARRAY_SIZE(iommu_ports));
msm_gem_address_space_put(dpu_kms->base.aspace);
 
-   return 0;
+   dpu_kms->base.aspace = NULL;
 }
 
 static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
-- 
2.7.4

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

[PATCH 3/3] drm/msm/adreno: Call pm_runtime_force_suspend() during unbind

2019-05-07 Thread Jordan Crouse
The GPU specific pm_suspend code assumes that the hardware is active
when the function is called, which it usually is when called as part
of pm_runtime.  But during unbind, the pm_suspend functions are called
blindly resulting in a bit of a when the hardware wasn't already
active (or booted, in the case of the GMU).

Instead of calling the pm_suspend function directly, use
pm_runtime_force_suspend() which should check the correct state of
runtime and call the functions on our behalf or skip them if they are
not needed.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 4 +---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9155daf..447706d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1230,9 +1230,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
if (IS_ERR_OR_NULL(gmu->mmio))
return;
 
-   a6xx_gmu_stop(a6xx_gpu);
-
-   pm_runtime_disable(gmu->dev);
+   pm_runtime_force_suspend(gmu->dev);
 
if (!IS_ERR(gmu->gxpd)) {
pm_runtime_disable(gmu->gxpd);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index b907245..3dd90df 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -351,7 +351,7 @@ static void adreno_unbind(struct device *dev, struct device 
*master,
 {
struct msm_gpu *gpu = dev_get_drvdata(dev);
 
-   gpu->funcs->pm_suspend(gpu);
+   pm_runtime_force_suspend(dev);
gpu->funcs->destroy(gpu);
 
set_gpu_pdev(dev_get_drvdata(master), NULL);
-- 
2.7.4

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

[PATCH 1/3] drm/msm/dpu: Fix error recovery after failing to enable clocks

2019-05-07 Thread Jordan Crouse
If enabling clocks fails in msm_dss_enable_clk() the code to unwind the
settings starts at 'i' which is the clock that just failed. While this
isn't harmful it does result in a number of warnings from the clock
subsystem while trying to unpreare/disable the very clock that had
just failed to prepare/enable. Skip the current failed clock during
the unwind to to avoid the extra log spew.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 78833c2..a40a630 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -114,9 +114,9 @@ int msm_dss_enable_clk(struct dss_clk *clk_arry, int 
num_clk, int enable)
rc = -EPERM;
}
 
-   if (rc) {
-   msm_dss_enable_clk(_arry[i],
-   i, false);
+   if (rc && i) {
+   msm_dss_enable_clk(_arry[i - 1],
+   i - 1, false);
break;
}
}
-- 
2.7.4

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

[PATCH 0/3] drm/msm: Handle component bind failures a bit better

2019-05-07 Thread Jordan Crouse
I somewhat accidently injected an error in the DPU KMS init that caused it to
fail and a handful of NULL deferences and errors ended up popping out. Here are
some fixes in the interest of robustness.

Jordan Crouse (3):
  drm/msm/dpu: Fix error recovery after failing to enable clocks
  drm/msm/dpu: Avoid a null de-ref while recovering from kms init fail
  drm/msm/adreno: Call pm_runtime_force_suspend() during unbind

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   | 4 +---
 drivers/gpu/drm/msm/adreno/adreno_device.c  | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 6 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++---
 4 files changed, 11 insertions(+), 10 deletions(-)

-- 
2.7.4

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

[PATCH] drm/atomic: Check that the config funcs exist drm_mode_alloc

2019-05-07 Thread Jordan Crouse
An error while initializing the msm driver ends up calling
drm_atomic_helper_shutdown() without first initializing the funcs
in mode_config. While I'm not 100% sure this isn't a ordering
problem in msm adding a check to drm_mode_alloc seems like
a nice and safe solution.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/drm_atomic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5eb4013..1729428 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -114,6 +114,9 @@ drm_atomic_state_alloc(struct drm_device *dev)
 {
struct drm_mode_config *config = >mode_config;
 
+   if (!config->funcs)
+   return NULL;
+
if (!config->funcs->atomic_state_alloc) {
struct drm_atomic_state *state;
 
-- 
2.7.4

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

Re: [PATCH 3/3] mesa: android: freedreno: Fix build failure due to path change

2019-05-07 Thread John Stultz
On Tue, May 7, 2019 at 11:34 AM Dylan Baker  wrote:
>
> This patch and the previous one landed with a fixes tag nominating them for 
> the
> staging/19.0 branch, but they don't apply, and to get the to apply requires
> pulling in several other android build system patches. If you'd like those in
> the 19.0 stable branch can you put together an MR against the staging/19.0
> branch, or if you don't care let me know so I can mark them as de-nominated?
>

Yea, so this one I don't think is necessary for  19.0

So you can see the patchset I'm pushing at the moment against 19.0.3 for AOSP:
  https://android-review.googlesource.com/c/platform/external/mesa3d/+/956844

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

Re: [PATCH 3/3] mesa: android: freedreno: Fix build failure due to path change

2019-05-07 Thread Dylan Baker
Hi John,

This patch and the previous one landed with a fixes tag nominating them for the
staging/19.0 branch, but they don't apply, and to get the to apply requires
pulling in several other android build system patches. If you'd like those in
the 19.0 stable branch can you put together an MR against the staging/19.0
branch, or if you don't care let me know so I can mark them as de-nominated?

Thanks,
Dylan

Quoting John Stultz (2019-05-02 11:03:46)
> The ir3_nir_trig.py file was moved in a previous commit,
> aa0fed10d3574 (freedreno: move ir3 to common location),
> so update the Android.gen.mk file to match.
> 
> Cc: Rob Clark 
> Cc: Emil Velikov 
> Cc: Amit Pundir 
> Cc: Sumit Semwal 
> Cc: Alistair Strachan 
> Cc: Greg Hartman 
> Cc: Tapani Pälli 
> Cc: Jason Ekstrand 
> Signed-off-by: John Stultz 
> ---
>  src/gallium/drivers/freedreno/Android.gen.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/freedreno/Android.gen.mk 
> b/src/gallium/drivers/freedreno/Android.gen.mk
> index 17b6fbe1b7e..d29ba159d5c 100644
> --- a/src/gallium/drivers/freedreno/Android.gen.mk
> +++ b/src/gallium/drivers/freedreno/Android.gen.mk
> @@ -25,7 +25,7 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
>  endif
>  
>  ir3_nir_trig_deps := \
> -   $(LOCAL_PATH)/ir3/ir3_nir_trig.py \
> +   $(MESA_TOP)/src/freedreno/ir3/ir3_nir_trig.py \
> $(MESA_TOP)/src/compiler/nir/nir_algebraic.py
>  
>  intermediates := $(call local-generated-sources-dir)
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master

2019-05-07 Thread Dylan Baker
Quoting Emil Velikov (2019-05-03 03:41:42)
> On Thu, 2 May 2019 at 23:19, Rob Clark  wrote:
> >
> > On Thu, May 2, 2019 at 2:57 PM Dan Willemsen  wrote:
> > >
> > > On Thu, May 2, 2019 at 1:52 PM John Stultz  wrote:
> > > >
> > > > We need solutions for the xgettext and the python-mako usage.
> > >
> > >  Android doesn't support translations at this level, so you may be
> > > able to just skip xgettext altogether.
> > >
> >
> > from quick look, gettext is just needed for docs build (which I guess
> > android doesn't do) and driconf (not supported on android afaiu,
> > although it could be nice if there was a way to support something like
> > driconf on android, but I guess a different topic[1]).. so yeah,
> > probably not needed
> >
> Pretty much what I've mentioned last time John brought the gettext
> patches - simply disable/drop the thing for Android.
> 
> One of these days we should even look closely at these "wanna-be
> translations, yet 90% not translated" and drop all together?
> 
> -Emil

Eric Engrstrom and I talked about this some time ago, the translations are very
incomplete and out of date at this point. Unless someone wants to step up and
maintain them I'd be in favor of dropping them all together.

Dylan


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

Re: [RESEND][PATCH v3 0/6] add LCD support for SAM9X60

2019-05-07 Thread Sam Ravnborg
Hi Thierry.

>   pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM
OK to add the "pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM"
patch via drm-misc?
Then we can add all 6 patches in one go.

Sam

(Kept remaining of mail for reference)
> 
> Hi,
> 
> These patches adds support for SAM9X60's LCD controller.
> 
> First patches add option to specify if controller clock source is fixed.
> Second patch avoid a variable initialization in 
> atmel_hlcdc_crtc_mode_set_nofb().
> The 3rd add compatibles in pwm-atmel-hlcdc driver.
> The 4th patch enables sys_clk in probe since SAM9X60 needs this.
> Specific support was added also in suspend/resume hooks.
> The 5th patch adds SAM9X60's LCD configuration and enabled it.
> 
> I took the changes of this series and introduced also a fix
> (this is the 6th patch in this series) - if you want to send it separately
> I would gladly do it.
> 
> I resend this to also include Lee Jones for pwm-atmel-hlcdc changes.
> 
> Thank you,
> Claudiu Beznea
> 
> Changes in v3:
> - keep compatible string on patch 3/6 on a single line (I keep here a tab
>   in front of ".compatible" to be aligned with the rest of the code in
>   atmel_hlcdc_dt_ids[])
> - patches 4/7 and 3/7 from v2 were applied so remove them from this version
> - add a fix for atmel_hlcdc (patch 6/6)
> 
> Changes in v2:
> - use "|" operator in patch 1/7 to set ATMEL_HLCDC_CLKSEL on cfg
> - collect Acked-by, Reviewed-by tags
> 
> Claudiu Beznea (4):
>   drm: atmel-hlcdc: add config option for clock selection
>   drm: atmel-hlcdc: avoid initializing cfg with zero
>   pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM
>   drm/atmel-hclcdc: revert shift by 8
> 
> Sandeep Sheriker Mallikarjun (2):
>   drm: atmel-hlcdc: enable sys_clk during initalization.
>   drm: atmel-hlcdc: add sam9x60 LCD controller
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  18 ++--
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 120 
> +++-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|   2 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |   2 +-
>  drivers/pwm/pwm-atmel-hlcdc.c   |   1 +
>  5 files changed, 132 insertions(+), 11 deletions(-)
> 
> -- 
> 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 v10 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs

2019-05-07 Thread Sam Ravnborg
Hi Guido.

Looks good now, stumbled upon a few details I missed in last round.
With these considered / fixed you can add my
Reviewed-by: Sam Ravnborg 

Sam

> +#define CM(x)(   \
> + ((x) <  32)?0xe0|((x)-16) : \
> + ((x) <  64)?0xc0|((x)-32) : \
> + ((x) < 128)?0x80|((x)-64) : \
> + ((x) - 128))
> +#define CN(x)(((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
> +#define CO(x)((CO_BUF)>>(8-(x))&0x3)

A few spaces around the operators may help readability a little.

> +static int phy_write(struct phy *phy, u32 value, unsigned int reg)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = regmap_write(priv->regmap, reg, value);
> + if (ret < 0)
> + dev_err(>dev, "Failed to write DPHY reg %d: %d", reg, ret);

I have recently learned that one has to remember trailign "\n"- please
add.
Check all other dev_xxx as I noticed the newline is missing in a few
more places.

> +
> + dev_dbg(>dev, "hs_clk/ref_clk=%ld/%ld ⩰ %d/%d\n",
   ^

There was another of the symbols my terminal cannot show.

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

Re: [PATCH v2 2/3] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel

2019-05-07 Thread Sam Ravnborg
On Tue, May 07, 2019 at 06:37:07PM +0530, Jagan Teki wrote:
> HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> resolution. It has built in Goodix, GT9271 captive touchscreen
> with backlight adjustable via PWM.
> 
> Add support for it.
> 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Rob Herring 
> Signed-off-by: Jagan Teki 

Patch applied to drm-misc-next

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

Re: [PATCH v2 1/3] dt-bindings: display: Document FriendlyELEC HD702E LCD panel

2019-05-07 Thread Sam Ravnborg
On Tue, May 07, 2019 at 06:37:06PM +0530, Jagan Teki wrote:
> HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> resolution. It has built in Goodix, GT9271 captive touchscreen
> with backlight adjustable via PWM.
> 
> Add dt-bindings documentation for it.
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Rob Herring 
> Signed-off-by: Jagan Teki 

Patch applied to drm-misc-next

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

[PATCH v1 0/3] drm/msm: Add dependencies for per-instance pagetables

2019-05-07 Thread Jordan Crouse
These are a few support changes in advance of per-instance pagetables. These
can be added to msm-next immediately since they don't require anything external
support and they are mostly benign on their own without the more aggressive
changes coming up later.

Jordan Crouse (3):
  drm/msm/adreno: Enable 64 bit mode by default on a5xx and a6xx targets
  drm/msm: Print all 64 bits of the faulting IOMMU address
  drm/msm: Pass the MMU domain index in struct msm_file_private

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 ++
 drivers/gpu/drm/msm/msm_drv.c |  2 ++
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_gem.h |  1 +
 drivers/gpu/drm/msm/msm_gem_submit.c  | 13 -
 drivers/gpu/drm/msm/msm_gpu.c |  5 ++---
 drivers/gpu/drm/msm/msm_iommu.c   |  2 +-
 8 files changed, 43 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[PATCH v1 2/3] drm/msm: Print all 64 bits of the faulting IOMMU address

2019-05-07 Thread Jordan Crouse
When we move to 64 bit addressing for a5xx and a6xx targets we will start
seeing pagefaults at larger addresses so format them appropriately in the
log message for easier debugging.

Signed-off-by: Jordan Crouse 
---

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

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 12bb54c..1926329 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -30,7 +30,7 @@ static int msm_fault_handler(struct iommu_domain *domain, 
struct device *dev,
struct msm_iommu *iommu = arg;
if (iommu->base.handler)
return iommu->base.handler(iommu->base.arg, iova, flags);
-   pr_warn_ratelimited("*** fault: iova=%08lx, flags=%d\n", iova, flags);
+   pr_warn_ratelimited("*** fault: iova=%16lx, flags=%d\n", iova, flags);
return 0;
 }
 
-- 
2.7.4

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

[PATCH v1 3/3] drm/msm: Pass the MMU domain index in struct msm_file_private

2019-05-07 Thread Jordan Crouse
Pass the index of the MMU domain in struct msm_file_private instead
of assuming gpu->id throughout the submit path. This clears the way
to change ctx->aspace to a per-instance pagetable.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c|  2 ++
 drivers/gpu/drm/msm/msm_drv.h|  1 +
 drivers/gpu/drm/msm/msm_gem.h|  1 +
 drivers/gpu/drm/msm/msm_gem_submit.c | 13 -
 drivers/gpu/drm/msm/msm_gpu.c|  5 ++---
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 154dab0..cac101f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -611,6 +611,7 @@ static void load_gpu(struct drm_device *dev)
 
 static int context_init(struct drm_device *dev, struct drm_file *file)
 {
+   struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx;
 
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -619,6 +620,7 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
 
msm_submitqueue_init(dev, ctx);
 
+   ctx->aspace = priv->gpu->aspace;
file->driver_priv = ctx;
 
return 0;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index bbf739d..07ae89f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -68,6 +68,7 @@ struct msm_file_private {
rwlock_t queuelock;
struct list_head submitqueues;
int queueid;
+   struct msm_gem_address_space *aspace;
 };
 
 enum msm_mdp_plane_property {
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c5ac781..1c75310 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -145,6 +145,7 @@ void msm_gem_free_work(struct work_struct *work);
 struct msm_gem_submit {
struct drm_device *dev;
struct msm_gpu *gpu;
+   struct msm_gem_address_space *aspace;
struct list_head node;   /* node in ring submit list */
struct list_head bo_list;
struct ww_acquire_ctx ticket;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 648e0c1..e19e083 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -32,8 +32,9 @@
 #define BO_PINNED   0x2000
 
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-   struct msm_gpu *gpu, struct msm_gpu_submitqueue *queue,
-   uint32_t nr_bos, uint32_t nr_cmds)
+   struct msm_gpu *gpu, struct msm_gem_address_space *aspace,
+   struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
+   uint32_t nr_cmds)
 {
struct msm_gem_submit *submit;
uint64_t sz = sizeof(*submit) + ((u64)nr_bos * sizeof(submit->bos[0])) +
@@ -47,6 +48,7 @@ static struct msm_gem_submit *submit_create(struct drm_device 
*dev,
return NULL;
 
submit->dev = dev;
+   submit->aspace = aspace;
submit->gpu = gpu;
submit->fence = NULL;
submit->cmd = (void *)>bos[nr_bos];
@@ -160,7 +162,7 @@ static void submit_unlock_unpin_bo(struct msm_gem_submit 
*submit,
struct msm_gem_object *msm_obj = submit->bos[i].obj;
 
if (submit->bos[i].flags & BO_PINNED)
-   msm_gem_unpin_iova(_obj->base, submit->gpu->aspace);
+   msm_gem_unpin_iova(_obj->base, submit->aspace);
 
if (submit->bos[i].flags & BO_LOCKED)
ww_mutex_unlock(_obj->resv->lock);
@@ -264,7 +266,7 @@ static int submit_pin_objects(struct msm_gem_submit *submit)
 
/* if locking succeeded, pin bo: */
ret = msm_gem_get_and_pin_iova(_obj->base,
-   submit->gpu->aspace, );
+   submit->aspace, );
 
if (ret)
break;
@@ -477,7 +479,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
}
}
 
-   submit = submit_create(dev, gpu, queue, args->nr_bos, args->nr_cmds);
+   submit = submit_create(dev, gpu, ctx->aspace, queue, args->nr_bos,
+   args->nr_cmds);
if (!submit) {
ret = -ENOMEM;
goto out_unlock;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index bf4ee27..0a4c77f 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -684,7 +684,7 @@ static void retire_submit(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring,
struct msm_gem_object *msm_obj = submit->bos[i].obj;
/* move to inactive: */
msm_gem_move_to_inactive(_obj->base);
-   msm_gem_unpin_iova(_obj->base, gpu->aspace);
+   msm_gem_unpin_iova(_obj->base, submit->aspace);
drm_gem_object_put(_obj->base);
}
 
@@ -768,8 +768,7 @@ void msm_gpu_submit(struct msm_gpu *gpu, 

[PATCH v1 1/3] drm/msm/adreno: Enable 64 bit mode by default on a5xx and a6xx targets

2019-05-07 Thread Jordan Crouse
A5XX and newer GPUs can be run in either 32 or 64 bit mode. The GPU
registers and the microcode use 64 bit virtual addressing in either
case but the upper 32 bits are ignored if the GPU is in 32 bit mode.
There is no performance disadvantage to remaining in 64 bit mode even
if we are only generating 32 bit addresses so switch over now to prepare
for using addresses above 4G on targets that support them.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index e5fcefa..43a2b4a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -642,6 +642,20 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
REG_A5XX_RBBM_SECVID_TSB_TRUSTED_BASE_HI, 0x);
gpu_write(gpu, REG_A5XX_RBBM_SECVID_TSB_TRUSTED_SIZE, 0x);
 
+   /* Put the GPU into 64 bit by default */
+   gpu_write(gpu, REG_A5XX_CP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VSC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_GRAS_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_RB_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_PC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_HLSQ_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VFD_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VPC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_UCHE_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_SP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_TPL1_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_RBBM_SECVID_TSB_ADDR_MODE_CNTL, 0x1);
+
ret = adreno_hw_init(gpu);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ec24508..360c070 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -391,6 +391,20 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
REG_A6XX_RBBM_SECVID_TSB_TRUSTED_BASE_HI, 0x);
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_TRUSTED_SIZE, 0x);
 
+   /* Turn on 64 bit addressing for all blocks */
+   gpu_write(gpu, REG_A6XX_CP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_VSC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_GRAS_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_RB_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_PC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_HLSQ_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_VFD_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_VPC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_UCHE_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_SP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_TPL1_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_ADDR_MODE_CNTL, 0x1);
+
/* enable hardware clockgating */
a6xx_set_hwcg(gpu, true);
 
-- 
2.7.4

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

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

2019-05-07 Thread Theodore Ts'o
On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote:
> > My understanding is that the intent of KUnit is to avoid booting a kernel on
> > real hardware or in a virtual machine.  That seems to be a matter of 
> > semantics
> > to me because isn't invoking a UML Linux just running the Linux kernel in
> > a different form of virtualization?
> > 
> > So I do not understand why KUnit is an improvement over kselftest.
> > 
> > It seems to me that KUnit is just another piece of infrastructure that I
> > am going to have to be familiar with as a kernel developer.  More overhead,
> > more information to stuff into my tiny little brain.
> > 
> > I would guess that some developers will focus on just one of the two test
> > environments (and some will focus on both), splitting the development
> > resources instead of pooling them on a common infrastructure.
> > 
> > What am I missing?
> 
> kselftest provides no in-kernel framework for testing kernel code
> specifically.  That should be what kunit provides, an "easy" way to
> write in-kernel tests for things.
> 
> Brendan, did I get it right?

Yes, that's basically right.  You don't *have* to use KUnit.  It's
supposed to be a simple way to run a large number of small tests that
for specific small components in a system.

For example, I currently use xfstests using KVM and GCE to test all of
ext4.  These tests require using multiple 5 GB and 20GB virtual disks,
and it works by mounting ext4 file systems and exercising ext4 through
the system call interfaces, using userspace tools such as fsstress,
fsx, fio, etc.  It requires time overhead to start the VM, create and
allocate virtual disks, etc.  For example, to run a single 3 seconds
xfstest (generic/001), it requires full 10 seconds to run it via
kvm-xfstests.

KUnit is something else; it's specifically intended to allow you to
create lightweight tests quickly and easily, and by reducing the
effort needed to write and run unit tests, hopefully we'll have a lot
more of them and thus improve kernel quality.

As an example, I have a volunteer working on developing KUinit tests
for ext4.  We're going to start by testing the ext4 extent status
tree.  The source code is at fs/ext4/extent_status.c; it's
approximately 1800 LOC.  The Kunit tests for the extent status tree
will exercise all of the corner cases for the various extent status
tree functions --- e.g., ext4_es_insert_delayed_block(),
ext4_es_remove_extent(), ext4_es_cache_extent(), etc.  And it will do
this in isolation without our needing to create a test file system or
using a test block device.

Next we'll test the ext4 block allocator, again in isolation.  To test
the block allocator we will have to write "mock functions" which
simulate reading allocation bitmaps from disk.  Again, this will allow
the test writer to explicitly construct corner cases and validate that
the block allocator works as expected without having to reverese
engineer file system data structures which will force a particular
code path to be executed.

So this is why it's largely irrelevant to me that KUinit uses UML.  In
fact, it's a feature.  We're not testing device drivers, or the
scheduler, or anything else architecture-specific.  UML is not about
virtualization.  What it's about in this context is allowing us to
start running test code as quickly as possible.  Booting KVM takes
about 3-4 seconds, and this includes initializing virtio_scsi and
other device drivers.  If by using UML we can hold the amount of
unnecessary kernel subsystem initialization down to the absolute
minimum, and if it means that we can communicating to the test
framework via a userspace "printf" from UML/KUnit code, as opposed to
via a virtual serial port to KVM's virtual console, it all makes for
lighter weight testing.

Why did I go looking for a volunteer to write KUnit tests for ext4?
Well, I have a plan to make some changes in restructing how ext4's
write path works, in order to support things like copy-on-write, a
more efficient delayed allocation system, etc.  This will require
making changes to the extent status tree, and by having unit tests for
the extent status tree, we'll be able to detect any bugs that we might
accidentally introduce in the es tree far more quickly than if we
didn't have those tests available.  Google has long found that having
these sorts of unit tests is a real win for developer velocity for any
non-trivial code module (or C++ class), even when you take into
account the time it takes to create the unit tests.

- Ted

P.S.  Many thanks to Brendan for finding such a volunteer for me; the
person in question is a SRE from Switzerland who is interested in
getting involved with kernel testing, and this is going to be their
20% project.  :-)

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

[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #90 from komqin...@zoho.eu ---
Created attachment 144188
  --> https://bugs.freedesktop.org/attachment.cgi?id=144188=edit
Geany without a bug

-- 
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 v15 11/17] drm/amdgpu, arm64: untag user pointers

2019-05-07 Thread Kuehling, Felix
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In amdgpu_gem_userptr_ioctl() and amdgpu_amdkfd_gpuvm.c/init_user_pages()
> an MMU notifier is set up with a (tagged) userspace pointer. The untagged
> address should be used so that MMU notifiers for the untagged address get
> correctly matched up with the right BO. This patch untag user pointers in
> amdgpu_gem_userptr_ioctl() for the GEM case and in amdgpu_amdkfd_gpuvm_
> alloc_memory_of_gpu() for the KFD case. This also makes sure that an
> untagged pointer is passed to amdgpu_ttm_tt_get_user_pages(), which uses
> it for vma lookups.
>
> Suggested-by: Kuehling, Felix 
> Signed-off-by: Andrey Konovalov 

Acked-by: Felix Kuehling 


> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c  | 2 ++
>   2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 1921dec3df7a..20cac44ed449 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1121,7 +1121,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>  alloc_flags = 0;
>  if (!offset || !*offset)
>  return -EINVAL;
> -   user_addr = *offset;
> +   user_addr = untagged_addr(*offset);
>  } else if (flags & ALLOC_MEM_FLAGS_DOORBELL) {
>  domain = AMDGPU_GEM_DOMAIN_GTT;
>  alloc_domain = AMDGPU_GEM_DOMAIN_CPU;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index d21dd2f369da..985cb82b2aa6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -286,6 +286,8 @@ int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void 
> *data,
>  uint32_t handle;
>  int r;
>
> +   args->addr = untagged_addr(args->addr);
> +
>  if (offset_in_page(args->addr | args->size))
>  return -EINVAL;
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #89 from komqin...@zoho.eu ---
Created attachment 144187
  --> https://bugs.freedesktop.org/attachment.cgi?id=144187=edit
Bug in Geany

-- 
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 v15 12/17] drm/radeon, arm64: untag user pointers in radeon_gem_userptr_ioctl

2019-05-07 Thread Kuehling, Felix
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In radeon_gem_userptr_ioctl() an MMU notifier is set up with a (tagged)
> userspace pointer. The untagged address should be used so that MMU
> notifiers for the untagged address get correctly matched up with the right
> BO. This funcation also calls radeon_ttm_tt_pin_userptr(), which uses
> provided user pointers for vma lookups, which can only by done with
> untagged pointers.
>
> This patch untags user pointers in radeon_gem_userptr_ioctl().
>
> Signed-off-by: Andrey Konovalov 
Acked-by: Felix Kuehling 


> ---
>   drivers/gpu/drm/radeon/radeon_gem.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 44617dec8183..90eb78fb5eb2 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -291,6 +291,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
> *data,
>  uint32_t handle;
>  int r;
>
> +   args->addr = untagged_addr(args->addr);
> +
>  if (offset_in_page(args->addr | args->size))
>  return -EINVAL;
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 10/11] drm/hdcp: update content protection property with uevent

2019-05-07 Thread Ramalingam C
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.

Need ACK for the uevent from userspace consumer.

v2:
  Update only when state is different from old one.
v3:
  KDoc is added [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_hdcp.c | 32 
 include/drm/drm_hdcp.h |  2 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 75402463466b..f29b7abda51f 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -372,6 +372,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
  *
  * The content protection will be set to 
_connector_state.content_protection
  *
+ * When kernel triggered content protection state change like DESIRED->ENABLED
+ * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to 
update
+ * the content protection state of a connector.
+ *
  * Returns:
  * Zero on success, negative errno on failure.
  */
@@ -412,3 +416,31 @@ int drm_connector_attach_content_protection_property(
return 0;
 }
 EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+/**
+ * drm_hdcp_update_content_protection - Updates the content protection state
+ * of a connector
+ *
+ * @connector: drm_connector on which content protection state needs an update
+ * @val: New state of the content protection property
+ *
+ * This function can be used by display drivers, to update the kernel triggered
+ * content protection state change of a drm_connector. This function update the
+ * new state of the property into the connector's state and generate an uevent
+ * to notify the userspace.
+ */
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+   u64 val)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_connector_state *state = connector->state;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+   if (state->content_protection == val)
+   return;
+
+   state->content_protection = val;
+   drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2970abdfaf12..dd864ac9ce85 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
 u8 *ksvs, u32 ksv_count);
 int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+   u64 val);
 #endif
-- 
2.19.1

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

[PATCH v7 11/11] drm/i915: update the hdcp state with uevent

2019-05-07 Thread Ramalingam C
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.

Hence whenever kernel changes the property state, userspace will be
updated with a uevent.

Need a ACK for uevent generating uAPI from userspace.

v2:
  state update is moved into drm function [daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 69522687b2cb..8abd69551ead 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -865,7 +865,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
   prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
-   struct drm_connector_state *state;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
mutex_lock(>mutex);
@@ -875,10 +874,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
 * those to UNDESIRED is handled by core. If value == UNDESIRED,
 * we're running just after hdcp has been disabled, so just exit
 */
-   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   state = connector->base.state;
-   state->content_protection = hdcp->value;
-   }
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   drm_hdcp_update_content_protection(>base,
+  hdcp->value);
 
mutex_unlock(>mutex);
drm_modeset_unlock(>mode_config.connection_mutex);
-- 
2.19.1

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

[PATCH v7 06/11] drm/hdcp: gathering hdcp related code into drm_hdcp.c

2019-05-07 Thread Ramalingam C
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.

v2:
  Rebased.
v2:
  Rebased.

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_connector.c | 44 --
 drivers/gpu/drm/drm_hdcp.c  | 47 +
 include/drm/drm_connector.h |  2 --
 include/drm/drm_hdcp.h  |  3 +++
 4 files changed, 50 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..764c7903edf6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
-   { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
-   { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
-   { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
 static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1515,43 +1508,6 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
 
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * The content protection will be set to 
_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
-   struct drm_connector *connector)
-{
-   struct drm_device *dev = connector->dev;
-   struct drm_property *prop =
-   dev->mode_config.content_protection_property;
-
-   if (!prop)
-   prop = drm_property_create_enum(dev, 0, "Content Protection",
-   drm_cp_enum_list,
-   ARRAY_SIZE(drm_cp_enum_list));
-   if (!prop)
-   return -ENOMEM;
-
-   drm_object_attach_property(>base, prop,
-  DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-   dev->mode_config.content_protection_property = prop;
-
-   return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
 /**
  * drm_mode_create_aspect_ratio_property - create aspect ratio property
  * @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e5409505c31..0da7b3718bad 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -17,6 +17,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 struct hdcp_srm {
u32 revoked_ksv_cnt;
@@ -331,3 +334,47 @@ void drm_teardown_hdcp_srm(struct class *drm_class)
kfree(srm_data);
}
 }
+
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+   { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+   { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+   { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * The content protection will be set to 
_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop =
+   dev->mode_config.content_protection_property;
+
+   if (!prop)
+   prop = drm_property_create_enum(dev, 0, "Content Protection",
+   drm_cp_enum_list,
+   ARRAY_SIZE(drm_cp_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(>base, prop,
+  

[PATCH v7 05/11] drm/i915: SRM revocation check for HDCP1.4 and 2.2

2019-05-07 Thread Ramalingam C
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.

v2:
  Rebased.
v3:
  %s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
  unwanted noise is removed.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 45 ++-
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index c308dfee9ca4..53df2f2376e8 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -491,9 +491,11 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port 
*intel_dig_port,
 
 /* Implements Part 2 of the HDCP authorization procedure */
 static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   const struct intel_hdcp_shim *shim = connector->hdcp.shim;
+   struct drm_device *dev = connector->base.dev;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
 
@@ -532,6 +534,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (ret)
goto err;
 
+   if (drm_hdcp_check_ksvs_revoked(dev, ksv_fifo, num_downstream)) {
+   DRM_ERROR("Revoked Ksv(s) in ksv_fifo\n");
+   return -EPERM;
+   }
+
/*
 * When V prime mismatches, DP Spec mandates re-read of
 * V prime atleast twice.
@@ -558,9 +565,12 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
 }
 
 /* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   struct drm_device *dev = connector->base.dev;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -626,6 +636,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
if (ret < 0)
return ret;
 
+   if (drm_hdcp_check_ksvs_revoked(dev, bksv.shim, 1)) {
+   DRM_ERROR("BKSV is revoked\n");
+   return -EPERM;
+   }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
 
@@ -699,7 +714,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
 
if (repeater_present)
-   return intel_hdcp_auth_downstream(intel_dig_port, shim);
+   return intel_hdcp_auth_downstream(connector);
 
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -762,7 +777,7 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
 
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
-   ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
+   ret = intel_hdcp_auth(connector);
if (!ret) {
hdcp->hdcp_encrypted = true;
return 0;
@@ -1161,6 +1176,7 @@ static int hdcp2_authentication_key_exchange(struct 
intel_connector *connector)
 {
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+   struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_ake_init ake_init;
struct hdcp2_ake_send_cert send_cert;
@@ -1195,6 +1211,12 @@ static int hdcp2_authentication_key_exchange(struct 
intel_connector *connector)
 
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
 
+   if (drm_hdcp_check_ksvs_revoked(dev, msgs.send_cert.cert_rx.receiver_id,
+   1)) {
+   DRM_ERROR("Receiver ID is revoked\n");
+   return -EPERM;
+   }
+
/*
 * Here msgs.no_stored_km will hold msgs corresponding to the km
 * stored also.
@@ -1347,13 +1369,14 @@ int hdcp2_authenticate_repeater_topology(struct 
intel_connector *connector)
 {
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+   struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_rep_send_receiverid_list recvid_list;
struct hdcp2_rep_send_ack rep_ack;
} msgs;
const 

[PATCH v7 07/11] drm: Add Content protection type property

2019-05-07 Thread Ramalingam C
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.

Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.

So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.

Need ACK for this new conenctor property from userspace consumer.

v2:
  cp_content_type is replaced with content_protection_type [daniel]
  check at atomic_set_property is removed [Maarten]
v3:
  %s/content_protection_type/hdcp_content_type [Pekka]
v4:
  property is created for the first requested connector and then reused.
[Danvet]
v5:
  kernel doc nits addressed [Daniel]
  Rebased as part of patch reordering.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 
 drivers/gpu/drm/drm_connector.c   | 18 
 drivers/gpu/drm/drm_hdcp.c| 36 ++-
 drivers/gpu/drm/i915/intel_hdcp.c |  4 +++-
 include/drm/drm_connector.h   |  7 ++
 include/drm/drm_hdcp.h|  2 +-
 include/drm/drm_mode_config.h |  6 ++
 include/uapi/drm/drm_mode.h   |  4 
 8 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4131e669785a..a85f3ccfe699 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == config->hdcp_content_type_property) {
+   state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+   } else if (property == config->hdcp_content_type_property) {
+   *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 764c7903edf6..de9e06583e8c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -955,6 +955,24 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
  *   the value transitions from ENABLED to DESIRED. This signifies the link
  *   is no longer protected and userspace should take appropriate action
  *   (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * to be displayed stream's content type. Content Type of a stream is
+ * decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ *   - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ *   - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Note that the HDCP Content Type property is specific to HDCP 2.2, and
+ * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2
+ * If content type is changed when content_protection is not UNDESIRED,
+ * then kernel will disable the HDCP and re-enable with new type in the
+ * same atomic commit
  *
  * max bpc:
  * This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 0da7b3718bad..75402463466b 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -342,23 +342,41 @@ static struct drm_prop_enum_list drm_cp_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
 
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+   { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+   { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+drm_hdcp_content_type_enum_list)
+
 /**
  * drm_connector_attach_content_protection_property - attach content protection
  * 

[PATCH v7 02/11] drm/i915: debugfs: HDCP2.2 capability read

2019-05-07 Thread Ramalingam C
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"

This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
 drivers/gpu/drm/i915/intel_hdcp.c   |  2 +-
 drivers/gpu/drm/i915/intel_hdcp.h   |  1 +
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..c15d3f3bb8e0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4753,6 +4753,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file 
*m, void *data)
 {
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+   bool hdcp_cap, hdcp2_cap;
 
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4763,8 +4764,16 @@ static int i915_hdcp_sink_capability_show(struct 
seq_file *m, void *data)
 
seq_printf(m, "%s:%d HDCP version: ", connector->name,
   connector->base.id);
-   seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
-  "None" : "HDCP1.4");
+   hdcp_cap = intel_hdcp_capable(intel_connector);
+   hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+   if (hdcp_cap)
+   seq_puts(m, "HDCP1.4 ");
+   if (hdcp2_cap)
+   seq_puts(m, "HDCP2.2 ");
+
+   if (!hdcp_cap && !hdcp2_cap)
+   seq_puts(m, "None");
seq_puts(m, "\n");
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index ca5982e45e3e..b8c8d6d1a33d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,7 +79,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
 }
 
 /* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.h 
b/drivers/gpu/drm/i915/intel_hdcp.h
index a75f25f09d39..be8da85c866a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/intel_hdcp.h
@@ -25,6 +25,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
 int intel_hdcp_disable(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
 void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
 void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
 void intel_hdcp_cleanup(struct intel_connector *connector);
-- 
2.19.1

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

[PATCH v7 09/11] drm: uevent for connector status change

2019-05-07 Thread Ramalingam C
DRM API for generating uevent for a status changes of connector's
property.

This uevent will have following details related to the status change:

  HOTPLUG=1, CONNECTOR= and PROPERTY=

Need ACK from this uevent from userspace consumer.

v2:
  Minor fixes at KDoc comments [Daniel]
v3:
  Check the property is really attached with connector [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_sysfs.c | 35 +++
 include/drm/drm_sysfs.h |  5 -
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..63fa951a20db 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include "drm_internal.h"
+#include "drm_crtc_internal.h"
 
 #define to_drm_minor(d) dev_get_drvdata(d)
 #define to_drm_connector(d) dev_get_drvdata(d)
@@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
  * Send a uevent for the DRM device specified by @dev.  Currently we only
  * set HOTPLUG=1 in the uevent environment, but this could be expanded to
  * deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
  */
 void drm_sysfs_hotplug_event(struct drm_device *dev)
 {
@@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_sysfs_hotplug_event);
 
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev.  Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+   struct drm_device *dev = connector->dev;
+   char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+   char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+   WARN_ON(!drm_mode_obj_find_prop_id(>base,
+  property->base.id));
+
+   snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+   snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+   DRM_DEBUG("generating connector status event\n");
+
+   kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
 static void drm_sysfs_release(struct device *dev)
 {
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
 
 struct drm_device;
 struct device;
+struct drm_connector;
+struct drm_property;
 
 int drm_class_device_register(struct device *dev);
 void drm_class_device_unregister(struct device *dev);
 
 void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
 #endif
-- 
2.19.1

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

[PATCH v7 01/11] drm: move content protection property to mode_config

2019-05-07 Thread Ramalingam C
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 ++--
 drivers/gpu/drm/drm_connector.c   | 13 +++--
 include/drm/drm_connector.h   |  6 --
 include/drm/drm_mode_config.h |  6 ++
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 428d82662dc4..4131e669785a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -732,7 +732,7 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
-   } else if (property == connector->content_protection_property) {
+   } else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
@@ -814,7 +814,7 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
-   } else if (property == connector->content_protection_property) {
+   } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..7c0eda9cca60 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
-   struct drm_property *prop;
+   struct drm_property *prop =
+   dev->mode_config.content_protection_property;
 
-   prop = drm_property_create_enum(dev, 0, "Content Protection",
-   drm_cp_enum_list,
-   ARRAY_SIZE(drm_cp_enum_list));
+   if (!prop)
+   prop = drm_property_create_enum(dev, 0, "Content Protection",
+   drm_cp_enum_list,
+   ARRAY_SIZE(drm_cp_enum_list));
if (!prop)
return -ENOMEM;
 
drm_object_attach_property(>base, prop,
   DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-
-   connector->content_protection_property = prop;
+   dev->mode_config.content_protection_property = prop;
 
return 0;
 }
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f43f40d5888a..2186eec0408b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1065,12 +1065,6 @@ struct drm_connector {
 */
struct drm_property *vrr_capable_property;
 
-   /**
-* @content_protection_property: DRM ENUM property for content
-* protection. See drm_connector_attach_content_protection_property().
-*/
-   struct drm_property *content_protection_property;
-
/**
 * @colorspace_property: Connector property to set the suitable
 * colorspace supported by the sink.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8eb269a..5764ee3c7453 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
 */
struct drm_property *writeback_out_fence_ptr_property;
 
+   /**
+* @content_protection_property: DRM ENUM property for content
+* protection. See drm_connector_attach_content_protection_property().
+*/
+   struct drm_property *content_protection_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
2.19.1

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

[PATCH v7 08/11] drm/i915: Attach content type property

2019-05-07 Thread Ramalingam C
Attaches the content type property for HDCP2.2 capable connectors.

Implements the update of content type from property and apply the
restriction on HDCP version selection.

Need ACK for content type property from userspace consumer.

v2:
  s/cp_content_type/content_protection_type [daniel]
  disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
  s/content_protection_type/hdcp_content_type [Pekka]
v4:
  hdcp disable incase of type change is moved into commit [daniel].
v5:
  Simplified the Type change procedure. [Daniel]
v6:
  Type change with UNDESIRED state is ignored.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 39 +++-
 drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
 drivers/gpu/drm/i915/intel_hdcp.h |  2 +-
 3 files changed, 62 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd5277d98b03..0ffba18613b2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3490,7 +3490,8 @@ static void intel_enable_ddi(struct intel_encoder 
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector));
+   intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
 }
 
 static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3559,15 +3560,41 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
  const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state)
 {
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   bool content_protection_type_changed =
+   (conn_state->hdcp_content_type != hdcp->content_type &&
+conn_state->content_protection !=
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
 
+   /*
+* During the HDCP encryption session if Type change is requested,
+* disable the HDCP and reenable it with new TYPE value.
+*/
if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector));
-   else if (conn_state->content_protection ==
-DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
-   intel_hdcp_disable(to_intel_connector(conn_state->connector));
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+   content_protection_type_changed)
+   intel_hdcp_disable(connector);
+
+   /*
+* Mark the hdcp state as DESIRED after the hdcp disable of type
+* change procedure.
+*/
+   if (content_protection_type_changed) {
+   mutex_lock(>mutex);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   mutex_unlock(>mutex);
+   }
+
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+   content_protection_type_changed)
+   intel_hdcp_enable(connector, (u8)conn_state->hdcp_content_type);
 }
 
 static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index be6c81addca0..69522687b2cb 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1748,14 +1748,15 @@ static const struct component_ops 
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
 };
 
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+   const struct intel_hdcp_shim *shim)
 {
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
 
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
-   data->protocol = (u8)hdcp->shim->protocol;
+   data->protocol = (u8)shim->protocol;
 
data->k = 1;
if (!data->streams)
@@ -1805,12 +1806,13 @@ void intel_hdcp_component_init(struct drm_i915_private 
*dev_priv)
}
 }
 
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector *connector,
+const struct intel_hdcp_shim 

[PATCH v7 00/11] HDCP2.2 Phase II

2019-05-07 Thread Ramalingam C
This series adds the content type capability for HDCP through a
drm connetor proeprty "HDCP Content Type". By default this property will
be "Type 0". And this property is exposed by the drivers which has the
HDCP2.2 capability to enable the userspace to configure for "Type 1".

HDCP Content Type:
This property is used to indicate the content type
classification of a stream. Which indicate the HDCP version required
for the rendering of that streams. This conten type is one of the
parameter in the HDCP2.2 authentication flow, as even downstream
repeaters will mandate the HDCP version requirement.

Two values possible for content type of a stream:
Type 0: Stream can be rendered only on HDCP encrypted link no
restriction on HDCP versions.
Type 1: Stream can be rendered only on HDCP2.2 encrypted link.

And also this series adds a uevent for a change in the property state
change of a connector. This helps the userspace to monitor the uevent
for a property state change than the trivial polling.

Userspace consumer for above "HDCP Content Type" property and uevent is
almost at the last phase of review at #wayland community. So Patches 
7, 8, 9, 10 and 11 can be merged only when patches in #wayland community
receives the ACK.

HDCP SRM is implemented through request_firmware() interface. Hence
userspace is expected to write the signature validated latest available
SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP
authentication kernel will read the SRM from above mentioned file and
do the revocation check.

And also this series gathers all HDCP related DRM code into drm_hdcp.c

Thanks Daniel Vetter for all the reviews.

v7:
  few suggestions in SRM handling at drm is addressed [Daniel]
  A prep patch is added.
  fix at content_type attachment is added.

Series can be cloned from github
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v7

Test-with: <20190502131625.27551-2-ramalinga...@intel.com>

Ramalingam C (11):
  drm: move content protection property to mode_config
  drm/i915: debugfs: HDCP2.2 capability read
  drm: generic fn converting be24 to cpu and vice versa
  drm: revocation check at drm subsystem
  drm/i915: SRM revocation check for HDCP1.4 and 2.2
  drm/hdcp: gathering hdcp related code into drm_hdcp.c
  drm: Add Content protection type property
  drm/i915: Attach content type property
  drm: uevent for connector status change
  drm/hdcp: update content protection property with uevent
  drm/i915: update the hdcp state with uevent

 Documentation/gpu/drm-kms-helpers.rst |   6 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic_uapi.c |   8 +-
 drivers/gpu/drm/drm_connector.c   |  61 ++--
 drivers/gpu/drm/drm_hdcp.c| 446 ++
 drivers/gpu/drm/drm_internal.h|   4 +
 drivers/gpu/drm/drm_sysfs.c   |  37 +++
 drivers/gpu/drm/i915/i915_debugfs.c   |  13 +-
 drivers/gpu/drm/i915/intel_ddi.c  |  39 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 105 --
 drivers/gpu/drm/i915/intel_hdcp.h |   3 +-
 drivers/misc/mei/hdcp/mei_hdcp.c  |   2 +-
 include/drm/drm_connector.h   |  15 +-
 include/drm/drm_hdcp.h|  33 +-
 include/drm/drm_mode_config.h |  12 +
 include/drm/drm_sysfs.h   |   5 +-
 include/uapi/drm/drm_mode.h   |   4 +
 17 files changed, 698 insertions(+), 97 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hdcp.c

-- 
2.19.1

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

[PATCH v7 04/11] drm: revocation check at drm subsystem

2019-05-07 Thread Ramalingam C
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin

SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)

This patch handles the HDCP1.4 and 2.2 versions of SRM table.

v2:
  moved the uAPI to request_firmware_direct() [Daniel]
v3:
  kdoc added. [Daniel]
  srm_header unified and bit field definitions are removed. [Daniel]
  locking improved. [Daniel]
  vrl length violation is fixed. [Daniel]
v4:
  s/__swab16/be16_to_cpu [Daniel]
  be24_to_cpu is done through a global func [Daniel]
  Unused variables are removed. [Daniel]
  unchecked return values are dropped from static funcs [Daniel]

Signed-off-by: Ramalingam C 
Acked-by: Satyeshwar Singh 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |   6 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_hdcp.c| 333 ++
 drivers/gpu/drm/drm_internal.h|   4 +
 drivers/gpu/drm/drm_sysfs.c   |   2 +
 include/drm/drm_hdcp.h|  24 ++
 6 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_hdcp.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..0fe726a6ee67 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -181,6 +181,12 @@ Panel Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
 
+HDCP Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+   :export:
+
 Display Port Helper Functions Reference
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dd02e9dec810 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.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_writeback.o drm_client.o \
-   drm_atomic_uapi.o
+   drm_atomic_uapi.o drm_hdcp.o
 
 drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
drm_dma.o drm_scatter.o drm_lock.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..5e5409505c31
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+struct hdcp_srm {
+   u32 revoked_ksv_cnt;
+   u8 *revoked_ksv_list;
+
+   /* Mutex to protect above struct member */
+   struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const u8 *ksv)
+{
+   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
+ ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
+}
+
+static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+   while (parsed_bytes < vrls_length) {
+   vrl_ksv_cnt = *buf;
+   ksv_count += vrl_ksv_cnt;
+
+   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+   buf += vrl_sz;
+   parsed_bytes += vrl_sz;
+   }
+
+   /*
+* When vrls are not valid, ksvs are not considered.
+* Hence SRM will be discarded.
+*/
+   if (parsed_bytes != vrls_length)
+   ksv_count = 0;
+
+   return ksv_count;
+}
+
+static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
+u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0;
+   u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+   do {
+   vrl_ksv_cnt = *buf;
+   vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+   buf++;
+
+   DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+   memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
+
+   ksv_count += vrl_ksv_cnt;
+   revoked_ksv_list += vrl_ksv_sz;
+   buf += vrl_ksv_sz;
+
+   parsed_bytes += (vrl_ksv_sz + 1);
+   } while (parsed_bytes < vrls_length);
+
+   return ksv_count;
+}
+
+static inline u32 get_vrl_length(const u8 *buf)
+{
+   return drm_hdcp_be24_to_cpu(buf);
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+{
+   struct hdcp_srm_header *header;
+   u32 vrl_length, ksv_count;
+
+   if (count < (sizeof(struct hdcp_srm_header) +
+  

[PATCH v7 03/11] drm: generic fn converting be24 to cpu and vice versa

2019-05-07 Thread Ramalingam C
Existing functions for converting a 3bytes(be24) of big endian value
into u32 of little endian and vice versa are renamed as

s/drm_hdcp2_seq_num_to_u32/drm_hdcp_be24_to_cpu
s/drm_hdcp2_u32_to_seq_num/drm_hdcp_cpu_to_be24

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
cc: Tomas Winkler 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 5 +++--
 drivers/misc/mei/hdcp/mei_hdcp.c  | 2 +-
 include/drm/drm_hdcp.h| 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b8c8d6d1a33d..c308dfee9ca4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1305,7 +1305,7 @@ int hdcp2_propagate_stream_management_info(struct 
intel_connector *connector)
 
/* Prepare RepeaterAuth_Stream_Manage msg */
msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
-   drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+   drm_hdcp_cpu_to_be24(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
 
/* K no of streams is fixed as 1. Stored as big-endian. */
msgs.stream_manage.k = cpu_to_be16(1);
@@ -1370,7 +1370,8 @@ int hdcp2_authenticate_repeater_topology(struct 
intel_connector *connector)
}
 
/* Converting and Storing the seq_num_v to local variable as DWORD */
-   seq_num_v = drm_hdcp2_seq_num_to_u32(msgs.recvid_list.seq_num_v);
+   seq_num_v =
+   drm_hdcp_be24_to_cpu((const u8 *)msgs.recvid_list.seq_num_v);
 
if (seq_num_v < hdcp->seq_num_v) {
/* Roll over of the seq_num_v from repeater. Reauthenticate. */
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 90b6ae8e9dae..2f192d6d8b54 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -576,7 +576,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
 
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
   HDCP_2_2_MPRIME_LEN);
-   drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+   drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data->seq_num_m);
memcpy(verify_mprime_in.streams, data->streams,
   (data->k * sizeof(struct hdcp2_streamid_type)));
 
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index f243408ecf26..1cc66df05a43 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -252,13 +252,13 @@ struct hdcp2_rep_stream_ready {
  * host format and back
  */
 static inline
-u32 drm_hdcp2_seq_num_to_u32(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
+u32 drm_hdcp_be24_to_cpu(const u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
 {
return (u32)(seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16);
 }
 
 static inline
-void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
+void drm_hdcp_cpu_to_be24(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
 {
seq_num[0] = val >> 16;
seq_num[1] = val >> 8;
-- 
2.19.1

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

Re: [PATCH RE-RESEND 1/2] drm/panel: Add support for Armadeus ST0700 Adapt

2019-05-07 Thread Sam Ravnborg
Hi Fabio

On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote:
> [Adding Sam, who is helping to review/collect panel-simple patches]
> 
> On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
>  wrote:
> >
> > This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> > Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> > that it can be connected on the TFT header of Armadeus Dev boards.
> >
> > Cc: sta...@vger.kernel.org # v4.19
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Sébastien Szymanski 
Reviewed-by: Sam Ravnborg 

If you wil lresend the patch I can apply it.
I have lost the original mail.

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

Re: [PATCH] drm/cma-helper: Fix drm_gem_cma_free_object()

2019-05-07 Thread Noralf Trønnes
Hi,

Could someone please have a look at this one?

Noralf.

Den 26.04.2019 14.47, skrev Noralf Trønnes:
> The logic for freeing an imported buffer with a virtual address is
> broken. It will free the buffer instead of unmapping the dma buf.
> Fix by reversing the if ladder and first check if the buffer is imported.
> 
> Fixes: b9068cde51ee ("drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS")
> Cc: sta...@vger.kernel.org
> Reported-by: "Li, Tingqian" 
> Signed-off-by: Noralf Trønnes 
> ---
> 
>  drivers/gpu/drm/drm_gem_cma_helper.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index cc26625b4b33..e01ceed09e67 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -186,13 +186,13 @@ void drm_gem_cma_free_object(struct drm_gem_object 
> *gem_obj)
>  
>   cma_obj = to_drm_gem_cma_obj(gem_obj);
>  
> - if (cma_obj->vaddr) {
> - dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
> - cma_obj->vaddr, cma_obj->paddr);
> - } else if (gem_obj->import_attach) {
> + if (gem_obj->import_attach) {
>   if (cma_obj->vaddr)
>   dma_buf_vunmap(gem_obj->import_attach->dmabuf, 
> cma_obj->vaddr);
>   drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
> + } else if (cma_obj->vaddr) {
> + dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
> + cma_obj->vaddr, cma_obj->paddr);
>   }
>  
>   drm_gem_object_release(gem_obj);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix timestamp docs for variable refresh properties.

2019-05-07 Thread Alex Deucher
On Tue, May 7, 2019 at 1:15 AM Mario Kleiner  wrote:
>
> Nag nag: The below documentation patch, acked-by Daniel and r-b'd by
> Nicholas seems to not have made it into drm-next yet?

Pushed to drm-misc-next-fixes

Thanks!

Alex

>
> thanks,
> -mario
>
> On Thu, Apr 18, 2019 at 2:45 PM Kazlauskas, Nicholas
>  wrote:
> >
> > On 4/18/19 2:01 AM, Mario Kleiner wrote:
> > > As discussed with Nicholas and Daniel Vetter (patchwork
> > > link to discussion below), the VRR timestamping behaviour
> > > produced utterly useless and bogus vblank/pageflip
> > > timestamps. We have found a way to fix this and provide
> > > sane behaviour.
> > >
> > > As of Linux 5.2, the amdgpu driver will be able to
> > > provide exactly the same vblank / pageflip timestamp
> > > semantic in variable refresh rate mode as in standard
> > > fixed refresh rate mode. This is achieved by deferring
> > > core vblank handling (drm_crtc_handle_vblank()) until
> > > the end of front porch, and also defer the sending of
> > > pageflip completion events until end of front porch,
> > > when we can safely compute correct pageflip/vblank
> > > timestamps.
> > >
> > > The same approach will be possible for other VRR
> > > capable kms drivers, so we can actually have sane
> > > and useful timestamps in VRR mode.
> > >
> > > This patch removes the section of the docs that
> > > describes the broken timestamp behaviour present
> > > in Linux 5.0/5.1.
> > >
> > > Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> > > Link: https://patchwork.freedesktop.org/patch/285333/
> > > Signed-off-by: Mario Kleiner 
> >
> > Reviewed-by: Nicholas Kazlauskas 
> >
> > Someone else can feel free to push this as I don't have commit rights
> > for DRM.
> >
> > Thanks!
> >
> > Nicholas Kazlauskas
> >
> > > ---
> > >   drivers/gpu/drm/drm_connector.c | 6 --
> > >   1 file changed, 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_connector.c 
> > > b/drivers/gpu/drm/drm_connector.c
> > > index 2355124849db..b34c3d38bf15 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1416,12 +1416,6 @@ 
> > > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> > >*
> > >*  The driver may place further restrictions within these minimum
> > >*  and maximum bounds.
> > > - *
> > > - *   The semantics for the vertical blank timestamp differ when
> > > - *   variable refresh rate is active. The vertical blank timestamp
> > > - *   is defined to be an estimate using the current mode's fixed
> > > - *   refresh rate timings. The semantics for the page-flip event
> > > - *   timestamp remain the same.
> > >*/
> > >
> > >   /**
> > >
> >
> ___
> 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: XORG Endless Vacation of Code

2019-05-07 Thread Daniel Vetter
Fix up to mean the evoc list, not the event list.
-Daniel

On Tue, May 7, 2019 at 5:34 PM Daniel Vetter  wrote:
>
> Adding evoc list.
> -Daniel
>
> On Tue, May 7, 2019 at 3:28 PM Karthik Guru  wrote:
> >
> > Hey
> >
> > Could you please tell me if applications are open for XORG EVOC?
> >
> > Also, whats the procedure for writing a proposal for any of the projects
> >
> > Thanks!
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
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 RE-RESEND 2/2] ARM: dts: opos6uldev: use OF graph to describe the display

2019-05-07 Thread Fabio Estevam
Hi Sébastien,

On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
 wrote:
>
> To make use of the new eLCDIF DRM driver OF graph description is
> required. Describe the display using OF graph nodes.
>
> Cc: sta...@vger.kernel.org # v4.19

The Cc to stable applies to bugfixes, which is not the case here.

With such tag removed:

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

Re: XORG Endless Vacation of Code

2019-05-07 Thread Daniel Vetter
Adding evoc list.
-Daniel

On Tue, May 7, 2019 at 3:28 PM Karthik Guru  wrote:
>
> Hey
>
> Could you please tell me if applications are open for XORG EVOC?
>
> Also, whats the procedure for writing a proposal for any of the projects
>
> Thanks!
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
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 RE-RESEND 1/2] drm/panel: Add support for Armadeus ST0700 Adapt

2019-05-07 Thread Fabio Estevam
[Adding Sam, who is helping to review/collect panel-simple patches]

On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
 wrote:
>
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be connected on the TFT header of Armadeus Dev boards.
>
> Cc: sta...@vger.kernel.org # v4.19
> Reviewed-by: Rob Herring 
> Signed-off-by: Sébastien Szymanski 
> ---
>  .../display/panel/armadeus,st0700-adapt.txt   |  9 ++
>  drivers/gpu/drm/panel/panel-simple.c  | 29 +++
>  2 files changed, 38 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt 
> b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
> new file mode 100644
> index ..a30d63db3c8f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
> @@ -0,0 +1,9 @@
> +Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
> +an adapter board.
> +
> +Required properties:
> +- compatible: "armadeus,st0700-adapt"
> +- power-supply: see panel-common.txt
> +
> +Optional properties:
> +- backlight: see panel-common.txt
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..45ca8d10b66f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -446,6 +446,32 @@ static const struct panel_desc ampire_am800480r3tmqwa1h 
> = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
>  };
>
> +static const struct display_timing santek_st0700i5y_rbslw_f_timing = {
> +   .pixelclock = { 2640, 3330, 4680 },
> +   .hactive = { 800, 800, 800 },
> +   .hfront_porch = { 16, 210, 354 },
> +   .hback_porch = { 45, 36, 6 },
> +   .hsync_len = { 1, 10, 40 },
> +   .vactive = { 480, 480, 480 },
> +   .vfront_porch = { 7, 22, 147 },
> +   .vback_porch = { 22, 13, 3 },
> +   .vsync_len = { 1, 10, 20 },
> +   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> +   DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE
> +};
> +
> +static const struct panel_desc armadeus_st0700_adapt = {
> +   .timings = _st0700i5y_rbslw_f_timing,
> +   .num_timings = 1,
> +   .bpc = 6,
> +   .size = {
> +   .width = 154,
> +   .height = 86,
> +   },
> +   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> +   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +};
> +
>  static const struct drm_display_mode auo_b101aw03_mode = {
> .clock = 51450,
> .hdisplay = 1024,
> @@ -2544,6 +2570,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "arm,rtsm-display",
> .data = _rtsm,
> +   }, {
> +   .compatible = "armadeus,st0700-adapt",
> +   .data = _st0700_adapt,
> }, {
> .compatible = "auo,b101aw03",
> .data = _b101aw03,
> --
> 2.19.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

2019-05-07 Thread shuah

On 5/7/19 2:01 AM, Greg KH wrote:

On Mon, May 06, 2019 at 08:14:12PM -0700, Frank Rowand wrote:

On 5/1/19 4:01 PM, Brendan Higgins wrote:

## TLDR

I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
5.2.

Shuah, I think you, Greg KH, and myself talked off thread, and we agreed
we would merge through your tree when the time came? Am I remembering
correctly?

## Background

This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.

Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace running on a host
kernel. Additionally, KUnit is fast: From invocation to completion KUnit
can run several dozen tests in under a second. Currently, the entire
KUnit test suite for KUnit runs in under a second from the initial
invocation (build time excluded).

KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.


As a result of the emails replying to this patch thread, I am now
starting to look at kselftest.  My level of understanding is based
on some slide presentations, an LWN article, https://kselftest.wiki.kernel.org/
and a _tiny_ bit of looking at kselftest code.

tl;dr; I don't really understand kselftest yet.


(1) why KUnit exists


## What's so special about unit testing?

A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.


(2) KUnit is not meant to replace kselftest


## Is KUnit trying to replace other testing frameworks for the kernel?

No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.


My understanding is that the intent of KUnit is to avoid booting a kernel on
real hardware or in a virtual machine.  That seems to be a matter of semantics
to me because isn't invoking a UML Linux just running the Linux kernel in
a different form of virtualization?

So I do not understand why KUnit is an improvement over kselftest.


They are in two different categories. Kselftest falls into black box
regression test suite which is a collection of user-space tests with a
few kernel test modules back-ending the tests in some cases.

Kselftest can be used by both kernel developers and users and provides
a good way to regression test releases in test rings.

KUnit is a white box category and is a better fit as unit test framework
for development and provides a in-kernel testing. I wouldn't view them
one replacing the other. They just provide coverage for different areas
of testing.

I wouldn't view KUnit as something that would be easily run in test 
rings for example.


Brendan, does that sound about right?



It seems to me that KUnit is just another piece of infrastructure that I
am going to have to be familiar with as a kernel developer.  More overhead,
more information to stuff into my tiny little brain.

I would guess that some developers will focus on just one of the two test
environments (and some will focus on both), splitting the development
resources instead of pooling them on a common infrastructure.



What am I missing?


kselftest provides no in-kernel framework for testing kernel code
specifically.  That should be what kunit provides, an "easy" way to
write in-kernel tests for things.

Brendan, did I get it right?

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

Re: [v8 02/10] drm: Parse HDR metadata info from EDID

2019-05-07 Thread Kazlauskas, Nicholas
On 4/9/19 12:44 PM, Uma Shankar wrote:
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
> 
> v2: Rebase and added Ville's POC changes to the patch.
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments
> 
> v5: Addressed Shashank's comment and added his RB.
> 
> v6: Addressed Jonas Karlman review comments.
> 
> Signed-off-by: Uma Shankar 
> Reviewed-by: Shashank Sharma 
> ---
>   drivers/gpu/drm/drm_edid.c | 52 
> ++
>   1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2c22ea4..1fc371b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2830,6 +2830,7 @@ static int drm_cvt_modes(struct drm_connector 
> *connector,
>   #define VIDEO_BLOCK 0x02
>   #define VENDOR_BLOCK0x03
>   #define SPEAKER_BLOCK   0x04
> +#define HDR_STATIC_METADATA_BLOCK0x6
>   #define USE_EXTENDED_TAG 0x07
>   #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>   #define EXT_VIDEO_DATA_BLOCK_4200x0E
> @@ -3577,6 +3578,12 @@ static int add_3d_struct_modes(struct drm_connector 
> *connector, u16 structure,
>   }
>   
>   static int
> +cea_db_payload_len_ext(const u8 *db)
> +{
> + return (db[0] & 0x1f) - 1;
> +}
> +
> +static int
>   cea_db_extended_tag(const u8 *db)
>   {
>   return db[1];
> @@ -3812,6 +3819,49 @@ static void fixup_detailed_cea_mode_clock(struct 
> drm_display_mode *mode)
>   mode->clock = clock;
>   }
>   
> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != HDR_STATIC_METADATA_BLOCK)
> + return false;

Shouldn't this just be cea_db_extended_tag(db) != HDR_STATIC_METADATA_BLOCK?

Also, the other functions all check that we're given a valid here here with:

if (!cea_db_payload_len_ext(db))
 return false;

Is there any reason this isn't done here?


> +
> + return true;
> +}
> +
> +static uint8_t eotf_supported(const u8 *edid_ext)
> +{
> + return edid_ext[2] &
> + (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
> +  BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
> +  BIT(HDMI_EOTF_SMPTE_ST2084));
> +}
> +
> +static uint8_t hdr_metadata_type(const u8 *edid_ext)
> +{
> + return edid_ext[3] &
> + BIT(HDMI_STATIC_METADATA_TYPE1);
> +}
> +
> +static void
> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
> +{
> + u16 len;
> +
> + len = cea_db_payload_len_ext(db);
> + connector->hdr_sink_metadata.hdmi_type1.eotf = eotf_supported(db);
> + connector->hdr_sink_metadata.hdmi_type1.metadata_type =
> + hdr_metadata_type(db);

While metadata_type is assigned here like it should be, it isn't 
assigned to the outer metadata_type in the hdr_sink_metadata. I also 
can't see anything in the other patches that assigns this anywhere.

Shouldn't it also be set here?

> +
> + if (len >= 4)
> + connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
> + if (len >= 5)
> + connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
> + if (len >= 6)
> + connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6];
> +}
> +
>   static void
>   drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
>   {
> @@ -4439,6 +4489,8 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   drm_parse_y420cmdb_bitmap(connector, db);
>   if (cea_db_is_vcdb(db))
>   drm_parse_vcdb(connector, db);
> + if (cea_db_is_hdmi_hdr_metadata_block(db))
> + drm_parse_hdr_metadata_block(connector, db);
>   }
>   }
>   
> 

Nicholas Kazlauskas

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

[Bug 110635] briefly flashing corruption when playing various OGL games

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110635

Bug ID: 110635
   Summary: briefly flashing corruption when playing various OGL
games
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tempel.jul...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

I'm seeing briefly flashing corruption in various OGL games, mostly Dying Light
and Counter-Strike Global Offensive Danger Zone. But I once also saw it in
X-Plane 11.
Happens with Mesa 18 and git and llvm 8 and git, but likely also even older
versions in both cases.

I was able to capture it by recording a video and then extracting an affected
frame:
https://abload.de/img/mpv-shot0001hkjyr.png

Across the aforementioned games, the artifacts look akin or the same. Can also
be brighter squares though.

Hardware issue is unlikely, as radv / amdvlk never show this issue (and Windows
driver neither).

I fail to see a pattern when this corruption occurs, it seems like total chance
to me while gaming.

This is with an RX 580 on Arch.

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

XORG Endless Vacation of Code

2019-05-07 Thread Karthik Guru
Hey

Could you please tell me if applications are open for XORG EVOC?

Also, whats the procedure for writing a proposal for any of the projects

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

Re: [PATCH] gpu/drm: Remove duplicate headers

2019-05-07 Thread Sam Ravnborg
On Tue, May 07, 2019 at 12:05:32PM +0200, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 04:43:34PM +0200, Daniel Vetter wrote:
> > On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> > > From: Jagadeesh Pagadala 
> > > 
> > > Remove duplicate headers which are included twice.
> > > 
> > > Signed-off-by: Jagadeesh Pagadala 
> > 
> > I collected some acks for the msm and nouveau parts and pushed this. For
> > next time around would be great if you split these up along driver/module
> > boundaries, so that each maintainer can pick this up directly.
> > 
> > Thanks for your patch.
> > -Daniel
> > 
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c| 2 --
> > >  drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -
> 
> Correction, this didn't compile, so I dropped the changes to panel-rpi.
> Another reason to split patches more for next time around. Also, needs
> more compile testing (you need cross compilers for at least arm to test
> this stuff).
I will try to resurrect my patch series for drm/panel/ that
addresses:
- removal of drmP.h
- removal of duplicated include files
- sort all include files

In other words - panel-raspberrypi-touchscreen.c will be dealt with.
I expect to look at it in two weeks time (on vacation starting friday).

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

Re: [PATCH 1/2] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel

2019-05-07 Thread Jagan Teki
On Mon, May 6, 2019 at 8:34 PM Rob Herring  wrote:
>
> On Mon, May 6, 2019 at 4:56 AM Jagan Teki  wrote:
> >
> > Hi Sam,
> >
> > On Thu, May 2, 2019 at 1:04 AM Sam Ravnborg  wrote:
> > >
> > > Hi Jagan
> > >
> > > On Wed, May 01, 2019 at 05:44:47PM +0530, Jagan Teki wrote:
> > > > HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> > > > resolution. It has built in Goodix, GT9271 captive touchscreen
> > > > with backlight adjustable via PWM.
> > > >
> > > > Add support for it.
> > > >
> > > > Cc: Thierry Reding 
> > > > Cc: Sam Ravnborg 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Signed-off-by: Jagan Teki 
> > >
> > > Please submit the binding in a separate patch as per
> > > Documentation/devicetree/bindings/submitting-patches.txt
> >
> > Hmm.. prepared like this initially but few of my patches were combined
> > earlier even-though I sent it separately. anyway let me separate it
> > again.
>
> For what subsystem? All the maintainers that I was aware of doing that
> have stopped.

May be it was recent, Dmitry combined by previous dt and driver changes.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae97fb589648cd5558f1ceea317404a639307501
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a5f50c501321249d67611353dde6d68d48c5b959
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DO NOT MERGE] [PATCH v2 3/3] arm64: rockchip: rk3399: nanopc-t4: Enable FriendlyELEC HD702E eDP panel

2019-05-07 Thread Jagan Teki
FriendlyELEC HD702E is one of optional LCD panel for
NanoPC T4 eDP interface.

It features 800x1280 resolutions, with built in GT9271 captive
touchscreen and adjustable backlight via PWM.

eDP panel connections are:
- VCC3V3_SYS: 3.3V panel power supply
- GPIO4_C2: PWM0_BL pin
- GPIO4_D5_LCD_BL_EN: Backlight enable pin
- VCC12V0_SYS: 12V backlight power supply
- Touchscreen connected via I2C4
- GPIO1_C4_TP_INT: touchscreen interrupt pin
- GPIO1_B5_TP_RST: touchscreen reset pin

Signed-off-by: Jagan Teki 
---
Changes for v2:
- use force-hpd and delete-property for edp
- use generic backlight brightness
- add simple-panel fallback compatible

 .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 50 +++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index 931c3dbf1b7d..4cacd09658dc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -46,6 +46,14 @@
};
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;/* 
GPIO4_D5_LCD_BL_EN */
+   pwms = < 0 25000 0>;
+   power-supply = <_sys>;
+   status = "okay";
+   };
+
ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
@@ -64,6 +72,18 @@
fan-supply = <_sys>;
pwms = < 0 5 0>;
};
+
+   panel {
+   compatible ="friendlyarm,hd702e", "simple-panel";
+   backlight = <>;
+   power-supply = <_sys>;
+
+   port {
+   panel_in_edp: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
 };
 
 _thermal {
@@ -94,6 +114,25 @@
};
 };
 
+ {
+   status = "okay";
+   force-hpd;
+   /delete-property/ pinctrl-0;
+
+   ports {
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   edp_out_panel: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_edp>;
+   };
+   };
+   };
+};
+
 _thermal {
trips {
gpu_warm: gpu_warm {
@@ -130,6 +169,17 @@
};
 };
 
+ {
+   touchscreen@5d {
+   compatible = "goodix,gt911";
+   reg = <0x5d>;
+   interrupt-parent = <>;
+   interrupts = ;
+   irq-gpio = < RK_PC4 GPIO_ACTIVE_HIGH>;/* 
GPIO1_C4_TP_INT */
+   reset-gpio = < RK_PB5 GPIO_ACTIVE_LOW>;   /* 
GPIO1_B5_TP_RST */
+   };
+};
+
  {
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v2 2/3] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel

2019-05-07 Thread Jagan Teki
HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
resolution. It has built in Goodix, GT9271 captive touchscreen
with backlight adjustable via PWM.

Add support for it.

Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rob Herring 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- separate it from binding patch
- sort the match id and compatible 

 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..93274e270663 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1184,6 +1184,29 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode friendlyarm_hd702e_mode = {
+   .clock  = 67185,
+   .hdisplay   = 800,
+   .hsync_start= 800 + 20,
+   .hsync_end  = 800 + 20 + 24,
+   .htotal = 800 + 20 + 24 + 20,
+   .vdisplay   = 1280,
+   .vsync_start= 1280 + 4,
+   .vsync_end  = 1280 + 4 + 8,
+   .vtotal = 1280 + 4 + 8 + 4,
+   .vrefresh   = 60,
+   .flags  = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc friendlyarm_hd702e = {
+   .modes = _hd702e_mode,
+   .num_modes = 1,
+   .size = {
+   .width  = 94,
+   .height = 151,
+   },
+};
+
 static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -2637,6 +2660,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
+   }, {
+   .compatible = "friendlyarm,hd702e",
+   .data = _hd702e,
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v2 1/3] dt-bindings: display: Document FriendlyELEC HD702E LCD panel

2019-05-07 Thread Jagan Teki
HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
resolution. It has built in Goodix, GT9271 captive touchscreen
with backlight adjustable via PWM.

Add dt-bindings documentation for it.
Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rob Herring 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- separate binding patch from driver
- Add simple-panel compatible as fallback
- Add text info about simple-panel bindings

 .../display/panel/friendlyarm,hd702e.txt  | 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt 
b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
new file mode 100644
index ..6c9156fc3478
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
@@ -0,0 +1,32 @@
+FriendlyELEC HD702E 800x1280 LCD panel
+
+HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
+resolution. It has built in Goodix, GT9271 captive touchscreen
+with backlight adjustable via PWM.
+
+Required properties:
+- compatible: should be "friendlyarm,hd702e"
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LCD panel input.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Example:
+
+   panel {
+   compatible ="friendlyarm,hd702e", "simple-panel";
+   backlight = <>;
+   power-supply = <_sys>;
+
+   port {
+   panel_in_edp: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
-- 
2.18.0.321.gffc6fa0e3

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

[Bug 105819] Window system hang due to GPU Fault

2019-05-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105819

--- Comment #12 from xom  ---
Only solution to this problem I have found is to downgrade to LTS 4.14 kernel.
GPU has never had any issues in windows.  

Linux abyss 4.14.116-1-lts414 #1 SMP Tue May 7 01:33:27 MDT 2019 x86_64
GNU/Linux

xom[~]$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.19.0,
4.14.116-1-lts414, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.0.3
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

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

RE: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem

2019-05-07 Thread Singh, Satyeshwar
Acked-by: Satyeshwar Singh 

-Original Message-
From: Roper, Matthew D 
Sent: Monday, May 6, 2019 2:59 PM
To: Daniel Vetter 
Cc: C, Ramalingam ; Vetter, Daniel 
; intel-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org; Singh, Satyeshwar 
Subject: Re: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem

On Mon, May 06, 2019 at 06:56:03PM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file 
> > /lib/firmware/display_hdcp_srm.bin
> > 
> > SRM table is parsed and stored at drm_hdcp.c, with functions 
> > exported for the services for revocation check from drivers (which 
> > implements the HDCP authentication)
> > 
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> > 
> > v2:
> >   moved the uAPI to request_firmware_direct() [Daniel]
> > v3:
> >   kdoc added. [Daniel]
> >   srm_header unified and bit field definitions are removed. [Daniel]
> >   locking improved. [Daniel]
> >   vrl length violation is fixed. [Daniel]
> > 
> > Signed-off-by: Ramalingam C 
> > Suggested-by: Daniel Vetter 
> 
> Found a few small details to polish, but looks good to me. With the 
> details addressed:
> 
> Reviewed-by: Daniel Vetter 
> 
> We also still need an ack on the firmware blob approach from Matt 
> Roper or someone else at iotg I think.

+Satyeshwar

Satyeshwar's probably the best person from IOTG to give the Ack since he's part 
of the group that needs this functionality and is involved in the 
userspace/compositor side as well.


Matt

> 
> Cheers, Daniel
> 
> > ---
> >  Documentation/gpu/drm-kms-helpers.rst |   6 +
> >  drivers/gpu/drm/Makefile  |   2 +-
> >  drivers/gpu/drm/drm_hdcp.c| 342 ++
> >  drivers/gpu/drm/drm_internal.h|   4 +
> >  drivers/gpu/drm/drm_sysfs.c   |   2 +
> >  include/drm/drm_hdcp.h|  24 ++
> >  6 files changed, 379 insertions(+), 1 deletion(-)  create mode 
> > 100644 drivers/gpu/drm/drm_hdcp.c
> > 
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 14102ae035dc..0fe726a6ee67 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -181,6 +181,12 @@ Panel Helper Reference  .. kernel-doc:: 
> > drivers/gpu/drm/drm_panel_orientation_quirks.c
> > :export:
> >  
> > +HDCP Helper Functions Reference
> > +===
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> > +   :export:
> > +
> >  Display Port Helper Functions Reference  
> > ===
> >  
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile 
> > index 72f5036d9bfa..dd02e9dec810 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.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_writeback.o drm_client.o \
> > -   drm_atomic_uapi.o
> > +   drm_atomic_uapi.o drm_hdcp.o
> >  
> >  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o 
> > drm_context.o drm_dma.o drm_scatter.o drm_lock.o
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git 
> > a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c new file 
> > mode 100644 index ..dc0e13409221
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C   */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct hdcp_srm {
> > +   u8 *srm_buf;
> 
> Allocated, but seems to not be used.
> 
> > +   size_t received_srm_sz;
> 
> Seems to be unused. Seems to both be leftovers from the sysfs interface.
> 
> > +   u32 revoked_ksv_cnt;
> > +   u8 *revoked_ksv_list;
> > +
> > +   /* Mutex to protect above struct member */
> > +   struct mutex mutex;
> > +} *srm_data;
> > +
> > +static inline void drm_hdcp_print_ksv(const u8 *ksv) {
> > +   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> > + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]); }
> > +
> > +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 
> > +vrls_length) {
> > +   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> > +
> > +   while (parsed_bytes < vrls_length) {
> > +   vrl_ksv_cnt = *buf;
> > +   ksv_count += vrl_ksv_cnt;
> > +
> > +   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> > +   buf += vrl_sz;
> > +   parsed_bytes += vrl_sz;
> > +   }
> > +
> > +   /*
> > +* When vrls are not valid, ksvs are not 

Re: [v8 01/10] drm: Add HDR source metadata property

2019-05-07 Thread Ville Syrjälä
On Tue, May 07, 2019 at 01:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
> > 
> > 
> > >-Original Message-
> > >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> > >Sent: Saturday, May 4, 2019 3:48 PM
> > >To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> > >dri-
> > >de...@lists.freedesktop.org
> > >Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com; 
> > >seanp...@chromium.org;
> > >Syrjala, Ville ; Lankhorst, Maarten
> > >
> > >Subject: Re: [v8 01/10] drm: Add HDR source metadata property
> > >
> > >On 2019-04-09 18:44, Uma Shankar wrote:
> > >> This patch adds a blob property to get HDR metadata information from
> > >> userspace. This will be send as part of AVI Infoframe to panel.
> > >>
> > >> It also implements get() and set() functions for HDR output metadata
> > >> property.The blob data is received from userspace and saved in
> > >> connector state, the same is returned as blob in get property call to
> > >> userspace.
> > >>
> > >> v2: Rebase and modified the metadata structure elements as per Ville's
> > >> POC changes.
> > >>
> > >> v3: No Change
> > >>
> > >> v4: Addressed Shashank's review comments
> > >>
> > >> v5: Rebase.
> > >>
> > >> v6: Addressed Brian Starkey's review comments, defined new structure
> > >> with header for dynamic metadata scalability.
> > >> Merge get/set property functions for metadata in this patch.
> > >>
> > >> v7: Addressed Jonas Karlman review comments and defined separate
> > >> structure for infoframe to better align with CTA 861.G spec. Added
> > >> Shashank's RB.
> > >>
> > >> Signed-off-by: Uma Shankar 
> > >> Reviewed-by: Shashank Sharma 
> > >> ---
> > >>  drivers/gpu/drm/drm_atomic.c  |  2 ++
> > >>  drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> > >>  drivers/gpu/drm/drm_connector.c   |  6 ++
> > >>  include/drm/drm_connector.h   | 11 +++
> > >>  include/drm/drm_mode_config.h |  6 ++
> > >>  include/linux/hdmi.h  | 10 ++
> > >>  include/uapi/drm/drm_mode.h   | 39
> > >+++
> > >>  7 files changed, 87 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_atomic.c
> > >> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
> > >> --- a/drivers/gpu/drm/drm_atomic.c
> > >> +++ b/drivers/gpu/drm/drm_atomic.c
> > >> @@ -881,6 +881,8 @@ static void
> > >> drm_atomic_connector_print_state(struct drm_printer *p,
> > >>
> > >>  drm_printf(p, "connector[%u]: %s\n", connector->base.id, 
> > >> connector-
> > >>name);
> > >>  drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> > >> "(null)");
> > >> +drm_printf(p, "\thdr_metadata_changed=%d\n",
> > >> +   state->hdr_metadata_changed);
> > >>
> > >>  if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> > >>  if (state->writeback_job && state->writeback_job->fb) 
> > >> diff --git
> > >> a/drivers/gpu/drm/drm_atomic_uapi.c
> > >> b/drivers/gpu/drm/drm_atomic_uapi.c
> > >> index ea797d4..6d0d161 100644
> > >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > >> @@ -673,6 +673,8 @@ static int
> > >> drm_atomic_connector_set_property(struct drm_connector *connector,  {
> > >>  struct drm_device *dev = connector->dev;
> > >>  struct drm_mode_config *config = >mode_config;
> > >> +bool replaced = false;
> > >> +int ret;
> > >>
> > >>  if (property == config->prop_crtc_id) {
> > >>  struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); 
> > >> @@ -721,6
> > >> +723,14 @@ static int drm_atomic_connector_set_property(struct 
> > >> drm_connector
> > >*connector,
> > >>   */
> > >>  if (state->link_status != DRM_LINK_STATUS_GOOD)
> > >>  state->link_status = val;
> > >> +} else if (property == config->hdr_output_metadata_property) {
> > >> +ret = drm_atomic_replace_property_blob_from_id(dev,
> > >> +>hdr_output_metadata_blob_ptr,
> > >> +val,
> > >> +-1, sizeof(struct hdr_output_metadata),
> > >> +);
> > >> +state->hdr_metadata_changed |= replaced;
> > >> +return ret;
> > >>  } else if (property == config->aspect_ratio_property) {
> > >>  state->picture_aspect_ratio = val;
> > >>  } else if (property == config->content_type_property) { @@ 
> > >> -807,6
> > >> +817,9 @@ static int drm_atomic_connector_set_property(struct 
> > >> drm_connector
> > >*connector,
> > >>  *val = state->colorspace;
> > >>  } else if (property == connector->scaling_mode_property) {
> > >>  *val = state->scaling_mode;
> > >> +} else if (property == 

Re: [v8 01/10] drm: Add HDR source metadata property

2019-05-07 Thread Ville Syrjälä
On Tue, Apr 09, 2019 at 10:14:35PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
> 
> It also implements get() and set() functions for HDR output
> metadata property.The blob data is received from userspace and
> saved in connector state, the same is returned as blob in get
> property call to userspace.
> 
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments
> 
> v5: Rebase.
> 
> v6: Addressed Brian Starkey's review comments, defined
> new structure with header for dynamic metadata scalability.
> Merge get/set property functions for metadata in this patch.
> 
> v7: Addressed Jonas Karlman review comments and defined separate
> structure for infoframe to better align with CTA 861.G spec. Added
> Shashank's RB.
> 
> Signed-off-by: Uma Shankar 
> Reviewed-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_atomic.c  |  2 ++
>  drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>  drivers/gpu/drm/drm_connector.c   |  6 ++
>  include/drm/drm_connector.h   | 11 +++
>  include/drm/drm_mode_config.h |  6 ++
>  include/linux/hdmi.h  | 10 ++
>  include/uapi/drm/drm_mode.h   | 39 
> +++
>  7 files changed, 87 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5eb4013..8b9c126 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct 
> drm_printer *p,
>  
>   drm_printf(p, "connector[%u]: %s\n", connector->base.id, 
> connector->name);
>   drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
> "(null)");
> + drm_printf(p, "\thdr_metadata_changed=%d\n",
> +state->hdr_metadata_changed);

Is that flag actually useful?

>  
>   if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>   if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ea797d4..6d0d161 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -673,6 +673,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>  {
>   struct drm_device *dev = connector->dev;
>   struct drm_mode_config *config = >mode_config;
> + bool replaced = false;
> + int ret;
>  
>   if (property == config->prop_crtc_id) {
>   struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
> @@ -721,6 +723,14 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>*/
>   if (state->link_status != DRM_LINK_STATUS_GOOD)
>   state->link_status = val;
> + } else if (property == config->hdr_output_metadata_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >hdr_output_metadata_blob_ptr,
> + val,
> + -1, sizeof(struct hdr_output_metadata),
> + );
> + state->hdr_metadata_changed |= replaced;
> + return ret;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
>   } else if (property == config->content_type_property) {
> @@ -807,6 +817,9 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   *val = state->colorspace;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == config->hdr_output_metadata_property) {
> + *val = (state->hdr_output_metadata_blob_ptr) ?

Pointless parens.

> + state->hdr_output_metadata_blob_ptr->base.id : 0;
>   } else if (property == connector->content_protection_property) {
>   *val = state->content_protection;
>   } else if (property == config->writeback_fb_id_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2355124..0bdae90 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.non_desktop_property = prop;
>  
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> 

Re: [v8 08/10] drm/i915:Enabled Modeset when HDR Infoframe changes

2019-05-07 Thread Ville Syrjälä
On Tue, Apr 09, 2019 at 10:14:42PM +0530, Uma Shankar wrote:
> This patch enables modeset whenever HDR metadata
> needs to be updated to sink.
> 
> v2: Addressed Shashank's review comments.
> 
> v3: Added Shashank's RB.
> 
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Uma Shankar 
> Reviewed-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c | 14 +-
>  drivers/gpu/drm/i915/intel_hdmi.c   | 26 ++
>  2 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 8c8fae3..e8b5f84 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -104,6 +104,16 @@ int intel_digital_connector_atomic_set_property(struct 
> drm_connector *connector,
>   return -EINVAL;
>  }
>  
> +static bool blob_equal(const struct drm_property_blob *a,
> +const struct drm_property_blob *b)
> +{
> + if (a && b)
> + return a->length == b->length &&
> + !memcmp(a->data, b->data, a->length);
> +
> + return !a == !b;
> +}

I have a feeling the memcmp() is overkill. We could just check for
whether the blob is the same or not. If userspace is an idiot and
creates a new blob with identical content so be it.

> +
>  int intel_digital_connector_atomic_check(struct drm_connector *conn,
>struct drm_connector_state *new_state)
>  {
> @@ -131,7 +141,9 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>   new_conn_state->base.colorspace != old_conn_state->base.colorspace 
> ||
>   new_conn_state->base.picture_aspect_ratio != 
> old_conn_state->base.picture_aspect_ratio ||
>   new_conn_state->base.content_type != 
> old_conn_state->base.content_type ||
> - new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode)
> + new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode ||
> + !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
> + old_conn_state->base.hdr_output_metadata_blob_ptr))
>   crtc_state->mode_changed = true;
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0ecfda0..85333a7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -799,6 +799,20 @@ void intel_read_infoframe(struct intel_encoder *encoder,
>   return true;
>  }
>  
> +static bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
> +{
> + if (output_eotf == 0)
> + return (sink_eotf & (1 << 0));
> + if (output_eotf == 1)
> + return (sink_eotf & (1 << 1));
> + if (output_eotf == 2)
> + return (sink_eotf & (1 << 2));
> + if (output_eotf == 3)
> + return (sink_eotf & (1 << 3));
> +
> + return false;

return sink_eotf & BIT(output_eotf);

> +}
> +
>  static bool
>  intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
>struct intel_crtc_state *crtc_state,
> @@ -806,11 +820,23 @@ void intel_read_infoframe(struct intel_encoder *encoder,
>  {
>   struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
>   struct hdr_output_metadata *hdr_metadata;
> + struct drm_connector *connector = conn_state->connector;
>   int ret;
>  
> + if (!conn_state->hdr_output_metadata_blob_ptr ||
> + conn_state->hdr_output_metadata_blob_ptr->length == 0)
> + return true;
> +
>   hdr_metadata = (struct hdr_output_metadata *)
>   conn_state->hdr_output_metadata_blob_ptr->data;
>  
> + /* Sink EOTF is Bit map while infoframe is absolute values */
> + if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
> +connector->hdr_sink_metadata.hdmi_type1.eotf)) {
> + DRM_ERROR("EOTF Not Supported\n");
> + return true;
> + }
> +
>   ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
>   if (ret < 0) {
>   DRM_ERROR("couldn't set HDR metadata in infoframe\n");
> -- 
> 1.9.1

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

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-07 Thread Christian König

Am 07.05.19 um 13:45 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user fail to get 
memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need 
memory for (or rather the ww_mutex of its reservation object) has a ticket 
assigned.
3. If we have a ticket we grab a reference to the first BO on the LRU, drop the 
LRU lock and try to grab the reservation lock with the ticket.
4. If getting the reservation lock with the ticket succeeded we check if the BO 
is still the first one on the LRU in question (the BO could have moved).
5. If the BO is still the first one on the LRU in question we try to evict it 
as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible usecase not only 
pinned bo.
v7: pass request bo->resv to ttm_bo_evict_first

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 


Reviewed-by: Christian König 

Please leave me a note when this hits amd-staging-drm-next, cause I need 
to test why it didn't helped with Mareks problem.


Christian.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
  1 file changed, 94 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..f5e6328e4a57 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
   * b. Otherwise, trylock it.
   */
  static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+   struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
  {
bool ret = false;
  
  	*locked = false;

+   if (busy)
+   *busy = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,46 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
} else {
*locked = reservation_object_trylock(bo->resv);
ret = *locked;
+   if (!ret && busy)
+   *busy = true;
}
  
  	return ret;

  }
  
-static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

-  uint32_t mem_type,
-  const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+struct ttm_mem_type_manager *man,
+const struct ttm_place *place,
+struct ttm_operation_ctx *ctx,
+struct ttm_buffer_object **first_bo,
+bool *locked)
  {
-   struct ttm_bo_global *glob = bdev->glob;
-   struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo = NULL;
-   bool locked = false;
-   unsigned i;
-   int ret;
+   int i;
  
-	spin_lock(>lru_lock);

+   if (first_bo)
+   *first_bo = NULL;
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   bool busy = false;
+
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+   )) {
+   if (first_bo && !(*first_bo) && busy) {
+   ttm_bo_get(bo);
+   *first_bo = bo;
+   }
continue;
+   }
  
  			if (place && !bdev->driver->eviction_valuable(bo,

  place)) {
-   if (locked)
+   if (*locked)
reservation_object_unlock(bo->resv);
continue;
}
+
break;
}
  
@@ -818,9 +831,67 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

bo = NULL;
}
  
+	return bo;

+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  struct ttm_operation_ctx *ctx,
+  

[PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-07 Thread Chunming Zhou
heavy gpu job could occupy memory long time, which lead other user fail to get 
memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need 
memory for (or rather the ww_mutex of its reservation object) has a ticket 
assigned.
3. If we have a ticket we grab a reference to the first BO on the LRU, drop the 
LRU lock and try to grab the reservation lock with the ticket.
4. If getting the reservation lock with the ticket succeeded we check if the BO 
is still the first one on the LRU in question (the BO could have moved).
5. If the BO is still the first one on the LRU in question we try to evict it 
as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible usecase not only 
pinned bo.
v7: pass request bo->resv to ttm_bo_evict_first

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
 1 file changed, 94 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..f5e6328e4a57 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  * b. Otherwise, trylock it.
  */
 static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+   struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
 {
bool ret = false;
 
*locked = false;
+   if (busy)
+   *busy = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,46 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
} else {
*locked = reservation_object_trylock(bo->resv);
ret = *locked;
+   if (!ret && busy)
+   *busy = true;
}
 
return ret;
 }
 
-static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-  uint32_t mem_type,
-  const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+struct ttm_mem_type_manager *man,
+const struct ttm_place *place,
+struct ttm_operation_ctx *ctx,
+struct ttm_buffer_object **first_bo,
+bool *locked)
 {
-   struct ttm_bo_global *glob = bdev->glob;
-   struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo = NULL;
-   bool locked = false;
-   unsigned i;
-   int ret;
+   int i;
 
-   spin_lock(>lru_lock);
+   if (first_bo)
+   *first_bo = NULL;
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   bool busy = false;
+
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+   )) {
+   if (first_bo && !(*first_bo) && busy) {
+   ttm_bo_get(bo);
+   *first_bo = bo;
+   }
continue;
+   }
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-   if (locked)
+   if (*locked)
reservation_object_unlock(bo->resv);
continue;
}
+
break;
}
 
@@ -818,9 +831,67 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
bo = NULL;
}
 
+   return bo;
+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  struct ttm_operation_ctx *ctx,
+  struct reservation_object *request_resv)
+{
+   struct ttm_bo_global *glob = bdev->glob;
+   struct ttm_mem_type_manager *man = >man[mem_type];
+   struct ttm_buffer_object *bo = 

[PATCH 2/2] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve

2019-05-07 Thread Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.

Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou 
Reviewed-by: Christian König 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ac22f7351a42..3f36770946ab 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4176,6 +4176,9 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
struct amdgpu_device *adev;
struct amdgpu_bo *rbo;
struct dm_plane_state *dm_plane_state_new, *dm_plane_state_old;
+   struct list_head list;
+   struct ttm_validate_buffer tv;
+   struct ww_acquire_ctx ticket;
uint64_t tiling_flags;
uint32_t domain;
int r;
@@ -4192,9 +4195,17 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
obj = new_state->fb->obj[0];
rbo = gem_to_amdgpu_bo(obj);
adev = amdgpu_ttm_adev(rbo->tbo.bdev);
-   r = amdgpu_bo_reserve(rbo, false);
-   if (unlikely(r != 0))
+   INIT_LIST_HEAD();
+
+   tv.bo = >tbo;
+   tv.num_shared = 1;
+   list_add(, );
+
+   r = ttm_eu_reserve_buffers(, , false, NULL);
+   if (r) {
+   dev_err(adev->dev, "fail to reserve bo (%d)\n", r);
return r;
+   }
 
if (plane->type != DRM_PLANE_TYPE_CURSOR)
domain = amdgpu_display_supported_domains(adev);
@@ -4205,21 +4216,21 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("Failed to pin framebuffer with error %d\n", 
r);
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
return r;
}
 
r = amdgpu_ttm_alloc_gart(>tbo);
if (unlikely(r != 0)) {
amdgpu_bo_unpin(rbo);
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
DRM_ERROR("%p bind failed\n", rbo);
return r;
}
 
amdgpu_bo_get_tiling_flags(rbo, _flags);
 
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
 
afb->address = amdgpu_bo_gpu_offset(rbo);
 
-- 
2.17.1

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

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Thomas Hellstrom

On 5/7/19 1:24 PM, Christian König wrote:

Am 07.05.19 um 13:22 schrieb zhoucm1:



On 2019年05月07日 19:13, Koenig, Christian wrote:

Am 07.05.19 um 13:08 schrieb zhoucm1:


On 2019年05月07日 18:53, Koenig, Christian wrote:

Am 07.05.19 um 11:36 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user
fail to get memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO
we need memory for (or rather the ww_mutex of its reservation
object) has a ticket assigned.
3. If we have a ticket we grab a reference to the first BO on the
LRU, drop the LRU lock and try to grab the reservation lock with the
ticket.
4. If getting the reservation lock with the ticket succeeded we
check if the BO is still the first one on the LRU in question (the
BO could have moved).
5. If the BO is still the first one on the LRU in question we try to
evict it as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return 
-EBUSY.


v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible
usecase not only pinned bo.

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
    drivers/gpu/drm/ttm/ttm_bo.c | 113
++-
    1 file changed, 97 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..bbf1d14d00a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 * b. Otherwise, trylock it.
 */
    static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
-    struct ttm_operation_ctx *ctx, bool *locked)
+    struct ttm_operation_ctx *ctx, bool *locked, bool 
*busy)

    {
    bool ret = false;
       *locked = false;
+    if (busy)
+    *busy = false;
    if (bo->resv == ctx->resv) {
    reservation_object_assert_held(bo->resv);
    if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,45 @@ static bool
ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
    } else {
    *locked = reservation_object_trylock(bo->resv);
    ret = *locked;
+    if (!ret && busy)
+    *busy = true;
    }
       return ret;
    }
    -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+ struct ttm_mem_type_manager *man,
+ const struct ttm_place *place,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_buffer_object **first_bo,
+ bool *locked)
    {
-    struct ttm_bo_global *glob = bdev->glob;
-    struct ttm_mem_type_manager *man = >man[mem_type];
    struct ttm_buffer_object *bo = NULL;
-    bool locked = false;
-    unsigned i;
-    int ret;
+    int i;
    -    spin_lock(>lru_lock);
+    if (first_bo)
+    *first_bo = NULL;
    for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
    list_for_each_entry(bo, >lru[i], lru) {
-    if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+    bool busy = false;
+    if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+    )) {

A newline between declaration and code please.


+    if (first_bo && !(*first_bo) && busy) {
+    ttm_bo_get(bo);
+    *first_bo = bo;
+    }
    continue;
+    }
       if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-    if (locked)
+    if (*locked)
reservation_object_unlock(bo->resv);
    continue;
    }
+
    break;
    }
    @@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
    bo = NULL;
    }
    +    return bo;
+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+   uint32_t mem_type,
+   const struct ttm_place *place,
+   struct ttm_operation_ctx *ctx)
+{
+    struct ttm_bo_global *glob = bdev->glob;
+    struct ttm_mem_type_manager *man = >man[mem_type];
+    struct ttm_buffer_object *bo = NULL, *first_bo = NULL;
+    bool locked = false;
+    int ret;
+
+    spin_lock(>lru_lock);
+    bo = ttm_mem_find_evitable_bo(bdev, man, place, ctx, _bo,
+  );
    if (!bo) {
+    struct ttm_operation_ctx busy_ctx;
+
    spin_unlock(>lru_lock);
-    return 

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Koenig, Christian
Am 07.05.19 um 13:37 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/7/19 1:24 PM, Christian König wrote:
>> Am 07.05.19 um 13:22 schrieb zhoucm1:
>>>
>>>
>>> On 2019年05月07日 19:13, Koenig, Christian wrote:
 Am 07.05.19 um 13:08 schrieb zhoucm1:
>
> On 2019年05月07日 18:53, Koenig, Christian wrote:
>> Am 07.05.19 um 11:36 schrieb Chunming Zhou:
>>> heavy gpu job could occupy memory long time, which lead other user
>>> fail to get memory.
>>>
>>> basically pick up Christian idea:
>>>
>>> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
>>> 2. If we then run into this EBUSY condition in TTM check if the BO
>>> we need memory for (or rather the ww_mutex of its reservation
>>> object) has a ticket assigned.
>>> 3. If we have a ticket we grab a reference to the first BO on the
>>> LRU, drop the LRU lock and try to grab the reservation lock with 
>>> the
>>> ticket.
>>> 4. If getting the reservation lock with the ticket succeeded we
>>> check if the BO is still the first one on the LRU in question (the
>>> BO could have moved).
>>> 5. If the BO is still the first one on the LRU in question we 
>>> try to
>>> evict it as we would evict any other BO.
>>> 6. If any of the "If's" above fail we just back off and return
>>> -EBUSY.
>>>
>>> v2: fix some minor check
>>> v3: address Christian v2 comments.
>>> v4: fix some missing
>>> v5: handle first_bo unlock and bo_get/put
>>> v6: abstract unified iterate function, and handle all possible
>>> usecase not only pinned bo.
>>>
>>> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
>>> Signed-off-by: Chunming Zhou 
>>> ---
>>>     drivers/gpu/drm/ttm/ttm_bo.c | 113
>>> ++-
>>>     1 file changed, 97 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 8502b3ed2d88..bbf1d14d00a7 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>>>  * b. Otherwise, trylock it.
>>>  */
>>>     static bool ttm_bo_evict_swapout_allowable(struct
>>> ttm_buffer_object *bo,
>>> -    struct ttm_operation_ctx *ctx, bool *locked)
>>> +    struct ttm_operation_ctx *ctx, bool *locked, bool
>>> *busy)
>>>     {
>>>     bool ret = false;
>>>    *locked = false;
>>> +    if (busy)
>>> +    *busy = false;
>>>     if (bo->resv == ctx->resv) {
>>> reservation_object_assert_held(bo->resv);
>>>     if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
>>> @@ -779,35 +781,45 @@ static bool
>>> ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
>>>     } else {
>>>     *locked = reservation_object_trylock(bo->resv);
>>>     ret = *locked;
>>> +    if (!ret && busy)
>>> +    *busy = true;
>>>     }
>>>    return ret;
>>>     }
>>>     -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>>> -   uint32_t mem_type,
>>> -   const struct ttm_place *place,
>>> -   struct ttm_operation_ctx *ctx)
>>> +static struct ttm_buffer_object*
>>> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
>>> + struct ttm_mem_type_manager *man,
>>> + const struct ttm_place *place,
>>> + struct ttm_operation_ctx *ctx,
>>> + struct ttm_buffer_object **first_bo,
>>> + bool *locked)
>>>     {
>>> -    struct ttm_bo_global *glob = bdev->glob;
>>> -    struct ttm_mem_type_manager *man = >man[mem_type];
>>>     struct ttm_buffer_object *bo = NULL;
>>> -    bool locked = false;
>>> -    unsigned i;
>>> -    int ret;
>>> +    int i;
>>>     -    spin_lock(>lru_lock);
>>> +    if (first_bo)
>>> +    *first_bo = NULL;
>>>     for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>>>     list_for_each_entry(bo, >lru[i], lru) {
>>> -    if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
>>> +    bool busy = false;
>>> +    if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
>>> +    )) {
>> A newline between declaration and code please.
>>
>>> +    if (first_bo && !(*first_bo) && busy) {
>>> +    ttm_bo_get(bo);
>>> +    *first_bo = bo;
>>> +    }
>>>     continue;
>>> +    }
>>>    if (place && 
>>> !bdev->driver->eviction_valuable(bo,
>>>   place)) {
>>> -    if 

[PATCH libdrm 4/7] add timeline signal/transfer ioctls v2

2019-05-07 Thread Chunming Zhou
v2: use one transfer ioctl

Signed-off-by: Chunming Zhou 
---
 xf86drm.c | 33 +
 xf86drm.h |  6 ++
 2 files changed, 39 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 17e3d880..acd16fab 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4257,6 +4257,21 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t 
*handles,
 return ret;
 }
 
+drm_public int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+   uint64_t *points, uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, );
+return ret;
+}
+
 drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t 
*points,
  unsigned num_handles,
  int64_t timeout_nsec, unsigned flags,
@@ -4299,4 +4314,22 @@ drm_public int drmSyncobjQuery(int fd, uint32_t 
*handles, uint64_t *points,
 return 0;
 }
 
+drm_public int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags)
+{
+struct drm_syncobj_transfer args;
+int ret;
+
+memclear(args);
+args.src_handle = src_handle;
+args.dst_handle = dst_handle;
+args.src_point = src_point;
+args.dst_point = dst_point;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TRANSFER, );
 
+return ret;
+}
diff --git a/xf86drm.h b/xf86drm.h
index 60c7a84f..3fb1d1ca 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,12 +876,18 @@ extern int drmSyncobjWait(int fd, uint32_t *handles, 
unsigned num_handles,
  uint32_t *first_signaled);
 extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t 
handle_count);
 extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t 
handle_count);
+extern int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+   uint64_t *points, uint32_t handle_count);
 extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
  unsigned num_handles,
  int64_t timeout_nsec, unsigned flags,
  uint32_t *first_signaled);
 extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
   uint32_t handle_count);
+extern int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags);
 
 #if defined(__cplusplus)
 }
-- 
2.17.1

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

[PATCH libdrm 6/7] wrap transfer interfaces

2019-05-07 Thread Chunming Zhou
Signed-off-by: Chunming Zhou 
---
 amdgpu/amdgpu.h| 22 ++
 amdgpu/amdgpu_cs.c | 16 
 2 files changed, 38 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index d2480dbe..9d9b0832 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1685,6 +1685,28 @@ int 
amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
uint32_t syncobj,
uint64_t point,
int sync_file_fd);
+
+/**
+ *  transfer between syncbojs.
+ *
+ * \param   dev- \c [in] device handle
+ * \param   dst_handle - \c [in] sync object handle
+ * \param   dst_point  - \c [in] timeline point, 0 presents dst is binary
+ * \param   src_handle - \c [in] sync object handle
+ * \param   src_point  - \c [in] timeline point, 0 presents src is binary
+ * \param   flags  - \c [in] flags
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+  uint32_t dst_handle,
+  uint64_t dst_point,
+  uint32_t src_handle,
+  uint64_t src_point,
+  uint32_t flags);
+
 /**
  * Export an amdgpu fence as a handle (syncobj or fd).
  *
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index daca4421..977fa3cf 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -817,6 +817,22 @@ out:
return ret;
 }
 
+drm_public int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+ uint32_t dst_handle,
+ uint64_t dst_point,
+ uint32_t src_handle,
+ uint64_t src_point,
+ uint32_t flags)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjTransfer(dev->fd,
+ dst_handle, dst_point,
+ src_handle, src_point,
+ flags);
+}
+
 drm_public int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
amdgpu_context_handle context,
amdgpu_bo_list_handle bo_list_handle,
-- 
2.17.1

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

[PATCH libdrm 5/7] expose timeline signal/export/import interfaces v2

2019-05-07 Thread Chunming Zhou
v2: adapt to new one transfer ioctl

Signed-off-by: Chunming Zhou 
---
 amdgpu/amdgpu-symbol-check |  3 ++
 amdgpu/amdgpu.h| 51 
 amdgpu/amdgpu_cs.c | 68 ++
 3 files changed, 122 insertions(+)

diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index d3c5bb89..274b4c6d 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -52,10 +52,13 @@ amdgpu_cs_submit
 amdgpu_cs_submit_raw
 amdgpu_cs_submit_raw2
 amdgpu_cs_syncobj_export_sync_file
+amdgpu_cs_syncobj_export_sync_file2
 amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_import_sync_file2
 amdgpu_cs_syncobj_query
 amdgpu_cs_syncobj_reset
 amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_signal
 amdgpu_cs_syncobj_timeline_wait
 amdgpu_cs_syncobj_wait
 amdgpu_cs_wait_fences
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 5ebfe1e3..d2480dbe 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1516,6 +1516,23 @@ int amdgpu_cs_syncobj_reset(amdgpu_device_handle dev,
 int amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
 const uint32_t *syncobjs, uint32_t syncobj_count);
 
+/**
+ * Signal kernel timeline sync objects.
+ *
+ * \param dev   - \c [in] device handle
+ * \param syncobjs  - \c [in] array of sync object handles
+ * \param points   - \c [in] array of timeline points
+ * \param syncobj_count - \c [in] number of handles in syncobjs
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+ const uint32_t *syncobjs,
+ uint64_t *points,
+ uint32_t syncobj_count);
+
 /**
  *  Wait for one or all sync objects to signal.
  *
@@ -1633,7 +1650,41 @@ int 
amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
 int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
   uint32_t syncobj,
   int sync_file_fd);
+/**
+ *  Export kernel timeline sync object to a sync_file.
+ *
+ * \param   dev- \c [in] device handle
+ * \param   syncobj- \c [in] sync object handle
+ * \param   point  - \c [in] timeline point
+ * \param   flags  - \c [in] flags
+ * \param   sync_file_fd - \c [out] sync_file file descriptor.
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+   uint32_t syncobj,
+   uint64_t point,
+   uint32_t flags,
+   int *sync_file_fd);
 
+/**
+ *  Import kernel timeline sync object from a sync_file.
+ *
+ * \param   dev- \c [in] device handle
+ * \param   syncobj- \c [in] sync object handle
+ * \param   point  - \c [in] timeline point
+ * \param   sync_file_fd - \c [in] sync_file file descriptor.
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
+   uint32_t syncobj,
+   uint64_t point,
+   int sync_file_fd);
 /**
  * Export an amdgpu fence as a handle (syncobj or fd).
  *
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 9fcaf2c4..daca4421 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -674,6 +674,18 @@ drm_public int 
amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
return drmSyncobjSignal(dev->fd, syncobjs, syncobj_count);
 }
 
+drm_public int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+const uint32_t *syncobjs,
+uint64_t *points,
+uint32_t syncobj_count)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjTimelineSignal(dev->fd, syncobjs,
+   points, syncobj_count);
+}
+
 drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
  uint32_t *handles, unsigned num_handles,
  int64_t timeout_nsec, unsigned flags,
@@ -749,6 +761,62 @@ drm_public int 
amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
return drmSyncobjImportSyncFile(dev->fd, syncobj, sync_file_fd);
 }
 
+drm_public int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+  uint32_t syncobj,
+  uint64_t point,
+  uint32_t flags,
+  

[PATCH libdrm 7/7] add syncobj timeline tests v3

2019-05-07 Thread Chunming Zhou
v2: drop DRM_SYNCOBJ_CREATE_TYPE_TIMELINE, fix timeout calculation,
fix some warnings
v3: add export/import and cpu signal testing cases

Signed-off-by: Chunming Zhou 
---
 tests/amdgpu/Makefile.am |   3 +-
 tests/amdgpu/amdgpu_test.c   |  11 ++
 tests/amdgpu/amdgpu_test.h   |  21 +++
 tests/amdgpu/meson.build |   2 +-
 tests/amdgpu/syncobj_tests.c | 290 +++
 5 files changed, 325 insertions(+), 2 deletions(-)
 create mode 100644 tests/amdgpu/syncobj_tests.c

diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 48278848..920882d0 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -34,4 +34,5 @@ amdgpu_test_SOURCES = \
uve_ib.h \
deadlock_tests.c \
vm_tests.c  \
-   ras_tests.c
+   ras_tests.c \
+   syncobj_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 35c8bf6c..73403fb4 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -57,6 +57,7 @@
 #define DEADLOCK_TESTS_STR "Deadlock Tests"
 #define VM_TESTS_STR "VM Tests"
 #define RAS_TESTS_STR "RAS Tests"
+#define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
 
 /**
  *  Open handles for amdgpu devices
@@ -123,6 +124,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_ras_tests_clean,
.pTests = ras_tests,
},
+   {
+   .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+   .pInitFunc = suite_syncobj_timeline_tests_init,
+   .pCleanupFunc = suite_syncobj_timeline_tests_clean,
+   .pTests = syncobj_timeline_tests,
+   },
 
CU_SUITE_INFO_NULL,
 };
@@ -176,6 +183,10 @@ static Suites_Active_Status suites_active_stat[] = {
.pName = RAS_TESTS_STR,
.pActive = suite_ras_tests_enable,
},
+   {
+   .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+   .pActive = suite_syncobj_timeline_tests_enable,
+   },
 };
 
 
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index bcd0bc7e..36675ea3 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -216,6 +216,27 @@ CU_BOOL suite_ras_tests_enable(void);
 extern CU_TestInfo ras_tests[];
 
 
+/**
+ * Initialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_init();
+
+/**
+ * Deinitialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_syncobj_timeline_tests_enable(void);
+
+/**
+ * Tests in syncobj timeline test suite
+ */
+extern CU_TestInfo syncobj_timeline_tests[];
+
+
 /**
  * Helper functions
  */
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 95ed9305..1726cb43 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
 files(
   'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
   'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
-  'vm_tests.c', 'ras_tests.c',
+  'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c',
 ),
 dependencies : [dep_cunit, dep_threads],
 include_directories : [inc_root, inc_drm, 
include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
new file mode 100644
index ..a0c627d7
--- /dev/null
+++ b/tests/amdgpu/syncobj_tests.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include 
+
+static  amdgpu_device_handle device_handle;
+static  uint32_t  major_version;
+static  uint32_t  minor_version;
+
+static void 

[PATCH libdrm 3/7] wrap syncobj timeline query/wait APIs for amdgpu v3

2019-05-07 Thread Chunming Zhou
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection

Signed-off-by: Chunming Zhou 
---
 amdgpu/amdgpu-symbol-check |  2 ++
 amdgpu/amdgpu.h| 39 ++
 amdgpu/amdgpu_cs.c | 23 ++
 3 files changed, 64 insertions(+)

diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 4d806922..d3c5bb89 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -53,8 +53,10 @@ amdgpu_cs_submit_raw
 amdgpu_cs_submit_raw2
 amdgpu_cs_syncobj_export_sync_file
 amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_query
 amdgpu_cs_syncobj_reset
 amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_wait
 amdgpu_cs_syncobj_wait
 amdgpu_cs_wait_fences
 amdgpu_cs_wait_semaphore
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index c44a495a..5ebfe1e3 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1536,6 +1536,45 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
   int64_t timeout_nsec, unsigned flags,
   uint32_t *first_signaled);
 
+/**
+ *  Wait for one or all sync objects on their points to signal.
+ *
+ * \param   dev- \c [in] self-explanatory
+ * \param   handles - \c [in] array of sync object handles
+ * \param   points - \c [in] array of sync points to wait
+ * \param   num_handles - \c [in] self-explanatory
+ * \param   timeout_nsec - \c [in] self-explanatory
+ * \param   flags   - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param   first_signaled - \c [in] self-explanatory
+ *
+ * \return   0 on success\n
+ *  -ETIME - Timeout
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+   uint32_t *handles, uint64_t *points,
+   unsigned num_handles,
+   int64_t timeout_nsec, unsigned flags,
+   uint32_t *first_signaled);
+/**
+ *  Query sync objects payloads.
+ *
+ * \param   dev- \c [in] self-explanatory
+ * \param   handles - \c [in] array of sync object handles
+ * \param   points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param   num_handles - \c [in] self-explanatory
+ *
+ * \return   0 on success\n
+ *  -ETIME - Timeout
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+   uint32_t *handles, uint64_t *points,
+   unsigned num_handles);
+
 /**
  *  Export kernel sync object to shareable fd.
  *
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 7c5b9d13..9fcaf2c4 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -686,6 +686,29 @@ drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle 
dev,
  flags, first_signaled);
 }
 
+drm_public int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+  uint32_t *handles, uint64_t 
*points,
+  unsigned num_handles,
+  int64_t timeout_nsec, unsigned 
flags,
+  uint32_t *first_signaled)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjTimelineWait(dev->fd, handles, points, num_handles,
+ timeout_nsec, flags, first_signaled);
+}
+
+drm_public int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+  uint32_t *handles, uint64_t *points,
+  unsigned num_handles)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjQuery(dev->fd, handles, points, num_handles);
+}
+
 drm_public int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
-- 
2.17.1

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

[PATCH libdrm 2/7] add timeline wait/query ioctl v2

2019-05-07 Thread Chunming Zhou
v2: drop export/import

Signed-off-by: Chunming Zhou 
---
 xf86drm.c | 44 
 xf86drm.h |  6 ++
 2 files changed, 50 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 2c19376b..17e3d880 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4256,3 +4256,47 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t 
*handles,
 ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_SIGNAL, );
 return ret;
 }
+
+drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t 
*points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+struct drm_syncobj_timeline_wait args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.timeout_nsec = timeout_nsec;
+args.count_handles = num_handles;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, );
+if (ret < 0)
+return -errno;
+
+if (first_signaled)
+*first_signaled = args.first_signaled;
+return ret;
+}
+
+
+drm_public int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+  uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, );
+if (ret)
+return ret;
+return 0;
+}
+
+
diff --git a/xf86drm.h b/xf86drm.h
index 887ecc76..60c7a84f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,6 +876,12 @@ extern int drmSyncobjWait(int fd, uint32_t *handles, 
unsigned num_handles,
  uint32_t *first_signaled);
 extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t 
handle_count);
 extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t 
handle_count);
+extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+  uint32_t handle_count);
 
 #if defined(__cplusplus)
 }
-- 
2.17.1

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

[PATCH libdrm 1/7] addr cs chunk for syncobj timeline

2019-05-07 Thread Chunming Zhou
Signed-off-by: Chunming Zhou 
---
 include/drm/amdgpu_drm.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d0701ffc..3d0318e6 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -528,6 +528,8 @@ struct drm_amdgpu_gem_va {
 #define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
 #define AMDGPU_CHUNK_ID_BO_HANDLES  0x06
 #define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x08
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL  0x09
 
 struct drm_amdgpu_cs_chunk {
__u32   chunk_id;
@@ -608,6 +610,13 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
 };
 
+struct drm_amdgpu_cs_chunk_syncobj {
+   __u32 handle;
+   __u32 flags;
+   __u64 point;
+};
+
+
 #define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
 #define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD  1
 #define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
-- 
2.17.1

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

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Christian König

Am 07.05.19 um 13:22 schrieb zhoucm1:



On 2019年05月07日 19:13, Koenig, Christian wrote:

Am 07.05.19 um 13:08 schrieb zhoucm1:


On 2019年05月07日 18:53, Koenig, Christian wrote:

Am 07.05.19 um 11:36 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user
fail to get memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO
we need memory for (or rather the ww_mutex of its reservation
object) has a ticket assigned.
3. If we have a ticket we grab a reference to the first BO on the
LRU, drop the LRU lock and try to grab the reservation lock with the
ticket.
4. If getting the reservation lock with the ticket succeeded we
check if the BO is still the first one on the LRU in question (the
BO could have moved).
5. If the BO is still the first one on the LRU in question we try to
evict it as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return 
-EBUSY.


v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible
usecase not only pinned bo.

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
    drivers/gpu/drm/ttm/ttm_bo.c | 113
++-
    1 file changed, 97 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..bbf1d14d00a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 * b. Otherwise, trylock it.
 */
    static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
-    struct ttm_operation_ctx *ctx, bool *locked)
+    struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
    {
    bool ret = false;
       *locked = false;
+    if (busy)
+    *busy = false;
    if (bo->resv == ctx->resv) {
    reservation_object_assert_held(bo->resv);
    if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,45 @@ static bool
ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
    } else {
    *locked = reservation_object_trylock(bo->resv);
    ret = *locked;
+    if (!ret && busy)
+    *busy = true;
    }
       return ret;
    }
    -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+ struct ttm_mem_type_manager *man,
+ const struct ttm_place *place,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_buffer_object **first_bo,
+ bool *locked)
    {
-    struct ttm_bo_global *glob = bdev->glob;
-    struct ttm_mem_type_manager *man = >man[mem_type];
    struct ttm_buffer_object *bo = NULL;
-    bool locked = false;
-    unsigned i;
-    int ret;
+    int i;
    -    spin_lock(>lru_lock);
+    if (first_bo)
+    *first_bo = NULL;
    for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
    list_for_each_entry(bo, >lru[i], lru) {
-    if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+    bool busy = false;
+    if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+    )) {

A newline between declaration and code please.


+    if (first_bo && !(*first_bo) && busy) {
+    ttm_bo_get(bo);
+    *first_bo = bo;
+    }
    continue;
+    }
       if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-    if (locked)
+    if (*locked)
reservation_object_unlock(bo->resv);
    continue;
    }
+
    break;
    }
    @@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
    bo = NULL;
    }
    +    return bo;
+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+   uint32_t mem_type,
+   const struct ttm_place *place,
+   struct ttm_operation_ctx *ctx)
+{
+    struct ttm_bo_global *glob = bdev->glob;
+    struct ttm_mem_type_manager *man = >man[mem_type];
+    struct ttm_buffer_object *bo = NULL, *first_bo = NULL;
+    bool locked = false;
+    int ret;
+
+    spin_lock(>lru_lock);
+    bo = ttm_mem_find_evitable_bo(bdev, man, place, ctx, _bo,
+  );
    if (!bo) {
+    struct ttm_operation_ctx busy_ctx;
+
    spin_unlock(>lru_lock);
-    return -EBUSY;
+    /* check if other user occupy 

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread zhoucm1



On 2019年05月07日 19:13, Koenig, Christian wrote:

Am 07.05.19 um 13:08 schrieb zhoucm1:


On 2019年05月07日 18:53, Koenig, Christian wrote:

Am 07.05.19 um 11:36 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user
fail to get memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO
we need memory for (or rather the ww_mutex of its reservation
object) has a ticket assigned.
3. If we have a ticket we grab a reference to the first BO on the
LRU, drop the LRU lock and try to grab the reservation lock with the
ticket.
4. If getting the reservation lock with the ticket succeeded we
check if the BO is still the first one on the LRU in question (the
BO could have moved).
5. If the BO is still the first one on the LRU in question we try to
evict it as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible
usecase not only pinned bo.

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
    drivers/gpu/drm/ttm/ttm_bo.c | 113
++-
    1 file changed, 97 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..bbf1d14d00a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
     * b. Otherwise, trylock it.
     */
    static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
-    struct ttm_operation_ctx *ctx, bool *locked)
+    struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
    {
    bool ret = false;
       *locked = false;
+    if (busy)
+    *busy = false;
    if (bo->resv == ctx->resv) {
    reservation_object_assert_held(bo->resv);
    if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,45 @@ static bool
ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
    } else {
    *locked = reservation_object_trylock(bo->resv);
    ret = *locked;
+    if (!ret && busy)
+    *busy = true;
    }
       return ret;
    }
    -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+ struct ttm_mem_type_manager *man,
+ const struct ttm_place *place,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_buffer_object **first_bo,
+ bool *locked)
    {
-    struct ttm_bo_global *glob = bdev->glob;
-    struct ttm_mem_type_manager *man = >man[mem_type];
    struct ttm_buffer_object *bo = NULL;
-    bool locked = false;
-    unsigned i;
-    int ret;
+    int i;
    -    spin_lock(>lru_lock);
+    if (first_bo)
+    *first_bo = NULL;
    for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
    list_for_each_entry(bo, >lru[i], lru) {
-    if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+    bool busy = false;
+    if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+    )) {

A newline between declaration and code please.


+    if (first_bo && !(*first_bo) && busy) {
+    ttm_bo_get(bo);
+    *first_bo = bo;
+    }
    continue;
+    }
       if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-    if (locked)
+    if (*locked)
    reservation_object_unlock(bo->resv);
    continue;
    }
+
    break;
    }
    @@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
    bo = NULL;
    }
    +    return bo;
+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+   uint32_t mem_type,
+   const struct ttm_place *place,
+   struct ttm_operation_ctx *ctx)
+{
+    struct ttm_bo_global *glob = bdev->glob;
+    struct ttm_mem_type_manager *man = >man[mem_type];
+    struct ttm_buffer_object *bo = NULL, *first_bo = NULL;
+    bool locked = false;
+    int ret;
+
+    spin_lock(>lru_lock);
+    bo = ttm_mem_find_evitable_bo(bdev, man, place, ctx, _bo,
+  );
    if (!bo) {
+    struct ttm_operation_ctx busy_ctx;
+
    spin_unlock(>lru_lock);
-    return -EBUSY;
+    /* check if other user occupy memory too long 

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Koenig, Christian
Am 07.05.19 um 13:08 schrieb zhoucm1:
>
>
> On 2019年05月07日 18:53, Koenig, Christian wrote:
>> Am 07.05.19 um 11:36 schrieb Chunming Zhou:
>>> heavy gpu job could occupy memory long time, which lead other user 
>>> fail to get memory.
>>>
>>> basically pick up Christian idea:
>>>
>>> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
>>> 2. If we then run into this EBUSY condition in TTM check if the BO 
>>> we need memory for (or rather the ww_mutex of its reservation 
>>> object) has a ticket assigned.
>>> 3. If we have a ticket we grab a reference to the first BO on the 
>>> LRU, drop the LRU lock and try to grab the reservation lock with the 
>>> ticket.
>>> 4. If getting the reservation lock with the ticket succeeded we 
>>> check if the BO is still the first one on the LRU in question (the 
>>> BO could have moved).
>>> 5. If the BO is still the first one on the LRU in question we try to 
>>> evict it as we would evict any other BO.
>>> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>>>
>>> v2: fix some minor check
>>> v3: address Christian v2 comments.
>>> v4: fix some missing
>>> v5: handle first_bo unlock and bo_get/put
>>> v6: abstract unified iterate function, and handle all possible 
>>> usecase not only pinned bo.
>>>
>>> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
>>> Signed-off-by: Chunming Zhou 
>>> ---
>>>    drivers/gpu/drm/ttm/ttm_bo.c | 113 
>>> ++-
>>>    1 file changed, 97 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 8502b3ed2d88..bbf1d14d00a7 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>>>     * b. Otherwise, trylock it.
>>>     */
>>>    static bool ttm_bo_evict_swapout_allowable(struct 
>>> ttm_buffer_object *bo,
>>> -    struct ttm_operation_ctx *ctx, bool *locked)
>>> +    struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
>>>    {
>>>    bool ret = false;
>>>       *locked = false;
>>> +    if (busy)
>>> +    *busy = false;
>>>    if (bo->resv == ctx->resv) {
>>>    reservation_object_assert_held(bo->resv);
>>>    if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
>>> @@ -779,35 +781,45 @@ static bool 
>>> ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
>>>    } else {
>>>    *locked = reservation_object_trylock(bo->resv);
>>>    ret = *locked;
>>> +    if (!ret && busy)
>>> +    *busy = true;
>>>    }
>>>       return ret;
>>>    }
>>>    -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>>> -   uint32_t mem_type,
>>> -   const struct ttm_place *place,
>>> -   struct ttm_operation_ctx *ctx)
>>> +static struct ttm_buffer_object*
>>> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
>>> + struct ttm_mem_type_manager *man,
>>> + const struct ttm_place *place,
>>> + struct ttm_operation_ctx *ctx,
>>> + struct ttm_buffer_object **first_bo,
>>> + bool *locked)
>>>    {
>>> -    struct ttm_bo_global *glob = bdev->glob;
>>> -    struct ttm_mem_type_manager *man = >man[mem_type];
>>>    struct ttm_buffer_object *bo = NULL;
>>> -    bool locked = false;
>>> -    unsigned i;
>>> -    int ret;
>>> +    int i;
>>>    -    spin_lock(>lru_lock);
>>> +    if (first_bo)
>>> +    *first_bo = NULL;
>>>    for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>>>    list_for_each_entry(bo, >lru[i], lru) {
>>> -    if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
>>> +    bool busy = false;
>>> +    if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
>>> +    )) {
>> A newline between declaration and code please.
>>
>>> +    if (first_bo && !(*first_bo) && busy) {
>>> +    ttm_bo_get(bo);
>>> +    *first_bo = bo;
>>> +    }
>>>    continue;
>>> +    }
>>>       if (place && !bdev->driver->eviction_valuable(bo,
>>>  place)) {
>>> -    if (locked)
>>> +    if (*locked)
>>>    reservation_object_unlock(bo->resv);
>>>    continue;
>>>    }
>>> +
>>>    break;
>>>    }
>>>    @@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct 
>>> ttm_bo_device *bdev,
>>>    bo = NULL;
>>>    }
>>>    +    return bo;
>>> +}
>>> +
>>> +static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>>> +   uint32_t mem_type,
>>> +   const struct ttm_place *place,
>>> +   struct ttm_operation_ctx *ctx)
>>> +{
>>> +    struct ttm_bo_global *glob = bdev->glob;
>>> +    struct ttm_mem_type_manager *man = 

[drm-tip:drm-tip /8] drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting'

2019-05-07 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking 
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 47f4a14297839cb4cedd725fb916a5da5eb9b5ba
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

Note: the drm-tip/drm-tip HEAD ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 
'i915_request_await_start'
i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
^~~~
   drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 
'i915_request_await_start' was here
i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
^~~~
>> drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 
>> 'already_busywaiting'
already_busywaiting(struct i915_request *rq)
^~~
   drivers/gpu/drm/i915/i915_request.c:809:1: note: previous definition of 
'already_busywaiting' was here
already_busywaiting(struct i915_request *rq)
^~~
   drivers/gpu/drm/i915/i915_request.c:809:1: warning: 'already_busywaiting' 
defined but not used [-Wunused-function]
   drivers/gpu/drm/i915/i915_request.c:794:1: warning: 
'i915_request_await_start' defined but not used [-Wunused-function]
i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
^~~~

vim +/already_busywaiting +842 drivers/gpu/drm/i915/i915_request.c

47f4a1429 drivers/gpu/drm/i915/i915_request.c Joonas Lahtinen 2019-05-07  
825  
a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson2016-09-09  
826  static int
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01 
@827  i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
828  {
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
829   if (list_is_first(>ring_link, >ring->request_list))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
830   return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
831  
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
832   signal = list_prev_entry(signal, ring_link);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
833   if (i915_timeline_sync_is_later(rq->timeline, >fence))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
834   return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
835  
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
836   return i915_sw_fence_await_dma_fence(>submit,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
837>fence, 0,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
838I915_FENCE_GFP);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
839  }
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
840  
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
841  static intel_engine_mask_t
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04 
@842  already_busywaiting(struct i915_request *rq)
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
843  {
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
844   /*
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
845* Polling a semaphore causes bus traffic, delaying other users of
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
846* both the GPU and CPU. We want to limit the impact on others,
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
847* while taking advantage of early submission to reduce GPU
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
848* latency. Therefore we restrict ourselves to not using more
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
849* than one semaphore from each source, and not using a semaphore
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread zhoucm1



On 2019年05月07日 18:53, Koenig, Christian wrote:

Am 07.05.19 um 11:36 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user fail to get 
memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need 
memory for (or rather the ww_mutex of its reservation object) has a ticket 
assigned.
3. If we have a ticket we grab a reference to the first BO on the LRU, drop the 
LRU lock and try to grab the reservation lock with the ticket.
4. If getting the reservation lock with the ticket succeeded we check if the BO 
is still the first one on the LRU in question (the BO could have moved).
5. If the BO is still the first one on the LRU in question we try to evict it 
as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible usecase not only 
pinned bo.

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
   drivers/gpu/drm/ttm/ttm_bo.c | 113 ++-
   1 file changed, 97 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..bbf1d14d00a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+   struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
   {
bool ret = false;
   
   	*locked = false;

+   if (busy)
+   *busy = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,45 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
} else {
*locked = reservation_object_trylock(bo->resv);
ret = *locked;
+   if (!ret && busy)
+   *busy = true;
}
   
   	return ret;

   }
   
-static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

-  uint32_t mem_type,
-  const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+struct ttm_mem_type_manager *man,
+const struct ttm_place *place,
+struct ttm_operation_ctx *ctx,
+struct ttm_buffer_object **first_bo,
+bool *locked)
   {
-   struct ttm_bo_global *glob = bdev->glob;
-   struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo = NULL;
-   bool locked = false;
-   unsigned i;
-   int ret;
+   int i;
   
-	spin_lock(>lru_lock);

+   if (first_bo)
+   *first_bo = NULL;
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   bool busy = false;
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+   )) {

A newline between declaration and code please.


+   if (first_bo && !(*first_bo) && busy) {
+   ttm_bo_get(bo);
+   *first_bo = bo;
+   }
continue;
+   }
   
   			if (place && !bdev->driver->eviction_valuable(bo,

  place)) {
-   if (locked)
+   if (*locked)
reservation_object_unlock(bo->resv);
continue;
}
+
break;
}
   
@@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

bo = NULL;
}
   
+	return bo;

+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  struct ttm_operation_ctx *ctx)
+{
+   struct ttm_bo_global *glob = bdev->glob;
+   struct ttm_mem_type_manager *man = >man[mem_type];
+   struct 

[bug report] drm/panfrost: Add sanity checks to submit IOCTL

2019-05-07 Thread Dan Carpenter
Hello Tomeu Vizoso,

The patch 6ff408e6dc20: "drm/panfrost: Add sanity checks to submit
IOCTL" from Apr 24, 2019, leads to the following static checker
warning:

drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
error: we previously assumed 'sync_out' could be null (see line 216)

drivers/gpu/drm/panfrost/panfrost_drv.c
   168  static int panfrost_ioctl_submit(struct drm_device *dev, void *data,
   169  struct drm_file *file)
   170  {
   171  struct panfrost_device *pfdev = dev->dev_private;
   172  struct drm_panfrost_submit *args = data;
   173  struct drm_syncobj *sync_out = NULL;
   174  struct panfrost_job *job;
   175  int ret = 0;
   176  
   177  if (!args->jc)
   178  return -EINVAL;
   179  
   180  if (args->requirements && args->requirements != 
PANFROST_JD_REQ_FS)
   181  return -EINVAL;
   182  
   183  if (args->out_sync > 0) {
   184  sync_out = drm_syncobj_find(file, args->out_sync);
   185  if (!sync_out)
   186  return -ENODEV;
   187  }
   188  
   189  job = kzalloc(sizeof(*job), GFP_KERNEL);
   190  if (!job) {
   191  ret = -ENOMEM;
   192  goto fail_out_sync;
   193  }
   194  
   195  kref_init(>refcount);
   196  
   197  job->pfdev = pfdev;
   198  job->jc = args->jc;
   199  job->requirements = args->requirements;
   200  job->flush_id = panfrost_gpu_get_latest_flush_id(pfdev);
   201  job->file_priv = file->driver_priv;
   202  
   203  ret = panfrost_copy_in_sync(dev, file, args, job);
   204  if (ret)
   205  goto fail_job;
   206  
   207  ret = panfrost_lookup_bos(dev, file, args, job);
   208  if (ret)
   209  goto fail_job;
   210  
   211  ret = panfrost_job_push(job);
   212  if (ret)
   213  goto fail_job;
   214  
   215  /* Update the return sync object for the job */
   216  if (sync_out)

I'm pretty sure this can be removed.


   217  drm_syncobj_replace_fence(sync_out, 
job->render_done_fence);
   218  
   219  fail_job:
   220  panfrost_job_put(job);
   221  fail_out_sync:
   222  drm_syncobj_put(sync_out);

Otherwise we are toasted...

   223  
   224  return ret;
   225  }

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

Re: [PATCH v10 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs

2019-05-07 Thread Fabio Estevam
On Tue, May 7, 2019 at 4:47 AM Guido Günther  wrote:
>
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
> added once the necessary system controller bits are in via
> mixel_dphy_devdata.
>
> Signed-off-by: Guido Günther 
> Co-developed-by: Robert Chiras 
> Signed-off-by: Robert Chiras 

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

Re: [PATCH v10 1/2] dt-bindings: phy: Add documentation for mixel dphy

2019-05-07 Thread Fabio Estevam
On Tue, May 7, 2019 at 4:47 AM Guido Günther  wrote:
>
> Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs.
>
> Signed-off-by: Guido Günther 
> Reviewed-by: Sam Ravnborg 
> Reviewed-by: Rob Herring 

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

[drm-tip:drm-tip 5/8] drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start'

2019-05-07 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   73db4ec12f05160528884c0b2c845b1c6b7c6718
commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking 
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b9a2acf7709f52c77dc752ec99e3873e392d8df6
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 
>> 'i915_request_await_start'
i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
^~~~
   drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 
'i915_request_await_start' was here
i915_request_await_start(struct i915_request *rq, struct i915_request 
*signal)
^~~~
   drivers/gpu/drm/i915/i915_request.c:794:1: warning: 
'i915_request_await_start' defined but not used [-Wunused-function]

vim +/i915_request_await_start +827 drivers/gpu/drm/i915/i915_request.c

ca6e56f65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04  825  
a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09  826  
static int
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 @827  
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  828  
{
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  829  
if (list_is_first(>ring_link, >ring->request_list))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  830  
return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  831  
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  832  
signal = list_prev_entry(signal, ring_link);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  833  
if (i915_timeline_sync_is_later(rq->timeline, >fence))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  834  
return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  835  
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  836  
return i915_sw_fence_await_dma_fence(>submit,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  837  
 >fence, 0,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  838  
 I915_FENCE_GFP);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  839  
}
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  840  

:: The code at line 827 was first introduced by commit
:: e766fde6511e2be83acbca1d603035e08de23f3b drm/i915: Delay semaphore 
submission until the start of the signaler

:: TO: Chris Wilson 
:: CC: Joonas Lahtinen 

---
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: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Koenig, Christian
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user fail to 
> get memory.
>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if the BO we need 
> memory for (or rather the ww_mutex of its reservation object) has a ticket 
> assigned.
> 3. If we have a ticket we grab a reference to the first BO on the LRU, drop 
> the LRU lock and try to grab the reservation lock with the ticket.
> 4. If getting the reservation lock with the ticket succeeded we check if the 
> BO is still the first one on the LRU in question (the BO could have moved).
> 5. If the BO is still the first one on the LRU in question we try to evict it 
> as we would evict any other BO.
> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>
> v2: fix some minor check
> v3: address Christian v2 comments.
> v4: fix some missing
> v5: handle first_bo unlock and bo_get/put
> v6: abstract unified iterate function, and handle all possible usecase not 
> only pinned bo.
>
> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 113 ++-
>   1 file changed, 97 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8502b3ed2d88..bbf1d14d00a7 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>* b. Otherwise, trylock it.
>*/
>   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked)
> + struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
>   {
>   bool ret = false;
>   
>   *locked = false;
> + if (busy)
> + *busy = false;
>   if (bo->resv == ctx->resv) {
>   reservation_object_assert_held(bo->resv);
>   if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
> @@ -779,35 +781,45 @@ static bool ttm_bo_evict_swapout_allowable(struct 
> ttm_buffer_object *bo,
>   } else {
>   *locked = reservation_object_trylock(bo->resv);
>   ret = *locked;
> + if (!ret && busy)
> + *busy = true;
>   }
>   
>   return ret;
>   }
>   
> -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -uint32_t mem_type,
> -const struct ttm_place *place,
> -struct ttm_operation_ctx *ctx)
> +static struct ttm_buffer_object*
> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
> +  struct ttm_mem_type_manager *man,
> +  const struct ttm_place *place,
> +  struct ttm_operation_ctx *ctx,
> +  struct ttm_buffer_object **first_bo,
> +  bool *locked)
>   {
> - struct ttm_bo_global *glob = bdev->glob;
> - struct ttm_mem_type_manager *man = >man[mem_type];
>   struct ttm_buffer_object *bo = NULL;
> - bool locked = false;
> - unsigned i;
> - int ret;
> + int i;
>   
> - spin_lock(>lru_lock);
> + if (first_bo)
> + *first_bo = NULL;
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   list_for_each_entry(bo, >lru[i], lru) {
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
> + bool busy = false;
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
> + )) {

A newline between declaration and code please.

> + if (first_bo && !(*first_bo) && busy) {
> + ttm_bo_get(bo);
> + *first_bo = bo;
> + }
>   continue;
> + }
>   
>   if (place && !bdev->driver->eviction_valuable(bo,
> place)) {
> - if (locked)
> + if (*locked)
>   reservation_object_unlock(bo->resv);
>   continue;
>   }
> +
>   break;
>   }
>   
> @@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct ttm_bo_device 
> *bdev,
>   bo = NULL;
>   }
>   
> + return bo;
> +}
> +
> +static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> +uint32_t mem_type,
> +const struct ttm_place *place,
> +struct ttm_operation_ctx *ctx)
> +{
> + struct ttm_bo_global *glob = 

Re: [PATCH 2/2] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve

2019-05-07 Thread Koenig, Christian
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
> add ticket for display bo, so that it can preempt busy bo.
>
> Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
> Signed-off-by: Chunming Zhou 
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>   1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ac22f7351a42..8633d52e3fbe 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4176,6 +4176,9 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
> *plane,
>   struct amdgpu_device *adev;
>   struct amdgpu_bo *rbo;
>   struct dm_plane_state *dm_plane_state_new, *dm_plane_state_old;
> + struct list_head list, duplicates;
> + struct ttm_validate_buffer tv;
> + struct ww_acquire_ctx ticket;
>   uint64_t tiling_flags;
>   uint32_t domain;
>   int r;
> @@ -4192,9 +4195,18 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
> *plane,
>   obj = new_state->fb->obj[0];
>   rbo = gem_to_amdgpu_bo(obj);
>   adev = amdgpu_ttm_adev(rbo->tbo.bdev);
> - r = amdgpu_bo_reserve(rbo, false);
> - if (unlikely(r != 0))
> + INIT_LIST_HEAD();
> + INIT_LIST_HEAD();
> +
> + tv.bo = >tbo;
> + tv.num_shared = 1;
> + list_add(, );
> +
> + r = ttm_eu_reserve_buffers(, , false, );

duplicates are superfluous and can be NULL in this case.

Apart from that the patch is Reviewed-by: Christian König 


Regards,
Christian.

> + if (r) {
> + dev_err(adev->dev, "fail to reserve bo (%d)\n", r);
>   return r;
> + }
>   
>   if (plane->type != DRM_PLANE_TYPE_CURSOR)
>   domain = amdgpu_display_supported_domains(adev);
> @@ -4205,21 +4217,21 @@ static int dm_plane_helper_prepare_fb(struct 
> drm_plane *plane,
>   if (unlikely(r != 0)) {
>   if (r != -ERESTARTSYS)
>   DRM_ERROR("Failed to pin framebuffer with error %d\n", 
> r);
> - amdgpu_bo_unreserve(rbo);
> + ttm_eu_backoff_reservation(, );
>   return r;
>   }
>   
>   r = amdgpu_ttm_alloc_gart(>tbo);
>   if (unlikely(r != 0)) {
>   amdgpu_bo_unpin(rbo);
> - amdgpu_bo_unreserve(rbo);
> + ttm_eu_backoff_reservation(, );
>   DRM_ERROR("%p bind failed\n", rbo);
>   return r;
>   }
>   
>   amdgpu_bo_get_tiling_flags(rbo, _flags);
>   
> - amdgpu_bo_unreserve(rbo);
> + ttm_eu_backoff_reservation(, );
>   
>   afb->address = amdgpu_bo_gpu_offset(rbo);
>   

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

Re: [PULL] 2nd pull for malidp-next

2019-05-07 Thread Liviu Dudau
On Tue, May 07, 2019 at 09:50:19AM +1000, Dave Airlie wrote:
> On Fri, 3 May 2019 at 22:17, Daniel Vetter  wrote:
> >
> > On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > > On Fri, May 3, 2019 at 11:11 AM Liviu Dudau  wrote:
> > > > >
> > > > > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > > > > On Thu, 2 May 2019 at 20:45, Liviu Dudau  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi DRM maintainers,
> > > > > > >
> > > > > > > This is the 2nd pull request for the malidp-next. The new patches 
> > > > > > > add
> > > > > > > additional support for Arm Mali D71 so that it can now be enabled
> > > > > > > correctly and brought up on any SoC that contains the IP. From 
> > > > > > > now on
> > > > > > > we will start focusing on adding writeback, scaling and other 
> > > > > > > useful
> > > > > > > features to bring the driver to the same level of maturity as 
> > > > > > > mali-dp.
> > > > > > >
> > > > > > > Please pull,
> > > > > > > Liviu
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The following changes since commit 
> > > > > > > 7c13e5cc2391950541f41fc9ab0336aae77c7f63:
> > > > > > >
> > > > > > >   Merge tag 'drm-intel-next-fixes-2019-04-25' of 
> > > > > > > git://anongit.freedesktop.org/drm/drm-intel into drm-next 
> > > > > > > (2019-04-26 11:35:59 +1000)
> > > > > > >
> > > > > > > are available in the Git repository at:
> > > > > > >
> > > > > > >   git://linux-arm.org/linux-ld.git for-upstream/mali-dp
> 
> So I get commits now, but I also get:
> 
> Pulling git://linux-arm.org/linux-ld.git for-upstream/mali-dp ...
> From git://linux-arm.org/linux-ld
>  * branch  for-upstream/mali-dp -> FETCH_HEAD
> dim: 09918bb1ff8c ("drm/komeda: Use memset to initialize config_id"):
> SHA1 in fixes line not found:
> dim: 4cc734cb79a8 ("drm/komeda: Add sysfs attribute: core_id and 
> config_id")
> dim: d9fcab4a131d ("drm/komeda: Mark the local functions as static"):
> author Signed-off-by missing.
> dim: ERROR: issues in commits detected, aborting
> 
> Please fix the fixes tag, though since that is all in the one pull
> request you should probably squash the fix into the offending commit.
> 
> Dave.

Hi Dave,

I have rolled the 09918bb1ff8c ("drm/komeda: Use memset to initialize 
config_id")
commit into the offending one and fixed the Signed-off-by ID for James,
please pull the updated tree.

Best regards,
Liviu



The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63:

  Merge tag 'drm-intel-next-fixes-2019-04-25' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 11:35:59 
+1000)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/mali-dp

for you to fetch changes up to 15e9122d9b5c745024f2d9d5653caed1f37c185f:

  drm/komeda: Mark the local functions as static (2019-05-07 11:26:47 +0100)


james qian wang (Arm Technology China) (18):
  drm: Add drm_atomic_get_old/new_private_obj_state
  drm/komeda: Add komeda_pipeline/component_get_state_and_set_user
  drm/komeda: Initialize komeda component as drm private object
  drm/komeda: Add komeda_build_layer_data_flow
  drm/komeda: Add komeda_plane/plane_helper_funcs
  drm/komeda: Add komeda_build_display_data_flow
  drm/komeda: Add komeda_release_unclaimed_resources
  drm/komeda: Add komeda_crtc_atomic_flush
  drm/komeda: Add komeda_crtc_mode_valid/fixup
  drm/komeda: Add komeda_crtc_prepare/unprepare
  drm/komeda: Add komeda_crtc_atomic_enable/disable
  drm/komeda: Add komeda_crtc_vblank_enable/disable
  drm/komeda: Add komeda_crtc_funcs
  drm/komeda: Add komeda_kms_check
  drm/komeda: Add sysfs attribute: core_id and config_id
  drm/komeda: Expose bus_width to Komeda-CORE
  drm/komeda: Fixed warning: Function parameter or member not described
  drm/komeda: Mark the local functions as static

 .../gpu/drm/arm/display/include/malidp_product.h   |  12 +
 drivers/gpu/drm/arm/display/komeda/Makefile|   1 +
 .../gpu/drm/arm/display/komeda/d71/d71_component.c |   9 +-
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   |  54 ++
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   | 395 -
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c|  52 ++
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h|  44 +-
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c|   9 +-
 .../drm/arm/display/komeda/komeda_framebuffer.h|   9 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c|  39 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h|  21 +-
 .../gpu/drm/arm/display/komeda/komeda_pipeline.c   |   2 +-
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   |  81 ++-
 .../drm/arm/display/komeda/komeda_pipeline_state.c | 610 +
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c 

Re: [v8 01/10] drm: Add HDR source metadata property

2019-05-07 Thread Ville Syrjälä
On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> >Sent: Saturday, May 4, 2019 3:48 PM
> >To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> >dri-
> >de...@lists.freedesktop.org
> >Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
> >Syrjala, Ville ; Lankhorst, Maarten
> >
> >Subject: Re: [v8 01/10] drm: Add HDR source metadata property
> >
> >On 2019-04-09 18:44, Uma Shankar wrote:
> >> This patch adds a blob property to get HDR metadata information from
> >> userspace. This will be send as part of AVI Infoframe to panel.
> >>
> >> It also implements get() and set() functions for HDR output metadata
> >> property.The blob data is received from userspace and saved in
> >> connector state, the same is returned as blob in get property call to
> >> userspace.
> >>
> >> v2: Rebase and modified the metadata structure elements as per Ville's
> >> POC changes.
> >>
> >> v3: No Change
> >>
> >> v4: Addressed Shashank's review comments
> >>
> >> v5: Rebase.
> >>
> >> v6: Addressed Brian Starkey's review comments, defined new structure
> >> with header for dynamic metadata scalability.
> >> Merge get/set property functions for metadata in this patch.
> >>
> >> v7: Addressed Jonas Karlman review comments and defined separate
> >> structure for infoframe to better align with CTA 861.G spec. Added
> >> Shashank's RB.
> >>
> >> Signed-off-by: Uma Shankar 
> >> Reviewed-by: Shashank Sharma 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c  |  2 ++
> >>  drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> >>  drivers/gpu/drm/drm_connector.c   |  6 ++
> >>  include/drm/drm_connector.h   | 11 +++
> >>  include/drm/drm_mode_config.h |  6 ++
> >>  include/linux/hdmi.h  | 10 ++
> >>  include/uapi/drm/drm_mode.h   | 39
> >+++
> >>  7 files changed, 87 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c
> >> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -881,6 +881,8 @@ static void
> >> drm_atomic_connector_print_state(struct drm_printer *p,
> >>
> >>drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
> >>name);
> >>drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> >> "(null)");
> >> +  drm_printf(p, "\thdr_metadata_changed=%d\n",
> >> + state->hdr_metadata_changed);
> >>
> >>if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> >>if (state->writeback_job && state->writeback_job->fb) diff --git
> >> a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index ea797d4..6d0d161 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -673,6 +673,8 @@ static int
> >> drm_atomic_connector_set_property(struct drm_connector *connector,  {
> >>struct drm_device *dev = connector->dev;
> >>struct drm_mode_config *config = >mode_config;
> >> +  bool replaced = false;
> >> +  int ret;
> >>
> >>if (property == config->prop_crtc_id) {
> >>struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -721,6
> >> +723,14 @@ static int drm_atomic_connector_set_property(struct 
> >> drm_connector
> >*connector,
> >> */
> >>if (state->link_status != DRM_LINK_STATUS_GOOD)
> >>state->link_status = val;
> >> +  } else if (property == config->hdr_output_metadata_property) {
> >> +  ret = drm_atomic_replace_property_blob_from_id(dev,
> >> +  >hdr_output_metadata_blob_ptr,
> >> +  val,
> >> +  -1, sizeof(struct hdr_output_metadata),
> >> +  );
> >> +  state->hdr_metadata_changed |= replaced;
> >> +  return ret;
> >>} else if (property == config->aspect_ratio_property) {
> >>state->picture_aspect_ratio = val;
> >>} else if (property == config->content_type_property) { @@ -807,6
> >> +817,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
> >*connector,
> >>*val = state->colorspace;
> >>} else if (property == connector->scaling_mode_property) {
> >>*val = state->scaling_mode;
> >> +  } else if (property == config->hdr_output_metadata_property) {
> >> +  *val = (state->hdr_output_metadata_blob_ptr) ?
> >> +  state->hdr_output_metadata_blob_ptr->base.id : 0;
> >>} else if (property == connector->content_protection_property) {
> >>*val = state->content_protection;
> >>} else if (property == config->writeback_fb_id_property) { diff
> >> --git a/drivers/gpu/drm/drm_connector.c
> >> b/drivers/gpu/drm/drm_connector.c index 2355124..0bdae90 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> 

Re: [PATCH] gpu/drm: Remove duplicate headers

2019-05-07 Thread Daniel Vetter
On Mon, May 06, 2019 at 04:43:34PM +0200, Daniel Vetter wrote:
> On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> > From: Jagadeesh Pagadala 
> > 
> > Remove duplicate headers which are included twice.
> > 
> > Signed-off-by: Jagadeesh Pagadala 
> 
> I collected some acks for the msm and nouveau parts and pushed this. For
> next time around would be great if you split these up along driver/module
> boundaries, so that each maintainer can pick this up directly.
> 
> Thanks for your patch.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c| 2 --
> >  drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -

Correction, this didn't compile, so I dropped the changes to panel-rpi.
Another reason to split patches more for next time around. Also, needs
more compile testing (you need cross compilers for at least arm to test
this stuff).
-Daniel

> >  3 files changed, 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > index 018df2c..45a5bc6 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > @@ -15,7 +15,6 @@
> >  #include "dpu_hwio.h"
> >  #include "dpu_hw_lm.h"
> >  #include "dpu_hw_mdss.h"
> > -#include "dpu_kms.h"
> >  
> >  #define LM_OP_MODE0x00
> >  #define LM_OUT_SIZE   0x04
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> > index c80b967..2b44ba5 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> > @@ -26,8 +26,6 @@
> >  
> >  #include 
> >  
> > -#include 
> > -
> >  static void
> >  nv04_bus_intr(struct nvkm_bus *bus)
> >  {
> > diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
> > b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> > index 2c9c972..cacf2e0 100644
> > --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> > +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> > @@ -53,7 +53,6 @@
> >  #include 
> >  #include 
> >  
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > -- 
> > 1.8.3.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: [PATCH] drm/doc: Improve docs for conn_state->best_encoder

2019-05-07 Thread Daniel Vetter
On Mon, May 06, 2019 at 05:27:24PM +0200, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 05:57:53PM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> > 
> > Thank you for the patch.
> > 
> > On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> > > It's mandatory and considered core state since ioctls rely on this
> > > working.
> > > 
> > > Thanks to Laurent for pointing out this gap.
> > > 
> > > v2: Clarify to "atomic drivers" only.
> > > 
> > > Cc: Laurent Pinchart 
> > > Cc: Sean Paul 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  include/drm/drm_connector.h | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index 02a131202add..f43f40d5888a 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -517,6 +517,10 @@ struct drm_connector_state {
> > >* Used by the atomic helpers to select the encoder, through the
> > >* _connector_helper_funcs.atomic_best_encoder or
> > >* _connector_helper_funcs.best_encoder callbacks.
> > 
> > How about updating this part as well ?
> > 
> > "Used by both the DRM core and the atomic helpers to select the encoder
> > (through the _connector_helper_funcs.atomic_best_encoder), access it
> > and report it to userspace (through the GETCONNECTOR and GETENCODER
> > ioctls). This field shall be set by all atomic drivers, either directly
> > or through atomic helpers."
> 
> It's kinda two things, I think best to describe in two paragraphs. But I
> can move the core usage up, since arguable more important. Otoh most
> drivers won't care since helpers handle this, and they care more about how
> @best_encoder is used.
> 
> E.g. core never calls the helper callbacks
> @atomic_best_endoer/best_encoder, which isn't clear anymore with your
> wording. And I have a sticker for core/helper splits :-)

Went ahead with Sean's irc ack and merged this. We can bikeshed more later
on I guess with more patches. I think sprinkling a pile of cross
references once Sean's and yours patches all land would be good.
-Daniel

> -Daniel
> > 
> > > +  *
> > > +  * NOTE: Atomic drivers must fill this out (either themselves or through
> > > +  * helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
> > > +  * not return correct data to userspace.
> > >*/
> > >   struct drm_encoder *best_encoder;
> > >  
> > 
> > -- 
> > Regards,
> > 
> > Laurent Pinchart
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[PATCH v2] drm/komeda: Mark the local functions as static

2019-05-07 Thread james qian wang (Arm Technology China)
Fix the kbuild test rebot reported warnings:
- symbol was not declared. Should it be static?
- missing braces around initializer

Depends on:
- https://patchwork.freedesktop.org/series/58976/

V2: Update Signed-off-by name to make it same with author entirely.

Reported-by: kbuild test robot 
Signed-off-by: james qian wang (Arm Technology China) 
Signed-off-by: Liviu Dudau 
---
 .../gpu/drm/arm/display/komeda/d71/d71_component.c|  9 +
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c  |  4 ++--
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c   |  4 +++-
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c   |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c  |  2 +-
 .../drm/arm/display/komeda/komeda_pipeline_state.c| 11 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 10 ++
 7 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index c56cfc2de147..031e5f305a3c 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -391,7 +391,7 @@ static void d71_compiz_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "CU_USER_HIGH:\t\t0x%X\n", v[1]);
 }
 
-struct komeda_component_funcs d71_compiz_funcs = {
+static struct komeda_component_funcs d71_compiz_funcs = {
.update = d71_compiz_update,
.disable= d71_component_disable,
.dump_register  = d71_compiz_dump,
@@ -467,7 +467,7 @@ static void d71_improc_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "IPS_RGB_YUV_COEFF%u:\t0x%X\n", i, v[i]);
 }
 
-struct komeda_component_funcs d71_improc_funcs = {
+static struct komeda_component_funcs d71_improc_funcs = {
.update = d71_improc_update,
.disable= d71_component_disable,
.dump_register  = d71_improc_dump,
@@ -543,7 +543,8 @@ static void d71_timing_ctrlr_update(struct komeda_component 
*c,
malidp_write32(reg, BLK_CONTROL, value);
 }
 
-void d71_timing_ctrlr_dump(struct komeda_component *c, struct seq_file *sf)
+static void d71_timing_ctrlr_dump(struct komeda_component *c,
+ struct seq_file *sf)
 {
u32 v[8], i;
 
@@ -579,7 +580,7 @@ void d71_timing_ctrlr_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "BS_USER:\t\t0x%X\n", v[4]);
 }
 
-struct komeda_component_funcs d71_timing_ctrlr_funcs = {
+static struct komeda_component_funcs d71_timing_ctrlr_funcs = {
.update = d71_timing_ctrlr_update,
.disable= d71_timing_ctrlr_disable,
.dump_register  = d71_timing_ctrlr_dump,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index d335fec1b727..62fad59f5a6a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -52,7 +52,7 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
 }
 
-u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
+static u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
 {
unsigned long mclk = kcrtc_st->base.adjusted_mode.clock * 1000;
 
@@ -350,7 +350,7 @@ static bool komeda_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }
 
-struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
+static struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.atomic_check   = komeda_crtc_atomic_check,
.atomic_flush   = komeda_crtc_atomic_flush,
.atomic_enable  = komeda_crtc_atomic_enable,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 9d6c31cca875..2075f4ac7078 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -73,9 +73,11 @@ config_id_show(struct device *dev, struct device_attribute 
*attr, char *buf)
 {
struct komeda_dev *mdev = dev_to_mdev(dev);
struct komeda_pipeline *pipe = mdev->pipelines[0];
-   union komeda_config_id config_id = {0,};
+   union komeda_config_id config_id;
int i;
 
+   config_id.value = 0;
+
config_id.max_line_sz = pipe->layers[0]->hsize_in.end;
config_id.n_pipelines = mdev->n_pipelines;
config_id.n_scalers = pipe->n_scalers;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 0285fd37a016..cfa5068d9d1e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -127,7 +127,7 @@ static const struct komeda_product_data komeda_products[] = 
{
},
 };
 
-const struct of_device_id komeda_of_match[] = {
+static const struct of_device_id komeda_of_match[] = {
{ 

Re: [PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions

2019-05-07 Thread Lee Jones
On Thu, 02 May 2019, Daniel Thompson wrote:

> On Thu, May 02, 2019 at 06:42:39AM -0400, Brian Masney wrote:
> > On Thu, May 02, 2019 at 11:07:51AM +0100, Daniel Thompson wrote:
> > > On 24/04/2019 10:25, Brian Masney wrote:
> > > > lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
> > > > both return the brightness value if the brightness was successfully
> > > > updated. Writing to these attributes via sysfs would cause a 'Bad
> > > > address' error to be returned. These functions should return 0 on
> > > > success, so let's change it to correct that error.
> > > > 
> > > > Signed-off-by: Brian Masney 
> > > > Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
> > > > Acked-by: Pavel Machek 
> > > 
> > > Hi Brian, sorry for the delay. For some reason your mails are being dumped
> > > before they reach me so I only discovered these patches when I paid proper
> > > attention to the replies and fetched them from patchwork.
> > > 
> > > Hi Lee, is the same thing happening for you? ;-)
> > 
> > Huh, that's odd. I haven't ran into that issue when working with people
> > from Linaro in other subsystems.
> > 
> > As a sanity check, I used 'git send-email' to send this patch to
> > check-a...@verifier.port25.com and it verified that I still have SPF,
> > DKIM, reverse DNS, etc. all setup properly on this domain.
> > 
> > hotmail.com addresses are the only ones I've had issues with in the
> > past, but I doubt you're forwarding your email there. :)
> 
> No... and strangely enough your recent e-mail sailed through just fine.
> Let's wait and see what is happening for Lee (which I suspect may not be
> until well into next week).

Just catching up now.  On first pass - only ~800 mails to go!

Looks like I do have Brian's mails though.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 1/5] drm/mediatek: move mipi_dsi_host_register to probe

2019-05-07 Thread CK Hu
Hi, Jitao:

On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> DSI panel driver need attach function which is inculde in
> mipi_dsi_host_ops.
> 
> If mipi_dsi_host_register is not in probe, dsi panel will
> probe fail or more delay.

I think this patch just prevent delay, not to prevent dsi panel probe
fail. In [1], you mention mipi_dsi_attach() is called in
panel_simple_dsi_probe(), but panel_simple_dsi_probe() is trigger by
mipi_dsi_host_register(), so the probe would success.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c?h=v5.0-rc6#n2987


> 
> So move the mipi_dsi_host_register to probe from bind.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 50 ++
>  1 file changed, 30 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..6c4ac37f983d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1045,12 +1045,6 @@ static int mtk_dsi_bind(struct device *dev, struct 
> device *master, void *data)
>   return ret;
>   }
>  
> - ret = mipi_dsi_host_register(>host);
> - if (ret < 0) {
> - dev_err(dev, "failed to register DSI host: %d\n", ret);
> - goto err_ddp_comp_unregister;
> - }
> -
>   ret = mtk_dsi_create_conn_enc(drm, dsi);
>   if (ret) {
>   DRM_ERROR("Encoder create failed with %d\n", ret);
> @@ -1060,8 +1054,6 @@ static int mtk_dsi_bind(struct device *dev, struct 
> device *master, void *data)
>   return 0;
>  
>  err_unregister:
> - mipi_dsi_host_unregister(>host);
> -err_ddp_comp_unregister:
>   mtk_ddp_comp_unregister(drm, >ddp_comp);
>   return ret;
>  }
> @@ -1097,31 +1089,37 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>  
>   dsi->host.ops = _dsi_ops;
>   dsi->host.dev = dev;
> + dsi->dev = dev;

Why do this?

Regards,
CK

> + ret = mipi_dsi_host_register(>host);
> + if (ret < 0) {
> + dev_err(dev, "failed to register DSI host: %d\n", ret);
> + return ret;
> + }
>  
>   ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> >panel, >bridge);
>   if (ret)
> - return ret;
> + goto err_unregister_host;
>  
>   dsi->engine_clk = devm_clk_get(dev, "engine");
>   if (IS_ERR(dsi->engine_clk)) {
>   ret = PTR_ERR(dsi->engine_clk);
>   dev_err(dev, "Failed to get engine clock: %d\n", ret);
> - return ret;
> + goto err_unregister_host;
>   }
>  
>   dsi->digital_clk = devm_clk_get(dev, "digital");
>   if (IS_ERR(dsi->digital_clk)) {
>   ret = PTR_ERR(dsi->digital_clk);
>   dev_err(dev, "Failed to get digital clock: %d\n", ret);
> - return ret;
> + goto err_unregister_host;
>   }
>  
>   dsi->hs_clk = devm_clk_get(dev, "hs");
>   if (IS_ERR(dsi->hs_clk)) {
>   ret = PTR_ERR(dsi->hs_clk);
>   dev_err(dev, "Failed to get hs clock: %d\n", ret);
> - return ret;
> + goto err_unregister_host;
>   }
>  
>   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);



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

Re: [PATCH] drm/ttm: fix busy memory to fail other user v5

2019-05-07 Thread zhoucm1



On 2019年05月07日 17:03, Christian König wrote:

[CAUTION: External Email]

Ping!
in fact, already address your comments, just wait for Prike test result, 
anyway, send v6 first.


-David


Marek is going to need this for its GDS patches as well.

Christina.

Am 30.04.19 um 11:10 schrieb Christian König:

Am 30.04.19 um 09:01 schrieb Chunming Zhou:

heavy gpu job could occupy memory long time, which lead other user
fail to get memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we
need memory for (or rather the ww_mutex of its reservation object)
has a ticket assigned.
3. If we have a ticket we grab a reference to the first BO on the
LRU, drop the LRU lock and try to grab the reservation lock with the
ticket.
4. If getting the reservation lock with the ticket succeeded we check
if the BO is still the first one on the LRU in question (the BO could
have moved).
5. If the BO is still the first one on the LRU in question we try to
evict it as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c    |  7 +-
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 +++--
  drivers/gpu/drm/ttm/ttm_bo.c  | 81 
+--

  3 files changed, 99 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index affde72b44db..523773e85284 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -811,7 +811,12 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo
*bo, u32 domain,
   u64 min_offset, u64 max_offset)
  {
  struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
-    struct ttm_operation_ctx ctx = { false, false };
+    struct ttm_operation_ctx ctx = {
+    .interruptible = false,
+    .no_wait_gpu = false,
+    .resv = bo->tbo.resv,
+    .flags = 0
+    };
  int r, i;
    if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a5cacf846e1b..cc3677c4a4c2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4101,6 +4101,9 @@ static int dm_plane_helper_prepare_fb(struct
drm_plane *plane,
  struct amdgpu_device *adev;
  struct amdgpu_bo *rbo;
  struct dm_plane_state *dm_plane_state_new, *dm_plane_state_old;
+    struct list_head list, duplicates;
+    struct ttm_validate_buffer tv;
+    struct ww_acquire_ctx ticket;
  uint64_t tiling_flags;
  uint32_t domain;
  int r;
@@ -4117,9 +4120,18 @@ static int dm_plane_helper_prepare_fb(struct
drm_plane *plane,
  obj = new_state->fb->obj[0];
  rbo = gem_to_amdgpu_bo(obj);
  adev = amdgpu_ttm_adev(rbo->tbo.bdev);
-    r = amdgpu_bo_reserve(rbo, false);
-    if (unlikely(r != 0))
+    INIT_LIST_HEAD();
+    INIT_LIST_HEAD();
+
+    tv.bo = >tbo;
+    tv.num_shared = 1;
+    list_add(, );
+
+    r = ttm_eu_reserve_buffers(, , false, );
+    if (r) {
+    dev_err(adev->dev, "fail to reserve bo (%d)\n", r);
  return r;
+    }
    if (plane->type != DRM_PLANE_TYPE_CURSOR)
  domain = amdgpu_display_supported_domains(adev);
@@ -4130,21 +4142,21 @@ static int dm_plane_helper_prepare_fb(struct
drm_plane *plane,
  if (unlikely(r != 0)) {
  if (r != -ERESTARTSYS)
  DRM_ERROR("Failed to pin framebuffer with error %d\n", 
r);

-    amdgpu_bo_unreserve(rbo);
+    ttm_eu_backoff_reservation(, );
  return r;
  }
    r = amdgpu_ttm_alloc_gart(>tbo);
  if (unlikely(r != 0)) {
  amdgpu_bo_unpin(rbo);
-    amdgpu_bo_unreserve(rbo);
+    ttm_eu_backoff_reservation(, );
  DRM_ERROR("%p bind failed\n", rbo);
  return r;
  }
    amdgpu_bo_get_tiling_flags(rbo, _flags);
  -    amdgpu_bo_unreserve(rbo);
+    ttm_eu_backoff_reservation(, );


Well I can only repeat myself, please put that into a separate patch!


    afb->address = amdgpu_bo_gpu_offset(rbo);
  diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..2c4963e105d9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
   * b. Otherwise, trylock it.
   */
  static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
*bo,
-    struct ttm_operation_ctx *ctx, bool *locked)
+    struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
  {
  bool ret = false;
   

[PATCH 2/2] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve

2019-05-07 Thread Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.

Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ac22f7351a42..8633d52e3fbe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4176,6 +4176,9 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
struct amdgpu_device *adev;
struct amdgpu_bo *rbo;
struct dm_plane_state *dm_plane_state_new, *dm_plane_state_old;
+   struct list_head list, duplicates;
+   struct ttm_validate_buffer tv;
+   struct ww_acquire_ctx ticket;
uint64_t tiling_flags;
uint32_t domain;
int r;
@@ -4192,9 +4195,18 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
obj = new_state->fb->obj[0];
rbo = gem_to_amdgpu_bo(obj);
adev = amdgpu_ttm_adev(rbo->tbo.bdev);
-   r = amdgpu_bo_reserve(rbo, false);
-   if (unlikely(r != 0))
+   INIT_LIST_HEAD();
+   INIT_LIST_HEAD();
+
+   tv.bo = >tbo;
+   tv.num_shared = 1;
+   list_add(, );
+
+   r = ttm_eu_reserve_buffers(, , false, );
+   if (r) {
+   dev_err(adev->dev, "fail to reserve bo (%d)\n", r);
return r;
+   }
 
if (plane->type != DRM_PLANE_TYPE_CURSOR)
domain = amdgpu_display_supported_domains(adev);
@@ -4205,21 +4217,21 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("Failed to pin framebuffer with error %d\n", 
r);
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
return r;
}
 
r = amdgpu_ttm_alloc_gart(>tbo);
if (unlikely(r != 0)) {
amdgpu_bo_unpin(rbo);
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
DRM_ERROR("%p bind failed\n", rbo);
return r;
}
 
amdgpu_bo_get_tiling_flags(rbo, _flags);
 
-   amdgpu_bo_unreserve(rbo);
+   ttm_eu_backoff_reservation(, );
 
afb->address = amdgpu_bo_gpu_offset(rbo);
 
-- 
2.17.1

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

[PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

2019-05-07 Thread Chunming Zhou
heavy gpu job could occupy memory long time, which lead other user fail to get 
memory.

basically pick up Christian idea:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need 
memory for (or rather the ww_mutex of its reservation object) has a ticket 
assigned.
3. If we have a ticket we grab a reference to the first BO on the LRU, drop the 
LRU lock and try to grab the reservation lock with the ticket.
4. If getting the reservation lock with the ticket succeeded we check if the BO 
is still the first one on the LRU in question (the BO could have moved).
5. If the BO is still the first one on the LRU in question we try to evict it 
as we would evict any other BO.
6. If any of the "If's" above fail we just back off and return -EBUSY.

v2: fix some minor check
v3: address Christian v2 comments.
v4: fix some missing
v5: handle first_bo unlock and bo_get/put
v6: abstract unified iterate function, and handle all possible usecase not only 
pinned bo.

Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 113 ++-
 1 file changed, 97 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8502b3ed2d88..bbf1d14d00a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  * b. Otherwise, trylock it.
  */
 static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+   struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
 {
bool ret = false;
 
*locked = false;
+   if (busy)
+   *busy = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
@@ -779,35 +781,45 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
} else {
*locked = reservation_object_trylock(bo->resv);
ret = *locked;
+   if (!ret && busy)
+   *busy = true;
}
 
return ret;
 }
 
-static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-  uint32_t mem_type,
-  const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+static struct ttm_buffer_object*
+ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
+struct ttm_mem_type_manager *man,
+const struct ttm_place *place,
+struct ttm_operation_ctx *ctx,
+struct ttm_buffer_object **first_bo,
+bool *locked)
 {
-   struct ttm_bo_global *glob = bdev->glob;
-   struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo = NULL;
-   bool locked = false;
-   unsigned i;
-   int ret;
+   int i;
 
-   spin_lock(>lru_lock);
+   if (first_bo)
+   *first_bo = NULL;
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   bool busy = false;
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
+   )) {
+   if (first_bo && !(*first_bo) && busy) {
+   ttm_bo_get(bo);
+   *first_bo = bo;
+   }
continue;
+   }
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-   if (locked)
+   if (*locked)
reservation_object_unlock(bo->resv);
continue;
}
+
break;
}
 
@@ -818,9 +830,66 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
bo = NULL;
}
 
+   return bo;
+}
+
+static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  struct ttm_operation_ctx *ctx)
+{
+   struct ttm_bo_global *glob = bdev->glob;
+   struct ttm_mem_type_manager *man = >man[mem_type];
+   struct ttm_buffer_object *bo = NULL, *first_bo = NULL;
+   bool locked = false;
+   int ret;
+
+   spin_lock(>lru_lock);
+   bo = 

RE: [v8 01/10] drm: Add HDR source metadata property

2019-05-07 Thread Shankar, Uma


>-Original Message-
>From: Jonas Karlman [mailto:jo...@kwiboo.se]
>Sent: Saturday, May 4, 2019 3:48 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v8 01/10] drm: Add HDR source metadata property
>
>On 2019-04-09 18:44, Uma Shankar wrote:
>> This patch adds a blob property to get HDR metadata information from
>> userspace. This will be send as part of AVI Infoframe to panel.
>>
>> It also implements get() and set() functions for HDR output metadata
>> property.The blob data is received from userspace and saved in
>> connector state, the same is returned as blob in get property call to
>> userspace.
>>
>> v2: Rebase and modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Rebase.
>>
>> v6: Addressed Brian Starkey's review comments, defined new structure
>> with header for dynamic metadata scalability.
>> Merge get/set property functions for metadata in this patch.
>>
>> v7: Addressed Jonas Karlman review comments and defined separate
>> structure for infoframe to better align with CTA 861.G spec. Added
>> Shashank's RB.
>>
>> Signed-off-by: Uma Shankar 
>> Reviewed-by: Shashank Sharma 
>> ---
>>  drivers/gpu/drm/drm_atomic.c  |  2 ++
>>  drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>>  drivers/gpu/drm/drm_connector.c   |  6 ++
>>  include/drm/drm_connector.h   | 11 +++
>>  include/drm/drm_mode_config.h |  6 ++
>>  include/linux/hdmi.h  | 10 ++
>>  include/uapi/drm/drm_mode.h   | 39
>+++
>>  7 files changed, 87 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -881,6 +881,8 @@ static void
>> drm_atomic_connector_print_state(struct drm_printer *p,
>>
>>  drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
>>name);
>>  drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
>> "(null)");
>> +drm_printf(p, "\thdr_metadata_changed=%d\n",
>> +   state->hdr_metadata_changed);
>>
>>  if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>>  if (state->writeback_job && state->writeback_job->fb) diff --git
>> a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index ea797d4..6d0d161 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -673,6 +673,8 @@ static int
>> drm_atomic_connector_set_property(struct drm_connector *connector,  {
>>  struct drm_device *dev = connector->dev;
>>  struct drm_mode_config *config = >mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>>  if (property == config->prop_crtc_id) {
>>  struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -721,6
>> +723,14 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>>   */
>>  if (state->link_status != DRM_LINK_STATUS_GOOD)
>>  state->link_status = val;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>hdr_output_metadata_blob_ptr,
>> +val,
>> +-1, sizeof(struct hdr_output_metadata),
>> +);
>> +state->hdr_metadata_changed |= replaced;
>> +return ret;
>>  } else if (property == config->aspect_ratio_property) {
>>  state->picture_aspect_ratio = val;
>>  } else if (property == config->content_type_property) { @@ -807,6
>> +817,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>>  *val = state->colorspace;
>>  } else if (property == connector->scaling_mode_property) {
>>  *val = state->scaling_mode;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +*val = (state->hdr_output_metadata_blob_ptr) ?
>> +state->hdr_output_metadata_blob_ptr->base.id : 0;
>>  } else if (property == connector->content_protection_property) {
>>  *val = state->content_protection;
>>  } else if (property == config->writeback_fb_id_property) { diff
>> --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 2355124..0bdae90 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
>drm_device *dev)
>>  return -ENOMEM;
>>  dev->mode_config.non_desktop_property = prop;
>>
>> 

  1   2   >