add txw700071s0 dsi panel

[berkutta]

No description provided.

[pelwell]

Here are some things you'll need to fix before we accept your change:

1. Use TABs, not spaces in your indentation, except for the README file.
2. You'll need a README entry for the overlay - copy the style of the others, including indent levels and two blank lines between entries.
3. Entries in the README and Makefile should be in alphabetical order.
4. The final submission should be split into 2 commits - 1 for C code, and 1 for the overlay. If there were defconfig changes, that would go in a third commit.

[6by9]

It would have been useful for you to have put in the PR description that I had asked you to create this for test purposes in https://forums.raspberrypi.com/viewtopic.php?t=389125

I'll give it a whirl against the analyser now.

[6by9]

Tested against the analyser. Images are fine.

Timings are reported as:

• link freq of 500Msps.
• horizontally line time 12.57us, Hactive 800. Hsync 16 pixels / 0.26us. HBP 0.96usc (Reading the registers it is 145/20/80)
• vertically: Vactive 1280. VFP 16 Vsync 7. VBP 25. 1328 lines total.
• D-PHY is only dropping to LP-11 at the end of the line with VSync End (which is signaled instead of the HSync Start for that line)

You can use kmstest to try out any random timings with a crtc. eg
kmstest -c 2 -r 83333000,800/145/20/80/+,1380/16/8/24/+
would use the fixed up timings for vc4 based on your panel's mode.
I'd try tweaking those horizontal timings to see if you can avoid the wrapping. As long as the total remains the same, then the frame timing will be correct.

[6by9]

Having looked again at your image from the forum post, please test with kmstest rather than the desktop. The desktop could have rendering errors in what is presented to the display pipeline.

kmstest should have a square box in each corner (top left is solid, the others are hollow). Ensure those are rendered correctly.

[berkutta]

Ok, I have tested with kmstest now. The modified kmstest parameters seem to introduce a vertical problem in addition to the horizontal wrap.
Anything else I can try?

---

Unchanged CM4 with kmstest, wrapping present the same as in desktop:

$ kmstest
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 78.086 800/80/20/80/? 1280/16/8/24/? 60 (60.00) P|D 
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

---

Your kmstest parameters:

$ kmstest -c 2 -r 83333000,800/145/20/80/+,1380/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 83.333 800/145/20/80/+ 1380/16/8/24/+ 0 (55.84)  
  Plane 2/@79: 0,0-800x1380
    Fb 723 800x1380-XR24
press enter to exit

---

Unchanged CM5 with kmstest, display working fine:

$ kmstest
Connector 0/@36: DSI-2
  Crtc 0/@34: [email protected] 78.086 800/80/20/80/? 1280/16/8/24/? 60 (60.00) P|D 
  Plane 0/@32: 0,0-800x1280
    Fb 39 800x1280-XR24
press enter to exit

[6by9]

Typo (by me) in the height is why you're getting 55.84Hz and a vertical change. 1280, not 1380.
kmstest -c 2 -r 83333000,800/145/20/80/+,1280/16/8/24/+
That's unlikely to change the wrapping issue though.

I don't have the display, but try kmstest -c 2 -r 83333000,800/125/40/80/+,1280/16/8/24/+ or other adjustments of those horizontal timings (not the 800 of course!) to see what the display wants.

[berkutta]

Wasn't able to improve it with changing HFP/HBP/HSA.
But changing pclk fixed it! Does this tell anything?

Wrap present:

$ kmstest -c 2 -r 83333000,800/80/20/80/+,1280/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 83.333 800/80/20/80/+ 1280/16/8/24/+ 0 (64.03)  
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

Wrap gone, display content fine:

$ kmstest -c 2 -r 73333000,800/80/20/80/+,1280/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 73.333 800/80/20/80/+ 1280/16/8/24/+ 0 (56.35)  
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

[berkutta]

Addition
This one is bad:

$ kmstest -c 2 -r 76000000,800/80/20/80/+,1280/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 76.000 800/80/20/80/+ 1280/16/8/24/+ 0 (58.40)  
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

This one is good:

$ kmstest -c 2 -r 75000000,800/80/20/80/+,1280/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 75.000 800/80/20/80/+ 1280/16/8/24/+ 0 (57.63)  
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

[6by9]

You've not changed the DSI clock.
Please read the "Panel timings" section of https://pip.raspberrypi.com/categories/685-app-notes-guides-whitepapers/documents/RP-003472-WP/Using-a-DSI-display.pdf and vc4_dsi_bridge_mode_fixup (BCM2711 actually has a 3GHz parent clock, but it is still an integer divider).

The fixup has just extended the HFP from 174 at 76MHz to 188 at 75MHz. You have dropped your frame rate in changing the nominal pixel clock though.
kmstest -c 2 -r 83333000,800/188/20/80/+,1280/16/8/24/+ should give you exactly the same result. You can dump the timing registers with sudo cat /sys/kernel/debug/dri/1/crtc1_regs and compare the PV_HORZA and PV_HORZB registers to verify.

Most likely you can reduce the HBP of 80 to compensate and bring the frame rate back to 60Hz.
Don't forget to validate the settings with CM5.

[berkutta]

Nice, this one seems to work fine on CM4 and is above 60Hz. Need to test it also on CM5, good point.

Is this safe to use like that, or is it recommended to confirm this with the display manufacturer first?
Is there a particular reason there is the need to change the parameters for CM4, but CM5 works with the display manufacturer parameters?

$ kmstest -c 2 -r 83333000,800/190/20/30/+,1280/16/8/24/+
Connector 2/@47: DSI-1
  Crtc 2/@90: [email protected] 83.333 800/190/20/30/+ 1280/16/8/24/+ 0 (60.34)  
  Plane 2/@79: 0,0-800x1280
    Fb 723 800x1280-XR24
press enter to exit

[6by9]

Is this safe to use like that, or is it recommended to confirm this with the display manufacturer first? Is there a particular reason there is the need to change the parameters for CM4, but CM5 works with the display manufacturer parameters?

Covered (briefly) in that white paper / source code comment.

DSI on BCM2711 is fed from a 3GHz clock via an integer only divider. It can therefore only get:

• 3GHz
• 1.5GHz
• 1GHz
• 750MHz
• 600MHz
• 500MHz
• 428.5MHz
• 375MHz
  etc

DSI supports what is called burst mode where the DSI clock is run faster (often max possible) to send the data as quickly as possible, and then drop the link into a low power mode (remember that the interface was designed for mobile devices, so power saving is essential).
The vc4 driver is effectively making use of that mechanism, although it only chooses the next frequency up rather than max, and adjusts the timings to keep the line time (and hence frame rate) the same.

RP1 has a dedicated PLL per DSI block, so it can produce the link frequency requested. If the timings are those proven to work on CM4, then they should always be good for CM5.

As to whether you need to check with the display manufacturer, it depends if they're actually helpful.
Section 18.4.9. Timing for DSI video mode of my ILI9881 datasheet shows it supporting burst mode, but then has TBD for all the parameters.
A native DSI panel largely doesn't need to care about the actual FP/SYNC/BP timings as the image data is all packetised. They need to note VSync Start or End to reset to the first line of the display, but that's probably about it.