On Tue, Jul 10, 2012 at 11:36:15, Shilimkar, Santosh wrote:
> On Tue, Jul 10, 2012 at 11:27 AM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote:
> > On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
> >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@xxxxxx> wrote:
> >> >
> >> >
> >> >
> >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
> >> > > From: R Sricharan <r.sricharan@xxxxxx>
> >> > >
> >> > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
> >> > > architecture. It's a dual core SOC with GIC used for interrupt
> >> > > handling and with an integrated L2 cache controller.
> >> > >
> >> > > OMAP5432 is another variant of OMAP5430, with a
> >> > > memory controller supporting DDR3 and SATA.
> >> > >
> >> > > Patch includes:
> >> > > - The machine specific headers and sources updates.
> >> > > - Platform header updates.
> >> > > - Minimum initialisation support for serial.
> >> > > - IO table init
> >> > >
> >> > > Signed-off-by: R Sricharan <r.sricharan@xxxxxx>
> >> > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
> >> > > ---
> >>
> >> [..]
> >>
> >> > >
> >> > > +#if defined(CONFIG_SOC_OMAP5)
> >> > > +static struct omap_globals omap5_globals = {
> >> > > + .class = OMAP54XX_CLASS,
> >> > > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
> >> > > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
> >> > > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE),
> >> > > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE),
> >> > > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
> >> > > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE),
> >> > > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE),
> >> >
> >> > I am not sure whether we had discussed on this before, couldn't find it.
> >> >
> >> > Why don't we reuse OMAP4 data here and elsewhere??
> >> >
> >> Because data is not same between OMAP4 and OMAP5.
> >> Wherever it is same, it is taken care.
> >>
> >
> > Above most of the base-addresses are same as omap4.
> >
> > And what about clocktree and hwmod? Is it going tobe same as omap4?
> > Or we have separate data generated?
> >
> The data generated is different for OMAP5. Hwmod, powerdomain, clockdomain,
> muxes. This data is out of the tree now since we are waiting for ES2.0
> data which
> has some differences w.r.t ES1.0.
Ok, this is useful information.
> This was discussed in the beginning
> as part of this
> series review on the list.
>
My bad, I missed that discussion, and will refer to archives now.
> >
> >> [..]
> >>
> >> > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> >> > > index 70cf825..766181c 100644
> >> > > --- a/arch/arm/plat-omap/sram.c
> >> > > +++ b/arch/arm/plat-omap/sram.c
> >> > > @@ -6,8 +6,8 @@
> >> > > * Copyright (C) 2005 Nokia Corporation
> >> > > * Written by Tony Lindgren <tony@xxxxxxxxxxx>
> >> > > *
> >> > > - * Copyright (C) 2009 Texas Instruments
> >> > > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@xxxxxx>
> >> > > + * Copyright (C) 2009-2012 Texas Instruments
> >> > > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@xxxxxx>
> >> > > *
> >> > > * This program is free software; you can redistribute it and/or modify
> >> > > * it under the terms of the GNU General Public License version 2 as
> >> > > @@ -44,6 +44,7 @@
> >> > > #else
> >> > > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
> >> > > #endif
> >> > > +#define OMAP5_SRAM_PA 0x40300000
> >> > >
> >> >
> >> > We have mix of such definitions here, for example,
> >> >
> >> > "arch/arm/plat-omap/include/plat/sram.h"
> >> > and now in arch/arm/plat-omap/sram.c here itself.
> >> >
> >> >
> >> > May be right time to clean it up now.
> >> >
> >> Thats because of an interconnect BUG which needed it exported
> >> at plat level in case of OMAP4.
> >>
> >
> > Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there
> > at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file.
> >
> I see that now. Infact there is no need for any of those PA's to be defined
> there except OMAP4 which needs to have that macro available for an errata.
>
> I will clean that up once the series is merged. Don't want to introduce any
> regression in last moment changes.
>
I am ok.
Thanks,
Vaibhav
--
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
