From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Tue, 26 Jan 2016 09:55:43 +0800 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> Message-ID: <20160126015541.GB13773@linux-7smt.suse> 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, 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