image corruption with high-res modes on DP

Dongle used: Dell DBQAUBC064

Reproduced using no-name DP '4k@60' dongle. native DP, same image using another DP dongle by Hama.

changed the description

I recall getting very similar diagonal line corruption on DSI devices when playing with planes of differing size with modetest, but only on the first (few?) frames.

Will try to repro and note if it looks the same (right line and all).

Even though likely unrelated, I do want to follow up on my "promise to repro". First up, are the diagonal colored lines a valid test pattern? If yes, then there is no corruption and this is probably expected.

Second, if I use atomic modesetting, the SMPTE color bars appear as expected:

modetest -M msm -P33@81:1440x2880 -s 32:#0-60 -a

However, if using the same command without atomic modeset, the SMPTE color bars appear very briefly before switching to the diagonal lines:

modetest -M msm -P33@81:1440x2880 -s 32:#0-60

Again, this is probably completely unrelated to the corruption you're seeing (which is specifically about the bar on the right-hand side of the screen on DP), so this little thread should just be collapsed and ignored.

One more thing to note: when I reported DSC-like corruption in #42, there is also this strange bar on the right, where colors remain identical horizontally.

For the reference, I could not reproduce this with the writeback using 4096x2160 and 3840x2160 modes.

I was able to find a 4k mode that doesn't have such issue:

./tests/modetest/modetest -s 32:3840,3888,3920,4000,2160,2163,2168,2191-30

Using modetest with custom modes I was able to find that the issue is caused by the vtotal part of the mode. Consider the following images which capture the rightmost part of modetest with vtotal set to 2225, 2230, 2232 an finally 2235:

vtotal	img
2225
2230
2232
2235

Hi Dmitry,

Would you mind sharing your kernel config file (.config). I got SM8350-HDK device and try to duplicate your problem. Thanks,

Hi @lumag

Does https://git.codelinaro.org/dmitry.baryshkov/linux/-/commits/test-dp-rpm?ref_type=heads have all the changes to make DP work with SM8350HDK?

@quic_khsieh cannot get basic DP to work with this branch.

If this is not the right one, can you pls suggest an alternate?

Thanks

Abhinav

DisplayPort works on SM8350-HDK since v6.5, no patches necessary.

@lumag Yeah I thought so too but hes not getting HPD with type C at all with your tree. I am doubting if pmic glink is working right on sm8350HDK. Did you have any changes on top of defconfig to make this work?

Also, I am assuming that you did not change the on-device DIP switches and are using HDMI out along with type C out?

So far, we had DSI panel switch settings as we were mostly using it to validate DSI cmd mode.

Thanks

Abhinav

I did not care about the defconfig, so I can not advise you here.

Yes, my board is setup for the HDMI. The only DIP switches turned to on are DSI0_SW and DSI1_SW

@lumag , in that case please attach your config as kuogee requested.

Thanks for confirming the DIP switches.

I do understand that developers can work with different configs but while reporting bugs I will probably request and make it mandatory to share the config which was tested otherwise QC spends a lot of time actually making the setup rather than the issue itself.

Thanks

Abhinav

Sure, here is my .config

Hi Dmitry, I tested 4k at my chromebook herobrine device. I try both 32:3840-2160 and 32:3840-2160-30 and can not duplicate you problem.

#0 3840x2160 29.98 3840 3888 3920 4000 2160 2163 2168 2191 262750 flags: phsync, nvsync; type: preferred, driver #1 3840x2160 30.00 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver

My setup is chroem book <--> apple typec dongle (can support 8,1G link rate) <--> hdmi cable <--> dell 4k monitor

