Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TESTING: V6.12 dwc hcd fixes #6496

Draft
wants to merge 703 commits into
base: rpi-6.12.y
Choose a base branch
from

Conversation

popcornmix
Copy link
Collaborator

Do not merge - just to create a test build.

mripard and others added 30 commits November 25, 2024 12:33
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]>
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]>
pelwell and others added 26 commits November 25, 2024 12:34
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]>
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]>
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]>
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]>
"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]>
@pelwell pelwell marked this pull request as draft November 26, 2024 20:18
@popcornmix popcornmix force-pushed the rpi-6.12.y branch 2 times, most recently from 1348250 to 2b062ea Compare December 10, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.