| Message ID | cover.1729240989.git.geert+renesas@glider.be (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: renesas: white-hawk: Add mini-DP output support | expand |
On Fri, Oct 18, 2024 at 11:32 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> - fbtest test002 crashes with SEGV in 2560x1440.
This is a bug in fbtest: 32-bit arithmetic no longer flies for drawing
ellipses on very large displays...
Gr{oetje,eeting}s,
Geert
Hi, On 18/10/2024 12:32, Geert Uytterhoeven wrote: > Hi all, > > As I had to test Tomi's WIP patches to add mini-DP output support to > Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board > farm, and thought this was a good opportunity to test mini-DP output on > White Hawk as a baseline (CN5), and add support for the second mini-DP > output on the White Hawk BreakOut board (CN15). > > For testing, I used the following hardware: > (A) BenQ BL2420PT desktop display (2560x1440), > (B) Joy-It Joy-View 15 portable display (1920x1080), > (C) Lindy DisplayPort to 2 Port HDMI MST Hub, > (D) Passive mini-DP to HDMI cable, > (E) LogiLink Mini DisplayPort to VGA Converter. > > (A)-(C) are known to work with my Intel desktop. > (D)-(E) are known to work with an old Dell XPS13. > > Software-wise, I used the frame buffer text console, "modetest -M > rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s > 86:2560x1440@XR24", and fbtest. > > White Hawk CN5 > -------------- > > 0. General: > - Hotplug detect does not work, switching display needs a reboot, Right. It's an eDP chip, and the driver seems to be made to really only support eDP. I'm not so familiar with the HW that I could say if DP HPD can be properly implemented or not (I've seen eDP chips that have had issues there...), but with a quick test one can do: rwmem --i2c=1:0x2c -s8 -S8 0x5c:0=0 to enable the HPD, and then it seems to work. However, the driver doesn't support interrupts and uses DRM's polling, so it takes a while for the framework to notice the disconnect. But if you run a command that does a display probe, say "kmsprint" from kms++, it'll update the status right away. So, as far as I can see, without actually properly looking at it, it should be doable to improve the sn65dsi86 driver to support HPD too. > - fbtest test002 crashes with SEGV in 2560x1440. > > 1. Mini-DP to (A) DP: > - 2560x1440 works but flickers (flickering shifts image > horizontally; perhaps a cable issue, as 2 below does work?) I get a stable picture with my old-ish Dell monitor: # kmstest Connector 0/@86: DP-1 Crtc 0/@83: 2560x1440@59.95 241.500 2560/48/32/80/+ 1440/3/5/33/- 60 (59.95) P|D Plane 0/@33: 0,0-2560x1440 Fb 97 2560x1440-XR24 press enter to exit > - 1920x1080 is stable > > 2. Mini-DP to (C) to (A) HDMI: > - 2560x1440 OK > - 1920x1080 OK > > 3. Mini-DP to (C) to (B) mini-HDMI: > - 1920x1080 OK > > 4. Mini-DP to (C) to (A) HDMI + (B) mini-HDMI: > - 1920x1080 mirrored OK > > 5. Mini-DP to (E) to (A) HDMI: > - SN65DSI86 behaves as if no cable is connected. > Expected, as TI SN65DSI86 does not support Dual-Mode/DP++. > > 6. Mini-DP to (D) to (A) VGA: > - Detected 1920x1080, black screen / no signal. > Perhaps this adapter relies on DP++, too? Hmm, are these two mixed up? 5. should have (D), and 6 should have (E)? No, the vga is an active one, but does it have external power source? If not, it relies on the power from the DP connector, and I'm not sure if we're providing any/enough. Tomi > > > White Hawk CN15 > --------------- > > Does not work: > - Display resolution is detected correctly (1920x1080 or 2560x1440), > - Black screen, displays say no signal detected, > - "modetest -M rcar-du -s 88:1920x1080@XR24" triggers: > > rcar-mipi-dsi fed90000.dsi-encoder: Failed to disable video transmission > vsp1 fea20000.vsp: Underrun occurred at WPF0 (total underruns 2) > > Note that fea20000.vsp is vspd0, not vspd1. I do have a few similar > messages for fea28000.vsp in my logs, so this may be a red herring. > > Thanks for your comments! > > Geert Uytterhoeven (1): > arm64: dts: renesas: white-hawk: Add mini-DP output support > > .../boot/dts/renesas/r8a779g0-white-hawk.dts | 90 +++++++++++++++++++ > 1 file changed, 90 insertions(+) >
Hi Tomi, On Tue, Nov 26, 2024 at 4:58 PM Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> wrote: > On 18/10/2024 12:32, Geert Uytterhoeven wrote: > > As I had to test Tomi's WIP patches to add mini-DP output support to > > Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board > > farm, and thought this was a good opportunity to test mini-DP output on > > White Hawk as a baseline (CN5), and add support for the second mini-DP > > output on the White Hawk BreakOut board (CN15). > > > > For testing, I used the following hardware: > > (A) BenQ BL2420PT desktop display (2560x1440), > > (B) Joy-It Joy-View 15 portable display (1920x1080), > > (C) Lindy DisplayPort to 2 Port HDMI MST Hub, > > (D) Passive mini-DP to HDMI cable, > > (E) LogiLink Mini DisplayPort to VGA Converter. > > > > (A)-(C) are known to work with my Intel desktop. > > (D)-(E) are known to work with an old Dell XPS13. > > > > Software-wise, I used the frame buffer text console, "modetest -M > > rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s > > 86:2560x1440@XR24", and fbtest. > > > > White Hawk CN5 > > -------------- > > 1. Mini-DP to (A) DP: > > - 2560x1440 works but flickers (flickering shifts image > > horizontally; perhaps a cable issue, as 2 below does work?) > > I get a stable picture with my old-ish Dell monitor: > > # kmstest > Connector 0/@86: DP-1 > Crtc 0/@83: 2560x1440@59.95 241.500 2560/48/32/80/+ 1440/3/5/33/- 60 > (59.95) P|D > Plane 0/@33: 0,0-2560x1440 > Fb 97 2560x1440-XR24 > press enter to exit Good to know! I'll see if I can try with a different cable (the current one claims to do 8K, though). > > 5. Mini-DP to (E) to (A) HDMI: > > - SN65DSI86 behaves as if no cable is connected. > > Expected, as TI SN65DSI86 does not support Dual-Mode/DP++. > > > > 6. Mini-DP to (D) to (A) VGA: > > - Detected 1920x1080, black screen / no signal. > > Perhaps this adapter relies on DP++, too? > > Hmm, are these two mixed up? 5. should have (D), and 6 should have (E)? Yes they are. Sorry for that. > No, the vga is an active one, but does it have external power source? If > not, it relies on the power from the DP connector, and I'm not sure if > we're providing any/enough. The VGA adapter does not have an external power source. Gr{oetje,eeting}s, Geert
Hi, On 18/10/2024 12:32, Geert Uytterhoeven wrote: > White Hawk CN15 > --------------- > > Does not work: > - Display resolution is detected correctly (1920x1080 or 2560x1440), > - Black screen, displays say no signal detected, > - "modetest -M rcar-du -s 88:1920x1080@XR24" triggers: > > rcar-mipi-dsi fed90000.dsi-encoder: Failed to disable video transmission > vsp1 fea20000.vsp: Underrun occurred at WPF0 (total underruns 2) > > Note that fea20000.vsp is vspd0, not vspd1. I do have a few similar > messages for fea28000.vsp in my logs, so this may be a red herring. I had a try with this. The first issue I hit was that ti-sn65dsi86 driver doesn't work if there are two sn65dsi86 devices: Creating aux devices try to create sysfs files with the same names for both devices, thus failing. I take you didn't see this? I brute forced my way through that by doing "aux->id = s_foo++;" in ti_sn65dsi86_add_aux_device(). After that, I was in the same situation as you, black screen. The ti-sn65dsi86 does detect the monitor, though, and reads the edid just fine, so I think it unlikely that the issue is on ti-sn65dsi86 side. I'm not sure if the second DSI output has ever been tested, maybe the issue is around there. I did not see the errors you saw. Random underflows are know to happen, though, but it's odd if you see them for the display path that's (supposedly) not in use... The fps looks fine, so the pclk and timings are probably ok: kmstest -c1 --flip Connector 1/@88: DP-2 Crtc 1/@84: 2560x1440@59.95 241.500 2560/48/32/80/+ 1440/3/5/33/- 60 (59.95) P|D Plane 5/@58: 0,0-2560x1440 Fb 99 2560x1440-XR24 press enter to exit Connector 1: fps 60.02, slowest 17.16 ms Connector 1: fps 59.99, slowest 16.69 ms Connector 1: fps 59.99, slowest 16.82 ms Connector 1: fps 60.00, slowest 16.82 ms Tomi
Hi Tomi, On Wed, Nov 27, 2024 at 10:28 AM Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> wrote: > On 18/10/2024 12:32, Geert Uytterhoeven wrote: > > > White Hawk CN15 > > --------------- > > > > Does not work: > > - Display resolution is detected correctly (1920x1080 or 2560x1440), > > - Black screen, displays say no signal detected, > > - "modetest -M rcar-du -s 88:1920x1080@XR24" triggers: > > > > rcar-mipi-dsi fed90000.dsi-encoder: Failed to disable video transmission > > vsp1 fea20000.vsp: Underrun occurred at WPF0 (total underruns 2) > > > > Note that fea20000.vsp is vspd0, not vspd1. I do have a few similar > > messages for fea28000.vsp in my logs, so this may be a red herring. > > I had a try with this. The first issue I hit was that ti-sn65dsi86 > driver doesn't work if there are two sn65dsi86 devices: Creating aux > devices try to create sysfs files with the same names for both devices, > thus failing. I take you didn't see this? I did, cfr. my comment in [PATCH/RFC 1/1][2]: This has a hard dependency on "[PATCH] drm/bridge: ti-sn65dsi86: Fix multiple instances"[1] > I brute forced my way through that by doing "aux->id = s_foo++;" in > ti_sn65dsi86_add_aux_device(). > > After that, I was in the same situation as you, black screen. The > ti-sn65dsi86 does detect the monitor, though, and reads the edid just > fine, so I think it unlikely that the issue is on ti-sn65dsi86 side. I'm > not sure if the second DSI output has ever been tested, maybe the issue > is around there. > > I did not see the errors you saw. Random underflows are know to happen, > though, but it's odd if you see them for the display path that's > (supposedly) not in use... > > The fps looks fine, so the pclk and timings are probably ok: Thanks! So it probably is an issue with the routing in the DU or DSI driver... [1] https://lore.kernel.org/8c2df6a903f87d4932586b25f1d3bd548fe8e6d1.1729180470.git.geert+renesas@glider.be/ [2] https://lore.kernel.org/all/05e43f61321b4191d5f97dec2349facd4b56c899.1729240989.git.geert+renesas@glider.be/ Gr{oetje,eeting}s, Geert
On Fri, Oct 18, 2024 at 11:32 AM Geert Uytterhoeven <geert+renesas@glider.be> wrote: > As I had to test Tomi's WIP patches to add mini-DP output support to > Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board > farm, and thought this was a good opportunity to test mini-DP output on > White Hawk as a baseline (CN5), and add support for the second mini-DP > output on the White Hawk BreakOut board (CN15). > > For testing, I used the following hardware: > (A) BenQ BL2420PT desktop display (2560x1440), > (B) Joy-It Joy-View 15 portable display (1920x1080), > (C) Lindy DisplayPort to 2 Port HDMI MST Hub, > (D) Passive mini-DP to HDMI cable, > (E) LogiLink Mini DisplayPort to VGA Converter. > > (A)-(C) are known to work with my Intel desktop. > (D)-(E) are known to work with an old Dell XPS13. > > Software-wise, I used the frame buffer text console, "modetest -M > rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s > 86:2560x1440@XR24", and fbtest. > > White Hawk CN5 > -------------- > > 1. Mini-DP to (A) DP: > - 2560x1440 works but flickers (flickering shifts image > horizontally; perhaps a cable issue, as 2 below does work?) > - 1920x1080 is stable While I don't have a second Mini-DP-to-DP-M cable, I tried a few other combos (now on Gray Hawk Single): 7. (D) + HDMI-F-F adapter + passive HDMI-F-to-DP-cable to (A) DP, 8. Mini-DP-to-DP-F cable (=X) + plain DP cable (=Y) to (A) DP, unfortunately with the same results. Note that (X) is the same cable as used in scenario 2 below, and (Y) works fine with my Intel desktop. However, the maximum cable length for eDP seems to be 30 cm, so that may explain why 2 below is the only wiring that works at 2560x1440 (despite cable (X) being 1m, i.e. still too long)? > 2. Mini-DP to (C) to (A) HDMI: > - 2560x1440 OK > - 1920x1080 OK Gr{oetje,eeting}s, Geert
On 02/12/2024 17:49, Geert Uytterhoeven wrote: > On Fri, Oct 18, 2024 at 11:32 AM Geert Uytterhoeven > <geert+renesas@glider.be> wrote: >> As I had to test Tomi's WIP patches to add mini-DP output support to >> Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board >> farm, and thought this was a good opportunity to test mini-DP output on >> White Hawk as a baseline (CN5), and add support for the second mini-DP >> output on the White Hawk BreakOut board (CN15). >> >> For testing, I used the following hardware: >> (A) BenQ BL2420PT desktop display (2560x1440), >> (B) Joy-It Joy-View 15 portable display (1920x1080), >> (C) Lindy DisplayPort to 2 Port HDMI MST Hub, >> (D) Passive mini-DP to HDMI cable, >> (E) LogiLink Mini DisplayPort to VGA Converter. >> >> (A)-(C) are known to work with my Intel desktop. >> (D)-(E) are known to work with an old Dell XPS13. >> >> Software-wise, I used the frame buffer text console, "modetest -M >> rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s >> 86:2560x1440@XR24", and fbtest. >> >> White Hawk CN5 >> -------------- >> >> 1. Mini-DP to (A) DP: >> - 2560x1440 works but flickers (flickering shifts image >> horizontally; perhaps a cable issue, as 2 below does work?) >> - 1920x1080 is stable > > While I don't have a second Mini-DP-to-DP-M cable, I tried a few > other combos (now on Gray Hawk Single): > 7. (D) + HDMI-F-F adapter + passive HDMI-F-to-DP-cable to (A) DP, D is passive DP->HDMI, it won't work. Are you saying it works, and the result matches the test case 1.? > 8. Mini-DP-to-DP-F cable (=X) + plain DP cable (=Y) to (A) DP, > unfortunately with the same results. Note that (X) is the same cable "same results" means same as in 1.? > as used in scenario 2 below, and (Y) works fine with my Intel desktop. > > However, the maximum cable length for eDP seems to be 30 cm, so that Where did you read that? I don't think there's such a thing as "eDP cable". In laptops etc. eDP is connected to the panel via custom made cables, and the cable design affects how long it can be. eDP and DP are identical wrt. signaling, so using a DP cable with eDP or DP should behave the same. That said, I don't think the eDP->DP connector designs we see in these development boards are really made to match what one would expect from a consumer device with a DP output. > may explain why 2 below is the only wiring that works at 2560x1440 > (despite cable (X) being 1m, i.e. still too long)? > >> 2. Mini-DP to (C) to (A) HDMI: >> - 2560x1440 OK >> - 1920x1080 OK My guess is that this works, because there's an active component there which decodes the DP input and re-encodes it to HDMI output, probably with different timings (read, more standard). So the (C) is more tolerant on not-so-standard DP input than (A) is. The eDP chip is limited in its capabilities, e.g. back porch registers are 8-bit, so they max out at 255. While those are checked in the driver, I wouldn't be surprised if some other limitations are not (the driver has clearly been written for eDP panels). You could try different custom timings with kmstest, to find if there's something obvious that makes the case 1. work. For example, if the issue is indeed the cable, probably lowering the pixel clock would fix it. So using the same timings but dropping the pclk in half might get a stable picture (then again, lowering pclk might fix many other kinds of issues too...). Can you send your monitor's edid blob? I don't have a board up here, but it should be available from somewhere in sysfs. On my desktop it's: /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2/edid Tomi
Hi Tomi, On Tue, Dec 3, 2024 at 8:33 AM Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> wrote: > On 02/12/2024 17:49, Geert Uytterhoeven wrote: > > On Fri, Oct 18, 2024 at 11:32 AM Geert Uytterhoeven > > <geert+renesas@glider.be> wrote: > >> As I had to test Tomi's WIP patches to add mini-DP output support to > >> Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board > >> farm, and thought this was a good opportunity to test mini-DP output on > >> White Hawk as a baseline (CN5), and add support for the second mini-DP > >> output on the White Hawk BreakOut board (CN15). > >> > >> For testing, I used the following hardware: > >> (A) BenQ BL2420PT desktop display (2560x1440), > >> (B) Joy-It Joy-View 15 portable display (1920x1080), > >> (C) Lindy DisplayPort to 2 Port HDMI MST Hub, > >> (D) Passive mini-DP to HDMI cable, > >> (E) LogiLink Mini DisplayPort to VGA Converter. > >> > >> (A)-(C) are known to work with my Intel desktop. > >> (D)-(E) are known to work with an old Dell XPS13. > >> > >> Software-wise, I used the frame buffer text console, "modetest -M > >> rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s > >> 86:2560x1440@XR24", and fbtest. > >> > >> White Hawk CN5 > >> -------------- > >> > >> 1. Mini-DP to (A) DP: > >> - 2560x1440 works but flickers (flickering shifts image > >> horizontally; perhaps a cable issue, as 2 below does work?) > >> - 1920x1080 is stable > > > > While I don't have a second Mini-DP-to-DP-M cable, I tried a few > > other combos (now on Gray Hawk Single): > > 7. (D) + HDMI-F-F adapter + passive HDMI-F-to-DP-cable to (A) DP, > > D is passive DP->HDMI, it won't work. Are you saying it works, and the > result matches the test case 1.? It doesn't. I had hoped combining the two passive adapters would provide a valid galvanical DP conduit... > > > 8. Mini-DP-to-DP-F cable (=X) + plain DP cable (=Y) to (A) DP, > > unfortunately with the same results. Note that (X) is the same cable > > "same results" means same as in 1.? Oops, IIRC both 7 and 8 didn't work at all (monitor not detected). > > as used in scenario 2 below, and (Y) works fine with my Intel desktop. > > > > However, the maximum cable length for eDP seems to be 30 cm, so that > > Where did you read that? I don't think there's such a thing as "eDP https://www.lv-tron.com/edp-made-simple-quick-start-guide-with-experts-tips/ > cable". In laptops etc. eDP is connected to the panel via custom made > cables, and the cable design affects how long it can be. eDP and DP are i.e. an eDP cable ;-) > identical wrt. signaling, so using a DP cable with eDP or DP should > behave the same. > > That said, I don't think the eDP->DP connector designs we see in these > development boards are really made to match what one would expect from a > consumer device with a DP output. Indeed. And using a (too) long cable probably breaks this. > > may explain why 2 below is the only wiring that works at 2560x1440 > > (despite cable (X) being 1m, i.e. still too long)? > > > >> 2. Mini-DP to (C) to (A) HDMI: > >> - 2560x1440 OK > >> - 1920x1080 OK > > My guess is that this works, because there's an active component there > which decodes the DP input and re-encodes it to HDMI output, probably > with different timings (read, more standard). So the (C) is more > tolerant on not-so-standard DP input than (A) is. Yes, it has an active component, and a shorter cable. > The eDP chip is limited in its capabilities, e.g. back porch registers > are 8-bit, so they max out at 255. While those are checked in the > driver, I wouldn't be surprised if some other limitations are not (the > driver has clearly been written for eDP panels). > > You could try different custom timings with kmstest, to find if there's > something obvious that makes the case 1. work. For example, if the issue > is indeed the cable, probably lowering the pixel clock would fix it. So > using the same timings but dropping the pclk in half might get a stable > picture (then again, lowering pclk might fix many other kinds of issues > too...). The modes reported by modetest differ slightly between (1) and (2). (1) contains one additional 1920x1080 mode, but all other modes are the same. > Can you send your monitor's edid blob? I don't have a board up here, but > it should be available from somewhere in sysfs. On my desktop it's: > > /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2/edid And in the modetest output. I'll send these by PM. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi all, As I had to test Tomi's WIP patches to add mini-DP output support to Gray Hawk Single, I moved my (old and new) DisplayPort gear to my board farm, and thought this was a good opportunity to test mini-DP output on White Hawk as a baseline (CN5), and add support for the second mini-DP output on the White Hawk BreakOut board (CN15). For testing, I used the following hardware: (A) BenQ BL2420PT desktop display (2560x1440), (B) Joy-It Joy-View 15 portable display (1920x1080), (C) Lindy DisplayPort to 2 Port HDMI MST Hub, (D) Passive mini-DP to HDMI cable, (E) LogiLink Mini DisplayPort to VGA Converter. (A)-(C) are known to work with my Intel desktop. (D)-(E) are known to work with an old Dell XPS13. Software-wise, I used the frame buffer text console, "modetest -M rcar-du -s 86:1920x1080@XR24" or "modetest -M rcar-du -s 86:2560x1440@XR24", and fbtest. White Hawk CN5 -------------- 0. General: - Hotplug detect does not work, switching display needs a reboot, - fbtest test002 crashes with SEGV in 2560x1440. 1. Mini-DP to (A) DP: - 2560x1440 works but flickers (flickering shifts image horizontally; perhaps a cable issue, as 2 below does work?) - 1920x1080 is stable 2. Mini-DP to (C) to (A) HDMI: - 2560x1440 OK - 1920x1080 OK 3. Mini-DP to (C) to (B) mini-HDMI: - 1920x1080 OK 4. Mini-DP to (C) to (A) HDMI + (B) mini-HDMI: - 1920x1080 mirrored OK 5. Mini-DP to (E) to (A) HDMI: - SN65DSI86 behaves as if no cable is connected. Expected, as TI SN65DSI86 does not support Dual-Mode/DP++. 6. Mini-DP to (D) to (A) VGA: - Detected 1920x1080, black screen / no signal. Perhaps this adapter relies on DP++, too? White Hawk CN15 --------------- Does not work: - Display resolution is detected correctly (1920x1080 or 2560x1440), - Black screen, displays say no signal detected, - "modetest -M rcar-du -s 88:1920x1080@XR24" triggers: rcar-mipi-dsi fed90000.dsi-encoder: Failed to disable video transmission vsp1 fea20000.vsp: Underrun occurred at WPF0 (total underruns 2) Note that fea20000.vsp is vspd0, not vspd1. I do have a few similar messages for fea28000.vsp in my logs, so this may be a red herring. Thanks for your comments! Geert Uytterhoeven (1): arm64: dts: renesas: white-hawk: Add mini-DP output support .../boot/dts/renesas/r8a779g0-white-hawk.dts | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+)