DRM fixes on 6.6 #5824
DRM fixes on 6.6 #5824
Conversation
The frame count values moved within registers DISPSTAT1 and DISPSTAT2 with GEN5, so update the accessor function to accommodate that. Fixes: b51cd7a ("drm/vc4: hvs: Fix frame count register readout") Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
|
This PR introduced a regression. I have a Pi5 driving a 7" 800x480 panel through a TFP401 on one of the HDMI ports. Prior to this PR the display works fine. After this PR, the display works fine until reaching the GUI, and then it goes blank. I do not see anything unusual in the logs. Through a process of bisecting the commits in this repository, I identified this PR as the culprit. |
|
Can you confirm which of the commits is responsible (neither looks obviously suspicious). |
|
I'm sorry, but I'm not sure how to do that conveniently. I'm using |
|
Using Note that this commit is against 6.6, whereas most PRs until recently will be 6.1. Can you provide the EDID for your display please? |
|
Here's the EDID: I'm sorry, but I don't quite follow what you're suggesting. After running |
|
As covered in https://github.com/raspberrypi/rpi-update?tab=readme-ov-file#options If you're not wanting to update the bootloader, prefix the command with The EDID looks a little odd. According to edid-decode, [email protected] with timing parameters of Negative timing properties sounds like an error to me. Pulling the DTD apart using https://en.wikipedia.org/wiki/Extended_display_identification_data#Detailed_Timing_Descriptor So it is defining negative back porches. DRM analyses the mode as And is therefore discarding it. |
|
Here's the timing from the LCD's datasheet: That is transferred to the EDID as: It appears the EDID parsing algorithm does not consider the "Horizontal/Vertical Line" field. Is that right, or am I missing something?
I added |
|
I see now that front_porch + blanking + active_area equals one horizontal/vertical line. It also appears the Image Size and Border fields are not used in the computation. So working backwards from the EDID parsing algorithm you posted, I modified the EDID as...
Logs show: .. which appears to not show any errors, but the screen still remains blank after trying to display the desktop.
... but nothing is displayed on the screen. |
|
I also tried this EDID in an attempt to satisfy the datasheet and the EDID parsing algorithm... |
|
The latest commit at https://github.com/raspberrypi/rpi-firmware/commits/master, "kernel: Bump to 6.1.74" works fine. I'm now working through the commits at https://github.com/raspberrypi/rpi-firmware/commits/next, but I hit the GitHub rate limit. I'll continue tomorrow. |
|
Pi4 all along has had a restriction on odd values in the horizontal timings due to running at 2pixels/clock, but that should be enforce on 6.1 as well as 6.6 Also double check your display datasheet - many quote a blank period that is sync + back porch, whereas DRM wants them independently. I think this is the case in your datasheet where thb is sync + back porch and must be 46 clocks, but the sync pulse (thpw) must be 1 to 40 of those clock cycles. Are you feeding your EDID editor with data in the right format? |
|
The specific commit in the "Next" branch that introduced this symptom is raspberrypi/rpi-firmware@7fa525a, "Bump to kernel 6.6.5", apparently the first v6.6 commit. |
Thanks, that is indeed how the data is presented in this LCD's datasheet. From that, and the algorithm you posted earlier, I was able to create a working EDID by using a high This is what ultimately worked.
... which matches the datasheet pretty well. Still, what changed? Now I wonder if I need a different EDID for v6.1 and v6.6. I think I'll just avoid 6.1 and hope things remain stable going forward. |
|
(Sorry, I had missed you'd said PI5, so my comment on odd timings is irrelevant). Your old EDID was invalid, so I suspect the core EDID parsing code has just been updated and now rejects it. d78c4ef looks like a likely candidate. A valid EDID should work fine under 6.1 or 6.6. |
|
Note that your timings still don't match your display's datasheet. Hsync + Hback should add up to It's often difficult to tell, but potentially you'd have a 1 pixel shift, as the start of the image data would be read as 46 clocks from the start of the sync signal, and you've put the active data at 47 clocks later. It all depends on exactly how the TFP401 translates the HDMI timing into the signals for the panel. Use of Using even horizontal timings will make the mode work on the Pi4 too. |
The debugfs fix could be split into 3 patches to fix the 3 commits that added each function, but that hardly seems worth it. It will obviously get fixed when looking to merge into mainline.
Other patch hopefully resolves #5674.