Re: [PATCH] drm/exynos: fix ref count leak in mic_pre_enable
Hi,
20. 6. 14. 오후 3:23에 Navid Emamdoost 이(가) 쓴 글:
> in mic_pre_enable, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref count before returning.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a86abc173605..69ff74c2ceb5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -270,7 +270,7 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>
> ret = pm_runtime_get_sync(mic->dev);
> if (ret < 0)
> - goto unlock;
> + goto turn_off;
How about just calling pm_runtime_put_noidle()?
if (ret < 0) {
pm_runtime_put_noidle(mic->dev);
goto unlock;
}
Thanks,
Inki Dae
>
> mic_set_path(mic, 1);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: mcde: Fix display initialization problem
On Sun, Jun 14, 2020 at 9:44 AM Sam Ravnborg wrote: > Hi Linus. > > On Sun, Jun 14, 2020 at 12:30:26AM +0200, Linus Walleij wrote: > > The following bug appeared in the MCDE driver/display > > initialization during the recent merge window. > > > > First the place we call drm_fbdev_generic_setup() in the > > wrong place: this needs to be called AFTER calling > > drm_dev_register() else we get this splat: > > > > [ cut here ] > > WARNING: CPU: 0 PID: 1 at ../drivers/gpu/drm/drm_fb_helper.c:2198 > > drm_fbdev_generic_setup+0x164/0x1a8 > > mcde a035.mcde: Device has not been registered. > > Modules linked in: > > Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x9c/0xb0) > > [] (dump_stack) from [] (__warn+0xb8/0xd0) > > [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8) > > [] (warn_slowpath_fmt) from [] > > (drm_fbdev_generic_setup+0x164/0x1a8) > > [] (drm_fbdev_generic_setup) from [] > > (mcde_drm_bind+0xc4/0x160) > > [] (mcde_drm_bind) from [] > > (try_to_bring_up_master+0x15c/0x1a4) > > (...) > > > > Signed-off-by: Linus Walleij > > Yup, this is the right way to do it. > > Reviewed-by: Sam Ravnborg Hm I can't seem to apply these because drm-misc-fixes isn't rebased to v5.8-rc1 or something (wrong ancestor). Does anyone know if ther is a special trick for this or do I need to wait for someone else to rebase that branch? Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: remove unnecessary conversion to bool
On Fri, 2020-06-12 at 20:40 +0800, Bernard Zhao wrote:
> In function mtk_dsi_clk_hs_state, remove unnecessary conversion
> to bool return, this change is to make the code a bit readable.
[]
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
[]
> @@ -319,7 +319,7 @@ static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
> u32 tmp_reg1;
>
> tmp_reg1 = readl(dsi->regs + DSI_PHY_LCCON);
> - return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
> + return ((tmp_reg1 & LC_HS_TX_EN) == 1);
Given:
drivers/gpu/drm/mediatek/mtk_dsi.c:#define LC_HS_TX_EN BIT(0)
This is likely clearer as
return tmp_reg1 & LC_HS_TX_EN;
or even
static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
{
return readl(dsi->regs + DSI_PHY_LCCON) & LC_HS_TX_EN;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204611] amdgpu error scheduling IBs when waking from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=204611 Daniel Parks (danielrpa...@gmail.com) changed: What|Removed |Added CC||danielrpa...@gmail.com --- Comment #11 from Daniel Parks (danielrpa...@gmail.com) --- Created attachment 289653 --> https://bugzilla.kernel.org/attachment.cgi?id=289653=edit 4700u journal I am also affected by this issue on a Dell Inspiron 14 2-in-1 7405 with a Ryzen 7 4700u. I also am willing to help debug and test, but unfortunately I cannot help bisect because amdgpu did not support my gpu at all when the regression occurred. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver
Den 07.06.2020 15.38, skrev Paul Cercueil:
> Hi,
>
> Here's a follow-up on the previous discussion about the current state of
> DSI/DBI panel drivers, TinyDRM, and the need of a cleanup.
>
> This patchset introduces the following:
> * It slightly tweaks the MIPI DSI code so that it supports MIPI DBI over
> various buses. This patch has been tested with a non-upstream DRM
> panel driver for a ILI9331 DBI/8080 panel, written with the DSI
> framework (and doesn't include ), and non-upstream
> DSI/DBI host driver for the Ingenic SoCs.
>
> * A SPI DBI host driver, using the current MIPI DSI framework. It allows
> MIPI DSI/DBI drivers to be written with the DSI framework, even if
> they are connected over SPI, instead of registering as SPI device
> drivers. Since most of these panels can be connected over various
> buses, it permits to reuse the same driver independently of the bus
> used.
>
> * A TinyDRM driver for DSI/DBI panels, once again independent of the bus
> used; the only dependency (currently) being that the panel must
> understand DCS commands.
>
> * A DRM panel driver to test the stack. This driver controls Ilitek
> ILI9341 based DBI panels, like the Adafruit YX240QV29-T 320x240 2.4"
> TFT LCD panel. This panel was converted from
> drivers/gpu/drm/tiny/ili9341.c.
>
> I would like to emphasize that while it has been compile-tested, I did
> not test it with real hardware since I do not have any DBI panel
> connected over SPI. I did runtime-test the code, just without any panel
> connected.
>
> Another thing to note, is that it does not break Device Tree ABI. The
> display node stays the same:
>
> display@0 {
> compatible = "adafruit,yx240qv29", "ilitek,ili9341";
> reg = <0>;
> spi-max-frequency = <3200>;
> dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
> rotation = <270>;
> backlight = <>;
> };
>
> The reason it works, is that the "adafruit,yx240qv29" device is probed
> on the SPI bus, so it will match with the SPI/DBI host driver. This will
> in turn register the very same node with the DSI bus, and the ILI9341
> DRM panel driver will probe. The driver will detect that no controller
> is linked to the panel, and eventually register the DBI/DSI TinyDRM
> driver.
>
> I can't stress it enough that this is a RFC, so it still has very rough
> edges.
>
I don't know bridge and dsi drivers so I can't comment on that, but one
thing I didn't like is that the DT compatible string has to be added to
2 different modules.
As an example, a MI0283QT panel (ILI9341) supports these interface options:
1. SPI
Panel setup/control and framebuffer upload over SPI
2. SPI + DPI
Panel setup/control over SPI, framebuffer scanout over DPI
3. Parallel bus
Panel setup/control and framebuffer upload over parallel bus
My suggestion is to have one panel driver module that can support all of
these like this:
For 1. and 2. a SPI driver is registered and if I understand your
example correctly of_graph_get_port_by_id() can be used during probe to
distinguish between the 2 options and register a full DRM driver for 1.
and add a DRM panel for 2.
For 3. a DSI driver is registered (adapted for DBI use like you're
suggesting).
Note that the interface part of the controller initialization will
differ between these, the panel side init will be the same I assume.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Hi Maxime, Am 11.06.20 um 15:34 schrieb Maxime Ripard: > Hi Stefan, > > On Sat, Jun 06, 2020 at 10:06:12AM +0200, Stefan Wahren wrote: >> Hi Maxime, >> >> Am 05.06.20 um 16:35 schrieb Maxime Ripard: >>> Hi Stefan, >>> >>> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote: Am 02.06.20 um 17:54 schrieb Maxime Ripard: FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. Here are the bisect results: 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good 2c6a651cac6359cb0244a40d3b7a14e72918f169 good 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat) 601527fea6bb226abd088a864e74b25368218e87 good 2165607ede34d229d0cbce916c70c7fb6c0337be good f094f388fc2df848227e2ae648df2c97872df42b good 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat) 4c4da3823e4d1a8189e96a59a79451fff372f70b good 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit commit 020de18840a1075b2671736c6cc2e451030fad74 Author: Maxime Ripard Date: Mon Jan 6 17:17:29 2020 +0100 drm/vc4: hdmi: rework connectors and encoders the vc4_hdmi driver has some custom structures to hold the data it needs to associate with the drm_encoder and drm_connector structures. However, it allocates them separately from the vc4_hdmi structure which makes it more complicated than it needs to be. Move those structures to be contained by vc4_hdmi and update the code accordingly. Signed-off-by: Maxime Ripard >>> So it looks like there was two issues on the Pi3. The first one was >>> causing the timeouts (and therefore likely the black screen but >>> heartbeat case you had) and I've fixed it. >>> >>> However, I can indeed reproduce the case with the black screen / no >>> heartbeat you mentionned. My bisection however returns that it's the >>> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault. >>> I've pushed my updated branch, if you have some spare time, it would be >>> great if you could confirm it on your Pi. >> yesterday i checked out your latest rpi4-kms branch, but i was still >> facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig >> (heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i >> tried to bisect but the offending commit didn't cause an issue the >> second time. >> >> By accident i noticed that a simple reboot seems to hang for at least 8 >> minutes (using b0523c7b1c9d0edcd the base of your branch). This usually >> take a few seconds. So i consider this base on linux-next as too >> unstable for reliable testing. >> >> Is it possible to rebase this on something more stable like linux-5.7 or >> at least drm-misc-next? This should avoid chasing unrelated issues. > I've rebased it on 5.7 here: > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms-5.7 > > And it looks to be indeed an issue coming from next. That branch can > start the desktop just fine on an RPi3 here. It would be great if you > could confirm on your end. > > Thanks! > Maxime thank you very much. The good news are that the "black screen, but heartbeat" issue and reboot hang are gone. Unfortunately the "no heartbeat" issue is still there. Here are more details about the issue. It doesn't occur everytime. I would guess the probability is about 40 percent, which made bisecting much harder. It is reproducible on my 2 Raspberry Pi 3 B Rev 1.2. It is also seems independent from the display because the problem occured on my Computer display and my TV. Yes, i can confirm that i was able to bisect the issue to this commit: commit 7b7e335f98c6f3199dcc7db83469dccac66dca1e Author: Maxime Ripard Date: Tue May 12 11:36:13 2020 +0200 drm/vc4: hdmi: Implement finer-grained hooks In order to prevent some pixels getting stuck in an unflushable FIFO on bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI controller (the encoder) in an intertwined way, and with tight delays. However, the atomic callbacks don't really provide a way to work with either constraints, so we need to roll our own callbacks so that we can provide those guarantees. Since those callbacks have been implemented and called in the CRTC code, we can just implement them in the HDMI driver now. Signed-off-by: Maxime Ripard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: fix reference count leaks due to pm_runtime_get_sync()
Hi Aditya,
(CC'ing Rafael)
Thank you for the patch.
On Sat, Jun 13, 2020 at 09:40:05PM -0500, Aditya Pakki wrote:
> On calling pm_runtime_get_sync() the reference count of the device
> is incremented. In case of failure, decrement the
> reference count before returning the error.
>
> Signed-off-by: Aditya Pakki
I've seen lots of similar patches recently. Instead of mass-patching the
drivers this way, shouldn't pm_runtime_get_sync() (and similar
functions) decrease the refcount on their failure path ? That would
require patching drivers that already handle this issue, but I believe
that would cause less churn, and more importantly, avoid the issue once
and for good for new code.
> ---
> drivers/gpu/drm/bridge/cdns-dsi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 69c3892caee5..583cb8547106 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -788,8 +788,10 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> u32 tmp, reg_wakeup, div;
> int nlanes;
>
> - if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
> + if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0)) {
> + pm_runtime_put(dsi->base.dev);
> return;
> + }
>
> mode = >encoder->crtc->state->adjusted_mode;
> nlanes = output->dev->lanes;
> @@ -1028,8 +1030,10 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host
> *host,
> int ret, i, tx_len, rx_len;
>
> ret = pm_runtime_get_sync(host->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put(host->dev);
> return ret;
> + }
>
> cdns_dsi_init_link(dsi);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: fix ref count leak in vc4_dsi_encoder_enable
On Sun, Jun 14, 2020 at 9:55 AM Navid Emamdoost wrote: > > in vc4_dsi_encoder_enable, the call to pm_runtime_get_sync increments > the counter even in case of failure, leading to incorrect > ref count. In case of failure, decrement the ref count before returning. ... > +out: > + pm_runtime_put(dev); Better to use pm_runtime_put_noidle() for error case. And here is a change of semantics, i.e. before your patch there was no put at all. How did you test this? -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: fix ref count leak via pm_runtime_get_sync
On Sun, Jun 14, 2020 at 9:48 AM Navid Emamdoost
wrote:
...
> + if (ret < 0) {
> + pm_runtime_put(gpu->dev);
Please, in all your patches fix this to be _put_noidle(). We wouldn't
bear the flag day of fixing these parts again.
Yes, I know that *now* behaviour is the same, but calling put here is
slightly inconsistent.
...
> + pm_runtime_put(gpu->dev);
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: mcde: Fix forgotten user of drm->dev_private
On Sun, Jun 14, 2020 at 12:30:27AM +0200, Linus Walleij wrote:
> We forgot one call site directly using drm->dev_private.
> This leads to a crash like this:
>
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 0918
> pgd = (ptrval)
> [0918] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-15001-gfa384b50b96b-dirty #514
> Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
> PC is at mcde_display_enable+0x78/0x7c0
> LR is at mcde_display_enable+0x78/0x7c0
>
> Fix this by using to_mcde() as in other functions.
>
> Cc: Daniel Vetter
> Fixes: fd7ee85cfe7b ("drm/mcde: Don't use drm_device->dev_private")
> Signed-off-by: Linus Walleij
This is the last hit for "git grep dev_private".
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/mcde/mcde_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_display.c
> b/drivers/gpu/drm/mcde/mcde_display.c
> index b319a474f801..212aee60cf61 100644
> --- a/drivers/gpu/drm/mcde/mcde_display.c
> +++ b/drivers/gpu/drm/mcde/mcde_display.c
> @@ -838,7 +838,7 @@ static void mcde_display_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc *crtc = >crtc;
> struct drm_plane *plane = >plane;
> struct drm_device *drm = crtc->dev;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> const struct drm_display_mode *mode = >mode;
> struct drm_framebuffer *fb = plane->state->fb;
> u32 format = fb->format->format;
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: mcde: Fix display initialization problem
Hi Linus. On Sun, Jun 14, 2020 at 12:30:26AM +0200, Linus Walleij wrote: > The following bug appeared in the MCDE driver/display > initialization during the recent merge window. > > First the place we call drm_fbdev_generic_setup() in the > wrong place: this needs to be called AFTER calling > drm_dev_register() else we get this splat: > > [ cut here ] > WARNING: CPU: 0 PID: 1 at ../drivers/gpu/drm/drm_fb_helper.c:2198 > drm_fbdev_generic_setup+0x164/0x1a8 > mcde a035.mcde: Device has not been registered. > Modules linked in: > Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x9c/0xb0) > [] (dump_stack) from [] (__warn+0xb8/0xd0) > [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8) > [] (warn_slowpath_fmt) from [] > (drm_fbdev_generic_setup+0x164/0x1a8) > [] (drm_fbdev_generic_setup) from [] > (mcde_drm_bind+0xc4/0x160) > [] (mcde_drm_bind) from [] > (try_to_bring_up_master+0x15c/0x1a4) > (...) > > Signed-off-by: Linus Walleij Yup, this is the right way to do it. Reviewed-by: Sam Ravnborg One small thing to consider, see below. But for another patch. > --- > drivers/gpu/drm/mcde/mcde_drv.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c > index 84f3e2dbd77b..80082d6dce3a 100644 > --- a/drivers/gpu/drm/mcde/mcde_drv.c > +++ b/drivers/gpu/drm/mcde/mcde_drv.c > @@ -209,7 +209,6 @@ static int mcde_modeset_init(struct drm_device *drm) > > drm_mode_config_reset(drm); > drm_kms_helper_poll_init(drm); > - drm_fbdev_generic_setup(drm, 32); > > return 0; > } > @@ -264,6 +263,8 @@ static int mcde_drm_bind(struct device *dev) > if (ret < 0) > goto unbind; > > + drm_fbdev_generic_setup(drm, 32); Consider using mode_config.preferred_depth, then you can pass 0 here. > + > return 0; > > unbind: > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v16 1/1] dt-bindings: display: mediatek: convert the dpi bindings to yaml
Convert display/mediatek/mediatek,dpi.txt to display/mediatek/mediatek,dpi.yaml
and remove the old text bindings.
Signed-off-by: Jitao Shi
---
.../display/mediatek/mediatek,dpi.txt | 42
.../display/mediatek/mediatek,dpi.yaml| 97 +++
2 files changed, 97 insertions(+), 42 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
deleted file mode 100644
index 77def4456706..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek DPI Device
-===
-
-The Mediatek DPI function block is a sink of the display subsystem and
-provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
-output bus.
-
-Required properties:
-- compatible: "mediatek,-dpi"
- the supported chips are mt2701 , mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "engine", and "pll"
-- port: Output port node with endpoint definitions as described in
- Documentation/devicetree/bindings/graph.txt. This port should be connected
- to the input port of an attached HDMI or LVDS encoder chip.
-
-Optional properties:
-- pinctrl-names: Contain "default" and "sleep".
-
-Example:
-
-dpi0: dpi@1401d000 {
- compatible = "mediatek,mt8173-dpi";
- reg = <0 0x1401d000 0 0x1000>;
- interrupts = ;
- clocks = < CLK_MM_DPI_PIXEL>,
-< CLK_MM_DPI_ENGINE>,
-< CLK_APMIXED_TVDPLL>;
- clock-names = "pixel", "engine", "pll";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <_pin_func>;
- pinctrl-1 = <_pin_idle>;
-
- port {
- dpi0_out: endpoint {
- remote-endpoint = <_in>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
new file mode 100644
index ..860b719b5dc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: mediatek DPI Controller Device Tree Bindings
+
+maintainers:
+ - CK Hu
+ - Jitao shi
+
+description: |
+ The Mediatek DPI function block is a sink of the display subsystem and
+ provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
+ output bus.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt2701-dpi
+ - mediatek,mt8173-dpi
+ - mediatek,mt8183-dpi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Pixel Clock
+ - description: Engine Clock
+ - description: DPI PLL
+
+ clock-names:
+items:
+ - const: pixel
+ - const: engine
+ - const: pll
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+items:
+ - const: default
+ - const: sleep
+
+ port:
+type: object
+description:
+ Output port node with endpoint definitions as described in
+ Documentation/devicetree/bindings/graph.txt. This port should be
connected
+ to the input port of an attached HDMI or LVDS encoder chip.
+
+properties:
+ endpoint:
+type: object
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+dpi0: dpi@1401d000 {
+compatible = "mediatek,mt8173-dpi";
+reg = <0 0x1401d000 0 0x1000>;
+interrupts = ;
+clocks = < CLK_MM_DPI_PIXEL>,
+ < CLK_MM_DPI_ENGINE>,
+ < CLK_APMIXED_TVDPLL>;
+clock-names = "pixel", "engine", "pll";
+pinctrl-names = "default", "sleep";
+pinctrl-0 = <_pin_func>;
+pinctrl-1 = <_pin_idle>;
+
+port {
+dpi0_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+...
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v16 0/1] mt8183 dpi support pin mode swap
Changes since v15: - Fix YAML License to (GPL-2.0-only OR BSD-2-Clause). - "dt-bindings: display: mediatek: control dpi pins mode to avoid leakage" "drm/mediatek: set dpi pin mode to gpio low to avoid leakage current" applied v15. The links are https://patchwork.kernel.org/patch/11489545/ https://patchwork.kernel.org/patch/11489577/ Changes since v14: - add "Acked-by" and "Reviewed-by" - change port@0 to port in yaml Changes since v13: - move dpi dual edge patches to another series because it will have long time to implement the dual edge change base boris patches. https://patchwork.kernel.org/cover/11354279/ Changes since v12: - fix mediatek,dpi.yaml make_dt_binding_check errors. Change since v11: - fine tune mediatek,dpi.yaml. - add Acked-by: Rob Herring . Change since v10: - convert the Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt to yaml format. - read the pclk-sample in endpoint. Changes since v9: - rename pinctrl-names = "gpiomode", "dpimode" to "active", "idle". - fix some typo. Changes since v8: - drop pclk-sample redefine in mediatek,dpi.txt - only get the gpiomode and dpimode when dpi->pinctrl is successful. Changes since v7: - separate dt-bindings to independent patches. - move dpi dual edge to one patch. Changes since v6: - change dual_edge to pclk-sample - remove dpi_pin_mode_swap and Changes since v5: - fine tune the dt-bindings commit message. Changes since v4: - move pin mode control and dual edge control to deveice tree. - update dt-bindings document for pin mode swap and dual edge control. Changes since v3: - add dpi pin mode control when dpi on or off. - update dpi dual edge comment. Changes since v2: - update dt-bindings document for mt8183 dpi. - separate dual edge modfication as independent patch. Jitao Shi (1): dt-bindings: display: mediatek: convert the dpi bindings to yaml .../display/mediatek/mediatek,dpi.txt | 42 .../display/mediatek/mediatek,dpi.yaml| 97 +++ 2 files changed, 97 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
