summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-07-13drm/vc4: hdmi: Switch to devm_pm_runtime_enableMaxime Ripard1-11/+4
devm_pm_runtime_enable() simplifies the driver a bit since it will call pm_runtime_disable() automatically through a device-managed action. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-49-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Protect device resources after removalMaxime Ripard1-17/+291
Whenever the device and driver are unbound, the main device and all the subdevices will be removed by calling their unbind() method. However, the DRM device itself will only be freed when the last user will have closed it. It means that there is a time window where the device and its resources aren't there anymore, but the userspace can still call into our driver. Fortunately, the DRM framework provides the drm_dev_enter() and drm_dev_exit() functions to make sure our underlying device is still there for the section protected by those calls. Let's add them to the HDMI driver. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-48-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Move audio structure offset checksMaxime Ripard1-20/+20
The HDMI driver unbind hook doesn't have any ALSA-related code anymore, so let's move the ALSA sanity checks and comments we have to some other part of the driver dedicated to ALSA. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-47-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Use devm to register hotplug interruptsMaxime Ripard1-30/+11
Commit 776efe800fed ("drm/vc4: hdmi: Drop devm interrupt handler for hotplug interrupts") dropped the device-managed interrupt registration because it was creating bugs and races whenever an interrupt was coming in while the device was removed. However, our latest patches to the HDMI controller driver fix this as well, so we can use device-managed interrupt handlers again. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-46-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to DRM-managed kfree to build regsetsMaxime Ripard2-18/+31
The current code to build the registers set later exposed in debugfs for the HDMI controller relies on traditional allocations, that are later free'd as part of the driver unbind hook. Since krealloc doesn't have a DRM-managed equivalent, let's add an action to free the buffer later on. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-45-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Use a device-managed action for DDCMaxime Ripard1-6/+12
The reference to the DDC controller device needs to be put back when we're done with it. Let's use a device-managed action to simplify the driver. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-44-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to device-managed CEC initializationMaxime Ripard1-44/+50
The current code to unregister our CEC device needs to be undone manually when we remove the HDMI driver. Since the CEC framework will allocate its main structure, and will defer its deallocation to when the last user will have closed it, we don't really need to take any particular measure to prevent any use-after-free and can thus use any managed action. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-43-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to device-managed ALSA initializationMaxime Ripard1-7/+36
The current code to unregister our ALSA device needs to be undone manually when we remove the HDMI driver. Since ALSA doesn't seem to support any mechanism to defer freeing something until the last user of the ALSA device is gone, we can either use a device-managed or a DRM-managed action. The consistent way would be to use a DRM-managed one, just like pretty much any framework-facing structure should be doing. However, ALSA does a lot of allocation and registration using device-managed calls. Thus, if we're going that way, by the time the DRM-managed action would run all of those allocation would have been freed and we would end up with a use-after-free. Thus, let's do a device-managed action. It's been tested with KASAN enabled and doesn't seem to trigger any issue, so it's as good as anything. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-42-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to DRM-managed connector initializationMaxime Ripard1-9/+8
The current code will call drm_connector_unregister() and drm_connector_cleanup() when the device is unbound. However, by then, there might still be some references held to that connector, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-41-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to DRM-managed encoder initializationMaxime Ripard1-5/+9
The current code will call drm_encoder_cleanup() when the device is unbound. However, by then, there might still be some references held to that encoder, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-40-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Remove call to drm_connector_unregister()Maxime Ripard1-9/+3
drm_connector_unregister() is only to be used for connectors that have been registered through drm_connector_register() after drm_dev_register() has been called. This is our case here so let's remove the call. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-39-maxime@cerno.tech
2022-07-13drm/vc4: hdmi: Switch to drmm_kzallocMaxime Ripard1-1/+2
Our internal structure that stores the DRM entities structure is allocated through a device-managed kzalloc. This means that this will eventually be freed whenever the device is removed. In our case, the most likely source of removal is that the main device is going to be unbound, and component_unbind_all() is being run. However, it occurs while the DRM device is still registered, which will create dangling pointers, eventually resulting in use-after-free. Switch to a DRM-managed allocation to keep our structure until the DRM driver doesn't need it anymore. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-38-maxime@cerno.tech
2022-07-13drm/vc4: dsi: Switch to devm_pm_runtime_enableMaxime Ripard1-4/+4
devm_pm_runtime_enable() simplifies the driver a bit since it will call pm_runtime_disable() automatically through a device-managed action. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-37-maxime@cerno.tech
2022-07-13drm/vc4: dsi: Fix the driver structure lifetimeMaxime Ripard1-1/+37
The vc4_dsi structure is currently allocated through a device-managed allocation. This can lead to use-after-free issues however in the unbinding path since the DRM entities will stick around, but the underlying structure has been freed. However, we can't just fix it by using a DRM-managed allocation like we did for the other drivers since the DSI case is a bit more intricate. Indeed, the structure will be allocated at probe time, when we don't have a DRM device yet, to be able to register the DSI bus driver. We will then reuse it at bind time to register our KMS entities in the framework. In order to work around both constraints, we can use a kref to track the users of the structure (DSI host, and KMS), and then put our structure when the DSI host will have been unregistered, and through a DRM-managed action that will execute once we won't need the KMS entities anymore. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-36-maxime@cerno.tech
2022-07-13drm/vc4: dsi: Switch to drmm_of_get_bridgeMaxime Ripard1-1/+1
The current code uses a device-managed function to retrieve the next bridge downstream. However, that means that it will be removed at unbind time, where the DRM device is still very much live and might still have some applications that still have it open. Switch to a DRM-managed variant to clean everything up once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-35-maxime@cerno.tech
2022-07-13drm/vc4: dsi: Switch to DRM-managed encoder initializationMaxime Ripard1-2/+7
The current code will call drm_encoder_cleanup() when the device is unbound. However, by then, there might still be some references held to that encoder, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-34-maxime@cerno.tech
2022-07-13drm/vc4: dsi: Embed DRM structures into the private structureMaxime Ripard1-36/+22
The VC4 DSI driver private structure contains only a pointer to the encoder it implements. This makes the overall structure somewhat inconsistent with the rest of the driver, and complicates its initialisation without any apparent gain. Let's embed the drm_encoder structure (through the vc4_encoder one) into struct vc4_dsi to fix both issues. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-33-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Protect device resourcesMaxime Ripard1-0/+14
Our current code now mixes some resources whose lifetime are tied to the device (clocks, IO mappings, etc.) and some that are tied to the DRM device (encoder, bridge). The device one will be freed at unbind time, but the DRM one will only be freed when the last user of the DRM device closes its file handle. So we end up with a time window during which we can call the encoder hooks, but we don't have access to the underlying resources and device. Let's protect all those sections with drm_dev_enter() and drm_dev_exit() so that we bail out if we are during that window. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-32-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Switch to drmm_of_get_bridgeMaxime Ripard1-1/+2
The current code uses a device-managed function to retrieve the next bridge downstream. However, that means that it will be removed at unbind time, where the DRM device is still very much live and might still have some applications that still have it open. Switch to a DRM-managed variant to clean everything up once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-31-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Switch to DRM-managed encoder initializationMaxime Ripard1-15/+8
The current code will call drm_encoder_cleanup() when the device is unbound. However, by then, there might still be some references held to that encoder, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-30-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Add action to disable the clockMaxime Ripard1-3/+11
The DPI controller has two clocks called core and pixel, the core clock being enabled at bind time. Adding a device-managed action will make the error path easier, so let's create one to disable it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-29-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Remove unnecessary drm_of_panel_bridge_remove callMaxime Ripard1-2/+0
Since we have a managed call to create our panel_bridge instance, the call to drm_of_panel_bridge_remove() at unbind is both redundant and dangerous since it might lead to a use-after-free. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-28-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Return an error if we can't enable our clockMaxime Ripard1-1/+4
If we fail to enable the DPI clock, we just ignore the error and moves forward. Let's return an error instead. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-27-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Switch to drmm_kzallocMaxime Ripard1-1/+2
Our internal structure that stores the DRM entities structure is allocated through a device-managed kzalloc. This means that this will eventually be freed whenever the device is removed. In our case, the most likely source of removal is that the main device is going to be unbound, and component_unbind_all() is being run. However, it occurs while the DRM device is still registered, which will create dangling pointers, eventually resulting in use-after-free. Switch to a DRM-managed allocation to keep our structure until the DRM driver doesn't need it anymore. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-26-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Embed DRM structures into the private structureMaxime Ripard1-33/+16
The VC4 DPI driver private structure contains only a pointer to the encoder it implements. This makes the overall structure somewhat inconsistent with the rest of the driver, and complicates its initialisation without any apparent gain. Let's embed the drm_encoder structure (through the vc4_encoder one) into struct vc4_dpi to fix both issues. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-25-maxime@cerno.tech
2022-07-13drm/vc4: dpi: Remove vc4_dev dpi pointerMaxime Ripard2-8/+0
There's no user for that pointer so let's just get rid of it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-24-maxime@cerno.tech
2022-07-13drm/vc4: crtc: Switch to DRM-managed CRTC initializationMaxime Ripard3-12/+6
The current code will call drm_crtc_cleanup() when the device is unbound. However, by then, there might still be some references held to that CRTC, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-23-maxime@cerno.tech
2022-07-13drm/vc4: crtc: Switch to drmm_kzallocMaxime Ripard1-1/+1
Our internal structure that stores the DRM entities structure is allocated through a device-managed kzalloc. This means that this will eventually be freed whenever the device is removed. In our case, the most likely source of removal is that the main device is going to be unbound, and component_unbind_all() is being run. However, it occurs while the DRM device is still registered, which will create dangling pointers, eventually resulting in use-after-free. Switch to a DRM-managed allocation to keep our structure until the DRM driver doesn't need it anymore. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-22-maxime@cerno.tech
2022-07-13drm/vc4: crtc: Move debugfs_name to crtc_dataMaxime Ripard3-11/+12
All the CRTCs, including the TXP, have a debugfs file and name so we can consolidate it into vc4_crtc_data. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-21-maxime@cerno.tech
2022-07-13drm/vc4: plane: Switch to drmm_universal_plane_alloc()Maxime Ripard2-16/+8
Let's switch to drmm_universal_plane_alloc() for our plane allocation and initialisation to make the driver a bit simpler. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-20-maxime@cerno.tech
2022-07-13drm/vc4: crtc: Remove manual plane removal on errorMaxime Ripard1-10/+1
When vc4_crtc_bind() fails after vc4_crtc_init() has been called, we have a loop undoing the plane creation and calling destroy on each plane registered and matching the possible_crtcs mask. However, this is redundant with what drm_mode_config_cleanup() is doing, so let's remove it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-19-maxime@cerno.tech
2022-07-13drm/vc4: plane: Take possible_crtcs as an argumentMaxime Ripard3-10/+10
vc4_plane_init() currently initialises the plane with no possible CRTCs, and will expect the caller to set it up by itself. Let's change that logic a bit to follow the syntax of drm_universal_plane_init() and pass the possible CRTCs bitmask as an argument to the function instead. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-18-maxime@cerno.tech
2022-07-13drm/vc4: hvs: Remove planes currently allocated before taking downMaxime Ripard1-0/+7
When the HVS driver is unbound, a lot of memory allocations in the LBM and DLIST RAM are still assigned to planes that are still allocated. Thus, we hit a warning when calling drm_mm_takedown() since the memory pool is not completely free of allocations. Let's free all the currently live entries before calling drm_mm_takedown(). Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-17-maxime@cerno.tech
2022-07-13drm/vc4: hvs: Protect device resources after removalMaxime Ripard1-6/+93
Whenever the device and driver are unbound, the main device and all the subdevices will be removed by calling their unbind() method. However, the DRM device itself will only be freed when the last user will have closed it. It means that there is a time window where the device and its resources aren't there anymore, but the userspace can still call into our driver. Fortunately, the DRM framework provides the drm_dev_enter() and drm_dev_exit() functions to make sure our underlying device is still there for the section protected by those calls. Let's add them to the HVS driver. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-16-maxime@cerno.tech
2022-07-13drm/vc4: crtc: Create vblank reporting functionMaxime Ripard2-8/+16
We'll need that code in the HVS driver, so let's create a shared function to reuse it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-15-maxime@cerno.tech
2022-07-13drm/vc4: drv: Use drm_dev_unplugMaxime Ripard1-2/+1
When our KMS driver is unbound, the device is no longer there but we might still have users with an opened fd to the KMS device. To avoid any issue in such a situation, every device access needs to be protected by calls to drm_dev_enter() and drm_dev_exit(), and the driver needs to call drm_dev_unplug(). We'll add calls to drm_dev_enter()/drm_dev_exit() in subsequent patches changing the relevant drivers, but let's start by calling drm_dev_unplug(). Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-14-maxime@cerno.tech
2022-07-13drm/vc4: drv: Call component_unbind_all()Maxime Ripard2-2/+13
While we were using the component framework to deal with all the DRM subdevices, we were not calling component_unbind_all(). This leads to none of the subdevices freeing up their resources as part of their unbind() or device managed hooks. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-13-maxime@cerno.tech
2022-07-13drm/bridge: panel: Introduce drmm_of_get_bridgeMaxime Ripard1-0/+35
Unlike what can be found for other DRM entities, we don't have a DRM-managed function equivalent to devm_drm_of_get_bridge(). Let's create it. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-12-maxime@cerno.tech
2022-07-13drm/bridge: panel: Introduce drmm_panel_bridge_addMaxime Ripard1-0/+39
Unlike what can be found for other entities, there's no DRM-managed function to create a panel_bridge instance from a panel. Let's introduce one. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-11-maxime@cerno.tech
2022-07-13drm/connector: Introduce drmm_connector_initMaxime Ripard1-0/+60
Unlike other DRM entities, there's no helper to create a DRM-managed initialisation of a connector. Let's create an helper to initialise a connector that would be passed as an argument, and handle the cleanup through a DRM-managed action. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-10-maxime@cerno.tech
2022-07-13drm/connector: Check for destroy implementationMaxime Ripard1-0/+6
Connectors need to be cleaned up with a call to drm_connector_cleanup() in their drm_connector_funcs.destroy implementation. Let's check for this and complain if there's no such function. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-9-maxime@cerno.tech
2022-07-13drm/connector: Consolidate Connector InitializationMaxime Ripard1-31/+34
We're going to add a DRM-managed connector initialization function. Since we'll need both the with and without the DDC pointer, having a single function that takes an optional pointer is easier to maintain. Let's create a static function that will back both existing variants, and will be reused by the DRM-managed variant. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-8-maxime@cerno.tech
2022-07-13drm/connector: Clarify when drm_connector_unregister is neededMaxime Ripard1-3/+5
The current documentation for drm_connector_unregister() mentions that it's needed for connectors that have been registered through drm_dev_register(). However, this was a typo and was meant to be drm_connector_register(), which only applies to connectors registered after drm_dev_register() has been called. In addition, it was also mentioning that connectors are unregistered automatically when drm_dev_unregister() is called. This part is a bit misleading, since it might make it appear that drm_connector_unregister() applies either to all connectors, or none of them. After discussing it with Daniel, it appears that we always need to call drm_connector_unregister() on connectors that have been registered with drm_connector_register(), but only those. drm_connector_init() already mentions that it only needs drm_connector_cleanup(), so let's clarify the drm_connector_register() and drm_connector_unregister() documentation to point at each other, and remove the misleading part about drm_dev_unregister(). Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-7-maxime@cerno.tech
2022-07-13drm/connector: Mention the cleanup after drm_connector_initMaxime Ripard1-0/+8
Unlike encoders and CRTCs, the drm_connector_init() and drm_connector_init_with_ddc() don't mention how the cleanup is supposed to be done. Let's add it. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-6-maxime@cerno.tech
2022-07-13drm/connector: Reorder headersMaxime Ripard1-3/+3
Unlike most of the other files in DRM, and Linux in general, the headers in drm_connector.c aren't sorted alphabetically. Let's fix that. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-5-maxime@cerno.tech
2022-07-13drm/encoder: Introduce drmm_encoder_initMaxime Ripard1-11/+64
The DRM-managed function to register an encoder is drmm_encoder_alloc() and its variants, which will allocate the underlying structure and initialisation the encoder. However, we might want to separate the structure creation and the encoder initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise an encoder that would be passed as an argument. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-4-maxime@cerno.tech
2022-07-13drm/crtc: Introduce drmm_crtc_init_with_planesMaxime Ripard1-12/+82
The DRM-managed function to register a CRTC is drmm_crtc_alloc_with_planes(), which will allocate the underlying structure and initialisation the CRTC. However, we might want to separate the structure creation and the CRTC initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise a CRTC that would be passed as an argument. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-3-maxime@cerno.tech
2022-07-13drm/mipi-dsi: Detach devices when removing the hostMaxime Ripard1-0/+1
Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached. Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-2-maxime@cerno.tech
2022-07-13Merge drm/drm-next into drm-misc-nextMaxime Ripard1031-12202/+369726
I need to have some vc4 patches merged in -rc4, but drm-misc-next is only at -rc2 for now. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-07-13Merge tag 'topic/nouveau-misc-2022-07-13-1' of ↵Dave Airlie34-556/+112
git://anongit.freedesktop.org/drm/drm into drm-next drm/nouveau next misc This is a set of misc nouveau patches skeggsb left queued up, just flushing some of them out. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAPM=9txSS9Pdagpi=3JJeFOGy6ALWC31WZdQxLBkfGeL3O+T1A@mail.gmail.com