kernel/linux.git/Documentation/gpu/drm-internals.rst, branch linux-7.1.y

drm/doc: Document KUnit expectations

2025-02-26T15:04:15+00:00

The DRM and KMS frameworks and helpers gain more and more kunit coverage, so let's document what our expectations are. Suggested-by: Jani Nikula Acked-by: Maíra Canal Acked-by: Tvrtko Ursulin Reviewed-by: Javier Martinez Canillas Acked-by: Jani Nikula Acked-by: Simona Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20250113101100.1373856-1-mripard@kernel.org Signed-off-by: Maxime Ripard

drm: Remove DRM aperture helpers

2024-10-14T13:28:48+00:00

The DRM aperture helpers are wrappers around video helpers from . There are no callers of these functions. Remove them entirely. Signed-off-by: Thomas Zimmermann Cc: Jonathan Corbet Acked-by: Javier Martinez Canillas Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20240930130921.689876-29-tzimmermann@suse.de

drm: deprecate driver date

2024-05-08T12:31:58+00:00

The driver date serves no useful purpose, because it's hardly ever updated. The information is misleading at best. As described in Documentation/gpu/drm-internals.rst: The driver date, formatted as YYYYMMDD, is meant to identify the date of the latest modification to the driver. However, as most drivers fail to update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. Stop printing the driver date at init, and start returning the empty string "" as driver date through the DRM_IOCTL_VERSION ioctl. The driver date initialization in drivers and the struct drm_driver date member can be removed in follow-up. Reviewed-by: Hamza Mahfooz Acked-by: Simon Ser Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240429164336.1406480-1-jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/doc: internals: remove section on PCI legacy support

2024-01-12T12:58:35+00:00

The functions that were described in this section of drm-internals.rst were removed in NOV-2023, along with all of the kernel-doc comments in the source file. This now causes a docs build warning, so remove that section of the documentation also. drivers/gpu/drm/drm_pci.c:1: warning: no structured comments found Fixes: 2504c7ec728b ("drm: Remove source code for non-KMS drivers") Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20240112051731.15722-1-rdunlap@infradead.org

drm/doc: Add KUnit documentation

2022-06-27T11:46:03+00:00

Explain how to run the KUnit tests present in the DRM subsystem and clarify why the UML-only options were not added to the configuration file present in drivers/gpu/drm/.kunitconfig [1] [2]. [1] https://lore.kernel.org/dri-devel/CABVgOSn8i=LO5p7830h2XU1Jgg0KrN0qTnxkOMhf1oTgxjaKKw@mail.gmail.com/ [2] https://lore.kernel.org/dri-devel/CAGS_qxqpiCim_sy1LDK7PLwVgWf-LKW+uNFTGM=T7ydk-dYcEw@mail.gmail.com/ Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Reviewed-by: David Gow Acked-by: Thomas Zimmermann Signed-off-by: José Expósito Link: https://patchwork.freedesktop.org/patch/msgid/20220620160640.3790-4-jose.exposito89@gmail.com

drm: Provide PCI module-init macros

2022-01-19T17:39:43+00:00

Provide helper macros to register PCI-based DRM drivers. The new macros behave like module_pci_driver() with an additional test if DRM modesetting has been enabled. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-2-javierm@redhat.com

DRM: delete DRM IRQ legacy midlayer docs

2021-10-06T09:12:29+00:00

Remove documentation associated with the removal of the DRM IRQ legacy midlayer. Eliminates these documentation warnings: ../drivers/gpu/drm/drm_irq.c:1: warning: 'irq helpers' not found ../drivers/gpu/drm/drm_irq.c:1: warning: no structured comments found Fixes: c1736b9008cb ("drm: IRQ midlayer is now legacy") Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: dri-devel@lists.freedesktop.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20211005025312.20913-1-rdunlap@infradead.org Signed-off-by: Maarten Lankhorst

drm/aperture: Add infrastructure for aperture ownership

2021-04-14T07:00:04+00:00

Platform devices might operate on firmware framebuffers, such as VESA or EFI. Before a native driver for the graphics hardware can take over the device, it has to remove any platform driver that operates on the firmware framebuffer. Aperture helpers provide the infrastructure for native drivers to remove the generic ones. For now, this only concerns generic fbdev drivers. Code for removing these is provided by drm_fb_helper_remove_conflicting_framebuffers() et al. Simply wrap these functions for now. At a later point, code can be added for generic DRM drivers to acquire firmware framebuffers. v2: * fix docs for drm_aperture_remove_framebuffers() Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-2-tzimmermann@suse.de

drm: Add docs for managed resources

2020-03-26T15:09:48+00:00

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_add_final_kfree() combo. Needs to be a macro since we'll have to do some typeof trickery and casting to make this fully generic for all drivers that embed struct drm_device into their own thing. - A lot of the simple drivers now have essentially just drm_dev_unplug(); drm_atomic_helper_shutdown(); as their $bus_driver->remove hook. We could create a devm_mode_config_reset which sets drm_atomic_helper_shutdown as it's cleanup action, and a devm_drm_dev_register with drm_dev_unplug as it's cleanup action, and simple drivers wouldn't have a need for a ->remove function at all, and we could delete them. - For more complicated drivers we need drmm_ versions of a _lot_ more things. All the userspace visible objects (crtc, plane, encoder, crtc), anything else hanging of those (maybe a drmm_get_edid, at least for panels and other built-in stuff). Also some more thoughts on why we're not reusing devm_ with maybe a fake struct device embedded into the drm_device (we can't use the kdev, since that's in each drm_minor). - Code review gets extremely tricky, since every time you see a devm_ you need to carefully check whether the fake device (with the drm_device lifetim) or the real device (with the lifetim of the underlying physical device and driver binding) are used. That's not going to help at all, and we have enormous amounts of drivers who use devm_ where they really shouldn't. Having different types makes sure the compiler type checks this for us and ensures correctness. - The set of functions are very much non-overlapping. E.g. devm_ioremap makes total sense, drmm_ioremap has the wrong lifetime, since hw resources need to be cleaned out at driver unbind and wont outlive that like a drm_device. Similar, but other way round for drmm_connector_init (which is the only correct version, devm_ for drm_connector is just buggy). Simply not having the wrong version again prevents bugs. Finally I guess this opens a huge todo for all the drivers. I'm semi-tempted to do a tree-wide s/devm_kzalloc/drmm_kzalloc/ since most likely that'll fix an enormous amount of bugs and most likely not cause any issues at all (aside from maybe holding onto memory slightly too long). v2: - Doc improvements from Laurent. - Also add kerneldoc for the new drmm_add_action_or_reset. v3: - Remove kerneldoc for drmm_remove_action. Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: Laurent Pinchart Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Signed-off-by: Daniel Vetter fixup docs Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-52-daniel.vetter@ffwll.ch

drm: add managed resources tied to drm_device

2020-03-26T13:49:13+00:00

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