HVS Core Clock Request Fix #4402
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 1c38342.
This was referenced Jun 21, 2021
|
@maxime: what does 'kmstest --flip' and what is the full command line for testing it? |
|
(Wrong @ mripard, not maxime)
See the dri-devel discussion. https://github.com/tomba/kmsxx/tree/master/utils |
|
And that builds and seems to run |
|
hmm ... not a Linux pro here, so something is missing |
|
|
|
Thanks for the hint, but NOPE! Edit: btw I'm on 6by9's MAREK DSI8x branch |
|
@aBUGSworstnightmare-rpi this isn't the place to debug build issues of an unrelated package. Google for error then apt install the package referenced. If still stuck use the forum. Tested and it fixes I don't think we want the hvs tracker enabled, as it is far too pessimistic about what is possible (e.g. here 1920x1200 RGBA32 + 4K P30 video is rejected). |
|
You can reproduce failure with modetest: |
|
Changes fix the issue manifesting in greeters (tested with sddm) but as @popcornmix pointed out, the changes break kodi playback. |
…_crtc_state" This reverts commit 040d0dd.
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
The load tracker was initially designed to report and warn about a load too high for the HVS. To do so, it computes for each plane the impact it's going to have on the HVS, and will warn (if it's enabled) if we go over what the hardware can process. While the limits being used are a bit irrelevant to the BCM2711, the algorithm to compute the HVS load will be one component used in order to compute the core clock rate on the BCM2711. Let's remove the hooks to prevent the load tracker to do its computation, but since we don't have the same limits, don't check them against them, and prevent the debugfs file to enable it from being created. Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]>
mripard
force-pushed
the
rpi/5.10-core-clock-request-fix
branch
from
3d4ce3c
to
953532f
Compare
|
I just pushed a new version that should address the Kodi (and modetest) issue |
|
@mripard - I built this patched on the latest rpi-5.10.y commit and confirm |
|
|
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Jun 23, 2021
See: raspberrypi/linux#4402 kernel: DPI mode 6 18bpp support See: raspberrypi/linux#4400 firmware: bcm_host: Recognise all Pi 4 variants, add BCM2711 See: raspberrypi/userland#695
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
Jun 23, 2021
See: raspberrypi/linux#4402 kernel: DPI mode 6 18bpp support See: raspberrypi/linux#4400 firmware: bcm_host: Recognise all Pi 4 variants, add BCM2711 See: raspberrypi/userland#695
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
Here's a fix for the breakage introduced by #4365. This significantly reworks the current code to drop the new, buggy, accessors and use the load tracker infrastructure that was already in place.
I haven't tested kmstest --flip yet, but the other issues seem to be gone.