- Sep 29, 2023
-
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 features a simpler TXP called MOPLET. Let's add support for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
We'll have multiple TXP instances in the BCM2712, so we can't use a single encoder type anymore. Let's tie the encoder type to the compatible. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 MOP and MOPLET can handle addresses larger than 32bits through an extra register. We can easily support it and make it conditional based on the compatible through a boolean in our variant structure. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The new writeback controllers that can be found on the BCM2712 require to have their horizontal and vertical size reduced by one. Let's tie that behaviour to the compatible so we can support both the new and old controllers. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The MOPLET doesn't have the BYTE_ENABLE field to set, but the TXP and MOP do, so let's add a boolean to control whether or not we need to set it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The TXP data structure has a name too generic for the multiple variants we'll have to support. Let's rename it to mention the SoC it applies to. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 will have several TXP with small differences. Let's add a structure tied to the compatible to deal with those differences. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The HDMI controllers found in the BCM2712 are largely the ones found in the BCM2711 with a different PHY. There's some difference with how timings are split between registers, and HDMI1 is now able to run at 4k/60Hz. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The PixelValves found on the BCM2712 are similar to the ones found in the previous generation. Compared to BCM2711, the pixelvalves only drive one HDMI controller each and HDMI1 PixelValve has a FIFO long enough to support 4k at 60Hz. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The HVS found in the BCM2712, while having a similar role, is very different from the one found in the previous SoCs. Indeed, the register layout is fairly different, and the DLIST format is new as well. Let's introduce the needed functions to support the new HVS. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 has an improved display pipeline, most notably with a different HVS and only HDMI and writeback outputs. Let's introduce it as a new VideoCore generation and compatible. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 SoC comes with a new variation of the videocore display pipeline. Let's create a new compatible for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 has a MOPLET controller which is basically a TXP without the transpose feature. Express that by adding a new compatible for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 has a MOP controller which is basically a new revision of the TXP. Express that by adding a new compatible for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 has 3 different pixelvalves that are similar to the ones found in the previous generations but with slightly different capabilities. Express that using a new set of compatibles. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 has a completely different HVS than the previous generations, so let's add a new compatible for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 HDMI controller uses a slightly different HDMI controller than the BCM2711, and a completely different PHY. Let's introduce a new compatible for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Tim Gover authored
Always enable SCALER_CONTROL before attempting other HVS operations. It's safe to write to some parts of the HVS but in general it's dangerous to do this because it can cause bus lockups. Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
-
Dom Cobley authored
ABORT_ON_EMPTY chooses whether the HVS abandons the current frame when it experiences an underflow, or attempts to continue. In theory the frame should be black from the point of underflow, compared to a shift of sebsequent pixels to the left. Unfortunately it seems to put the HVS is a bad state where it is not possible to recover simply. This typically requires a reboot following the 'flip done timed out message'. Discussion with Broadcom has suggested we don't use this flag. All their testing is done with it disabled. Additionally setting BLANK_INSERT_EN causes the HDMI to output blank pixels on an underflow which avoids it losing sync. After this change a 'flip done timed out' due to sdram bandwidth starvation or too low a clock is recoverable once the situation improves. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dave Stevenson authored
The debugfs function to dump dlists aborted at 256 bytes, when actually the dlist memory is generally significantly larger but varies based on SoC. We already have the correct limit in __vc4_hvs_alloc, so store it for use in the debugfs dlist function. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The debug function to display the dlists didn't reset next_entry_start when starting each display, so resulting in not stopping the list at the correct place. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The offset fields in vc4_plane_state are described as being the offset for each buffer in the bo, however it is used to store the complete DMA address that is then written into the register. The DMA address including the fb ofset can be retrieved using drm_fb_dma_get_gem_addr, and the offset adjustment due to clipping is local to vc4_plane_mode_set. Drop the offset field from the state, and compute the complete DMA address in vc4_plane_mode_set. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dom Cobley authored
Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dave Stevenson authored
It has been observed that a YUV422 unity scaled plane isn't displayed. Enabling vertical scaling on the UV planes solves this. There is already a similar clause to always enable horizontal scaling on the UV planes. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Maxime Ripard authored
The BCM2712 HVS has registers to report the size of the various SRAM the driver uses, and their size actually differ depending on the stepping. The initialisation of the memory pools happen in the __vc4_hvs_alloc() function that also allocates the main HVS structure, that will then hold the pointer to the memory mapping of the registers. This creates some kind of circular dependency that we can break by passing the mapping pointer as an argument for __vc4_hvs_alloc() to use to query to get the SRAM sizes and initialise the memory pools accordingly. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
With the introduction of the support for BCM2712, the check of whether we're running on vc5 or not to compute the LBM alignment requirement doesn't work anymore. Moreover, the LBM size will need to be computed in words for the BCM2712, while we've had sizes in bytes so far. Aligning on either 64 or 32 words is thus fairly harmful on BCM2712, so let's just explicitly align the size when needed, and then call drm_mm_insert_node_generic() with an alignment of 1. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The BCM2712 will have a fairly different dlist, that will feature one Pointer 0 word for each plane. Let's prepare by changing the ptr0_offset variable that holds the offset in a dlist of the pointer 0 word to an array. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The HVS register set has been heavily modified in the BCM2712, and we'll thus need a separate debugfs_reg32 array for it. The name hvs_regs is thus a bit too generic, so let's rename it to something more specific. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Just like the HVS itself, the COB parameters will be fairly different in the BCM2712. Let's move the COB parameters computation and its initialisation to a separate function that will be easier to extend in the future. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Since the BCM2712 will feature a significantly different HVS, let's move the hardware initialisation part of our bind function into a separate function. That way, it will be easier to extend in the future. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
We currently enable the EOF interrupts through the CRTC destroy_state implementation. However, nothing guarantees that we can't call destroy_state multiple times in a row, and therefore before the EOF interrupt even happens. This means we would enable the interrupt multiple times but disable it only once. It wasn't an issue so far since the interrupts were only enabled by setting a bit in a register, but with BCM2712 we will use an external interrupt controller, with a refcounted interrupt. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Since we'll support BCM2712 soon, let's move the logic to enable and disable the end-of-frame interrupts to a switch to extend it more easily. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Since we'll support BCM2712 soon, let's move the logic behind vc4_hvs_get_fifo_from_output() to a switch to extend it more easily. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The V3D IP has been separate since BCM2711, so let's make sure we issue a WARN if we're running not only on BCM2711, but also anything newer. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-