- 07 Sep, 2020 40 commits
-
-
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 <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> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/bd0c4afa83b4e121692352cdc2dd1886162c7552.1599120059.git-series.maxime@cerno.tech
-
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:
-
Maxime Ripard authored
In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller requires very precise ordering and timing that the regular atomic callbacks don't provide. Let's add new callbacks on top of the regular ones to be able to split the configuration as needed. Signed-off-by:
-
Maxime Ripard authored
In order to avoid stale pixels getting stuck in an intermediate FIFO between the HVS and the pixelvalve on BCM2711, we need to configure the HVS channel before the pixelvalve is reset and configured. Signed-off-by:
-
Maxime Ripard authored
Since we moved the pixelvalve configuration to atomic_enable, we're now first calling the function that resets the pixelvalve and then the one that configures it. However, the first thing the latter is doing is calling the reset function, meaning that we reset twice our pixelvalve. Let's remove the first call. Signed-off-by:
-
Maxime Ripard authored
On BCM2711 to avoid stale pixels getting stuck in intermediate FIFOs, the pixelvalve needs to be setup each time there's a mode change or enable / disable sequence. Therefore, we can't really use mode_set_nofb anymore to configure it, but we need to move it to atomic_enable. Signed-off-by:
-
Maxime Ripard authored
In order to clear our intermediate FIFOs that might end up with a stale pixel, let's make sure our FIFO channel is reset every time our channel is setup. Signed-off-by:
-
Maxime Ripard authored
Since most of the HVS channel is setup in the init function, let's move the gamma setup there too. As this makes the HVS mode_set function empty, let's remove it in the process. Signed-off-by:
-
Maxime Ripard authored
In order to make further refactoring easier, let's move the HVS channel setup / teardown to their own function. Signed-off-by:
-
Maxime Ripard authored
Now that we only configure the PixelValve in vc4_crtc_config_pv, it doesn't really make much sense to dump its register content in its caller. Signed-off-by:
-
