- Dec 19, 2023
-
-
Dave Stevenson authored
Fixes: 1216ea56 ("drm/fb-helper: Look up preferred fbdev node number from DT") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Apparently aliases are only allowed lower case and hyphens, so swap the use of underscore to hyphen. Fixes: 3aa1f247 ("drm: Look for an alias for the displays to use as the DRM device name") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
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 <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
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 <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
11cf37e7 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: 11cf37e7 ("drm/vc4: Move the buffer offset out of the vc4_plane_state") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
bcm2708_fb is disabled by the vc4-kms-v3d overlay, which means that the DMA memcpy support it provides is not available to allow vclog to read the VC logs from the top 16MB on Pi 2 and Pi 3. Add the code to the vc_mem driver, which will still be enabled. It ought to be possible to do a proper DMA_MEM_TO_MEM copy via the generic DMA customer API, but that can be a later step. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
The firmware wants the YUYV format stride alignment to be to a multiple of 32pixels / 64 bytes. The kernel driver was configuring it to a multiple of 16 pixels / 32 bytes, which then failed when it tried starting to stream. Correct the alignment requirements. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
John Cox authored
In order to use iommu on hevc set dma mask_and_coherent in probe. I am assured dma_set_mask_and_coherent is benign on Pi4 (which has no iommu) and it seems to be so in practice. Also adds a bit of debug to make internal buffer allocation failure easier to spot in future Signed-off-by: John Cox <jc@kynesim.co.uk>
-
Dave Stevenson authored
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 <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
Forcing a gpiochip to have a fixed base number now leads to a warning message. Remove the need to do so by calculating hwirq numbers based on bank numbers. Signed-off-by: Phil Elwell <phil@raspberrypi.com> Fixes: 3b0213d5 ("gpio: Add GPIO support for Broadcom STB SoCs")
-
Dom Cobley authored
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: e84da235 ("drm/vc4: hvs: Support BCM2712 HVS") Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dave Stevenson authored
Allow DT aliases of eg DSI2 to force make DRM allocate the display with the requested name. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Naushir Patuck authored
It was accidentally placed in the audio decoder section. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Tomi Valkeinen authored
The driver does not lock the imx477 mutex when calling imx477_set_framing_limits(), leading to: WARNING: CPU: 3 PID: 426 at drivers/media/v4l2-core/v4l2-ctrls-api.c:934 __v4l2_ctrl_modify_range+0x1a0/0x210 [ videodev] Fix this by taking the lock. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
Dave Stevenson authored
The 10.1" panel doesn't work with the timings defined. vc4 will always have been fixing up the timing due to the limited integer divider, so compute the fixed up mode and use it directly. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
vc4 has always fixed up the timing, so the values defined have never actually appeared on the wire. The display appears to want a slightly longer HFP, so extend the timings and recompute the clock to give the same frame rate. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Avoid double buffering LBM allocations by making the allocation a single alloc per crtc at atomic_flush. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dom Cobley authored
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 <popcornmix@gmail.com>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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 <maxime@cerno.tech>
-
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>
-