From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 25 May 2020 16:00:48 -0400 Subject: [U-Boot] is it mandatory for SPL to support DM In-Reply-To: <5e5383dc-700b-e4df-6dfa-ddd4208cb803@denx.de> References: <20200525173208.GA12717@bill-the-cat> <20200525192806.GR12717@bill-the-cat> <1da0f731-a69e-f46d-e487-d0ef12ca400c@denx.de> <20200525195542.GT12717@bill-the-cat> <5e5383dc-700b-e4df-6dfa-ddd4208cb803@denx.de> Message-ID: <20200525200048.GU12717@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Mon, 25 May 2020 at 04:35, Marek Vasut 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: