Introduction and queries
I think my first email got blocked if I understand the archives correctly. Hello everyone, I am Suyash Singh from India. I am a second year undergraduate computer science student. I want to participate in Xorg EVOC. As I see on https://www.x.org/wiki/SummerOfCodeIdeas/ most of the projects are done with C/C++ both of which have been a major part of my curriculum for the last 4 years (school + college). 1) Which ones are the preferred/important projects? 2) How do I begin understanding the project? 3) What do I need to learn? My resume: https://drive.google.com/drive/u/0/folders/1j28k6LAlGMrMO5NkQ9KspW3lo8DOUY8C ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ
Hi, On Fri, Jul 17, 2020 at 09:48:49PM +0200, Sam Ravnborg wrote: > Hi Laurentiu. > > On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > > Some of its capabilities include: > > * 4K@60fps; > > * HDR10; > > * one graphics and 2 video pipelines; > > * on-the-fly decompression of compressed video and graphics; > > > > The reference manual can be found here: > > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > > > The current patch adds only basic functionality: one primary plane for > > graphics, linear, tiled and super-tiled buffers support (no graphics > > decompression yet), no HDR10 and no video planes. > > > > Video planes support and HDR10 will be added in subsequent patches once > > per-plane de-gamma/CSC/gamma support is in. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Lucas Stach > > --- > > > return drm_bridge_attach(encoder, bridge, NULL, 0); > > > The above code-snippet tells that the display-driver rely on the bridge > to create the connector. > Could this by any chance be updated to the new way where the display > driver creates the connector - and thus passing DRM_BRIDGE_ATTACH_NO_CONNECTOR > as the flags argument? > > What bridges would be relevant? > To check that the reelvant bridges are already ported. I think that's mostly NWL atm since MHDP isn't mainline yet. Can you recommend a bridge driver to look at that does this right? Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ
On Sat, Jul 18, 2020 at 01:05:25PM +0200, Guido Günther wrote: > Hi, > On Fri, Jul 17, 2020 at 09:48:49PM +0200, Sam Ravnborg wrote: > > Hi Laurentiu. > > > > On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote: > > > From: Laurentiu Palcu > > > > > > This adds initial support for iMX8MQ's Display Controller Subsystem > > > (DCSS). > > > Some of its capabilities include: > > > * 4K@60fps; > > > * HDR10; > > > * one graphics and 2 video pipelines; > > > * on-the-fly decompression of compressed video and graphics; > > > > > > The reference manual can be found here: > > > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > > > > > The current patch adds only basic functionality: one primary plane for > > > graphics, linear, tiled and super-tiled buffers support (no graphics > > > decompression yet), no HDR10 and no video planes. > > > > > > Video planes support and HDR10 will be added in subsequent patches once > > > per-plane de-gamma/CSC/gamma support is in. > > > > > > Signed-off-by: Laurentiu Palcu > > > Reviewed-by: Lucas Stach > > > --- > > > > > > return drm_bridge_attach(encoder, bridge, NULL, 0); > > > > > > The above code-snippet tells that the display-driver rely on the bridge > > to create the connector. > > Could this by any chance be updated to the new way where the display > > driver creates the connector - and thus passing > > DRM_BRIDGE_ATTACH_NO_CONNECTOR > > as the flags argument? > > > > What bridges would be relevant? > > To check that the reelvant bridges are already ported. > > I think that's mostly NWL atm since MHDP isn't mainline yet. Can you > recommend a bridge driver to look at that does this right? Hi Guido. The following is from my notes: bridge/adv7511 done bridge/simple-bridge done bridge/synopsys/dw-hdmidone bridge/display-connector.c done bridge/lvds-codec done bridge/cdns-dsidone bridge/panel.c done bridge/parade-ps8640 done bridge/sil-sii8620 done bridge/synopsys/dw-mipi-dsidone bridge/tc358768done bridge/thc63lvd1024done bridge/ti-tfp410 done This is a list of bridge drivers which are converted and in drm-misc-next now. I have a patch set that converts some more but they needs a bit more polishing before they are done. Laurent has written about is in a very comprehensive way several times. The short variant is that we needed to support chained bridges where the individual bridges implemented the functions required by the connector - and creating the connector was pushed back to the display driver. So the bridges now announce their support of for example hot-plug detect and reading edid. Then the connector, created by the display driver, can use the operations exported by the bridge drivers. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: core: Convert device logging to drm_* functions.
Hi Suraj.
On Sat, Jul 18, 2020 at 08:25:31PM +0530, Suraj Upadhyay wrote:
> Convert device logging with dev_* functions into drm_* functions.
>
> The patch has been generated with the coccinelle script below.
> The script focuses on instances of dev_* functions where the drm device
> context is clearly visible in its arguments.
>
> @@expression E1; expression list E2; @@
> -dev_warn(E1->dev, E2)
> +drm_warn(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_info(E1->dev, E2)
> +drm_info(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_err(E1->dev, E2)
> +drm_err(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_info_once(E1->dev, E2)
> +drm_info_once(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_notice_once(E1->dev, E2)
> +drm_notice_once(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_warn_once(E1->dev, E2)
> +drm_warn_once(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_err_once(E1->dev, E2)
> +drm_err_once(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_err_ratelimited(E1->dev, E2)
> +drm_err_ratelimited(E1, E2)
>
> @@expression E1; expression list E2; @@
> -dev_dbg(E1->dev, E2)
> +drm_dbg_(E1, E2)
>
> Signed-off-by: Suraj Upadhyay
> ---
> drivers/gpu/drm/drm_edid.c | 6 ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
> drivers/gpu/drm/drm_mipi_dbi.c | 7 +++
> 3 files changed, 7 insertions(+), 10 deletions(-)
Looks good, coccinelle is a reliable way for such mass conversion.
When converting to new style logging then all logging should be
converted in a file. Maybe, if too much, split in two patches.
But for all three files there are logging remaining to be converted
so we would end up in several patch-sets before done.
Please try to extend the scripting to also cover DRM_ => drm_ logging.
You may need some manual adjustments to cover it all.
Sam
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 52b357e75c3d..6840f0530a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector
> *connector,
> if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
> return;
>
> - dev_warn(connector->dev->dev,
> - "%s: EDID is invalid:\n",
> - connector->name);
> + drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
> for (i = 0; i < num_blocks; i++) {
> u8 *block = edid + i * EDID_LENGTH;
> char prefix[20];
> @@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector,
> struct edid *edid)
> }
> if (!drm_edid_is_valid(edid)) {
> clear_eld(connector);
> - dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> + drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
> return 0;
> }
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 06a5b9ee1fe0..8d7408a78aee 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
> GFP_KERNEL | __GFP_NOWARN);
> if (!cma_obj->vaddr) {
> - dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
> - size);
> + drm_dbg_(drm, "failed to allocate buffer with size %zu\n",
> + size);
> ret = -ENOMEM;
> goto error;
> }
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 0e55d8716e3d..a7a611894243 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
> break;
> default:
> - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> - drm_get_format_name(fb->format->format,
> - &format_name));
> + drm_err_once(fb->dev, "Format is not supported: %s\n",
> + drm_get_format_name(fb->format->format,
> &format_name));
> return -EINVAL;
> }
>
> @@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> width * height * 2);
> err_msg:
> if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> ret);
> + drm_err_once(fb->dev, "Failed to update display %d\n", ret);
>
> drm_dev_exit(idx);
> }
> --
> 2.17.1
Re: [PATCH v3] drm/kmb: Add support for KeemBay Display
Hi Anitha.
A few extra details.
> diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
> new file mode 100644
> index 000..570d46e
> --- /dev/null
> +++ b/drivers/gpu/drm/kmb/kmb_crtc.c
> @@ -0,0 +1,219 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright © 2018-2020 Intel Corporation
> + */
> +
> +#include
> +#include
Not used, can be dropped. Gos for all includes except the one in
kmb_drv.c
> +#include
Not used, can be dropped. Goes for all include of this file.
> + /* disable vertical interrupt */
> + kmb_clr_bitmask_lcd(dev_p, LCD_INT_ENABLE,
> + LCD_INT_VERT_COMP);
> +}
> +
> +static const struct drm_crtc_funcs kmb_crtc_funcs = {
> + .destroy = kmb_crtc_cleanup,
> + .set_config = drm_atomic_helper_set_config,
>From the description of set_config:
* Drivers implementing atomic modeset should use
* drm_atomic_helper_set_config() to implement this hook.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: Fix example in nwl-dsi.yaml
Hi,
On Fri, Jul 03, 2020 at 01:47:16PM +0200, Ondrej Jirman wrote:
> The example is now validated against rocktech,jh057n00900 schema
> that was ported to yaml, and didn't validate with:
>
> - '#address-cells', '#size-cells', 'port@0' do not match any of
> the regexes: 'pinctrl-[0-9]+'
> - 'vcc-supply' is a required property
> - 'iovcc-supply' is a required property
> - 'reset-gpios' is a required property
>
> Fix it.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> index 8aff2d68fc33..2c4c34e3bc29 100644
> --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -165,6 +165,7 @@ examples:
> - |
>
> #include
> + #include
> #include
> #include
>
> @@ -191,12 +192,12 @@ examples:
>phy-names = "dphy";
>
>panel@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
>compatible = "rocktech,jh057n00900";
>reg = <0>;
> - port@0 {
> - reg = <0>;
> + vcc-supply = <®_2v8_p>;
> + iovcc-supply = <®_1v8_p>;
> + reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
> + port {
> panel_in: endpoint {
> remote-endpoint = <&mipi_dsi_out>;
> };
Reviewed-by: Guido Günther
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-binding: display: Allow a single port node on rocktech,jh057n00900
Hi, On Fri, Jul 03, 2020 at 01:47:17PM +0200, Ondrej Jirman wrote: > The display has one port. Allow it in the binding. > > Signed-off-by: Ondrej Jirman > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index a6985cd947fb..d5733ef30954 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -24,6 +24,7 @@ properties: > # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel >- xingbangda,xbd599 > > + port: true >reg: > maxItems: 1 > description: DSI virtual channel Reviewed-by: Guido Günther -- Guido > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mxsfb: Make supported modifiers explicit
Hi,
On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
> > In contrast to other display controllers on imx like DCSS and ipuv3
> > lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
> > Since mesa might assume otherwise make it explicit that only
> > DRM_FORMAT_MOD_LINEAR is supported.
> >
> > Signed-off-by: Guido Günther
>
> Reviewed-by: Lucas Stach
Can i do anything to get this applied?
Cheers,
-- Guido
>
> > ---
> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > index 762379530928..fc71e7a7a02e 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > @@ -73,6 +73,11 @@ static const uint32_t mxsfb_formats[] = {
> > DRM_FORMAT_RGB565
> > };
> >
> > +static const uint64_t mxsfb_modifiers[] = {
> > + DRM_FORMAT_MOD_LINEAR,
> > + DRM_FORMAT_MOD_INVALID
> > +};
> > +
> > static struct mxsfb_drm_private *
> > drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> > {
> > @@ -334,8 +339,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> > long flags)
> > }
> >
> > ret = drm_simple_display_pipe_init(drm, &mxsfb->pipe, &mxsfb_funcs,
> > - mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
> > - mxsfb->connector);
> > + mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
> > + mxsfb_modifiers, mxsfb->connector);
> > if (ret < 0) {
> > dev_err(drm->dev, "Cannot setup simple display pipe\n");
> > goto err_vblank;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi, On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote: > Hi Guido, > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote: > > Hi Ondrej, > > On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > > > When extending the driver for xbd599 panel support I tried to do minimal > > > changes and keep the existing initialization timing. > > > > > > It turned out that it's not good enough and the existing init sequence > > > is too aggressive and doesn't follow the specification. On PinePhone > > > panel is being powered down/up during suspend/resume and with current > > > timings this frequently leads to corrupted display. > > > > Given the amount of ST7703 look alikes i don't think you can go by the > > datasheet and hope not to break other panels. The current sleeps cater > > for the rocktech panel (which suffered from similar issues you describe > > when we took other parameters) so you need to make those panel specific. > > It should work on rocktech too. The patch mostly increases/reorders the delays > slightly, to match the controller documentation. I don't see a reason to > complicate the driver with per panel special delays, unless these patches > don't > work on your panel. That's why i brought it up. It breaks the rocktech panel on blank/unblank loops where it just stays blank and then starts hitting DSI command timeouts. Cheers, -- Guido > > The init sequence is still suboptimal, and doesn't follow the kernel docs > completely, even after these patches. Controller spec also talks about adding > some delay before enabling the backlight to avoid visual glitches. > > Which is what enable callback is documented to be for. Currently part of the > initialization that belongs to prepare callback is also done in enable > callback. > > I see the glitch (small vertical shift of the image on powerup), but > personally > don't care much to introduce even more delays to the driver, just for the > cosmetic issue. > > regards, > o. > > > Cheers, > > -- Guido > > > > > > > > This patch series fixes the problems. > > > > > > The issue was reported by Samuel Holland. > > > > > > Relevant screenshots from the datasheet: > > > > > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > > > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > > > More optimal reset on poweron: > > > https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > > > Less optimal reset on poweron: > > > https://megous.com/dl/tmp/246761039283c4cf.png > > > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > > > > > Please take a look. > > > > > > thank you and regards, > > > Ondrej Jirman > > > > > > Ondrej Jirman (2): > > > drm/panel: st7703: Make the sleep exit timing match the spec > > > drm/panel: st7703: Fix the power up sequence of the panel > > > > > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 ++- > > > 1 file changed, 15 insertions(+), 14 deletions(-) > > > > > > -- > > > 2.27.0 > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check.
We don't create a connector but let panel_bridge handle that so there's
no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/nwl-dsi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 77a79af70914..ce94f797d090 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -918,11 +918,6 @@ static int nwl_dsi_bridge_attach(struct drm_bridge *bridge,
struct drm_panel *panel;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, &panel,
&panel_bridge);
if (ret)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check.
We don't create a connector but let panel_bridge handle that so there's no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR. This was prompted by Sam in https://lore.kernel.org/dri-devel/20200718115734.ga2989...@ravnborg.org/ Signed-off-by: Guido Günther Guido Günther (1): drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check. drivers/gpu/drm/bridge/nwl-dsi.c | 5 - 1 file changed, 5 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208333] Black screen with Kernel 5.8 rc1/2/3/4 with Nvidia Gtx 760 driver nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=208333 --- Comment #9 from Nathan Bryant (nbry...@optonline.net) --- I'm seeing similar symptoms on my Geforce GTX 1070 (GP104). Screen blanks after GDM login, Wayland works, Xorg doesn't. This is a regression from 5.7 to 5.8-rc1. As long as I only have my primary monitor connected, after the failure I can still switch to another VT with Ctrl-Alt-F3 and log in to the text console. ~/.local/share/xorg/Xorg.0.log has a few of these: [17.240] (EE) modeset(0): failed to set mode: Invalid argument Bisected to this commit: fa4f4c213f5f7807360c41f2501a3031a9940f3a is the first bad commit commit fa4f4c213f5f7807360c41f2501a3031a9940f3a Author: James Jones Date: Mon Feb 10 15:15:55 2020 -0800 drm/nouveau/kms: Support NVIDIA format modifiers Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind. The specified format modifier is validated against the list of modifiers supported by the target display hardware. v2: Used Tesla family instead of NV50 chipset compare v4: Do not cache kind, tile_mode in nouveau_framebuffer v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones Signed-off-by: Ben Skeggs drivers/gpu/drm/nouveau/dispnv50/wndw.c | 20 --- drivers/gpu/drm/nouveau/nouveau_display.c | 89 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 4 ++ 3 files changed, 104 insertions(+), 9 deletions(-) -- 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
[PATCH] drm/mcde: Fix stability issue
Whenener a display update was sent, apart from updating
the memory base address we called mcde_display_send_one_frame()
which also sent a command to the display requesting the TE IRQ
and enabling the FIFO.
When continous updates are running this is wrong: we need
to only send this to start the flow to the display on
the very first update. This lead to the display pipeline
locking up and crashing.
Check if the flow is already running and in that case
do not call mcde_display_send_one_frame().
This fixes crashes on the Samsung GT-S7710 (Skomer).
Cc: Stephan Gerhold
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_display.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 212aee60cf61..1d8ea8830a17 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -1086,9 +1086,14 @@ static void mcde_display_update(struct
drm_simple_display_pipe *pipe,
*/
if (fb) {
mcde_set_extsrc(mcde, drm_fb_cma_get_gem_addr(fb, pstate, 0));
- if (!mcde->video_mode)
- /* Send a single frame using software sync */
- mcde_display_send_one_frame(mcde);
+ if (!mcde->video_mode) {
+ /*
+* Send a single frame using software sync if the flow
+* is not active yet.
+*/
+ if (mcde->flow_active == 0)
+ mcde_display_send_one_frame(mcde);
+ }
dev_info_once(mcde->dev, "sent first display update\n");
} else {
/*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
