summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4/vc4_crtc.c
AgeCommit message (Collapse)AuthorFilesLines
2022-06-09drm/vc4: hvs: Fix frame count register readoutMaxime Ripard1-1/+1
[ Upstream commit b51cd7ad143d2eb31a6df81c2183128920e47c2b ] In order to get the field currently being output, the driver has been using the display FIFO frame count in the HVS, reading a 6-bit field at the offset 12 in the DISPSTATx register. While that field is indeed at that location for the FIFO 1 and 2, the one for the FIFO0 is actually in the DISPSTAT1 register, at the offset 18. Fixes: e538092cb15c ("drm/vc4: Enable precise vblank timestamping for interlaced modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20220331143744.777652-3-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-17drm/vc4: crtc: Fix runtime_pm reference countingMaxime Ripard1-3/+5
At boot on the BCM2711, if the HDMI controllers are running, the CRTC driver will disable itself and its associated HDMI controller to work around a hardware bug that would leave some pixels stuck in a FIFO. In order to avoid that issue, we need to run some operations in lockstep between the CRTC and HDMI controller, and we need to make sure the HDMI controller will be powered properly. However, since we haven't enabled it through KMS, the runtime_pm state is off at this point so we need to make sure the device is powered through pm_runtime_resume_and_get, and once the operations are complete, we call pm_runtime_put. However, the HDMI controller will do that itself in its post_crtc_powerdown, which means we'll end up calling pm_runtime_put for a single pm_runtime_get, throwing the reference counting off. Let's remove the pm_runtime_put call in the CRTC code in order to have the proper counting. Fixes: bca10db67bda ("drm/vc4: crtc: Make sure the HDMI controller is powered when disabling") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203102003.1114673-1-maxime@cerno.tech
2022-02-07drm/vc4: crtc: Fix redundant variable assignmentMaxime Ripard1-1/+0
The variable is assigned twice to the same value. Let's drop one. Reported-by: kernel test robot <yujie.liu@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220203151151.1270461-1-maxime@cerno.tech
2021-11-05drm/vc4: crtc: Copy assigned channel to the CRTCMaxime Ripard1-2/+2
Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, and the previous commits removed them all but the HVS channel a CRTC has been assigned. Let's move this channel in struct vc4_crtc at atomic_begin() time, drop it from our private state structure, and remove our use of crtc->state from our vblank handler entirely. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-4-maxime@cerno.tech Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: Fix non-blocking commit getting stuck foreverMaxime Ripard1-1/+4
In some situation, we can end up being stuck on a non-blocking that went through properly. The situation that seems to trigger it reliably is to first start a non-blocking commit, and then right after, and before we had any vblank interrupt), start a blocking commit. This will lead to the first commit workqueue to be scheduled, setup the display, while the second commit is waiting for the first one to be completed. The vblank interrupt will then be raised, vc4_crtc_handle_vblank() will run and will compare the active dlist in the HVS channel to the one associated with the crtc->state. However, at that point, the second commit is waiting using drm_atomic_helper_wait_for_dependencies that occurs after drm_atomic_helper_swap_state has been called, so crtc->state points to the second commit state. vc4_crtc_handle_vblank() will compare the two dlist addresses and since they don't match will ignore the interrupt. The vblank event will never be reported, and the first and second commit will wait for the first commit completion until they timeout. The underlying reason is that it was never safe to do so. Indeed, accessing the ->state pointer access synchronization is based on ownership guarantees that can only occur within the functions and hooks defined as part of the KMS framework, and obviously the irq handler isn't one of them. The rework to move to generic helpers only uncovered the underlying issue. However, since the code path between drm_atomic_helper_wait_for_dependencies() and drm_atomic_helper_wait_for_vblanks() is serialised and we can't get two commits in that path at the same time, we can work around this issue by setting a variable associated to struct drm_crtc to the dlist we expect, and then using it from the vc4_crtc_handle_vblank() function. Since that state is shared with the modesetting path, we also need to introduce a spinlock to protect the code shared between the interrupt handler and the modesetting path, protecting only our new variable for now. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-3-maxime@cerno.tech Fixes: 56d1fe0979dc ("drm/vc4: Make pageflip completion handling more robust.") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: crtc: Drop feed_txp from stateMaxime Ripard1-2/+1
Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, the first one being whether or not the downstream controller of the pixelvalve is our writeback controller. Fortunately for us, Since commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") this is no longer something that can change from one commit to the other and is hardcoded. Let's set this flag in struct vc4_crtc if we happen to be the TXP, and drop the flag from our private state structure. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-2-maxime@cerno.tech Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-04drm/vc4: Increase the core clock based on HVS loadMaxime Ripard1-0/+15
Depending on a given HVS output (HVS to PixelValves) and input (planes attached to a channel) load, the HVS needs for the core clock to be raised above its boot time default. Failing to do so will result in a vblank timeout and a stalled display pipeline. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-11-maxime@cerno.tech
2021-11-04drm/vc4: crtc: Add some loggingMaxime Ripard1-0/+6
The encoder retrieval code has been a source of bugs and glitches in the past and the crtc <-> encoder association been wrong in a number of different ways. Add some logging to quickly spot issues if they occur. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-7-maxime@cerno.tech
2021-11-04drm/vc4: crtc: Rework the encoder retrieval code (again)Maxime Ripard1-21/+9
It turns out the encoder retrieval code, in addition to being unnecessarily complicated, has a bug when only the planes and crtcs are affected by a given atomic commit. Indeed, in such a case, either drm_atomic_get_old_connector_state or drm_atomic_get_new_connector_state will return NULL and thus our encoder retrieval code will not match on anything. We can however simplify the code by using drm_for_each_encoder_mask, the drm_crtc_state storing the encoders a given CRTC is connected to directly and without relying on any other state. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-6-maxime@cerno.tech
2021-11-04drm/vc4: crtc: Add encoder to vc4_crtc_config_pv prototypeMaxime Ripard1-4/+3
vc4_crtc_config_pv() retrieves the encoder again, even though its only caller, vc4_crtc_atomic_enable(), already did. Pass the encoder pointer as an argument instead of going through all the connectors to retrieve it again. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-5-maxime@cerno.tech
2021-11-04drm/vc4: Make vc4_crtc_get_encoder publicMaxime Ripard1-4/+4
We'll need that function in vc4_kms to compute the core clock rate requirements. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-4-maxime@cerno.tech
2021-10-25drm/vc4: crtc: Make sure the HDMI controller is powered when disablingMaxime Ripard1-1/+18
Since commit 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time"), during the initial setup of the driver we call into the VC4 HDMI controller hooks to make sure the controller is properly disabled. However, we were never making sure that the device was properly powered while doing so. This never resulted in any (reported) issue in practice, but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn if we access the controller while disabled") we get a loud complaint when we do that kind of access. Let's make sure we have the HDMI controller properly powered while disabling it. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210923185013.826679-1-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Lookup the encoder from the register at bootMaxime Ripard1-4/+34
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a state yet and thus will not be able to figure out which connector is attached to our CRTC. However, we have a muxing bit in the CRTC register we can use to get the encoder currently connected to the pixelvalve. We can thus read that register, lookup the associated register through the vc4_pv_data structure, and then pass it to vc4_crtc_disable so that we can perform the proper operations. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-6-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Fix vc4_get_crtc_encoder logicMaxime Ripard1-5/+16
The vc4_get_crtc_encoder function currently only works when the connector->state->crtc pointer is set, which is only true when the connector is currently enabled. However, we use it as part of the disable path as well, and our lookup will fail in that case, resulting in it returning a null pointer we can't act on. We can access the connector that used to be connected to that crtc though using the old connector state in the disable path. Since we want to support both the enable and disable path, we can support it by passing the state accessor variant as a function pointer, together with the atomic state. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-5-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Pass the drm_atomic_state to config_pvMaxime Ripard1-4/+4
The vc4_crtc_config_pv will need to access the drm_atomic_state structure and its only parent function, vc4_crtc_atomic_enable already has access to it. Let's pass it as a parameter. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-4-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Skip the TXPMaxime Ripard1-0/+3
The vc4_set_crtc_possible_masks is meant to run over all the encoders and then set their possible_crtcs mask to their associated pixelvalve. However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own"), the TXP has been turned to a CRTC and encoder of its own, and while it does indeed register an encoder, it no longer has an associated pixelvalve. The code will thus run over the TXP encoder and set a bogus possible_crtcs mask, overriding the one set in the TXP bind function. In order to fix this, let's skip any virtual encoder. Cc: <stable@vger.kernel.org> # v5.9+ Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-3-maxime@cerno.tech
2021-05-24drm/vc4: Fix clock source for VEC PixelValve on BCM2711Mateusz Kwiatkowski1-1/+1
On the BCM2711 (Raspberry Pi 4), the VEC is actually connected to output 2 of pixelvalve3. NOTE: This contradicts the Broadcom docs, but has been empirically tested and confirmed by Raspberry Pi firmware devs. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210520150344.273900-2-maxime@cerno.tech
2021-04-08drm/vc4: crtc: Reduce PV fifo threshold on hvs4Dom Cobley1-0/+17
Experimentally have found PV on hvs4 reports fifo full error with expected settings and does not with one less This appears as: [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done timed out with bit 10 of PV_STAT set "HVS driving pixels when the PV FIFO is full" Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161328.1471556-3-maxime@cerno.tech
2020-12-16drm/vc4: Pass the atomic state to encoder hooksMaxime Ripard1-8/+10
We'll need to access the connector state in our encoder setup, so let's just pass the whole DRM state to our private encoder hooks. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-3-maxime@cerno.tech
2020-12-16drm/vc4: hvs: Align the HVS atomic hooks to the new APIMaxime Ripard1-4/+2
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the HVS, only the PV/TXP atomic hooks were updated in the previous commits, but it makes sense to update the HVS ones too. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-2-maxime@cerno.tech
2020-12-15drm: automatic legacy gamma supportTomi Valkeinen1-1/+0
To support legacy gamma ioctls the drivers need to set drm_crtc_funcs.gamma_set either to a custom implementation or to drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the latter. We can simplify this by making the core handle it automatically. Move the drm_atomic_helper_legacy_gamma_set() functionality into drm_color_mgmt.c to make drm_mode_gamma_set_ioctl() use drm_crtc_funcs.gamma_set if set or GAMMA_LUT property if not. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211114237.213288-2-tomi.valkeinen@ti.com
2020-12-15drm/vc4: kms: Remove async modeset semaphoreMaxime Ripard1-13/+0
Now that we have proper ordering guaranteed by the previous patch, the semaphore is redundant and can be removed. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201204151138.1739736-7-maxime@cerno.tech
2020-11-03drm: Use the state pointer directly in atomic_checkMaxime Ripard1-1/+1
Now that atomic_check takes the global atomic state as a parameter, we don't need to go through the pointer in the CRTC state. This was done using the following coccinelle script: @ crtc_atomic_func @ identifier helpers; identifier func; @@ static struct drm_crtc_helper_funcs helpers = { ..., .atomic_check = func, ..., }; @@ identifier crtc_atomic_func.func; identifier crtc, state; @@ func(struct drm_crtc *crtc, struct drm_atomic_state *state) { ... - struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc); ... when != crtc_state - crtc_state->state + state ... } @@ struct drm_crtc_state *crtc_state; identifier crtc_atomic_func.func; identifier crtc, state; @@ func(struct drm_crtc *crtc, struct drm_atomic_state *state) { ... - crtc_state->state + state ... } Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201102133834.1176740-3-maxime@cerno.tech
2020-11-02drm/atomic: Pass the full state to CRTC atomic_checkMaxime Ripard1-4/+7
The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Let's start convert all the remaining helpers to provide a consistent interface, starting with the CRTC's atomic_check. The conversion was done using the coccinelle script below, built tested on all the drivers and actually tested on vc4. virtual report @@ struct drm_crtc_helper_funcs *FUNCS; struct drm_crtc *crtc; struct drm_crtc_state *crtc_state; identifier dev, state; identifier ret, f; @@ f(struct drm_device *dev, struct drm_atomic_state *state) { <... - ret = FUNCS->atomic_check(crtc, crtc_state); + ret = FUNCS->atomic_check(crtc, state); ...> } @@ identifier crtc, new_state; @@ struct drm_crtc_helper_funcs { ... - int (*atomic_check)(struct drm_crtc *crtc, struct drm_crtc_state *new_state); + int (*atomic_check)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ static struct drm_crtc_helper_funcs helpers = { ..., .atomic_check = func, ..., }; @ ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { ... when != new_state } @ adds_new_state depends on crtc_atomic_func && !ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; expression E; type T; @@ int func(...) { ... - T state = E; + T crtc_state = E; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; type T; @@ int func(...) { ... - T state; + T crtc_state; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; identifier new_state; identifier crtc; @@ int func(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ); @ include depends on adds_new_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_new_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201028123222.1732139-1-maxime@cerno.tech
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard1-3/+11
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-10-09drm/atomic: Pass the full state to CRTC atomic enable/disableMaxime Ripard1-2/+6
If the CRTC driver ever needs to access the full DRM state, it can't do so at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state will have cleared the pointer from the struct drm_crtc_state to the struct drm_atomic_state before calling those hooks. In order to allow that, let's pass the full DRM state to atomic_enable and atomic_disable. The conversion was done using the coccinelle script below, built tested on all the drivers and actually tested on vc4. virtual report @@ struct drm_crtc_helper_funcs *FUNCS; identifier dev, state; identifier crtc, crtc_state; @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_disable(crtc, crtc_state); + FUNCS->atomic_disable(crtc, state); ...> } @@ struct drm_crtc_helper_funcs *FUNCS; identifier dev, state; identifier crtc, crtc_state; @@ drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_enable(crtc, crtc_state); + FUNCS->atomic_enable(crtc, state); ...> } @@ identifier crtc, old_state; @@ struct drm_crtc_helper_funcs { ... - void (*atomic_enable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_enable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... - void (*atomic_disable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_disable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_crtc_helper_funcs helpers = { ..., .atomic_enable = func, ..., }; | static struct drm_crtc_helper_funcs helpers = { ..., .atomic_disable = func, ..., }; ) @ ignores_old_state @ identifier crtc_atomic_func.func; identifier crtc, old_state; @@ void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { ... when != old_state } @ adds_old_state depends on crtc_atomic_func && !ignores_old_state @ identifier crtc_atomic_func.func; identifier crtc, old_state; @@ void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { + struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc); ... } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; expression E; type T; @@ void func(...) { ... - T state = E; + T crtc_state = E; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; type T; @@ void func(...) { ... - T state; + T crtc_state; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; identifier old_state; identifier crtc; @@ void func(struct drm_crtc *crtc, - struct drm_crtc_state *old_state + struct drm_atomic_state *state ) { ... } @ include depends on adds_old_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_old_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/845aa10ef171fc0ea060495efef142a0c13f7870.1602161031.git-series.maxime@cerno.tech
2020-09-25drm/vc4: crtc: Keep the previously assigned HVS FIFOMaxime Ripard1-0/+1
The HVS FIFOs are currently assigned each time we have an atomic_check for all the enabled CRTCs. However, if we are running multiple outputs in parallel and we happen to disable the first (by index) CRTC, we end up changing the assigned FIFO of the second CRTC without disabling and reenabling the pixelvalve which ends up in a stall and eventually a VBLANK timeout. In order to fix this, we can create a special value for our assigned channel to mark it as disabled, and if our CRTC already had an assigned channel in its previous state, we keep on using it. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-2-maxime@cerno.tech
2020-09-25drm/vc4: crtc: Rework a bit the CRTC state codeMaxime Ripard1-3/+10
The current CRTC state reset hook in vc4 allocates a vc4_crtc_state structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state embeds drm_crtc_state as its first member, and therefore can be safely cast. However, this is pretty fragile especially since there's no check for this in place, and we're going to need to access vc4_crtc_state member at reset so this looks like a good occasion to make it more robust. Fixes: 6d6e50039187 ("drm/vc4: Allocate the right amount of space for boot-time CRTC state.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-1-maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add BCM2711 pixelvalvesMaxime Ripard1-2/+93
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> 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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/2553ec9ece0d8a0e5299ff74ed932a38703c5db9.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: drv: Disable the CRTC at boot timeMaxime Ripard1-0/+25
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 <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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/ad57f1bdeae7a99631713b0fc193c86f223de042.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the CRTC disable outMaxime Ripard1-12/+22
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 <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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/5288fb72ed2da643085dce1bc7f6d6f656bf176e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Clear the PixelValve FIFO during configurationMaxime Ripard1-1/+1
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 <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/ccd6269ba37b2f849ba6e62471c99bd93a4548a0.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Clear the PixelValve FIFO on disableMaxime Ripard1-2/+1
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 <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/26fe48b09d77088679ed0c8cb8cf0db2f108195e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add a delay after disabling the PixelValve outputMaxime Ripard1-0/+18
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 <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/15cf215bd2ceebd203c4010c09c21a4019c650ed.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: encoder: Add finer-grained encoder callbacksMaxime Ripard1-0/+19
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 <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/1dd78efe8f29add73c97d0148cfd4ec8e34aaf22.1599120059.git-series.maxime@cerno.tech
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 <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/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 <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/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 <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/f86c7a6946f98262f1cf59a461596a796d4bcc5f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the HVS gamma LUT setup to our init functionMaxime Ripard1-2/+0
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 <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/d439da8f1592a450a6ad35ab1f9e77def17c7965.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 <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/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 <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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/fb31003a9eee02c4b949556299ff41f0a113499a.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Disable color management for HVS5Maxime Ripard1-6/+11
The HVS5 uses different color matrices. Disable color management support for now. 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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/e528e2edf0a1be3930196d437e548114dd9fcf59.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HDMI encoder type to HDMI0Maxime Ripard1-1/+1
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> 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: Eric Anholt <eric@anholt.net> 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 <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: Eric Anholt <eric@anholt.net> 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 Ripard1-3/+17
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> 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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/7df3549c1bea9b0a27c784dc416bb9a831e4e18f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Assign output to channel automaticallyMaxime Ripard1-4/+8
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> 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/f9aba3814ef37156ff36f310118cdd3954dd3dc5.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 <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/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 <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/439c589baec72ddb89159857a2d078fdd77b02a2.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HVS channel to outputMaxime Ripard1-4/+4
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> 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/b7618bb17b1c435c5d6ce50bcde2fe9243281d02.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the cob allocation outside of bindMaxime Ripard1-18/+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 <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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/484cbd4b00cfeee425295df438222258cc39a3dd.1599120059.git-series.maxime@cerno.tech
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-19 00:44:37 +0300