Hi Tomi,
Am 23.05.2017 um 11:19 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 22/05/17 18:23, H. Nikolaus Schaller wrote:
Hi Tomi,
Am 22.05.2017 um 08:31 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
On 20/05/17 14:30, H. Nikolaus Schaller wrote:
Hi Tomi,
after rebasing our Letux kernel to 4.12-rc1 our DSI panel stopped initializing. DRM and X11 are up and running, but the panel fails to initialize and show anything.
We have not touched the code of our btl507212-w677l DSI driver.
Is there anything to consider on panel driver side?
What I can't 100% exclude is that we have additional hacks in the omapdss system which may now be in conflict. For example we have your "[PATCH] dispc hackfix" or "dss: remove export of venc modes".
Can you try reverting 7d267f068a8b4944d52e8b0ae4c8fcc1c1c5c5ba
Yes, a revert makes it working again!
The interesting question is why it makes such a difference...
Are there additional dividers which depend on M and N? For example the DSI LP clock? This could explain why a DPI panel (GTA04) simply works as before and there is only a DSI communication problem during DSI panel initialization.
I digged up my omap5 uevm, which has the dsi panel you sent me long time back. After forward porting the related patches, for some reason, I'm getting dispc underflows with it (after I revert the patch above). But I still get a semi-valid picture, and can do page flips at ~60fps.
After applying the patch, fps drops into half. I don't see anything wrong with the PLL calcs. I was doing testing with some other dividers, and, well... results vary. Changing the fint_min to 0.5MHz in dsi.c makes it work, but lower limits show different problems. TRM has conflicting limits for the PLL's internal frequencies, so I don't know the correct limits.
I'll look at this a bit more when I find time.
Ok, no problem. Take the time it needs to fix.
For the moment we can live with the revert-hack.
BR and thanks, Nikolaus