TESTING: V6.12 dwc hcd fixes #6496
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Starting with BCM2712, we'll have a two TXP. Let's follow the HDMI example and add two encoder types for TXP: TXP0 and TXP1. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 has an evolution of what used to be called TXP in the earlier SoCs, but is now called MOP. There's a few differences still, so we can add a new compatible to deal with them easily. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 features a simpler TXP called MOPLET. Let's add support for it. Signed-off-by: Maxime Ripard <[email protected]>
Some code path in vc4 are conditional to a generation and cannot be executed on others. Let's put a WARN_ON if that ever happens. Signed-off-by: Maxime Ripard <[email protected]>
Testing whether the VideoCore generation we want to mock is vc5 or vc4 worked so far, but will be difficult to extend to support BCM2712 (VC6). Convert to a switch. Signed-off-by: Maxime Ripard <[email protected]>
The DRM device pointer and the DRM encoder pointer are redundant, since the latter is attached to the former and we can just follow the drm_encoder->dev pointer. Let's remove the drm_device pointer argument. Signed-off-by: Maxime Ripard <[email protected]>
Some tests will need to retrieve the output that was just allocated by vc4_mock_atomic_add_output(). Instead of making them look them up in the DRM device, we can simply make vc4_mock_atomic_add_output() return an error pointer that holds the allocated output instead of the error code. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 has a simpler pipeline that can only output to a writeback connector and two HDMI controllers. Let's allow our kunit tests to create a mock of that pipeline. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 has a simpler pipeline than the BCM2711, and thus the muxing requirements are different. Create some tests to make sure we get proper muxing decisions. Signed-off-by: Maxime Ripard <[email protected]>
The current mock planes were just using the regular drm_plane_state, while the driver expect struct vc4_plane_state that subclasses drm_plane_state. Hook the proper implementations of reset, duplicate_state, destroy and atomic_check to create vc4_plane_state. Signed-off-by: Maxime Ripard <[email protected]>
Some tests will need to find a plane to run a test on for a given CRTC. Let's create a small helper to do that. Signed-off-by: Maxime Ripard <[email protected]>
We'll start to add some tests for the plane state logic, so let's create a helper to add a plane to an existing atomic state. Signed-off-by: Maxime Ripard <[email protected]>
We'll start testing our planes code in situations where we will use more than XRGB8888, so let's add a few common pixel formats. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 comes with a different LBM size computation than the previous generations, so let's add the few examples provided as kunit tests to make sure we always satisfy those requirements. Signed-off-by: Maxime Ripard <[email protected]>
On 2712, the firmware always runs these clock at a speed sufficient for dual 4kp60. The requests here prevent the gpu from going into its lowest voltage mode, so just skip the clock requests. With this applied the idle voltage on my pi 5 reduces from 0.7424V to 0.72V. Signed-off-by: Dom Cobley <[email protected]>
It was accidentally placed in the audio decoder section. Signed-off-by: Naushir Patuck <[email protected]>
Allow DT aliases of eg DSI2 to force make DRM allocate the display with the requested name. Signed-off-by: Dave Stevenson <[email protected]>
Since "drm/vc4: hvs: Support BCM2712 HVS" booting Pi4 with dual 4kp30 displays connected fails with: vc4-drm gpu: [drm] *ERROR* [CRTC:107:pixelvalve-4] flip_done timed out It has been tracked down to the referenced commit adding a path to clear the SCALER_DISPBKGND_FILL when not required. Dual 4kp30 works with a core clock of 297MHz when background fill is enabled, but requires a higher value with it disabled. 320MHz still fails, while 330MHz seems okay. Lets always enable background fill for Pi0-4. Fixes: e84da23 ("drm/vc4: hvs: Support BCM2712 HVS") Signed-off-by: Dom Cobley <[email protected]>
Vision Components have made an OV9281 module which blocks reading back the majority of registers to comply with NDAs, and in doing so doesn't allow auto-increment register reading as used when reading the chip ID. Use two reads and manually combine the results. Signed-off-by: Dave Stevenson <[email protected]>
11cf37e switched to using drm_fb_dma_get_gem_addr instead of drm_fb_dma_get_gem_obj and adding fb->offset[]. However the tiled formats need to compute the offset in a more involved manner than drm_fb_dma_get_gem_addr applies, and we were ending up with the offset for src_[xy] being applied twice. Switch back to using drm_fb_dma_get_gem_obj and fully computing the offsets ourselves. Fixes: 11cf37e ("drm/vc4: Move the buffer offset out of the vc4_plane_state") Signed-off-by: Dave Stevenson <[email protected]>
Add a flag custom_fb_num to denote that the client has requested a specific fbdev node number via node. Signed-off-by: Dave Stevenson <[email protected]>
For situations where there are multiple DRM cards in a system, add a query of DT for "drm_fb" designations for cards to set their preferred /dev/fbN designation. Signed-off-by: Dave Stevenson <[email protected]> drm/fb_helper: Change query for FB designation from drm_fb to drm-fb Fixes: 1216ea5 ("drm/fb-helper: Look up preferred fbdev node number from DT") Signed-off-by: Dave Stevenson <[email protected]>
Apparently aliases are only allowed lower case and hyphens, so swap the use of underscore to hyphen. Fixes: 3aa1f24 ("drm: Look for an alias for the displays to use as the DRM device name") Signed-off-by: Dave Stevenson <[email protected]>
This property can be used to delay deassertion of external fundamental reset, which may be useful for endpoints that require an extended time for internal setup to complete. Signed-off-by: Jonathan Bell <[email protected]>
When factoring out __vc4_hvs_stop_channel, the logic got inverted from if (condition) // stop channel to if (condition) goto out //stop channel out: and also changed the exact register writes used to stop the channel. Correct the logic so that the channel is actually stopped, and revert to the original register writes. Fixes: 6d01a10 ("drm/vc4: crtc: Move HVS init and close to a function") Signed-off-by: Dave Stevenson <[email protected]>
The reset condition for the EMPTY flag in DISPSTATx is 0, so seeing as we've just reset the pipeline there is no guarantee that the flag will denote empty if it hasn't been enabled. Drop the WARN. Signed-off-by: Dave Stevenson <[email protected]>
The code handling freeing stale dlists had 2 issues: - it disabled the interrupt as soon as the first EOF interrupt occurred, even if it didn't clear all stale allocations, thus leading to stale entries - It didn't free stale entries from disabled channels, so eg "kmstest -c 0" could leave a stale alloc on channel 1 floating around. Keep the interrupt enabled whilst there are any outstanding allocs, and discard those on disabled channels. This second channel does require us to call vc4_hvs_stop_channel from vc4_crtc_atomic_disable so that the channel actually gets stopped. Signed-off-by: Dave Stevenson <[email protected]>
Users are reporting running out of DLIST memory. Add a debugfs file to dump out all the allocations. Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
BCM2711 runs pixelvalve at two pixels per clock cycle which results in an unfortunate limitation that odd horizontal timings are not possible. This is apparent on the standard DMT mode of 1366x768@60 which cannot be driven with correct timing. BCM2712 defaults to the same behaviour, but has a mode to support odd timings. While internally it still runs at two pixels per clock, setting the PV_VCONTROL_ODD_TIMING bit makes it appear externally to behave as it is one pixel per clock. Switching to this mode fixes 1366x768@60 mode, and other custom resultions with odd horizontal timings. Signed-off-by: Dom Cobley <[email protected]> drm/vc4: Disable the 2pixel/clock odd timings workaround for interlaced Whilst BCM2712 does fix using odd horizontal timings, it doesn't work with interlaced modes. Drop the workaround for interlaced modes and revert to the same behaviour as BCM2711. raspberrypi#6281 Signed-off-by: Dave Stevenson <[email protected]>
Declare the communications channel to RP1. Signed-off-by: Phil Elwell <[email protected]>
Provide remote access to the PIO hardware in RP1. There is a single instance, with 4 state machines. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
Declare the device that proxies RP1's PIO hardware. Signed-off-by: Phil Elwell <[email protected]>
Use the PIO hardware on RP1 to implement a PWM interface. Signed-off-by: Phil Elwell <[email protected]>
Enable building of the pwm-pio-rp1 driver, which is Pi 5-specific. Signed-off-by: Phil Elwell <[email protected]>
Add an overlay to enable a single-channel PIO-assisted PWM interface on any header pin. Signed-off-by: Phil Elwell <[email protected]>
This is a SPI to powerline chipset with host-side Ethernet interface. Is is usually used in e-mobility environments, e.g. on Electrical Vehicle Supply Equipment (EVSE) side. Signed-off-by: Michael Heimpold <[email protected]>
Sourced from https://github.com/hailo-ai/hailort-drivers/ Signed-off-by: Naushir Patuck <[email protected]>
The documentation isn't very clear explaining how to enable SPI CS active-high and it takes a long time to understand it. Adding a specific overlay as a simple example on how to invert this signal can help understand the solution. Link: https://forums.raspberrypi.com/viewtopic.php?t=378222 Signed-off-by: Iker Pedrosa <[email protected]>
The register to enable/disable background fill was being set from atomic flush, however that will be applied immediately and can be a while before the vblank. If it was required for the current frame but not for the next one, that can result in corruption for part of the current frame. Store the state in vc4_hvs, and update it on vblank. Signed-off-by: Dave Stevenson <[email protected]>
See: raspberrypi#6480 Signed-off-by: foonerd <[email protected]>
If autonomous speed negotiation is unreliable then brcm_pcie_set_gen() can be used to override/limit this behaviour. However, setting the limit after the linkup poll means the link can temporarily enter a bad speed which may result in link failure. Move the speed setup to just prior to releasing perst_n. Fixes: 0693b42 ("PCI: brcmstb: Split post-link up initialization to brcm_pcie_start_link()") Signed-off-by: Jonathan Bell <[email protected]>
If you disable HDR metadata, then the hardware should stop sending the infoframe, and that is implemented by the clear_infoframe hook which wasn't implemented. Add it. Signed-off-by: Dave Stevenson <[email protected]>
Using increased bit depth for no reason increases power consumption, and differs from the behaviour prior to the conversion to use the HDMI helper functions. Initialise the state max_bpc and requested_max_bpc to the minimum value supported. This only affects Raspberry Pi, as the other users of the helpers (rockchip/inno_hdmi and sunx4i) only support a bit depth of 8. Signed-off-by: Dave Stevenson <[email protected]>
If an infoframe was ever enabled, duplicate_state would memcpy the infoframe including the "set" flag. The infoframe functions then never cleared it, so once set it was always set. This was most obvious with the HDR infoframe as it resulted in bad colour rendering. Signed-off-by: Dave Stevenson <[email protected]>
Drop from RGB to YUV422 output if RGB couldn't be supported within the defined max_bpc and TMDS rates, and then try dropping max_bpc. Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
"media: i2c: imx477: Add options for slightly modifying the link freq" created a link frequency menu with 2 items in instead of one. Correct this. Signed-off-by: Dave Stevenson <[email protected]>
As per the subject, there was a copy/paste error that caused pio_sm_unclaim from a driver to result in a call to pio_sm_claim. Fix it. Signed-off-by: Phil Elwell <[email protected]>
Passing bad parameters to an API call without a pio pointer will cause a NULL pointer exception when the persistent error is set. Guard against that. Signed-off-by: Phil Elwell <[email protected]>
This helps to reproduce issue faster ... Signed-off-by: Stefan Wahren <[email protected]>
The Raspberry Pi can suffer on interrupt storms on HCD resume. The dwc2 driver sometimes misses to enable HCD_FLAG_HW_ACCESSIBLE before re-enabling the interrupts. This causes a situation where both handler ignore a incoming port interrupt and force the upper layers to disable the dwc2 interrupt line. This leaves the USB interface in a unusable state: irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.10.0-rc3 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1b01f20 to 0xc1b01f68) 1f20: 0005c0d4 00000001 00000000 00000000 c1b09780 c1d6b32c c1b04e54 c1a5eae8 1f40: c1b04e90 00000000 00000000 00000000 c1d6a8a0 c1b01f70 c11d2da8 c11d4160 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<f539e0f4>] dwc2_handle_common_intr [<75cd278b>] usb_hcd_irq Disabling IRQ raspberrypi#66 So enable the HCD_FLAG_HW_ACCESSIBLE flag in case there is a port connection. Fixes: c74c26f ("usb: dwc2: Fix partial power down exiting by system resume") Link: https://lore.kernel.org/linux-usb/[email protected]/T/ Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Stefan Wahren <[email protected]>
On Rasperry Pis without onboard USB hub the power cycle during power connect init only disable the port but never enabled it again: usb usb1-port1: attempt power cycle The port relevant part in dwc2_hcd_hub_control() is skipped in case port_connect_status = 0 under the assumption the core is or will be soon in device mode. But this assumption is wrong, because after ClearPortFeature USB_PORT_FEAT_POWER the port_connect_status will also be 0 and SetPortFeature (incl. USB_PORT_FEAT_POWER) will be a no-op. Fix the behavior of dwc2_hcd_hub_control() by replacing the port_connect_status check with dwc2_is_device_mode(). Link: raspberrypi#6247 Fixes: 7359d48 ("staging: HCD files for the DWC2 driver") Signed-off-by: Stefan Wahren <[email protected]>
On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ raspberrypi#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty raspberrypi#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ raspberrypi#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <[email protected]>
popcornmix
force-pushed
the
rpi-6.12.y
branch
2 times, most recently
from
1348250 to
2b062ea
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Do not merge - just to create a test build.