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 = _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 = _rtsm,
> + }, {
> + .compatible = "armadeus,st0700-adapt",
> + .data = _st0700_adapt,
> }, {
> .compatible = "auo,b101aw03",
> .data = _b101aw03,
> --
> 2.19.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
On Wed, Jun 26, 2019 at 7:21 AM Robert Chiras wrote: > > Add dt-bindings documentation for Raydium RM67191 DSI panel. > > Signed-off-by: Robert Chiras > Reviewed-by: Sam Ravnborg Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Robert, On Wed, Jun 26, 2019 at 7:21 AM Robert Chiras wrote: > > This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI > protocol). > > Signed-off-by: Robert Chiras > Reviewed-by: Sam Ravnborg Looks good to me: Reviewed-by: Fabio Estevam Thanks
Re: [PATCH] drm/etnaviv: add missing failure path to destroy suballoc
Hi Lucas, On Thu, Jun 27, 2019 at 11:44 AM Lucas Stach wrote: > > When something goes wrong in the GPU init after the cmdbuf suballocator > has been constructed, we fail to destory it properly. This causes havok s/destory/destroy > later when the GPU is unbound due to a module unload or similar. Should this one have a Fixes tag? Thanks ___ 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 3/3] drm/bridge: Add NWL MIPI DSI host controller support
Hi Guido, On Wed, Jul 31, 2019 at 11:35 AM Guido Günther wrote: > The idea is to have > > "%sabling platform clocks", enable ? "en" : "dis"); > > depending whether clocks are enabled/disabled. Yes, I understood the idea, but this would print: ensabling or dissabling :-) > > Same here. Please return 'int' instead. > > This is from drm_bridge_funcs so the prototype is fixed. I'm not sure > how what's the best way to bubble up fatal errors through the drm layer? Ok, so let's not change this one. > I went for DRM_DEV_ERROR() since that what i used in the rest of the > driver and these ones were omission. Hope that's o.k. No strong preferences here. I just think dev_err() easier to type and shorter. Thanks for this work! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Adreno crash on i.MX53 running 5.3-rc6
Hi Jonathan, On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote: > > Hi, > > I tried this and it works with patches 4+5 from Rob's series and > changing gpummu to use sg_phys(sg) instead of sg->dma_address > (dma_address isn't set now that dma_map_sg isn't used). Thanks for testing it. I haven't had a chance to test it yet. Rob, I assume your series is targeted to 5.4, correct? If this is the case, what we should do about the i.MX5 regression on 5.3? Would a revert of the two commits be acceptable in 5.3 in order to avoid the regression? Please advise. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Adreno crash on i.MX53 running 5.3-rc6
Hi Rob, On Tue, Sep 3, 2019 at 9:12 PM Rob Clark wrote: > In the mean time, it is a bit ugly, but I guess something like this should > work: Yes, this works on a i.MX53 board, thanks: Tested-by: Fabio Estevam Is this something you could submit for 5.3? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Adreno crash on i.MX53 running 5.3-rc6
Hi, I am getting the following crash when booting the adreno driver on i.MX53 running a 5.3-rc6 kernel. Such error does not happen with 5.2 though. Before I start running a bisect, I am wondering if anyone has any ideas about this issue. Thanks, Fabio Estevam [2.083249] 8<--- cut here --- [2.086460] Unable to handle kernel paging request at virtual address 50001000 [2.094174] pgd = (ptrval) [2.096911] [50001000] *pgd= [2.100606] Internal error: Oops: 805 [#1] SMP ARM [2.105412] Modules linked in: [2.108487] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4 [2.116411] Hardware name: Freescale i.MX53 (Device Tree Support) [2.122538] PC is at v7_dma_clean_range+0x20/0x38 [2.127254] LR is at __dma_page_cpu_to_dev+0x28/0x90 [2.132226] pc : []lr : []psr: 2013 [2.138500] sp : d80b5a88 ip : de96c000 fp : d840ce6c [2.143732] r10: r9 : 0001 r8 : d843e010 [2.148964] r7 : r6 : 8000 r5 : ddb6c000 r4 : [2.155500] r3 : 003f r2 : 0040 r1 : 50008000 r0 : 50001000 [2.162037] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [2.169180] Control: 10c5387d Table: 70004019 DAC: 0051 [2.174934] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [2.180949] Stack: (0xd80b5a88 to 0xd80b6000) [2.185319] 5a80: c011c7bc d8491780 d840ce6c d849b380 c011822c [2.193509] 5aa0: c0d01a18 c0118abc c0118a78 d84a0200 0008 c1308908 d838e800 d849a4a8 [2.201697] 5ac0: d8491780 c06699b4 d8491600 d80b5b20 d84a0200 [2.209886] 5ae0: d8491780 d8491600 d80b5b20 d8491600 d849a4a8 d84a0200 0003 d84a0358 [2.218077] 5b00: c1308908 d8491600 d849a4a8 d8491780 d840ce6c c066a55c c1308908 c066a104 [2.226266] 5b20: 01001000 d84a0200 10700ac6 d849a480 d84a0200 d8491600 [2.234455] 5b40: e0845000 c1308908 c066a72c d849a480 d840ce6c d840ce00 c1308908 [2.242643] 5b60: c066b584 d849a488 d849a4a8 c1308908 d840ce6c c066ff40 [2.250832] 5b80: d849a488 d849a4a8 c1308908 d81b4000 e0845000 [2.259021] 5ba0: d838e800 c1308908 d8491600 10700ac6 d80b5bc8 d840ce00 d840ce6c 0001 [2.267210] 5bc0: e0845000 d838e800 c066ece4 0100 10ff [2.275399] 5be0: c1308908 0001 d81b4000 0100 0001 10700ac6 [2.283587] 5c00: c0d6d564 d840ce00 d81b4010 0001 d81b4000 c0d6d564 c1308908 d80b5c48 [2.291777] 5c20: d838e800 c061f9cc c1029dec d80b5c48 d838e800 c13e8788 [2.299965] 5c40: c1308928 c102a234 0100 10ff [2.308154] 5c60: 0001 a013 10700ac6 c13b7658 d840ce00 d838e800 d81b4000 [2.316343] 5c80: d840ce00 c1308908 0002 d838f800 c0620514 0001 10700ac6 [2.324531] 5ca0: d8496440 d81b4010 c1aa1c00 d838e800 c061e070 [2.332720] 5cc0: c0d6c534 df56cf34 00c8 10700ac6 d81b4010 [2.340909] 5ce0: d8496440 d838e800 c103acd0 d8496280 c1380488 c06a3e10 [2.349097] 5d00: d838f800 d838e800 d843e010 d8496440 c1308908 [2.357286] 5d20: d83f9640 c1380488 c0668554 0006 0007 c13804d4 d83f9640 [2.365475] 5d40: c1380488 c017ec18 d80c c0c43e40 d843e010 d8496440 0001 c0182a94 [2.373665] 5d60: 6013 10700ac6 d843e010 d8496280 d8496400 0018 d8496440 0001 [2.381854] 5d80: c13804d4 d83f9640 c1380488 c06a4280 c1380488 c0d764f8 d8496440 [2.390044] 5da0: c1380488 d843e010 c0d764f8 c1308908 c13ef300 c06a44f0 [2.398232] 5dc0: c0d8a0dc dffcc6f0 d843e010 dffcc6f0 d843e010 c06680b8 [2.406421] 5de0: d84988c0 d83f9640 d84988c0 d84989a0 d8498230 10700ac6 0001 d843e010 [2.414610] 5e00: c137eec0 c137eec0 c13ef300 c06ac1a0 [2.422799] 5e20: d843e010 c1aa40dc c1aa40e0 c137eec0 c06aa014 d843e010 c137eec0 [2.430988] 5e40: c137eec0 c1308908 c13e9880 c13e85d4 c06aa368 c1308908 c13e9880 [2.439178] 5e60: c13e85d4 d843e010 c137eec0 c1308908 c13e9880 c13e85d4 c06aa618 [2.447367] 5e80: c137eec0 d843e010 c06aa6a4 c137eec0 c06aa620 c06a844c [2.46] 5ea0: d80888d4 d80888a4 d84914d0 10700ac6 d80888d4 c137eec0 d8494f00 c1380d28 [2.463745] 5ec0: c06a946c c105f3d4 c1308908 c137eec0 c1308908 [2.471934] 5ee0: c125fdd0 c06ab304 c1308928 c1308908 c0103178 0109 [2.480123] 5f00: dc6e dc00 c1126860 0109 0109 c014dc88 c11253ac c10607a0 [2.488312] 5f20: 0006 0006 c12adeec dc6e 10700ac6 [2.496501] 5f40: c1308f18 10700ac6 0007 c13e9880 c13ef300 c1294
Re: Adreno crash on i.MX53 running 5.3-rc6
Hi Robin, On Mon, Sep 2, 2019 at 11:45 AM Robin Murphy wrote: > Try 0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG > should have been screaming about anyway. Thanks for your suggestion. I can successfully boot after reverting the following commits: commit 141db5703c887f46957615cd6616ca28fe4691e0 (HEAD) Author: Fabio Estevam Date: Mon Sep 2 14:58:18 2019 -0300 Revert "drm/msm: stop abusing dma_map/unmap for cache" This reverts commit 0036bc73ccbe7e600a3468bf8e8879b122252274. commit fa5b1f620f2984c254877d6049214c39c24c8207 Author: Fabio Estevam Date: Mon Sep 2 14:56:01 2019 -0300 Revert "drm/msm: Use the correct dma_sync calls in msm_gem" This reverts commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c. Rob, What would be the recommended approach for fixing this? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 048c8be426f3..73c79f1614c1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -825,7 +825,7 @@ static int adreno_get_legacy_pwrlevels(struct device *dev)
node = of_get_compatible_child(dev->of_node, "qcom,gpu-pwrlevels");
if (!node) {
- DRM_DEV_ERROR(dev, "Could not find the GPU powerlevels\n");
+ DRM_DEV_DEBUG(dev, "Could not find the GPU powerlevels\n");
return -ENXIO;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
On Wed, Jul 31, 2019 at 1:40 PM Jernej Škrabec wrote: > > Yes, I understood the idea, but this would print: > > > > ensabling or dissabling :-) > > No, it wouldn't. That extra "s" is part of "%s", e.g. part of format > specifier. Ops, you are right. Sorry about that! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: Drop unused imx-ipuv3-crtc.o build
Hi Guido,
Good catch!
On Fri, Aug 2, 2019 at 7:55 AM Guido Günther wrote:
>
> Since
>
> commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one
> module")
>
> imx-ipuv3-crtc.o is built via imxdrm-objs. So there's no need to keep an
Actually, it is ipuv3-crtc.o that is built via imxdrm-objs, not
imx-ipuv3-crtc.o.
Apart from that:
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: mxsfb: add i.MX6UL in Kconfig
Hi Sébastien, On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski wrote: > config DRM_MXSFB > - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller" > + tristate "i.MX23/i.MX28/i.MX6SX/i.MX6UL MXSFB LCD controller" This IP is also found on i.MX6SL, i.MX7D, i.MX7S, i.MX8M, i.MX8QXP, etc I think it would be better if we do not keep increasing the list of supported SoCs in the Kconfig text. What about just having the text like this instead? tristate "MXSFB LCD controller" > depends on DRM && OF > depends on COMMON_CLK > select DRM_MXS > @@ -14,7 +14,7 @@ config DRM_MXSFB > select DRM_KMS_CMA_HELPER > select DRM_PANEL > help > - Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB > + Choose this option if you have an i.MX23/i.MX28/i.MX6SX/i.MX6UL > MXSFB > LCD controller. and here it would become: Choose this option if you want to support the MXSFB LCD controller. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: mxsfb: add i.MX6UL in Kconfig
Hi Sam, On Mon, Jul 29, 2019 at 11:37 AM Sam Ravnborg wrote: > Could we throw a COMPILE_TEST in the mix so we get better build > coverage too? There is no architecture dependency to build this driver, so we already have build coverage for it. Regards, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: Improve the help text for DRM_ANALOGIX_ANX78XX
Improve the help text for DRM_ANALOGIX_ANX78XX by adding the missing "power" word. After this change the help text matches with the ANX7814 product description from the Analogix website: https://www.analogix.com/en/products/convertersbridges/anx7814 Signed-off-by: Fabio Estevam --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index ee777469293a..a6eec908c43e 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -21,7 +21,7 @@ config DRM_ANALOGIX_ANX78XX select DRM_KMS_HELPER select REGMAP_I2C ---help--- - ANX78XX is an ultra-low Full-HD SlimPort transmitter + ANX78XX is an ultra-low power Full-HD SlimPort transmitter designed for portable devices. The ANX78XX transforms the HDMI output of an application processor to MyDP or DisplayPort. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
Hi Guido,
Thanks for your work on this driver!
On Wed, Jul 24, 2019 at 12:52 PM Guido Günther wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx-nwl/Kconfig
> @@ -0,0 +1,15 @@
> +config DRM_IMX_NWL_DSI
> + tristate "Support for Northwest Logic MIPI DSI Host controller"
> + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
This IP could potentially be found on other SoCs, so no need to make
it depend on ARCH_MXC.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
I did not find gpio AP used in this driver.
> +static void imx_nwl_dsi_set_clocks(struct imx_nwl_dsi *dsi, bool enable)
Better make it to return 'int' instead...
> +{
> + struct device *dev = dsi->dev;
> + const char *id;
> + struct clk *clk;
> + unsigned long new_rate, cur_rate;
> + bool enabled;
> + size_t i;
> + int ret;
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "%sabling platform clocks",
Please remove the letter 's' from 'sabling'.
> +enable ? "en" : "dis");
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to enable clock
> %s",
> + id);
and propagate the error in case of clk_prepare_enable() failure.
> + }
> + dsi->clk_config[i].enabled = true;
> + cur_rate = clk_get_rate(clk);
> + DRM_DEV_DEBUG_DRIVER(
> + dev, "Enabled %s clk (rate: req=%lu
> act=%lu)\n",
> + id, new_rate, cur_rate);
> + } else if (enabled) {
> + clk_disable_unprepare(clk);
> + dsi->clk_config[i].enabled = false;
> + DRM_DEV_DEBUG_DRIVER(dev, "Disabled %s clk\n", id);
> + }
> + }
> +}
> +
> +static void imx_nwl_dsi_enable(struct imx_nwl_dsi *dsi)
Same here. Please return 'int' instead.
> +{
> + struct device *dev = dsi->dev;
> + int ret;
> +
> + imx_nwl_dsi_set_clocks(dsi, true);
> +
> + ret = dsi->pdata->poweron(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "Failed to power on DSI (%d)\n", ret);
If the power domain failed to turn on, it is better to propagate the error.
> + phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
> + if (ret < 0) {
This check looks wrong. At this point ret is always 0.
> + DRM_DEV_ERROR(dsi->dev,
> + "Cannot setup PHY for mode: %ux%u @%d Hz\n",
> + adjusted_mode->hdisplay,
> adjusted_mode->vdisplay,
> + adjusted_mode->clock);
> + DRM_DEV_ERROR(dsi->dev, "PHY ref clk: %lu, bit clk: %lu\n",
> + phy_ref_rate, new_cfg.mipi_dphy.hs_clk_rate);
> + } else {
> + /* Save the new desired phy config */
> + memcpy(>phy_cfg, _cfg, sizeof(new_cfg));
> + }
> +
> + /* LCDIF + NWL needs active high sync */
Would this still work if DCSS is used instead?
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> +
> + drm_display_mode_to_videomode(adjusted_mode, >vm);
> + drm_mode_debug_printmodeline(adjusted_mode);
> +
> + return ret == 0;
At this point ret is always 0.
> +static void imx_nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct imx_nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
> + return;
> +
> + imx_nwl_select_input_source(dsi);
This function is i.MX8M specific, so better protect it to run only for
the i.MX8M variant.
> + pm_runtime_get_sync(dsi->dev);
> + imx_nwl_dsi_enable(dsi);
> + nwl_dsi_enable(dsi);
Please check the error and propagate in the case of failure.
> + dsi->dpms_mode = DRM_MODE_DPMS_ON;
> +}
> +
> + dsi->csr = syscon_regmap_lookup_by_phandle(np, "csr");
> + if (IS_ERR(dsi->csr) && dsi->pdata->ext_regs & IMX_REG_CSR) {
> + ret = PTR_ERR(dsi->csr);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get CSR regmap: %d\n",
In this function (and globally in the driver) there is a mix of
DRM_DEV_ERROR() and dev_err().
Can we just pick one of the two and use it consistently?
Not sure what is the norm in drm code, but IMHO dev_err() looks prettier :-)
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(dsi->dev, res);
Could use devm_platform_ioremap_resource(), which makes it simpler.
> +err_cleanup:
> +
[PATCH v2] drm/mxsfb: Remove brackets for single line if block
There is no need for brackets for a single line inside the 'if' block,
so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit log
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b69ace8bf526..bacd1f2b2fb3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -326,11 +326,10 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
if (event) {
crtc->state->event = NULL;
- if (drm_crtc_vblank_get(crtc) == 0) {
+ if (drm_crtc_vblank_get(crtc) == 0)
drm_crtc_arm_vblank_event(crtc, event);
- } else {
+ else
drm_crtc_send_vblank_event(crtc, event);
- }
}
spin_unlock_irq(>dev->event_lock);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mxsfb: Remove brackets for single line if block
There is no need for brackets when for a single line inside
the 'if' block, so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b69ace8bf526..bacd1f2b2fb3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -326,11 +326,10 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
if (event) {
crtc->state->event = NULL;
- if (drm_crtc_vblank_get(crtc) == 0) {
+ if (drm_crtc_vblank_get(crtc) == 0)
drm_crtc_arm_vblank_event(crtc, event);
- } else {
+ else
drm_crtc_send_vblank_event(crtc, event);
- }
}
spin_unlock_irq(>dev->event_lock);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Hi Rob, On Tue, Oct 15, 2019 at 11:19 AM Jeffrey Hugo wrote: > > On Tue, Oct 15, 2019 at 7:40 AM Fabio Estevam wrote: > > > > Booting the adreno driver on a imx53 board leads to the following > > error message: > > > > adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU > > powerlevels > > > > As the "qcom,gpu-pwrlevels" property is optional and never present on > > i.MX5, turn the message into debug level instead. > > > > Signed-off-by: Fabio Estevam > > Seems reasonable. Reviewed-by: Jeffrey Hugo Any comments, please? Just wanted to get rid of this misleading error message on i.MX5. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Hi Jordan, On Fri, Nov 1, 2019 at 11:52 AM Jordan Crouse wrote: > I'm good with this. This really should only be around for > compatibility with downstream device tree files which should mean nothing for > I.MX5. May I resend it with your Reviewed-by tag? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-off-by: Fabio Estevam
Reviewed-by: Jeffrey Hugo
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0783e4b5486a..5d7bdb4c83cc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -826,7 +826,7 @@ static int adreno_get_legacy_pwrlevels(struct device *dev)
node = of_get_compatible_child(dev->of_node, "qcom,gpu-pwrlevels");
if (!node) {
- DRM_DEV_ERROR(dev, "Could not find the GPU powerlevels\n");
+ DRM_DEV_DEBUG(dev, "Could not find the GPU powerlevels\n");
return -ENXIO;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-off-by: Fabio Estevam
Reviewed-by: Jeffrey Hugo
Reviewed-by: Jordan Crouse
---
Trying once again :-)
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0783e4b5486a..5d7bdb4c83cc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -826,7 +826,7 @@ static int adreno_get_legacy_pwrlevels(struct device *dev)
node = of_get_compatible_child(dev->of_node, "qcom,gpu-pwrlevels");
if (!node) {
- DRM_DEV_ERROR(dev, "Could not find the GPU powerlevels\n");
+ DRM_DEV_DEBUG(dev, "Could not find the GPU powerlevels\n");
return -ENXIO;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0783e4b5486a..5d7bdb4c83cc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -826,7 +826,7 @@ static int adreno_get_legacy_pwrlevels(struct device *dev)
node = of_get_compatible_child(dev->of_node, "qcom,gpu-pwrlevels");
if (!node) {
- DRM_DEV_ERROR(dev, "Could not find the GPU powerlevels\n");
+ DRM_DEV_DEBUG(dev, "Could not find the GPU powerlevels\n");
return -ENXIO;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Wed, Oct 23, 2019 at 11:16 AM Adam Ford wrote: > What is the plan to address the regression for 5.4? I wasn't sure if > we're going to apply the i.mx fixes or temporarily revert the > offending patch, or something else. (or maybe nothing at all) Yes, I do see the regression on a imx53 board with 5.4-rc too and also interested on a fix. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm: imx: Add i.MX 6 MIPI DSI host driver
Hi Adrian,
On Mon, Nov 18, 2019 at 12:25 PM Adrian Ratiu
wrote:
Some nitpicks:
> +
> +config DRM_IMX_MIPI_DSI
> + tristate "Freescale i.MX DRM MIPI DSI"
This text seems too generic as there are i.MX SoCs that use different
MIPI DSI IP.
Maybe "Freescale i.MX6 DRM MIPI DSI" instead?
> +module_platform_driver(imx_mipi_dsi_driver);
> +
> +MODULE_DESCRIPTION("i.MX MIPI DSI host controller driver");
i.MX6 MIPI DSI, please.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Use the correct dma_sync calls harder
Hi Rob,
On Wed, Sep 4, 2019 at 2:19 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Looks like the dma_sync calls don't do what we want on armv7 either.
> Fixes:
>
> Unable to handle kernel paging request at virtual address 50001000
> pgd = (ptrval)
> [50001000] *pgd=
> Internal error: Oops: 805 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4
> Hardware name: Freescale i.MX53 (Device Tree Support)
> PC is at v7_dma_clean_range+0x20/0x38
> LR is at __dma_page_cpu_to_dev+0x28/0x90
> pc : []lr : []psr: 2013
> sp : d80b5a88 ip : de96c000 fp : d840ce6c
> r10: r9 : 0001 r8 : d843e010
> r7 : r6 : 8000 r5 : ddb6c000 r4 :
> r3 : 003f r2 : 0040 r1 : 50008000 r0 : 50001000
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 70004019 DAC: 0051
> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>
> Signed-off-by: Rob Clark
> Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem")
> Tested-by: Fabio Estevam
I see this one got applied in linux-next already.
Could it be sent to 5.4-rc, please?
mx53 boards cannot boot in mainline because of this.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Use the correct dma_sync calls harder
Hi Rob, On Tue, Oct 8, 2019 at 8:08 PM Rob Clark wrote: > afaict this should be at least in v5.4-rc2.. am I missing something? You are right, it is in 5.4-rc indeed, sorry. It is 5.3.x stable that has this commit missing, but I guess it will be backported at some point. Thanks!
Re: [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom,gpu-pwrlevels" absence
Hi Rob,
On Tue, Dec 10, 2019 at 8:12 PM Fabio Estevam wrote:
>
> Booting the adreno driver on a imx53 board leads to the following
> error message:
>
> adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
> powerlevels
>
> As the "qcom,gpu-pwrlevels" property is optional and never present on
> i.MX5, turn the message into debug level instead.
>
> Signed-off-by: Fabio Estevam
> Reviewed-by: Jeffrey Hugo
> Reviewed-by: Jordan Crouse
> ---
> Trying once again :-)
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 0783e4b5486a..5d7bdb4c83cc 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -826,7 +826,7 @@ static int adreno_get_legacy_pwrlevels(struct device *dev)
>
> node = of_get_compatible_child(dev->of_node, "qcom,gpu-pwrlevels");
> if (!node) {
> - DRM_DEV_ERROR(dev, "Could not find the GPU powerlevels\n");
> + DRM_DEV_DEBUG(dev, "Could not find the GPU powerlevels\n");
A gentle ping...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: adv7511: Replace hardcoded number
The hardcoded '12' means the number of elements in the
adv7511_csc_ycbcr_to_rgb[] array, so use the ARRAY_SIZE() macro
to let the code less error prone.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..568c6d52cdda 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -132,6 +132,13 @@ static const struct regmap_config adv7511_regmap_config = {
* Hardware configuration
*/
+/* Coefficients for adv7511 color space conversion */
+static const uint16_t adv7511_csc_ycbcr_to_rgb[] = {
+ 0x0734, 0x04ad, 0x, 0x1c1b,
+ 0x1ddc, 0x04ad, 0x1f24, 0x0135,
+ 0x, 0x04ad, 0x087c, 0x1b77,
+};
+
static void adv7511_set_colormap(struct adv7511 *adv7511, bool enable,
const uint16_t *coeff,
unsigned int scaling_factor)
@@ -142,7 +149,7 @@ static void adv7511_set_colormap(struct adv7511 *adv7511,
bool enable,
ADV7511_CSC_UPDATE_MODE, ADV7511_CSC_UPDATE_MODE);
if (enable) {
- for (i = 0; i < 12; ++i) {
+ for (i = 0; i < ARRAY_SIZE(adv7511_csc_ycbcr_to_rgb); ++i) {
regmap_update_bits(adv7511->regmap,
ADV7511_REG_CSC_UPPER(i),
0x1f, coeff[i] >> 8);
@@ -193,13 +200,6 @@ static int adv7511_packet_disable(struct adv7511 *adv7511,
unsigned int packet)
return 0;
}
-/* Coefficients for adv7511 color space conversion */
-static const uint16_t adv7511_csc_ycbcr_to_rgb[] = {
- 0x0734, 0x04ad, 0x, 0x1c1b,
- 0x1ddc, 0x04ad, 0x1f24, 0x0135,
- 0x, 0x04ad, 0x087c, 0x1b77,
-};
-
static void adv7511_set_config_csc(struct adv7511 *adv7511,
struct drm_connector *connector,
bool rgb, bool hdmi_mode)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add Innolux N133HSE panel support
Hi Marek, On Mon, Jan 27, 2020 at 5:16 AM Marek Vasut wrote: > > From: Sean Cross > > The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an > integrated backlight, and connects via eDP. > > It is used in the Kosagi Novena. > > Signed-off-by: Sean Cross > Cc: Shawn Guo > Cc: Fabio Estevam The freescale.com domain is gone for quite some time. Please use nxp.com instead or feste...@gmail.com. Otherwise the patch looks good. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01
Hi Ville,
On Mon, Mar 2, 2020 at 5:36 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Fabio Estevam
> Cc: Sam Ravnborg
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5ce1328fd7dc..6b48c02af112 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3368,7 +3368,7 @@ static const struct panel_desc urt_umsh_8596md_parallel
> = {
> };
>
> static const struct drm_display_mode vl050_8048nt_c01_mode = {
> - .clock = 3,
> + .clock = 34540,
I don't have access to hardware to test this change at the moment, but
looking at the panel datasheet I see that 34.54MHz is still inside the
valid range:
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/21] drm: mxsfb: Add i.MX7 to the list of supported SoCs in Kconfig
Hi Laurent, On Mon, Mar 9, 2020 at 4:53 PM Laurent Pinchart wrote: > config DRM_MXSFB > - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller" > + tristate "i.MX23/i.MX28/i.MX6SX/i.MX7 MXSFB LCD controller" Can't we just make it simpler and write: tristate "i.MX eLCDIF controller" instead? Otherwise this list will get longer each time a new SoC is supported: tristate "i.MX23/i.MX28/i.MX6SX/i.MX6SL/i.MX7/i.MX7ULP/i.MX8M/i.MX8MM/i.MX8QXP/i.MX8M MXSFB LCD controller" and probably more :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-bindings: display: xpp055c272: Remove the reg property
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.example.dts:17.5-29.11:
Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges
property, but no unit name
Fix it by removing the unneeded 'reg' property.
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml| 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
index d9fdb58e06b4..6913923df569 100644
--- a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
+++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
@@ -37,7 +37,6 @@ examples:
dsi {
#address-cells = <1>;
#size-cells = <0>;
-reg = <0xff45 0x1000>;
panel@0 {
compatible = "xinpeng,xpp055c272";
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: ltk500hd1829: Remove the reg property
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11:
Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges
property, but no unit name
Fix it by removing the unneeded 'reg' property.
Fixes: 52120e8c7ae3 ("dt-bindings: display: fix panel warnings")
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
index fd931b293816..b900973b5f7b 100644
--- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
@@ -37,7 +37,6 @@ examples:
dsi {
#address-cells = <1>;
#size-cells = <0>;
-reg = <0xff45 0x1000>;
panel@0 {
compatible = "leadtek,ltk500hd1829";
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/5] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Mon, Mar 30, 2020 at 8:35 AM Adrian Ratiu wrote:
> +panel@0 {
> +compatible = "sharp,ls032b3sx01";
> +reg = <0>;
> +reset-gpios = < 8 GPIO_ACTIVE_LOW>;
> +ports {
> +port@0 {
There is a unit address here without a corresponding reg property.
This gives warning with 'make dt_binding_check'
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/5] drm: imx: Add i.MX 6 MIPI DSI host platform driver
Hi Adrian,
On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu wrote:
>
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
>
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
> Signed-off-by: Liu Ying
>
> - ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
> Signed-off-by: Liu Ying
This one looks like a devicetree patch, but this patch does not touch
devicetree.
> + ret = clk_prepare_enable(dsi->pllref_clk);
> + if (ret) {
> + dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
> + return ret;
> + }
> +
> + dsi->mux_sel = syscon_regmap_lookup_by_phandle(dev->of_node,
> "fsl,gpr");
> + if (IS_ERR(dsi->mux_sel)) {
> + ret = PTR_ERR(dsi->mux_sel);
> + dev_err(dev, "%s: Failed to get GPR regmap: %d\n",
> + __func__, ret);
> + return ret;
You should disable the dsi->pllref_clk clock prior to returning the error.
> + dsi->mipi_dsi = dw_mipi_dsi_probe(pdev, pdata);
> + if (IS_ERR(dsi->mipi_dsi)) {
> + ret = PTR_ERR(dsi->mipi_dsi);
> + dev_dbg(dev, "%s: Unable to probe DW DSI host device: %d\n",
> + __func__, ret);
> + return -ENODEV;
Same here. You should disable the clock. Shouldn't you return 'ret'
here instead of -ENODEV?
> +module_platform_driver(imx_mipi_dsi_driver);
> +
> +MODULE_DESCRIPTION("i.MX6 MIPI DSI host controller driver");
> +MODULE_AUTHOR("Liu Ying ");
The freescale.com domain is no longer functional.
Ying Liu's NXP address is victor@nxp.com. You could probably add
your entry as well.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gpu: msm: possible circular locking dependency detected on 5.5
Hi,
Here is an adreno regression I noticed on imx53 running 5.5.13:
[ 21.283902] ==
[ 21.290148] WARNING: possible circular locking dependency detected
[ 21.296409] 5.5.13 #1 Not tainted
[ 21.299785] --
[ 21.306030] kworker/u2:1/19 is trying to acquire lock:
[ 21.311236] dc888ae8 (reservation_ww_class_mutex){+.+.}, at:
dma_buf_detach+0x78/0x1e0
[ 21.319341]
[ 21.319341] but task is already holding lock:
[ 21.325232] dc88838c (_obj->lock){+.+.}, at:
msm_gem_free_work+0x100/0x188
[ 21.332587]
[ 21.33258[ 32.525073] evbug: Event. Dev: input1, Type: 3, Code:
1, Value: 41
[ 32.531942] evbug: Event. Dev: input1, Type: 0, Code: 0, Value: 0
7] which lock already depends on the new lock.
[ 21.332587]
[ 21.340823]
[ 21.340823] the existing dependency chain (in reverse order) is:
[ 21.348362]
[ 21.348362] -> #1 (_obj->lock){+.+.}:
[ 21.353989]mutex_lock_nested+0x1c/0x24
[ 21.358514]msm_gem_get_and_pin_iova+0x30/0x158
[ 21.363733]msm_ioctl_gem_submit+0xa90/0x1148
[ 21.368775]drm_ioctl_kernel+0xa4/0xec
[ 21.373203]drm_ioctl+0x1e0/0x3c8
[ 21.377215]do_vfs_ioctl+0x9c/0xa68
[ 21.381388]ksys_ioctl+0x34/0x60
[ 21.385304]ret_fast_syscall+0x0/0x28
[ 21.389646]0xbea6f8d8
[ 21.392670]
[ 21.392670] -> #0 (reservation_ww_class_mutex){+.+.}:
[ 21.399333]lock_acquire+0xcc/0x1ec
[ 21.403516]__ww_mutex_lock.constprop.8+0x94/0x10a4
[ 21.409080]ww_mutex_lock+0x78/0xb0
[ 21.413261]dma_buf_detach+0x78/0x1e0
[ 21.417637]drm_prime_gem_destroy+0x2c/0x38
[ 21.422505]msm_gem_free_work+0x88/0x188
[ 21.427133]process_one_work+0x2c4/0x754
[ 21.431744]worker_thread+0x2c/0x590
[ 21.436015]kthread+0x134/0x148
[ 21.439838]ret_from_fork+0x14/0x20
[ 21.444000]0x0
[ 21.446418]
[ 21.446418] other info that might help us debug this:
[ 21.446418]
[ 21.454483] Possible unsafe locking scenario:
[ 21.454483]
[ 21.460460]CPU0CPU1
[ 21.465044]
[ 21.469627] lock(_obj->lock);
[ 21.473190]lock(reservation_ww_class_mutex);
[ 21.480314]lock(_obj->lock);
[ 21.486392] lock(reservation_ww_class_mutex);
[ 21.490996]
[ 21.490996] *** DEADLOCK ***
[ 21.490996]
[ 21.496985] 4 locks held by kworker/u2:1/19:
[ 21.501311] #0: dc43a6a0 ((wq_completion)msm){+.+.}, at:
process_one_work+0x210/0x754
[ 21.509358] #1: dc207f1c
((work_completion)(>free_work)){+.+.}, at:
process_one_work+0x210/0x754
[ 21.518876] #2: dc3a7070 (>struct_mutex){+.+.}, at:
msm_gem_free_work+0x4c/0x188
[ 21.526915] #3: dc88838c (_obj->lock){+.+.}, at:
msm_gem_free_work+0x100/0x188
[ 21.534692]
[ 21.534692] stack backtrace:
[ 21.539136] CPU: 0 PID: 19 Comm: kworker/u2:1 Not tainted 5.5.13 #1
[ 21.545470] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 21.551667] Workqueue: msm msm_gem_free_work
[ 21.556087] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 21.563950] [] (show_stack) from []
(dump_stack+0xe4/0x11c)
[ 21.571372] [] (dump_stack) from []
(check_noncircular+0x130/0x1e4)
[ 21.579486] [] (check_noncircular) from []
(__lock_acquire+0xf58/0x2458)
[ 21.588030] [] (__lock_acquire) from []
(lock_acquire+0xcc/0x1ec)
[ 21.595976] [] (lock_acquire) from []
(__ww_mutex_lock.constprop.8+0x94/0x10a4)
[ 21.605134] [] (__ww_mutex_lock.constprop.8) from
[] (ww_mutex_lock+0x78/0xb0)
[ 21.614207] [] (ww_mutex_lock) from []
(dma_buf_detach+0x78/0x1e0)
[ 21.622239] [] (dma_buf_detach) from []
(drm_prime_gem_destroy+0x2c/0x38)
[ 21.630874] [] (drm_prime_gem_destroy) from []
(msm_gem_free_work+0x88/0x188)
[ 21.639854] [] (msm_gem_free_work) from []
(process_one_work+0x2c4/0x754)
[ 21.648487] [] (process_one_work) from []
(worker_thread+0x2c/0x590)
[ 21.656681] [] (worker_thread) from []
(kthread+0x134/0x148)
[ 21.664176] [] (kthread) from []
(ret_from_fork+0x14/0x20)
[ 21.671470] Exception stack(0xdc207fb0 to 0xdc207ff8)
In order to reproduce it, I just launch kmscube and it starts running normally.
Then I do a "CTRL + C" and the message below appears.
Testing on 5.4.x I don't see this problem.
I haven't started bisecting this yet, but just checking if anyone has
any ideas first.
Thanks,
Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks
Hi Lubomir,
On Wed, May 13, 2020 at 12:08 PM Lubomir Rintel wrote:
> /* Get Clocks: */
> - gpu->clk_reg = devm_clk_get(>dev, "reg");
> + gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
> DBG("clk_reg: %p", gpu->clk_reg);
> if (IS_ERR(gpu->clk_reg))
> - gpu->clk_reg = NULL;
> + return err;
You should return PTR_ERR(gpu->clk_reg) instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks
On Wed, May 13, 2020 at 12:08 PM Lubomir Rintel wrote:
>
> There might be good reasons why the getting a clock failed. To treat the
> clocks as optional we're specifically only interested in ignoring -ENOENT,
> and devm_clk_get_optional() does just that.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index c6dacfe3d321..e7dbb924f576 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1786,26 +1786,26 @@ static int etnaviv_gpu_platform_probe(struct
> platform_device *pdev)
> }
>
> /* Get Clocks: */
> - gpu->clk_reg = devm_clk_get(>dev, "reg");
> + gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
> DBG("clk_reg: %p", gpu->clk_reg);
> if (IS_ERR(gpu->clk_reg))
> - gpu->clk_reg = NULL;
> + return err;
>
> - gpu->clk_bus = devm_clk_get(>dev, "bus");
> + gpu->clk_bus = devm_clk_get_optional(>dev, "bus");
The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
says that only the 'reg' clock could be optional, the others are
required.
> DBG("clk_bus: %p", gpu->clk_bus);
> if (IS_ERR(gpu->clk_bus))
> - gpu->clk_bus = NULL;
> + return err;
>
> - gpu->clk_core = devm_clk_get(>dev, "core");
> + gpu->clk_core = devm_clk_get_optional(>dev, "core");
> DBG("clk_core: %p", gpu->clk_core);
> if (IS_ERR(gpu->clk_core))
> - gpu->clk_core = NULL;
> + return err;
> gpu->base_rate_core = clk_get_rate(gpu->clk_core);
>
> - gpu->clk_shader = devm_clk_get(>dev, "shader");
> + gpu->clk_shader = devm_clk_get_optional(>dev, "shader");
> DBG("clk_shader: %p", gpu->clk_shader);
> if (IS_ERR(gpu->clk_shader))
> - gpu->clk_shader = NULL;
> + return err;
> gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
>
> /* TODO: figure out max mapped size */
> --
> 2.26.2
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks
On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote: > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml > says that only the 'reg' clock could be optional, the others are > required. arch/arm/boot/dts/dove.dtsi only uses the 'core' clock. arch/arm/boot/dts/stm32mp157.dtsi uses 'bus' and 'core' Maybe the binding needs to be updated and it seems that using devm_clk_get_optional() like you propose is safe. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
On Fri, Mar 20, 2020 at 3:49 PM Guido Günther wrote: > > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. > > Signed-off-by: Guido Günther > Tested-by: Robert Chiras > Reviewed-by: Rob Herring > Acked-by: Sam Ravnborg 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] drm/bridge: Add NWL MIPI DSI host controller support
On Fri, Mar 20, 2020 at 3:49 PM Guido Günther wrote: > > This adds initial support for the NWL MIPI DSI Host controller found on > i.MX8 SoCs. > > It adds support for the i.MX8MQ but the same IP can be found on > e.g. the i.MX8QXP. > > It has been tested on the Librem 5 devkit using mxsfb. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Tested-by: Robert Chiras > Tested-by: Martin Kepplinger Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: mxsfb: check framebuffer pitch
Hi Stefan, On Tue, Sep 8, 2020 at 9:56 AM Stefan Agner wrote: > > The lcdif IP does not support a framebuffer pitch (stride) other than > framebuffer width. Check for equality and reject the framebuffer > otherwise. > > This prevents a distorted picture when using 640x800 and running the > Mesa graphics stack. Mesa tires to use a cache aligned stride, which > leads at that particular resolution to width != stride. Currently > Mesa has no fallback behavior, but rejecting this configuration allows > userspace to handle the issue correctly. What about adding a Fixes tag so that it can be backported to old stable kernels? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
imx8m: Failed to attach bridge
Hi Martin and Guido, I am trying to get MIPI DSI panel to work on an imx8mq-evk board. Here are the changes I did against linux-next 20200914 following what was done on imx8mq-librem5-devkit.dts: https://pastebin.com/raw/GXazRyNx The config I am using is this one: https://pastebin.com/raw/UGAjTQyg This is what I see in dmesg: [1.666974] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] *ERROR* failed to attach bridge: -517 [1.667309] sdhci-esdhc-imx 30b5.mmc: Got CD GPIO [1.675977] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 [1.689620] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] *ERROR* failed to attach bridge: -517 [1.692019] mmc0: SDHCI controller on 30b4.mmc [30b4.mmc] using ADMA [1.698606] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 [1.711321] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using ADMA [1.721418] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] *ERROR* failed to attach bridge: -517 [1.730422] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 Any ideas as to what I am missing? Thanks, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imx8m: Failed to attach bridge
On Mon, Sep 14, 2020 at 10:52 AM Fabio Estevam wrote: > > Hi Martin and Guido, > > I am trying to get MIPI DSI panel to work on an imx8mq-evk board. > > Here are the changes I did against linux-next 20200914 following what > was done on imx8mq-librem5-devkit.dts: > https://pastebin.com/raw/GXazRyNx > > The config I am using is this one: > https://pastebin.com/raw/UGAjTQyg > > This is what I see in dmesg: > > [1.666974] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] > *ERROR* failed to attach bridge: -517 > [1.667309] sdhci-esdhc-imx 30b5.mmc: Got CD GPIO > [1.675977] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 > [1.689620] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] > *ERROR* failed to attach bridge: -517 > [1.692019] mmc0: SDHCI controller on 30b4.mmc [30b4.mmc] using > ADMA > [1.698606] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 > [1.711321] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using > ADMA > [1.721418] mxsfb 3032.lcd-controller: [drm:mxsfb_probe] > *ERROR* failed to attach bridge: -517 > [1.730422] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 > > Any ideas as to what I am missing? Nevermind. I got it to work. The 'dsi-lanes' property for the panel was missing. I will submit a patch later. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: cdn-dp-core: Pass __maybe_unused for the suspend()/resume() hooks
When building using a riscv allmodconfig the following build warning is
seen:
drivers/gpu/drm/rockchip/cdn-dp-core.c:1124:12: warning: 'cdn_dp_resume'
defined but not used [-Wunused-function]
Pass __maybe_unused for the suspend()/resume() hooks to fix the build
warning when a defconfig does not select CONFIG_PM_SLEEP.
Reported-by: Olof's autobuilder
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf93f2..18e4de116630 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1107,7 +1107,7 @@ static const struct component_ops cdn_dp_component_ops = {
.unbind = cdn_dp_unbind,
};
-static int cdn_dp_suspend(struct device *dev)
+static int __maybe_unused cdn_dp_suspend(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
int ret = 0;
@@ -1121,7 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
}
-static int cdn_dp_resume(struct device *dev)
+static int __maybe_unused cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: always start/stop scheduler in timeout processing
Hi Lucas,
On Mon, Aug 24, 2020 at 8:02 AM Lucas Stach wrote:
>
> The drm scheduler currently expects that the stop/start sequence is always
> executed in the timeout handling, as the job at the head of the hardware
> execution list is always removed from the ring mirror before the driver
> function is called and only inserted back into the list when starting the
> scheduler.
>
> This adds some unnecessary overhead if the timeout handler determines
> that the GPU is still executing jobs normally and just wished to extend
> the timeout, but a better solution requires a major rearchitecture of the
> scheduler, which is not applicable as a fix.
>
> Fixes: 135517d3565b drm/scheduler: Avoid accessing freed bad job.)
Just a nit: the correct syntax for the Fixes line is:
Fixes: 135517d3565b ("drm/scheduler: Avoid accessing freed bad job.")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: sii902x: Enable I/O and core VCC supplies if present
Hi Alexandre,
On Thu, Sep 24, 2020 at 5:16 PM Alexandru Gagniuc wrote:
> + ret = regulator_enable(sii902x->cvcc12);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable cvcc12 supply: %d\n", ret);
> + regulator_disable(sii902x->iovcc);
> + return PTR_ERR(sii902x->cvcc12);
return ret;
>
> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
> @@ -1012,11 +1052,11 @@ static int sii902x_probe(struct i2c_client *client,
> regmap_read(sii902x->regmap, SII902X_INT_STATUS, );
> regmap_write(sii902x->regmap, SII902X_INT_STATUS, status);
>
> - if (client->irq > 0) {
> + if (sii902x->i2c->irq > 0) {
Unrelated change.
> regmap_write(sii902x->regmap, SII902X_INT_ENABLE,
> SII902X_HOTPLUG_EVENT);
>
> - ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + ret = devm_request_threaded_irq(dev, sii902x->i2c->irq, NULL,
Unrelated change.
sii902x_interrupt,
> IRQF_ONESHOT, dev_name(dev),
> sii902x);
> @@ -1031,9 +1071,9 @@ static int sii902x_probe(struct i2c_client *client,
>
> sii902x_audio_codec_init(sii902x, dev);
>
> - i2c_set_clientdata(client, sii902x);
> + i2c_set_clientdata(sii902x->i2c, sii902x);
Unrelated change.
> - sii902x->i2cmux = i2c_mux_alloc(client->adapter, dev,
> + sii902x->i2cmux = i2c_mux_alloc(sii902x->i2c->adapter, dev,
Unrelated change.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v1 3/3] dt-binding: display: Require two rests on mantix panel
Hi Guido, On Mon, Sep 21, 2020 at 1:56 PM Guido Günther wrote: > > We need to reset both for the panel to show an image. There is a typo in "resets" in the Subject line. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: sun8i-mixer: Remove duplicated 'iommus'
Commit 13871279ff5c ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
introduced a double instance of 'iommus' causing the following build
error with 'make dt_binding_check':
found duplicate key "iommus" with value "{}" (original value: "{}")
in "", line 45, column 3
Remove the double occurrence to fix this problem.
Fixes: 13871279ff5c ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Fabio Estevam
---
.../bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
index c2fbf0b06d32..c040eef56518 100644
---
a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
+++
b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
@@ -42,9 +42,6 @@ properties:
resets:
maxItems: 1
- iommus:
-maxItems: 1
-
ports:
type: object
description: |
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: arm: versatile: Pass the sysreg unit name
Pass the sysreg unit name to fix the following warning seen with
'make dt_binding_check':
Warning (unit_address_vs_reg): /example-0/sysreg: node has a reg or ranges
property, but no unit name
Signed-off-by: Fabio Estevam
---
.../bindings/display/panel/arm,versatile-tft-panel.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
index 41fd5713c156..be69e0cc50fc 100644
---
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
+++
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
@@ -33,7 +33,7 @@ additionalProperties: false
examples:
- |
-sysreg {
+sysreg@0 {
compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
reg = <0x0 0x1000>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel-simple: fix connector type for LogicPD Type28 Display
On Mon, Jun 15, 2020 at 10:19 AM Adam Ford wrote: > > The LogicPD Type28 display used by several Logic PD products has not > worked since v5.5. Maybe you could tell which commit exactly and then put a Fixes tag? ___ 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
[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/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: [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(>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(>panel->desc, edid_quirks,
- DP_DPCD_QUIRK_CONSTANT_N));
+ return (drm_dp_has_quirk(>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 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] 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 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: [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
[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: 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 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
[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
Re: [PATCH] drm/msm: Call shutdown conditionally
00 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
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, _crtc); + bool async; + + if (!kms) + return; + + async = kms->funcs->vsync_time && can_do_async(state, _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
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
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: [RFC PATCH 2/9] drm: bridge: Add Samsung SEC MIPI DSIM bridge driver
Hi Jagan, On Thu, Jun 24, 2021 at 9:32 AM Jagan Teki wrote: > > I had a brief look at the exynos driver, and I think it should be turned > > into a DRM bridge as part of this rework to be used with the i.MX8MM. > > > > Is there someone from Samsung who could assist, at least to test the > > changes ? > > I have hardware to verify it on i.MX8MM but from exynos I don't have > any contact from Samsung to suggest or test. Maybe I can add Tomasz > Figa while sending the changes? Adding Inki Dae and Marek Szyprowski from Samsung who helped to review Michael's series. > I understand that there are 2 key implementations. > > 1. Adjust the exynos_drm_dsi.c by dropping component_ops as i.MX8MM > flow with LCDIF doesn't have component_ops (make sure it works with > exynos platform first) > 2. Sec DSIM Bridge driver common cross Exynos and i.MX8MM platform > drivers or only one Sec DSIM bridge driver to handle both the > platforms by differentiating compatible and driver data > > Any more suggestions would be appreciated? > > Jagan.
Re: [RFC PATCH 2/9] drm: bridge: Add Samsung SEC MIPI DSIM bridge driver
Hi Jagan/Laurent, On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart wrote: > Looking at the register set, it seems to match the Exynos 5433, > supported by drivers/gpu/drm/exynos/exynos_drm_dsi.c. Can we leverage > that driver instead of adding a new one for the same IP core ? Yes. there was an attempt from Michael in this direction: https://patchwork.kernel.org/project/dri-devel/cover/20200911135413.3654800-1-m.tret...@pengutronix.de/ Cheers
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
[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
[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
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
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] 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, _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 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 = _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 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 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
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
[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] 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: 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
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 (>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]register_frame
[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(>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
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
[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
