[PATCH AUTOSEL 4.9 01/13] gpu: host1x: Detach driver on unregister
From: Thierry Reding
[ Upstream commit d9a0a05bf8c76e6dc79230669a8b5d685b168c30 ]
Currently when a host1x device driver is unregistered, it is not
detached from the host1x controller, which means that the device
will stay around and when the driver is registered again, it may
bind to the old, stale device rather than the new one that was
created from scratch upon driver registration. This in turn can
cause various weird crashes within the driver core because it is
confronted with a device that was already deleted.
Fix this by detaching the driver from the host1x controller when
it is unregistered. This ensures that the deleted device also is
no longer present in the device list that drivers will bind to.
Reported-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Tested-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c27858ae05529..6ef89e8a515a9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -542,8 +542,17 @@ EXPORT_SYMBOL(host1x_driver_register_full);
void host1x_driver_unregister(struct host1x_driver *driver)
{
+ struct host1x *host1x;
+
driver_unregister(>driver);
+ mutex_lock(_lock);
+
+ list_for_each_entry(host1x, , list)
+ host1x_detach_driver(host1x, driver);
+
+ mutex_unlock(_lock);
+
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 04/27] gpu: host1x: Detach driver on unregister
From: Thierry Reding
[ Upstream commit d9a0a05bf8c76e6dc79230669a8b5d685b168c30 ]
Currently when a host1x device driver is unregistered, it is not
detached from the host1x controller, which means that the device
will stay around and when the driver is registered again, it may
bind to the old, stale device rather than the new one that was
created from scratch upon driver registration. This in turn can
cause various weird crashes within the driver core because it is
confronted with a device that was already deleted.
Fix this by detaching the driver from the host1x controller when
it is unregistered. This ensures that the deleted device also is
no longer present in the device list that drivers will bind to.
Reported-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Tested-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 0121fe7a4548d..02f896b50ed07 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -632,8 +632,17 @@ EXPORT_SYMBOL(host1x_driver_register_full);
*/
void host1x_driver_unregister(struct host1x_driver *driver)
{
+ struct host1x *host1x;
+
driver_unregister(>driver);
+ mutex_lock(_lock);
+
+ list_for_each_entry(host1x, , list)
+ host1x_detach_driver(host1x, driver);
+
+ mutex_unlock(_lock);
+
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 15/27] drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003
From: Hans de Goede
[ Upstream commit a05caf9e62a85d12da27e814ac13195f4683f21c ]
The Acer S1003 has proper DMI strings for sys-vendor and product-name,
so we do not need to match by BIOS-date.
This means that the Acer S1003 can use the generic lcd800x1280_rightside_up
drm_dmi_panel_orientation_data struct which is also used by other quirks.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index de7837efbbfce..fa5c25d36d3dc 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -30,12 +30,6 @@ struct drm_dmi_panel_orientation_data {
int orientation;
};
-static const struct drm_dmi_panel_orientation_data acer_s1003 = {
- .width = 800,
- .height = 1280,
- .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
-};
-
static const struct drm_dmi_panel_orientation_data asus_t100ha = {
.width = 800,
.height = 1280,
@@ -100,7 +94,7 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
- .driver_data = (void *)_s1003,
+ .driver_data = (void *)_rightside_up,
}, {/* Asus T100HA */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 02/17] gpu: host1x: Detach driver on unregister
From: Thierry Reding
[ Upstream commit d9a0a05bf8c76e6dc79230669a8b5d685b168c30 ]
Currently when a host1x device driver is unregistered, it is not
detached from the host1x controller, which means that the device
will stay around and when the driver is registered again, it may
bind to the old, stale device rather than the new one that was
created from scratch upon driver registration. This in turn can
cause various weird crashes within the driver core because it is
confronted with a device that was already deleted.
Fix this by detaching the driver from the host1x controller when
it is unregistered. This ensures that the deleted device also is
no longer present in the device list that drivers will bind to.
Reported-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Tested-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index f9cde03030fd9..c2a9dcf6f4907 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -615,8 +615,17 @@ EXPORT_SYMBOL(host1x_driver_register_full);
*/
void host1x_driver_unregister(struct host1x_driver *driver)
{
+ struct host1x *host1x;
+
driver_unregister(>driver);
+ mutex_lock(_lock);
+
+ list_for_each_entry(host1x, , list)
+ host1x_detach_driver(host1x, driver);
+
+ mutex_unlock(_lock);
+
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 14/27] drm: panel-orientation-quirks: Add quirk for Asus T101HA panel
From: Hans de Goede
[ Upstream commit 6c22bc18a3b93a38018844636557ad02e588e055 ]
Like the Asus T100HA the Asus T101HA also uses a panel which has been
mounted 90 degrees rotated, albeit in the opposite direction.
Add a quirk for this.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index cc354b4917742..de7837efbbfce 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -107,6 +107,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+ }, {/* Asus T101HA */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T101HA"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* GPD MicroPC (generic strings, also match on bios date) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 03/27] drm/tegra: hub: Do not enable orphaned window group
From: Nicolin Chen
[ Upstream commit ef4e417eb3ec7fe657928f10ac1d2154d8a5fb38 ]
Though the unconditional enable/disable code is not a final solution,
we don't want to run into a NULL pointer situation when window group
doesn't link to its DC parent if the DC is disabled in Device Tree.
So this patch simply adds a check to make sure that window group has
a valid parent before running into tegra_windowgroup_enable/disable.
Signed-off-by: Nicolin Chen
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/hub.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index bb97cad1eb699..b08ce1125996d 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -143,7 +143,9 @@ int tegra_display_hub_prepare(struct tegra_display_hub *hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_enable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_enable(wgrp);
}
return 0;
@@ -160,7 +162,9 @@ void tegra_display_hub_cleanup(struct tegra_display_hub
*hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_disable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_disable(wgrp);
}
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 19/27] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
From: Maxime Ripard
[ Upstream commit 842ec61f4006a6477a9deaedd69131e9f46e4cb5 ]
The main DRM device is actually a virtual device so it doesn't have the
iommus property, which is instead on the DMA masters, in this case the
mixers.
Add a call to of_dma_configure with the mixers DT node but on the DRM
virtual device to configure it in the same way than the mixers.
Reviewed-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.max...@cerno.tech
(cherry picked from commit b718102dbdfd0285ad559687a30e27cc9124e592)
[Maxime: Applied to -fixes since it missed the merge window and display is
broken without it]
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 71a798e5d5591..ddab3fab36a1a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -435,6 +435,19 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
mixer->engine.ops = _engine_ops;
mixer->engine.node = dev->of_node;
+ if (of_find_property(dev->of_node, "iommus", NULL)) {
+ /*
+* This assume we have the same DMA constraints for
+* all our the mixers in our pipeline. This sounds
+* bad, but it has always been the case for us, and
+* DRM doesn't do per-device allocation either, so we
+* would need to fix DRM first...
+*/
+ ret = of_dma_configure(drm->dev, dev->of_node, true);
+ if (ret)
+ return ret;
+ }
+
/*
* While this function can fail, we shouldn't do anything
* if this happens. Some early DE2 DT entries don't provide
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 07/40] gpu: host1x: Detach driver on unregister
From: Thierry Reding
[ Upstream commit d9a0a05bf8c76e6dc79230669a8b5d685b168c30 ]
Currently when a host1x device driver is unregistered, it is not
detached from the host1x controller, which means that the device
will stay around and when the driver is registered again, it may
bind to the old, stale device rather than the new one that was
created from scratch upon driver registration. This in turn can
cause various weird crashes within the driver core because it is
confronted with a device that was already deleted.
Fix this by detaching the driver from the host1x controller when
it is unregistered. This ensures that the deleted device also is
no longer present in the device list that drivers will bind to.
Reported-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Tested-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 742aa9ff21b87..fcda8621ae6f9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -686,8 +686,17 @@ EXPORT_SYMBOL(host1x_driver_register_full);
*/
void host1x_driver_unregister(struct host1x_driver *driver)
{
+ struct host1x *host1x;
+
driver_unregister(>driver);
+ mutex_lock(_lock);
+
+ list_for_each_entry(host1x, , list)
+ host1x_detach_driver(host1x, driver);
+
+ mutex_unlock(_lock);
+
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 05/40] drm/ttm: Fix dma_fence refcnt leak when adding move fence
From: Xiyu Yang
[ Upstream commit 11425c4519e2c974a100fc984867046d905b9380 ]
ttm_bo_add_move_fence() invokes dma_fence_get(), which returns a
reference of the specified dma_fence object to "fence" with increased
refcnt.
When ttm_bo_add_move_fence() returns, local variable "fence" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
ttm_bo_add_move_fence(). When no_wait_gpu flag is equals to true, the
function forgets to decrease the refcnt increased by dma_fence_get(),
causing a refcnt leak.
Fix this issue by calling dma_fence_put() when no_wait_gpu flag is
equals to true.
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
Reviewed-by: Christian König
Link: https://patchwork.freedesktop.org/patch/370221/
Signed-off-by: Christian König
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index abf165b2f64fc..3ce8ad7603c7f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -941,8 +941,10 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
if (!fence)
return 0;
- if (no_wait_gpu)
+ if (no_wait_gpu) {
+ dma_fence_put(fence);
return -EBUSY;
+ }
dma_resv_add_shared_fence(bo->base.resv, fence);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 31/40] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
From: Maxime Ripard
[ Upstream commit 842ec61f4006a6477a9deaedd69131e9f46e4cb5 ]
The main DRM device is actually a virtual device so it doesn't have the
iommus property, which is instead on the DMA masters, in this case the
mixers.
Add a call to of_dma_configure with the mixers DT node but on the DRM
virtual device to configure it in the same way than the mixers.
Reviewed-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.max...@cerno.tech
(cherry picked from commit b718102dbdfd0285ad559687a30e27cc9124e592)
[Maxime: Applied to -fixes since it missed the merge window and display is
broken without it]
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 18b4881f44814..e24f225d80f1f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -452,6 +452,19 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
mixer->engine.ops = _engine_ops;
mixer->engine.node = dev->of_node;
+ if (of_find_property(dev->of_node, "iommus", NULL)) {
+ /*
+* This assume we have the same DMA constraints for
+* all our the mixers in our pipeline. This sounds
+* bad, but it has always been the case for us, and
+* DRM doesn't do per-device allocation either, so we
+* would need to fix DRM first...
+*/
+ ret = of_dma_configure(drm->dev, dev->of_node, true);
+ if (ret)
+ return ret;
+ }
+
/*
* While this function can fail, we shouldn't do anything
* if this happens. Some early DE2 DT entries don't provide
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 26/40] drm: panel-orientation-quirks: Add quirk for Asus T101HA panel
From: Hans de Goede
[ Upstream commit 6c22bc18a3b93a38018844636557ad02e588e055 ]
Like the Asus T100HA the Asus T101HA also uses a panel which has been
mounted 90 degrees rotated, albeit in the opposite direction.
Add a quirk for this.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index ffd95bfeaa94c..d11d83703931e 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -121,6 +121,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+ }, {/* Asus T101HA */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T101HA"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* GPD MicroPC (generic strings, also match on bios date) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 09/40] drm: mcde: Fix display initialization problem
From: Linus Walleij [ Upstream commit b984b6d8b52372b98cce0a6ff6c2787f50665b87 ] The following bug appeared in the MCDE driver/display initialization during the recent merge window. First the place we call drm_fbdev_generic_setup() in the wrong place: this needs to be called AFTER calling drm_dev_register() else we get this splat: [ cut here ] WARNING: CPU: 0 PID: 1 at ../drivers/gpu/drm/drm_fb_helper.c:2198 drm_fbdev_generic_setup+0x164/0x1a8 mcde a035.mcde: Device has not been registered. Modules linked in: Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x9c/0xb0) [] (dump_stack) from [] (__warn+0xb8/0xd0) [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8) [] (warn_slowpath_fmt) from [] (drm_fbdev_generic_setup+0x164/0x1a8) [] (drm_fbdev_generic_setup) from [] (mcde_drm_bind+0xc4/0x160) [] (mcde_drm_bind) from [] (try_to_bring_up_master+0x15c/0x1a4) (...) Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200613223027.4189309-1-linus.wall...@linaro.org Signed-off-by: Sasha Levin --- drivers/gpu/drm/mcde/mcde_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c index 5649887d2b901..16e5fb9ec784d 100644 --- a/drivers/gpu/drm/mcde/mcde_drv.c +++ b/drivers/gpu/drm/mcde/mcde_drv.c @@ -215,7 +215,6 @@ static int mcde_modeset_init(struct drm_device *drm) drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm); - drm_fbdev_generic_setup(drm, 32); return 0; @@ -282,6 +281,8 @@ static int mcde_drm_bind(struct device *dev) if (ret < 0) goto unbind; + drm_fbdev_generic_setup(drm, 32); + return 0; unbind: -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 27/40] drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003
From: Hans de Goede
[ Upstream commit a05caf9e62a85d12da27e814ac13195f4683f21c ]
The Acer S1003 has proper DMI strings for sys-vendor and product-name,
so we do not need to match by BIOS-date.
This means that the Acer S1003 can use the generic lcd800x1280_rightside_up
drm_dmi_panel_orientation_data struct which is also used by other quirks.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d11d83703931e..d00ea384dcbfe 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -30,12 +30,6 @@ struct drm_dmi_panel_orientation_data {
int orientation;
};
-static const struct drm_dmi_panel_orientation_data acer_s1003 = {
- .width = 800,
- .height = 1280,
- .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
-};
-
static const struct drm_dmi_panel_orientation_data asus_t100ha = {
.width = 800,
.height = 1280,
@@ -114,7 +108,7 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
- .driver_data = (void *)_s1003,
+ .driver_data = (void *)_rightside_up,
}, {/* Asus T100HA */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 06/40] drm/tegra: hub: Do not enable orphaned window group
From: Nicolin Chen
[ Upstream commit ef4e417eb3ec7fe657928f10ac1d2154d8a5fb38 ]
Though the unconditional enable/disable code is not a final solution,
we don't want to run into a NULL pointer situation when window group
doesn't link to its DC parent if the DC is disabled in Device Tree.
So this patch simply adds a check to make sure that window group has
a valid parent before running into tegra_windowgroup_enable/disable.
Signed-off-by: Nicolin Chen
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/hub.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 839b49c40e514..767fb440a79d9 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -141,7 +141,9 @@ int tegra_display_hub_prepare(struct tegra_display_hub *hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_enable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_enable(wgrp);
}
return 0;
@@ -158,7 +160,9 @@ void tegra_display_hub_cleanup(struct tegra_display_hub
*hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_disable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_disable(wgrp);
}
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 13/53] drm: mcde: Fix display initialization problem
From: Linus Walleij [ Upstream commit b984b6d8b52372b98cce0a6ff6c2787f50665b87 ] The following bug appeared in the MCDE driver/display initialization during the recent merge window. First the place we call drm_fbdev_generic_setup() in the wrong place: this needs to be called AFTER calling drm_dev_register() else we get this splat: [ cut here ] WARNING: CPU: 0 PID: 1 at ../drivers/gpu/drm/drm_fb_helper.c:2198 drm_fbdev_generic_setup+0x164/0x1a8 mcde a035.mcde: Device has not been registered. Modules linked in: Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x9c/0xb0) [] (dump_stack) from [] (__warn+0xb8/0xd0) [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8) [] (warn_slowpath_fmt) from [] (drm_fbdev_generic_setup+0x164/0x1a8) [] (drm_fbdev_generic_setup) from [] (mcde_drm_bind+0xc4/0x160) [] (mcde_drm_bind) from [] (try_to_bring_up_master+0x15c/0x1a4) (...) Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200613223027.4189309-1-linus.wall...@linaro.org Signed-off-by: Sasha Levin --- drivers/gpu/drm/mcde/mcde_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c index f28cb7a576ba4..1e7c5aa4d5e62 100644 --- a/drivers/gpu/drm/mcde/mcde_drv.c +++ b/drivers/gpu/drm/mcde/mcde_drv.c @@ -208,7 +208,6 @@ static int mcde_modeset_init(struct drm_device *drm) drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm); - drm_fbdev_generic_setup(drm, 32); return 0; @@ -275,6 +274,8 @@ static int mcde_drm_bind(struct device *dev) if (ret < 0) goto unbind; + drm_fbdev_generic_setup(drm, 32); + return 0; unbind: -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 10/53] gpu: host1x: Detach driver on unregister
From: Thierry Reding
[ Upstream commit d9a0a05bf8c76e6dc79230669a8b5d685b168c30 ]
Currently when a host1x device driver is unregistered, it is not
detached from the host1x controller, which means that the device
will stay around and when the driver is registered again, it may
bind to the old, stale device rather than the new one that was
created from scratch upon driver registration. This in turn can
cause various weird crashes within the driver core because it is
confronted with a device that was already deleted.
Fix this by detaching the driver from the host1x controller when
it is unregistered. This ensures that the deleted device also is
no longer present in the device list that drivers will bind to.
Reported-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Tested-by: Sowjanya Komatineni
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 6a995db51d6d8..e201f62d62c0c 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -686,8 +686,17 @@ EXPORT_SYMBOL(host1x_driver_register_full);
*/
void host1x_driver_unregister(struct host1x_driver *driver)
{
+ struct host1x *host1x;
+
driver_unregister(>driver);
+ mutex_lock(_lock);
+
+ list_for_each_entry(host1x, , list)
+ host1x_detach_driver(host1x, driver);
+
+ mutex_unlock(_lock);
+
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 07/53] drm/ttm: Fix dma_fence refcnt leak when adding move fence
From: Xiyu Yang
[ Upstream commit 11425c4519e2c974a100fc984867046d905b9380 ]
ttm_bo_add_move_fence() invokes dma_fence_get(), which returns a
reference of the specified dma_fence object to "fence" with increased
refcnt.
When ttm_bo_add_move_fence() returns, local variable "fence" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
ttm_bo_add_move_fence(). When no_wait_gpu flag is equals to true, the
function forgets to decrease the refcnt increased by dma_fence_get(),
causing a refcnt leak.
Fix this issue by calling dma_fence_put() when no_wait_gpu flag is
equals to true.
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
Reviewed-by: Christian König
Link: https://patchwork.freedesktop.org/patch/370221/
Signed-off-by: Christian König
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9e07c3f75156b..ef5bc00c73e23 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -881,8 +881,10 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
if (!fence)
return 0;
- if (no_wait_gpu)
+ if (no_wait_gpu) {
+ dma_fence_put(fence);
return -EBUSY;
+ }
dma_resv_add_shared_fence(bo->base.resv, fence);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 34/53] drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003
From: Hans de Goede
[ Upstream commit a05caf9e62a85d12da27e814ac13195f4683f21c ]
The Acer S1003 has proper DMI strings for sys-vendor and product-name,
so we do not need to match by BIOS-date.
This means that the Acer S1003 can use the generic lcd800x1280_rightside_up
drm_dmi_panel_orientation_data struct which is also used by other quirks.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d11d83703931e..d00ea384dcbfe 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -30,12 +30,6 @@ struct drm_dmi_panel_orientation_data {
int orientation;
};
-static const struct drm_dmi_panel_orientation_data acer_s1003 = {
- .width = 800,
- .height = 1280,
- .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
-};
-
static const struct drm_dmi_panel_orientation_data asus_t100ha = {
.width = 800,
.height = 1280,
@@ -114,7 +108,7 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
- .driver_data = (void *)_s1003,
+ .driver_data = (void *)_rightside_up,
}, {/* Asus T100HA */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 08/53] gpu: host1x: Clean up debugfs in error handling path
From: Christophe JAILLET
[ Upstream commit 109be8b23fb2ec8e2d309325ee3b7a49eab63961 ]
host1x_debug_init() must be reverted in an error handling path.
This is already fixed in the remove function since commit 44156eee91ba
("gpu: host1x: Clean up debugfs on removal")
Signed-off-by: Christophe JAILLET
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index d24344e919227..3c0f151847bae 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -468,11 +468,12 @@ static int host1x_probe(struct platform_device *pdev)
err = host1x_register(host);
if (err < 0)
- goto deinit_intr;
+ goto deinit_debugfs;
return 0;
-deinit_intr:
+deinit_debugfs:
+ host1x_debug_deinit(host);
host1x_intr_deinit(host);
deinit_syncpt:
host1x_syncpt_deinit(host);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 33/53] drm: panel-orientation-quirks: Add quirk for Asus T101HA panel
From: Hans de Goede
[ Upstream commit 6c22bc18a3b93a38018844636557ad02e588e055 ]
Like the Asus T100HA the Asus T101HA also uses a panel which has been
mounted 90 degrees rotated, albeit in the opposite direction.
Add a quirk for this.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20200531093025.28050-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index ffd95bfeaa94c..d11d83703931e 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -121,6 +121,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+ }, {/* Asus T101HA */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T101HA"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* GPD MicroPC (generic strings, also match on bios date) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 38/53] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
From: Maxime Ripard
[ Upstream commit 842ec61f4006a6477a9deaedd69131e9f46e4cb5 ]
The main DRM device is actually a virtual device so it doesn't have the
iommus property, which is instead on the DMA masters, in this case the
mixers.
Add a call to of_dma_configure with the mixers DT node but on the DRM
virtual device to configure it in the same way than the mixers.
Reviewed-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.max...@cerno.tech
(cherry picked from commit b718102dbdfd0285ad559687a30e27cc9124e592)
[Maxime: Applied to -fixes since it missed the merge window and display is
broken without it]
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 4a64f7ae437a8..19b3b41847046 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -452,6 +452,19 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
mixer->engine.ops = _engine_ops;
mixer->engine.node = dev->of_node;
+ if (of_find_property(dev->of_node, "iommus", NULL)) {
+ /*
+* This assume we have the same DMA constraints for
+* all our the mixers in our pipeline. This sounds
+* bad, but it has always been the case for us, and
+* DRM doesn't do per-device allocation either, so we
+* would need to fix DRM first...
+*/
+ ret = of_dma_configure(drm->dev, dev->of_node, true);
+ if (ret)
+ return ret;
+ }
+
/*
* While this function can fail, we shouldn't do anything
* if this happens. Some early DE2 DT entries don't provide
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 06/53] drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reserved
From: Xiyu Yang [ Upstream commit 37cc4b95d13f311c04aa8e9daacca3905ad45ca7 ] ttm_bo_vm_fault_reserved() invokes dma_fence_get(), which returns a reference of the specified dma_fence object to "moving" with increased refcnt. When ttm_bo_vm_fault_reserved() returns, local variable "moving" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in several exception handling paths of ttm_bo_vm_fault_reserved(). When those error scenarios occur such as "err" equals to -EBUSY, the function forgets to decrease the refcnt increased by dma_fence_get(), causing a refcnt leak. Fix this issue by calling dma_fence_put() when no_wait_gpu flag is equals to true. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/370219/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 0ad30b1129821..72100b84c7a90 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -300,8 +300,10 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf, break; case -EBUSY: case -ERESTARTSYS: + dma_fence_put(moving); return VM_FAULT_NOPAGE; default: + dma_fence_put(moving); return VM_FAULT_SIGBUS; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 09/53] drm/tegra: hub: Do not enable orphaned window group
From: Nicolin Chen
[ Upstream commit ef4e417eb3ec7fe657928f10ac1d2154d8a5fb38 ]
Though the unconditional enable/disable code is not a final solution,
we don't want to run into a NULL pointer situation when window group
doesn't link to its DC parent if the DC is disabled in Device Tree.
So this patch simply adds a check to make sure that window group has
a valid parent before running into tegra_windowgroup_enable/disable.
Signed-off-by: Nicolin Chen
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/hub.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 8183e617bf6b8..a2ef8f218d4ec 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -149,7 +149,9 @@ int tegra_display_hub_prepare(struct tegra_display_hub *hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_enable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_enable(wgrp);
}
return 0;
@@ -166,7 +168,9 @@ void tegra_display_hub_cleanup(struct tegra_display_hub
*hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
- tegra_windowgroup_disable(wgrp);
+ /* Skip orphaned window group whose parent DC is disabled */
+ if (wgrp->parent)
+ tegra_windowgroup_disable(wgrp);
}
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: ratelimit crtc event overflow error
On 2020-07-01 13:36, Rob Clark wrote:
From: Rob Clark
This can happen a lot when things go pear shaped. Lets not flood dmesg
when this happens.
Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e15b42a780e0..969d95aa873c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -389,7 +389,7 @@ static void dpu_crtc_frame_event_cb(void *data, u32
event)
spin_unlock_irqrestore(_crtc->spin_lock, flags);
if (!fevent) {
- DRM_ERROR("crtc%d event %d overflow\n", crtc->base.id, event);
+ DRM_ERROR_RATELIMITED("crtc%d event %d overflow\n", crtc->base.id,
event);
return;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: allows LP commands in video mode
Hi Yannick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc3 next-20200701]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Yannick-Fertre/drm-bridge-synopsys-dsi-allows-LP-commands-in-video-mode/20200701-231547
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7c30b859a947535f2213277e827d7ac7dcff9c84
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c: In function
'dw_mipi_message_config':
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:374:10: error:
>> 'ENABLE_LOW_POWER_CMD' undeclared (first use in this function); did you mean
>> 'ENABLE_LOW_POWER_MASK'?
374 | val |= ENABLE_LOW_POWER_CMD;
| ^~~~
| ENABLE_LOW_POWER_MASK
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:374:10: note: each undeclared
identifier is reported only once for each function it appears in
vim +374 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
357
358 static void dw_mipi_message_config(struct dw_mipi_dsi *dsi,
359 const struct mipi_dsi_msg *msg)
360 {
361 bool lpm = msg->flags & MIPI_DSI_MSG_USE_LPM;
362 u32 val = 0;
363
364 if (msg->flags & MIPI_DSI_MSG_REQ_ACK)
365 val |= ACK_RQST_EN;
366 if (lpm)
367 val |= CMD_MODE_ALL_LP;
368
369 dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
370 dsi_write(dsi, DSI_CMD_MODE_CFG, val);
371
372 val = dsi_read(dsi, DSI_VID_MODE_CFG);
373 if (lpm)
> 374 val |= ENABLE_LOW_POWER_CMD;
375 else
376 val &= ~ENABLE_LOW_POWER_CMD;
377 dsi_write(dsi, DSI_VID_MODE_CFG, val);
378 }
379
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 00/59] Add support for Keem Bay DRM driver
Thanks much Sam for reviewing the code so quickly. I'll address your reviews in v2. Anitha > -Original Message- > From: Sam Ravnborg > Sent: Wednesday, July 1, 2020 12:01 AM > To: Chrisanthus, Anitha > Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J ; > Dea, Edmund J ; Vetter, Daniel > ; intel-...@lists.freedesktop.org; Vivi, Rodrigo > > Subject: Re: [PATCH 00/59] Add support for Keem Bay DRM driver > > Hi Anitha. > > On Tue, Jun 30, 2020 at 02:27:12PM -0700, Anitha Chrisanthus wrote: > > This is a new DRM driver for Intel's KeemBay SOC. > > The SoC couples an ARM Cortex A53 CPU with an Intel > > Movidius VPU. > ... > Nice and informative intro - thanks. > > The patchset looks more like a dump of current state and less like a > logical set of changes - as the few I looked at changed code introduced > in earlier patches. > So I ended up applying all patches to a local branch. > Very good to post an WIP version so you can capture some early > feedback. > It is never fun to think something is finished and then address a lot of > feedback. > > > Some general remarks after reading/browsing some of the code: > - Embeds drm_device - good > - Uses SPDX, good. But includes also a license text. Can we > get rid of the redundandt license text? > - Some of the inline functions in kmb_drv.h is too large > (kmb_write_bits_mipi()) > - There is stray code commented out using "//" here and there - shall be > dropped. > - Please arrange include files in blocks: > #include > > #include > > #include > > #include "kmb_*" > > Within each block sort alphabetially. > > - Use a kmb_ prefix or similar for global variables - like under_flow > - no extern in .c files - plane_status > - Consider using an array for the clk's > - In general use drm_info(), drm_err() for logging. > Yes, you will need to pass kmb_drm_private around to do so > - Do not use drm_device->dev_private, it is deprecated. Use upclassing > - kmb_driver can be slimmed a lot. See what recent drivers uses. There is > some nice defines so it is obvious what is not standard. > DRIVER_HAVE_IRQ is not relevant btw. > - Start using drmm_* support. The way kmb_drm_private is allocated > is sub-optimal > > The above was my fist drive-by comments - but do not be discouraged. > For the most part they should be easy to address. > Looking forward for other feedback and for v2. > > Let me know if the above triggers any questions. > > > +--++-++---+ > > |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | > > +--++-++---+ > > Question to dri-devel people: > Would the Mipi DSI be better represented outside the display driver? > If yes, how? > > Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: ratelimit crtc event overflow error
From: Rob Clark
This can happen a lot when things go pear shaped. Lets not flood dmesg
when this happens.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e15b42a780e0..969d95aa873c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -389,7 +389,7 @@ static void dpu_crtc_frame_event_cb(void *data, u32 event)
spin_unlock_irqrestore(_crtc->spin_lock, flags);
if (!fevent) {
- DRM_ERROR("crtc%d event %d overflow\n", crtc->base.id, event);
+ DRM_ERROR_RATELIMITED("crtc%d event %d overflow\n",
crtc->base.id, event);
return;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 00/11] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Hi Heiko, On Wed, 01 Jul 2020, Heiko Stübner wrote: Hi Adrian, Am Dienstag, 9. Juni 2020, 19:49:48 CEST schrieb Adrian Ratiu: [Re-submitting to cc dri-devel, sorry about the noise] Hello all, v9 cleanly applies on top of latest next-20200609 tree. at least it doesn't apply on top of current drm-misc-next for me which I really don't understand. Like patch 2/11 does @@ -31,6 +31,7 @@ #include . #define HWVER_131<><--><-->0x31333100<>/* IP version 1.31 */ +#define HWVER_130<><--><-->0x31333000<>/* IP version 1.30 */ . #define DSI_VERSION<--><--><-->0x00 #define VERSION<--><--><--><-->GENMASK(31, 8) where the file currently looks like #include #include #include #include #include #include #include #define HWVER_131 0x31333100 /* IP version 1.31 */ #define DSI_VERSION 0x00 #define VERSION GENMASK(31, 8) even in Linux-next So I guess ideally rebase on top of drm-misc-next I will send a rebase on top of drm-misc-next soon (with the last DTS nitpick fixed and the latest acks and reviewed-by tags added). In the meantime I also found someone within Collabora who has a RK with a DSI panel and found a bug (likely clock is not enabled early enough to access the cfg registers to get the version for regmap). I'm super happy this is getting tested on RK, thank you! Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
OK, I think I see what's going on. In the Xorg modesetting driver, the
logic is basically:
if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
} else {
drmModeAddFB(...);
}
There's no attempt to verify the DRM-KMS device supports the modifier,
but then, why would there be? GBM presumably chose a supported modifier
at buffer creation time, and we don't know which plane the FB is going
to be used with yet. GBM doesn't actually ask the kernel which
modifiers it supports here either though. It just goes into Mesa via
DRI and reports the modifier (unpatched) Mesa chose on its own. Mesa
just hard-codes the modifiers in its driver backends since its thinking
in terms of a device's 3D engine, not display. In theory, Mesa's DRI
drivers could query KMS for supported modifiers if allocating from GBM
using the non-modifiers path and the SCANOUT flag is set (perhaps some
drivers do this or its equivalent? Haven't checked.), but that seems
pretty gnarly and doesn't fix the modifier-based GBM allocation path
AFAIK. Bit of a mess.
For a quick userspace fix that could probably be pushed out everywhere
(Only affects Xorg server 1.20+ AFAIK), just retrying
drmModeAddFB2WithModifiers() without the DRM_MODE_FB_MODIFIERS flag on
failure should be sufficient. Still need to verify as I'm having
trouble wrangling my Xorg build at the moment and I'm pressed for time.
A more complete fix would be quite involved, as modesetting isn't really
properly plumbed to validate GBM's modifiers against KMS planes, and it
doesn't seem like GBM/Mesa/DRI should be responsible for this as noted
above given the general modifier workflow/design.
Most importantly, options I've considered for fixing from the kernel side:
-Accept "legacy" modifiers in nouveau in addition to the new modifiers,
though avoid reporting them to userspace as supported to avoid further
proliferation. This is pretty straightforward. I'll need to modify
both the AddFB2 handler (nouveau_validate_decode_mod) and the mode set
plane validation logic (nv50_plane_format_mod_supported), but it should
end up just being a few lines of code.
-Don't validate modifiers in AddFB. This doesn't really gain anything
because it just pushes the failure down to mode set time, so it's not
that useful, so I don't plan on pursuing this.
As noted, need to run just now, but I should have a kernel patch to test
out either tonight or tomorrow.
If anyone's curious, the reason my testing missed this was I did most of
my verification of "old" code against the Xorg 1.19 build included with
my distro. I did hack up a Xorg 1.20-ish build to test as well that
would have included this path, but I must not have properly configured
it with GBM modifier support somehow. I was pretty focused on just
testing the forcibly-disabled atomic path in the modesetting driver in
this build, so I didn't look too closely at things beyond that.
Thanks,
-James
On 7/1/20 12:59 AM, Kirill A. Shutemov wrote:
On Wed, Jul 01, 2020 at 10:57:19AM +0300, Kirill A. Shutemov wrote:
On Tue, Jun 30, 2020 at 09:40:19PM -0700, James Jones wrote:
This implies something is trying to use one of the old
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without
first checking whether it is supported by the kernel. I had tried to force
an Xorg+Mesa stack without my userspace patches to hit this error when
testing, but must have missed some permutation. If the stalled Mesa patches
go in, this would stop happening of course, but those were held up for a
long time in review, and are now waiting on me to make some modifications.
Are you using the modesetting driver in X? If so, with glamor I presume?
Yes and yes. I attached Xorg.log.
Attached now.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.8
Hi Dave, Daniel, Fixes for 5.8. The following changes since commit 5b83c254571b26e6b6110019929dc9729e5c59d1: Merge tag 'amd-drm-fixes-5.8-2020-06-24' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-06-25 14:51:14 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.8-2020-07-01 for you to fetch changes up to beaf10efca64ac824240838ab1f054dfbefab5e6: drm/amdgpu: use %u rather than %d for sclk/mclk (2020-07-01 14:20:23 -0400) amd-drm-fixes-5.8-2020-07-01: amdgpu: - Fix for vega20 boards without RAS support - DC bandwidth revalidation fix - Fix Renoir vram info fetching - Fix hwmon freq printing Alex Deucher (2): drm/amdgpu/atomfirmware: fix vram_info fetching for renoir drm/amdgpu: use %u rather than %d for sclk/mclk Ivan Mironov (1): drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS Nicholas Kazlauskas (1): drm/amd/display: Only revalidate bandwidth on medium and fast updates drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 4 ++-- drivers/gpu/drm/amd/display/dc/core/dc.c | 10 ++ drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c | 11 +++ 4 files changed, 16 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: add support for non-continuous HS clock
From: Antonio Borneo
Current code enables the HS clock when video mode is started or to
send out a HS command, and disables the HS clock to send out a LP
command. This is not what DSI spec specify.
Enable HS clock either in command and in video mode.
Set automatic HS clock management for panels and devices that
support non-continuous HS clock.
Signed-off-by: Antonio Borneo
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d580b2aa4ce9..979acaa90d00 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -365,7 +365,6 @@ static void dw_mipi_message_config(struct dw_mipi_dsi *dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
- dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
dsi_write(dsi, DSI_CMD_MODE_CFG, val);
}
@@ -541,16 +540,22 @@ static void dw_mipi_dsi_video_mode_config(struct
dw_mipi_dsi *dsi)
static void dw_mipi_dsi_set_mode(struct dw_mipi_dsi *dsi,
unsigned long mode_flags)
{
+ u32 val;
+
dsi_write(dsi, DSI_PWR_UP, RESET);
if (mode_flags & MIPI_DSI_MODE_VIDEO) {
dsi_write(dsi, DSI_MODE_CFG, ENABLE_VIDEO_MODE);
dw_mipi_dsi_video_mode_config(dsi);
- dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
} else {
dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
}
+ val = PHY_TXREQUESTCLKHS;
+ if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
+ val |= AUTO_CLKLANE_CTRL;
+ dsi_write(dsi, DSI_LPCLK_CTRL, val);
+
dsi_write(dsi, DSI_PWR_UP, POWERUP);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: allow LP commands in video mode
From: Antonio Borneo Current code only sends LP commands in command mode. Allows sending LP commands also in video mode by setting the proper flag in DSI_VID_MODE_CFG. Signed-off-by: Antonio Borneo --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index d580b2aa4ce9..0cd43e7a69bb 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -367,6 +367,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi *dsi, dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS); dsi_write(dsi, DSI_CMD_MODE_CFG, val); + + val = dsi_read(dsi, DSI_VID_MODE_CFG); + if (lpm) + val |= ENABLE_LOW_POWER_CMD; + else + val &= ~ENABLE_LOW_POWER_CMD; + dsi_write(dsi, DSI_VID_MODE_CFG, val); } static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #35 from Duncan (1i5t5.dun...@cox.net) --- (In reply to mnrzk from comment #34) > Has anyone tried 5.8-rc3? I've been testing it out for the past 3 hours and > it seems stable to me. I have now (well, v5.8.0-rc3-00017-g7c30b859a). Unfortunately got a freeze with our familiar trace fairly quickly (building kde updates at the time) so it's not fixed yet. =:^( -- 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] drm/vc4/vc4_hdmi: fill ASoC card owner
Hi Marek,
Am 01.07.20 um 09:39 schrieb Marek Szyprowski:
> card->owner is a required property and since commit 81033c6b584b ("ALSA:
> core: Warn on empty module") a warning is issued if it is empty. Fix lack
> of it. This fixes following warning observed on RaspberryPi 3B board
> with ARM 32bit kernel and multi_v7_defconfig:
>
> [ cut here ]
> WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 snd_card_new+0x378/0x398
> [snd]
> Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine bluetooth
> snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore ecdh_generic
> ecc bcm2835_thermal phy_generic
> CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 5.8.0-rc1-00027-g81033c6b584b
> #1087
> Hardware name: BCM2835
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xd4/0xe8)
> [] (dump_stack) from [] (__warn+0xdc/0xf4)
> [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
> [] (warn_slowpath_fmt) from [] (snd_card_new+0x378/0x398
> [snd])
> [] (snd_card_new [snd]) from []
> (snd_soc_bind_card+0x280/0x99c [snd_soc_core])
> [] (snd_soc_bind_card [snd_soc_core]) from []
> (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core])
> [] (devm_snd_soc_register_card [snd_soc_core]) from []
> (vc4_hdmi_bind+0x43c/0x5f4 [vc4])
> [] (vc4_hdmi_bind [vc4]) from []
> (component_bind_all+0xec/0x24c)
> [] (component_bind_all) from [] (vc4_drm_bind+0xd4/0x174
> [vc4])
> [] (vc4_drm_bind [vc4]) from []
> (try_to_bring_up_master+0x160/0x1b0)
> [] (try_to_bring_up_master) from []
> (component_master_add_with_match+0xd0/0x104)
> [] (component_master_add_with_match) from []
> (vc4_platform_drm_probe+0x9c/0xbc [vc4])
> [] (vc4_platform_drm_probe [vc4]) from []
> (platform_drv_probe+0x6c/0xa4)
> [] (platform_drv_probe) from [] (really_probe+0x210/0x350)
> [] (really_probe) from [] (driver_probe_device+0x5c/0xb4)
> [] (driver_probe_device) from []
> (device_driver_attach+0x58/0x60)
> [] (device_driver_attach) from []
> (__driver_attach+0x80/0xbc)
> [] (__driver_attach) from [] (bus_for_each_dev+0x68/0xb4)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x130/0x1e8)
> [] (bus_add_driver) from [] (driver_register+0x78/0x110)
> [] (driver_register) from [] (do_one_initcall+0x50/0x220)
> [] (do_one_initcall) from [] (do_init_module+0x60/0x210)
> [] (do_init_module) from [] (load_module+0x1e34/0x2338)
> [] (load_module) from [] (sys_finit_module+0xac/0xbc)
> [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x54)
> Exception stack(0xeded9fa8 to 0xeded9ff0)
> ...
> ---[ end trace 6414689569c2bc08 ]---
>
> Suggested-by: Takashi Iwai
> Signed-off-by: Marek Szyprowski
thanks for this patch. Any chance for a fixes tag here?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Wed, Jul 1, 2020 at 7:37 PM James Jones wrote: > > On 7/1/20 10:04 AM, Karol Herbst wrote: > > On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: > >> > >> On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: > >>> > >>> On 7/1/20 4:24 AM, Karol Herbst wrote: > On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > > > > This implies something is trying to use one of the old > > DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without > > first checking whether it is supported by the kernel. I had tried to > > force an Xorg+Mesa stack without my userspace patches to hit this error > > when testing, but must have missed some permutation. If the stalled > > Mesa patches go in, this would stop happening of course, but those were > > held up for a long time in review, and are now waiting on me to make > > some modifications. > > > > that's completely irrelevant. If a kernel change breaks userspace, > it's a kernel bug. > >>> > >>> Agreed it is unacceptable to break userspace, but I don't think it's > >>> irrelevant. Perhaps the musings on pending userspace patches are. > >>> > >>> My intent here was to point out it appears at first glance that > >>> something isn't behaving as expected in userspace, so fixing this would > >>> likely require some sort of work-around for broken userspace rather than > >>> straight-forward fixing of a bug in the kernel logic. My intent was not > >>> to shift blame to something besides my code & testing for the > >>> regression, though I certainly see how it could be interpreted that way. > >>> > >>> Regardless, I'm looking in to it. > >> > > > > I assume the MR you were talking about is > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3724 ? > > Correct. > > > I am > > also aware of the tegra driver being broken on my jetson nano and I am > > now curious if this MR could fix this bug as well... and sorry for the > > harsh reply, I was just a annoyed by the fact that "everything > > modifier related is just breaking things", first tegra and that nobody > > is looking into fixing it and then apparently the userspace code being > > quite broken as well :/ > > > > Anyway, yeah I trust you guys on figuring out the keeping "broken" > > userspace happy from a kernel side and maybe I can help out with > > reviewing the mesa bits. I am just wondering if it could help with the > > tegra situation giving me more reasons to look into it as this would > > solve other issues I should be working on :) > > Not sure if you're claiming this, but if there's Tegra breakage > attributable to this patch series, I'd love to hear more details there > as well. The Tegra patches did have backwards-compat code to handle the > old modifiers, since Tegra was the only working use case I could find > for them within the kernel itself. However, the Tegra kernel patches > are independent (and haven't even been reviewed yet to my knowledge), so > Tegra shouldn't be affected at all given it uses TegraDRM rather than > Nouveau's modesetting driver. > > If there are just general existing issues with modifier support on > Tegra, let's take that to a smaller venue. I probably won't be as much > help there, but I can at least try to help get some eyes on it. > I am sure that your patches here have nothing to do with it, just inside mesa since https://gitlab.freedesktop.org/mesa/mesa/commit/c56fe4118a2dd991ff1b2a532c0f234eddd435e9 it's broken on the jetson nano and because it's so old I am not able to tell if this is because of some kernel changes or because of the modifier code inside mesa being slightly broken. Maybe you have an idea, but Thierry knows about the issue, but I think he never was able to reproduce it on any system. > Thanks, > -James > > >> If we do need to have a kernel workaround I'm happy to help out, I've > >> done a bunch of these and occasionally it's good to get rather > >> creative :-) > >> > >> Ideally we'd also push a minimal fix in userspace to all stable > >> branches and make sure distros upgrade (might need releases if some > >> distro is stuck on old horrors), so that we don't have to keep the > >> hack in place for 10+ years or so. Definitely if the hack amounts to > >> disabling modifiers on nouveau, that would be kinda sad. > >> -Daniel > >> > >>> > >>> Thanks, > >>> -James > >>> > > Are you using the modesetting driver in X? If so, with glamor I > > presume? What version of Mesa? Any distro patches? Any non-default > > xorg.conf options that would affect modesetting, your X driver if it > > isn't modesetting, or glamour? > > > > Thanks, > > -James > > > > On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: > >> On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: > >>> James Jones (4): > >> ... > >>> drm/nouveau/kms: Support NVIDIA format modifiers > >> > >> This commit is the first one that breaks Xorg startup
Re: [git pull] drm for 5.8-rc1
On 7/1/20 10:04 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: On 7/1/20 4:24 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: This implies something is trying to use one of the old DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without first checking whether it is supported by the kernel. I had tried to force an Xorg+Mesa stack without my userspace patches to hit this error when testing, but must have missed some permutation. If the stalled Mesa patches go in, this would stop happening of course, but those were held up for a long time in review, and are now waiting on me to make some modifications. that's completely irrelevant. If a kernel change breaks userspace, it's a kernel bug. Agreed it is unacceptable to break userspace, but I don't think it's irrelevant. Perhaps the musings on pending userspace patches are. My intent here was to point out it appears at first glance that something isn't behaving as expected in userspace, so fixing this would likely require some sort of work-around for broken userspace rather than straight-forward fixing of a bug in the kernel logic. My intent was not to shift blame to something besides my code & testing for the regression, though I certainly see how it could be interpreted that way. Regardless, I'm looking in to it. I assume the MR you were talking about is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3724 ? Correct. I am also aware of the tegra driver being broken on my jetson nano and I am now curious if this MR could fix this bug as well... and sorry for the harsh reply, I was just a annoyed by the fact that "everything modifier related is just breaking things", first tegra and that nobody is looking into fixing it and then apparently the userspace code being quite broken as well :/ Anyway, yeah I trust you guys on figuring out the keeping "broken" userspace happy from a kernel side and maybe I can help out with reviewing the mesa bits. I am just wondering if it could help with the tegra situation giving me more reasons to look into it as this would solve other issues I should be working on :) Not sure if you're claiming this, but if there's Tegra breakage attributable to this patch series, I'd love to hear more details there as well. The Tegra patches did have backwards-compat code to handle the old modifiers, since Tegra was the only working use case I could find for them within the kernel itself. However, the Tegra kernel patches are independent (and haven't even been reviewed yet to my knowledge), so Tegra shouldn't be affected at all given it uses TegraDRM rather than Nouveau's modesetting driver. If there are just general existing issues with modifier support on Tegra, let's take that to a smaller venue. I probably won't be as much help there, but I can at least try to help get some eyes on it. Thanks, -James If we do need to have a kernel workaround I'm happy to help out, I've done a bunch of these and occasionally it's good to get rather creative :-) Ideally we'd also push a minimal fix in userspace to all stable branches and make sure distros upgrade (might need releases if some distro is stuck on old horrors), so that we don't have to keep the hack in place for 10+ years or so. Definitely if the hack amounts to disabling modifiers on nouveau, that would be kinda sad. -Daniel Thanks, -James Are you using the modesetting driver in X? If so, with glamor I presume? What version of Mesa? Any distro patches? Any non-default xorg.conf options that would affect modesetting, your X driver if it isn't modesetting, or glamour? Thanks, -James On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: James Jones (4): ... drm/nouveau/kms: Support NVIDIA format modifiers This commit is the first one that breaks Xorg startup for my setup: GTX 1080 + Dell UP2414Q (4K DP MST monitor). I believe this is the crucial part of dmesg (full dmesg is attached): [ 29.997140] [drm:nouveau_framebuffer_new] Unsupported modifier: 0x314 [ 29.997143] [drm:drm_internal_framebuffer_create] could not create framebuffer [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22 Any suggestions? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing
Re: [PATCH v2] dt-bindings: display: Convert connectors to DT schema
Hi Rob
On Tue, Jun 30, 2020 at 02:02:16PM -0600, Rob Herring wrote:
> Convert the analog TV, DVI, HDMI, and VGA connector bindings to DT schema
> format.
>
> Cc: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Signed-off-by: Rob Herring
Reviewed-by: Sam Ravnborg
> ---
> v2:
> - Make Laurent maintainer
> - Add missing port and compatible required
> - Drop copy-n-paste 'type' from dvi-connector
> - Use 4 space indent on examples
I assume you take this via the DT tree.
Sam
> ---
> .../display/connector/analog-tv-connector.txt | 31
> .../connector/analog-tv-connector.yaml| 52 ++
> .../display/connector/dvi-connector.txt | 36 --
> .../display/connector/dvi-connector.yaml | 70 +++
> .../display/connector/hdmi-connector.txt | 31
> .../display/connector/hdmi-connector.yaml | 64 +
> .../display/connector/vga-connector.txt | 36 --
> .../display/connector/vga-connector.yaml | 46
> 8 files changed, 232 insertions(+), 134 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> create mode 100644
> Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/connector/dvi-connector.txt
> create mode 100644
> Documentation/devicetree/bindings/display/connector/dvi-connector.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> create mode 100644
> Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/connector/vga-connector.txt
> create mode 100644
> Documentation/devicetree/bindings/display/connector/vga-connector.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> deleted file mode 100644
> index 883bcb2604c7..
> ---
> a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -Analog TV Connector
> -===
> -
> -Required properties:
> -- compatible: "composite-video-connector" or "svideo-connector"
> -
> -Optional properties:
> -- label: a symbolic name for the connector
> -- sdtv-standards: limit the supported TV standards on a connector to the
> given
> - ones. If not specified all TV standards are allowed.
> - Possible TV standards are defined in
> - include/dt-bindings/display/sdtv-standards.h.
> -
> -Required nodes:
> -- Video port for TV input
> -
> -Example
>
> -#include
> -
> -tv: connector {
> - compatible = "composite-video-connector";
> - label = "tv";
> - sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
> -
> - port {
> - tv_connector_in: endpoint {
> - remote-endpoint = <_out>;
> - };
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml
>
> b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml
> new file mode 100644
> index ..eebe88fed999
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/display/connector/analog-tv-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog TV Connector
> +
> +maintainers:
> + - Laurent Pinchart
> +
> +properties:
> + compatible:
> +enum:
> + - composite-video-connector
> + - svideo-connector
> +
> + label: true
> +
> + sdtv-standards:
> +description:
> + Limit the supported TV standards on a connector to the given ones. If
> + not specified all TV standards are allowed. Possible TV standards are
> + defined in include/dt-bindings/display/sdtv-standards.h.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> + port:
> +description: Connection to controller providing analog TV signals
> +
> +required:
> + - compatible
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +connector {
> +compatible = "composite-video-connector";
> +label = "tv";
> +sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
> +
> +port {
> +tv_connector_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +
> +...
> diff --git
> a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt
> b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt
> deleted file mode 100644
> index
Re: [PATCH] drm/msm: handle for EPROBE_DEFER for of_icc_get
On Wed, Jul 01, 2020 at 01:13:34PM -0400, Jonathan Marek wrote: > On 7/1/20 1:12 PM, Matthias Kaehlcke wrote: > > Hi Jonathan, > > > > On Tue, Jun 30, 2020 at 11:08:41PM -0400, Jonathan Marek wrote: > > > Check for EPROBE_DEFER instead of silently not using icc if the msm driver > > > probes before the interconnect driver. > > > > Agreed with supporting deferred ICC probing. > > > > > Only check for EPROBE_DEFER because of_icc_get can return other errors > > > that > > > we want to ignore (ENODATA). > > > > What would be the -ENODATA case? > > > > The of_icc_get for the ocmem_icc_path can return -ENODATA when the ocmem > path is not specified (it is optional and only relevant for a3xx/a4xx). Thanks for the clarification! In this case it seems reasonable to me to return any error for the 'gfx-mem' path and all errors except -ENODATA for 'ocmem'. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 00/13] Add support for PinePhone LCD panel
Hi Ondrej. On Wed, Jul 01, 2020 at 06:29:15PM +0200, Ondrej Jirman wrote: > This patchset adds support for the LCD panel of PinePhone. > > I've tested this on PinePhone 1.0 and 1.2. Thanks for this nive sereis. Applied the first 11 patches to drm-misc-next. The DTS files needs to go in via another tree. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: handle for EPROBE_DEFER for of_icc_get
Hi Jonathan, On Tue, Jun 30, 2020 at 11:08:41PM -0400, Jonathan Marek wrote: > Check for EPROBE_DEFER instead of silently not using icc if the msm driver > probes before the interconnect driver. Agreed with supporting deferred ICC probing. > Only check for EPROBE_DEFER because of_icc_get can return other errors that > we want to ignore (ENODATA). What would be the -ENODATA case? If the 'interconnects' property is not specified of_icc_get() returns NULL, shouldn't all (or most) errors be propagated rather than staying silent? Thanks Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: remove redundant initialization of variable result
On Wed, Jul 1, 2020 at 10:59 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable result is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
> index 1b3474aa380d..d0a23b72e604 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
> @@ -151,7 +151,8 @@ bool edp_receiver_ready_T9(struct dc_link *link)
> unsigned int tries = 0;
> unsigned char sinkstatus = 0;
> unsigned char edpRev = 0;
> - enum dc_status result = DC_OK;
> + enum dc_status result;
> +
> result = core_link_read_dpcd(link, DP_EDP_DPCD_REV, ,
> sizeof(edpRev));
>
> /* start from eDP version 1.2, SINK_STAUS indicate the sink is ready.*/
> @@ -177,7 +178,7 @@ bool edp_receiver_ready_T7(struct dc_link *link)
> {
> unsigned char sinkstatus = 0;
> unsigned char edpRev = 0;
> - enum dc_status result = DC_OK;
> + enum dc_status result;
>
> /* use absolute time stamp to constrain max T7*/
> unsigned long long enter_timestamp = 0;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: > > On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: > > > > On 7/1/20 4:24 AM, Karol Herbst wrote: > > > On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > > >> > > >> This implies something is trying to use one of the old > > >> DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without > > >> first checking whether it is supported by the kernel. I had tried to > > >> force an Xorg+Mesa stack without my userspace patches to hit this error > > >> when testing, but must have missed some permutation. If the stalled > > >> Mesa patches go in, this would stop happening of course, but those were > > >> held up for a long time in review, and are now waiting on me to make > > >> some modifications. > > >> > > > > > > that's completely irrelevant. If a kernel change breaks userspace, > > > it's a kernel bug. > > > > Agreed it is unacceptable to break userspace, but I don't think it's > > irrelevant. Perhaps the musings on pending userspace patches are. > > > > My intent here was to point out it appears at first glance that > > something isn't behaving as expected in userspace, so fixing this would > > likely require some sort of work-around for broken userspace rather than > > straight-forward fixing of a bug in the kernel logic. My intent was not > > to shift blame to something besides my code & testing for the > > regression, though I certainly see how it could be interpreted that way. > > > > Regardless, I'm looking in to it. > I assume the MR you were talking about is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3724 ? I am also aware of the tegra driver being broken on my jetson nano and I am now curious if this MR could fix this bug as well... and sorry for the harsh reply, I was just a annoyed by the fact that "everything modifier related is just breaking things", first tegra and that nobody is looking into fixing it and then apparently the userspace code being quite broken as well :/ Anyway, yeah I trust you guys on figuring out the keeping "broken" userspace happy from a kernel side and maybe I can help out with reviewing the mesa bits. I am just wondering if it could help with the tegra situation giving me more reasons to look into it as this would solve other issues I should be working on :) > If we do need to have a kernel workaround I'm happy to help out, I've > done a bunch of these and occasionally it's good to get rather > creative :-) > > Ideally we'd also push a minimal fix in userspace to all stable > branches and make sure distros upgrade (might need releases if some > distro is stuck on old horrors), so that we don't have to keep the > hack in place for 10+ years or so. Definitely if the hack amounts to > disabling modifiers on nouveau, that would be kinda sad. > -Daniel > > > > > Thanks, > > -James > > > > >> Are you using the modesetting driver in X? If so, with glamor I > > >> presume? What version of Mesa? Any distro patches? Any non-default > > >> xorg.conf options that would affect modesetting, your X driver if it > > >> isn't modesetting, or glamour? > > >> > > >> Thanks, > > >> -James > > >> > > >> On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: > > >>> On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: > > James Jones (4): > > >>> ... > > drm/nouveau/kms: Support NVIDIA format modifiers > > >>> > > >>> This commit is the first one that breaks Xorg startup for my setup: > > >>> GTX 1080 + Dell UP2414Q (4K DP MST monitor). > > >>> > > >>> I believe this is the crucial part of dmesg (full dmesg is attached): > > >>> > > >>> [ 29.997140] [drm:nouveau_framebuffer_new] Unsupported modifier: > > >>> 0x314 > > >>> [ 29.997143] [drm:drm_internal_framebuffer_create] could not create > > >>> framebuffer > > >>> [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22 > > >>> > > >>> Any suggestions? > > >>> > > >> ___ > > >> dri-devel mailing list > > >> dri-devel@lists.freedesktop.org > > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > >> > > > > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] interconnect: qcom: add functions to query addr/cmds for a path
On Wed, Jul 01, 2020 at 12:25:25AM -0400, Jonathan Marek wrote:
> The a6xx GMU can vote for ddr and cnoc bandwidth, but it needs to be able
> to query the interconnect driver for bcm addresses and commands.
>
> I'm not sure what is the best way to go about implementing this, this is
> what I came up with.
>
> I included a quick example of how this can be used by the a6xx driver to
> fill out the GMU bw_table (two ddr bandwidth levels in this example, note
> this would be using the frequency table in dts and not hardcoded values).
I would like to add my enthusiasm for this idea but I'm not much of an
interconnect or RPMh expert so I would defer to them to be sure that the APIs
are robust enough to cover all the corner cases.
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 20 ---
> drivers/interconnect/qcom/icc-rpmh.c | 50 +++
> include/soc/qcom/icc.h| 11 ++
> 3 files changed, 68 insertions(+), 13 deletions(-)
> create mode 100644 include/soc/qcom/icc.h
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
> b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
> index ccd44d0418f8..1fb8f0480be3 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
>
> #include "a6xx_gmu.h"
> #include "a6xx_gmu.xml.h"
> @@ -320,24 +321,18 @@ static void a640_build_bw_table(struct
> a6xx_hfi_msg_bw_table *msg)
> msg->cnoc_cmds_data[1][2] = 0x6001;
> }
>
> -static void a650_build_bw_table(struct a6xx_hfi_msg_bw_table *msg)
> +static void a650_build_bw_table(struct a6xx_hfi_msg_bw_table *msg, struct
> icc_path *path)
> {
> /*
>* Send a single "off" entry just to get things running
>* TODO: bus scaling
>*/
> - msg->bw_level_num = 1;
> -
> - msg->ddr_cmds_num = 3;
> + msg->bw_level_num = 2;
> msg->ddr_wait_bitmask = 0x01;
We're going to need a API function for the wait bitmask too.
> - msg->ddr_cmds_addrs[0] = 0x5;
> - msg->ddr_cmds_addrs[1] = 0x50004;
> - msg->ddr_cmds_addrs[2] = 0x5007c;
> -
> - msg->ddr_cmds_data[0][0] = 0x4000;
> - msg->ddr_cmds_data[0][1] = 0x4000;
> - msg->ddr_cmds_data[0][2] = 0x4000;
> + msg->ddr_cmds_num = qcom_icc_query_addr(path, msg->ddr_cmds_addrs);
> + qcom_icc_query_cmd(path, msg->ddr_cmds_data[0], 0, 0);
> + qcom_icc_query_cmd(path, msg->ddr_cmds_data[1], 0, 7216000);
>
> /*
>* These are the CX (CNOC) votes - these are used by the GMU but the
> @@ -388,7 +383,6 @@ static void a6xx_build_bw_table(struct
> a6xx_hfi_msg_bw_table *msg)
> msg->cnoc_cmds_data[1][2] = 0x6001;
> }
>
> -
> static int a6xx_hfi_send_bw_table(struct a6xx_gmu *gmu)
> {
> struct a6xx_hfi_msg_bw_table msg = { 0 };
> @@ -400,7 +394,7 @@ static int a6xx_hfi_send_bw_table(struct a6xx_gmu *gmu)
> else if (adreno_is_a640(adreno_gpu))
> a640_build_bw_table();
> else if (adreno_is_a650(adreno_gpu))
> - a650_build_bw_table();
> + a650_build_bw_table(, adreno_gpu->base.icc_path);
> else
> a6xx_build_bw_table();
>
> diff --git a/drivers/interconnect/qcom/icc-rpmh.c
> b/drivers/interconnect/qcom/icc-rpmh.c
> index 3ac5182c9ab2..3ce2920330f9 100644
> --- a/drivers/interconnect/qcom/icc-rpmh.c
> +++ b/drivers/interconnect/qcom/icc-rpmh.c
> @@ -9,6 +9,7 @@
>
> #include "bcm-voter.h"
> #include "icc-rpmh.h"
> +#include "../internal.h"
>
> /**
> * qcom_icc_pre_aggregate - cleans up stale values from prior icc_set
> @@ -92,6 +93,55 @@ int qcom_icc_set(struct icc_node *src, struct icc_node
> *dst)
> }
> EXPORT_SYMBOL_GPL(qcom_icc_set);
>
> +static u32 bcm_query(struct qcom_icc_bcm *bcm, u64 sum_avg, u64 max_peak)
> +{
> + u64 temp, agg_peak = 0;
> + int i;
> +
> + for (i = 0; i < bcm->num_nodes; i++) {
> + temp = max_peak * bcm->aux_data.width;
> + do_div(temp, bcm->nodes[i]->buswidth);
> + agg_peak = max(agg_peak, temp);
> + }
> +
> + temp = agg_peak * 1000ULL;
> + do_div(temp, bcm->aux_data.unit);
> +
> + // TODO vote_x
> +
> + return BCM_TCS_CMD(true, temp != 0, 0, temp);
> +}
> +
> +int qcom_icc_query_addr(struct icc_path *path, u32 *addr)
The leaf driver won't know the size of the path, so we'll likely need to kmalloc
and return the array or allow addr to be NULL and have the leaf driver do the
allocation itself once it knows what k is.
> +{
> + struct qcom_icc_node *qn;
> + int i, j, k = 0;
> +
> + for (i = 0; i < path->num_nodes; i++) {
> + qn = path->reqs[i].node->data;
> + for (j = 0; j < qn->num_bcms; j++, k++)
> + addr[k] = qn->bcms[j]->addr;
> + }
> +
> + return k;
> +}
> +EXPORT_SYMBOL_GPL(qcom_icc_query_addr);
> +
> +int qcom_icc_query_cmd(struct icc_path
Re: [PATCH] drm/connector: Add of_drm_find_connector
Hi Andy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc3 next-20200701]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Andy-Yan/drm-connector-Add-of_drm_find_connector/20200701-151333
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7c30b859a947535f2213277e827d7ac7dcff9c84
config: x86_64-randconfig-a002-20200701 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
c8f1d442d0858f66fd4128fde6f67eb5202fa2b1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_connector.c:756:23: warning: no previous prototype for
>> function 'of_drm_find_connector' [-Wmissing-prototypes]
struct drm_connector *of_drm_find_connector(struct drm_device *dev, const
struct device_node *np)
^
drivers/gpu/drm/drm_connector.c:756:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
struct drm_connector *of_drm_find_connector(struct drm_device *dev, const
struct device_node *np)
^
static
1 warning generated.
vim +/of_drm_find_connector +756 drivers/gpu/drm/drm_connector.c
745
746 #ifdef CONFIG_OF
747 /**
748 * of_drm_find_connector - look up a connector using a device tree node
749 * @np: device tree node of the connector
750 *
751 *
752 * Return: A pointer to the connector which match the specified device
tree
753 * node or NULL if no panel matching the device tree node can be found,
or
754 * -ENODEV: the device is not available (status != "okay" or "ok")
755 */
> 756 struct drm_connector *of_drm_find_connector(struct drm_device *dev,
> const struct device_node *np)
757 {
758 struct drm_connector *connector;
759 struct drm_connector_list_iter conn_iter;
760
761 if (!of_device_is_available(np))
762 return ERR_PTR(-ENODEV);
763
764 drm_connector_list_iter_begin(dev, _iter);
765 drm_for_each_connector_iter(connector, _iter) {
766 if (connector->of_node == np) {
767 drm_connector_list_iter_end(_iter);
768 return connector;
769 }
770 }
771 drm_connector_list_iter_end(_iter);
772
773 return NULL;
774 }
775 EXPORT_SYMBOL(of_drm_find_connector);
776 #endif
777
778
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
On Wed, Jul 1, 2020 at 6:30 PM Ondřej Jirman wrote: > On Wed, Jul 01, 2020 at 05:25:32PM +0200, Sam Ravnborg wrote: > > Hi Ondrej. > > > > On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > > > This patchset adds support for the LCD panel of PinePhone. > > > > > > I've tested this on PinePhone 1.0 and 1.2. > > > > > > Please take a look. > > > > > > thank you and regards, > > > Ondrej Jirman > > > > > > Changes in v6: > > > - Fixed spacing in yaml > > > - Fixed wrong vccio->iovcc supply name in the bindings doc > > > - I noticed that the original driver uses a delay of 20ms in the init > > > function to achieve a combined total of 120ms required from post-reset > > > to display_on. I've added a similar delay to xbd599_init, so that > > > xbd599 panel also has the right timing. (patch 9) > > > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > > > - Added review/ack tags > > > - Learned to run dt_binding_check by myself ;) > > The patch-set does not apply clean on top of drm-misc-next - due to > > vrefresh removal. > > Please re-spin. > > Sorry for that. Rebased and retested. Sam will you apply it? I was in the middle of applying and ran into the same issue :D Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/msm: dsi: Use OPP API to set clk/perf state
On Tue, Jun 30, 2020 at 05:26:14PM +0530, Rajendra Nayak wrote:
> On SDM845 DSI needs to express a perforamnce state
nit: performance
> requirement on a power domain depending on the clock rates.
> Use OPP table from DT to register with OPP framework and use
> dev_pm_opp_set_rate() to set the clk/perf state.
>
> Signed-off-by: Rajendra Nayak
> ---
> drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
> drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 +--
> drivers/gpu/drm/msm/dsi/dsi_host.c | 58
> ++
> 3 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 4de771d..ba7583c 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -180,10 +180,12 @@ int msm_dsi_runtime_suspend(struct device *dev);
> int msm_dsi_runtime_resume(struct device *dev);
> int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host);
> int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host);
> +int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host);
> int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
> int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
> void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
> void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
> +void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host);
> int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
> int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
> void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> index 813d69d..773c4fe 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> @@ -210,9 +210,9 @@ static const struct msm_dsi_host_cfg_ops
> msm_dsi_6g_host_ops = {
> };
>
> static const struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
> - .link_clk_set_rate = dsi_link_clk_set_rate_6g,
> + .link_clk_set_rate = dsi_link_clk_set_rate_6g_v2,
> .link_clk_enable = dsi_link_clk_enable_6g,
> - .link_clk_disable = dsi_link_clk_disable_6g,
> + .link_clk_disable = dsi_link_clk_disable_6g_v2,
> .clk_init_ver = dsi_clk_init_6g_v2,
> .tx_buf_alloc = dsi_tx_buf_alloc_6g,
> .tx_buf_get = dsi_tx_buf_get_6g,
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 11ae5b8..890531c 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -111,6 +112,9 @@ struct msm_dsi_host {
> struct clk *pixel_clk_src;
> struct clk *byte_intf_clk;
>
> + struct opp_table *opp_table;
> + bool has_opp_table;
> +
> u32 byte_clk_rate;
> u32 pixel_clk_rate;
> u32 esc_clk_rate;
> @@ -537,6 +541,38 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host
> *msm_host)
> return 0;
> }
>
> +int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host)
> +{
> + int ret;
> + struct device *dev = _host->pdev->dev;
> +
> + DBG("Set clk rates: pclk=%d, byteclk=%d",
> + msm_host->mode->clock, msm_host->byte_clk_rate);
> +
> + ret = dev_pm_opp_set_rate(dev, msm_host->byte_clk_rate);
> + if (ret) {
> + pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
> + return ret;
> + }
> +
> + ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
> + if (ret) {
> + pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
> + return ret;
> + }
> +
> + if (msm_host->byte_intf_clk) {
> + ret = clk_set_rate(msm_host->byte_intf_clk,
> +msm_host->byte_clk_rate / 2);
> + if (ret) {
> + pr_err("%s: Failed to set rate byte intf clk, %d\n",
> +__func__, ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
xThis function is essentially the same as dsi_link_clk_set_rate_6g(),
except for the use of dev_pm_opp_set_rate() instead of clk_set_rate().
IIUC dev_pm_opp_set_rate() just calls clk_set_rate() if the device has
no OPP table. If that's correct you could just call dev_pm_opp_set_rate()
in dsi_link_clk_set_rate_6g().
/*
* For IO devices which require an OPP on some platforms/SoCs
* while just needing to scale the clock on some others
* we look for empty OPP tables with just a clock handle and
* scale only the clk. This makes dev_pm_opp_set_rate()
* equivalent to a clk_set_rate()
*/
if (!_get_opp_count(opp_table)) {
ret = _generic_set_opp_clk_only(dev, clk, freq);
goto put_opp_table;
}
Re: [PATCH v6 02/13] dt-bindings: panel: Convert rocktech,jh057n00900 to yaml
On Wed, Jul 01, 2020 at 05:58:57PM +0200, Guido Günther wrote: > Hi Ondrej, > On Wed, Jul 01, 2020 at 12:31:15PM +0200, Ondrej Jirman wrote: > > Convert Rocktech MIPI DSI panel driver from txt to yaml bindings. > > > > Signed-off-by: Ondrej Jirman > > --- > > .../display/panel/rocktech,jh057n00900.txt| 23 --- > > .../display/panel/rocktech,jh057n00900.yaml | 66 +++ > > 2 files changed, 66 insertions(+), 23 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > > Thanks for the conversion! Shouldn't we switch to `sitronix-st7703.yaml` > as well in this patch? That would be good if this rename is included. Otherwise we will just have to do it later. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 10/13] drm/panel: st7703: Enter sleep after display off
Hi,
On Wed, Jul 01, 2020 at 12:31:23PM +0200, Ondrej Jirman wrote:
> The datasheet suggests to issue sleep in after display off
> as a part of the panel's shutdown sequence.
Out of curiosity: which exact datasheet did you use?
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 5cd5503f894f..0c4167994d01 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -395,8 +395,19 @@ static int st7703_disable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + int ret;
> +
> + ret = mipi_dsi_dcs_set_display_off(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(ctx->dev,
> + "Failed to turn off the display: %d\n", ret);
>
> - return mipi_dsi_dcs_set_display_off(dsi);
> + ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(ctx->dev,
> + "Failed to enter sleep mode: %d\n", ret);
> +
> + return 0;
> }
>
> static int st7703_unprepare(struct drm_panel *panel)
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/13] drm/panel: st7703: Assert reset prior to powering down the regulators
Hi, On Wed, Jul 01, 2020 at 12:31:24PM +0200, Ondrej Jirman wrote: > The reset pin is inverted, so if we don't assert reset, the actual gpio > will be high and may keep driving the IO port of the panel. Reviewed-by: Guido Günther > > Signed-off-by: Ondrej Jirman > Reviewed-by: Linus Walleij > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 0c4167994d01..e303b7b1a215 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -417,6 +417,7 @@ static int st7703_unprepare(struct drm_panel *panel) > if (!ctx->prepared) > return 0; > > + gpiod_set_value_cansleep(ctx->reset_gpio, 1); > regulator_disable(ctx->iovcc); > regulator_disable(ctx->vcc); > ctx->prepared = false; > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/13] drm/panel: st7703: Add support for Xingbangda XBD599
Hi,
On Wed, Jul 01, 2020 at 12:31:22PM +0200, Ondrej Jirman wrote:
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel used in
> PinePhone. Add support for it.
Reviewed-by: Guido Günther
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 200 +-
> 1 file changed, 198 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index cdbf7dfb4dd4..5cd5503f894f 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -39,10 +39,11 @@
> #define ST7703_CMD_SETEXTC0xB9
> #define ST7703_CMD_SETMIPI0xBA
> #define ST7703_CMD_SETVDC 0xBC
> -#define ST7703_CMD_UNKNOWN0 0xBF
> +#define ST7703_CMD_UNKNOWN_BF 0xBF
> #define ST7703_CMD_SETSCR 0xC0
> #define ST7703_CMD_SETPOWER 0xC1
> #define ST7703_CMD_SETPANEL 0xCC
> +#define ST7703_CMD_UNKNOWN_C6 0xC6
> #define ST7703_CMD_SETGAMMA 0xE0
> #define ST7703_CMD_SETEQ 0xE3
> #define ST7703_CMD_SETGIP10xE9
> @@ -109,7 +110,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> msleep(20);
>
> dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> - dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN0, 0x02, 0x11, 0x00);
> + dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> 0x82, 0x10, 0x06, 0x05, 0x9E, 0x0A, 0xA5, 0x12,
> 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> @@ -163,6 +164,200 @@ struct st7703_panel_desc jh057n00900_panel_desc = {
> .init_sequence = jh057n_init_sequence,
> };
>
> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +
> +static int xbd599_init_sequence(struct st7703 *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + /*
> + * Init sequence was supplied by the panel vendor.
> + */
> +
> + /* Magic sequence to unlock user commands below. */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xF1, 0x12, 0x83);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
> + 0x33, /* VC_main = 0, Lane_Number = 3 (4 lanes) */
> + 0x81, /* DSI_LDO_SEL = 1.7V, RTERM = 90 Ohm */
> + 0x05, /* IHSRX = x6 (Low High Speed driving ability)
> */
> + 0xF9, /* TX_CLK_SEL = fDSICLK/16 */
> + 0x0E, /* HFP_OSC (min. HFP number in DSI mode) */
> + 0x0E, /* HBP_OSC (min. HBP number in DSI mode) */
> + /* The rest is undocumented in ST7703 datasheet */
> + 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x44, 0x25, 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02,
> + 0x4F, 0x11, 0x00, 0x00, 0x37);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
> + 0x25, /* PCCS = 2, ECP_DC_DIV = 1/4 HSYNC */
> + 0x22, /* DT = 15ms XDK_ECP = x2 */
> + 0x20, /* PFM_DC_DIV = /1 */
> + 0x03 /* ECP_SYNC_EN = 1, VGX_SYNC_EN = 1 */);
> +
> + /* RGB I/F porch timing */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
> + 0x10, /* VBP_RGB_GEN */
> + 0x10, /* VFP_RGB_GEN */
> + 0x05, /* DE_BP_RGB_GEN */
> + 0x05, /* DE_FP_RGB_GEN */
> + /* The rest is undocumented in ST7703 datasheet */
> + 0x03, 0xFF,
> + 0x00, 0x00,
> + 0x00, 0x00);
> +
> + /* Source driving settings. */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
> + 0x73, /* N_POPON */
> + 0x73, /* N_NOPON */
> + 0x50, /* I_POPON */
> + 0x50, /* I_NOPON */
> + 0x00, /* SCR[31,24] */
> + 0xC0, /* SCR[23,16] */
> + 0x08, /* SCR[15,8] */
> + 0x70, /* SCR[7,0] */
> + 0x00 /* Undocumented */);
> +
> + /* NVDDD_SEL = -1.8V, VDDD_SEL = out of range (possibly 1.9V?) */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> +
> + /*
> + * SS_PANEL = 1 (reverse scan), GS_PANEL = 0 (normal
Re: [PATCH v6 08/13] drm/panel: st7703: Move generic part of init sequence to enable callback
Hi,
On Wed, Jul 01, 2020 at 12:31:21PM +0200, Ondrej Jirman wrote:
> Calling sleep out and display on is a controller specific part
> of the initialization process. Move it out of the panel specific
> initialization function to the enable callback.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 33 ++-
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index d03aab10cfef..cdbf7dfb4dd4 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -84,8 +84,6 @@ static inline struct st7703 *panel_to_st7703(struct
> drm_panel *panel)
> static int jh057n_init_sequence(struct st7703 *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> - struct device *dev = ctx->dev;
> - int ret;
>
> /*
>* Init sequence was supplied by the panel vendor. Most of the commands
> @@ -136,20 +134,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x18, 0x00, 0x09, 0x0E, 0x29, 0x2D, 0x3C, 0x41,
> 0x37, 0x07, 0x0B, 0x0D, 0x10, 0x11, 0x0F, 0x10,
> 0x11, 0x18);
> - msleep(20);
> -
> - ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> - if (ret < 0) {
> - DRM_DEV_ERROR(dev, "Failed to exit sleep mode: %d\n", ret);
> - return ret;
> - }
> - /* Panel is operational 120 msec after reset */
> - msleep(60);
> - ret = mipi_dsi_dcs_set_display_on(dsi);
> - if (ret)
> - return ret;
>
> - DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
> return 0;
> }
>
> @@ -181,6 +166,7 @@ struct st7703_panel_desc jh057n00900_panel_desc = {
> static int st7703_enable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> int ret;
>
> ret = ctx->desc->init_sequence(ctx);
> @@ -190,6 +176,23 @@ static int st7703_enable(struct drm_panel *panel)
> return ret;
> }
>
> + msleep(20);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(ctx->dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> +
> + /* Panel is operational 120 msec after reset */
> + msleep(60);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret)
> + return ret;
> +
> + DRM_DEV_DEBUG_DRIVER(ctx->dev, "Panel init sequence done\n");
> +
> return 0;
> }
>
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 07/13] drm/panel: st7703: Move code specific to jh057n closer together
Hi,
On Wed, Jul 01, 2020 at 12:31:20PM +0200, Ondrej Jirman wrote:
> It's better than having it spread around the driver.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 50 +--
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 08cbc316266c..d03aab10cfef 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -153,6 +153,31 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> return 0;
> }
>
> +static const struct drm_display_mode jh057n00900_mode = {
> + .hdisplay= 720,
> + .hsync_start = 720 + 90,
> + .hsync_end = 720 + 90 + 20,
> + .htotal = 720 + 90 + 20 + 20,
> + .vdisplay= 1440,
> + .vsync_start = 1440 + 20,
> + .vsync_end = 1440 + 20 + 4,
> + .vtotal = 1440 + 20 + 4 + 12,
> + .vrefresh= 60,
> + .clock = 75276,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> + .width_mm= 65,
> + .height_mm = 130,
> +};
> +
> +struct st7703_panel_desc jh057n00900_panel_desc = {
> + .mode = _mode,
> + .lanes = 4,
> + .mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> + .format = MIPI_DSI_FMT_RGB888,
> + .init_sequence = jh057n_init_sequence,
> +};
> +
> static int st7703_enable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> @@ -226,31 +251,6 @@ static int st7703_prepare(struct drm_panel *panel)
> return ret;
> }
>
> -static const struct drm_display_mode jh057n00900_mode = {
> - .hdisplay= 720,
> - .hsync_start = 720 + 90,
> - .hsync_end = 720 + 90 + 20,
> - .htotal = 720 + 90 + 20 + 20,
> - .vdisplay= 1440,
> - .vsync_start = 1440 + 20,
> - .vsync_end = 1440 + 20 + 4,
> - .vtotal = 1440 + 20 + 4 + 12,
> - .vrefresh= 60,
> - .clock = 75276,
> - .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> - .width_mm= 65,
> - .height_mm = 130,
> -};
> -
> -struct st7703_panel_desc jh057n00900_panel_desc = {
> - .mode = _mode,
> - .lanes = 4,
> - .mode_flags = MIPI_DSI_MODE_VIDEO |
> - MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> - .format = MIPI_DSI_FMT_RGB888,
> - .init_sequence = jh057n_init_sequence,
> -};
> -
> static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 06/13] drm/panel: st7703: Prepare for supporting multiple panels
Hi,
On Wed, Jul 01, 2020 at 12:31:19PM +0200, Ondrej Jirman wrote:
> Parametrize the driver so that it can support more panels based
> on st7703 controller.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 43 +--
> 1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 511af659f273..08cbc316266c 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -56,6 +57,15 @@ struct st7703 {
> bool prepared;
>
> struct dentry *debugfs;
> + const struct st7703_panel_desc *desc;
> +};
> +
> +struct st7703_panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + unsigned long mode_flags;
> + enum mipi_dsi_pixel_format format;
> + int (*init_sequence)(struct st7703 *ctx);
> };
>
> static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> @@ -148,7 +158,7 @@ static int st7703_enable(struct drm_panel *panel)
> struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> - ret = jh057n_init_sequence(ctx);
> + ret = ctx->desc->init_sequence(ctx);
> if (ret < 0) {
> DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
> ret);
> @@ -216,7 +226,7 @@ static int st7703_prepare(struct drm_panel *panel)
> return ret;
> }
>
> -static const struct drm_display_mode default_mode = {
> +static const struct drm_display_mode jh057n00900_mode = {
> .hdisplay= 720,
> .hsync_start = 720 + 90,
> .hsync_end = 720 + 90 + 20,
> @@ -232,17 +242,26 @@ static const struct drm_display_mode default_mode = {
> .height_mm = 130,
> };
>
> +struct st7703_panel_desc jh057n00900_panel_desc = {
> + .mode = _mode,
> + .lanes = 4,
> + .mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> + .format = MIPI_DSI_FMT_RGB888,
> + .init_sequence = jh057n_init_sequence,
> +};
> +
> static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev, _mode);
> + mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
> if (!mode) {
> DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - default_mode.vrefresh);
> + ctx->desc->mode->hdisplay,
> ctx->desc->mode->vdisplay,
> + ctx->desc->mode->vrefresh);
> return -ENOMEM;
> }
>
> @@ -317,11 +336,11 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
> mipi_dsi_set_drvdata(dsi, ctx);
>
> ctx->dev = dev;
> + ctx->desc = of_device_get_match_data(dev);
>
> - dsi->lanes = 4;
> - dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> - MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> + dsi->mode_flags = ctx->desc->mode_flags;
> + dsi->format = ctx->desc->format;
> + dsi->lanes = ctx->desc->lanes;
>
> ctx->vcc = devm_regulator_get(dev, "vcc");
> if (IS_ERR(ctx->vcc)) {
> @@ -361,8 +380,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
> }
>
> DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - default_mode.vrefresh,
> + ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
> + ctx->desc->mode->vrefresh,
>mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
>
> st7703_debugfs_init(ctx);
> @@ -405,7 +424,7 @@ static int st7703_remove(struct mipi_dsi_device *dsi)
> }
>
> static const struct of_device_id st7703_of_match[] = {
> - { .compatible = "rocktech,jh057n00900" },
> + { .compatible = "rocktech,jh057n00900", .data = _panel_desc
> },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, st7703_of_match);
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: > > On 7/1/20 4:24 AM, Karol Herbst wrote: > > On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > >> > >> This implies something is trying to use one of the old > >> DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without > >> first checking whether it is supported by the kernel. I had tried to > >> force an Xorg+Mesa stack without my userspace patches to hit this error > >> when testing, but must have missed some permutation. If the stalled > >> Mesa patches go in, this would stop happening of course, but those were > >> held up for a long time in review, and are now waiting on me to make > >> some modifications. > >> > > > > that's completely irrelevant. If a kernel change breaks userspace, > > it's a kernel bug. > > Agreed it is unacceptable to break userspace, but I don't think it's > irrelevant. Perhaps the musings on pending userspace patches are. > > My intent here was to point out it appears at first glance that > something isn't behaving as expected in userspace, so fixing this would > likely require some sort of work-around for broken userspace rather than > straight-forward fixing of a bug in the kernel logic. My intent was not > to shift blame to something besides my code & testing for the > regression, though I certainly see how it could be interpreted that way. > > Regardless, I'm looking in to it. If we do need to have a kernel workaround I'm happy to help out, I've done a bunch of these and occasionally it's good to get rather creative :-) Ideally we'd also push a minimal fix in userspace to all stable branches and make sure distros upgrade (might need releases if some distro is stuck on old horrors), so that we don't have to keep the hack in place for 10+ years or so. Definitely if the hack amounts to disabling modifiers on nouveau, that would be kinda sad. -Daniel > > Thanks, > -James > > >> Are you using the modesetting driver in X? If so, with glamor I > >> presume? What version of Mesa? Any distro patches? Any non-default > >> xorg.conf options that would affect modesetting, your X driver if it > >> isn't modesetting, or glamour? > >> > >> Thanks, > >> -James > >> > >> On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: > >>> On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: > James Jones (4): > >>> ... > drm/nouveau/kms: Support NVIDIA format modifiers > >>> > >>> This commit is the first one that breaks Xorg startup for my setup: > >>> GTX 1080 + Dell UP2414Q (4K DP MST monitor). > >>> > >>> I believe this is the crucial part of dmesg (full dmesg is attached): > >>> > >>> [ 29.997140] [drm:nouveau_framebuffer_new] Unsupported modifier: > >>> 0x314 > >>> [ 29.997143] [drm:drm_internal_framebuffer_create] could not create > >>> framebuffer > >>> [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22 > >>> > >>> Any suggestions? > >>> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 05/13] drm/panel: st7703: Rename functions from jh057n prefix to st7703
Hi,
On Wed, Jul 01, 2020 at 12:31:18PM +0200, Ondrej Jirman wrote:
> This is done so that code that's not specific to a particular
> jh057n panel is named after the controller. Functions specific
> to the panel are kept named after the panel.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 90 ++-
> 1 file changed, 46 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 38ff742bc120..511af659f273 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -1,6 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Rockteck jh057n00900 5.5" MIPI-DSI panel driver
> + * Driver for panels based on Sitronix ST7703 controller, souch as:
> + *
> + * - Rocktech jh057n00900 5.5" MIPI-DSI panel
> *
> * Copyright (C) Purism SPC 2019
> */
> @@ -21,7 +23,7 @@
> #include
> #include
>
> -#define DRV_NAME "panel-rocktech-jh057n00900"
> +#define DRV_NAME "panel-sitronix-st7703"
>
> /* Manufacturer specific Commands send via DSI */
> #define ST7703_CMD_ALL_PIXEL_OFF 0x22
> @@ -45,7 +47,7 @@
> #define ST7703_CMD_SETGIP10xE9
> #define ST7703_CMD_SETGIP20xEA
>
> -struct jh057n {
> +struct st7703 {
> struct device *dev;
> struct drm_panel panel;
> struct gpio_desc *reset_gpio;
> @@ -56,9 +58,9 @@ struct jh057n {
> struct dentry *debugfs;
> };
>
> -static inline struct jh057n *panel_to_jh057n(struct drm_panel *panel)
> +static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> {
> - return container_of(panel, struct jh057n, panel);
> + return container_of(panel, struct st7703, panel);
> }
>
> #define dsi_generic_write_seq(dsi, seq...) do {
> \
> @@ -69,7 +71,7 @@ static inline struct jh057n *panel_to_jh057n(struct
> drm_panel *panel)
> return ret; \
> } while (0)
>
> -static int jh057n_init_sequence(struct jh057n *ctx)
> +static int jh057n_init_sequence(struct st7703 *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> struct device *dev = ctx->dev;
> @@ -141,9 +143,9 @@ static int jh057n_init_sequence(struct jh057n *ctx)
> return 0;
> }
>
> -static int jh057n_enable(struct drm_panel *panel)
> +static int st7703_enable(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> ret = jh057n_init_sequence(ctx);
> @@ -156,17 +158,17 @@ static int jh057n_enable(struct drm_panel *panel)
> return 0;
> }
>
> -static int jh057n_disable(struct drm_panel *panel)
> +static int st7703_disable(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>
> return mipi_dsi_dcs_set_display_off(dsi);
> }
>
> -static int jh057n_unprepare(struct drm_panel *panel)
> +static int st7703_unprepare(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
>
> if (!ctx->prepared)
> return 0;
> @@ -178,9 +180,9 @@ static int jh057n_unprepare(struct drm_panel *panel)
> return 0;
> }
>
> -static int jh057n_prepare(struct drm_panel *panel)
> +static int st7703_prepare(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> if (ctx->prepared)
> @@ -230,10 +232,10 @@ static const struct drm_display_mode default_mode = {
> .height_mm = 130,
> };
>
> -static int jh057n_get_modes(struct drm_panel *panel,
> +static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> struct drm_display_mode *mode;
>
> mode = drm_mode_duplicate(connector->dev, _mode);
> @@ -254,17 +256,17 @@ static int jh057n_get_modes(struct drm_panel *panel,
> return 1;
> }
>
> -static const struct drm_panel_funcs jh057n_drm_funcs = {
> - .disable = jh057n_disable,
> - .unprepare = jh057n_unprepare,
> - .prepare = jh057n_prepare,
> - .enable= jh057n_enable,
> - .get_modes = jh057n_get_modes,
> +static const struct drm_panel_funcs st7703_drm_funcs = {
> + .disable = st7703_disable,
> + .unprepare = st7703_unprepare,
> + .prepare = st7703_prepare,
> + .enable= st7703_enable,
> + .get_modes = st7703_get_modes,
> };
>
> static int allpixelson_set(void *data, u64
Re: [PATCH v6 04/13] drm/panel: rocktech-jh057n00900: Rename the driver to st7703
Hi,
On Wed, Jul 01, 2020 at 12:31:17PM +0200, Ondrej Jirman wrote:
> This rename is done so that the driver matches the name of the
> display controller and in preparation for adding support for more
> panels to the driver.
>
> This is just a basic file rename, with no code changes.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/Kconfig | 26 +--
> drivers/gpu/drm/panel/Makefile| 2 +-
> ...-jh057n00900.c => panel-sitronix-st7703.c} | 0
> 3 files changed, 14 insertions(+), 14 deletions(-)
> rename drivers/gpu/drm/panel/{panel-rocktech-jh057n00900.c =>
> panel-sitronix-st7703.c} (100%)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 39055c1f0e2f..de2f2a452be5 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -283,19 +283,6 @@ config DRM_PANEL_RAYDIUM_RM68200
> Say Y here if you want to enable support for Raydium RM68200
> 720x1280 DSI video mode panel.
>
> -config DRM_PANEL_ROCKTECH_JH057N00900
> - tristate "Rocktech JH057N00900 MIPI touchscreen panel"
> - depends on OF
> - depends on DRM_MIPI_DSI
> - depends on BACKLIGHT_CLASS_DEVICE
> - help
> - Say Y here if you want to enable support for Rocktech JH057N00900
> - MIPI DSI panel as e.g. used in the Librem 5 devkit. It has a
> - resolution of 720x1440 pixels, a built in backlight and touch
> - controller.
> - Touch input support is provided by the goodix driver and needs to be
> - selected separately.
> -
> config DRM_PANEL_RONBO_RB070D30
> tristate "Ronbo Electronics RB070D30 panel"
> depends on OF
> @@ -395,6 +382,19 @@ config DRM_PANEL_SITRONIX_ST7701
> ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> system interfaces.
>
> +config DRM_PANEL_SITRONIX_ST7703
> + tristate "Sitronix ST7703 based MIPI touchscreen panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Sitronix ST7703 based
> + panels, souch as Rocktech JH057N00900 MIPI DSI panel as e.g. used in
> + the Librem 5 devkit. It has a resolution of 720x1440 pixels, a built
> + in backlight and touch controller.
> + Touch input support is provided by the goodix driver and needs to be
> + selected separately.
> +
> config DRM_PANEL_SITRONIX_ST7789V
> tristate "Sitronix ST7789V panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index de74f282c433..e45ceac6286f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -27,7 +27,6 @@ obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
> panel-panasonic-vvx10f034n00.o
> obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> panel-raspberrypi-touchscreen.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
> -obj-$(CONFIG_DRM_PANEL_ROCKTECH_JH057N00900) += panel-rocktech-jh057n00900.o
> obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
> @@ -41,6 +40,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
> panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> similarity index 100%
> rename from drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> rename to drivers/gpu/drm/panel/panel-sitronix-st7703.c
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/13] dt-bindings: panel: Convert rocktech,jh057n00900 to yaml
Hi Ondrej,
On Wed, Jul 01, 2020 at 12:31:15PM +0200, Ondrej Jirman wrote:
> Convert Rocktech MIPI DSI panel driver from txt to yaml bindings.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../display/panel/rocktech,jh057n00900.txt| 23 ---
> .../display/panel/rocktech,jh057n00900.yaml | 66 +++
> 2 files changed, 66 insertions(+), 23 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
Thanks for the conversion! Shouldn't we switch to `sitronix-st7703.yaml`
as well in this patch?
Cheers,
-- Guido
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> deleted file mode 100644
> index a372c5d84695..
> --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "rocktech,jh057n00900"
> -- reg: DSI virtual channel of the peripheral
> -- reset-gpios: panel reset gpio
> -- backlight: phandle of the backlight device attached to the panel
> -- vcc-supply: phandle of the regulator that provides the vcc supply voltage.
> -- iovcc-supply: phandle of the regulator that provides the iovcc supply
> - voltage.
> -
> -Example:
> -
> - _dsi {
> - panel@0 {
> - compatible = "rocktech,jh057n00900";
> - reg = <0>;
> - backlight = <>;
> - reset-gpios = < 13 GPIO_ACTIVE_LOW>;
> - vcc-supply = <_2v8_p>;
> - iovcc-supply = <_1v8_p>;
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> new file mode 100644
> index ..928ba42e7f8d
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
> +
> +maintainers:
> + - Ondrej Jirman
> +
> +description: |
> + Rocktech JH057N00900 is a 720x1440 TFT LCD panel
> + connected using a MIPI-DSI video interface.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: rocktech,jh057n00900
> +
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + vcc-supply:
> +description: Panel power supply
> +
> + iovcc-supply:
> +description: I/O voltage supply
> +
> + reset-gpios:
> +description: GPIO used for the reset pin
> +maxItems: 1
> +
> + backlight:
> +description: Backlight used by the panel
> +$ref: "/schemas/types.yaml#/definitions/phandle"
> +
> +required:
> + - compatible
> + - reg
> + - vcc-supply
> + - iovcc-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel@0 {
> +compatible = "rocktech,jh057n00900";
> +reg = <0>;
> +vcc-supply = <_2v8_p>;
> +iovcc-supply = <_1v8_p>;
> +reset-gpios = < 13 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> + };
> +};
> +...
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
Hi, On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > This patchset adds support for the LCD panel of PinePhone. I gave this a quick spin on the Librem5 devkit so Tested-by: Guido Günther but please also adjust MAINTAINERS so we stay in the loop on driver changes. Cheers, -- Guido > > I've tested this on PinePhone 1.0 and 1.2. > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Changes in v6: > - Fixed spacing in yaml > - Fixed wrong vccio->iovcc supply name in the bindings doc > - I noticed that the original driver uses a delay of 20ms in the init > function to achieve a combined total of 120ms required from post-reset > to display_on. I've added a similar delay to xbd599_init, so that > xbd599 panel also has the right timing. (patch 9) > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > - Added review/ack tags > - Learned to run dt_binding_check by myself ;) > > Changes in v5: > - rewritten on top of rocktech-jh057n00900 driver > - rocktech-jh057n00900 renamed to st7703 (controller name) > - converted rocktech-jh057n00900 bindings to yaml and extended for xbd599 > > Changes in v4: > - use ->type from the mode instead of hardcoding (Samuel) > - move init_sequence to ->prepare (Samuel) > - move anti-flicker delay to ->enable, explain it (Samuel) > - add enter_sleep after display_off (Samuel) > - drop ->disable (move code to ->unprepare) > - add ID bytes dumping (Linus) > (I can't test it since allwinner DSI driver has a broken >dcs_read function, and I didn't manage to fix it.) > - document magic bytes (Linus) > - assert reset during powerup > - cleanup powerup timings according to the datasheet > > Changes in v3: > - Panel driver renamed to the name of the LCD controller > - Re-organize the driver slightly to more easily support more panels > based on the same controller. > - Add patch to enable the touchscreen to complete the LCD support > on PinePhone. > - Dropped the "DSI fix" patch (the driver seems to work for me without it) > - Improved brightness levels handling: > - PinePhone 1.0 uses default levels generated by the driver > - On PinePhone 1.1 duty cycles < 20% lead to black screen, so > default levels can't be used. Martijn Braam came up with a > list of duty cycle values that lead to perception of linear > brigtness level <-> light intensity on PinePhone 1.1 > - There was some feedback on v2 about this being similar to st7701. > It's only similar in name. Most of the "user commands" are different, > so I opted to keep this in a new driver instead of creating st770x. > > Anyone who likes to check the differences, here are datasheets: > > - https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > - https://megous.com/dl/tmp/ST7701.pdf > > Changes in v2: > - DT Example fix. > - DT Format fix. > - Raised copyright info to 2020. > - Sort panel operation functions. > - Sort inclusion. > > > -- For phone owners: -- > > There's an open question on how to set the backlight brightness values > on post 1.0 revision phone, since lower duty cycles (< 10-20%) lead > to backlight being black. It would be nice if more people can test > the various backlight levels on 1.1 and 1.2 revision with this change > in dts: > >brightness-levels = <0 1000>; >num-interpolated-steps = <1000>; > > and report at what brightness level the backlight turns on. So far it > seems this has a wide range. Lowest useable duty cycle for me is ~7% > on 1.2 and for Martijn ~20% on 1.1. > > Icenowy Zheng (2): > dt-bindings: vendor-prefixes: Add Xingbangda > arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone > > Ondrej Jirman (11): > dt-bindings: panel: Convert rocktech,jh057n00900 to yaml > dt-bindings: panel: Add compatible for Xingbangda XBD599 panel > drm/panel: rocktech-jh057n00900: Rename the driver to st7703 > drm/panel: st7703: Rename functions from jh057n prefix to st7703 > drm/panel: st7703: Prepare for supporting multiple panels > drm/panel: st7703: Move code specific to jh057n closer together > drm/panel: st7703: Move generic part of init sequence to enable > callback > drm/panel: st7703: Add support for Xingbangda XBD599 > drm/panel: st7703: Enter sleep after display off > drm/panel: st7703: Assert reset prior to powering down the regulators > arm64: dts: sun50i-a64-pinephone: Add touchscreen support > > .../display/panel/rocktech,jh057n00900.txt| 23 - > .../display/panel/rocktech,jh057n00900.yaml | 70 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > .../allwinner/sun50i-a64-pinephone-1.1.dts| 19 + > .../dts/allwinner/sun50i-a64-pinephone.dtsi | 54 ++ > drivers/gpu/drm/panel/Kconfig | 26 +- > drivers/gpu/drm/panel/Makefile| 2 +- > .../drm/panel/panel-rocktech-jh057n00900.c| 424 --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 656 ++ > 9 files changed, 815
Re: [git pull] drm for 5.8-rc1
On 7/1/20 4:24 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: This implies something is trying to use one of the old DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without first checking whether it is supported by the kernel. I had tried to force an Xorg+Mesa stack without my userspace patches to hit this error when testing, but must have missed some permutation. If the stalled Mesa patches go in, this would stop happening of course, but those were held up for a long time in review, and are now waiting on me to make some modifications. that's completely irrelevant. If a kernel change breaks userspace, it's a kernel bug. Agreed it is unacceptable to break userspace, but I don't think it's irrelevant. Perhaps the musings on pending userspace patches are. My intent here was to point out it appears at first glance that something isn't behaving as expected in userspace, so fixing this would likely require some sort of work-around for broken userspace rather than straight-forward fixing of a bug in the kernel logic. My intent was not to shift blame to something besides my code & testing for the regression, though I certainly see how it could be interpreted that way. Regardless, I'm looking in to it. Thanks, -James Are you using the modesetting driver in X? If so, with glamor I presume? What version of Mesa? Any distro patches? Any non-default xorg.conf options that would affect modesetting, your X driver if it isn't modesetting, or glamour? Thanks, -James On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: James Jones (4): ... drm/nouveau/kms: Support NVIDIA format modifiers This commit is the first one that breaks Xorg startup for my setup: GTX 1080 + Dell UP2414Q (4K DP MST monitor). I believe this is the crucial part of dmesg (full dmesg is attached): [ 29.997140] [drm:nouveau_framebuffer_new] Unsupported modifier: 0x314 [ 29.997143] [drm:drm_internal_framebuffer_create] could not create framebuffer [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22 Any suggestions? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd, radeon drm-next-5.9
Hi Dave, Daniel, Same great flavor, now with 0.2% more S-o-b. The following changes since commit 9ca1f474cea0edc14a1d7ec933e5472c0ff115d3: Merge tag 'amd-drm-next-5.8-2020-05-27' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-05-28 16:10:17 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.9-2020-07-01 for you to fetch changes up to 7808363154d622f9446bf4db97ff0f041dafa30b: drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS (2020-07-01 01:59:27 -0400) amd-drm-next-5.9-2020-07-01: amdgpu: - DC DMUB updates - HDCP fixes - Thermal interrupt fixes - Add initial support for Sienna Cichlid GPU - Add support for unique id on Arcturus - Major swSMU code cleanup - Skip BAR resizing if the bios already did id - Fixes for DCN bandwidth calculations - Runtime PM reference count fixes - Add initial UVD support for SI - Add support for ASSR on eDP links - Lots of misc fixes and cleanups - Enable runtime PM on vega10 boards that support BACO - RAS fixes - SR-IOV fixes - Use IP discovery table on renoir - DC stream synchronization fixes amdkfd: - Track SDMA usage per process - Fix GCC10 compiler warnings - Locking fix radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes UAPI: - Update comments to clarify MTYPE Aditya Pakki (2): drm/radeon: fix multiple reference count leak drm/radeon: Fix reference count leaks caused by pm_runtime_get_sync Alex Deucher (36): drm/amdgpu: simplify ATIF backlight handling drm/amdgpu/sdma4: add renoir to powergating setup drm/amdgpu/gfx10: add navi12 to gfxoff case drm/amdgpu: simplify raven and renoir checks drm/amdgpu: simplify CZ/ST and KV/KB/ML checks drm/amdgpu: simplify mec2 fw check drm/amdgpu/sdma4: simplify the logic around powering up sdma drm/amdgpu: put some case statments in family order drm/amdgpu/gmc10: program the smallK fragment size drm/amdgpu/pm: return an error during GPU reset or suspend (v2) drm/amdgpu: skip gpu_info firmware if discovery info is available drm/amdgpu: clean up discovery testing drm/amdgpu: use IP discovery table for renoir drm/amdgpu/nv: allow access to SDMA status registers drm/amdgpu/nv: remove some dead code drm/amdgpu/nv: enable init reset check drm/amdgpu/fru: fix header guard and include header drm/amdgpu/mes10.1: add no scheduler flag for mes drm/amdgpu/vcn3.0: schedule instance 0 for decode and 1 for encode drm/amdgpu/display: fix build without CONFIG_DRM_AMD_DC_DCN3_0 Revert "drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper" drm/amdgpu/fence: use the no_scheduler flag drm/amdgpu/display: use blanked rather than plane state for sync groups drm/amdgpu: skip BAR resizing if the bios already did it drm/amdgpu/pm: update comment to clarify Overdrive interfaces drm/amdgpu: fix documentation around busy_percentage drm/amdgpu/fence: fix ref count leak when pm_runtime_get_sync fails drm/amdkfd: fix ref count leak when pm_runtime_get_sync fails drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails drm/amdgpu/pm: fix ref count leak when pm_runtime_get_sync fails drm/amdgpu/display bail early in dm_pp_get_static_clocks drm/amdgpu/display: properly guard the calls to swSMU functions drm/amdgpu/uvd3.x: fix register definition warnings drm/amdgpu: make sure to reserve tmr region on all asics which support it drm/amdgpu: rework runtime pm enablement for BACO drm/amdgpu: enable runtime pm on vega10 when noretry=0 Alvin Lee (5): drm/amd/display: Disable PG on NV12 drm/amd/display: Don't compare same stream for synchronized vblank drm/amd/display: Get num_chans from VBIOS table drm/amd/display: Update DCN3 bounding box drm/amd/display: Update bounding box states (v2) Anthony Koo (11): drm/amd/display: FW release 1.0.10 drm/amd/display: FW Release 1.0.11 drm/amd/display: combine public interfaces into single header drm/amd/display: [FW Promotion] Release 1.0.12 drm/amd/display: [FW Promotion] Release 1.0.13 drm/amd/display: [FW Promotion] Release 1.0.14 drm/amd/display: [FW Promotion] Release 1.0.15 drm/amd/display: [FW Promotion] Release 1.0.16 drm/amd/display: [FW Promotion] Release 1.0.17 drm/amd/display: [FW Promotion] Release 1.0.18 drm/amd/display: [FW Promotion] Release 1.0.19 Aric Cyr (10): drm/amd/display: 3.2.85 drm/amd/display: 3.2.86 drm/amd/display: Handle link loss interrupt better drm/amd/display: Guard against invalid array access drm/amd/display: 3.2.87
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Wed, Jul 1, 2020 at 2:56 PM Christian König wrote: > > Am 01.07.20 um 14:39 schrieb Jason Gunthorpe: > > On Wed, Jul 01, 2020 at 11:03:06AM +0200, Christian König wrote: > >> Am 30.06.20 um 20:46 schrieb Xiong, Jianxin: > From: Jason Gunthorpe > Sent: Tuesday, June 30, 2020 10:35 AM > To: Xiong, Jianxin > Cc: linux-r...@vger.kernel.org; Doug Ledford ; > Sumit Semwal ; Leon Romanovsky > ; Vetter, Daniel ; Christian > Koenig > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote: > >>> Heterogeneous Memory Management (HMM) utilizes > >>> mmu_interval_notifier and ZONE_DEVICE to support shared virtual > >>> address space and page migration between system memory and device > >>> memory. HMM doesn't support pinning device memory because pages > >>> located on device must be able to migrate to system memory when > >>> accessed by CPU. Peer-to-peer access is possible if the peer can > >>> handle page fault. For RDMA, that means the NIC must support > >>> on-demand paging. > >> peer-peer access is currently not possible with hmm_range_fault(). > > Currently hmm_range_fault() always sets the cpu access flag and device > > private pages are migrated to the system RAM in the fault handler. > > However, it's possible to have a modified code flow to keep the device > > private page info for use with peer to peer access. > Sort of, but only within the same device, RDMA or anything else generic > can't reach inside a DEVICE_PRIVATE and extract anything useful. > >>> But pfn is supposed to be all that is needed. > >>> > >> So.. this patch doesn't really do anything new? We could just make a > >> MR against the DMA buf mmap and get to the same place? > > That's right, the patch alone is just half of the story. The > > functionality depends on availability of dma-buf exporter that can pin > > the device memory. > Well, what do you want to happen here? The RDMA parts are reasonable, > but I don't want to add new functionality without a purpose - the > other parts need to be settled out first. > >>> At the RDMA side, we mainly want to check if the changes are acceptable. > >>> For example, > >>> the part about adding 'fd' to the device ops and the ioctl interface. All > >>> the previous > >>> comments are very helpful for us to refine the patch so that we can be > >>> ready when > >>> GPU side support becomes available. > >>> > The need for the dynamic mapping support for even the current DMA Buf > hacky P2P users is really too bad. Can you get any GPU driver to > support non-dynamic mapping? > >>> We are working on direct direction. > >>> > >>> migrate to system RAM. This is due to the lack of knowledge about > >>> whether the importer can perform peer-to-peer access and the lack > >>> of resource limit control measure for GPU. For the first part, the > >>> latest dma-buf driver has a peer-to-peer flag for the importer, > >>> but the flag is currently tied to dynamic mapping support, which > >>> requires on-demand paging support from the NIC to work. > >> ODP for DMA buf? > > Right. > Hum. This is not actually so hard to do. The whole dma buf proposal > would make a lot more sense if the 'dma buf MR' had to be the > dynamic kind and the driver had to provide the faulting. It would not be > so hard to change mlx5 to be able to work like this, perhaps. (the > locking might be a bit tricky though) > >>> The main issue is that not all NICs support ODP. > >> You don't need on-demand paging support from the NIC for dynamic mapping to > >> work. > >> > >> All you need is the ability to stop wait for ongoing accesses to end and > >> make sure that new ones grab a new mapping. > > Swap and flush isn't a general HW ability either.. > > > > I'm unclear how this could be useful, it is guarenteed to corrupt > > in-progress writes? > > > > Did you mean pause, swap and resume? That's ODP. > > Yes, something like this. And good to know, never heard of ODP. Hm I thought ODP was full hw page faults at an individual page level, and this stop is for the entire nic. Under the hood both apply back-pressure on the network if a transmission can't be received, but I thought the ODP one is a lore more fine-grained. For this dma_buf stop-the-world approach we'd also need to guarantee _all_ buffers are present again (without hw page faults on the nic side of things), which has some additional locking implications. > On the GPU side we can pipeline things, e.g. you can program the > hardware that page tables are changed at a certain point in time. > > So what we do is when we get a notification that a buffer will move > around is to mark this buffer in our structures as invalid and return a > fence to so that the exporter is able to wait for
[PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail
there is an error when igt test is run continuously. vkms_atomic_commit_tail() need to call drm_atomic_helper_wait_for_vblanks() for give up ownership of vblank events. without this code, next atomic commit will not enable vblank and raise timeout error. Signed-off-by: Sidong Yang --- drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index 1e8b2169d834..10b9be67a068 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state) flush_work(_state->composer_work); } + drm_atomic_helper_wait_for_vblanks(dev, old_state); + drm_atomic_helper_cleanup_planes(dev, old_state); } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
Hi Ondrej. On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > This patchset adds support for the LCD panel of PinePhone. > > I've tested this on PinePhone 1.0 and 1.2. > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Changes in v6: > - Fixed spacing in yaml > - Fixed wrong vccio->iovcc supply name in the bindings doc > - I noticed that the original driver uses a delay of 20ms in the init > function to achieve a combined total of 120ms required from post-reset > to display_on. I've added a similar delay to xbd599_init, so that > xbd599 panel also has the right timing. (patch 9) > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > - Added review/ack tags > - Learned to run dt_binding_check by myself ;) The patch-set does not apply clean on top of drm-misc-next - due to vrefresh removal. Please re-spin. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: allows LP commands in video mode
From: Antonio Borneo Current code only sends LP commands in command mode. Allows sending LP commands also in video mode by setting the proper flag in DSI_VID_MODE_CFG. Signed-off-by: Antonio Borneo Change-Id: Ib78fa37bcc7559ce63017acd6ee0bbf00c61a397 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/153242 Reviewed-by: CITOOLS Reviewed-by: CIBUILD Reviewed-by: Yannick FERTRE Reviewed-by: Philippe CORNU Tested-by: Yannick FERTRE --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index d580b2aa4ce9..0cd43e7a69bb 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -367,6 +367,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi *dsi, dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS); dsi_write(dsi, DSI_CMD_MODE_CFG, val); + + val = dsi_read(dsi, DSI_VID_MODE_CFG); + if (lpm) + val |= ENABLE_LOW_POWER_CMD; + else + val &= ~ENABLE_LOW_POWER_CMD; + dsi_write(dsi, DSI_VID_MODE_CFG, val); } static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: allows LP commands in video mode
Hi Yannick.
On Wed, Jul 01, 2020 at 04:52:58PM +0200, Yannick Fertre wrote:
> From: Antonio Borneo
>
> Current code only sends LP commands in command mode.
>
> Allows sending LP commands also in video mode by setting the
> proper flag in DSI_VID_MODE_CFG.
>
> Signed-off-by: Antonio Borneo
> Change-Id: Ib78fa37bcc7559ce63017acd6ee0bbf00c61a397
Change-Id is not used in kernel patches to my best knowledge.
> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/153242
> Reviewed-by: CITOOLS
> Reviewed-by: CIBUILD
Reviews by humans, not machines..
> Reviewed-by: Yannick FERTRE
> Reviewed-by: Philippe CORNU
> Tested-by: Yannick FERTRE
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d580b2aa4ce9..0cd43e7a69bb 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -367,6 +367,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi
> *dsi,
>
> dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> +
> + val = dsi_read(dsi, DSI_VID_MODE_CFG);
> + if (lpm)
> + val |= ENABLE_LOW_POWER_CMD;
> + else
> + val &= ~ENABLE_LOW_POWER_CMD;
> + dsi_write(dsi, DSI_VID_MODE_CFG, val);
> }
We have following code:
static void dw_mipi_dsi_set_mode(struct dw_mipi_dsi *dsi,
unsigned long mode_flags)
{
dsi_write(dsi, DSI_PWR_UP, RESET);
if (mode_flags & MIPI_DSI_MODE_VIDEO) {
dsi_write(dsi, DSI_MODE_CFG, ENABLE_VIDEO_MODE);
dw_mipi_dsi_video_mode_config(dsi);
dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
} else {
dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
}
dsi_write(dsi, DSI_PWR_UP, POWERUP);
}
Here DSI_MODE_CFG is used to set vidoe mode or not.
But the code snip above checks DSI_VID_MODE_CFG.
It looks inconsistent.
I do not know the HW - and just stumbled over this.
Sam
>
> static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32
> hdr_val)
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains
On Tue, Jun 30, 2020 at 05:26:16PM +0530, Rajendra Nayak wrote: > Add the OPP tables for DSI and MDP based on the perf state/clk > requirements, and add the power-domains property to specify the > scalable power domain. > > Signed-off-by: Rajendra Nayak Reviewed-by: Matthias Kaehlcke ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains
On Tue, Jun 30, 2020 at 05:26:15PM +0530, Rajendra Nayak wrote:
> Add the OPP tables for DSI and MDP based on the perf state/clk
> requirements, and add the power-domains property to specify the
> scalable power domain.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 59
>
> 1 file changed, 59 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 8eb5a31..b6afeb2 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3296,6 +3296,35 @@
> #power-domain-cells = <1>;
> };
>
> + dsi_opp_table: dsi-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-1920 {
> + opp-hz = /bits/ 64 <1920>;
> + required-opps = <_opp_min_svs>;
> + };
> +
> + opp-18000 {
> + opp-hz = /bits/ 64 <18000>;
> + required-opps = <_opp_low_svs>;
> + };
> +
> + opp-27500 {
> + opp-hz = /bits/ 64 <27500>;
> + required-opps = <_opp_svs>;
> + };
> +
> + opp-32858 {
> + opp-hz = /bits/ 64 <32858>;
> + required-opps = <_opp_svs_l1>;
> + };
> +
> + opp-35800 {
> + opp-hz = /bits/ 64 <35800>;
> + required-opps = <_opp_nom>;
> + };
> + };
> +
I still don't like the shared OPP tables to be positioned inmidst of the
device nodes, but it seems we currently don't have a better convention.
> mdss: mdss@ae0 {
> compatible = "qcom,sdm845-mdss";
> reg = <0 0x0ae0 0 0x1000>;
> @@ -3340,6 +3369,8 @@
> <
> DISP_CC_MDSS_VSYNC_CLK>;
> assigned-clock-rates = <3>,
> <1920>;
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
> interrupt-parent = <>;
> interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> @@ -3364,6 +3395,30 @@
> };
> };
> };
> +
> + mdp_opp_table: mdp-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-1920 {
> + opp-hz = /bits/ 64 <1920>;
> + required-opps =
> <_opp_min_svs>;
> + };
> +
> + opp-171428571 {
> + opp-hz = /bits/ 64 <171428571>;
> + required-opps =
> <_opp_low_svs>;
> + };
> +
> + opp-34400 {
> + opp-hz = /bits/ 64 <34400>;
> + required-opps =
> <_opp_svs_l1>;
> + };
> +
> + opp-43000 {
> + opp-hz = /bits/ 64 <43000>;
> + required-opps =
> <_opp_nom>;
> + };
> + };
> };
>
> dsi0: dsi@ae94000 {
> @@ -3386,6 +3441,8 @@
> "core",
> "iface",
> "bus";
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
> phys = <_phy>;
> phy-names = "dsi";
> @@ -3450,6 +3507,8 @@
> "core",
> "iface",
> "bus";
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
> phys = <_phy>;
> phy-names = "dsi";
Reviewed-by: Matthias Kaehlcke
___
[PATCH] drm/amd/display: remove redundant initialization of variable result
From: Colin Ian King
The variable result is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index 1b3474aa380d..d0a23b72e604 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -151,7 +151,8 @@ bool edp_receiver_ready_T9(struct dc_link *link)
unsigned int tries = 0;
unsigned char sinkstatus = 0;
unsigned char edpRev = 0;
- enum dc_status result = DC_OK;
+ enum dc_status result;
+
result = core_link_read_dpcd(link, DP_EDP_DPCD_REV, ,
sizeof(edpRev));
/* start from eDP version 1.2, SINK_STAUS indicate the sink is ready.*/
@@ -177,7 +178,7 @@ bool edp_receiver_ready_T7(struct dc_link *link)
{
unsigned char sinkstatus = 0;
unsigned char edpRev = 0;
- enum dc_status result = DC_OK;
+ enum dc_status result;
/* use absolute time stamp to constrain max T7*/
unsigned long long enter_timestamp = 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: allows LP commands in video mode
From: Antonio Borneo Current code only sends LP commands in command mode. Allows sending LP commands also in video mode by setting the proper flag in DSI_VID_MODE_CFG. Signed-off-by: Antonio Borneo Change-Id: Ib78fa37bcc7559ce63017acd6ee0bbf00c61a397 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/153242 Reviewed-by: CITOOLS Reviewed-by: CIBUILD Reviewed-by: Yannick FERTRE Reviewed-by: Philippe CORNU Tested-by: Yannick FERTRE --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index d580b2aa4ce9..0cd43e7a69bb 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -367,6 +367,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi *dsi, dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS); dsi_write(dsi, DSI_CMD_MODE_CFG, val); + + val = dsi_read(dsi, DSI_VID_MODE_CFG); + if (lpm) + val |= ENABLE_LOW_POWER_CMD; + else + val &= ~ENABLE_LOW_POWER_CMD; + dsi_write(dsi, DSI_VID_MODE_CFG, val); } static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: allow sending longer LP commands
From: Antonio Borneo Current code does not properly computes the max length of LP commands that can be send during H or V sync, and rely on static values. Limiting the max LP length to 4 byte during the V-sync is overly conservative. Relax the limit and allows longer LP commands (16 bytes) to be sent during V-sync. Signed-off-by: Antonio Borneo --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index d580b2aa4ce9..1a24ea648ef8 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -360,6 +360,15 @@ static void dw_mipi_message_config(struct dw_mipi_dsi *dsi, bool lpm = msg->flags & MIPI_DSI_MSG_USE_LPM; u32 val = 0; + /* +* TODO dw drv improvements +* largest packet sizes during hfp or during vsa/vpb/vfp +* should be computed according to byte lane, lane number and only +* if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS) +*/ + dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(16) + | INVACT_LPCMD_TIME(4)); + if (msg->flags & MIPI_DSI_MSG_REQ_ACK) val |= ACK_RQST_EN; if (lpm) @@ -611,14 +620,6 @@ static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi, dsi_write(dsi, DSI_DPI_VCID, DPI_VCID(dsi->channel)); dsi_write(dsi, DSI_DPI_COLOR_CODING, color); dsi_write(dsi, DSI_DPI_CFG_POL, val); - /* -* TODO dw drv improvements -* largest packet sizes during hfp or during vsa/vpb/vfp -* should be computed according to byte lane, lane number and only -* if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS) -*/ - dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(4) - | INVACT_LPCMD_TIME(4)); } static void dw_mipi_dsi_packet_handler_config(struct dw_mipi_dsi *dsi) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi Daniel, thanks for reviewing most of the patchset. Am 30.06.20 um 11:06 schrieb Daniel Vetter: > On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede wrote: >> >> Hi, >> >> On 6/25/20 2:00 PM, Thomas Zimmermann wrote: >>> This patchset adds support for simple-framebuffer platform devices and >>> a handover mechanism for native drivers to take-over control of the >>> hardware. >>> >>> The new driver, called simplekms, binds to a simple-frambuffer platform >>> device. The kernel's boot code creates such devices for firmware-provided >>> framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot >>> loader sets up the framebuffers. Description via device tree is also an >>> option. >>> >>> Simplekms is small enough to be linked into the kernel. The driver's main >>> purpose is to provide graphical output during the early phases of the boot >>> process, before the native DRM drivers are available. Native drivers are >>> typically loaded from an initrd ram disk. Occationally simplekms can also >>> serve as interim solution on graphics hardware without native DRM driver. >> >> Cool, thank you for doing this, this is a very welcome change, >> but ... (see below). >> >>> So far distributions rely on fbdev drivers, such as efifb, vesafb or >>> simplefb, for early-boot graphical output. However fbdev is deprecated and >>> the drivers do not provide DRM interfaces for modern userspace. >>> >>> Patches 1 and 2 prepare the DRM format helpers for simplekms. >>> >>> Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers >>> and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During >>> pageflips, SHMEM buffers are copied into the framebuffer memory, similar >>> to cirrus or mgag200. The code in patches 6 and 7 handles clocks and >>> regulators. It's based on the simplefb drivers, but has been modified for >>> DRM. >>> >>> Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's >>> framebuffer's I/O-memory range and provides a callback function to be >>> removed by a native driver. The native driver will remove simplekms before >>> taking over the hardware. The removal is integrated into existing helpers, >>> so drivers use it automatically. >>> >>> I tested simplekms with x86 EFI and VESA framebuffers, which both work >>> reliably. The fbdev console and Weston work automatically. Xorg requires >>> manual configuration of the device. Xorgs current modesetting driver does >>> not work with both, platform and PCI device, for the same physical >>> hardware. Once configured, X11 works. >> >> Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go >> around and break userspace. OTOH this does seem like an userspace issue >> and not something which we can (or should try to) fix in the kernel. >> >> I guess the solution will have to be to have this default to N for now >> in Kconfig and clearly mention in the Kconfig help text that this needs >> a fixed Xorg modesetting driver before it can be enabled. >> >> Any chance you have time to work on fixing the Xorg modesetting driver >> so that this will just work with the standard Xorg autoconfiguration >> stuff? > > Hm, why do we even have both platform and pci drivers visible at the > same time? I thought the point of this is that simplekms is built-in, > then initrd loads the real drm driver, and by the time Xorg is > running, simplekms should be long gone. > > Maybe a few more details of what's going wrong and why to help unconfuse me? I tested simplekms with PCI graphics cards. Xorg does it's own scanning of the busses. It supports a platform bus, where it finds the simple-framebuffer device that is driven by simplekms. Xorg also scans the PCI bus, where is finds the native PCI device; usually driven by the native driver. It's the same hardware, but on different busses. For each device, Xorg tries to configure a screen, the Xorg modeset driver tried to open the DRM device file and acquire DRM master status on it. This works for the first screen, but DRM master status can only be acquired once, so it fails for the second screen. Xorg then aborts and asks for manual configuration of the display device. This can be solved by setting the platform device's bus id in the xorg.conf device section. It just doesn't happen automatically. I found it hard to find a solution to this. Weston just opens a DRM device file and uses whatever it gets. Ideally, Xorg would do the same. That whole bus-scanning exercise gives it a wrong idea on which graphics devices are available. One idea for a fix is to compare the device I/O-memory ranges and filter out duplicates on the Xorg modeset driver. I don't know how reliable this works in practice or if their are false positives. A more fundamental solution is to introduce a DRM bus in Xorg that enumerates all available DRM device files. If there are any, no other busses would be scanned. I'm still looking for something better. Idea are highly welcome. Best regards
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi Hans Am 29.06.20 um 11:38 schrieb Hans de Goede: > Hi, > > On 6/25/20 2:00 PM, Thomas Zimmermann wrote: >> This patchset adds support for simple-framebuffer platform devices and >> a handover mechanism for native drivers to take-over control of the >> hardware. >> >> The new driver, called simplekms, binds to a simple-frambuffer platform >> device. The kernel's boot code creates such devices for firmware-provided >> framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot >> loader sets up the framebuffers. Description via device tree is also an >> option. >> >> Simplekms is small enough to be linked into the kernel. The driver's main >> purpose is to provide graphical output during the early phases of the >> boot >> process, before the native DRM drivers are available. Native drivers are >> typically loaded from an initrd ram disk. Occationally simplekms can also >> serve as interim solution on graphics hardware without native DRM driver. > > Cool, thank you for doing this, this is a very welcome change, > but ... (see below). > >> So far distributions rely on fbdev drivers, such as efifb, vesafb or >> simplefb, for early-boot graphical output. However fbdev is deprecated >> and >> the drivers do not provide DRM interfaces for modern userspace. >> >> Patches 1 and 2 prepare the DRM format helpers for simplekms. >> >> Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers >> and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During >> pageflips, SHMEM buffers are copied into the framebuffer memory, similar >> to cirrus or mgag200. The code in patches 6 and 7 handles clocks and >> regulators. It's based on the simplefb drivers, but has been modified for >> DRM. >> >> Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's >> framebuffer's I/O-memory range and provides a callback function to be >> removed by a native driver. The native driver will remove simplekms >> before >> taking over the hardware. The removal is integrated into existing >> helpers, >> so drivers use it automatically. >> >> I tested simplekms with x86 EFI and VESA framebuffers, which both work >> reliably. The fbdev console and Weston work automatically. Xorg requires >> manual configuration of the device. Xorgs current modesetting driver does >> not work with both, platform and PCI device, for the same physical >> hardware. Once configured, X11 works. > > Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go > around and break userspace. OTOH this does seem like an userspace issue > and not something which we can (or should try to) fix in the kernel. Xorg is an important use case, but simplekms does not "break userspace." If you're not using simplekms, nothing changes; if simplekms is replaced by the native driver, nothing changes. Simplekms works with Xorg of the device is auto-configured. Xorg is not able to auto-configure simplekms devices ATM. > > I guess the solution will have to be to have this default to N for now > in Kconfig and clearly mention in the Kconfig help text that this needs > a fixed Xorg modesetting driver before it can be enabled. Sure, but simplekms is just a driver. Shouldn't it default to N anyway? > > Any chance you have time to work on fixing the Xorg modesetting driver > so that this will just work with the standard Xorg autoconfiguration > stuff? I'll do if somehow possible. See my reply to Daniel for a description of the problem. > >> One cosmetical issue is that simplekms's device file is card0 and the >> native driver's device file is card1. After simplekms has been kicked >> out, >> only card1 is left. This does not seem to be a practical problem however. >> >> TODO/IDEAS: >> >> * provide deferred takeover > > I assume you mean akin to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ? > I don't think you need to do anything for that, as long as you just > leave the fb contents intact until requested to change it. Great. If it's that easy; even better. > > Right now with flickerfree boot we have fbcon on top of efifb and > efifb does not do anything special wrt > CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER > ATM it does draw/restore the ACPI BGRT logo since since some firmwares > don't draw that themselves, but that is not necessary in most cases > and other then that all the deferred takeover magic is in the fbcon > code, it does not bind to the fbdev (and thus does not draw to it) > until the first time the kernel tries to output text to the console, > together with the "quiet" kernel commandline argument that ensures > that the fb is kept unmodified until e.g. a panic happens. > > With simplekms we would replace "fbcon on top of efifb" with > "fbcon on top of emulated-fbdev on top of simplekms" so as long > as the emulated-fbdev and simplekms code defer from say clearing > the screen to black, but keep it as is. Then the fb contents > should be preserved until fbcon decides to takeover the fbdev >
[PATCH] drm/virtgpu: remove redundant assignments to width and height
From: Colin Ian King
Variables width and height are being assigned values that are never
read. The assignments are redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..bf80d8c23da7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -165,8 +165,6 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
if (width == 0 || height == 0) {
- width = XRES_DEF;
- height = YRES_DEF;
drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
} else {
DRM_DEBUG("add mode: %dx%d\n", width, height);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel -
Pretty quiet in the i915 front.
drm-intel-fixes-2020-07-01:
drm/i915 fixes for v5.8-rc4:
- GVT fixes
- Include asm sources for render cache clear batches
BR,
Jani.
The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:
Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-07-01
for you to fetch changes up to 55fd7e0222ea01246ef3e6aae28b5721fdfb790f:
drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c (2020-06-29
11:29:12 +0300)
drm/i915 fixes for v5.8-rc4:
- GVT fixes
- Include asm sources for render cache clear batches
Colin Xu (4):
drm/i915/gvt: Add one missing MMIO handler for D_SKL_PLUS
drm/i915/gvt: Fix two CFL MMIO handling caused by regression.
drm/i915/gvt: Fix incorrect check of enabled bits in mask registers
drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context
Jani Nikula (1):
Merge tag 'gvt-fixes-2020-06-17' of https://github.com/intel/gvt-linux
into drm-intel-fixes
Rodrigo Vivi (1):
drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
drivers/gpu/drm/i915/gt/shaders/README | 46
.../gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm | 119 +
.../gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm | 117
drivers/gpu/drm/i915/gvt/debugfs.c | 2 +-
drivers/gpu/drm/i915/gvt/handlers.c| 24 +++--
drivers/gpu/drm/i915/gvt/mmio_context.h| 6 +-
drivers/gpu/drm/i915/gvt/reg.h | 5 +
7 files changed, 304 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/shaders/README
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
Am 01.07.20 um 14:39 schrieb Jason Gunthorpe: On Wed, Jul 01, 2020 at 11:03:06AM +0200, Christian König wrote: Am 30.06.20 um 20:46 schrieb Xiong, Jianxin: From: Jason Gunthorpe Sent: Tuesday, June 30, 2020 10:35 AM To: Xiong, Jianxin Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit Semwal ; Leon Romanovsky ; Vetter, Daniel ; Christian Koenig Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote: Heterogeneous Memory Management (HMM) utilizes mmu_interval_notifier and ZONE_DEVICE to support shared virtual address space and page migration between system memory and device memory. HMM doesn't support pinning device memory because pages located on device must be able to migrate to system memory when accessed by CPU. Peer-to-peer access is possible if the peer can handle page fault. For RDMA, that means the NIC must support on-demand paging. peer-peer access is currently not possible with hmm_range_fault(). Currently hmm_range_fault() always sets the cpu access flag and device private pages are migrated to the system RAM in the fault handler. However, it's possible to have a modified code flow to keep the device private page info for use with peer to peer access. Sort of, but only within the same device, RDMA or anything else generic can't reach inside a DEVICE_PRIVATE and extract anything useful. But pfn is supposed to be all that is needed. So.. this patch doesn't really do anything new? We could just make a MR against the DMA buf mmap and get to the same place? That's right, the patch alone is just half of the story. The functionality depends on availability of dma-buf exporter that can pin the device memory. Well, what do you want to happen here? The RDMA parts are reasonable, but I don't want to add new functionality without a purpose - the other parts need to be settled out first. At the RDMA side, we mainly want to check if the changes are acceptable. For example, the part about adding 'fd' to the device ops and the ioctl interface. All the previous comments are very helpful for us to refine the patch so that we can be ready when GPU side support becomes available. The need for the dynamic mapping support for even the current DMA Buf hacky P2P users is really too bad. Can you get any GPU driver to support non-dynamic mapping? We are working on direct direction. migrate to system RAM. This is due to the lack of knowledge about whether the importer can perform peer-to-peer access and the lack of resource limit control measure for GPU. For the first part, the latest dma-buf driver has a peer-to-peer flag for the importer, but the flag is currently tied to dynamic mapping support, which requires on-demand paging support from the NIC to work. ODP for DMA buf? Right. Hum. This is not actually so hard to do. The whole dma buf proposal would make a lot more sense if the 'dma buf MR' had to be the dynamic kind and the driver had to provide the faulting. It would not be so hard to change mlx5 to be able to work like this, perhaps. (the locking might be a bit tricky though) The main issue is that not all NICs support ODP. You don't need on-demand paging support from the NIC for dynamic mapping to work. All you need is the ability to stop wait for ongoing accesses to end and make sure that new ones grab a new mapping. Swap and flush isn't a general HW ability either.. I'm unclear how this could be useful, it is guarenteed to corrupt in-progress writes? Did you mean pause, swap and resume? That's ODP. Yes, something like this. And good to know, never heard of ODP. On the GPU side we can pipeline things, e.g. you can program the hardware that page tables are changed at a certain point in time. So what we do is when we get a notification that a buffer will move around is to mark this buffer in our structures as invalid and return a fence to so that the exporter is able to wait for ongoing stuff to finish. The actual move then happens only after the ongoing operations on the GPU are finished and on the next operation we grab the new location of the buffer and re-program the page tables to it. This way all the CPU does is really just planning asynchronous page table changes which are executed on the GPU later on. You can of course do it synchronized as well, but this would hurt our performance pretty badly. Regards, Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 00/11] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Hi Adrian, Am Dienstag, 9. Juni 2020, 19:49:48 CEST schrieb Adrian Ratiu: > [Re-submitting to cc dri-devel, sorry about the noise] > > Hello all, > > v9 cleanly applies on top of latest next-20200609 tree. at least it doesn't apply on top of current drm-misc-next for me which I really don't understand. Like patch 2/11 does @@ -31,6 +31,7 @@ #include . #define HWVER_131<><--><-->0x31333100<>/* IP version 1.31 */ +#define HWVER_130<><--><-->0x31333000<>/* IP version 1.30 */ . #define DSI_VERSION<--><--><-->0x00 #define VERSION<--><--><--><-->GENMASK(31, 8) where the file currently looks like #include #include #include #include #include #include #include #define HWVER_131 0x31333100 /* IP version 1.31 */ #define DSI_VERSION 0x00 #define VERSION GENMASK(31, 8) even in Linux-next So I guess ideally rebase on top of drm-misc-next Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
Thanks for all the good work here, Christian! On Wed, 1 Jul 2020 at 17:20, Daniel Vetter wrote: > > On Wed, Jul 1, 2020 at 1:26 PM Christian König > wrote: > > > > As discussed on the list. > > > > Signed-off-by: Christian König > > Acked-by: Daniel Vetter Acked-by: Sumit Semwal > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 40474982a21d..5d7130f8d342 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5089,6 +5089,7 @@ F:fs/dlm/ > > > > DMA BUFFER SHARING FRAMEWORK > > M: Sumit Semwal > > +M: Christian König > > L: linux-me...@vger.kernel.org > > L: dri-devel@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > > -- > > 2.20.1 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Wed, Jul 01, 2020 at 02:07:44PM +0200, Daniel Vetter wrote: > Either my mailer ate half the thread or it's still stuck somewhere, so > jumping in the middle a bit. > > On Wed, Jul 01, 2020 at 11:03:06AM +0200, Christian König wrote: > > Am 30.06.20 um 20:46 schrieb Xiong, Jianxin: > > > > -Original Message- > > > > From: Jason Gunthorpe > > > > Sent: Tuesday, June 30, 2020 10:35 AM > > > > To: Xiong, Jianxin > > > > Cc: linux-r...@vger.kernel.org; Doug Ledford ; > > > > Sumit Semwal ; Leon Romanovsky > > > > ; Vetter, Daniel ; Christian > > > > Koenig > > > > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support > > > > > > > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote: > > > > > > > Heterogeneous Memory Management (HMM) utilizes > > > > > > > mmu_interval_notifier and ZONE_DEVICE to support shared virtual > > > > > > > address space and page migration between system memory and device > > > > > > > memory. HMM doesn't support pinning device memory because pages > > > > > > > located on device must be able to migrate to system memory when > > > > > > > accessed by CPU. Peer-to-peer access is possible if the peer can > > > > > > > handle page fault. For RDMA, that means the NIC must support > > > > > > > on-demand paging. > > > > > > peer-peer access is currently not possible with hmm_range_fault(). > > > > > Currently hmm_range_fault() always sets the cpu access flag and device > > > > > private pages are migrated to the system RAM in the fault handler. > > > > > However, it's possible to have a modified code flow to keep the device > > > > > private page info for use with peer to peer access. > > > > Sort of, but only within the same device, RDMA or anything else generic > > > > can't reach inside a DEVICE_PRIVATE and extract anything useful. > > > But pfn is supposed to be all that is needed. > > > > > > > > > So.. this patch doesn't really do anything new? We could just make > > > > > > a MR against the DMA buf mmap and get to the same place? > > > > > That's right, the patch alone is just half of the story. The > > > > > functionality depends on availability of dma-buf exporter that can pin > > > > > the device memory. > > > > Well, what do you want to happen here? The RDMA parts are reasonable, > > > > but I don't want to add new functionality without a purpose - the > > > > other parts need to be settled out first. > > > At the RDMA side, we mainly want to check if the changes are acceptable. > > > For example, > > > the part about adding 'fd' to the device ops and the ioctl interface. All > > > the previous > > > comments are very helpful for us to refine the patch so that we can be > > > ready when > > > GPU side support becomes available. > > > > > > > The need for the dynamic mapping support for even the current DMA Buf > > > > hacky P2P users is really too bad. Can you get any GPU driver to > > > > support non-dynamic mapping? > > > We are working on direct direction. > > > > > > > > > > migrate to system RAM. This is due to the lack of knowledge about > > > > > > > whether the importer can perform peer-to-peer access and the lack > > > > > > > of resource limit control measure for GPU. For the first part, the > > > > > > > latest dma-buf driver has a peer-to-peer flag for the importer, > > > > > > > but the flag is currently tied to dynamic mapping support, which > > > > > > > requires on-demand paging support from the NIC to work. > > > > > > ODP for DMA buf? > > > > > Right. > > > > Hum. This is not actually so hard to do. The whole dma buf proposal > > > > would make a lot more sense if the 'dma buf MR' had to be the > > > > dynamic kind and the driver had to provide the faulting. It would not > > > > be so hard to change mlx5 to be able to work like this, perhaps. (the > > > > locking might be a bit tricky though) > > > The main issue is that not all NICs support ODP. > > > > You don't need on-demand paging support from the NIC for dynamic mapping to > > work. > > > > All you need is the ability to stop wait for ongoing accesses to end and > > make sure that new ones grab a new mapping. > > So having no clue about rdma myself much, this sounds rather interesting. > Sure it would result in immediately re-acquiring the pages, but that's > also really all we need to be able to move buffers around on the gpu side. > And with dma_resv_lock there's no livelock risk if the NIC immediately > starts a kthread/work_struct which reacquires all the dma-buf and > everything else it needs. Plus also with the full ww_mutex deadlock > backoff dance there's no locking issues with having to acquire an entire > pile of dma_resv_lock, that's natively supported (gpus very much need to > be able to lock arbitrary set of buffers). > > And I think if that would allow us to avoid the entire "avoid random > drivers pinning dma-buf into vram" discussions, much better and quicker to > land something like that. > > I guess the big question is going to be how
Re: [PATCH] drm/stm: repair runtime power management
On 3/9/20 12:57 PM, Marek Vasut wrote:
> On 3/9/20 11:35 AM, Yannick FERTRE wrote:
>> Hello Marek,
>
> Hi,
>
> (please stop top-posting)
>
>> Thank for your patch. Pm_runtime_put_sync is also done into function
>> ltdc_crtc_mode_fixup.
>> To avoid several call of Pm_runtime_put_sync, it could be better to check
>> pm_runtime activity:
>>
>> +int ret;
>>
>> DRM_DEBUG_DRIVER("\n");
>>
>> +if (!pm_runtime_active(ddev->dev)) {
>> +ret = pm_runtime_get_sync(ddev->dev);
>> +if (ret) {
>> +DRM_ERROR("Failed to enable crtc, cannot get sync\n");
>> +return;
>> +}
>> +}
>> +
>
> Where should this go ? And wouldn't that only hide nastier PM imbalance
> issues ?
Hi Marek,
I tested the patch & it generate an error when I try wake up / sleep
the board STM32MP1 DK2 with weston application.
It need an additional patch
drm-stm-ltdc-remove-call-of-pm-runtime-functions.
Thanks for the patch.
Tested-by: Yannick Fertre
>
>> Best regards
>>
>> Yannick Fertré
>>
>>
>> -Original Message-
>> From: Marek Vasut
>> Sent: samedi 29 février 2020 23:17
>> To: dri-devel@lists.freedesktop.org
>> Cc: Marek Vasut ; Yannick FERTRE ;
>> Philippe CORNU ; Benjamin Gaignard
>> ; Vincent ABRIOU ;
>> Maxime Coquelin ; Alexandre TORGUE
>> ; linux-st...@st-md-mailman.stormreply.com;
>> linux-arm-ker...@lists.infradead.org
>> Subject: [PATCH] drm/stm: repair runtime power management
>>
>> Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to match
>> pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise the LTDC
>> might suspend via runtime PM, disable clock, and then fail to resume later
>> on.
>>
>> The test which triggers it is roughly -- run qt5 application which uses
>> eglfs platform and etnaviv, stop the application, sleep for 15 minutes, run
>> the application again. This leads to a timeout waiting for vsync, because
>> the LTDC has suspended, but did not resume.
>>
>> Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management")
>> Signed-off-by: Marek Vasut
>> Cc: Yannick Fertré
>> Cc: Philippe Cornu
>> Cc: Benjamin Gaignard
>> Cc: Vincent Abriou
>> Cc: Maxime Coquelin
>> Cc: Alexandre Torgue
>> To: dri-devel@lists.freedesktop.org
>> Cc: linux-st...@st-md-mailman.stormreply.com
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>> [ cut here ]
>> WARNING: CPU: 0 PID: 297 at drivers/gpu/drm/drm_atomic_helper.c:1494
>> drm_atomic_helper_wait_for_vblanks+0x1dc/0x200
>> [CRTC:35:crtc-0] vblank wait timed out
>> Modules linked in:
>> CPU: 0 PID: 297 Comm: QSGRenderThread Not tainted
>> 5.6.0-rc3-next-20200228-00010-g318bf0fc08ef #2 Hardware name: STM32 (Device
>> Tree Support) [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14) [] (show_stack) from []
>> (dump_stack+0xb4/0xd0) [] (dump_stack) from []
>> (__warn+0xd4/0xf0) [] (__warn) from []
>> (warn_slowpath_fmt+0x78/0xa8) [] (warn_slowpath_fmt) from
>> [] (drm_atomic_helper_wait_for_vblanks+0x1dc/0x200)
>> [] (drm_atomic_helper_wait_for_vblanks) from []
>> (drm_atomic_helper_commit_tail+0
>> x50/0x60)
>> [] (drm_atomic_helper_commit_tail) from []
>> (commit_tail+0x12c/0x13c) [] (commit_tail) from []
>> (drm_atomic_helper_commit+0xf4/0x100)
>> [] (drm_atomic_helper_commit) from []
>> (drm_atomic_helper_set_config+0x58/0x6c)
>> [] (drm_atomic_helper_set_config) from []
>> (drm_mode_setcrtc+0x450/0x550) [] (drm_mode_setcrtc) from
>> [] (drm_ioctl_kernel+0x90/0xe8) [] (drm_ioctl_kernel)
>> from [] (drm_ioctl+0x2e4/0x32c) [] (drm_ioctl) from
>> [] (vfs_ioctl+0x20/0x38) [] (vfs_ioctl) from
>> [] (ksys_ioctl+0xbc/0x7b0) [] (ksys_ioctl) from
>> [] (ret_fast_syscall+0x0/0x54) Exception stack(0xee8f3fa8 to
>> 0xee8f3ff0)
>> 3fa0: 0005 adcbeb18 0005 c06864a2 adcbeb18 0001
>> 3fc0: 0005 adcbeb18 c06864a2 0036 0029 0023 0023 0007
>> 3fe0: b113b098 adcbeafc b1125413 b6155cf8 ---[ end trace 2ad5ba954ceb767a
>> ]---
>> ---
>> drivers/gpu/drm/stm/ltdc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index
>> 99bf93e8b36f..301de0498078 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -425,9 +425,12 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> struct drm_crtc_state *old_state) {
>> struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>> +struct drm_device *ddev = crtc->dev;
>>
>> DRM_DEBUG_DRIVER("\n");
>>
>> +pm_runtime_get_sync(ddev->dev);
>> +
>> /* Sets the background color value */
>> reg_write(ldev->regs, LTDC_BCCR, BCCR_BCBLACK);
>>
>> --
>> 2.25.0
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
Either my mailer ate half the thread or it's still stuck somewhere, so jumping in the middle a bit. On Wed, Jul 01, 2020 at 11:03:06AM +0200, Christian König wrote: > Am 30.06.20 um 20:46 schrieb Xiong, Jianxin: > > > -Original Message- > > > From: Jason Gunthorpe > > > Sent: Tuesday, June 30, 2020 10:35 AM > > > To: Xiong, Jianxin > > > Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit > > > Semwal ; Leon Romanovsky > > > ; Vetter, Daniel ; Christian > > > Koenig > > > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support > > > > > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote: > > > > > > Heterogeneous Memory Management (HMM) utilizes > > > > > > mmu_interval_notifier and ZONE_DEVICE to support shared virtual > > > > > > address space and page migration between system memory and device > > > > > > memory. HMM doesn't support pinning device memory because pages > > > > > > located on device must be able to migrate to system memory when > > > > > > accessed by CPU. Peer-to-peer access is possible if the peer can > > > > > > handle page fault. For RDMA, that means the NIC must support > > > > > > on-demand paging. > > > > > peer-peer access is currently not possible with hmm_range_fault(). > > > > Currently hmm_range_fault() always sets the cpu access flag and device > > > > private pages are migrated to the system RAM in the fault handler. > > > > However, it's possible to have a modified code flow to keep the device > > > > private page info for use with peer to peer access. > > > Sort of, but only within the same device, RDMA or anything else generic > > > can't reach inside a DEVICE_PRIVATE and extract anything useful. > > But pfn is supposed to be all that is needed. > > > > > > > So.. this patch doesn't really do anything new? We could just make a > > > > > MR against the DMA buf mmap and get to the same place? > > > > That's right, the patch alone is just half of the story. The > > > > functionality depends on availability of dma-buf exporter that can pin > > > > the device memory. > > > Well, what do you want to happen here? The RDMA parts are reasonable, but > > > I don't want to add new functionality without a purpose - the > > > other parts need to be settled out first. > > At the RDMA side, we mainly want to check if the changes are acceptable. > > For example, > > the part about adding 'fd' to the device ops and the ioctl interface. All > > the previous > > comments are very helpful for us to refine the patch so that we can be > > ready when > > GPU side support becomes available. > > > > > The need for the dynamic mapping support for even the current DMA Buf > > > hacky P2P users is really too bad. Can you get any GPU driver to > > > support non-dynamic mapping? > > We are working on direct direction. > > > > > > > > migrate to system RAM. This is due to the lack of knowledge about > > > > > > whether the importer can perform peer-to-peer access and the lack > > > > > > of resource limit control measure for GPU. For the first part, the > > > > > > latest dma-buf driver has a peer-to-peer flag for the importer, > > > > > > but the flag is currently tied to dynamic mapping support, which > > > > > > requires on-demand paging support from the NIC to work. > > > > > ODP for DMA buf? > > > > Right. > > > Hum. This is not actually so hard to do. The whole dma buf proposal would > > > make a lot more sense if the 'dma buf MR' had to be the > > > dynamic kind and the driver had to provide the faulting. It would not be > > > so hard to change mlx5 to be able to work like this, perhaps. (the > > > locking might be a bit tricky though) > > The main issue is that not all NICs support ODP. > > You don't need on-demand paging support from the NIC for dynamic mapping to > work. > > All you need is the ability to stop wait for ongoing accesses to end and > make sure that new ones grab a new mapping. So having no clue about rdma myself much, this sounds rather interesting. Sure it would result in immediately re-acquiring the pages, but that's also really all we need to be able to move buffers around on the gpu side. And with dma_resv_lock there's no livelock risk if the NIC immediately starts a kthread/work_struct which reacquires all the dma-buf and everything else it needs. Plus also with the full ww_mutex deadlock backoff dance there's no locking issues with having to acquire an entire pile of dma_resv_lock, that's natively supported (gpus very much need to be able to lock arbitrary set of buffers). And I think if that would allow us to avoid the entire "avoid random drivers pinning dma-buf into vram" discussions, much better and quicker to land something like that. I guess the big question is going to be how to fit this into rdma, since the ww_mutex deadlock backoff dance needs to be done at a fairly high level. For gpu drivers it's always done at the top level ioctl entry point. > Apart from that this is a rather interesting work. > > Regards,
[PATCH] drm/stm: ltdc: remove call of pm-runtime functions
It is not necessary to suspend or stop the ltdc clocks
to modify the pixel clock.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 3f590d916e91..6e28f707092f 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -506,15 +506,7 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
- struct drm_device *ddev = crtc->dev;
int rate = mode->clock * 1000;
- bool runtime_active;
- int ret;
-
- runtime_active = pm_runtime_active(ddev->dev);
-
- if (runtime_active)
- pm_runtime_put_sync(ddev->dev);
if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
@@ -523,14 +515,6 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
- if (runtime_active) {
- ret = pm_runtime_get_sync(ddev->dev);
- if (ret) {
- DRM_ERROR("Failed to fixup mode, cannot get sync\n");
- return false;
- }
- }
-
DRM_DEBUG_DRIVER("requested clock %dkHz, adjusted clock %dkHz\n",
mode->clock, adjusted_mode->clock);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: gma500: Convert to GPIO descriptors
On Sun, Jun 28, 2020 at 1:29 AM Linus Walleij wrote:
>
> Finalize he conversion of GMA500 to use only GPIO descriptors.
> The GPIO look-up-table is associated with the device directly
> in the GMA500 Medfield chip driver since no explicit platform
> type device (such as in x86/platform/intel-mid) exists: the
> GMA500 probes directly from the PCI device. Apparently GPIOs
> 88 and 34 are used on all of these so just go ahead and
Is 88 meant to be 128 here?
> register those for resetting the DSI pipes.
>
> Cc: Patrik Jakobsson
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/gma500/mdfld_device.c | 20 +
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 2 +-
> drivers/gpu/drm/gma500/mdfld_dsi_output.c | 51 ---
> drivers/gpu/drm/gma500/mdfld_dsi_output.h | 2 +-
> drivers/gpu/drm/gma500/mdfld_output.h | 2 +-
> drivers/gpu/drm/gma500/psb_intel_drv.h| 1 -
> 6 files changed, 49 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_device.c
> b/drivers/gpu/drm/gma500/mdfld_device.c
> index b718efccdcf2..be9cf6b1e3b3 100644
> --- a/drivers/gpu/drm/gma500/mdfld_device.c
> +++ b/drivers/gpu/drm/gma500/mdfld_device.c
> @@ -6,6 +6,7 @@
> **/
>
> #include
> +#include
>
> #include
>
> @@ -505,12 +506,31 @@ static const struct psb_offset mdfld_regmap[3] = {
> },
> };
>
> +/*
> + * The GPIO lines for resetting DSI pipe 0 and 2 are available in the
> + * PCI device :00:0c.0 on the Medfield.
> + */
> +static struct gpiod_lookup_table mdfld_dsi_pipe_gpio_table = {
> + .table = {
> + GPIO_LOOKUP(":00:0c.0", 128, "dsi-pipe0-reset",
> + GPIO_ACTIVE_HIGH),
> + GPIO_LOOKUP(":00:0c.0", 34, "dsi-pipe2-reset",
> + GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static int mdfld_chip_setup(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> if (pci_enable_msi(dev->pdev))
> dev_warn(dev->dev, "Enabling MSI failed!\n");
> dev_priv->regmap = mdfld_regmap;
> +
> + /* Associate the GPIO lines with the DRM device */
> + mdfld_dsi_pipe_gpio_table.dev_id = dev_name(dev->dev);
> + gpiod_add_lookup_table(_dsi_pipe_gpio_table);
> +
> return mid_chip_setup(dev);
> }
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
> b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
> index c976a9dd9240..ae1223f631a7 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
> @@ -955,7 +955,7 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct
> drm_device *dev,
>
> /* panel hard-reset */
> if (p_funcs->reset) {
> - ret = p_funcs->reset(pipe);
> + ret = p_funcs->reset(dev, pipe);
> if (ret) {
> DRM_ERROR("Panel %d hard-reset failed\n",
> pipe);
> return NULL;
> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> index f350ac1ead18..c9478261964a 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -432,42 +433,42 @@ static int mdfld_dsi_get_default_config(struct
> drm_device *dev,
> return 0;
> }
>
> -int mdfld_dsi_panel_reset(int pipe)
> +int mdfld_dsi_panel_reset(struct drm_device *ddev, int pipe)
> {
> - unsigned gpio;
> - int ret = 0;
> -
> + struct device *dev = ddev->dev;
> + struct gpio_desc *gpiod;
> +
> + /*
> +* Raise the GPIO reset line for the corresponding pipe to HIGH,
> +* this is probably because it is active low so this takes the
> +* respective pipe out of reset. (We have no code to put it back
> +* into reset in this driver.)
> +*/
> switch (pipe) {
> case 0:
> - gpio = 128;
> + gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(gpiod))
> + return PTR_ERR(gpiod);
> break;
> case 2:
> - gpio = 34;
> + gpiod = gpiod_get(dev, "dsi-pipe2-reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(gpiod))
> + return PTR_ERR(gpiod);
> break;
> default:
> - DRM_ERROR("Invalid output\n");
> + DRM_DEV_ERROR(dev, "Invalid output pipe\n");
> return -EINVAL;
> }
> + gpiod_put(gpiod);
>
> - ret = gpio_request(gpio, "gfx");
> - if (ret) {
> - DRM_ERROR("gpio_rqueset failed\n");
> - return ret;
> - }
> -
Re: [PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
Thanks for all the good work here, Christian! On Wed, 1 Jul 2020, 17:20 Daniel Vetter, wrote: > On Wed, Jul 1, 2020 at 1:26 PM Christian König > wrote: > > > > As discussed on the list. > > > > Signed-off-by: Christian König > > Acked-by: Daniel Vetter > Acked-by: Sumit Semwal > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 40474982a21d..5d7130f8d342 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5089,6 +5089,7 @@ F:fs/dlm/ > > > > DMA BUFFER SHARING FRAMEWORK > > M: Sumit Semwal > > +M: Christian König > > L: linux-me...@vger.kernel.org > > L: dri-devel@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > > -- > > 2.20.1 > > > Best, Sumit. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 2/3] drm/mediatek: mtk_dpi: Convert to bridge driver
On Mon, 18 May 2020 19:39:08 +0200
Enric Balletbo i Serra wrote:
> Convert mtk_dpi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
>
> drivers/gpu/drm/mediatek/mtk_dpi.c | 66 +++---
> 1 file changed, 34 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 7112125dc3d1..baad198c69eb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -61,6 +61,7 @@ enum mtk_dpi_out_color_format {
> struct mtk_dpi {
> struct mtk_ddp_comp ddp_comp;
> struct drm_encoder encoder;
> + struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> void __iomem *regs;
> struct device *dev;
> @@ -77,9 +78,9 @@ struct mtk_dpi {
> int refcount;
> };
>
> -static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> +static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
> {
> - return container_of(e, struct mtk_dpi, encoder);
> + return container_of(b, struct mtk_dpi, bridge);
> }
>
> enum mtk_dpi_polarity {
> @@ -518,50 +519,44 @@ static const struct drm_encoder_funcs
> mtk_dpi_encoder_funcs = {
> .destroy = mtk_dpi_encoder_destroy,
> };
>
> -static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
> -const struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode)
> +static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
> {
> - return true;
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
> + >bridge, flags);
> }
>
> -static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> {
> - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>
> drm_mode_copy(>mode, adjusted_mode);
> }
>
> -static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
> +static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
> {
> - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>
> mtk_dpi_power_off(dpi);
> }
>
> -static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
> +static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
> {
> - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>
> mtk_dpi_power_on(dpi);
> mtk_dpi_set_display_mode(dpi, >mode);
> }
>
> -static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
> - struct drm_crtc_state *crtc_state,
> - struct drm_connector_state *conn_state)
> -{
> - return 0;
> -}
> -
> -static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
> - .mode_fixup = mtk_dpi_encoder_mode_fixup,
> - .mode_set = mtk_dpi_encoder_mode_set,
> - .disable = mtk_dpi_encoder_disable,
> - .enable = mtk_dpi_encoder_enable,
> - .atomic_check = mtk_dpi_atomic_check,
> +static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> + .attach = mtk_dpi_bridge_attach,
> + .mode_set = mtk_dpi_bridge_mode_set,
> + .disable = mtk_dpi_bridge_disable,
> + .enable = mtk_dpi_bridge_enable,
> };
>
> static void mtk_dpi_start(struct mtk_ddp_comp *comp)
> @@ -602,16 +597,13 @@ static int mtk_dpi_bind(struct device *dev, struct
> device *master, void *data)
> dev_err(dev, "Failed to initialize decoder: %d\n", ret);
> goto err_unregister;
> }
> - drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
>
> /* Currently DPI0 is fixed to be driven by OVL1 */
> dpi->encoder.possible_crtcs = BIT(1);
>
> - ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
> - if (ret) {
> - dev_err(dev, "Failed to attach bridge: %d\n", ret);
Any reason your decided to drop this error message? If there's one,
this should probably happen in a separate patch.
> + ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> + if (ret)
> goto err_cleanup;
> - }
>
> dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> @@ -768,8
Re: [PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
On Wed, Jul 1, 2020 at 1:26 PM Christian König wrote: > > As discussed on the list. > > Signed-off-by: Christian König Acked-by: Daniel Vetter > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 40474982a21d..5d7130f8d342 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5089,6 +5089,7 @@ F:fs/dlm/ > > DMA BUFFER SHARING FRAMEWORK > M: Sumit Semwal > +M: Christian König > L: linux-me...@vger.kernel.org > L: dri-devel@lists.freedesktop.org > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder
On Mon, 18 May 2020 19:39:09 +0200
Enric Balletbo i Serra wrote:
> The mtk_dpi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
>
> drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index baad198c69eb..80778b2aac2a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_dpi_regs.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> return 0;
> }
>
> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> - .destroy = mtk_dpi_encoder_destroy,
> -};
> -
> static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
> {
> @@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - ret = drm_encoder_init(drm_dev, >encoder, _dpi_encoder_funcs,
> -DRM_MODE_ENCODER_TMDS, NULL);
> + ret = drm_simple_encoder_init(drm_dev, >encoder,
> + DRM_MODE_ENCODER_TMDS);
Not related to this change, but shouldn't we have DRM_MODE_ENCODER_DPI
here?
> if (ret) {
> dev_err(dev, "Failed to initialize decoder: %d\n", ret);
> goto err_unregister;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/3] drm/mediatek: mtk_dpi: Rename bridge to next_bridge
On Wed, 1 Jul 2020 13:23:03 +0200
Boris Brezillon wrote:
> On Mon, 18 May 2020 19:39:07 +0200
> Enric Balletbo i Serra wrote:
>
> > This is really a cosmetic change just to make a bit more readable the
> > code after convert the driver to drm_bridge. The bridge variable name
> > will be used by the encoder drm_bridge, and the chained bridge will be
> > named next_bridge.
> >
> > Signed-off-by: Enric Balletbo i Serra
> > Reviewed-by: Chun-Kuang Hu
> > ---
> >
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 7fbfa95bab09..7112125dc3d1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -61,7 +61,7 @@ enum mtk_dpi_out_color_format {
> > struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > - struct drm_bridge *bridge;
> > + struct drm_bridge *next_bridge;
>
> Did you consider moving the drm_of_find_panel_or_bridge() call to
> mtk_dpi_bind() so you can get rid of this field?
Nevermind, you need it in patch 2 for the recursive call to
drm_bridge_attach().
>
> This makes we realize there's no refcounting on bridges, which means
> the bridge can vanish between the drm_of_find_panel_or_bridge() and
> drm_bridge_attach() calls :-/.
>
> > void __iomem *regs;
> > struct device *dev;
> > struct clk *engine_clk;
> > @@ -607,7 +607,7 @@ static int mtk_dpi_bind(struct device *dev, struct
> > device *master, void *data)
> > /* Currently DPI0 is fixed to be driven by OVL1 */
> > dpi->encoder.possible_crtcs = BIT(1);
> >
> > - ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
> > + ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
> > if (ret) {
> > dev_err(dev, "Failed to attach bridge: %d\n", ret);
> > goto err_cleanup;
> > @@ -747,11 +747,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> > }
> >
> > ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> > - NULL, >bridge);
> > + NULL, >next_bridge);
> > if (ret)
> > return ret;
> >
> > - dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
> > + dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
> >
> > comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
> > if (comp_id < 0) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
As discussed on the list. Signed-off-by: Christian König --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 40474982a21d..5d7130f8d342 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5089,6 +5089,7 @@ F:fs/dlm/ DMA BUFFER SHARING FRAMEWORK M: Sumit Semwal +M: Christian König L: linux-me...@vger.kernel.org L: dri-devel@lists.freedesktop.org L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > > This implies something is trying to use one of the old > DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without > first checking whether it is supported by the kernel. I had tried to > force an Xorg+Mesa stack without my userspace patches to hit this error > when testing, but must have missed some permutation. If the stalled > Mesa patches go in, this would stop happening of course, but those were > held up for a long time in review, and are now waiting on me to make > some modifications. > that's completely irrelevant. If a kernel change breaks userspace, it's a kernel bug. > Are you using the modesetting driver in X? If so, with glamor I > presume? What version of Mesa? Any distro patches? Any non-default > xorg.conf options that would affect modesetting, your X driver if it > isn't modesetting, or glamour? > > Thanks, > -James > > On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: > > On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: > >> James Jones (4): > > ... > >>drm/nouveau/kms: Support NVIDIA format modifiers > > > > This commit is the first one that breaks Xorg startup for my setup: > > GTX 1080 + Dell UP2414Q (4K DP MST monitor). > > > > I believe this is the crucial part of dmesg (full dmesg is attached): > > > > [ 29.997140] [drm:nouveau_framebuffer_new] Unsupported modifier: > > 0x314 > > [ 29.997143] [drm:drm_internal_framebuffer_create] could not create > > framebuffer > > [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22 > > > > Any suggestions? > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/3] drm/mediatek: mtk_dpi: Rename bridge to next_bridge
On Mon, 18 May 2020 19:39:07 +0200
Enric Balletbo i Serra wrote:
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridge.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
>
> drivers/gpu/drm/mediatek/mtk_dpi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 7fbfa95bab09..7112125dc3d1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -61,7 +61,7 @@ enum mtk_dpi_out_color_format {
> struct mtk_dpi {
> struct mtk_ddp_comp ddp_comp;
> struct drm_encoder encoder;
> - struct drm_bridge *bridge;
> + struct drm_bridge *next_bridge;
Did you consider moving the drm_of_find_panel_or_bridge() call to
mtk_dpi_bind() so you can get rid of this field?
This makes we realize there's no refcounting on bridges, which means
the bridge can vanish between the drm_of_find_panel_or_bridge() and
drm_bridge_attach() calls :-/.
> void __iomem *regs;
> struct device *dev;
> struct clk *engine_clk;
> @@ -607,7 +607,7 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> /* Currently DPI0 is fixed to be driven by OVL1 */
> dpi->encoder.possible_crtcs = BIT(1);
>
> - ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
> + ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Failed to attach bridge: %d\n", ret);
> goto err_cleanup;
> @@ -747,11 +747,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - NULL, >bridge);
> + NULL, >next_bridge);
> if (ret)
> return ret;
>
> - dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
> + dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
>
> comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
> if (comp_id < 0) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
Hi Vinay.
On Wed, Jul 01, 2020 at 03:14:09PM +0530, Vinay Simha B N wrote:
> sam,
>
> I rechecked, but did not find any indents are too spaced.
> This is taken from a working dts tree.
>
port@1 {
| reg = <1>;
| dsi0_out: endpoint {
| remote-endpoint = <_in_test>;
| data-lanes = <0 1 2 3>;
| };
};
};
};
See above, something is wrong with the indent in the examples.
> I had given two examples for a purpose. One for single lvds
> configuration single link mode,
> another is for dual lvds configurations dual-link mode and port mappings.
Please provide a proper description of the single link and dual link
modes in the descriptions of the bindings.
The examples shall support the bindings, they shall not include
information that is not covered in the bindings.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property
Hi
On 29/06/2020 14:28, Andrzej Hajda wrote:
Hi Grygorii,
(...)
/*
* deferred_devs_show() - Show the devices in the deferred probe
pending list.
*/
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
void *data)
mutex_lock(_probe_mutex);
list_for_each_entry(curr, _probe_pending_list,
deferred_probe)
- seq_printf(s, "%s\n", dev_name(curr->device));
+ seq_printf(s, "%s\t%s", dev_name(curr->device),
+ curr->device->p->deferred_probe_reason ?: "\n");
mutex_unlock(_probe_mutex);
Sry, may be i missing smth, but shouldn't it be optional
(CONFIG_DEBUG_FS is probably too generic).
I am not sure what exactly are you referring to, but this patch does not
add new property, it just extends functionality of existing one.
Sry, needed to be more specific.
You've added device_set_deferred_probe_reson(dev, );
which expected to be used on every EPROBE_DEFER in dev_err_probe() in
combination with
+ } else {
+ device_set_deferred_probe_reson(dev, );
dev_dbg(dev, "error %d: %pV", err, );
^^ dev_dbg() does not add any runtime overhead during boot unless enabled
+ }
But:
+void device_set_deferred_probe_reson(const struct device *dev, struct
va_format *vaf)
+{
+ const char *drv = dev_driver_string(dev);
+
+ mutex_lock(_probe_mutex);
+
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv,
vaf);
+
+ mutex_unlock(_probe_mutex);
+}
^^ Adds locking, kfree() and kasprintf() for every deferred probe during boot
and can't be disabled.
Right?
--
Best regards,
grygorii
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create
Thanks for your suggestion, I can make the patch. But the
problem is reported by tool "Hulk Robot" and only happen
one time. No scripts are left, so I have no exact environment
to test.
On 2020/7/1 14:56, Thomas Zimmermann wrote:
> Hi
>
> Thanks for the patch and apologies for being late with the review.
>
> The fix is good, but I'd like to see different approach. I'd rather have
> drm_gem_vram_init() being integrated into drm_gem_vram_create().
>
> Do you prefer to make the patch or shall I type up something? Would you
> be able to test?
>
> I have some comments on the resulting changes below.
>
> Am 01.07.20 um 04:32 schrieb Jia Yang:
>> Ping...
>>
>> On 2020/6/20 14:21, Jia Yang wrote:
>>> I got a use-after-free report when doing some fuzz test:
>>>
>>> If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
>>> freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
>>> then drm_gem_vram_create() and drm_gem_vram_init() will free
>>> "gbo" and "gbo->bo.base" again.
>>>
>>> BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150
>>> CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: GB W
>>> 5.7.0-rc4-msan #2
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> Ubuntu-1.8.2-1ubuntu1 04/01/2014
>>> Call Trace:
>>> __dump_stack
>>> dump_stack+0x1c9/0x220
>>> kmsan_report+0xf7/0x1e0
>>> __msan_warning+0x58/0xa0
>>> drm_vma_offset_remove+0xb3/0x150
>>> drm_gem_free_mmap_offset
>>> drm_gem_object_release+0x159/0x180
>>> drm_gem_vram_init
>>> drm_gem_vram_create+0x7c5/0x990
>>> drm_gem_vram_fill_create_dumb
>>> drm_gem_vram_driver_dumb_create+0x238/0x590
>>> drm_mode_create_dumb
>>> drm_mode_create_dumb_ioctl+0x41d/0x450
>>> drm_ioctl_kernel+0x5a4/0x710
>>> drm_ioctl+0xc6f/0x1240
>>> vfs_ioctl
>>> ksys_ioctl
>>> __do_sys_ioctl
>>> __se_sys_ioctl+0x2e9/0x410
>>> __x64_sys_ioctl+0x4a/0x70
>>> do_syscall_64+0xb8/0x160
>>> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> RIP: 0033:0x4689b9
>>> Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>>> ff 0f 83 cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00
>>> RSP: 002b:7f368fa4dc98 EFLAGS: 0246 ORIG_RAX: 0010
>>> RAX: ffda RBX: 0076bf00 RCX: 004689b9
>>> RDX: 2240 RSI: c02064b2 RDI: 0003
>>> RBP: 0004 R08: R09:
>>> R10: R11: 0246 R12:
>>> R13: 004d17e0 R14: 7f368fa4e6d4 R15: 0076bf0c
>>>
>>> Uninit was created at:
>>> kmsan_save_stack_with_flags
>>> kmsan_internal_poison_shadow+0x66/0xd0
>>> kmsan_slab_free+0x6e/0xb0
>>> slab_free_freelist_hook
>>> slab_free
>>> kfree+0x571/0x30a0
>>> drm_gem_vram_destroy
>>> ttm_buffer_object_destroy+0xc8/0x130
>>> ttm_bo_release
>>> kref_put
>>> ttm_bo_put+0x117d/0x23e0
>>> ttm_bo_init_reserved+0x11c0/0x11d0
>>> ttm_bo_init+0x289/0x3f0
>>> drm_gem_vram_init
>>> drm_gem_vram_create+0x775/0x990
>>> drm_gem_vram_fill_create_dumb
>>> drm_gem_vram_driver_dumb_create+0x238/0x590
>>> drm_mode_create_dumb
>>> drm_mode_create_dumb_ioctl+0x41d/0x450
>>> drm_ioctl_kernel+0x5a4/0x710
>>> drm_ioctl+0xc6f/0x1240
>>> vfs_ioctl
>>> ksys_ioctl
>>> __do_sys_ioctl
>>> __se_sys_ioctl+0x2e9/0x410
>>> __x64_sys_ioctl+0x4a/0x70
>>> do_syscall_64+0xb8/0x160
>>> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>
>>> If ttm_bo_init() fails, the "gbo" will be freed by
>>> ttm_buffer_object_destroy() in ttm_bo_init(). But then
>>> drm_gem_vram_create() and drm_gem_vram_init() will free
>>> "gbo" again.
>>>
>>> Reported-by: Hulk Robot
>>> Signed-off-by: Jia Yang
>>> ---
>>> drivers/gpu/drm/drm_gem_vram_helper.c | 28 +++
>>> 1 file changed, 16 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> index 8b2d5c945c95..1d85af9a481a 100644
>>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> @@ -175,6 +175,10 @@ static void drm_gem_vram_placement(struct
>>> drm_gem_vram_object *gbo,
>>> }
>>> }
>>>
>>> +/*
>>> + * Note that on error, drm_gem_vram_init will free the buffer object.
>>> + */
>>> +
>
> This comment could go away.
>
>>> static int drm_gem_vram_init(struct drm_device *dev,
>>> struct drm_gem_vram_object *gbo,
>>> size_t size, unsigned long pg_align)
>>> @@ -184,15 +188,19 @@ static int drm_gem_vram_init(struct drm_device *dev,
>>> int ret;
>>> size_t acc_size;
>>>
>>> - if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
>>> + if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
>>> + kfree(gbo);
>>> return -EINVAL;
>>> + }
>
> This test can go to the top of drm_gem_vram_create()
>
>>> bdev = >bdev;
>>>
>>>
Re: [PATCH] backlight: Delete the OT200 backlight driver
On Fri, 26 Jun 2020, Linus Walleij wrote: > This driver has no in-kernel users. The device can only be populated > by board files since it does not support device tree nor ACPI, > and nothing in the kernel creates a device named "ot200-backlight". > > This driver has been in the kernel since 2012. If it is used by > out-of-tree code that code should have been upstreamed by now, > it's been 8 years. > > It uses the idiomatic forked GPIO of the CS5535 which combines > pin control and GPIO into its private custom interface, which > causes me a headache because that is not how we do things these > days: we creates separate pin control and GPIO drivers. > > Delete this unused driver. > > Cc: Christian Gmeiner > Signed-off-by: Linus Walleij > --- > drivers/video/backlight/Kconfig| 7 -- > drivers/video/backlight/Makefile | 1 - > drivers/video/backlight/ot200_bl.c | 162 - > 3 files changed, 170 deletions(-) > delete mode 100644 drivers/video/backlight/ot200_bl.c Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services 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] backlight: lms501kf03: Drop unused include
On Fri, 26 Jun 2020, Linus Walleij wrote: > This driver includes but does not use any > symbols from that file, drop the include. > > Signed-off-by: Linus Walleij > --- > drivers/video/backlight/lms501kf03.c | 1 - > 1 file changed, 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services 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 2/2] backlight: sky81452: Privatize platform data
On Fri, 26 Jun 2020, Linus Walleij wrote: > The only way the platform data for the SKY81452 ever gets populated > is through the device tree. > > The MFD device is bothered with this for no reason at all. Just > allocate the platform data in the driver and be happy. > > Cc: Gyungoh Yoo > Signed-off-by: Linus Walleij > --- > drivers/mfd/sky81452.c| 2 - > drivers/video/backlight/sky81452-backlight.c | 34 + > include/linux/mfd/sky81452.h | 2 - > .../linux/platform_data/sky81452-backlight.h | 37 --- > 4 files changed, 27 insertions(+), 48 deletions(-) > delete mode 100644 include/linux/platform_data/sky81452-backlight.h Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services 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 v1 0/7] drm_connector: drop legacy drm_bus_flags
On Tue, Jun 30, 2020 at 08:05:38PM +0200, Sam Ravnborg wrote: > Drop all uses of legacy drm_bus_flags, and then drop the flags. > Follow-up with a patch to inline the documentation of the flags. > > The conversion was triggered by Laurent's clean-up of > the bus_flags use in panel-simple. > https://lore.kernel.org/dri-devel/20200630135802.ga581...@ravnborg.org/T/#t > > Build tested only. > Patches on top of latest drm-misc-next. > > Sam > > (Procrastination, was supposed to review patches, not producing them). > > Sam Ravnborg (7): > drm/tidss: drop use of legacy drm_bus_flags > drm/ingenic-drm: drop use of legacy drm_bus_flags > drm/panel: raydium-rm67191: drop use of legacy drm_bus_flags > drm/panel: novatek-nt39016: drop use of legacy drm_bus_flags > drm/panel: panel-simple: drop use of legacy drm_bus_flags > drm/drm_connector: drop legacy drm_bus_flags values > drm/drm_connector: use inline comments for drm_bus_flags With the quick feedback from Jyri ack and Laurent I have applied this set to drm-misc-next. Sam > > drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +- > drivers/gpu/drm/panel/panel-novatek-nt39016.c | 2 +- > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 2 +- > drivers/gpu/drm/panel/panel-simple.c | 28 +++--- > drivers/gpu/drm/tidss/tidss_dispc.c | 4 +- > include/drm/drm_connector.h | 124 > ++ > 6 files changed, 104 insertions(+), 58 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] backlight: sky81452: Convert to GPIO descriptors
On Fri, 26 Jun 2020, Linus Walleij wrote: > The SKY81452 backlight driver just obtains a GPIO (named "gpios" > in the device tree) drives it high and leaves it high until the > driver is removed. > > Switch to use GPIO descriptors for this, simple and > straight-forward. > > Cc: Gyungoh Yoo > Signed-off-by: Linus Walleij > --- > drivers/video/backlight/sky81452-backlight.c | 18 -- > .../linux/platform_data/sky81452-backlight.h | 6 -- > 2 files changed, 8 insertions(+), 16 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services 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 v5 2/2] display/drm/bridge: TC358775 DSI/LVDS driver
Hi Vinay. On Wed, Jul 01, 2020 at 12:33:37PM +0530, Vinay Simha BN wrote: Please provide some kind of changlog. for example info where this bridge is used. > Signed-off-by: Vinay Simha BN Some comments in the following. Sam > > --- > v1: > Initial version > > v2: > * Andrzej Hajda review comments incorporated > SPDX identifier > development debug removed > alphabetic order headers > u32 instead of unit32_t > magic numbers to macros for CLRSI and mux registers > ignored return value > > * Laurent Pinchart review comments incorporated > mdelay to usleep_range > bus_formats added > > v3: > * Andrzej Hajda review comments incorporated > drm_connector_status removed > u32 rev removed and local variabl is used > regulator enable disable with proper orders and delays > as per the spec > devm_drm_panel_bridge_add method used instead of panel > description modified > dual port implemented > > v4: > * Sam Ravnborg review comments incorporated > panel->connector_type removed > > * Reported-by: kernel test robot > parse_dt to static function > removed the if (endpoint), since data-lanes has to be > present for dsi dts ports > > v5: > ~vsdelay dynamic value set based on the > calculation of dsi speed, output speed, blanking > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/tc358775.c | 735 ++ > 3 files changed, 746 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/tc358775.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 43271c21d3fc..084e9853944a 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768 > help > Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > > +config DRM_TOSHIBA_TC358775 > +tristate "Toshiba TC358775 LVDS bridge" > +depends on OF > +select DRM_KMS_HELPER > +select REGMAP_I2C > +select DRM_PANEL > + select DRM_MIPI_DSI > +---help--- --help--- is no longer supported. Use plain "help". > + Toshiba TC358775 LVDS bridge chip driver. This is a very short description. Can you elaborate more here? > + > config DRM_TI_TFP410 > tristate "TI TFP410 DVI/HDMI bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index d63d4b7e4347..23c770b3bfe4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > +obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > diff --git a/drivers/gpu/drm/bridge/tc358775.c > b/drivers/gpu/drm/bridge/tc358775.c > new file mode 100644 > index ..e580c544190c > --- /dev/null > +++ b/drivers/gpu/drm/bridge/tc358775.c > @@ -0,0 +1,735 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * tc358775 DSI to LVDS bridge driver > + * > + * Copyright (C) 2020 SMART Wireless Computing > + * Author: Vinay Simha BN > + * > + */ > +/* #define DEBUG */ > +#include > +#include > +#include > +#include > +#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)) > + > +/* Registers */ > + > +/* DSI D-PHY Layer Registers */ > +#define D0W_DPHYCONTTX 0x0004 /* Data Lane 0 DPHY Tx Control */ > +#define CLW_DPHYCONTRX 0x0020 /* Clock Lane DPHY Rx Control */ > +#define D0W_DPHYCONTRX 0x0024 /* Data Lane 0 DPHY Rx Control */ > +#define D1W_DPHYCONTRX 0x0028 /* Data Lane 1 DPHY Rx Control */ > +#define D2W_DPHYCONTRX 0x002C /* Data Lane 2 DPHY Rx Control */ > +#define D3W_DPHYCONTRX 0x0030 /* Data Lane 3 DPHY Rx Control */ > +#define COM_DPHYCONTRX 0x0038 /* DPHY Rx Common Control */ > +#define CLW_CNTRL 0x0040 /* Clock Lane Control */ > +#define D0W_CNTRL 0x0044 /* Data Lane 0 Control */ > +#define D1W_CNTRL 0x0048 /* Data Lane 1 Control */ > +#define D2W_CNTRL 0x004C /* Data Lane 2 Control */ > +#define D3W_CNTRL 0x0050 /* Data Lane 3 Control */ > +#define DFTMODE_CNTRL 0x0054 /* DFT Mode Control */ > + > +/* DSI PPI Layer Registers */ > +#define PPI_STARTPPI0x0104 /* START control bit of PPI-TX function. */ > +#define PPI_START_FUNCTION 1 > + > +#define PPI_BUSYPPI 0x0108 > +#define PPI_LINEINITCNT 0x0110 /* Line Initialization
Re: [PATCH v5 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
Hi Vinay.
On Wed, Jul 01, 2020 at 12:33:36PM +0530, Vinay Simha BN wrote:
> This driver is tested with two panels with Apq8016-IFC6309 board
> https://www.inforcecomputing.com/products/single-board-computers-sbc/qualcomm-snapdragon-410-inforce-6309-micro-sbc
>
> 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24"
> 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24"
>
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> Initial version wast .txt file
>
> v2:
> From txt to yaml file format
>
> v3:
> * Andrzej Hajda review comments incorporated
> dual port lvds implemented
>
> * Laurent Pinchart review comments incorporated
> dsi lanes property removed and it is dynamically
> picked from the dsi ports
> VESA/JEIDA format picked from panel-lvds dts
> ---
> .../display/bridge/toshiba,tc358775.yaml | 204 ++
> 1 file changed, 204 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> new file mode 100644
> index ..ec53d62d408b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> @@ -0,0 +1,204 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC358775 DSI to LVDS bridge bindings
> +
> +maintainers:
> + - Vinay Simha BN
> +
> +description: |
> + This binding supports DSI to LVDS bridge TC358775
> +
> +properties:
> + compatible:
> +const: toshiba,tc358775
> +
> + reg:
> +maxItems: 1
> +description: i2c address of the bridge, 0x0f
> +
> + vdd-supply:
> +maxItems: 1
> +description: 1.2V LVDS Power Supply
> +
> + vddio-supply:
> +maxItems: 1
> +description: 1.8V IO Power Supply
> +
> + stby-gpios:
> +maxItems: 1
> +description: Standby pin, Low active
> +
> + reset-gpios:
> +maxItems: 1
> +description: Hardware reset, Low active
> +
> + ports:
> +type: object
> +description:
> + A node containing input and output port nodes with endpoint definitions
> + as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + DSI Input. The remote endpoint phandle should be a
> + reference to a valid mipi_dsi_host device node.
> +
> + port@1:
> +type: object
> +description: |
> + Video port for LVDS output (panel or connector).
> +
> + port@2:
> +type: object
> +description: |
> + Video port for Dual link LVDS output (panel or connector).
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> + - vddio-supply
> + - stby-gpios
> + - reset-gpios
> + - ports
> +
> +examples:
> + - |
> +#include
> +
> +i2c@78b8000 {
> +/* On High speed expansion */
> +label = "HS-I2C2";
> +reg = <0x078b8000 0x500>;
> +clock-frequency = <40>; /* fastmode operation */
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +tc_bridge: bridge@f {
> +compatible = "toshiba,tc358775";
> +reg = <0x0f>;
> +
> +vdd-supply = <_l2>;
> +vddio-supply = <_l6>;
> +
> +stby-gpios = < 99 GPIO_ACTIVE_LOW>;
> +reset-gpios = < 72 GPIO_ACTIVE_LOW>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +d2l_in_test: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
> +};
> +
> +dsi@1a98000 {
> +reg = <0x1a98000 0x25c>;
> +reg-names = "dsi_ctrl";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@1 {
> +reg = <1>;
> +dsi0_out: endpoint {
> +remote-endpoint = <_in_test>;
> +data-lanes = <0 1 2 3>;
> +};
> + };
> + };
> + };
> +
Fix indent. One of the '}' is indented one space too much.
> + - |
> +i2c@78b8000 {
> +/* On High speed expansion */
> +label = "HS-I2C2";
> +
