- Jul 10, 2021
-
-
Dom Cobley authored
This reverts commit c53f42cc.
-
- Jul 09, 2021
-
-
chipdip.lab authored
Signed-off-by: Evgenij Sapunov <evgenij.sapunov@chipdip.ru>
-
- Jul 08, 2021
-
-
Jakub Vaněk authored
The vidioc_enum_input() v4l2 ioctl is capable of returning sensor/input status as well. This is used in current GStreamer HEAD for signal detection [1]. bcm2835-unicam does handle this syscall, but it didn't ask the subdevice driver about the input status. The input then appeared as always present. This commit adds the necessary query. There is a precedent for this - the R-Car VIN V4L2 driver does a similar call [2]. [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/ce0be27caf69aa9d96b73bc2b50737451b6f6936/sys/v4l2/gstv4l2src.c#L553 [2]: https://github.com/raspberrypi/linux/blob/7fb9d006d3ff3baf2e205e0c85c4e4fd0a64fcd0/drivers/media/platform/rcar-vin/rcar-v4l2.c#L548 Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
-
Dom Cobley authored
The temperature sensor is valid below zero and the linux framework is happy with it. See: https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=315382 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
- Jul 06, 2021
-
-
Maxime Ripard authored
Our hotplug handler will currently call the drm_kms_helper_hotplug_event every time a hotplug interrupt is called. However, since the device is registered after all the drivers have finished their bind callback, we have a window between when we install our interrupt handler and when drm_dev_register() is eventually called where our handler can run and call drm_kms_helper_hotplug_event but the device hasn't been registered yet, causing a null pointer dereference. Fix this by making sure we only call drm_kms_helper_hotplug_event if our device has been properly registered. Fixes: f4790083 ("drm/vc4: hdmi: Rely on interrupts to handle hotplug") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The hotplugs interrupt handlers are registered through the devm_request_threaded_irq function. However, while free_irq is indeed called properly when the device is unbound or bind fails, it's called after unbind or bind is done. In our particular case, it means that on failure it creates a window where our interrupt handler can be called, but we're freeing every resource (CEC adapter, DRM objects, etc.) it might need. In order to address this, let's switch to the non-devm variant to control better when the handler will be unregistered and allow us to make it safe. Fixes: f4790083 ("drm/vc4: hdmi: Rely on interrupts to handle hotplug") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The CEC interrupt handlers are registered through the devm_request_threaded_irq function. However, while free_irq is indeed called properly when the device is unbound or bind fails, it's called after unbind or bind is done. In our particular case, it means that on failure it creates a window where our interrupt handler can be called, but we're freeing every resource (CEC adapter, DRM objects, etc.) it might need. In order to address this, let's switch to the non-devm variant to control better when the handler will be unregistered and allow us to make it safe. Fixes: 15b4511a ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Phil Elwell authored
NetBSD have changed their licensing requirements such that the 2-clause licence is preferred. Update usb.h in the downstream dwc_otg code accordingly. See https://www.netbsd.org/about/redistribution.html for more information. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Jul 05, 2021
-
-
Dom Cobley authored
fkms driver still wants firmware display to be active Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Maxime Ripard authored
Commit ecdd08fd ("drm/vc4: hdmi: Make sure the device is powered with CEC") made sure that the device is powered while there is CEC-related accesses but missed one register read in the variable declaration. Move the variable assignment after the pm_runtime_resume_and_get. Fixes: ecdd08fd ("drm/vc4: hdmi: Make sure the device is powered with CEC") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
We've had many silent hangs where the kernel would look like it just stalled due to the access to one of the HDMI registers while the controller was disabled. Add a warning if we're about to do that so that it's at least not silent anymore. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
- Jul 03, 2021
-
-
Maxime Ripard authored
In vc4_hdmi_encoder_pre_crtc_configure, if clk_request_start for the HSM clock fails, we don't call clk_disable_unprepare on the pixel clock even though it's enabled by now. Make sure it's there to avoid leaking that reference. Fixes: cd4cb49d ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
- Jul 02, 2021
-
-
Maxime Ripard authored
Similarly to what we encountered with the detect hook with DRM, nothing actually prevents any of the CEC callback from being run while the HDMI output is disabled. However, this is an issue since any register access to the controller when it's powered down will result in a silent hang. Let's make sure we run the runtime_pm hooks when the CEC adapter is opened and closed by the userspace to avoid that issue. Fixes: 15b4511a ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
In order to ease further additions to the CEC enable and disable, let's split the function into two functions, one to enable and the other to disable. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
In the vc4_hdmi_encoder_pre_crtc_configure() function error path we never actually call pm_runtime_put() even though pm_runtime_resume_and_get() is our very first call. Fixes: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
In the bind hook, we actually need the device to have the HSM clock running during the final part of the display initialisation where we reset the controller and initialise the CEC component. Failing to do so will result in a complete, silent, hang of the CPU. Fixes: 411efa18 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The HPD GPIO retrieval code on failure will jump to the err_unprepare_hsm label that calls pm_runtime_disable. However at that point we haven't called pm_runtime_enable, so we end up with an unbalanced call. The next error than can occur (and therefore the next label) needs both pm_runtime_disable and drm_encoder_cleanup though, so let's rearrange the labels to match what we expect. Fixes: cd4cb49d ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
In order to access the HDMI controller, we need to make sure the HSM clock is enabled. If we were to access it with the clock disabled, the CPU would completely hang, resulting in an hard crash. Since we have different code path that would require it, let's move that clock enable / disable to runtime_pm that will take care of the reference counting for us. Fixes: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525091059.234116-3-maxime@cerno.tech
-
Maxime Ripard authored
Add the firmware phandle to the vc4 node so that we can send it the message that we're done with the firmware display. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has been made, simplefb has been unregistered and the KMS driver is entirely in charge of the display. Thus, we can notify the firmware it can free whatever resource it was using to maintain simplefb functional. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the firmware the kernel is in charge of the display now and the firmware can free whatever resources it was using. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The vc4 driver will need to tell the firmware that it takes over the display for the firmware to free its resources (lower the clock, free some memory, etc.) Let's add an optional phandle to our firmware node. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The raspberrypi,firmware property has been documented as required in the binding but was never actually used in the final version of the binding. Remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
- Jul 01, 2021
-
-
Phil Elwell authored
Lift the set of RTCs out of i2c-rtc and i2c-rtc-gpio to update i2c-rtc-gpio and to reduce duplication. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Jun 30, 2021
-
-
David Plowman authored
The imx378 sensor is almost identical to the imx477 and can be supported as a "compatible" sensor with just a few extra register writes. Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
-
David Plowman authored
This is based off a common overlay which is now also used by the imx477 sensor. Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
-
David Plowman authored
The imx378 sensor is compatible with the imx477 and shares common device tree settings. Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
-
- Jun 29, 2021
-
-
Naushir Patuck authored
The bcm2835 ISP requires the base address of all input/output planes to have 32 byte alignment. Using a Y stride of 32 bytes would not guarantee that the V plane would fulfil this, e.g. a height of 650 lines would mean the V plane buffer is not 32 byte aligned for YUV420 formats. Having a Y stride of 64 bytes would ensure both U and V planes have a 32 byte alignment, as the luma height will always be an even number of lines. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Phil Elwell authored
From the requesting issue: "This option is necessary for having bridge-like networking on KVM VMs with the host root filesystem on NFS (since regular bridge networking doesn't work in that case)," See: https://github.com/raspberrypi/linux/issues/4413 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Maxime Ripard authored
If we have a state already and disconnect/reconnect the display, the SCDC messages won't be sent again since we didn't go through a disable / enable cycle. In order to fix this, let's call the vc4_hdmi_enable_scrambling function in the detect callback if there is a mode and it needs the scrambler to be enabled. Fixes: 74465b84 ("drm/vc4: hdmi: Enable the scrambler") Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
- Jun 28, 2021
-
-
Dom Cobley authored
Before the introduction of the BCM2711 support, the HSM clock rate was fixed, and was the CEC and audio clock source on the SoCs previously supported. The HSM clock is also the source of the internal state machine of the controller and needs to run faster than the pixel clock. All these requirements were met by running at 101% of the maximum pixel rate, meeting the fixed clock requirement for audio and CEC, while remaining faster than any pixel clock we might need. However, the BCM2711 brought support for 4k and therefore increased significantly the rate needed for the HSM, and new, independant, clocks to feed the audio and CEC clocks. Since the HSM clock can also run much higher, we also need to lower its rate if possible to reduce its power consumption. The CEC support code changes its clock divider when the HSM clock rate is changed, but the audio support never had a similar feature and will glitch out if audio is played back during a mode set. Since the HSM rate was meant to be fixed on the SoCs prior to the BCM2711 anyway, let's introduce back a fixed HSM rate and fix audio. Fixes: cd4cb49d ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Dom Cobley authored
-
Dave Stevenson authored
From the original Rockchip driver, the subdev was renamed from the default to being "mov9281 <dev_name>" whereas the default would have been "ov9281 <dev_name>". Remove the override to drop back to the default rather than a vendor custom string. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Maxime Ripard authored
The core clock needs to be raised temporarily during a modeset to 500MHz. However, the HVS core clock requirement might be higher than 500MHz. This rate will be enforced at the end of the mode setting, meaning that might might end up with a core clock rate lower than planned on the first mode set. Use the maximum value of 500MHz and the HVS core clock rate for our temporary boost to fix this issue. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
- Jun 25, 2021
-
-
Tim Gover authored
Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back to pixelvalve causing it to not clear the FIFO. Adjust the ordering and timing of operations to ensure the clear signal makes it through to pixelvalve. Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
-
- Jun 24, 2021
-
-
Joerg Quinten authored
Signed-off-by: Joerg Quinten <aBUGSworstnightmare@gmail.com>
-
Joerg Quinten authored
A matching media bus format was added and an overlay for using it, both with FB and VC4 was added as well. Signed-off-by: Joerg Quinten <aBUGSworstnightmare@gmail.com>
-
John Cox authored
It is legitimate, though unusual, for an aux ent associated with a slot to be selected in phase 0 before a previous selection has been used and released in phase 2. Fix such that if the slot is found to be in use that the aux ent associated with it is reused rather than an new aux ent being created. This fixes a problem where when the first aux ent was released the second was lost track of. This bug spotted in Nick's testing. It may explain some other occasional, unreliable decode error reports where dmesg included "Missing DPB AUX ent" logging. Signed-off-by: John Cox <jc@kynesim.co.uk>
-
Dom Cobley authored
fkms doesn't use vc4->hvs so protect against that Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-