date:20191001

Re: [PATCH v4] drm/amdgpu: fix multiple memory leaks in acp_hw_init

2019-10-01 Thread Koenig, Christian

Am 02.10.19 um 05:46 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocations should be released if
> mfd_add_hotplug_devices or pm_genpd_add_device fail.
> 3- Release is needed in case of time out values expire.
>
> Signed-off-by: Navid Emamdoost 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 34 -
>   1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index eba42c752bca..82155ac3288a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -189,7 +189,7 @@ static int acp_hw_init(void *handle)
>   u32 val = 0;
>   u32 count = 0;
>   struct device *dev;
> - struct i2s_platform_data *i2s_pdata;
> + struct i2s_platform_data *i2s_pdata = NULL;
>   
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>   
> @@ -231,20 +231,21 @@ static int acp_hw_init(void *handle)
>   adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
>   GFP_KERNEL);
>   
> - if (adev->acp.acp_cell == NULL)
> - return -ENOMEM;
> + if (adev->acp.acp_cell == NULL) {
> + r = -ENOMEM;
> + goto failure;
> + }
>   
>   adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
>   if (adev->acp.acp_res == NULL) {
> - kfree(adev->acp.acp_cell);
> - return -ENOMEM;
> + r = -ENOMEM;
> + goto failure;
>   }
>   
>   i2s_pdata = kcalloc(3, sizeof(struct i2s_platform_data), GFP_KERNEL);
>   if (i2s_pdata == NULL) {
> - kfree(adev->acp.acp_res);
> - kfree(adev->acp.acp_cell);
> - return -ENOMEM;
> + r = -ENOMEM;
> + goto failure;
>   }
>   
>   switch (adev->asic_type) {
> @@ -341,14 +342,14 @@ static int acp_hw_init(void *handle)
>   r = mfd_add_hotplug_devices(adev->acp.parent, adev->acp.acp_cell,
>   ACP_DEVS);
>   if (r)
> - return r;
> + goto failure;
>   
>   for (i = 0; i < ACP_DEVS ; i++) {
>   dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
>   r = pm_genpd_add_device(&adev->acp.acp_genpd->gpd, dev);
>   if (r) {
>   dev_err(dev, "Failed to add dev to genpd\n");
> - return r;
> + goto failure;
>   }
>   }
>   
> @@ -367,7 +368,8 @@ static int acp_hw_init(void *handle)
>   break;
>   if (--count == 0) {
>   dev_err(&adev->pdev->dev, "Failed to reset ACP\n");
> - return -ETIMEDOUT;
> + r = -ETIMEDOUT;
> + goto failure;
>   }
>   udelay(100);
>   }
> @@ -384,7 +386,8 @@ static int acp_hw_init(void *handle)
>   break;
>   if (--count == 0) {
>   dev_err(&adev->pdev->dev, "Failed to reset ACP\n");
> - return -ETIMEDOUT;
> + r = -ETIMEDOUT;
> + goto failure;
>   }
>   udelay(100);
>   }
> @@ -393,6 +396,13 @@ static int acp_hw_init(void *handle)
>   val &= ~ACP_SOFT_RESET__SoftResetAud_MASK;
>   cgs_write_register(adev->acp.cgs_device, mmACP_SOFT_RESET, val);
>   return 0;
> +
> +failure:
> + kfree(i2s_pdata);
> + kfree(adev->acp.acp_res);
> + kfree(adev->acp.acp_cell);
> + kfree(adev->acp.acp_genpd);
> + return r;
>   }
>   
>   /**

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

[PATCH 1/2] drm/virtgpu: plumb fix for virtgpu_drm.h / virtio_gpu.h discrepancy

2019-10-01 Thread Gurchetan Singh

virglrenderer has logic to validate both stride and layer_stride,
but both are always zero. The fallback for that case is:

stride = width * bytes_per_pixel
layer_stride = stride * num_layers

However, this assumption causes trouble in the following cases:

1) When allocating host-compatible buffers for the planned wayland integration.
2) Certain YUV buffers, which Gallium imports as 3 R8 buffers with variable
   strides. For example, HAL_PIXEL_FORMAT_YV12 requires that the chroma planes
   are aligned to 16 bytes.

This commit doesn't fix the discrepancy, but adds the necessary plumbing
so we don't forget.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   | 2 ++
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 ++---
 drivers/gpu/drm/virtio/virtgpu_vq.c| 6 ++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 314e02f94d9c..c1c9a9b8e25c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -312,12 +312,14 @@ void virtio_gpu_cmd_submit(struct virtio_gpu_device 
*vgdev,
 void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev,
  uint32_t ctx_id,
  uint64_t offset, uint32_t level,
+ uint32_t stride, uint32_t 
layer_stride,
  struct virtio_gpu_box *box,
  struct virtio_gpu_object_array *objs,
  struct virtio_gpu_fence *fence);
 void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
uint32_t ctx_id,
uint64_t offset, uint32_t level,
+   uint32_t stride, uint32_t layer_stride,
struct virtio_gpu_box *box,
struct virtio_gpu_object_array *objs,
struct virtio_gpu_fence *fence);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 9af1ec62434f..98b72dead962 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -324,8 +324,10 @@ static int virtio_gpu_transfer_from_host_ioctl(struct 
drm_device *dev,
ret = -ENOMEM;
goto err_unlock;
}
+
+   /* TODO: add the correct stride / layer_stride. */
virtio_gpu_cmd_transfer_from_host_3d
-   (vgdev, vfpriv->ctx_id, offset, args->level,
+   (vgdev, vfpriv->ctx_id, offset, args->level, 0, 0,
 &box, objs, fence);
dma_fence_put(&fence->f);
return 0;
@@ -369,10 +371,11 @@ static int virtio_gpu_transfer_to_host_ioctl(struct 
drm_device *dev, void *data,
if (!fence)
goto err_unlock;
 
+   /* TODO: add the correct stride / layer_stride. */
virtio_gpu_cmd_transfer_to_host_3d
(vgdev,
-vfpriv ? vfpriv->ctx_id : 0, offset,
-args->level, &box, objs, fence);
+vfpriv ? vfpriv->ctx_id : 0, offset, args->level,
+0, 0, &box, objs, fence);
dma_fence_put(&fence->f);
}
return 0;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 80176f379ad5..9fb3c8c3b687 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -965,6 +965,7 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device 
*vgdev,
 void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
uint32_t ctx_id,
uint64_t offset, uint32_t level,
+   uint32_t stride, uint32_t layer_stride,
struct virtio_gpu_box *box,
struct virtio_gpu_object_array *objs,
struct virtio_gpu_fence *fence)
@@ -990,6 +991,8 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct 
virtio_gpu_device *vgdev,
cmd_p->box = *box;
cmd_p->offset = cpu_to_le64(offset);
cmd_p->level = cpu_to_le32(level);
+   cmd_p->stride = cpu_to_le32(stride);
+   cmd_p->layer_stride = cpu_to_le32(layer_stride);
 
virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence);
 }
@@ -997,6 +1000,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct 
virtio_gpu_device *vgdev,
 void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev,
  uint32_t ctx_id,

[PATCH 2/2] [RFC] drm/virtgpu: modify uapi with stride/layer_stride fix

2019-10-01 Thread Gurchetan Singh

This doesn't really break userspace, since it always passes down
0 for stride/layer_stride currently. We could:

(1) modify UAPI now and add a VIRTGPU_PARAM_STRIDE_FIX feature

(2) modify the UAPI now, and not expose a corresponding feature
(i.e, VIRTGPU_PARAM_STRIDE_FIX).  This would fold this minor fix
into another bigger feature (like the proposed metadata query).

(3) don't modify UAPI now, wait until another feature lands.

I don't have a preference either way, as long as we get something like
this eventually.

The corresponding userspace is:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2129

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8 +++-
 include/uapi/drm/virtgpu_drm.h | 4 
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 98b72dead962..c29473ac24a1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -325,10 +325,9 @@ static int virtio_gpu_transfer_from_host_ioctl(struct 
drm_device *dev,
goto err_unlock;
}
 
-   /* TODO: add the correct stride / layer_stride. */
virtio_gpu_cmd_transfer_from_host_3d
-   (vgdev, vfpriv->ctx_id, offset, args->level, 0, 0,
-&box, objs, fence);
+   (vgdev, vfpriv->ctx_id, offset, args->level, args->stride,
+args->layer_stride, &box, objs, fence);
dma_fence_put(&fence->f);
return 0;
 
@@ -371,11 +370,10 @@ static int virtio_gpu_transfer_to_host_ioctl(struct 
drm_device *dev, void *data,
if (!fence)
goto err_unlock;
 
-   /* TODO: add the correct stride / layer_stride. */
virtio_gpu_cmd_transfer_to_host_3d
(vgdev,
 vfpriv ? vfpriv->ctx_id : 0, offset, args->level,
-0, 0, &box, objs, fence);
+args->stride, args->layer_stride, &box, objs, fence);
dma_fence_put(&fence->f);
}
return 0;
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index f06a789f34cd..b2fc92c3d2be 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -117,6 +117,8 @@ struct drm_virtgpu_3d_transfer_to_host {
struct drm_virtgpu_3d_box box;
__u32 level;
__u32 offset;
+   __u32 stride;
+   __u32 layer_stride;
 };
 
 struct drm_virtgpu_3d_transfer_from_host {
@@ -124,6 +126,8 @@ struct drm_virtgpu_3d_transfer_from_host {
struct drm_virtgpu_3d_box box;
__u32 level;
__u32 offset;
+   __u32 stride;
+   __u32 layer_stride;
 };
 
 #define VIRTGPU_WAIT_NOWAIT 1 /* like it */
-- 
2.23.0.444.g18eeb5a265-goog

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

[Bug 111846] Suspend to RAM cause screen to glitch on navi10

2019-10-01 Thread bugzilla-daemon

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

--- Comment #3 from Yuxuan Shui  ---
Created attachment 145611
  --> https://bugs.freedesktop.org/attachment.cgi?id=145611&action=edit
Xorg.0.log (has a couple of suspension/hibernation)

-- 
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 111846] Suspend to RAM cause screen to glitch on navi10

2019-10-01 Thread bugzilla-daemon

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

--- Comment #2 from Yuxuan Shui  ---
Created attachment 145610
  --> https://bugs.freedesktop.org/attachment.cgi?id=145610&action=edit
dmesg (from suspend entry to exit)

-- 
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 111879] GPU reset during hibernation

2019-10-01 Thread bugzilla-daemon

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

--- Comment #4 from Yuxuan Shui  ---
(In reply to Alex Deucher from comment #3)
> Created attachment 145608 [details] [review]
> possible fix
> 
> Does this patch fix the issue?

I hiberate/resumed with this patch a couple of times, the problem hasn't
occurred so far. Looks like this fixes the problem.

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

[Bug 204611] amdgpu error scheduling IBs when waking from sleep

2019-10-01 Thread bugzilla-daemon

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

--- Comment #4 from tones...@hotmail.com ---
I've been able to narrow the problem down a bit.

The first commit where I get the scrolling amdgpu errors is
4f8b49092c37cf0c87c43bb2698d43c71cf0e4e5

Unfortunately that's a merge commit.
One of the parents appears to be good
ceacbc0e145e3b27d8b12eecb881f9d87702765a

The other parent
5dd6c49339126c2c8df2179041373222362d6e49
causes lockups that don't have any journal messages after going to sleep.  I've
tried bisecting this back to v5.1-rc1 (good) but the lockups become much less
consistent.

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

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

2019-10-01 Thread bugzilla-daemon

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

--- Comment #153 from ReddestDream  ---
Just FYI, it appears that kernel 5.3.2 does not have the Vega 20 fix commits
that Alex Deucher mentioned.

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

[PATCH V4 3/3] ARM: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel

2019-10-01 Thread Adam Ford

With the removal of the panel-dpi from the omap drivers, the
LCD no longer works.  This patch points the device tree to
a newly created panel named "logicpd,type28"

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford 
Acked-by: Sam Ravnborg 
---
V4:  No Change
V3:  No change
V2:  Remove legacy 'label' from binding

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
index 07ac99b9cda6..cdb89b3e2a9b 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
@@ -11,22 +11,6 @@
 #include "logicpd-torpedo-37xx-devkit.dts"
 
 &lcd0 {
-
-   label = "28";
-
-   panel-timing {
-   clock-frequency = <900>;
-   hactive = <480>;
-   vactive = <272>;
-   hfront-porch = <3>;
-   hback-porch = <2>;
-   hsync-len = <42>;
-   vback-porch = <3>;
-   vfront-porch = <2>;
-   vsync-len = <11>;
-   hsync-active = <1>;
-   vsync-active = <1>;
-   de-active = <1>;
-   pixelclk-active = <0>;
-   };
+   /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
+   compatible = "logicpd,type28";
 };
-- 
2.17.1

[PATCH V4 3/3] ARM: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel

2019-10-01 Thread Adam Ford

With the removal of the panel-dpi from the omap drivers, the
LCD no longer works.  This patch points the device tree to
a newly created panel named "logicpd,type28"

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford 
Acked-by: Sam Ravnborg 
---
V4:  No Change
V3:  No change
V2:  Remove legacy 'label' from binding

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
index 07ac99b9cda6..cdb89b3e2a9b 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
@@ -11,22 +11,6 @@
 #include "logicpd-torpedo-37xx-devkit.dts"
 
 &lcd0 {
-
-   label = "28";
-
-   panel-timing {
-   clock-frequency = <900>;
-   hactive = <480>;
-   vactive = <272>;
-   hfront-porch = <3>;
-   hback-porch = <2>;
-   hsync-len = <42>;
-   vback-porch = <3>;
-   vfront-porch = <2>;
-   vsync-len = <11>;
-   hsync-active = <1>;
-   vsync-active = <1>;
-   de-active = <1>;
-   pixelclk-active = <0>;
-   };
+   /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
+   compatible = "logicpd,type28";
 };
-- 
2.17.1

[PATCH V4 1/3] drm/panel: simple: Add Logic PD Type 28 display support

2019-10-01 Thread Adam Ford

Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly.  This driver was removed so the screen
no longer functions.  This patch modifies the panel-simple
file to setup the timings to the same values previously used.

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford 
Reviewed-by: Sam Ravnborg 
---
V4:  No Change
V3:  No Change
V2:  No Change

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..8abb31f83ffc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2048,6 +2048,40 @@ static const struct drm_display_mode 
mitsubishi_aa070mc01_mode = {
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
 };
 
+static const struct drm_display_mode logicpd_type_28_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 3,
+   .hsync_end = 480 + 3 + 42,
+   .htotal = 480 + 3 + 42 + 2,
+
+   .vdisplay = 272,
+   .vsync_start = 272 + 2,
+   .vsync_end = 272 + 2 + 11,
+   .vtotal = 272 + 2 + 11 + 3,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc logicpd_type_28 = {
+   .modes = &logicpd_type_28_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 105,
+   .height = 67,
+   },
+   .delay = {
+   .prepare = 200,
+   .enable = 200,
+   .unprepare = 200,
+   .disable = 200,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
+DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+};
+
 static const struct panel_desc mitsubishi_aa070mc01 = {
.modes = &mitsubishi_aa070mc01_mode,
.num_modes = 1,
@@ -3264,6 +3298,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lp129qe",
.data = &lg_lp129qe,
+   }, {
+   .compatible = "logicpd,type28",
+   .data = &logicpd_type_28,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = &mitsubishi_aa070mc01,
-- 
2.17.1

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

[PATCH V4 2/3] dt-bindings: Add Logic PD Type 28 display panel

2019-10-01 Thread Adam Ford

This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.

Signed-off-by: Adam Ford 
---
V4:  Update per Rob H's suggestions and copy other panel yaml example from 
5.4-rc1
V3:  Correct build errors from 'make dt_binding_check'
V2:  Use YAML instead of TXT for binding

diff --git 
a/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml 
b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml
new file mode 100644
index ..e2c62e8f1db4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/logicpd,type28.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Logic PD Type 28 4.3" WQVGA TFT LCD panel
+
+maintainers:
+  - Adam Ford 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: logicpd,type28
+
+  power-supply: true
+  enable-gpios: true
+  backlight: true
+  port: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+lcd0: display {
+  compatible = "logicpd,type28";
+  enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
+  backlight = <&backlight>;
+  port {
+lcd_in: endpoint {
+  remote-endpoint = <&dpi_out>;
+};
+  };
+};
+
+...
-- 
2.17.1

[PATCH V4 1/3] drm/panel: simple: Add Logic PD Type 28 display support

2019-10-01 Thread Adam Ford

Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly.  This driver was removed so the screen
no longer functions.  This patch modifies the panel-simple
file to setup the timings to the same values previously used.

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford 
Reviewed-by: Sam Ravnborg 
---
V4:  No Change
V3:  No Change
V2:  No Change

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..8abb31f83ffc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2048,6 +2048,40 @@ static const struct drm_display_mode 
mitsubishi_aa070mc01_mode = {
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
 };
 
+static const struct drm_display_mode logicpd_type_28_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 3,
+   .hsync_end = 480 + 3 + 42,
+   .htotal = 480 + 3 + 42 + 2,
+
+   .vdisplay = 272,
+   .vsync_start = 272 + 2,
+   .vsync_end = 272 + 2 + 11,
+   .vtotal = 272 + 2 + 11 + 3,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc logicpd_type_28 = {
+   .modes = &logicpd_type_28_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 105,
+   .height = 67,
+   },
+   .delay = {
+   .prepare = 200,
+   .enable = 200,
+   .unprepare = 200,
+   .disable = 200,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
+DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+};
+
 static const struct panel_desc mitsubishi_aa070mc01 = {
.modes = &mitsubishi_aa070mc01_mode,
.num_modes = 1,
@@ -3264,6 +3298,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lp129qe",
.data = &lg_lp129qe,
+   }, {
+   .compatible = "logicpd,type28",
+   .data = &logicpd_type_28,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = &mitsubishi_aa070mc01,
-- 
2.17.1

[PATCH V4 2/3] dt-bindings: Add Logic PD Type 28 display panel

2019-10-01 Thread Adam Ford

This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.

Signed-off-by: Adam Ford 
---
V4:  Update per Rob H's suggestions and copy other panel yaml example from 
5.4-rc1
V3:  Correct build errors from 'make dt_binding_check'
V2:  Use YAML instead of TXT for binding

diff --git 
a/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml 
b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml
new file mode 100644
index ..e2c62e8f1db4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/logicpd,type28.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Logic PD Type 28 4.3" WQVGA TFT LCD panel
+
+maintainers:
+  - Adam Ford 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: logicpd,type28
+
+  power-supply: true
+  enable-gpios: true
+  backlight: true
+  port: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+lcd0: display {
+  compatible = "logicpd,type28";
+  enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
+  backlight = <&backlight>;
+  port {
+lcd_in: endpoint {
+  remote-endpoint = <&dpi_out>;
+};
+  };
+};
+
+...
-- 
2.17.1

[PATCH] backlight: pwm_bl: Don't assign levels table repeatedly

2019-10-01 Thread Matthias Kaehlcke

pwm_backlight_probe() re-assigns pb->levels for every brightness
level. This is not needed and was likely not intended, since
neither side of the assignment changes during the loop. Assign
the field only once.

Signed-off-by: Matthias Kaehlcke 
---

 drivers/video/backlight/pwm_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 746eebc411df..959436b9e92b 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -564,6 +564,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
memset(&props, 0, sizeof(struct backlight_properties));
 
if (data->levels) {
+   pb->levels = data->levels;
+
/*
 * For the DT case, only when brightness levels is defined
 * data->levels is filled. For the non-DT case, data->levels
@@ -572,8 +574,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
for (i = 0; i <= data->max_brightness; i++) {
if (data->levels[i] > pb->scale)
pb->scale = data->levels[i];
-
-   pb->levels = data->levels;
}
 
if (pwm_backlight_is_linear(data))
-- 
2.23.0.444.g18eeb5a265-goog

Re: [PATCH] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Liu, Leo


On 2019-10-01 5:57 p.m., Gustavo A. R. Silva wrote:
>
> On 10/1/19 16:46, Liu, Leo wrote:
>
> + ring->sched.ready = true;
 This is redundant. all the sched->ready is initialized as true, please
 refer to drm_sched_init()

>>> I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial 
>>> VCN2.0 support (v2)")
>>> that line is also redundant?
>> Yes.
>>
> OK.
>
>   r = amdgpu_ring_test_ring(ring);
>   if (r) {
>   ring->sched.ready = false;
> @@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
> 
>   for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
>   ring = &adev->vcn.inst[j].ring_enc[i];
> - ring->sched.ready = false;
> - continue;
> + ring->sched.ready = true;
 Because the VCN 2.5 FW still has issue for encode, so we have it
 disabled here.

>>> OK. So, maybe we can add a comment pointing that out?
>> That could be better.
>>
> Great. I'm glad it's not a bug.  I'll write a patch for that so other
> people don't waste time taking a look.

Thanks, just sent two patches to add comment, and long with the patch to 
make VCN ring ready properly.

Leo




>
> I appreciate your feedback.
> Thanks
> --
> Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Gustavo A. R. Silva



On 10/1/19 16:46, Liu, Leo wrote:

 +  ring->sched.ready = true;
>>> This is redundant. all the sched->ready is initialized as true, please
>>> refer to drm_sched_init()
>>>
>> I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial 
>> VCN2.0 support (v2)")
>> that line is also redundant?
> 
> Yes.
> 

OK.

> 
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
 @@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)

for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
ring = &adev->vcn.inst[j].ring_enc[i];
 -  ring->sched.ready = false;
 -  continue;
 +  ring->sched.ready = true;
>>> Because the VCN 2.5 FW still has issue for encode, so we have it
>>> disabled here.
>>>
>> OK. So, maybe we can add a comment pointing that out?
> 
> That could be better.
> 

Great. I'm glad it's not a bug.  I'll write a patch for that so other
people don't waste time taking a look.

I appreciate your feedback.
Thanks
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] dt-bindings: add vendor prefix for logic technologies limited

2019-10-01 Thread Rob Herring

On Fri, 20 Sep 2019 09:54:10 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Add vendor prefix for Logic Technologies Limited [1] which is a Chinese
> display manufacturer e.g. distributed by German Endrich Bauelemente
> Vertriebs GmbH [2].
> 
> [1] https://logictechno.com/contact-us/
> [2] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 

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

Re: [PATCH] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Gustavo A. R. Silva

Hi,

On 10/1/19 16:29, Liu, Leo wrote:
> 
> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>> Notice that there is a *continue* statement in the middle of the
>> for loop and that prevents the code below from ever being reached:
>>
>>  r = amdgpu_ring_test_ring(ring);
>>  if (r) {
>>  ring->sched.ready = false;
>>  goto done;
>>  }
>>
>> Fix this by removing the continue statement and updating ring->sched.ready
>> to true before calling amdgpu_ring_test_ring(ring).
>>
>> Notice that this fix is based on
>> commit 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)")
>>
>> Addresses-Coverity-ID 1485608 ("Structurally dead code")
>> Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports")
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>
>> Any feedback is greatly appreciated.
>>
>>   drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>> index 395c2259f979..47b0dcd59e13 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>> @@ -258,6 +258,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>  adev->nbio_funcs->vcn_doorbell_range(adev, ring->use_doorbell,
>>   ring->doorbell_index, j);
>>   
>> +ring->sched.ready = true;
> 
> This is redundant. all the sched->ready is initialized as true, please 
> refer to drm_sched_init()
> 

I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial 
VCN2.0 support (v2)")
that line is also redundant?

> 
>>  r = amdgpu_ring_test_ring(ring);
>>  if (r) {
>>  ring->sched.ready = false;
>> @@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>   
>>  for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
>>  ring = &adev->vcn.inst[j].ring_enc[i];
>> -ring->sched.ready = false;
>> -continue;
>> +ring->sched.ready = true;
> 
> Because the VCN 2.5 FW still has issue for encode, so we have it 
> disabled here.
> 

OK. So, maybe we can add a comment pointing that out?

Thanks
--
Gustavo

> 
>>  r = amdgpu_ring_test_ring(ring);
>>  if (r) {
>>  ring->sched.ready = false;
>> @@ -276,6 +276,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>  }
>>   
>>  ring = &adev->vcn.inst[j].ring_jpeg;
>> +ring->sched.ready = true;
>>  r = amdgpu_ring_test_ring(ring);
>>  if (r) {
>>  ring->sched.ready = false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/2] drm/panel: simple: add display timings for logic technologies displays

2019-10-01 Thread Rob Herring

On Fri, Sep 20, 2019 at 09:54:11AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Add display timings for the following 3 display panels manufactured by
> Logic Technologies Limited:
> 
> - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
>   7" Parallel [1]
> - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7"
>   Parallel [2]
> - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display
>   10.1" LVDS [3]
> 
> Those panels may also be distributed by Endrich Bauelemente Vertriebs
> GmbH [4].
> 
> [1] 
> https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf
> [2] 
> https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf
> [3] 
> https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf
> [4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 65 
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 28fa6ba7b767..42bd0de25167 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2034,6 +2034,62 @@ static const struct panel_desc lg_lp129qe = {
>   },
>  };
>  
> +static const struct display_timing logictechno_lt161010_2nh_timing = {
> + .pixelclock = { 2640, 3330, 4680 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 16, 210, 354 },
> + .hback_porch = { 46, 46, 46 },
> + .hsync_len = { 1, 20, 40 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 7, 22, 147 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 1, 10, 20 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> +  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
> +  DISPLAY_FLAGS_SYNC_POSEDGE,
> +};
> +
> +static const struct panel_desc logictechno_lt161010_2nh = {
> + .timings = &logictechno_lt161010_2nh_timing,
> + .num_timings = 1,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> +  DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> +  DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
> +};
> +
> +static const struct display_timing logictechno_lt170410_2whc_timing = {
> + .pixelclock = { 6890, 7110, 734 },
> + .hactive = { 1280, 1280, 1280 },
> + .hfront_porch = { 23, 60, 71 },
> + .hback_porch = { 23, 60, 71 },
> + .hsync_len = { 15, 40, 47 },
> + .vactive = { 800, 800, 800 },
> + .vfront_porch = { 5, 7, 10 },
> + .vback_porch = { 5, 7, 10 },
> + .vsync_len = { 6, 9, 12 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> +  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
> +  DISPLAY_FLAGS_SYNC_POSEDGE,
> +};
> +
> +static const struct panel_desc logictechno_lt170410_2whc = {
> + .timings = &logictechno_lt170410_2whc_timing,
> + .num_timings = 1,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> +  DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> +  DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
> +};
> +
>  static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
>   .clock = 30400,
>   .hdisplay = 800,
> @@ -3264,6 +3320,15 @@ static const struct of_device_id platform_of_match[] = 
> {
>   }, {
>   .compatible = "lg,lp129qe",
>   .data = &lg_lp129qe,
> + }, {
> + .compatible = "logictechno,lt161010-2nhc",
> + .data = &logictechno_lt161010_2nh,
> + }, {
> + .compatible = "logictechno,lt161010-2nhr",
> + .data = &logictechno_lt161010_2nh,
> + }, {
> + .compatible = "logictechno,lt170410-2whc",
> + .data = &logictechno_lt170410_2whc,

The vendor prefix wasn't documented, but the compatible string and rest 
already are?

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

[Bug 111879] GPU reset during hibernation

2019-10-01 Thread bugzilla-daemon

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

--- Comment #3 from Alex Deucher  ---
Created attachment 145608
  --> https://bugs.freedesktop.org/attachment.cgi?id=145608&action=edit
possible fix

Does this patch fix the issue?

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

Re: [PATCH] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Liu, Leo


On 2019-10-01 5:43 p.m., Gustavo A. R. Silva wrote:
> Hi,
>
> On 10/1/19 16:29, Liu, Leo wrote:
>> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>>> Notice that there is a *continue* statement in the middle of the
>>> for loop and that prevents the code below from ever being reached:
>>>
>>> r = amdgpu_ring_test_ring(ring);
>>> if (r) {
>>> ring->sched.ready = false;
>>> goto done;
>>> }
>>>
>>> Fix this by removing the continue statement and updating ring->sched.ready
>>> to true before calling amdgpu_ring_test_ring(ring).
>>>
>>> Notice that this fix is based on
>>> commit 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)")
>>>
>>> Addresses-Coverity-ID 1485608 ("Structurally dead code")
>>> Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports")
>>> Signed-off-by: Gustavo A. R. Silva 
>>> ---
>>>
>>> Any feedback is greatly appreciated.
>>>
>>>drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 5 +++--
>>>1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
>>> b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>>> index 395c2259f979..47b0dcd59e13 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
>>> @@ -258,6 +258,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>> adev->nbio_funcs->vcn_doorbell_range(adev, ring->use_doorbell,
>>>  ring->doorbell_index, j);
>>>
>>> +   ring->sched.ready = true;
>> This is redundant. all the sched->ready is initialized as true, please
>> refer to drm_sched_init()
>>
> I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial 
> VCN2.0 support (v2)")
> that line is also redundant?

Yes.


>>> r = amdgpu_ring_test_ring(ring);
>>> if (r) {
>>> ring->sched.ready = false;
>>> @@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>>
>>> for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
>>> ring = &adev->vcn.inst[j].ring_enc[i];
>>> -   ring->sched.ready = false;
>>> -   continue;
>>> +   ring->sched.ready = true;
>> Because the VCN 2.5 FW still has issue for encode, so we have it
>> disabled here.
>>
> OK. So, maybe we can add a comment pointing that out?

That could be better.

Thanks,
Leo


>
> Thanks
> --
> Gustavo
>
>>> r = amdgpu_ring_test_ring(ring);
>>> if (r) {
>>> ring->sched.ready = false;
>>> @@ -276,6 +276,7 @@ static int vcn_v2_5_hw_init(void *handle)
>>> }
>>>
>>> ring = &adev->vcn.inst[j].ring_jpeg;
>>> +   ring->sched.ready = true;
>>> r = amdgpu_ring_test_ring(ring);
>>> if (r) {
>>> ring->sched.ready = false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111879] GPU reset during hibernation

2019-10-01 Thread bugzilla-daemon

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

--- Comment #2 from Alex Deucher  ---
What chip is this?  Please attach your full dmesg output.

-- 
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] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Liu, Leo


On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
> Notice that there is a *continue* statement in the middle of the
> for loop and that prevents the code below from ever being reached:
>
>   r = amdgpu_ring_test_ring(ring);
>   if (r) {
>   ring->sched.ready = false;
>   goto done;
>   }
>
> Fix this by removing the continue statement and updating ring->sched.ready
> to true before calling amdgpu_ring_test_ring(ring).
>
> Notice that this fix is based on
> commit 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)")
>
> Addresses-Coverity-ID 1485608 ("Structurally dead code")
> Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>
> Any feedback is greatly appreciated.
>
>   drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
> b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> index 395c2259f979..47b0dcd59e13 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> @@ -258,6 +258,7 @@ static int vcn_v2_5_hw_init(void *handle)
>   adev->nbio_funcs->vcn_doorbell_range(adev, ring->use_doorbell,
>ring->doorbell_index, j);
>   
> + ring->sched.ready = true;

This is redundant. all the sched->ready is initialized as true, please 
refer to drm_sched_init()


>   r = amdgpu_ring_test_ring(ring);
>   if (r) {
>   ring->sched.ready = false;
> @@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
>   
>   for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
>   ring = &adev->vcn.inst[j].ring_enc[i];
> - ring->sched.ready = false;
> - continue;
> + ring->sched.ready = true;

Because the VCN 2.5 FW still has issue for encode, so we have it 
disabled here.


Regards,

Leo




>   r = amdgpu_ring_test_ring(ring);
>   if (r) {
>   ring->sched.ready = false;
> @@ -276,6 +276,7 @@ static int vcn_v2_5_hw_init(void *handle)
>   }
>   
>   ring = &adev->vcn.inst[j].ring_jpeg;
> + ring->sched.ready = true;
>   r = amdgpu_ring_test_ring(ring);
>   if (r) {
>   ring->sched.ready = false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: add fb max width/height fields to drm_mode_config

2019-10-01 Thread Jeykumar Sankaran


On 2019-09-30 03:39, Ville Syrjälä wrote:

On Fri, Sep 27, 2019 at 06:28:51PM -0700, Jeykumar Sankaran wrote:

The mode_config max width/height values determine the maximum
resolution the pixel reader can handle.


Not according to the docs I "fixed" a while ago.


But the same values are
used to restrict the size of the framebuffer creation. Hardware's
with scaling blocks can operate on framebuffers larger/smaller than
that of the pixel reader resolutions by scaling them down/up before
rendering.

This changes adds a separate framebuffer max width/height fields
in drm_mode_config to allow vendors to set if they are different
than that of the default max resolution values.


If you're going to change the meaning of the old values you need
to fix the drivers too.

Personally I don't see too much point in this since you most likely
want to validate all the other timings as well, and so likely need
some kind of mode_valid implementation anyway. Hence to validate
modes there's not much benefit of having global min/max values.


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

I believe you are referring to this patch.

I am primarily interested in the scaling scenario mentioned here. MSM
and a few other hardware have scaling block that are used both ways:

1) Where FB limits are larger than the display limits. Scalar blocks are 
used to

   downscale the framebuffers and render within display limits.

In this scenario, with your patch, are you suggesting the drivers 
maintain the
display limits locally and use those values in fill_modes() / 
mode_valid() to filter

out invalid modes explicitly instead of mode_config.max_width/height?

2) Where FB limits are smaller than display limits. Enforced for 
performance reasons on low tier hardware.
It reduces the fetch bandwidth and uses post blending scalar block to 
scale up the pixel stream

to match the display resolution.

Any suggestions on how this topology can be handled with a single set of 
max/min values?


Thanks and Regards,
Jeykumar S.


Vendors setting these fields should fix their mode_set paths too
by filtering and validating the modes against the appropriate max
fields in their mode_valid() implementations.

Signed-off-by: Neil Armstrong 
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/drm_framebuffer.c | 15 +++
 include/drm/drm_mode_config.h |  3 +++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c

b/drivers/gpu/drm/drm_framebuffer.c

index 5756431..2083168 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -300,14 +300,21 @@ struct drm_framebuffer *
return ERR_PTR(-EINVAL);
}

-   if ((config->min_width > r->width) || (r->width >

config->max_width)) {

+   if ((config->min_width > r->width) ||
+   (!config->max_fb_width && r->width > config->max_width) ||
+   (config->max_fb_width && r->width > config->max_fb_width)) {
DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d

&& <= %d\n",

- r->width, config->min_width, config->max_width);
+   r->width, config->min_width, config->max_fb_width

?

+   config->max_fb_width : config->max_width);
return ERR_PTR(-EINVAL);
}
-   if ((config->min_height > r->height) || (r->height >

config->max_height)) {

+
+   if ((config->min_height > r->height) ||
+   (!config->max_fb_height && r->height > config->max_height) ||
+   (config->max_fb_height && r->height > config->max_fb_height))

{

DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d

&& <= %d\n",

- r->height, config->min_height,

config->max_height);

+   r->height, config->min_height,

config->max_fb_width ?

+   config->max_fb_height : config->max_height);
return ERR_PTR(-EINVAL);
}

diff --git a/include/drm/drm_mode_config.h

b/include/drm/drm_mode_config.h

index 3bcbe30..c6394ed 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -339,6 +339,8 @@ struct drm_mode_config_funcs {
  * @min_height: minimum fb pixel height on this device
  * @max_width: maximum fb pixel width on this device
  * @max_height: maximum fb pixel height on this device
+ * @max_fb_width: maximum fb buffer width if differs from max_width
+ * @max_fb_height: maximum fb buffer height if differs from  
max_height

  * @funcs: core driver provided mode setting functions
  * @fb_base: base address of the framebuffer
  * @poll_enabled: track polling support for this device
@@ -523,6 +525,7 @@ struct drm_mode_config {

int min_width, min_height;
int max_width, max_height;
+   int max_fb_width, max_fb_height;
const struct drm_mode_config_funcs *funcs;
resource_size_t fb_base;

--
The Qualcomm Innovation Center, Inc. is a member o

[Bug 205069] Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

--- Comment #5 from freddyrei...@comcast.net ---
I've seen another report on a similar issue, where the suggestion (solution?)
was to be using a newer mesa and llvm. I am on llvm 9 and mesa 19.2.0


*  media-libs/mesa
  Latest version available: 19.2.0
  Latest version installed: 19.2.0_rc4

*  sys-devel/llvm
  Latest version available: 9.0.0
  Latest version installed: 9.0.0

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

[Bug 205069] Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

--- Comment #4 from freddyrei...@comcast.net ---
Created attachment 285293
  --> https://bugzilla.kernel.org/attachment.cgi?id=285293&action=edit
Xorg log from amdgpu freeze startx

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

[Bug 205069] Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

--- Comment #3 from freddyrei...@comcast.net ---
Created attachment 285291
  --> https://bugzilla.kernel.org/attachment.cgi?id=285291&action=edit
lspci -vv

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

[Bug 205069] Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

--- Comment #2 from freddyrei...@comcast.net ---
Created attachment 285289
  --> https://bugzilla.kernel.org/attachment.cgi?id=285289&action=edit
lsmod

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

[Bug 205069] Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

--- Comment #1 from freddyrei...@comcast.net ---
Created attachment 285287
  --> https://bugzilla.kernel.org/attachment.cgi?id=285287&action=edit
dmesg

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

[Bug 205069] New: Black screen when starting graphical environment

2019-10-01 Thread bugzilla-daemon

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

Bug ID: 205069
   Summary: Black screen when starting graphical environment
   Product: Drivers
   Version: 2.5
Kernel Version: 5.3.1, 5.4.0-rc1, latest
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: freddyrei...@comcast.net
Regression: No

Created attachment 285285
  --> https://bugzilla.kernel.org/attachment.cgi?id=285285&action=edit
kernel .config 5.4.0-rc1

Hello there

On kernels 5.3.1 and 5.4.0-rc1, I get a black screen with a white underscore
cursor in the upper left. The display gets stuck in this state, with no way to
switch to a different TTY or leave this aside from hitting the reset button.
I can secure-shell into the box and get a login at this time, but killing the
process does not fix the display. Sway WM also does this, with it just getting
stuck at the prompt entry.

I have an AMD RX 5700 graphics card, using the amdgpu driver. When I do some
manual configuration by blacklisting amdgpu and writing a stanza in xorg conf
for vesa, I am able to get X running using vesa.

uname -a output: Linux gentoo 5.4.0-rc1 #1 SMP Tue Oct 1 14:24:57 EDT 2019
x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux

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

Re: [RESEND][PATCH v8 3/5] dma-buf: heaps: Add system heap to dmabuf heaps

2019-10-01 Thread John Stultz

On Mon, Sep 30, 2019 at 12:43 AM Hillf Danton  wrote:
>
>
> On Fri,  6 Sep 2019 18:47:09 + John Stultz wrote:
> >
> > +static int system_heap_allocate(struct dma_heap *heap,
> > + unsigned long len,
> > + unsigned long fd_flags,
> > + unsigned long heap_flags)
> > +{
> > + struct heap_helper_buffer *helper_buffer;
> > + struct dma_buf *dmabuf;
> > + int ret = -ENOMEM;
> > + pgoff_t pg;
> > +
> > + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> > + if (!helper_buffer)
> > + return -ENOMEM;
> > +
> > + init_heap_helper_buffer(helper_buffer, system_heap_free);
> > + helper_buffer->flags = heap_flags;
> > + helper_buffer->heap = heap;
> > + helper_buffer->size = len;
> > +
> A couple of lines looks needed to handle len if it is not
> PAGE_SIZE aligned.

Hey! Thanks so much for the review!

dma_heap_buffer_alloc() sets "len = PAGE_ALIGN(len);" before calling
into the heap allocation hook.
So hopefully this isn't a concern, or am I missing something?

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

Re: [PATCH 10/60] drm/bridge: Add bridge driver for display connectors

2019-10-01 Thread Laurent Pinchart

Hi Tomi,

On Mon, Sep 30, 2019 at 02:15:20PM +0300, Tomi Valkeinen wrote:
> On 07/07/2019 21:18, Laurent Pinchart wrote:
> > Display connectors are modelled in DT as a device node, but have so far
> > been handled manually in several bridge drivers. This resulted in
> > duplicate code in several bridge drivers, with slightly different (and
> > thus confusing) logics.
> > 
> > In order to fix this, implement a bridge driver for display connectors.
> > The driver centralises logic for the DVI, HDMI, VGAn composite and
> > S-video connectors and exposes corresponding bridge operations.
> > 
> > This driver in itself doesn't solve the issue completely, changes in
> > bridge and display controller drivers are needed to make use of the new
> > connector driver.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >   drivers/gpu/drm/bridge/Kconfig |  11 +
> >   drivers/gpu/drm/bridge/Makefile|   1 +
> >   drivers/gpu/drm/bridge/display-connector.c | 327 +
> >   3 files changed, 339 insertions(+)
> >   create mode 100644 drivers/gpu/drm/bridge/display-connector.c
> 
> 
> > +   dev_info(&pdev->dev,
> > +"Found %s display connector '%s' %s DDC bus and %s HPD GPIO 
> > (ops 0x%x)\n",
> > +display_connector_type_name(conn),
> > +conn->label ? conn->label : "",
> > +conn->ddc ? "with" : "without",
> > +conn->hpd_gpio ? "with" : "without",
> > +conn->bridge.ops);
> 
> dev_dbg()?

Many drivers print an info message at probe time when everything goes
fine, to inform about the device that has been succesfully probed. Do
you think this is overkill and a dev_dbg() would be better ?

-- 
Regards,

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

Re: [PATCH v2 05/50] drm/bridge: Extend bridge API to disable connector creation

2019-10-01 Thread Laurent Pinchart

Hi Tomi,

On Tue, Oct 01, 2019 at 10:04:11AM +0300, Tomi Valkeinen wrote:
> On 20/08/2019 04:16, Laurent Pinchart wrote:
> 
> > @@ -,7 +1113,7 @@ int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct 
> > drm_encoder *encoder)
> >   {
> > int ret;
> >   
> > -   ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
> > +   ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, true);
> 
> This doesn't look correct. Where does the "true" come from?

It should be 0. I think it comes from the previous version of this
patch, which I've rebased instead of regenerating it completely with
Coccinelle. I'll fix that.

-- 
Regards,

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

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

2019-10-01 Thread Bjorn Helgaas

On Tue, Oct 01, 2019 at 06:21:28PM +0200, Karol Herbst wrote:
> On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas  wrote:
> > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> > >  wrote:
> > > >
> > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > > > > still happens with your patch applied. The machine simply gets shut 
> > > > > down.
> > > > >
> > > > > dmesg can be found here:
> > > > > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt
> > > >
> > > > Looking your dmesg:
> > > >
> > > > Sep 30 17:24:27 kernel: nouveau :01:00.0: DRM: DCB version 4.1
> > > > Sep 30 17:24:27 kernel: nouveau :01:00.0: DRM: MM: using COPY for 
> > > > buffer copies
> > > > Sep 30 17:24:27 kernel: [drm] Initialized nouveau 1.3.1 20120801 for 
> > > > :01:00.0 on minor 1
> > > >
> > > > I would assume it runtime suspends here. Then it wakes up because of PCI
> > > > access from userspace:
> > > >
> > > > Sep 30 17:24:42 kernel: pci_raw_set_power_state: 56 callbacks suppressed
> > > >
> > > > and for some reason it does not get resumed properly. There are also few
> > > > warnings from ACPI that might be relevant:
> > > >
> > > > Sep 30 17:24:27 kernel: ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 
> > > > type mismatch - Found [Buffer], ACPI requires [Package] 
> > > > (20190509/nsarguments-59)
> > > > Sep 30 17:24:27 kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: 
> > > > Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] 
> > > > (20190509/nsarguments-59)
> > >
> > > afaik this is the case for essentially every laptop out there.
> >
> > I think we should look into this a little bit.
> > acpi_ns_check_argument_types() checks the argument type and prints
> > this message, but AFAICT it doesn't actually fix anything or prevent
> > execution of the method, so I have no idea what happens when we
> > actually execute the _DSM.
> 
> I can assure you that this warning happens on every single laptop out
> there with dual Nvidia graphics and it's essentially just a firmware
> bug. And it never caused any issues on any of the older laptops (or
> newest one for that matter).

Rafael, do you know anything about this?  If ACPI has some sort of
workaround so it can execute the method correctly anyway, maybe we
should remove or reword the warning?

Or if this does prevent execution of the method, maybe we need to add
a workaround since the problem is so prevalent in the field?

> > If we execute this _DSM as part of power management, and the _DSM
> > doesn't work right, it would be no surprise that we have problems.
> >
> > Maybe we could learn something by turning on ACPI_DB_PARSE output (see
> > Documentation/firmware-guide/acpi/debug.rst).
> >
> > You must have an acpidump already from all your investigation.  Can
> > you put it somewhere, e.g., bugzilla.kernel.org, and include a URL?
> 
> Will do so later, right now I am traveling to XDC and will have more
> time for that then.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 8/9] drm: rcar-du: kms: Update CMM in atomic commit tail

2019-10-01 Thread Laurent Pinchart

Hi Ezequiel,

On Mon, Sep 30, 2019 at 05:53:00PM -0300, Ezequiel Garcia wrote:
> +Doug, Heiko:
> 
> On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> > The CMM is updated with new gamma values provided to the driver
> > in the GAMMA_LUT blob property.
> > 
> > When resuming from system suspend, the DU driver is responsible for
> > reprogramming and enabling the CMM unit if it was in use at the time the
> > system entered the suspend state.  Force the color_mgmt_changed flag to
> > true if the DRM gamma lut color transformation property was set in the
> > CRTC state duplicated at suspend time, as the CMM gets reprogrammed only
> > if said flag is active in the rcar_du_atomic_commit_update_cmm() method.
> > 
> > Reviewed-by: Ulrich Hecht 
> > Reviewed-by: Laurent Pinchart 
> > Signed-off-by: Jacopo Mondi 
> > ---
> > 
> > Daniel could you have a look if resume bits are worth being moved to the
> > DRM core? The color_mgmt_changed flag is set to false when the state is
> > duplicated if I read the code correctly, but when this happens in a
> > suspend/resume sequence its value should probably be restored to true if
> > any color management property was set in the crtc state when system entered
> > suspend.
> 
> Perhaps we can use the for_each_new_crtc_in_state() helper here,
> and move it to the core like this:
> 
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3234,8 +3234,20 @@ int drm_atomic_helper_resume(struct
> drm_device *dev,
>  struct drm_atomic_state *state)
>  {
> struct drm_modeset_acquire_ctx ctx;
> +   struct drm_crtc_state
> *crtc_state;
> +   struct drm_crtc *crtc;
> +   unsigned int i;
> int err;
>  
> +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> +   
> /*
> +* Force re-enablement of CMM after system resume if any
> +* of the DRM color transformation properties
> was set in
> +* the state saved at system suspend time.
> +*/
> +   if (crtc_state->gamma_lut)
> +
>crtc_state->color_mgmt_changed = true;
> +   }
> 
> This probably is wrong, and should be instead constrained to some
> condition of some sort.
> 
> FWIW, the Rockchip DRM is going to need this as well.
> 
> Any ideas?

That's more or less what I had in mind, yes. The question is if
something like this would make sense. If there's a consensus it would, I
think it can be done as part of this series.

-- 
Regards,

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

[Bug 111879] GPU reset during hibernation

2019-10-01 Thread bugzilla-daemon

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

--- Comment #1 from Yuxuan Shui  ---
Looks like a GPU reset was triggered during hibernation and that's what's
causing the "Failed to initialize parser" error.

-- 
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 111879] GPU reset during hibernation

2019-10-01 Thread bugzilla-daemon

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

Yuxuan Shui  changed:

   What|Removed |Added

Summary|Failed to initialize parser |GPU reset during
   |after resuming from disk|hibernation

-- 
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 111879] Failed to initialize parser after resuming from disk

2019-10-01 Thread bugzilla-daemon

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

Bug ID: 111879
   Summary: Failed to initialize parser after resuming from disk
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: not set
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: yshu...@gmail.com

Created attachment 145606
  --> https://bugs.freedesktop.org/attachment.cgi?id=145606&action=edit
relevant bits of dmesg

After resuming from hibernation, the screen freezes (flickers between two
frames), and "Failed to initialize parser -125!" is printed repeatedly in
dmesg.

-- 
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: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver

2019-10-01 Thread Sasha Levin


On Fri, Sep 20, 2019 at 05:26:34PM +, Michael Kelley wrote:

From: Michael Kelley   Sent: Wednesday, September 18, 
2019 2:48 PM

>
> Without deferred IO support, hyperv_fb driver informs the host to refresh
> the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> is screen update or not. This patch supports deferred IO for screens in
> graphics mode and also enables the frame buffer on-demand refresh. The
> highest refresh rate is still set at 20Hz.
>
> Currently Hyper-V only takes a physical address from guest as the starting
> address of frame buffer. This implies the guest must allocate contiguous
> physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
> accept address from MMIO region as frame buffer address. Due to these
> limitations on Hyper-V host, we keep a shadow copy of frame buffer
> in the guest. This means one more copy of the dirty rectangle inside
> guest when doing the on-demand refresh. This can be optimized in the
> future with help from host. For now the host performance gain from deferred
> IO outweighs the shadow copy impact in the guest.
>
> Signed-off-by: Wei Hu 


Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
driver should be ready.  Both patches affect only the Hyper-V frame buffer
driver so can go through the Hyper-V tree.  Can you pick these up?  Thx.


I can't get this to apply anywhere, what tree is it based on?

--
Thanks,
Sasha

Re: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver

2019-10-01 Thread Sasha Levin


On Fri, Sep 13, 2019 at 06:02:55AM +, Wei Hu wrote:

Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports deferred IO for screens in
graphics mode and also enables the frame buffer on-demand refresh. The
highest refresh rate is still set at 20Hz.

Currently Hyper-V only takes a physical address from guest as the starting
address of frame buffer. This implies the guest must allocate contiguous
physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
accept address from MMIO region as frame buffer address. Due to these
limitations on Hyper-V host, we keep a shadow copy of frame buffer
in the guest. This means one more copy of the dirty rectangle inside
guest when doing the on-demand refresh. This can be optimized in the
future with help from host. For now the host performance gain from deferred
IO outweighs the shadow copy impact in the guest.

Signed-off-by: Wei Hu 


What tree is this based on? I can't get it to apply.

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

Re: [PATCH] video: hyperv_fb: Add the support of hibernation

2019-10-01 Thread Sasha Levin


On Wed, Sep 11, 2019 at 11:34:10PM +, Dexuan Cui wrote:

This patch depends on the vmbus side change of the definition of
struct hv_driver.

Signed-off-by: Dexuan Cui 


Queued up for hyperv-next, thanks!

--
Thanks,
Sasha

[PATCH] drm: lima: Add support for multiple reset lines

2019-10-01 Thread John Stultz

From: Peter Griffin 

Some SoCs like HiKey have 2 reset lines, so update
to use the devm_reset_control_array_* variant of the
API so that multiple resets can be specified in DT.

Cc: Qiang Yu 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Signed-off-by: Peter Griffin 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/lima/lima_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/lima/lima_device.c 
b/drivers/gpu/drm/lima/lima_device.c
index d86b8d81a483..e3e0ca11382e 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -105,7 +105,8 @@ static int lima_clk_init(struct lima_device *dev)
if (err)
goto error_out0;
 
-   dev->reset = devm_reset_control_get_optional(dev->dev, NULL);
+   dev->reset = devm_reset_control_array_get_optional_shared(dev->dev);
+
if (IS_ERR(dev->reset)) {
err = PTR_ERR(dev->reset);
if (err != -EPROBE_DEFER)
-- 
2.17.1

[PATCH] drm/amdgpu: fix structurally dead code vcn_v2_5_hw_init

2019-10-01 Thread Gustavo A. R. Silva

Notice that there is a *continue* statement in the middle of the
for loop and that prevents the code below from ever being reached:

r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
goto done;
}

Fix this by removing the continue statement and updating ring->sched.ready
to true before calling amdgpu_ring_test_ring(ring).

Notice that this fix is based on
commit 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)")

