aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2020-09-07drm/vc4: crtc: Move HVS channel init before the PV initialisationMaxime Ripard1-4/+4
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9d7c5a03bc1a1e6d50f7b617cc2d8a46a4bbb7bc.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Remove redundant pixelvalve resetMaxime Ripard1-1/+0
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a0a31af0d4a7a070de979f0e5b618d9e2c730e7f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Remove mode_set_nofbMaxime Ripard1-6/+1
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f86c7a6946f98262f1cf59a461596a796d4bcc5f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: hvs: Make sure our channel is resetMaxime Ripard1-0/+4
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b34c562b36177c758dd2e9d84bceb07689bfbe05.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the HVS gamma LUT setup to our init functionMaxime Ripard4-47/+16
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d439da8f1592a450a6ad35ab1f9e77def17c7965.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move HVS init and close to a functionMaxime Ripard1-46/+58
In order to make further refactoring easier, let's move the HVS channel setup / teardown to their own function. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/fb1b5299d1636ddce8340b51a80d51641839f83b.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move PV dump to config_pvMaxime Ripard1-14/+12
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: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c195af7d9e140a2a6db32992ee7e54071c6f94ba.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Turn pixelvalve reset into a functionMaxime Ripard1-7/+13
The driver resets the pixelvalve FIFO in a number of occurences without always using the same sequence. Since this will be critical for BCM2711, let's move that sequence to a function so that we are consistent. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/fb31003a9eee02c4b949556299ff41f0a113499a.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Disable color management for HVS5Maxime Ripard2-7/+12
The HVS5 uses different color matrices. Disable color management support for now. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e528e2edf0a1be3930196d437e548114dd9fcf59.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add HDMI1 encoder typeMaxime Ripard1-0/+1
The BCM2711 sports a second HDMI controller, so let's add that second HDMI encoder type. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6ba56d2421a4ad59ce72178e8f37eacfbd72cb33.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HDMI encoder type to HDMI0Maxime Ripard3-3/+3
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/84e11e4793aaa30d6e5c56e305d22404ac5a932d.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add function to compute FIFO level bitsMaxime Ripard1-2/+10
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e46a3823128af50c1c833de8fa9b95e9b86c2f66.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add FIFO depth to vc4_crtc_dataMaxime Ripard2-3/+20
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7df3549c1bea9b0a27c784dc416bb9a831e4e18f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Assign output to channel automaticallyMaxime Ripard6-26/+200
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f9aba3814ef37156ff36f310118cdd3954dd3dc5.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: kms: Convert to for_each_new_crtc_stateMaxime Ripard1-4/+6
The vc4 atomic commit loop has an handrolled loop that is basically identical to for_each_new_crtc_state, let's convert it to that helper. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a712d2b70aaee20379cfc52c2141aa2f6e2a9d5b.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Enable and disable the PV in atomic_enable / disableMaxime Ripard1-3/+7
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 by calling vc4_crtc_config_pv, 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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e97596f62f4df83424d994a23465463ac60f986e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Use local chan variableMaxime Ripard1-1/+1
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/439c589baec72ddb89159857a2d078fdd77b02a2.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HVS channel to outputMaxime Ripard4-8/+8
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b7618bb17b1c435c5d6ce50bcde2fe9243281d02.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the cob allocation outside of bindMaxime Ripard2-20/+17
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/484cbd4b00cfeee425295df438222258cc39a3dd.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Use a shared interruptMaxime Ripard1-1/+3
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/5a915d374357f41083ac71779fa9b2c35a339c2f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Deal with different number of pixel per clockMaxime Ripard2-7/+14
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/18a3bb079981ba820132b37e736a4bb371234d2e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Create more planesMaxime Ripard1-1/+1
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 <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b41003001541fc2bb23668c699c0369ff7983be8.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Optimize the LBM allocation sizeDave Stevenson1-4/+13
The current code is using the maximum of the source line size and the destination line size to compute the size of the LBM to allocate. While this is simpler, it starts to be an issue with modes such as 4k with a quite long that will consume all the available memory, so we no longer have that luxury. Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b9e091883a4f7395c5b6a4f7c6070225934293db.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Change LBM alignment constraint on LBMDave Stevenson1-1/+3
The HVS5 needs an alignment of 64bytes for its LBM memory, so let's reflect it. Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6f9c4fe1eb9258a3f1d0f21af6a99c42472ac531.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: hvs: Boost the core clock during modesetMaxime Ripard3-0/+29
In order to prevent timeouts and stalls in the pipeline, the core clock needs to be maxed at 500MHz during a modeset on the BCM2711. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/37ed9e0124c5cce005ddc8dafe821d8b0da036ff.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: Add support for the BCM2711 HVS5Dave Stevenson4-59/+240
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Chanwoo Choi <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1d02fab3b916d639c2dc05608c117bbd8230ebe8.1599120059.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Remove the feed_txp testsMaxime Ripard1-22/+7
Now that the code in vc4_crtc accessing registers is only meant for the pixelvalve, it doesn't make sense anymore to test whether we're accessing the TXP or not and we can safely remove those checks. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c044daba470fcb1cb57e3d34d88f75325b2ebbab.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: txp: Turn the TXP into a CRTC of its ownMaxime Ripard2-20/+99
The TXP so far has been leveraging the PixelValve infrastructure in the driver, that was really two things: the interaction with DRM's CRTC concept, the setup of the underlying pixelvalve and the setup of the shared HVS, the pixelvalve part being irrelevant to the TXP since it accesses the HVS directly. Now that we have a clear separation between the three parts, we can represent the TXP as a CRTC of its own, leveraging the common CRTC and HVS code, but leaving aside the pixelvalve setup. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20f387f881b57f3474fa42d94cfd8bc1b7b80595.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Move the txp_armed function to the TXPMaxime Ripard3-9/+8
The TXP driver is the only place where we need to set the txp_armed flag, so let's move the function in the TXP driver. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/12b383e7b8462e281b00c0a21b2b50f13691bead.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Move the CRTC initialisation to a separate functionMaxime Ripard2-37/+53
The upcoming patches to turn the TXP into a full-blown CRTC will have the same CRTC initialisation code, so let's move it into a separate, public, function so that we can reuse it later on. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3a3026c0e7408895d154d8dea454cf6d1c459715.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Only access the PixelValve registers if we have toMaxime Ripard1-4/+15
The CRTC hooks are called both for the TXP and the pixelvalve, yet some will read / write the registers as if the device was a pixelvalve, which won't really work. Let's make sure we only access those registers if we are running on a PixelValve. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b55e31869304c748920c261eba87b3275dbeb297.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Split CRTC data in twoMaxime Ripard2-11/+37
The vc4_crtc_data structure is currently storing data related to both the general CRTC information needed by the rest of the vc4 driver (like HVS output and available FIFOs) and some related to the pixelvalve attached to that CRTC. Let's split this into two structures so that we can reuse the CRTC part into the TXP later on. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8eb317c91ac208d7f926d76ad421002fa0364c47.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Make state functions publicMaxime Ripard2-11/+20
We'll need the CRTC state related functions to be exported so that we can reuse them for the TXP. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/658f40aa01d7a45cbf6feebfc3dc6549f100d110.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: crtc: Move HVS setup code to the HVS driverMaxime Ripard3-251/+302
The CRTC in vc4 is backed by two devices, the HVS that does the composition and the PixelValve that does the timing generation. The writeback is kind of a special case since it doesn't have an associated pixelvalve but goes straight from the HVS to the TXP. Therefore, it makes sense to move out the HVS setup code into helpers so that we can also reuse them from the TXP driver. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/96443394e81429ee38f070cfe231701b07e56d69.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: Reorder the bind order of the devicesMaxime Ripard1-1/+1
We'll need the HVS to be bound before the TXP for the upcoming reworks, but it needs to happen before the PV are bound so that the code to set the possible_crtcs field works properly on the TXP. Move it right between the two devices. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/2d7fcde29dec429442eb76afc51d8cc275cb407f.1591882579.git-series.maxime@cerno.tech
2020-07-07drm/vc4: Convert register accessors to FIELD_*Maxime Ripard1-5/+4
The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to use the FIELD_* macros. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-02drm/vc4: Use __drm_atomic_helper_crtc_resetDaniel Vetter1-2/+1
Now also comes with the added benefit of doing a drm_crtc_vblank_off(), which means vblank state isn't ill-defined and fail-y at driver load before the first modeset on each crtc. Reviewed-by: Maxime Ripard <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-10drm/vc4: crtc: Restrict HACT_ACT setup to DSIMaxime Ripard1-1/+2
The HACT_ACT field only needs to be written to when using a DSI display. Let's move that setup to our DSI branch to clear a bit the common path. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7a93436f97666a2aa025686ef3ff3606de4bec67.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: crtc: Turn static const variable into a defineMaxime Ripard1-3/+4
The hvs_latency_pix variable doesn't need to be a variable and can just be defined. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8535c679f79af8abaa1b7796261bfeda11f874fd.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: crtc: Move crtc state to common headerMaxime Ripard2-21/+21
We'll need to access the crtc_state from outside of vc4_crtc.c, so let's move it to vc4_drv.h Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1e6e563f9c75961e2885c9d648a3130d3b46b6d1.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: crtc: Switch to of_device_get_match_dataMaxime Ripard1-5/+5
of_device_get_match_data allow to simplify a bit the retrieval of the data associated to the pixelvalve compatible. Let's use it. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1ff06413a1350d28bc3e88b034ed7ad23834e5bd.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: crtc: Rename SoC data structuresMaxime Ripard1-6/+6
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 targeting. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/39aed7dd512ce2a4560902974ec26b16b88ec68b.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: plane: Move additional planes creation to driverMaxime Ripard4-17/+19
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, and make the planes associated to all CRTCs. 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. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0b85a3fdb20bb4ff85fb62cabd082d5a65e2730b.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: plane: Move planes creation to its own functionMaxime Ripard3-29/+44
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. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a378ea56214179f1f25fcd36ecc69511edd1e790.1590594512.git-series.maxime@cerno.tech
2020-06-10drm/vc4: drv: Add include guardsMaxime Ripard1-0/+4
vc4_drv.h doesn't have any include guards which prevents it from being included twice. Let's add them. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/68e89e315c4c35b313efc277c9642eca684e0ade.1590594512.git-series.maxime@cerno.tech
2020-05-25drm/vc4: hdmi: Silence pixel clock error on -EPROBE_DEFERJames Hilliard1-2/+4
If the vc4 hdmi driver loads before the pixel clock is available we see a spurious "*ERROR* Failed to get pixel clock" error. Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-19drm/vc4: remove _unlocked suffix in drm_gem_object_put_unlockedEmil Velikov4-17/+17
Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not know (or need to) about the horror stories involving struct_mutex. Just drop the suffix. It makes the API cleaner. Done via the following script: __from=drm_gem_object_put_unlocked __to=drm_gem_object_put for __file in $(git grep --name-only $__from); do sed -i "s/$__from/$__to/g" $__file; done Cc: Eric Anholt <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-17Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-4/+16
Backmerging required to pull topic/phy-compliance. Signed-off-by: Thomas Zimmermann <[email protected]>
2020-04-02drm/vc4: Use simple encoderThomas Zimmermann4-37/+11
The vc4 driver uses empty implementations for its encoders. Replace the code with the generic simple encoder. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-27drm/vc4: Fix HDMI mode validationNicolas Saenz Julienne1-4/+16
Current mode validation impedes setting up some video modes which should be supported otherwise. Namely 1920x1200@60Hz. Fix this by lowering the minimum HDMI state machine clock to pixel clock ratio allowed. Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.") Reported-by: Stefan Wahren <[email protected]> Suggested-by: Dave Stevenson <[email protected]> Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.