- 07 Sep, 2020 40 commits
-
-
Dave Stevenson authored
The audio configuration has changed for the BCM2711, with notably a different parent clock and a different channel configuration. Make that modular to be able to support the BCM2711. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Tested-by:
Chanwoo Choi <cw00.choi@samsung.com> Tested-by:
Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by:
Stefan Wahren <stefan.wahren@i2se.com> Link: https://patchwork.freedesktop.org/patch/msgid/85a8ca721c2d800be758c55870cea98536749680.1599120059.git-series.maxime@cerno.tech
-
Dave Stevenson authored
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 authored
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 authored
The register range used for audio setup in the previous generations of SoC were always the second range in the device tree. However, now that the BCM2711 has way more register ranges, it makes sense to retrieve it by names for it, while preserving the id-based lookup as a fallback. Signed-off-by:
-
Maxime Ripard authored
The HSM clock needs to be running at 101% the pixel clock of the HDMI controller, however it's shared between the two HDMI controllers, which means that if the resolutions are different between the two HDMI controllers, and the lowest resolution is on the second (in enable order) controller, the first HDMI controller will end up with a smaller than expected clock rate. Since we don't really need an exact frequency there, we can simply change the minimum rate we expect instead. Signed-off-by:
-
Maxime Ripard authored
The HSM clock needs to be setup at around 101% of the pixel rate. This was done previously by setting the clock rate to 163.7MHz at probe time and only check in mode_valid whether the mode pixel clock was under the pixel clock +1% or not. However, with 4k we need to change that frequency to a higher frequency than 163.7MHz, and yet want to have the lowest clock as possible to have a decent power saving. 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 authored
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 authored
The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove it. Signed-off-by:
-
Maxime Ripard authored
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 authored
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 authored
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 variant to avoid that name conflict. Signed-off-by:
-
Maxime Ripard authored
The vc4 CRTC will use the encoder type to control its output clock muxing. However, this will be different from HDMI0 to HDMI1, so let's store our type in the variant structure so that we can support multiple controllers later on. Signed-off-by:
-
Maxime Ripard authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/aee5120728db350b19c074de4290eafaf01e6671.1599120059.git-series.maxime@cerno.tech
-
Maxime Ripard authored
Now that we don't have any users anymore, we can kill that pointer. Signed-off-by:
-
Maxime Ripard authored
The unbind function needs to retrieve a vc4_hdmi structure pointer through the struct device that we're given since we want to support multiple HDMI controllers. However, our optional ASoC support doesn't make that trivial since it will overwrite the device drvdata if we use it, but obviously won't if we don't use it. Let's make sure the fields are at the proper offset to be able to cast between the snd_soc_card structure and the vc4_hdmi structure transparently so we can support both cases. Signed-off-by:
-
Maxime Ripard authored
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 authored
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 authored
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 authored
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 authored
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 authored
Now that we are passing the vc4_hdmi structure to the connector init function, we can simply use the pointer in that structure instead of having the pointer as an argument. Signed-off-by:
-
Maxime Ripard authored
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 authored
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 authored
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 authored
The BCM2711 has 5 pixelvalves, so now that our driver is ready, let's add support for them. Signed-off-by:
-
Maxime Ripard authored
The BCM2711 comes with other pixelvalves that have different requirements and capabilities. Let's document their compatible. Signed-off-by:
Rob Herring <robh+dt@kernel.org> Reviewed-by:
-
Maxime Ripard authored
In order to prevent issues during the firmware to KMS transition, we need to make sure the pixelvalve are disabled at boot time so that the DRM state matches the hardware state. Signed-off-by:
-
Maxime Ripard authored
We'll need to reuse the part that disables the HVS and PixelValve during boot too, so let's create a separate function. Signed-off-by:
-
Maxime Ripard authored
At boot time, if we detect that a pixelvalve has been enabled, we need to be able to retrieve the HVS channel it has been assigned to so that we can disable that channel too. Let's create that function that returns the FIFO or an error from a given output. Signed-off-by:
-
Maxime Ripard authored
During the transition from the firmware to the KMS driver, we need to pay particular attention to how we deal with the pixelvalves that have already been enabled, otherwise either timeouts or stuck pixels can occur. We'll thus need to call the function to stop an HVS channel at boot. Signed-off-by:
-
Maxime Ripard authored
Even though it's not really clear why we need to flush the PV FIFO during the configuration even though we started by flushing it, experience shows that without it we get a stale pixel stuck in the FIFO between the HVS and the PV. Signed-off-by:
-
Maxime Ripard authored
In order to avoid a stale pixel getting stuck on mode change or a disable / enable cycle, we need to make sure to flush the PV FIFO on disable. Signed-off-by:
-
Maxime Ripard authored
In order to avoid pixels getting stuck in the (unflushable) FIFO between the HVS and the PV, we need to add some delay after disabling the PV output and before disabling the HDMI controller. 20ms seems to be good enough so let's use that. Signed-off-by:
-
