PM
To: R, Sricharan
Cc: linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org; linus.wall...@linaro.org; li...@arm.linux.org.uk;
t...@atomide.com; Nayak, Rajendra; marc.zyng...@arm.com;
grant.lik
Hi Thomas,
Again sorry for top post.
I agree and will fix both of the comments below.
Thanks for the reviews.
Regards,
Sricharan
From: Thomas Gleixner [t...@linutronix.de]
Sent: Wednesday, October 30, 2013 9:00 PM
To: R, Sricharan
Cc: linux-ker
Hi,
On Sunday 30 December 2012 02:13 AM, ahema...@gmail.com wrote:
From: ahemaily ahema...@gmail.com
The variable dma_lch_count used for comparison (omap_dma_reserve_channels =
dma_lch_count)
before it initialized to the value from omap_dma_dev_attr : d-lch_count.
I change the place of
Hi,
On Wednesday 19 December 2012 07:34 PM, Benoit Cousson wrote:
On 12/19/2012 02:58 PM, Luciano Coelho wrote:
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
BTW: have you
Hi Kevin,
In the latest, pad mux and clocks for all
non-essential modules at U-BOOT were removed.
This might also cause the problem.
We can bring this back in u-boot by adding the following macros
and check if it works fine again.
include/configs/omap4_common.h
Hi Tony,
[snip..]
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct
the boot with CMA and LPAE
enabled.
Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
[V2] Moved the loop to alloc_init_pte as per Russell's
feedback and changed the subject accordingly
/lkml/2012/6/28/112
The final conclusion from the thread seems to
be align the memblock_steal calls on the SECTION boundary.
The issue comes out when LPAE is enabled, where the
section size is 2MB.
Boot tested this on OMAP5 evm with and without LPAE.
Signed-off-by: R Sricharan r.sricha...@ti.com
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
[V2
...@ti.com wrote:
On 9/12/2012 1:50 AM, R Sricharan wrote:
Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
the feature is not getting selected.
Adding a string description in the Kconfig resolves this.
But not sure if this is the right way to fix this.
Shouldn't you
Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
the feature is not getting selected.
Adding a string description in the Kconfig resolves this.
But not sure if this is the right way to fix this.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
/lkml/2012/6/28/112
The final conclusion from the thread seems to
be align the memblock_steal calls on the SECTION boundary.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap-secure.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
---
arch/arm/plat-omap/counter_32k.c | 21
Hi Paul,
On Wed, Jul 4, 2012 at 8:49 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 28 Jun 2012, R, Sricharan wrote:
Ping..
Since the prcm.c cleanup series isn't ready yet, I've queued this modified
version of your patch.
Once the prcm.c cleanup series is ready, hopefully in the 3.7
Ping..
Thanks,
Sricharan
On Thu, Jun 14, 2012 at 5:26 PM, R, Sricharan r.sricha...@ti.com wrote:
Hi Paul,
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements
Hi David,
On Mon, Jun 25, 2012 at 2:17 AM, David Rientjes rient...@google.com wrote:
On Sat, 23 Jun 2012, R, Sricharan wrote:
Hi,
I am observing a below crash with VMALLOC call on mainline kernel.
The issue happens when there is insufficent vmalloc space.
Isn't it expected
Hi,
BTW i was facing the issue on OMAP4430 SDP platform with
mainline.
Thanks,
Sricharan
On Sat, Jun 23, 2012 at 11:28 AM, R, Sricharan r.sricha...@ti.com wrote:
Hi,
I am observing a below crash with VMALLOC call on mainline kernel.
The issue happens when there is insufficent vmalloc
Hi,
I am observing a below crash with VMALLOC call on mainline kernel.
The issue happens when there is insufficent vmalloc space.
Isn't it expected that the API should return a NULL instead of crashing when
there is not enough memory?. This can be reproduced with succesive vmalloc
calls
Hi Paul,
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
Tony,
Thanks for you suggestions
OMAP5 V2 series is ready with all comments addressed, but I have
below dependencies to be merged to apply my series against your
cleanup-soc branch
OK
1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5
This one is not merged in yet
Vaibhav,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8
Hi Vaibhav,
Sricharan,
Yesterday, Paul confirmed that, removing ifdef is the way to go. So
just few mins back I had submitted patch for the same.
http://permalink.gmane.org/gmane.linux.ports.arm.omap/76972
oh ya, was just looking at that.
Thanks,
Sricharan
--
To unsubscribe from this
Tony,
[snip]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Well it seems that we've come to a conclusion
Hi Roger,
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+
Hi J,
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+
omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm
This is a continuation of the previous cleanup series from
santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5
review suggestions from Tony/Benoit/Santosh/Rajendra.
[1] http://www.spinics.net/lists/linux-omap/msg69730.html
R Sricharan (4):
ARM: OMAP2+: Introduce
place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/cminst44xx.h | 25
arch/arm/mach-omap2/prcm.c | 77
applicable SOC. This
makes it nessecary to add new a check for every new SOC added
in the future.
So by introducing a new SOC_HAS_OMAP_DPLL config such new #ifdefs
can be avoided for the future socs and also to cleanup the existing
ifdefferies.
Signed-off-by: R Sricharan r.sricha...@ti.com
.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/plat-omap/counter_32k.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index b2f634b..cbd939d 100644
--- a/arch/arm/plat-omap
Tony,
[snip]
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
Tony,
On Mon, May 7, 2012 at 11:04 PM, Tony Lindgren t...@atomide.com wrote:
* R, Sricharan r.sricha...@ti.com [120506 00:42]:
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i
Hi Benoit,
Thanks for the reviews.
Adding the minimal support for OMAP5 soc with device tree.
You should probably split that patch since you are doing several things that
are not OMAP5 related.
Do a patch that move the omap_init_irq into the INTC and GIC code first.
Then, you can add
Hi Tony,
[snip]
OK this seems to be based on Santosh' Makefile cleanup.
yes..
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) || \
+ defined(CONFIG_ARCH_OMAP5)
How about we add
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
Isn't there some unnecessary parens here?
You mean in this above for loop?.
There are multiple statements .
Thanks,
Hi Tony,
- select NEON if ARCH_OMAP3 || ARCH_OMAP4
+ select NEON if ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5
select SERIAL_OMAP
select SERIAL_OMAP_CONSOLE
select I2C
If we add CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS, then
this becomes more future proof with
The system dma module has capabiities register indicating
the support for descriptor loading, constant fill, etc.
Use this instead of OMAP revision check to identify the features
supported runtime.
This avoids patching the code for feature SOCs which has
those capabilities.
Signed-off-by: R
Adding the build support required for OMAP5 soc
in to omap2+ config.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/configs/omap2plus_defconfig |2 ++
arch/arm/mach-omap2/Kconfig | 13 -
arch/arm
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/gpmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index
Not for merge.
Just update the base address of the counter for
OMAP5 soc.
This patch will no longer be needed after rebasing on top of below
series from Vaibhav Hiremath hvaib...@ti.com.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html
Signed-off-by: R Sricharan r.sricha
-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7144ae6..4063a8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
Adding the Initialisaton for clocksource and clockevent device
on OMAP5 Socs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/timer.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2
Adding the minimum device tree files required for
OMAP5 to boot.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 +
arch/arm/boot/dts/omap5-evm.dts| 20 ++
arch/arm/boot/dts/omap5.dtsi | 201
* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 +
arch/arm/mach-omap2/omap-hotplug.c
From: Tarun Kanti DebBarma tarun.ka...@ti.com
OMAP5 has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile | 26
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Makefile |1
Adding the minimal support for OMAP5 soc with device tree.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 39 +-
arch/arm/mach-omap2/common.h|2 +
arch/arm/mach-omap2/irq.c | 11 +
arch/arm
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h
/msg69233.html
[2] http://www.spinics.net/lists/linux-omap/msg69013.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html
R Sricharan (10):
ARM: OMAP5: id: Add cpu id for ES versions
ARM: OMAP5: Add minimal support for OMAP5430 SOC
TEMP: ARM: OMAP5: Add cpu_is_omap54xx
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47
-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 44f4a09..0511238 100644
,
commit 9f97da78bf018206fb623cd351d454af2f105fe0
Author: David Howells dhowe...@redhat.com
Date: Wed Mar 28 18:30:01 2012 +0100
Disintegrate asm/system.h for ARM
Disintegrate asm/system.h for ARM.
Fixing this here.
Signed-off-by: R Sricharan r.sricha
] undefined!
ERROR: omap_bus_sync [drivers/mtd/nand/omap2.ko] undefined!
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap4-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4
Hi Paul,
Hello Sricharan,
It looks like Archit is out of the office. Would it be possible for you
to test the updated DSS reset patch, below?
Ok. I will test this.
I have tested the patch from,
git://gitorious.org/linux-omap-dss2/linux.git
MASTER branch.
I tested
Paul,
On Tue, Oct 4, 2011 at 2:18 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Sricharan,
It looks like Archit is out of the office. Would it be possible for you
to test the updated DSS reset patch, below?
Ok. I will test this.
snip ..
Thanks,
Sricharan
--
To unsubscribe from this
Sorry resending again. My mailer settings thrashed my earlier email.
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the below
scenario.
In file net/sunrpc/xprtsock.c,
static int
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, November 19, 2010 2:56 AM
To: Cousson, Benoit
Cc: R, Sricharan; linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
* Cousson, Benoit b-cous...@ti.com [101118 12:56
Adding people in CC.
This series updates the core device drivers to use mux framework
for OMAP4 SDP and PANDA board. It's generated against the
linux-omap master branch. It has a dependency on the Benoit's
omap4 mux data series.
http://www.spinics.net/lists/linux-omap/msg40039.html
59 matches
Mail list logo
