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

[Peng Fan]

On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan 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.
>
>This sounds similar, but different.  The problem I'm asking to be solved
>is that at the starting point, there are no DTBs on the hardware.  But

Oh. Thanks for explanation.

>we can in software easily and reliable tell which of say 3 boards we are
>on.  At that point, we need to make sure that both SPL and then U-Boot
>know which board they are on.  And if in U-Boot we use the DT to pass in
>all data, it has to be correct.  It sounds to me like you're describing
>the case where the HW has the dtb stored at a known location and you
>just don't need it embedded within SPL/U-Boot.

Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.

Thanks,
Peng.
>
>-- 
>Tom