Addresses-Coverity-ID 1485608 ("Structurally dead code")
Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports")
Signed-off-by: Gustavo A. R. Silva 
---

Any feedback is greatly appreciated.

 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index 395c2259f979..47b0dcd59e13 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
@@ -258,6 +258,7 @@ static int vcn_v2_5_hw_init(void *handle)
adev->nbio_funcs->vcn_doorbell_range(adev, ring->use_doorbell,
 ring->doorbell_index, j);
 
+   ring->sched.ready = true;
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
@@ -266,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
 
for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
ring = &adev->vcn.inst[j].ring_enc[i];
-   ring->sched.ready = false;
-   continue;
+   ring->sched.ready = true;
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
@@ -276,6 +276,7 @@ static int vcn_v2_5_hw_init(void *handle)
}
 
ring = &adev->vcn.inst[j].ring_jpeg;
+   ring->sched.ready = true;
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
-- 
2.23.0

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

[PATCH AUTOSEL 4.4 06/15] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a5c8240784726..e35e603710b4d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -406,6 +406,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 4.9 07/19] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 3938fca1ea8e5..24941a7b659f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -430,6 +430,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 4.14 10/29] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index e16229000a983..884ed359f2493 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -540,6 +540,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 4.19 41/43] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-10-01 Thread Sasha Levin

From: Hans de Goede 

[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Reviewed-by: Michel Dänzer 
Signed-off-by: Hans de Goede 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 31 +
 drivers/gpu/drm/radeon/radeon_kms.c | 25 ---
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 2a7977a23b31c..c26f09b47ecb2 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -340,8 +340,39 @@ static int radeon_kick_out_firmware_fb(struct pci_dev 
*pdev)
 static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
+   unsigned long flags = 0;
int ret;
 
+   if (!ent)
+   return -ENODEV; /* Avoid NULL-ptr deref in drm_get_pci_dev */
+
+   flags = ent->driver_data;
+
+   if (!radeon_si_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(&pdev->dev,
+"SI support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+   if (!radeon_cik_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(&pdev->dev,
+"CIK support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 6a8fb6fd183c3..3ff835767ac58 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -95,31 +95,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
struct radeon_device *rdev;
int r, acpi_status;
 
-   if (!radeon_si_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-   if (!radeon_cik_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-
rdev = kzalloc(sizeof(struct radeon_device), GFP_KERNEL);
if (rdev == NULL) {
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 4.19 14/43] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index c0396e83f3526..fc93b103f7778 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -562,6 +562,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 4.19 13/43] drm/amdgpu: Fix KFD-related kernel oops on Hawaii

2019-10-01 Thread Sasha Levin

From: Felix Kuehling 

[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]

Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.

Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Felix Kuehling 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 51b5e977ca885..f4e9d1b10e3ed 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -139,7 +139,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
/* ring tests don't use a job */
if (job) {
vm = job->vm;
-   fence_ctx = job->base.s_fence->scheduled.context;
+   fence_ctx = job->base.s_fence ?
+   job->base.s_fence->scheduled.context : 0;
} else {
vm = NULL;
fence_ctx = 0;
-- 
2.20.1

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

[PATCH AUTOSEL 5.2 60/63] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-10-01 Thread Sasha Levin

From: Hans de Goede 

[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Reviewed-by: Michel Dänzer 
Signed-off-by: Hans de Goede 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 31 +
 drivers/gpu/drm/radeon/radeon_kms.c | 25 ---
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 2e96c886392bd..5502e34288685 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -320,8 +320,39 @@ bool radeon_device_is_virtual(void);
 static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
+   unsigned long flags = 0;
int ret;
 
+   if (!ent)
+   return -ENODEV; /* Avoid NULL-ptr deref in drm_get_pci_dev */
+
+   flags = ent->driver_data;
+
+   if (!radeon_si_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(&pdev->dev,
+"SI support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+   if (!radeon_cik_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(&pdev->dev,
+"CIK support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 6a8fb6fd183c3..3ff835767ac58 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -95,31 +95,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
struct radeon_device *rdev;
int r, acpi_status;
 
-   if (!radeon_si_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-   if (!radeon_cik_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-
rdev = kzalloc(sizeof(struct radeon_device), GFP_KERNEL);
if (rdev == NULL) {
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 5.2 19/63] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index b17d0545728ee..a103998f72128 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -662,6 +662,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 5.2 18/63] drm/amdgpu: Fix KFD-related kernel oops on Hawaii

2019-10-01 Thread Sasha Levin

From: Felix Kuehling 

[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]

Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.

Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Felix Kuehling 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index fe393a46f8811..5eed2423dbb5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -141,7 +141,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
/* ring tests don't use a job */
if (job) {
vm = job->vm;
-   fence_ctx = job->base.s_fence->scheduled.context;
+   fence_ctx = job->base.s_fence ?
+   job->base.s_fence->scheduled.context : 0;
} else {
vm = NULL;
fence_ctx = 0;
-- 
2.20.1

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

[PATCH AUTOSEL 5.3 68/71] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-10-01 Thread Sasha Levin

From: Hans de Goede 

[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Reviewed-by: Michel Dänzer 
Signed-off-by: Hans de Goede 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 31 +
 drivers/gpu/drm/radeon/radeon_kms.c | 25 ---
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index a6cbe11f79c61..7033f3a38c878 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -325,8 +325,39 @@ bool radeon_device_is_virtual(void);
 static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
+   unsigned long flags = 0;
int ret;
 
+   if (!ent)
+   return -ENODEV; /* Avoid NULL-ptr deref in drm_get_pci_dev */
+
+   flags = ent->driver_data;
+
+   if (!radeon_si_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(&pdev->dev,
+"SI support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+   if (!radeon_cik_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(&pdev->dev,
+"CIK support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 07f7ace42c4ba..e85c554eeaa94 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -100,31 +100,6 @@ int radeon_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
struct radeon_device *rdev;
int r, acpi_status;
 
-   if (!radeon_si_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-   if (!radeon_cik_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-
rdev = kzalloc(sizeof(struct radeon_device), GFP_KERNEL);
if (rdev == NULL) {
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 5.3 20/71] drm/amdgpu: Check for valid number of registers to read

2019-10-01 Thread Sasha Levin

From: Trek 

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 0cf7e8606fd3d..00beba533582c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -662,6 +662,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK)
sh_num = 0x;
 
+   if (info->read_mmr_reg.count > 128)
+   return -EINVAL;
+
regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), 
GFP_KERNEL);
if (!regs)
return -ENOMEM;
-- 
2.20.1

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

[PATCH AUTOSEL 5.3 19/71] drm/amdgpu: Fix KFD-related kernel oops on Hawaii

2019-10-01 Thread Sasha Levin

From: Felix Kuehling 

[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]

Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.

Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Felix Kuehling 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 7850084a05e3a..60655834d6498 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -143,7 +143,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
/* ring tests don't use a job */
if (job) {
vm = job->vm;
-   fence_ctx = job->base.s_fence->scheduled.context;
+   fence_ctx = job->base.s_fence ?
+   job->base.s_fence->scheduled.context : 0;
} else {
vm = NULL;
fence_ctx = 0;
-- 
2.20.1

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

Re: New sysfs interface for privacy screens

2019-10-01 Thread Greg KH

On Tue, Oct 01, 2019 at 10:09:46AM -0600, Mat King wrote:
> Resending in plain text mode
> 
> I have been looking into adding Linux support for electronic privacy
> screens which is a feature on some new laptops which is built into the
> display and allows users to turn it on instead of needing to use a
> physical privacy filter. In discussions with my colleagues the idea of
> using either /sys/class/backlight or /sys/class/leds but this new
> feature does not seem to quite fit into either of those classes.
> 
> I am proposing adding a class called "privacy_screen" to interface
> with these devices. The initial API would be simple just a single
> property called "privacy_state" which when set to 1 would mean that
> privacy is enabled and 0 when privacy is disabled.
> 
> Current known use cases will use ACPI _DSM in order to interface with
> the privacy screens, but this class would allow device driver authors
> to use other interfaces as well.
> 
> Example:
> 
> # get privacy screen state
> cat /sys/class/privacy_screen/cros_privacy/privacy_state # 1: privacy
> enabled 0: privacy disabled
> 
> # set privacy enabled
> echo 1 > /sys/class/privacy_screen/cros_privacy/privacy_state

What is "cros_privacy" here?

>  Does this approach seem to be reasonable?

Seems sane to me, do you have any code that implements this so we can
see it?

thanks,

greg k-h

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

2019-10-01 Thread Karol Herbst

On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas  wrote:
>
> On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> >  wrote:
> > >
> > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > > > still happens with your patch applied. The machine simply gets shut 
> > > > down.
> > > >
> > > > dmesg can be found here:
> > > > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt
> > >
> > > Looking your dmesg:
> > >
> > > Sep 30 17:24:27 kernel: nouveau :01:00.0: DRM: DCB version 4.1
> > > Sep 30 17:24:27 kernel: nouveau :01:00.0: DRM: MM: using COPY for 
> > > buffer copies
> > > Sep 30 17:24:27 kernel: [drm] Initialized nouveau 1.3.1 20120801 for 
> > > :01:00.0 on minor 1
> > >
> > > I would assume it runtime suspends here. Then it wakes up because of PCI
> > > access from userspace:
> > >
> > > Sep 30 17:24:42 kernel: pci_raw_set_power_state: 56 callbacks suppressed
> > >
> > > and for some reason it does not get resumed properly. There are also few
> > > warnings from ACPI that might be relevant:
> > >
> > > Sep 30 17:24:27 kernel: ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 
> > > type mismatch - Found [Buffer], ACPI requires [Package] 
> > > (20190509/nsarguments-59)
> > > Sep 30 17:24:27 kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument 
> > > #4 type mismatch - Found [Buffer], ACPI requires [Package] 
> > > (20190509/nsarguments-59)
> >
> > afaik this is the case for essentially every laptop out there.
>
> I think we should look into this a little bit.
> acpi_ns_check_argument_types() checks the argument type and prints
> this message, but AFAICT it doesn't actually fix anything or prevent
> execution of the method, so I have no idea what happens when we
> actually execute the _DSM.
>

I can assure you that this warning happens on every single laptop out
there with dual Nvidia graphics and it's essentially just a firmware
bug. And it never caused any issues on any of the older laptops (or
newest one for that matter).

> If we execute this _DSM as part of power management, and the _DSM
> doesn't work right, it would be no surprise that we have problems.
>
> Maybe we could learn something by turning on ACPI_DB_PARSE output (see
> Documentation/firmware-guide/acpi/debug.rst).
>
> You must have an acpidump already from all your investigation.  Can
> you put it somewhere, e.g., bugzilla.kernel.org, and include a URL?

Will do so later, right now I am traveling to XDC and will have more
time for that then.

[PATCH 12/14] drm/amd/display: MST DSC compute fair share

2019-10-01 Thread mikita.lipski

From: David Francis 

If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network

Implement an algorithm to determine the correct DSC config
for each stream

The algorithm:
This
 [   ]  ( )
represents the range of bandwidths possible for a given stream.
The [] area represents the range of DSC configs, and the ()
represents no DSC. The bandwidth used increases from left to right.

First, try disabling DSC on all streams
 [  ]  (|)
 [ ](|)
Check this against the bandwidth limits of the link and each branch
(including each endpoint). If it passes, the job is done

Second, try maximum DSC compression on all streams
that support DSC
 [| ]( )
 [|] ( )
If this does not pass, then enabling this combination of streams
is impossible

Otherwise, divide the remaining bandwidth evenly amongst the streams
 [|  ] ( )
 [|  ]( )

If one or more of the streams reach minimum compression, evenly
divide the reamining bandwidth amongst the remaining streams
 [|] ( )
 [   |]   ( )
 [ |   ]   ( )
 [ |  ]  ( )

If all streams can reach minimum compression, disable compression
greedily
 [  |]  ( )
 [|]( )
 [ ](|)

Perform this algorithm on each full update, on each MST link
with at least one DSC stream on it

After the configs are computed, call
dcn20_add_dsc_to_stream_resource on each stream with DSC enabled.
It is only after all streams are created that we can know which
of them will need DSC.

Do all of this at the end of amdgpu atomic check.  If it fails,
fail check; This combination of timings cannot be supported.

Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   4 +
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 386 ++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |   4 +
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |   7 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.h |   1 +
 5 files changed, 400 insertions(+), 2 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 59114b52090d..81e30918f9ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7702,6 +7702,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (!compute_mst_dsc_configs_for_state(dm_state->context))
+   goto fail;
+#endif
if (dc_validate_global_state(dc, dm_state->context, false) != 
DC_OK) {
ret = -EINVAL;
goto fail;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 270d972c9c3c..6b9696889668 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -38,6 +38,8 @@
 
 #include "i2caux_interface.h"
 
+#include "dc/dcn20/dcn20_resource.h"
+
 /* #define TRACE_DPCD */
 
 #ifdef TRACE_DPCD
@@ -490,3 +492,387 @@ void amdgpu_dm_initialize_dp_connector(struct 
amdgpu_display_manager *dm,
aconnector->connector_id);
 }
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+struct dsc_mst_fairness_params {
+   struct dc_crtc_timing *timing;
+   struct dc_sink *sink;
+   struct dc_dsc_bw_range bw_range;
+   bool compression_possible;
+   struct drm_dp_mst_port *port;
+};
+
+struct dsc_mst_fairness_vars {
+   int pbn;
+   bool dsc_enabled;
+   int bpp_x16;
+};
+
+static bool port_downstream_of_branch(struct drm_dp_mst_port *port,
+   struct drm_dp_mst_branch *branch)
+{
+   while (port->parent) {
+   if (port->parent == branch)
+   return true;
+
+   if (port->parent->port_parent)
+   port = port->parent->port_parent;
+   else
+   break;
+   }
+   return false;
+}
+
+static bool check_pbn_limit_on_branch(struct drm_dp_mst_branch *branch,
+   struct dsc_mst_fairness_params *params,
+   struct dsc_mst_fairness_vars *vars, int count)
+{
+   struct drm_dp_mst_port *port;
+   int i;
+   int pbn_limit = 0;
+   int pbn_used = 0;
+
+   list_for_each_entry(port, &branch->ports, next) {
+   if (port->mstb)
+   if (!check_pbn_limit_on_branch(port->mstb, params, 
vars, count))
+   return false;
+
+   if (por

[PATCH 11/14] drm/amd/display: Write DSC enable to MST DPCD

2019-10-01 Thread mikita.lipski

From: David Francis 

Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.

Use the cached dsc_aux field.

Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index fc537ae25eeb..bd694499e3de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -37,6 +37,7 @@
 #include "dc.h"
 #include "amdgpu_dm.h"
 #include "amdgpu_dm_irq.h"
+#include "amdgpu_dm_mst_types.h"
 
 #include "dm_helpers.h"
 
@@ -518,8 +519,24 @@ bool dm_helpers_dp_write_dsc_enable(
 )
 {
uint8_t enable_dsc = enable ? 1 : 0;
+   struct amdgpu_dm_connector *aconnector;
+
+   if (!stream)
+   return false;
+
+   if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) {
+   aconnector = (struct amdgpu_dm_connector 
*)stream->dm_stream_context;
+
+   if (!aconnector->dsc_aux)
+   return false;
+
+   return (drm_dp_dpcd_write(aconnector->dsc_aux, DP_DSC_ENABLE, 
&enable_dsc, 1) >= 0);
+   }
+
+   if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
+   return dm_helpers_dp_write_dpcd(ctx, stream->link, 
DP_DSC_ENABLE, &enable_dsc, 1);
 
-   return dm_helpers_dp_write_dpcd(ctx, stream->sink->link, DP_DSC_ENABLE, 
&enable_dsc, 1);
+   return false;
 }
 #endif
 
-- 
2.17.1

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

[PATCH 06/14] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux

2019-10-01 Thread mikita.lipski

From: David Francis 

Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.

As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
is a DP feature new in DP v1.4, which exposes certain DPCD
registers on virtual ports.

v2: Remember to unlock mutex on all paths
v3: Refactor to match coding style and increase brevity

Reviewed-by: Lyude Paul 
Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 127 ++
 include/drm/drm_dp_mst_helper.h   |   2 +
 2 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 502923c24450..d8f9ba27b559 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4150,3 +4150,130 @@ static void drm_dp_mst_unregister_i2c_bus(struct 
drm_dp_aux *aux)
 {
i2c_del_adapter(&aux->ddc);
 }
+
+/**
+ * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
+ * @port: The port to check
+ *
+ * A single physical MST hub object can be represented in the topology
+ * by multiple branches, with virtual ports between those branches.
+ *
+ * As of DP1.4, An MST hub with internal (virtual) ports must expose
+ * certain DPCD registers over those ports. See sections 2.6.1.1.1
+ * and 2.6.1.1.2 of Display Port specification v1.4 for details.
+ *
+ * May acquire mgr->lock
+ *
+ * Returns:
+ * true if the port is a virtual DP peer device, false otherwise
+ */
+static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
+{
+   struct drm_dp_mst_port *downstream_port;
+
+   if (!port || port->dpcd_rev < DP_DPCD_REV_14)
+   return false;
+
+   /* Virtual DP Sink (Internal Display Panel) */
+   if (port->port_num >= 8)
+   return true;
+
+   /* DP-to-HDMI Protocol Converter */
+   if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
+   !port->mcs &&
+   port->ldps)
+   return true;
+
+   /* DP-to-DP */
+   mutex_lock(&port->mgr->lock);
+   if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
+   port->mstb &&
+   port->mstb->num_ports == 2) {
+   list_for_each_entry(downstream_port, &port->mstb->ports, next) {
+   if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
+   !downstream_port->input) {
+   mutex_unlock(&port->mgr->lock);
+   return true;
+   }
+   }
+   }
+   mutex_unlock(&port->mgr->lock);
+
+   return false;
+}
+
+/**
+ * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
+ * @port: The port to check. A leaf of the MST tree with an attached display.
+ *
+ * Depending on the situation, DSC may be enabled via the endpoint aux,
+ * the immediately upstream aux, or the connector's physical aux.
+ *
+ * This is both the correct aux to read DSC_CAPABILITY and the
+ * correct aux to write DSC_ENABLED.
+ *
+ * This operation can be expensive (up to four aux reads), so
+ * the caller should cache the return.
+ *
+ * Returns:
+ * NULL if DSC cannot be enabled on this port, otherwise the aux device
+ */
+struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
+{
+   struct drm_dp_mst_port *immediate_upstream_port;
+   struct drm_dp_mst_port *fec_port;
+
+   if (!port)
+   return NULL;
+
+   if (port->parent)
+   immediate_upstream_port = port->parent->port_parent;
+   else
+   immediate_upstream_port = NULL;
+
+   fec_port = immediate_upstream_port;
+   while (fec_port) {
+   /*
+* Each physical link (i.e. not a virtual port) between the
+* output and the primary device must support FEC
+*/
+   if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
+   !fec_port->fec_capable)
+   return NULL;
+
+   fec_port = fec_port->parent->port_parent;
+   }
+
+   /* DP-to-DP peer device */
+   if (drm_dp_mst_is_virtual_dpcd(immediate_upstream_port)) {
+   u8 upstream_dsc;
+   u8 endpoint_dsc;
+   u8 endpoint_fec;
+
+   if (drm_dp_dpcd_read(&port->aux,
+DP_DSC_SUPPORT, &endpoint_dsc, 1) < 0)
+   return NULL;
+   if (drm_dp_dpcd_read(&port->aux,
+DP_FEC_CAPABILITY, &endpoint_fec, 1) < 0)
+   return NULL;
+   if (drm_dp_dpcd_read(&immediate_upstream_port->aux,
+DP_DSC_SUPPORT, &upstream_dsc, 1) < 0)
+   return NULL;
+
+

[PATCH 13/14] drm/amd/display: Recalculate VCPI slots for new DSC connectors

2019-10-01 Thread mikita.lipski

From: Mikita Lipski 

Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.

This patch proposes to use similair logic as in
dm_encoder_helper_atomic_chek, but since we do not know which
connectors will have DSC enabled we have to recalculate PBN only
after that's determined, which is done in
compute_mst_dsc_configs_for_state.

Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc: Lyude Paul 
Signed-off-by: Mikita Lipski 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 64 +--
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  6 --
 2 files changed, 59 insertions(+), 11 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 81e30918f9ec..7501ce2233ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4569,6 +4569,27 @@ static void dm_encoder_helper_disable(struct drm_encoder 
*encoder)
 
 }
 
+static int convert_dc_color_depth_into_bpc (enum dc_color_depth 
display_color_depth)
+{
+   switch (display_color_depth) {
+   case COLOR_DEPTH_666:
+   return 6;
+   case COLOR_DEPTH_888:
+   return 8;
+   case COLOR_DEPTH_101010:
+   return 10;
+   case COLOR_DEPTH_121212:
+   return 12;
+   case COLOR_DEPTH_141414:
+   return 14;
+   case COLOR_DEPTH_161616:
+   return 16;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -4616,6 +4637,36 @@ const struct drm_encoder_helper_funcs 
amdgpu_dm_encoder_helper_funcs = {
.atomic_check = dm_encoder_helper_atomic_check
 };
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
+   struct dc_state *dc_state)
+{
+   struct dc_stream_state *stream;
+   struct amdgpu_dm_connector *aconnector;
+   int i, clock = 0, bpp = 0;
+
+   for (i = 0; i < dc_state->stream_count; i++) {
+   stream = dc_state->streams[i];
+   aconnector = (struct amdgpu_dm_connector 
*)stream->dm_stream_context;
+
+   if (stream && stream->timing.flags.DSC == 1) {
+   bpp = 
convert_dc_color_depth_into_bpc(stream->timing.display_color_depth)* 3;
+   clock = stream->timing.pix_clk_100hz / 10;
+
+   aconnector->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
true);
+
+   aconnector->vcpi_slots = 
drm_dp_atomic_find_vcpi_slots(state,
+ 
&aconnector->mst_port->mst_mgr,
+ aconnector->port,
+ aconnector->pbn);
+   if (aconnector->vcpi_slots < 0)
+   return aconnector->vcpi_slots;
+   }
+   }
+   return 0;
+}
+#endif
+
 static void dm_drm_plane_reset(struct drm_plane *plane)
 {
struct dm_plane_state *amdgpu_state = NULL;
@@ -7629,11 +7680,6 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
-   /* Perform validation of MST topology in the state*/
-   ret = drm_dp_mst_atomic_check(state);
-   if (ret)
-   goto fail;
-
if (state->legacy_cursor_update) {
/*
 * This is a fast cursor update coming from the plane update
@@ -7705,6 +7751,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
if (!compute_mst_dsc_configs_for_state(dm_state->context))
goto fail;
+
+   ret = dm_update_mst_vcpi_slots_for_dsc(state, 
dm_state->context);
+   if (ret)
+   goto fail;
 #endif
if (dc_validate_global_state(dc, dm_state->context, false) != 
DC_OK) {
ret = -EINVAL;
@@ -7734,6 +7784,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dc_retain_state(old_dm_state->context);
}
}
+   /* Perform validation of MST topology in the state*/
+   ret = drm_dp_mst_atomic_check(state);
+   if (ret)
+   goto fail;
 
/* Store the overall update type for use later in atomic check. */
for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
diff --git a/drivers/gpu/drm/

[PATCH 14/14] drm/amd/display: Trigger modesets on MST DSC connectors

2019-10-01 Thread mikita.lipski

From: David Francis 

Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not change timing.

Therefore, whenever a crtc has drm_atomic_crtc_needs_modeset,
for each crtc that shares a MST topology with that stream and
supports DSC, add that crtc (and all affected connectors and
planes) to the atomic state and set mode_changed on its state

v2: Do this check only on Navi and before adding connectors
and planes on modesetting crtcs

Cc: Leo Li 
Cc: Nicholas Kazlauskas 
Cc: Lyude Paul 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 +++
 1 file changed, 79 insertions(+)

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 7501ce2233ed..371086a67c68 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6888,6 +6888,74 @@ static int do_aquire_global_lock(struct drm_device *dev,
return ret < 0 ? ret : 0;
 }
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+/*
+ * TODO: This logic should at some point be moved into DRM
+ */
+static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state, struct 
drm_crtc *crtc)
+{
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_connector_list_iter conn_iter;
+   struct drm_crtc_state *new_crtc_state;
+   struct amdgpu_dm_connector *aconnector = NULL, *aconnector_to_add;
+   int i, j;
+   struct drm_crtc *crtcs_affected[AMDGPU_MAX_CRTCS] = { 0 };
+
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
+   if (conn_state->crtc != crtc)
+   continue;
+
+   aconnector = to_amdgpu_dm_connector(connector);
+   if (!aconnector->port)
+   aconnector = NULL;
+   else
+   break;
+   }
+
+   if (!aconnector)
+   return 0;
+
+   i = 0;
+   drm_connector_list_iter_begin(state->dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   if (!connector->state || !connector->state->crtc)
+   continue;
+
+   aconnector_to_add = to_amdgpu_dm_connector(connector);
+   if (!aconnector_to_add->port)
+   continue;
+
+   if (aconnector_to_add->port->mgr != aconnector->port->mgr)
+   continue;
+
+   if (!aconnector_to_add->dc_sink)
+   continue;
+
+   if 
(!aconnector_to_add->dc_sink->sink_dsc_caps.dsc_dec_caps.is_dsc_supported)
+   continue;
+
+   if (i >= AMDGPU_MAX_CRTCS)
+   continue;
+
+   crtcs_affected[i] = connector->state->crtc;
+   i++;
+   }
+   drm_connector_list_iter_end(&conn_iter);
+
+   for (j = 0; j < i; j++) {
+   new_crtc_state = drm_atomic_get_crtc_state(state, 
crtcs_affected[j]);
+   if (IS_ERR(new_crtc_state))
+   return PTR_ERR(new_crtc_state);
+
+   new_crtc_state->mode_changed = true;
+   }
+
+   return 0;
+
+}
+#endif
+
 static void get_freesync_config_for_crtc(
struct dm_crtc_state *new_crtc_state,
struct dm_connector_state *new_con_state)
@@ -7577,6 +7645,17 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (adev->asic_type >= CHIP_NAVI10) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
+   ret = add_affected_mst_dsc_crtcs(state, crtc);
+   if (ret)
+   goto fail;
+   }
+   }
+   }
+#endif
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
if (!drm_atomic_crtc_needs_modeset(new_crtc_state) &&
!new_crtc_state->color_mgmt_changed &&
-- 
2.17.1

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

[PATCH 02/14] drm/dp_mst: Add PBN calculation for DSC modes

2019-10-01 Thread mikita.lipski

From: David Francis 

With DSC, bpp can be fractional in multiples of 1/16.

Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel

v2: Don't add separate function for this

Reviewed-by: Manasi Navare 
Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c| 16 
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  3 ++-
 drivers/gpu/drm/nouveau/dispnv50/disp.c  |  3 ++-
 drivers/gpu/drm/radeon/radeon_dp_mst.c   |  2 +-
 include/drm/drm_dp_mst_helper.h  |  3 +--
 6 files changed, 19 insertions(+), 10 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 3fc1afccbb33..59114b52090d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4597,7 +4597,7 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
if(!state->duplicated) {
bpp = (uint8_t)connector->display_info.bpc * 3;
clock = adjusted_mode->clock;
-   aconnector->pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   aconnector->pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
}
aconnector->vcpi_slots = drm_dp_atomic_find_vcpi_slots(state,
   mst_mgr,
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 82add736e17d..3e7b7553cf4d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3534,10 +3534,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
  * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
  * @clock: dot clock for the mode
  * @bpp: bpp for the mode.
+ * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
  *
  * This uses the formula in the spec to calculate the PBN value for a mode.
  */
-int drm_dp_calc_pbn_mode(int clock, int bpp)
+int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
 {
u64 kbps;
s64 peak_kbps;
@@ -3555,11 +3556,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
 * peak_kbps *= (1006/1000)
 * peak_kbps *= (64/54)
 * peak_kbps *= 8convert to bytes
+*
+* If the bpp is in units of 1/16, further divide by 16. Put this
+* factor in the numerator rather than the denominator to avoid
+* integer overflow
 */
 
numerator = 64 * 1006;
denominator = 54 * 8 * 1000 * 1000;
 
+   if (dsc)
+   numerator /= 16;
+
kbps *= numerator;
peak_kbps = drm_fixp_from_fraction(kbps, denominator);
 
@@ -3570,19 +3578,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
 static int test_calc_pbn_mode(void)
 {
int ret;
-   ret = drm_dp_calc_pbn_mode(154000, 30);
+   ret = drm_dp_calc_pbn_mode(154000, 30, false);
if (ret != 689) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
expected PBN %d, actual PBN %d.\n",
154000, 30, 689, ret);
return -EINVAL;
}
-   ret = drm_dp_calc_pbn_mode(234000, 30);
+   ret = drm_dp_calc_pbn_mode(234000, 30, false);
if (ret != 1047) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
expected PBN %d, actual PBN %d.\n",
234000, 30, 1047, ret);
return -EINVAL;
}
-   ret = drm_dp_calc_pbn_mode(297000, 24);
+   ret = drm_dp_calc_pbn_mode(297000, 24, false);
if (ret != 1063) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
expected PBN %d, actual PBN %d.\n",
297000, 24, 1063, ret);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2c5ac3dd647f..dfac450841df 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -61,7 +61,8 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
crtc_state->pipe_bpp = bpp;
 
crtc_state->pbn = 
drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
-  crtc_state->pipe_bpp);
+  crtc_state->pipe_bpp,
+  false);
 
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
  port, crtc_state->pbn);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c

[PATCH 08/14] drm/amd/display: Use correct helpers to compute timeslots

2019-10-01 Thread mikita.lipski

From: David Francis 

We were using drm helpers to convert a timing into its
bandwidth, its bandwidth into pbn, and its pbn into timeslots

These helpers
-Did not take DSC timings into account
-Used the link rate and lane count of the link's aux device,
which are not the same as the link's current cap
-Did not take FEC into account (FEC reduces the PBN per timeslot)

For converting timing into PBN, use the new function
drm_dp_calc_pbn_mode_dsc that handles the DSC case

For converting PBN into time slots, amdgpu doesn't use the
'correct' atomic method (drm_dp_atomic_find_vcpi_slots), so
don't add a new helper to cover our approach. Use the same
means of calculating pbn per time slot as the DSC code.

Cc: Jerry Zuo 
Cc: Nicholas Kazlauskas 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 5256abe32e92..fc537ae25eeb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -185,6 +185,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
bool ret;
+   int pbn_per_timeslot = 0;
 
aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
 
@@ -200,6 +201,11 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
 
if (enable) {
 
+   /* Convert kilobits per second / 64 (for 64 timeslots) to pbn 
(54/64 megabytes per second) */
+   pbn_per_timeslot = dc_link_bandwidth_kbps(
+   stream->link, 
dc_link_get_link_cap(stream->link)) / (8 * 1000 * 54);
+   aconnector->vcpi_slots = DIV_ROUND_UP(aconnector->pbn, 
pbn_per_timeslot);
+
ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port,
   aconnector->pbn,
   aconnector->vcpi_slots);
-- 
2.17.1

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

[PATCH 09/14] drm/amd/display: Initialize DSC PPS variables to 0

2019-10-01 Thread mikita.lipski

From: David Francis 

For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.

memset to 0 to avoid this

Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 3 +++
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index a519dbc5ecb6..5d6cbaebebc0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -496,6 +496,9 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool 
enable)
struct dsc_config dsc_cfg;
uint8_t dsc_packed_pps[128];
 
+   memset(&dsc_cfg, 0, sizeof(dsc_cfg));
+   memset(dsc_packed_pps, 0, 128);
+
/* Enable DSC hw block */
dsc_cfg.pic_width = stream->timing.h_addressable + 
stream->timing.h_border_left + stream->timing.h_border_right;
dsc_cfg.pic_height = stream->timing.v_addressable + 
stream->timing.v_border_top + stream->timing.v_border_bottom;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 63eb377ed9c0..296eeff00296 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -207,6 +207,9 @@ static bool dsc2_get_packed_pps(struct 
display_stream_compressor *dsc, const str
struct dsc_reg_values dsc_reg_vals;
struct dsc_optc_config dsc_optc_cfg;
 
+   memset(&dsc_reg_vals, 0, sizeof(dsc_reg_vals));
+   memset(&dsc_optc_cfg, 0, sizeof(dsc_optc_cfg));
+
DC_LOG_DSC("Getting packed DSC PPS for DSC Config:");
dsc_config_log(dsc, dsc_cfg);
DC_LOG_DSC("DSC Picture Parameter Set (PPS):");
-- 
2.17.1

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

[PATCH v2 00/14] DSC MST support for AMDGPU

2019-10-01 Thread mikita.lipski

From: Mikita Lipski 

This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic check routines.

First 12 patches have been introduced in multiple
iterations to the mailing list before. These patches were
developed by David Francis as part of his work on DSC.

Other 2 patches add atomic check functionality to
encoder and connector to allocate and release VCPI
slots on each state atomic check. These changes
utilize newly added drm_mst_helper functions for
better tracking of VCPI slots.

v2: squashed previously 3 separate atomic check patches,
separate atomic check for dsc connectors, track vcpi and
pbn on connectors.

David Francis (12):
  drm/dp_mst: Add PBN calculation for DSC modes
  drm/dp_mst: Parse FEC capability on MST ports
  drm/dp_mst: Add MST support to DP DPCD R/W functions
  drm/dp_mst: Fill branch->num_ports
  drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
  drm/dp_mst: Add new quirk for Synaptics MST hubs
  drm/amd/display: Use correct helpers to compute timeslots
  drm/amd/display: Initialize DSC PPS variables to 0
  drm/amd/display: Validate DSC caps on MST endpoints
  drm/amd/display: Write DSC enable to MST DPCD
  drm/amd/display: MST DSC compute fair share
  drm/amd/display: Trigger modesets on MST DSC connectors

Mikita Lipski (2):
  drm/amd/display: Add MST atomic routines
  drm/amd/display: Recalculate VCPI slots for new DSC connectors

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 179 +++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  63 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 449 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |   4 +
 .../drm/amd/display/dc/core/dc_link_hwss.c|   3 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c  |   3 +
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |   7 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.h |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c  |  12 +-
 drivers/gpu/drm/drm_dp_helper.c   |  33 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 174 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |   3 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c|   2 +-
 include/drm/drm_dp_helper.h   |   7 +
 include/drm/drm_dp_mst_helper.h   |   8 +-
 17 files changed, 885 insertions(+), 73 deletions(-)

-- 
2.17.1

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

[PATCH 10/14] drm/amd/display: Validate DSC caps on MST endpoints

2019-10-01 Thread mikita.lipski

From: David Francis 

During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.

Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.

Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  3 ++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 31 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 3ce104324096..8bae6f264ef1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -279,6 +279,9 @@ struct amdgpu_dm_connector {
struct drm_dp_mst_port *port;
struct amdgpu_dm_connector *mst_port;
struct amdgpu_encoder *mst_encoder;
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   struct drm_dp_aux *dsc_aux;
+#endif
 
/* MST specific */
uint32_t vcpi_slots;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 7f3ce29bd14c..270d972c9c3c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 #include "dm_services.h"
 #include "amdgpu.h"
 #include "amdgpu_dm.h"
@@ -187,6 +188,28 @@ static const struct drm_connector_funcs 
dm_dp_mst_connector_funcs = {
.early_unregister = amdgpu_dm_mst_connector_early_unregister,
 };
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+static bool validate_dsc_caps_on_connector(struct amdgpu_dm_connector 
*aconnector)
+{
+   struct dc_sink *dc_sink = aconnector->dc_sink;
+   struct drm_dp_mst_port *port = aconnector->port;
+   u8 dsc_caps[16] = { 0 };
+
+   aconnector->dsc_aux = drm_dp_mst_dsc_aux_for_port(port);
+
+   if (!aconnector->dsc_aux)
+   return false;
+
+   if (drm_dp_dpcd_read(aconnector->dsc_aux, DP_DSC_SUPPORT, dsc_caps, 16) 
< 0)
+   return false;
+
+   if (!dc_dsc_parse_dsc_dpcd(dsc_caps, NULL, 
&dc_sink->sink_dsc_caps.dsc_dec_caps))
+   return false;
+
+   return true;
+}
+#endif
+
 static int dm_dp_mst_get_modes(struct drm_connector *connector)
 {
struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
@@ -229,10 +252,16 @@ static int dm_dp_mst_get_modes(struct drm_connector 
*connector)
/* dc_link_add_remote_sink returns a new reference */
aconnector->dc_sink = dc_sink;
 
-   if (aconnector->dc_sink)
+   if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(
connector, aconnector->edid);
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (!validate_dsc_caps_on_connector(aconnector))
+   memset(&aconnector->dc_sink->sink_dsc_caps,
+  0, 
sizeof(aconnector->dc_sink->sink_dsc_caps));
+#endif
+   }
}
 
drm_connector_update_edid_property(
-- 
2.17.1

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

[PATCH 03/14] drm/dp_mst: Parse FEC capability on MST ports

2019-10-01 Thread mikita.lipski

From: David Francis 

As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.

The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)

That value is needed for FEC and DSC support

Store it on drm_dp_mst_port

Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 include/drm/drm_dp_mst_helper.h   | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3e7b7553cf4d..9f3604355705 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -553,6 +553,7 @@ static bool 
drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
 {
int idx = 1;
repmsg->u.path_resources.port_number = (raw->msg[idx] >> 4) & 0xf;
+   repmsg->u.path_resources.fec_capable = raw->msg[idx] & 0x1;
idx++;
if (idx > raw->curlen)
goto fail_len;
@@ -2183,6 +2184,7 @@ static int drm_dp_send_enum_path_resources(struct 
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("enum path resources %d: %d %d\n", 
txmsg->reply.u.path_resources.port_number, 
txmsg->reply.u.path_resources.full_payload_bw_number,
   
txmsg->reply.u.path_resources.avail_payload_bw_number);
port->available_pbn = 
txmsg->reply.u.path_resources.avail_payload_bw_number;
+   port->fec_capable = 
txmsg->reply.u.path_resources.fec_capable;
}
}
 
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 9116b2c95239..f113ae04fa88 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -108,6 +108,8 @@ struct drm_dp_mst_port {
 * audio-capable.
 */
bool has_audio;
+
+   bool fec_capable;
 };
 
 /**
@@ -312,6 +314,7 @@ struct drm_dp_port_number_req {
 
 struct drm_dp_enum_path_resources_ack_reply {
u8 port_number;
+   bool fec_capable;
u16 full_payload_bw_number;
u16 avail_payload_bw_number;
 };
-- 
2.17.1

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

[PATCH 01/14] drm/amd/display: Add MST atomic routines

2019-10-01 Thread mikita.lipski

From: Mikita Lipski 

- Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate  PBN and VCPI slots only once during atomic
check and store them on amdgpu connector to eliminate
redundant calculation
- Call drm_dp_mst_atomic_check to verify validity of MST topology
during state atomic check

v2: squashed previous 3 separate patches, removed DSC PBN calculation,
and added PBN and VCPI slots properties to amdgpu connector

Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
Cc: Lyude Paul 
Signed-off-by: Mikita Lipski 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 +++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  4 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 42 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 32 ++
 4 files changed, 81 insertions(+), 39 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 239b1ae86007..3fc1afccbb33 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4573,6 +4573,41 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
 {
+   struct drm_atomic_state *state = crtc_state->state;
+   struct drm_connector *connector = conn_state->connector;
+   struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
+   struct dm_crtc_state *dm_new_crtc_state = to_dm_crtc_state(crtc_state);
+   const struct drm_display_mode *adjusted_mode = 
&crtc_state->adjusted_mode;
+   struct drm_dp_mst_topology_mgr *mst_mgr;
+   struct drm_dp_mst_port *mst_port;
+   int clock, bpp = 0;
+
+   if (!dm_new_crtc_state)
+   return 0;
+
+   if (!aconnector->port || !aconnector->dc_sink)
+   return 0;
+
+   mst_port = aconnector->port;
+   mst_mgr = &aconnector->mst_port->mst_mgr;
+
+   if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
+   return 0;
+
+   if(!state->duplicated) {
+   bpp = (uint8_t)connector->display_info.bpc * 3;
+   clock = adjusted_mode->clock;
+   aconnector->pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   }
+   aconnector->vcpi_slots = drm_dp_atomic_find_vcpi_slots(state,
+  mst_mgr,
+  mst_port,
+  aconnector->pbn);
+
+   if (aconnector->vcpi_slots < 0) {
+   DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", 
aconnector->vcpi_slots);
+   return aconnector->vcpi_slots;
+   }
return 0;
 }
 
@@ -5197,6 +5232,8 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.dpms = DRM_MODE_DPMS_OFF;
aconnector->hpd.hpd = AMDGPU_HPD_NONE; /* not used */
aconnector->audio_inst = -1;
+   aconnector->vcpi_slots = 0;
+   aconnector->pbn = 0;
mutex_init(&aconnector->hpd_lock);
 
/*
@@ -7592,6 +7629,11 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+   /* Perform validation of MST topology in the state*/
+   ret = drm_dp_mst_atomic_check(state);
+   if (ret)
+   goto fail;
+
if (state->legacy_cursor_update) {
/*
 * This is a fast cursor update coming from the plane update
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index c6fdebee7189..3ce104324096 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -280,6 +280,10 @@ struct amdgpu_dm_connector {
struct amdgpu_dm_connector *mst_port;
struct amdgpu_encoder *mst_encoder;
 
+   /* MST specific */
+   uint32_t vcpi_slots;
+   uint32_t pbn;
+
/* TODO see if we can merge with ddc_bus or make a dm_connector */
struct amdgpu_i2c_adapter *i2c;
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 11e5784aa62a..5256abe32e92 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -184,11 +184,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
-

[PATCH 05/14] drm/dp_mst: Fill branch->num_ports

2019-10-01 Thread mikita.lipski

From: David Francis 

This field on drm_dp_mst_branch was never filled

It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.

v2: remember to decrement on port removal
v3: don't explicitly init to 0

Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9f3604355705..502923c24450 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1669,6 +1669,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
mutex_lock(&mstb->mgr->lock);
drm_dp_mst_topology_get_port(port);
list_add(&port->next, &mstb->ports);
+   mstb->num_ports++;
mutex_unlock(&mstb->mgr->lock);
}
 
@@ -1703,6 +1704,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
/* remove it from the port list */
mutex_lock(&mstb->mgr->lock);
list_del(&port->next);
+   mstb->num_ports--;
mutex_unlock(&mstb->mgr->lock);
/* drop port list reference */
drm_dp_mst_topology_put_port(port);
-- 
2.17.1

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

[PATCH 07/14] drm/dp_mst: Add new quirk for Synaptics MST hubs

2019-10-01 Thread mikita.lipski

From: Mikita Lipski 

Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs.  Add a new quirk to detect this case.

Reviewed-by: Wenjing Liu 
Reviewed-by: Lyude Paul 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_helper.c   |  2 ++
 drivers/gpu/drm/drm_dp_mst_topology.c | 27 +++
 include/drm/drm_dp_helper.h   |  7 +++
 3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index af1cd968adfd..02fa8c3d9a82 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1271,6 +1271,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
BIT(DP_DPCD_QUIRK_NO_PSR) },
/* CH7511 seems to leave SINK_COUNT zeroed */
{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'), 
false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
+   /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
+   { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true, 
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
 };
 
 #undef OUI
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d8f9ba27b559..d5df02315e14 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4222,6 +4222,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct 
drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
+   struct drm_dp_desc desc = { 0 };
 
if (!port)
return NULL;
@@ -4274,6 +4275,32 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct 
drm_dp_mst_port *port)
if (drm_dp_mst_is_virtual_dpcd(port))
return &port->aux;
 
+   /*
+* Synaptics quirk
+* Applies to ports for which:
+* - Physical aux has Synaptics OUI
+* - DPv1.4 or higher
+* - Port is on primary branch device
+* - Not a VGA adapter (DP_DWN_STRM_PORT_TYPE_ANALOG)
+*/
+   if (!drm_dp_read_desc(port->mgr->aux, &desc, true))
+   return NULL;
+
+   if (drm_dp_has_quirk(&desc, DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
+   port->mgr->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 &&
+   port->parent == port->mgr->mst_primary) {
+   u8 downstreamport;
+
+   if (drm_dp_dpcd_read(&port->aux, DP_DOWNSTREAMPORT_PRESENT,
+&downstreamport, 1) < 0)
+   return NULL;
+
+   if ((downstreamport & DP_DWN_STRM_PORT_PRESENT) &&
+  ((downstreamport & DP_DWN_STRM_PORT_TYPE_MASK)
+!= DP_DWN_STRM_PORT_TYPE_ANALOG))
+   return port->mgr->aux;
+   }
+
return NULL;
 }
 EXPORT_SYMBOL(drm_dp_mst_dsc_aux_for_port);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8364502f92cf..a1331b08705f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1434,6 +1434,13 @@ enum drm_dp_quirk {
 * The driver should ignore SINK_COUNT during detection.
 */
DP_DPCD_QUIRK_NO_SINK_COUNT,
+   /**
+* @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
+*
+* The device supports MST DSC despite not supporting Virtual DPCD.
+* The DSC caps can be read from the physical aux instead.
+*/
+   DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
 };
 
 /**
-- 
2.17.1

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

[PATCH 04/14] drm/dp_mst: Add MST support to DP DPCD R/W functions

2019-10-01 Thread mikita.lipski

From: David Francis 

Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.

This means that DRM drivers can make MST DPCD read/writes.

v2: Fix spacing
v3: Dump dpcd access on MST read/writes

Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
 drivers/gpu/drm/drm_dp_helper.c  | 31 +--
 2 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 0cfb386754c3..418cad4f649a 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -163,11 +163,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
break;
}
 
-   if (aux_dev->aux->is_remote)
-   res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
-  todo);
-   else
-   res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+   res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
 
if (res <= 0)
break;
@@ -215,11 +211,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb, 
struct iov_iter *from)
break;
}
 
-   if (aux_dev->aux->is_remote)
-   res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
-   todo);
-   else
-   res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
+   res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf, todo);
 
if (res <= 0)
break;
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffc68d305afe..af1cd968adfd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "drm_crtc_helper_internal.h"
 
@@ -251,7 +253,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 
 /**
  * drm_dp_dpcd_read() - read a series of bytes from the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
  * @offset: address of the (first) register to read
  * @buffer: buffer to store the register values
  * @size: number of bytes in @buffer
@@ -280,13 +282,18 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned 
int offset,
 * We just have to do it before any DPCD access and hope that the
 * monitor doesn't power down exactly after the throw away read.
 */
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
-1);
-   if (ret != 1)
-   goto out;
+   if (!aux->is_remote) {
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV,
+buffer, 1);
+   if (ret != 1)
+   goto out;
+   }
 
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
-size);
+   if (aux->is_remote)
+   ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
+   else
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset,
+buffer, size);
 
 out:
drm_dp_dump_access(aux, DP_AUX_NATIVE_READ, offset, buffer, ret);
@@ -296,7 +303,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
 
 /**
  * drm_dp_dpcd_write() - write a series of bytes to the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
  * @offset: address of the (first) register to write
  * @buffer: buffer containing the values to write
  * @size: number of bytes in @buffer
@@ -313,8 +320,12 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned 
int offset,
 {
int ret;
 
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
-size);
+   if (aux->is_remote)
+   ret = drm_dp_mst_dpcd_write(aux, offset, buffer, size);
+   else
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset,
+buffer, size);
+
drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
return ret;
 }
-- 
2.17.1

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

New sysfs interface for privacy screens

2019-10-01 Thread Mat King

Resending in plain text mode

I have been looking into adding Linux support for electronic privacy
screens which is a feature on some new laptops which is built into the
display and allows users to turn it on instead of needing to use a
physical privacy filter. In discussions with my colleagues the idea of
using either /sys/class/backlight or /sys/class/leds but this new
feature does not seem to quite fit into either of those classes.

I am proposing adding a class called "privacy_screen" to interface
with these devices. The initial API would be simple just a single
property called "privacy_state" which when set to 1 would mean that
privacy is enabled and 0 when privacy is disabled.

Current known use cases will use ACPI _DSM in order to interface with
the privacy screens, but this class would allow device driver authors
to use other interfaces as well.

Example:

# get privacy screen state
cat /sys/class/privacy_screen/cros_privacy/privacy_state # 1: privacy
enabled 0: privacy disabled

# set privacy enabled
echo 1 > /sys/class/privacy_screen/cros_privacy/privacy_state

 Does this approach seem to be reasonable?

Re: [PATCH v3] drm/bridge: analogix-anx78xx: add support for 7808 addresses

2019-10-01 Thread Enric Balletbo i Serra

Hi,

On 22/9/19 19:59, Brian Masney wrote:
> According to the downstream Android sources, the anx7808 variants use
> address 0x78 for TX_P0 and the anx781x variants use address 0x70. Since
> the datasheets aren't available for these devices, and we only have the
> downstream kernel sources to look at, let's assume that these addresses
> are fixed based on the model, and pass the i2c addresses to the driver
> via the data pointer in the driver's of_match_table.
> 
> Signed-off-by: Brian Masney 
> Reviewed-by: Laurent Pinchart 

The patch looks good to me:

Reviewed-by: Enric Balletbo i Serra 

> ---
> Changes since v2:
> - Change comments in analogix-anx78xx.h from using the address to the
>   name
> 
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 36 +++
>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 17 ---
>  2 files changed, 28 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index 8daee6b1fa88..dec3f7e66aa0 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -38,12 +38,20 @@
>  #define AUX_CH_BUFFER_SIZE   16
>  #define AUX_WAIT_TIMEOUT_MS  15
>  
> -static const u8 anx78xx_i2c_addresses[] = {
> - [I2C_IDX_TX_P0] = TX_P0,
> - [I2C_IDX_TX_P1] = TX_P1,
> - [I2C_IDX_TX_P2] = TX_P2,
> - [I2C_IDX_RX_P0] = RX_P0,
> - [I2C_IDX_RX_P1] = RX_P1,
> +static const u8 anx7808_i2c_addresses[] = {
> + [I2C_IDX_TX_P0] = 0x78,
> + [I2C_IDX_TX_P1] = 0x7a,
> + [I2C_IDX_TX_P2] = 0x72,
> + [I2C_IDX_RX_P0] = 0x7e,
> + [I2C_IDX_RX_P1] = 0x80,
> +};
> +
> +static const u8 anx781x_i2c_addresses[] = {
> + [I2C_IDX_TX_P0] = 0x70,
> + [I2C_IDX_TX_P1] = 0x7a,
> + [I2C_IDX_TX_P2] = 0x72,
> + [I2C_IDX_RX_P0] = 0x7e,
> + [I2C_IDX_RX_P1] = 0x80,
>  };
>  
>  struct anx78xx_platform_data {
> @@ -1315,6 +1323,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
>   struct anx78xx *anx78xx;
>   struct anx78xx_platform_data *pdata;
>   unsigned int i, idl, idh, version;
> + const u8 *i2c_addresses;
>   bool found = false;
>   int err;
>  
> @@ -1354,15 +1363,16 @@ static int anx78xx_i2c_probe(struct i2c_client 
> *client,
>   }
>  
>   /* Map slave addresses of ANX7814 */
> + i2c_addresses = device_get_match_data(&client->dev);
>   for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
>   struct i2c_client *i2c_dummy;
>  
>   i2c_dummy = i2c_new_dummy_device(client->adapter,
> -  anx78xx_i2c_addresses[i] >> 1);
> +  i2c_addresses[i] >> 1);
>   if (IS_ERR(i2c_dummy)) {
>   err = PTR_ERR(i2c_dummy);
>   DRM_ERROR("Failed to reserve I2C bus %02x: %d\n",
> -   anx78xx_i2c_addresses[i], err);
> +   i2c_addresses[i], err);
>   goto err_unregister_i2c;
>   }
>  
> @@ -1372,7 +1382,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
>   if (IS_ERR(anx78xx->map[i])) {
>   err = PTR_ERR(anx78xx->map[i]);
>   DRM_ERROR("Failed regmap initialization %02x\n",
> -   anx78xx_i2c_addresses[i]);
> +   i2c_addresses[i]);
>   goto err_unregister_i2c;
>   }
>   }
> @@ -1471,10 +1481,10 @@ MODULE_DEVICE_TABLE(i2c, anx78xx_id);
>  
>  #if IS_ENABLED(CONFIG_OF)
>  static const struct of_device_id anx78xx_match_table[] = {
> - { .compatible = "analogix,anx7808", },
> - { .compatible = "analogix,anx7812", },
> - { .compatible = "analogix,anx7814", },
> - { .compatible = "analogix,anx7818", },
> + { .compatible = "analogix,anx7808", .data = anx7808_i2c_addresses },
> + { .compatible = "analogix,anx7812", .data = anx781x_i2c_addresses },
> + { .compatible = "analogix,anx7814", .data = anx781x_i2c_addresses },
> + { .compatible = "analogix,anx7818", .data = anx781x_i2c_addresses },
>   { /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, anx78xx_match_table);
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> index 25e063bcecbc..55d6c2109740 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> @@ -6,15 +6,8 @@
>  #ifndef __ANX78xx_H
>  #define __ANX78xx_H
>  
> -#define TX_P00x70
> -#define TX_P10x7a
> -#define TX_P20x72
> -
> -#define RX_P00x7e
> -#define RX_P10x80
> -
>  /***/
> -/* Register definition of device address 0x7e

[Bug 111877] AMDKFD crash with VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #3 from Dimitar Atanasov  ---
yes this helps. clinfo is working now without crash and also darktable will
find all gpu-s

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

Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer

2019-10-01 Thread Alex Deucher

On Mon, Sep 30, 2019 at 8:57 AM Ayan Halder  wrote:
>
> On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> > Hi,
> >
> > On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > > > On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
> > > > >> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> > > > >>> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that 
> > > > >>> the framebuffer
> > > > >>> is allocated in a protected system memory.
> > > > >>> Essentially, we want to support EGL_EXT_protected_content in our 
> > > > >>> komeda driver.
> > > > >>>
> > > > >>> Signed-off-by: Ayan Kumar Halder 
> > > > >>>
> > > > >>> /-- Note to reviewer
> > > > >>> Komeda driver is capable of rendering DRM (Digital Rights 
> > > > >>> Management) protected
> > > > >>> content. The DRM content is stored in a framebuffer allocated in 
> > > > >>> system memory
> > > > >>> (which needs some special hardware signals for access).
> > > > >>>
> > > > >>> Let us ignore how the protected system memory is allocated and for 
> > > > >>> the scope of
> > > > >>> this discussion, we want to figure out the best way possible for 
> > > > >>> the userspace
> > > > >>> to communicate to the drm driver to turn the protected mode on (for 
> > > > >>> accessing the
> > > > >>> framebuffer with the DRM content) or off.
> > > > >>>
> > > > >>> The possible ways by which the userspace could achieve this is via:-
> > > > >>>
> > > > >>> 1. Modifiers :- This looks to me the best way by which the 
> > > > >>> userspace can
> > > > >>> communicate to the kernel to turn the protected mode on for the 
> > > > >>> komeda driver
> > > > >>> as it is going to access one of the protected framebuffers. The 
> > > > >>> only problem is
> > > > >>> that the current modifiers describe the tiling/compression format. 
> > > > >>> However, it
> > > > >>> does not hurt to extend the meaning of modifiers to denote other 
> > > > >>> attributes of
> > > > >>> the framebuffer as well.
> > > > >>>
> > > > >>> The other reason is that on Android, we get an info from Gralloc
> > > > >>> (GRALLOC_USAGE_PROTECTED) which tells us that the buffer is 
> > > > >>> protected. This can
> > > > >>> be used to set up the modifier/s (AddFB2) during framebuffer 
> > > > >>> creation.
> > > > >>
> > > > >> How does this mesh with other modifiers, like AFBC? That's where I 
> > > > >> see the
> > > > >> issue here.
> > > > >
> > > > > AFBC modifiers are currently under Arm's namespace, the thought 
> > > > > behind the DRM
> > > > > modifiers would be to have it as a "generic" modifier.
> > >
> > > But if it's a generic flag, how do you combine that with other
> > > modifiers? Like if you have a tiled buffer, but also encrypted? Or
> > > afbc compressed, or whatever else. I'd expect for your hw encryption
> > > is orthogonal to the buffer/tiling/compression format used?
> >
> > This bit doesn't overlap with any of the other AFBC modifiers, so as
> > you say it'd be orthogonal, and could be set on AFBC buffers (if we
> > went that route).
> >
> > >
> > > > >>> 2. Framebuffer flags :- As of today, this can be one of the two 
> > > > >>> values
> > > > >>> ie (DRM_MODE_FB_INTERLACED/DRM_MODE_FB_MODIFIERS). Unlike 
> > > > >>> modifiers, the drm
> > > > >>> framebuffer flags are generic to the drm subsystem and ideally we 
> > > > >>> should not
> > > > >>> introduce any driver specific constraint/feature.
> > > > >>>
> > > > >>> 3. Connector property:- I could see the following properties used 
> > > > >>> for DRM
> > > > >>> protected content:-
> > > > >>> DRM_MODE_CONTENT_PROTECTION_DESIRED / ENABLED :- "This property is 
> > > > >>> used by
> > > > >>> userspace to request the kernel protect future content communicated 
> > > > >>> over
> > > > >>> the link". Clearly, we are not concerned with the protection 
> > > > >>> attributes of the
> > > > >>> transmitter. So, we cannot use this property for our case.
> > > > >>>
> > > > >>> 4. DRM plane property:- Again, we want to communicate that the 
> > > > >>> framebuffer(which
> > > > >>> can be attached to any plane) is protected. So introducing a new 
> > > > >>> plane property
> > > > >>> does not help.
> > > > >>>
> > > > >>> 5. DRM crtc property:- For the same reason as above, introducing a 
> > > > >>> new crtc
> > > > >>> property does not help.
> > > > >>
> > > > >> 6. Just track this as part of buffer allocation, i.e. I think it does
> > > > >> matter how you allocate these protected buffers. We could add a "is
> > > > >> protected buffer" flag at the dma_buf level for this.
> >
> > I also like this approach. The protected-ness is a property of the
> > allocation, so makes sense to store it with the allocation IMO.
> >
> > > > >>
> > > > >> So yeah for this stuff here I think we do want the full userspace 
> > > > >> s

Re: [PATCH v2 2/8] dt-bindings: sram: Convert SRAM bindings to json-schema

2019-10-01 Thread Krzysztof Kozlowski

On Tue, Oct 01, 2019 at 09:00:03AM -0500, Rob Herring wrote:
> On Wed, Sep 18, 2019 at 07:31:35PM +0200, Krzysztof Kozlowski wrote:
> > Convert generic mmio-sram bindings to DT schema format using
> > json-schema.
> 
> I've been slow getting to this because I started on the same thing...
> 
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> > 
> > ---
> > 
> > Changes since v1:
> > 1. Indent example with four spaces (more readable).
> > ---
> >  .../devicetree/bindings/sram/sram.txt |  80 --
> >  .../devicetree/bindings/sram/sram.yaml| 138 ++
> >  2 files changed, 138 insertions(+), 80 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/sram/sram.txt
> >  create mode 100644 Documentation/devicetree/bindings/sram/sram.yaml
> 
> > diff --git a/Documentation/devicetree/bindings/sram/sram.yaml 
> > b/Documentation/devicetree/bindings/sram/sram.yaml
> > new file mode 100644
> > index ..8d9d6ce494b2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sram/sram.yaml
> > @@ -0,0 +1,138 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sram/sram.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Generic on-chip SRAM
> > +
> > +maintainers:
> > +  - FIXME 
> 
> You can put me.

Sure.

> 
> > +
> > +description: |+
> > +  Simple IO memory regions to be managed by the genalloc API.
> > +
> > +  Each child of the sram node specifies a region of reserved memory. Each
> > +  child node should use a 'reg' property to specify a specific range of
> > +  reserved memory.
> > +
> > +  Following the generic-names recommended practice, node names should
> > +  reflect the purpose of the node. Unit address (@) should be
> > +  appended to the name.
> > +
> > +properties:
> > +  $nodename:
> > +pattern: "^sram(@.*)?"
> > +
> > +  compatible:
> > +items:
> > +  - enum:
> > +  - mmio-sram
> > +  - atmel,sama5d2-securam
> 
> I was trying to go down the path of putting all the compatibles for 
> various SRAM bindings here, but I ran into some issues. I need to 
> revisit as I've forgotten the exact issue.
> 
> This would need to be a 'contains' if this is going to work for others.

OK.

> 
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  "#address-cells":
> > +description: Should use the same values as the root node.
> > +
> > +  "#size-cells":
> > +description: Should use the same values as the root node.
> 
> I defined both of these to be 1 as 4GB of SRAM should be enough for a 
> while. We can debate 1 or 2 cells vs. 1, but there's no reason it has to 
> be the same as the root (unless we're failing to do address 
> translation).

That was copied from txt version. I can adjust them to 1 although this
is will more than simple conversion.

> 
> > +
> > +  ranges:
> > +description:
> > +  Should translate from local addresses within the sram to bus 
> > addresses.
> > +
> > +  no-memory-wc:
> > +description:
> > +  The flag indicating, that SRAM memory region has not to be remapped
> > +  as write combining. WC is used by default.
> > +type: boolean
> > +
> > +  # TODO: additionalProperties: false
> > +
> > +patternProperties:
> > +  "^([a-z]*-)?sram@[a-f0-9]$":
> > +type: object
> > +description:
> > +  Each child of the sram node specifies a region of reserved memory.
> > +properties:
> > +  reg:
> > +description:
> > +  IO mem address range, relative to the SRAM range.
> 
> maxItems: 1

OK

> 
> > +
> > +  compatible:
> > +$ref: /schemas/types.yaml#/definitions/string
> > +description:
> > +  Should contain a vendor specific string in the form
> > +  ,[-]
> > +
> > +  pool:
> > +description:
> > +  Indicates that the particular reserved SRAM area is addressable
> > +  and in use by another device or devices.
> > +type: boolean
> > +
> > +  export:
> > +description:
> > +  Indicates that the reserved SRAM area may be accessed outside
> > +  of the kernel, e.g. by bootloader or userspace.
> > +type: boolean
> > +
> > +  protect-exec:
> > +description: |
> > +  Same as 'pool' above but with the additional constraint that code
> > +  will be run from the region and that the memory is maintained as
> > +  read-only, executable during code execution. NOTE: This region 
> > must
> > +  be page aligned on start and end in order to properly allow
> > +  manipulation of the page attributes.
> > +type: boolean
> > +
> > +  label:
> > +$ref: /schemas/types.yaml#/definitions/string
> 
> Already has a type definition.

OK

Best regards,
Krzysztof

[Bug 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #7 from Dimitar Atanasov  ---
Created attachment 145605
  --> https://bugs.freedesktop.org/attachment.cgi?id=145605&action=edit
dmesg_resume

-- 
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 V6 5/8] backlight: qcom-wled: Restructure the driver for WLED3

2019-10-01 Thread Dan Murphy


Kiran

On 9/30/19 1:39 AM, Kiran Gunda wrote:

Restructure the driver to add the support for new WLED
peripherals.

Signed-off-by: Kiran Gunda 
Acked-by: Daniel Thompson 
---
  drivers/video/backlight/qcom-wled.c | 395 ++--
  1 file changed, 245 insertions(+), 150 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c
index f191242..740f1b6 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -7,59 +7,71 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  /* From DT binding */

+#define WLED_MAX_STRINGS   4
+
  #define WLED_DEFAULT_BRIGHTNESS   2048
  
-#define WLED3_SINK_REG_BRIGHT_MAX			0xFFF

-#define WLED3_CTRL_REG_VAL_BASE0x40
+#define WLED_SINK_REG_BRIGHT_MAX   0xFFF


Why did you change some of these again?

Can you just change it to the final #define in patch 4/8?

Dan

Re: [PATCH V6 3/8] backlight: qcom-wled: Add new properties for PMI8998

2019-10-01 Thread Dan Murphy


Kiran

On 9/30/19 1:39 AM, Kiran Gunda wrote:

Update the bindings with the new properties used for
PMI8998.

Signed-off-by: Kiran Gunda 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Rob Herring 
Acked-by: Daniel Thompson 
---
  .../bindings/leds/backlight/qcom-wled.txt  | 76 ++
  1 file changed, 62 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index 14f28f2..9d840d5 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -20,8 +20,7 @@ platforms. The PMIC is connected to the host processor via 
SPMI bus.
  - default-brightness
Usage:optional
Value type:   
-   Definition:   brightness value on boot, value from: 0-4095
- Default: 2048
+   Definition:   brightness value on boot, value from: 0-4095.
  
  - label

Usage:required
@@ -48,20 +47,24 @@ platforms. The PMIC is connected to the host processor via 
SPMI bus.
  - qcom,current-limit
Usage:optional
Value type:   
-   Definition:   mA; per-string current limit
- value: For pm8941: from 0 to 25 with 5 mA step
-Default 20 mA.
-For pmi8998: from 0 to 30 with 5 mA step
-Default 25 mA.
+   Definition:   mA; per-string current limit; value from 0 to 25 with
+ 1 mA step.
+ This property is supported only for pm8941.
+
+- qcom,current-limit-microamp
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit; value from 0 to 3 with
+ 2500 uA step.
  
  - qcom,current-boost-limit

Usage:optional
Value type:   
Definition:   mA; boost current limit.
  For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400,
- 1680. Default: 805 mA
+ 1680.
  For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300,
- 1500. Default: 970 mA
+ 1500.
  
  - qcom,switching-freq

Usage:optional
@@ -69,22 +72,66 @@ platforms. The PMIC is connected to the host processor via 
SPMI bus.
 Definition:   kHz; switching frequency; one of: 600, 640, 685, 738,
   800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200,
   4800, 9600.
-  Default: for pm8941: 1600 kHz
-   for pmi8998: 800 kHz
  
  - qcom,ovp

Usage:optional
Value type:   
Definition:   V; Over-voltage protection limit; one of:
- 27, 29, 32, 35. default: 29V
+ 27, 29, 32, 35.
  This property is supported only for PM8941.
  
+- qcom,ovp-millivolt

+   Usage:optional
+   Value type:   
+   Definition:   mV; Over-voltage protection limit;
+ For pmi8998: one of 18100, 19600, 29600, 31100
+ If this property is not specified for PM8941, it
+ falls back to "qcom,ovp" property.
+
  - qcom,num-strings
Usage:optional
Value type:   
Definition:   #; number of led strings attached;
- value from 1 to 3. default: 2
- This property is supported only for PM8941.
+ value: For PM8941 from 1 to 3.
+For PMI8998 from 1 to 4.


We probably don't need this since we define 1 led node per output.  And 
if you need to define


multiple strings per node then you use led-sources.

Then you will use fwnode_property_count_u32(child, "led-sources"); to 
get the number of outputs




+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. This should be
+ "short" and "ovp" interrupts. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.
+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- qcom,enabled-strings
+   Usage:optional
+   Value tyoe:   
+   Definition:   Array of the WLED strings numbered from 0 to 3. Each
+ string of leds are operated individually. Specify the
+ list of strings used by the device. Any combination of
+ led strings can be u

[Bug 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #6 from Dimitar Atanasov  ---
It was working with 5.1.x but since 5.2.x it is not

-- 
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 111877] AMDKFD crash with VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #2 from Alex Deucher  ---
Does appending amdgpu.runpm=0 to the kernel command line in grub help?

-- 
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 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #5 from Dimitar Atanasov  ---
Created attachment 145604
  --> https://bugs.freedesktop.org/attachment.cgi?id=145604&action=edit
dmesg_full

-- 
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 111877] AMDKFD crash with VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #1 from Dimitar Atanasov  ---
CPU 8706G Precision 5530 2-in-1 Ubuntu 18.04.3 kernel 5.3.1

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

[Bug 111877] AMDKFD crash with VegaM

2019-10-01 Thread bugzilla-daemon

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

Bug ID: 111877
   Summary: AMDKFD crash with VegaM
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: not set
  Priority: not set
 Component: DRM/amdkfd
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: phu...@yahoo.com

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

AMDKFD will crash and will hang entire machine with clinfo executed

-- 
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 V6 2/8] backlight: qcom-wled: restructure the qcom-wled bindings

2019-10-01 Thread Dan Murphy


Kiran

On 9/30/19 1:39 AM, Kiran Gunda wrote:

Restructure the qcom-wled bindings for the better readability.

Signed-off-by: Kiran Gunda 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Rob Herring 
Acked-by: Daniel Thompson 
Acked-by: Pavel Machek 
---
  .../bindings/leds/backlight/qcom-wled.txt  | 110 -


Since you are restructuring would it not be better to convert this to 
the yaml format?


It looks yamlish so the file extension should be .yaml.

Dan


  1 file changed, 85 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index fb39e32..14f28f2 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,90 @@
  Binding for Qualcomm Technologies, Inc. WLED driver
  
-Required properties:

-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to dim
-- qcom,current-limit: mA; per-string current limit; value from 0 to 25
-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 1 to 3
-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. reference
+platforms. The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be one of:
+   "qcom,pm8941-wled"
+   "qcom,pmi8998-wled"
+   "qcom,pm660l-wled"
+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- qcom,cs-out
+   Usage:optional
+   Value type:   
+   Definition:   enable current sink output.
+ This property is supported only for PM8941.
+
+- qcom,cabc
+   Usage:optional
+   Value type:   
+   Definition:   enable content adaptive backlight control.
+
+- qcom,ext-gen
+   Usage:optional
+   Value type:   
+   Definition:   use externally generated modulator signal to dim.
+ This property is supported only for PM8941.
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   mA; per-string current limit
+ value: For pm8941: from 0 to 25 with 5 mA step
+Default 20 mA.
+For pmi8998: from 0 to 30 with 5 mA step
+Default 25 mA.
+
+- qcom,current-boost-limit
+   Usage:optional
+   Value type:   
+   Definition:   mA; boost current limit.
+ For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400,
+ 1680. Default: 805 mA
+ For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300,
+ 1500. Default: 970 mA
+
+- qcom,switching-freq
+   Usage:optional
+   Value type:   
+Definition:   kHz; switching frequency; one of: 600, 640, 685, 738,
+  800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200,
+  4800, 9600.
+  Default: for pm8941: 1600 kHz
+   for pmi8998: 800 kHz
+
+- qcom,ovp
+   Usage:optional
+   Value type:   
+   Definition:   V; Over-voltage protection limit; one of:
+ 27, 29, 32, 35. default: 29V
+ This property is supported only for PM8941.
+
+- qcom,num-strings
+   Usage:optional
+   Value type:   
+   Definition:   #; number of led strings attached;
+ value from 1 to 3. default: 2
+ This property is supported only for PM8941.
  
  Example:

Re: [PATCH v3] drm/print: add drm_debug_enabled()

2019-10-01 Thread Eric Engestrom

On Tuesday, 2019-10-01 17:06:14 +0300, Jani Nikula wrote:
> Add helper to check if a drm debug category is enabled. Convert drm core
> to use it. No functional changes.
> 
> v2: Move unlikely() to drm_debug_enabled() (Eric)
> 
> v3: Keep unlikely() when combined with other conditions (Eric)
> 
> Cc: Eric Engestrom 

Reviewed-by: Eric Engestrom 

> Acked-by: Alex Deucher 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
>  drivers/gpu/drm/drm_edid.c| 2 +-
>  drivers/gpu/drm/drm_edid_load.c   | 2 +-
>  drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
>  drivers/gpu/drm/drm_print.c   | 4 ++--
>  drivers/gpu/drm/drm_vblank.c  | 6 +++---
>  include/drm/drm_print.h   | 5 +
>  8 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 7a26bfb5329c..0d466d3b0809 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1405,7 +1405,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>   ret = drm_atomic_nonblocking_commit(state);
>   } else {
> - if (unlikely(drm_debug & DRM_UT_STATE))
> + if (drm_debug_enabled(DRM_UT_STATE))
>   drm_atomic_print_state(state);
>  
>   ret = drm_atomic_commit(state);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e6801db54d0f..6b14b63b8d62 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1179,7 +1179,7 @@ static int drm_dp_mst_wait_tx_reply(struct 
> drm_dp_mst_branch *mstb,
>   }
>   }
>  out:
> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
>   struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>  
>   drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> @@ -2322,7 +2322,7 @@ static int process_single_tx_qlock(struct 
> drm_dp_mst_topology_mgr *mgr,
>   idx += tosend + 1;
>  
>   ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
>   struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>  
>   drm_printf(&p, "sideband msg failed to send\n");
> @@ -2389,7 +2389,7 @@ static void drm_dp_queue_down_tx(struct 
> drm_dp_mst_topology_mgr *mgr,
>   mutex_lock(&mgr->qlock);
>   list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
>  
> - if (unlikely(drm_debug & DRM_UT_DP)) {
> + if (drm_debug_enabled(DRM_UT_DP)) {
>   struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>  
>   drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3c9703b08491..0552175313cb 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1651,7 +1651,7 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  {
>   int i;
>  
> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>   return;
>  
>   dev_warn(connector->dev->dev,
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index d38b3b255926..37d8ba3ddb46 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name,
>   u8 *edid;
>   int fwsize, builtin;
>   int i, valid_extensions = 0;
> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
> DRM_UT_KMS);
> + bool print_bad_edid = !connector->bad_edid_counter || 
> drm_debug_enabled(DRM_UT_KMS);
>  
>   builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
>   if (builtin >= 0) {
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index f8154316a3b0..ccfb5b33c5e3 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi, 
> int dc,
>   int i, ret;
>   u8 *dst;
>  
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
>   pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>__func__, dc, max_chunk);
>  
> @@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, 
> int dc,
>   max_chunk = dbi->tx_buf9_len;
>   dst16 = dbi->tx_buf9;
>  
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
>   pr_debug("[

Re: [PATCH V6 1/8] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

2019-10-01 Thread Dan Murphy


Kiran

On 9/30/19 1:39 AM, Kiran Gunda wrote:

pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
Reviewed-by: Bjorn Andersson 
Acked-by: Rob Herring 
Acked-by: Daniel Thompson 
Acked-by: Pavel Machek 
---
  .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-


Instead of renaming this file would it be more maintainable to indicate 
in the pm8941-wled.txt


to reference the qcom-wled.txt file for complete description?

I will let Rob comment on maintainability.

Dan


  drivers/video/backlight/Kconfig   | 8 
  drivers/video/backlight/Makefile  | 2 +-
  drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
  4 files changed, 6 insertions(+), 6 deletions(-)
  rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt => 
qcom-wled.txt} (95%)
  rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
rename to Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver
  
  Required properties:

  - compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8b081d6..6ff3176 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -284,12 +284,12 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight
  
-config BACKLIGHT_PM8941_WLED

-   tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+   tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.
  
  config BACKLIGHT_SAHARA

tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 63c507c..6f87770 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -48,8 +48,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
  obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
  obj-$(CONFIG_BACKLIGHT_PANDORA)   += pandora_bl.o
  obj-$(CONFIG_BACKLIGHT_PCF50633)  += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
  obj-$(CONFIG_BACKLIGHT_PWM)   += pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
  obj-$(CONFIG_BACKLIGHT_SAHARA)+= kb3886_bl.o
  obj-$(CONFIG_BACKLIGHT_SKY81452)  += sky81452-backlight.o
  obj-$(CONFIG_BACKLIGHT_TOSA)  += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c 
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c

[Bug 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #4 from Alex Deucher  ---
Is this a regression?  Did it work on a previous kernel?  Please attach your
full dmesg output from boot.

-- 
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 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #3 from Dimitar Atanasov  ---
No it will not work at all. DRI_PRIME is not functioning also

-- 
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] RFC: drm/atomic-helper: Reapply color transformation after resume

2019-10-01 Thread Ville Syrjälä

On Mon, Sep 30, 2019 at 07:28:02PM -0300, Ezequiel Garcia wrote:
> Some platforms are not able to maintain the color transformation
> state after a system suspend/resume cycle.
> 
> Set the colog_mgmt_changed flag so that CMM on the CRTCs in
> the suspend state are reapplied after system resume.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
> This is an RFC, and it's mostly based on Jacopo Mondi's work 
> https://lkml.org/lkml/2019/9/6/498.
> 
> Changes from v2:
> * New patch.
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e41db0f202ca..518488125575 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3234,8 +3234,20 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>struct drm_atomic_state *state)
>  {
>   struct drm_modeset_acquire_ctx ctx;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned int i;
>   int err;
>  
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> +  * Force re-enablement of CMM after system resume if any
> +  * of the DRM color transformation properties was set in
> +  * the state saved at system suspend time.
> +  */
> + if (crtc_state->gamma_lut)

You say "any" but you check the one?

> + crtc_state->color_mgmt_changed = true;

But I'm not convinced this is the best way to go about it. 
I would generally expect that you repgrogram everything
when doing a full modeset since the state was possibly
lost while the crtc was disabled.

> + }
>   drm_mode_config_reset(dev);
>  
>   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err);
> -- 
> 2.22.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 1/4] drm/rect: Add drm_rect_translate_to()

2019-10-01 Thread Ville Syrjälä

On Tue, Oct 01, 2019 at 12:26:52PM +0300, Jani Nikula wrote:
> On Mon, 30 Sep 2019, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Add a helper to translate a rectangle to an absolute position.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> The series is
> 
> Reviewed-by: Jani Nikula 
>

Thanks. 1-2 pushed to drm-misc-next.

> 
> 
> > ---
> >  include/drm/drm_rect.h | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > index 6195820aa5c5..fc7c14627ee2 100644
> > --- a/include/drm/drm_rect.h
> > +++ b/include/drm/drm_rect.h
> > @@ -106,6 +106,20 @@ static inline void drm_rect_translate(struct drm_rect 
> > *r, int dx, int dy)
> > r->y2 += dy;
> >  }
> >  
> > +/**
> > + * drm_rect_translate_to - translate the rectangle to an absolute position
> > + * @r: rectangle to be tranlated
> > + * @x: horizontal position
> > + * @y: vertical position
> > + *
> > + * Move rectangle @r to @x in the horizontal direction,
> > + * and to @y in the vertical direction.
> > + */
> > +static inline void drm_rect_translate_to(struct drm_rect *r, int x, int y)
> > +{
> > +   drm_rect_translate(r, x - r->x1, y - r->y1);
> > +}
> > +
> >  /**
> >   * drm_rect_downscale - downscale a rectangle
> >   * @r: rectangle to be downscaled
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

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

Re: [PATCH v3 5/5] RFC: drm/atomic-helper: Reapply color transformation after resume

2019-10-01 Thread Jacopo Mondi

Hi Ezequiel,

On Mon, Sep 30, 2019 at 07:28:02PM -0300, Ezequiel Garcia wrote:
> Some platforms are not able to maintain the color transformation
> state after a system suspend/resume cycle.
>
> Set the colog_mgmt_changed flag so that CMM on the CRTCs in

CMM is the name of the Renesas unit for color enanchement. It should
not be used here as this will apply to all platforms.

> the suspend state are reapplied after system resume.
>
> Signed-off-by: Ezequiel Garcia 
> ---
> This is an RFC, and it's mostly based on Jacopo Mondi's work 
> https://lkml.org/lkml/2019/9/6/498.
>
> Changes from v2:
> * New patch.
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e41db0f202ca..518488125575 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3234,8 +3234,20 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>struct drm_atomic_state *state)
>  {
>   struct drm_modeset_acquire_ctx ctx;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned int i;
>   int err;
>
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> +  * Force re-enablement of CMM after system resume if any
> +  * of the DRM color transformation properties was set in
> +  * the state saved at system suspend time.
> +  */
> + if (crtc_state->gamma_lut)

Please note that in my original patch I only took gamma_lut into
account as that's what our CMM supports at the moment, but you should
here consider the degamma_lut and cmt flags in the crtc_state.

> + crtc_state->color_mgmt_changed = true;
> + }
>   drm_mode_config_reset(dev);
>
>   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err);
> --
> 2.22.0
>


signature.asc
Description: PGP signature

[Bug 111846] Suspend to RAM cause screen to glitch on navi10

2019-10-01 Thread bugzilla-daemon

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log (if using X) and your dmesg output.

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

Re: [PATCH v2 RESEND] drm/komeda: Workaround for broken FLIP_COMPLETE timestamps

2019-10-01 Thread Ayan Halder

On Tue, Oct 01, 2019 at 02:21:40PM +, Mihail Atanassov wrote:
> When initially turning a crtc on, drm_reset_vblank_timestamp will
> set the vblank timestamp to 0 for any driver that doesn't provide
> a ->get_vblank_timestamp() hook.
> 
> Unfortunately, the FLIP_COMPLETE event depends on that timestamp,
> and the only way to regenerate a valid one is to have vblank
> interrupts enabled and have a valid in-ISR call to
> drm_crtc_handle_vblank.
> 
> Additionally, if the user doesn't request vblanks but _does_ request
> FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the
> same stamp as the last vblank one.
> 
> Work around the issue by always enabling vblanks when the CRTC is on.
> Reducing the amount of time that PL0 has to be unmasked would be nice to
> fix at a later time.
> 
> Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]:
>  - moved drm_crtc_vblank_put call to the ->atomic_disable() hook
> 
> Cc: Daniel Vetter 
> Cc: Liviu Dudau 
> Signed-off-by: Mihail Atanassov 
> Reviewed-by: James Qian Wang (Arm Technology China) 

Pushed to drm-misc-next f59769c52cd7d158df53487ec2936f5592073340

Thanks,
Ayan
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 9ca5dbfd0723..75263d8cd0bd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -249,6 +249,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc,
>  {
>   komeda_crtc_prepare(to_kcrtc(crtc));
>   drm_crtc_vblank_on(crtc);
> + WARN_ON(drm_crtc_vblank_get(crtc));
>   komeda_crtc_do_flush(crtc, old);
>  }
>  
> @@ -341,6 +342,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc,
>   komeda_crtc_flush_and_wait_for_flip_done(kcrtc, disable_done);
>   }
>  
> + drm_crtc_vblank_put(crtc);
>   drm_crtc_vblank_off(crtc);
>   komeda_crtc_unprepare(kcrtc);
>  }
> -- 
> 2.23.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111860] Crash in AMDGPU after resume on VegaM

2019-10-01 Thread bugzilla-daemon

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

--- Comment #2 from Alex Deucher  ---
That's just a warning.  Does the driver still work properly?

-- 
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 111876] AMD 5700 XT / Navi - BenQ XL2420G - No EDID read with DP connector, HDMI works fine

2019-10-01 Thread bugzilla-daemon

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

--- Comment #4 from Christopher Jordan  ---
I forgot to mention - when using DP, after that EDID error, my screen displays
a 640x480 tty. I can start X with it, but xrandr shows no other resolutions to
use (probably because the KMS has no EDID info). I haven't been brave enough to
manually generate and force EDIDs, but I figure that something else is wrong,
as this all works fine under Windows.

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

Re: [PATCH v4 1/7] backlight: gpio: remove unneeded include

2019-10-01 Thread Daniel Thompson

On Tue, Oct 01, 2019 at 02:58:31PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> We no longer use any symbols from of_gpio.h. Remove this include.
> 
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Daniel Thompson 

> ---
>  drivers/video/backlight/gpio_backlight.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/gpio_backlight.c 
> b/drivers/video/backlight/gpio_backlight.c
> index 18e053e4716c..7e1990199fae 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.23.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 RESEND] drm/komeda: Workaround for broken FLIP_COMPLETE timestamps

2019-10-01 Thread Mihail Atanassov

When initially turning a crtc on, drm_reset_vblank_timestamp will
set the vblank timestamp to 0 for any driver that doesn't provide
a ->get_vblank_timestamp() hook.

Unfortunately, the FLIP_COMPLETE event depends on that timestamp,
and the only way to regenerate a valid one is to have vblank
interrupts enabled and have a valid in-ISR call to
drm_crtc_handle_vblank.

Additionally, if the user doesn't request vblanks but _does_ request
FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the
same stamp as the last vblank one.

Work around the issue by always enabling vblanks when the CRTC is on.
Reducing the amount of time that PL0 has to be unmasked would be nice to
fix at a later time.

Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]:
 - moved drm_crtc_vblank_put call to the ->atomic_disable() hook

Cc: Daniel Vetter 
Cc: Liviu Dudau 
Signed-off-by: Mihail Atanassov 
Reviewed-by: James Qian Wang (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 9ca5dbfd0723..75263d8cd0bd 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -249,6 +249,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc,
 {
komeda_crtc_prepare(to_kcrtc(crtc));
drm_crtc_vblank_on(crtc);
+   WARN_ON(drm_crtc_vblank_get(crtc));
komeda_crtc_do_flush(crtc, old);
 }
 
@@ -341,6 +342,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc,
komeda_crtc_flush_and_wait_for_flip_done(kcrtc, disable_done);
}
 
+   drm_crtc_vblank_put(crtc);
drm_crtc_vblank_off(crtc);
komeda_crtc_unprepare(kcrtc);
 }
-- 
2.23.0

1 2 >

1 - 100 of 160 matches

Mail list logo