[U-Boot] is it mandatory for SPL to support DM

[Tom Rini <trini@konsulko.com>]

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 <sjg@chromium.org> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Mon, 25 May 2020 at 04:35, Marek Vasut <marex@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.

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: <https://lists.denx.de/pipermail/u-boot/attachments/20200525/f66df225/attachment.sig>