2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-08 10:26:18 +02:00
|
|
|
|
2017-10-30 16:39:38 +01:00
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:29 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 11:18:01 +01:00
|
|
|
|
2019-01-08 20:29:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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 <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Neil Armstrong <narmstrong@baylibre.com
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
2020-03-24 13:45:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2020-11-04 11:04:23 +01:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-03 15:57:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-02 09:26:27 +02:00
|
|
|
|
2020-04-03 15:57:47 +02:00
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2023-01-09 17:46:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2023-01-09 17:46:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
accel: add dedicated minor for accelerator devices
The accelerator devices are exposed to user-space using a dedicated
major. In addition, they are represented in /dev with new, dedicated
device char names: /dev/accel/accel*. This is done to make sure any
user-space software that tries to open a graphic card won't open
the accelerator device by mistake.
The above implies that the minor numbering should be separated from
the rest of the DRM devices. However, to avoid code duplication, we
want the drm_minor structure to be able to represent the accelerator
device.
To achieve this, we add a new drm_minor* to drm_device that represents
the accelerator device. This pointer is initialized for drivers that
declare they handle compute accelerator, using a new driver feature
flag called DRIVER_COMPUTE_ACCEL. It is important to note that this
driver feature is mutually exclusive with DRIVER_RENDER. Devices that
want to expose both graphics and compute device char files should be
handled by two drivers that are connected using the auxiliary bus
framework.
In addition, we define a different IDR to handle the accelerators
minors. This is done to make the minor's index be identical to the
device index in /dev/. Any access to the IDR is done solely
by functions in accel_drv.c, as the IDR is define as static. The
DRM core functions call those functions in case they detect the minor's
type is DRM_MINOR_ACCEL.
We define a separate accel_open function (from drm_open) that the
accel drivers should set as their open callback function. Both these
functions eventually call the same drm_open_helper(), which had to be
changed to be non-static so it can be called from accel_drv.c.
accel_open() only partially duplicates drm_open as I removed some code
from it that handles legacy devices.
To help new drivers, I defined DEFINE_DRM_ACCEL_FOPS macro to easily
set the required function operations pointers structure.
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Tested-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
2022-10-31 15:33:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
2018-09-13 16:16:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-28 10:38:35 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-15 10:50:45 +01:00
|
|
|
|
2023-11-22 13:09:41 +01:00
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-24 13:01:07 +00:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
2018-07-03 18:03:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2018-07-03 18:03:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2018-07-03 18:03:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2018-07-03 18:03:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-25 16:51:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-27 20:20:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
2019-01-08 20:29:28 +01:00
|
|
|
|
2019-05-08 10:26:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-08 20:29:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-30 16:39:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-11 17:40:48 +01:00
|
|
|
|
2023-08-29 13:01:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 13:56:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
