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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160126/65c12375/attachment.sig>