| 96a3278 | Phil Elwell | 08 April 2020, 14:23:56 UTC | kbuild: Disable gcc plugins The GCC plugin feature leads to different kernel configurations on what ought to be equivalent build systems because they depend on the build hosts native compilers rather than the cross compilers needed for the target. This causes problems with module symbol version mismatches. Disable GCC plugins for all build hosts. Advanced build script hackery borrowed from a patch by milhouse. Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| a31d81d | Phil Elwell | 08 April 2020, 10:59:39 UTC | overlays: Fix dtc warnings in i2c-gpio Better late than never. Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| f9d5f00 | Matt Flax | 08 April 2020, 10:00:30 UTC | Add support for the AudioInjector.net Isolated sound card This patch adds support for the Audio Injector Isolated sound card. Signed-off-by: Matt Flax <flatmax@flatmax.org> | 20 May 2020, 12:49:57 UTC |
| 8e29546 | Phil Elwell | 08 April 2020, 08:48:29 UTC | configs: FS_ENCRYPTION replaces EXT4_ENCRYPTION The filesystem-specific encryption options have been replaced by a generic FS_ENCRYPTION option. Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| aa840d2 | popcornmix | 09 September 2019, 14:49:56 UTC | clk-raspberrypi: Allow cpufreq driver to also adjust gpu clocks For performance/power it is beneficial to adjust gpu clocks with arm clock. This is how the downstream cpufreq driver works Signed-off-by: popcornmix <popcornmix@gmail.com> | 20 May 2020, 12:49:57 UTC |
| e2d8d77 | Phil Elwell | 06 April 2020, 08:47:42 UTC | Add upstream and upstream-pi4 to overlay_map Because the upstream overlay applies vc4-kms-v3d, of which Pi 4 has its own version, there also needs to be a Pi 4 version - vc4-kms-v3d-pi4. Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| a3e87d2 | Phil Elwell | 01 April 2020, 14:51:56 UTC | overlays: Add vc4-kms-v3d-pi4 to overlay_map Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| 8640124 | Phil Elwell | 01 April 2020, 16:24:15 UTC | overlays: Formally rename/deprecate old overlays Take advantage of the overlay_map to rename or deprecate some obsolete overlays. Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:57 UTC |
| 094d9da | Phil Elwell | 01 April 2020, 14:09:42 UTC | overlays: Add overlay_map The overlay map permits platform-specific overlays, with deprecation and renaming. See: https://github.com/raspberrypi/linux/issues/3520 Signed-off-by: Phil Elwell <phil@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| 95543d2 | Phil Elwell | 06 April 2020, 10:10:42 UTC | FIXUP: drm/vc4: Add support for margins to fkms | 20 May 2020, 12:49:56 UTC |
| 3a81707 | popcornmix | 02 April 2020, 15:46:31 UTC | vc4_hdmi_phy: Fix offset calculation The original firmware code worked with float and did offset = ((vco_freq / fref * 2) * (1 << 22)); offset >>= 2; In this code it's all integer so doing the integer divide before the shift loses lots of precision This fixes the issue of 1080p59.94 mode having 59.64 fps Signed-off-by: popcornmix <popcornmix@gmail.com> | 20 May 2020, 12:49:56 UTC |
| 20896ca | Dave Stevenson | 31 March 2020, 16:54:08 UTC | dt: Drop I2C for Pi4 HDMI interfaces to 97.5kHz. It was set to 390kHz, which is outside of the required spec for reading HDMI (max 100kHz). The i2c-brcmstb driver only supports a number of fixed bus speeds, of which 97.5kHz is the closest to 100kHz without exceeding it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| bbb8f57 | Dave Stevenson | 31 March 2020, 15:23:11 UTC | i2c: brcmstb: The interrupt line is optional, so use platform_get_irq_optional If there is no interrupt defined then an error is logged due to the use of platform_get_irq. The driver handles not having the interrupt by falling back to polling, therefore make the appropriate call when claiming it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| 00dd474 | Dave Stevenson | 31 March 2020, 15:21:45 UTC | drm/vc4-hdmi: Give the HDMI audio instances different names The debugfs usage within asoc gets confused if multiple interfaces have the same card name, therefore use unique names when initialising them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| a569864 | Dave Stevenson | 30 March 2020, 17:25:10 UTC | drm/vc4: Fixup plane init within firmware-kms "drm/vc4: plane: Move additional planes creation to driver" moved overlay and cursor plane creation to a global function thata was unconditionally run, when it is not wanted in firmware KMS mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| 8beaca1 | Dave Stevenson | 30 March 2020, 11:52:26 UTC | drm/vc4: Fixup for firmware KMS Fix up "drm/vc4: Kick the core clock up during a mode change" for firmware KMS mode where we don't have the HVS or core clock configured. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| 3accb8a | Dave Stevenson | 26 March 2020, 15:32:19 UTC | drm/vc4: Kick the core clock up during a mode change Experimental commit to kick the core clock up during mode switching. This makes mode switching far more reliable, and mimics what the firmware does. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:56 UTC |
| 8bf4ba6 | Dave Stevenson | 26 March 2020, 11:51:55 UTC | dtoverlays: Remove comment about vc4-kms-v3d locking up X from README Using vc4-kms-v3d with X has worked for quite a while, and essentially required not using fbturbo and having an up to date MESA library. Remove the comment that says otherwise. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| 4f36561 | Dave Stevenson | 25 March 2020, 18:22:40 UTC | drm/vc4: Alter the HDMI state machine clock calc to allow for 1920x1200 Whilst the documentation for BCM2835 states that the HDMI state machine clock needs to be 108% of the pixel clock, other documentation says that it only has to be greater than the pixel clock. The firmware uses 101%, and that allows 1920x1200@60Hz to work within the constraint of the HSM clock being < 163.68MHz. Adopt 101%, and increase the maximum pixel clock for vc4 to 162MHz so that it too supports 1920x1200@60. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| b749787 | Dave Stevenson | 25 March 2020, 18:18:45 UTC | drm/vc4: Enable audio on Pi4. This could be a revert of "drm/vc4: hdmi: Add an audio support flag" as it is no longer needed. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| 1223a42 | Dave Stevenson | 25 March 2020, 18:16:14 UTC | drm/vc4: Add audio initialisation for Pi4. The audio configuration has changed for Pi4, so support the configuration functions via the variant tables. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| f742c48 | Dave Stevenson | 25 March 2020, 18:11:41 UTC | drm/vc4: Use reg-names to configure HDMI audio. HDMI audio configuration was using fixed index numbers to load in DT register settings. Switch to using reg-names for flexibility and to match Pi4. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| 2f5d2fd | Dave Stevenson | 25 March 2020, 18:08:39 UTC | dt: Add HDMI audio dma values to bcm2711.dtsi Adds the relevant DMA settings for HDMI audio to work. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| 6d12a8f | Dave Stevenson | 25 March 2020, 18:07:19 UTC | dts: Add reg-names for the HDMI registers on bcm2835 Pi4 is requiring many more register configs in the HDMI block, and has switched to using reg-names instead of fixed index values. Switch bc2835-common to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| 47b296a | Dave Stevenson | 25 March 2020, 18:03:42 UTC | drm/vc4: Set the b-frame marker to the match ALSA's default. ALSA's iec958 plugin by default sets the block start preamble to 8, whilst this driver was programming the hardware to expect 0xF. Amend the hardware config to match ALSA. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| f7a8c77 | Dave Stevenson | 25 March 2020, 18:01:04 UTC | drm/vc4: Reset audio infoframe on encoder_enable if previously streaming If the encoder is disabled and re-enabled (eg mode change) all infoframes are reset, whilst the audio subsystem know nothing about this change. The driver therefore needs to reinstate the audio infoframe for itself. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| fc1740f | Dave Stevenson | 17 February 2020, 11:37:21 UTC | dt: Update v3d to use firmware_clocks. Use the updated DT clock-names property to map the v3d clock to the firmware_clocks driver, instead of the older clkdev API. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:55 UTC |
| bf5baa5 | Dave Stevenson | 11 February 2020, 15:36:59 UTC | drm/vc4: The check for assigned HVS channels is not applicable firmware_kms Channel assignments is only in full KMS, so skip the check if in firmware kms mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:54 UTC |
| d118594 | Dave Stevenson | 25 February 2020, 17:35:10 UTC | Fixup P030 support I got the logic wrong for enabling pixel formats, resulting in Pi0-3 only getting a single, invalid, format (P030 SAND). Fixes: e07ef1d drm/vc4: Add support for DRM_FORMAT_P030 to vc4 planes Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:54 UTC |
| d9e4279 | Dave Stevenson | 24 January 2020, 14:25:41 UTC | drm/vc4: Add support for DRM_FORMAT_P030 to vc4 planes This currently doesn't handle non-zero source rectangles correctly, but add support for DRM_FORMAT_P030 with DRM_FORMAT_MOD_BROADCOM_SAND128 modifier to planes when running on HVS5. WIP still for source cropping SAND/P030 formats Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:54 UTC |
| eaf351b | Dave Stevenson | 27 January 2020, 10:22:44 UTC | drm: Checking of the pitch is only valid for linear formats framebuffer_check was computing a minimum pitch value and ensuring that the provided value was greater than this. That check is only valid if the format is linear. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> | 20 May 2020, 12:49:54 UTC |
| 0eb0dfe | Dave Stevenson | 20 September 2019, 16:20:01 UTC | dtoverlays: Add Pi4 version of vc4-kms-v3d The Pi4 version of the KMS drivers is a work in progress, some blocks need alternate configuration, and some blocks currently need to remain disabled (eg the VEC). Add a new overlay (vc4-kms-v3d-pi4) that loads the parts of vc4-kms that do work on Pi4. This has been tested with DPI and HDMI (not 100% reliable on mode switching) Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org> | 20 May 2020, 12:49:54 UTC |
| 931ce71 | Maxime Ripard | 21 February 2020, 16:10:45 UTC | [DOWNSTREAM] ARM: dts: rpi4: Disable KMS driver by default Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:54 UTC |
| 96f908c | Maxime Ripard | 12 February 2020, 11:26:40 UTC | ARM: dts: bcm2711: Enable the display pipeline Now that all the drivers have been adjusted for it, let's bring in the necessary device tree changes. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:54 UTC |
| 32956d0 | Maxime Ripard | 13 February 2020, 15:45:24 UTC | dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings The HDMI controllers found in the BCM2711 SoC need some adjustments to the bindings, especially since the registers have been shuffled around in more register ranges. Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:54 UTC |
| 128abd0 | Maxime Ripard | 17 December 2019, 10:48:37 UTC | drm/vc4: hdmi: Support the BCM2711 HDMI controllers Now that the driver is ready for it, let's bring in the HDMI controllers variants for the BCM2711. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| e5fa3ab | Maxime Ripard | 10 February 2020, 14:23:06 UTC | drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate The HSM clock needs to be setup at around 110% of the pixel rate. This was done previously by setting the clock rate to 148.5MHz * 108% at probe time and only check in mode_valid whether the mode pixel clock was under 148.5MHz or not. However, with 4k we need to change that frequency to a higher frequency than 148.5MHz. Let's change that logic a bit by setting the clock rate of the HSM clock to the pixel rate at encoder_enable time. This would work for the BCM2711 that support 4k resolutions and has a clock that can provide it, but we still have to take care of a 4k panel plugged on a BCM283x SoCs that wouldn't be able to use those modes, so let's define the limit in the variant. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| a2fb4d4 | Maxime Ripard | 13 February 2020, 11:31:09 UTC | drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid The mode_valid hook on the encoder uses a pointer to a drm_encoder called crtc, which is pretty confusing. Let's rename it to encoder to make it clear what it is. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| 731fc9e | Maxime Ripard | 10 February 2020, 14:15:47 UTC | drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| 67ba17a | Maxime Ripard | 06 February 2020, 15:22:50 UTC | drm/vc4: hdmi: Add CEC support flag Similarly to the audio support, CEC support is not there yet for the BCM2711, so let's skip entirely the CEC initialization through a variant flag. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| 09ee4b5 | Maxime Ripard | 06 February 2020, 15:22:13 UTC | drm/vc4: hdmi: Move CEC init to its own function The CEC init code was put directly into the bind function, which was quite inconsistent with how the audio support was done, and would prevent us from further changes to skip that initialisation entirely. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:53 UTC |
| 1b151e9 | Maxime Ripard | 06 February 2020, 15:21:45 UTC | drm/vc4: hdmi: Add an audio support flag The BCM2711 audio support doesn't work yet, so let's add a boolean to indicate whether or not it's supported, and only register a sound card if that boolean is set. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| a7a164d | Maxime Ripard | 16 January 2020, 13:27:56 UTC | drm/vc4: hdmi: Deal with multiple debugfs files The HDMI driver was registering a single debugfs file so far with the name hdmi_regs. Obviously, this is not going to work anymore when will have multiple HDMI controllers since we will end up trying to register two files with the same name. Let's use the ID to avoid that name conflict. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 18f47a5 | Maxime Ripard | 07 January 2020, 12:14:07 UTC | drm/vc4: hdmi: Add HDMI ID Some operations will need us to have the raw ID of the HDMI controller in the BCM2711, such as the encoder type to register, the name of the debugfs files, etc. Let's add it to our variant structure. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 74cdf7c | Maxime Ripard | 06 January 2020, 12:43:27 UTC | drm/vc4: hdmi: Add a set_timings callback Similarly to the previous patches, the timings setup in the HDMI controller of the BCM2711 is slightly different, mostly because it supports higher resolutions and thus needed more spaces for the various timings, resulting in the register layout changing. Let's add a callback for that as well. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 78f96cb | Maxime Ripard | 26 December 2019, 17:41:53 UTC | drm/vc4: hdmi: Add a CSC setup callback Similarly to the previous patches, the CSC setup is slightly different in the BCM2711 than in the previous generations. Let's add a callback for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 5101889 | Maxime Ripard | 19 December 2019, 16:22:24 UTC | drm/vc4: hdmi: Add PHY RNG enable / disable function Let's continue the implementation of hooks for the parts that change in the BCM2711 SoC with the PHY RNG setup. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 770c4e9 | Maxime Ripard | 19 December 2019, 15:53:33 UTC | drm/vc4: hdmi: Add PHY init and disable function The HDMI PHY in the BCM2711 HDMI controller is significantly more complicated to setup than in the older BCM283x SoCs. Let's add hooks to enable and disable the PHY. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:52 UTC |
| 5bdbf65 | Maxime Ripard | 19 December 2019, 15:25:26 UTC | drm/vc4: hdmi: Add reset callback The BCM2711 and BCM283x HDMI controllers use a slightly different reset sequence, so let's add a callback to reset the controller. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| 8d5bcc5 | Maxime Ripard | 18 December 2019, 18:15:08 UTC | drm/vc4: hdmi: Implement a register layout abstraction The HDMI controllers found in the BCM2711 have most of the registers reorganized in multiple registers areas and at different offsets than previously found. The logic however remains pretty much the same, so it doesn't really make sense to create a whole new driver and we should share the code as much as possible. Let's implement some indirection to wrap around a register and depending on the variant will lookup the associated register on that particular variant. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| d9ed9d2 | Maxime Ripard | 18 December 2019, 10:30:54 UTC | drm/vc4: hdmi: Introduce resource init and variant The HDMI controllers found in the BCM2711 has a pretty different clock and registers areas than found in the older BCM283x SoCs. Let's create a variant structure to store the various adjustments we'll need later on, and a function to get the resources needed for one particular version. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| 7845952 | Maxime Ripard | 06 January 2020, 17:57:16 UTC | drm/vc4: hdmi: Remove vc4_hdmi_connector The vc4_hdmi_connector was only used to switch between drm_connector to drm_encoder. However, we can now use vc4_hdmi to do the switch, so that structure is redundant. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| 81f6a6d | Maxime Ripard | 06 January 2020, 17:49:11 UTC | drm/vc4: hdmi: Remove vc4_dev hdmi pointer Now that we don't have any users anymore, we can kill that pointer. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| a03f6c8 | Maxime Ripard | 06 January 2020, 17:47:53 UTC | drm/vc4: hdmi: Pass vc4_hdmi to CEC code Our CEC code also retrieves the associated vc4_hdmi by setting the vc4_dev pointer as its private data, and then dereferences its vc4_hdmi pointer. In order to eventually get rid of that pointer, we can simply pass the vc4_hdmi pointer directly. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| f19886c | Maxime Ripard | 06 January 2020, 17:45:46 UTC | drm/vc4: hdmi: Add container_of macros for encoders and connectors Whenever the code needs to access the vc4_hdmi structure from a DRM connector or encoder, it first accesses the drm_device associated to the connector, then retrieve the drm_dev private data which gives it a pointer to our vc4_dev, and will finally follow the vc4_hdmi pointer in that structure. That will also give us some trouble when having multiple controllers, but now that we have our encoder and connector structures that are part of vc4_hdmi, we can simply call container_of on the DRM connector or encoder and retrieve the vc4_hdmi structure directly. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:51 UTC |
| 5ca5d97 | Maxime Ripard | 06 January 2020, 17:44:36 UTC | drm/vc4: hdmi: Use local vc4_hdmi directly The function vc4_hdmi_connector_detect access its vc4_hdmi struct by dereferencing the pointer in the structure vc4_dev. This will cause some issues when we will have multiple HDMI controllers, so let's just use the local variable for now instead of dereferencing that pointer all the time, and we'll fix the local variable later. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 881fb6e | Maxime Ripard | 06 January 2020, 17:21:44 UTC | drm/vc4: hdmi: Move accessors to vc4_hdmi The current driver only supports a single HDMI controller, and part of the issue is that the main vc4_dev structure holds a pointer to its (only) HDMI controller, and the HDMI registers accessors will use it to retrieve the mapped addresses. Let's modify those accessors to use directly the vc4_hdmi structure so that we can eventually get rid of that single global pointer. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 54cc18d | Maxime Ripard | 06 January 2020, 17:07:05 UTC | drm/vc4: hdmi: Rename hdmi to vc4_hdmi The driver isn't consistent with the name given to the vc4_hdmi structure pointer in its functions. Make sure to use a consistent name. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| f106aa7 | Maxime Ripard | 06 January 2020, 16:17:29 UTC | drm/vc4: hdmi: rework connectors and encoders the vc4_hdmi driver has some custom structures to hold the data it needs to associate with the drm_encoder and drm_connector structures. However, it allocates them separately from the vc4_hdmi structure which makes it more complicated than it needs to be. Move those structures to be contained by vc4_hdmi and update the code accordingly. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 0c5f71a | Maxime Ripard | 18 December 2019, 17:35:12 UTC | drm/vc4: hdmi: Move structure to header We will need to share the vc4_hdmi and related structures with multiple files, so let's create a header for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 5a7bf3b | Maxime Ripard | 14 January 2020, 16:24:32 UTC | drm/vc4: hdmi: Use debugfs private field We're calling vc4_debugfs_add_file with our struct vc4_hdmi pointer set in the private field, but we don't use that field and go through the main struct vc4_dev to get it. Let's use the private field directly, that will save us some trouble later on. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 7dff744 | Maxime Ripard | 26 December 2019, 10:35:58 UTC | drm/vc4: crtc: Add BCM2711 pixelvalves The BCM2711 has 5 pixelvalves, so now that our driver is ready, let's add support for them. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| cac21ce | Maxime Ripard | 13 February 2020, 16:07:02 UTC | dt-bindings: display: vc4: pv: Add BCM2711 pixel valves The BCM2711 comes with other pixelvalves that have different requirements and capabilities. Let's document their compatible. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:50 UTC |
| 5234196 | Maxime Ripard | 21 February 2020, 15:54:21 UTC | drm/vc4: crtc: Disable color management for HVS5 The HVS5 uses different color matrices. Disable color management support for now. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 06e7202 | Maxime Ripard | 21 February 2020, 15:48:19 UTC | drm/vc4: crtc: Remove redundant call to drm_crtc_enable_color_mgmt The driver calls the helper to add the color management properties twice, which is redundant. Remove the first one. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 6483047 | Maxime Ripard | 09 January 2020, 17:39:30 UTC | drm/vc4: crtc: Add HDMI1 encoder type The BCM2711 sports a second HDMI controller, so let's add that second HDMI encoder type. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 0dfea31 | Maxime Ripard | 09 January 2020, 17:35:13 UTC | drm/vc4: crtc: Rename HDMI encoder type to HDMI0 The previous generations were only supporting a single HDMI controller, but that's about to change, so put an index as well to differentiate between the two controllers. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| c54dffc | Maxime Ripard | 13 January 2020, 12:40:37 UTC | drm/vc4: crtc: Add function to compute FIFO level bits The longer FIFOs in vc5 pixelvalves means that the FIFO full level doesn't fit in the original register field and that we also have a secondary field. In order to prepare for this, let's move the registers fill part to a helper function. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 704a48c | Maxime Ripard | 13 January 2020, 12:39:20 UTC | drm/vc4: crtc: Add FIFO depth to vc4_crtc_data Not all pixelvalve FIFOs in vc5 have the same depth, so we need to add that to our vc4_crtc_data structure to be able to compute the fill level properly later on. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 277b51a | Maxime Ripard | 26 December 2019, 16:53:18 UTC | drm/vc4: crtc: Assign output to channel automatically The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output being connected to a pixelvalve, and some muxing between the FIFOs and outputs. Any output cannot feed from any FIFO though, and they all have a bunch of constraints. In order to support this, let's store the possible FIFOs each output can be assigned to in the vc4_crtc_data, and use that information at atomic_check time to iterate over all the CRTCs enabled and assign them FIFOs. The channel assigned is then set in the vc4_crtc_state so that the rest of the driver can use it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| 5f8b77b | Maxime Ripard | 21 February 2020, 13:34:31 UTC | drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable The VIDEN bit in the pixelvalve currently being used to enable or disable the pixelvalve seems to not be enough in some situations, which whill end up with the pixelvalve stalling. In such a case, even re-enabling VIDEN doesn't bring it back and we need to clear the FIFO. This can only be done if the pixelvalve is disabled though. In order to overcome this, we can configure the pixelvalve during mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO there, and in atomic_disable disable the pixelvalve again. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:49 UTC |
| c0e249d | Maxime Ripard | 14 January 2020, 12:37:27 UTC | drm/vc4: crtc: Use local chan variable The vc4_crtc_handle_page_flip already has a local variable holding the value of vc4_crtc->channel, so let's use it instead. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| bac2291 | Maxime Ripard | 26 December 2019, 12:49:17 UTC | drm/vc4: crtc: Rename HVS channel to output In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with pixelvalves each being assigned to a given output, but each output can then be muxed to feed from multiple FIFOs. Since vc4 had that entirely static, both were probably equivalent, but since that changes, let's rename hvs_channel to hvs_output in the vc4_crtc_data, since a pixelvalve is really connected to an output, and not to a FIFO. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| 1f797b3 | Maxime Ripard | 26 December 2019, 14:48:09 UTC | drm/vc4: crtc: Move the cob allocation outside of bind The COB allocation depends on the HVS channel used for a given pixelvalve. While the channel allocation was entirely static in vc4, vc5 changes that and at bind time, a pixelvalve can be assigned to multiple HVS channels. Let's prepare that rework by allocating the COB when it's actually needed. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| 574782b | Maxime Ripard | 13 January 2020, 12:39:32 UTC | drm/vc4: crtc: Turn static const variable into a define The hvs_latency_pix variable doesn't need to be a variable and can just be defined. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| fffa10b | Maxime Ripard | 09 January 2020, 17:40:49 UTC | drm/vc4: crtc: Use a shared interrupt Some pixelvalves in vc5 use the same interrupt line so let's register our interrupt handler as a shared one. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| 3ea0ebb | Maxime Ripard | 26 December 2019, 10:36:50 UTC | drm/vc4: crtc: Deal with different number of pixel per clock Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle. Let's put the number of pixel output per clock cycle in the CRTC data and update the various calculations to reflect that. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| 7b07ad1 | Maxime Ripard | 26 December 2019, 14:45:04 UTC | drm/vc4: crtc: Move crtc state to common header We'll need to access the crtc_state from outside of vc4_crtc.c, so let's move it to vc4_drv.h Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| adfd040 | Maxime Ripard | 26 December 2019, 10:45:04 UTC | drm/vc4: crtc: Rename SoC data structures Since we're going to introduce pixelvalve data structures for other SoCs than the BCM2835, let's rename the structures defined in the code to make it obvious which SoC we're targetting. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| 6112d97 | Maxime Ripard | 06 February 2020, 13:52:42 UTC | drm/vc4: plane: Create more planes Let's now create more planes that can be affected to all the CRTCs. vc4 has 3 CRTCs, 1 primary and 1 cursor each, and was having 24 (8 planes per CRTC) overlays. However, vc5 has 5 CRTCs, so keeping the same logic would put us at 50 planes which is well above the 32 planes limit imposed by DRM. Using 16 seems like a good tradeoff between staying under 32 and yet providing enough planes. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:48 UTC |
| b549bfb | Maxime Ripard | 06 February 2020, 13:50:06 UTC | drm/vc4: plane: Create overlays for any CRTC Now that we have everything in place, we can now register all the overlay planes that can be assigned to all the CRTCs. This has two side effects: - The number of overlay planes is reduced from 24 to 8. This is temporary and will be increased again in the next patch. - The ID of the various planes is changed again, and we will now have all the primary planes, then all the overlay planes and finally the cursor planes. This shouldn't cause any issue since the ordering between primary, overlay and cursor planes is preserved. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| 4a8849a | Maxime Ripard | 06 February 2020, 13:46:14 UTC | drm/vc4: plane: Register all the planes at once Instead of creating planes for each CRTC, we eventually want to create all the planes for each CRTCs. In order to make that more convenient, let's iterate on the CRTCs in the plane creation function instead of its caller. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| dfe9244 | Maxime Ripard | 06 February 2020, 13:41:41 UTC | drm/vc4: plane: Move additional planes creation to driver So far the plane creation was done when each CRTC was bound, and those planes were only tied to the CRTC that was registering them. This causes two main issues: - The planes in the vc4 hardware are actually not tied to any CRTC, but can be used with every combination - More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs. However, the next generation of hardware will have 5 CRTCs, putting us well above the maximum of 32 planes currently allowed by DRM. This patch is the first one in a series of patches that will take down both of these issues so that we can support the next generation of hardware while keeping a good amount of planes. We start by changing the way the planes are registered to first registering the primary planes for each CRTC in the CRTC bind function as we used to, but moving the overlay and cursor creation to the main driver bind function, after all the CRTCs have been bound. This will slightly change the ID order of the planes, since the primary planes of all CRTCs will be first, and then a pattern of 8 overlays, 1 cursor plane for each CRTC. This shouldn't cause any trouble since the ordering between the planes is preserved though. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| 35ab9d3 | Maxime Ripard | 06 February 2020, 13:32:57 UTC | drm/vc4: plane: Move planes creation to its own function The planes so far were created as part of the CRTC binding code with each planes created associated only to one CRTC. However, the hardware in the vc4 doesn't really have such constraint and can be used with any CRTC. In order to rework this, let's first move the overlay and cursor planes creation to a function of its own. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| b07b597 | Dave Stevenson | 11 February 2020, 16:55:02 UTC | drm/vc4: plane: Improve LBM usage LBM allocations were always taking the worst case sizing of max(src_width, dst_width) * 16. This is significantly over the required sizing, and stops us rendering multiple 4k images to the screen. Add some of the additional constraints to more accurately describe the LBM requirements. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| 4383272 | Dave Stevenson | 08 August 2019, 16:51:07 UTC | drm/vc4: drv: Add support for the BCM2711 HVS5 The HVS found in the BCM2711 is slightly different from the previous generations. Most notably, the display list layout changes a bit, the LBM doesn't have the same size and the formats ordering for some formats is swapped. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| 781a771 | Maxime Ripard | 06 February 2020, 14:40:34 UTC | drm/vc4: drv: Support BCM2711 The BCM2711 has a reworked display pipeline, and the load tracker needs some adjustement to operate properly. Let's add a compatible for BCM2711 and disable the load tracker until properly supported. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| f2e2cb7 | Maxime Ripard | 19 December 2019, 17:08:48 UTC | drm/vc4: drv: Add include guards vc4_drv.h doesn't have any include guards which prevents it from being included twice. Let's add them. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| 44c8536 | Maxime Ripard | 13 February 2020, 16:40:56 UTC | dt-bindings: display: vc4: Document BCM2711 VC5 The BCM2711 comes with a new VideoCore. Add a compatible for it. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:47 UTC |
| bda52ac | Maxime Ripard | 13 February 2020, 14:47:18 UTC | dt-bindings: display: vc4: hdmi: Add missing clock-names property While the device tree and the driver expected a clock-names property, it wasn't explicitly documented in the previous binding. The documented order was wrong too, so make sure clock-names is there and in the proper order. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| 8553dd1 | Maxime Ripard | 13 February 2020, 14:47:18 UTC | dt-bindings: display: vc4: dsi: Add missing clock properties While the device tree and the driver expected a clock-names and a clock-cells properties, it wasn't explicitly documented in the previous binding. Make sure it is now. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| cedf51c | Maxime Ripard | 13 February 2020, 14:47:18 UTC | dt-bindings: display: vc4: dpi: Add missing clock-names property While the device tree and the driver expected a clock-names property, it wasn't explicitly documented in the previous binding. Make sure it is now. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| 3054fbb | Maxime Ripard | 13 February 2020, 14:42:05 UTC | dt-bindings: display: Convert VC4 bindings to schemas The BCM283x SoCs have a display pipeline composed of several controllers with device tree bindings that are supported by Linux. Now that we have the DT validation in place, let's split into separate files and convert the device tree bindings for those controllers to schemas. This is just a 1:1 conversion though, and some bindings were incomplete so it results in example validation warnings that are going to be addressed in the following patches. Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| 41327cb | Maxime Ripard | 28 January 2020, 08:37:06 UTC | ARM: dts: bcm2711: Add HDMI DVP Now that we have a driver for the DVP, let's add its DT node. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| b94ecb9 | Maxime Ripard | 28 January 2020, 08:36:27 UTC | clk: bcm: Add BCM2711 DVP driver The HDMI block has a block that controls clocks and reset signals to the HDMI0 and HDMI1 controllers. Let's expose that through a clock driver implementing a clock and reset provider. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-clk@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| 99d0821 | Maxime Ripard | 13 February 2020, 16:50:31 UTC | dt-bindings: clock: Add BCM2711 DVP binding The BCM2711 has a unit controlling the HDMI0 and HDMI1 clock and reset signals. Let's add a binding for it. Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| 82a1dc0 | Maxime Ripard | 28 January 2020, 15:22:20 UTC | reset: simple: Add reset callback The reset-simple code lacks a reset callback that is still pretty easy to implement. The only real thing to consider is the delay needed for a device to be reset, so let's expose that as part of the reset-simple driver data. Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:46 UTC |
| fb99135 | Maxime Ripard | 28 January 2020, 08:33:52 UTC | reset: Move reset-simple header out of drivers/reset The reset-simple code can be useful for drivers outside of drivers/reset that have a few reset controls as part of their features. Let's move it to include/linux/reset. Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:45 UTC |
| f38e362 | Maxime Ripard | 23 December 2019, 18:58:30 UTC | ARM: dts: bcm2711: Add firmware clocks node Now that we have a clock driver for the clocks exposed by the firmware, let's add the device tree nodes for it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:45 UTC |
| 7ed3940 | Maxime Ripard | 10 February 2020, 13:06:09 UTC | clk: bcm: rpi: Discover the firmware clocks The RaspberryPi4 firmware actually exposes more clocks than are currently handled by the driver and we will need to change some of them directly based on the pixel rate for the display related clocks, or the load for the GPU. This rate change can have a number of side-effects, including adjusting the various PLL voltages or the PLL parents. The firmware will also update those clocks by itself for example if the SoC runs too hot. In order to make Linux play as nice as possible with those constraints, it makes sense to rely on the firmware clocks as much as possible. Fortunately,t he firmware has an interface to discover the clocks it exposes. Let's use it to discover, register the clocks in the clocks framework and then expose them through the device tree for consumers to use them. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> | 20 May 2020, 12:49:45 UTC |
