Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On Tue, 28 May 2019 at 11:33, Igor Opaniuk wrote: > > On Mon, May 27, 2019 at 5:58 PM Tom Rini wrote: > > > > On Mon, May 27, 2019 at 09:22:05AM +0200, Stefan Agner wrote: > > > On 27.05.2019 07:21, Igor Opaniuk 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]. > > > > 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. > > > > > > Just wanted to mention that the Linux mxsfb fbdev driver is considered > > > deprecated. > > > > > > See: https://lore.kernel.org/patchwork/patch/950619/#1135990 > > > > > > Also note that the new DRM driver does use OF graph style bindings, see: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > > > > > > > > > > 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). > > > > > > IMHO, if the deadline hinders us to do it properly, we should extend the > > > deadline. > > > > Agreed. We can always extend deadlines as needed when people are > > working to solve the problem, and we want it solved correctly. Thanks > > all! > > > > -- > > Tom > > Stefan, Anatolij, Tom, > > Thanks a lot for your input! Just want to mention that I am in full agreement with what was said here :-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On Mon, May 27, 2019 at 5:58 PM Tom Rini wrote: > > On Mon, May 27, 2019 at 09:22:05AM +0200, Stefan Agner wrote: > > On 27.05.2019 07:21, Igor Opaniuk 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]. > > > 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. > > > > Just wanted to mention that the Linux mxsfb fbdev driver is considered > > deprecated. > > > > See: https://lore.kernel.org/patchwork/patch/950619/#1135990 > > > > Also note that the new DRM driver does use OF graph style bindings, see: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > > > > > > > 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). > > > > IMHO, if the deadline hinders us to do it properly, we should extend the > > deadline. > > Agreed. We can always extend deadlines as needed when people are > working to solve the problem, and we want it solved correctly. Thanks > all! > > -- > Tom Stefan, Anatolij, Tom, Thanks a lot for your input! -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On Mon, May 27, 2019 at 09:22:05AM +0200, Stefan Agner wrote: > On 27.05.2019 07:21, Igor Opaniuk 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]. > > 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. > > Just wanted to mention that the Linux mxsfb fbdev driver is considered > deprecated. > > See: https://lore.kernel.org/patchwork/patch/950619/#1135990 > > Also note that the new DRM driver does use OF graph style bindings, see: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > > > > 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). > > IMHO, if the deadline hinders us to do it properly, we should extend the > deadline. Agreed. We can always extend deadlines as needed when people are working to solve the problem, and we want it solved correctly. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
Hi Igor, On Mon, 27 May 2019 08:21:17 +0300 Igor Opaniuk igor.opan...@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 ___ U-Boot mailing
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On 27.05.2019 07:21, Igor Opaniuk 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]. > 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. Just wanted to mention that the Linux mxsfb fbdev driver is considered deprecated. See: https://lore.kernel.org/patchwork/patch/950619/#1135990 Also note that the new DRM driver does use OF graph style bindings, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > 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). IMHO, if the deadline hinders us to do it properly, we should extend the deadline. > > 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) > > 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. > 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.). Is there maybe option 3, start a new DM_VIDEO capable driver mxsfb driver without converting the existing stuff. It is probably not much different from 2, but it allows you to start with a minimal feature set, and go from there incrementally. That is what Marek did when he implemented the Linux mxsfb DRM driver.. Haven't looked into the code much, so this might not really make sense... -- Stefan > > Just to be aware about the amount of effort that should be done: > > : u-boot.git$ grep -e CONFIG_CFB_CONSOLE -r ./configs/ > ./configs/T1042RDB_PI_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/nokia_rx51_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_internal_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > > Additional Kconfig symbols, that depend on CFB_CONSOLE: > * VGA_AS_SINGLE_DEVICE > * CONSOLE_EXTRA_INFO > * CONSOLE_SCROLL_LINES > * SYS_CONSOLE_BG_COL > * SYS_CONSOLE_FG_COL > > 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 > > Looking forward to your suggestions/recommendations here (and let me > know if I missed something), thanks! > > [1] https://lists.denx.de/pipermail/u-boot/2019-April/365506.html ___ U-Boot mailing list
[U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
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]. 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. 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). 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) 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. 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.). Just to be aware about the amount of effort that should be done: : u-boot.git$ grep -e CONFIG_CFB_CONSOLE -r ./configs/ ./configs/T1042RDB_PI_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/nokia_rx51_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/eb_cpu5282_internal_defconfig:# CONFIG_CFB_CONSOLE is not set ./configs/T1042D4RDB_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/eb_cpu5282_defconfig:# CONFIG_CFB_CONSOLE is not set ./configs/T1042D4RDB_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y Additional Kconfig symbols, that depend on CFB_CONSOLE: * VGA_AS_SINGLE_DEVICE * CONSOLE_EXTRA_INFO * CONSOLE_SCROLL_LINES * SYS_CONSOLE_BG_COL * SYS_CONSOLE_FG_COL 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 Looking forward to your suggestions/recommendations here (and let me know if I missed something), thanks! [1] https://lists.denx.de/pipermail/u-boot/2019-April/365506.html -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
