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