Skip to content
  1. Jul 10, 2021
  3. Jul 09, 2021
  5. Jul 08, 2021
  7. Jul 06, 2021
    • Maxime Ripard's avatar
      drm/vc4: hdmi: Only call into DRM framework if registered · 20dcc461
      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: default avatarMaxime Ripard <maxime@cerno.tech>
      20dcc461
    • Maxime Ripard's avatar
      drm/vc4: hdmi: Drop devm interrupt handler for hotplug interrupts · c6fa884e
      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: default avatarMaxime Ripard <maxime@cerno.tech>
      c6fa884e
    • Maxime Ripard's avatar
      drm/vc4: hdmi: Drop devm interrupt handler for CEC interrupts · e6fa19ad
      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: default avatarMaxime Ripard <maxime@cerno.tech>
      e6fa19ad
    • Phil Elwell's avatar
      dwc_otg: Update NetBSD usb.h header licence · 94f7ac6e
      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: default avatarPhil Elwell <phil@raspberrypi.com>
      94f7ac6e
  9. Jul 05, 2021
  11. Jul 03, 2021
  13. Jul 02, 2021
  15. Jul 01, 2021
  17. Jun 30, 2021
  19. Jun 29, 2021
  21. Jun 28, 2021
    • Dom Cobley's avatar
      drm/vc4: hdmi: Use a fixed rate for the HSM clock on BCM2835 · d2d1ac07
      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: default avatarDom Cobley <popcornmix@gmail.com>
Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      d2d1ac07
    • Dom Cobley's avatar
      Merge remote-tracking branch 'stable/linux-5.10.y' into rpi-5.10.y · e791d8ef
      Dom Cobley authored
      e791d8ef
    • Dave Stevenson's avatar
      media: i2c: ov9281: Remove override of subdev name · 8ecb5442
      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: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
      8ecb5442
    • Maxime Ripard's avatar
      drm/vc4: Increase the core clock to a minimum of 500MHz · c53f42cc
      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: default avatarMaxime Ripard <maxime@cerno.tech>
      c53f42cc
  23. Jun 25, 2021
    • Tim Gover's avatar
      drm: vc4: Fix pixel-wrap issue with DVP teardown · 2be20d05
      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: default avatarTim Gover <tim.gover@raspberrypi.com>
      2be20d05
  25. Jun 24, 2021