[U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions

[Anatolij Gustschin]

Hi Igor,

On Mon, 27 May 2019 08:21:17 +0300
Igor Opaniuk igor.opaniuk at gmail.com wrote:

> Hi everyone,
> 
> I've finally started looking into the cfb_console.c driver and it's
> conversion to DM_VIDEO after our initial discussion [1].

This initial discussion was only about DM_VIDEO support for mxsfb
driver, we don't need to convert cfb_console.c. With DM_VIDEO
cfb_console is obsolete and the basic functionality (text/bitmap output
on video frame buffer) is replaced by video console uclass driver,
drivers/video/vidconsole-uclass.c.

> Unfortunately I've a bit underestimated the amount of effort that
> should be done, as mxsfb.c in the Linux mainline obviously pulls the
> whole core fb subsystem
> (drivers/video/fbdev/core), which can take a while and frankly I doubt
> that this is a proper way to do things here.

Yes, we should not port the Linux code from drivers/video/fbdev/core,
we don't need it in U-Boot.

> Taking into account that the deadline for DM_VIDEO conversion is
> 2019.07, it's unlikely that we will manage to do the full conversions
> this cfb_console driver and all dependent hw specific drivers in a
> proper way (where we can provide information about videomodes as
> properties in a proper nodes in DT).

Speaking only about mxsfb, it shouldn't be too difficult to
convert the existing U-Boot driver, even if we decide to extend
it to support video mode description in DT.

We already have some converted drivers using existing code for reading
video modes from DT (grep for ofnode_decode_display_timing() or
fdtdec_decode_display_timing()). E.g. see commits 9dc89a053d and
d63ec26a49 for atmel_lcdfb.c driver.

> Currently the init chain for fb stuff in U-boot (on the other hand, in
> the Linux, hw specific driver is probed initially, then they trigger
> fb common routines that are needed from `video/fbdev/core`):
> stdio_add_devices() -> ./common/stdio.c -> drv_video_init ()
> (drivers/cfb_console.c) - > video_hw_init (particular hw backend,
> which was statically linked at compile time with a proper
> video_hw_init() implementation, for example look into mxsfb.c)

With DM_VIDEO the framebuffer/videoconsole probing and init will only
happen when there is a display user, e.g. when the board starts to
output text or bitmap on the video console (stdio_probe_device()
for UCLASS_VIDEO ID in common/stdio.c or bmp_display()).

> 2 ways of conversion that come to my mind:
> 1. Start with simple DM wrappers in cfb_console.c, and introduce dumb
> DT nodes so the device at least can be probed. All video configuration
> will be stored the same way as before in the U-boot env (for example,
> "videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0\0").
> Then, step by step, driver by driver, we can move some properties to
> DT and try to sync Linux/U-boot video DT nodes (at least avoid
> divergence of tree nodes, so Linux/U-boot video-related DT nodes
> conform to each other). Yes, this is kind of dirty workaround, but at
> least this something we can start with, and with minimal amount of
> intrusive changes.

No, please don't use cfb_console at all.

> 2. Perform full conversion, where everything works the same way as in
> Linux kernel. Initially I thought that it could be the proper way to
> go, but taking into account all differences in the implementation of
> fb in U-boot/Linux (even the way how the drivers are initialized), I
> think we will just end up pulling the whole big piece from the Linux
> kernel, that will definitely take a while (especially further support
> of this code base, testing/fixing issues etc.).

No, we should not pull Linux fbdev code, we already have basic
video console code and can use it (probably with some extensions for
not yet supported combinations of frame buffer color depth and bitmap
color depth, when needed).

...
> Drivers, that don't imply CFG_CONSOLE, but are used alongside with
> cfb_console.c (kind of particular hw backend driver for fb console):
> * mxsfb.c
> * mb862xx.c
> * sunxi_display.c
> * ati_radeon_fb.c
> * fsl_dcu_fb.c
> * omap3_dss.c
> * da8xx-fb.c

I think that we will remove CFB_CONSOLE driver when the backend drivers
above are ported to use DM_VIDEO code.

> Looking forward to your suggestions/recommendations here (and let me
> know if I missed something), thanks!

I'd suggest to look at the existing already converted code or to inspect
in tree commits moving drivers to DM_VIDEO. For 2019.07 release we can
add extended mxsfb driver with DM_VIDEO support still using timing
info from videomode environment.  When you want to extend the mxsfb driver
to read the display timings from DT, see e.g. 6d9a98c583 and f182209190.

Also make sure to add "u-boot,dm-pre-reloc" properties in the device
tree node for lcdif controller and in its parent node. Otherwise the
allocation of frame buffer memory in video uclass driver won't work.

Thanks,

--
Anatolij