Re: [PATCH v2] drm/panel: panel-simple: Fix proper bpc for ytc700tlag_05_201c
Hi Jagan, On Sun, Jul 25, 2021 at 2:28 PM Jagan Teki wrote: > > ytc700tlag_05_201c panel support 8 bpc not 6 bpc as per > recent testing in i.MX8MM platform. > > Fix it. > > Signed-off-by: Jagan Teki What about adding a Fixes tag?
[PATCH] drm/imx/dcss: Use device_get_match_data()
The retrieval of driver data can be a bit simplified by using
device_get_match_data(), so switch to it.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index c849533ca83e..de0f02de94c4 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -168,13 +168,6 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
int ret;
struct resource *res;
struct dcss_dev *dcss;
- const struct dcss_type_data *devtype;
-
- devtype = of_device_get_match_data(dev);
- if (!devtype) {
- dev_err(dev, "no device match found\n");
- return ERR_PTR(-ENODEV);
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -187,7 +180,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
return ERR_PTR(-ENOMEM);
dcss->dev = dev;
- dcss->devtype = devtype;
+ dcss->devtype = device_get_match_data(dev);
dcss->hdmi_output = hdmi_output;
ret = dcss_clks_init(dcss);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
Hi Dmitry, On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov wrote: > diff --git a/drivers/gpu/drm/msm/msm_atomic.c > b/drivers/gpu/drm/msm/msm_atomic.c > index 6a326761dc4a..2fd0cf6421ad 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state > *state) > struct msm_kms *kms = priv->kms; > struct drm_crtc *async_crtc = NULL; > unsigned crtc_mask = get_crtc_mask(state); > - bool async = kms->funcs->vsync_time && > + bool async; > + > + if (!kms) > + return; > + > + async = kms->funcs->vsync_time && > can_do_async(state, &async_crtc); I also see the same issue on a i.MX53: https://lists.freedesktop.org/archives/freedreno/2021-January/009369.html Then I got a different suggestion from Rob. Please check: https://www.spinics.net/lists/dri-devel/msg286648.html and https://www.spinics.net/lists/dri-devel/msg286649.html Does this series fix the issue in your platform too? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
Hi Rob, On Fri, Mar 19, 2021 at 11:44 AM Rob Clark wrote: > I think that might not help if something fails to probe due to (for > example) a missing dependency, so !priv->kms is probably a better > check to cover both cases. But the 2nd patch makes a good point, that > the suspend/resume path probably needs the same treatment Thanks for the feedback. I will follow the same approach for fixing the suspend/resume path then. Let me test it and then I will re-submit Dmitry's patch and the one for suspend/resume as part of a patch series. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: fix shutdown hook in case GPU components failed to bind
From: Dmitry Baryshkov
If GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm: Fix suspend/resume on i.MX5
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x1c4/0x1d4)
[ 70.050913] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_suspend+0xb8/0x170)
[ 70.061198] [] (drm_atomic_helper_suspend) from
[] (drm_mode_config_helper_suspend+0x24/0x58)
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_mode_config_helper_suspend/resume()
only when priv->kms is available.
Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM
sleep")
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fd2ac54caf9f..a5c6b8c23336 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1072,6 +1072,10 @@ static int __maybe_unused msm_pm_resume(struct device
*dev)
static int __maybe_unused msm_pm_prepare(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return 0;
return drm_mode_config_helper_suspend(ddev);
}
@@ -1079,6 +1083,10 @@ static int __maybe_unused msm_pm_prepare(struct device
*dev)
static void __maybe_unused msm_pm_complete(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_mode_config_helper_resume(ddev);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
On Fri, Mar 19, 2021 at 12:13 PM Fabio Estevam wrote: > Thanks for the feedback. > I will follow the same approach for fixing the suspend/resume path then. > > Let me test it and then I will re-submit Dmitry's patch and the one > for suspend/resume as part of a patch series. This approach works here for the suspend/resume path too. I have just submitted the series, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: fix shutdown hook in case GPU components failed to bind
From: Dmitry Baryshkov
If GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None, only added freedr...@lists.freedesktop.org on Cc
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/msm: Fix suspend/resume on i.MX5
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x1c4/0x1d4)
[ 70.050913] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_suspend+0xb8/0x170)
[ 70.061198] [] (drm_atomic_helper_suspend) from
[] (drm_mode_config_helper_suspend+0x24/0x58)
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_mode_config_helper_suspend/resume()
only when priv->kms is available.
Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM
sleep")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None, only added freedr...@lists.freedesktop.org on Cc
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fd2ac54caf9f..a5c6b8c23336 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1072,6 +1072,10 @@ static int __maybe_unused msm_pm_resume(struct device
*dev)
static int __maybe_unused msm_pm_prepare(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return 0;
return drm_mode_config_helper_suspend(ddev);
}
@@ -1079,6 +1083,10 @@ static int __maybe_unused msm_pm_prepare(struct device
*dev)
static void __maybe_unused msm_pm_complete(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_mode_config_helper_resume(ddev);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: fix out of bounds array access warning
Hi Arnd, On Tue, Mar 23, 2021 at 10:05 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > When CONFIG_OF is disabled, building with 'make W=1' produces warnings > about out of bounds array access: > > drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop': > drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below > array bounds of 'struct clk *[4]' [-Werror=array-bounds] What about making the driver depend on OF instead (like it is done in DRM_IMX_HDMI) ? --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -27,7 +27,7 @@ config DRM_IMX_TVE config DRM_IMX_LDB tristate "Support for LVDS displays" - depends on DRM_IMX && MFD_SYSCON + depends on DRM_IMX && MFD_SYSCON && OF depends on COMMON_CLK select DRM_PANEL help ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On Sat, Jan 16, 2021 at 9:49 AM Oliver Graute wrote: > > power-supply = <®_touch_3v3> is not correct, as the reg_touch_3v3 > > does not power the LCD. > > yes, but how is the LCD correctly powered then? J4 is powered by VCC_5V and VCC_3V#. > [7.795980] pwm-backlight backlight: supply power not found, using dummy > regulator > [7.804436] OF: /backlight: #pwm-cells = 3 found -1 > [7.806563] of_pwm_get(): can't parse "pwms" property > [7.812026] pwm-backlight backlight: unable to request PWM > [7.822929] pwm-backlight: probe of backlight failed with error -22 You need to fix this. > [7.876831] imx-sdma 20ec000.sdma: Direct firmware load for > imx/sdma/sdma-imx6q.bin failed with error -2 > [7.884231] imx-sdma 20ec000.sdma: Falling back to sysfs fallback for: > imx/sdma/sdma-imx6q.bin > [7.916013] printk: console [ttymxc0] enabled > [7.916013] printk: console [ttymxc0] enabled > [7.922351] printk: bootconsole [ec_imx6q0] disabled > [7.922351] printk: bootconsole [ec_imx6q0] disabled > [7.952397] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 68, base_baud > = 500) is a IMX > [7.970794] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 69, base_baud > = 500) is a IMX > [8.033015] [ cut here ] > [8.037826] WARNING: CPU: 0 PID: 1 at > ../drivers/gpu/drm/panel/panel-simple.c:577 panel_simple_probe+0x5dc/0x6b8 And this too > [8.846104] imx6ul-pinctrl 20e.pinctrl: pin MX6UL_PAD_NAND_CE0_B > already requested by regulator-gpio; cannot claim for 1806000.nand-controller > [8.859641] imx6ul-pinctrl 20e.pinctrl: pin-107 > (1806000.nand-controller) status -22 > [8.867851] imx6ul-pinctrl 20e.pinctrl: could not request pin 107 > (MX6UL_PAD_NAND_CE0_B) from group gpminandgrp on device 20e.pinctrl > [8.880930] gpmi-nand 1806000.nand-controller: Error applying setting, > reverse things back > [8.889726] gpmi-nand: probe of 1806000.nand-controller failed with error > -22 And this pin conflict too. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
Adding some more folks in case anyone has any suggestions to fix this reboot hang. Thanks On Tue, Jan 12, 2021 at 5:07 PM Fabio Estevam wrote: > > Hi, > > I have noticed that on an imx53-qsb, it is no longer possible to > reboot the system as it fails like this: > > Requesting system reboot > [ 23.819116] cfg80211: failed to load regulatory.db > [ 23.827569] imx-sdma 63fb.sdma: external firmware not found, > using ROM firmware > [ 23.956838] ci_hdrc ci_hdrc.0: remove, state 1 > [ 23.968029] usb usb1: USB disconnect, device number 1 > [ 23.976033] usb 1-1: USB disconnect, device number 2 > [ 24.234253] ci_hdrc ci_hdrc.0: USB bus 1 deregistered > [ 24.268964] 8<--- cut here --- > [ 24.274602] Unable to handle kernel NULL pointer dereference at > virtual address > [ 24.283434] pgd = (ptrval) > [ 24.286387] [] *pgd=ca212831 > [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM > [ 24.295609] Modules linked in: > [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted > 5.11.0-rc2-next-20210111 #333 > [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support) > [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c > [ 24.317743] LR is at commit_tail+0xa4/0x1b0 > [ 24.322032] pc : []lr : []psr: 6013 > [ 24.328374] sp : c28d1d50 ip : c23a3000 fp : > [ 24.333670] r10: c2816780 r9 : c12d71c0 r8 : c17fb018 > [ 24.338967] r7 : c23a3000 r6 : c2816780 r5 : r4 : > [ 24.345572] r3 : c24c2c00 r2 : c23a3000 r1 : c0769b24 r0 : > [ 24.352177] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > none > [ 24.359407] Control: 10c5387d Table: 72858019 DAC: 0051 > [ 24.365220] Process init (pid: 197, stack limit = 0x(ptrval)) > [ 24.371052] Stack: (0xc28d1d50 to 0xc28d2000) > [ 24.375508] 1d40: > 9682f000 0005 > [ 24.383794] 1d60: 3031e53d 0dc0 c0f816d8 c23a3000 > c23a3000 c17fb018 > [ 24.392079] 1d80: c12d71c0 c2816780 c06db0b4 a5f7faba > 0005 c2816780 > [ 24.400363] 1da0: c23a3000 c17fb018 c12d71c0 > c24c20a0 c06dbed0 > [ 24.408647] 1dc0: c2816780 c23a349c c2816780 > c28d1dfc c23a34a4 c06db604 > [ 24.416932] 1de0: c23a3000 c1609388 c12ba9dc c17fb018 > c06db704 c2965e80 c2965e80 > [ 24.425214] 1e00: 0008 0001 c175f454 > c175f458 c1c669cc > [ 24.433498] 1e20: c12bebb8 0001 0008 > c23a32ec c23a32ec > [ 24.441783] 1e40: 433f193b c24c2014 c24c2014 c24c2010 > c17674c8 c1e68bec c07c76e8 > [ 24.450067] 1e60: c16158d8 c1609388 fee1dead > c28d 0058 c0153730 > [ 24.458350] 1e80: 01234567 c01539d4 fffe > > [ 24.466633] 1ea0: > c1609388 > [ 24.474917] 1ec0: c29663c8 c0e17954 e000 > 0001 > [ 24.483200] 1ee0: c1609388 c1609388 c16093d4 433f193b > c1581584 e000 1ea51000 > [ 24.491485] 1f00: 0001 0080 c1609388 c1609794 c29663c8 > c0e17954 > [ 24.499769] 1f20: c1609388 c1609388 > c16093d4 c1609388 > [ 24.508054] 1f40: c29663c8 c0183f24 c2965e80 c1609388 0001 > c1609794 c2995090 c018ce7c > [ 24.516337] 1f60: 0001 c2995080 c0136e80 c010012c > 0001 c158b21c c0e22334 > [ 24.524622] 1f80: c158b21c c010019c c1609794 433f193b > beefefd4 0001 0058 > [ 24.532907] 1fa0: c0100264 c0100080 beefefd4 fee1dead > 28121969 01234567 > [ 24.541191] 1fc0: beefefd4 0001 0058 > b6f1ef74 > [ 24.549476] 1fe0: 000d7298 beefed40 00091a48 b6e8894c 6010 > fee1dead > [ 24.557742] [] (msm_atomic_commit_tail) from [] > (commit_tail+0xa4/0x1b0) > [ 24.566349] [] (commit_tail) from [] > (drm_atomic_helper_commit+0x154/0x188) > [ 24.575193] [] (drm_atomic_helper_commit) from > [] (drm_atomic_helper_disable_all+0x154/0x1c0) > [ 24.585599] [] (drm_atomic_helper_disable_all) from > [] (drm_atomic_helper_shutdown+0x94/0x12c) > [ 24.596094] [] (drm_atomic_helper_shutdown) from > [] (device_shutdown+0x118/0x250) > [ 24.605475] [] (device_shutdown) from [] > (kernel_restart+0xc/0x68) > [ 24.613574] [] (kernel_restart) from [] > (__do_sys_reboot+0x144/0x200) > [ 24.621915] [] (__do_sys_reboot) from [] > (ret_fast_syscall+0x0/0x2c) > [ 24.630160] Exception stack(0xc28d1fa8 to 0x
Re: Reboot crash at msm_atomic_commit_tail
On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote: > > Adding some more folks in case anyone has any suggestions to fix this > reboot hang. Not sure if this is a valid fix, but the change below makes reboot works correctly. kmscube still works. --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -207,8 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) struct msm_kms *kms = priv->kms; struct drm_crtc *async_crtc = NULL; unsigned crtc_mask = get_crtc_mask(state); - bool async = kms->funcs->vsync_time && - can_do_async(state, &async_crtc); + bool async; + + if (!kms) + return; + + async = kms->funcs->vsync_time && can_do_async(state, &async_crtc); trace_msm_atomic_commit_tail_start(async, crtc_mask); Any comments? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: ipuv3-plane: do not advertise YUV formats on planes without CSC
Hi Phillip, On Tue, Jan 19, 2021 at 11:08 AM Philipp Zabel wrote: > > Only planes that are displayed via the Display Processor (DP) path > support color space conversion. Limit formats on planes that are > shown via the direct Display Controller (DC) path to RGB. > > Reported-by: Fabio Estevam > Signed-off-by: Philipp Zabel With the IPU workaround you sent yesterday, I am able to play video with the correct colors. If I don't apply that patch and only apply this one, then the Gstreamer pipeline does not start: # gst-launch-1.0 filesrc -v location=/media/clip.mp4 ! qtdemux ! h264parse ! v4l2h264dec ! video/x-raw,format=NV12 ! kmssink Setting pipeline to PAUSED ... [ 14.836438] msm msm: [drm:adreno_request_fw] loaded qcom/yamato_pm4.fw from new location [ 14.847716] msm msm: [drm:adreno_request_fw] loaded qcom/yamato_pfp.fw from new location [ 16.103923] random: crng init done Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 1024 /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 576 WARNING: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Delayed linking failed. Additional debug info: gst/parse/grammar.y(540): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0: failed delayed linking some pad of GstQTDemux named qtdemux0 to some pad of GstH264Parse named h264parse0 ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Internal data stream error. Additional debug info: ../gst/isomp4/qtdemux.c(6545): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0: streaming stopped, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Any ideas? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
Hi Rob, On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote: > > I suppose we should do the drm_atomic_helper_shutdown() conditionally? This suggestion works, thanks. I will submit a patch shortly. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Call shutdown conditionally
Calling the drm_atomic_helper_shutdown() on i.MX5 leads to
the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Call shutdown conditionally
01 000d7b54 0004 0004 0020 00d20410 00d20284 [ 70.166083] ffe0: 000d7258 be831960 0001b93c b6ee97a0 [ 70.171156] Code: 1592208c 1184421c e153 1af8 (e595c000) [ 70.177483] ---[ end trace 2775110cb98281db ]--- > feel like follow up patch to push this into the helpers with a > DRIVER_MODESET check like I described would be kinda neat. I tried using use drm_core_check_feature(dev, DRIVER_MODESET), but since the drivers/gpu/drm/imx/imx-drm-core.c also sets the DRIVER_MODESET flag, I am not sure how we can differentiate the fact that imx5 is not running on a Qualcomm display driver. Just to be clear: would it be OK to proceed with this original patch as a minimum fix so that it can reach upstream and also stable-trees (5.4 and 5.10)? I am glad to work on a more generic solution that would also fix the suspend/resume case. Just need some more guidance on that as I am not familiar with this area. Thanks, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: Call shutdown conditionally
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Explain in the commit log that the problem happens after a 'reboot' command.
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: Call shutdown conditionally
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Explain in the commit log that the problem happens after a 'reboot' command.
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/msm: Call suspend/resume conditionally
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x1c4/0x1d4)
[ 70.050913] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_suspend+0xb8/0x170)
[ 70.061198] [] (drm_atomic_helper_suspend) from
[] (drm_mode_config_helper_suspend+0x24/0x58)
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_mode_config_helper_suspend/resume()
conditionally.
Cc:
Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM
sleep")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Newly introduced in this series.
drivers/gpu/drm/msm/msm_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c082b72b9e3b..0d1a94e06912 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1072,14 +1072,17 @@ static int __maybe_unused msm_pm_prepare(struct device
*dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- return drm_mode_config_helper_suspend(ddev);
+ if (of_device_get_match_data(dev))
+ return drm_mode_config_helper_suspend(ddev);
+ return 0;
}
static void __maybe_unused msm_pm_complete(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- drm_mode_config_helper_resume(ddev);
+ if (of_device_get_match_data(dev))
+ drm_mode_config_helper_resume(ddev);
}
static const struct dev_pm_ops msm_pm_ops = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
Hi Jani,
On Thu, Jan 21, 2021 at 8:22 AM Jani Nikula wrote:
> Sean, Rob, or anyone with an arm toolchain for msm available, could I
> trouble you to build test this please?
I tried to build after applying your patch:
CC drivers/gpu/drm/msm/dp/dp_ctrl.o
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function ‘dp_ctrl_use_fixed_nvid’:
drivers/gpu/drm/msm/dp/dp_ctrl.c:1429:11: error: too few arguments to
function ‘drm_dp_has_quirk’
1429 | return (drm_dp_has_quirk(&ctrl->panel->desc,
| ^~~~
In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:15:
./include/drm/drm_dp_helper.h:2101:1: note: declared here
2101 | drm_dp_has_quirk(const struct drm_dp_desc *desc, u32 edid_quirks,
| ^~~~
make[4]: *** [scripts/Makefile.build:287:
drivers/gpu/drm/msm/dp/dp_ctrl.o] Error 1
make[3]: *** [scripts/Makefile.build:530: drivers/gpu/drm/msm] Error 2
make[2]: *** [scripts/Makefile.build:530: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:530: drivers/gpu] Error 2
make: *** [Makefile:1819: drivers] Error 2
I had to add the extra parameter like this:
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
{
u8 *dpcd = ctrl->panel->dpcd;
- u32 edid_quirks = 0;
- edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
/*
* For better interop experience, used a fixed NVID=0x8000
* whenever connected to a VGA dongle downstream.
*/
if (drm_dp_is_branch(dpcd))
- return (drm_dp_has_quirk(&ctrl->panel->desc, edid_quirks,
- DP_DPCD_QUIRK_CONSTANT_N));
+ return (drm_dp_has_quirk(&ctrl->panel->desc, 0,
+DP_DPCD_QUIRK_CONSTANT_N));
return false;
}
and then it builds.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, Jan 21, 2021 at 8:41 AM Jani Nikula wrote: > On top of what? Current drm-tip? It was on top of next-20210121. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, Jan 21, 2021 at 9:10 AM Jani Nikula wrote: > Kinda catch-22 because next has dropped current drm-intel-next because > it doesn't build because of the issue this patch fixes. ;) Ok, so I built drm-intel-next and I was able to reproduce the buid error as reported by Stephen. Applied this patch and it builds fine now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node.
Hi Oleksij, On Thu, Jan 21, 2021 at 3:12 AM Oleksij Rempel wrote: > > At some point PWM cell count was changed, but it didn't triggered any It changed in this commit: commit fa28d8212ede9c533ae87a737571a9d3b3eebb29 Author: Uwe Kleine-König Date: Fri Jul 10 07:19:37 2020 +0200 ARM: dts: imx: default to #pwm-cells = <3> in the SoC dtsi files The imx-pwm driver supports 3 cells and this is the more flexible setting. So use it by default and overwrite it back to two for the files that reference the PWMs with just 2 cells to minimize changes. This allows to drop explicit setting to 3 cells for the boards that already depend on this. The boards that are now using 2 cells explicitly can be converted to 3 individually. Signed-off-by: Uwe Kleine-König Signed-off-by: Shawn Guo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 6:29 PM Oliver Graute wrote: > Ok I fixed the pin conflict with regulator-gpio and added a 5V > regulator node in my dts file. Now the display is working fine! That's good news :-) > I'll post the dts files soon and check if there is something to > improve for this patch. Did the panel patch I sent earlier work? https://pastebin.com/raw/diTMVsh8 If it does, I can send it formally if you want. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 7:17 PM Oliver Graute wrote: > I would prefer mine, because I got a wrong colored penguin on bootup > with yours :-) I have originally passed .bpc = 8, but looking at the panel datasheet, this should be: .bpc = 6 instead. In your patch, you pass the timing parameters three times, but they are all the same. Usually, it is meant to be: minimal, typical, maximum values. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/msm: Call shutdown conditionally
Hi Rob,
Any comments on this series, please?
On Tue, Jan 19, 2021 at 8:15 PM Fabio Estevam wrote:
>
> Issuing a 'reboot' command in i.MX5 leads to the following flow:
>
> [ 24.557742] [] (msm_atomic_commit_tail) from []
> (commit_tail+0xa4/0x1b0)
> [ 24.566349] [] (commit_tail) from []
> (drm_atomic_helper_commit+0x154/0x188)
> [ 24.575193] [] (drm_atomic_helper_commit) from
> [] (drm_atomic_helper_disable_all+0x154/0x1c0)
> [ 24.585599] [] (drm_atomic_helper_disable_all) from
> [] (drm_atomic_helper_shutdown+0x94/0x12c)
> [ 24.596094] [] (drm_atomic_helper_shutdown) from
>
> In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
> of the Qualcomm display controllers), causing a NULL pointer
> dereference in msm_atomic_commit_tail():
>
> [ 24.268964] 8<--- cut here ---
> [ 24.274602] Unable to handle kernel NULL pointer dereference at
> virtual address
> [ 24.283434] pgd = (ptrval)
> [ 24.286387] [] *pgd=ca212831
> [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
> [ 24.295609] Modules linked in:
> [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted
> 5.11.0-rc2-next-20210111 #333
> [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
> [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
> [ 24.317743] LR is at commit_tail+0xa4/0x1b0
>
> Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
>
> Cc:
> Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
> platform_driver")
> Suggested-by: Rob Clark
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Explain in the commit log that the problem happens after a 'reboot' command.
>
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 108c405e03dd..c082b72b9e3b 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
> *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
>
> - drm_atomic_helper_shutdown(drm);
> + if (get_mdp_ver(pdev))
> + drm_atomic_helper_shutdown(drm);
> }
>
> static const struct of_device_id dt_match[] = {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver,
On Tue, Feb 2, 2021 at 2:35 PM Oliver Graute wrote:
> +static const struct panel_desc sgd_gktw70sdad1sd = {
> + .timings = &sgd_gktw70sdad1sd_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 153,
> + .height = 86,
> + },
> + .delay = {
> + .prepare = 20 + 20 + 10 + 10,
Adding the datasheet label like Marco suggested make it clearer where
these numbers come from : /* T0 + T2 + T3 + T4 */
Glad you got it working on your imx6ul board:
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/msm: Call shutdown conditionally
Gentle ping...
On Fri, Jan 29, 2021 at 8:09 AM Fabio Estevam wrote:
>
> Hi Rob,
>
> Any comments on this series, please?
>
> On Tue, Jan 19, 2021 at 8:15 PM Fabio Estevam wrote:
> >
> > Issuing a 'reboot' command in i.MX5 leads to the following flow:
> >
> > [ 24.557742] [] (msm_atomic_commit_tail) from []
> > (commit_tail+0xa4/0x1b0)
> > [ 24.566349] [] (commit_tail) from []
> > (drm_atomic_helper_commit+0x154/0x188)
> > [ 24.575193] [] (drm_atomic_helper_commit) from
> > [] (drm_atomic_helper_disable_all+0x154/0x1c0)
> > [ 24.585599] [] (drm_atomic_helper_disable_all) from
> > [] (drm_atomic_helper_shutdown+0x94/0x12c)
> > [ 24.596094] [] (drm_atomic_helper_shutdown) from
> >
> > In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
> > of the Qualcomm display controllers), causing a NULL pointer
> > dereference in msm_atomic_commit_tail():
> >
> > [ 24.268964] 8<--- cut here ---
> > [ 24.274602] Unable to handle kernel NULL pointer dereference at
> > virtual address
> > [ 24.283434] pgd = (ptrval)
> > [ 24.286387] [] *pgd=ca212831
> > [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
> > [ 24.295609] Modules linked in:
> > [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted
> > 5.11.0-rc2-next-20210111 #333
> > [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
> > [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
> > [ 24.317743] LR is at commit_tail+0xa4/0x1b0
> >
> > Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
> >
> > Cc:
> > Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
> > platform_driver")
> > Suggested-by: Rob Clark
> > Signed-off-by: Fabio Estevam
> > ---
> > Changes since v1:
> > - Explain in the commit log that the problem happens after a 'reboot'
> > command.
> >
> > drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 108c405e03dd..c082b72b9e3b 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
> > *pdev)
> > {
> > struct drm_device *drm = platform_get_drvdata(pdev);
> >
> > - drm_atomic_helper_shutdown(drm);
> > + if (get_mdp_ver(pdev))
> > + drm_atomic_helper_shutdown(drm);
> > }
> >
> > static const struct of_device_id dt_match[] = {
> > --
> > 2.25.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: ipu-v3: use swap()
Hi Salah,
On Tue, Jul 13, 2021 at 10:33 AM Salah Triki wrote:
>
> Use swap() instead of implementing it since it makes code more clean.
s/more clean/cleaner
> Signed-off-by: Salah Triki
> ---
> drivers/gpu/ipu-v3/ipu-image-convert.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
> b/drivers/gpu/ipu-v3/ipu-image-convert.c
> index aa1d4b6d278f..5f730cd6009d 100644
> --- a/drivers/gpu/ipu-v3/ipu-image-convert.c
> +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
> @@ -1021,11 +1021,8 @@ static int calc_tile_offsets_planar(struct
> ipu_image_convert_ctx *ctx,
>
> u_off = y_size - y_off + uv_off;
> v_off = (fmt->uv_packed) ? 0 : u_off + uv_size;
> - if (fmt->uv_swapped) {
> - tmp = u_off;
> - u_off = v_off;
> - v_off = tmp;
The 'tmp' variable seems to be unused now, so its declaration should be removed.
Thanks
Re: [PATCH] drm/msm/gpu: Fix crash on devices without devfreq support (v2)
On Tue, Mar 8, 2022 at 3:48 PM Rob Clark wrote: > > From: Rob Clark > > Avoid going down devfreq paths on devices where devfreq is not > initialized. > > v2: Change has_devfreq() logic [Dmitry] > > Reported-by: Linux Kernel Functional Testing > Reported-by: Anders Roxell > Signed-off-by: Rob Clark Does this need a Fixes tag?
[PATCH] drm/msm: Do not run snapshot on non-DPU devices
Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 3000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012] Unable to handle kernel NULL pointer dereference at virtual address
0028
[ 3.305244] pgd = (ptrval)
[ 3.307989] [0028] *pgd=
[ 3.311624] Internal error: Oops: 805 [#1] SMP ARM
[ 3.316430] Modules linked in:
[ 3.319503] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+g682d702b426b #1
[ 3.326652] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.332754] PC is at __mutex_init+0x14/0x54
[ 3.336969] LR is at msm_disp_snapshot_init+0x24/0xa0
i.MX53 does not use the DPU controller.
Fix the problem by only calling msm_disp_snapshot_init() on platforms that
use the DPU controller.
Cc: sta...@vger.kernel.org
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 2e6fc185e54d..2aa2266454b7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -630,10 +630,11 @@ static int msm_drm_init(struct device *dev, const struct
drm_driver *drv)
if (ret)
goto err_msm_uninit;
- ret = msm_disp_snapshot_init(ddev);
- if (ret)
- DRM_DEV_ERROR(dev, "msm_disp_snapshot_init failed ret = %d\n",
ret);
-
+ if (kms) {
+ ret = msm_disp_snapshot_init(ddev);
+ if (ret)
+ DRM_DEV_ERROR(dev, "msm_disp_snapshot_init failed ret =
%d\n", ret);
+ }
drm_mode_config_reset(ddev);
#ifdef CONFIG_DRM_FBDEV_EMULATION
--
2.25.1
Re: [PATCH v3 3/3] drm/bridge: parade-ps8640: Add support for AUX channel
On Wed, Sep 15, 2021 at 5:41 PM Philip Chen wrote: > As regmap_read() should always read 1 byte at a time, should I just do: > regmap_read(map, PAGE0_SWAUX_RDATA, (unsigned int*)(buf + i)) There is also regmap_bulk_read() if you need to read more data.
Re: [Freedreno] [PATCH] drm/msm: Do not run snapshot on non-DPU devices
Hi Abhinav,
On Wed, Sep 15, 2021 at 11:22 PM wrote:
> Are you not using DPU or are you not using mdp4/mdp5 as well? Even if
> you are using any of mdps, kms should
> not be NULL. Hence wanted to check the test case.
I am running i.MX53, which is an NXP SoC, not Qualcomm's.
It does not use DPU, nor MDP4/5 and kms is NULL in this case.
Some debug prints to confirm:
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -557,18 +557,22 @@ static int msm_drm_init(struct device *dev,
const struct drm_driver *drv)
case KMS_MDP4:
kms = mdp4_kms_init(ddev);
priv->kms = kms;
+ pr_err(" KMS_MDP4\n");
break;
case KMS_MDP5:
kms = mdp5_kms_init(ddev);
+ pr_err(" KMS_MDP5\n");
break;
case KMS_DPU:
kms = dpu_kms_init(ddev);
+ pr_err(" KMS_DPU\n");
priv->kms = kms;
break;
default:
/* valid only for the dummy headless case, where of_node=NULL */
WARN_ON(dev->of_node);
kms = NULL;
+ pr_err(" KMS is NULL\n");
break;
}
# dmesg | grep KMS
[3.153215] KMS is NULL
Re: [Freedreno] [PATCH] drm/msm: Do not run snapshot on non-DPU devices
Hi Abhinav, On Thu, Sep 16, 2021 at 1:15 PM wrote: > > Hi Fabio > > Thanks for confirming. > > Although I have no issues with your change, I am curious why even msm is > probing and/or binding. > Your device tree should not be having any mdp/dpu nodes then. The i.MX53 does have the following GPU node: compatible = "amd,imageon-200.0", "amd,imageon"; That's why it probes the msm driver. However, i.MX53 does not have any of the Qualcomm display controllers. It uses the i.MX IPU display controller instead. Hope that clarifies. Please reply with a Reviewed-by if you are happy with my fix. Thanks
imx_ldb: lockdep warning on 5.14.x
Hi,
I am getting the lockdep warning below on a imx6q-sabred running 5.14.9.
Haven't debugged this yet, but just wanted to report in case someone
has any suggestions.
Thanks,
Fabio Estevam
[4.913294] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops)
[4.921640] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops)
[4.929798] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
ipu_crtc_ops)
[4.937977] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
ipu_crtc_ops)
[4.946850] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops)
[4.954685] imx-drm display-subsystem: bound ldb (ops imx_ldb_ops)
[4.966943] [drm] Initialized imx-drm 1.0.0 20120507 for
display-subsystem on minor 0
[5.001801]
[5.001811] ==
[5.001817] WARNING: possible circular locking dependency detected
[5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: GW
[5.001833] --
[5.001838] kworker/u8:0/7 is trying to acquire lock:
[5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent+0x40/0x294
[5.001903]
[5.001903] but task is already holding lock:
[5.001909] c176df78 (dma_fence_map){}-{0:0}, at:
imx_drm_atomic_commit_tail+0x10/0x160
[5.001957]
[5.001957] which lock already depends on the new lock.
[5.001957]
[5.001963]
[5.001963] the existing dependency chain (in reverse order) is:
[5.001968]
[5.001968] -> #3 (dma_fence_map){}-{0:0}:
[5.001993]dma_resv_lockdep+0x1c4/0x2b8
[5.002010]do_one_initcall+0x84/0x3b8
[5.002026]kernel_init_freeable+0x198/0x22c
[5.002040]kernel_init+0x10/0x128
[5.002061]ret_from_fork+0x14/0x38
[5.002072]0x0
[5.002081]
[5.002081] -> #2 (fs_reclaim){+.+.}-{0:0}:
[5.002105]kmem_cache_alloc+0x28/0x38c
[5.002125]__d_alloc+0x20/0x224
[5.002141]d_alloc+0x10/0x60
[5.002152]d_alloc_parallel+0x48/0xa60
[5.002165]__lookup_slow+0x8c/0x178
[5.002184]lookup_one_len+0x98/0xd8
[5.002196]start_creating+0x94/0x14c
[5.002216]debugfs_create_dir+0x10/0x100
[5.002231]pinctrl_init+0x1c/0xd4
[5.002247]do_one_initcall+0x84/0x3b8
[5.002259]kernel_init_freeable+0x198/0x22c
[5.002271]kernel_init+0x10/0x128
[5.002286]ret_from_fork+0x14/0x38
[5.002296]0x0
[5.002303]
[5.002303] -> #1 (&sb->s_type->i_mutex_key#2){+.+.}-{3:3}:
[5.002335]simple_recursive_removal+0x54/0x33c
[5.002350]debugfs_remove+0x30/0x4c
[5.002364]_regulator_put.part.0+0x30/0x1d8
[5.002383]regulator_put+0x2c/0x3c
[5.002395]release_nodes+0x50/0x190
[5.002415]devres_release_all+0x80/0xd4
[5.002426]really_probe+0xd4/0x314
[5.002438]__driver_probe_device+0x80/0xe4
[5.002449]driver_probe_device+0x30/0xd4
[5.002459]__driver_attach_async_helper+0x20/0x38
[5.002470]async_run_entry_fn+0x20/0xb4
[5.002483]process_one_work+0x2a0/0x7c0
[5.002500]worker_thread+0x30/0x510
[5.002512]kthread+0x154/0x17c
[5.002526]ret_from_fork+0x14/0x38
[5.002537]0x0
[5.002546]
[5.002546] -> #0 (regulator_list_mutex){+.+.}-{3:3}:
[5.002569]lock_acquire+0x13c/0x418
[5.002581]__mutex_lock+0x94/0x97c
[5.002595]mutex_lock_nested+0x1c/0x24
[5.002605]regulator_lock_dependent+0x40/0x294
[5.002622]regulator_enable+0x2c/0xec
[5.002632]panel_simple_resume+0x38/0x1f4
[5.002648]__rpm_callback+0x3c/0x108
[5.002661]rpm_callback+0x68/0x70
[5.002671]rpm_resume+0x604/0x7f4
[5.002681]__pm_runtime_resume+0x64/0x90
[5.002692]panel_simple_prepare+0x2c/0x50
[5.002703]imx_ldb_encoder_enable+0x58/0x2b0
[5.002715]drm_atomic_helper_commit_modeset_enables+0x230/0x26c
[5.002734]imx_drm_atomic_commit_tail+0x3c/0x160
[5.002753]commit_tail+0x9c/0x18c
[5.002766]drm_atomic_helper_commit+0x158/0x18c
[5.002778]drm_client_modeset_commit_atomic+0x23c/0x288
[5.002795]drm_client_modeset_commit_locked+0x60/0x1d0
[5.002806]drm_client_modeset_commit+0x24/0x40
[5.002819]__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc8
[5.002835]drm_fb_helper_set_par+0x38/0x68
[5.002845]fbcon_init+0x2bc/0x550
[5.002862]visual_init+0xbc/0x104
[5.002881]do_bind_con_driver+0x1c8/0x3b0
[5.002896]do_take_over_console+0x134/0x1f0
[5.002910]do_fbcon_takeover+0x60/0xc0
[5.002924]regis
Re: imx_ldb: lockdep warning on 5.14.x
On Sun, Oct 10, 2021 at 12:39 PM Fabio Estevam wrote: > > Hi, > > I am getting the lockdep warning below on a imx6q-sabred running 5.14.9. > > Haven't debugged this yet, but just wanted to report in case someone > has any suggestions. git bisect shows that the guilty commit is: commit f4b34faa08428d813fc3629f882c503487f94a12 Author: Daniel Vetter Date: Thu Jan 21 16:29:55 2021 +0100 drm/imx: Annotate dma-fence critical section in commit path drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup apparrently), so it's the entire function. And a nice comment explaining why the wait_for_flip_done is ahead, unlike the usual sequence. Aside, I think since the atomic helpers do track plane disabling now separately this might no longer be a real problem since: commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648 Author: Maarten Lankhorst Date: Mon Sep 4 12:48:37 2017 +0200 drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3. Plus the subsequent bugfixes of course, this was tricky to get right. Signed-off-by: Daniel Vetter Cc: Philipp Zabel Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Philipp Zabel If I revert this commit on top of 5.14, the lockdep warning is gone. Daniel, How do we fix this? Thanks
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Tommaso, On Sat, Jan 15, 2022 at 8:23 PM Tommaso Merciai wrote: > Hi Fabio, > I'm working on bring up urt,umsh-8596md-20t lvds kit panel, but after enable > following node I get the following error: I assume you are trying to connect an external panel via connector CN3. This connector is for LVDS panel, not parallel. The eLCDIF parallel interface is connected to the TDA19988. Anyway, this is a different topic. My goal here is to fix the kernel warning when using the TDA19988 HDMI output. Thanks
Re: [PATCH 01/31] gpu: nouveau: nouveau_led: changing LED_FULL to actual value
Hi Luiz, On Sat, Jan 22, 2022 at 7:44 AM Luiz Sampaio wrote: > > The enum led_brightness, which contains the declaration of LED_OFF, > LED_ON, LED_HALF and LED_FULL is obsolete, as the led class now supports > max_brightness. Your Signed-off-by tag is missing. Please run ./scripts/checkpatch.pl on your patch and it helps detect this kind of issue. Regards, Fabio Estevam
Re: [PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
On Wed, Jan 26, 2022 at 5:25 PM Peter Geis wrote: > + > + ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE); > + if (ret) > + dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate: > %d\n", ret); You are setting the cec clock rate after it has been enabled, which can be glitchy. Better to set the rate prior to enabling the clock.
kmscube: GLES3/gl3.h: No such file or directory
Hi Rob, We are getting the following kmscube build error in Buildroot: ../cube-shadertoy.c:37:10: fatal error: GLES3/gl3.h: No such file or directory 37 | #include Complete log: http://autobuild.buildroot.net/results/7f559e89a96273fc019056eae13104e14161a484/build-end.log In OpenEmbedded the following patch is used: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/kmscube/kmscube/0001-texturator-Use-correct-GL-extension-header.patch?h=master What would be the appropriate fix for this issue? Thanks, Fabio Estevam
Re: Kconfig CONFIG_FB dependency regression
Hi Thinh,
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap wrote:
>
> On 2/1/22 15:01, Thinh Nguyen wrote:
> > Hi,
> >
> > One of our test setups is unable to boot (stuck at initramfs). Git
> > bisection points to the commit below:
> >
> > f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> >
> > Reverting this patch resolves the issue. This issue persists in mainline
> > also. Unfortunately there isn't any meaningful log. Hopefully someone
> > can give some insight as to what could be the issue and revert/fix this
> > issue.
>
> Hi,
> Did you enable DRM_FBDEV_EMULATION?
> Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
We had to manually select this option in imx_v6_v7_defconfig after f611b1e7624c.
Please see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.17-rc2&id=c54467482ffd407a4404c990697f432bfcb6cdc4
[PATCH] Revert "drm/imx: Annotate dma-fence critical section in commit path"
This reverts commit f4b34faa08428d813fc3629f882c503487f94a12.
Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in
commit path") the following possible circular dependency is detected:
[5.001811] ==
[5.001817] WARNING: possible circular locking dependency detected
[5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: GW
[5.001833] --
[5.001838] kworker/u8:0/7 is trying to acquire lock:
[5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent+0x40/0x294
[5.001903]
[5.001903] but task is already holding lock:
[5.001909] c176df78 (dma_fence_map){}-{0:0}, at:
imx_drm_atomic_commit_tail+0x10/0x160
[5.001957]
[5.001957] which lock already depends on the new lock.
...
Revert it for now.
Tested on a imx6q-sabresd.
Fixes: f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit
path")
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 9558e9e1b431..cb685fe2039b 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -81,7 +81,6 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_plane_state *old_plane_state, *new_plane_state;
bool plane_disabling = false;
int i;
- bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -112,7 +111,6 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
}
drm_atomic_helper_commit_hw_done(state);
- dma_fence_end_signalling(fence_cookie);
}
static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers =
{
--
2.25.1
Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver
Hi Jagan, On Mon, Nov 22, 2021 at 11:21 AM Jagan Teki wrote: > Is this with Bridge or normal DSI panel? According to the log shared by Marek, the dts being used is: arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts which includes arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi. In this dtsi there is a "sil,sii8620" bridge.
Re: [PATCH 1/2] dt-bindings: display: bridge: Add TI DLPC3433 bindings
Hi Jagan, On Wed, Nov 24, 2021 at 2:26 PM Jagan Teki wrote: > > TI DLPC3433 is a MIPI DSI based display controller bridge > for processing high resolution DMD based projectors. > > It has a flexible configuration of MIPI DSI signal input > produces RGB565, RGB666, RGB888 output format with maximum > of 720p resolution in 60 and 120 Hz refresh rates. > > Add dt-bingings for it. > > Signed-off-by: Christopher Vollo > Signed-off-by: Jagan Teki > --- > .../bindings/display/bridge/ti,dlpc3433.yaml | 112 ++ > MAINTAINERS | 6 + Shouldn't the MAINTAINERS change be part of patch 2/2 instead?
[PATCH libdrm] tests/util: Add mxsfb-drm driver
Add an entry for the "mxsfb-drm" driver, so that the test utilities
work with the mxsfb driver without passing the -M argument.
Signed-off-by: Fabio Estevam
---
tests/util/kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index 08b48fe585b7..39a93866a9d1 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -149,6 +149,7 @@ static const char * const modules[] = {
"armada-drm",
"komeda",
"imx-dcss",
+ "mxsfb-drm",
};
int util_open(const char *device, const char *module)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute wrote: > > On 19/12/20, Oliver Graute wrote: > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > > to panel-simple. > > > > The panel spec from Variscite can be found at: > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf > > some clue what bus_format and bus_flags I have to use? > > [ 42.505156] panel-simple panel-lcd: Specify missing bus_flags > [ 42.511090] panel-simple panel-lcd: Specify missing bus_format > [ 42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 Does this patch work? https://pastebin.com/raw/diTMVsh8 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute wrote: > the first two errors are gone. But I still get this: > > [ 42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 > > The panel is still off perhaps I miss something else. Some suggestions: - Take a look at arch/arm/boot/dts/imx6ul-14x14-evk.dtsi as a reference as it has display functional - Use imx_v6_v7_defconfig to make sure all the required drivers are selected - If it still does not work, share the dts and schematics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On Sun, Jan 10, 2021 at 5:09 PM Oliver Graute wrote: > here the schematics and my dts. The board is using a LVDS connector for > the display. The schematics shows the GKTW70SDAD1SD panel in the J4 connector, not the LVDS J7 connector. > https://www.variscite.de/wp-content/uploads/2017/12/VAR-6ULCustomboard-Schematics.pdf > https://lore.kernel.org/linux-arm-kernel/1610144511-19018-3-git-send-email-oliver.gra...@gmail.com/ As I mentioned earlier you should remove the display timings from the dts when using the compatible string for the panel. power-supply = <®_touch_3v3> is not correct, as the reg_touch_3v3 does not power the LCD. Another hint is to use the PLL5_VIDEO as the clock source for the lcdif controller as done in the imx6ul evk dtsi. It would also help if you could share the complete boot log. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bit
Hi Geert, On Mon, Jan 11, 2021 at 10:02 AM Geert Uytterhoeven wrote: > > As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 10L, the second > multiplication in > > dsi->lanes * 8 * NSEC_PER_SEC > > will overflow on a 32-bit platform. Fix this by making the constant > unsigned long long, forcing 64-bit arithmetic. > > While iMX8 is arm64, this driver is currently used on 64-bit platforms > only, where long is 64-bit, so this cannot happen. But the issue may > start to happen when the driver is reused for a 32-bit SoC, or when code > is copied for a new driver. This IP is also present on i.MX7ULP, which is 32-bit, but not supported yet. Thanks for taking care of this. Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reboot crash at msm_atomic_commit_tail
Hi, I have noticed that on an imx53-qsb, it is no longer possible to reboot the system as it fails like this: Requesting system reboot [ 23.819116] cfg80211: failed to load regulatory.db [ 23.827569] imx-sdma 63fb.sdma: external firmware not found, using ROM firmware [ 23.956838] ci_hdrc ci_hdrc.0: remove, state 1 [ 23.968029] usb usb1: USB disconnect, device number 1 [ 23.976033] usb 1-1: USB disconnect, device number 2 [ 24.234253] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 24.268964] 8<--- cut here --- [ 24.274602] Unable to handle kernel NULL pointer dereference at virtual address [ 24.283434] pgd = (ptrval) [ 24.286387] [] *pgd=ca212831 [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM [ 24.295609] Modules linked in: [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111 #333 [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support) [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c [ 24.317743] LR is at commit_tail+0xa4/0x1b0 [ 24.322032] pc : []lr : []psr: 6013 [ 24.328374] sp : c28d1d50 ip : c23a3000 fp : [ 24.333670] r10: c2816780 r9 : c12d71c0 r8 : c17fb018 [ 24.338967] r7 : c23a3000 r6 : c2816780 r5 : r4 : [ 24.345572] r3 : c24c2c00 r2 : c23a3000 r1 : c0769b24 r0 : [ 24.352177] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 24.359407] Control: 10c5387d Table: 72858019 DAC: 0051 [ 24.365220] Process init (pid: 197, stack limit = 0x(ptrval)) [ 24.371052] Stack: (0xc28d1d50 to 0xc28d2000) [ 24.375508] 1d40: 9682f000 0005 [ 24.383794] 1d60: 3031e53d 0dc0 c0f816d8 c23a3000 c23a3000 c17fb018 [ 24.392079] 1d80: c12d71c0 c2816780 c06db0b4 a5f7faba 0005 c2816780 [ 24.400363] 1da0: c23a3000 c17fb018 c12d71c0 c24c20a0 c06dbed0 [ 24.408647] 1dc0: c2816780 c23a349c c2816780 c28d1dfc c23a34a4 c06db604 [ 24.416932] 1de0: c23a3000 c1609388 c12ba9dc c17fb018 c06db704 c2965e80 c2965e80 [ 24.425214] 1e00: 0008 0001 c175f454 c175f458 c1c669cc [ 24.433498] 1e20: c12bebb8 0001 0008 c23a32ec c23a32ec [ 24.441783] 1e40: 433f193b c24c2014 c24c2014 c24c2010 c17674c8 c1e68bec c07c76e8 [ 24.450067] 1e60: c16158d8 c1609388 fee1dead c28d 0058 c0153730 [ 24.458350] 1e80: 01234567 c01539d4 fffe [ 24.466633] 1ea0: c1609388 [ 24.474917] 1ec0: c29663c8 c0e17954 e000 0001 [ 24.483200] 1ee0: c1609388 c1609388 c16093d4 433f193b c1581584 e000 1ea51000 [ 24.491485] 1f00: 0001 0080 c1609388 c1609794 c29663c8 c0e17954 [ 24.499769] 1f20: c1609388 c1609388 c16093d4 c1609388 [ 24.508054] 1f40: c29663c8 c0183f24 c2965e80 c1609388 0001 c1609794 c2995090 c018ce7c [ 24.516337] 1f60: 0001 c2995080 c0136e80 c010012c 0001 c158b21c c0e22334 [ 24.524622] 1f80: c158b21c c010019c c1609794 433f193b beefefd4 0001 0058 [ 24.532907] 1fa0: c0100264 c0100080 beefefd4 fee1dead 28121969 01234567 [ 24.541191] 1fc0: beefefd4 0001 0058 b6f1ef74 [ 24.549476] 1fe0: 000d7298 beefed40 00091a48 b6e8894c 6010 fee1dead [ 24.557742] [] (msm_atomic_commit_tail) from [] (commit_tail+0xa4/0x1b0) [ 24.566349] [] (commit_tail) from [] (drm_atomic_helper_commit+0x154/0x188) [ 24.575193] [] (drm_atomic_helper_commit) from [] (drm_atomic_helper_disable_all+0x154/0x1c0) [ 24.585599] [] (drm_atomic_helper_disable_all) from [] (drm_atomic_helper_shutdown+0x94/0x12c) [ 24.596094] [] (drm_atomic_helper_shutdown) from [] (device_shutdown+0x118/0x250) [ 24.605475] [] (device_shutdown) from [] (kernel_restart+0xc/0x68) [ 24.613574] [] (kernel_restart) from [] (__do_sys_reboot+0x144/0x200) [ 24.621915] [] (__do_sys_reboot) from [] (ret_fast_syscall+0x0/0x2c) [ 24.630160] Exception stack(0xc28d1fa8 to 0xc28d1ff0) [ 24.635315] 1fa0: beefefd4 fee1dead 28121969 01234567 [ 24.643600] 1fc0: beefefd4 0001 0058 b6f1ef74 [ 24.651867] 1fe0: 000d7298 beefed40 00091a48 b6e8894c [ 24.657025] Code: 1592208c 1185521c e153 1af8 (e5942000) [ 24.663681] ---[ end trace 9a1e129deec83f42 ]--- [ 25.670432] Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 25.678331] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x ]--- It happens on 5.4 as well as 5.11-rc2. Any ideas? Thanks, Fabio Este
[PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.
Based on Laurent's commit a6ea7d268a63("drm: bridge: ti-sn65dsi83:
Switch to atomic operations").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/i2c/tda998x_drv.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b7ec6c374fbd..adaa985af87e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1395,7 +1395,8 @@ static enum drm_mode_status
tda998x_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void tda998x_bridge_enable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1413,7 +1414,8 @@ static void tda998x_bridge_enable(struct drm_bridge
*bridge)
}
}
-static void tda998x_bridge_disable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1680,9 +1682,9 @@ static const struct drm_bridge_funcs tda998x_bridge_funcs
= {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
.mode_valid = tda998x_bridge_mode_valid,
- .disable = tda998x_bridge_disable,
+ .atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
- .enable = tda998x_bridge_enable,
+ .atomic_enable = tda998x_bridge_atomic_enable,
};
/* I2C driver functions */
--
2.25.1
[PATCH 2/2] drm/i2c/tda998x: Implement atomic_get_input_bus_fmts
Implement the .atomic_get_input_bus_fmts callback to let the bridge
indicate the pixel format it requires on the parallel bus to the LCDIF.
Based on Marek's commit db8b7ca5b232 ("drm/bridge: ti-sn65dsi83: Replace
connector format patching with atomic_get_input_bus_fmts").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/i2c/tda998x_drv.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index adaa985af87e..d987481e97c1 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1678,6 +1678,31 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
mutex_unlock(&priv->audio_mutex);
}
+#define MAX_INPUT_SEL_FORMATS 1
+
+static u32 *
+tda998x_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
@@ -1685,6 +1710,10 @@ static const struct drm_bridge_funcs
tda998x_bridge_funcs = {
.atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
.atomic_enable = tda998x_bridge_atomic_enable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = tda998x_atomic_get_input_bus_fmts,
};
/* I2C driver functions */
--
2.25.1
[PATCH v2 1/2] drm/i2c/tda998x: Switch to atomic operations
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.
Based on Laurent's commit a6ea7d268a63("drm: bridge: ti-sn65dsi83:
Switch to atomic operations").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Laurent Pinchart
---
Changes since v1:
- Move .atomic_duplicate_state,.atomic_destroy_state .atomic_reset from
patch 2/2 to 1/2. (Laurent)
drivers/gpu/drm/i2c/tda998x_drv.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b7ec6c374fbd..45d52b8a4026 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1395,7 +1395,8 @@ static enum drm_mode_status
tda998x_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void tda998x_bridge_enable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1413,7 +1414,8 @@ static void tda998x_bridge_enable(struct drm_bridge
*bridge)
}
}
-static void tda998x_bridge_disable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1680,9 +1682,12 @@ static const struct drm_bridge_funcs
tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
.mode_valid = tda998x_bridge_mode_valid,
- .disable = tda998x_bridge_disable,
+ .atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
- .enable = tda998x_bridge_enable,
+ .atomic_enable = tda998x_bridge_atomic_enable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
};
/* I2C driver functions */
--
2.25.1
[PATCH v2 2/2] drm/i2c/tda998x: Implement atomic_get_input_bus_fmts
Implement the .atomic_get_input_bus_fmts callback to let the bridge
indicate the pixel format it requires on the parallel bus to the LCDIF.
Based on Marek's commit db8b7ca5b232 ("drm/bridge: ti-sn65dsi83: Replace
connector format patching with atomic_get_input_bus_fmts").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Laurent Pinchart
---
Changes since v1:
- Move .atomic_duplicate_state,.atomic_destroy_state .atomic_reset from
patch 2/2 to 1/2. (Laurent)
drivers/gpu/drm/i2c/tda998x_drv.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 45d52b8a4026..d987481e97c1 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1678,6 +1678,31 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
mutex_unlock(&priv->audio_mutex);
}
+#define MAX_INPUT_SEL_FORMATS 1
+
+static u32 *
+tda998x_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
@@ -1688,6 +1713,7 @@ static const struct drm_bridge_funcs tda998x_bridge_funcs
= {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = tda998x_atomic_get_input_bus_fmts,
};
/* I2C driver functions */
--
2.25.1
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Laurent, On Mon, Jan 3, 2022 at 8:48 AM Laurent Pinchart wrote: > With the comment from 2/2 taken into account, > > Reviewed-by: Laurent Pinchart Thanks for the review. I addressed your feedback and sent v2. I noticed a problem when removing/inserting the HDMI cable. If I boot the board with the HDMI cable connected, then after removal/insertion of the HDMI cable, the following kernel warning is observed: # [ 23.201080] [ cut here ] [ 23.207275] WARNING: CPU: 0 PID: 56 at drivers/gpu/drm/drm_atomic_helper.c:1514 drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294 [ 23.221469] [CRTC:35:crtc-0] vblank wait timed out [ 23.226448] Modules linked in: [ 23.230255] CPU: 0 PID: 56 Comm: kworker/0:3 Not tainted 5.15.12-3-g27f29fb60028 #94 [ 23.238508] Hardware name: Freescale i.MX6 SoloX (Device Tree) [ 23.244457] Workqueue: events output_poll_execute [ 23.249377] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 23.257316] [] (show_stack) from [] (dump_stack_lvl+0x58/0x70) [ 23.265059] [] (dump_stack_lvl) from [] (__warn+0xd8/0x114) [ 23.272533] [] (__warn) from [] (warn_slowpath_fmt+0x90/0xc4) [ 23.280166] [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294) [ 23.291054] [] (drm_atomic_helper_wait_for_vblanks.part.0) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [ 23.303150] [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x9c/0x190) [ 23.312717] [] (commit_tail) from [] (drm_atomic_helper_commit+0x158/0x18c) [ 23.321588] [] (drm_atomic_helper_commit) from [] (drm_client_modeset_commit_atomic+0x238/0x284) [ 23.332314] [] (drm_client_modeset_commit_atomic) from [] (drm_client_modeset_commit_locked+0x60/0x1cc) [ 23.343615] [] (drm_client_modeset_commit_locked) from [] (drm_client_modeset_commit+0x24/0x40) [ 23.354218] [] (drm_client_modeset_commit) from [] (__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc8) [ 23.365803] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x38/0x68) [ 23.377015] [] (drm_fb_helper_set_par) from [] (drm_fb_helper_hotplug_event.part.0+0xa4/0xc0) [ 23.387443] [] (drm_fb_helper_hotplug_event.part.0) from [] (drm_client_dev_hotplug+0x6c/0xb4) [ 23.397959] [] (drm_client_dev_hotplug) from [] (output_poll_execute+0x200/0x21c) [ 23.407346] [] (output_poll_execute) from [] (process_one_work+0x298/0x7cc) [ 23.416224] [] (process_one_work) from [] (worker_thread+0x30/0x50c) [ 23.424479] [] (worker_thread) from [] (kthread+0x154/0x17c) [ 23.432039] [] (kthread) from [] (ret_from_fork+0x14/0x38) [ 23.439413] Exception stack(0xc42a1fb0 to 0xc42a1ff8) [ 23.444588] 1fa0: [ 23.452888] 1fc0: [ 23.461182] 1fe0: 0013 [ 23.468734] irq event stamp: 43775 [ 23.472305] hardirqs last enabled at (43783): [] __up_console_sem+0x50/0x60 [ 23.480785] hardirqs last disabled at (43792): [] __up_console_sem+0x3c/0x60 [ 23.489224] softirqs last enabled at (43774): [] __do_softirq+0x2ec/0x5a4 [ 23.497163] softirqs last disabled at (43747): [] irq_exit+0x18c/0x210 [ 23.505106] ---[ end trace 86572327287ca501 ]--- I haven't managed to fix this yet, but if you have any suggestions, please let me know. Thanks, Fabio Estevam
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Tommaso, On Sat, Jan 8, 2022 at 4:17 PM Tommaso Merciai wrote: > Hi Fabio, > If you need some test let me know. Whitch filesystem are you using? I am using a rootfs generated by Buildroot. The issue I see seems to be hotplug-related. cat /sys/class/drm/card1-HDMI-A-1/status not always match with the real state of the HDMI cable. > In the next days I will investigate on this issue. > Let me know. Thanks
Re: dw_hdmi is showing wrong colour after commit 7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts callbacks")
Hi Biju,
On Thu, Jan 13, 2022 at 2:45 PM Biju Das wrote:
>
> Hi All,
>
> RZ/G2{H, M, N} SoC has dw_hdmi IP and it was working ok(colour) till the
> commit
> 7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts
> callbacks").
>
> After this patch, the screen becomes greenish(may be it is setting it into
> YUV format??).
>
> By checking the code, previously it used to call get_input_fmt callback and
> set colour as RGB24.
>
> After this commit, it calls get_output_fmt_callbck and returns 3
> outputformats(YUV16, YUV24 and RGB24)
> And get_input_fmt callback, I see the outputformat as YUV16 instead of RGB24.
>
> Not sure, I am the only one seeing this issue with dw_HDMI driver.
I have tested linux-next 20220112 on a imx6q-sabresd board, which shows:
dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with HDCP
(DWC HDMI 3D TX PHY)
The colors are shown correctly here.
libdrm-armada repository
Hi Joshua, On Tue, Aug 2, 2016 at 8:09 PM, Joshua Clayton wrote: > Greetings Russell, > I'm publishing an etnaviv yocto layer on github. Cool! Could you please let us know when this layer becomes available? Thanks
[PATCH 1/3] drm/etnaviv: check for errors when enabling clocks
clk_prepare_enable() may fail, so we should better check for its return
value and propagate it in the case of failure.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 87ef341..efee7d47 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -872,12 +872,25 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct
seq_file *m)
*/
static int enable_clk(struct etnaviv_gpu *gpu)
{
- if (gpu->clk_core)
- clk_prepare_enable(gpu->clk_core);
- if (gpu->clk_shader)
- clk_prepare_enable(gpu->clk_shader);
+ int ret;
+
+ if (gpu->clk_core) {
+ ret = clk_prepare_enable(gpu->clk_core);
+ if (ret)
+ return ret;
+ }
+
+ if (gpu->clk_shader) {
+ ret = clk_prepare_enable(gpu->clk_shader);
+ if (ret)
+ goto disable_clk_core;
+ }
return 0;
+
+disable_clk_core:
+ clk_disable_unprepare(gpu->clk_core);
+ return ret;
}
static int disable_clk(struct etnaviv_gpu *gpu)
@@ -892,8 +905,13 @@ static int disable_clk(struct etnaviv_gpu *gpu)
static int enable_axi(struct etnaviv_gpu *gpu)
{
- if (gpu->clk_bus)
- clk_prepare_enable(gpu->clk_bus);
+ int ret;
+
+ if (gpu->clk_bus) {
+ ret = clk_prepare_enable(gpu->clk_bus);
+ if (ret)
+ return ret;
+ }
return 0;
}
--
1.9.1
[PATCH 2/3] drm/etnaviv: remove unneeded 'fail' label
In the etnaviv_gpu_platform_probe() error path the 'fail' label is
used to just return the error code.
This can be simplified by returning the error code immediately, so
get rid of the unneeded 'fail' label.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index efee7d47..d93eb8c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1669,16 +1669,15 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
/* Get Interrupt: */
gpu->irq = platform_get_irq(pdev, 0);
if (gpu->irq < 0) {
- err = gpu->irq;
- dev_err(dev, "failed to get irq: %d\n", err);
- goto fail;
+ dev_err(dev, "failed to get irq: %d\n", gpu->irq);
+ return gpu->irq;
}
err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
dev_name(gpu->dev), gpu);
if (err) {
dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
- goto fail;
+ return err;
}
/* Get Clocks: */
@@ -1712,13 +1711,10 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
err = component_add(&pdev->dev, &gpu_ops);
if (err < 0) {
dev_err(&pdev->dev, "failed to register component: %d\n", err);
- goto fail;
+ return err;
}
return 0;
-
-fail:
- return err;
}
static int etnaviv_gpu_platform_remove(struct platform_device *pdev)
--
1.9.1
[PATCH 3/3] drm/etnaviv: remove unneeded variable initialization
There is no need to initialize variable 'err' with 0 because it will
be properly assigned later on.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d93eb8c..27f34f5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1652,7 +1652,7 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct etnaviv_gpu *gpu;
- int err = 0;
+ int err;
gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
if (!gpu)
--
1.9.1
[PATCH] drm/fsl-dcu: disable clock on error path
From: Fabio Estevam
In fsl_dcu_drm_pm_resume() we should disable the previously enabled
clock (fsl_dev->clk) when enabling fsl_dev->pix_clk fails.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 7882387..76ae558 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -270,7 +270,7 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
ret = clk_prepare_enable(fsl_dev->pix_clk);
if (ret < 0) {
dev_err(dev, "failed to enable pix clk\n");
- return ret;
+ goto disable_dcu_clk;
}
fsl_dcu_drm_init_planes(fsl_dev->drm);
@@ -284,6 +284,10 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
enable_irq(fsl_dev->irq);
return 0;
+
+disable_dcu_clk:
+ clk_disable_unprepare(fsl_dev->clk);
+ return ret;
}
#endif
--
1.9.1
Re: [PATCH v10 1/2] dt-bindings: phy: Add documentation for mixel dphy
On Tue, May 7, 2019 at 4:47 AM Guido Günther wrote: > > Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs. > > Signed-off-by: Guido Günther > Reviewed-by: Sam Ravnborg > Reviewed-by: Rob Herring Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
On Tue, May 7, 2019 at 4:47 AM Guido Günther wrote: > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > this is an IP core it will likely be found on others in the future. So > instead of adding this to the nwl host driver make it a generic PHY > driver. > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be > added once the necessary system controller bits are in via > mixel_dphy_devdata. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RE-RESEND 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
[Adding Sam, who is helping to review/collect panel-simple patches]
On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
wrote:
>
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be connected on the TFT header of Armadeus Dev boards.
>
> Cc: sta...@vger.kernel.org # v4.19
> Reviewed-by: Rob Herring
> Signed-off-by: Sébastien Szymanski
> ---
> .../display/panel/armadeus,st0700-adapt.txt | 9 ++
> drivers/gpu/drm/panel/panel-simple.c | 29 +++
> 2 files changed, 38 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
> b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
> new file mode 100644
> index ..a30d63db3c8f
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
> @@ -0,0 +1,9 @@
> +Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
> +an adapter board.
> +
> +Required properties:
> +- compatible: "armadeus,st0700-adapt"
> +- power-supply: see panel-common.txt
> +
> +Optional properties:
> +- backlight: see panel-common.txt
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..45ca8d10b66f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -446,6 +446,32 @@ static const struct panel_desc ampire_am800480r3tmqwa1h
> = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct display_timing santek_st0700i5y_rbslw_f_timing = {
> + .pixelclock = { 2640, 3330, 4680 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 16, 210, 354 },
> + .hback_porch = { 45, 36, 6 },
> + .hsync_len = { 1, 10, 40 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 7, 22, 147 },
> + .vback_porch = { 22, 13, 3 },
> + .vsync_len = { 1, 10, 20 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> + DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE
> +};
> +
> +static const struct panel_desc armadeus_st0700_adapt = {
> + .timings = &santek_st0700i5y_rbslw_f_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +};
> +
> static const struct drm_display_mode auo_b101aw03_mode = {
> .clock = 51450,
> .hdisplay = 1024,
> @@ -2544,6 +2570,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "arm,rtsm-display",
> .data = &arm_rtsm,
> + }, {
> + .compatible = "armadeus,st0700-adapt",
> + .data = &armadeus_st0700_adapt,
> }, {
> .compatible = "auo,b101aw03",
> .data = &auo_b101aw03,
> --
> 2.19.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RE-RESEND 2/2] ARM: dts: opos6uldev: use OF graph to describe the display
Hi Sébastien, On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski wrote: > > To make use of the new eLCDIF DRM driver OF graph description is > required. Describe the display using OF graph nodes. > > Cc: sta...@vger.kernel.org # v4.19 The Cc to stable applies to bugfixes, which is not the case here. With such tag removed: Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: etnaviv: avoid DMA API warning when importing buffers
Hi Russell, On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin wrote: > > Ping. This patch is present in Lucas' pull request: https://lists.freedesktop.org/archives/etnaviv/2019-May/002490.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: mxsfb: Remove driver
There is a DRM version of the mxsfb driver for quite some time at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining the fbdev version any longer. Remove the fbdev mxsfb driver in favour of the DRM version. Signed-off-by: Fabio Estevam --- drivers/video/fbdev/Kconfig | 13 +- drivers/video/fbdev/Makefile |1 - drivers/video/fbdev/mxsfb.c | 1036 -- 3 files changed, 1 insertion(+), 1049 deletions(-) delete mode 100644 drivers/video/fbdev/mxsfb.c diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index bf6b77b964f1..61c173b0c906 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2171,7 +2171,7 @@ config FB_EP93XX config FB_PRE_INIT_FB bool "Don't reinitialize, use bootloader's GDC/Display configuration" - depends on FB && (FB_MB862XX_LIME || FB_MXS) + depends on FB && FB_MB862XX_LIME ---help--- Select this option if display contents should be inherited as set by the bootloader. @@ -2212,17 +2212,6 @@ config FB_JZ4740 help Framebuffer support for the JZ4740 SoC. -config FB_MXS - tristate "MXS LCD framebuffer support" - depends on FB && (ARCH_MXS || ARCH_MXC) - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - select FB_MODE_HELPERS - select VIDEOMODE_HELPERS - help - Framebuffer support for the MXS SoC. - config FB_PUV3_UNIGFX tristate "PKUnity v3 Unigfx framebuffer support" depends on FB && UNICORE32 && ARCH_PUV3 diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile index 655f2537cac1..7dc4861a93e6 100644 --- a/drivers/video/fbdev/Makefile +++ b/drivers/video/fbdev/Makefile @@ -131,7 +131,6 @@ obj-$(CONFIG_FB_VGA16)+= vga16fb.o obj-$(CONFIG_FB_OF) += offb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o -obj-$(CONFIG_FB_MXS) += mxsfb.o obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o obj-$(CONFIG_FB_SIMPLE) += simplefb.o diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c deleted file mode 100644 index 1fdd1eb38fe0.. --- a/drivers/video/fbdev/mxsfb.c +++ /dev/null @@ -1,1036 +0,0 @@ -/* - * Copyright (C) 2010 Juergen Beisert, Pengutronix - * - * This code is based on: - * Author: Vitaly Wool - * - * Copyright 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved. - * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ - -#define DRIVER_NAME "mxsfb" - -/** - * @file - * @brief LCDIF driver for i.MX23 and i.MX28 - * - * The LCDIF support four modes of operation - * - MPU interface (to drive smart displays) -> not supported yet - * - VSYNC interface (like MPU interface plus Vsync) -> not supported yet - * - Dotclock interface (to drive LC displays with RGB data and sync signals) - * - DVI (to drive ITU-R BT656) -> not supported yet - * - * This driver depends on a correct setup of the pins used for this purpose - * (platform specific). - * - * For the developer: Don't forget to set the data bus width to the display - * in the imx_fb_videomode structure. You will else end up with ugly colours. - * If you fight against jitter you can vary the clock delay. This is a feature - * of the i.MX28 and you can vary it between 2 ns ... 8 ns in 2 ns steps. Give - * the required value in the imx_fb_videomode structure. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#define REG_SET4 -#define REG_CLR8 - -#define LCDC_CTRL 0x00 -#define LCDC_CTRL1 0x10 -#define LCDC_V4_CTRL2 0x20 -#define LCDC_V3_TRANSFER_COUNT 0x20 -#define LCDC_V4_TRANSFER_COUNT 0x30 -#define LCDC_V4_CUR_BUF0x40 -#define LCDC_V4_NEXT_BUF 0x50 -#define LCDC_V3_CUR_BUF0x30 -#define LCDC_V3_NEXT_BUF 0x40 -#define LCDC_TIMING0x60 -#define LCDC_VDCTRL0 0x70 -#define LCDC_VDCTRL1 0x80 -#define LCDC_VDCTRL2 0x90 -#define LCDC_VDCTRL3 0xa0 -#define LCDC_VDCTRL4
Re: [PATCH v2 1/3] dt-bindings: Add vendor prefix for VXT Ltd
On Tue, Apr 23, 2019 at 8:03 AM Thierry Reding wrote: > > On Mon, Feb 18, 2019 at 09:27:04PM -0300, Fabio Estevam wrote: > > VXT Ltd is a manufacturer of projected capacitive touch panel > > and display solutions: http://www.vxt.com.tw/ > > > > Reviewed-by: Otavio Salvador > > Reviewed-by: Rob Herring > > Signed-off-by: Fabio Estevam > > --- > > Changes since v1: > > - None > > > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > Applied all three patches, thanks. I don't see any of these patches applied in linux-next nor 5.2-rc1. What is the issue here? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi Kishon, On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > this is an IP core it will likely be found on others in the future. So > instead of adding this to the nwl host driver make it a generic PHY > driver. > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be > added once the necessary system controller bits are in via > mixel_dphy_devdata. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Reviewed-by: Fabio Estevam > Reviewed-by: Sam Ravnborg Would you have any comments on this series, please? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/damage-helper: Use NULL instead of 0
The 'clips' member is a pointer, so assign NULL instead of 0.
This fixes the following sparse warning:
drivers/gpu/drm/drm_damage_helper.c:289:31: warning: Using plain integer as
NULL pointer
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/drm_damage_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index ee67c96841fa..8230dac01a89 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -286,7 +286,7 @@ drm_atomic_helper_damage_iter_init(struct
drm_atomic_helper_damage_iter *iter,
iter->plane_src.y2 = (state->src.y2 >> 16) + !!(state->src.y2 & 0x);
if (!iter->clips || !drm_rect_equals(&state->src, &old_state->src)) {
- iter->clips = 0;
+ iter->clips = NULL;
iter->num_clips = 0;
iter->full_update = true;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Include the header
The prototype for 'drm_timeout_abs_to_jiffies' is provided by the header. Include this header to fix the following sparse warning: drivers/gpu/drm/drm_syncobj.c:937:13: warning: symbol 'drm_timeout_abs_to_jiffies' was not declared. Should it be static? Signed-off-by: Fabio Estevam --- drivers/gpu/drm/drm_syncobj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 3d400905100b..b06fa424bd44 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -46,6 +46,7 @@ * The file takes a reference on the kref. */ +#include #include #include #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Pending panel driver patches - OK to commit?
Hi Sam, On Mon, Apr 1, 2019 at 3:24 PM Sam Ravnborg wrote: > panel-simple support for VXT VL050-8048NT-C01 panel - Fabio Estevam > Any chance to get this one to kernel 5.2? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi Guido,
On Tue, Apr 30, 2019 at 11:40 AM Guido Günther wrote:
>
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
> added once the necessary system controller bits are in via
> mixel_dphy_devdata.
>
> Co-authored-by: Robert Chiras
> Signed-off-by: Guido Günther
I wish I could test it on a imx8m-evk , but there are some other
pieces needed such as Northwest Logic driver, mxsfb changes for
supporting mx8m, OLED panel driver, etc
Anyway, it looks good to me and I have only a few minor comments:
> ---
> drivers/phy/freescale/Kconfig | 11 +
> drivers/phy/freescale/Makefile| 1 +
> .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 506 ++
> 3 files changed, 518 insertions(+)
> create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 832670b4952b..a111b130f9d2 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -3,3 +3,14 @@ config PHY_FSL_IMX8MQ_USB
> depends on OF && HAS_IOMEM
> select GENERIC_PHY
> default ARCH_MXC && ARM64
> +
> +config PHY_MIXEL_MIPI_DPHY
> + tristate "Mixel MIPI DSI PHY support"
> + depends on OF && HAS_IOMEM
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
> + select REGMAP_MMIO
> + default ARCH_MXC && ARM64
I don't think that this default is a good idea.
There are imx8m systems that do not have display, so in this case it
does not make sense to always force the build of this driver.
> + help
> + Enable this to add support for the Mixel DSI PHY as found
> + on NXP's i.MX8 family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index dc2b3f1f2f80..07491c926a2c 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
> +obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> new file mode 100644
> index ..d6b5af0b3380
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -0,0 +1,506 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2017,2018 NXP
> + * Copyright 2019 Purism SPC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please keep the headers sorted.
> +#include
> +static int mixel_dphy_validate(struct phy *phy, enum phy_mode mode, int
> submode,
> + union phy_configure_opts *opts)
> +{
> + struct mixel_dphy_cfg cfg = { 0 };
> +
> + if (mode != PHY_MODE_MIPI_DPHY)
> + return -EINVAL;
> +
> + return mixel_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
> +}
> +
> +
A single blank line is enough.
> +static int mixel_dphy_init(struct phy *phy)
> +{
> + phy_write(phy, PWR_OFF, DPHY_PD_PLL);
> + phy_write(phy, PWR_OFF, DPHY_PD_DPHY);
> +
> + return 0;
> +}
> +
> +
Ditto.
> +static int mixel_dphy_exit(struct phy *phy)
> +{
> + phy_write(phy, 0, DPHY_CM);
> + phy_write(phy, 0, DPHY_CN);
> + phy_write(phy, 0, DPHY_CO);
> +
> + return 0;
> +}
> +
> +
Ditto.
> +static int mixel_dphy_power_off(struct phy *phy)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> +
> + phy_write(phy, PWR_OFF, DPHY_PD_PLL);
> + phy_write(phy, PWR_OFF, DPHY_PD_DPHY);
> +
> + clk_disable_unprepare(priv->phy_ref_clk);
> +
> + return 0;
> +}
> +
> +
Ditto.
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(regs)) {
> + dev_err(dev, "Couldn't map the DPHY registers\n");
You can skip this error message, because the core already complains on
ioremap failures.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
Ping On Sun, Dec 16, 2018 at 10:39 PM Fabio Estevam wrote: > > Hi Thierry, > > On Tue, Dec 4, 2018 at 2:57 PM Fabio Estevam wrote: > > > > Add support for the VXT VL050-8048NT-C01 800x480 panel to the > > panel-simple driver. > > > > This panel is used on some boards manufactured by TechNexion, such as > > imx7d-pico. > > > > Signed-off-by: Fabio Estevam > > Do you think it is possible to get this series applied for 4.21? > > Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] phy: Add driver for mixel dphy
Hi Guido,
On Fri, Jan 25, 2019 at 8:15 AM Guido Günther wrote:
> +config PHY_MIXEL_MIPI_DPHY
> + bool
> + depends on OF
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
> + default ARCH_MXC && ARM64
No need to force this selection for all i.MX8M boards, as not everyone
is interested in using Mixel DSI.
> --- /dev/null
> +++ b/drivers/phy/phy-mixel-mipi-dphy.c
> @@ -0,0 +1,449 @@
> +/*
> + * Copyright 2017 NXP
> + * Copyright 2019 Purism SPC
> + *
> + * SPDX-License-Identifier: GPL-2.0
SPDX line should be in the first line and start with //
> + */
> +
> +/* #define DEBUG 1 */
Please remove it.
> +/* DPHY registers */
> +#define DPHY_PD_DPHY 0x00
> +#define DPHY_M_PRG_HS_PREPARE 0x04
> +#define DPHY_MC_PRG_HS_PREPARE 0x08
> +#define DPHY_M_PRG_HS_ZERO 0x0c
> +#define DPHY_MC_PRG_HS_ZERO0x10
> +#define DPHY_M_PRG_HS_TRAIL0x14
> +#define DPHY_MC_PRG_HS_TRAIL 0x18
> +#define DPHY_PD_PLL0x1c
> +#define DPHY_TST 0x20
> +#define DPHY_CN0x24
> +#define DPHY_CM0x28
> +#define DPHY_CO0x2c
> +#define DPHY_LOCK 0x30
> +#define DPHY_LOCK_BYP 0x34
> +#define DPHY_TX_RCAL 0x38
> +#define DPHY_AUTO_PD_EN0x3c
> +#define DPHY_RXLPRP0x40
> +#define DPHY_RXCDRP0x44
In the NXP vendor tree we have these additional offsets for imx8m that
are missing here:
.reg_rxhs_settle = 0x48,
.reg_bypass_pll = 0x4c,
> +#define MBPS(x) ((x) * 100)
> +
> +#define DATA_RATE_MAX_SPEED MBPS(1500)
> +#define DATA_RATE_MIN_SPEED MBPS(80)
> +
> +#define CN_BUF 0xcb7a89c0
> +#define CO_BUF 0x63
> +#define CM(x) ( \
> + ((x) < 32)?0xe0|((x)-16) : \
> + ((x) < 64)?0xc0|((x)-32) : \
> + ((x) < 128)?0x80|((x)-64) : \
> + ((x) - 128))
> +#define CN(x) (((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
> +#define CO(x) ((CO_BUF)>>(8-(x))&0x3)
> +
> +static inline u32 phy_read(struct phy *phy, unsigned int reg)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> +
> + return readl(priv->regs + reg);
Maybe it's worth using regmap here. It makes it very easy to dump all
the MIXEL registers at once.
> +static int mixel_dphy_config_from_opts(struct phy *phy,
> + struct phy_configure_opts_mipi_dphy *dphy_opts,
> + struct mixel_dphy_cfg *cfg)
> +{
> + struct mixel_dphy_priv *priv = dev_get_drvdata(phy->dev.parent);
> + unsigned long ref_clk = clk_get_rate(priv->phy_ref_clk);
> + int i;
> + unsigned long numerator, denominator, frequency;
> + unsigned step;
> +
> + if (dphy_opts->hs_clk_rate > DATA_RATE_MAX_SPEED ||
> + dphy_opts->hs_clk_rate < DATA_RATE_MIN_SPEED)
> + return -EINVAL;
> + cfg->hs_clk_rate = dphy_opts->hs_clk_rate;
> +
> + numerator = dphy_opts->hs_clk_rate;
> + denominator = ref_clk;
> + get_best_ratio(&numerator, &denominator, 255, 256);
> + if (!numerator || !denominator) {
> + dev_dbg(&phy->dev, "Invalid %ld/%ld for %ld/%ld\n",
dev_err should be more appropriate here.
> +static int mixel_dphy_ref_power_on(struct phy *phy)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + u32 lock, timeout;
> + int ret = 0;
> +
> + mutex_lock(&priv->lock);
> + clk_prepare_enable(priv->phy_ref_clk);
> +
> + phy_write(phy, PWR_ON, DPHY_PD_DPHY);
> + phy_write(phy, PWR_ON, DPHY_PD_PLL);
> +
> + timeout = 100;
> + while (!(lock = phy_read(phy, DPHY_LOCK))) {
> + udelay(10);
> + if (--timeout == 0) {
> + dev_err(&phy->dev, "Could not get DPHY lock!\n");
> + mutex_unlock(&priv->lock);
> + return -EINVAL;
Could you use readl_poll_timeout() instead?
> +static int mixel_dphy_ref_power_off(struct phy *phy)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + int ret = 0;
This variable is not needed.
> +
> + mutex_lock(&priv->lock);
> +
> + phy_write(phy, PWR_OFF, DPHY_PD_PLL);
> + phy_write(phy, PWR_OFF, DPHY_PD_DPHY);
> +
> + clk_disable_unprepare(priv->phy_ref_clk);
> + mutex_unlock(&priv->lock);
> +
> + return ret;
and you could simply do a 'return 0' instead.
> + phy_write(phy, 0x00, DPHY_LOCK_BYP);
> + phy_write(phy, 0x01, DPHY_TX_RCAL);
> + phy_write(phy, 0x00, DPHY_AUTO_PD_EN);
> + phy_write(phy, 0x01, DPHY_RXLPRP);
> + phy_write(phy, 0x01, DPHY_RXCDRP);
In the NXP vendor code the value 2 is written to this register:
phy_write(phy, 0x02, priv->plat_data->reg_rxcdrp);
It
Re: [PATCH v2 3/3] phy: Add driver for mixel dphy found on imx8
Hi Guido,
Thanks for the respin. It looks better :-)
On Fri, Feb 1, 2019 at 6:50 AM Guido Günther wrote:
> +config PHY_MIXEL_MIPI_DPHY
> + tristate "Mixel MIPI DSI PHY support"
> + depends on OF
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
Since you converted to regmap, I guess you need:
select REGMAP_MMIO now?
> + help
> + Enable this to add support for the Mixel DSI PHY as found
> + on NXP's i.MX8 family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index dc2b3f1f2f80..07491c926a2c 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
> +obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> new file mode 100644
> index ..4b182f2eaa6e
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -0,0 +1,494 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2017,2018 NXP
> + * Copyright 2019 Purism SPC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* DPHY registers */
> +#define DPHY_PD_DPHY 0x00
> +#define DPHY_M_PRG_HS_PREPARE 0x04
> +#define DPHY_MC_PRG_HS_PREPARE 0x08
> +#define DPHY_M_PRG_HS_ZERO 0x0c
> +#define DPHY_MC_PRG_HS_ZERO0x10
> +#define DPHY_M_PRG_HS_TRAIL0x14
> +#define DPHY_MC_PRG_HS_TRAIL 0x18
> +#define DPHY_PD_PLL0x1c
> +#define DPHY_TST 0x20
> +#define DPHY_CN0x24
> +#define DPHY_CM0x28
> +#define DPHY_CO0x2c
> +#define DPHY_LOCK 0x30
> +#define DPHY_LOCK_BYP 0x34
> +#define DPHY_REG_BYPASS_PLL0x4C
> +
> +#define MBPS(x) ((x) * 100)
> +
> +#define DATA_RATE_MAX_SPEED MBPS(1500)
> +#define DATA_RATE_MIN_SPEED MBPS(80)
> +
> +#define CN_BUF 0xcb7a89c0
> +#define CO_BUF 0x63
> +#define CM(x) ( \
> + ((x) < 32)?0xe0|((x)-16) : \
Doesn't checkpatch complain about the need of space between operators?
> + ((x) < 64)?0xc0|((x)-32) : \
> + ((x) < 128)?0x80|((x)-64) : \
> + ((x) - 128))
> +#define CN(x) (((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
> +#define CO(x) ((CO_BUF)>>(8-(x))&0x3)
> +
> +/* PHY power on is LOW_ENABLE */
active low is probably a better term.
> +#define PWR_ON 0
> +#define PWR_OFF1
> +static inline u32 phy_read(struct phy *phy, unsigned int reg)
After the conversion to regmap this function is unused now and you
should remove it.
> +static inline void phy_write(struct phy *phy, u32 value, unsigned int reg)
No need for "inline".
Make it static int instead.
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = regmap_write(priv->regs, reg, value);
Or maybe get rid of this function and use regmap_write() instead.
> + frequency = ref_clk * numerator / (2 * denominator);
> + dev_info(&phy->dev, "freq=%ld, hs_clk/ref_clk=%ld/%ld ⩰ %ld/%ld\n",
dev_dbg() would be better?
> +frequency, dphy_opts->hs_clk_rate, ref_clk,
> +numerator, denominator);
> +
> + /* LP clock period */
> + lp_t = 1L / dphy_opts->lp_clk_rate; /* ps */
> + dev_dbg(&phy->dev, "LP clock %lu, period: %lu ps\n",
> + dphy_opts->lp_clk_rate, lp_t);
> + /*
> +* hs_prepare: in lp clock periods
> +*/
Please use single line comment style instead.
> + if (2 * dphy_opts->hs_prepare > 5 * lp_t) {
> + dev_err(&phy->dev,
> + "hs_prepare (%u) > 2.5 * lp clock period (%lu)",
> + dphy_opts->hs_prepare, lp_t);
> + return -EINVAL;
> + }
> + /* 00: lp_t, 01: 1.5 * lp_t, 10: 2 * lp_t, 11: 2.5 * lp_t */
> + if (dphy_opts->hs_prepare < lp_t)
> + n = 0;
> + else
> + n = 2 * (dphy_opts->hs_prepare - lp_t) / lp_t;
> + cfg->m_prg_hs_prepare = n;
> +
> + /*
> +* clk_prepare: in lp clock periods
> +*/
Same here.
> + if (2 * dphy_opts->clk_prepare > 3 * lp_t) {
> + dev_err(&phy->dev,
> + "clk_prepare (%u) > 1.5 * lp clock period (%lu)",
> + dphy_opts->clk_prepare, lp_t);
> + return -EINVAL;
> + }
> + /* 00: lp_t, 01: 1.5 * lp_t */
> + cfg->mc_prg_hs_prepare = dphy_opts->clk_prepare > lp_t ? 1 : 0;
> +
> + /*
> +* hs_zero: forumu
[PATCH] qcom-scm: Include header
Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
error when building imx_v6_v7_defconfig:
In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
this function)
return -ENODEV;
Include the header file to fix this problem.
Reported-by: kernelci.org bot
Fixes: e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
Signed-off-by: Fabio Estevam
---
include/linux/qcom_scm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 06996ad4f2bc..ce5a476fd733 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -13,6 +13,7 @@
#ifndef __QCOM_SCM_H
#define __QCOM_SCM_H
+#include
#include
#include
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
Hi Bjorn,
On Fri, Dec 28, 2018 at 5:31 PM Bjorn Andersson
wrote:
>
> On Wed 26 Dec 04:06 PST 2018, Fabio Estevam wrote:
>
> > Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> > the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
> > error when building imx_v6_v7_defconfig:
> >
> > In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
> > ../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
> > ../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
> > this function)
> > return -ENODEV;
> >
> > Include the header file to fix this problem.
> >
>
> Reviewed-by: Bjorn Andersson
>
> Andy, please pick up for inclusion in -rc
Yes, it would be really nice if we could get this fix into 4.20-rc1 so
that imx_v6_v7_defconfig could be built.
> Fabio, please use get_maintainers, so your patches hits the appropriate
> mailing lists (linux-arm-msm@ in this case)
Sorry, I copied the folks involved in the offending commit:
e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
By the way, I just ran get_maintainers in this patch and linux-arm-msm
is not listed.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
Hi Bjorn, On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > By the way, I just ran get_maintainers in this patch and linux-arm-msm > is not listed. Would you like to me to submit a patch like this to fix this problem? diff --git a/MAINTAINERS b/MAINTAINERS index 7a9804a891fd..e014de05b046 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4797,6 +4797,7 @@ L:freedr...@lists.freedesktop.org T: git git://people.freedesktop.org/~robclark/linux S: Maintained F: drivers/gpu/drm/msm/ +F: include/linux/qcom_scm.h F: include/uapi/drm/msm_drm.h F: Documentation/devicetree/bindings/display/msm/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > > Andy, please pick up for inclusion in -rc > > Yes, it would be really nice if we could get this fix into 4.20-rc1 so > that imx_v6_v7_defconfig could be built. Ops, I meant 4.21-rc1 :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri, Dec 28, 2018 at 5:56 PM Fabio Estevam wrote: > > Hi Bjorn, > > On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > > > By the way, I just ran get_maintainers in this patch and linux-arm-msm > > is not listed. > > Would you like to me to submit a patch like this to fix this problem? Just realized that include/linux/qcom_scm.h is used in several subsystems, so maybe a better location would be under ARM/QUALCOMM SUPPORT? diff --git a/MAINTAINERS b/MAINTAINERS index 7a9804a891fd..77836b9a8ffd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1950,6 +1950,7 @@ F:drivers/tty/serial/msm_serial.c F: drivers/*/pm8???-* F: drivers/mfd/ssbi.c F: drivers/firmware/qcom_scm* +F: include/linux/qcom_scm.h T: git git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git ARM/RADISYS ENP2611 MACHINE SUPPORT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
Hi Bjorn, On Fri, Dec 28, 2018 at 10:27 PM Bjorn Andersson wrote: > Sorry about that, I forgot that the header file is not covered by the > MAINTAINERS file. > > Your second patch looks good, but I'm hoping we can merge the upcoming > v3 of Amit's patch right after the merge window. It fixes this and a lot > of other pieces where we would like to include linux-arm-msm@: > > https://lore.kernel.org/lkml/d153a86748f99526e7790bfc4ef8781a2016fd51.1545126964.git.amit.kuche...@linaro.org/ Amit's patch adds the following entry: +F: include/linux/*/qcom* but it does not catch include/linux/qcom_scm.h It also needs +F: include/linux/qcom* in order to catch include/linux/qcom-geni-se.h and include/linux/qcom_scm.h I can add that entry after Amit's patch gets applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] drm/mxsfb: Update mxsfb to support LCD reset
Hi Robert,
On Thu, Jan 10, 2019 at 6:34 AM Robert Chiras wrote:
>
> The eLCDIF controller has control pin for the external LCD reset pin.
> Add support for it and assert this pin in enable and de-assert it in
> disable.
> Also, correct the pm_runtime_enable call, since it was made too early in
> the probe, causing issues to DRM enable routines.
The pm_runtime change should be on a different patch.
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 20
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
> 3 files changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index b62b607..8d1b6a6 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -230,9 +230,12 @@ static void mxsfb_enable_controller(struct
> mxsfb_drm_private *mxsfb)
> clk_prepare_enable(mxsfb->clk_disp_axi);
> clk_prepare_enable(mxsfb->clk);
>
> - if (mxsfb->devdata->ipversion >= 4)
> + if (mxsfb->devdata->ipversion >= 4) {
> writel(CTRL2_OUTSTANDING_REQS(REQ_16),
> mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> + /* Assert LCD Reset bit */
> + writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 +
> REG_SET);
> + }
>
> /* If it was disabled, re-enable the mode again */
> writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
> @@ -250,9 +253,12 @@ static void mxsfb_disable_controller(struct
> mxsfb_drm_private *mxsfb)
> {
> u32 reg;
>
> - if (mxsfb->devdata->ipversion >= 4)
> + if (mxsfb->devdata->ipversion >= 4) {
> writel(CTRL2_OUTSTANDING_REQS(0x7),
> mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
> + /* De-assert LCD Reset bit */
> + writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 +
> REG_CLR);
> + }
>
> writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
>
> @@ -346,6 +352,8 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
> return;
>
> clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
> + DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
> + m->crtc_clock, (int)(clk_get_rate(mxsfb->clk) / 1000));
This unrelated change should also be in a different patch.
>
> DRM_DEV_DEBUG_DRIVER(drm->dev,
> "Connector bus_flags: 0x%08X\n", bus_flags);
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index f528a37..135b8e1 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -287,7 +287,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> long flags)
> if (IS_ERR(mxsfb->base))
> return PTR_ERR(mxsfb->base);
>
> - mxsfb->clk = devm_clk_get(drm->dev, NULL);
> + mxsfb->clk = devm_clk_get(drm->dev, "pix");
This breaks mx23 and mx28 as there is no "pix" clock defined in their
dtsi files.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
Hi Chris, On Mon, Jan 14, 2019 at 5:54 PM Chris Healy wrote: > > Perhaps I am confused but it appears that this patch has already > landed upstream and got included in 5.0-rc2: The patch that Amit is referring is the following entry in MAINTAINERS file: +F: include/linux/qcom* so that the proper lists can be put on Cc on future changes of this file. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: Add vendor prefix for VXT Ltd
VXT Ltd is a manufacturer of projected capacitive touch panel and display solutions: http://www.vxt.com.tw/ Reviewed-by: Otavio Salvador Reviewed-by: Rob Herring Signed-off-by: Fabio Estevam --- Changes since v1: - None Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389508584f48..096ad1857692 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -427,6 +427,7 @@ vivante Vivante Corporation vocore VoCore Studio voipac Voipac Technologies s.r.o. votVision Optical Technology Co., Ltd. +vxtVXT Ltd wd Western Digital Corp. wetek WeTek Electronics, limited. wexler Wexler -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
Add support for the VXT VL050-8048NT-C01 800x480 panel to the
panel-simple driver.
This panel is used on some boards manufactured by TechNexion, such as
imx7d-pico.
Reviewed-by: Otavio Salvador
Reviewed-by: Sam Ravnborg
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Pass .flags and .bus_flags (Sam)
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e739a524..737cbf3aee11 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2434,6 +2434,32 @@ static const struct panel_desc urt_umsh_8596md_parallel
= {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode vl050_8048nt_c01_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 20,
+ .htotal = 800 + 210 + 20 + 46,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 10,
+ .vtotal = 480 + 22 + 10 + 23,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc vl050_8048nt_c01 = {
+ .modes = &vl050_8048nt_c01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 120,
+ .height = 76,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode winstar_wf35ltiacd_mode = {
.clock = 6410,
.hdisplay = 320,
@@ -2751,6 +2777,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "urt,umsh-8596md-20t",
.data = &urt_umsh_8596md_parallel,
+ }, {
+ .compatible = "vxt,vl050-8048nt-c01",
+ .data = &vl050_8048nt_c01,
}, {
.compatible = "winstar,wf35ltiacd",
.data = &winstar_wf35ltiacd,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: Add VXT VL050-8048NT-C01 panel bindings
The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution connected via 24 width parallel interface. Reviewed-by: Otavio Salvador Reviewed-by: Rob Herring --- Changes since v1: - None .../bindings/display/panel/vl050_8048nt_c01.txt | 12 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt diff --git a/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt new file mode 100644 index ..b42bf06bbd99 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt @@ -0,0 +1,12 @@ +VXT 800x480 color TFT LCD panel + +Required properties: +- compatible: should be "vxt,vl050-8048nt-c01" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: dpms mode change with wayland on iMX.6
On Mon, May 27, 2019 at 10:53 AM Pintu Agarwal wrote: > One more point: > Although it is having Kernel 3.10, but the DRM modules were upgraded > to Kernel 4.9.xx from mainline. > So, latest DRM changes are already applied. Please don't do this: just use a recent mainline kernel instead of mixing 3.10 kernel + DRM part from 4.9. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Use devm_platform_ioremap_resource()
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 72d01e873160..a4ff1ee41bfa 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1711,7 +1711,6 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct etnaviv_gpu *gpu;
- struct resource *res;
int err;
gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
@@ -1723,8 +1722,7 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
mutex_init(&gpu->fence_lock);
/* Map registers: */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- gpu->mmio = devm_ioremap_resource(&pdev->dev, res);
+ gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(gpu->mmio))
return PTR_ERR(gpu->mmio);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Use dev_info() instead of pr_info()
dev_info() is more appropriate for printing error messages inside
drivers, so switch to dev_info().
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 160ce3c060a5..827b5e42dbe3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -414,18 +414,18 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
buffer->user_size - 4);
if (drm_debug & DRM_UT_DRIVER)
- pr_info("stream link to 0x%08x @ 0x%08x %p\n",
- return_target, etnaviv_cmdbuf_get_va(cmdbuf),
- cmdbuf->vaddr);
+ dev_info(gpu->dev, "stream link to 0x%08x @ 0x%08x %p\n",
+return_target, etnaviv_cmdbuf_get_va(cmdbuf),
+cmdbuf->vaddr);
if (drm_debug & DRM_UT_DRIVER) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
cmdbuf->vaddr, cmdbuf->size, 0);
- pr_info("link op: %p\n", buffer->vaddr + waitlink_offset);
- pr_info("addr: 0x%08x\n", link_target);
- pr_info("back: 0x%08x\n", return_target);
- pr_info("event: %d\n", event);
+ dev_info(gpu->dev, "link op: %p\n", buffer->vaddr +
waitlink_offset);
+ dev_info(gpu->dev, "addr: 0x%08x\n", link_target);
+ dev_info(gpu->dev, "back: 0x%08x\n", return_target);
+ dev_info(gpu->dev, "event: %d\n", event);
}
/*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/etnaviv: Use dev_info() instead of pr_info()
dev_info() is more appropriate for printing _info level messages
inside drivers, so switch to dev_info().
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Adjust commit log to say "_info level" instead of "error"
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 160ce3c060a5..827b5e42dbe3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -414,18 +414,18 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
buffer->user_size - 4);
if (drm_debug & DRM_UT_DRIVER)
- pr_info("stream link to 0x%08x @ 0x%08x %p\n",
- return_target, etnaviv_cmdbuf_get_va(cmdbuf),
- cmdbuf->vaddr);
+ dev_info(gpu->dev, "stream link to 0x%08x @ 0x%08x %p\n",
+return_target, etnaviv_cmdbuf_get_va(cmdbuf),
+cmdbuf->vaddr);
if (drm_debug & DRM_UT_DRIVER) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
cmdbuf->vaddr, cmdbuf->size, 0);
- pr_info("link op: %p\n", buffer->vaddr + waitlink_offset);
- pr_info("addr: 0x%08x\n", link_target);
- pr_info("back: 0x%08x\n", return_target);
- pr_info("event: %d\n", event);
+ dev_info(gpu->dev, "link op: %p\n", buffer->vaddr +
waitlink_offset);
+ dev_info(gpu->dev, "addr: 0x%08x\n", link_target);
+ dev_info(gpu->dev, "back: 0x%08x\n", return_target);
+ dev_info(gpu->dev, "event: %d\n", event);
}
/*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
etnaviv: Possible circular lockingon i.MX6QP
Hi,
On a imx6qp-wandboard I get the warning below about a possible
circular locking dependency running 5.1.9 built from
imx_v6_v7_defconfig.
Such warning does not happen on the imx6q or imx6solo variants of
wandboard though.
Any ideas?
Thanks,
Fabio Estevam
** (matchbox-panel:708): WARNING **: Failed to load applet "battery"
(/usr/lib/matchbox-panel/libbattery.so: cannot open shared object
file: No such file or directory).
matchbox-wm: X error warning (0xe3): BadWindow (invalid Window
parameter) (opcode: 12)
etnaviv-gpu 134000.gpu: MMU fault status 0x0001
etnaviv-gpu 134000.gpu: MMU 0 fault addr 0x0805ffc0
==
WARNING: possible circular locking dependency detected
5.1.9 #58 Not tainted
--
kworker/0:1/29 is trying to acquire lock:
(ptrval) (&(&gpu->fence_spinlock)->rlock){-...}, at:
dma_fence_remove_callback+0x14/0x50
but task is already holding lock:
(ptrval) (&(&sched->job_list_lock)->rlock){-...}, at: drm_sched_stop+0x1c/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&sched->job_list_lock)->rlock){-...}:
drm_sched_process_job+0x5c/0x1c8
dma_fence_signal+0xdc/0x1d4
irq_handler+0xd0/0x1e0
__handle_irq_event_percpu+0x48/0x360
handle_irq_event_percpu+0x28/0x7c
handle_irq_event+0x38/0x5c
handle_fasteoi_irq+0xc0/0x17c
generic_handle_irq+0x20/0x34
__handle_domain_irq+0x64/0xe0
gic_handle_irq+0x4c/0xa8
__irq_svc+0x70/0x98
cpuidle_enter_state+0x168/0x5a4
cpuidle_enter_state+0x168/0x5a4
do_idle+0x220/0x2c0
cpu_startup_entry+0x18/0x20
start_kernel+0x3e4/0x498
-> #0 (&(&gpu->fence_spinlock)->rlock){-...}:
_raw_spin_lock_irqsave+0x38/0x4c
dma_fence_remove_callback+0x14/0x50
drm_sched_stop+0x98/0x124
etnaviv_sched_timedout_job+0x7c/0xb4
drm_sched_job_timedout+0x34/0x5c
process_one_work+0x2ac/0x704
worker_thread+0x2c/0x574
kthread+0x134/0x148
ret_from_fork+0x14/0x20
(null)
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(&(&sched->job_list_lock)->rlock);
lock(&(&gpu->fence_spinlock)->rlock);
lock(&(&sched->job_list_lock)->rlock);
lock(&(&gpu->fence_spinlock)->rlock);
*** DEADLOCK ***
3 locks held by kworker/0:1/29:
#0: (ptrval) ((wq_completion)events){+.+.}, at: process_one_work+0x1f4/0x704
#1: (ptrval) ((work_completion)(&(&sched->work_tdr)->work)){+.+.},
at: process_one_work+0x1f4/0x704
#2: (ptrval) (&(&sched->job_list_lock)->rlock){-...}, at:
drm_sched_stop+0x1c/0x124
stack backtrace:
CPU: 0 PID: 29 Comm: kworker/0:1 Not tainted 5.1.9 #58
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Workqueue: events drm_sched_job_timedout
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xd8/0x110)
[] (dump_stack) from []
(print_circular_bug.constprop.19+0x1bc/0x2f0)
[] (print_circular_bug.constprop.19) from []
(__lock_acquire+0x1778/0x1f38)
[] (__lock_acquire) from [] (lock_acquire+0xcc/0x1e8)
[] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x38/0x4c)
[] (_raw_spin_lock_irqsave) from []
(dma_fence_remove_callback+0x14/0x50)
[] (dma_fence_remove_callback) from []
(drm_sched_stop+0x98/0x124)
[] (drm_sched_stop) from []
(etnaviv_sched_timedout_job+0x7c/0xb4)
[] (etnaviv_sched_timedout_job) from []
(drm_sched_job_timedout+0x34/0x5c)
[] (drm_sched_job_timedout) from []
(process_one_work+0x2ac/0x704)
[] (process_one_work) from [] (worker_thread+0x2c/0x574)
[] (worker_thread) from [] (kthread+0x134/0x148)
[] (kthread) from [] (ret_from_fork+0x14/0x20)
Exception stack(0xe81f7fb0 to 0xe81f7ff8)
7fa0:
7fc0:
7fe0: 0013
etnaviv-gpu 134000.gpu: recover hung GPU!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Robert,
On Fri, Jun 14, 2019 at 8:52 AM Robert Chiras wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,730 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver
> + *
> + * Copyright (C) 2017 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
No need for this text as you are using SPDX tag.
> +static int color_format_from_dsi_format(enum mipi_dsi_pixel_format format)
> +{
> + switch (format) {
> + case MIPI_DSI_FMT_RGB565:
> + return 0x55;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return 0x66;
> + case MIPI_DSI_FMT_RGB888:
> + return 0x77;
Could you use defines for these magic 0x55, 0x66 and 0x77 numbers?
> +static int rad_panel_prepare(struct drm_panel *panel)
> +{
> + struct rad_panel *rad = to_rad_panel(panel);
> +
> + if (rad->prepared)
> + return 0;
> +
> + if (rad->reset) {
> + gpiod_set_value(rad->reset, 0);
> + usleep_range(5000, 1);
> + gpiod_set_value(rad->reset, 1);
> + usleep_range(2, 25000);
This does not look correct.
The correct way to do a reset with gpiod API is:
gpiod_set_value(rad->reset, 1);
delay
gpiod_set_value(rad->reset, 0);
I don't have the datasheet for the RM67191 panel, but I assume the
reset GPIO is active low.
Since you inverted the polarity in the dts and inside the driver, you
got it right by accident.
You could also consider using gpiod_set_value_cansleep() variant
instead because the GPIO reset could be provided by an I2C GPIO
expander, for example.
Also, when sleeping for more than 10ms, msleep is a better fit as per
Documentation/timers/timers-howto.txt.
> + if (rad->reset) {
> + gpiod_set_value(rad->reset, 0);
> + usleep_range(15000, 17000);
> + gpiod_set_value(rad->reset, 1);
> + }
Another reset?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
On Fri, Jun 14, 2019 at 8:53 AM Robert Chiras wrote:
>
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 42
> ++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> new file mode 100644
> index 000..5a6268d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> @@ -0,0 +1,42 @@
> +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
> +
> +Required properties:
> +- compatible: "raydium,rm67191"
> +- reg: virtual channel for MIPI-DSI protocol
> + must be <0>
> +- dsi-lanes: number of DSI lanes to be used
> + must be <3> or <4>
> +- port:input port node with endpoint definition as
> + defined in
> Documentation/devicetree/bindings/graph.txt;
> + the input port should be connected to a MIPI-DSI
> device
> + driver
> +
> +Optional properties:
> +- reset-gpio: a GPIO spec for the RST_B GPIO pin
reset-gpios (with the s in the end) is the recommendation.
> +- display-timings: timings for the connected panel according to [1]
This is not needed.
> +- video-mode: 0 - burst-mode
> + 1 - non-burst with sync event
> + 2 - non-burst with sync pulse
> +
> +[1]: Documentation/devicetree/bindings/display/display-timing.txt
This path does not exist.
Also, could you try to align these bindings with the one from raydium,rm68200?
There are power-supply and backlight optional properties there, which
seem useful.
> +
> +Example:
> +
> + panel@0 {
> + compatible = "raydium,rm67191";
> + reg = <0>;
> + pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>;
You should also pass pinctrl-names = "default"; if you use pinctrl-0.
> + reset-gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
Should be active low.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] Re: [PATCH 2/2] drm/panel: Add support for Raydium RM67191 panel driver
On Fri, Jun 14, 2019 at 10:29 AM Robert Chiras wrote: > The GPIO is active high, and the above sequence was received from the > panel vendor in the following form: > SET_RESET_PIN(1); > MDELAY(10); > SET_RESET_PIN(0); > MDELAY(5); > SET_RESET_PIN(1); > MDELAY(20); > I got rid of the first transition to high since seemed redundant. > Also, according to the manual reference, the RSTB pin needs to be > active high while operating the display. That's exactly my point :-) In normal operation the GPIO reset needs to be high. During reset the GPIO reset needs to be low., which means that the GPIO reset is "active low". So you should invert both the dts and the driver to behave correctly.
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
Hi Robert, On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras wrote: > +Optional properties: > +- reset-gpios: a GPIO spec for the RST_B GPIO pin > +- pinctrl-0phandle to the pin settings for the reset pin > +- width-mm:physical panel width [mm] > +- height-mm: physical panel height [mm] > +- display-timings: timings for the connected panel according to [1] Still not convinced we need the 'display-timings' property, even as an optional property. My understanding is that passing display timings in the devicetree is not encouraged. Last time you said you need to pass ''display-timings' to workaround the problem of connecting this panel to mx8m DCSS or eLCDIF. The panel timings come from the LCD manufacturer and it is agnostic to what display controller interface it is connected to. So I suggest making sure the timings passed in the driver are correct as per the vendor datasheet. If they are correct and one specific interface is not able to drive it, then probably it is a bug in this specific display controller interface or in the SoC clock driver.
Re: [PATCH v2 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Robert,
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> +static const struct display_timing rad_default_timing = {
> + .pixelclock = { 6600, 13200, 13200 },
> + .hactive = { 1080, 1080, 1080 },
> + .hfront_porch = { 20, 20, 20 },
> + .hsync_len = { 2, 2, 2 },
> + .hback_porch = { 34, 34, 34 },
> + .vactive = { 1920, 1920, 1920 },
> + .vfront_porch = { 10, 10, 10 },
> + .vsync_len = { 2, 2, 2 },
> + .vback_porch = { 4, 4, 4 },
Are you sure that the sync_len and porch parameters are the same for
both 66MHz and 132MHz?
Re: [PATCH v2 2/2] drm/panel: Add support for Raydium RM67191 panel driver
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,709 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver
Please remove the "i.MX drm driver" as there is nothing i.MX specific
in this driver.
> + *
> + * Copyright 2019 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/* Write Manufacture Command Set Control */
> +#define WRMAUCCTR 0xFE
> +
> +#define COL_FMT_16BPP 0x55
> +#define COL_FMT_18BPP 0x66
> +#define COL_FMT_24BPP 0x77
> +
> +/* Manufacturer Command Set pages (CMD2) */
> +struct cmd_set_entry {
> + u8 cmd;
> + u8 param;
> +};
> +
> +/*
> + * There is no description in the Reference Manual about these commands.
> + * We received them from vendor, so just use them as is.
> + */
> +static const struct cmd_set_entry manufacturer_cmd_set[] = {
> + {0xFE, 0x0B},
> + {0x28, 0x40},
> + {0x29, 0x4F},
> + {0xFE, 0x0E},
> + {0x4B, 0x00},
> + {0x4C, 0x0F},
> + {0x4D, 0x20},
> + {0x4E, 0x40},
> + {0x4F, 0x60},
> + {0x50, 0xA0},
> + {0x51, 0xC0},
> + {0x52, 0xE0},
> + {0x53, 0xFF},
> + {0xFE, 0x0D},
> + {0x18, 0x08},
> + {0x42, 0x00},
> + {0x08, 0x41},
> + {0x46, 0x02},
> + {0x72, 0x09},
> + {0xFE, 0x0A},
> + {0x24, 0x17},
> + {0x04, 0x07},
> + {0x1A, 0x0C},
> + {0x0F, 0x44},
> + {0xFE, 0x04},
> + {0x00, 0x0C},
> + {0x05, 0x08},
> + {0x06, 0x08},
> + {0x08, 0x08},
> + {0x09, 0x08},
> + {0x0A, 0xE6},
> + {0x0B, 0x8C},
> + {0x1A, 0x12},
> + {0x1E, 0xE0},
> + {0x29, 0x93},
> + {0x2A, 0x93},
> + {0x2F, 0x02},
> + {0x31, 0x02},
> + {0x33, 0x05},
> + {0x37, 0x2D},
> + {0x38, 0x2D},
> + {0x3A, 0x1E},
> + {0x3B, 0x1E},
> + {0x3D, 0x27},
> + {0x3F, 0x80},
> + {0x40, 0x40},
> + {0x41, 0xE0},
> + {0x4F, 0x2F},
> + {0x50, 0x1E},
> + {0xFE, 0x06},
> + {0x00, 0xCC},
> + {0x05, 0x05},
> + {0x07, 0xA2},
> + {0x08, 0xCC},
> + {0x0D, 0x03},
> + {0x0F, 0xA2},
> + {0x32, 0xCC},
> + {0x37, 0x05},
> + {0x39, 0x83},
> + {0x3A, 0xCC},
> + {0x41, 0x04},
> + {0x43, 0x83},
> + {0x44, 0xCC},
> + {0x49, 0x05},
> + {0x4B, 0xA2},
> + {0x4C, 0xCC},
> + {0x51, 0x03},
> + {0x53, 0xA2},
> + {0x75, 0xCC},
> + {0x7A, 0x03},
> + {0x7C, 0x83},
> + {0x7D, 0xCC},
> + {0x82, 0x02},
> + {0x84, 0x83},
> + {0x85, 0xEC},
> + {0x86, 0x0F},
> + {0x87, 0xFF},
> + {0x88, 0x00},
> + {0x8A, 0x02},
> + {0x8C, 0xA2},
> + {0x8D, 0xEA},
> + {0x8E, 0x01},
> + {0x8F, 0xE8},
> + {0xFE, 0x06},
> + {0x90, 0x0A},
> + {0x92, 0x06},
> + {0x93, 0xA0},
> + {0x94, 0xA8},
> + {0x95, 0xEC},
> + {0x96, 0x0F},
> + {0x97, 0xFF},
> + {0x98, 0x00},
> + {0x9A, 0x02},
> + {0x9C, 0xA2},
> + {0xAC, 0x04},
> + {0xFE, 0x06},
> + {0xB1, 0x12},
> + {0xB2, 0x17},
> + {0xB3, 0x17},
> + {0xB4, 0x17},
> + {0xB5, 0x17},
> + {0xB6, 0x11},
> + {0xB7, 0x08},
> + {0xB8, 0x09},
> + {0xB9, 0x06},
> + {0xBA, 0x07},
> + {0xBB, 0x17},
> + {0xBC, 0x17},
> + {0xBD, 0x17},
> + {0xBE, 0x17},
> + {0xBF, 0x17},
> + {0xC0, 0x17},
> + {0xC1, 0x17},
> + {0xC2, 0x17},
> + {0xC3, 0x17},
> + {0xC4, 0x0F},
> + {0xC5, 0x0E},
> + {0xC6, 0x00},
> + {0xC7, 0x01},
> + {0xC8, 0x10},
> + {0xFE, 0x06},
> + {0x95, 0xEC},
> + {0x8D, 0xEE},
> + {0x44, 0xEC},
> + {0x4C, 0xEC},
> + {0x32, 0xEC},
> + {0x3A, 0xEC},
> + {0x7D, 0xEC},
> + {0x75, 0xEC},
> + {0x00, 0xEC},
> + {0x08, 0xEC},
> + {0x85, 0xEC},
> + {0xA6, 0x21},
> + {0xA7, 0x05},
> + {0xA9, 0x06},
> + {0x82, 0x06},
> + {0x41, 0x06},
> + {0x7A, 0x07},
> + {0x37, 0x07},
> + {0x05, 0x06},
> + {0x49, 0x06},
> + {0x0D, 0x04},
> + {0x51, 0x04},
> +};
> +
> +static const u32 rad_bus_formats[] = {
> + MEDIA_BUS_FMT_RGB888_1X24,
> + MEDIA_BUS_FMT_RGB666_1X18,
> + MEDIA_BUS_FMT_RGB565_1X16,
> +};
> +
> +struct rad_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> +
> + struct gpio_desc *reset;
> + struct backlight_device *backlight;
> +
> + bool prepared;
> + bool enabled;
> +
> + struct videomode vm;
> + u32 width_mm;
> + u32 height_mm;
> +};
> +
> +st
