From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Ricard Date: Wed, 10 Feb 2016 22:00:55 +0100 Subject: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM In-Reply-To: References: <1453028210-10139-1-git-send-email-christophe-h.ricard@st.com> <1453028210-10139-4-git-send-email-christophe-h.ricard@st.com> <20160121122407.GY3359@bill-the-cat> <20160126015541.GB13773@linux-7smt.suse> <56B67349.8010502@gmail.com> <20160208174041.GG25786@bill-the-cat> Message-ID: <56BBA507.5060101@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 ? Best Regards Christophe On 10/02/2016 20:16, Jagan Teki wrote: > On 8 February 2016 at 23:26, Jagan Teki wrote: >> On 8 February 2016 at 23:10, Tom Rini 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 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 >>>>>>>> wrote: >>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with previous >>>>>>>>> mode. >>>>>>>>> >>>>>>>>> Signed-off-by: Christophe Ricard >>>>>>>>> --- >>>>>>>>> >>>>>>>>> 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.