From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Wed, 27 Jan 2016 10:46:43 +0800 Subject: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM In-Reply-To: <20160126151210.GR3359@bill-the-cat> 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> <20160126024547.GV3359@bill-the-cat> <20160126025846.GB15145@linux-7smt.suse> <20160126151210.GR3359@bill-the-cat> Message-ID: <20160127024638.GA10090@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 On Tue, Jan 26, 2016 at 10:12:10AM -0500, Tom Rini wrote: >On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote: >> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote: >> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, 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. >> > >> >This sounds similar, but different. The problem I'm asking to be solved >> >is that at the starting point, there are no DTBs on the hardware. But >> >> Oh. Thanks for explanation. >> >> >we can in software easily and reliable tell which of say 3 boards we are >> >on. At that point, we need to make sure that both SPL and then U-Boot >> >know which board they are on. And if in U-Boot we use the DT to pass in >> >all data, it has to be correct. It sounds to me like you're describing >> >the case where the HW has the dtb stored at a known location and you >> >just don't need it embedded within SPL/U-Boot. >> >> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file. > >Can you explain how this would work, or the use case for it? We can't >always assume we're reading u-boot.img off FAT for example. I have no idea on this for now (:. Regards, Peng. > >-- >Tom