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

[Peng Fan]

On Tue, Jan 26, 2016 at 10:12:10AM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote:
>> 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.
>
>Can you explain how this would work, or the use case for it?  We can't
>always assume we're reading u-boot.img off FAT for example.

I have no idea on this for now (:.

Regards,
Peng.

>
>-- 
>Tom