| Message ID | 1335952093-12541-1-git-send-email-santosh.shilimkar@ti.com |
|---|---|
| State | New |
| Headers | show |
On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/mach-omap2/Makefile | 160 ++++++++++++++++++++--------------------- > 1 files changed, 78 insertions(+), 82 deletions(-) > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index 56ed62e..669e2b1 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -24,10 +24,11 @@ endif > obj-$(CONFIG_TWL4030_CORE) += omap_twl.o > > # SMP support ONLY available for OMAP4 > + > obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o > obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o > -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ > - sleep44xx.o > +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o > +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o Using \ in makefiles really isn't a problem. I don't think this is something which we need to do, and it just creates additional changes where none is required.
On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >> --- >> arch/arm/mach-omap2/Makefile | 160 ++++++++++++++++++++--------------------- >> 1 files changed, 78 insertions(+), 82 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile >> index 56ed62e..669e2b1 100644 >> --- a/arch/arm/mach-omap2/Makefile >> +++ b/arch/arm/mach-omap2/Makefile >> @@ -24,10 +24,11 @@ endif >> obj-$(CONFIG_TWL4030_CORE) += omap_twl.o >> >> # SMP support ONLY available for OMAP4 >> + >> obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o >> obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o >> -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ >> - sleep44xx.o >> +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o >> +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o > > Using \ in makefiles really isn't a problem. I don't think this is something > which we need to do, and it just creates additional changes where none is > required. Tony might give better reasoning for this change since he suggested it. Regards Santosh
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120502 03:18]: > On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote: > >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > >> --- > >> arch/arm/mach-omap2/Makefile | 160 ++++++++++++++++++++--------------------- > >> 1 files changed, 78 insertions(+), 82 deletions(-) > >> > >> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > >> index 56ed62e..669e2b1 100644 > >> --- a/arch/arm/mach-omap2/Makefile > >> +++ b/arch/arm/mach-omap2/Makefile > >> @@ -24,10 +24,11 @@ endif > >> obj-$(CONFIG_TWL4030_CORE) += omap_twl.o > >> > >> # SMP support ONLY available for OMAP4 > >> + > >> obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o > >> obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o > >> -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \ > >> - sleep44xx.o > >> +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o > >> +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o > > > > Using \ in makefiles really isn't a problem. I don't think this is something > > which we need to do, and it just creates additional changes where none is > > required. > > Tony might give better reasoning for this change since he suggested it. Mostly for making it cleaner to build shared objects between omap4 and omap5 without adding things like: +obj-$(CONFIG_ARCH_OMAP5) += omap4-common.o omap-wakeupgen.o \ + sleep44xx.o But of course more localized changes will do there too to prepare adding omap5. Regards, Tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code > cpu checks accordingly so that there is no need to patch > the file for any future OMAP2+ devices. > > In long run, all these attributes should come from hwmod dev_attr based > on DMA IP version. > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/mach-omap2/dma.c | 2 +- > arch/arm/plat-omap/dma.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c > index b19d849..2750bb9 100644 > --- a/arch/arm/mach-omap2/dma.c > +++ b/arch/arm/mach-omap2/dma.c > @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) > > dma_stride = OMAP2_DMA_STRIDE; > dma_common_ch_start = CSDP; > - if (cpu_is_omap3630() || cpu_is_omap44xx()) > + if (omap_rev() >= OMAP3630_REV_ES1_0) It's not obvious (at least to me) that this is equivalent. For example, this will now be true on the TI81xx devices. Kevin
"Shilimkar, Santosh" <santosh.shilimkar@ti.com> writes: > On Fri, May 4, 2012 at 3:17 AM, Kevin Hilman <khilman@ti.com> wrote: >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes: >> >>> cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code >>> cpu checks accordingly so that there is no need to patch >>> the file for any future OMAP2+ devices. >>> >>> In long run, all these attributes should come from hwmod dev_attr based >>> on DMA IP version. >>> >>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >>> --- >>> arch/arm/mach-omap2/dma.c | 2 +- >>> arch/arm/plat-omap/dma.c | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c >>> index b19d849..2750bb9 100644 >>> --- a/arch/arm/mach-omap2/dma.c >>> +++ b/arch/arm/mach-omap2/dma.c >>> @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) >>> >>> dma_stride = OMAP2_DMA_STRIDE; >>> dma_common_ch_start = CSDP; >>> - if (cpu_is_omap3630() || cpu_is_omap44xx()) >>> + if (omap_rev() >= OMAP3630_REV_ES1_0) >> >> It's not obvious (at least to me) that this is equivalent. >> >> For example, this will now be true on the TI81xx devices. >> > I see your point. > On second thought, i decided to drop this hunk from the patch since > the availability of the dma descriptor feature can be read from dma > capability register. Will post another patch for it and also add it to > the clean-up series. > > Updated $subject patch in the end of email. > > Regards > Santosh > > From e42966bc56b1603e033b5b259564ae149b11a5d9 Mon Sep 17 00:00:00 2001 > From: Santosh Shilimkar <santosh.shilimkar@ti.com> > Date: Sat, 28 Apr 2012 20:19:10 +0530 > Subject: [PATCH 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to > avoid future patching. > > cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code > cpu checks accordingly so that there is no need to patch > the file for any future OMAP2+ devices. > > In long run, all these attributes should come from hwmod dev_attr based > on DMA IP version. > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > Dropped the hunk for descriptor feature check based on OMAP cpu > version since it can be handled with DMA hardware capability > register read. Right, this looks better. Thanks, Kevin
* Santosh Shilimkar <santosh.shilimkar@ti.com> [120502 02:51]: > This series has some miscellianeous clean up patches which help to add future > OMAP2+ device support with bit less changes. It is a preparatory series for > adding minimal OMAP5 support. Is this ready to be pulled? Tony
On Wed, 2 May 2012, Santosh Shilimkar wrote: > Since OMAP4 code base now makes use of OMAP4 specific PRCM functions, > cm2xxx_3xxx.c need not be compiled for OMAP4 only builds. > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Paul Walmsley <paul@pwsan.com> Will remove the stub functions in a separate patch. - Paul
On Wed, 2 May 2012, Santosh Shilimkar wrote: > From: R Sricharan <r.sricharan@ti.com> > > Instead of statically defining seperate arrays for every OMAP4+ archs, > have a generic init function to populate the arrays. This avoids the > need for creating new array for every arch added in the future that > reuses the prm and cm registers read/write code. > > Cc: Paul Walmsley <paul@pwsan.com> > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Thanks, looks reasonable, will queue this for 3.5. - Paul
On Tue, May 8, 2012 at 10:39 AM, Paul Walmsley <paul@pwsan.com> wrote: > On Wed, 2 May 2012, Santosh Shilimkar wrote: > >> Since OMAP4 code base now makes use of OMAP4 specific PRCM functions, >> cm2xxx_3xxx.c need not be compiled for OMAP4 only builds. >> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >> Cc: Paul Walmsley <paul@pwsan.com> > > Acked-by: Paul Walmsley <paul@pwsan.com> > > Will remove the stub functions in a separate patch. > ok
On Tue, May 8, 2012 at 10:45 AM, Paul Walmsley <paul@pwsan.com> wrote: > On Wed, 2 May 2012, Santosh Shilimkar wrote: > >> From: R Sricharan <r.sricharan@ti.com> >> >> Instead of statically defining seperate arrays for every OMAP4+ archs, >> have a generic init function to populate the arrays. This avoids the >> need for creating new array for every arch added in the future that >> reuses the prm and cm registers read/write code. >> >> Cc: Paul Walmsley <paul@pwsan.com> >> Signed-off-by: R Sricharan <r.sricharan@ti.com> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > > Thanks, looks reasonable, will queue this for 3.5. > Great. I will drop this one from my clean-up pull request. Regards Santosh
On Tuesday 08 May 2012 04:33 AM, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [120502 02:51]: >> This series has some miscellianeous clean up patches which help to add future >> OMAP2+ device support with bit less changes. It is a preparatory series for >> adding minimal OMAP5 support. > > Is this ready to be pulled? > Yes. I just sent a pull request to you after dropping [PATCH 7/7] since Paul is taking that in his 3.5 queue. Regards Santosh
This series has some miscellianeous clean up patches which help to add future OMAP2+ device support with bit less changes. It is a preparatory series for adding minimal OMAP5 support. Boot tested on below platforms: - OMAP2430 SDP - OMAP3430 SDP - OMAP4430 SDP Thanks for Tony and Benoit for these suggestions. The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: Linux 3.4-rc5 (2012-04-29 15:19:10 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap_misc_cleanup R Sricharan (1): ARM: OMAP4+: Add prm and cm base init function. Santosh Shilimkar (6): ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds. ARM: OMAP2+: Clean up wrapping multiple objects in Makefile ARM: OMAP4: Remove un-used WakeupGen register defines. ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching. ARM: All OMAP2PLUS machines use omap2 directory so just add one entry ARM: OMAP4: Reduce the static IO mapping arch/arm/Makefile | 4 +- arch/arm/mach-omap2/Makefile | 163 ++++++++++----------- arch/arm/mach-omap2/cminst44xx.c | 28 +++-- arch/arm/mach-omap2/common.c | 1 + arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/dma.c | 2 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 8 - arch/arm/mach-omap2/io.c | 30 ---- arch/arm/mach-omap2/iomap.h | 28 ---- arch/arm/mach-omap2/prcm-common.h | 13 ++ arch/arm/mach-omap2/prcm.c | 8 + arch/arm/mach-omap2/prminst44xx.c | 27 ++-- arch/arm/plat-omap/dma.c | 4 +- 13 files changed, 139 insertions(+), 178 deletions(-)