On 5/25/20 9:28 PM, Tom Rini wrote: > On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote: >> On 5/25/20 7:32 PM, Tom Rini wrote: >>> On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote: >>>> On Mon, May 25, 2020 at 9:06 PM Simon Glass <s...@chromium.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Mon, 25 May 2020 at 04:35, Marek Vasut <ma...@denx.de> wrote: >>>>>> >>>>>> On 5/25/20 10:44 AM, Jagan Teki wrote: >>>>>>> SPL has a foot-print constraint, so fully switching a particular >>>>>>> subsystem like SPI or SPI Flash to DM would increase the size of it. >>>>>>> >>>>>>> Possible areas to look at are (assume SPL_DM supported) >>>>>>> 1) platdata >>>>>>> 2) implement board or platform specific spl device driver which >>>>>>> bypassed the actual framework ex: spl_spi_sunxi.c >>>>>>> >>>>>>> Do we have any other solutions? or any arguments on above step 2? >>>>>> >>>>>> SPL does not need to support DM until the size problem is solved. >>>>> >>>>> I don't think the problem will ever be 'solved'. It is an ongoing battle. >>>>> >>>>> But as it happens I've just sent a proposal for tiny-dm that I think will >>>>> help. >>>>> >>>>> Jagan, which board are you trying to convert? If you are trying to >>>>> convert SPI flash, I think we need to remove the legacy code first. >>>> >>>> These are the partially dm converted drivers, so boards which are >>>> using can eventually need a dm spi switch. >>>> >>>> drivers/spi/fsl_dspi.c >>>> drivers/spi/kirkwood_spi.c >>>> drivers/spi/mxc_spi.c >>>> drivers/spi/mxs_spi.c >>>> drivers/spi/omap3_spi.c >>>> drivers/spi/sh_qspi.c >>>> >>>> I'm looking for proper options along with removal of some legacy code, >>>> and tiny-dm. >>> >>> For the number of about to be year past published deadline (which has >>> been extended at times to get to that point even) boards, I think we >>> need to start by dropping boards. Then we can see what makes sense >>> moving forward. >> >> At least mxc_spi and sh_qspi must stay, since those are heavily used in >> embedded/industrial/automotive. > > So, this brings us back to the main topic of this thread. Both of the > drivers you mention ARE converted to DM, but cannot fit adding DM to > SPL. Where do we put non-DM SPL code as we have real size constraints > in SPL/TPL? I should bring this up in Simon's new thread too, but I > wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the > non-DM-framework drivers for SPL reside somewhere and move on. The > notions of "we have a nice abstract framework" and "we need to be as > small as possible" can and do conflict.
But then how do you propose to keep sharing code between the two worlds?