aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-03-26drm/mcde: More devm_drm_dev_initDaniel Vetter1-6/+3
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. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/mcde: Drop explicit drm_mode_config_cleanup callDaniel Vetter1-14/+6
Allows us to drop the drm_driver.release callback. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by: Sam Ravnborg <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Reviewed-by: Linus Walleij <[email protected]> (v2) Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/ingenic: Drop explicit drm_mode_config_cleanup callDaniel Vetter1-7/+4
Allows us to drop the drm_driver.release callback. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by: Sam Ravnborg <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Reviewed-by: Paul Cercueil <[email protected]> (v2) Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Paul Cercueil <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/cirrus: Fully embrace devm_Daniel Vetter1-30/+14
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. Acked-by: Gerd Hoffmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/cirrus: Drop explicit drm_mode_config_cleanup callDaniel Vetter1-10/+11
We can even delete the drm_driver.release hook now! This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by: Gerd Hoffmann <[email protected]> Cc: Sam Ravnborg <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/bochs: Drop explicit drm_mode_config_cleanupDaniel Vetter3-14/+7
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. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by: Gerd Hoffmann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/bochs: Remove leftover drm_atomic_helper_shutdownDaniel Vetter1-1/+0
Small mistake that crept into commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab Author: Gerd Hoffmann <[email protected]> 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 hardware. Acked-by: Gerd Hoffmann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Manage drm_mode_config_init with drmm_Daniel Vetter2-19/+27
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 now also possible that (at least for simple drivers) automatic resource cleanup can be done correctly without a drm_driver->release hook. Therefore allow this now in devm_drm_dev_init(). Also with drmm_ explicit drm_driver->release hooks are kinda not the best option: Drivers can always just register their current release hook with drmm_add_action, but even better they could split them up to simplify the unwinding for the driver load failure case. So deprecate that hook to discourage future users. v2: Fixup the example in the kerneldoc too. v3: - For paranoia, double check that minor->dev == dev in the release hook, because I botched the pointer math in the drmm library. - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be missing some mutex_destroy and ida_cleanup otherwise (Laurent) v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this pattern (Noralf). v5: Fix oversight in the new drmm_add_action_or_reset macro (Noralf) v4: Review from Sam: - drmm_mode_config_init wrapper (also suggested by Thomas) - improve commit message, explain better why ->relase is deprecated v5: - Make drmm_ the main function, with the old one as compat wrapper (Sam) - Add FIXME comments to drm_mode_config_cleanup/init() that drivers shouldn't use these anymore. - Move drmm_add_action_or_reset helper to an earlier patch. Reviewed-by: Sam Ravnborg <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Garbage collect drm_dev_finiDaniel Vetter14-42/+0
It has become empty. Given the few users I figured not much point splitting this up. v2: Rebase over i915 changes. v3: Rebase over patch split fix. Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Manage drm_vblank_cleanup with drmm_Daniel Vetter3-21/+12
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 end of the release sequence for all drivers, and that's still the case. At least without more uses of drmm_ through explicit driver calls. Also for this one we need drmm_kcalloc, so lets add those. The motivation here is to allow us to remove the explicit calls to drm_dev_fini() from all drivers. v2: Sort includes (Laurent) v3: Motivate the change in the commit message better (Sam) Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Manage drm_gem_init with drmm_Daniel Vetter3-19/+11
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. Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: manage drm_minor cleanup with drmm_Daniel Vetter2-45/+38
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. Hence add drmm_remove_action() to the drm_managed library. v2: Make pointer math around void ** consistent with what Laurent suggested. v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed because of some questions from Thomas. This also means we need to move the drmm_add_action_or_reset helper earlier in the series. v4: Uh ... fix slightly embarrassing bug CI spotted. Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Use drmm_ for drm_dev_init cleanupDaniel Vetter1-23/+25
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 really pretty, but oh well. Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Handle dev->unique with drmm_Daniel Vetter2-3/+18
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. Reviewed-by: Sam Ravnborg <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Cleanups after drmm_add_final_kfree rolloutDaniel Vetter1-7/+5
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. v2: Restore the full cleanup, I accidentally left some moved code behind when fixing the bisectability of the series. Acked-by: Sam Ravnborg <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Dan Carpenter <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/<drivers>: Use drmm_add_final_kfreeDaniel Vetter3-0/+6
These are the leftover drivers that didn't have a ->release hook that needed to be updated. Acked-by: Sam Ravnborg <[email protected]> Acked-by: Liviu Dudau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: "James (Qian) Wang" <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Mihail Atanassov <[email protected]> Cc: Russell King <[email protected]> Cc: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/gm12u320: Use drmm_add_final_kfreeDaniel Vetter1-1/+2
With this we can drop the final kfree from the release function. Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/ingenic: Use drmm_add_final_kfreeDaniel Vetter1-3/+2
With this we can drop the final kfree from the release function. Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Paul Cercueil <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Paul Cercueil <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/repaper: Use drmm_add_final_kfreeDaniel Vetter1-3/+2
With this we can drop the final kfree from the release function. Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/vkms: Use drmm_add_final_kfreeDaniel Vetter1-9/+9
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. Reviewed-by: Rodrigo Siqueira <[email protected]> Tested-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Rodrigo Siqueira <[email protected]> Cc: Haneen Mohammed <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/vgem: Use drmm_add_final_kfreeDaniel Vetter1-6/+8
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. Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Sean Paul <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Rob Clark <[email protected]> Cc: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/mcde: Use drmm_add_final_kfreeDaniel Vetter1-3/+2
With this we can drop the final kfree from the release function. v2: Fix unused variable warning, spotted while applying. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/tidss: Use drmm_add_final_kfreeDaniel Vetter1-2/+2
With this we can drop the final kfree from the release function. Acked-by: Jyri Sarha <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Jyri Sarha <[email protected]> Cc: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/v3d: Use drmm_add_final_kfreeDaniel Vetter1-18/+20
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 should be able to switch over to devm_drm_dev_init, which should clean this up further. Acked-by: Eric Anholt <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/cirrus: Use drmm_add_final_kfreeDaniel Vetter1-7/+7
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. Acked-by: Gerd Hoffmann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/i915: Use drmm_add_final_kfreeDaniel Vetter3-8/+35
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 also called in the unwind code of the error path. There we need a drm_dev_put. Similar for the mock object. Now the problem with that is that the drm_driver->release callbacks for both the real driver and the mock one assume everything has been set up. Hence going through that path for a partially set up driver will result in issues. Quickest fix is to disable the ->release() hook until the driver is fully initialized, and keep the onion unwinding. Long term would be cleanest to move everything over to drmm_ release actions, but that's a lot of work for a big driver like i915. Plus more core work needed first anyway. v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch over to start using drm_dev_put() to clean up even on the error path. Aside I think the current error path is leaking the allocation. v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/ Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Abdiel Janulgue <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst299-5869/+11443
Requested for getting some i915 fixes back into drm-misc-next by danvet. Signed-off-by: Maarten Lankhorst <[email protected]>
2020-03-26drm/qxl: Use drmm_add_final_kfreeDaniel Vetter2-2/+2
With this we can drop the final kfree from the release function. Acked-by: Gerd Hoffmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/udl: Use drmm_add_final_kfreeDaniel Vetter1-3/+3
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. v3: Actually squash in the fixup (Laurent). Acked-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Sean Paul <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/mipi_dbi: Use drmm_add_final_kfree in all driversDaniel Vetter8-3/+14
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 for the drm_driver pointer). Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Tested-by: Noralf Trønnes <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Cc: David Lechner <[email protected]> Cc: Kamlesh Gurudasani <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Set final_kfree in drm_dev_allocDaniel Vetter2-1/+4
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, but leaked the drm_device ever since commit 0a6659bdc5e8221da99eebb176fd9591435e38de Author: Gerd Hoffmann <[email protected]> Date: Tue Dec 17 18:04:46 2013 +0100 drm/bochs: new driver This patch here fixes that leak. Same for virtio, started leaking with commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a Author: Gerd Hoffmann <[email protected]> Date: Tue Feb 11 14:58:04 2020 +0100 drm/virtio: add drm_driver.release callback. Acked-by: Gerd Hoffmann <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Oleksandr Andrushchenko <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Oleksandr Andrushchenko <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: add managed resources tied to drm_deviceDaniel Vetter4-4/+210
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 hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Neil Armstrong <[email protected] Cc: Greg Kroah-Hartman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/i915: Don't clear drvdata in ->releaseDaniel Vetter1-5/+0
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 be kept alive by open drm_file or well really anything else userspace is still hanging onto. So if we clear this ourselves, we should clear it in the pci ->remove callback, not in the drm_device ->release callback. Looking at git history this was fixed in the driver core with commit 0998d0631001288a5974afc0b2a5f568bcdecb4d Author: Hans de Goede <[email protected]> Date: Wed May 23 00:09:34 2012 +0200 device-core: Ensure drvdata = NULL when no driver is bound v2: Cite the core fix in the commit message (Chris). v3: Fix commit message and unused variable warning (Jani). Cc: Greg Kroah-Hartman <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-25Merge branch 'feature/staging_sm5' of ↵Dave Airlie24-1045/+3241
git://people.freedesktop.org/~sroland/linux into drm-next vmwgfx pull for for 5.7. Needed for GL4 functionality. Sync up device headers, add support for new commands, code refactoring around surface definition. Signed-off-by: Dave Airlie <[email protected]> From: "Roland Scheidegger (VMware)" <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-25Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into ↵Dave Airlie11-35/+230
drm-next - fix for potential out-of-bounds reads in the perfmon ioctl implementation from Christian - override to expose proper feature flags for the GC400 found on the STM32MP1 SoC, also from Christian - Guido fixed an issue where we would spuriously fail to enter runtime suspend due to a new GPU engine status bit on GC7000 - tree-wide change from Gustavo to get rid of zero-length arrays - fix for missed TS cache flush on GC7000, leading to spurious MMU faults from me - request pages from DMA32 zone on systems where we can't address all present memory from me Signed-off-by: Dave Airlie <[email protected]> From: Lucas Stach <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/bridge: dw-hdmi: rework csc related functionsJernej Skrabec1-10/+21
is_color_space_conversion() is a misnomer. It checks not only if color space conversion is needed, but also if format conversion is needed. This is actually desired behaviour because result of this function determines if CSC block should be enabled or not (CSC block can also do format conversion). In order to clear misunderstandings, let's rework is_color_space_conversion() to do exactly what is supposed to do and add another function which will determine if CSC block must be enabled or not. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/bridge: dw-hdmi: Add support for RGB limited rangeJernej Skrabec1-17/+46
CEA 861 standard requestis that RGB quantization range is "limited" for CEA modes. Support that by adding CSC matrix which downscales values. This allows proper color reproduction on TV and PC monitor at the same time. In future, override property can be added, like "Broadcast RGB" in i915 driver. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/bridge: dw-hdmi: do not force "none" scan modeJonas Karlman1-2/+0
Setting scan mode to "none" confuses some TVs like LG B8, which randomly change overscan percentage over time. Digital outputs like HDMI and DVI, handled by this controller, don't really need overscan, so we can always set scan mode to underscan. Actually, this is exactly what drm_hdmi_avi_infoframe_from_display_mode() already does, so we can just remove offending line. Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Signed-off-by: Jonas Karlman <[email protected]> [updated commit message] Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/sun4i: Sort includes in VI and UI layer codeJernej Skrabec2-2/+2
sun8i_mixer.h include is misplaced. Move it. Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/sun4i: de2: Don't return de2_fmt_info structJernej Skrabec4-21/+23
Now that de2_fmt_info contains only DRM <-> HW format mapping, it doesn't make sense to return pointer to structure when searching by DRM format. Rework that to return only HW format instead. This doesn't make any functional change. Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/sun4i: de2: csc_mode in de2 format struct is mostly redundantJernej Skrabec3-55/+23
For RGB formats CSC mode is always set to none and for YUV formats almost always set to YUV to RGB. Add a helper function to deduce CSC mode from format. Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-24drm/sun4i: de2: rgb field in de2 format struct is redundantJernej Skrabec4-53/+8
drm_format_info structure already contains information if format is RGB or YUV. Use that instead. Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-23drm/vmwgfx: Use vmwgfx version 2.18 to signal SM5 compatibilityThomas Hellström (VMware)1-1/+1
Signed-off-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Charmaine Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]> ___ v2: Use 2.18 instead of 2.17
2020-03-23drm/vmwgfx: Add SM5 param for userspaceDeepak Rawat1-0/+3
Add a new param for user-space to determine if kernel module is SM5 capable. Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Add surface define v4 commandDeepak Rawat2-2/+36
Surface define v4 added new member buffer_byte_stride. With this patch add buffer_byte_stride in surface metadata and create surface using new command if support is available. Also with this patch replace device specific data types with kernel types. Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Refactor surface_define to use vmw_surface_metadataDeepak Rawat4-246/+215
Makes surface_define cleaner by sending vmw_surface_metadata instead of all the arguments individually. v2: fix uninitialized return value, error message Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Split surface metadata from struct vmw_surfaceDeepak Rawat4-154/+202
Create a new structure vmw_surface_metadata representing the metadata used for creating surface. With this can make the surface_define_priv a bit cleaner. Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Add support for streamoutput with mob commandsDeepak Rawat8-7/+630
With SM5 capability a new version of streamoutput is supported by device which need backing mob and a new field. With this change the new command is supported in command buffer. v2: Also track streamoutput context binding in binding manager. v3: Track only one streamoutput as only one can be set to context. v4: Fix comment typos Signed-off-by: Deepak Rawat <[email protected]> Signed-off-by: Neha Bhende <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Rename stream output target binding tracker structDeepak Rawat3-23/+23
Previous name vmw_ctx_bindinfo_so is misleading because it actually represent so target and stream output is a new resource type that needs tracking for SM5 capable device. Also rename binding type enum and internal functions to reflect these belongs to so targets. Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>
2020-03-23drm/vmwgfx: Add support for indirect and dispatch commandsDeepak Rawat1-0/+70
Validate indirect and dispatch commands in command buffer. Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Thomas Hellström (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Roland Scheidegger <[email protected]>