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 <jt...@openedev.com> wrote: > >>On 8 February 2016 at 23:10, Tom Rini <tr...@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 <tr...@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.ric...@gmail.com> wrote: > >>>>>>>>>Convert omap3_spi driver to DM and keep compatibility with previous > >>>>>>>>>mode. > >>>>>>>>> > >>>>>>>>>Signed-off-by: Christophe Ricard <christophe-h.ric...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot