On 11 February 2016 at 20:31, Jagan Teki <jt...@openedev.com> wrote: > On 11 February 2016 at 02:30, Christophe Ricard > <christophe.ric...@gmail.com> 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. >> >> Are you ok in applying patch 1 and 2 only ? or should i send a new serie >> with only patch 1 and 2 ? > > 3/4 looks not good to me with so many ifdef, may we can do something > clear similar to kirkwood_spi does.
I did some dm conversion on these long back which looks similar like kirkwood_spi, will post them as well so-that we can discuss. > >> >> 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. >> >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > > > -- > Jagan. -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot