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. -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot