From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lubomir Popov Date: Tue, 14 May 2013 22:42:11 +0300 Subject: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based) In-Reply-To: <20130514164151.GP29196@bill-the-cat> References: <51599458.1000505@mm-sol.com> <20130425190130.GC32253@bill-the-cat> <517AA471.4070708@mm-sol.com> <51914110.9030702@ti.com> <519210E9.7060108@mm-sol.com> <20130514145231.GN29196@bill-the-cat> <519261BD.3060701@mm-sol.com> <20130514164151.GP29196@bill-the-cat> Message-ID: <31473061e89e2f098fdacd8a192e27fc.squirrel@www.mm-sol.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 Tom, Just a couple of things to clarify below. > On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> On 14/05/13 17:52, Tom Rini wrote: >> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> >> Hi Tom, >> >> >> >> I'm currently busy with other work; on the other hand, careful >> >> rebasing shall require some time, especially the Palmas stuff. >> >> What would be the deadline for a V2 submission? >> >> >> >> Meanwhile could you please have a look at the (already old) >> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> >> shall be needed if we enable USB (for the uEVM along with >> >> our board). In general, what are your plans regarding USB >> >> (.../patch/232742/)? >> > >> > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but >> do >> > you have a patch around for uEVM still? >> Not yet (didn't have the opportunity to test, although some uEVMs should >> be around at MMS). As you know, a patch shall be needed in the uEVM >> board >> file along with the common USB stuff. > > Yeah, I can test it as well if you write it up, and may find the time if > you point me in the right direction. OK, shall do it. > >> >> And again on I2C (.../patch/233823/): what is you final >> >> opinion? I'm confident that this patch is a major improvement >> >> for OMAP4/5 at least. >> > >> > I'm inclined to go with it, just need to mentally unswap the i2c notes >> > in my brain and think it over one more time. >> Just applied 233823 to current u-boot-ti master. Works fine. > > OK, thanks. Just to avoid confusion: I applied it and tested on a locally cloned version of u-boot-ti, not upstream (don't laugh please; just want to clarify for those who don't know that it is your job). > >> > [snip] >> Currently the scrm struct is defined for OMAP4 in the >> asm/arch-omap4/clocks.h >> file and I have already done the same for OMAP5 by analogy. I must admit >> however that this approach does not correspond to the latest way by >> which >> groups of OMAP hardware regs are defined, prcm in particular - a struct >> in >> omap_common.h, holding only the required regs, no padding and such >> garbage, >> and an init with the physical addresses in a .c file for the particular >> SoC >> (prcm-regs.c). But still the Panda board, for example, uses the old way >> for >> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old >> and >> lazy ;) ). > > Yes, I'm OK starting off with moving things into omap_common.h as-is and > then updating them a bit later ala pcrm-regs.c. Who is starting off, me or you? ;) > > -- > Tom > BR, Lubo