Hi Igor,

On Mon, 27 May 2019 08:21:17 +0300 Igor Opaniuk igor.opaniuk@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