user/sven/linux.git/include/drm/drm_device.h, branch v5.13

drm: Move struct drm_device.hose to legacy section

2021-01-13T13:22:37Z

The field is only relevant for legacy DRM drivers. Its only non-legacy user in the DRM core is in drm_file.c. This code is now protected by CONFIG_DRM_LEGACY. Radeon, the only driver that used the field, has been changed to maintain it's own copy. Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210112081035.6882-7-tzimmermann@suse.de

drm: Use a const drm_driver for legacy PCI devices

2021-01-05T05:20:35Z

Now that the legacy PCI support code doesn't need to write to the drm_driver structure, it can be treated as const through the whole DRM core, unconditionally. This allows declaring the structure as const in all drivers, removing one possible attack vector. Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter

drm: Move legacy device list out of drm_driver

2021-01-05T05:20:29Z

The drm_driver structure contains a single field (legacy_dev_list) that is modified by the DRM core, used to store a linked list of legacy DRM devices associated with the driver. In order to make the structure const, move the field out to a global variable. This requires locking access to the global where the local field didn't require serialization, but this only affects legacy drivers, and isn't in any hot path. While at it, compile-out the legacy_dev_list field when DRM_LEGACY isn't defined. Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter Reviewed-by: Emil Velikov

drm: fix some kernel-doc markups

2020-11-16T19:48:20Z

Some identifiers have different names between their prototypes and the kernel-doc markup. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Signed-off-by: Mauro Carvalho Chehab Acked-by: Jani Nikula Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/12d4ca26f6843618200529ce5445063734d38c04.1605521731.git.mchehab+huawei@kernel.org

drm: Allow const struct drm_driver

2020-11-06T09:31:26Z

It's nice if a big function/ioctl table like this is const. Only downside here is that we need a few more #ifdef to paper over the differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more motivation to sunset that horror show :-) v2: - Fix super important checkpatch warning (Sam) - Update the kerneldoc example too (Sam) Acked-by: Maxime Ripard Reviewed-by: Sam Ravnborg Acked-by: Thomas Zimmermann Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201104100425.1922351-4-daniel.vetter@ffwll.ch

drm/managed: Cleanup of unused functions and polishing docs

2020-09-03T14:25:06Z

Following functions are only used internally, not by drivers: - devm_drm_dev_init Also, now that we have a very slick and polished way to allocate a drm_device with devm_drm_dev_alloc, update all the docs to reflect the new reality. Mostly this consists of deleting old and misleading hints. Two main ones: - it is no longer required that the drm_device base class is first in the structure. devm_drm_dev_alloc can cope with it being anywhere - obviously embedded now strongly recommends using devm_drm_dev_alloc v2: Fix typos (Noralf) v3: Split out the removal of drm_dev_init, that's blocked on some discussions on how to convert vgem/vkms/i915-selftests. Adjust commit message to reflect that. Cc: Noralf Trønnes Acked-by: Noralf Trønnes (v2) Acked-by: Sam Ravnborg Cc: Luben Tuikov Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch

drm/doc: add WARNING for drm_device::struct_mutex

2020-05-19T20:52:25Z

The mutex should be used, only by legacy drivers. Add a big warning to deter people from using it. Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Emil Velikov Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-6-emil.l.velikov@gmail.com

drm/device: Deprecate dev_private harder

2020-04-14T16:43:18Z

We've had lots of conversions to embeddeding, but didn't stop using ->dev_private. Which defeats the point of this. Reviewed-by: Sam Ravnborg Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200403135828.2542770-4-daniel.vetter@ffwll.ch

drm: add managed resources tied to drm_device

2020-03-26T13:49:13Z

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 Cc: Thomas Zimmermann Cc: Dan Carpenter Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: Neil Armstrong Cc: "Rafael J. Wysocki" Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch

drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count

2020-01-24T17:41:34Z

Since drm_global_mutex is a true global mutex across devices, we don't want to acquire it unless absolutely necessary. For maintaining the device local open_count, we can use atomic operations on the counter itself, except when making the transition to/from 0. Here, we tackle the easy portion of delaying acquiring the drm_global_mutex for the final release by using atomic_dec_and_mutex_lock(), leaving the global serialisation across the device opens. Signed-off-by: Chris Wilson Cc: Thomas Hellström (VMware) Reviewed-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20200124130107.125404-1-chris@chris-wilson.co.uk