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

[Lubomir Popov <lpopov@mm-sol.com>]

Hi Sricharan, Tom,

On 15/05/13 14:25, Sricharan R wrote:
> On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote:
>> Hi Sricharan,
>>
>> On 15/05/13 12:04, Sricharan R wrote:
>>> Hi,
>>>
>>> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
>>>> Hi Sricharan,
>>>>
>>>> On 15/05/13 08:11, Sricharan R wrote:
>>>>> 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..
>>>> Yes, you are right in respect to fluent software integration and consistency
>>>> with current implementation. My only concern is that from architectural point
>>>> of view the SCRM, although related to the PRCM, is a separate module (described
>>>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall
>>>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
>>>> confusing.
>>>>
>>>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
>>>> to the prcm_regs declaration in omap_common.h, and the required init to the
>>>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
>>>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
>>>> start with a scrm_ prefix.
>>>>
>>>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
>>>> with the appropriate pointers, and the corresponding definitions/inits added as
>>>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
>>>> be a bit confusing.
>>>>
>>>> What do you say?
>>>   At this point , i think just adding only the registers that you need in to the
>>>  prcm structure should be ok.
>> OK, I just tend to add all registers, it shall be easier for later rework.
>  Actually no :). When were are not using them no good in adding. Especially
>  those SCRM registers very less we will use all of them in bootloader.
OK, agree. Done.

Now on USB in general: u-boot-ti master lags behind mainline master in respect to
drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old
.../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom
does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom?
> 
> Regards,
>  Sricharan
> 
Regards,
Lubo