https://github.com/raspberrypi/linux

sort by:
Revision Author Date Message Commit Date
bffce27 configs: Add FSIA6B driver module See: https://github.com/raspberrypi/linux/issues/5208 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:18 UTC
89384c4 ARM: dts: Add nvmem node for BCM2711 bootloader public key Make a copy of the bootloader secure-boot public key available to the OS via an nvmem node. The placement information is populated by the Raspberry Pi firmware if a public key is present in the BCM2711 bootloader EEPROM. Signed-off-by: Tim Gover <tim.gover@raspberrypi.com> 25 October 2022, 11:20:18 UTC
9e5fee2 configs: Add RTC_DRV_RV3032=m See: https://github.com/raspberrypi/linux/issues/5205 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:18 UTC
72b663d overlays: i2c-rtc: Add RV3032 support See: https://github.com/raspberrypi/linux/issues/5205 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:18 UTC
ee209af media: i2c: imx290: Correct min HBLANK. In the 720p mode the CSI link is run at a lower frequency, and the minimum HBLANK value has to be increased to avoid generating more data from the sensor than the link can carry. Set the minimum based on the mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 25 October 2022, 11:20:18 UTC
437011b nvmem: Use NVMEM_DEVID_AUTO It is reasonable to declare multiple nvmem blocks. Unless a unique 'id' is passed in for each block there may be name clashes. Avoid this by using the magic token NVMEM_DEVID_AUTO. Fixes: 5a3fa75a4d9cb ("nvmem: Add driver to expose reserved memory as nvmem") Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:18 UTC
d49a0de media: i2c: imx477: Do not unconditionally adjust hblank and vblank limits On a mode change, only call imx477_set_framing_limits() to adjust the hblank and vblank limits if the new mode is different from the existing mode. This preserves any manual control values the user might have set. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 25 October 2022, 11:20:18 UTC
e8b2330 media: i2c: imx477: Reset hblank on mode switch Reset the hblank control to the minimum value on every mode switch. This is to account for userland instances that do not yet control hblank, otherwise it gets set to a non-optimal value. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 25 October 2022, 11:20:17 UTC
3d72df0 vc04_services: bcm2835-codec: Allow encoder_cmd on ISP and deinterlace ISP and deinterlace also need a mechanism for passing effectively an EOS through the pipeline to signal when all buffers have been processed. VIDIOC_ENCODER_CMD does exactly this for encoders, so reuse the same function for ISP and deinterlace. (VIDIOC_DECODER_CMD is slightly different in that it also passes details of when and how to stop, so is not as relevant). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 25 October 2022, 11:20:17 UTC
869e48a vc04_services: bcm2835-codec: Remove redundant role check vidioc_try_encoder_cmd checks the role, but the ioctl is disabled for any roles in which it is invalid. Remove the redundant check. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 25 October 2022, 11:20:17 UTC
34376bf media: i2c: imx477: Allow dynamic horizontal blanking control Currently, the V4L2_CID_HBLANK control is marked as read-only. Remove this restriction and allow userland to modify the control if needed. Set the maximum limit of the line length to 0xfff0. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 25 October 2022, 11:20:17 UTC
26fe8dc staging: bcm2835-audio: Fix unused enable_headphones module parameter Since commit "staging: bcm2835-audio: Add disable-headphones flag" the enabling/disabling of the headphones output is solely determined by the presence of the DT property 'brcm,disable-headphones' and the enable_headphones module parameter is unused. Fix that by making it a global switch. Fixes: ee90e47d8824 ("staging: bcm2835-audio: Add disable-headphones flag") Signed-off-by: Juerg Haefliger <juergh@proton.me> 25 October 2022, 11:20:17 UTC
fb7fe05 staging: bcm2835-audio: Fix unused enable_hdmi module parameter The commit "Add HDMI1 facility to the driver." made the enable_hdmi module parameter unused. Fix that by making it a global switch for all available HDMI audio outputs. Fixes: 755f3366084b ("Add HDMI1 facility to the driver.") Signed-off-by: Juerg Haefliger <juergh@proton.me> 25 October 2022, 11:20:17 UTC
8ba5d6d staging: bcm2835-audio: Log errors in case of firmware query failures The driver queries the firmware for the number of detected HDMI displays and their IDs. Log error messages if queries fail. Signed-off-by: Juerg Haefliger <juergh@proton.me> 25 October 2022, 11:20:17 UTC
4c825db staging: bcm2835-audio: Fix firmware node refcounting Decrement firmware node refcounts on all exit paths in set_hdmi_enables(). Signed-off-by: Juerg Haefliger <juergh@proton.me> 25 October 2022, 11:20:17 UTC
71874d0 staging: bcm2835-audio: Find compatible firmware node Commit "ARM: dts: Adopt the upstream snd_bcm2835 handling" removed the audio section from the DT and the driver can no longer access the referenced firmware node 'brcm,firmware'. Fix that by searching for a compatible firmware node instead, similar to drivers/gpu/drm/vc4. Fixes: b9e62329e096 ("ARM: dts: Adopt the upstream snd_bcm2835 handling") Signed-off-by: Juerg Haefliger <juergh@proton.me> 25 October 2022, 11:20:17 UTC
7efb1f7 overlays: Add rpi-sense-v2 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:17 UTC
e5b7c75 usb: xhci: account for num_trbs_free when invalidating TDs If a ring has a number of TDs enqueued past the dequeue pointer, and the URBs corresponding to these TDs are dequeued, then num_trbs_free isn't updated to show that these TDs have been converted to no-ops and effectively "freed". This means that num_trbs_free creeps downwards until the count is exhausted, which then triggers xhci_ring_expansion() and effectively leaks memory by infinitely growing the transfer ring. This is commonly encounted through the use of a usb-serial port where the port is repeatedly opened, read, then closed. Move the num_trbs_free crediting out of the Set TR Dequeue Pointer handling and into xhci_invalidate_cancelled_tds(). There is a potential for overestimating the actual space on the ring if the ring is nearly full and TDs are arbitrarily enqueued by a device driver while it is dequeueing them, but dequeues are usually batched during device close/shutdown or endpoint error recovery. See https://github.com/raspberrypi/linux/issues/5088 Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> 25 October 2022, 11:20:16 UTC
87bf78b ARM: dts: Don't enable the 8250 UART on CM4S CM4S (like CM3, but unlike some CM4) has no Bluetooth, so don't enable the 8250 support in the kernel. See: https://github.com/raspberrypi/linux/issues/5182 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:16 UTC
739a984 ARM: dts: Fix missing rpi CM4 serial console Without commandline argument '8250.nr_uarts=1' there is no 8250 UART and hence no serial console on the CM4. Add it back. Fixes: b9e62329e096 ("ARM: dts: Adopt the upstream snd_bcm2835 handling") Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> 25 October 2022, 11:20:16 UTC
6db16b2 ARM: dts: Add dtparams to disable PCIe, HDMI, and SD card/eMMC Under certain situations, it is desired to disable some unused devices. This patch introduces three parameters allowing disabling PCIe, HDMI, and SD card (or eMMC on CM4). Signed-off-by: Victor Ding <victording@live.com> 25 October 2022, 11:20:16 UTC
ae0efe2 Revert "Add PHY_ID_BCM54213PE identifier." This reverts commit b8e68d153d429de337d173e6bfc295f1d8ba557d. 25 October 2022, 11:20:16 UTC
1b4e307 media: i2c: imx219: make HBLANK r/w to allow longer exposures The HBLANK control was read-only, and always configured such that the sensor HTS register was 3448. This limited the maximum exposure time that could be achieved to around 1.26 secs. Make HBLANK read/write so that the line time can be extended, and thereby allow longer exposures (and slower frame rates). Retain the overall HTS setting when changing modes rather than resetting it to a default. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 25 October 2022, 11:20:16 UTC
435aef0 drm/vc4: hdmi: Reset link on hotplug During a hotplug cycle (such as a TV going out of suspend, or when the cable is disconnected and reconnected), the expectation is that the same state used before the disconnection is reused until the next commit. However, the HDMI scrambling requires that some flags are set in the monitor, and those flags are very likely to be reset when the cable has been disconnected. This will thus result in a blank display, even if the display pipeline configuration hasn't been modified or is in the exact same state. The solution we've had so far is to enable the scrambling-related bits again on reconnection, but the HDMI 2.0 specification (Section 6.1.3.1 - Scrambling Control) requires that the scrambling enable bit is set before sending any scrambled video signal. Using that solution thus breaks that expectation. The solution used by i915 is to do a full modeset on the connector so that we disable the video signal, enable the scrambling bit, and enable the video signal again. As such, we took that code and plugged it into vc4. It probably could have been turned into an helper, but it proved to be difficult for several reasons: * i915 has fairly different structures than simpler KMS drivers such as vc4, so doing some code that works with both proved to be difficult; * Other simpler drivers could reuse some of it (tegra, dw-hdmi), but it would still require to move some parameters currently stored in private structure that are needed to compute whether the scrambling is needed or not, and then inform the driver that it needs to be enabled. Some of those parameters are already in core structures (drm_display_mode, drm_display_info, bpc), but the output format isnt't. Adding it is fairly challenging since unlike the TMDS char rate or mode, there's no consensus on what format to pick in drivers, so it's not possible to write some generic code that can depend on it. For these reasons, we chose to duplicate the code for now, until someone else really needs it as well, in which case we will be able to convert it into a generic helper. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:16 UTC
2727228 drm/vc4: hdmi: Move vc4_hdmi_supports_scrambling() around We'll need it earlier in the driver, so let's move it next to the other scrambling-related helpers. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:16 UTC
83ef9fc drm/vc4: hdmi: Switch to detect_ctx We'll need the locking context in future patch, so let's convert .detect to .detect_ctx. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:16 UTC
53dde12 drm/vc4: hdmi: Simplify the hotplug handling Our detect callback has a bunch of operations to perform depending on the current and last status of the connector, such a setting the CEC physical address or enabling the scrambling again. This is currently dealt with a bunch of if / else statetements that make it fairly difficult to read and extend. Let's move all that logic to a function of its own. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
e3aaa9a drm/vc4: hdmi: Remove mutex in detect We recently introduced a new mutex to protect concurrent execution of ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi fields. However, using it in the detect hook was creating a reentrency issue with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect might call the CEC adap_enable hook with the lock held, eventually resulting in a deadlock. Since we didn't really need to protect anything at the moment in the CEC code, the decision was made to ignore the mutex in those CEC hooks, working around the issue. However, we can have the same thing happening if we end up triggering a mode set from the detect callback, for example using drm_atomic_helper_connector_hdmi_reset_link(). Since we don't really need to protect anything in detect either, let's just drop the lock in detect, and add it again in CEC. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
f119320 drm/vc4: hdmi: Remove unused argument in vc4_hdmi_supports_scrambling Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it never uses it. Let's remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
f783c54 drm/vc4: hdmi: Constify drm_display_mode We don't modify the drm_display_mode pointer we have in the driver in most places, so let's make them const. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
b039152 usb: xhci: expand mitigations for VLI_SS_BULK_OUT_BUG quirk The VL805 can cause data corruption if a SS Bulk OUT endpoint enters a flow-control condition and there are TRBs in the transfer ring that are not an integral size of wMaxPacket and the endpoint is behind one or more hubs. This is frequently the case encountered when FAT32 filesystems are present on mass-storage devices with cluster sizes of 1 sector, and the filesystem is being written to with an aggregate of small files. The initial implementation of this quirk separated TRBs that didn't adhere to this limitation into two - the first a multiple of wMaxPacket and the second the 512-byte remainder - in an attempt to force TD fragments to align with packet boundaries. This reduced the incidence rate of data corruption but did not resolve it. The fix as recommended by VIA is to disable bursts if this sequence of TRBs can occur. Limit turning off bursts to just USB mass-storage devices by searching the device's configuration for an interface with a class type of USB_CLASS_MASS_STORAGE. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> 25 October 2022, 11:20:15 UTC
00353b2 configs: Add NET_XFRM=m Enable the net_xfrm module to support using nftables rules with ipsec matches, See: https://github.com/raspberrypi/linux/issues/5171 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 25 October 2022, 11:20:15 UTC
4ea08af drm/vc4: v3d: Switch to devm_pm_runtime_enable 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> 25 October 2022, 11:20:15 UTC
5a8f519 drm/vc4: v3d: Rework the runtime_pm setup At bind time, vc4_v3d_bind() will read a register to retrieve the v3d version and make sure it's a version we're compatible with. However, the v3d has an optional clock that is enabled only after the register read-out and a power domain that wasn't enabled at all in the bind implementation. This was working fine at boot because both were enabled, but resulted in the version check failing if we were unbinding and rebinding the driver because the unbinding would have turned them off. The fix isn't as easy as calling pm_runtime_resume_and_get() prior to the register access to power up the power domain though. Indeed, the runtime_resume implementation will enable the clock mentioned above, call vc4_v3d_init_hw() and then vc4_irq_enable(). Prior to the previous patch, vc4_irq_enable() needed to occur after our call to platform_get_irq() and vc4_irq_install(), since vc4_irq_enable() used to call enable_irq() and vc4_irq_install() will call request_irq(). vc4_irq_install() will also do some register access, so needs the power domain to be on. So we ended up in a situation where vc4_v3d_runtime_resume() needed vc4_irq_install() to have been called before, and vc4_irq_install() needed vc4_v3d_runtime_resume(). The previous patch removed the enable_irq() call in vc4_irq_enable() and thus removed the dependency of vc4_v3d_runtime_resume() on vc4_irq_install(). Thus, we can now rework our bind implementation to call pm_runtime_resume_and_get() before our register access to make sure the power domain is on. vc4_v3d_runtime_resume() also takes care of turning the clock on and calling vc4_v3d_init_hw() so we can remove them from bind. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
fde4e60 drm/vc4: v3d: Stop disabling interrupts The vc4_irq_disable(), among other things, will call disable_irq() to complete any in-flight interrupts. This requires its counterpart, vc4_irq_enable(), to call enable_irq() which causes issues addressed in a later patch. However, vc4_irq_disable() is called by two callees: vc4_irq_uninstall() and vc4_v3d_runtime_suspend(). vc4_irq_uninstall() also calls free_irq() which already disables the interrupt line. We thus don't require an explicit disable_irq() for that call site. vc4_v3d_runtime_suspend() doesn't have any other code. However, the rest of vc4_irq_disable() masks the interrupts coming from the v3d, so explictly disabling the interrupt line is also redundant. The only thing we really care about is thus to make sure we don't have any handler in-flight, as suggested by the comment. We can thus replace disable_irq() by synchronize_irq(). Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
8e06264 drm/vc4: perfmon: Add missing mutex_destroy vc4_perfmon_open_file() will instantiate a mutex for that file instance, but we never call mutex_destroy () in vc4_perfmon_close_file(). Let's add that missing call. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:15 UTC
c720395 drm/vc4: Switch to drmm_mutex_init mutex_init is supposed to be balanced by a call to mutex_destroy that we were never doing in the vc4 driver. Since a DRM-managed mutex_init variant has been introduced, let's just switch to it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
3056ec4 drm/vc4: hvs: Skip DebugFS Registration for FKMS FKMS doesn't have an HVS and it's expected. Return from the debugfs init function immediately if we're running with fkms. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
467cf5a drm/vc4: debugfs: Simplify debugfs registration The vc4 has a custom API to allow components to register a debugfs file before the DRM driver has been registered and the debugfs_init hook has been called. However, the .late_register hook allows to have the debugfs file creation deferred after that time already. Let's remove our custom code to only register later our debugfs entries as part of either debugfs_init or after it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
894d7c8 drm/vc4: debugfs: Return an error on failure vc4_debugfs_add_file() can fail, so let's propagate its error code instead of silencing it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
7c773c5 drm/vc4: debugfs: Protect device resources 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> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
0a3db22 drm/vc4: vec: Switch to devm_pm_runtime_enable 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> 25 October 2022, 11:20:14 UTC
5e08378 drm/vc4: vec: Protect device resources after removal 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 VEC driver. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:14 UTC
fceea00 drm/vc4: vec: Switch to DRM-managed connector initialization 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> 25 October 2022, 11:20:14 UTC
579e032 drm/vc4: vec: Switch to DRM-managed encoder initialization 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> 25 October 2022, 11:20:14 UTC
751155b drm/vc4: vec: Remove call to drm_connector_unregister() 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> 25 October 2022, 11:20:14 UTC
30aea1d drm/vc4: vec: Switch to drmm_kzalloc 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> 25 October 2022, 11:20:13 UTC
bf1ce42 drm/vc4: vec: Embed DRM structures into the private structure The VC4 VEC driver private structure contains only a pointer to the encoder and connector 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) and drm_connector into struct vc4_vec to fix both issues. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:13 UTC
4d4198f drm/vc4: vec: Remove vc4_dev vec pointer There's no user for that pointer so let's just get rid of it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:13 UTC
b06c0d8 drm/vc4: txp: Protect device resources 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> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:13 UTC
ad431a3 drm/vc4: txp: Remove call to drm_connector_unregister() 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> 25 October 2022, 11:20:13 UTC
83491c8 drm/vc4: txp: Switch to drmm_kzalloc 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> 25 October 2022, 11:20:13 UTC
bc8df04 drm/vc4: txp: Remove duplicate regset There's already a regset in the vc4_crtc structure so there's no need to duplicate it in vc4_txp. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:13 UTC
b63df70 drm/vc4: txp: Remove vc4_dev txp pointer There's no user for that pointer so let's just get rid of it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:13 UTC
0c94852 drm/vc4: hdmi: Switch to devm_pm_runtime_enable 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> 25 October 2022, 11:20:13 UTC
d1bafd9 drm/vc4: hdmi: Protect device resources after removal 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> 25 October 2022, 11:20:13 UTC
7a2a89d drm/vc4: hdmi: Move audio structure offset checks 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> 25 October 2022, 11:20:12 UTC
5a0f587 drm/vc4: hdmi: Use devm to register hotplug interrupts 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> 25 October 2022, 11:20:12 UTC
a00bc25 drm/vc4: hdmi: Switch to DRM-managed kfree to build regsets 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> 25 October 2022, 11:20:12 UTC
00e1e95 drm/vc4: hdmi: Use a device-managed action for DDC 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> 25 October 2022, 11:20:12 UTC
f1b87df drm/vc4: hdmi: Switch to device-managed CEC initialization 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> 25 October 2022, 11:20:12 UTC
541662e drm/vc4: hdmi: Switch to device-managed ALSA initialization 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> 25 October 2022, 11:20:12 UTC
a143693 drm/vc4: hdmi: Switch to DRM-managed connector initialization 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> 25 October 2022, 11:20:12 UTC
924bbd8 drm/vc4: hdmi: Switch to DRM-managed encoder initialization 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> 25 October 2022, 11:20:12 UTC
2933cbf drm/vc4: hdmi: Remove call to drm_connector_unregister() 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> 25 October 2022, 11:20:12 UTC
e386ab0 drm/vc4: hdmi: Switch to drmm_kzalloc 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> 25 October 2022, 11:20:12 UTC
0a7b295 drm/vc4: dsi: Switch to devm_pm_runtime_enable 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> 25 October 2022, 11:20:11 UTC
49928f2 drm/vc4: dsi: Fix the driver structure lifetime 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> 25 October 2022, 11:20:11 UTC
811ff0b drm/vc4: dsi: Switch to drmm_of_get_bridge 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> 25 October 2022, 11:20:11 UTC
cfd69ad drm/vc4: dsi: Switch to DRM-managed encoder initialization 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> 25 October 2022, 11:20:11 UTC
4ebe302 drm/vc4: dsi: Embed DRM structures into the private structure 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> 25 October 2022, 11:20:11 UTC
13e1f7b drm/vc4: dpi: Protect device resources 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> 25 October 2022, 11:20:11 UTC
c5048b5 drm/vc4: dpi: Switch to drmm_of_get_bridge 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> 25 October 2022, 11:20:11 UTC
4013c12 drm/vc4: dpi: Switch to DRM-managed encoder initialization 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> 25 October 2022, 11:20:11 UTC
dd76ddb drm/vc4: dpi: Add action to disable the clock 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> 25 October 2022, 11:20:11 UTC
37d10ad drm/vc4: dpi: Remove unnecessary drm_of_panel_bridge_remove call 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> 25 October 2022, 11:20:10 UTC
3e4eb84 drm/vc4: dpi: Return an error if we can't enable our clock 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> 25 October 2022, 11:20:10 UTC
0f75bdd drm/vc4: dpi: Switch to drmm_kzalloc 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> 25 October 2022, 11:20:10 UTC
7549a55 drm/vc4: dpi: Embed DRM structures into the private structure 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> 25 October 2022, 11:20:10 UTC
42e0ba5 drm/vc4: dpi: Remove vc4_dev dpi pointer 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> 25 October 2022, 11:20:10 UTC
da4e3dc drm/vc4: crtc: Switch to DRM-managed CRTC initialization 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> 25 October 2022, 11:20:10 UTC
3541f71 drm/vc4: crtc: Switch to drmm_kzalloc 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> 25 October 2022, 11:20:10 UTC
e223492 drm/vc4: crtc: Move debugfs_name to crtc_data 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> 25 October 2022, 11:20:10 UTC
e838eb5 drm/vc4: plane: Switch to drmm_universal_plane_alloc() 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> 25 October 2022, 11:20:10 UTC
98c4f0f drm/vc4: crtc: Remove manual plane removal on error 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> 25 October 2022, 11:20:10 UTC
a226be5 drm/vc4: plane: Take possible_crtcs as an argument 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> 25 October 2022, 11:20:09 UTC
a35de9d drm/vc4: hvs: Remove planes currently allocated before taking down 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> 25 October 2022, 11:20:09 UTC
5a8473e drm/vc4: hvs: Protect device resources after removal 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> 25 October 2022, 11:20:09 UTC
44f236a drm/vc4: crtc: Create vblank reporting function 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> 25 October 2022, 11:20:09 UTC
42cacfa drm/vc4: drv: Use drm_dev_unplug 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> 25 October 2022, 11:20:09 UTC
95f5732 drm/vc4: drv: Call component_unbind_all() 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> 25 October 2022, 11:20:09 UTC
758fed3 drm/vc4: Add module dependency on hdmi-codec The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver will register a device matching the HDMI codec driver, and then register an ASoC card using that codec. However, if vc4 is compiled as a module, chances are that the hdmi-codec driver will be too. In such a case, the module loader will have a very narrow window to load the module between the device registration and the card registration. If it fails to load the module in time, the card registration will fail with EPROBE_DEFER, and we'll abort the audio initialisation, unregistering the HDMI codec device in the process. The next time the bind callback will be run, it's likely that we end up missing that window again, effectively preventing vc4 to probe entirely. In order to prevent this, we can create a soft dependency of the vc4 driver on the HDMI codec one so that we're sure the HDMI codec will be loaded before the VC4 module is, and thus we'll never end up in the previous situation. Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Signed-off-by: Maxime Ripard <maxime@cerno.tech> 25 October 2022, 11:20:09 UTC
5ba0b56 drm/bridge: panel: Introduce drmm_of_get_bridge 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> 25 October 2022, 11:20:09 UTC
7b2227d drm/bridge: panel: Introduce drmm_panel_bridge_add 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> 25 October 2022, 11:20:09 UTC
962fd1d drm/connector: Introduce drmm_connector_init 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> 25 October 2022, 11:20:09 UTC
d465871 drm/connector: Check for destroy implementation 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> 25 October 2022, 11:20:08 UTC
2ecc3bd drm/connector: Consolidate Connector Initialization 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> 25 October 2022, 11:20:08 UTC
6763266 drm/connector: Clarify when drm_connector_unregister is needed 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> 25 October 2022, 11:20:08 UTC
d1a38bb drm/connector: Mention the cleanup after drm_connector_init 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> 25 October 2022, 11:20:08 UTC
dceca82 drm/connector: Reorder headers 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> 25 October 2022, 11:20:08 UTC
back to top