I attached a path which support 8.1Gbit link rate. Would you apply this patch to see it can fix your problem or not (sorry, dp is not work at my sm8350-hdk with linux-next branc0001-kuogee-add-8.1Gbits-link-rate-support.patch.

I will try this patch later today. Meanwhile, could you please try the modes that I posted earlier with HBR3 being disabled? The latest modetest supports specifying custom mode timings.

Also, what kind of issue do you have with the 8350-hdk? Could you please send me a dmesg and/or issue description?

Hi Dmitry,

Thanks for help. I've tried booting with the .config you shared earlier, but am still not seeing the DP hotplug. Here's the full boot log: sm8350-dp-rpm.txt

I'm using the following command line arguments: root=PARTLABEL=super console=tty0 console=ttyMSM0,115200n8 fw_devlink=off ignore_loglevel clk_ignore_unused pd_ignore_unused copy_modules --

While I do have root and copy_modules set, I'm using the qemu arm64 initramfs.

I used your test-dp-rpm tree and cherry-picked the parked RCG series on top of that.

I've also set the HDK to use HDMI and connected it to both HDMI and DP over USBC simultaneously (which is why the above log has modetest outputting HDMI as connected).

Can you let me know if there are any deltas between our setups that might be causing the DP hotplug to not send?

Thanks,

Jessica Zhang

@jesszhan , How do you expect for the PMIC glink to function if there is no adsp firmware? Please start the remoteproc properly and you are going to have all the DP HPD events.

For the reference, you can use meta-qcom to build the initramfs-firmware-sm8350-hdk-image, then you can just concat both cpio.gz files to form the final ramdisk to be passed to mkbootimg.

Hi Dmitry,

Thanks for the pointers. I tried loading the adsp firmware but I'm still seeing nothing from the DP hotplug. Here are the updated logs: sm8350-dp-with-fw

I was able to obtain the *.mbn files for adsp, cdsp, slpi, and modem so I loaded them using CONFIG_EXTRA_FIRMWARE. Not sure if that could've caused some issue with DP hotplug. I also tried booting with HDMI plugged in to address the Cannot find any crtc or sizes errors, but got the same results.

Are there any other setup steps that I'm missing?

Thanks,

Jessica Zhang

Maybe you have a missing jsn file. Could you please use the existing and tested way of providing firmware instead of hacking it through CONFIG_EXTRA_FIRMWARE?

iirc the json is parsed by userspace, so CONFIG_EXTRA_FIRMWARE won't work

Hi @lumag,

Do you have a initramfs you use for sm8350 which has the adsp firmware?

If so, can you pls share yours and we will use that to get us unblocked on this issue.

We have not used OE environment so far as it was not part of our workflow. We need to have a sync up on this with you and the linaro team as half the time its mostly a question of using the correct initramfs as different members are using a different initramfs while we are mostly relying what has been provided on the snapshots. So we have to align somewhere based on our common needs.

Thanks

Abhinav

I understand the problems. However please note, that unlike dragonboards and RB[1235] boards we do not have a firmware set licensed for redistribution. So unlike e.g. RB5 we can not put the initramfs anywhere.

Of course this also causes issues on our side too. Historically we have tried different approaches. Mounting modem_a and system_a. Manually creating zip files with the firmware files. I ended up with the OE recipes which repack NON-HLOS.bin (for DSP firmware) and proprietary.tar.gz (as that seems to be the only way to get Adreno ZAP shader and SQE, where required) into initramfs-firmware-board-image.cpio.gz. Then this image can be concatenated with your typical initramfs-test-image.cpio.gz or any other firmware image.

The management on both sides is aware of this issue, but your vote to get Lantronix to follow Thundercomm Robotics boards might also help.

Thanks for the feedback. Yes, I will discuss this with our mgmt as well.

Abhinav

My chrome book (Linux 6.6-rc2) with link rate=540000 lane=2

I run below test casew with different vtotal, I still can not duplicate screen corruption issue.

/usr/bin/modetest -M msm -s 32:3840,4016,4104,4400,2160,2168,2178,2250-30 /usr/bin/modetest -M msm -s 32:3840,4016,4104,4400,2160,2168,2178,2225-30 /usr/bin/modetest -M msm -s 32:3840,4016,4104,4400,2160,2168,2178,2230-30 /usr/bin/modetest -M msm -s 32:3840,4016,4104,4400,2160,2168,2178,2232-30

we will try run those test cases at sm8550-mtp later.

Hi @lumag

Can you please help to check if https://patchwork.freedesktop.org/patch/603355/ is resolving this issue on your side?

From my validation, it is fixing the corruption seen with 4K modes.

I will add the fixes and closes tags once confirmed by you.

Thanks

Abhinav

is this something we should backport to CrOS kernel?

@robclark , yes we should have widebus enabled by default for DP . I will add the Fixes tag and repost it

@abhinavk I will try doing that tomorrow. But please note that i was able to reproduce the issue on RB5 (sm8250), which rules out the wide bus case.

@lumag, there is no native DP support on sm8250.

That uses a DSI to HDMI bridge. Not sure if you have any local changes to enable DP on it.

So that has to be a different issue for sure.

I will wait for your test result on sm8350 first.

Thanks

Abhinav

RB5 definitely supports native DisplayPort.

@lumag , I checked more. sm8250 and sm8350 use the same DP compatible. I didnt notice sm8250 in the list in dp_display.c so mistakenly thought DP is not enabled yet on RB5.

                   mdss_dp: displayport-controller@ae90000 {
                            compatible = "qcom,sm8250-dp", "qcom,sm8350-dp";

So widebus was disabled on that too. Why do you think its still ruled out?

Hmm, it uses sc7180 config. Let me really check that tomorrow. Unfortunately at this point I don't have a working DP on the sdm845, I will try getting that to work during the weekend.

Sure. On my sm8350 HDK, I no longer see this vertical bar issue with the patch. Will wait for your result because the pictures on this issue slightly differ from the vertical bar I see but that could also be a monitor to monitor difference. Thats why I didnt mark the "Closes" tag yet.

modetest tiles with widebus

modetest tiles without widebus

modetest bars with widebus

modetest bars without widebus

I have attached the images of the modetest patterns on my monitor with SM8350HDK with and without widebus

Thanks

Abhinav

@abhinavk I have tested the patch on RB5, SM8350 HDK and SM8450 HDK. On all three boards I see the vertical stripe even with the patch applied.

@lumag , I ran some more tests on my setup. I do still see the issue on some modes with widebus, on some issue does get fixed with it:

3840x2160 30.00 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver (issue is seen without widebus but not with it)

3840x2160 29.97 3840 4016 4104 4400 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver (issue is seen even with widebus)

3840x2160 25.00 3840 4896 4984 5280 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver (issue is seen without widebus but not with it)

3840x2160 24.00 3840 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver (issue is seen without widebus but not with it)

3840x2160 23.98 3840 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver (issue is seen even with widebus)

So it seems like with fractional fps, issue is still not resolved with widebus. Are you seeing the same behavior OR for you it still happens even with any of the above modes?

Thanks

Abhinav

@lumag if you are seeing the issue even for non-fractional fps, can you pls share me one more devcoredump with widebus enabled on the resolution you are testing?

Thanks

Abhinav

closed

mentioned in commit nouveau@db33bf43

mentioned in commit nouveau@86d7701f

mentioned in commit nouveau@4a2798cc

mentioned in commit b0abcd65

image corruption with high-res modes on DP

Designs

Child items ...

Activity

Admin message

Admin message

image corruption with high-res modes on DP

Activity