On 5/25/20 9:55 PM, Tom Rini wrote: > On Mon, May 25, 2020 at 09:48:29PM +0200, Marek Vasut wrote: >> 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? > > Sharing defines is easy. Sharing information buried in the device tree > requires some of the dtoc changes either in progress or variations on > them. Sharing other functionality? Depends on what fits well > (logically) in inline functions. But I don't see some duplication of > either functional (i.e. read()/write()) nor initialization code as a > hard blocker. > > But the only choice that doesn't have some duplication of code would be > "throw out current DM, replace with a new DM that's small enough in all > cases". And we're at a few years now of "DM is too big and bloaty!" > without "here are my patches to slim down DM for all cases".
Surely the functionality to control/access hardware can be shared ? See tiny-mmc for example.