Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
> * Pedanekar, Hemant <hemantp@xxxxxx> [101129 09:07]:
>> Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
>>
>> Though based on Cortex A8, TI816X series has differences in PRCM, PLL,
>> clock structure compared to OMAP3.
>>
>> Many of the OMAP3 specific checks are not applicable for TI816X. For
>> example, consider following: File - arch/arm/mach-omap2/omap_hwmod.c
>> Function - _wait_target_ready()
>>
>> if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
>> ret =
> omap2_cm_wait_module_ready(oh->prcm.omap2.module_offs,
>> oh->prcm.omap2.idlest_reg_id,
>> oh->prcm.omap2.idlest_idle_bit);
>>
>> The above code inside cpu_is_omap34xx() check is not applicable for TI816X
>> as there are no CM_IDELST registers.
>
> OK, so places like these will need different handling, and should
> then be based on some idlest flag that gets set during the init
> based on cpu_is_omap24xx() || cpu_is_omap3430() || cpu_is_omap3630().
>
Tony,
Thanks for clarifications. I have some concerns though:
1) I will eventually end up preceeding existing OMAP3 ckecks to have
cpu_is_34xx() fail. Fo example, in above case, since cpu_is_omap34xx will
be true for ti81xx (which we don't want), I need to update the code as:
if (cpu_is_omap24xx() || (cpu_is_omap34xx() && !cpu_is_ti816x()) {
OR
if (cpu_is_omap24xx() || (cpu_is_omap34xx() && omap_has_idlest()) {
Then proceed to have a TI816X specific handling in "else if" part with
cpu_is_ti816x() check.
2) Various module base addresses part of global data are different compared to
OMAP3/4 - e.g., .tap, .ctrl, .prm etc are different. This means I will still
need separate global data in arch/arm/mach-omap2/common.c as present for
OMAP3/4 and have it set up in omap2_set_globals_ti816x().
3) Differences in PRCM, PLL mean we need a separate clock data files such as
clock816x_data.c, clockdomains816x.h, powerdomains816x.h etc. In fact, future
SoCs in 816x (or rather, 81xx) series will share the same organization and we
will be adding to these files instead of growing omap3xxx_data.c etc. Of course,
I see some special handling done depending upon cpu_is_ and features in
omap3xxx_clk_init() - but will similar approach scale with TI816X which has
completely different clock data?
Similarly, we will also need to add TI816X specific hwmods.
4) TI816X series shares similarity with OMAP4 too - e.g., various IPs are same,
CM module is closer to OMAP4 than OMAP3. Thus, regaring (1) above, I could use
OMAP4 code instead of adding new "else if". Of course, again, there are above
mentioned differences too.
With all this, won't it be better if we add TI816X (or TI81XX) series to exist
on similar lines with OMAP3/4?
Please let me know your thoughts on the above. I can send v3 patch set
incorporating your suggestion of plugging TI816X into OMAP3.
Also, the patch set submitted doesn't have complete set of files yet
(particularly PRCM/clock code), please have a look at code hosted on Arago.
Below is the link to mach-omap2 folder (2.6.34 at the moment)
http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=tree;f=arch/arm/mach-omap2;h=7f2c48b8cb3213b3850d0b6ea242c0c53fa5d6fa;hb=refs/heads/ti816x-master
Thanks
-
Hemant
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
