[PATCH] drm/imx: Switch to SPDX identifier
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/dw_hdmi-imx.c | 5 + drivers/gpu/drm/imx/imx-drm-core.c | 11 +-- drivers/gpu/drm/imx/imx-ldb.c | 10 +- drivers/gpu/drm/imx/imx-tve.c | 10 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 10 +- drivers/gpu/drm/imx/ipuv3-plane.c | 10 +- drivers/gpu/drm/imx/parallel-display.c | 10 +- 7 files changed, 7 insertions(+), 59 deletions(-) diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c b/drivers/gpu/drm/imx/dw_hdmi-imx.c index fe6becd..77a26fd 100644 --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c @@ -1,10 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* Copyright (C) 2011-2013 Freescale Semiconductor, Inc. * * derived from imx-hdmi.c(renamed to bridge/dw_hdmi.c now) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #include #include diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index f0122af..14bf05c 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Freescale i.MX drm driver * * Copyright (C) 2011 Sascha Hauer, Pengutronix - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * */ #include #include diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c index 3bd0f8a..2c5bbe3 100644 --- a/drivers/gpu/drm/imx/imx-ldb.c +++ b/drivers/gpu/drm/imx/imx-ldb.c @@ -1,16 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * i.MX drm driver - LVDS display bridge * * Copyright (C) 2012 Sascha Hauer, Pengutronix - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index cffd331..4bc3ead 100644 --- a/drivers/gpu/drm/imx/imx-tve.c +++ b/drivers/gpu/drm/imx/imx-tve.c @@ -1,16 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * i.MX drm driver - Television Encoder (TVEv2) * * Copyright (C) 2013 Philipp Zabel, Pengutronix - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index 7d4b710..058b53c 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -1,16 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * i.MX IPUv3 Graphics driver * * Copyright (C) 2011 Sascha Hauer, Pengutronix - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index 203f247..b9a9d53 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -1,16 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * i.MX IPUv3 DP Overlay Planes * * Copyright (C) 2013 Philipp Zabel, Pengutronix - * - * This program is free softwa
[PATCH RESEND 2/2] drm/msm/adreno: Add power management functions for system sleep
When a msm8016 based system is woken up from suspend, the firmware in
the adreno device hangs.
[ 83.903416] qcom-iommu-ctx 1f09000.iommu-ctx: Unhandled context fault:
fsr=0x202, iova=0x, fsynr=0x2, cb=1
[ 85.853633] msm 1a0.mdss: A306: hangcheck detected gpu lockup rb 0!
[ 85.853661] msm 1a0.mdss: A306: completed fence: 370
[ 85.859073] msm 1a0.mdss: A306: submitted fence: 372
[ 85.865113] msm 1a0.mdss: A306: hangcheck recover!
Fix this by adding pm_runtime_force_suspend/pm_runtime_force_resume
as sleep ops.
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea2a007..12d87ccdec53 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -357,6 +357,7 @@ static int adreno_suspend(struct device *dev)
#endif
static const struct dev_pm_ops adreno_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(adreno_suspend, adreno_resume, NULL)
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/secboot/acr: fix memory leak
In case memory resources for *bl_desc* were allocated, release
them before return.
Addresses-Coverity-ID: 1472021 ("Resource leak")
Fixes: 0d466901552a ("drm/nouveau/secboot/acr: Remove VLA usage")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
index d02e183..5c14d6a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
@@ -801,6 +801,7 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
*falcon,
bl = acr->hsbl_unload_blob;
} else {
nvkm_error(_acr->subdev, "invalid secure boot blob!\n");
+ kfree(bl_desc);
return -EINVAL;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/4] Add infrastructure needed for CRC support
This patchset add the necessary infrastructure needed later for CRC support. 1. add functions to map buffers to kernel address space. 2. map/unmap buffers in the prepare/cleanup_fb hooks. 3. clip plane coordinates. 4. subclass CRTC state. changes in v4: - drop patch 5 "drm/vkms: Implement CRC debugfs API" from this patchset since it needs further work. Haneen Mohammed (4): drm/vkms: Add functions to map/unmap GEM backing storage drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks drm/vkms: Add atomic_helper_check_plane_state drm/vkms: subclass CRTC state drivers/gpu/drm/vkms/vkms_crtc.c | 53 +++-- drivers/gpu/drm/vkms/vkms_drv.h | 20 drivers/gpu/drm/vkms/vkms_gem.c | 79 ++- drivers/gpu/drm/vkms/vkms_plane.c | 63 4 files changed, 211 insertions(+), 4 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 1/2] drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()
To make suspend and resume work on msm8916 platforms, call into the generic
helpers and preserve the state across suspends.
Signed-off-by: Daniel Mack
---
I've sent these two small patches twice already in May, but I haven't
gotten any feedback, not sure why.
We're using these on a number of prototypes and they seem to do work
just fine.
drivers/gpu/drm/msm/msm_drv.c | 9 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0a3ea3034e39..cdbe9249bff2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -907,16 +907,25 @@ static struct drm_driver msm_driver = {
static int msm_pm_suspend(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
drm_kms_helper_poll_disable(ddev);
+ priv->pm_state = drm_atomic_helper_suspend(ddev);
+ if (IS_ERR(priv->pm_state)) {
+ drm_kms_helper_poll_enable(ddev);
+ return PTR_ERR(priv->pm_state);
+ }
+
return 0;
}
static int msm_pm_resume(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
+ drm_atomic_helper_resume(ddev, priv->pm_state);
drm_kms_helper_poll_enable(ddev);
return 0;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0a653dd2e618..459d06a1ab9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -155,6 +155,7 @@ struct msm_drm_private {
struct shrinker shrinker;
struct msm_vblank_ctrl vblank_ctrl;
+ struct drm_atomic_state *pm_state;
};
struct msm_format {
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks
This patch map/unmap GEM backing memory to kernel address space
in prepare/cleanup_fb respectively and cache the virtual address
for later use.
Signed-off-by: Haneen Mohammed
---
Changes in v2:
- use vkms_gem_vunmap
Changes in v3:
- return error number instead of vkms_obj->vaddr
Changes in v4:
- print return value from vkms_gem_vmap
drivers/gpu/drm/vkms/vkms_plane.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index 9f75b1e2c1c4..5611e7cf5fc9 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -9,6 +9,7 @@
#include "vkms_drv.h"
#include
#include
+#include
static const struct drm_plane_funcs vkms_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
@@ -24,8 +25,41 @@ static void vkms_primary_plane_update(struct drm_plane
*plane,
{
}
+static int vkms_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_gem_object *gem_obj;
+ struct vkms_gem_object *vkms_obj;
+ int ret;
+
+ if (!state->fb)
+ return 0;
+
+ gem_obj = drm_gem_fb_get_obj(state->fb, 0);
+ vkms_obj = drm_gem_to_vkms_gem(gem_obj);
+ ret = vkms_gem_vmap(gem_obj);
+ if (ret)
+ DRM_ERROR("vmap failed: %d\n", ret);
+
+ return drm_gem_fb_prepare_fb(plane, state);
+}
+
+static void vkms_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct drm_gem_object *gem_obj;
+
+ if (!old_state->fb)
+ return;
+
+ gem_obj = drm_gem_fb_get_obj(old_state->fb, 0);
+ vkms_gem_vunmap(gem_obj);
+}
+
static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
.atomic_update = vkms_primary_plane_update,
+ .prepare_fb = vkms_prepare_fb,
+ .cleanup_fb = vkms_cleanup_fb,
};
struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] drm/vkms: Add functions to map/unmap GEM backing storage
This patch add the necessary functions to map/unmap GEM
backing memory to the kernel's virtual address space.
Signed-off-by: Haneen Mohammed
---
Changes in v2:
- add vkms_gem_vunmap
- use vmap_count to guard against multiple prepare_fb calls on the same fb
Changes in v3:
- change vkms_gem_vmap to retrun int
- cleanup if vmap failed
- increment vmap_count after successful vmap
Changes in v4:
- add err_vmap label
- use out label instead of fail and remove 2 redundant lines
drivers/gpu/drm/vkms/vkms_drv.h | 9
drivers/gpu/drm/vkms/vkms_gem.c | 79 -
2 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 07be29f2dc44..47048f707566 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -39,6 +39,8 @@ struct vkms_gem_object {
struct drm_gem_object gem;
struct mutex pages_lock; /* Page lock used in page fault handler */
struct page **pages;
+ unsigned int vmap_count;
+ void *vaddr;
};
#define drm_crtc_to_vkms_output(target) \
@@ -47,6 +49,9 @@ struct vkms_gem_object {
#define drm_device_to_vkms_device(target) \
container_of(target, struct vkms_device, drm)
+#define drm_gem_to_vkms_gem(target)\
+ container_of(target, struct vkms_gem_object, gem)
+
/* CRTC */
int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor);
@@ -75,4 +80,8 @@ int vkms_dumb_map(struct drm_file *file, struct drm_device
*dev,
void vkms_gem_free_object(struct drm_gem_object *obj);
+int vkms_gem_vmap(struct drm_gem_object *obj);
+
+void vkms_gem_vunmap(struct drm_gem_object *obj);
+
#endif /* _VKMS_DRV_H_ */
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index c7e38368602b..a52e88338c05 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -37,7 +37,9 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
struct vkms_gem_object *gem = container_of(obj, struct vkms_gem_object,
gem);
- kvfree(gem->pages);
+ WARN_ON(gem->pages);
+ WARN_ON(gem->vaddr);
+
mutex_destroy(&gem->pages_lock);
drm_gem_object_release(obj);
kfree(gem);
@@ -177,3 +179,78 @@ int vkms_dumb_map(struct drm_file *file, struct drm_device
*dev,
return ret;
}
+
+static struct page **_get_pages(struct vkms_gem_object *vkms_obj)
+{
+ struct drm_gem_object *gem_obj = &vkms_obj->gem;
+
+ if (!vkms_obj->pages) {
+ struct page **pages = drm_gem_get_pages(gem_obj);
+
+ if (IS_ERR(pages))
+ return pages;
+
+ if (cmpxchg(&vkms_obj->pages, NULL, pages))
+ drm_gem_put_pages(gem_obj, pages, false, true);
+ }
+
+ return vkms_obj->pages;
+}
+
+void vkms_gem_vunmap(struct drm_gem_object *obj)
+{
+ struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(obj);
+
+ mutex_lock(&vkms_obj->pages_lock);
+ if (vkms_obj->vmap_count < 1) {
+ WARN_ON(vkms_obj->vaddr);
+ WARN_ON(vkms_obj->pages);
+ mutex_unlock(&vkms_obj->pages_lock);
+ return;
+ }
+
+ vkms_obj->vmap_count--;
+
+ if (vkms_obj->vmap_count == 0) {
+ vunmap(vkms_obj->vaddr);
+ vkms_obj->vaddr = NULL;
+ drm_gem_put_pages(obj, vkms_obj->pages, false, true);
+ vkms_obj->pages = NULL;
+ }
+
+ mutex_unlock(&vkms_obj->pages_lock);
+}
+
+int vkms_gem_vmap(struct drm_gem_object *obj)
+{
+ struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(obj);
+ int ret = 0;
+
+ mutex_lock(&vkms_obj->pages_lock);
+
+ if (!vkms_obj->vaddr) {
+ unsigned int n_pages = obj->size >> PAGE_SHIFT;
+ struct page **pages = _get_pages(vkms_obj);
+
+ if (IS_ERR(pages)) {
+ ret = PTR_ERR(pages);
+ goto out;
+ }
+
+ vkms_obj->vaddr = vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
+ if (!vkms_obj->vaddr)
+ goto err_vmap;
+
+ vkms_obj->vmap_count++;
+ }
+
+ goto out;
+
+err_vmap:
+ ret = -ENOMEM;
+ drm_gem_put_pages(obj, vkms_obj->pages, false, true);
+ vkms_obj->pages = NULL;
+out:
+ mutex_unlock(&vkms_obj->pages_lock);
+ return ret;
+}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] dt-bindings: drm/bridge Document Cadence MHDP DPI/DP bridge bindings
From: Quentin Schulz
Signed-off-by: Damian Kos
---
.../bindings/display/bridge/cdns,mhdp.txt | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
new file mode 100644
index ..dc7be7590048
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
@@ -0,0 +1,43 @@
+Cadence MHDP bridge
+==
+
+The Cadence MHDP bridge is a DPI to DP bridge.
+
+Required properties:
+- compatible: should be "cdns,mhdp8546",
+- reg: physical base address and length of the controller's registers,
+- clocks: DP bridge clock, it's used by the IP to know how to translate
+ a number of clock cycles into a time (which is used to comply
+ with DP standard timings and delays),
+
+Required subnodes:
+- ports: Ports as described in Documentation/devictree/bindings/graph.txt
+ Port 0 - input port representing the VGA bridge input
+ Port 1 - output port representing the VGA bridge output
+
+Example:
+
+ mhdp: dp-bridge@f0fb00 {
+ compatible = "cdns,mhdp8546";
+ reg = <0xf0 0xfb00 0x0 0x100>;
+ clocks = <&mhdp_clock>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ vga_bridge_input: endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ vga_bridge_output: endpoint {
+ remote-endpoint =
<&xxx_vga_connector_input>;
+ };
+ };
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()
On Tue, Jul 24, 2018 at 11:54 AM, Inki Dae wrote:
> Hi,
>
> 2018년 07월 19일 05:49에 Souptick Joarder 이(가) 쓴 글:
>> convert drm_atomic_helper_suspend/resume() to use
>> drm_mode_config_helper_suspend/resume().
>>
>> exynos_drm_fbdev_suspend/resume can be removed
>> as drm_mode_config_helper_suspend/resume has
>> implement the same in generic way.
>>
>> Signed-off-by: Souptick Joarder
>> Signed-off-by: Ajit Negi
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 32
>> ++-
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 17
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 --
>> 3 files changed, 10 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index a81b4a5..1996ff7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -151,39 +151,27 @@ static void exynos_drm_postclose(struct drm_device
>> *dev, struct drm_file *file)
>> static int exynos_drm_suspend(struct device *dev)
>> {
>> struct drm_device *drm_dev = dev_get_drvdata(dev);
>> - struct exynos_drm_private *private;
>> + int ret = 0;
>>
>> - if (pm_runtime_suspended(dev) || !drm_dev)
>> - return 0;
>
> You removes '!drm_dev' not related to this patch.
The same has been checked inside drm_mode_config_helper_suspend(),
so we should avoid double check.
>
>> + if (pm_runtime_suspended(dev))
>> + return ret;
>>
>> - private = drm_dev->dev_private;
>> + ret = drm_mode_config_helper_suspend(drm_dev);
>
> Just return drm_mode_config_helper_suspend(drm_dev);
Ok
>
>>
>> - drm_kms_helper_poll_disable(drm_dev);
>> - exynos_drm_fbdev_suspend(drm_dev);
>> - private->suspend_state = drm_atomic_helper_suspend(drm_dev);
>> - if (IS_ERR(private->suspend_state)) {
>> - exynos_drm_fbdev_resume(drm_dev);
>> - drm_kms_helper_poll_enable(drm_dev);
>> - return PTR_ERR(private->suspend_state);
>> - }
>> -
>> - return 0;
>> + return ret;
>> }
>>
>> static int exynos_drm_resume(struct device *dev)
>> {
>> struct drm_device *drm_dev = dev_get_drvdata(dev);
>> - struct exynos_drm_private *private;
>> + int ret = 0;
>>
>> - if (pm_runtime_suspended(dev) || !drm_dev)
>> - return 0;
>> + if (pm_runtime_suspended(dev))
>> + return ret;
>
> Ditto. You removes '!drm_dev' not related to this patch.
Same reason mentioned above to remove '!drm_dev'
>
>>
>> - private = drm_dev->dev_private;
>> - drm_atomic_helper_resume(drm_dev, private->suspend_state);
>> - exynos_drm_fbdev_resume(drm_dev);
>> - drm_kms_helper_poll_enable(drm_dev);
>> + ret = drm_mode_config_helper_resume(drm_dev);
>
> Ditto. return drm_mode_config_helper_resume(drm_dev);
>
> With this patch, you could remove 'int ret' declaration including one from
> exynos_drm_suspend.
Ok, I will add this in v2.
>
> Thanks,
> Inki Dae
>
>>
>> - return 0;
>> + return ret;
>> }
>> #endif
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index 132dd52..918dd2c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -270,20 +270,3 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
>> private->fb_helper = NULL;
>> }
>>
>> -void exynos_drm_fbdev_suspend(struct drm_device *dev)
>> -{
>> - struct exynos_drm_private *private = dev->dev_private;
>> -
>> - console_lock();
>> - drm_fb_helper_set_suspend(private->fb_helper, 1);
>> - console_unlock();
>> -}
>> -
>> -void exynos_drm_fbdev_resume(struct drm_device *dev)
>> -{
>> - struct exynos_drm_private *private = dev->dev_private;
>> -
>> - console_lock();
>> - drm_fb_helper_set_suspend(private->fb_helper, 0);
>> - console_unlock();
>> -}
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> index b338472..6840b6a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> @@ -19,8 +19,6 @@
>>
>> int exynos_drm_fbdev_init(struct drm_device *dev);
>> void exynos_drm_fbdev_fini(struct drm_device *dev);
>> -void exynos_drm_fbdev_suspend(struct drm_device *drm);
>> -void exynos_drm_fbdev_resume(struct drm_device *drm);
>>
>> #else
>>
>> @@ -39,14 +37,6 @@ static inline void exynos_drm_fbdev_restore_mode(struct
>> drm_device *dev)
>>
>> #define exynos_drm_output_poll_changed (NULL)
>>
>> -static inline void exynos_drm_fbdev_suspend(struct drm_device *drm)
>> -{
>> -}
>> -
>> -static inline void exynos_drm_fbdev_resume(struct drm_device *drm)
>> -{
>> -}
>> -
>> #endif
>>
>> #endif
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
[PATCH v2 1/5] drm/rockchip: moved cdns mhdp dpi/dp bridge low driver to a new location
- Moved cdn-dp-reg from drivers/gpu/drm/rockchip to a new location
in drivers/drm/bridge/cadence and renamed it to cdns-mhdp-common.
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdns-mhdp-common.h.
- Changed prefixes from cdn_dp to cdns_mhdp
cdn -> cdns to match the other Cadence's drivers
dp -> mhdp to distinguish it from a "just a DP" as the IP underneath
this registers map can be a HDMI (which is internally different,
but the interface for commands, events is pretty much the same).
- Modified cdn-dp-core.c to use the new driver structure and new function
names.
- Changed the CONFIG_ROCKCHIP_CDN_DP configuration to automatically select the
Cadence MHDP DPI/DP bridge (DRM_CDNS_MHDP).
Signed-off-by: Damian Kos
---
drivers/gpu/drm/bridge/Kconfig| 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
.../cdns-mhdp-common.c} | 434 +-
.../cdns-mhdp-common.h} | 123 -
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip/Makefile | 4 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 220 -
drivers/gpu/drm/rockchip/cdn-dp-core.h| 40 +-
8 files changed, 453 insertions(+), 377 deletions(-)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
(53%)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
(83%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bf6cad6c9178..31b75c971454 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -35,6 +35,13 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence MHDP DPI/DP bridge"
+ select DRM_KMS_HELPER
+ depends on OF
+ help
+ Support for Cadence DPI to DP bridge.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 35f88d48ec20..c9b35f736a00 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp-common.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
similarity index 53%
rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
index 3105965fc260..813319481220 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
@@ -19,22 +19,24 @@
#include
#include
-#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
+#include
+#include
-#define CDN_DP_SPDIF_CLK 2
+#include "cdns-mhdp-common.h"
+
+#define CDNS_DP_SPDIF_CLK 2
#define FW_ALIVE_TIMEOUT_US100
#define MAILBOX_RETRY_US 1000
#define MAILBOX_TIMEOUT_US 500
#define LINK_TRAINING_RETRY_MS 20
#define LINK_TRAINING_TIMEOUT_MS 500
-void cdn_dp_set_fw_clk(struct cdn_dp_device *dp, unsigned long clk)
+void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp, unsigned long clk)
{
- writel(clk / 100, dp->regs + SW_CLK_H);
+ writel(clk / 100, mhdp->regs + SW_CLK_H);
}
-void cdn_dp_clock_reset(struct cdn_dp_device *dp)
+void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
{
u32 val;
@@ -50,16 +52,16 @@ void cdn_dp_clock_reset(struct cdn_dp_device *dp)
DPTX_SYS_CLK_EN |
CFG_DPTX_VIF_CLK_RSTN_EN |
CFG_DPTX_VIF_CLK_EN;
- writel(val, dp->regs + SOURCE_DPTX_CAR);
+ writel(val, mhdp->regs + SOURCE_DPTX_CAR);
val = SOURCE_PHY_RSTN_EN | SOURCE_PHY_CLK_EN;
- writel(val, dp->regs + SOURCE_PHY_CAR);
+ writel(val, mhdp->regs + SOURCE_PHY_CAR);
val = SOURCE_PKT_SYS_RSTN_EN |
SOURCE_PKT_SYS_CLK_EN |
SOURCE_PKT_DATA_RSTN_EN |
SOURCE_PKT_DATA_CLK_EN;
- writel(val, dp->regs + SOURCE_PKT_CAR);
+ writel(val, mhdp->regs + SOURCE_PKT_CAR);
val = SPDIF_CDR_CLK_RSTN_EN |
SPDIF_CDR_CLK_EN |
@@ -67,53 +69,53 @@ void cdn_dp_clock_reset(struct cdn_dp_device *dp)
SOURCE_AIF_SYS_CLK_EN |
SOURCE_AIF_CLK_RSTN_EN |
[PATCH v2 3/5] drm/dp: make dp_link_status and dp_get_lane_status usable from outside of the core
From: Quentin Schulz
dp_link_status and dp_get_lane_status are pretty generic and can be used for
other means, so let's make it "public".
This adds drm_dp_link_status and drm_dp_get_lane_status to the header file and
add the appropriate EXPORT_SYMBOL for it so that it can be used by other
drivers, be they compiled built-in or as modules.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 20 +++-
include/drm/drm_dp_helper.h | 3 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 86a070269c87..8d10f70465cc 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -43,19 +43,21 @@
*/
/* Helpers for DP link training */
-static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
+u8 drm_dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
{
return link_status[r - DP_LANE0_1_STATUS];
}
+EXPORT_SYMBOL(drm_dp_link_status);
-static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
+u8 drm_dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane)
{
int i = DP_LANE0_1_STATUS + (lane >> 1);
int s = (lane & 1) * 4;
- u8 l = dp_link_status(link_status, i);
+ u8 l = drm_dp_link_status(link_status, i);
return (l >> s) & 0xf;
}
+EXPORT_SYMBOL(drm_dp_get_lane_status);
bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count)
@@ -64,12 +66,12 @@ bool drm_dp_channel_eq_ok(const u8
link_status[DP_LINK_STATUS_SIZE],
u8 lane_status;
int lane;
- lane_align = dp_link_status(link_status,
- DP_LANE_ALIGN_STATUS_UPDATED);
+ lane_align = drm_dp_link_status(link_status,
+ DP_LANE_ALIGN_STATUS_UPDATED);
if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
return false;
for (lane = 0; lane < lane_count; lane++) {
- lane_status = dp_get_lane_status(link_status, lane);
+ lane_status = drm_dp_get_lane_status(link_status, lane);
if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
return false;
}
@@ -84,7 +86,7 @@ bool drm_dp_clock_recovery_ok(const u8
link_status[DP_LINK_STATUS_SIZE],
u8 lane_status;
for (lane = 0; lane < lane_count; lane++) {
- lane_status = dp_get_lane_status(link_status, lane);
+ lane_status = drm_dp_get_lane_status(link_status, lane);
if ((lane_status & DP_LANE_CR_DONE) == 0)
return false;
}
@@ -99,7 +101,7 @@ u8 drm_dp_get_adjust_request_voltage(const u8
link_status[DP_LINK_STATUS_SIZE],
int s = ((lane & 1) ?
DP_ADJUST_VOLTAGE_SWING_LANE1_SHIFT :
DP_ADJUST_VOLTAGE_SWING_LANE0_SHIFT);
- u8 l = dp_link_status(link_status, i);
+ u8 l = drm_dp_link_status(link_status, i);
return ((l >> s) & 0x3) << DP_TRAIN_VOLTAGE_SWING_SHIFT;
}
@@ -112,7 +114,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
int s = ((lane & 1) ?
DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT :
DP_ADJUST_PRE_EMPHASIS_LANE0_SHIFT);
- u8 l = dp_link_status(link_status, i);
+ u8 l = drm_dp_link_status(link_status, i);
return ((l >> s) & 0x3) << DP_TRAIN_PRE_EMPHASIS_SHIFT;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 92800f2241b1..1ba6b6855444 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -952,6 +952,9 @@
#define DP_MST_LOGICAL_PORT_0 8
#define DP_LINK_STATUS_SIZE 6
+
+u8 drm_dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r);
+u8 drm_dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE], int lane);
bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring
在 2018-07-24二的 14:37 +0200，Maxime Ripard写道： > On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: > > Hi Maxime, > > > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard > > napisal(a): > > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: > > > > This series fixes several issues found in R40 HDMI patch series > > > > after > > > > it was applied. Conversation can be found here: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.htm > > > > l > > > > > > > > Patches are based on latest linux-next (next-20180710) and are > > > > ordered > > > > in such way that they don't break R40 HDMI at any time. Because > > > > of that > > > > I suggest that whole series goes through drm-misc to preserve > > > > that order. > > > > > > > > I also tested those patches on H3 to make sure it doesn't break > > > > other > > > > platforms. However, it would be nice to test for regressions > > > > also on > > > > older SoCs (with DE1). > > > > > > > > Best regards, > > > > Jernej > > > > > > Applied all patches but the patch 10, thanks! > > > Maxime > > > > It seems that you forgot to merge some patches: > > > > [PATCH v2 12/18] drm/sun4i: tcon: Add another way for matching > > mixers with > > tcon > > [PATCH v2 13/18] drm/sun4i: tcon: Add support for R40 TCON > > > > Without them, R40 display pipeline can't work. > > > > Maybe they are in your spam folder? > > Thanks for telling me, I'm not quite sure what happened. > > I've applied them. BTW without them the board cannot boot because of dead loop in sun4i_drv_probe(). > > Sorry, > Maxime > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/vkms: subclass CRTC state
Subclass CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.
Signed-off-by: Haneen Mohammed
Reviewed-by: Daniel Vetter
Reviewed-by: Sean Paul
---
drivers/gpu/drm/vkms/vkms_crtc.c | 53 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 11 +++
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 875fca662ac0..26babb85ca77 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -64,13 +64,60 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
unsigned int pipe,
return true;
}
+static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
+{
+ struct vkms_crtc_state *vkms_state = NULL;
+
+ if (crtc->state) {
+ vkms_state = to_vkms_crtc_state(crtc->state);
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+ kfree(vkms_state);
+ crtc->state = NULL;
+ }
+
+ vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
+ if (!vkms_state)
+ return;
+
+ crtc->state = &vkms_state->base;
+ crtc->state->crtc = crtc;
+}
+
+static struct drm_crtc_state *
+vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+ struct vkms_crtc_state *vkms_state;
+
+ if (WARN_ON(!crtc->state))
+ return NULL;
+
+ vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
+ if (!vkms_state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, &vkms_state->base);
+
+ return &vkms_state->base;
+}
+
+static void vkms_atomic_crtc_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct vkms_crtc_state *vkms_state;
+
+ vkms_state = to_vkms_crtc_state(state);
+
+ __drm_atomic_helper_crtc_destroy_state(state);
+ kfree(vkms_state);
+}
+
static const struct drm_crtc_funcs vkms_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy= drm_crtc_cleanup,
.page_flip = drm_atomic_helper_page_flip,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .reset = vkms_atomic_crtc_reset,
+ .atomic_duplicate_state = vkms_atomic_crtc_duplicate_state,
+ .atomic_destroy_state = vkms_atomic_crtc_destroy_state,
.enable_vblank = vkms_enable_vblank,
.disable_vblank = vkms_disable_vblank,
};
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 47048f707566..75e52d61e65d 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -20,6 +20,14 @@ static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB,
};
+/**
+ * vkms_crtc_state - Driver specific CRTC state
+ * @base: base CRTC state
+ */
+struct vkms_crtc_state {
+ struct drm_crtc_state base;
+};
+
struct vkms_output {
struct drm_crtc crtc;
struct drm_encoder encoder;
@@ -52,6 +60,9 @@ struct vkms_gem_object {
#define drm_gem_to_vkms_gem(target)\
container_of(target, struct vkms_gem_object, gem)
+#define to_vkms_crtc_state(target)\
+ container_of(target, struct vkms_crtc_state, base)
+
/* CRTC */
int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] drm: add support for Cadence MHDP DPI/DP bridge.
Hello!
This is the series of patches that will add support for the Cadence's DPI/DP
bridge. Please note that this is a preliminary version of the driver and there
will be more patches in the future with updates, fixes and improvements.
Please keep that in mind when looking at FIXME/TODO/XXX comments.
Initially, MHDP driver was developed as a DRM bridge driver and was planed to
be placed in drivers/gpu/drm/bridge/mhdp.c. However, there was already
a driver for Cadence's DP controller developed by RockChip, but that driver
uses the different DRM framework and looks like a part of a bigger system.
Both controllers (including firmware) are quite different internally
(MST/FEC/DSC support, link training done by driver, additional commands, IRQ's
etc.) but they have similar register map, except for Framer/Streamer (which is
noticeably different), so they appear similar.
The following patches contain:
- Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and
modifying it a bit (mostly new prefixes for functions and data types) so it
can be used by two, higher level, drivers.
- Modifying existing RockChip's DP driver to use the common code after changes
made to it (use the new cdns_mhdp_device structure and new function names).
- Modifying DRM helpers a bit. Some are required for new driver, some are
updates from DP 1.2 to 1.3 or 1.4.
- Adding documentation for device tree bindings.
- Adding preliminary Cadence DPI/DP bridge driver.
Some of the things that will be added later on include (but are not limited
to):
- Support for Cadence SD0801 PHY (PHY's driver should be on the way by now)
- SST audio support
- MST support
- DSC support
- FEC support
- HDCP support
Changes in v2:
- Added actual description of what the patch contains, what is it for and
what's going on here in general.
- New structure. Now we have one common low level driver + two high level
drivers - one for RockChip with minimum changes and one, more general, for
Cadence.
- Dropped some changes made to DRM helpers.
- Updated the device tree bindings document.
Damian Kos (1):
drm/rockchip: moved cdns mhdp dpi/dp bridge low driver to a new
location
Quentin Schulz (4):
drm/dp: fix link probing for devices supporting DP 1.4+
drm/dp: make dp_link_status and dp_get_lane_status usable from outside
of the core
dt-bindings: drm/bridge Document Cadence MHDP DPI/DP bridge bindings
drm/bridge: add preliminary driver for cadence dpi/dp bridge
.../bindings/display/bridge/cdns,mhdp.txt | 43 +
drivers/gpu/drm/bridge/Kconfig|7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/cdns-mhdp-common.c | 1087 +++
.../cdns-mhdp-common.h} | 134 +-
drivers/gpu/drm/bridge/cdns-mhdp.c| 1233 +
drivers/gpu/drm/drm_dp_helper.c | 50 +-
drivers/gpu/drm/rockchip/Kconfig |1 +
drivers/gpu/drm/rockchip/Makefile |4 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 220 +--
drivers/gpu/drm/rockchip/cdn-dp-core.h| 40 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 969 -
include/drm/drm_dp_helper.h |4 +
13 files changed, 2648 insertions(+), 1145 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-common.c
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
(80%)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
delete mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH] drm/bridge/synopsys: remove commented-out flag in Makefile
Please do not comment out unneeded code. Remove. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/bridge/synopsys/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile index 5dad97d..3e1b1e3 100644 --- a/drivers/gpu/drm/bridge/synopsys/Makefile +++ b/drivers/gpu/drm/bridge/synopsys/Makefile @@ -1,5 +1,3 @@ -#ccflags-y := -Iinclude/drm - obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from DP_DPCD_REV
to DP_ADAPTER_CAP should be retrieved starting from DP_DPCD_REV_EXTENDED.
All registers are copied except DP_DPCD_REV, DP_MAX_LINK_RATE and
DP_DOWNSTREAMPORT_PRESENT which represent the "true capabilities" of DPRX
device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT might
falsely return lower capabilities to "avoid interoperability issues with some
of the existing DP Source devices that malfunction when they discover the
higher capabilities within those three registers.".
Before DP 1.4, DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT bit was reserved and read 0
so it's safe to check against it even if DP revision is <1.4
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
include/drm/drm_dp_helper.h | 1 +
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0cccbcb2d03e..86a070269c87 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT bit was reserved
+* and read 0 so it's safe to check against it even if DP revision is
+* <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 05cc31b5db16..92800f2241b1 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -125,6 +125,7 @@
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
+# define DP_EXTENDED_RCVR_CAPA_FIELD_PRESENT BIT(7) /* 1.3 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH linux-next] gnu: fix mismatch in function argument.
Fix the sparse error. the dpu_rm_init declaration is not consistent
with the implement.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index ef3f67b..ffd1841 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -105,7 +105,7 @@ struct dpu_rm_hw_iter {
*/
int dpu_rm_init(struct dpu_rm *rm,
struct dpu_mdss_cfg *cat,
- void *mmio,
+ void __iomem *mmio,
struct drm_device *dev);
/**
--
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes
On Tuesday, July 24, 2018 05:03 PM, Bartlomiej Zolnierkiewicz wrote: On Monday, July 09, 2018 07:12:50 AM Daniel Mack wrote: Should I resend with Robert's Reviewed-bys again? I'd like to get this merged for 4.19 if possible. No need for resend, I added Robert's tags while applying your patches. Great, thank you! Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH linux-next] gnu: fix mismatch in function argument.
Fix the sparse error. the dpu_rm_init declaration is not consistent
with the implement.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index ef3f67b..ffd1841 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -105,7 +105,7 @@ struct dpu_rm_hw_iter {
*/
int dpu_rm_init(struct dpu_rm *rm,
struct dpu_mdss_cfg *cat,
- void *mmio,
+ void __iomem *mmio,
struct drm_device *dev);
/**
--
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dw-hdmi: re-run dw_hdmi_setup when setting mode
Currently dw_hdmi_setup is only run when the dw-hdmi bridge is enabled, with the mode set last time. When the bridge is enabled before any mode is set (this may happen when booting), the mode won't be set at all, some setup steps will be skipped or fail, and the HDMI output may not work. Re-run dw_hdmi_setup when setting mode, in order to prevent such situation. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 5971976284bf..e2f832182afe 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2007,6 +2007,7 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge, /* Store the display mode for plugin/DKMS poweron events */ memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode)); + dw_hdmi_setup(hdmi, mode); mutex_unlock(&hdmi->mutex); } -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring
Dne torek, 24. julij 2018 ob 18:04:49 CEST je Icenowy Zheng napisal(a): > 在 2018-07-24二的 14:37 +0200，Maxime Ripard写道： > > > On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: > > > Hi Maxime, > > > > > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard > > > > > > napisal(a): > > > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: > > > > > This series fixes several issues found in R40 HDMI patch series > > > > > after > > > > > > it was applied. Conversation can be found here: > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.htm > > > > > > l > > > > > > > > > > Patches are based on latest linux-next (next-20180710) and are > > > > > ordered > > > > > in such way that they don't break R40 HDMI at any time. Because > > > > > of that > > > > > I suggest that whole series goes through drm-misc to preserve > > > > > that order. > > > > > > > > > > I also tested those patches on H3 to make sure it doesn't break > > > > > other > > > > > platforms. However, it would be nice to test for regressions > > > > > also on > > > > > older SoCs (with DE1). > > > > > > > > > > Best regards, > > > > > Jernej > > > > > > > > Applied all patches but the patch 10, thanks! > > > > Maxime > > > > > > It seems that you forgot to merge some patches: > > > > > > [PATCH v2 12/18] drm/sun4i: tcon: Add another way for matching > > > mixers with > > > tcon > > > [PATCH v2 13/18] drm/sun4i: tcon: Add support for R40 TCON > > > > > > Without them, R40 display pipeline can't work. > > > > > > Maybe they are in your spam folder? > > > > Thanks for telling me, I'm not quite sure what happened. > > > > I've applied them. > > BTW without them the board cannot boot because of dead loop in > sun4i_drv_probe(). Does it work for you now? > > > Sorry, > > Maxime > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/bridge: add preliminary driver for cadence dpi/dp bridge
From: Quentin Schulz
This patch finally adds the preliminary driver for Cadence MHDP DPI/DP bridge.
Changes made in the low level driver:
- functions for writing register and register bits are now public
- added functions for reading registers and link training
adjustment
Signed-off-by: Damian Kos
---
drivers/gpu/drm/bridge/Makefile |2 +-
drivers/gpu/drm/bridge/cdns-mhdp-common.c | 110 +-
drivers/gpu/drm/bridge/cdns-mhdp-common.h | 11 +
drivers/gpu/drm/bridge/cdns-mhdp.c| 1233 +
4 files changed, 1353 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c9b35f736a00..5e2a84734c7a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
-obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp-common.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp.o cdns-mhdp-common.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-common.c
b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
index 813319481220..5c426b04cf65 100644
--- a/drivers/gpu/drm/bridge/cdns-mhdp-common.c
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
@@ -191,7 +191,55 @@ static int cdns_mhdp_mailbox_send(struct cdns_mhdp_device
*mhdp, u8 module_id,
return 0;
}
-static int cdns_mhdp_reg_write(struct cdns_mhdp_device *mhdp, u16 addr, u32
val)
+int cdns_mhdp_reg_read(struct cdns_mhdp_device *mhdp, u32 addr, u32 *value)
+{
+ u8 msg[4], resp[8];
+ int ret;
+
+ if (addr == 0) {
+ ret = -EINVAL;
+ goto err_reg_read;
+ }
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+
+ ret = cdns_mhdp_mailbox_send(mhdp, MB_MODULE_ID_GENERAL,
+GENERAL_REGISTER_READ,
+sizeof(msg), msg);
+ if (ret)
+ goto err_reg_read;
+
+ ret = cdns_mhdp_mailbox_validate_receive(mhdp, MB_MODULE_ID_GENERAL,
+GENERAL_REGISTER_READ,
+sizeof(resp));
+ if (ret)
+ goto err_reg_read;
+
+ ret = cdns_mhdp_mailbox_read_receive(mhdp, resp, sizeof(resp));
+ if (ret)
+ goto err_reg_read;
+
+ /* Returned address value should be the same as requested */
+ if (memcmp(msg, resp, sizeof(msg))) {
+ ret = -EINVAL;
+ goto err_reg_read;
+ }
+
+ *value = (resp[4] << 24) | (resp[5] << 16) | (resp[6] << 8) | resp[7];
+
+err_reg_read:
+ if (ret) {
+ DRM_DEV_ERROR(mhdp->dev, "Failed to read register.\n");
+ *value = 0;
+ }
+
+ return ret;
+}
+
+int cdns_mhdp_reg_write(struct cdns_mhdp_device *mhdp, u16 addr, u32 val)
{
u8 msg[6];
@@ -205,7 +253,7 @@ static int cdns_mhdp_reg_write(struct cdns_mhdp_device
*mhdp, u16 addr, u32 val)
DPTX_WRITE_REGISTER, sizeof(msg), msg);
}
-static int cdns_mhdp_reg_write_bit(struct cdns_mhdp_device *mhdp, u16 addr,
+int cdns_mhdp_reg_write_bit(struct cdns_mhdp_device *mhdp, u16 addr,
u8 start_bit, u8 bits_no, u32 val)
{
u8 field[8];
@@ -979,3 +1027,61 @@ int cdns_mhdp_audio_config(struct cdns_mhdp_device *mhdp,
DRM_DEV_ERROR(mhdp->dev, "audio config failed: %d\n", ret);
return ret;
}
+
+int cdns_mhdp_adjust_lt(struct cdns_mhdp_device *mhdp,
+ u8 nlanes, u16 udelay, u8 *lanes_data, u8 *dpcd)
+{
+ u8 payload[7];
+ u8 hdr[5]; /* For DPCD read response header */
+ u32 addr;
+ u8 const nregs = 6; /* Registers 0x202-0x207 */
+ int ret;
+
+ if (nlanes != 4 && nlanes != 2 && nlanes != 1) {
+ DRM_DEV_ERROR(mhdp->dev, "invalid number of lanes: %d\n",
+ nlanes);
+ ret = -EINVAL;
+ goto err_adjust_lt;
+ }
+
+ payload[0] = nlanes;
+ payload[1] = (u8)(udelay >> 8);
+ payload[2] = (u8)udelay;
+
+ payload[3] = lanes_data[0];
+ if (nlanes > 1)
+ payload[4] = lanes_data[1];
+ if (nlanes > 2) {
+ payload[5] = lanes_data[2];
+ payload[6] = lanes_data[3];
+ }
+
+ ret = cdns_mhdp_mailbox_send(mhdp, MB_MODULE_ID_DP_TX,
+DPTX_ADJUST_LT,
+sizeof(payload), payload);
+ if (ret)
+ goto err_adjust_
[PATCH v4 3/4] drm/vkms: Add atomic_helper_check_plane_state
Call atomic_helper_check_plane_state to clip plane coordinates.
Signed-off-by: Haneen Mohammed
Reviewed-by: Sean Paul
---
Changes in v2:
- check for plane_state->visible since we can't handle a disabled
primary plane yet.
drivers/gpu/drm/vkms/vkms_plane.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index 5611e7cf5fc9..8191940844e5 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -8,6 +8,7 @@
#include "vkms_drv.h"
#include
+#include
#include
#include
@@ -25,6 +26,33 @@ static void vkms_primary_plane_update(struct drm_plane
*plane,
{
}
+static int vkms_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ int ret;
+
+ if (!state->fb | !state->crtc)
+ return 0;
+
+ crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ ret = drm_atomic_helper_check_plane_state(state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true);
+ if (ret != 0)
+ return ret;
+
+ /* for now primary plane must be visible and full screen */
+ if (!state->visible)
+ return -EINVAL;
+
+ return 0;
+}
+
static int vkms_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -58,6 +86,7 @@ static void vkms_cleanup_fb(struct drm_plane *plane,
static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
.atomic_update = vkms_primary_plane_update,
+ .atomic_check = vkms_plane_atomic_check,
.prepare_fb = vkms_prepare_fb,
.cleanup_fb = vkms_cleanup_fb,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring
于 2018年7月25日 GMT+08:00 上午1:20:42, "Jernej Škrabec" 写到: >Dne torek, 24. julij 2018 ob 18:04:49 CEST je Icenowy Zheng napisal(a): >> 在 2018-07-24二的 14:37 +0200，Maxime Ripard写道： >> >> > On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: >> > > Hi Maxime, >> > > >> > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard >> > > >> > > napisal(a): >> > > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: >> > > > > This series fixes several issues found in R40 HDMI patch >series >> > > > > after >> >> > > > > it was applied. Conversation can be found here: >> >http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.htm >> >> > > > > l >> > > > > >> > > > > Patches are based on latest linux-next (next-20180710) and >are >> > > > > ordered >> > > > > in such way that they don't break R40 HDMI at any time. >Because >> > > > > of that >> > > > > I suggest that whole series goes through drm-misc to preserve >> > > > > that order. >> > > > > >> > > > > I also tested those patches on H3 to make sure it doesn't >break >> > > > > other >> > > > > platforms. However, it would be nice to test for regressions >> > > > > also on >> > > > > older SoCs (with DE1). >> > > > > >> > > > > Best regards, >> > > > > Jernej >> > > > >> > > > Applied all patches but the patch 10, thanks! >> > > > Maxime >> > > >> > > It seems that you forgot to merge some patches: >> > > >> > > [PATCH v2 12/18] drm/sun4i: tcon: Add another way for matching >> > > mixers with >> > > tcon >> > > [PATCH v2 13/18] drm/sun4i: tcon: Add support for R40 TCON >> > > >> > > Without them, R40 display pipeline can't work. >> > > >> > > Maybe they are in your spam folder? >> > >> > Thanks for telling me, I'm not quite sure what happened. >> > >> > I've applied them. >> >> BTW without them the board cannot boot because of dead loop in >> sun4i_drv_probe(). > >Does it work for you now? Yes, although it cannot output 1920x1200 to my father's DVI monitor, but if it output a smaller resolution (e.g. 1024x600, by insert my WaveShare LCD first then the monitor) it works. > >> >> > Sorry, >> > Maxime >> > >> > ___ >> > linux-arm-kernel mailing list >> > linux-arm-ker...@lists.infradead.org >> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
https://bugzilla.kernel.org/show_bug.cgi?id=200645 Duncan (1i5t5.dun...@cox.net) changed: What|Removed |Added Regression|No |Yes --- Comment #3 from Duncan (1i5t5.dun...@cox.net) --- Confirmed it's this commit. Reverting it on top of... $ uname -r 4.18.0-rc6-00093-g9981b4fb8-dirty ... gets me a fully working multi-monitor setup once again. (The "dirty" is that patch, along with one that sets noatime as a mount default so I don't have to add it everywhere.) -- 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
[PATCH v4] backlight: pwm_bl: Fix uninitialized variable
Currently, if the DT does not define num-interpolated-steps then
num_steps is undefined and the interpolation code will deploy randomly.
Fix with a simple initialize to zero.
Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
brightness-levels")
Reported-by: Marcel Ziswiler
Signed-off-by: Daniel Thompson
Tested-by: Marcel Ziswiler
Reviewed-by: Douglas Anderson
Acked-by: Lee Jones
---
Notes:
v4:
- Remove line break from Fixes: and update the *-by:s
v3:
- Switch to the simplest fix and zero the uninitialized variable. git
grep indicates that ~25% of calls to of_property_read_u32() use this
pattern (pre-initialize optional properties with sane values and
ignore the return code).
v2:
- Simplify SoB chain (with Marcel's permission)
- Separate complex if statement and make other similar calls use same
return code checking approach
- Tidy up comment formatting and fix pre-existing grammar error
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 9ee4c1b735b2..bdfcc0a71db1 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -250,7 +250,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
struct device_node *node = dev->of_node;
unsigned int num_levels = 0;
unsigned int levels_count;
- unsigned int num_steps;
+ unsigned int num_steps = 0;
struct property *prop;
unsigned int *table;
int length;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #3 from Michel Dänzer (mic...@daenzer.net) --- (In reply to syboxez from comment #2) > dmesg: https://ghostbin.com/paste/7pyty > Xorg: https://ghostbin.com/paste/38zyy Thanks, but please attach files here directly instead of referencing an external pastebin site. -- 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
[PATCH v4] drm/bridge: tc358764: Add DSI to LVDS bridge driver
Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Changes in v4: - removed license blob, - ordered includes, - added error handling, - fixed reset GPIO handling, - added missing calls to the panel, - custom OF graph code replaced with helpers, - removed tc358764_poweroff from remove callback. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski [ a.ha...@samsung.com: v4 ] Signed-off-by: Andrzej Hajda --- Since Maciej cannot work soon on this patchset I took over his work. Regards Andrzej --- drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 492 ++ 3 files changed, 501 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c7997e2fd..f3da8a716833 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + help + Toshiba TC358764 DSI/LVDS bridge driver. + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d48ec20..bf7c0cecf227 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index ..0bb0d10bca47 --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,492 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0) +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */ +#define VP_VTIM2_VFP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM2_VACT(v) FLD_VAL(v, 10, 0) +#define VP_VFUEN 0x0464 /* Video Frame Timing Update Enable */ + +/* LVDS registers */ +#define LV_MX0003
[GIT PULL] exynos-drm-next
Hi Dave,
Two big cleanups to suspend/resume code and g2d driver including
trivial one.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 2d3bda7071a713fa4ecf9d0acb7faede6d59100a:
Merge tag 'exynos-drm-fixes-for-v4.18-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
exynos-drm-next (2018-07-24 15:28:44 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
tags/exynos-drm-next-for-v4.19
for you to fetch changes up to 3f2b78d630b46c7921cb415be35f686e5293c3a4:
drm/exynos/mixer: Remove unused local variable priv (2018-07-24 16:28:53
+0900)
Cleanups
- Change g2d driver to component based driver
. g2d driver was last customed sub driver so this patch series
changes it to component based driver, which also makes gem handling
to be more simplify.
- Cleanup of Exynos DRM suspend/resume
. Register exynos drm core suspend/resume functions
to prepare/complete callbacks of dev_pm_ops instead of suspend/resume
callbacks to ensure exynos_drm_suspend() is called before any suspend
callback from the real devices to avoid some issues on boards with
complex pipelines.
. Also Add pm_runtime_furce_suspend/resume as SYSTEM_SLEEP_PM_OPS
to ensure that resources of each devices will be released
for the system PM suspend/resume cycle.
- Remove local value not used.
Krzysztof Kozlowski (1):
drm/exynos/mixer: Remove unused local variable priv
Marek Szyprowski (6):
drm/exynos: g2d: Convert to driver component API
drm/exynos: gem: Simplify access to exynos GEM objects
drm/exynos: Use common exynos_drm_gem_get()/put() functions for GEM lookup
drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
drm/exynos: Suspend/resume display pipeline as early/late as possible
drm/exynos: Ensure suspended runtime PM state during system suspend
drivers/gpu/drm/exynos/Makefile | 2 +-
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +
drivers/gpu/drm/exynos/exynos_dp.c| 3 +
drivers/gpu/drm/exynos/exynos_drm_core.c | 119 --
drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 47 +---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +
drivers/gpu/drm/exynos/exynos_drm_fb.c| 10 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 300 ++
drivers/gpu/drm/exynos/exynos_drm_g2d.h | 11 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 58 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 24 +--
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +
drivers/gpu/drm/exynos/exynos_mixer.c | 4 +-
18 files changed, 179 insertions(+), 450 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_core.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: çå¤: [PATCH 4/4] drm/amdgpu: Add audio component support
On 2018å¹´07æ25æ¥ 13:46, Takashi Iwai wrote:
On Wed, 25 Jul 2018 07:38:37 +0200,
Qu, Jim wrote:
Jim: Just like Alex said, we want driver can get eld info when hotplug in new
device. amdgpu driver is a bit difference from radeon driver, it is not a
suitable place to call notify() function in *_audio_enable() , since they are
not in the hotplug process context like them in radeon driver, but the mode
setting.
IMO, the right place to call notify() function is also in the
amdgpu_connector__detect() in amdgpu_connector.c.
Hm, but by the modesetting, it actually enables / disables the audio
as well, no? If so, the notifier is exactly for that purpose. The
audio driver needs to know not only about the physical connection but
whether the audio can be actually driven.
That is, even if the monitor is connected, the audio won't come out if
the mode is off. That is equivalent with the unplugged state for the
audio driver.
The i915 driver deals with the notifier just like the above, so the
behavior is intentional.
thanks,
Takashi
I am afraid if device hotplug out, how is audio state if it follow up
eld info? Since the modesetting is never performed for the display which
is plugged out, so there is no notify() call on it.
Thanks
JimQu
With None-DC driver, the detect() of connectors will to be preformed in
drm_helper_hpd_irq_event() when there is device hotplug. However,
amdgpu_connector__detect() maybe need to be modified to fit your change.
Thanks
JimQu
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c | 97 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 +
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++
9 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2c7112ddfed4..fbe7216c5c56 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -193,6 +193,7 @@ config DRM_AMDGPU
select BACKLIGHT_LCD_SUPPORT
select INTERVAL_TREE
select CHASH
+ select SND_HDA_COMPONENT if SND_HDA_CORE
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index bfd332c95b61..9c26facddb17 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -52,7 +52,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_atomfirmware.o
\
amdgpu_queue_mgr.o amdgpu_vf_error.o amdgpu_sched.o amdgpu_debugfs.o \
- amdgpu_ids.o
+ amdgpu_ids.o amdgpu_audio.o
# add asic specific block
amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a59c07590cee..203d2584c989 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1957,5 +1957,9 @@ int amdgpu_dm_display_resume(struct amdgpu_device *adev );
static inline int amdgpu_dm_display_resume(struct amdgpu_device *adev) {
return 0; }
#endif
+int amdgpu_audio_component_init(struct amdgpu_device *adev);
+void amdgpu_audio_component_fini(struct amdgpu_device *adev);
+void amdgpu_audio_eld_notify(struct amdgpu_device *adev, int pin);
+
#include "amdgpu_object.h"
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
new file mode 100644
index ..39256e2f84b3
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: MIT
+
+#include
+#include "amdgpu.h"
+
+static int amdgpu_audio_component_get_eld(struct device *kdev, int port,
+ int pipe, bool *enabled,
+ unsigned char *buf, int max_bytes)
+{
+ struct drm_device *dev = dev_get_drvdata(kdev);
+ struct drm_encoder *encoder;
+ struct amdgpu_encoder *amdgpu_encoder;
+ struct amdgpu_encoder_atom_dig *dig;
+ struct drm_connector *connector;
+ int ret = 0;
+
+ *enabled = 0;
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ amdgpu_encoder = to_amdgpu_encoder(encoder);
+ dig = amdgpu_encoder->enc_priv;
+ if (!dig || !dig->afmt || !dig->afmt->enabled)
+
Re: [PATCH v4] backlight: pwm_bl: Fix uninitialized variable
On Wed, 25 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
> brightness-levels")
> Reported-by: Marcel Ziswiler
> Signed-off-by: Daniel Thompson
> Tested-by: Marcel Ziswiler
> Reviewed-by: Douglas Anderson
> Acked-by: Lee Jones
> ---
>
> Notes:
> v4:
> - Remove line break from Fixes: and update the *-by:s
>
> v3:
> - Switch to the simplest fix and zero the uninitialized variable. git
>grep indicates that ~25% of calls to of_property_read_u32() use this
>pattern (pre-initialize optional properties with sane values and
>ignore the return code).
>
> v2:
> - Simplify SoB chain (with Marcel's permission)
> - Separate complex if statement and make other similar calls use same
>return code checking approach
> - Tidy up comment formatting and fix pre-existing grammar error
>
> drivers/video/backlight/pwm_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"
On 24.07.2018 09:49, Inki Dae wrote:
> Hi,
>
> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>> When adding support for peripheral out bridges, the "bridge" name
>> becomes imprecise as it refers to a different device than the
>> "out_bridge".
> Could you give me more details? I'm afriad that I don't understand what you
> say.
The problem is that MIC is an input bridge and now we will have also
output bridge (Toshiba DSI/LVDS converter).
So we will have to distinguish them.
>
> And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement System)
> can be located between DECON and MIPI-DSI devices also.
> Therefore, having specific name isn't reasonable.
So probably in_bridge would be a better name. I will rephrase message
and bridge name.
Regars
Andrzej
>
> Thanks,
> Inki Dae
>
>> Signed-off-by: Maciej Purski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index eae44fd..9599e6b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -279,7 +279,7 @@ struct exynos_dsi {
>> struct list_head transfer_list;
>>
>> const struct exynos_dsi_driver_data *driver_data;
>> -struct device_node *bridge_node;
>> +struct device_node *mic_bridge_node;
>> };
>>
>> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>> if (ret < 0)
>> return ret;
>>
>> -dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>> +dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>
>> return 0;
>> }
>> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
>> device *master,
>> struct drm_encoder *encoder = dev_get_drvdata(dev);
>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>> struct drm_device *drm_dev = data;
>> -struct drm_bridge *bridge;
>> +struct drm_bridge *mic_bridge;
>> int ret;
>>
>> drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
>> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev,
>> struct device *master,
>> return ret;
>> }
>>
>> -if (dsi->bridge_node) {
>> -bridge = of_drm_find_bridge(dsi->bridge_node);
>> -if (bridge)
>> -drm_bridge_attach(encoder, bridge, NULL);
>> +if (dsi->mic_bridge_node) {
>> +mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>> +if (mic_bridge)
>> +drm_bridge_attach(encoder, mic_bridge, NULL);
>> }
>>
>> return mipi_dsi_host_register(&dsi->dsi_host);
>> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device
>> *pdev)
>> {
>> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>
>> -of_node_put(dsi->bridge_node);
>> +of_node_put(dsi->mic_bridge_node);
>>
>> pm_runtime_disable(&pdev->dev);
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"
2018년 07월 25일 17:11에 Andrzej Hajda 이(가) 쓴 글:
> On 24.07.2018 09:49, Inki Dae wrote:
>> Hi,
>>
>> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>>> When adding support for peripheral out bridges, the "bridge" name
>>> becomes imprecise as it refers to a different device than the
>>> "out_bridge".
>> Could you give me more details? I'm afriad that I don't understand what you
>> say.
>
> The problem is that MIC is an input bridge and now we will have also
> output bridge (Toshiba DSI/LVDS converter).
> So we will have to distinguish them.
>
>>
>> And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement
>> System) can be located between DECON and MIPI-DSI devices also.
>> Therefore, having specific name isn't reasonable.
>
> So probably in_bridge would be a better name. I will rephrase message
> and bridge name.
Good idea. :)
Thanks,
Inki Dae
>
> Regars
> Andrzej
>
>
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Maciej Purski
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index eae44fd..9599e6b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -279,7 +279,7 @@ struct exynos_dsi {
>>> struct list_head transfer_list;
>>>
>>> const struct exynos_dsi_driver_data *driver_data;
>>> - struct device_node *bridge_node;
>>> + struct device_node *mic_bridge_node;
>>> };
>>>
>>> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>>> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>>> if (ret < 0)
>>> return ret;
>>>
>>> - dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>> + dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>>
>>> return 0;
>>> }
>>> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
>>> device *master,
>>> struct drm_encoder *encoder = dev_get_drvdata(dev);
>>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>>> struct drm_device *drm_dev = data;
>>> - struct drm_bridge *bridge;
>>> + struct drm_bridge *mic_bridge;
>>> int ret;
>>>
>>> drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
>>> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev,
>>> struct device *master,
>>> return ret;
>>> }
>>>
>>> - if (dsi->bridge_node) {
>>> - bridge = of_drm_find_bridge(dsi->bridge_node);
>>> - if (bridge)
>>> - drm_bridge_attach(encoder, bridge, NULL);
>>> + if (dsi->mic_bridge_node) {
>>> + mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>>> + if (mic_bridge)
>>> + drm_bridge_attach(encoder, mic_bridge, NULL);
>>> }
>>>
>>> return mipi_dsi_host_register(&dsi->dsi_host);
>>> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device
>>> *pdev)
>>> {
>>> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>>
>>> - of_node_put(dsi->bridge_node);
>>> + of_node_put(dsi->mic_bridge_node);
>>>
>>> pm_runtime_disable(&pdev->dev);
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: fix BOE/HV070WSA-100 timings
Panel timings were taken from vendor code and are not fully correct - refresh
rate is about 50Hz instead of 60Hz. The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-simple.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index d5da58d5c9b1..a2226a3d2887 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -746,15 +746,15 @@ static const struct panel_desc avic_tm070ddh03 = {
};
static const struct drm_display_mode boe_hv070wsa_mode = {
- .clock = 40800,
+ .clock = 42105,
.hdisplay = 1024,
- .hsync_start = 1024 + 90,
- .hsync_end = 1024 + 90 + 90,
- .htotal = 1024 + 90 + 90 + 90,
+ .hsync_start = 1024 + 30,
+ .hsync_end = 1024 + 30 + 30,
+ .htotal = 1024 + 30 + 30 + 30,
.vdisplay = 600,
- .vsync_start = 600 + 3,
- .vsync_end = 600 + 3 + 4,
- .vtotal = 600 + 3 + 4 + 3,
+ .vsync_start = 600 + 10,
+ .vsync_end = 600 + 10 + 10,
+ .vtotal = 600 + 10 + 10 + 10,
.vrefresh = 60,
};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: y4T�TCH 4/4] drm/amdgpu: Add audio component support
On Wed, 25 Jul 2018 10:02:34 +0200, jimqu wrote: > > > > On 2018å¹´07æ25æ¥ 13:46, Takashi Iwai wrote: > > On Wed, 25 Jul 2018 07:38:37 +0200, > > Qu, Jim wrote: > >> Jim: Just like Alex said, we want driver can get eld info when hotplug in > >> new device. amdgpu driver is a bit difference from radeon driver, it is > >> not a suitable place to call notify() function in *_audio_enable() , since > >> they are not in the hotplug process context like them in radeon driver, > >> but the mode setting. > >> > >> IMO, the right place to call notify() function is also in the > >> amdgpu_connector__detect() in amdgpu_connector.c. > > Hm, but by the modesetting, it actually enables / disables the audio > > as well, no? If so, the notifier is exactly for that purpose. The > > audio driver needs to know not only about the physical connection but > > whether the audio can be actually driven. > > > > That is, even if the monitor is connected, the audio won't come out if > > the mode is off. That is equivalent with the unplugged state for the > > audio driver. > > > > The i915 driver deals with the notifier just like the above, so the > > behavior is intentional. > > > > > > thanks, > > > > Takashi > > I am afraid if device hotplug out, how is audio state if it follow up > eld info? Since the modesetting is never performed for the display > which is plugged out, so there is no notify() call on it. In principle, the HDMI audio just needs to follows the video state, and it doesn't need to care actual physical connections. As long as video can go out, it's fine, audio can, too. When video is disabled (even if connected), audio can't be used as well, so it must follow to off, too. The notifier is used to follow this video state change. Practically seen, the user-space shall switch off the video accordingly upon hot unplug, then the audio notifier is sent, and the audio gets off, too. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107367 --- Comment #1 from Gregor Münch --- Forgot to add: direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD Radeon HD 7900 Series (TAHITI, DRM 3.27.0, 4.18.0-rc1-amd-staging-drm-next-git, LLVM 7.0.0) (0x6798) Version: 18.2.0 Accelerated: yes Video memory: 3072MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.4 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI, DRM 3.27.0, 4.18.0-rc1-amd-staging-drm-next-git, LLVM 7.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel (git-6853862a58) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.0-devel (git-6853862a58) OpenGL shading language version string: 4.40 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.0-devel (git-6853862a58) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 I use latest linuxfirmware git to be able to use my Tahiti card with AMDGPU. -- 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 libdrm v2] tests/modetest: Add modetest_atomic tool
This is a modetest like tool but using atomic API.
Unlike modetest it becomes mandatory to specify a mode ("-s")
and a plane ("-P") to display a pattern on screen.
This version of modetest_atomic doesn't offer cursor support
("-C" argument has been removed).
Test the frame rate ("-v") it does a loop and swap between two
framebuffer for each active planes and not using pageflip event
like done in modetest.
Signed-off-by: Benjamin Gaignard
---
The code is based on modetest and keep most of it infrastructure
like arguments parsing, finding properties id from their name,
resources dumping or the general way of working.
It duplicates modetest code but adding compilation flags or
conditional tests everywhere in modetest would have made it
more complex and unreadable.
Creating modetest_atomic could allow to test atomic API without
need to use "big" frameworks like weston, drm_hwcomposer or igt
with all their dependencies.
kmscube could also be used to test atomic API but it need EGL.
It have been tested (only) on stm driver with one or two planes
actived.
change in version 2:
- make modetest_atomci compile with meson and Android
tests/modetest/Android.mk| 13 +
tests/modetest/Makefile.am | 13 +-
tests/modetest/Makefile.sources |7 +
tests/modetest/meson.build | 10 +
tests/modetest/modetest_atomic.c | 1546 ++
5 files changed, 1587 insertions(+), 2 deletions(-)
create mode 100644 tests/modetest/modetest_atomic.c
diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index c1a71fd9..0fe96c5a 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -12,3 +12,16 @@ LOCAL_STATIC_LIBRARIES := libdrm_util
include $(LIBDRM_COMMON_MK)
include $(BUILD_EXECUTABLE)
+
+include $(CLEAR_VARS)
+include $(LOCAL_PATH)/Makefile.sources
+
+LOCAL_SRC_FILES := $(MODETEST_ATOMIC_FILES)
+
+LOCAL_MODULE := modetest_atomic
+
+LOCAL_SHARED_LIBRARIES := libdrm
+LOCAL_STATIC_LIBRARIES := libdrm_util
+
+include $(LIBDRM_COMMON_MK)
+include $(BUILD_EXECUTABLE)
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 4b296c83..8f697bb3 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -10,10 +10,12 @@ AM_CFLAGS += \
if HAVE_INSTALL_TESTS
bin_PROGRAMS = \
- modetest
+ modetest \
+ modetest_atomic
else
noinst_PROGRAMS = \
- modetest
+ modetest \
+ modetest_atomic
endif
modetest_SOURCES = $(MODETEST_FILES)
@@ -22,3 +24,10 @@ modetest_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/tests/util/libutil.la \
$(CAIRO_LIBS)
+
+modetest_atomic_SOURCES = $(MODETEST_ATOMIC_FILES)
+
+modetest_atomic_LDADD = \
+ $(top_builddir)/libdrm.la \
+ $(top_builddir)/tests/util/libutil.la \
+ $(CAIRO_LIBS)
diff --git a/tests/modetest/Makefile.sources b/tests/modetest/Makefile.sources
index 399af0df..0a1df4c0 100644
--- a/tests/modetest/Makefile.sources
+++ b/tests/modetest/Makefile.sources
@@ -4,3 +4,10 @@ MODETEST_FILES := \
cursor.c \
cursor.h \
modetest.c
+
+MODETEST_ATOMIC_FILES := \
+ buffers.c \
+ buffers.h \
+ cursor.c \
+ cursor.h \
+ modetest_atomic.c
diff --git a/tests/modetest/meson.build b/tests/modetest/meson.build
index 2a081845..d1cda9e9 100644
--- a/tests/modetest/meson.build
+++ b/tests/modetest/meson.build
@@ -27,3 +27,13 @@ modetest = executable(
link_with : [libdrm, libutil],
install : with_install_tests,
)
+
+modetest_atomic = executable(
+ 'modetest_atomic',
+ files('buffers.c', 'cursor.c', 'modetest_atomic.c'),
+ c_args : [warn_c_args, '-Wno-pointer-arith'],
+ include_directories : [inc_root, inc_tests, inc_drm],
+ dependencies : [dep_threads, dep_cairo],
+ link_with : [libdrm, libutil],
+ install : with_install_tests,
+)
diff --git a/tests/modetest/modetest_atomic.c b/tests/modetest/modetest_atomic.c
new file mode 100644
index ..8c877860
--- /dev/null
+++ b/tests/modetest/modetest_atomic.c
@@ -0,0 +1,1546 @@
+/*
+ * DRM based mode setting test program
+ * Copyright 2008 Tungsten Graphics
+ * Jakob Bornecrantz
+ * Copyright 2008 Intel Corporation
+ * Jesse Barnes
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *
[Bug 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set
https://bugs.freedesktop.org/show_bug.cgi?id=106228 --- Comment #6 from jian-h...@endlessm.com --- Apply "[PATCH] drm/amdgpu: Read back max backlight value at boot" to Linux 4.18.0-rc6 kernel. I disable all of the brightness setting applications, including masking systemd-backlight service and than reboot. "cat /sys/class/backlight/amdgpu_bl0/brightness" before set brightness manually again and it reads back 255 (the maximum brightness). If I unmask systemd-backlight service and than reboot for test, "cat /sys/class/backlight/amdgpu_bl0/brightness" before set brightness manually again and it reads back the brightness which is saved before last reboot. -- 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 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set
https://bugs.freedesktop.org/show_bug.cgi?id=106228 --- Comment #7 from jian-h...@endlessm.com --- Applied both "[PATCH] drm/amdgpu: Read back max backlight value at boot" and "[PATCH] drm/amd/display: Implement backlight_ops.get_brightness" to Linux 4.18.0-rc6 kernel. I got the same behavior as previous comment. -- 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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 jian-h...@endlessm.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #37 from jian-h...@endlessm.com --- Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
On 20 July 2018 at 12:33, Benjamin Gaignard
wrote:
> This is a modetest like tool but using atomic API.
>
> With modetest_atomic it is mandatory to specify a mode ("-s")
> and a plane ("-P") to display a pattern on screen.
>
> "-v" does a loop swapping between two framebuffers for each
> active planes.
>
> modetest_atomic doesn't offer cursor support
>
> Signed-off-by: Benjamin Gaignard
> ---
>
> The code is based on modetest and keep most of it infrastructure
> like arguments parsing, finding properties id from their name,
> resources dumping or the general way of working.
> It duplicates modetest code but adding compilation flags or
> conditional tests everywhere in modetest would have made it
> more complex and unreadable.
>
> Creating modetest_atomic could allow to test atomic API without
> need to use "big" frameworks like weston, drm_hwcomposer or igt
> with all their dependencies.
> kmscube could also be used to test atomic API but it need EGL.
>
> It have been tested (only) on stm driver with one or two planes
> actived.
>
> tests/modetest/Makefile.am | 13 +-
> tests/modetest/Makefile.sources |7 +
> tests/modetest/modetest_atomic.c | 1546
> ++
Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new code.
I agree that modetest.c is getting kind of big and messy. How about
instead of duplicating it, we flesh out the legacy vs atomic codepaths
into helpers in separate files?
It will result in [c]leaner code, only one executable
installed/packaged and less build system changes.
What do you think?
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fb: fix lost console when the user unplugs a USB adapter
On Wednesday, July 04, 2018 05:31:19 PM Noralf Trønnes wrote:
>
> Den 03.07.2018 19.18, skrev Mikulas Patocka:
> >
> > On Tue, 3 Jul 2018, Bartlomiej Zolnierkiewicz wrote:
> >
> >> Hi,
> >>
> >> On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote:
> >>> I have a USB display adapter using the udlfb driver and I use it on an ARM
> >>> board that doesn't have any graphics card. When I plug the adapter in, the
> >>> console is properly displayed, however when I unplug and re-plug the
> >>> adapter, the console is not displayed and I can't access it until I reboot
> >>> the board.
> >>>
> >>> The reason is this:
> >>> When the adapter is unplugged, dlfb_usb_disconnect calls
> >>> unlink_framebuffer, then it waits until the reference count drops to zero
> >>> and then it deallocates the framebuffer. However, the console that is
> >>> attached to the framebuffer device keeps the reference count non-zero, so
> >>> the framebuffer device is never destroyed. When the USB adapter is plugged
> >>> again, it creates a new device /dev/fb1 and the console is not attached to
> >>> it.
> >>>
> >>> This patch fixes the bug by unbinding the console from unlink_framebuffer.
> >>> The code to unbind the console is moved from do_unregister_framebuffer to
> >>> a function unbind_console. When the console is unbound, the reference
> >>> count drops to zero and the udlfb driver frees the framebuffer. When the
> >>> adapter is plugged back, a new framebuffer is created and the console is
> >>> attached to it.
> >>>
> >>> Signed-off-by: Mikulas Patocka
> >>> Cc: sta...@vger.kernel.org
> >> After this change unbind_console() will be called twice in the standard
> >> framebuffer unregister path:
> >>
> >> - first time, directly by do_unregister_framebuffer()
> >>
> >> - second time, indirectly by
> >> do_unregister_framebuffer()->unlink_framebuffer()
> >>
> >> This doesn't look correctly.
> > unbind_console calls the FB_EVENT_FB_UNBIND notifier, FB_EVENT_FB_UNBIND
> > goes to the function fbcon_fb_unbind and fbcon_fb_unbind checks if the
> > console is bound to the framebuffer for which unbind is requested. So a
> > double call won't cause any trouble.
> >
> >> Also why can't udlfb just use unregister_framebuffer() like all other
> >> drivers (it uses unlink_framebuffer() and it is the only user of this
> >> helper)?
> > It uses unregister_framebuffer() - but - unregister_framebuffer() may only
> > be called when the open count of the framebuffer is zero.
>
> AFAIU calling unregister_framebuffer() with open fd's is just fine as
> long as fb_info with buffers stay intact. All it does is to remove the
> fbX from userspace. Cleanup can be done in fb_ops->fb_destroy.
>
> I have been working on generic fbdev emulation for DRM [1] and I did a
> test now to see what would happen if I did unbind the driver from the
> device. It worked as expected if I didn't have another fbdev present,
> but if there is an fb0 and I remove fb1 with a console on it, I would
> sometimes get crashes, often with a call to cursor_timer_handler() in
> the traceback.
>
> I think there's index mixup in fbcon_fb_unbind(), at least this change
> seems to solve the immediate problem:
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 5fb156bdcf4e..271b9b988b73 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3066,7 +3072,7 @@ static int fbcon_fb_unbind(int idx)
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> if (con2fb_map[i] != idx &&
> con2fb_map[i] != -1) {
> - new_idx = i;
> + new_idx = con2fb_map[i];
> break;
> }
> }
Looks fine, could you please submit this as a proper patch
(with S-o-b tag and patch description)? Thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107373] Screen recording stutters when SteamVR is running
https://bugs.freedesktop.org/show_bug.cgi?id=107373 Bug ID: 107373 Summary: Screen recording stutters when SteamVR is running Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: haa...@frickel.club QA Contact: dri-devel@lists.freedesktop.org Filed for radeonsi but the cause may very well be somewhere else. RX 480, with mesa git, linux 4.18 and drm-next-4.19-wip. Typically 60 fps screen recording works quite smoothly, but when SteamVR is running the produced video is stuttering badly. The actual rendering and displaying is still smooth, only the recorded video is affected. Example video: https://youtu.be/yU_SKilk0p8 That's my gstreamer pipeline I use for recording: gst-launch-1.0 -e ximagesrc display-name=$DISPLAY use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12,framerate=60/1 ! multiqueue ! vaapih265enc rate-control=cqp bitrate=2000 ! video/x-h265,stream-format=byte-stream ! h265parse ! multiqueue ! matroskamux name=muxer pulsesrc ! audio/x-raw,channels=2 ! multiqueue ! opusenc frame-size=40 complexity=6 ! multiqueue ! muxer. muxer. ! progressreport name=Rec_time ! filesink location=$HOME/foobar.mkv -- 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 libdrm] tests/modetest: Add modetest_atomic tool
2018-07-25 12:29 GMT+02:00 Emil Velikov :
> On 20 July 2018 at 12:33, Benjamin Gaignard
> wrote:
>> This is a modetest like tool but using atomic API.
>>
>> With modetest_atomic it is mandatory to specify a mode ("-s")
>> and a plane ("-P") to display a pattern on screen.
>>
>> "-v" does a loop swapping between two framebuffers for each
>> active planes.
>>
>> modetest_atomic doesn't offer cursor support
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>>
>> The code is based on modetest and keep most of it infrastructure
>> like arguments parsing, finding properties id from their name,
>> resources dumping or the general way of working.
>> It duplicates modetest code but adding compilation flags or
>> conditional tests everywhere in modetest would have made it
>> more complex and unreadable.
>>
>> Creating modetest_atomic could allow to test atomic API without
>> need to use "big" frameworks like weston, drm_hwcomposer or igt
>> with all their dependencies.
>> kmscube could also be used to test atomic API but it need EGL.
>>
>> It have been tested (only) on stm driver with one or two planes
>> actived.
>>
>> tests/modetest/Makefile.am | 13 +-
>> tests/modetest/Makefile.sources |7 +
>> tests/modetest/modetest_atomic.c | 1546
>> ++
>
> Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new code.
> I agree that modetest.c is getting kind of big and messy. How about
> instead of duplicating it, we flesh out the legacy vs atomic codepaths
> into helpers in separate files?
>
> It will result in [c]leaner code, only one executable
> installed/packaged and less build system changes.
>
> What do you think?
> Emil
It was my initial thought too: I have tried to add "-a" option to
enable atomic way
of working but their is small changes to do everywhere and that add
lot of conditional tests.
Make the changes for build system isn't that complicated (see in v2)
Regards,
Benjamin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus
On Monday 09 July 2018 02:37 PM, Archit Taneja wrote:
Add a section that describes dt-bindings for peripherals that support
MIPI DSI, but have a different bus as the primary control bus, or no
control bus at all. Add an example for a peripheral with a non-DSI
control bus.
Reviewed-by: Rob Herring
Reviewed-by: Boris Brezillon
Reviewed-by: Philippe Cornu
Reviewed-by: Sean Paul
Signed-off-by: Archit Taneja
queued to drm-misc-next.
Thanks,
Archit
---
.../devicetree/bindings/display/mipi-dsi-bus.txt | 71 +++---
1 file changed, 64 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 973c27273772..b7c5bf47403c 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is
connected to a DSI
host. Experience shows that this is true for the large majority of setups.
DSI host
-
+
In addition to the standard properties and those defined by the parent bus of
a DSI host, the following properties apply to a node representing a DSI host.
@@ -30,11 +30,16 @@ Required properties:
different value here. See below.
DSI peripheral
---
+==
-Peripherals are represented as child nodes of the DSI host's node. Properties
-described here apply to all DSI peripherals, but individual bindings may want
-to define additional, device-specific properties.
+Peripherals with DSI as control bus, or no control bus
+--
+
+Peripherals with the DSI bus as the primary control bus, or peripherals with
+no control bus but use the DSI bus to transmit pixel data are represented
+as child nodes of the DSI host's node. Properties described here apply to all
+DSI peripherals, but individual bindings may want to define additional,
+device-specific properties.
Required properties:
- reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +54,25 @@ case two alternative representations can be chosen:
property is the number of the first virtual channel and the second cell is
the number of consecutive virtual channels.
-Example
+Peripherals with a different control bus
+
+
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
+primary control bus, but are also connected to a DSI bus (mostly for the data
+path). Connections between such peripherals and a DSI host can be represented
+using the graph bindings [1], [2].
+
+[1] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+Examples
+
+- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
+ with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected to a
+ DSI host using of-graph bindings.
+
+1)
dsi-host {
...
@@ -67,6 +88,7 @@ Example
...
};
+2)
dsi-host {
...
@@ -82,6 +104,7 @@ Example
...
};
+3)
dsi-host {
...
@@ -96,3 +119,37 @@ Example
...
};
+
+4)
+ i2c-host {
+ ...
+
+ dsi-bridge@35 {
+ compatible = "...";
+ reg = <0x35>;
+
+ ports {
+ ...
+
+ port {
+ bridge_mipi_in: endpoint {
+ remote-endpoint =
<&host_mipi_out>;
+ };
+ };
+ };
+ };
+ };
+
+ dsi-host {
+ ...
+
+ ports {
+ ...
+
+ port {
+ host_mipi_out: endpoint {
+ remote-endpoint = <&bridge_mipi_in>;
+ };
+ };
+ };
+ };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Wednesday 11 July 2018 09:18 PM, Rob Herring wrote: On Mon, Jul 09, 2018 at 02:37:51PM +0530, Archit Taneja wrote: Add binding info for peripherals that support dual-channel DSI. Add corresponding optional bindings for DSI host controllers that may be configured in this mode. Add an example of an I2C controlled device operating in dual-channel DSI mode. Reviewed-by: Philippe Cornu Reviewed-by: Sean Paul Reviewed-by: Heiko Stuebner Signed-off-by: Archit Taneja --- .../devicetree/bindings/display/mipi-dsi-bus.txt | 80 ++ 1 file changed, 80 insertions(+) Reviewed-by: Rob Herring queued to drm-misc-next. Thanks, Archit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fb: fix lost console when the user unplugs a USB adapter
On Monday, July 09, 2018 10:29:40 PM Mikulas Patocka wrote: > > On Wed, 4 Jul 2018, Bartlomiej Zolnierkiewicz wrote: > > > On Tuesday, July 03, 2018 01:18:57 PM Mikulas Patocka wrote: > > > > > > On Tue, 3 Jul 2018, Bartlomiej Zolnierkiewicz wrote: > > > > > > > Hi, > > > > > > > > On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote: > > > > > I have a USB display adapter using the udlfb driver and I use it on > > > > > an ARM > > > > > board that doesn't have any graphics card. When I plug the adapter > > > > > in, the > > > > > console is properly displayed, however when I unplug and re-plug the > > > > > adapter, the console is not displayed and I can't access it until I > > > > > reboot > > > > > the board. > > > > > > > > > > The reason is this: > > > > > When the adapter is unplugged, dlfb_usb_disconnect calls > > > > > unlink_framebuffer, then it waits until the reference count drops to > > > > > zero > > > > > and then it deallocates the framebuffer. However, the console that is > > > > > attached to the framebuffer device keeps the reference count > > > > > non-zero, so > > > > > the framebuffer device is never destroyed. When the USB adapter is > > > > > plugged > > > > > again, it creates a new device /dev/fb1 and the console is not > > > > > attached to > > > > > it. > > > > > > > > > > This patch fixes the bug by unbinding the console from > > > > > unlink_framebuffer. > > > > > The code to unbind the console is moved from > > > > > do_unregister_framebuffer to > > > > > a function unbind_console. When the console is unbound, the reference > > > > > count drops to zero and the udlfb driver frees the framebuffer. When > > > > > the > > > > > adapter is plugged back, a new framebuffer is created and the console > > > > > is > > > > > attached to it. > > > > > > > > > > Signed-off-by: Mikulas Patocka > > > > > Cc: sta...@vger.kernel.org > > > > > > > > After this change unbind_console() will be called twice in the standard > > > > framebuffer unregister path: > > > > > > > > - first time, directly by do_unregister_framebuffer() > > > > > > > > - second time, indirectly by > > > > do_unregister_framebuffer()->unlink_framebuffer() > > > > > > > > This doesn't look correctly. > > > > > > unbind_console calls the FB_EVENT_FB_UNBIND notifier, FB_EVENT_FB_UNBIND > > > goes to the function fbcon_fb_unbind and fbcon_fb_unbind checks if the > > > console is bound to the framebuffer for which unbind is requested. So a > > > double call won't cause any trouble. > > > > Even if it works okay currently it is not a best design to send duplicate > > events - especially since this can be easily avoided (for non-udlfb users) > > by: > > > > - renaming "vanilla" unlink_framebuffer() to __unlink_framebuffer() > > > > - converting do_unregister_framebuffer() to use __unlink_framebuffer() > > > > - adding "new" unlink_framebuffer() that will also call unbind_console() > > > > > > Also why can't udlfb just use unregister_framebuffer() like all other > > > > drivers (it uses unlink_framebuffer() and it is the only user of this > > > > helper)? > > > > > > It uses unregister_framebuffer() - but - unregister_framebuffer() may > > > only > > > be called when the open count of the framebuffer is zero. So, the udlfb > > > driver waits until the open count drops to zero and then calls > > > unregister_framebuffer(). > > > > > > But the console subsystem keeps the framebuffer open - which means that > > > if > > > user use unplugs the USB adapter, the open count won't drop to zero > > > (because the console is bound to it) - which means that > > > unregister_framebuffer() will not be called. > > > > Is it a really the console subsystem and not the user-space keeping > > /dev/fb0 (with console binded to fb0) opened after the USB device > > vanishes? > > Yes - I unplugged the adapter without Xserver running and without any > other framebuffer application running - the console keeps it open. > > > After re-plugging the USB device /dev/fb0 stays and /dev/fb1 > > appears, right? > > The file /dev/fb0 is deleted (because dlfb_usb_disconnect calls > unlink_framebuffer), but it is kept in the kernel. When I re-plug the > adapter, /dev/fb1 is created but the console is still bound to /dev/fb0. > When the adapter is re-plugged, it shows just a green screen. > > > I also mean that unregister_framebuffer() should be called instead > > unlink_framebuffer(), not additionally some time later as it is done > > currently. > > Can unregister_framebuffer() be called when /dev/fb0 is open as a file > handle and/or mapped to some process? It should be OK. > > Moreover the dlfb <-> fb_info locking scheme seems to be reversed > > (+racy) as it is dlfb that should control lifetime of fb_info, then > > in dlfb_free() we should just call framebuffer_release() etc. > > How should in your opinion framebuffer destruction work? > > Should the driver count the number of users and call > unr
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
On 25 July 2018 at 12:27, Benjamin Gaignard
wrote:
> 2018-07-25 12:29 GMT+02:00 Emil Velikov :
>> On 20 July 2018 at 12:33, Benjamin Gaignard
>> wrote:
>>> This is a modetest like tool but using atomic API.
>>>
>>> With modetest_atomic it is mandatory to specify a mode ("-s")
>>> and a plane ("-P") to display a pattern on screen.
>>>
>>> "-v" does a loop swapping between two framebuffers for each
>>> active planes.
>>>
>>> modetest_atomic doesn't offer cursor support
>>>
>>> Signed-off-by: Benjamin Gaignard
>>> ---
>>>
>>> The code is based on modetest and keep most of it infrastructure
>>> like arguments parsing, finding properties id from their name,
>>> resources dumping or the general way of working.
>>> It duplicates modetest code but adding compilation flags or
>>> conditional tests everywhere in modetest would have made it
>>> more complex and unreadable.
>>>
>>> Creating modetest_atomic could allow to test atomic API without
>>> need to use "big" frameworks like weston, drm_hwcomposer or igt
>>> with all their dependencies.
>>> kmscube could also be used to test atomic API but it need EGL.
>>>
>>> It have been tested (only) on stm driver with one or two planes
>>> actived.
>>>
>>> tests/modetest/Makefile.am | 13 +-
>>> tests/modetest/Makefile.sources |7 +
>>> tests/modetest/modetest_atomic.c | 1546
>>> ++
>>
>> Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new code.
>> I agree that modetest.c is getting kind of big and messy. How about
>> instead of duplicating it, we flesh out the legacy vs atomic codepaths
>> into helpers in separate files?
>>
>> It will result in [c]leaner code, only one executable
>> installed/packaged and less build system changes.
>>
>> What do you think?
>> Emil
>
> It was my initial thought too: I have tried to add "-a" option to
> enable atomic way
> of working but their is small changes to do everywhere and that add
> lot of conditional tests.
Can you please try beating something into shape? It's fairly hard to
judge without anything to look at.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-msm tree
On Mon, Jul 23, 2018 at 12:50 AM, Stephen Rothwell
wrote:
> Hi Rob,
>
> [Dave, this will presumably soon turn up in the drm tree]
>
> After merging the drm-msm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c: In function 'dpu_plane_destroy':
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1483:3: error: too few arguments to
> function 'drm_plane_helper_disable'
>drm_plane_helper_disable(plane);
>^~~~
> In file included from drivers/gpu/drm/msm/msm_drv.h:43:0,
> from drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:24:
> include/drm/drm_plane_helper.h:72:5: note: declared here
> int drm_plane_helper_disable(struct drm_plane *plane,
> ^~~~
>
> Caused by commit
>
> drm_plane_helper_disable ("drm/msm: Add SDM845 DPU support")
>
> interacting with commit
>
> 070473bcf703 ("drm: add missing ctx argument to plane transitional helpers")
>
> from the drm tree.
>
> I have added this merge fix patch.
This looks like the correct fix. I'll rebase my msm-next branch to
correct this and the other merge conflict..
BR,
-R
>
> From: Stephen Rothwell
> Date: Mon, 23 Jul 2018 12:47:04 +1000
> Subject: [PATCH] drm: msm: merge fix for drm_plane_helper_disable() API change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index d3d7ebf0c394..b640e39ebaca 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -1480,7 +1480,7 @@ static void dpu_plane_destroy(struct drm_plane *plane)
>
> mutex_destroy(&pdpu->lock);
>
> - drm_plane_helper_disable(plane);
> + drm_plane_helper_disable(plane, NULL);
>
> /* this will destroy the states as well */
> drm_plane_cleanup(plane);
> --
> 2.18.0
>
> --
> Cheers,
> Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107367 --- Comment #2 from Christian König --- Well that is more than just a bit strange. Do you have an error message in dmesg that the entity was killed? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Fix the "no scaling" case on multi-planar YUV formats
When there's no scaling requested ->is_unity should be true no matter
the format.
Also, when no scaling is requested and we have a multi-planar YUV
format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only
set ->x_scaling[0] to VC4_SCALING_PPF.
Doing this fixes an hardly visible artifact (seen when using modetest
and a rather big overlay plane in YUV420).
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_plane.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index cfb50fedfa2b..a3275fa66b7b 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -297,6 +297,9 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
vc4_state->crtc_h);
+ vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
+ vc4_state->y_scaling[0] == VC4_SCALING_NONE);
+
if (num_planes > 1) {
vc4_state->is_yuv = true;
@@ -312,24 +315,17 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_get_scaling_mode(vc4_state->src_h[1],
vc4_state->crtc_h);
- /* YUV conversion requires that scaling be enabled,
-* even on a plane that's otherwise 1:1. Choose TPZ
-* for simplicity.
+ /* YUV conversion requires that horizontal scaling be enabled,
+* even on a plane that's otherwise 1:1. Looks like only PPF
+* works in that case, so let's pick that one.
*/
- if (vc4_state->x_scaling[0] == VC4_SCALING_NONE)
- vc4_state->x_scaling[0] = VC4_SCALING_TPZ;
- if (vc4_state->y_scaling[0] == VC4_SCALING_NONE)
- vc4_state->y_scaling[0] = VC4_SCALING_TPZ;
+ if (vc4_state->is_unity)
+ vc4_state->x_scaling[0] = VC4_SCALING_PPF;
} else {
vc4_state->x_scaling[1] = VC4_SCALING_NONE;
vc4_state->y_scaling[1] = VC4_SCALING_NONE;
}
- vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
- vc4_state->y_scaling[0] == VC4_SCALING_NONE &&
- vc4_state->x_scaling[1] == VC4_SCALING_NONE &&
- vc4_state->y_scaling[1] == VC4_SCALING_NONE);
-
/* No configuring scaling on the cursor plane, since it gets
non-vblank-synced updates, and scaling requires requires
LBM changes which have to be vblank-synced.
@@ -672,7 +668,10 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_dlist_write(vc4_state, SCALER_CSC2_ITR_R_601_5);
}
- if (!vc4_state->is_unity) {
+ if (vc4_state->x_scaling[0] != VC4_SCALING_NONE ||
+ vc4_state->x_scaling[1] != VC4_SCALING_NONE ||
+ vc4_state->y_scaling[0] != VC4_SCALING_NONE ||
+ vc4_state->y_scaling[1] != VC4_SCALING_NONE) {
/* LBM Base Address. */
if (vc4_state->y_scaling[0] != VC4_SCALING_NONE ||
vc4_state->y_scaling[1] != VC4_SCALING_NONE) {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
2018-07-25 14:05 GMT+02:00 Emil Velikov :
> On 25 July 2018 at 12:27, Benjamin Gaignard
> wrote:
>> 2018-07-25 12:29 GMT+02:00 Emil Velikov :
>>> On 20 July 2018 at 12:33, Benjamin Gaignard
>>> wrote:
This is a modetest like tool but using atomic API.
With modetest_atomic it is mandatory to specify a mode ("-s")
and a plane ("-P") to display a pattern on screen.
"-v" does a loop swapping between two framebuffers for each
active planes.
modetest_atomic doesn't offer cursor support
Signed-off-by: Benjamin Gaignard
---
The code is based on modetest and keep most of it infrastructure
like arguments parsing, finding properties id from their name,
resources dumping or the general way of working.
It duplicates modetest code but adding compilation flags or
conditional tests everywhere in modetest would have made it
more complex and unreadable.
Creating modetest_atomic could allow to test atomic API without
need to use "big" frameworks like weston, drm_hwcomposer or igt
with all their dependencies.
kmscube could also be used to test atomic API but it need EGL.
It have been tested (only) on stm driver with one or two planes
actived.
tests/modetest/Makefile.am | 13 +-
tests/modetest/Makefile.sources |7 +
tests/modetest/modetest_atomic.c | 1546
++
>>>
>>> Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new
>>> code.
>>> I agree that modetest.c is getting kind of big and messy. How about
>>> instead of duplicating it, we flesh out the legacy vs atomic codepaths
>>> into helpers in separate files?
>>>
>>> It will result in [c]leaner code, only one executable
>>> installed/packaged and less build system changes.
>>>
>>> What do you think?
>>> Emil
>>
>> It was my initial thought too: I have tried to add "-a" option to
>> enable atomic way
>> of working but their is small changes to do everywhere and that add
>> lot of conditional tests.
> Can you please try beating something into shape? It's fairly hard to
> judge without anything to look at.
After dump_resource code in main function all the logic is different
between the two
modetest because, with atomic you to build a request and commit it
while, with legacy API,
you could set mode and after set a plane.
In addition with atomic version you have set a mode and a plane to be
able to display something.
That explain why the end of main function is completely different.
Another example in the set_mode function: in legacy API you have
create a FB and reference/use it
with calls to bo_create, drmModeAddFB2 and drmModeSetCrtc while for
atomic you have to set
properties on connectors, create and set a blob for the mode before
active the crct.
The same diff exist for set_plane.
I can add big if/else blocks but I do think that will make the code
more readable.
>
> Thanks
> Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #14 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to mikita.lip...@amd.com from comment #10) > Johannes, > My patch wasn't merged into DRM, but Daniel Vetter proposed another patch > that might remove legacy code that causes the issue. Could you remove my > patch from your tree and apply the following patch: > > https://patchwork.freedesktop.org/patch/230355/ > > Could you please if it fixes the Kasan issue for you, thanks. Doesn't avoid the use-after-free. Tested with the patch on top of 4.18-rc6. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
On 25 July 2018 at 13:37, Benjamin Gaignard
wrote:
> 2018-07-25 14:05 GMT+02:00 Emil Velikov :
>> On 25 July 2018 at 12:27, Benjamin Gaignard
>> wrote:
>>> 2018-07-25 12:29 GMT+02:00 Emil Velikov :
On 20 July 2018 at 12:33, Benjamin Gaignard
wrote:
> This is a modetest like tool but using atomic API.
>
> With modetest_atomic it is mandatory to specify a mode ("-s")
> and a plane ("-P") to display a pattern on screen.
>
> "-v" does a loop swapping between two framebuffers for each
> active planes.
>
> modetest_atomic doesn't offer cursor support
>
> Signed-off-by: Benjamin Gaignard
> ---
>
> The code is based on modetest and keep most of it infrastructure
> like arguments parsing, finding properties id from their name,
> resources dumping or the general way of working.
> It duplicates modetest code but adding compilation flags or
> conditional tests everywhere in modetest would have made it
> more complex and unreadable.
>
> Creating modetest_atomic could allow to test atomic API without
> need to use "big" frameworks like weston, drm_hwcomposer or igt
> with all their dependencies.
> kmscube could also be used to test atomic API but it need EGL.
>
> It have been tested (only) on stm driver with one or two planes
> actived.
>
> tests/modetest/Makefile.am | 13 +-
> tests/modetest/Makefile.sources |7 +
> tests/modetest/modetest_atomic.c | 1546
> ++
Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new
code.
I agree that modetest.c is getting kind of big and messy. How about
instead of duplicating it, we flesh out the legacy vs atomic codepaths
into helpers in separate files?
It will result in [c]leaner code, only one executable
installed/packaged and less build system changes.
What do you think?
Emil
>>>
>>> It was my initial thought too: I have tried to add "-a" option to
>>> enable atomic way
>>> of working but their is small changes to do everywhere and that add
>>> lot of conditional tests.
>> Can you please try beating something into shape? It's fairly hard to
>> judge without anything to look at.
>
> After dump_resource code in main function all the logic is different
> between the two
> modetest because, with atomic you to build a request and commit it
> while, with legacy API,
> you could set mode and after set a plane.
> In addition with atomic version you have set a mode and a plane to be
> able to display something.
> That explain why the end of main function is completely different.
>
> Another example in the set_mode function: in legacy API you have
> create a FB and reference/use it
> with calls to bo_create, drmModeAddFB2 and drmModeSetCrtc while for
> atomic you have to set
> properties on connectors, create and set a blob for the mode before
> active the crct.
> The same diff exist for set_plane.
>
> I can add big if/else blocks but I do think that will make the code
> more readable.
Guessing you meant "...I do not think..."
What is the blocker of moving the atomic specifics into a few functions?
As said before legacy.c and atomic.c would be great.
That will about 5(?) cases of
if (atomic)
atomic_foo(...)
else
legacy_foo(...)
I can see that 5 (10 even) cases of if (atomic) atomic_foo(...) else
legacy_foo(...) can be fiddly. Yet it fades in the context of 1.5kloc.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/vkms: Use new return type vm_fault_t
Hi,
Thanks for the patch,
I reviewed and tested it; everything is fine. I only suggest removing
the "gpu" part from the patch title (i.e., "drm/vkms: Use new return
type vm_fault_t").
On 07/23, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
> drivers/gpu/drm/vkms/vkms_gem.c | 5 ++---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 07be29f..d5d04a8 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -65,7 +65,7 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
> *dev,
> u32 *handle,
> u64 size);
>
> -int vkms_gem_fault(struct vm_fault *vmf);
> +vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
>
> int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
>struct drm_mode_create_dumb *args);
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index c7e3836..62e05dc 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -43,14 +43,14 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
> kfree(gem);
> }
>
> -int vkms_gem_fault(struct vm_fault *vmf)
> +vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct vkms_gem_object *obj = vma->vm_private_data;
> unsigned long vaddr = vmf->address;
> pgoff_t page_offset;
> loff_t num_pages;
> - int ret;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
> @@ -58,7 +58,6 @@ int vkms_gem_fault(struct vm_fault *vmf)
> if (page_offset > num_pages)
> return VM_FAULT_SIGBUS;
>
> - ret = -ENOENT;
> mutex_lock(&obj->pages_lock);
> if (obj->pages) {
> get_page(obj->pages[page_offset]);
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107278] Raven: pci_pm_resume takes over 1 second
https://bugs.freedesktop.org/show_bug.cgi?id=107278 Paul Menzel changed: What|Removed |Added Depends on||107375 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=107375 [Bug 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms -- 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 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107375
Bug ID: 107375
Summary: Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: pmenzel+bugs.freedesk...@molgen.mpg.de
Created attachment 140810
--> https://bugs.freedesktop.org/attachment.cgi?id=140810&action=edit
HTML output of `sudo ./sleepgraph.py -config config/suspend-callgraph.cfg`
(devicelist: amdgpu, maxdepth: 12)
Profiling the suspend and resume time [1] on a MSI B350M MORTAR (MS-7A37) with
AMD Ryzen 3 2200G with Radeon Vega Graphics with Linux 4.18-rc6+ and
amd-staging-drm-next [2], `pci_pm_suspend()` takes over one second, which is
too long [3], cf. bug 107278 [3].
The majority of that, 750 ms, is spent in `amdgpu_device_ip_resume_phase2()`.
• amdgpu_device_ip_resume_phase2 [amdgpu] (747.134 ms @ 97.889371)
• psp_resume [amdgpu] (673.370 ms @ 97.889371)
[…]
• psp_hw_start [amdgpu] (88.577 ms @ 97.889379)
[…]
• psp_np_fw_load [amdgpu] (584.783 ms @ 97.977957)
[…]
• dm_resume [amdgpu] (44.992 ms @ 98.567232)
[…]
• dc_link_detect [amdgpu] (17.777 ms @ 98.568212)
(EDID read takes 8 ms?)
[…]
• drm_atomic_helper_resume (25.139 ms @ 98.587030)
[…]
[…]
In the PSP code the problem is `psp_cmd_submit_buf()`, which takes from 45 ms
to 141 ms. Something is wrong there.
```
static int
psp_cmd_submit_buf(struct psp_context *psp,
struct amdgpu_firmware_info *ucode,
struct psp_gfx_cmd_resp *cmd, uint64_t fence_mc_addr,
int index)
{
int ret;
memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE);
memcpy(psp->cmd_buf_mem, cmd, sizeof(struct psp_gfx_cmd_resp));
ret = psp_cmd_submit(psp, ucode, psp->cmd_buf_mc_addr,
fence_mc_addr, index);
while (*((unsigned int *)psp->fence_buf) != index) {
msleep(1);
}
return ret;
}
```
Also, I wonder why the sleep in the trace is 3 ms instead of 1 ms like in the
code.
[1]: https://01.org/suspendresume
[2]: https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
[3]: https://bugs.freedesktop.org/show_bug.cgi?id=107278
--
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 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107375 Paul Menzel changed: What|Removed |Added Blocks||107278 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=107278 [Bug 107278] Raven: pci_pm_resume takes over 1 second -- 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 00/21] USB DisplayLink patches
On Tuesday, June 05, 2018 11:34:42 AM Mikulas Patocka wrote: > > On Tue, 5 Jun 2018, Alexey Brodkin wrote: > > > Hi Mikulas, > > > > On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote: > > > Hi > > > > > > Here I'm sending bug fixes and performance improvements for the USB > > > DisplayLink framebuffer and modesetting drivers for this merge window. > > > > For such a long series it would be very nice to post a link to your git > > tree so people may play with your changes easily. > > > > Could you please prepare one? > > > > -Alexey > > I don't use git to manage my patches, I use quilt. > > I uploaded the patches from quilt here: > http://people.redhat.com/~mpatocka/patches/kernel/udl/series.html I've queued fbdev ones for 4.19 (w/ some minor fixes), thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107376] Raven: `flush_delayed_work()` takes 500 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107376 Bug ID: 107376 Summary: Raven: `flush_delayed_work()` takes 500 ms Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: pmenzel+bugs.freedesk...@molgen.mpg.de Created attachment 140811 --> https://bugs.freedesktop.org/attachment.cgi?id=140811&action=edit HTML output of `sudo ./sleepgraph.py -config config/suspend-callgraph.cfg` (devicelist: amdgpu, maxdepth: 12) Created attachment 140810 [details] HTML output of `sudo ./sleepgraph.py -config config/suspend-callgraph.cfg` (devicelist: amdgpu, maxdepth: 12) Profiling the suspend and resume time [1] on a MSI B350M MORTAR (MS-7A37) with AMD Ryzen 3 2200G with Radeon Vega Graphics with Linux 4.18-rc6+ and amd-staging-drm-next [2], `pci_pm_suspend()` takes over one second, which is too long [3], cf. bug 107278 [3]. This is spent in `amdgpu_device_ip_resume_phase2()`, where 505 ms are spent in `flush_delayed_work()`. • flush_delayed_work (505.026 ms @ 98.640854) […] • flush_work (505.017 ms @ 98.640863) […] • wait_for_completion (504.985 ms @ 98.640894) […] •schedule_timeout (504.963 ms @ 98.640914) […] • schedule (504.963 ms @ 98.640914) [1]: https://01.org/suspendresume [2]: https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next [3]: https://bugs.freedesktop.org/show_bug.cgi?id=107278 -- 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 107278] Raven: pci_pm_resume takes over 1 second
https://bugs.freedesktop.org/show_bug.cgi?id=107278 Paul Menzel changed: What|Removed |Added Depends on||107376 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=107376 [Bug 107376] Raven: `flush_delayed_work()` takes 500 ms -- 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 107376] Raven: `flush_delayed_work()` takes 500 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107376 Paul Menzel changed: What|Removed |Added Blocks||107278 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=107278 [Bug 107278] Raven: pci_pm_resume takes over 1 second -- 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 libdrm v3] tests/modetest: Add atomic support
If "-a" option is set this make modetest use atomic API instead
of legacy API.
Test the frame rate ("-v") it does a loop and swap between two
framebuffer for each active planes.
Signed-off-by: Benjamin Gaignard
---
version 3:
- merge atomic code into modetest itself
- do not change build systems
version 2 :
- make modetest_atomic compile with meson and Android
version 1:
- add dedicated modetest_atomic tool to test atomic API
tests/modetest/modetest.c | 349 ++
1 file changed, 321 insertions(+), 28 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 62957d84..975dcbcd 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -119,6 +119,9 @@ struct device {
struct bo *bo;
struct bo *cursor_bo;
} mode;
+
+ int use_atomic;
+ drmModeAtomicReq *req;
};
static inline int64_t U642I64(uint64_t val)
@@ -805,7 +808,9 @@ struct plane_arg {
uint32_t w, h;
double scale;
unsigned int fb_id;
+ unsigned int old_fb_id;
struct bo *bo;
+ struct bo *old_bo;
char format_str[5]; /* need to leave room for terminating \0 */
unsigned int fourcc;
};
@@ -999,8 +1004,12 @@ static void set_property(struct device *dev, struct
property_arg *p)
p->prop_id = props->props[i];
- ret = drmModeObjectSetProperty(dev->fd, p->obj_id, p->obj_type,
- p->prop_id, p->value);
+ if (!dev->use_atomic)
+ ret = drmModeObjectSetProperty(dev->fd, p->obj_id, p->obj_type,
+
p->prop_id, p->value);
+ else
+ ret = drmModeAtomicAddProperty(dev->req, p->obj_id, p->prop_id,
p->value);
+
if (ret < 0)
fprintf(stderr, "failed to set %s %i property %s to %" PRIu64
": %s\n",
obj_type, p->obj_id, p->name, p->value,
strerror(errno));
@@ -1049,6 +1058,94 @@ static bool format_support(const drmModePlanePtr ovr,
uint32_t fmt)
return false;
}
+static void add_property(struct device *dev, uint32_t obj_id,
+ const char *name, uint64_t value)
+{
+ struct property_arg p;
+
+ p.obj_id = obj_id;
+ strcpy(p.name, name);
+ p.value = value;
+
+ set_property(dev, &p);
+}
+
+static int atomic_set_plane(struct device *dev, struct plane_arg *p,
+ int pattern, bool
update)
+{
+ uint32_t handles[4] = {0}, pitches[4] = {0}, offsets[4] = {0};
+ struct bo *plane_bo;
+ int crtc_x, crtc_y, crtc_w, crtc_h;
+ struct crtc *crtc = NULL;
+ unsigned int i;
+ unsigned int old_fb_id;
+
+ /* Find an unused plane which can be connected to our CRTC. Find the
+* CRTC index first, then iterate over available planes.
+*/
+ for (i = 0; i < (unsigned int)dev->resources->res->count_crtcs; i++) {
+ if (p->crtc_id == dev->resources->res->crtcs[i]) {
+ crtc = &dev->resources->crtcs[i];
+ break;
+ }
+ }
+
+ if (!crtc) {
+ fprintf(stderr, "CRTC %u not found\n", p->crtc_id);
+ return -1;
+ }
+
+ if (!update)
+ fprintf(stderr, "testing %dx%d@%s on plane %u, crtc %u\n",
+ p->w, p->h, p->format_str, p->plane_id, p->crtc_id);
+
+ plane_bo = p->old_bo;
+ p->old_bo = p->bo;
+
+ if (!plane_bo) {
+ plane_bo = bo_create(dev->fd, p->fourcc, p->w, p->h,
+handles, pitches, offsets, pattern);
+
+ if (plane_bo == NULL)
+ return -1;
+
+ if (drmModeAddFB2(dev->fd, p->w, p->h, p->fourcc,
+ handles, pitches, offsets, &p->fb_id, 0)) {
+ fprintf(stderr, "failed to add fb: %s\n",
strerror(errno));
+ return -1;
+ }
+ }
+
+ p->bo = plane_bo;
+
+ old_fb_id = p->fb_id;
+ p->old_fb_id = old_fb_id;
+
+ crtc_w = p->w * p->scale;
+ crtc_h = p->h * p->scale;
+ if (!p->has_position) {
+ /* Default to the middle of the screen */
+ crtc_x = (crtc->mode->hdisplay - crtc_w) / 2;
+ crtc_y = (crtc->mode->vdisplay - crtc_h) / 2;
+ } else {
+ crtc_x = p->x;
+ crtc_y = p->y;
+ }
+
+ add_property(dev, p->plane_id, "FB_ID", p->fb_id);
+ add_property(dev, p->plane_id, "CRTC_ID", p->crtc_id);
+ add_property(dev, p->plane_id, "SRC_X", 0);
+ add_property(dev, p->plane_id, "SRC_Y", 0);
+ add_property(dev, p->plane_id, "SRC_W", p->w << 16);
+ add_property(dev, p->plane_id, "SRC_H", p->h << 16);
+ add_property(dev, p->plane_id, "C
[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
https://bugzilla.kernel.org/show_bug.cgi?id=200645 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Fixed. See: https://bugs.freedesktop.org/show_bug.cgi?id=106959 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/19] drm: add msm compressed format modifiers
Hi,
On 07/20/2018 11:42 PM, Sean Paul wrote:
> From: Jeykumar Sankaran
>
> Qualcomm Snapdragon chipsets uses compressed format
> to optimize BW across multiple IP's. This change adds
> needed modifier support in drm for a simple 4x4 tile
> based compressed variants of base formats.
>
> Changes in v3:
> - Removed duplicate entry for DRM_FORMAT_MOD_QCOM_COMPRESSED (Rob Clark)
>
> Signed-off-by: Jeykumar Sankaran
> Signed-off-by: Sean Paul
> ---
> include/uapi/drm/drm_fourcc.h | 37 +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..1c9a6bf8c81e 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -298,6 +298,43 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILEfourcc_mod_code(SAMSUNG, 1)
>
> +/*
> + * Qualcomm Compressed Format
> + *
> + * Refers to a compressed variant of the base format that is compressed.
> + * Implementation may be platform and base-format specific.
> + *
> + * Each macrotile consists of m x n (mostly 4 x 4) tiles.
> + * Pixel data pitch/stride is aligned with macrotile width.
> + * Pixel data height is aligned with macrotile height.
> + * Entire pixel data buffer is aligned with 4k(bytes).
> + */
> +#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
> +
> +/*
> + * QTI DX Format
> + *
> + * Refers to a DX variant of the base format.
> + * Implementation may be platform and base-format specific.
> + */
> +#define DRM_FORMAT_MOD_QCOM_DX fourcc_mod_code(QCOM, 0x2)
What DX stands for?
--
regards,
Stan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||107369 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=107369 [Bug 107369] "volatile" in OpenCL code not recognized by POLARIS10 and KABINI -- 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 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #15 from mikita.lip...@amd.com (mikita.lip...@amd.com) --- Lyude Paul fixed this issue, please try his patch: https://patchwork.kernel.org/patch/10480569/ Thanks -- 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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #38 from Alex Deucher --- (In reply to jian-hong from comment #36) > Created attachment 140806 [details] > dmesg of 4.18.0-rc6 > > Tested with Linux 4.18.0-rc6 kernel. > It seems the amdgpu module could be loaded correctly. I tried over 20 times. Could you bisect to see what change fixed it? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107375 --- Comment #1 from Michel Dänzer --- Created attachment 140814 --> https://bugs.freedesktop.org/attachment.cgi?id=140814&action=edit Do posting read in psp_v10_0_cmd_submit Does this patch help by any chance? (In reply to Paul Menzel from comment #0) > Also, I wonder why the sleep in the trace is 3 ms instead of 1 ms like in > the code. Maybe your kernel is configured with CONFIG_HZ=300? Anyway, it doesn't really matter, as it's waiting for the PSP to finish processing the command. -- 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 107377] [CI][DRMTIP] igt@gem_gpgpu_fill - fail - Test assertion failure function gen7_render_flush, Failed assertion: ret == 0, Last errno: 5, Input/output error
https://bugs.freedesktop.org/show_bug.cgi?id=107377 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Resolution|--- |FIXED Status|NEW |RESOLVED Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #1 from Chris Wilson --- The gpu was never the same after the hang in kms_draw_crc, and it ended up being declared wedged when a reset failed shortly after in perf. commit 3806547319038879f1c7939671b9e35937f0cae6 Author: Chris Wilson Date: Thu Jul 12 16:22:51 2018 +0100 igt/gem_gpgpu_fill: Check for GEM before use As we need GEM and the GPU to do a GPGPU fill, we should check that it is operable before using -- skipping rather than failing when the device is wedged. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä -- 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 0/5] drm/vc4: Fix negative X/Y positioning of planes
Hello Eric, This is an attempt at fixing support for negative X/Y positioning of various FB formats. I kept you as the author since I started from your initial work and fixed a few things + split the changes in several commits. Let me know if that's a problem, and I change the author. This series has been tested with a modified modetest (support for this modifier has been added). Note that I plan to test/debug support for negative X/Y positioning of SANDXX planes. Regards, Boris Eric Anholt (5): drm/vc4: Fix TILE_Y_OFFSET definitions drm/vc4: Define missing PICTH0_SINK_PIX field drm/vc4: Use drm_atomic_helper_check_plane_state() to simplify the logic drm/vc4: Move ->offsets[] adjustment out of setup_clipping_and_scaling() drm/vc4: Fix negative X/Y positioning of planes using T_TILES modifier drivers/gpu/drm/vc4/vc4_drv.h | 9 -- drivers/gpu/drm/vc4/vc4_plane.c | 272 drivers/gpu/drm/vc4/vc4_regs.h | 8 +- 3 files changed, 170 insertions(+), 119 deletions(-) -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/vc4: Define missing PICTH0_SINK_PIX field
From: Eric Anholt
This is needed to support X/Y negative placement of planes using
T-format buffers.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_regs.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index ccbd6b377ffe..931088014272 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -1037,6 +1037,10 @@ enum hvs_pixel_format {
#define SCALER_TILE_HEIGHT_MASKVC4_MASK(15, 0)
#define SCALER_TILE_HEIGHT_SHIFT 0
+/* Common PITCH0 fields */
+#define SCALER_PITCH0_SINK_PIX_MASKVC4_MASK(31, 26)
+#define SCALER_PITCH0_SINK_PIX_SHIFT 26
+
/* PITCH0 fields for T-tiled. */
#define SCALER_PITCH0_TILE_WIDTH_L_MASKVC4_MASK(22, 16)
#define SCALER_PITCH0_TILE_WIDTH_L_SHIFT 16
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/vc4: Fix TILE_Y_OFFSET definitions
From: Eric Anholt
Y_OFFSET field starts at bit 8 not 7.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index d6864fa4bd14..ccbd6b377ffe 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -1043,8 +1043,8 @@ enum hvs_pixel_format {
#define SCALER_PITCH0_TILE_LINE_DIRBIT(15)
#define SCALER_PITCH0_TILE_INITIAL_LINE_DIRBIT(14)
/* Y offset within a tile. */
-#define SCALER_PITCH0_TILE_Y_OFFSET_MASK VC4_MASK(13, 7)
-#define SCALER_PITCH0_TILE_Y_OFFSET_SHIFT 7
+#define SCALER_PITCH0_TILE_Y_OFFSET_MASK VC4_MASK(13, 8)
+#define SCALER_PITCH0_TILE_Y_OFFSET_SHIFT 8
#define SCALER_PITCH0_TILE_WIDTH_R_MASKVC4_MASK(6, 0)
#define SCALER_PITCH0_TILE_WIDTH_R_SHIFT 0
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/vc4: Move ->offsets[] adjustment out of setup_clipping_and_scaling()
From: Eric Anholt
The offset adjustment depends on the framebuffer modified, so let's
just move this operation in the DRM_FORMAT_MOD_LINEAR case inside
vc4_plane_mode_set().
This we'll be able to fix offset calculation for
DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED and DRM_FORMAT_MOD_BROADCOM_SANDXXX.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_plane.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 39e1fa3a8466..2b8ba1c412be 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -354,14 +354,6 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_state->y_scaling[1] = VC4_SCALING_NONE;
}
- /* Adjust the base pointer to the first pixel to be scanned out. */
- for (i = 0; i < num_planes; i++) {
- vc4_state->offsets[i] += (src_y / (i ? v_subsample : 1)) *
-fb->pitches[i];
- vc4_state->offsets[i] += (src_x / (i ? h_subsample : 1)) *
-fb->format->cpp[i];
- }
-
return 0;
}
@@ -476,6 +468,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u64 base_format_mod = fourcc_mod_broadcom_mod(fb->modifier);
int num_planes = drm_format_num_planes(format->drm);
u32 src_x, src_y, crtc_h, crtc_w, src_h, src_w;
+ u32 h_subsample, v_subsample;
bool mix_plane_alpha;
bool covers_screen;
u32 scl0, scl1, pitch0;
@@ -527,11 +520,25 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
src_y = state->src.y1 >> 16;
src_w = (state->src.x2 - state->src.x1) >> 16;
src_h = (state->src.y2 - state->src.y1) >> 16;
+ h_subsample = drm_format_horz_chroma_subsampling(format->drm);
+ v_subsample = drm_format_vert_chroma_subsampling(format->drm);
switch (base_format_mod) {
case DRM_FORMAT_MOD_LINEAR:
tiling = SCALER_CTL0_TILING_LINEAR;
pitch0 = VC4_SET_FIELD(fb->pitches[0], SCALER_SRC_PITCH);
+
+ /* Adjust the base pointer to the first pixel to be scanned
+* out.
+*/
+ for (i = 0; i < num_planes; i++) {
+ vc4_state->offsets[i] += src_y /
+(i ? v_subsample : 1) *
+fb->pitches[i];
+ vc4_state->offsets[i] += src_x /
+(i ? h_subsample : 1) *
+fb->format->cpp[i];
+ }
break;
case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED: {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/vc4: Fix negative X/Y positioning of planes using T_TILES modifier
From: Eric Anholt
X/Y positioning of T-format buffers is quite tricky and the current
implementation was failing to position a plane using this format
correctly when the X, Y or both X and Y offsets were negative.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
Hi Eric,
I kept the SoB and authorship since you're the original author, but
I also significantly reworked the code, so I'd be more confident if you
could have a close look at this code.
It's been tested with a modified modetest (one that supports generating
T-format buffers) and it seems to work fine with any kind of negative
X/Y offset (both when starting on an even or an odd tile row).
Also, I intentionally did not add a Fixes and Cc-stable to this commit
because it depends on a rework we've done in
vc4_plane_setup_clipping_and_scaling() which cannot be easily
backported.
What I could do though is add a patch that rejects all negative
crtc_{x,y}.
Regards,
Boris
---
drivers/gpu/drm/vc4/vc4_plane.c | 51 +++--
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 2b8ba1c412be..ade47c3f65d1 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -539,22 +539,59 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
(i ? h_subsample : 1) *
fb->format->cpp[i];
}
+
break;
case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED: {
- /* For T-tiled, the FB pitch is "how many bytes from
-* one row to the next, such that pitch * tile_h ==
-* tile_size * tiles_per_row."
-*/
u32 tile_size_shift = 12; /* T tiles are 4kb */
+ /* Whole-tile offsets, mostly for setting the pitch. */
+ u32 tile_w_shift = fb->format->cpp[0] == 2 ? 6 : 5;
u32 tile_h_shift = 5; /* 16 and 32bpp are 32 pixels high */
+ u32 tile_w_mask = (1 << tile_w_shift) - 1;
+ /* The height mask on 32-bit-per-pixel tiles is 63, i.e. 2
+* times the height (in pixels) of a 4k tile. I just assumed
+* this is also true for other RGB formats, but maybe it's not.
+*/
+ u32 tile_h_mask = (2 << tile_h_shift) - 1;
+ /* For T-tiled, the FB pitch is "how many bytes from one row to
+* the next, such that
+*
+* pitch * tile_h == tile_size * tiles_per_row
+*/
u32 tiles_w = fb->pitches[0] >> (tile_size_shift -
tile_h_shift);
+ u32 tiles_l = src_x >> tile_w_shift;
+ u32 tiles_r = tiles_w - tiles_l;
+ u32 tiles_t = src_y >> tile_h_shift;
+ /* Intra-tile offsets, which modify the base address (the
+* SCALER_PITCH0_TILE_Y_OFFSET tells HVS how to walk from that
+* base address).
+*/
+ u32 tile_y = (src_y >> 4) & 1;
+ u32 subtile_y = (src_y >> 2) & 3;
+ u32 utile_y = src_y & 3;
+ u32 x_off = src_x & tile_w_mask;
+ u32 y_off = src_y & tile_h_mask;
tiling = SCALER_CTL0_TILING_256B_OR_T;
+ pitch0 = (VC4_SET_FIELD(x_off, SCALER_PITCH0_SINK_PIX) |
+ VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
+ VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
+ VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
+ vc4_state->offsets[0] += tiles_t * (tiles_w << tile_size_shift);
+ vc4_state->offsets[0] += subtile_y << 8;
+ vc4_state->offsets[0] += utile_y << 4;
+
+ /* Rows of tiles alternate left-to-right and right-to-left. */
+ if (tiles_t & 1) {
+ pitch0 |= SCALER_PITCH0_TILE_INITIAL_LINE_DIR;
+ vc4_state->offsets[0] += (tiles_w - tiles_l) <<
+tile_size_shift;
+ vc4_state->offsets[0] -= (1 + !tile_y) << 10;
+ } else {
+ vc4_state->offsets[0] += tiles_l << tile_size_shift;
+ vc4_state->offsets[0] += tile_y << 10;
+ }
- pitch0 = (VC4_SET_FIELD(0, SCALER_PITCH0_TILE_Y_OFFSET) |
- VC4_SET_FIELD(0, SCALER_PITCH0_TILE_WIDTH_L) |
- VC4_SET_FIELD(tiles_w, SCALER_PITCH0_TILE_WIDTH_R));
break;
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/vc4: Use drm_atomic_helper_check_plane_state() to simplify the logic
From: Eric Anholt
drm_atomic_helper_check_plane_state() takes care of checking the
scaling capabilities and calculating the clipped X/Y offsets for us.
Rely on this function instead of open-coding the logic. While at it, we
get rid of a few fields in vc4_plane_state that can be easily extracted
from drm_plane_state.
Incidentally, it seems to fix a problem we had with negative X/Y
positioning of YUV planes.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_drv.h | 9 --
drivers/gpu/drm/vc4/vc4_plane.c | 210 +---
2 files changed, 111 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index bd6ef1f31822..eae7817837a9 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -344,17 +344,8 @@ struct vc4_plane_state {
*/
u32 __iomem *hw_dlist;
- /* Clipped coordinates of the plane on the display. */
- int crtc_x, crtc_y, crtc_w, crtc_h;
- /* Clipped area being scanned from in the FB. */
- u32 src_x, src_y;
-
- u32 src_w[2], src_h[2];
-
/* Scaling selection for the RGB/Y plane and the Cb/Cr planes. */
enum vc4_scaling_mode x_scaling[2], y_scaling[2];
- bool is_unity;
- bool is_yuv;
/* Offset to start scanning out from the start of the plane's
* BO.
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index a3275fa66b7b..39e1fa3a8466 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -258,107 +258,108 @@ static u32 vc4_get_scl_field(struct drm_plane_state
*state, int plane)
}
}
+static bool is_unity(struct drm_plane_state *state)
+{
+ u32 src_w = (state->src.x2 - state->src.x1) >> 16;
+ u32 src_h = (state->src.y2 - state->src.y1) >> 16;
+ u32 crtc_w = state->dst.x2 - state->dst.x1;
+ u32 crtc_h = state->dst.y2 - state->dst.y1;
+
+ return src_w == crtc_w && src_h == crtc_h;
+}
+
+static bool is_yuv(struct drm_plane_state *state)
+{
+ return state->fb->format->num_planes > 1;
+}
+
static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state)
{
struct drm_plane *plane = state->plane;
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *bo = drm_fb_cma_get_gem_obj(fb, 0);
+ u32 crtc_h, crtc_w, src_h, src_w, src_x, src_y;
u32 subpixel_src_mask = (1 << 16) - 1;
u32 format = fb->format->format;
int num_planes = fb->format->num_planes;
- u32 h_subsample = 1;
- u32 v_subsample = 1;
- int i;
+ int min_scale = 1, max_scale = INT_MAX;
+ struct drm_crtc_state *crtc_state;
+ u32 h_subsample, v_subsample;
+ int i, ret;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (!crtc_state) {
+ DRM_DEBUG_KMS("Invalid crtc state\n");
+ return -EINVAL;
+ }
+
+ /* No configuring scaling on the cursor plane, since it gets
+* non-vblank-synced updates, and scaling requires LBM changes which
+* have to be vblank-synced.
+*/
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ min_scale = DRM_PLANE_HELPER_NO_SCALING;
+ max_scale = DRM_PLANE_HELPER_NO_SCALING;
+ } else {
+ min_scale = 1;
+ max_scale = INT_MAX;
+ }
+
+ ret = drm_atomic_helper_check_plane_state(state, crtc_state,
+ min_scale, max_scale,
+ true, true);
+ if (ret)
+ return ret;
for (i = 0; i < num_planes; i++)
vc4_state->offsets[i] = bo->paddr + fb->offsets[i];
/* We don't support subpixel source positioning for scaling. */
- if ((state->src_x & subpixel_src_mask) ||
- (state->src_y & subpixel_src_mask) ||
- (state->src_w & subpixel_src_mask) ||
- (state->src_h & subpixel_src_mask)) {
+ if ((state->src.x1 & subpixel_src_mask) ||
+ (state->src.x2 & subpixel_src_mask) ||
+ (state->src.y1 & subpixel_src_mask) ||
+ (state->src.y2 & subpixel_src_mask)) {
return -EINVAL;
}
- vc4_state->src_x = state->src_x >> 16;
- vc4_state->src_y = state->src_y >> 16;
- vc4_state->src_w[0] = state->src_w >> 16;
- vc4_state->src_h[0] = state->src_h >> 16;
-
- vc4_state->crtc_x = state->crtc_x;
- vc4_state->crtc_y = state->crtc_y;
- vc4_state->crtc_w = state->crtc_w;
- vc4_state->crtc_h = state->crtc_h;
+ src_w = (state->src.x2 - state->src.x1) >> 16;
+ src_h = (state->src.y2 - state->src.y1) >> 16;
+
[PATCH v5 6/9] ARM: dts: exynos5250: add DSI node
The patch adds common part of DSI node for Exynos5250 platforms
and a required mipi-phy node.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505b3d08..9965eca94a31 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,27 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy@10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040710 0x100>;
+ #phy-cells = <1>;
+ syscon = <&pmu_system_controller>;
+ };
+
+ dsi_0: dsi@1450 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = ;
+ samsung,power-domain = <&pd_disp1>;
+ phys = <&mipi_phy 3>;
+ phy-names = "dsim";
+ clocks = <&clock CLK_DSIM0>, <&clock CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc@12d1 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D1 0x100>;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/9] drm/exynos: enable out_bridge in exynos_dsi_enable
From: Maciej Purski
As the out bridge will not be enabled directly by the framework,
it should be enabled by DSI. exynos_dsi_enable() should handle a case,
when there is an out_bridge connected as a DSI peripheral.
Changed in v5:
- fixed error path in exynos_dsi_enable
Signed-off-by: Maciej Purski
[ a.ha...@samsung.com: v5 ]
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38 +++--
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index f5f51f584fa0..54cfcebe7a2c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1383,29 +1383,37 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
return;
pm_runtime_get_sync(dsi->dev);
-
dsi->state |= DSIM_STATE_ENABLED;
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0)
+ goto err_put_sync;
+ } else {
+ drm_bridge_pre_enable(dsi->out_bridge);
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0)
+ goto err_display_disable;
+ } else {
+ drm_bridge_enable(dsi->out_bridge);
}
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
+ return;
+
+err_display_disable:
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+
+err_put_sync:
+ dsi->state &= ~DSIM_STATE_ENABLED;
+ pm_runtime_put(dsi->dev);
}
static void exynos_dsi_disable(struct drm_encoder *encoder)
@@ -1418,11 +1426,11 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
drm_panel_disable(dsi->panel);
+ drm_bridge_disable(dsi->out_bridge);
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
-
+ drm_bridge_post_disable(dsi->out_bridge);
dsi->state &= ~DSIM_STATE_ENABLED;
-
pm_runtime_put_sync(dsi->dev);
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/9] Add TOSHIBA TC358764 DSI/LVDS bridge driver
Hi, This is continuation of Maciej patchset. I took it over since he can't work on it in near future. I have removed panel patches as they are already merged (thanks Thierry), but I have added fix for timings to allow refresh rate 60Hz. I have addressed all comments from reviewers - thanks Inki, thanks me :) All changes are described in the patches. Regards Andrzej Andrzej Hajda (6): dt-bindings: tc358754: add DT bindings drm/bridge: tc358764: Add DSI to LVDS bridge driver ARM: dts: exynos5250: add DSI node ARM: dts: exynos5250-arndale: add DSI and panel nodes drm/panel: simple: fix BOE/HV070WSA-100 timings dt-bindings: exynos_dsim: update of graph bindings Maciej Purski (3): drm/exynos: rename bridge_node to in_bridge_node drm/exynos: move connector creation to attach callback drm/exynos: enable out_bridge in exynos_dsi_enable .../display/bridge/toshiba,tc358764.txt | 35 ++ .../bindings/display/exynos/exynos_dsim.txt | 25 +- arch/arm/boot/dts/exynos5250-arndale.dts | 61 +++ arch/arm/boot/dts/exynos5250.dtsi | 21 + drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 499 ++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 104 ++-- drivers/gpu/drm/panel/panel-simple.c | 14 +- 9 files changed, 701 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt create mode 100644 drivers/gpu/drm/bridge/tc358764.c -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 8/9] drm/panel: simple: fix BOE/HV070WSA-100 timings
Panel timings were taken from vendor code and are not fully correct - refresh
rate is about 50Hz instead of 60Hz. The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-simple.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index d5da58d5c9b1..a2226a3d2887 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -746,15 +746,15 @@ static const struct panel_desc avic_tm070ddh03 = {
};
static const struct drm_display_mode boe_hv070wsa_mode = {
- .clock = 40800,
+ .clock = 42105,
.hdisplay = 1024,
- .hsync_start = 1024 + 90,
- .hsync_end = 1024 + 90 + 90,
- .htotal = 1024 + 90 + 90 + 90,
+ .hsync_start = 1024 + 30,
+ .hsync_end = 1024 + 30 + 30,
+ .htotal = 1024 + 30 + 30 + 30,
.vdisplay = 600,
- .vsync_start = 600 + 3,
- .vsync_end = 600 + 3 + 4,
- .vtotal = 600 + 3 + 4 + 3,
+ .vsync_start = 600 + 10,
+ .vsync_end = 600 + 10 + 10,
+ .vtotal = 600 + 10 + 10 + 10,
.vrefresh = 60,
};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 7/9] ARM: dts: exynos5250-arndale: add DSI and panel nodes
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board and
regulators required by the bridge.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250-arndale.dts | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c55701a..816d89d4cefd 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <&vcc_3v3_reg>;
+ enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <&bridge_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -97,6 +108,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
fixed-rate-clocks {
@@ -119,6 +154,32 @@
cpu0-supply = <&buck2_reg>;
};
+&dsi_0 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ samsung,pll-clock-frequency = <2400>;
+ samsung,burst-clock-frequency = <32000>;
+ samsung,esc-clock-frequency = <1000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddlvds-supply = <&vcc_3v3_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+};
+
&dp {
status = "okay";
samsung,color-space = <0>;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/9] dt-bindings: tc358754: add DT bindings
The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
Bindings describe power supplies, reset gpio and video interfaces.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
Reviewed-by: Rob Herring
---
.../display/bridge/toshiba,tc358764.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
new file mode 100644
index ..8f9abf28a8fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
@@ -0,0 +1,35 @@
+TC358764 MIPI-DSI to LVDS panel bridge
+
+Required properties:
+ - compatible: "toshiba,tc358764"
+ - reg: the virtual channel number of a DSI peripheral
+ - vddc-supply: core voltage supply, 1.2V
+ - vddio-supply: I/O voltage supply, 1.8V or 3.3V
+ - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
+ - reset-gpios: a GPIO spec for the reset pin
+
+The device node can contain following 'port' child nodes,
+according to the OF graph bindings defined in [1]:
+ 0: DSI Input, not required, if the bridge is DSI controlled
+ 1: LVDS Output, mandatory
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddlvds-supply = <&vcc_3v3_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ lvds_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver
Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Changes in v4: - removed license blob, - ordered includes, - added error handling, - fixed reset GPIO handling, - added missing calls to the panel, - custom OF graph code replaced with helpers, - removed tc358764_poweroff from remove callback. v5: - fixed supply names, - fixed broken console - added connector to fb_helper, - added detach callback - unbinding works, - fixed typo in error checking code, - removed sparse bridge->encoder check - core does it already. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski [ a.ha...@samsung.com: v4, v5 ] Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 499 ++ 3 files changed, 508 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c7997e2fd..f3da8a716833 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + help + Toshiba TC358764 DSI/LVDS bridge driver. + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d48ec20..bf7c0cecf227 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index ..779bc5fce22a --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,499 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0) +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */ +#define VP_VTIM2_VFP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM2_VACT(v) F
[PATCH v5 1/9] drm/exynos: rename bridge_node to in_bridge_node
From: Maciej Purski
Driver uses bridge_node to refer to bridge on input side of DSI.
Since we want to add support for bridges on output side lets add
"in" prefix to avoid confusion with out bridges.
Changes in v5:
- replace mic_ prefix with in_
Signed-off-by: Maciej Purski
[ a.ha...@samsuung.com: v5 ]
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7c3030b7e586..351403f9d245 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *in_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->in_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *in_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->in_bridge_node) {
+ in_bridge = of_drm_find_bridge(dsi->in_bridge_node);
+ if (in_bridge)
+ drm_bridge_attach(encoder, in_bridge, NULL);
}
return mipi_dsi_host_register(&dsi->dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->in_bridge_node);
pm_runtime_disable(&pdev->dev);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/9] drm/exynos: move connector creation to attach callback
From: Maciej Purski
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge child device
should also be possible.
If an output bridge is available, don't create a new connector.
Instead, call drm_bridge_attach() and set encoder's bridge to NULL
in order to avoid an out bridge from being visible by the framework, as
the DSI bus needs control on enabling its child output bridge.
Such sequence is required by Toshiba TC358764 bridge, which is a DSI
peripheral bridge device.
changed in v5:
- detach bridge in mipi_dsi detach callback
Signed-off-by: Maciej Purski
[ a.ha...@samsung.com: v5 ]
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 50 -
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 351403f9d245..f5f51f584fa0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,7 @@ struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
struct drm_panel *panel;
+ struct drm_bridge *out_bridge;
struct device *dev;
void __iomem *reg_base;
@@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = &dsi->encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ dsi->out_bridge = out_bridge;
+ encoder->bridge = NULL;
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, &dsi->connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1518,11 +1542,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, &dsi->connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1538,19 +1557,21 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
-
- mutex_lock(&drm->mode_config.mutex);
+ struct drm_device *drm = dsi->encoder.dev;
if (dsi->panel) {
+ mutex_lock(&drm->mode_config.mutex);
exynos_dsi_disable(&dsi->encoder);
drm_panel_detach(dsi->panel);
dsi->panel = NULL;
dsi->connector.status = connector_status_disconnected;
+ mutex_unlock(&drm->mode_config.mutex);
+ } else {
+ if (dsi->out_bridge->funcs->detach)
+ dsi->out_bridge->funcs->detach(dsi->out_bridge);
+ dsi->out_bridge = NULL;
}
- mutex_unlock(&drm->mode_config.mutex);
-
if (drm->mode_config.poll_enabled)
drm_kms_helper_hotplug_event(drm);
@@ -1654,13 +1675,6 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->in_bridge_node) {
in_bridge = of_drm_find_bridge(dsi->in_bridge_node);
if (in_bridge)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 9/9] dt-bindings: exynos_dsim: update of graph bindings
Of-graph bindings should describe ports present in the device, not the devices it can be connected to. The patch replaces verbose description with shorter but more precise one. While at it clock related properties are moved to the main node as it is their actual location. Signed-off-by: Andrzej Hajda --- .../bindings/display/exynos/exynos_dsim.txt | 25 +-- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt index 2fff8b406f4c..be377786e8cd 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt @@ -21,6 +21,9 @@ Required properties: - samsung,pll-clock-frequency: specifies frequency of the oscillator clock - #address-cells, #size-cells: should be set respectively to <1> and <0> according to DSI host bindings (see MIPI DSI bindings [1]) + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst +mode + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode Optional properties: - power-domains: a phandle to DSIM power domain node @@ -29,25 +32,9 @@ Child nodes: Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). Video interfaces: - Device node can contain video interface port nodes according to [2]. - The following are properties specific to those nodes: - - port node inbound: -- reg: (required) must be 0. - port node outbound: -- reg: (required) must be 1. - - endpoint node connected from mic node (reg = 0): -- remote-endpoint: specifies the endpoint in mic node. This node is required - for Exynos5433 mipi dsi. So mic can access to panel node - throughout this dsi node. - endpoint node connected to panel node (reg = 1): -- remote-endpoint: specifies the endpoint in panel node. This node is - required in all kinds of exynos mipi dsi to represent - the connection between mipi dsi and panel. -- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst - mode -- samsung,esc-clock-frequency: specifies DSI frequency in escape mode + Device node can contain following video interface port nodes according to [2]: + 0: RGB input, + 1: DSI output [1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt [2]: Documentation/devicetree/bindings/media/video-interfaces.txt -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107375 --- Comment #2 from Paul Menzel --- (In reply to Michel Dänzer from comment #1) > Created attachment 140814 [details] [review] > Do posting read in psp_v10_0_cmd_submit > > Does this patch help by any chance? No, unfortunately it does not change the times. > (In reply to Paul Menzel from comment #0) > > Also, I wonder why the sleep in the trace is 3 ms instead of 1 ms like in > > the code. > > Maybe your kernel is configured with CONFIG_HZ=300? Anyway, it doesn't > really matter, as it's waiting for the PSP to finish processing the command. ``` $ grep CONFIG_HZ .config # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 ``` -- 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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #39 from Paul Menzel --- (In reply to jian-hong from comment #36) > Created attachment 140806 [details] > dmesg of 4.18.0-rc6 > > Tested with Linux 4.18.0-rc6 kernel. > It seems the amdgpu module could be loaded correctly. I tried over 20 times. I am still hitting this issue, though less often with 4.18-rc6. Could you please attach your configuration, your build instructions? It seems independent from the compiler (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1endless2bem1)) as I use GCC 8.1.0 from Debian Sid/unstable. -- 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 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #16 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to mikita.lip...@amd.com from comment #15) > Lyude Paul fixed this issue, please try his patch: > > https://patchwork.kernel.org/patch/10480569/ > > Thanks As written in https://bugzilla.kernel.org/show_bug.cgi?id=199425#c13, this patch fix another bug. It doesn't help with this use-after-free. Your patch is still needed. -- 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 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #4 from sybo...@gmail.com --- Created attachment 277521 --> https://bugzilla.kernel.org/attachment.cgi?id=277521&action=edit dmesg log -- 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 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #5 from sybo...@gmail.com --- Created attachment 277523 --> https://bugzilla.kernel.org/attachment.cgi?id=277523&action=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] dt-bindings: drm/bridge Document Cadence MHDP DPI/DP bridge bindings
On Tue, Jul 24, 2018 at 12:13:35PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> Signed-off-by: Damian Kos
> ---
> .../bindings/display/bridge/cdns,mhdp.txt | 43 +++
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> new file mode 100644
> index ..dc7be7590048
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> @@ -0,0 +1,43 @@
> +Cadence MHDP bridge
> +==
> +
> +The Cadence MHDP bridge is a DPI to DP bridge.
> +
> +Required properties:
> +- compatible: should be "cdns,mhdp8546",
> +- reg: physical base address and length of the controller's registers,
> +- clocks: DP bridge clock, it's used by the IP to know how to translate
> + a number of clock cycles into a time (which is used to comply
> + with DP standard timings and delays),
> +
> +Required subnodes:
> +- ports: Ports as described in Documentation/devictree/bindings/graph.txt
> + Port 0 - input port representing the VGA bridge input
> + Port 1 - output port representing the VGA bridge output
VGA?
> +
> +Example:
> +
> + mhdp: dp-bridge@f0fb00 {
> + compatible = "cdns,mhdp8546";
> + reg = <0xf0 0xfb00 0x0 0x100>;
> + clocks = <&mhdp_clock>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + vga_bridge_input: endpoint {
> + remote-endpoint = <&xxx_dpi_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + vga_bridge_output: endpoint {
> + remote-endpoint =
> <&xxx_vga_connector_input>;
vga?
> + };
> + };
> + };
> + };
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] media: omap2: omapfb: fix ifnullfree.cocci warnings
From: kbuild test robot
drivers/video/fbdev/omap2/omapfb/dss/core.c:141:2-26: WARNING: NULL check
before some freeing functions is not needed.
NULL check before some freeing functions is not needed.
Based on checkpatch warning
"kfree(NULL) is safe this check is probably not required"
and kfreeaddr.cocci by Julia Lawall.
Generated by: scripts/coccinelle/free/ifnullfree.cocci
Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST")
Signed-off-by: kbuild test robot
---
Please take the patch only if it's a positive warning. Thanks!
core.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -137,8 +137,7 @@ static int dss_initialize_debugfs(void)
static void dss_uninitialize_debugfs(void)
{
- if (dss_debugfs_dir)
- debugfs_remove_recursive(dss_debugfs_dir);
+ debugfs_remove_recursive(dss_debugfs_dir);
}
int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] media: omap2: omapfb: fix boolreturn.cocci warnings
From: kbuild test robot
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:290:9-10: WARNING: return of 0/1
in function 'cmp_var_to_colormode' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST")
Signed-off-by: kbuild test robot
---
omapfb-main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -287,7 +287,7 @@ static bool cmp_var_to_colormode(struct
var->red.length == 0 ||
var->blue.length == 0 ||
var->green.length == 0)
- return 0;
+ return false;
return var->bits_per_pixel == color->bits_per_pixel &&
cmp_component(&var->red, &color->red) &&
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] media: omap2: omapfb: fix bugon.cocci warnings
From: kbuild test robot
drivers/video/fbdev/omap2/omapfb/dss/dss_features.c:895:2-5: WARNING: Use
BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON
definition in include/asm-generic/bug.h)
Use BUG_ON instead of a if condition followed by BUG.
Semantic patch information:
This makes an effort to find cases where BUG() follows an if
condition on an expression and replaces the if condition and BUG()
with a BUG_ON having the conditional expression of the if statement
as argument.
Generated by: scripts/coccinelle/misc/bugon.cocci
Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST")
Signed-off-by: kbuild test robot
---
Please take the patch only if it's a positive warning. Thanks!
dss_features.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -891,8 +891,7 @@ bool dss_has_feature(enum dss_feat_id id
void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end)
{
- if (id >= omap_current_dss_features->num_reg_fields)
- BUG();
+ BUG_ON(id >= omap_current_dss_features->num_reg_fields);
*start = omap_current_dss_features->reg_fields[id].start;
*end = omap_current_dss_features->reg_fields[id].end;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104193] [radeonsi] The Witcher 3 freezes the system (POLARIS10)
https://bugs.freedesktop.org/show_bug.cgi?id=104193 --- Comment #10 from Christian Widmer --- It seems I have also just hit this bug. I am able to trigger hangs on my Sapphire Nitro+ Radeon RX 580 Special Edition on the first fight with ghouls after Geralt awakes from his dream at the beginning of the game using wine 3.13. It does not happen all the time, but when I do the fight a few times, there is eventually a point where it freezes. I am using mesa git on commit c3eaf8fe5746e5b29a46a076247ba072c84e2ec5 and kernel 4.17.9 with the Gentoo patchset. -- 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] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
On Tue, 24 Jul 2018 15:32:15 +0200
Boris Brezillon wrote:
> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC.
>
> Check old_plane_state->crtc value to make sure async plane update is
> allowed.
>
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
> update")
> Cc:
> Signed-off-by: Boris Brezillon
> Reviewed-by: Eric Anholt
Applied to drm-misc-fixes.
> ---
> Changes in v2:
> - Cc stable
> - Add Eric's R-b
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 866a2cc72ef6..f7ccfebd3ca8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1555,7 +1555,8 @@ int drm_atomic_helper_async_check(struct drm_device
> *dev,
> if (n_planes != 1)
> return -EINVAL;
>
> - if (!new_plane_state->crtc)
> + if (!new_plane_state->crtc ||
> + old_plane_state->crtc != new_plane_state->crtc)
> return -EINVAL;
>
> funcs = plane->helper_private;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy
On Tue, 24 Jul 2018 15:33:00 +0200
Boris Brezillon wrote:
> drm_atomic_helper_async_check() declares the plane, old_plane_state and
> new_plane_state variables to iterate over all planes of the atomic
> state and make sure only one plane is enabled.
>
> Unfortunately gcc is not smart enough to figure out that the check on
> n_planes is enough to guarantee that plane, new_plane_state and
> old_plane_state are initialized.
>
> Explicitly initialize those variables to NULL to make gcc happy.
>
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
> update")
> Cc:
> Signed-off-by: Boris Brezillon
> Reviewed-by: Sean Paul
Applied to drm-misc-fixes.
> ---
> Changes in v2:
> - Cc stable
> - Add Sean's R-b
> - Fix a typo in the commit message
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f7ccfebd3ca8..80be74df7ba6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1538,8 +1538,9 @@ int drm_atomic_helper_async_check(struct drm_device
> *dev,
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *crtc_state;
> - struct drm_plane *plane;
> - struct drm_plane_state *old_plane_state, *new_plane_state;
> + struct drm_plane *plane = NULL;
> + struct drm_plane_state *old_plane_state = NULL;
> + struct drm_plane_state *new_plane_state = NULL;
> const struct drm_plane_helper_funcs *funcs;
> int i, n_planes = 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Reset ->{x,y}_scaling[1] when dealing with uniplanar formats
On Tue, 24 Jul 2018 15:36:01 +0200
Boris Brezillon wrote:
> This is needed to ensure ->is_unity is correct when the plane was
> previously configured to output a multi-planar format with scaling
> enabled, and is then being reconfigured to output a uniplanar format.
>
> Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
> Cc:
> Signed-off-by: Boris Brezillon
Applied to drm-misc-fixes.
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 9d7a36f148cf..cfb50fedfa2b 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -320,6 +320,9 @@ static int vc4_plane_setup_clipping_and_scaling(struct
> drm_plane_state *state)
> vc4_state->x_scaling[0] = VC4_SCALING_TPZ;
> if (vc4_state->y_scaling[0] == VC4_SCALING_NONE)
> vc4_state->y_scaling[0] = VC4_SCALING_TPZ;
> + } else {
> + vc4_state->x_scaling[1] = VC4_SCALING_NONE;
> + vc4_state->y_scaling[1] = VC4_SCALING_NONE;
> }
>
> vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-4.18
Hi Dave, Fixes for some power features not getting set properly after a suspend cycle on vega10. The following changes since commit 02e546eacceaaad4494e2ea8fb5014f00f9c4bef: Merge branch 'linux-4.18' of git://github.com/skeggsb/linux into drm-fixes (2018-07-20 10:27:53 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.18 for you to fetch changes up to d52af7a4a8a502cd031101eaace7ed8fd80f2283: drm/amd/pp: Update clk with od setting when set power state (2018-07-20 15:28:01 -0500) Rex Zhu (2): drm/amd/pp: Read vbios vddc limit before use them drm/amd/pp: Update clk with od setting when set power state drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
