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

[Tom Rini]

On Wed, Feb 10, 2016 at 10:00:55PM +0100, Christophe Ricard wrote:

> Hi Jagan,
> 
> My understanding is that some work are ongoing around spl in order
> to support correctly DM for all spi/i2c bus drivers.
> As a consequence patch 4 got differed.
>
> Hopefully Simon or Tom can comment.

Yes, I deferred 4/4 because until we convert all of the platforms to DM
(and Simon is making progress on what's required there).

> Are you ok in applying patch 1 and 2 only ? or should i send a new
> serie with only patch 1 and 2 ?

1, 2 and 3? should be fine to go now and you shouldn't need to re-send
them.

> 
> Best Regards
> Christophe
> 
> On 10/02/2016 20:16, Jagan Teki wrote:
> >On 8 February 2016 at 23:26, Jagan Teki <jteki at openedev.com> wrote:
> >>On 8 February 2016 at 23:10, Tom Rini <trini at konsulko.com> wrote:
> >>>On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> >>>>Hi Simon, Tom,
> >>>>
> >>>>I assume the approach you are taking is also valuable for the i2c:
> >>>>omap24xx patch serie:
> >>>>http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> >>>>
> >>>>What are your recommendation about the pending patches ?
> >>>>Should i send back only the one not taking care of the DM conversion
> >>>>and send another serie later ?
> >>>>
> >>>>I have seen some work ongoing on this topic on the u-boot-fdt tree
> >>>>on the spl-working branch.
> >>>>Is there a more accurate place to follow this work ?
> >>>For i2c, aside from needing to defer removing the non-DM code for a
> >>>while yet, there were some review comments to address in a v2 or answer
> >>>as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> >>>will have a SPI PR soon.  Thanks!
> >>Yes, by this week-end.
> >Any idea 4/4 got differed in patchwork [1], do we have next version
> >patches for these?
> >
> >[1] https://patchwork.ozlabs.org/patch/569241/
> >
> >>>>On 26/01/2016 02:55, 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.
> >>>>>
> >>>>>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.
> 

-- 
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/20160210/1b7ad36a/attachment-0001.sig>