- Oct 25, 2022
-
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/5208 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Tim Gover authored
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>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/5205 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/5205 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
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>
-
Phil Elwell authored
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: 5a3fa75a ("nvmem: Add driver to expose reserved memory as nvmem") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Naushir Patuck authored
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>
-
Naushir Patuck authored
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>
-
Dave Stevenson authored
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>
-
Dave Stevenson authored
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>
-
Naushir Patuck authored
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>
-
Juerg Haefliger authored
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: ee90e47d ("staging: bcm2835-audio: Add disable-headphones flag") Signed-off-by: Juerg Haefliger <juergh@proton.me>
-
Juerg Haefliger authored
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: 755f3366 ("Add HDMI1 facility to the driver.") Signed-off-by: Juerg Haefliger <juergh@proton.me>
-
Juerg Haefliger authored
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>
-
Juerg Haefliger authored
Decrement firmware node refcounts on all exit paths in set_hdmi_enables(). Signed-off-by: Juerg Haefliger <juergh@proton.me>
-
Juerg Haefliger authored
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>
-
Phil Elwell authored
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Jonathan Bell authored
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>
-
Phil Elwell authored
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>
-
Juerg Haefliger authored
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>
-
Victor Ding authored
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>
-
Dom Cobley authored
This reverts commit b8e68d15.
-
Dave Stevenson authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Jonathan Bell authored
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>
-
Phil Elwell authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-