drm/mgag200: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
drm/ast: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
drm/ttm: clean up ttm_trace_dma_map/ttm_trace_dma_unmap (v2)
ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore.
v2: remove the file completely
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/360432/
Jason Yan [Fri, 3 Apr 2020 02:16:09 +0000 (10:16 +0800)]
video: fbdev: matroxfb: remove dead code and set but not used variable
Fix the following gcc warning:
drivers/video/fbdev/matrox/g450_pll.c:336:15: warning: variable
‘pixel_vco’ set but not used [-Wunused-but-set-variable]
unsigned int pixel_vco;
^~~~~~~~~
In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'assigned-clocks' and
'assigned-clock-rates' for rk3399 and 'power-domains' for most
Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'.
Lyude Paul [Mon, 6 Apr 2020 20:06:42 +0000 (16:06 -0400)]
drm/dp_mst: Remove drm_dp_mst_has_audio()
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there's no use in keeping this function around as all it
does is validate the port pointer before checking the audio status.
Note - drm_dp_mst_port->has_audio is technically protected by
drm_device->mode_config.connection_mutex, since it's only ever updated
from drm_dp_mst_get_edid(). Additionally, we change the declaration for
port in struct intel_connector to be properly typed, so we can directly
access it.
Changes since v1:
* Change type of intel_connector->port in a separate patch - Sean Paul
Lyude Paul [Mon, 6 Apr 2020 20:06:41 +0000 (16:06 -0400)]
drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port
The only reason for having this cast as void * before was because we
originally needed to use drm_dp_mst_get_port_validated() and friends in
order to (attempt to) safely access MST ports. However, we've since
improved how reference counting works with ports and mstbs such that we
can now rely on drm_dp_mst_port structs remaining in memory for as long
as the driver needs. This means we don't really need to cast this as
void* anymore, and can just access the struct directly.
We'll also need this for the next commit, so that we can remove
drm_dp_mst_port_has_audio().
Sam Ravnborg [Mon, 6 Apr 2020 19:47:44 +0000 (21:47 +0200)]
drm/vblank: Add intro to documentation
Lyude Paul wrote a very good intro to vblank here:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.camel@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Add this to the intro chapter in drm_vblank.c so others
can benefit from it too.
v2:
- Reworded to improve readability (Thomas)
v3:
- Added nice ascii drawing from Lyude (Lyude)
- Added referende to high-precision timestamp (Daniel)
- Improved grammar (Thomas)
- Combined it all and made kernel-doc happy
- Dropped any a-b, r-b do to the amount of changes
v4:
- Add intro to vblank interrupt (Liviu)
- Add historical reference for blanking (Alex)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Co-developed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200406194746.26433-2-sam@ravnborg.org
Sam Ravnborg [Mon, 6 Apr 2020 19:47:45 +0000 (21:47 +0200)]
drm: writeback: document callbacks
Document the callbacks:
drm_connector_helper_funcs.prepare_writeback_job
drm_connector_helper_funcs.cleanup_writeback_job
The documentation was pulled from the changelong introducing the
callbacks, originally written by Laurent.
Adding the missing documentation fixes the following warnings:
drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'prepare_writeback_job' not described in 'drm_connector_helper_funcs'
drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'cleanup_writeback_job' not described in 'drm_connector_helper_funcs'
v2:
- Fix formatting (Daniel)
- Drop changelog text and add reference (Daniel)
- Improve grammar. and use "operation" (Laurent)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200406194746.26433-3-sam@ravnborg.org
Lyude Paul [Fri, 3 Apr 2020 20:03:25 +0000 (16:03 -0400)]
drm/dp_mst: Don't drop NAKs for down responses
It looks like that when we introduced the ability to handle multiple
down requests at once, we accidentally started dropping NAK replies -
causing sideband messages which got NAK'd to seemingly timeout and cause
all sorts of weirdness.
So, fix this by making sure we don't return from
drm_dp_mst_handle_down_rep() early, but instead treat NAKs like any
other message.
Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Wayne Lin <waynelin@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200403200325.885628-1-lyude@redhat.com Reviewed-by: Sean Paul <sean@poorly.run>
Lyude Paul [Mon, 6 Apr 2020 19:33:52 +0000 (15:33 -0400)]
drm/dp_mst: Fix NULL deref in drm_dp_get_one_sb_msg()
While we don't need this function to store an mstb anywhere for UP
requests since we process them asynchronously, we do need to make sure
that we don't try to write to **mstb for UP requests otherwise we'll
cause a NULL pointer deref:
Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <waynelin@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200406193352.1245985-1-lyude@redhat.com Reviewed-by: Sean Paul <sean@poorly.run>
Sam Ravnborg [Sat, 28 Mar 2020 13:20:25 +0000 (14:20 +0100)]
drm/bridge: fix kernel-doc warning in panel.c
Add missing documentation to fix following warning:
panel.c:303: warning: Function parameter or member 'bridge' not described in 'drm_panel_bridge_connector'
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Mihail Atanassov <Mihail.Atanassov@arm.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-7-sam@ravnborg.org
Lyude Paul [Tue, 31 Mar 2020 20:57:36 +0000 (16:57 -0400)]
drm/amd/amdgpu_dm/mst: Stop printing extra messages in dm_dp_add_mst_connector()
You can already trace the creation and destruction of connectors using
DRM, and we definitely don't need to be printing info messages on
connector hotplugs as well. So, get rid of these.
Pankaj Bharadiya started cleaning up the MST connector callbacks a while
ago, as I pointed out that they are the same across every driver and
don't serve much purpose. There was one callback that was left over
though from amdgpu, that we delayed removing due to not being completely
sure as to whether or not it was needed.
So, I've read through said callback and can confirm it's not at all
needed. Pretty much all of the work that is done in
dm_dp_destroy_mst_connector() can be done in
dm_dp_mst_connector_destroy(). Additionally, I've removed some bits that
didn't actually do anything:
* Removed DRM_INFO message we were printing, this shouldn't be info
level and there's more appropriate drm debugging flags that should be
used instead
* Removed amdgpu_dm_update_freesync_caps() - reading into this function,
it doesn't actually do anything important and I'm not sure why it was
ever being called here
* Stop clearing aconnector->dc_sink - this also doesn't do anything
* Stop clearing link settings in dc_link - this also doesn't do anything
* Also, use shorter variable
Tian Tao [Fri, 6 Mar 2020 03:43:01 +0000 (11:43 +0800)]
drm/hisilicon: Enforce 128-byte stride alignment to fix the hardware limitation
because the hardware limitation,The initial color depth must set to 32bpp
and must set the FB Offset of the display hardware to 128Byte alignment,
which is used to solve the display problem at 800x600 and 1440x900
resolution under 16bpp.
The gma500 driver uses empty implementations for some of its encoders.
Replace the code with the generic simple encoder. As a side effect, the
patch also removes an indirection in the encoder setup for Medfield.
Some drivers (komeda, malidp) don't set anything in cpp. If that is the
case the right value can be inferred from the format. Then the "bpp" member
can be eliminated from struct drm_afbc_framebuffer.
Christian König [Tue, 10 Mar 2020 13:23:12 +0000 (14:23 +0100)]
drm/amdgpu: improve amdgpu_gem_info debugfs file
Note if a buffer was imported using peer2peer.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359296
Christian König [Fri, 23 Mar 2018 15:56:37 +0000 (16:56 +0100)]
drm/amdgpu: add support for exporting VRAM using DMA-buf v3
We should be able to do this now after checking all the prerequisites.
v2: fix entrie count in the sgt
v3: manually construct the sg
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359295
Christian König [Fri, 23 Mar 2018 15:33:57 +0000 (16:33 +0100)]
drm/amdgpu: add checks if DMA-buf P2P is supported
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359294
Christian König [Thu, 22 Mar 2018 18:21:30 +0000 (19:21 +0100)]
drm/amdgpu: note that we can handle peer2peer DMA-buf
Importing should work out of the box.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359293
Christian König [Mon, 30 Mar 2020 13:45:01 +0000 (15:45 +0200)]
drm/ttm: lock resv object during destruction
Calling ttm_bo_cleanup_memtype_use() destroys the TT object
which in turn could result in warnings without this.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359288
Christian König [Thu, 22 Mar 2018 16:09:42 +0000 (17:09 +0100)]
dma-buf: add peer2peer flag
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359286/
Huacai Chen [Tue, 31 Mar 2020 06:18:08 +0000 (14:18 +0800)]
drm/qxl: Use correct notify port address when creating cursor ring
The command ring and cursor ring use different notify port addresses
definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in
qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring
and cursor ring. This doesn't cause any problems now, because QEMU's
behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same.
However, QEMU's behavior may be change in future, so let's fix it.
P.S.: In the X.org QXL driver, the notify port address of cursor ring
is correct.
Daniel Vetter [Sat, 28 Mar 2020 16:23:58 +0000 (17:23 +0100)]
drm/managed: Fix off-by-one in warning
I'm thinking this is the warning that fired in the 0day report, but I
can't double-check yet since 0day didn't upload its source tree
anywhere I can check. And all the drivers I can easily test don't use
drm_dev_alloc anymore ...
Also if I'm correct supreme amounts of bad luck because usually kslap
(for bigger structures) gives us something quite a bit bigger than
what we asked for.
[0day uploaded tree, guess is correct]
Reported-by: kernel test robot <lkp@intel.com> Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device") Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> 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/20200328162358.18500-1-daniel.vetter@ffwll.ch
Sam Ravnborg [Sat, 28 Mar 2020 13:20:21 +0000 (14:20 +0100)]
drm/fb: fix kernel-doc in drm_framebuffer.h
Fix following warnings:
drm_framebuffer.h:342: warning: Function parameter or member 'block_width' not described in 'drm_afbc_framebuffer'
drm_framebuffer.h:342: warning: Function parameter or member 'block_height' not described in 'drm_afbc_framebuffer'
Trivial spelling mistakes.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Fixes: 55f7f72753ab ("drm/core: Add drm_afbc_framebuffer and a corresponding helper") Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: James Qian Wang <james.qian.wang@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-3-sam@ravnborg.org
Sam Ravnborg [Sat, 28 Mar 2020 13:20:24 +0000 (14:20 +0100)]
drm/dp_mst: add kernel-doc for drm_dp_mst_port.fec_capable
Fix kernel-doc warnings for drm_dp_mst_port.fec_capable.
This fixed the following warning:
drm_dp_mst_helper.h:162: warning: Function parameter or member
'fec_capable' not described in 'drm_dp_mst_port'
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: David Francis <David.Francis@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch>
[Wrapped commit msg + s/network/topology] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-6-sam@ravnborg.org
Emil Velikov [Thu, 19 Mar 2020 17:29:30 +0000 (17:29 +0000)]
drm: error out with EBUSY when device has existing master
As requested by Adam, provide different error message for when the
device has an existing master. An audit of the following projects, shows
that the errno is used only for printf() purposes.
Emil Velikov [Thu, 19 Mar 2020 17:29:29 +0000 (17:29 +0000)]
drm: rework SET_MASTER and DROP_MASTER perm handling
This commit reworks the permission handling of the two ioctls. In
particular it enforced the CAP_SYS_ADMIN check only, if:
- we're issuing the ioctl from process other than the one which opened
the node, and
- we are, or were master in the past
This ensures that we:
- do not regress the systemd-logind style of DRM_MASTER arbitrator
- allow applications which do not use systemd-logind to drop their
master capabilities (and regain them at later point) ... w/o running as
root.
See the comment above drm_master_check_perm() for more details.
v1:
- Tweak wording, fixup all checks, add igt test
Fabio Estevam [Sat, 28 Mar 2020 18:36:41 +0000 (15:36 -0300)]
dt-bindings: display: xpp055c272: Remove the reg property
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.example.dts:17.5-29.11: Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges property, but no unit name
Fabio Estevam [Sat, 28 Mar 2020 18:36:40 +0000 (15:36 -0300)]
dt-bindings: display: ltk500hd1829: Remove the reg property
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11: Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges property, but no unit name
Pascal Roeleven [Fri, 20 Mar 2020 11:21:33 +0000 (12:21 +0100)]
drm: panel: Add Starry KR070PE2T
The KR070PE2T is a 7" panel with a resolution of 800x480.
KR070PE2T is the marking present on the ribbon cable. As this panel is
probably available under different brands, this marking will catch
most devices.
As I can't find a datasheet for this panel, the bus_flags are instead
from trial-and-error. The flags seem to be common for these kind of
panels as well.
drm/lima: Add optional devfreq and cooling device support
Most platforms with a Mali-400 or Mali-450 GPU also have support for
changing the GPU clock frequency. Add devfreq support so the GPU clock
rate is updated based on the actual GPU usage when the
"operating-points-v2" property is present in the board.dts.
The actual devfreq code is taken from panfrost_devfreq.c and modified so
it matches what the lima hardware needs:
- a call to dev_pm_opp_set_clkname() during initialization because there
are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
the GPU so we need to control it using devfreq.
- locking when reading or writing the devfreq statistics because (unlike
than panfrost) we have multiple PP and GP IRQs which may finish jobs
concurrently.
Sean Paul [Thu, 13 Feb 2020 21:15:20 +0000 (16:15 -0500)]
drm/dp_mst: Remove single tx msg restriction.
Now that we can support multiple simultaneous replies, remove the
restrictions placed on sending new tx msgs.
This patch essentially just reverts commit 5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
now that the problem is solved in a different way.
Sean Paul [Thu, 13 Feb 2020 21:15:19 +0000 (16:15 -0500)]
drm/mst: Support simultaneous down replies
Currently we have one down reply message servicing the mst manager, so
we need to serialize all tx msgs to ensure we only have one message in
flight at a time. For obvious reasons this is suboptimal (but less
suboptimal than the free-for-all we had before serialization).
This patch removes the single down_rep_recv message from manager and
adds 2 replies in the branch structure. The 2 replies mirrors the tx_slots
which we use to rate-limit outgoing messages and correspond to seqno in
the packet headers.
Sean Paul [Thu, 13 Feb 2020 21:15:18 +0000 (16:15 -0500)]
drm/mst: Separate sideband packet header parsing from message building
In preparation of per-branch device down message handling, separate
header parsing from message building. This will allow us to peek at
figure out which branch device the message is from before starting to
parse the message contents.
Hans de Goede [Thu, 26 Mar 2020 15:10:09 +0000 (16:10 +0100)]
drm/fb-helper: Add TODO for making drm_fb_helper_alloc_fbi fill apertures
Currently drivers using drm_fbdev_generic_setup() end up with a single
empty aperture in their fb_info struct.
Not having the proper info in the apertures list causes
register_framebuffer to not remove conflicting framebuffers,
which some drivers currently workaround by manually calling
drm_fb_helper_remove_conflicting_pci_framebuffers().
Add a TODO as a reminder that we need to fix this.
Daniel Vetter [Mon, 23 Mar 2020 14:49:50 +0000 (15:49 +0100)]
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_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 <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
fixup docs Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-52-daniel.vetter@ffwll.ch
projects / kernel.git / log