[Letux-kernel] DSI panels with omapdrm on 4.20-rc

[H. Nikolaus Schaller]

Hi Tomi,

> Am 19.12.2018 um 10:30 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
> 
> On 18/12/18 20:09, H. Nikolaus Schaller wrote:
> 
>>> Comparing it to the (mostly) working kernel, I found out that the bus
>>> flags are again broken. I attached a quick hack patch that seems to fix
>>> them, and with that I get a working 400x400 plane, but underflows with
>>> full-screen plane.
>>> 
>>> I couldn't quite figure out how to fix the bus-flags correctly, though.
>> 
>> Hm. For me this patch does not make a difference.
>> 
>> But I think we are close to a solution.
> 
> Ok... Well, the VC stuff works ok for me, as far as I see.
> 
> I pushed my hacky test branch to:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
> 4.20/omap5-video-dsi-test
> 
> It has one additional fix "fix dsi depopulate", which is needed if you
> want to unload modules.

It seems as if that one already makes the difference!

Well, we

modprobe -r omapdrm
modprobe -r drm_kms_helper

and then reload the modules with different rotation parameter.

> 
> The panel r63311 driver probes fine, and can read something via DSI (I
> get a proper reply for MIPI_DCS_GET_PIXEL_FORMAT), and everything seems
> to be ok.

Good!

Unfortunately I think I have no working r63311 setup any more since
we switched to a different panel in the Pyra project.

> 
> The only problem with my branch are FIFO underflows. Apparently these
> were present on older kernels too, and is probably somehow related to
> horizontal blanking. 1080x1920 plane causes underflows, but 1000x1920
> does not.

I haven't seen that but it might be that if horizontal blanking is
too short, it might not be enough to send long DCS commands.

> 
> Maybe you can compare your driver to the r63311 driver in my branch
> (although the r63311 driver is a total mess =).

Yes, it is... Anyways, it works which is a good starting point for optimizations :)

I have compared drivers and only found that I try to set dssdev->driver
to a private structure. And there was a spurious omapdss_device_disconnect()
in the remove() function. But both do not seem to be critical.

Maybe I should clean up my driver (remove some bells and whistles) and submit
it upstream as soon as the Pyra is being mass produced and shipped. Then we
would have a good reference implementation and hardware to test for future
regressions.

So in summary I have added these patches not yet in v4.20-rc7 (plus the panel driver):

b2b80dbeff3a fix dsi depopulate
2ef5e09c79d9 drm/omap: hackfix dsi bus flags
b8aedc2b8295 drm/omap: fix crash in DSI debug dumps
5cceb44e03e3 drm/omap: add support for manually updated displays
87dfb765c3be drm/omap: add framedone interrupt support
50f581c97fbe drm/omap: fix incorrect union usage
977e0c2e641f drm/omap: don't check dispc timings for DSI
f62952e37eae drm/omap: use DRM_DEBUG_DRIVER instead of CORE

Do you plan to get these fixes already into v4.20.0?

BR and thanks,
Nikolaus