- Jun 18, 2020
-
-
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>
-
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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>
-
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 ID to avoid that name conflict. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
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>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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: Maxime Ripard <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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
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 <maxime@cerno.tech>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
The HVS5 uses different color matrices. Disable color management support for now. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
The BCM2711 sports a second HDMI controller, so let's add that second HDMI encoder type. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-