| Message ID | 1441460717-23318-1-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
Hi, On 05-09-15 15:45, Simon Glass wrote: > Add a README with a brief guide to porting serial drivers over to use > driver model. > > Add a timeline also. > > Signed-off-by: Simon Glass <sjg@chromium.org> I assume that the purpose of the timeline is to retire the non dm serial drivers ? What about SPL use ? I do not see the SPL for sunxi move to dm / devicetree anytime soon, there simply does not seem to be enough space. With the new nand SPL support we have already been hitting the 24k limit without bringing in dm + a dtb + a dtb parser ... Which reminds me I still need to look at your version of the patch for only using malloc_simple.c in the SPL and not build in dl_malloc.c, that saves about 1k which we could use really well. I still have this on my todo list. Regards, Hans > --- > I intend to cc the final patch to all U-Boot maintainers using something > like this: > > (for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \ > awk '{$1=""; print "Series-cc:" $0}' |sort | uniq > > This is about 229 email address, of which 217 seem to be different people. > > doc/driver-model/serial-howto.txt | 58 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 doc/driver-model/serial-howto.txt > > diff --git a/doc/driver-model/serial-howto.txt b/doc/driver-model/serial-howto.txt > new file mode 100644 > index 0000000..76a75da > --- /dev/null > +++ b/doc/driver-model/serial-howto.txt > @@ -0,0 +1,58 @@ > +How to port a serial driver to driver model > +=========================================== > + > +About 16 of 33 serial drivers have been converted as at September 2015. It > +is time for maintainers to start converting over the remaining serial drivers: > + > + altera_jtag_uart.c > + altera_uart.c > + arm_dcc.c > + lpc32xx_hsuart.c > + mcfuart.c > + mxs_auart.c > + opencores_yanu.c > + serial_bfin.c > + serial_imx.c > + serial_lpuart.c > + serial_max3100.c > + serial_pxa.c > + serial_s3c24x0.c > + serial_sa1100.c > + serial_stm32.c > + serial_xuartlite.c > + usbtty.c > + > +You should complete this by Christmas 2015. > + > +Here is a suggested approach for converting your serial driver over to driver > +model. Please feel free to update this file with your ideas and suggestions. > + > +- #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL) > +- Define CONFIG_DM_SERIAL for your board, vendor or architecture > +- If the board does not already use driver model, you need CONFIG_DM also > +- Your board should then build, but will not boot since there will be no serial > + driver > +- Add the U_BOOT_DRIVER piece at the end (e.g. copy serial_s5p.c for example) > +- Add a private struct for the driver data - avoid using static variables > +- Implement each of the driver methods, perhaps by calling your old methods > +- You may need to adjust the function parameters so that the old and new > + implementations can share most of the existing code > +- If you convert all existing users of the driver, remove the pre-driver-model > + code > + > +In terms of patches a conversion series typically has these patches: > +- clean up / prepare the driver for conversion > +- add driver model code > +- convert at least one existing board to use driver model serial > +- (if no boards remain that don't use driver model) remove the old code > + > +This may be a good time to move your board to use device tree also. Mostly > +this involves these steps: > + > +- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE > +- add your device tree files to arch/<arch>/dts > +- update the Makefile there > +- Add stdout-path to your /chosen device tree node if it is not already there > +- build and get u-boot-dtb.bin so you can test it > +- Your drivers can now use device tree > +- For device tree in SPL, define CONFIG_SPL_OF_CONTROL >
Hi Hans, On 5 September 2015 at 07:52, Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > On 05-09-15 15:45, Simon Glass wrote: >> >> Add a README with a brief guide to porting serial drivers over to use >> driver model. >> >> Add a timeline also. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> > > > I assume that the purpose of the timeline is to retire the non dm > serial drivers ? > > What about SPL use ? > > I do not see the SPL for sunxi move to dm / devicetree anytime soon, > there simply does not seem to be enough space. Yes I think device tree in SPL will only work for newer SoCs with enough SRAM. With Rockchip the device tree added about 3KB of code. If you are already hitting the limit then it isn't going to help! Still, there is the option of adding platform data for the SPL case, and still using driver model. That should work for most (but not all) boards. > > With the new nand SPL support we have already been hitting the 24k > limit without bringing in dm + a dtb + a dtb parser ... > > Which reminds me I still need to look at your version of the > patch for only using malloc_simple.c in the SPL and not build > in dl_malloc.c, that saves about 1k which we could use really > well. I still have this on my todo list. Yes - the down-side is when you want to use SDRAM for your malloc() region in SPL's board_init_r(). Then it's nice to have the full malloc(). > > Regards, > > Hans > > Regards, Simon [snip]
On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > On 05-09-15 15:45, Simon Glass wrote: > > Add a README with a brief guide to porting serial drivers over to use > > driver model. > > > > Add a timeline also. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > I assume that the purpose of the timeline is to retire the non dm > serial drivers ? > > What about SPL use ? > > I do not see the SPL for sunxi move to dm / devicetree anytime soon, > there simply does not seem to be enough space. Based on my experience, introducing code bloat is always easier than removing it. As long as the dm /devicetree remains optional for the SPL, it is safer to stay away from it for sunxi. And prioritize the use of precious SRAM space for user visible features. > With the new nand SPL support we have already been hitting the 24k > limit without bringing in dm + a dtb + a dtb parser ... What is the exact limit for the SPL size when it is loaded by the BROM? The comment in http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c;hb=HEAD#l66 says that the limit is 0x7600, which means 30208 bytes. I guess, somebody needs to do some experiments on different Allwinner SoC variants and try to confirm this information. Regarding gaining more space, there is still a decades old trick we can take advantage of: https://en.wikipedia.org/wiki/Executable_compression When using GCC 4.8.4, I'm getting 22756 bytes size for the Cubieboard u-boot-spl.bin file. Running "lzop -9 u-boot-spl.bin" results in 17876 bytes for the compressed file. Running "uclpack --10 u-boot-spl.bin u-boot-spl.bin.ucl" results in 16652 bytes for the compressed file. Both LZO and UCL have very simple small decompressors. Basically, using compression can provide us with something like 4 or 5 extra kilobytes. And we are not limited with just 32K for the uncompressed SPL size. For example, even Allwinner A13 has the total size of SRAM equal to 48K. A small part of it needs to be reserved for the USB (FEL) boot mode, but I think that maybe up to something like ~38K of contiguous SRAM space can be used for the uncompressed SPL (code+data+stack). The other SoC variants are a bit tricky, for example A31 does not have 38K of contiguous space starting at the address 0x0 in SRAM. So these 38K would have to be uncompressed to some other location and CONFIG_SPL_TEXT_BASE would need to be adjusted. And if we want the same SPL binary to be in principle bootable on all SoC variants (including A80), then relocations support can be added too (fixup them immediately after the decompression). Though additionally storing relocations can waste some space. It's all about trade-offs. Compression tricks can provide extra space at the cost of increasing complexity. The dm /devicetree wastes space for the sake of architectural aesthetics and codebase unification. > Which reminds me I still need to look at your version of the > patch for only using malloc_simple.c in the SPL and not build > in dl_malloc.c, that saves about 1k which we could use really > well. I still have this on my todo list. The current printf related machinery is a little bit heavyweight too.
Hi, On Saturday, 5 September 2015, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote: > > On Sat, 5 Sep 2015 15:52:03 +0200 > Hans de Goede <hdegoede@redhat.com> wrote: > > > Hi, > > > > On 05-09-15 15:45, Simon Glass wrote: > > > Add a README with a brief guide to porting serial drivers over to use > > > driver model. > > > > > > Add a timeline also. > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > I assume that the purpose of the timeline is to retire the non dm > > serial drivers ? > > > > What about SPL use ? > > > > I do not see the SPL for sunxi move to dm / devicetree anytime soon, > > there simply does not seem to be enough space. > > Based on my experience, introducing code bloat is always easier than > removing it. As long as the dm /devicetree remains optional for the > SPL, it is safer to stay away from it for sunxi. And prioritize the > use of precious SRAM space for user visible features. I think it will be optional for the forseeable future. But I think it would be worth exploring for sunxi to see what the cost is. I think device tree is a great unifier for SoCs that have the space and don't impose some arbitrary limit on the amount of code the boot ROM will load. An interesting avenue that I have not explored is static binding of devices. If device tree is not used a lot of the code size comes from device_bind() and device_probe(). The first one could perhaps be dropped by using some sort of static table. The second one is less clear, but if we only have serial then perhaps some efforts can be made to reduce space. > > > > With the new nand SPL support we have already been hitting the 24k > > limit without bringing in dm + a dtb + a dtb parser ... > > What is the exact limit for the SPL size when it is loaded by the > BROM? The comment in > http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c;hb=HEAD#l66 > says that the limit is 0x7600, which means 30208 bytes. I guess, > somebody needs to do some experiments on different Allwinner SoC > variants and try to confirm this information. > > Regarding gaining more space, there is still a decades old trick > we can take advantage of: > https://en.wikipedia.org/wiki/Executable_compression > > When using GCC 4.8.4, I'm getting 22756 bytes size for the > Cubieboard u-boot-spl.bin file. Running "lzop -9 u-boot-spl.bin" > results in 17876 bytes for the compressed file. Running > "uclpack --10 u-boot-spl.bin u-boot-spl.bin.ucl" results in > 16652 bytes for the compressed file. Both LZO and UCL have > very simple small decompressors. > > Basically, using compression can provide us with something > like 4 or 5 extra kilobytes. And we are not limited with just > 32K for the uncompressed SPL size. For example, even Allwinner > A13 has the total size of SRAM equal to 48K. A small part of it > needs to be reserved for the USB (FEL) boot mode, but I think > that maybe up to something like ~38K of contiguous SRAM space > can be used for the uncompressed SPL (code+data+stack). The > other SoC variants are a bit tricky, for example A31 does not > have 38K of contiguous space starting at the address 0x0 in SRAM. > So these 38K would have to be uncompressed to some other location > and CONFIG_SPL_TEXT_BASE would need to be adjusted. And if we > want the same SPL binary to be in principle bootable on all SoC > variants (including A80), then relocations support can be added > too (fixup them immediately after the decompression). Though > additionally storing relocations can waste some space. > > It's all about trade-offs. Compression tricks can provide extra > space at the cost of increasing complexity. The dm /devicetree > wastes space for the sake of architectural aesthetics and codebase > unification. I'm not a huge fan of the additional complexity from compression. As it happened this was implemented in the Chrome OS U-Boot to improve boot time, but the effect was pretty small. But perhaps as an option to enable to get more features, it could be useful. > > > > Which reminds me I still need to look at your version of the > > patch for only using malloc_simple.c in the SPL and not build > > in dl_malloc.c, that saves about 1k which we could use really > > well. I still have this on my todo list. > > The current printf related machinery is a little bit heavyweight > too. Yes a minimal printf() would be nice - perhaps just strings, hex and maybe decimal. Regards, Simon
Hi, On 9 September 2015 at 12:06, Simon Glass <sjg@chromium.org> wrote: > Hi, > > On Saturday, 5 September 2015, Siarhei Siamashka > <siarhei.siamashka@gmail.com> wrote: >> >> On Sat, 5 Sep 2015 15:52:03 +0200 >> Hans de Goede <hdegoede@redhat.com> wrote: >> >> > Hi, >> > >> > On 05-09-15 15:45, Simon Glass wrote: >> > > Add a README with a brief guide to porting serial drivers over to use >> > > driver model. >> > > >> > > Add a timeline also. >> > > >> > > Signed-off-by: Simon Glass <sjg@chromium.org> >> > [snip] Are there any more comments on this patch? Does December seem like a reasonable deadline to convert serial drivers over? Regards, Simon
Hi, On 18-10-15 14:18, Simon Glass wrote: > Hi, > > On 9 September 2015 at 12:06, Simon Glass <sjg@chromium.org> wrote: >> Hi, >> >> On Saturday, 5 September 2015, Siarhei Siamashka >> <siarhei.siamashka@gmail.com> wrote: >>> >>> On Sat, 5 Sep 2015 15:52:03 +0200 >>> Hans de Goede <hdegoede@redhat.com> wrote: >>> >>>> Hi, >>>> >>>> On 05-09-15 15:45, Simon Glass wrote: >>>>> Add a README with a brief guide to porting serial drivers over to use >>>>> driver model. >>>>> >>>>> Add a timeline also. >>>>> >>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>> > > [snip] > > Are there any more comments on this patch? Does December seem like a > reasonable deadline to convert serial drivers over? December seems fine, with the caveat that we need to keep non a non dm version around for SPL. That or maybe look into doing none dt instantiation of dm serial ports for the SPL. Regards, Hans
diff --git a/doc/driver-model/serial-howto.txt b/doc/driver-model/serial-howto.txt new file mode 100644 index 0000000..76a75da --- /dev/null +++ b/doc/driver-model/serial-howto.txt @@ -0,0 +1,58 @@ +How to port a serial driver to driver model +=========================================== + +About 16 of 33 serial drivers have been converted as at September 2015. It +is time for maintainers to start converting over the remaining serial drivers: + + altera_jtag_uart.c + altera_uart.c + arm_dcc.c + lpc32xx_hsuart.c + mcfuart.c + mxs_auart.c + opencores_yanu.c + serial_bfin.c + serial_imx.c + serial_lpuart.c + serial_max3100.c + serial_pxa.c + serial_s3c24x0.c + serial_sa1100.c + serial_stm32.c + serial_xuartlite.c + usbtty.c + +You should complete this by Christmas 2015. + +Here is a suggested approach for converting your serial driver over to driver +model. Please feel free to update this file with your ideas and suggestions. + +- #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL) +- Define CONFIG_DM_SERIAL for your board, vendor or architecture +- If the board does not already use driver model, you need CONFIG_DM also +- Your board should then build, but will not boot since there will be no serial + driver +- Add the U_BOOT_DRIVER piece at the end (e.g. copy serial_s5p.c for example) +- Add a private struct for the driver data - avoid using static variables +- Implement each of the driver methods, perhaps by calling your old methods +- You may need to adjust the function parameters so that the old and new + implementations can share most of the existing code +- If you convert all existing users of the driver, remove the pre-driver-model + code + +In terms of patches a conversion series typically has these patches: +- clean up / prepare the driver for conversion +- add driver model code +- convert at least one existing board to use driver model serial +- (if no boards remain that don't use driver model) remove the old code + +This may be a good time to move your board to use device tree also. Mostly +this involves these steps: + +- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE +- add your device tree files to arch/<arch>/dts +- update the Makefile there +- Add stdout-path to your /chosen device tree node if it is not already there +- build and get u-boot-dtb.bin so you can test it +- Your drivers can now use device tree +- For device tree in SPL, define CONFIG_SPL_OF_CONTROL
Add a README with a brief guide to porting serial drivers over to use driver model. Add a timeline also. Signed-off-by: Simon Glass <sjg@chromium.org> --- I intend to cc the final patch to all U-Boot maintainers using something like this: (for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \ awk '{$1=""; print "Series-cc:" $0}' |sort | uniq This is about 229 email address, of which 217 seem to be different people. doc/driver-model/serial-howto.txt | 58 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 doc/driver-model/serial-howto.txt