[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Simon Glass]

Hi Peng,

On 25 January 2016 at 18:55, Peng Fan <van.freenix at gmail.com> wrote:
> Hi Simon,
>
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>+Hans
>>
>>Hi Tom,
>>
>>On 21 January 2016 at 05:24, Tom Rini <trini at konsulko.com> wrote:
>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>> +Mugunthan, Tom
>>>>
>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>> <christophe.ricard at gmail.com> wrote:
>>>> > Convert omap3_spi driver to DM and keep compatibility with previous
>>>> > mode.
>>>> >
>>>> > Signed-off-by: Christophe Ricard <christophe-h.ricard at st.com>
>>>> > ---
>>>> >
>>>> >  drivers/spi/Kconfig     |   6 +
>>>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>>> >  drivers/spi/omap3_spi.h |  14 +-
>>>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>>>
>>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>>> would be possible to use a common pointer type and reduce this.
>>>>
>>>> But perhaps it does not matter - how long must we be in the state of
>>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>>
>>> We _really_ need some way to support more than one board per binary
>>> before we can move everything to DM only.
>>>
>>> I think we can kind of do this today if we stick to using platform data
>>> for everything that's board-specific rather than SoC-defined.  What we
>>> talked about at ELCE was auto-generating the pdata from the device tree,
>>> I think.
>>
>>We discussed this on IRC but since that doesn't exist as far as the
>>mailing list is concerned...
>>
>>The current plan is:
>>
>>- Adjust build system to optionally build a u-boot.img in FIT format
>>that includes the U-Boot binary and >1 device tree files
>>- Adjust SPL to load this
>>- Add a way for SPL to determine which device tree to select (by
>>calling a board-specific function)
>>- Have SPL pass this selected device tree to U-Boot when it starts
>
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.

The way I have it is that u-boot.img include U-Boot and multiple .dtb
files. Then SPL selects the correct one and passes it to U-Boot.

It could be passed to the kernel also, but then you would need to
upgrade your firmware to upgrade your kernel. If that's what you want,
it would not be hard to implement. But I am not planning that for this
work - it seems like a separate feature to me.

>
> Regards,
> Peng.
>>
>>Thus we should be able to support more than one board with a single
>>U-Boot image. Of course this is not a perfect solution (e.g. it is
>>inefficient since the DTs are likely to be largely the same) but it
>>should be a good first step.
>>
>>I'm going to try this out with sunxi initially and plan to get some
>>patches out by the end of the week.
>>
>>Regards,
>>Simon

Regards
Simon