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

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

[Jagan Teki]

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?

Jagan.

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

[Marek Vasut]

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.

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

[Simon Glass]

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.

Regards,
Simon

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

[Marek Vasut]

On 5/25/20 5:36 PM, Simon Glass 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.

If you want a board which boots from SPI NOR and has some 14k or so
limit on SPL, any of the R-Car Gen2 boards fit the bill.

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

[Simon Glass]

Hi Marek,

On Mon, 25 May 2020 at 09:43, Marek Vasut <marex@denx.de> wrote:
>
> On 5/25/20 5:36 PM, Simon Glass 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.
>
> If you want a board which boots from SPI NOR and has some 14k or so
> limit on SPL, any of the R-Car Gen2 boards fit the bill.

Thanks...do you have a link to one?

Also was there a 64-bit board that had to run 64-bit SPL? I think I
remember you mentioning it.

Regards,
Simon

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

[Marek Vasut]

On 5/25/20 5:48 PM, Simon Glass wrote:
> Hi Marek,
> 
> On Mon, 25 May 2020 at 09:43, Marek Vasut <marex@denx.de> wrote:
>>
>> On 5/25/20 5:36 PM, Simon Glass 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.
>>
>> If you want a board which boots from SPI NOR and has some 14k or so
>> limit on SPL, any of the R-Car Gen2 boards fit the bill.
> 
> Thanks...do you have a link to one?

https://elinux.org/R-Car/Boards/U-Boot-Gen2

> Also was there a 64-bit board that had to run 64-bit SPL? I think I
> remember you mentioning it.

You can build SPL for R-Car Gen3 boards.

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

[Simon Glass]

Hi Marek,

On Mon, 25 May 2020 at 09:56, Marek Vasut <marex@denx.de> wrote:
>
> On 5/25/20 5:48 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Mon, 25 May 2020 at 09:43, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 5/25/20 5:36 PM, Simon Glass 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.
> >>
> >> If you want a board which boots from SPI NOR and has some 14k or so
> >> limit on SPL, any of the R-Car Gen2 boards fit the bill.
> >
> > Thanks...do you have a link to one?
>
> https://elinux.org/R-Car/Boards/U-Boot-Gen2

I mean a link to buy one...if not too expensive. The links on those
pages all go nowhere. Digikey lists it as a 'non-stock' item.

>
> > Also was there a 64-bit board that had to run 64-bit SPL? I think I
> > remember you mentioning it.
>
> You can build SPL for R-Car Gen3 boards.

Regards,
Simon

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

[Jagan Teki]

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.

Jagan.

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

[Tom Rini]

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.

-- 
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/69ca42b2/attachment.sig>

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

[Marek Vasut]

On 5/25/20 6:59 PM, Simon Glass wrote:
> Hi Marek,
> 
> On Mon, 25 May 2020 at 09:56, Marek Vasut <marex@denx.de> wrote:
>>
>> On 5/25/20 5:48 PM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On Mon, 25 May 2020 at 09:43, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 5/25/20 5:36 PM, Simon Glass 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.
>>>>
>>>> If you want a board which boots from SPI NOR and has some 14k or so
>>>> limit on SPL, any of the R-Car Gen2 boards fit the bill.
>>>
>>> Thanks...do you have a link to one?
>>
>> https://elinux.org/R-Car/Boards/U-Boot-Gen2
> 
> I mean a link to buy one...if not too expensive. The links on those
> pages all go nowhere. Digikey lists it as a 'non-stock' item.

Y-RCAR-E2-SILK-A is probably the one you want then. I got it from Mouser
iirc.

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

[Marek Vasut]

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.

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

[Tom Rini]

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.

-- 
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/063f780d/attachment.sig>

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

[Marek Vasut]

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?

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

[Tom Rini]

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".

-- 
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/adee72d9/attachment.sig>

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

[Marek Vasut]

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.

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

[Tom Rini]

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>

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

[Simon Glass]

Hi Marek,

On Mon, 25 May 2020 at 13:06, Marek Vasut <marex@denx.de> wrote:
>
> On 5/25/20 6:59 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Mon, 25 May 2020 at 09:56, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 5/25/20 5:48 PM, Simon Glass wrote:
> >>> Hi Marek,
> >>>
> >>> On Mon, 25 May 2020 at 09:43, Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 5/25/20 5:36 PM, Simon Glass 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.
> >>>>
> >>>> If you want a board which boots from SPI NOR and has some 14k or so
> >>>> limit on SPL, any of the R-Car Gen2 boards fit the bill.
> >>>
> >>> Thanks...do you have a link to one?
> >>
> >> https://elinux.org/R-Car/Boards/U-Boot-Gen2
> >
> > I mean a link to buy one...if not too expensive. The links on those
> > pages all go nowhere. Digikey lists it as a 'non-stock' item.
>
> Y-RCAR-E2-SILK-A is probably the one you want then. I got it from Mouser
> iirc.

It looks like it is obsolete and out of stock. I think I'll try rock2 for now.

Regards,
Simon