[Intel-gfx] [PATCH 02/52] drm/i915: Don't clear drvdata in ->release

For two reasons: - The driver core clears this already for us after we're unloaded in __device_release_driver(). - It's way too late, the drm_device ->release callback might massively outlive the underlying physical device, since a drm_device can't be kept alive by open drm_file or well rea

[Intel-gfx] [PATCH 00/52] drm_device managed resources

Hi all, So I finally bit the bullet and started a little framework for managed resources tied to the drm_device lifetime, instead of the lifetime of the underlying physical device. Because I've seen one patch too many that just totally got this wrong. Yes it's huge, but I think this is what we mi

[Intel-gfx] [PATCH 01/52] mm/sl[uo]b: export __kmalloc_track(_node)_caller

slab does this already, and I want to use this in a memory allocation tracker in drm for stuff that's tied to the lifetime of a drm_device, not the underlying struct device. Kinda like devres, but for drm. Signed-off-by: Daniel Vetter Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes C

[Intel-gfx] [PATCH 08/52] drm/qxl: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org --- drivers/gpu/drm/qxl/qxl_drv.c | 2 -- drivers/gpu/drm/qxl/qxl_kms.c | 2 ++ 2

[Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a

[Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

They all share mipi_dbi_release so we need to switch them all together. With this we can drop the final kfree from the release function. Aside, I think we could perhaps have a tiny additional helper for these mipi_dbi drivers, the first few lines around devm_drm_dev_init are all the same (except f

[Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc

I also did a full review of all callers, and only the xen driver forgot to call drm_dev_put in the failure path. Fix that up too. v2: I noticed that xen has a drm_driver.release hook, and uses drm_dev_alloc(). We need to remove the kfree from xen_drm_drv_release(). bochs also has a release hook,

[Intel-gfx] [PATCH 07/52] drm/udl: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. v2: We need drm_dev_put to unroll the driver creation (once drm_dev_init and drmm_add_final_kfree suceeded), otherwise the drmm_ magic doesn't happen. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Sean Paul Cc: Thomas Zimmerma

[Intel-gfx] [PATCH 20/52] drm: Cleanups after drmm_add_final_kfree rollout

A few things: - Update the example driver in the documentation. - We can drop the old kfree in drm_dev_release. - Add a WARN_ON check in drm_dev_register to make sure everyone calls drmm_add_final_kfree and there's no leaks. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 11 -

[Intel-gfx] [PATCH 06/52] drm/udl: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Sean Paul Cc: Thomas Zimmermann Cc: Emil Velikov Cc: Daniel Vetter Cc: "Noralf Trønnes" Cc: Thomas Gleixner Cc: Sam Ravnborg --- drivers/gpu/drm/udl/udl_drv.c | 3 ++- 1 file

[Intel-gfx] [PATCH 15/52] drm/vkms: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. v2: After drm_dev_init/drmm_add_final_kfree we need to clean up everything through a drm_dev_put. Rework the unwind code to match that. Signed-off-by: Daniel Vetter Cc: Rodrigo Siqueira Cc: Haneen Mohammed Cc: Daniel Vetter ---

[Intel-gfx] [PATCH 10/52] drm/cirrus: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. I also noticed that cirrus forgot to call drm_dev_fini(). v2: Don't call kfree(cirrus) after we've handed overship of that to drm_device and the drmm_ stuff. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Dan

[Intel-gfx] [PATCH 28/52] drm/bochs: Remove leftover drm_atomic_helper_shutdown

Small mistake that crept into commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab Author: Gerd Hoffmann Date: Tue Feb 11 14:52:18 2020 +0100 drm/bochs: add drm_driver.release callback where drm_atomic_helper_shutdown was left in both places. The ->release callback really shouldn't touch hardw

[Intel-gfx] [PATCH 23/52] drm: manage drm_minor cleanup with drmm_

The cleanup here is somewhat tricky, since we can't tell apart the allocated minor index from 0. So register a cleanup action first, and if the index allocation fails, unregister that cleanup action again to avoid bad mistakes. The kdev for the minor already handles NULL, so no problem there. Hen

[Intel-gfx] [PATCH 14/52] drm/vgem: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. v2: After drm_dev_init/drmm_add_final_kfree we need to clean up everything through a drm_dev_put. Rework the unwind code to match that. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Emil Velikov Cc: Chris Wilson Cc: Sean Pa

[Intel-gfx] [PATCH 26/52] drm: Garbage collect drm_dev_fini

It has become empty. Given the few users I figured not much point splitting this up. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/cirrus/cirrus.c | 1 - drivers/gpu/drm/drm_drv.c | 23 +-- drivers/gpu/drm/drm_mipi_dbi.c| 1 -

[Intel-gfx] [PATCH 13/52] drm/mcde: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Linus Walleij --- 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 f28cb

[Intel-gfx] [PATCH 11/52] drm/v3d: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. I also noticed that the unwind code is wrong, after drm_dev_init the drm_device owns the v3d allocation, so the kfree(v3d) is a double-free. Reorder the setup to fix this issue. After a bit more prep in drivers and drm core v3d shou

[Intel-gfx] [PATCH 12/52] drm/tidss: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Jyri Sarha Cc: Tomi Valkeinen --- drivers/gpu/drm/tidss/tidss_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tid

[Intel-gfx] [PATCH 09/52] drm/i915: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. The mock device in the selftests needed it's pci_device split up from the drm_device. In the future we could simplify this again by allocating the pci_device as a managed allocation too. v2: I overlooked that i915_driver_destroy is

[Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree

These are the leftover drivers that didn't have a ->release hook that needed to be updated. Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov Cc: Russell King Cc: Hans de Goede --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 ++ drivers/gpu/dr

[Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

drm_mode_config_cleanup is idempotent, so no harm in calling this twice. This allows us to gradually switch drivers over by removing explicit drm_mode_config_cleanup calls. With this step it's not also possible that (at least for simple drivers) automatic resource cleanup can be done correctly wit

[Intel-gfx] [PATCH 16/52] drm/repaper: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: "Noralf Trønnes" --- drivers/gpu/drm/tiny/repaper.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c index f5

[Intel-gfx] [PATCH 18/52] drm/gm12u320: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Hans de Goede --- drivers/gpu/drm/tiny/gm12u320.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c index a4817

[Intel-gfx] [PATCH 17/52] drm/inigenic: Use drmm_add_final_kfree

With this we can drop the final kfree from the release function. Signed-off-by: Daniel Vetter Cc: Paul Cercueil --- drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ing

[Intel-gfx] [PATCH 21/52] drm: Handle dev->unique with drmm_

We need to add a drmm_kstrdup for this, but let's start somewhere. This is not exactly perfect onion unwinding, but it's jsut a kfree so doesn't really matter at all. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 5 ++--- drivers/gpu/drm/drm_managed.c | 16

[Intel-gfx] [PATCH 31/52] drm/cirrus: Fully embrace devm_

With the drm_device lifetime fun cleaned up there's nothing in the way anymore to use devm_ for everything hw releated. Do it, and in the process, throw out the entire onion unwinding. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: "Noralf Trønnes" Cc: Em

[Intel-gfx] [PATCH 49/52] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call

Allows us to drop the drm_driver.release callback from all drivers, and remove the mipi_dbi_release() function. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Eric Anholt Cc: David Lechner Cc: Kamlesh Guruda

[Intel-gfx] [PATCH 36/52] drm/pl111: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: This driver gets its devm_ stuff all wrong wrt drm_device and anything hanging off that. Not the only one unfortunately. Signed-off-by: Daniel Vetter Cc: Eric Anholt --- drivers/gpu/drm/pl111/pl111_drv.c | 12 ++-- 1 file changed, 6 insertions

[Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_

We might want to look into pushing this down into drm_mm_init, but that would mean rolling out return codes to a pile of functions unfortunately. So let's leave that for now. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 8 +--- drivers/gpu/drm/drm_gem.c | 21 ++

[Intel-gfx] [PATCH 35/52] drm/meson: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: This driver gets its devm_ stuff all wrong wrt drm_device and anything hanging off that. Not the only one unfortunately. Signed-off-by: Daniel Vetter Cc: Neil Armstrong Cc: Kevin Hilman Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-ker...@lists.

[Intel-gfx] [PATCH 46/52] drm/gm12u320: Simplify upload work

Instead of having a work item that never stops (which really should be a kthread), with a dedicated workqueue to not upset anyone else, use a delayed work. A bunch of changes: - We can throw out all the custom wakeup and requeue logic and state tracking. If we schedule the work with a 0 delay it

[Intel-gfx] [PATCH 32/52] drm/ingenic: Drop explicit drm_mode_config_cleanup call

Allows us to drop the drm_driver.release callback. Signed-off-by: Daniel Vetter Cc: Paul Cercueil --- drivers/gpu/drm/ingenic/ingenic-drm.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-dr

[Intel-gfx] [PATCH 38/52] drm/rockchip: Drop explicit drm_mode_config_cleanup call

It's (almost, there's some iommu stuff without significance) right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Sandy Huang Cc: "Heiko Stübner" Cc: linux-arm-ker...@lists.infrade

[Intel-gfx] [PATCH 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Yannick Fertre Cc: Philippe Cornu Cc: Benjamin Gaignard Cc: Vincent Abriou Cc: Maxime Coquelin Cc: Alexandre Torgue Cc

[Intel-gfx] [PATCH 25/52] drm: Manage drm_vblank_cleanup with drmm_

Nothing special here, except that this is the first time that we automatically clean up something that's initialized with an explicit driver call. But the cleanup was done at the very of the release sequence for all drivers, and that's still the case. At least without more uses of drmm_ through exp

[Intel-gfx] [PATCH 45/52] drm/gm12u320: Use helpers for shutdown/suspend/resume

Also there's a race in the disconnect implemenation. First shut down, then unplug, leaves a window where userspace could sneak in and restart the entire machinery. With this we can also delete the very un-atomic global pipe_enabled tracking. Signed-off-by: Daniel Vetter Cc: Hans de Goede Cc: "N

[Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

Well for the simple stuff at least, vblank, gem and minor cleanup I want to further split up as a demonstration. v2: We need to clear drm_device->dev otherwise the debug drm printing after our cleanup hook (e.g. in drm_manged_release) will chase released memory and result in a use-after-free. Not

[Intel-gfx] [PATCH 48/52] drm/mipi-dbi: Move drm_mode_config_init into mipi library

7/7 drivers agree that's the right choice, let's do this. This avoids duplicating the same old error checking code over all 7 drivers, which is the motivation here. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mipi_dbi.c | 4 drivers/gpu/drm/tiny/hx8357d.c | 2 -- drivers/gpu/drm

[Intel-gfx] [PATCH 34/52] drm/mcde: More devm_drm_dev_init

Auto-unwind ftw, now possible with the fixed drm_device related management. Aside, clk/regulator seem to be missing devm versions for a bunch of functions, preventing a pile of these simpler drivers from outright losing their ->remove hook. Signed-off-by: Daniel Vetter Cc: Linus Walleij --- dr

[Intel-gfx] [PATCH 42/52] drm/tidss: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... I'm pretty sure this one blows up already under KASAN because it's using devm_drm_dev_init, and later on devm_kzalloc. Hence the memory will get freed before

[Intel-gfx] [PATCH 29/52] drm/bochs: Drop explicit drm_mode_config_cleanup

Instead rely on the automatic clean, for which we just need to check that drm_mode_config_init succeeded. To avoid an inversion in the cleanup we also have to move the dev_private allocation over to drmm_kzalloc. Signed-off-by: Daniel Vetter Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-found

[Intel-gfx] [PATCH 52/52] drm: Add docs for managed resources

All collected together to provide a consistent story in one patch, instead of the somewhat bumpy refactor-evolution leading to this. Also some thoughts on what the next steps could be: - Create a macro called devm_drm_dev_alloc() which essentially wraps the kzalloc(); devm_drm_dev_init(); drmm_

[Intel-gfx] [PATCH 50/52] drm/udl: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). This allows us to delete a bit of onion unwinding in udl_modeset_init(). Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Sean Paul Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Emil Velikov Cc: Gerd Hoffmann Cc: "Noralf Trønnes" Cc: Thomas Gleixner Cc:

[Intel-gfx] [PATCH 30/52] drm/cirrus: Drop explicit drm_mode_config_cleanup call

We can even delete the drm_driver.release hook now! Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: "Noralf Trønnes" Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: virtualizat...@lists.linux-foundation.org --- drivers/gpu/drm/cirrus/cirrus.c | 21 ++

[Intel-gfx] [PATCH 41/52] drm/mtk: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers

[Intel-gfx] [PATCH 44/52] drm/gm12u320: Use devm_drm_dev_init

Only drops the drm_dev_put, but hey a few lines! Signed-off-by: Daniel Vetter Cc: Hans de Goede Cc: "Noralf Trønnes" --- drivers/gpu/drm/tiny/gm12u320.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/ti

[Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -

[Intel-gfx] [PATCH 51/52] drm/udl: drop drm_driver.release hook

There's only two functions called from that: drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are also called from the ubs_driver->disconnect hook, so entirely pointless to do the same again in the ->release hook. Furthermore by the time we clean up the drm_driver we really should

[Intel-gfx] [PATCH 40/52] drm/shmob: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/shmobile/shmob_drm_drv.c |

[Intel-gfx] [PATCH 43/52] drm/gm12u320: More drmm_

The drm_mode_config_cleanup call we can drop, and all the allocations we can switch over to drmm_kzalloc. Unfortunately the work queue is still present, so can't get rid of the drm_driver->release function outright. Signed-off-by: Daniel Vetter Cc: Hans de Goede Cc: "Noralf Trønnes" --- driver

[Intel-gfx] [PATCH 33/52] drm/mcde: Drop explicit drm_mode_config_cleanup call

Allows us to drop the drm_driver.release callback. Signed-off-by: Daniel Vetter Cc: Linus Walleij --- drivers/gpu/drm/mcde/mcde_drv.c | 22 ++ 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c ind

[Intel-gfx] [PATCH 47/52] drm/repaper: Drop explicit drm_mode_config_cleanup call

Allows us to drop the drm_driver.release callback. Signed-off-by: Daniel Vetter Cc: "Noralf Trønnes" --- drivers/gpu/drm/tiny/repaper.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c index 4741ff670ec9..2f70fb1be200 100

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: conversion to struct drm_device based logging macros. (rev2)

== Series Details == Series: drm/i915/perf: conversion to struct drm_device based logging macros. (rev2) URL : https://patchwork.freedesktop.org/series/73589/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9139cc1d6f24 drm/i915/perf: conversion to struct drm_device based loggin

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... What's drmm_kzalloc()? The only references I can find are in this patch series. Gr{

Re: [Intel-gfx] [PATCH 35/52] drm/meson: Drop explicit drm_mode_config_cleanup call

On 19/02/2020 11:21, Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: This driver gets its devm_ stuff all wrong wrt drm_device and > anything hanging off that. Not the only one unfortunately. > > Signed-off-by: Daniel Vetter > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: l

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct drm_device based WARN* and use them in i915 (rev6)

On Wed, 05 Feb 2020, Patchwork wrote: > == Series Details == > > Series: drm: Introduce struct drm_device based WARN* and use them in i915 > (rev6) > URL : https://patchwork.freedesktop.org/series/72035/ > State : failure > > == Summary == > > Applying: drm/i915/display/cdclk: Make WARN* drm sp

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > > It's right above the drm_dev_put(). > > > > Aside: Another driver with a bit much devm_kzalloc, which should > > probably use drmm_kzalloc instead ... > > What's

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct drm_device based WARN* and use them in i915 (rev6)

> -Original Message- > From: Jani Nikula > Sent: 19 February 2020 16:25 > To: Patchwork ; Laxminarayan Bharadiya, > Pankaj > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct > drm_device based WARN* and use them in i915 (rev

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: conversion to struct drm_device based logging macros. (rev2)

== Series Details == Series: drm/i915/perf: conversion to struct drm_device based logging macros. (rev2) URL : https://patchwork.freedesktop.org/series/73589/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16617 ===

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven > wrote: > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter > > wrote: > > > It's right above the drm_dev_put(). > > > > > > Aside: Another driver with a bit much devm_kzalloc

[Intel-gfx] [PATCH 1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

Check that the CTX_TIMESTAMP is monotonic across context save/restore and upon preemption. References: https://gitlab.freedesktop.org/drm/intel/issues/1233 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 229 + 1 file changed, 229 insertions(+) d

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Mark GPR checking more hostile

Currently, we check that a new context has a clear set of general purpose registers. Add a little bit of hostility by preempting our new context and re-poisoning the GPR to ensure that there is no context leakage from preemption. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_l

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : warning == Summary == $ dim checkpatch origin/drm-tip 913ef020101d mm/sl[uo]b: export __kmalloc_track(_node)_caller -:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: l

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller Okay! _

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Hi Daniel, good idea. I guess it's the simple encoder's fault. :) I only read briefly over the whole thing. Am 19.02.20 um 11:20 schrieb Daniel Vetter: > They all share mipi_dbi_release so we need to switch them all > together. With this we can drop the final kfree from the release > function. >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16618 Summary --- **SUCCESS** No regr

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

== Series Details == Series: series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches URL : https://patchwork.freedesktop.org/series/73637/ State : warning == Summary == $ dim checkpatch origin/drm-tip e360e7c59c3d drm/i915/selftest: Analyse timestamp

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: use spinlock_t instead of struct spinlock

== Series Details == Series: drm/i915/gem: use spinlock_t instead of struct spinlock URL : https://patchwork.freedesktop.org/series/73546/ State : success == Summary == CI Bug Log - changes from CI_DRM_7957_full -> Patchwork_16595_full Summ

[Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

The purpose of userptr MMU notifier is to invalidate object pages as soon as someone unpins them from memory. While doing that, obj->mm.lock is acquired. If the notifier was called with obj->mm.lock already held, a lockdep loop would be triggered. That scenario is believed to be possible in seve

[Intel-gfx] [PATCH i-g-t] i915/gem_vm_create: Call set-domain manually

Since we are secretly using execbuf to write into an object's location, then read back from the object we must manually handle the domain changes. Closes: https://gitlab.freedesktop.org/drm/intel/issues/314 Signed-off-by: Chris Wilson --- tests/i915/gem_vm_create.c | 4 1 file changed, 4 in

Re: [Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

Quoting Janusz Krzysztofik (2020-02-19 12:09:44) > The purpose of userptr MMU notifier is to invalidate object pages as > soon as someone unpins them from memory. While doing that, > obj->mm.lock is acquired. If the notifier was called with obj->mm.lock > already held, a lockdep loop would be tri

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

== Series Details == Series: series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches URL : https://patchwork.freedesktop.org/series/73637/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16619 =

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 12:10:18PM +0100, Geert Uytterhoeven wrote: > On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > > > > It's right above the drm_dev_put

[Intel-gfx] [PATCH v16 4/7] drm/i915: Refactor intel_can_enable_sagv

Currently intel_can_enable_sagv function contains a mix of workarounds for different platforms some of them are not valid for gens >= 11 already, so lets split it into separate functions. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with ad

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

Hi, On 19/02/2020 11:20, Daniel Vetter wrote: > We have lots of these. And the cleanup code tends to be of dubious > quality. The biggest wrong pattern is that developers use devm_, which > ties the release action to the underlying struct device, whereas > all the userspace visible stuff attached

[Intel-gfx] [PATCH v2] drm/i915/selftests: Mark GPR checking more hostile

Currently, we check that a new context has a clear set of general purpose registers. Add a little bit of hostility by preempting our new context and re-poisoning the GPR to ensure that there is no context leakage from preemption. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_l

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 02:17:27PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wed, Feb 19, 2020 at 12:10:18PM +0100, Geert Uytterhoeven wrote: > > On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > > > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > > > On Wed, Feb 19,

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Am 19.02.20 um 12:47 schrieb Thomas Zimmermann: > Hi Daniel, > > good idea. I guess it's the simple encoder's fault. :) I only read > briefly over the whole thing. > > Am 19.02.20 um 11:20 schrieb Daniel Vetter: >> They all share mipi_dbi_release so we need to switch them all >> together. With

[Intel-gfx] [PATCH] drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx

For dgfx, we do not need to reconfigure the IA/ring frequencies of the main processors as they are distinct devices. Signed-off-by: Chris Wilson Cc: Andi Shyti Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_llc.c| 6 -- drivers/gpu/drm/i915/gt/selftest_llc.c | 11 ++- 2

Re: [Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

Hi Chris, On Wednesday, February 19, 2020 1:17:12 PM CET Chris Wilson wrote: > Quoting Janusz Krzysztofik (2020-02-19 12:09:44) > > The purpose of userptr MMU notifier is to invalidate object pages as > > soon as someone unpins them from memory. While doing that, > > obj->mm.lock is acquired. If

Re: [Intel-gfx] [PATCH] drm/i915/gem: use spinlock_t instead of struct spinlock

On Tue, 18 Feb 2020, Jani Nikula wrote: > On Mon, 17 Feb 2020, Chris Wilson wrote: >> Quoting Jani Nikula (2020-02-17 18:42:19) >>> spinlock_t is one case where the typedef is to be preferred over struct >>> spinlock. >>> >>> Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Iterate over pipe and skip the disabled one

On Tue, Feb 18, 2020 at 11:23:43PM +0530, Anshuman Gupta wrote: > On 2020-02-07 at 16:47:53 +0200, Ville Syrjälä wrote: > > On Fri, Feb 07, 2020 at 07:50:37PM +0530, Anshuman Gupta wrote: > > > It should not be assumed that a disabled display pipe will be > > > always last the pipe. > > > for_each_

Re: [Intel-gfx] [CI 1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall

On Fri, 14 Feb 2020, Jani Nikula wrote: > Split intel_modeset_driver_remove() to two, the part with working irqs > before irq uninstall, and the part after irq uninstall. Move > irq_unintall() closer to the layer it belongs. > > The error path in i915_driver_modeset_probe() looks obviously weird >

Re: [Intel-gfx] [PATCH] drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx

Hi Chris, On Wed, Feb 19, 2020 at 01:01:19PM +, Chris Wilson wrote: > For dgfx, we do not need to reconfigure the IA/ring frequencies of the > main processors as they are distinct devices. > > Signed-off-by: Chris Wilson > Cc: Andi Shyti > Cc: Tvrtko Ursulin looks good: Reveiwed-by: Andi

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

On Wed, Feb 19, 2020 at 12:47 PM Thomas Zimmermann wrote: > > Hi Daniel, > > good idea. I guess it's the simple encoder's fault. :) I only read > briefly over the whole thing. > > Am 19.02.20 um 11:20 schrieb Daniel Vetter: > > They all share mipi_dbi_release so we need to switch them all > > toge

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 1:31 PM Neil Armstrong wrote: > > Hi, > > On 19/02/2020 11:20, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_, which > > ties the release action to the underlyin

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > We have lots of these. And the cleanup code tends to be of dubious > quality. The biggest wrong pattern is that developers use devm_, which > ties the release action to the underlying struct devic

Re: [Intel-gfx] [PATCH] drm/i915: Read rawclk_freq earlier

On Sun, Feb 16, 2020 at 04:34:45PM +, Chris Wilson wrote: > Read the rawclk_freq during runtime info probing, prior to its first use > in computing the CS timestamp frequency. Then store it in the runtime > info, and include it in the debug printouts. > > Closes: https://gitlab.freedesktop.org

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Hi Am 19.02.20 um 14:23 schrieb Daniel Vetter: > On Wed, Feb 19, 2020 at 12:47 PM Thomas Zimmermann > wrote: >> >> Hi Daniel, >> >> good idea. I guess it's the simple encoder's fault. :) I only read >> briefly over the whole thing. >> >> Am 19.02.20 um 11:20 schrieb Daniel Vetter: >>> They all s

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that deve

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter

On Tue, Feb 18, 2020 at 05:42:28PM -0800, José Roberto de Souza wrote: > Most of the kms_frontbuffer_tracking tests disables the feature being > tested, draw, get the CRC then enable the feature, draw again, get the > CRC and check if it matches. > Some times it is able to do that with a fastset, s

[Intel-gfx] [CI] drm/i915: split i915_driver_modeset_probe() to pre/post irq install

Pair the irq install and uninstall in the same layer. There are no functional changes in the happy day scenario. The cleanup paths are currently a mess though. Note that modeset probe pre-irq + post-irq install are matched by modeset driver remove pre-irq + post-irq uninstall, together, but not in

Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. I'd split this patch in two then, with the Xen first coming fir

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

== Series Details == Series: drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired URL : https://patchwork.freedesktop.org/series/73641/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16620 =

Re: [Intel-gfx] [PATCH 07/52] drm/udl: Use drmm_add_final_kfree

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:37AM +0100, Daniel Vetter wrote: > With this we can drop the final kfree from the release function. > > v2: We need drm_dev_put to unroll the driver creation (once > drm_dev_init and drmm_add_final_kfree suceeded), otherwise > the

Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote: > drm_mode_config_cleanup is idempotent, so no harm in calling this > twice. This allows us to gradually switch drivers over by removing > explicit drm_mode_config_cleanup calls. > > With this step

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:07AM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). Could you mention in the commit message that the call can be dropped because drm_mode_config_init() uses the managed API to handle cleaning automatically, remo

Re: [Intel-gfx] [PATCH 40/52] drm/shmob: Drop explicit drm_mode_config_cleanup call

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:10AM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... With the same comments as the one for the rcar-du

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 2:29 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers us

  1   2   3   >