[U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)

[Lubomir Popov]

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