[meta-xilinx] ZU+ mali with simple panel

[Laurent Pinchart]

Hi Jean-François,

On Friday 12 May 2017 09:02:38 Jean-Francois Dagenais wrote:
> Hi all! (Bonjour Laurent!;)
> 
> Preface: This is the first time I dive into display/DRM drivers, read:
> display-newbie.
> 
> Does anyone have any pointers for a reference design of the MALI being used
> on a simple fixed resolution panel? I don't need to get the MALI working
> just yet, but I don't want to wander too far since I do need to make it
> work in a few weeks. In fact, if it's more straight forward to do it using
> MALI first, that's what I'll want to do.

Is this MALI as in the ARM GPU or the MALI Processor (MALI-DP) ?

> We currently have our display hooked up in our PL design using the Avnet
> ALI3 display kit IP components and the axi-vdma engine. We confirmed it was
> working using a standalone vivado created project which generates a color
> stripe pattern in DDR.
> 
> I have not finished my analysis on how to make the display work under linux.
> I was thinking about using xlnx,drm as a start, but already I'm having
> doubts as our scenario is so much simpler since all of the "pipeline"
> (video timing, encoder, connector) are fixed in PL and un-configurable,
> only the vdma is visible from the driver code.
> 
> Could tinydrm (from latest upstream) help simplify things here?

There are two layers of helpers for simple devices, drm_simple_kms_helper and 
tinydrm. The former is used by the mxsfb driver and by the tinydrm helper, and 
the later by the mi0283qt driver only. Given the very low number of users the 
helpers APIs might lack the flexibility you need. It would be worth having a 
look at them, but you might need to modify them slightly.

> Since our setup looks so simple, I'm hoping not to have to write code but
> just devicetree bindings. Am I dreaming?

I'm afraid you are :-) There are DT bindings for a "simple framebuffer" device 
that requires no configuration at all (basically representing a display engine 
that has been configured by the boot loader and is already running), with a 
corresponding fbdev driver, but no DRM/KMS driver. Furthermore, in your case, 
you need to configure at least the VDMA engine, so this isn't applicable.

You need a driver, and I wouldn't recommend going for the deprecated fbdev API 
(be aware, though, that support for DRM/KMS in Qt might be limited, I haven't 
checked the latest status). If you PL architecture is similar to the Xilinx 
DRM architecture, you could reuse their driver, possibly with modifications to 
support a simpler PL implementation. However, if your PL architecture is 
custom, at this time you'll need to write your own driver.

> Here are a few relevant points:
> * Ultimately, the only thing that needs to drive the display is Qt in eglfs
> or the like. (QML based app)
> * console is not really required but would be nice
> * We will require DP to work over the USB-C connection in our final released
> product
> 
> Cheers! And thanks in advance!

-- 
Regards,

Laurent Pinchart