Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add video related patches to Rockchip64-legacy kernel. #2650

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@dpapavas
Copy link

@dpapavas dpapavas commented Feb 21, 2021

Description

These patches were lifted from the Rockchip port of libreelec 9.2, specifically from this and this file. My main aim was to get HDR output working with the RK3399 Legacy Media Framework, of which more details can be found in the discussion here.

I'm fairly sure (although I haven't tested it) that I could get HDR output working by applying a single patch, but as the Armbian kernel seemed to suffer from other problems, compared to the kernel in the libreelec image (most prominently, it was unable to connect via HDMI at 3840x2160@60 9 times out of 10), I decided to pick any video-related patches that seemed desirable (and hadn't been applied already), based on the commit message and cursory perusal of the code.

Most of these are fixes and should therefore be desirable in a general-purpose kernel. Some may not be though, so please let me know if you'd like me to remove some of them and retest the result. The ones I have my doubts about are listed below:

[PATCH] gpu/arm/mali400: default to performance gpu governor
[PATCH] gpu/arm/midgard: default to performance gpu governor
[PATCH] drm: bridge: dw-hdmi: default to underscan mode
[PATCH] bump PD voltage & current for board without charge IC

The patch filenames are probably not very good; please advise on whether you'd like me to bundle all patches in a single file and what good filenames would be.

How Has This Been Tested?

I've tested this on my Rock Pi 4B board, which I mostly use with KODI for media playback. I've been using the patched kernel for about a week now and have noticed no adverse effects, either crashes etc., or suspicious kernel messages (that weren't there before). On the other hand, I can now connect in 3840x2160@60 every time, the display is properly switched to HDR mode and I think a crash in the VOP driver may also have been fixed (I say "think" because this happened rarely before, and resulted in video mode switching being impossible until reboot).

@teacupx
Copy link
Contributor

@teacupx teacupx commented Feb 22, 2021

I see many patches in areas that are working perfectly now. I would rather apply the principle "if it is not broken, then don't fix it". For example, GPU devfreq was having problems in the past, but we fixed them (I don't remember exactly how). I see no need to apply patches there. Same with the clk-pll driver, it can have undesired effects and should not be touched unless we know exactly what we are doing.

So I would say, just stick with the patches that fix the HDR output, and leave the others for the future.

@dpapavas If eventually you test and observe that some of the other patches gives some clear feature or performance improvement, then we can make a different PR for it.

@150balbes
Copy link
Contributor

@150balbes 150balbes commented Feb 23, 2021

I would rather apply the principle "if it is not broken, then don't fix it"

I agree with this approach. The Legacy core is a temporary solution that is only used until the media script for the main core is released (LE already has everything you need for HW on the main core). So adding new patches to the Legacy core is not a big priority for me. If such patches are needed for other users, I will try to check them, so that they do not break the current work (but additional time is needed for checking).

@dpapavas
Copy link
Author

@dpapavas dpapavas commented Feb 27, 2021

I would rather apply the principle "if it is not broken, then don't fix it".

I fully understand and agree with the principle. Nevertheless, some things are broken apart from HDR output, as I explained in my post above. The issue which prevents establishing an HDMI link at 3840x2160@60 can be frustrating, as this will be the default on displays supporting it. In such cases you're only left with the option of removing and reinserting the cable until a connection is established. I have reason to believe others are having issues with this (see opening remarks in my first post in the thread linked in my previous message), so I think this should be fixed as well.

I'm not sure how serious the VOP crash will be in practice, as I'm not sure how often it will happen, but when it does happen, it seems you'll need to reboot for further mode switches, so this might be serious too.

I will try to determine the specific patches that fix the HDR and 60Hz issues, as these are easy to test (i.e. don't require waiting for an arbitrary amount of time, to see whether a crash will occur). If I do so, would you prefer that I submit these as separate patches in different PRs, or in a single file in this PR?

@teacupx
Copy link
Contributor

@teacupx teacupx commented Feb 27, 2021

would you prefer that I submit these as separate patches in different PRs, or in a single file in this PR?

I think both can be grouped in a single patch, since both relate to HDMI problems. Something along the lines of "hdmi_out_fixes" or alike. Patch list for rockchip64-legacy is already long enough, so we don't want it to get unnecessarily longer :)

@150balbes
Copy link
Contributor

@150balbes 150balbes commented Feb 28, 2021

I added your patch and built a Buster-legacy image with it. I checked the work, it seems that I did not find any problems from adding the patch (I test on 1080p TV).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants