dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[PATCH] drm/nouveau/dispnv50: fix runtime pm imbalance on error
by Dinghao Liu 03 Jun '20

03 Jun '20

pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu(a)zju.edu.cn> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 6be9df1820c5..e670756664ff 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1123,8 +1123,10 @@ nv50_mstc_detect(struct drm_connector *connector, return connector_status_disconnected; ret = pm_runtime_get_sync(connector->dev->dev); - if (ret < 0 && ret != -EACCES) + if (ret < 0 && ret != -EACCES) { + pm_runtime_put_autosuspend(connector->dev->dev); return connector_status_disconnected; + } ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr, mstc->port); -- 2.17.1

2 1

[PATCH 1/3] drm/atomic-helper: reset vblank on crtc reset
by Daniel Vetter 03 Jun '20

03 Jun '20

Only when vblanks are supported ofc. Some drivers do this already, but most unfortunately missed it. This opens up bugs after driver load, before the crtc is enabled for the first time. syzbot spotted this when loading vkms as a secondary output. Given how many drivers are buggy it's best to solve this once and for all in shared helper code. Aside from moving the few existing calls to drm_crtc_vblank_reset into helpers (i915 doesn't use helpers, so keeps its own) I think the regression risk is minimal: atomic helpers already rely on drivers calling drm_crtc_vblank_on/off correctly in their hooks when they support vblanks. And driver that's failing to handle vblanks after this is missing those calls already, and vblanks could only work by accident when enabling a CRTC for the first time right after boot. Big thanks to Tetsuo for helping track down what's going wrong here. There's only a few drivers which already had the necessary call and needed some updating: - komeda, atmel and tidss also needed to be changed to call __drm_atomic_helper_crtc_reset() intead of open coding it - tegra and msm even had it in the same place already, just code motion, and malidp already uses __drm_atomic_helper_crtc_reset(). Only call left is in i915, which doesn't use drm_mode_config_reset, but has its own fastboot infrastructure. So that's the only case where we actually want this in the driver still. I've also reviewed all other drivers which set up vblank support with drm_vblank_init. After the previous patch fixing mxsfb all atomic drivers do call drm_crtc_vblank_on/off as they should, the remaining drivers are either legacy kms or legacy dri1 drivers, so not affected by this change to atomic helpers. v2: Use the drm_dev_has_vblank() helper. v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off instead of drm_crtc_vblank_reset. Adjust them too. Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> Acked-by: Liviu Dudau <liviu.dudau(a)arm.com> Acked-by: Thierry Reding <treding(a)nvidia.com> Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7… Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot+0871b14ca2e2fb64f6e3(a)syzkaller.appspotmail.com Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: "James (Qian) Wang" <james.qian.wang(a)arm.com> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Mihail Atanassov <mihail.atanassov(a)arm.com> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com> Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: Ludovic Desroches <ludovic.desroches(a)microchip.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Jonathan Hunter <jonathanh(a)nvidia.com> Cc: Jyri Sarha <jsarha(a)ti.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Brian Masney <masneyb(a)onstation.org> Cc: Emil Velikov <emil.velikov(a)collabora.com> Cc: zhengbin <zhengbin13(a)huawei.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-tegra(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++----- drivers/gpu/drm/arm/malidp_drv.c | 1 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++----- drivers/gpu/drm/drm_atomic_state_helper.c | 4 ++++ drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 -- drivers/gpu/drm/omapdrm/omap_drv.c | 3 --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 --- drivers/gpu/drm/tegra/dc.c | 1 - drivers/gpu/drm/tidss/tidss_crtc.c | 3 +-- drivers/gpu/drm/tidss/tidss_kms.c | 4 ---- 10 files changed, 9 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 56bd938961ee..f33418d6e1a0 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc) crtc->state = NULL; state = kzalloc(sizeof(*state), GFP_KERNEL); - if (state) { - crtc->state = &state->base; - crtc->state->crtc = crtc; - } + if (state) + __drm_atomic_helper_crtc_reset(crtc, &state->base); } static struct drm_crtc_state * @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms, return err; drm_crtc_helper_add(crtc, &komeda_crtc_helper_funcs); - drm_crtc_vblank_reset(crtc); crtc->port = kcrtc->master->of_output_port; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index c2507b7d8512..02904392e370 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev) drm->irq_enabled = true; ret = drm_vblank_init(drm, drm->mode_config.num_crtc); - drm_crtc_vblank_reset(&malidp->crtc); if (ret < 0) { DRM_ERROR("failed to initialise vblank\n"); goto vblank_fail; diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index 10985134ce0b..ce246b96330b 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c @@ -411,10 +411,8 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc) } state = kzalloc(sizeof(*state), GFP_KERNEL); - if (state) { - crtc->state = &state->base; - crtc->state->crtc = crtc; - } + if (state) + __drm_atomic_helper_crtc_reset(crtc, &state->base); } static struct drm_crtc_state * @@ -528,7 +526,6 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev) } drm_crtc_helper_add(&crtc->base, &lcdc_crtc_helper_funcs); - drm_crtc_vblank_reset(&crtc->base); drm_mode_crtc_set_gamma_size(&crtc->base, ATMEL_HLCDC_CLUT_SIZE); drm_crtc_enable_color_mgmt(&crtc->base, 0, false, diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c index 8fce6a115dfe..9ad74045158e 100644 --- a/drivers/gpu/drm/drm_atomic_state_helper.c +++ b/drivers/gpu/drm/drm_atomic_state_helper.c @@ -32,6 +32,7 @@ #include <drm/drm_device.h> #include <drm/drm_plane.h> #include <drm/drm_print.h> +#include <drm/drm_vblank.h> #include <drm/drm_writeback.h> #include <linux/slab.h> @@ -93,6 +94,9 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc, if (crtc_state) __drm_atomic_helper_crtc_state_reset(crtc_state, crtc); + if (drm_dev_has_vblank(crtc->dev)) + drm_crtc_vblank_reset(crtc); + crtc->state = crtc_state; } EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset); diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c index ca3368c828d0..9606185c284b 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c @@ -1117,8 +1117,6 @@ static void mdp5_crtc_reset(struct drm_crtc *crtc) mdp5_crtc_destroy_state(crtc, crtc->state); __drm_atomic_helper_crtc_reset(crtc, &mdp5_cstate->base); - - drm_crtc_vblank_reset(crtc); } static const struct drm_crtc_funcs mdp5_crtc_funcs = { diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 242d28281784..7a7066cded79 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -642,9 +642,6 @@ static int omapdrm_init(struct omap_drm_private *priv, struct device *dev) goto err_cleanup_modeset; } - for (i = 0; i < priv->num_pipes; i++) - drm_crtc_vblank_off(priv->pipes[i].crtc); - omap_fbdev_init(ddev); drm_kms_helper_poll_init(ddev); diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d73e88ddecd0..e2959e32fd19 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -1271,9 +1271,6 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int swindex, drm_crtc_helper_add(crtc, &crtc_helper_funcs); - /* Start with vertical blanking interrupt reporting disabled. */ - drm_crtc_vblank_off(crtc); - /* Register the interrupt handler. */ if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CRTC_IRQ_CLOCK)) { /* The IRQ's are associated with the CRTC (sw)index. */ diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 83f31c6e891c..9b308b572eac 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1168,7 +1168,6 @@ static void tegra_crtc_reset(struct drm_crtc *crtc) tegra_crtc_atomic_destroy_state(crtc, crtc->state); __drm_atomic_helper_crtc_reset(crtc, &state->base); - drm_crtc_vblank_reset(crtc); } static struct drm_crtc_state * diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c index 89a226912de8..4d01c4af61cd 100644 --- a/drivers/gpu/drm/tidss/tidss_crtc.c +++ b/drivers/gpu/drm/tidss/tidss_crtc.c @@ -352,8 +352,7 @@ static void tidss_crtc_reset(struct drm_crtc *crtc) return; } - crtc->state = &tcrtc->base; - crtc->state->crtc = crtc; + __drm_atomic_helper_crtc_reset(crtc, &tcrtc->base); } static struct drm_crtc_state *tidss_crtc_duplicate_state(struct drm_crtc *crtc) diff --git a/drivers/gpu/drm/tidss/tidss_kms.c b/drivers/gpu/drm/tidss/tidss_kms.c index 4b99e9fa84a5..e6ab59eed259 100644 --- a/drivers/gpu/drm/tidss/tidss_kms.c +++ b/drivers/gpu/drm/tidss/tidss_kms.c @@ -278,10 +278,6 @@ int tidss_modeset_init(struct tidss_device *tidss) if (ret) return ret; - /* Start with vertical blanking interrupt reporting disabled. */ - for (i = 0; i < tidss->num_crtcs; ++i) - drm_crtc_vblank_reset(tidss->crtcs[i]); - drm_mode_config_reset(ddev); dev_dbg(tidss->dev, "%s done\n", __func__); -- 2.26.2

4 9

[PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
by Simon Ser 03 Jun '20

03 Jun '20

In update_output_state, the link-status property was reset to GOOD to ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset is also performed on an atomic commit without ALLLOW_MODESET. If a driver reads link-status to figure out whether to re-train the link, this could cause an atomic commit failure. User-space doesn't expect such a failure, because commits without ALLOW_MODESET aren't supposed to fail because of link training issues. Change update_output_state to implicitly reset link-status to GOOD only if ALLOW_MODESET is set. This is the case for legacy drmModeSetCrtc because drm_atomic_state_init sets it (and is used in drm_atomic_helper_set_config, called from drm_mode_setcrtc). Drivers don't seem to read link-status at the moment -- they seem to rely on user-space performing a modeset instead. So this shouldn't result in any change in behaviour, this should only prevent future failures if drivers start reading link-status. Signed-off-by: Simon Ser <contact(a)emersion.fr> Suggested-by: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Manasi Navare <manasi.d.navare(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 965173fd0ac2..3d9d9e6f7397 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1426,7 +1426,8 @@ static int update_output_state(struct drm_atomic_state *state, return ret; /* Make sure legacy setCrtc always re-trains */ - new_conn_state->link_status = DRM_LINK_STATUS_GOOD; + if (state->allow_modeset) + new_conn_state->link_status = DRM_LINK_STATUS_GOOD; } } -- 2.26.2

3 5

[PATCH v2] drm: document how user-space should use link-status
by Simon Ser 03 Jun '20

03 Jun '20

Describe what a "BAD" link-status means for user-space and how it should handle it. The logic described has been implemented in igt [1]. v2: - Change wording to avoid "enabled" (Daniel) - Add paragraph about multiple connectors sharing the same CRTC (Pekka) - Add paragraph about performing an atomic commit on a connector without updating the link-status property (Daniel) [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0… Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Manasi Navare <manasi.d.navare(a)intel.com> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> --- drivers/gpu/drm/drm_connector.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index f2b20fd66319..829b21124048 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -994,6 +994,21 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { * after modeset, the kernel driver may set this to "BAD" and issue a * hotplug uevent. Drivers should update this value using * drm_connector_set_link_status_property(). + * + * When user-space receives the hotplug uevent and detects a "BAD" + * link-status, the sink doesn't receive pixels anymore. The list of + * available modes may have changed. User-space is expected to pick a new + * mode if the current one has disappeared and perform a new modeset with + * link-status set to "GOOD" to re-enable the connector. + * + * If multiple connectors share the same CRTC and one of them gets a "BAD" + * link-status, the other are unaffected (ie. the sinks still continue to + * receive pixels). + * + * When user-space performs an atomic commit on a connector with a "BAD" + * link-status without resetting the property to "GOOD", it gets + * implicitly reset. This might make the atomic commit fail if the modeset + * is unsuccessful. * non_desktop: * Indicates the output should be ignored for purposes of displaying a * standard desktop environment or console. This is most likely because -- 2.26.2

3 3

[PATCH v2 00/10] Generic USB Display driver
by Noralf Trønnes 03 Jun '20

03 Jun '20

Hi, A while back I had the idea to turn a Raspberry Pi Zero into a $5 USB to HDMI/SDTV/DSI/DPI display adapter. This series adds a USB host driver and a device/gadget driver to achieve that. The reason for calling it 'Generic' is so anyone can make a USB display/adapter against this driver, all that's needed is to add a USB vid:pid. I was hoping to have someone working on a microcontroller based USB display by now, but unfortunately that has been delayed. It would have been nice to have a microcontroller implementation to ensure that I haven't made things unnecessary difficult to implement. Performance The one thing that decides how useful this all is, is how smooth an experience it gives. My hope was that it should not be noticeably laggy with ordinary office use on 1920x1080@RG16. I'm pleased to see that it's also possible to watch youtube movies, although not in fullscreen. Some of the main factors that affects performance: - Display resolution - Userspace providing damage reports (FB_DAMAGE_CLIPS or DRM_IOCTL_MODE_DIRTYFB) - Color depth (DRM_CAP_DUMB_PREFERRED_DEPTH = 16 if RGB565) - How well the frames compress (lz4) - USB2 vs. USB3 - Gadget device memory bandwidth, CPU power for decompression - (Big endian hosts will have to do byte swapping on the frames) I've tested these: - xorg-server on Pi4. This was nice and smooth since it uses DRM_IOCTL_MODE_DIRTYFB and honours DRM_CAP_DUMB_PREFERRED_DEPTH. - Ubuntu 20.04 GNOME on x86. This was useable, but not so good for movies. GNOME doesn't look at DRM_CAP_DUMB_PREFERRED_DEPTH and doesn't set FB_DAMAGE_CLIPS on the pageflips. I've made a short video to show what it looks like[1]. Tearing Host side Compression and transfer happens in an async worker. There are 2 tearing cases here: 1. The framebuffer fits in the kmalloc'ed transfer buffer, max 4MB by default (KMALLOC_MAX_SIZE). This can give occasional tearing when userspace gets ahead of the worker. 2. The framebuffer doesn't fit in the transfer buffer, so the host splits the transfer. When showing a movie this will almost always give tearing between each part of the frame. Fix: The device can increase KMALLOC_MAX_SIZE by setting CONFIG_FORCE_MAX_ZONEORDER since it probably has a custom kernel anyways. The host distro can't/won't do that, so I have look for solution here. The host side tearing is worse than the device side, because it lasts longer. Device side Received updates are decompressed/copied into the framebuffer that's being scanned out, so tearing is possible. Double buffering/page flipping could be used for full frames, but well behaving userspace doesn't send many of those, so very little impact. Double buffering on all updates would require memcpy between buffers locally, hampering performance. Maybe a Pi4 could get away with it, but a Pi Zero would certainly not (memory bandwidth). I've tested this series with usbip[2] by connecting 2 Pi4's over cabled gigabit network. It worked fine. One use case for these drivers is reusing old tablets and cell phones as USB displays. The Pi4 has two hdmi ports and I was asked if the driver supports that, and I've concluded that it would be too much work to implement at this point. It is possible to extend the protocol and implement it later. I have used a Pi4 as the gadget device during development since it has much better memory bandwith (4000 vs 200 MBps)[3] and CPU than the Pi Zero. They both have the same gadget controller (dwc2). Changes in this version: - Drop drm_backlight_helper - Use devm_drm_dev_alloc() - Addressed Sam's comments Noralf. [1] https://youtu.be/AhGZWwUm8JU [2] tools/usb/usbip/README [3] https://magpi.raspberrypi.org/articles/raspberry-pi-specs-benchmarks Noralf Trønnes (10): backlight: Add backlight_device_get_by_name() drm/client: Add drm_client_init_from_id() drm/client: Add drm_client_framebuffer_flush() drm/client: Add drm_client_modeset_check() drm/client: Add drm_client_modeset_disable() drm/client: Add a way to set modeset, properties and rotation drm/format-helper: Add drm_fb_swab() drm: Add Generic USB Display driver drm/gud: Add functionality for the USB gadget side usb: gadget: function: Add Generic USB Display support .../ABI/testing/configfs-usb-gadget-gud_drm | 10 + MAINTAINERS | 10 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_client.c | 81 +- drivers/gpu/drm/drm_client_modeset.c | 192 ++- drivers/gpu/drm/drm_format_helper.c | 61 +- drivers/gpu/drm/drm_mipi_dbi.c | 2 +- drivers/gpu/drm/gud/Kconfig | 20 + drivers/gpu/drm/gud/Makefile | 5 + drivers/gpu/drm/gud/gud_drm_connector.c | 724 ++++++++++ drivers/gpu/drm/gud/gud_drm_drv.c | 641 +++++++++ drivers/gpu/drm/gud/gud_drm_gadget.c | 1165 +++++++++++++++++ drivers/gpu/drm/gud/gud_drm_internal.h | 66 + drivers/gpu/drm/gud/gud_drm_pipe.c | 423 ++++++ drivers/usb/gadget/Kconfig | 12 + drivers/usb/gadget/function/Makefile | 2 + drivers/usb/gadget/function/f_gud_drm.c | 678 ++++++++++ drivers/video/backlight/backlight.c | 21 + include/drm/drm_client.h | 45 +- include/drm/drm_format_helper.h | 4 +- include/drm/gud_drm.h | 377 ++++++ include/linux/backlight.h | 1 + 23 files changed, 4513 insertions(+), 30 deletions(-) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-gud_drm create mode 100644 drivers/gpu/drm/gud/Kconfig create mode 100644 drivers/gpu/drm/gud/Makefile create mode 100644 drivers/gpu/drm/gud/gud_drm_connector.c create mode 100644 drivers/gpu/drm/gud/gud_drm_drv.c create mode 100644 drivers/gpu/drm/gud/gud_drm_gadget.c create mode 100644 drivers/gpu/drm/gud/gud_drm_internal.h create mode 100644 drivers/gpu/drm/gud/gud_drm_pipe.c create mode 100644 drivers/usb/gadget/function/f_gud_drm.c create mode 100644 include/drm/gud_drm.h -- 2.23.0

4 14

[PATCH v8 00/10] Genericize DW MIPI DSI bridge and add i.MX 6 driver
by Adrian Ratiu 03 Jun '20

03 Jun '20

Hello everyone, The dt-binding added in this series depends on [1] for "make dt_binding_check" to pass. The biggest change in v8 is a conversion of the imx6 host controller driver to drm_bridge and an extension to dw_mipi_dsi.c which allows platform drivers to daisy-chain bridges between the encoder and the Synopsis DSI bridge. Obviously a lot more work can be done on this front, for example to convert the Rockchip and STM platform drivers to drm_bridge (the STM driver doesn't even use the current dw_mipi_dsi.c bind API to attach) or to improve the API itself. Another kind of related work is refactoring the existng IMX drivers to drm_bridge and move the empty encoder management to imx-drm-core. Because this patch is already quite big, I did only the minimum changes to get the imx6 mipi dsi driver in good shape, all the other changes should be done in separate patch series. I also just realized imx6qdl.dtsi was missing some properties to get the DSI host controller working so I've added them as a new patch. All received feedback up to this point has been addressed. Thank you and best wishes, Adrian [1] https://lore.kernel.org/linux-devicetree/20200423100058.1734009-1-adrian.ra… Adrian Ratiu (10): drm: bridge: dw_mipi_dsi: add initial regmap infrastructure drm: bridge: dw_mipi_dsi: abstract register access using reg_fields drm: bridge: dw_mipi_dsi: add dsi v1.01 support drm: bridge: dw_mipi_dsi: allow bridge daisy chaining drm: imx: Add i.MX 6 MIPI DSI host platform driver ARM: dts: imx6qdl: add missing mipi dsi properties dt-bindings: display: add i.MX6 MIPI DSI host controller doc drm: stm: dw-mipi-dsi: let the bridge handle the HW version check drm: bridge: dw-mipi-dsi: split low power cfg register into fields drm: bridge: dw-mipi-dsi: fix bad register field offsets .../display/imx/fsl,mipi-dsi-imx6.yaml | 145 ++++ arch/arm/boot/dts/imx6qdl.dtsi | 8 + drivers/gpu/drm/bridge/synopsys/Kconfig | 1 + drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 698 +++++++++++++----- drivers/gpu/drm/imx/Kconfig | 8 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 399 ++++++++++ .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +- include/drm/bridge/dw_mipi_dsi.h | 5 +- 10 files changed, 1070 insertions(+), 209 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c -- 2.26.0

6 20

KMS documentation for userspace
by Simon Ser 03 Jun '20

03 Jun '20

Hi all, With Wayland compositors and DRM leases, the number of DRM userspace programs has increased (and will probably continue to increase). However it's been pretty hard to find good DRM docs for userspace. The resources currently available are: - The kernel docs, although only the high level overview is useful to userspace. - User-contributed tutorials, like [1] and [2]. - To help userspace understand hardware capabilities and limitations, I've recently started a DRM database dump project [3]. (Anything else I've missed?) We still lack docs that describe how to properly use the KMS API and the KMS properties. There is a deprecated list at [4], and another list mixed with kernel structs at [5]. This is not great for userspace developers. So I wanted to know if there's interest from the kernel community to maintain documentation for userspace? Or should userspace maintain its own docs of the kernel API? I don't know what would be the best place for these docs. If they live in kernel doc comments, then references to kernel functions and guidelines for kernel devs will appear (just like in the current docs). If they live outside of the kernel source code or outside of the kernel tree, they might get outdated. Thoughts? Thanks, [1]: https://github.com/ascent12/drm_doc [2]: https://gitlab.freedesktop.org/daniels/kms-quads [3]: https://drmdb.emersion.fr/ [4]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#standard-connect… [5]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#existing-kms-pro… -- Simon Ser https://emersion.fr

3 7

[RFC PATCH 1/1] drm/mm: add ig_frag selftest
by Nirmoy Das 03 Jun '20

03 Jun '20

This patch introduces fragmentation in the address range and measures time taken by 10k and 20k insertions. ig_frag() will fail if time taken by 20k insertions takes more than 4 times of 10k insertions as we know that insertions scale quadratically. Also tolerate 10% error because of kernel scheduler's jitters. Output: <snip> [ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128 [ 8092.653520] drm_mm: igt_sanitycheck - ok! [ 8092.653525] igt_debug 0x0000000000000000-0x0000000000000200: 512: free [ 8092.653526] igt_debug 0x0000000000000200-0x0000000000000600: 1024: used [ 8092.653527] igt_debug 0x0000000000000600-0x0000000000000a00: 1024: free [ 8092.653528] igt_debug 0x0000000000000a00-0x0000000000000e00: 1024: used [ 8092.653529] igt_debug 0x0000000000000e00-0x0000000000001000: 512: free [ 8092.653529] igt_debug total: 4096, used 2048 free 2048 [ 8112.569813] drm_mm: best fragmented insert of 10000 and 20000 insertions took 504 and 1996 msecs [ 8112.723254] drm_mm: bottom-up fragmented insert of 10000 and 20000 insertions took 44 and 108 msecs [ 8112.813212] drm_mm: top-down fragmented insert of 10000 and 20000 insertions took 40 and 44 msecs [ 8112.847733] drm_mm: evict fragmented insert of 10000 and 20000 insertions took 8 and 20 msecs <snip> Signed-off-by: Nirmoy Das <nirmoy.das(a)amd.com> --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 73 ++++++++++++++++++++ 2 files changed, 74 insertions(+) diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h b/drivers/gpu/drm/selftests/drm_mm_selftests.h index 6b943ea1c57d..8c87c964176b 100644 --- a/drivers/gpu/drm/selftests/drm_mm_selftests.h +++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h @@ -14,6 +14,7 @@ selftest(insert, igt_insert) selftest(replace, igt_replace) selftest(insert_range, igt_insert_range) selftest(align, igt_align) +selftest(frag, igt_frag) selftest(align32, igt_align32) selftest(align64, igt_align64) selftest(evict, igt_evict) diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c index 9aabe82dcd3a..05d8f3659b4d 100644 --- a/drivers/gpu/drm/selftests/test-drm_mm.c +++ b/drivers/gpu/drm/selftests/test-drm_mm.c @@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored) return 0; } +static int get_insert_time(unsigned int num_insert, + const struct insert_mode *mode) +{ + struct drm_mm mm; + struct drm_mm_node *nodes, *node, *next; + unsigned int size = 4096, align = 8192; + unsigned long start; + unsigned int i; + int ret = -EINVAL; + + drm_mm_init(&mm, 1, U64_MAX - 2); + nodes = vzalloc(array_size(num_insert, sizeof(*nodes))); + if (!nodes) + goto err; + + start = jiffies; + for (i = 0; i < num_insert; i++) { + if (!expect_insert(&mm, &nodes[i], size, align, i, mode)) { + pr_err("%s insert failed\n", mode->name); + goto out; + } + } + + ret = jiffies_to_msecs(jiffies - start); +out: + drm_mm_for_each_node_safe(node, next, &mm) + drm_mm_remove_node(node); + drm_mm_takedown(&mm); + vfree(nodes); +err: + return ret; + +} + +static int igt_frag(void *ignored) +{ + const struct insert_mode *mode; + unsigned int insert_time1, insert_time2; + unsigned int insert_size = 10000; + unsigned int scale_factor = 4; + /* tolerate 10% excess insertion duration */ + unsigned int error_factor = 110; + int ret = -EINVAL; + + for (mode = insert_modes; mode->name; mode++) { + unsigned int expected_time; + + insert_time1 = get_insert_time(insert_size, mode); + if (insert_time1 < 0) + goto err; + + insert_time2 = get_insert_time((insert_size * 2), mode); + if (insert_time2 < 0) + goto err; + + expected_time = (scale_factor * insert_time1 * + error_factor)/100; + if (insert_time2 > expected_time) { + pr_err("%s fragmented insert took more %u msecs\n", + mode->name, insert_time2 - expected_time); + goto err; + } + + pr_info("%s fragmented insert of %u and %u insertions took %u and %u msecs\n", + mode->name, insert_size, insert_size * 2, insert_time1, + insert_time2); + } + + ret = 0; +err: + return ret; +} + static int igt_align(void *ignored) { const struct insert_mode *mode; -- 2.26.2

4 7

[PATCH] drm/connector: notify userspace on hotplug after register complete
by Jeykumar Sankaran 03 Jun '20

03 Jun '20

drm connector notifies userspace on hotplug event prematurely before late_register and mode_object register completes. This leads to a race between userspace and kernel on updating the IDR list. So, move the notification to end of connector register. Signed-off-by: Jeykumar Sankaran <jsanka(a)codeaurora.org> Signed-off-by: Steve Cohen <cohens(a)codeaurora.org> --- drivers/gpu/drm/drm_connector.c | 5 +++++ drivers/gpu/drm/drm_sysfs.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b1099e1..d877ddc 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -27,6 +27,7 @@ #include <drm/drm_print.h> #include <drm/drm_drv.h> #include <drm/drm_file.h> +#include <drm/drm_sysfs.h> #include <linux/uaccess.h> @@ -523,6 +524,10 @@ int drm_connector_register(struct drm_connector *connector) drm_mode_object_register(connector->dev, &connector->base); connector->registration_state = DRM_CONNECTOR_REGISTERED; + + /* Let userspace know we have a new connector */ + drm_sysfs_hotplug_event(connector->dev); + goto unlock; err_debugfs: diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index 939f003..f0336c8 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -291,9 +291,6 @@ int drm_sysfs_connector_add(struct drm_connector *connector) return PTR_ERR(connector->kdev); } - /* Let userspace know we have a new connector */ - drm_sysfs_hotplug_event(dev); - if (connector->ddc) return sysfs_create_link(&connector->kdev->kobj, &connector->ddc->dev.kobj, "ddc"); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new()
by Markus Elfring 03 Jun '20

03 Jun '20

> When gk20a_clk_ctor() returns an error code, pointer "clk" > should be released. Such an information is reasonable. > It's the same when gm20b_clk_new() returns from elsewhere following this call. I suggest to reconsider the interpretation of the software situation once more. Can it be that the allocated clock object should be kept usable even after a successful return from this function? Would you like to add the tag “Fixes” to the commit message? Regards, Markus

3 13

← Newer
1
...
67
68
69
70
71
72
73
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020