Re: [PATCH 1/2] drm/msm: Fix address space size after refactor.
On Wed, Jun 17, 2020 at 1:53 PM Eric Anholt wrote:
>
> Previously the address space went from 16M to ~0u, but with the
> refactor one of the 'f's was dropped, limiting us to 256MB.
> Additionally, the new interface takes a start and size, not start and
> end, so we can't just copy and paste.
>
> Fixes regressions in dEQP-VK.memory.allocation.random.*
>
> Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
> Signed-off-by: Eric Anholt
rebased on https://patchwork.freedesktop.org/series/78281/ (which
fixed half of the problem) and pushed this and 2/2 to msm-next so it
should show up in linux-next shortly..
planning to wait a short time more to see if we find any other issues
and then send a -fixes PR
BR,
-R
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 89673c7ed473..5db06b590943 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -194,7 +194,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct msm_gem_address_space *aspace;
>
> aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> - 0xfff);
> + 0x - SZ_16M);
>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: Don't set in MISC
On 6/17/20 8:29 PM, Thomas Zimmermann wrote: Hi Am 17.06.20 um 11:22 schrieb Rong Chen: On Wed, Jun 17, 2020 at 08:28:02AM +0200, Thomas Zimmermann wrote: Hi Emil Am 16.06.20 um 17:14 schrieb Emil Velikov: Hi Thomas, On Tue, 16 Jun 2020 at 15:26, Thomas Zimmermann wrote: The original modesetting code set MISC to 0x2d, which is , and With the conversion to atomic modesetting, accidentally got enabled as well. Revert this change and initialize MISC with a constant value of and . The bits are set in mga_crtc_set_plls(), sync flags are set in mgag200_set_mode_regs(). Let's keep the remove (restoring original functionality) and rename (cosmetics) separate patches. The read has also disappeared, which should be safe although might be better on it's own. I'm waiting for Rong Chen's performance results on this patch. Moving the rename into a separate patch makes sense, but removing the read is part of restoring the original behavior. I think it should be in this patch. Maybe I can write a better commit message to highlight the change. Hi Thomas, I tested the patch based on previous patch series, it seems doesn't take effect, and commit 39fb72816c4ee brings a larger regression when comparing to commit caac4dda44f37: Thanks for testing! I still don't understand these numbers, but are you sure that e44e907dd8f93 is really the regression? Yes, it's a regression too, according to the previous report https://www.spinics.net/lists/dri-devel/msg260034.html the bot bisected to commit e44e907dd8f93 which let the glmark2.800x600.score reduced by 64.9%, but the bot doesn't notice the improvement of commit caac4dda44f37, and commit 39fb72816c4ee causes another regression. Best Regards, Rong Chen It would make sense that 39fb72816c4ee has an impact on performance, as it changes memory management and the way the driver updates the display. I'll take a closer look at that patch and maybe send out an update. Best regards Thomas 4606edf870927 drm/mgag200: Don't set in MISC 3 3 3 39fb72816c4ee drm/mgag200: Replace VRAM helpers with SHMEM helpers 3 22 caac4dda44f37 drm/mgag200: Convert to simple KMS helper 238 233 240 234 239 4b11c90431108 drm/mgag200: Use simple-display data structures 35 34 34 34 db22c903c9322 drm/mgag200: Remove out-commented suspend/resume helpers 34 34 87d4880d2aeb5 drm/mgag200: Move register initialization into separate function 35 0c51726f95396 drm/mgag200: Move hiprilvl setting into separate functions 35 8078e8b182e73 drm/mgag200: Set primary plane's format in separate helper function35 19f7b409d95b7 drm/mgag200: Set pitch in a separate helper function 35 34 9b9a363828c60 drm/mgag200: Update mode registers after plane registers 34 e44e907dd8f93 drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O 34 34 34 34 bef2303526adb drm/mgag200: Move mode-setting code into separate helper function 97 97 5cd8460e81e8f drm/mgag200: Clean up mga_crtc_do_set_base() 96 0671ca8c559ba drm/mgag200: Clean up mga_set_start_address() e82c8969a2474 drm/mgag200: Remove HW cursor 96 Best Regards, Rong Chen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 51/80] drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
From: Roy Spliet [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c index ed7143d35b25..6224aca7cd29 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c @@ -769,7 +769,8 @@ static int mdp5_init(struct platform_device *pdev, struct drm_device *dev) return 0; fail: - mdp5_destroy(pdev); + if (mdp5_kms) + mdp5_destroy(pdev); return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 107/108] drm/sun4i: hdmi ddc clk: Fix size of m divider
From: Jernej Skrabec
[ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ]
m divider in DDC clock register is 4 bits wide. Fix that.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index a1f8cba251a2..3d9148eb40a7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -143,7 +143,7 @@
#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE 3
#define SUN4I_HDMI_DDC_CLK_REG 0x528
-#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
+#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0xf) << 3)
#define SUN4I_HDMI_DDC_CLK_N(n)((n) & 0x7)
#define SUN4I_HDMI_DDC_LINE_CTRL_REG 0x540
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
index 4692e8c345ed..58d9557a774f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
@@ -32,7 +32,7 @@ static unsigned long sun4i_ddc_calc_divider(unsigned long
rate,
unsigned long best_rate = 0;
u8 best_m = 0, best_n = 0, _m, _n;
- for (_m = 0; _m < 8; _m++) {
+ for (_m = 0; _m < 16; _m++) {
for (_n = 0; _n < 8; _n++) {
unsigned long tmp_rate;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 07/80] backlight: lp855x: Ensure regulators are disabled on probe failure
From: Jon Hunter
[ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051
_regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables
ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
Reviewed-by: Daniel Thompson
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/video/backlight/lp855x_bl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 939f057836e1..4cdc7a3f6dc5 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -460,7 +460,7 @@ static int lp855x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
ret = regulator_enable(lp->enable);
if (ret < 0) {
dev_err(lp->dev, "failed to enable vddio: %d\n", ret);
- return ret;
+ goto disable_supply;
}
/*
@@ -475,24 +475,34 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
ret = lp855x_configure(lp);
if (ret) {
dev_err(lp->dev, "device config err: %d", ret);
- return ret;
+ goto disable_vddio;
}
ret = lp855x_backlight_register(lp);
if (ret) {
dev_err(lp->dev,
"failed to register backlight. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
ret = sysfs_create_group(>dev->kobj, _attr_group);
if (ret) {
dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
backlight_update_status(lp->bl);
+
return 0;
+
+disable_vddio:
+ if (lp->enable)
+ regulator_disable(lp->enable);
+disable_supply:
+ if (lp->supply)
+ regulator_disable(lp->supply);
+
+ return ret;
}
static int lp855x_remove(struct i2c_client *cl)
@@ -501,6 +511,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ if (lp->enable)
+ regulator_disable(lp->enable);
if (lp->supply)
regulator_disable(lp->supply);
sysfs_remove_group(>dev->kobj, _attr_group);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 064/108] drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
From: Roy Spliet [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c index f7c0698fec40..791a74b9907d 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c @@ -972,7 +972,8 @@ static int mdp5_init(struct platform_device *pdev, struct drm_device *dev) return 0; fail: - mdp5_destroy(pdev); + if (mdp5_kms) + mdp5_destroy(pdev); return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 008/108] backlight: lp855x: Ensure regulators are disabled on probe failure
From: Jon Hunter
[ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051
_regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables
ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
Reviewed-by: Daniel Thompson
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/video/backlight/lp855x_bl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 939f057836e1..4cdc7a3f6dc5 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -460,7 +460,7 @@ static int lp855x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
ret = regulator_enable(lp->enable);
if (ret < 0) {
dev_err(lp->dev, "failed to enable vddio: %d\n", ret);
- return ret;
+ goto disable_supply;
}
/*
@@ -475,24 +475,34 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
ret = lp855x_configure(lp);
if (ret) {
dev_err(lp->dev, "device config err: %d", ret);
- return ret;
+ goto disable_vddio;
}
ret = lp855x_backlight_register(lp);
if (ret) {
dev_err(lp->dev,
"failed to register backlight. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
ret = sysfs_create_group(>dev->kobj, _attr_group);
if (ret) {
dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
backlight_update_status(lp->bl);
+
return 0;
+
+disable_vddio:
+ if (lp->enable)
+ regulator_disable(lp->enable);
+disable_supply:
+ if (lp->supply)
+ regulator_disable(lp->supply);
+
+ return ret;
}
static int lp855x_remove(struct i2c_client *cl)
@@ -501,6 +511,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ if (lp->enable)
+ regulator_disable(lp->enable);
if (lp->supply)
regulator_disable(lp->supply);
sysfs_remove_group(>dev->kobj, _attr_group);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 168/172] drm/sun4i: hdmi ddc clk: Fix size of m divider
From: Jernej Skrabec
[ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ]
m divider in DDC clock register is 4 bits wide. Fix that.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index b685ee11623d..a13e14dd7746 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -152,7 +152,7 @@
#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE 3
#define SUN4I_HDMI_DDC_CLK_REG 0x528
-#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
+#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0xf) << 3)
#define SUN4I_HDMI_DDC_CLK_N(n)((n) & 0x7)
#define SUN4I_HDMI_DDC_LINE_CTRL_REG 0x540
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
index e826da34e919..14b6762567fb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
@@ -37,7 +37,7 @@ static unsigned long sun4i_ddc_calc_divider(unsigned long
rate,
unsigned long best_rate = 0;
u8 best_m = 0, best_n = 0, _m, _n;
- for (_m = 0; _m < 8; _m++) {
+ for (_m = 0; _m < 16; _m++) {
for (_n = 0; _n < 8; _n++) {
unsigned long tmp_rate;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 097/172] drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
From: Roy Spliet [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c index bddd625ab91b..25691b7cece1 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c @@ -1021,7 +1021,8 @@ static int mdp5_init(struct platform_device *pdev, struct drm_device *dev) return 0; fail: - mdp5_destroy(pdev); + if (mdp5_kms) + mdp5_destroy(pdev); return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 010/172] backlight: lp855x: Ensure regulators are disabled on probe failure
From: Jon Hunter
[ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051
_regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables
ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
Reviewed-by: Daniel Thompson
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/video/backlight/lp855x_bl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 73612485ed07..bd43d8cff389 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -460,7 +460,7 @@ static int lp855x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
ret = regulator_enable(lp->enable);
if (ret < 0) {
dev_err(lp->dev, "failed to enable vddio: %d\n", ret);
- return ret;
+ goto disable_supply;
}
/*
@@ -475,24 +475,34 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
ret = lp855x_configure(lp);
if (ret) {
dev_err(lp->dev, "device config err: %d", ret);
- return ret;
+ goto disable_vddio;
}
ret = lp855x_backlight_register(lp);
if (ret) {
dev_err(lp->dev,
"failed to register backlight. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
ret = sysfs_create_group(>dev->kobj, _attr_group);
if (ret) {
dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
backlight_update_status(lp->bl);
+
return 0;
+
+disable_vddio:
+ if (lp->enable)
+ regulator_disable(lp->enable);
+disable_supply:
+ if (lp->supply)
+ regulator_disable(lp->supply);
+
+ return ret;
}
static int lp855x_remove(struct i2c_client *cl)
@@ -501,6 +511,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ if (lp->enable)
+ regulator_disable(lp->enable);
if (lp->supply)
regulator_disable(lp->supply);
sysfs_remove_group(>dev->kobj, _attr_group);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 257/266] drm/sun4i: hdmi ddc clk: Fix size of m divider
From: Jernej Skrabec
[ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ]
m divider in DDC clock register is 4 bits wide. Fix that.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 7ad3f06c127e..00ca35f07ba5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -148,7 +148,7 @@
#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE 3
#define SUN4I_HDMI_DDC_CLK_REG 0x528
-#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
+#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0xf) << 3)
#define SUN4I_HDMI_DDC_CLK_N(n)((n) & 0x7)
#define SUN4I_HDMI_DDC_LINE_CTRL_REG 0x540
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
index 2ff780114106..12430b9d4e93 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
@@ -33,7 +33,7 @@ static unsigned long sun4i_ddc_calc_divider(unsigned long
rate,
unsigned long best_rate = 0;
u8 best_m = 0, best_n = 0, _m, _n;
- for (_m = 0; _m < 8; _m++) {
+ for (_m = 0; _m < 16; _m++) {
for (_n = 0; _n < 8; _n++) {
unsigned long tmp_rate;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 215/266] drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection
From: Ben Skeggs
[ Upstream commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc ]
This is a SOR register, and not indexed by the bound head.
Fixes display not coming up on high-bandwidth HDMI displays under a
number of configurations.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
index 9b16a08eb4d9..bf6d41fb0c9f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
@@ -27,10 +27,10 @@ void
gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc)
{
struct nvkm_device *device = ior->disp->engine.subdev.device;
- const u32 hoff = head * 0x800;
+ const u32 soff = nv50_ior_base(ior);
const u32 ctrl = scdc & 0x3;
- nvkm_mask(device, 0x61c5bc + hoff, 0x0003, ctrl);
+ nvkm_mask(device, 0x61c5bc + soff, 0x0003, ctrl);
ior->tmds.high_speed = !!(scdc & 0x2);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 226/266] drm/amd/display: Revalidate bandwidth before commiting DC updates
From: Nicholas Kazlauskas
[ Upstream commit a24eaa5c51255b344d5a321f1eeb3205f2775498 ]
[Why]
Whenever we switch between tiled formats without also switching pixel
formats or doing anything else that recreates the DC plane state we
can run into underflow or hangs since we're not updating the
DML parameters before committing to the hardware.
[How]
If the update type is FULL then call validate_bandwidth again to update
the DML parmeters before committing the state.
This is basically just a workaround and protective measure against
update types being added DC where we could run into this issue in
the future.
We can only fully validate the state in advance before applying it to
the hardware if we recreate all the plane and stream states since
we can't modify what's currently in use.
The next step is to update DM to ensure that we're creating the plane
and stream states for whatever could potentially be a full update in
DC to pre-emptively recreate the state for DC global validation.
The workaround can stay until this has been fixed in DM.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Hersen Wu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 2028dc017f7a..b95a58aa82d9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2230,6 +2230,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_stream_update_to_stream(dc, context, stream, stream_update);
+ if (!dc->res_pool->funcs->validate_bandwidth(dc, context, false)) {
+ DC_ERROR("Mode validation failed for stream update!\n");
+ dc_release_state(context);
+ return;
+ }
+
commit_planes_for_stream(
dc,
srf_updates,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 156/266] drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
From: Roy Spliet [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c index 91cd76a2bab1..77823ccdd0f8 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c @@ -1037,7 +1037,8 @@ static int mdp5_init(struct platform_device *pdev, struct drm_device *dev) return 0; fail: - mdp5_destroy(pdev); + if (mdp5_kms) + mdp5_destroy(pdev); return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 011/266] backlight: lp855x: Ensure regulators are disabled on probe failure
From: Jon Hunter
[ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051
_regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables
ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
Reviewed-by: Daniel Thompson
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/video/backlight/lp855x_bl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index f68920131a4a..e94932c69f54 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -456,7 +456,7 @@ static int lp855x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
ret = regulator_enable(lp->enable);
if (ret < 0) {
dev_err(lp->dev, "failed to enable vddio: %d\n", ret);
- return ret;
+ goto disable_supply;
}
/*
@@ -471,24 +471,34 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
ret = lp855x_configure(lp);
if (ret) {
dev_err(lp->dev, "device config err: %d", ret);
- return ret;
+ goto disable_vddio;
}
ret = lp855x_backlight_register(lp);
if (ret) {
dev_err(lp->dev,
"failed to register backlight. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
ret = sysfs_create_group(>dev->kobj, _attr_group);
if (ret) {
dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
backlight_update_status(lp->bl);
+
return 0;
+
+disable_vddio:
+ if (lp->enable)
+ regulator_disable(lp->enable);
+disable_supply:
+ if (lp->supply)
+ regulator_disable(lp->supply);
+
+ return ret;
}
static int lp855x_remove(struct i2c_client *cl)
@@ -497,6 +507,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ if (lp->enable)
+ regulator_disable(lp->enable);
if (lp->supply)
regulator_disable(lp->supply);
sysfs_remove_group(>dev->kobj, _attr_group);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 370/388] drm/sun4i: hdmi ddc clk: Fix size of m divider
From: Jernej Skrabec
[ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ]
m divider in DDC clock register is 4 bits wide. Fix that.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 7ad3f06c127e..00ca35f07ba5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -148,7 +148,7 @@
#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE 3
#define SUN4I_HDMI_DDC_CLK_REG 0x528
-#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
+#define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0xf) << 3)
#define SUN4I_HDMI_DDC_CLK_N(n)((n) & 0x7)
#define SUN4I_HDMI_DDC_LINE_CTRL_REG 0x540
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
index 2ff780114106..12430b9d4e93 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
@@ -33,7 +33,7 @@ static unsigned long sun4i_ddc_calc_divider(unsigned long
rate,
unsigned long best_rate = 0;
u8 best_m = 0, best_n = 0, _m, _n;
- for (_m = 0; _m < 8; _m++) {
+ for (_m = 0; _m < 16; _m++) {
for (_n = 0; _n < 8; _n++) {
unsigned long tmp_rate;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 373/388] drm/ast: fix missing break in switch statement for format->cpp[0] case 4
From: Colin Ian King
[ Upstream commit 291ddeb621e4a9f1ced8302a777fbd7fbda058c6 ]
Currently the switch statement for format->cpp[0] value 4 assigns
color_index which is never read again and then falls through to the
default case and returns. This looks like a missing break statement
bug. Fix this by adding a break statement.
Addresses-Coverity: ("Unused value")
Fixes: 259d14a76a27 ("drm/ast: Split ast_set_vbios_mode_info()")
Signed-off-by: Colin Ian King
Signed-off-by: Thomas Zimmermann
Tested-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20200610115804.1132338-1-colin.k...@canonical.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index cdd6c46d6557..479fc60b6c93 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -226,6 +226,7 @@ static void ast_set_vbios_color_reg(struct ast_private *ast,
case 3:
case 4:
color_index = TrueCModeIndex;
+ break;
default:
return;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 329/388] drm/amd/display: Revalidate bandwidth before commiting DC updates
From: Nicholas Kazlauskas
[ Upstream commit a24eaa5c51255b344d5a321f1eeb3205f2775498 ]
[Why]
Whenever we switch between tiled formats without also switching pixel
formats or doing anything else that recreates the DC plane state we
can run into underflow or hangs since we're not updating the
DML parameters before committing to the hardware.
[How]
If the update type is FULL then call validate_bandwidth again to update
the DML parmeters before committing the state.
This is basically just a workaround and protective measure against
update types being added DC where we could run into this issue in
the future.
We can only fully validate the state in advance before applying it to
the hardware if we recreate all the plane and stream states since
we can't modify what's currently in use.
The next step is to update DM to ensure that we're creating the plane
and stream states for whatever could potentially be a full update in
DC to pre-emptively recreate the state for DC global validation.
The workaround can stay until this has been fixed in DM.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Hersen Wu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 47431ca6986d..4a619328101c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2517,6 +2517,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_stream_update_to_stream(dc, context, stream, stream_update);
+ if (!dc->res_pool->funcs->validate_bandwidth(dc, context, false)) {
+ DC_ERROR("Mode validation failed for stream update!\n");
+ dc_release_state(context);
+ return;
+ }
+
commit_planes_for_stream(
dc,
srf_updates,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 314/388] drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection
From: Ben Skeggs
[ Upstream commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc ]
This is a SOR register, and not indexed by the bound head.
Fixes display not coming up on high-bandwidth HDMI displays under a
number of configurations.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
index 9b16a08eb4d9..bf6d41fb0c9f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
@@ -27,10 +27,10 @@ void
gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc)
{
struct nvkm_device *device = ior->disp->engine.subdev.device;
- const u32 hoff = head * 0x800;
+ const u32 soff = nv50_ior_base(ior);
const u32 ctrl = scdc & 0x3;
- nvkm_mask(device, 0x61c5bc + hoff, 0x0003, ctrl);
+ nvkm_mask(device, 0x61c5bc + soff, 0x0003, ctrl);
ior->tmds.high_speed = !!(scdc & 0x2);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 231/388] drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
From: Roy Spliet [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c index 47b989834af1..c23a2fa13fb9 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c @@ -943,7 +943,8 @@ static int mdp5_init(struct platform_device *pdev, struct drm_device *dev) return 0; fail: - mdp5_destroy(pdev); + if (mdp5_kms) + mdp5_destroy(pdev); return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 230/388] drm/msm: Fix undefined "rd_full" link error
From: Bjorn Andersson
[ Upstream commit 20aebe83698feb107d5a66b6cfd1d54459ccdfcf ]
rd_full should be defined outside the CONFIG_DEBUG_FS region, in order
to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled.
Fixes: e515af8d4a6f ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP
buffers")
Reported-by: Stephen Rothwell
Signed-off-by: Bjorn Andersson
Reviewed-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_rd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 732f65df5c4f..fea30e7aa9e8 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -29,8 +29,6 @@
* or shader programs (if not emitted inline in cmdstream).
*/
-#ifdef CONFIG_DEBUG_FS
-
#include
#include
#include
@@ -47,6 +45,8 @@ bool rd_full = false;
MODULE_PARM_DESC(rd_full, "If true, $debugfs/.../rd will snapshot all buffer
contents");
module_param_named(rd_full, rd_full, bool, 0600);
+#ifdef CONFIG_DEBUG_FS
+
enum rd_sect_type {
RD_NONE,
RD_TEST, /* ascii text */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 090/388] drm/nouveau: gr/gk20a: Use firmware version 0
From: Thierry Reding
[ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ]
Tegra firmware doesn't actually use any version numbers and passing -1
causes the existing firmware binaries not to be found. Use version 0 to
find the correct files.
Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on
available FW")
Signed-off-by: Thierry Reding
Reviewed-by: Emil Velikov
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
index 4209b24a46d7..bf6b65257852 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
@@ -341,7 +341,7 @@ gk20a_gr_load(struct gf100_gr *gr, int ver, const struct
gf100_gr_fwif *fwif)
static const struct gf100_gr_fwif
gk20a_gr_fwif[] = {
- { -1, gk20a_gr_load, _gr },
+ { 0, gk20a_gr_load, _gr },
{}
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 014/388] backlight: lp855x: Ensure regulators are disabled on probe failure
From: Jon Hunter
[ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051
_regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables
ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
Reviewed-by: Daniel Thompson
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/video/backlight/lp855x_bl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index f68920131a4a..e94932c69f54 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -456,7 +456,7 @@ static int lp855x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
ret = regulator_enable(lp->enable);
if (ret < 0) {
dev_err(lp->dev, "failed to enable vddio: %d\n", ret);
- return ret;
+ goto disable_supply;
}
/*
@@ -471,24 +471,34 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
ret = lp855x_configure(lp);
if (ret) {
dev_err(lp->dev, "device config err: %d", ret);
- return ret;
+ goto disable_vddio;
}
ret = lp855x_backlight_register(lp);
if (ret) {
dev_err(lp->dev,
"failed to register backlight. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
ret = sysfs_create_group(>dev->kobj, _attr_group);
if (ret) {
dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
- return ret;
+ goto disable_vddio;
}
backlight_update_status(lp->bl);
+
return 0;
+
+disable_vddio:
+ if (lp->enable)
+ regulator_disable(lp->enable);
+disable_supply:
+ if (lp->supply)
+ regulator_disable(lp->supply);
+
+ return ret;
}
static int lp855x_remove(struct i2c_client *cl)
@@ -497,6 +507,8 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ if (lp->enable)
+ regulator_disable(lp->enable);
if (lp->supply)
regulator_disable(lp->supply);
sysfs_remove_group(>dev->kobj, _attr_group);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 319/414] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1817:28: sparse: sparse: cast to restricted __le32
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next head: f59073f6df9b07d94917221486cf5929efa6b315 commit: a5cc9a9321cb7c32ed9d8f6f82e82376bcc04f81 [319/414] drm/amd/powerplay: update powerplay table for sienna_cichlid config: i386-randconfig-s001-20200617 (attached as .config) compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-rc1-6-g78f577f8-dirty git checkout a5cc9a9321cb7c32ed9d8f6f82e82376bcc04f81 # save the attached .config to linux build tree make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1367:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MinClock @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1367:52: sparse: expected unsigned short [usertype] MinClock drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1367:52: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1371:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MaxClock @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1371:52: sparse: expected unsigned short [usertype] MaxClock drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1371:52: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1375:51: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MinUclk @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1375:51: sparse: expected unsigned short [usertype] MinUclk drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1375:51: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1379:51: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MaxUclk @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1379:51: sparse: expected unsigned short [usertype] MaxUclk drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1379:51: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1388:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MinClock @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1388:52: sparse: expected unsigned short [usertype] MinClock drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1388:52: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1392:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MaxClock @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1392:52: sparse: expected unsigned short [usertype] MaxClock drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1392:52: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1396:51: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MinUclk @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1396:51: sparse: expected unsigned short [usertype] MinUclk drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1396:51: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1400:51: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] MaxUclk @@ got restricted __le16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1400:51: sparse: expected unsigned short [usertype] MaxUclk drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1400:51: sparse: got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1726:5: sparse: sparse: symbol 'sienna_cichlid_get_dpm_ultimate_freq' was not declared. Should it be static? drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c:1742:5: sparse: sparse: symbol 'sienna_cichlid_set_soft_freq_limited_range' was not declared.
[Bug 208205] [amdgpu] System hang / freeze
https://bugzilla.kernel.org/show_bug.cgi?id=208205 --- Comment #4 from Automne von Einzbern (mar...@automne.me) --- Also on Kernel 5.8-rc1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] dt-bindings: display: ti,tfp410.yaml: make the ports node optional
Hi Rob, On Wed, Jun 17, 2020 at 04:34:55PM -0600, Rob Herring wrote: > On Thu, Jun 11, 2020 at 12:23:56PM +0200, Ricardo Cañuelo wrote: > > Make the ports node optional, since there are some DTs that don't define > > any ports for ti,tfp410. > > Only arch/arm/boot/dts/dove-sbc-a510.dts AFAICT... It should be updated > IMO. Agreed, but Ricardo wasn't sure how to update it. It would be nice if someone with knowledge of the hardware could have a look. By the way, this patch is dropped from v4 of the series. > > Signed-off-by: Ricardo Cañuelo > > --- > > Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > > b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > > index 605831c1e836..1c9421eb80fa 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > > @@ -83,7 +83,6 @@ properties: > > > > required: > >- compatible > > - - ports > > > > if: > >required: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 2/4] dt-bindings: display: simple: add Tianma TM070JVHG33
On Fri, 12 Jun 2020 09:22:17 +0200, Matthias Schiffer wrote: > Add the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to the > panel-simple compatible list. > > Signed-off-by: Matthias Schiffer > --- > > v2: no changes > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 1/4] dt-bindings: display: simple: add CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44
On Fri, 12 Jun 2020 09:22:16 +0200, Matthias Schiffer wrote: > Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and > S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list. > > Signed-off-by: Matthias Schiffer > --- > > v2: no changes > > .../devicetree/bindings/display/panel/panel-simple.yaml | 4 > 1 file changed, 4 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] gpu: ipu-v3: image-convert: Wait for all EOFs before completing a tile
Use a bit-mask of EOF irqs to determine when all required idmac
channel EOFs have been received for a tile conversion, and only do
tile completion processing after all EOFs have been received. Otherwise
it was found that a conversion would stall after the completion of a
tile and the start of the next tile, because the input/read idmac
channel had not completed and entered idle state, thus locking up the
channel when attempting to re-start it for the next tile.
Fixes: 0537db801bb01 ("gpu: ipu-v3: image-convert: reconfigure IC per tile")
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 108 ++---
1 file changed, 81 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index f8b031ded3cf..43e82eb79a08 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -137,6 +137,17 @@ struct ipu_image_convert_ctx;
struct ipu_image_convert_chan;
struct ipu_image_convert_priv;
+enum eof_irq_mask {
+ EOF_IRQ_IN = BIT(0),
+ EOF_IRQ_ROT_IN = BIT(1),
+ EOF_IRQ_OUT = BIT(2),
+ EOF_IRQ_ROT_OUT = BIT(3),
+};
+
+#define EOF_IRQ_COMPLETE (EOF_IRQ_IN | EOF_IRQ_OUT)
+#define EOF_IRQ_ROT_COMPLETE (EOF_IRQ_IN | EOF_IRQ_OUT | \
+ EOF_IRQ_ROT_IN | EOF_IRQ_ROT_OUT)
+
struct ipu_image_convert_ctx {
struct ipu_image_convert_chan *chan;
@@ -173,6 +184,9 @@ struct ipu_image_convert_ctx {
/* where to place converted tile in dest image */
unsigned int out_tile_map[MAX_TILES];
+ /* mask of completed EOF irqs at every tile conversion */
+ enum eof_irq_mask eof_mask;
+
struct list_head list;
};
@@ -189,6 +203,8 @@ struct ipu_image_convert_chan {
struct ipuv3_channel *rotation_out_chan;
/* the IPU end-of-frame irqs */
+ int in_eof_irq;
+ int rot_in_eof_irq;
int out_eof_irq;
int rot_out_eof_irq;
@@ -1380,6 +1396,9 @@ static int convert_start(struct ipu_image_convert_run
*run, unsigned int tile)
dev_dbg(priv->ipu->dev, "%s: task %u: starting ctx %p run %p tile %u ->
%u\n",
__func__, chan->ic_task, ctx, run, tile, dst_tile);
+ /* clear EOF irq mask */
+ ctx->eof_mask = 0;
+
if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
/* swap width/height for resizer */
dest_width = d_image->tile[dst_tile].height;
@@ -1615,7 +1634,7 @@ static bool ic_settings_changed(struct
ipu_image_convert_ctx *ctx)
}
/* hold irqlock when calling */
-static irqreturn_t do_irq(struct ipu_image_convert_run *run)
+static irqreturn_t do_tile_complete(struct ipu_image_convert_run *run)
{
struct ipu_image_convert_ctx *ctx = run->ctx;
struct ipu_image_convert_chan *chan = ctx->chan;
@@ -1715,8 +1734,9 @@ static irqreturn_t eof_irq(int irq, void *data)
struct ipu_image_convert_priv *priv = chan->priv;
struct ipu_image_convert_ctx *ctx;
struct ipu_image_convert_run *run;
+ irqreturn_t ret = IRQ_HANDLED;
+ bool tile_complete = false;
unsigned long flags;
- irqreturn_t ret;
spin_lock_irqsave(>irqlock, flags);
@@ -1729,27 +1749,33 @@ static irqreturn_t eof_irq(int irq, void *data)
ctx = run->ctx;
- if (irq == chan->out_eof_irq) {
- if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
- /* this is a rotation op, just ignore */
- ret = IRQ_HANDLED;
- goto out;
- }
- } else if (irq == chan->rot_out_eof_irq) {
+ if (irq == chan->in_eof_irq) {
+ ctx->eof_mask |= EOF_IRQ_IN;
+ } else if (irq == chan->out_eof_irq) {
+ ctx->eof_mask |= EOF_IRQ_OUT;
+ } else if (irq == chan->rot_in_eof_irq ||
+ irq == chan->rot_out_eof_irq) {
if (!ipu_rot_mode_is_irt(ctx->rot_mode)) {
/* this was NOT a rotation op, shouldn't happen */
dev_err(priv->ipu->dev,
"Unexpected rotation interrupt\n");
- ret = IRQ_HANDLED;
goto out;
}
+ ctx->eof_mask |= (irq == chan->rot_in_eof_irq) ?
+ EOF_IRQ_ROT_IN : EOF_IRQ_ROT_OUT;
} else {
dev_err(priv->ipu->dev, "Received unknown irq %d\n", irq);
ret = IRQ_NONE;
goto out;
}
- ret = do_irq(run);
+ if (ipu_rot_mode_is_irt(ctx->rot_mode))
+ tile_complete = (ctx->eof_mask == EOF_IRQ_ROT_COMPLETE);
+ else
+ tile_complete = (ctx->eof_mask == EOF_IRQ_COMPLETE);
+
+ if (tile_complete)
+ ret = do_tile_complete(run);
out:
spin_unlock_irqrestore(>irqlock, flags);
return ret;
@@ -1783,6 +1809,10 @@
[PATCH 1/3] gpu: ipu-v3: Restore RGB32, BGR32
RGB32 and BGR32 formats were inadvertently removed from the switch
statement in ipu_pixelformat_to_colorspace(). Restore them.
Fixes: a59957172b0c ("gpu: ipu-v3: enable remaining 32-bit RGB V4L2 pixel
formats")
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index ee2a025e54cf..b3dae9ec1a38 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -124,6 +124,8 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32
pixelformat)
case V4L2_PIX_FMT_RGBX32:
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_XRGB32:
+ case V4L2_PIX_FMT_RGB32:
+ case V4L2_PIX_FMT_BGR32:
return IPUV3_COLORSPACE_RGB;
default:
return IPUV3_COLORSPACE_UNKNOWN;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] gpu: ipu-v3: image-convert: Combine rotate/no-rotate irq handlers
Combine the rotate_irq() and norotate_irq() handlers into a single
eof_irq() handler.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 58 +-
1 file changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index eeca50d9a1ee..f8b031ded3cf 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1709,9 +1709,10 @@ static irqreturn_t do_irq(struct ipu_image_convert_run
*run)
return IRQ_WAKE_THREAD;
}
-static irqreturn_t norotate_irq(int irq, void *data)
+static irqreturn_t eof_irq(int irq, void *data)
{
struct ipu_image_convert_chan *chan = data;
+ struct ipu_image_convert_priv *priv = chan->priv;
struct ipu_image_convert_ctx *ctx;
struct ipu_image_convert_run *run;
unsigned long flags;
@@ -1728,45 +1729,26 @@ static irqreturn_t norotate_irq(int irq, void *data)
ctx = run->ctx;
- if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
- /* this is a rotation operation, just ignore */
- spin_unlock_irqrestore(>irqlock, flags);
- return IRQ_HANDLED;
- }
-
- ret = do_irq(run);
-out:
- spin_unlock_irqrestore(>irqlock, flags);
- return ret;
-}
-
-static irqreturn_t rotate_irq(int irq, void *data)
-{
- struct ipu_image_convert_chan *chan = data;
- struct ipu_image_convert_priv *priv = chan->priv;
- struct ipu_image_convert_ctx *ctx;
- struct ipu_image_convert_run *run;
- unsigned long flags;
- irqreturn_t ret;
-
- spin_lock_irqsave(>irqlock, flags);
-
- /* get current run and its context */
- run = chan->current_run;
- if (!run) {
+ if (irq == chan->out_eof_irq) {
+ if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
+ /* this is a rotation op, just ignore */
+ ret = IRQ_HANDLED;
+ goto out;
+ }
+ } else if (irq == chan->rot_out_eof_irq) {
+ if (!ipu_rot_mode_is_irt(ctx->rot_mode)) {
+ /* this was NOT a rotation op, shouldn't happen */
+ dev_err(priv->ipu->dev,
+ "Unexpected rotation interrupt\n");
+ ret = IRQ_HANDLED;
+ goto out;
+ }
+ } else {
+ dev_err(priv->ipu->dev, "Received unknown irq %d\n", irq);
ret = IRQ_NONE;
goto out;
}
- ctx = run->ctx;
-
- if (!ipu_rot_mode_is_irt(ctx->rot_mode)) {
- /* this was NOT a rotation operation, shouldn't happen */
- dev_err(priv->ipu->dev, "Unexpected rotation interrupt\n");
- spin_unlock_irqrestore(>irqlock, flags);
- return IRQ_HANDLED;
- }
-
ret = do_irq(run);
out:
spin_unlock_irqrestore(>irqlock, flags);
@@ -1859,7 +1841,7 @@ static int get_ipu_resources(struct
ipu_image_convert_chan *chan)
chan->out_chan,
IPU_IRQ_EOF);
- ret = request_threaded_irq(chan->out_eof_irq, norotate_irq, do_bh,
+ ret = request_threaded_irq(chan->out_eof_irq, eof_irq, do_bh,
0, "ipu-ic", chan);
if (ret < 0) {
dev_err(priv->ipu->dev, "could not acquire irq %d\n",
@@ -1872,7 +1854,7 @@ static int get_ipu_resources(struct
ipu_image_convert_chan *chan)
chan->rotation_out_chan,
IPU_IRQ_EOF);
- ret = request_threaded_irq(chan->rot_out_eof_irq, rotate_irq, do_bh,
+ ret = request_threaded_irq(chan->rot_out_eof_irq, eof_irq, do_bh,
0, "ipu-ic", chan);
if (ret < 0) {
dev_err(priv->ipu->dev, "could not acquire irq %d\n",
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] dt-bindings: display: ti,tfp410.yaml: make the ports node optional
On Mon, Jun 15, 2020 at 11:38:07AM +0200, Ricardo Cañuelo wrote: > Hi Laurent, > > Thanks for reviewing the patch > > On Thu, 2020-06-11 at 19:08 +0300, Laurent Pinchart wrote: > > Hi Ricardo, > > > > Thank you for the patch. > > > > On Thu, Jun 11, 2020 at 12:23:56PM +0200, Ricardo Cañuelo wrote: > > > Make the ports node optional, since there are some DTs that don't define > > > any ports for ti,tfp410. > > > > > > Signed-off-by: Ricardo Cañuelo > > > > Shouldn't we fix those DTs instead ? What's the point of a TFP410 > > without ports in DT ? > > This comes from the discussion in the previous version of this series. > > In the DTs that don't define any ports (it's dove-sbc-a510.dts only, actually) > it's not clear how to define the ports (I'm not familiar with this board). > Initially I defined a set of empty ports just to comply with the binding > requirements, but Rob suggested that we might as well declare them as > optional, > since having an empty port definition with no remote endpoints is no better > than > having no ports at all. I did? Must have missed some context. > I understand both opinions but I just don't know which is the best option at > this point. Just leave the warning to be fixed. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] dt-bindings: display: ti,tfp410.yaml: make the ports node optional
On Thu, Jun 11, 2020 at 12:23:56PM +0200, Ricardo Cañuelo wrote: > Make the ports node optional, since there are some DTs that don't define > any ports for ti,tfp410. Only arch/arm/boot/dts/dove-sbc-a510.dts AFAICT... It should be updated IMO. > > Signed-off-by: Ricardo Cañuelo > --- > Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > index 605831c1e836..1c9421eb80fa 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml > @@ -83,7 +83,6 @@ properties: > > required: >- compatible > - - ports > > if: >required: > -- > 2.18.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd drm-fixes-5.8
Hi Dave, Daniel, Fixes for 5.8. The following changes since commit 8d286e2ff4400d313955b4203fc640ca6fd9228b: Merge tag 'drm-intel-next-fixes-2020-06-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-06-08 11:59:57 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.8-2020-06-17 for you to fetch changes up to da9cebe16930f0273278fe893f2809450c61ae41: drm/amdgpu: fix documentation around busy_percentage (2020-06-17 17:42:43 -0400) amd-drm-fixes-5.8-2020-06-17: amdgpu: - Fix kvfree/kfree mixup - Fix hawaii device id in powertune configuration - Display FP fixes - Documentation fixes amdkfd: - devcgroup check fix Alex Deucher (2): drm/amdgpu/pm: update comment to clarify Overdrive interfaces drm/amdgpu: fix documentation around busy_percentage Denis Efremov (2): drm/amd/display: Use kvfree() to free coeff in build_regamma() drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp() Lorenz Brun (1): drm/amdkfd: Use correct major in devcgroup check Rodrigo Siqueira (1): drm/amd/display: Rework dsc to isolate FPU operations Sandeep Raghuraman (1): drm/amdgpu: Replace invalid device ID with a valid device ID Documentation/gpu/amdgpu.rst | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +- drivers/gpu/drm/amd/display/dc/dsc/Makefile| 2 - drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c| 18 +-- drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c | 151 - drivers/gpu/drm/amd/display/dc/dsc/rc_calc.h | 5 +- drivers/gpu/drm/amd/display/dc/dsc/rc_calc_dpi.c | 27 +--- .../drm/amd/display/modules/color/color_gamma.c| 4 +- drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 +- 10 files changed, 166 insertions(+), 59 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/i915/query: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/i915/i915_query.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index e75c528ebbe0..c1ebda9b5627 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -109,8 +109,7 @@ query_engine_info(struct drm_i915_private *i915, for_each_uabi_engine(engine, i915) num_uabi_engines++; - len = sizeof(struct drm_i915_query_engine_info) + - num_uabi_engines * sizeof(struct drm_i915_engine_info); + len = struct_size(query_ptr, engines, num_uabi_engines); ret = copy_query_item(, sizeof(query), len, query_item); if (ret != 0) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: ipu-v3: image-convert: Wait for channels before disabling
Hi Philpp,
Please disregard this patch. A better solution to a busy wait with a
spin lock held is to wait for all required EOF interrupts before doing
tile completion processing. I will submit a new patch series.
Steve
On 6/9/20 5:51 PM, Steve Longerbeam wrote:
Call ipu_idmac_wait_busy() on each idmac channel to busy wait for the
channel to be idle before disabling. Otherwise it was found that a
conversion would stall after the completion of a tile and the start
of the next tile.
Fixes: 0537db801bb01 ("gpu: ipu-v3: image-convert: reconfigure IC per tile")
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index eeca50d9a1ee..f0938015d2fd 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1251,6 +1251,19 @@ static int get_run_count(struct ipu_image_convert_ctx
*ctx,
return count;
}
+static void stop_channel(struct ipu_image_convert_chan *chan,
+struct ipuv3_channel *channel)
+{
+ struct ipu_image_convert_priv *priv = chan->priv;
+ int ret;
+
+ ret = ipu_idmac_wait_busy(channel, 1);
+ if (ret == -ETIMEDOUT)
+ dev_warn(priv->ipu->dev, "IDMAC timeout\n");
+
+ ipu_idmac_disable_channel(channel);
+}
+
static void convert_stop(struct ipu_image_convert_run *run)
{
struct ipu_image_convert_ctx *ctx = run->ctx;
@@ -1262,12 +1275,12 @@ static void convert_stop(struct ipu_image_convert_run
*run)
/* disable IC tasks and the channels */
ipu_ic_task_disable(chan->ic);
- ipu_idmac_disable_channel(chan->in_chan);
- ipu_idmac_disable_channel(chan->out_chan);
+ stop_channel(chan, chan->in_chan);
+ stop_channel(chan, chan->out_chan);
if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
- ipu_idmac_disable_channel(chan->rotation_in_chan);
- ipu_idmac_disable_channel(chan->rotation_out_chan);
+ stop_channel(chan, chan->rotation_in_chan);
+ stop_channel(chan, chan->rotation_out_chan);
ipu_idmac_unlink(chan->out_chan, chan->rotation_in_chan);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/virtio: Use struct_size() helper in kmalloc()
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 24ffacac99e4..c30c75ee83fc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -154,9 +154,8 @@ void virtio_gpu_gem_object_close(struct drm_gem_object *obj,
struct virtio_gpu_object_array *virtio_gpu_array_alloc(u32 nents)
{
struct virtio_gpu_object_array *objs;
- size_t size = sizeof(*objs) + sizeof(objs->objs[0]) * nents;
- objs = kmalloc(size, GFP_KERNEL);
+ objs = kmalloc(struct_size(objs, objs, nents), GFP_KERNEL);
if (!objs)
return NULL;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/vmwgfx: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c index 126f93c0b0b8..3914bfee0533 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c @@ -1969,7 +1969,7 @@ static int vmw_surface_dirty_alloc(struct vmw_resource *res) num_mip = 1; num_subres = num_layers * num_mip; - dirty_size = sizeof(*dirty) + num_subres * sizeof(dirty->boxes[0]); + dirty_size = struct_size(dirty, boxes, num_subres); acc_size = ttm_round_pot(dirty_size); ret = ttm_mem_global_alloc(vmw_mem_glob(res->dev_priv), acc_size, ); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 22/37] dt-bindings: host1x: Document new interconnect properties
On Tue, Jun 09, 2020 at 04:13:49PM +0300, Dmitry Osipenko wrote: > Most of Host1x devices have at least one memory client. These clients > are directly connected to the memory controller. The new interconnect > properties represent the memory client's connection to the memory > controller. > > Signed-off-by: Dmitry Osipenko > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++ > 1 file changed, 68 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > index 47319214b5f6..ab4fbee7bccf 100644 > --- > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > +++ > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > @@ -20,6 +20,10 @@ Required properties: > - reset-names: Must include the following entries: >- host1x > > +Each host1x client module having to perform DMA through the Memory Controller > +should have the interconnect endpoints set to the Memory Client and External > +Memory respectively. > + > The host1x top-level node defines a number of children, each representing one > of the following host1x client modules: > > @@ -36,6 +40,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - mpe > > + Optional properties: > + - interconnects: Must contain entry for the MPE memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - vi: video input > >Required properties: > @@ -65,6 +75,12 @@ of the following host1x client modules: >- power-domains: Must include sor powergate node as csicil is in > SOR partition. > > + Optional properties: > + - interconnects: Must contain entry for the VI memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - epp: encoder pre-processor > >Required properties: > @@ -78,6 +94,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - epp > > + Optional properties: > + - interconnects: Must contain entry for the EPP memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - isp: image signal processor > >Required properties: > @@ -91,6 +113,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - isp > > + Optional properties: > + - interconnects: Must contain entry for the ISP memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - gr2d: 2D graphics engine > >Required properties: > @@ -104,6 +132,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - 2d > > + Optional properties: > + - interconnects: Must contain entry for the GR2D memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - gr3d: 3D graphics engine > >Required properties: > @@ -122,6 +156,12 @@ of the following host1x client modules: > - 3d > - 3d2 (Only required on SoCs with two 3D clocks) > > + Optional properties: > + - interconnects: Must contain entry for the GR3D memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > + > - dc: display controller > >Required properties: > @@ -149,6 +189,10 @@ of the following host1x client modules: >- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection >- nvidia,edid: supplies a binary EDID blob >- nvidia,panel: phandle of a display panel > + - interconnects: Must contain entry for the DC memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients, see MEMORY CONTROLLER section. > > - hdmi: High Definition Multimedia Interface > > @@ -297,6 +341,12 @@ of the following host1x client modules: >-
[PATCH 1/2] drm/msm: Fix address space size after refactor.
Previously the address space went from 16M to ~0u, but with the
refactor one of the 'f's was dropped, limiting us to 256MB.
Additionally, the new interface takes a start and size, not start and
end, so we can't just copy and paste.
Fixes regressions in dEQP-VK.memory.allocation.random.*
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 89673c7ed473..5db06b590943 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -194,7 +194,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct msm_gem_address_space *aspace;
aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
- 0xfff);
+ 0x - SZ_16M);
if (IS_ERR(aspace) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm: Fix setup of a6xx create_address_space.
We don't want it under CONFIG_DRM_MSM_GPU_STATE, we need it all the
time (like the other GPUs do).
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index a1589e040c57..7768557cdfb2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -893,8 +893,8 @@ static const struct adreno_gpu_funcs funcs = {
#if defined(CONFIG_DRM_MSM_GPU_STATE)
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
#endif
+ .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a6xx_get_timestamp,
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] drm/msm: Refactor address space initialization
On Wed, Jun 17, 2020 at 1:16 PM Eric Anholt wrote: > > On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote: > > > > Refactor how address space initialization works. Instead of having the > > address space function create the MMU object (and thus require separate but > > equal functions for gpummu and iommu) use a single function and pass the > > MMU struct in. Make the generic code cleaner by using target specific > > functions to create the address space so a2xx can do its own thing in its > > own space. For all the other targets use a generic helper to initialize > > IOMMU but leave the door open for newer targets to use customization > > if they need it. > > I'm seeing regressions in dEQP-VK.memory.allocation.random.* on cheza > after this commit. The symptom is that large allocations fail with > -ENOSPC from MSM_GEM_INFO(IOVA). > > Possibly relevant change from having stuffed some debug info in: > > before: > [3.791436] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x100 + 0xfeff > [3.801672] platform 506a000.gmu: Adding to iommu group 6 > [3.807359] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x0 + 0x7fff > [3.817140] msm ae0.mdss: bound 500.gpu (ops a3xx_ops) > [3.823212] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed > to get memory resource: vbif_nrt > [3.832429] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed > to get memory resource: regdma > [3.841478] [drm:dpu_kms_hw_init:878] dpu hardware revision:0x4000 > [3.848193] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x1000 + 0xefff > > after: > > [3.798707] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x100 + 0xfff > [3.808731] platform 506a000.gmu: Adding to iommu group 6 > [3.814440] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x0 + 0x7fff > [3.820494] hub 2-1:1.0: USB hub found > [3.824108] msm ae0.mdss: bound 500.gpu (ops a3xx_ops) > [3.828554] hub 2-1:1.0: 4 ports detected > [3.833756] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed > to get memory resource: vbif_nrt > [3.847038] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed > to get memory resource: regdma > [3.856095] [drm:dpu_kms_hw_init:878] dpu hardware revision:0x4000 > [3.862840] [drm:msm_gem_address_space_create] *ERROR* msmgem > address space create: 0x1000 + 0xfff > > 256MB for GMU address space? Found the bug, fixes at the last 2 commits of https://github.com/anholt/linux/tree/drm-msm-address-space I'm going to try having another go at convincing gmail to let git send-email through, but all the howtos in the world didn't work last time (gsuite has different behavior from normal gmail). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 006/105] dt-bindings: display: Convert VC4 bindings to schemas
On Wed, May 27, 2020 at 9:49 AM Maxime Ripard wrote:
>
> The BCM283x SoCs have a display pipeline composed of several controllers
> with device tree bindings that are supported by Linux.
>
> Now that we have the DT validation in place, let's split into separate
> files and convert the device tree bindings for those controllers to
> schemas.
>
> This is just a 1:1 conversion though, and some bindings were incomplete so
> it results in example validation warnings that are going to be addressed in
> the following patches.
>
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt |
> 174 +
> Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml |
> 66 +++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml|
> 73 ++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml|
> 75 +++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml |
> 37 +++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml |
> 40 +-
> Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml |
> 37 +++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml |
> 42 +-
> Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml |
> 34 ++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml |
> 44 ++-
> MAINTAINERS |
> 2 +-
> 11 files changed, 449 insertions(+), 175 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
Not sure why my checks didn't catch this, but now linux-next has these warnings:
/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: compatible: Additional items are not allowed ('simple-panel'
was unexpected)
/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: compatible: ['ontat,yx700wv03', 'simple-panel'] is too long
/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: 'power-supply' is a required property
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] drm/msm: Refactor address space initialization
On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote: > > Refactor how address space initialization works. Instead of having the > address space function create the MMU object (and thus require separate but > equal functions for gpummu and iommu) use a single function and pass the > MMU struct in. Make the generic code cleaner by using target specific > functions to create the address space so a2xx can do its own thing in its > own space. For all the other targets use a generic helper to initialize > IOMMU but leave the door open for newer targets to use customization > if they need it. I'm seeing regressions in dEQP-VK.memory.allocation.random.* on cheza after this commit. The symptom is that large allocations fail with -ENOSPC from MSM_GEM_INFO(IOVA). Possibly relevant change from having stuffed some debug info in: before: [3.791436] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x100 + 0xfeff [3.801672] platform 506a000.gmu: Adding to iommu group 6 [3.807359] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x0 + 0x7fff [3.817140] msm ae0.mdss: bound 500.gpu (ops a3xx_ops) [3.823212] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed to get memory resource: vbif_nrt [3.832429] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed to get memory resource: regdma [3.841478] [drm:dpu_kms_hw_init:878] dpu hardware revision:0x4000 [3.848193] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x1000 + 0xefff after: [3.798707] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x100 + 0xfff [3.808731] platform 506a000.gmu: Adding to iommu group 6 [3.814440] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x0 + 0x7fff [3.820494] hub 2-1:1.0: USB hub found [3.824108] msm ae0.mdss: bound 500.gpu (ops a3xx_ops) [3.828554] hub 2-1:1.0: 4 ports detected [3.833756] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed to get memory resource: vbif_nrt [3.847038] msm_dpu ae01000.mdp: [drm:msm_ioremap] *ERROR* failed to get memory resource: regdma [3.856095] [drm:dpu_kms_hw_init:878] dpu hardware revision:0x4000 [3.862840] [drm:msm_gem_address_space_create] *ERROR* msmgem address space create: 0x1000 + 0xfff 256MB for GMU address space? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 317/414] drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2480:28: sparse: sparse: cast to restricted __le32
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: f59073f6df9b07d94917221486cf5929efa6b315
commit: 00e86cf4bb21d5904053da0c2327dbcfa21f22ca [317/414] drm/amd/powerplay:
move powerplay table operation out of smu_v11_0.c
config: i386-randconfig-s001-20200617 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-rc1-6-g78f577f8-dirty
git checkout 00e86cf4bb21d5904053da0c2327dbcfa21f22ca
# save the attached .config to linux build tree
make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2480:28: sparse:
>> sparse: cast to restricted __le32
--
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1495:52: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MinClock @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1495:52: sparse:
expected unsigned short [usertype] MinClock
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1495:52: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1499:52: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MaxClock @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1499:52: sparse:
expected unsigned short [usertype] MaxClock
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1499:52: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1503:51: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MinUclk @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1503:51: sparse:
expected unsigned short [usertype] MinUclk
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1503:51: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1507:51: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MaxUclk @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1507:51: sparse:
expected unsigned short [usertype] MaxUclk
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1507:51: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1516:52: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MinClock @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1516:52: sparse:
expected unsigned short [usertype] MinClock
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1516:52: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1520:52: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MaxClock @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1520:52: sparse:
expected unsigned short [usertype] MaxClock
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1520:52: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1524:51: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MinUclk @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1524:51: sparse:
expected unsigned short [usertype] MinUclk
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1524:51: sparse:
got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1528:51: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
unsigned short [usertype] MaxUclk @@ got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1528:51: sparse:
expected unsigned short [usertype] MaxUclk
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1528:51: sparse:
got restricted __le16 [usertype]
>> drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:2323:28: sparse:
>> sparse: cast to restricted __le32
vim +2480 drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c
2463
2464 static uint32_t atcturus_get_max_power_limit(struct smu_context *smu) {
2465 uint32_t od_limit, max_power_limit;
2466 struct smu_11_0_powerplay_table *powerplay_table
Re: [PATCH v3] drm/panfrost: Reduce the amount of logs on deferred probe
On Wed, Jun 17, 2020 at 8:36 AM Steven Price wrote: > > On 17/06/2020 15:15, Krzysztof Kozlowski wrote: > > On Wed, May 27, 2020 at 04:43:34PM -0400, Alyssa Rosenzweig wrote: > >> Reviewed-by: Alyssa Rosenzweig > >> > >> On Wed, May 27, 2020 at 10:05:44PM +0200, Krzysztof Kozlowski wrote: > >>> There is no point to print deferred probe (and its failures to get > >>> resources) as an error. Also there is no need to print regulator errors > >>> twice. > >>> > >>> In case of multiple probe tries this would pollute the dmesg. > >>> > >>> Signed-off-by: Krzysztof Kozlowski > >>> Reviewed-by: Steven Price > >>> > >>> --- > >>> > >>> Changes since v2: > >>> 1. Rebase > >>> 2. Add Steven's review > >>> > >>> Changes since v1: > >>> 1. Remove second error message from calling panfrost_regulator_init() > >>> --- > >>> drivers/gpu/drm/panfrost/panfrost_device.c | 8 > >>> 1 file changed, 4 insertions(+), 4 deletions(-) > >>> > > > > Hi Rob, Tomeu and Steven, > > > > You're listed as maintainers for panfrost. Is anyone going to pick this > > up? > > I'm only a reviewer so I've been leaving it for Rob or Tomeu, but I can > pick it up if Rob/Tomeu are happy for me to do that. > > > Maybe I sent it to wrong mailing list or forgot about anything? > > No, there's actually a few Panfrost commits waiting, it was on my todo > list to ask if Rob/Tomeu needed some help with merging patches. Please do, I haven't had the cycles for panfrost lately. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: Don't set in MISC
On Wed, 17 Jun 2020 at 07:28, Thomas Zimmermann wrote: > Maybe I can write a better commit message to highlight the change. > That would be amazing, thank you. Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Stephen, On Wed, 17 Jun 2020 at 08:03, Stephen Rothwell wrote: > > Hi Thomas, > > On Wed, 17 Jun 2020 08:33:24 +0200 Thomas Zimmermann > wrote: > > > > We recently dropped the _unlock() suffix from drm_gem_object_put(). This > > patch should be ok. > > Yes, but what it shows is that the drm-misc tree is still based on > v5.7-rc1 and v5.8-rc1 has about 16000 more commits for you to get > conflicts against :-) > Being the culprit here - thanks for the patience and report. I believe that both AMD and drm-misc teams are aware of this lovely situation I've put them in. As you mentioned drm-misc is a bit special and doing the usual backmerge will be fun. If you have any tips on how to minimise such issues, I'd gladly utilise them. Thanks again, -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/amdgpu/debugfs: fix memory leak when amdgpu_virt_enable_access_debugfs failed
Applied. Thanks!
Alex
On Wed, Jun 17, 2020 at 9:10 AM Chen Tao wrote:
>
> Fix memory leak in amdgpu_debugfs_gpr_read not freeing data when
> amdgpu_virt_enable_access_debugfs failed.
>
> Fixes: 95a2f917387a2 ("drm/amdgpu: restrict debugfs register accessunder
> SR-IOV")
> Signed-off-by: Chen Tao
> ---
> v1->v2:
> - remove the duplication of result and r here and then use "goto err"
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 7993b9eeff38..7086e1982f9e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -867,7 +867,7 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f,
> char __user *buf,
>
> r = amdgpu_virt_enable_access_debugfs(adev);
> if (r < 0)
> - return r;
> + goto err;
>
> /* switch to the specific se/sh/cu */
> mutex_lock(>grbm_idx_mutex);
> --
> 2.22.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: add support for min horizontal rate equal to max horizontal rate
On Thu, Jun 18, 2020 at 12:58:33AM +0800, Cyrus Lien wrote: > On Tue, Jun 9, 2020 at 10:58 PM Ville Syrjälä > wrote: > > > On Tue, Jun 09, 2020 at 03:57:04AM +0800, Cyrus Lien wrote: > > > According to EDID spec, table 3.26, byte #6 and #8, which said "Minimum > > > rate value shall be less than or equal to maximum rate value". The > > minimum > > > horizontal/vertical rate value is able to be equal to maximum horizontal/ > > > veritcal rate value. > > > > How does that justifiy ignoring the min value? > > > > Indeed, this patch does not make sense. > Setting minimum horizontal rate equal to maximum horizontal rate is a > request come from AMD Windows graphic driver for support freesync (I'm not > sure if linux AMD driver also require it). AFAICS the DP spec itself doesn't say anything about the horizontal min/max rates. However DP-EDID-CTS 1.2 / 4.8 seems to say that hmin==hmax==hsync should hold. Not sure if that should be the hsync rate of the min/max/nominal refresh rate. I would have maybe expected the max since that's the actual rate it's going operate at. Alhtough I even less of an idea what it should be if the monitor supports multiple resolutions. In this case it doesn't seem to be any of those exactly. Pretty close to the min refresh rate though. hmin=hmax=110 kHz vs. actual hsync rate for 50Hz would be 111.1 kHz (if it was actually running at 50Hz with the declared vblank length which it won't be of course). If we calculate in the opposite direction we get a vrefresh of ~49.5 Hz based on the 110 kHz hsync rate. So if we round to nearest integer it does match the declared vmin of 50Hz. I suspect the right answer is to just ignore hmin/hmax when it comes to adaptive sync. > The problem is mode_in_hsync_range always return false except the mode's > hsync exactly equal to hmax and hmin. > > Add print in mode_in_hsync_range(): > [drm] mode_in_hsync_range 1920x1200: hsync: 94, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1200: hsync: 107, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1200: hsync: 152, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 90, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 113, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 183, hmax: 110, hmix:110 > > Is it available to get or calculate the hmax, hmix value from other fields > in EDID ? > Would you please provide some advice or directions to solve this problem ? > Thank you and appreciated the help. > > edid-decode (hex): > > 00 ff ff ff ff ff ff 00 06 af 9b 32 00 00 00 00 > 00 1e 01 04 b5 26 15 78 03 1f 95 a5 53 35 b5 26 > 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > 01 01 01 01 01 01 70 d0 00 a0 f0 70 3e 80 30 20 > 35 00 7d d6 10 00 00 1a 00 00 00 fd 00 32 5a 6e > 6e 17 01 11 01 e0 60 20 50 3c 00 00 00 fe 00 34 > 34 54 52 4e 15 42 31 37 33 5a 41 4e 00 00 00 00 > 00 05 81 01 28 00 12 00 00 0b 01 0a 20 20 01 af > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > EDID version: 1.4 > Manufacturer: AUO Model 12955 Serial Number 0 > Made in year 2020 > Digital display > 10 bits per primary color channel > DisplayPort interface > Maximum image size: 38 cm x 21 cm > Gamma: 2.20 > Supported color formats: RGB 4:4:4 > First detailed timing includes the native pixel format and preferred > refresh rate > Display is continuous frequency > Color Characteristics > Red: 0.6445, 0.3251 > Green: 0.2099, 0.7099 > Blue: 0.1503, 0.0595 > White: 0.3134, 0.3291 > Established Timings I & II: none > Standard Timings: none > Detailed mode: Clock 533.600 MHz, 381 mm x 214 mm >3840 3888 3920 4000 ( 48 32 80) >2160 2163 2168 ( 3 5 54) >+hsync -vsync >VertFreq: 60.036 Hz, HorFreq: 133.400 kHz > Display Range Limits > Monitor ranges (Bare Limits): 50-90 Hz V, 110-110 kHz H, max dotclock 230 > MHz > Alphanumeric Data String: 44TRN > Manufacturer-Specified Display Descriptor (0x00): 00 00 00 05 81 01 28 00 > 12 00 00 0b 01 0a 20 20 ..(... > Has 1 extension block > Checksum: 0xaf > > > > > > > > This change check if h/v-sync excess maximum horizontal/vertical rate if > > > hmin equal to hmax or vmin equal to vmax. > > > > > > Signed-off-by: Cyrus Lien > > > --- > > > drivers/gpu/drm/drm_edid.c | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > > index fed653f13c26..23878320eabd 100644 > > > --- a/drivers/gpu/drm/drm_edid.c > > > +++ b/drivers/gpu/drm/drm_edid.c > > > @@ -2674,6 +2674,9 @@
[PATCH][next] fbdev/fb.h: Use struct_size() helper in kzalloc()
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva
---
include/linux/fb.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3b4b2f0c6994..2b530e6d86e4 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -506,8 +506,9 @@ struct fb_info {
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
- struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
- + max_num * sizeof(struct aperture), GFP_KERNEL);
+ struct apertures_struct *a;
+
+ a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
if (!a)
return NULL;
a->count = max_num;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan Teja >Kalla >Sent: Wednesday, June 17, 2020 2:29 AM >To: Ruhl, Michael J ; Sumit Semwal >; open list:DMA BUFFER SHARING FRAMEWORK >; DRI mailing list de...@lists.freedesktop.org> >Cc: Linaro MM SIG ; >vinme...@codeaurora.org; LKML ; >sta...@vger.kernel.org >Subject: Re: [PATCH] dmabuf: use spinlock to access dmabuf->name > >Thanks Michael for the comments.. > >On 6/16/2020 7:29 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: dri-devel On Behalf Of >>> Ruhl, Michael J >>> Sent: Tuesday, June 16, 2020 9:51 AM >>> To: Charan Teja Kalla ; Sumit Semwal >>> ; open list:DMA BUFFER SHARING >FRAMEWORK >>> ; DRI mailing list >> de...@lists.freedesktop.org> >>> Cc: Linaro MM SIG ; >>> vinme...@codeaurora.org; LKML ; >>> sta...@vger.kernel.org >>> Subject: RE: [PATCH] dmabuf: use spinlock to access dmabuf->name >>> -Original Message- From: dri-devel On Behalf Of Charan Teja Kalla Sent: Thursday, June 11, 2020 9:40 AM To: Sumit Semwal ; open list:DMA BUFFER SHARING FRAMEWORK ; DRI mailing list de...@lists.freedesktop.org> Cc: Linaro MM SIG ; vinme...@codeaurora.org; LKML ; sta...@vger.kernel.org Subject: [PATCH] dmabuf: use spinlock to access dmabuf->name There exists a sleep-while-atomic bug while accessing the dmabuf->name under mutex in the dmabuffs_dname(). This is caused from the SELinux permissions checks on a process where it tries to validate the inherited files from fork() by traversing them through iterate_fd() (which traverse files under spin_lock) and call match_file(security/selinux/hooks.c) where the permission checks >happen. This audit information is logged using dump_common_audit_data() >where it calls d_path() to get the file path name. If the file check happen on the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex >to access dmabuf->name. The flow will be like below: flush_unauthorized_files() iterate_fd() spin_lock() --> Start of the atomic section. match_file() file_has_perm() avc_has_perm() avc_audit() slow_avc_audit() common_lsm_audit() dump_common_audit_data() audit_log_d_path() d_path() dmabuffs_dname() mutex_lock()--> Sleep while atomic. Call trace captured (on 4.19 kernels) is below: ___might_sleep+0x204/0x208 __might_sleep+0x50/0x88 __mutex_lock_common+0x5c/0x1068 __mutex_lock_common+0x5c/0x1068 mutex_lock_nested+0x40/0x50 dmabuffs_dname+0xa0/0x170 d_path+0x84/0x290 audit_log_d_path+0x74/0x130 common_lsm_audit+0x334/0x6e8 slow_avc_audit+0xb8/0xf8 avc_has_perm+0x154/0x218 file_has_perm+0x70/0x180 match_file+0x60/0x78 iterate_fd+0x128/0x168 selinux_bprm_committing_creds+0x178/0x248 security_bprm_committing_creds+0x30/0x48 install_exec_creds+0x1c/0x68 load_elf_binary+0x3a4/0x14e0 search_binary_handler+0xb0/0x1e0 So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. Cc: [5.3+] Signed-off-by: Charan Teja Reddy --- drivers/dma-buf/dma-buf.c | 13 +++-- include/linux/dma-buf.h | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125..2e0456c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry >*dentry, char *buffer, int buflen) size_t ret = 0; dmabuf = dentry->d_fsdata; - dma_resv_lock(dmabuf->resv, NULL); + spin_lock(>name_lock); if (dmabuf->name) ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); - dma_resv_unlock(dmabuf->resv); + spin_unlock(>name_lock); >>> >>> I am not really clear on why you need this lock. >>> >>> If name == NULL you have no issues. >>> If name is real, you have no issues. > >Yeah, ideal cases... > >>> >>> If name is freed you will copy garbage, but the only way >>> for that to happen is that _set_name or _release have to be called >>> at just the right time. >>> >>> And the above would probably only be an issue if the set_name >>> was called, so you will get NULL or a real name. > >And there exists a use-after-free to avoid which requires the lock. Say >that memcpy() in dmabuffs_dname is in progress and in parallel _set_name >will free the same buffer that memcpy is operating on. Hmm... I can see that. However, note that in dma_buf_set_name, you cannot use the spinlock to protect the dma_buf->attachements list. I think you need to do this:
[radeon-alex:drm-next 333/414] arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function 'pr_warn'; did you mean
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: f59073f6df9b07d94917221486cf5929efa6b315
commit: 5872ef0b03247fe659226973998ff28e835afbe4 [333/414] drm/amd/powerplay:
forbid to use pr_err/warn/info/debug
config: arc-allyesconfig (attached as .config)
compiler: arc-elf-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
git checkout 5872ef0b03247fe659226973998ff28e835afbe4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/firmware.h:7,
from drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:23:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
'smu_v11_0_init_microcode':
>> arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function
>> 'pr_warn'; did you mean 'pci_warn'? [-Werror=implicit-function-declaration]
22 | pr_warn("BUG: failure at %s:%d/%s()!n", __FILE__, __LINE__, __func__);
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:176:3: note: in
>> expansion of macro 'BUG'
176 | BUG();
| ^~~
In file included from drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:30:
At top level:
drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:190:18: warning: 'sched_policy'
defined but not used [-Wunused-const-variable=]
190 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:65,
from drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:30:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:67:32: warning:
'dc_fixpt_zero' defined but not used [-Wunused-const-variable=]
67 | static const struct fixed31_32 dc_fixpt_zero = { 0 };
|^
cc1: some warnings being treated as errors
--
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function
'arcturus_is_dpm_running':
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2112:6: warning:
variable 'ret' set but not used [-Wunused-but-set-variable]
2112 | int ret = 0;
| ^~~
In file included from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/firmware.h:7,
from drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:24:
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function
'arcturus_fill_eeprom_i2c_req':
arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function
'pr_warn'; did you mean 'fb_warn'? [-Werror=implicit-function-declaration]
22 | pr_warn("BUG: failure at %s:%d/%s()!n", __FILE__, __LINE__, __func__);
| ^~~
>> include/asm-generic/bug.h:62:57: note: in expansion of macro 'BUG'
62 | #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2157:2: note: in
>> expansion of macro 'BUG_ON'
2157 | BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
| ^~
In file included from
Re: [PATCH] drm/edid: add support for min horizontal rate equal to max horizontal rate
On Tue, Jun 9, 2020 at 10:58 PM Ville Syrjälä wrote: > On Tue, Jun 09, 2020 at 03:57:04AM +0800, Cyrus Lien wrote: > > According to EDID spec, table 3.26, byte #6 and #8, which said "Minimum > > rate value shall be less than or equal to maximum rate value". The > minimum > > horizontal/vertical rate value is able to be equal to maximum horizontal/ > > veritcal rate value. > > How does that justifiy ignoring the min value? > > Indeed, this patch does not make sense. Setting minimum horizontal rate equal to maximum horizontal rate is a request come from AMD Windows graphic driver for support freesync (I'm not sure if linux AMD driver also require it). The problem is mode_in_hsync_range always return false except the mode's hsync exactly equal to hmax and hmin. Add print in mode_in_hsync_range(): [drm] mode_in_hsync_range 1920x1200: hsync: 94, hmax: 110, hmix:110 [drm] mode_in_hsync_range 1920x1200: hsync: 107, hmax: 110, hmix:110 [drm] mode_in_hsync_range 1920x1200: hsync: 152, hmax: 110, hmix:110 [drm] mode_in_hsync_range 1920x1440: hsync: 90, hmax: 110, hmix:110 [drm] mode_in_hsync_range 1920x1440: hsync: 113, hmax: 110, hmix:110 [drm] mode_in_hsync_range 1920x1440: hsync: 183, hmax: 110, hmix:110 Is it available to get or calculate the hmax, hmix value from other fields in EDID ? Would you please provide some advice or directions to solve this problem ? Thank you and appreciated the help. edid-decode (hex): 00 ff ff ff ff ff ff 00 06 af 9b 32 00 00 00 00 00 1e 01 04 b5 26 15 78 03 1f 95 a5 53 35 b5 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 70 d0 00 a0 f0 70 3e 80 30 20 35 00 7d d6 10 00 00 1a 00 00 00 fd 00 32 5a 6e 6e 17 01 11 01 e0 60 20 50 3c 00 00 00 fe 00 34 34 54 52 4e 15 42 31 37 33 5a 41 4e 00 00 00 00 00 05 81 01 28 00 12 00 00 0b 01 0a 20 20 01 af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EDID version: 1.4 Manufacturer: AUO Model 12955 Serial Number 0 Made in year 2020 Digital display 10 bits per primary color channel DisplayPort interface Maximum image size: 38 cm x 21 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Display is continuous frequency Color Characteristics Red: 0.6445, 0.3251 Green: 0.2099, 0.7099 Blue: 0.1503, 0.0595 White: 0.3134, 0.3291 Established Timings I & II: none Standard Timings: none Detailed mode: Clock 533.600 MHz, 381 mm x 214 mm 3840 3888 3920 4000 ( 48 32 80) 2160 2163 2168 ( 3 5 54) +hsync -vsync VertFreq: 60.036 Hz, HorFreq: 133.400 kHz Display Range Limits Monitor ranges (Bare Limits): 50-90 Hz V, 110-110 kHz H, max dotclock 230 MHz Alphanumeric Data String: 44TRN Manufacturer-Specified Display Descriptor (0x00): 00 00 00 05 81 01 28 00 12 00 00 0b 01 0a 20 20 ..(... Has 1 extension block Checksum: 0xaf > > > This change check if h/v-sync excess maximum horizontal/vertical rate if > > hmin equal to hmax or vmin equal to vmax. > > > > Signed-off-by: Cyrus Lien > > --- > > drivers/gpu/drm/drm_edid.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > index fed653f13c26..23878320eabd 100644 > > --- a/drivers/gpu/drm/drm_edid.c > > +++ b/drivers/gpu/drm/drm_edid.c > > @@ -2674,6 +2674,9 @@ mode_in_hsync_range(const struct drm_display_mode > *mode, > > hmax += ((t[4] & 0x08) ? 255 : 0); > > hsync = drm_mode_hsync(mode); > > > > + if (hmax == hmin) > > + return (hsync <= hmax); > > + > > return (hsync <= hmax && hsync >= hmin); > > } > > > > @@ -2691,6 +2694,9 @@ mode_in_vsync_range(const struct drm_display_mode > *mode, > > vmax += ((t[4] & 0x02) ? 255 : 0); > > vsync = drm_mode_vrefresh(mode); > > > > + if (vmax == vmin) > > + return (vsync <= vmax); > > + > > return (vsync <= vmax && vsync >= vmin); > > } > > > > -- > > 2.25.1 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[linux-next:master 953/2089] drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:446:6: sparse: sparse: symbol 'vcn_v2_5_mc_resume_dpg_mode' was not declared. Should it be
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 5fcb9628fd1227a5f11d87171cb1b8b5c414d9d9 commit: c422a628925d9733b0807d803133fb78a0a0f707 [953/2089] drm/amdgpu: rename macro for VCN2.0 2.5 and 3.0 config: i386-randconfig-s001-20200617 (attached as .config) compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-rc1-6-g78f577f8-dirty git checkout c422a628925d9733b0807d803133fb78a0a0f707 # save the attached .config to linux build tree make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:152:25: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:152:25: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:152:25: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:158:33: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:158:33: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:158:33: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:217:43: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] present_flag_0 @@ got restricted __le32 [usertype] @@ drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:217:43: sparse: expected unsigned int volatile [usertype] present_flag_0 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:217:43: sparse: got restricted __le32 [usertype] >> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:446:6: sparse: sparse: symbol >> 'vcn_v2_5_mc_resume_dpg_mode' was not declared. Should it be static? >> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:660:6: sparse: sparse: symbol >> 'vcn_v2_5_clock_gating_dpg_mode' was not declared. Should it be static? >> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1303:5: sparse: sparse: symbol >> 'vcn_v2_5_stop_dpg_mode' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 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
[RFC PATCH linux-next] drm/amdgpu: vcn_v2_5_mc_resume_dpg_mode() can be static
Fixes: c422a628925d ("drm/amdgpu: rename macro for VCN2.0 2.5 and 3.0")
Signed-off-by: kernel test robot
---
vcn_v2_5.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index 261afbb504bd0..ba1c4fbc19dc5 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
@@ -443,7 +443,7 @@ static void vcn_v2_5_mc_resume(struct amdgpu_device *adev)
}
}
-void vcn_v2_5_mc_resume_dpg_mode(struct amdgpu_device *adev, int inst_idx,
bool indirect)
+static void vcn_v2_5_mc_resume_dpg_mode(struct amdgpu_device *adev, int
inst_idx, bool indirect)
{
uint32_t size = AMDGPU_GPU_PAGE_ALIGN(adev->vcn.fw->size + 4);
uint32_t offset;
@@ -657,7 +657,7 @@ static void vcn_v2_5_disable_clock_gating(struct
amdgpu_device *adev)
}
}
-void vcn_v2_5_clock_gating_dpg_mode(struct amdgpu_device *adev,
+static void vcn_v2_5_clock_gating_dpg_mode(struct amdgpu_device *adev,
uint8_t sram_sel, int inst_idx, uint8_t indirect)
{
uint32_t reg_data = 0;
@@ -1300,7 +1300,7 @@ static int vcn_v2_5_sriov_start(struct amdgpu_device
*adev)
return vcn_v2_5_mmsch_start(adev, >virt.mm_table);
}
-int vcn_v2_5_stop_dpg_mode(struct amdgpu_device *adev, int inst_idx)
+static int vcn_v2_5_stop_dpg_mode(struct amdgpu_device *adev, int inst_idx)
{
int ret_code = 0;
uint32_t tmp;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fbdev: fix a memory leak on the dmt_mode object
From: Colin Ian King
Object drm_mode is allocated by the call to drm_mode_find_dmt
(via the call to drm_mode_duplicate and drm_mode_create). The
object is never free'd and hence causes a small memory leak.
Fix this by kfree'ing drm_mode once it is no longer required.
Addresses-Coverity: ("Resource leak")
Fixes: 1d42bbc8f7f9 ("drm/fbdev: fix cloning on fbcon")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_client_modeset.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b7e9e1c2564c..c0119e4db045 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -324,6 +324,8 @@ static bool drm_client_target_cloned(struct drm_device *dev,
can_clone = false;
}
+ kfree(dmt_mode);
+
if (can_clone) {
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
--
2.27.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/22] drm: mxsfb: Remove mxsfb_devdata unused fields
The debug0 and ipversion fields of the mxsfb_devdata structure are
unused. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index cece90101731..73d0c541dec8 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -42,19 +42,15 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.transfer_count = LCDC_V3_TRANSFER_COUNT,
.cur_buf= LCDC_V3_CUR_BUF,
.next_buf = LCDC_V3_NEXT_BUF,
- .debug0 = LCDC_V3_DEBUG0,
.hs_wdth_mask = 0xff,
.hs_wdth_shift = 24,
- .ipversion = 3,
},
[MXSFB_V4] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
.cur_buf= LCDC_V4_CUR_BUF,
.next_buf = LCDC_V4_NEXT_BUF,
- .debug0 = LCDC_V4_DEBUG0,
.hs_wdth_mask = 0x3fff,
.hs_wdth_shift = 18,
- .ipversion = 4,
},
};
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index edd766ad254f..607a6a5e6be3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -19,10 +19,8 @@ struct mxsfb_devdata {
unsigned int transfer_count;
unsigned int cur_buf;
unsigned int next_buf;
- unsigned int debug0;
unsigned int hs_wdth_mask;
unsigned int hs_wdth_shift;
- unsigned int ipversion;
};
struct mxsfb_drm_private {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 20/22] drm: mxsfb: Merge mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt()
The mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() functions both deal
with format configuration, are always called in a row from
mxsfb_crtc_mode_set_nofb(), and set fields from the LCDC_CTRL register.
This requires a read-modify-update cycle in mxsfb_set_bus_fmt(). Make
this more efficient by merging them together.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 47 +--
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 9a43c98963cc..ed25ecac983b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -42,13 +42,23 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private
*mxsfb, u32 val)
mxsfb->devdata->hs_wdth_shift;
}
-/* Setup the MXSFB registers for decoding the pixels out of the framebuffer */
-static void mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
+/*
+ * Setup the MXSFB registers for decoding the pixels out of the framebuffer and
+ * outputting them on the bus.
+ */
+static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb)
{
struct drm_device *drm = mxsfb->drm;
const u32 format = mxsfb->crtc.primary->state->fb->format->format;
+ u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
u32 ctrl, ctrl1;
+ if (mxsfb->connector->display_info.num_bus_formats)
+ bus_format = mxsfb->connector->display_info.bus_formats[0];
+
+ DRM_DEV_DEBUG_DRIVER(drm->dev, "Using bus_format: 0x%08X\n",
+bus_format);
+
ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
/* CTRL1 contains IRQ config and status bits, preserve those. */
@@ -69,40 +79,23 @@ static void mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
break;
}
- writel(ctrl1, mxsfb->base + LCDC_CTRL1);
- writel(ctrl, mxsfb->base + LCDC_CTRL);
-}
-
-static void mxsfb_set_bus_fmt(struct mxsfb_drm_private *mxsfb)
-{
- struct drm_device *drm = mxsfb->drm;
- u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
- u32 reg;
-
- reg = readl(mxsfb->base + LCDC_CTRL);
-
- if (mxsfb->connector->display_info.num_bus_formats)
- bus_format = mxsfb->connector->display_info.bus_formats[0];
-
- DRM_DEV_DEBUG_DRIVER(drm->dev, "Using bus_format: 0x%08X\n",
-bus_format);
-
- reg &= ~CTRL_BUS_WIDTH_MASK;
switch (bus_format) {
case MEDIA_BUS_FMT_RGB565_1X16:
- reg |= CTRL_BUS_WIDTH_16;
+ ctrl |= CTRL_BUS_WIDTH_16;
break;
case MEDIA_BUS_FMT_RGB666_1X18:
- reg |= CTRL_BUS_WIDTH_18;
+ ctrl |= CTRL_BUS_WIDTH_18;
break;
case MEDIA_BUS_FMT_RGB888_1X24:
- reg |= CTRL_BUS_WIDTH_24;
+ ctrl |= CTRL_BUS_WIDTH_24;
break;
default:
dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
break;
}
- writel(reg, mxsfb->base + LCDC_CTRL);
+
+ writel(ctrl1, mxsfb->base + LCDC_CTRL1);
+ writel(ctrl, mxsfb->base + LCDC_CTRL);
}
static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
@@ -213,7 +206,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
- mxsfb_set_pixel_fmt(mxsfb);
+ mxsfb_set_formats(mxsfb);
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
@@ -255,8 +248,6 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
- mxsfb_set_bus_fmt(mxsfb);
-
/* Frame length in lines. */
writel(m->crtc_vtotal, mxsfb->base + LCDC_VDCTRL1);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/22] drm: mxsfb: Update internal IP version number for i.MX6SX
The LCDIF present in the i.MX6SX has extra features compared to
the i.MX28. It has however lost its IP version register, so no official
version number is known. Bump the version to MXSFB_V6 following the i.MX
version, in preparation for support for the additional features.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 73d0c541dec8..5dd82e36154d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -35,6 +35,11 @@
enum mxsfb_devtype {
MXSFB_V3,
MXSFB_V4,
+ /*
+* Starting at i.MX6 the hardware version register is gone, use the
+* i.MX family number as the version.
+*/
+ MXSFB_V6,
};
static const struct mxsfb_devdata mxsfb_devdata[] = {
@@ -52,6 +57,13 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_mask = 0x3fff,
.hs_wdth_shift = 18,
},
+ [MXSFB_V6] = {
+ .transfer_count = LCDC_V4_TRANSFER_COUNT,
+ .cur_buf= LCDC_V4_CUR_BUF,
+ .next_buf = LCDC_V4_NEXT_BUF,
+ .hs_wdth_mask = 0x3fff,
+ .hs_wdth_shift = 18,
+ },
};
void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
@@ -271,7 +283,7 @@ static struct drm_driver mxsfb_driver = {
static const struct platform_device_id mxsfb_devtype[] = {
{ .name = "imx23-fb", .driver_data = MXSFB_V3, },
{ .name = "imx28-fb", .driver_data = MXSFB_V4, },
- { .name = "imx6sx-fb", .driver_data = MXSFB_V4, },
+ { .name = "imx6sx-fb", .driver_data = MXSFB_V6, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, mxsfb_devtype);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 21/22] drm: mxsfb: Remove unnecessary spaces after tab
This is a cosmetic change only, no code change is included.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 607a6a5e6be3..f883b56caed3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -16,11 +16,11 @@
struct clk;
struct mxsfb_devdata {
- unsigned int transfer_count;
- unsigned int cur_buf;
- unsigned int next_buf;
- unsigned int hs_wdth_mask;
- unsigned int hs_wdth_shift;
+ unsigned inttransfer_count;
+ unsigned intcur_buf;
+ unsigned intnext_buf;
+ unsigned inths_wdth_mask;
+ unsigned inths_wdth_shift;
};
struct mxsfb_drm_private {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/22] drm: mxsfb: Add i.MX7 and i.MX8M to the list of supported SoCs in Kconfig
Extend the Kconfig option description by listing the i.MX7 and i.MX8M SoCs, as they are supported by the same driver. Replace the list of SoCs in the short description with just "(e)LCDIF LCD controller" to avoid expanding it further in the future as support for more SoCs is added. Signed-off-by: Laurent Pinchart Reviewed-by: Emil Velikov Reviewed-by: Stefan Agner --- Changes since v1: - Make description more explicit by mentioning LCDIF and eLCDIF - Add i.MX8M --- drivers/gpu/drm/mxsfb/Kconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig index e43b326e9147..0143d539f8f8 100644 --- a/drivers/gpu/drm/mxsfb/Kconfig +++ b/drivers/gpu/drm/mxsfb/Kconfig @@ -5,7 +5,7 @@ config DRM_MXS Choose this option to select drivers for MXS FB devices config DRM_MXSFB - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller" + tristate "i.MX (e)LCDIF LCD controller" depends on DRM && OF depends on COMMON_CLK select DRM_MXS @@ -15,7 +15,8 @@ config DRM_MXSFB select DRM_PANEL select DRM_PANEL_BRIDGE help - Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB - LCD controller. + Choose this option if you have an LCDIF or eLCDIF LCD controller. + Those devices are found in various i.MX SoC (including i.MX23, + i.MX28, i.MX6SX, i.MX7 and i.MX8M). If M is selected the module will be called mxsfb. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 22/22] drm: mxsfb: Support the alpha plane
The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
plane. Support it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
Changes since v1:
- Split whitespace cleanup to a separate patch
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 6 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 129 +
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 22 +
4 files changed, 144 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index bb80e12d9120..8c549c3931af 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -49,6 +49,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.next_buf = LCDC_V3_NEXT_BUF,
.hs_wdth_mask = 0xff,
.hs_wdth_shift = 24,
+ .has_overlay= false,
},
[MXSFB_V4] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -56,6 +57,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.next_buf = LCDC_V4_NEXT_BUF,
.hs_wdth_mask = 0x3fff,
.hs_wdth_shift = 18,
+ .has_overlay= false,
},
[MXSFB_V6] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -63,6 +65,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.next_buf = LCDC_V4_NEXT_BUF,
.hs_wdth_mask = 0x3fff,
.hs_wdth_shift = 18,
+ .has_overlay= true,
},
};
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index f883b56caed3..399d23e91ed1 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -21,6 +21,7 @@ struct mxsfb_devdata {
unsigned intnext_buf;
unsigned inths_wdth_mask;
unsigned inths_wdth_shift;
+ boolhas_overlay;
};
struct mxsfb_drm_private {
@@ -32,7 +33,10 @@ struct mxsfb_drm_private {
struct clk *clk_disp_axi;
struct drm_device *drm;
- struct drm_planeplane;
+ struct {
+ struct drm_planeprimary;
+ struct drm_planeoverlay;
+ } planes;
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector*connector;
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index ed25ecac983b..d11a1b21dc22 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -169,9 +169,9 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
}
-static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
+static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
{
- struct drm_framebuffer *fb = mxsfb->plane.state->fb;
+ struct drm_framebuffer *fb = plane->state->fb;
struct drm_gem_cma_object *gem;
if (!fb)
@@ -206,6 +206,9 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
+ if (mxsfb->devdata->has_overlay)
+ writel(0, mxsfb->base + LCDC_AS_CTRL);
+
mxsfb_set_formats(mxsfb);
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
@@ -313,7 +316,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
mxsfb_crtc_mode_set_nofb(mxsfb);
/* Write cur_buf as well to avoid an initial corrupt frame */
- paddr = mxsfb_get_fb_paddr(mxsfb);
+ paddr = mxsfb_get_fb_paddr(crtc->primary);
if (paddr) {
writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
@@ -410,20 +413,85 @@ static int mxsfb_plane_atomic_check(struct drm_plane
*plane,
false, true);
}
-static void mxsfb_plane_atomic_update(struct drm_plane *plane,
- struct drm_plane_state *old_pstate)
+static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state
*old_pstate)
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
dma_addr_t paddr;
- paddr = mxsfb_get_fb_paddr(mxsfb);
+ paddr = mxsfb_get_fb_paddr(plane);
if (paddr)
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
}
-static const struct drm_plane_helper_funcs mxsfb_plane_helper_funcs = {
+static void mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,
+ struct
[PATCH v3 09/22] drm: mxsfb: Remove unneeded includes
A fair number of includes are not needed. Drop them, and add a couple of required includes that were included indirectly. Signed-off-by: Laurent Pinchart Reviewed-by: Stefan Agner Reviewed-by: Emil Velikov --- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 +++- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 - 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c index aef72adabf41..c4f1575b4210 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c @@ -10,19 +10,13 @@ #include #include -#include -#include +#include -#include - -#include +#include #include #include -#include +#include #include -#include -#include -#include #include #include diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index d3de45735237..522680f84874 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -9,15 +9,10 @@ */ #include -#include #include -#include #include #include -#include -#include #include -#include #include #include -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/22] drm: mxsfb: Drop non-OF support
The mxsfb driver is only used by OF platforms. Drop non-OF support.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 5dd82e36154d..bb80e12d9120 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -131,7 +131,8 @@ static int mxsfb_attach_bridge(struct mxsfb_drm_private
*mxsfb)
return 0;
}
-static int mxsfb_load(struct drm_device *drm, unsigned long flags)
+static int mxsfb_load(struct drm_device *drm,
+ const struct mxsfb_devdata *devdata)
{
struct platform_device *pdev = to_platform_device(drm->dev);
struct mxsfb_drm_private *mxsfb;
@@ -144,7 +145,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long
flags)
mxsfb->drm = drm;
drm->dev_private = mxsfb;
- mxsfb->devdata = _devdata[pdev->id_entry->driver_data];
+ mxsfb->devdata = devdata;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mxsfb->base = devm_ioremap_resource(drm->dev, res);
@@ -280,18 +281,10 @@ static struct drm_driver mxsfb_driver = {
.minor = 0,
};
-static const struct platform_device_id mxsfb_devtype[] = {
- { .name = "imx23-fb", .driver_data = MXSFB_V3, },
- { .name = "imx28-fb", .driver_data = MXSFB_V4, },
- { .name = "imx6sx-fb", .driver_data = MXSFB_V6, },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(platform, mxsfb_devtype);
-
static const struct of_device_id mxsfb_dt_ids[] = {
- { .compatible = "fsl,imx23-lcdif", .data = _devtype[0], },
- { .compatible = "fsl,imx28-lcdif", .data = _devtype[1], },
- { .compatible = "fsl,imx6sx-lcdif", .data = _devtype[2], },
+ { .compatible = "fsl,imx23-lcdif", .data = _devdata[MXSFB_V3], },
+ { .compatible = "fsl,imx28-lcdif", .data = _devdata[MXSFB_V4], },
+ { .compatible = "fsl,imx6sx-lcdif", .data = _devdata[MXSFB_V6], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxsfb_dt_ids);
@@ -306,14 +299,11 @@ static int mxsfb_probe(struct platform_device *pdev)
if (!pdev->dev.of_node)
return -ENODEV;
- if (of_id)
- pdev->id_entry = of_id->data;
-
drm = drm_dev_alloc(_driver, >dev);
if (IS_ERR(drm))
return PTR_ERR(drm);
- ret = mxsfb_load(drm, 0);
+ ret = mxsfb_load(drm, of_id->data);
if (ret)
goto err_free;
@@ -367,7 +357,6 @@ static const struct dev_pm_ops mxsfb_pm_ops = {
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
- .id_table = mxsfb_devtype,
.driver = {
.name = "mxsfb",
.of_match_table = mxsfb_dt_ids,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/22] drm: mxsfb: Enable vblank handling
Enable vblank handling when the CRTC is turned on and disable it when it
is turned off. This requires moving vblank init after the KMS pipeline
initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +--
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 752373803055..cece90101731 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -161,12 +161,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
pm_runtime_enable(drm->dev);
- ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
- if (ret < 0) {
- dev_err(drm->dev, "Failed to initialise vblank\n");
- goto err_vblank;
- }
-
/* Modeset init */
drm_mode_config_init(drm);
@@ -176,6 +170,15 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
goto err_vblank;
}
+ ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+ if (ret < 0) {
+ dev_err(drm->dev, "Failed to initialise vblank\n");
+ goto err_vblank;
+ }
+
+ /* Start with vertical blanking interrupt reporting disabled. */
+ drm_crtc_vblank_off(>crtc);
+
ret = mxsfb_attach_bridge(mxsfb);
if (ret) {
dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index a8172fd6cd41..aa9e962bb026 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -322,8 +322,10 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
dma_addr_t paddr;
pm_runtime_get_sync(drm->dev);
-
mxsfb_enable_axi_clk(mxsfb);
+
+ drm_crtc_vblank_on(crtc);
+
mxsfb_crtc_mode_set_nofb(mxsfb);
/* Write cur_buf as well to avoid an initial corrupt frame */
@@ -353,6 +355,8 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc,
}
spin_unlock_irq(>event_lock);
+ drm_crtc_vblank_off(crtc);
+
mxsfb_disable_axi_clk(mxsfb);
pm_runtime_put_sync(drm->dev);
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/22] drm: mxsfb: Turn mxsfb_set_pixel_fmt() into a void function
The mxsfb_set_pixel_fmt() function returns an error when the selected
pixel format is unsupported. This can never happen, as such errors are
caught by the DRM core. Remove the error check.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index aa9e962bb026..9a43c98963cc 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -43,7 +43,7 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private
*mxsfb, u32 val)
}
/* Setup the MXSFB registers for decoding the pixels out of the framebuffer */
-static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
+static void mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
{
struct drm_device *drm = mxsfb->drm;
const u32 format = mxsfb->crtc.primary->state->fb->format->format;
@@ -67,15 +67,10 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
break;
- default:
- dev_err(drm->dev, "Unhandled pixel format %08x\n", format);
- return -EINVAL;
}
writel(ctrl1, mxsfb->base + LCDC_CTRL1);
writel(ctrl, mxsfb->base + LCDC_CTRL);
-
- return 0;
}
static void mxsfb_set_bus_fmt(struct mxsfb_drm_private *mxsfb)
@@ -218,9 +213,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
- err = mxsfb_set_pixel_fmt(mxsfb);
- if (err)
- return;
+ mxsfb_set_pixel_fmt(mxsfb);
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/22] drm: mxsfb: Move vblank event arm to CRTC .atomic_flush()
The vblank event is armed in the plane .atomic_update(). This works fine
as we have a single plane, and was the only option when the driver was
using the drm_simple_kms_helper helper, but will break as soon as
multiple planes are supported. Move it to CRTC .atomic_flush().
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
Changes since v1:
- Reword commit message
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 35 ++-
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index e2f0bc40d1a0..cbf6d6d481ed 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -295,6 +295,25 @@ static int mxsfb_crtc_atomic_check(struct drm_crtc *crtc,
return drm_atomic_add_affected_planes(state->state, crtc);
}
+static void mxsfb_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct drm_pending_vblank_event *event;
+
+ event = crtc->state->event;
+ crtc->state->event = NULL;
+
+ if (!event)
+ return;
+
+ spin_lock_irq(>dev->event_lock);
+ if (drm_crtc_vblank_get(crtc) == 0)
+ drm_crtc_arm_vblank_event(crtc, event);
+ else
+ drm_crtc_send_vblank_event(crtc, event);
+ spin_unlock_irq(>dev->event_lock);
+}
+
static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -364,6 +383,7 @@ static void mxsfb_crtc_disable_vblank(struct drm_crtc *crtc)
static const struct drm_crtc_helper_funcs mxsfb_crtc_helper_funcs = {
.atomic_check = mxsfb_crtc_atomic_check,
+ .atomic_flush = mxsfb_crtc_atomic_flush,
.atomic_enable = mxsfb_crtc_atomic_enable,
.atomic_disable = mxsfb_crtc_atomic_disable,
};
@@ -410,23 +430,8 @@ static void mxsfb_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *old_pstate)
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
- struct drm_crtc *crtc = >crtc;
- struct drm_pending_vblank_event *event;
dma_addr_t paddr;
- spin_lock_irq(>dev->event_lock);
- event = crtc->state->event;
- if (event) {
- crtc->state->event = NULL;
-
- if (drm_crtc_vblank_get(crtc) == 0) {
- drm_crtc_arm_vblank_event(crtc, event);
- } else {
- drm_crtc_send_vblank_event(crtc, event);
- }
- }
- spin_unlock_irq(>dev->event_lock);
-
paddr = mxsfb_get_fb_paddr(mxsfb);
if (paddr) {
mxsfb_enable_axi_clk(mxsfb);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/22] drm: mxsfb: Use drm_panel_bridge
Replace the manual connector implementation based on drm_panel with the
drm_panel_bridge helper. This simplifies the mxsfb driver by removing
connector-related code, and standardizing all pipeline control
operations on bridges.
A hack is needed to get hold of the connector, as that's our only source
of bus flags and formats for now. As soon as the bridge API provides us
with that information this can be fixed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
Changes since v2:
- Use drm_panel_bridge_add_typed()
Changes since v1:
- Select DRM_PANEL_BRIDGE in Kconfig
---
drivers/gpu/drm/mxsfb/Kconfig | 1 +
drivers/gpu/drm/mxsfb/Makefile| 2 +-
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 106 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +-
drivers/gpu/drm/mxsfb/mxsfb_out.c | 99
5 files changed, 55 insertions(+), 158 deletions(-)
delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 0dca8f27169e..e43b326e9147 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -13,6 +13,7 @@ config DRM_MXSFB
select DRM_KMS_FB_HELPER
select DRM_KMS_CMA_HELPER
select DRM_PANEL
+ select DRM_PANEL_BRIDGE
help
Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
LCD controller.
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
index ff6e358088fa..811584e54ad1 100644
--- a/drivers/gpu/drm/mxsfb/Makefile
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o
+mxsfb-y := mxsfb_drv.o mxsfb_crtc.o
obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 96ee67ef9a13..d3de45735237 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -100,29 +99,11 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
- struct drm_connector *connector;
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
struct drm_device *drm = pipe->plane.dev;
- if (!mxsfb->connector) {
- list_for_each_entry(connector,
- >mode_config.connector_list,
- head)
- if (connector->encoder == >pipe.encoder) {
- mxsfb->connector = connector;
- break;
- }
- }
-
- if (!mxsfb->connector) {
- dev_warn(drm->dev, "No connector attached, using default\n");
- mxsfb->connector = >panel_connector;
- }
-
pm_runtime_get_sync(drm->dev);
- drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
- drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -132,9 +113,7 @@ static void mxsfb_pipe_disable(struct
drm_simple_display_pipe *pipe)
struct drm_crtc *crtc = >crtc;
struct drm_pending_vblank_event *event;
- drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
- drm_panel_unprepare(mxsfb->panel);
pm_runtime_put_sync(drm->dev);
spin_lock_irq(>event_lock);
@@ -144,9 +123,6 @@ static void mxsfb_pipe_disable(struct
drm_simple_display_pipe *pipe)
drm_crtc_send_vblank_event(crtc, event);
}
spin_unlock_irq(>event_lock);
-
- if (mxsfb->connector != >panel_connector)
- mxsfb->connector = NULL;
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
@@ -190,6 +166,49 @@ static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
.disable_vblank = mxsfb_pipe_disable_vblank,
};
+static int mxsfb_attach_bridge(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_device *drm = mxsfb->drm;
+ struct drm_connector_list_iter iter;
+ struct drm_panel *panel;
+ struct drm_bridge *bridge;
+ int ret;
+
+ ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, ,
+ );
+ if (ret)
+ return ret;
+
+ if (panel) {
+ bridge = devm_drm_panel_bridge_add_typed(drm->dev, panel,
+
DRM_MODE_CONNECTOR_DPI);
+ if (IS_ERR(bridge))
+ return PTR_ERR(bridge);
+ }
+
+ if (!bridge)
+ return -ENODEV;
+
+ ret =
[PATCH v3 13/22] drm: mxsfb: Don't touch AXI clock in IRQ context
The driver attempts agressive power management by enabling and disabling
the AXI clock around register accesses. This results in attempts to
enable and disable the clock in the IRQ handler, which is a no-go as
preparing or unpreparing the clock may sleep.
On the other hand, the driver enables the AXI clock when enabling the
CRTC and keeps it enabled until the CRTC is disabled. This is correct,
and renders the power management attempt pointless, as interrupts are
not supposed to occur when the CRTC is off.
The same reasoning can be applied to the CRTC .enable_vblank() and
.disable_vblank() that are not supposed to be called when the CRTC off
and thus don't require manual handling of the AXI clock. Furthermore,
vblank handling is never enabled, which results in the vblank enable and
disable handlers never being called.
To fix this, remove the manual clock handling in the IRQ, the CRTC
.enable_vblank() and .disable_vblank() handlers and the plane
.atomic_update() handler. We however need to handle the clock manually
in mxsfb_irq_disable() as is calls .disable_vblank() manually and is
used both at probe and remove time.
The clock disabling is also moved to the last step of the
mxsfb_crtc_atomic_disable() function, to prepare for enabling vblank
handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 15 ---
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index f7c89c0b1665..752373803055 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -232,7 +232,9 @@ static void mxsfb_irq_disable(struct drm_device *drm)
{
struct mxsfb_drm_private *mxsfb = drm->dev_private;
+ mxsfb_enable_axi_clk(mxsfb);
mxsfb->crtc.funcs->disable_vblank(>crtc);
+ mxsfb_disable_axi_clk(mxsfb);
}
static irqreturn_t mxsfb_irq_handler(int irq, void *data)
@@ -241,8 +243,6 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
struct mxsfb_drm_private *mxsfb = drm->dev_private;
u32 reg;
- mxsfb_enable_axi_clk(mxsfb);
-
reg = readl(mxsfb->base + LCDC_CTRL1);
if (reg & CTRL1_CUR_FRAME_DONE_IRQ)
@@ -250,8 +250,6 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- mxsfb_disable_axi_clk(mxsfb);
-
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index cbf6d6d481ed..a8172fd6cd41 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -344,9 +344,6 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_pending_vblank_event *event;
mxsfb_disable_controller(mxsfb);
- mxsfb_disable_axi_clk(mxsfb);
-
- pm_runtime_put_sync(drm->dev);
spin_lock_irq(>event_lock);
event = crtc->state->event;
@@ -355,6 +352,9 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc,
drm_crtc_send_vblank_event(crtc, event);
}
spin_unlock_irq(>event_lock);
+
+ mxsfb_disable_axi_clk(mxsfb);
+ pm_runtime_put_sync(drm->dev);
}
static int mxsfb_crtc_enable_vblank(struct drm_crtc *crtc)
@@ -362,10 +362,8 @@ static int mxsfb_crtc_enable_vblank(struct drm_crtc *crtc)
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
/* Clear and enable VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
- mxsfb_disable_axi_clk(mxsfb);
return 0;
}
@@ -375,10 +373,8 @@ static void mxsfb_crtc_disable_vblank(struct drm_crtc
*crtc)
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
/* Disable and clear VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- mxsfb_disable_axi_clk(mxsfb);
}
static const struct drm_crtc_helper_funcs mxsfb_crtc_helper_funcs = {
@@ -433,11 +429,8 @@ static void mxsfb_plane_atomic_update(struct drm_plane
*plane,
dma_addr_t paddr;
paddr = mxsfb_get_fb_paddr(mxsfb);
- if (paddr) {
- mxsfb_enable_axi_clk(mxsfb);
+ if (paddr)
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
- }
}
static const struct drm_plane_helper_funcs mxsfb_plane_helper_funcs = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH v3 06/22] drm: mxsfb: Pass mxsfb_drm_private pointer to mxsfb_reset_block()
The mxsfb_reset_block() function isn't special, pass it the
mxsfb_drm_private pointer instead of a pointer to the base address.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 8b6339316929..be60c4021e2f 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -166,21 +166,21 @@ static int clear_poll_bit(void __iomem *addr, u32 mask)
return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
}
-static int mxsfb_reset_block(void __iomem *reset_addr)
+static int mxsfb_reset_block(struct mxsfb_drm_private *mxsfb)
{
int ret;
- ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base, MODULE_SFTRST);
if (ret)
return ret;
- writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+ writel(MODULE_CLKGATE, mxsfb->base + MXS_CLR_ADDR);
- ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base, MODULE_SFTRST);
if (ret)
return ret;
- return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+ return clear_poll_bit(mxsfb->base, MODULE_CLKGATE);
}
static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
@@ -213,7 +213,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
/* Mandatory eLCDIF reset as per the Reference Manual */
- err = mxsfb_reset_block(mxsfb->base);
+ err = mxsfb_reset_block(mxsfb);
if (err)
return;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/22] drm: mxsfb: Rename mxsfb_crtc.c to mxsfb_kms.c
The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other
KMS objects. Rename it accordingly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/Makefile | 2 +-
drivers/gpu/drm/mxsfb/{mxsfb_crtc.c => mxsfb_kms.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/gpu/drm/mxsfb/{mxsfb_crtc.c => mxsfb_kms.c} (100%)
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
index 811584e54ad1..26d153896d72 100644
--- a/drivers/gpu/drm/mxsfb/Makefile
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-mxsfb-y := mxsfb_drv.o mxsfb_crtc.o
+mxsfb-y := mxsfb_drv.o mxsfb_kms.o
obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
similarity index 100%
rename from drivers/gpu/drm/mxsfb/mxsfb_crtc.c
rename to drivers/gpu/drm/mxsfb/mxsfb_kms.c
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/22] drm: mxsfb: Clarify format and bus width configuration
Replace the convoluted way to set the format and bus width through
difficult to read macros with more explicit ones. Also remove the
outdated comment related to the limitations on bus width setting as it
doesn't apply anymore (the bus width can be specified through the
display_info bus format).
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 17 +
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 17 -
2 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b69ace8bf526..8b6339316929 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -52,13 +52,6 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
- /*
-* WARNING: The bus width, CTRL_SET_BUS_WIDTH(), is configured to
-* match the selected mode here. This differs from the original
-* MXSFB driver, which had the option to configure the bus width
-* to arbitrary value. This limitation should not pose an issue.
-*/
-
/* CTRL1 contains IRQ config and status bits, preserve those. */
ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
@@ -66,12 +59,12 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
switch (format) {
case DRM_FORMAT_RGB565:
dev_dbg(drm->dev, "Setting up RGB565 mode\n");
- ctrl |= CTRL_SET_WORD_LENGTH(0);
+ ctrl |= CTRL_WORD_LENGTH_16;
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
case DRM_FORMAT_XRGB:
dev_dbg(drm->dev, "Setting up XRGB mode\n");
- ctrl |= CTRL_SET_WORD_LENGTH(3);
+ ctrl |= CTRL_WORD_LENGTH_24;
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
break;
@@ -104,13 +97,13 @@ static void mxsfb_set_bus_fmt(struct mxsfb_drm_private
*mxsfb)
reg &= ~CTRL_BUS_WIDTH_MASK;
switch (bus_format) {
case MEDIA_BUS_FMT_RGB565_1X16:
- reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
+ reg |= CTRL_BUS_WIDTH_16;
break;
case MEDIA_BUS_FMT_RGB666_1X18:
- reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_18BIT);
+ reg |= CTRL_BUS_WIDTH_18;
break;
case MEDIA_BUS_FMT_RGB888_1X24:
- reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
+ reg |= CTRL_BUS_WIDTH_24;
break;
default:
dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
index 78e6cb754712..8ebb52bb1b46 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
@@ -34,11 +34,15 @@
#define CTRL_VSYNC_MODEBIT(18)
#define CTRL_DOTCLK_MODE BIT(17)
#define CTRL_DATA_SELECT BIT(16)
-#define CTRL_SET_BUS_WIDTH(x) (((x) & 0x3) << 10)
-#define CTRL_GET_BUS_WIDTH(x) (((x) >> 10) & 0x3)
+#define CTRL_BUS_WIDTH_16 (0 << 10)
+#define CTRL_BUS_WIDTH_8 (1 << 10)
+#define CTRL_BUS_WIDTH_18 (2 << 10)
+#define CTRL_BUS_WIDTH_24 (3 << 10)
#define CTRL_BUS_WIDTH_MASK(0x3 << 10)
-#define CTRL_SET_WORD_LENGTH(x)(((x) & 0x3) << 8)
-#define CTRL_GET_WORD_LENGTH(x)(((x) >> 8) & 0x3)
+#define CTRL_WORD_LENGTH_16(0 << 8)
+#define CTRL_WORD_LENGTH_8 (1 << 8)
+#define CTRL_WORD_LENGTH_18(2 << 8)
+#define CTRL_WORD_LENGTH_24(3 << 8)
#define CTRL_MASTERBIT(5)
#define CTRL_DF16 BIT(3)
#define CTRL_DF18 BIT(2)
@@ -91,9 +95,4 @@
#define MXSFB_MAX_XRES 0x
#define MXSFB_MAX_YRES 0x
-#define STMLCDIF_8BIT 1 /* pixel data bus to the display is of 8 bit width */
-#define STMLCDIF_16BIT 0 /* pixel data bus to the display is of 16 bit width */
-#define STMLCDIF_18BIT 2 /* pixel data bus to the display is of 18 bit width */
-#define STMLCDIF_24BIT 3 /* pixel data bus to the display is of 24 bit width */
-
#endif /* __MXSFB_REGS_H__ */
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/22] drm: mxsfb: Stop using DRM simple display pipeline helper
The DRM simple display pipeline helper only supports a single plane. In
order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
move away from the helper. No new feature is added.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
Changes since v2:
- Fix primary plane enable check in mxsfb_crtc_atomic_check()
Changes since v1:
- Move after mxsfb_crtc.c rename to mxsfb_kms.c
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 108 +++---
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 23 ++--
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 184 +++---
3 files changed, 197 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 522680f84874..f7c89c0b1665 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -10,22 +10,23 @@
#include
#include
+#include
#include
#include
+#include
#include
-#include
-#include
#include
-#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
-#include
#include
#include "mxsfb_drv.h"
@@ -57,17 +58,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
},
};
-static const uint32_t mxsfb_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_RGB565
-};
-
-static struct mxsfb_drm_private *
-drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
-{
- return container_of(pipe, struct mxsfb_drm_private, pipe);
-}
-
void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
{
if (mxsfb->clk_axi)
@@ -90,77 +80,6 @@ static const struct drm_mode_config_helper_funcs
mxsfb_mode_config_helpers = {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
-static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state,
- struct drm_plane_state *plane_state)
-{
- struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
- struct drm_device *drm = pipe->plane.dev;
-
- pm_runtime_get_sync(drm->dev);
- mxsfb_crtc_enable(mxsfb);
-}
-
-static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
-{
- struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
- struct drm_device *drm = pipe->plane.dev;
- struct drm_crtc *crtc = >crtc;
- struct drm_pending_vblank_event *event;
-
- mxsfb_crtc_disable(mxsfb);
- pm_runtime_put_sync(drm->dev);
-
- spin_lock_irq(>event_lock);
- event = crtc->state->event;
- if (event) {
- crtc->state->event = NULL;
- drm_crtc_send_vblank_event(crtc, event);
- }
- spin_unlock_irq(>event_lock);
-}
-
-static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
- struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
-
- mxsfb_plane_atomic_update(mxsfb, plane_state);
-}
-
-static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
-{
- struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
-
- /* Clear and enable VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
- writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
- mxsfb_disable_axi_clk(mxsfb);
-
- return 0;
-}
-
-static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe *pipe)
-{
- struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
-
- /* Disable and clear VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
- writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- mxsfb_disable_axi_clk(mxsfb);
-}
-
-static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
- .enable = mxsfb_pipe_enable,
- .disable= mxsfb_pipe_disable,
- .update = mxsfb_pipe_update,
- .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
- .enable_vblank = mxsfb_pipe_enable_vblank,
- .disable_vblank = mxsfb_pipe_disable_vblank,
-};
-
static int mxsfb_attach_bridge(struct mxsfb_drm_private *mxsfb)
{
struct drm_device *drm = mxsfb->drm;
@@ -184,7 +103,7 @@ static int mxsfb_attach_bridge(struct mxsfb_drm_private
*mxsfb)
if (!bridge)
return -ENODEV;
- ret = drm_simple_display_pipe_attach_bridge(>pipe, bridge);
+ ret = drm_bridge_attach(>encoder, bridge, NULL, 0);
if (ret) {
DRM_DEV_ERROR(drm->dev,
"failed to attach bridge: %d\n", ret);
@@ -251,10 +170,9 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
[PATCH v3 03/22] drm: mxsfb: Use BIT() macro to define register bitfields
Using BIT() is preferred over manual shifts as it's more readable, handles the 1 << 31 case properly, and avoids other mistakes as shown by the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use it. Signed-off-by: Laurent Pinchart Reviewed-by: Stefan Agner Reviewed-by: Emil Velikov --- drivers/gpu/drm/mxsfb/mxsfb_regs.h | 56 +++--- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h b/drivers/gpu/drm/mxsfb/mxsfb_regs.h index 932d7ea08fd5..713d8f830135 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h +++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h @@ -28,51 +28,51 @@ #define LCDC_V4_DEBUG0 0x1d0 #define LCDC_V3_DEBUG0 0x1f0 -#define CTRL_SFTRST(1 << 31) -#define CTRL_CLKGATE (1 << 30) -#define CTRL_BYPASS_COUNT (1 << 19) -#define CTRL_VSYNC_MODE(1 << 18) -#define CTRL_DOTCLK_MODE (1 << 17) -#define CTRL_DATA_SELECT (1 << 16) +#define CTRL_SFTRSTBIT(31) +#define CTRL_CLKGATE BIT(30) +#define CTRL_BYPASS_COUNT BIT(19) +#define CTRL_VSYNC_MODEBIT(18) +#define CTRL_DOTCLK_MODE BIT(17) +#define CTRL_DATA_SELECT BIT(16) #define CTRL_SET_BUS_WIDTH(x) (((x) & 0x3) << 10) #define CTRL_GET_BUS_WIDTH(x) (((x) >> 10) & 0x3) #define CTRL_BUS_WIDTH_MASK(0x3 << 10) #define CTRL_SET_WORD_LENGTH(x)(((x) & 0x3) << 8) #define CTRL_GET_WORD_LENGTH(x)(((x) >> 8) & 0x3) -#define CTRL_MASTER(1 << 5) -#define CTRL_DF16 (1 << 3) -#define CTRL_DF18 (1 << 2) -#define CTRL_DF24 (1 << 1) -#define CTRL_RUN (1 << 0) +#define CTRL_MASTERBIT(5) +#define CTRL_DF16 BIT(3) +#define CTRL_DF18 BIT(2) +#define CTRL_DF24 BIT(1) +#define CTRL_RUN BIT(0) -#define CTRL1_FIFO_CLEAR (1 << 21) +#define CTRL1_FIFO_CLEAR BIT(21) #define CTRL1_SET_BYTE_PACKAGING(x)(((x) & 0xf) << 16) #define CTRL1_GET_BYTE_PACKAGING(x)(((x) >> 16) & 0xf) -#define CTRL1_CUR_FRAME_DONE_IRQ_EN(1 << 13) -#define CTRL1_CUR_FRAME_DONE_IRQ (1 << 9) +#define CTRL1_CUR_FRAME_DONE_IRQ_ENBIT(13) +#define CTRL1_CUR_FRAME_DONE_IRQ BIT(9) #define TRANSFER_COUNT_SET_VCOUNT(x) (((x) & 0x) << 16) #define TRANSFER_COUNT_GET_VCOUNT(x) (((x) >> 16) & 0x) #define TRANSFER_COUNT_SET_HCOUNT(x) ((x) & 0x) #define TRANSFER_COUNT_GET_HCOUNT(x) ((x) & 0x) -#define VDCTRL0_ENABLE_PRESENT (1 << 28) -#define VDCTRL0_VSYNC_ACT_HIGH (1 << 27) -#define VDCTRL0_HSYNC_ACT_HIGH (1 << 26) -#define VDCTRL0_DOTCLK_ACT_FALLING (1 << 25) -#define VDCTRL0_ENABLE_ACT_HIGH(1 << 24) -#define VDCTRL0_VSYNC_PERIOD_UNIT (1 << 21) -#define VDCTRL0_VSYNC_PULSE_WIDTH_UNIT (1 << 20) -#define VDCTRL0_HALF_LINE (1 << 19) -#define VDCTRL0_HALF_LINE_MODE (1 << 18) +#define VDCTRL0_ENABLE_PRESENT BIT(28) +#define VDCTRL0_VSYNC_ACT_HIGH BIT(27) +#define VDCTRL0_HSYNC_ACT_HIGH BIT(26) +#define VDCTRL0_DOTCLK_ACT_FALLING BIT(25) +#define VDCTRL0_ENABLE_ACT_HIGHBIT(24) +#define VDCTRL0_VSYNC_PERIOD_UNIT BIT(21) +#define VDCTRL0_VSYNC_PULSE_WIDTH_UNIT BIT(20) +#define VDCTRL0_HALF_LINE BIT(19) +#define VDCTRL0_HALF_LINE_MODE BIT(18) #define VDCTRL0_SET_VSYNC_PULSE_WIDTH(x) ((x) & 0x3) #define VDCTRL0_GET_VSYNC_PULSE_WIDTH(x) ((x) & 0x3) #define VDCTRL2_SET_HSYNC_PERIOD(x)((x) & 0x3) #define VDCTRL2_GET_HSYNC_PERIOD(x)((x) & 0x3) -#define VDCTRL3_MUX_SYNC_SIGNALS (1 << 29) -#define VDCTRL3_VSYNC_ONLY (1 << 28) +#define VDCTRL3_MUX_SYNC_SIGNALS BIT(29) +#define VDCTRL3_VSYNC_ONLY BIT(28) #define SET_HOR_WAIT_CNT(x)(((x) & 0xfff) << 16) #define GET_HOR_WAIT_CNT(x)(((x) >> 16) & 0xfff) #define SET_VERT_WAIT_CNT(x) ((x) & 0x) @@ -80,11 +80,11 @@ #define VDCTRL4_SET_DOTCLK_DLY(x) (((x) & 0x7) << 29) /* v4 only */ #define VDCTRL4_GET_DOTCLK_DLY(x) (((x) >> 29) & 0x7) /* v4 only */ -#define VDCTRL4_SYNC_SIGNALS_ON(1 << 18) +#define VDCTRL4_SYNC_SIGNALS_ONBIT(18) #define SET_DOTCLK_H_VALID_DATA_CNT(x) ((x) & 0x3) -#define DEBUG0_HSYNC (1 < 26) -#define DEBUG0_VSYNC (1 < 25) +#define DEBUG0_HSYNC BIT(26) +#define DEBUG0_VSYNC BIT(25) #define MXSFB_MIN_XRES 120 #define MXSFB_MIN_YRES 120 -- Regards, Laurent Pinchart
[PATCH v3 00/22] drm: mxsfb: Add i.MX7 support
Hello, This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF instance found in the i.MX7 is backward-compatible with the already supported LCDC v4, but has extended features amongst which the most notable one is a second plane. The first 10 patches (01/22 to 10/22) contain miscellaneous cleanups and refactoring to prepare for what is to come. Patch 11/22 starts the real work with removal of the DRM simple display pipeline helper, as it doesn't support multiple planes. The next patch (12/22) is an additional cleanup. Patches 13/22 to 15/22 fix vblank handling that I found to be broken when testing on my device. Patch 16/22 then performs an additional small cleanup, and patch 17/22 starts official support for i.MX7 by mentioning it in Kconfig. Patch 18/22 adds a new device model for the i.MX6SX and i.MX7 eLCDIF. After three additional cleanups in patches 19/22 to 21/22, patch 22/22 finally adds support for the second plane. The second plane suffers from an issue whose root cause hasn't been found, which results in the first 64 bytes of the first line to contain data of unknown origin. Help from NXP to diagnose this issue would be useful and appreciated. Compared to v2, the patches incorporate various review feedback, without major modifications. See individual changelogs for details. The code is based on drm-misc-next and has been tested on an i.MX7D platform with a DPI panel. Stefan, the series has been fully reviewed, could you merge it ? Laurent Pinchart (22): drm: mxsfb: Remove fbdev leftovers drm: mxsfb: Use drm_panel_bridge drm: mxsfb: Use BIT() macro to define register bitfields drm: mxsfb: Remove unused macros from mxsfb_regs.h drm: mxsfb: Clarify format and bus width configuration drm: mxsfb: Pass mxsfb_drm_private pointer to mxsfb_reset_block() drm: mxsfb: Use LCDC_CTRL register name explicitly drm: mxsfb: Remove register definitions from mxsfb_crtc.c drm: mxsfb: Remove unneeded includes drm: mxsfb: Rename mxsfb_crtc.c to mxsfb_kms.c drm: mxsfb: Stop using DRM simple display pipeline helper drm: mxsfb: Move vblank event arm to CRTC .atomic_flush() drm: mxsfb: Don't touch AXI clock in IRQ context drm: mxsfb: Enable vblank handling drm: mxsfb: Remove mxsfb_devdata unused fields drm: mxsfb: Add i.MX7 and i.MX8M to the list of supported SoCs in Kconfig drm: mxsfb: Update internal IP version number for i.MX6SX drm: mxsfb: Drop non-OF support drm: mxsfb: Turn mxsfb_set_pixel_fmt() into a void function drm: mxsfb: Merge mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() drm: mxsfb: Remove unnecessary spaces after tab drm: mxsfb: Support the alpha plane drivers/gpu/drm/mxsfb/Kconfig | 8 +- drivers/gpu/drm/mxsfb/Makefile | 2 +- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 343 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 249 - drivers/gpu/drm/mxsfb/mxsfb_drv.h | 42 ++- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 565 + drivers/gpu/drm/mxsfb/mxsfb_out.c | 99 - drivers/gpu/drm/mxsfb/mxsfb_regs.h | 103 +++--- 8 files changed, 733 insertions(+), 678 deletions(-) delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_crtc.c create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_kms.c delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/22] drm: mxsfb: Use LCDC_CTRL register name explicitly
The LCDC_CTRL register is located at address 0x. Some of the
accesses to the register simply use the mxsfb->base address. Reference
the LCDC_CTRL register explicitly instead to clarify the code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index be60c4021e2f..722bd9b4f5f9 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -170,17 +170,17 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
{
int ret;
- ret = clear_poll_bit(mxsfb->base, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_SFTRST);
if (ret)
return ret;
- writel(MODULE_CLKGATE, mxsfb->base + MXS_CLR_ADDR);
+ writel(MODULE_CLKGATE, mxsfb->base + LCDC_CTRL + MXS_CLR_ADDR);
- ret = clear_poll_bit(mxsfb->base, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_SFTRST);
if (ret)
return ret;
- return clear_poll_bit(mxsfb->base, MODULE_CLKGATE);
+ return clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_CLKGATE);
}
static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/22] drm: mxsfb: Remove register definitions from mxsfb_crtc.c
mxsfb_crtc.c defines several macros related to register addresses and
bit, which duplicates macros from mxsfb_regs.h. Use the macros from
mxsfb_regs.h instead and remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 722bd9b4f5f9..aef72adabf41 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -29,10 +29,6 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
-#define MXS_SET_ADDR 0x4
-#define MXS_CLR_ADDR 0x8
-#define MODULE_CLKGATE BIT(30)
-#define MODULE_SFTRST BIT(31)
/* 1 second delay should be plenty of time for block reset */
#define RESET_TIMEOUT 100
@@ -162,7 +158,7 @@ static int clear_poll_bit(void __iomem *addr, u32 mask)
{
u32 reg;
- writel(mask, addr + MXS_CLR_ADDR);
+ writel(mask, addr + REG_CLR);
return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
}
@@ -170,17 +166,17 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
{
int ret;
- ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_SFTRST);
if (ret)
return ret;
- writel(MODULE_CLKGATE, mxsfb->base + LCDC_CTRL + MXS_CLR_ADDR);
+ writel(CTRL_CLKGATE, mxsfb->base + LCDC_CTRL + REG_CLR);
- ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_SFTRST);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_SFTRST);
if (ret)
return ret;
- return clear_poll_bit(mxsfb->base + LCDC_CTRL, MODULE_CLKGATE);
+ return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
}
static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/22] drm: mxsfb: Remove unused macros from mxsfb_regs.h
mxsfb_regs.h defines macros related to register bits. Some of them are not used and don't clearly map to any particular register, so their purpose isn't known. Remove them. Signed-off-by: Laurent Pinchart Reviewed-by: Stefan Agner Reviewed-by: Emil Velikov --- drivers/gpu/drm/mxsfb/mxsfb_regs.h | 8 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h b/drivers/gpu/drm/mxsfb/mxsfb_regs.h index 713d8f830135..78e6cb754712 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h +++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h @@ -91,17 +91,9 @@ #define MXSFB_MAX_XRES 0x #define MXSFB_MAX_YRES 0x -#define RED 0 -#define GREEN 1 -#define BLUE 2 -#define TRANSP 3 - #define STMLCDIF_8BIT 1 /* pixel data bus to the display is of 8 bit width */ #define STMLCDIF_16BIT 0 /* pixel data bus to the display is of 16 bit width */ #define STMLCDIF_18BIT 2 /* pixel data bus to the display is of 18 bit width */ #define STMLCDIF_24BIT 3 /* pixel data bus to the display is of 24 bit width */ -#define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT(1 << 6) -#define MXSFB_SYNC_DOTCLK_FALLING_ACT (1 << 7) /* negative edge sampling */ - #endif /* __MXSFB_REGS_H__ */ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/22] drm: mxsfb: Remove fbdev leftovers
Commit 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
replaced fbdev handling with drm_fbdev_generic_setup() but left
inclusion of the drm/drm_fb_cma_helper.h header. Remove it.
Fixes: 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 47c7dce03da4..96ee67ef9a13 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
On Wed, Jun 17, 2020 at 05:20:14PM +0300, Dmitry Osipenko wrote:
> 17.06.2020 17:10, Thierry Reding пишет:
> > On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
> >> 16.06.2020 21:14, Thierry Reding пишет:
> >>> From: Thierry Reding
> >>>
> >>> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> >>> have a zpos property") a warning is emitted if there's a mix of planes
> >>> with and without a zpos property.
> >>>
> >>> On Tegra, cursor planes are always composited on top of all other
> >>> planes, which is why they never had a zpos property attached to them.
> >>> However, since the composition order is fixed, this is trivial to
> >>> remedy by simply attaching an immutable zpos property to them.
> >>>
> >>> v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
> >>> v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
> >>>
> >>> Reported-by: Jonathan Hunter
> >>> Signed-off-by: Thierry Reding
> >>> ---
> >>> drivers/gpu/drm/tegra/dc.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >>> index 83f31c6e891c..04d6848d19fc 100644
> >>> --- a/drivers/gpu/drm/tegra/dc.c
> >>> +++ b/drivers/gpu/drm/tegra/dc.c
> >>> @@ -957,6 +957,7 @@ static struct drm_plane
> >>> *tegra_dc_cursor_plane_create(struct drm_device *drm,
> >>> }
> >>>
> >>> drm_plane_helper_add(>base, _cursor_plane_helper_funcs);
> >>> + drm_plane_create_zpos_immutable_property(>base, 255);
> >>>
> >>> return >base;
> >>> }
> >>>
> >>
> >> Looks nice, thanks! Since you dropped all other zpos changes for other
> >> planes and given that the other planes have 255 for the max zpos, what
> >> about to set the cursor's zpos to 256?
> >
> > I'd prefer to have all of the planes' zpos within the same range. By
> > default the other planes will be on the very bottom end of that range
> > and the atomic core will normalize the zpos for all planes anyway, so
> > the cursor plane will end up with a very small normalized zpos in the
> > end.
> >
> > The zpos documentation already mentions that the behaviour is undefined
> > if two planes have the same zpos value, so I think userspace is going to
> > know how to set these anyway.
> >
> > It might be worth to do a follow-up patch that is smarter about setting
> > the range of valid values. 0-255 is true on later chips where we
> > actually have a proper "layer depth" register field and I wanted this to
> > be uniform across all generations. Other drivers seem to set the upper
> > limit on the zpos range to be equal to the number of planes available,
> > so that there aren't potentially big gaps in the numbering. That said,
> > since the core already normalizes the zpos for us, I don't see a big
> > benefit in explicitly clipping the range.
>
> But the cursor plane doesn't use the "layer depth" register, doesn't it?
> So the zpos over 255 shouldn't matter in this case.
>
> I know that DRM should normalizes the given zpos, but still it makes me
> a bit uncomfortable knowing that there are the ranges overlap visible to
> userspace :)
Userspace has to be able to deal with this anyway because it can't make
any assumptions about what hardware supports underneath. A cursor on a
different platform may very well be stackable anywhere in the layout so
it must ensure that the cursor always has the highest zpos (provided
that that's what it wants). Immutable 255 basically just says that the
cursor is always going to be at the top. /If/ userspace then decides to
set some other plane's zpos = 255, then we're in the "undefined"
behaviour case that the documentation mentions, in which case the
behaviour on Tegra would still be sane in showing the cursor on top.
So I don't think there's really an issue with the overlap.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 22/22] drm: mxsfb: Support the alpha plane
On 2020-05-30 05:10, Laurent Pinchart wrote:
> The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
> plane. Support it.
>
> Signed-off-by: Laurent Pinchart
Looks good to me.
Reviewed-by: Stefan Agner
--
Stefan
> ---
> Changes since v1:
>
> - Split whitespace cleanup to a separate patch
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 6 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 129 +
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 22 +
> 4 files changed, 144 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index ed8e3f7bc27c..ab3a212375f1 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -49,6 +49,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
> .next_buf = LCDC_V3_NEXT_BUF,
> .hs_wdth_mask = 0xff,
> .hs_wdth_shift = 24,
> + .has_overlay= false,
> },
> [MXSFB_V4] = {
> .transfer_count = LCDC_V4_TRANSFER_COUNT,
> @@ -56,6 +57,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
> .next_buf = LCDC_V4_NEXT_BUF,
> .hs_wdth_mask = 0x3fff,
> .hs_wdth_shift = 18,
> + .has_overlay= false,
> },
> [MXSFB_V6] = {
> .transfer_count = LCDC_V4_TRANSFER_COUNT,
> @@ -63,6 +65,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
> .next_buf = LCDC_V4_NEXT_BUF,
> .hs_wdth_mask = 0x3fff,
> .hs_wdth_shift = 18,
> + .has_overlay= true,
> },
> };
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> index f883b56caed3..399d23e91ed1 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> @@ -21,6 +21,7 @@ struct mxsfb_devdata {
> unsigned intnext_buf;
> unsigned inths_wdth_mask;
> unsigned inths_wdth_shift;
> + boolhas_overlay;
> };
>
> struct mxsfb_drm_private {
> @@ -32,7 +33,10 @@ struct mxsfb_drm_private {
> struct clk *clk_disp_axi;
>
> struct drm_device *drm;
> - struct drm_planeplane;
> + struct {
> + struct drm_planeprimary;
> + struct drm_planeoverlay;
> + } planes;
> struct drm_crtc crtc;
> struct drm_encoder encoder;
> struct drm_connector*connector;
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index f81f8c222c13..c9c394f7cbe2 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -169,9 +169,9 @@ static int mxsfb_reset_block(struct
> mxsfb_drm_private *mxsfb)
> return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
> }
>
> -static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
> +static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
> {
> - struct drm_framebuffer *fb = mxsfb->plane.state->fb;
> + struct drm_framebuffer *fb = plane->state->fb;
> struct drm_gem_cma_object *gem;
>
> if (!fb)
> @@ -206,6 +206,9 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
> /* Clear the FIFOs */
> writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
>
> + if (mxsfb->devdata->has_overlay)
> + writel(0, mxsfb->base + LCDC_AS_CTRL);
> +
> mxsfb_set_formats(mxsfb);
>
> clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
> @@ -313,7 +316,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
> *crtc,
> mxsfb_crtc_mode_set_nofb(mxsfb);
>
> /* Write cur_buf as well to avoid an initial corrupt frame */
> - paddr = mxsfb_get_fb_paddr(mxsfb);
> + paddr = mxsfb_get_fb_paddr(crtc->primary);
> if (paddr) {
> writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
> writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> @@ -410,20 +413,85 @@ static int mxsfb_plane_atomic_check(struct
> drm_plane *plane,
> false, true);
> }
>
> -static void mxsfb_plane_atomic_update(struct drm_plane *plane,
> - struct drm_plane_state *old_pstate)
> +static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state
> *old_pstate)
> {
> struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
> dma_addr_t paddr;
>
> - paddr = mxsfb_get_fb_paddr(mxsfb);
> + paddr = mxsfb_get_fb_paddr(plane);
> if (paddr)
> writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> }
>
> -static const
[PATCH][next] drm/mm/selftests: fix unsigned comparison with less than zero
From: Colin Ian King
Function get_insert_time can return error values that are cast
to a u64. The checks of insert_time1 and insert_time2 check for
the errors but because they are u64 variables the check for less
than zero can never be true. Fix this by casting the value to s64
to allow of the negative error check to succeed.
Addresses-Coverity: ("Unsigned compared against 0, no effect")
Fixes: 6e60d5ded06b ("drm/mm: add ig_frag selftest")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/selftests/test-drm_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 3846b0f5bae3..671a152a6df2 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1124,12 +1124,12 @@ static int igt_frag(void *ignored)
insert_time1 = get_insert_time(, insert_size,
nodes + insert_size, mode);
- if (insert_time1 < 0)
+ if ((s64)insert_time1 < 0)
goto err;
insert_time2 = get_insert_time(, (insert_size * 2),
nodes + insert_size * 2, mode);
- if (insert_time2 < 0)
+ if ((s64)insert_time2 < 0)
goto err;
pr_info("%s fragmented insert of %u and %u insertions took %llu
and %llu nsecs\n",
--
2.27.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon
On Tue, Jun 16, 2020 at 5:15 AM Stephen Boyd wrote:
>
> Quoting Tanmay Shah (2020-06-11 18:50:26)
> > diff --git a/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml
> > b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml
> > new file mode 100644
> > index ..5fdb9153df00
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml
> > @@ -0,0 +1,142 @@
> > +data-lanes = <0 1>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +dp_in: endpoint {
> > +remote-endpoint = <_intf0_out>;
> > +};
> > +};
> > +
> > +port@1 {
> > +reg = <1>;
> > +dp_out: endpoint {
>
> Just curious what is eventually connected here? This is possibly a
> question for Rob Herring, but I can't figure out how we're supposed to
> connect this to the USB type-c connector that is receiving the DP
> signal. Does the type-c connector binding support connecting to this end
> of the graph? Or should this connect to the DP phy and then the phy
> connects to the USB type-c connector node? Right now it is empty which
> seems wrong.
It should connect to the Type-C connector perhaps thru some sort of
switching/muxing node, but that's not really flushed out though. See
'dt-bindings: chrome: Add cros-ec-typec mux props' discussion with
your CrOS colleagues.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add enable/disable flip done and flip done handler
On Wed, Jun 17, 2020 at 11:58:10AM +0200, Daniel Vetter wrote:
> On Wed, Jun 10, 2020 at 03:33:06PM -0700, Paulo Zanoni wrote:
> > Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> > > Add enable/disable flip done functions and the flip done handler
> > > function which handles the flip done interrupt.
> > >
> > > Enable the flip done interrupt in IER.
> > >
> > > Enable flip done function is called before writing the
> > > surface address register as the write to this register triggers
> > > the flip done interrupt
> > >
> > > Flip done handler is used to send the page flip event as soon as the
> > > surface address is written as per the requirement of async flips.
> > > The interrupt is disabled after the event is sent.
> > >
> > > v2: -Change function name from icl_* to skl_* (Paulo)
> > > -Move flip handler to this patch (Paulo)
> > > -Remove vblank_put() (Paulo)
> > > -Enable flip done interrupt for gen9+ only (Paulo)
> > > -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> > > -Removed the event check in flip done handler to handle async
> > > flips without pageflip events.
> > >
> > > v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> > > -Make the pending vblank event NULL in the begining of
> > > flip_done_handler to remove sporadic WARN_ON that is seen.
> > >
> > > Signed-off-by: Karthik B S
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 10
> > > drivers/gpu/drm/i915/i915_irq.c | 52
> > > drivers/gpu/drm/i915/i915_irq.h | 2 +
> > > 3 files changed, 64 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index f40b909952cc..48cc1fc9bc5a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -15530,6 +15530,13 @@ static void intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > >
> > > intel_dbuf_pre_plane_update(state);
> > >
> > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->uapi.async_flip) {
> > > + skl_enable_flip_done(>base);
> > > + break;
> > > + }
> > > + }
> > > +
> > > /* Now enable the clocks, plane, pipe, and connectors that we set up.
> > > */
> > > dev_priv->display.commit_modeset_enables(state);
> > >
> > > @@ -15551,6 +15558,9 @@ static void intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > > drm_atomic_helper_wait_for_flip_done(dev, >base);
> > >
> > > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->uapi.async_flip)
> > > + skl_disable_flip_done(>base);
> > > +
> > > if (new_crtc_state->hw.active &&
> > > !needs_modeset(new_crtc_state) &&
> > > !new_crtc_state->preload_luts &&
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index efdd4c7b8e92..632e7b1deb87 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1295,6 +1295,23 @@ display_pipe_crc_irq_handler(struct
> > > drm_i915_private *dev_priv,
> > > u32 crc4) {}
> > > #endif
> > >
> > > +static void flip_done_handler(struct drm_i915_private *dev_priv,
> > > + unsigned int pipe)
> > > +{
> > > + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > > + struct drm_crtc_state *crtc_state = crtc->base.state;
> > > + struct drm_pending_vblank_event *e = crtc_state->event;
> > > + struct drm_device *dev = _priv->drm;
> > > + unsigned long irqflags;
> > > +
> > > + crtc_state->event = NULL;
> > > +
> > > + spin_lock_irqsave(>event_lock, irqflags);
> > > +
> > > + drm_crtc_send_vblank_event(>base, e);
> >
> > I don't think this is what we want. With this, the events the Kernel
> > sends us all have the same sequence and timestamp. In fact, the IGT
> > test you submitted fails because of this.
> >
> > In my original hackish proof-of-concept patch I had changed
> > drm_update_vblank_count() to force diff=1 in order to always send
> > events and I also changed g4x_get_vblank_counter() to get the counter
> > from FLIPCOUNT (which updates every time there's a flip) instead of
> > FRMCOUNT (which doesn't seem to increment when you do async flips).
> > That is a drastic change, but the patch was just a PoC so I didn't care
> > about keeping anything else working.
> >
> > One thing that confused me a little bit when dealing the the
> > vblank/flip event interface from drm.ko is that "flips" and "vblanks"
> > seem to be changed interchangeably, which is confusing for async flips:
> > if you keep forever doing async flips in the very first few scanlines
> > you never
Re: [PATCH v2 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
Reviewed-by: Lyude Paul
Thanks for all the subtle fixes for broken MST displays, these are always my
favorite to find :)
On Wed, 2020-06-17 at 00:11 +0300, Imre Deak wrote:
> Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> sink's payload table, along clearing the payload table updated flag.
> The sink is supposed to set this flag once it detects that the source
> has completed the ACT sequence (after detecting the 4 required ACT MTPH
> symbols sent by the source). As opposed to this 2 DELL monitors I have
> set the flag already along the payload table updated flag, which is not
> quite correct.
>
> To be sure that the sink has detected the ACT MTPH symbols before
> continuing enabling the encoder, clear the ACT sent flag before enabling
> or disabling the transcoder VC payload allocation (which is what starts
> the ACT sequence).
>
> v2 (Ville):
> - Use the correct bit to clear the flags.
> - Add code comment explaining the clearing semantics of the ACT handled
> flag.
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 38 +++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
> include/drm/drm_dp_mst_helper.h | 2 ++
> 3 files changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b2f5a84b4cfb..1f5d14128c1a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4377,6 +4377,41 @@ void drm_dp_mst_deallocate_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
> }
> EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
>
> +/**
> + * drm_dp_clear_payload_status() - Clears the payload table status flags
> + * @mgr: manager to use
> + *
> + * Clears the payload table ACT handled and table updated flags in the MST
> hub's
> + * DPCD. This function must be called before updating the payload table or
> + * starting the ACT sequence and waiting for the corresponding flags to get
> + * set by the hub.
> + *
> + * Returns:
> + * 0 if the flags got cleared successfully, otherwise a negative error
> code.
> + */
> +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> +{
> + int ret;
> +
> + /*
> + * Note that the following is based on the DP Standard stating that
> + * writing the DP_PAYLOAD_TABLE_UPDATED bit alone will clear both the
> + * DP_PAYLOAD_TABLE_UPDATED and the DP_PAYLOAD_ACT_HANDLED flags. This
> + * seems to be also the only way to clear DP_PAYLOAD_ACT_HANDLED.
> + */
> + ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> + DP_PAYLOAD_TABLE_UPDATED);
> + if (ret < 0) {
> + DRM_DEBUG_DRIVER("Can't clear the ACT handled/table updated
> flags (%d)\n",
> + ret);
> + return ret;
> + }
> + WARN_ON(ret != 1);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> +
> static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
>int id, struct drm_dp_payload *payload)
> {
> @@ -4384,8 +4419,7 @@ static int drm_dp_dpcd_write_payload(struct
> drm_dp_mst_topology_mgr *mgr,
> int ret;
> int retries = 0;
>
> - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> -DP_PAYLOAD_TABLE_UPDATED);
> + drm_dp_clear_payload_status(mgr);
>
> payload_alloc[0] = id;
> payload_alloc[1] = payload->start_slot;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 9308b5920780..3c4b0fb10d8b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp)
>
> intel_de_write(i915, intel_dp->regs.dp_tp_status,
> DP_TP_STATUS_ACT_SENT);
> +
> + drm_dp_clear_payload_status(_dp->mst_mgr);
> }
>
> static void wait_for_act_sent(struct intel_dp *intel_dp)
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h
> index 8b9eb4db3381..2facb87624bf 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct
> drm_dp_mst_topology_mgr *mgr,
> int pbn);
>
>
> +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr);
> +
> int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
>
>
--
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/22] drm: mxsfb: Use drm_panel_bridge
On 2020-05-30 05:09, Laurent Pinchart wrote:
> Replace the manual connector implementation based on drm_panel with the
> drm_panel_bridge helper. This simplifies the mxsfb driver by removing
> connector-related code, and standardizing all pipeline control
> operations on bridges.
>
> A hack is needed to get hold of the connector, as that's our only source
> of bus flags and formats for now. As soon as the bridge API provides us
> with that information this can be fixed.
>
> Signed-off-by: Laurent Pinchart
As discussed in the late discussion on the v1 thread, we should add a
default type to avoid warnings for some panels.
Other than that, looks good to me:
Reviewed-by: Stefan Agner
> ---
> Changes since v1:
>
> - Select DRM_PANEL_BRIDGE in Kconfig
> ---
> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> drivers/gpu/drm/mxsfb/Makefile| 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +-
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 99
> 5 files changed, 54 insertions(+), 158 deletions(-)
> delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c
>
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0dca8f27169e..e43b326e9147 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -13,6 +13,7 @@ config DRM_MXSFB
> select DRM_KMS_FB_HELPER
> select DRM_KMS_CMA_HELPER
> select DRM_PANEL
> + select DRM_PANEL_BRIDGE
> help
> Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
> LCD controller.
> diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
> index ff6e358088fa..811584e54ad1 100644
> --- a/drivers/gpu/drm/mxsfb/Makefile
> +++ b/drivers/gpu/drm/mxsfb/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o
> +mxsfb-y := mxsfb_drv.o mxsfb_crtc.o
> obj-$(CONFIG_DRM_MXSFB) += mxsfb.o
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 2e6068d96034..cffc70257bd3 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -29,7 +29,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -100,29 +99,11 @@ static void mxsfb_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
> {
> - struct drm_connector *connector;
> struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> struct drm_device *drm = pipe->plane.dev;
>
> - if (!mxsfb->connector) {
> - list_for_each_entry(connector,
> - >mode_config.connector_list,
> - head)
> - if (connector->encoder == >pipe.encoder) {
> - mxsfb->connector = connector;
> - break;
> - }
> - }
> -
> - if (!mxsfb->connector) {
> - dev_warn(drm->dev, "No connector attached, using default\n");
> - mxsfb->connector = >panel_connector;
> - }
> -
> pm_runtime_get_sync(drm->dev);
> - drm_panel_prepare(mxsfb->panel);
> mxsfb_crtc_enable(mxsfb);
> - drm_panel_enable(mxsfb->panel);
> }
>
> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> @@ -132,9 +113,7 @@ static void mxsfb_pipe_disable(struct
> drm_simple_display_pipe *pipe)
> struct drm_crtc *crtc = >crtc;
> struct drm_pending_vblank_event *event;
>
> - drm_panel_disable(mxsfb->panel);
> mxsfb_crtc_disable(mxsfb);
> - drm_panel_unprepare(mxsfb->panel);
> pm_runtime_put_sync(drm->dev);
>
> spin_lock_irq(>event_lock);
> @@ -144,9 +123,6 @@ static void mxsfb_pipe_disable(struct
> drm_simple_display_pipe *pipe)
> drm_crtc_send_vblank_event(crtc, event);
> }
> spin_unlock_irq(>event_lock);
> -
> - if (mxsfb->connector != >panel_connector)
> - mxsfb->connector = NULL;
> }
>
> static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
> @@ -190,6 +166,48 @@ static struct drm_simple_display_pipe_funcs mxsfb_funcs
> = {
> .disable_vblank = mxsfb_pipe_disable_vblank,
> };
>
> +static int mxsfb_attach_bridge(struct mxsfb_drm_private *mxsfb)
> +{
> + struct drm_device *drm = mxsfb->drm;
> + struct drm_connector_list_iter iter;
> + struct drm_panel *panel;
> + struct drm_bridge *bridge;
> + int ret;
> +
> + ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, ,
> + );
> + if (ret)
> + return ret;
> +
> + if (panel) {
> + bridge = devm_drm_panel_bridge_add(drm->dev, panel);
> + if
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add enable/disable flip done and flip done handler
On 2020-06-17 5:58 a.m., Daniel Vetter wrote:
On Wed, Jun 10, 2020 at 03:33:06PM -0700, Paulo Zanoni wrote:
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Flip done handler is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
The interrupt is disabled after the event is sent.
v2: -Change function name from icl_* to skl_* (Paulo)
-Move flip handler to this patch (Paulo)
-Remove vblank_put() (Paulo)
-Enable flip done interrupt for gen9+ only (Paulo)
-Enable flip done interrupt in power_well_post_enable hook (Paulo)
-Removed the event check in flip done handler to handle async
flips without pageflip events.
v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
-Make the pending vblank event NULL in the begining of
flip_done_handler to remove sporadic WARN_ON that is seen.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 10
drivers/gpu/drm/i915/i915_irq.c | 52
drivers/gpu/drm/i915/i915_irq.h | 2 +
3 files changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f40b909952cc..48cc1fc9bc5a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15530,6 +15530,13 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_dbuf_pre_plane_update(state);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ skl_enable_flip_done(>base);
+ break;
+ }
+ }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
@@ -15551,6 +15558,9 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
drm_atomic_helper_wait_for_flip_done(dev, >base);
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip)
+ skl_disable_flip_done(>base);
+
if (new_crtc_state->hw.active &&
!needs_modeset(new_crtc_state) &&
!new_crtc_state->preload_luts &&
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index efdd4c7b8e92..632e7b1deb87 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1295,6 +1295,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
*dev_priv,
u32 crc4) {}
#endif
+static void flip_done_handler(struct drm_i915_private *dev_priv,
+ unsigned int pipe)
+{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_crtc_state *crtc_state = crtc->base.state;
+ struct drm_pending_vblank_event *e = crtc_state->event;
+ struct drm_device *dev = _priv->drm;
+ unsigned long irqflags;
+
+ crtc_state->event = NULL;
+
+ spin_lock_irqsave(>event_lock, irqflags);
+
+ drm_crtc_send_vblank_event(>base, e);
I don't think this is what we want. With this, the events the Kernel
sends us all have the same sequence and timestamp. In fact, the IGT
test you submitted fails because of this.
In my original hackish proof-of-concept patch I had changed
drm_update_vblank_count() to force diff=1 in order to always send
events and I also changed g4x_get_vblank_counter() to get the counter
from FLIPCOUNT (which updates every time there's a flip) instead of
FRMCOUNT (which doesn't seem to increment when you do async flips).
That is a drastic change, but the patch was just a PoC so I didn't care
about keeping anything else working.
One thing that confused me a little bit when dealing the the
vblank/flip event interface from drm.ko is that "flips" and "vblanks"
seem to be changed interchangeably, which is confusing for async flips:
if you keep forever doing async flips in the very first few scanlines
you never actually reach the "vblank" period, yet you keep flipping
your frame. Then, what should your expectation regarding events be?
Hm vblank should keep happening I thought (this isn't VRR or DRRS or PSR
where that changes), no idea why we can't keep sending out vblank
interrupts.
Now flip events look maybe conflated in drm.ko code with vblank events
since most of the time a flip complete happens at exactly the same time
the vblank event. But for async flip this is not the case.
Probably worth it to have new helpers/function in drm_vblank.c for
async flips, so that this is less
Re: [PATCH v3] drm/panfrost: Reduce the amount of logs on deferred probe
On 17/06/2020 15:15, Krzysztof Kozlowski wrote: On Wed, May 27, 2020 at 04:43:34PM -0400, Alyssa Rosenzweig wrote: Reviewed-by: Alyssa Rosenzweig On Wed, May 27, 2020 at 10:05:44PM +0200, Krzysztof Kozlowski wrote: There is no point to print deferred probe (and its failures to get resources) as an error. Also there is no need to print regulator errors twice. In case of multiple probe tries this would pollute the dmesg. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Steven Price --- Changes since v2: 1. Rebase 2. Add Steven's review Changes since v1: 1. Remove second error message from calling panfrost_regulator_init() --- drivers/gpu/drm/panfrost/panfrost_device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) Hi Rob, Tomeu and Steven, You're listed as maintainers for panfrost. Is anyone going to pick this up? I'm only a reviewer so I've been leaving it for Rob or Tomeu, but I can pick it up if Rob/Tomeu are happy for me to do that. Maybe I sent it to wrong mailing list or forgot about anything? No, there's actually a few Panfrost commits waiting, it was on my todo list to ask if Rob/Tomeu needed some help with merging patches. Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panfrost: Reduce the amount of logs on deferred probe
On Wed, May 27, 2020 at 04:43:34PM -0400, Alyssa Rosenzweig wrote: > Reviewed-by: Alyssa Rosenzweig > > On Wed, May 27, 2020 at 10:05:44PM +0200, Krzysztof Kozlowski wrote: > > There is no point to print deferred probe (and its failures to get > > resources) as an error. Also there is no need to print regulator errors > > twice. > > > > In case of multiple probe tries this would pollute the dmesg. > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Steven Price > > > > --- > > > > Changes since v2: > > 1. Rebase > > 2. Add Steven's review > > > > Changes since v1: > > 1. Remove second error message from calling panfrost_regulator_init() > > --- > > drivers/gpu/drm/panfrost/panfrost_device.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > Hi Rob, Tomeu and Steven, You're listed as maintainers for panfrost. Is anyone going to pick this up? Maybe I sent it to wrong mailing list or forgot about anything? Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
> 16.06.2020 21:14, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> > have a zpos property") a warning is emitted if there's a mix of planes
> > with and without a zpos property.
> >
> > On Tegra, cursor planes are always composited on top of all other
> > planes, which is why they never had a zpos property attached to them.
> > However, since the composition order is fixed, this is trivial to
> > remedy by simply attaching an immutable zpos property to them.
> >
> > v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
> > v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
> >
> > Reported-by: Jonathan Hunter
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/gpu/drm/tegra/dc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 83f31c6e891c..04d6848d19fc 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -957,6 +957,7 @@ static struct drm_plane
> > *tegra_dc_cursor_plane_create(struct drm_device *drm,
> > }
> >
> > drm_plane_helper_add(>base, _cursor_plane_helper_funcs);
> > + drm_plane_create_zpos_immutable_property(>base, 255);
> >
> > return >base;
> > }
> >
>
> Looks nice, thanks! Since you dropped all other zpos changes for other
> planes and given that the other planes have 255 for the max zpos, what
> about to set the cursor's zpos to 256?
I'd prefer to have all of the planes' zpos within the same range. By
default the other planes will be on the very bottom end of that range
and the atomic core will normalize the zpos for all planes anyway, so
the cursor plane will end up with a very small normalized zpos in the
end.
The zpos documentation already mentions that the behaviour is undefined
if two planes have the same zpos value, so I think userspace is going to
know how to set these anyway.
It might be worth to do a follow-up patch that is smarter about setting
the range of valid values. 0-255 is true on later chips where we
actually have a proper "layer depth" register field and I wanted this to
be uniform across all generations. Other drivers seem to set the upper
limit on the zpos range to be equal to the number of planes available,
so that there aren't potentially big gaps in the numbering. That said,
since the core already normalizes the zpos for us, I don't see a big
benefit in explicitly clipping the range.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 --- Comment #19 from udo (udo...@xs4all.nl) --- Appears to work OK for me: AMD Ryzen 5 3400G with Radeon Vega Graphics on Gigabyte X570 AORUS PRO, Fedora 31, git mesa, kernel.org 5.6.x, etc amdgpu.gttsize=8192 amdgpu.lockup_timeout=1000 amdgpu.gpu_recovery=1 amdgpu.noretry=0 amdgpu.ppfeaturemask=0xfffd3fff -- 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 v5 08/12] device core: Introduce multiple dma pfn offsets
Hi Jim,
Thanks for taking this on!
On 2020-06-16 21:55, Jim Quinlan wrote:
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
This isn't just about offsets - it should (eventually) subsume
bus_dma_limit as well, so I'd be inclined to call it something like
"dma_ranges"/"dma_range_map"/"dma_regions"/etc.
The function of_dma_get_range() has been modified to take two additional
arguments: the "map", which is an array that holds the information
regarding the pfn offset regions, and map_size, which is the size in bytes
of the map array.
of_dma_configure() is the typical manner to set pfn offsets but there are a
number of ad hoc assignments to dev->dma_pfn_offset in the kernel driver
code. These cases now invoke the function
dma_attach_uniform_pfn_offset(dev, pfn_offset).
I'm also not convinced that sticking to the PFN paradigm is necessarily
the right way to go - when there's only a single nicely-aligned offset
to consider then an unsigned long that's immune to PAE/LPAE/etc.
disruption is indeed the cheapest and easiest option from core code's
PoV. However it already means that all the users have to do some degree
of conversion back and forth between PFNs and usable addresses; once the
core code itself also has to start bouncing back and forth between
addresses and PFNs internally then we end up effectively just doing work
to cancel out other work, and the whole lot would end up simpler and
more efficient if the API worked purely in terms of addresses.
[...]
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..767fa3b492c8 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -918,12 +918,48 @@ void __iomem *of_io_request_and_map(struct device_node
*np, int index,
}
EXPORT_SYMBOL(of_io_request_and_map);
+static int dma_attach_pfn_offset_map(struct device_node *node, int num_ranges,
+struct bus_dma_region **map, size_t
*map_size)
+{
+ struct of_range_parser parser;
+ struct of_range range;
+ struct bus_dma_region *r;
+
+ *map_size = (num_ranges + 1) * sizeof(**map);
+ r = kcalloc(num_ranges + 1, sizeof(**map), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+ *map = r;
+
+ of_dma_range_parser_init(, node);
+ /*
+* Record all info for DMA ranges array. We could
+* just use the of_range struct, but if we did that it
Not making the entire DMA API depend on OF is a far better justification
for having its own dedicated structure.
+* would require more calculations for phys_to_dma and
+* dma_to_phys conversions.
+*/
However that part is pretty much nonsense. Consider your "efficient"
operation for looking up and consuming a DMA offset:
API caller
1. load cpu_start
2. compare addr >= cpu_start
3. load cpu_end
4. compare addr <= cpu_end
5. load pfn_offset
6. shift pfn_offset << PAGE_SHIFT
7. add "offset" + addr
8. [use the result]
versus the "more calculations" approach (once the PFN cruft is peeled away):
API caller
1. load cpu_addr
2. compare addr >= cpu_addr
3. subtract addr - cpu_addr
4. load size
5. compare "addr_offset" < size
6. load dma_start
7. add dma_start + "addr_offset"
8. [use the result]
Oh look, it's the exact same number of memory accesses and ALU
operations, but with a smaller code footprint (assuming, reasonably,
more than one caller) and less storage overhead ;)
Basically, having this degree of redundancy is somewhere between silly
and actively harmful (what if pfn_offset gets out of sync with
cpu_start/dma_start? What if cpu_end/dma_end don't represent equivalent
lengths?)
+ for_each_of_range(, ) {
+ r->cpu_start = range.cpu_addr;
+ r->cpu_end = r->cpu_start + range.size - 1;
+ r->dma_start = range.bus_addr;
+ r->dma_end = r->dma_start + range.size - 1;
+ r->pfn_offset = PFN_DOWN(range.cpu_addr) -
PFN_DOWN(range.bus_addr);
+ r++;
+ }
+ return 0;
+}
+
/**
* of_dma_get_range - Get DMA range info
* @np: device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr:pointer to store initial CPU address of DMA range
* @size: pointer to store size of DMA range
+ * @map: pointer to a pointer of an array of structs. This is updated
+ * to point to NULL (no offsets needed) or kmalloc'd array of
+ * structs. In the latter case, it is the caller's obligation to
+ * kfree the array in the case it is no longer in
Re: [PATCH] drm/mgag200: Don't set in MISC
Hi Am 17.06.20 um 11:22 schrieb Rong Chen: > On Wed, Jun 17, 2020 at 08:28:02AM +0200, Thomas Zimmermann wrote: >> Hi Emil >> >> Am 16.06.20 um 17:14 schrieb Emil Velikov: >>> Hi Thomas, >>> >>> On Tue, 16 Jun 2020 at 15:26, Thomas Zimmermann wrote: The original modesetting code set MISC to 0x2d, which is , and With the conversion to atomic modesetting, accidentally got enabled as well. Revert this change and initialize MISC with a constant value of and . The bits are set in mga_crtc_set_plls(), sync flags are set in mgag200_set_mode_regs(). >>> >>> Let's keep the remove (restoring original functionality) and rename >>> (cosmetics) separate patches. The read has also disappeared, which >>> should be safe although might be better on it's own. >> >> I'm waiting for Rong Chen's performance results on this patch. Moving >> the rename into a separate patch makes sense, but removing the read is >> part of restoring the original behavior. I think it should be in this >> patch. Maybe I can write a better commit message to highlight the change. >> > > Hi Thomas, > > I tested the patch based on previous patch series, it seems doesn't take > effect, and commit 39fb72816c4ee brings a larger regression when > comparing to commit caac4dda44f37: Thanks for testing! I still don't understand these numbers, but are you sure that e44e907dd8f93 is really the regression? It would make sense that 39fb72816c4ee has an impact on performance, as it changes memory management and the way the driver updates the display. I'll take a closer look at that patch and maybe send out an update. Best regards Thomas > > 4606edf870927 drm/mgag200: Don't set in MISC >3 3 3 > 39fb72816c4ee drm/mgag200: Replace VRAM helpers with SHMEM helpers >3 22 > caac4dda44f37 drm/mgag200: Convert to simple KMS helper >238 233 240 234 239 > 4b11c90431108 drm/mgag200: Use simple-display data structures >35 34 34 34 > db22c903c9322 drm/mgag200: Remove out-commented suspend/resume helpers >34 34 > 87d4880d2aeb5 drm/mgag200: Move register initialization into separate > function 35 > 0c51726f95396 drm/mgag200: Move hiprilvl setting into separate functions >35 > 8078e8b182e73 drm/mgag200: Set primary plane's format in separate helper > function35 > 19f7b409d95b7 drm/mgag200: Set pitch in a separate helper function >35 34 > 9b9a363828c60 drm/mgag200: Update mode registers after plane registers >34 > e44e907dd8f93 drm/mgag200: Split MISC register update into PLL selection, > SYNC and I/O 34 34 34 34 > bef2303526adb drm/mgag200: Move mode-setting code into separate helper > function 97 97 > 5cd8460e81e8f drm/mgag200: Clean up mga_crtc_do_set_base() >96 > 0671ca8c559ba drm/mgag200: Clean up mga_set_start_address() > e82c8969a2474 drm/mgag200: Remove HW cursor >96 > > Best Regards, > Rong Chen > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/12] device core: Introduce multiple dma pfn offsets
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
The function of_dma_get_range() has been modified to take two additional
arguments: the "map", which is an array that holds the information
regarding the pfn offset regions, and map_size, which is the size in bytes
of the map array.
of_dma_configure() is the typical manner to set pfn offsets but there are a
number of ad hoc assignments to dev->dma_pfn_offset in the kernel driver
code. These cases now invoke the function
dma_attach_uniform_pfn_offset(dev, pfn_offset).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +--
arch/arm/mach-keystone/keystone.c | 8 ++-
arch/sh/drivers/pci/pcie-sh7786.c | 3 +-
arch/sh/kernel/dma-coherent.c | 14 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 4 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 71 ---
drivers/of/device.c | 19 +++--
drivers/of/of_private.h | 11 +--
drivers/of/unittest.c | 8 ++-
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 4 +-
drivers/usb/core/usb.c| 2 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 14 +++-
include/linux/dma-mapping.h | 38 ++
kernel/dma/coherent.c | 11 +--
kernel/dma/mapping.c | 39 ++
23 files changed, 231 insertions(+), 60 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..f1e72f99468b 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev && dev->dma_pfn_offset_map)
+ pfn -= dma_pfn_offset_from_phys_addr(dev, PFN_PHYS(pfn));
+
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
+ if (dev && dev->dma_pfn_offset_map)
+ pfn += dma_pfn_offset_from_dma_addr(dev, addr);
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..5890ec90599e 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -38,9 +39,10 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_attach_uniform_pfn_offset(dev,
keystone_dma_pfn_offset);
+
+ dev_err(dev, "set dma_pfn_offset%08lx%s\n", dev->dma_pfn_offset,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
diff --git a/arch/sh/drivers/pci/pcie-sh7786.c
b/arch/sh/drivers/pci/pcie-sh7786.c
index e0b568aaa701..3e63c6b6e070 100644
--- a/arch/sh/drivers/pci/pcie-sh7786.c
+++ b/arch/sh/drivers/pci/pcie-sh7786.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -487,7 +488,7 @@ int pcibios_map_platform_irq(const struct pci_dev *pdev, u8
slot, u8 pin)
void pcibios_bus_add_device(struct pci_dev *pdev)
{
- pdev->dev.dma_pfn_offset = dma_pfn_offset;
+ dma_attach_uniform_pfn_offset(>dev, dma_pfn_offset);
}
static int __init sh7786_pcie_core_init(void)
diff --git a/arch/sh/kernel/dma-coherent.c b/arch/sh/kernel/dma-coherent.c
index d4811691b93c..f4a092e74910 100644
--- a/arch/sh/kernel/dma-coherent.c
+++ b/arch/sh/kernel/dma-coherent.c
@@ -14,6 +14,7 @@ void *arch_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle,
{
void *ret, *ret_nocache;
int order = get_order(size);
+ phys_addr_t phys;
gfp |= __GFP_ZERO;
@@ -34,11 +35,12 @@ void
[PATCH v5 00/12] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets.
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range() call.
Commit "device core: Add ability to handle multiple dma offsets"
-- align comment in device.h (AndyS).
-- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
dma_pfn_offset_region (AndyS).
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that
Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
On 16/06/2020 18:30, Tony Lindgren wrote: * Tomi Valkeinen [200616 13:02]: On 11/06/2020 17:00, Grygorii Strashko wrote: I think, suspend might be fixed if all devices, which are now child of ti-sysc, will do pm_runtime_force_xxx() calls at noirq suspend stage by adding: SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) Am I missing smth? Isn't this almost exactly the same my patch does? I just used suspend_late and resume_early. Is noirq phase better than late & early? Well up to you as far as I'm concerned. The noirq phase comes with serious limitations, for let's say i2c bus usage if needed. Probably also harder to debug for suspend and resume. Unfortunately, you can't use PM runtime force API at .suspend() stage as pm_runtime_get will still work and there is no sync between suspend and pm_runtime. The PM runtime force API can be used only during late/noirq as at this time pm_runtime is disabled. -- Best regards, grygorii ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] dt-bindings: display: bridge: Add documentation for LT9611
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
new file mode 100644
index ..d60208359234
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ The LT9611 is a bridge device which converts DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt9611
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 1
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ vdd-supply:
+description: Regulator for 1.8V MIPI phy power.
+
+ vcc-supply:
+description: Regulator for 3.3V IO power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ Primary MIPI port-1 for MIPI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@1:
+type: object
+description: |
+ Additional MIPI port-2 for MIPI input, used in combination
+ with primary MIPI port-1 to drive higher resolution displays
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@2:
+type: object
+description: |
+ HDMI port for HDMI output
+
+properties:
+ reg:
+const: 2
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@3b {
+compatible = "lontium,lt9611";
+reg = <0x3b>;
+
+reset-gpios = < 128 GPIO_ACTIVE_HIGH>;
+interrupts-extended = < 84 IRQ_TYPE_EDGE_FALLING>;
+
+vdd-supply = <_1v8>;
+vcc-supply = <_3v3>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+lt9611_a: endpoint {
+ remote-endpoint = <_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+lt9611_b: endpoint {
+ remote-endpoint = <_out>;
+};
+ };
+
+ port@2 {
+reg = <2>;
+lt9611_out: endpoint {
+ remote-endpoint = <_con>;
+};
+ };
+};
+ };
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1219 +++
3 files changed, 1233 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..c7f0dacfb57a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT9611
+ tristate "Lontium LT9611 DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611 DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..7d7c123a95e4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
new file mode 100644
index ..c38f89f28651
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -0,0 +1,1219 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_SEG_SIZE 256
+#define EDID_LEN 32
+#define EDID_LOOP 8
+#define KEY_DDC_ACCS_DONE 0x02
+#define DDC_NO_ACK 0x50
+
+#define LT9611_4LANES 0
+
+struct lt9611 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ bool ac_mode;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool power_on;
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ enum drm_connector_status status;
+
+ u8 edid_buf[EDID_SEG_SIZE];
+ u32 vic;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0x85ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611_ranges),
+};
+
+struct lt9611_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611_mode lt9611_modes[] = {
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611, bridge);
+}
+
+static struct lt9611 *connector_to_lt9611(struct drm_connector *connector)
+{
+ return container_of(connector, struct lt9611, connector);
+}
+
+static int lt9611_mipi_input_analog(struct lt9611 *lt9611)
+{
+
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add Lontium vendor prefix
Add prefix for Lontium Semiconductor Corporation Acked-by: Rob Herring Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..31cdb21a3d22 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -595,6 +595,8 @@ patternProperties: description: Logic Technologies Limited "^longcheer,.*": description: Longcheer Technology (Shanghai) Co., Ltd. + "^lontium,.*": +description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited "^lsi,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
