On Mon, May 25, 2020 at 09:59:32PM +0200, Marek Vasut wrote: > 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 <[email protected]> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Mon, 25 May 2020 at 04:35, Marek Vasut <[email protected]> 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.
Yes, it can. Lets move over to the other thread where I call that out as a good example. -- Tom
signature.asc
Description: PGP signature
