RE: [PATCH-V2 3/3] arm:omap:omap4: Hook-up am33xx support to existing prm code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
> Vaibhav Hiremath <hvaibhav@xxxxxx> writes:
> 
> > AM33XX PRM module (L4_WK domain) will be treated as another seperate
> > partition in _prm_bases[] table.
> >
> > Also, since cpu_is_omap34xx check is true for am33xx family of
> > devices, we must check cpu_is_am33xx fisrt, in order to follow
> > omap4 execution path.
> 
> Can you remind me why cpu_is_omap34xx() is true for AM33xx family?

Yeah sure...

Kevin,
As mentioned before, the main idea behind bringing am33xx under omap34xx
was mainly due to "cortex-A8 family of devices".

It has been discussed and aligned long time back, so
please refer to the thread -

http://www.spinics.net/lists/linux-omap/msg41046.html
Multiple versions of -
http://www.spinics.net/lists/linux-omap/msg45505.html

Thanks,
Vaibhav

> These AM3xxx devices make my brain hurt.
> 
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx>
> > Cc: Kevin Hilman <khilman@xxxxxx>
> > Cc: Rajendra Nayak <rnayak@xxxxxx>
> 
> [...]
> 
> > diff --git a/arch/arm/mach-omap2/prminst44xx.c b/arch/arm/mach-omap2/prminst44xx.c
> > index 3d9894f..fcc4123 100644
> > --- a/arch/arm/mach-omap2/prminst44xx.c
> > +++ b/arch/arm/mach-omap2/prminst44xx.c
> > @@ -19,6 +19,7 @@
> >  #include "common.h"
> >
> >  #include "prm44xx.h"
> > +#include "prm33xx.h"
> >  #include "prminst44xx.h"
> >  #include "prm-regbits-44xx.h"
> >  #include "prcm44xx.h"
> > @@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
> >  	[OMAP4430_CM2_PARTITION]		= 0,
> >  	[OMAP4430_SCRM_PARTITION]		= 0,
> >  	[OMAP4430_PRCM_MPU_PARTITION]		= OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
> > +	[AM33XX_PRM_PARTITION]			= AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
> >  };
> 
> I'm not crazy about just extending the "normal" OMAP4 table.  

If it is required then yes (with proper comment).

> That would
> imply that with each OMAP4 derivatve we keep extending this table.
> 

I would say anyway we will end up adding
Cpu_is_xxx everywhere as we add new table for derivatives.

> Instead, how about rename this to one to omap44xx_prm_bases[], then
> create a new one called am33xx_prm_bases[].  Then, at init time, assing
> _prm_bases to the right one based on cpu_is_.
> 

Just wanted to avoid cpu_is_xxxx check here. Will specific comment wouldn't
help here (I have clearly mentioned in patch description), may be in c file
it is required?
OR 
you want to be clearly separate table for code readability.

Thanks,
Vaibhav

> Kevin
> 
> 

--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux