From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Ricard Date: Sat, 6 Feb 2016 23:27:21 +0100 Subject: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM In-Reply-To: <20160126015541.GB13773@linux-7smt.suse> 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> Message-ID: <56B67349.8010502@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 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 ? Best Regards Christophe 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. >> >> Regards, >> Simon >> _______________________________________________ >> U-Boot mailing list >> U-Boot at lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot