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

[Sricharan R <r.sricharan@ti.com>]

Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
> 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.
>
>>>> 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.
>
>>> [snip]
>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>> Again, do please.
>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>> I hack around?
>>>>> Add it to the most likely struct in the headers.
>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>> course I could define only the member that I need, but I guess it is
>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>> registers, almost identical to the OMAP4, and should go into 
>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>> I don't see any conflicts per-se just some reserved areas being named
>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>> <asm/omap_common.h>.  Thanks!
>> I would argue that this is not very appropriate. Those regs that are
>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>> on the other hand the OMAP5 has some modem clock regs that are reserved
>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>> and below?
> We don't need to use ifdefs since there's no conflicts, things are
> either reserved in one case and used in the other.  And we can make sure
> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
> there.
>
>> 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.
>
>
 I am sorry for the very late response on this.
 Now then, why not add this register in to omap5_es2_prcm
 ??. That is how the  TRM sees it as well.. Of course, this is cleanup
 stuff for OMAP4  panda as you pointed out..

Regards,
 Sricharan
 

>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot