Re: [PATCH 5/6] ARM: OMAP4: CLKDM: Update supported transition modes
On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...
NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep transition. The transition is
initiated
when the associated hardware conditions are satisfied
SW_WKUP (0x2) - A software-forced clock domain wake-up transition is
initiated,
irrespective of the hardware conditions.
HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is
initiated by the PRCM module when the associated hardware
conditions are satisfied.
For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is
equivalent
to SW_WKUP. For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can
place the CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we
do not need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it
is
preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
instead of NO_SLEEP where possible.
For a software perspective the above 4 modes are represented by the following
flags to indicate what modes are supported by each of the CLKDMs.
CLKDM_CAN_DISABLE_AUTO-- NO_SLEEP
CLKDM_CAN_ENABLE_AUTO -- HW_AUTO
CLKDM_CAN_FORCE_SLEEP -- SW_SLEEP
CLKDM_CAN_FORCE_WAKEUP-- SW_WKUP
By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4
devices
can becomes ...
CLKDM_CAN_DISABLE_AUTO-- NO_SLEEP
CLKDM_CAN_ENABLE_AUTO -- HW_AUTO
CLKDM_CAN_FORCE_SLEEP -- HW_AUTO
Not sure if this can be entirely correct for OMAP4.
Because HW_AUTO = Sleep and wakeup transition are
based upon hardware conditions
Where as SW_SLEEP = Start a software forced sleep
transition on the domain.
I will reply on the the thread where this is being discussed.
CLKDM_CAN_FORCE_WAKEUP-- SW_WKUP
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clockdomain44xx.c |7 +--
arch/arm/mach-omap2/cminst44xx.c | 14 --
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index 4f04dd1..99ce556 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -70,7 +70,7 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
static int omap4_clkdm_sleep(struct clockdomain *clkdm)
{
- omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
+ omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
In case SW_SLEEP != HW_AUTO, something like below can be done
if (clkdm-flags CLKDM_CAN_FORCE_SLEEP )
omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
else
omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
return 0;
}
@@ -90,7 +90,10 @@ static void omap4_clkdm_allow_idle(struct clockdomain
*clkdm)
static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
{
- omap4_cminst_clkdm_disable_hwsup(clkdm-prcm_partition,
+ if (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)
+ omap4_clkdm_wakeup(clkdm);
+ else
+ omap4_cminst_clkdm_disable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
}
diff --git a/arch/arm/mach-omap2/cminst44xx.c
b/arch/arm/mach-omap2/cminst44xx.c
index bd8810c..a44456c 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -227,20 +227,6 @@ void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst,
u16 cdoffs)
}
/**
- * omap4_cminst_clkdm_force_sleep - try to put a clockdomain into idle
- * @part: PRCM partition ID that the clockdomain registers exist in
- * @inst: CM instance register offset (*_INST macro)
- * @cdoffs: Clockdomain register offset (*_CDOFFS macro)
- *
- * Put a clockdomain referred to by (@part, @inst, @cdoffs) into idle
- * No return value.
- */
-void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
-{
- _clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, part, inst, cdoffs);
-}
-
-/**
* omap4_cminst_clkdm_force_sleep - try to take a clockdomain out of idle
* @part: PRCM partition ID that the clockdomain registers exist in
* @inst: CM instance register offset (*_INST macro)
--
To unsubscribe from this list: send the line
Re: oprofile and ARM A9 hardware counter
Benoit,
On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wednesday 09 May 2012 09:18 PM, Russell King - ARM Linux wrote: On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote: On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote: The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined. Some implementations used the bit to mean allow writes to update the cache. Other implementations labelled this bit as should be zero while others labelled it as should be one. Good to know. The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react. I agree. The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value. I'll sort out a patch later today for this. Great. This works for my 4430SDP board. I haven't booted it on anything else yet. Please can you check that this solves the issue for you? Thanks. Yes it does. Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix Either is fine with me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Thursday 10 May 2012 02:23 PM, Russell King - ARM Linux wrote: On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote: Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix I don't see any point in splitting this up, especially as the ARMv7 fix would involve merely changing two lines (the domain register value and the value passed into __setup_mmu via r6.) Fine with me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On Thursday 10 May 2012 05:18 PM, Roger Quadros wrote: On 05/10/2012 02:42 PM, Shilimkar, Santosh wrote: On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote: Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: From: Santosh Shilimkar santosh.shilim...@ti.com OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5. - Additional 32 interrupt support is added w.r.t OMAP4 design. - The AUX CORE boot registers are now made accessible from non-secure SW. - SAR offset are changed and PTMSYNC* 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| 24 - arch/arm/mach-omap2/omap-smp.c| 19 +++- arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++- arch/arm/mach-omap2/omap4-sar-layout.h| 12 ++- 5 files changed, 135 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index 548de90..4d700bc 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -11,15 +11,20 @@ #ifndef OMAP_ARCH_WAKEUPGEN_H #define OMAP_ARCH_WAKEUPGEN_H +/* OMAP4 and OMAP5 has same base address */ +#define OMAP_WKUPGEN_BASE0x48281000 unnecessary change, why don't you just use OMAP44XX_WKUPGEN_BASE or define this in the same header as OMAP44XX_WKUPGEN_BASE? Just to avoid confusion about OMAP44XX and OMAP54XX. It's cleaner to remove the OMAP44XX reference if the base is generic and not depend on OMAP4/5. It's not un-necessary change as such. OK, is OMAP_WKUPGEN_BASE applicable for OMAPs prior to OMAP4? If not the naming scheme does not look appropriate. It's IP exist on OMAP4/5 and future OMAPs, no name is fine. Btw, if you go on that route you will too many examples of non appropriate names. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: Misc cleanup
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP platforms.
I have dropped {[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function}
from this set since Paul is taking that one in his queue.
P.S: While merging this series with linux-omap master, I saw one trivial
Makefile conflict.
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: OMAP2+: dma: Define dma capabilities register bitfields and use them.
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/dma.c | 11 +-
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/plat-omap/dma.c |4 +-
arch/arm/plat-omap/include/plat/dma.h |5 +
8 files changed, 93 insertions(+), 160 deletions(-)
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: OMAP2+: Misc cleanup
On Tuesday 08 May 2012 04:33 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
On Tuesday 08 May 2012 03:56 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]: Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/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 Do you have a branch where above dependencies are merged ? Seems like those should go into the cleanup branch, and then that can be used as a base. Yep. That will be a good base. How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Probably the DT patch should be separate, we can make dt branch depend on the cleanup branch. Sounds good. Btw, who is re-basing the omap-dt branch against 3.4 ? Then the data files should be first posted for reviews (and potentially updated for what we have queued in hwmod-cleanup). Does this series compile on it's own without the data now? This series does compile on it's own without data patches. Data patches needs to re-based against Paul's clean-up and also we need to sort out ES1/ES2 diff so they can wait till then. Probably 3.6+ This series was intentionally made in such a way that it can be merged without data patches. Just for getting boot working on OMAP5 data patches needs to be merged. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] ARM: OMAP5: Add SMP support.
On Tuesday 08 May 2012 06:17 PM, Will Deacon wrote:
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
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 |1 +
arch/arm/mach-omap2/omap-headsmp.S | 21 ++
arch/arm/mach-omap2/omap-smp.c | 41
+--
3 files changed, 51 insertions(+), 12 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 151fd5b..9424bb6 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,10 @@
#include common.h
#include clockdomain.h
+#define CPU_MASK0xff00
+#define CPU_CORTEX_A9 0x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
/* SCU base address */
static void __iomem *scu_base;
@@ -43,6 +47,14 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+static inline unsigned int get_a15_core_count(void)
+{
+unsigned int ncores;
+
+asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r (ncores));
+return ((ncores 24) 3) + 1;
+}
This register (L2 control) only tells you how many cores you have hanging
off the L2 cache, which isn't really viable for future multi-cluster
configurations. You're probably better off either reading the number of CPU
nodes out of the DT (ppc, vexpress) or returning a constant for now
(exynos5).
Thanks will for the information. I agree for the future multiple
packages, this register may not be good enough. We can hard-code
it as well for now.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote: On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote: From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..a2602b8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,12 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size -mov r1, #0x12 +mov r1, #0x02 @ Default executable section I think it is simpler if you leave the original code here (with XN) Sounds good. With that updated can I add your ack and push it to the patch system ? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On Saturday 05 May 2012 04:25 AM, Tony Lindgren wrote:
* R Sricharan r.sricha...@ti.com [120503 00:30]:
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/smp.h
+#include linux/io.h
#include asm/cacheflush.h
+#include mach/omap-wakeupgen.h
#include common.h
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)
*/
void __ref platform_cpu_die(unsigned int cpu)
{
-unsigned int this_cpu;
+unsigned int boot_cpu = 0;
+void __iomem *base = omap_get_wakeupgen_base();
flush_cache_all();
dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)
/*
* we're ready for shutdown now, so do it
*/
-if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
-pr_err(Secure clear status failed\n);
+if (cpu_is_omap44xx()) {
+if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+pr_err(Secure clear status failed\n);
+} else {
+__raw_writel(0, base + OMAP_AUX_CORE_BOOT_0);
+}
+
for (;;) {
/*
* Enter into low power state
*/
omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
-this_cpu = smp_processor_id();
-if (omap_read_auxcoreboot0() == this_cpu) {
+
+if (cpu_is_omap44xx())
+boot_cpu = omap_read_auxcoreboot0();
+else
+boot_cpu =
+__raw_readl(base + OMAP_AUX_CORE_BOOT_0) 5;
+
+if (boot_cpu == smp_processor_id()) {
/*
* OK, proper wakeup, we're done
*/
These should use variables set up during init instead of cpu_is_omapxxx
checks.
Sounds good. Will fit it.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/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 Do you have a branch where above dependencies are merged ? How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
From: R Sricharan r.sricha...@ti.com ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective. A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..4dc799b 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,7 +578,7 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x32 @ set domain1, XN, valid orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM @@ -587,8 +587,10 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size #else orrhs r1, r1, #0x0c @ set cacheable, bufferable #endif + bichs r1, r1, #0x20 @ set domain0 for DRAM cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable + orrhs r1, r1, #0x20 @ set domain1 str r1, [r0], #4@ 1:1 mapping add r1, r1, #1048576 teq r0, r2 @@ -658,6 +660,9 @@ __armv7_mmu_cache_on: movne r1, #-1 mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer mcrne p15, 0, r1, c3, c0, 0 @ load domain access control + bic r1, r1, #0xc + orr r1, r1, #0x4 + mcr p15, 0, r1, c3, c0, 0 @ set domain1 as client #endif mcr p15, 0, r0, c7, c5, 4 @ ISB mcr p15, 0, r0, c1, c0, 0 @ load control register -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver
On Friday 04 May 2012 05:33 AM, Greg KH wrote: On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote: On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs Hi Santosh, Can you send Greg a patch that adds proper dependencies to the Kconfig? I was going to simply add an ARM dependency, but perhaps you want to restrict it further to a subset of OMAP platforms? Thanks Paul for reporting the issue. At the moment it is causing build failures in other architectures. http://kisskb.ellerman.id.au/kisskb/buildresult/6243036/ I think there's a config option for readl/writel, but yes, ARM would probably be fine as well. Just send a patch [1] to Greg. EMIF driver build is restricted to ARCH_OMAP2PLUS for now and can be extended later if any other non OMAP architecture start using it. Regards Santosh [1] https://lkml.org/lkml/2012/5/4/22 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] gpio/omap: remove virtual_irq_start variable
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote: This cleanup got missed while implementing following: 25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ 384ebe1 gpio/omap: Add DT support to GPIO driver Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- arch/arm/mach-omap1/gpio15xx.c |2 -- arch/arm/mach-omap1/gpio16xx.c |5 - arch/arm/mach-omap1/gpio7xx.c |7 --- arch/arm/mach-omap2/gpio.c |1 - arch/arm/plat-omap/include/plat/gpio.h |1 - 5 files changed, 0 insertions(+), 16 deletions(-) Looks good. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] gpio/omap: remove cpu_is_omapxxxx() checks from *_runtime_resume()
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote: Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0 which are present on OMAP4+ processors. Now we can distinguish conditions applicable to OMAP4,5 and those specific to OMAP24xx and OMAP3xxx. Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- arch/arm/mach-omap2/gpio.c |2 ++ arch/arm/plat-omap/include/plat/gpio.h |2 ++ drivers/gpio/gpio-omap.c |4 ++-- 3 files changed, 6 insertions(+), 2 deletions(-) Looks like this was the last cpu_is_*() in gpio driver. Thanks for cleaning up this. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote: We do checking for bank-enabled_non_wakeup_gpios in order to skip redundant operations. Somehow, the check got missed while doing the cleanup series. Just to make sure that we do context restore correctly in *_runtime_resume(), the bank-workaround_enabled check is moved after context restore. Otherwise, it would prevent context restore when bank-enabled_non_wakeup_gpios is 0. Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Looks good. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] gpio/omap: remaining cleanups and fix
Tarun,
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
Test info:
OMAP2+ platforms: OMAP2430SDP, OMAP3430SDP, OMAP4430SDP
OMAP1: Bootup test on OMAP1710SDP.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Tarun Kanti DebBarma (8):
gpio/omap: remove virtual_irq_start variable
gpio/omap: remove saved_fallingdetect, saved_risingdetect
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: remove retrigger variable in gpio_irq_handler
gpio/omap: remove suspend/resume callbacks
gpio/omap: remove cpu_is_omap() checks from *_runtime_resume()
gpio/omap: fix missing check in *_runtime_suspend()
I have reviewed the remaining 3 patches from this series.
Thanks.
Regards
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] ARM: OMAP2+: Misc cleanup
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(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds.
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.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 49f92bc..56ed62e 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -86,10 +86,7 @@ obj-y+= prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \ vc3xxx_data.o vp3xxx_data.o -# XXX The presence of cm2xxx_3xxx.o on the line below is temporary and -# will be removed once the OMAP4 part of the codebase is converted to -# use OMAP4-specific PRCM functions. -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ +obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o \ cm44xx.o prcm_mpu44xx.o \ prminst44xx.o vc44xx_data.o \ vp44xx_data.o prm44xx.o -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ARM: OMAP4: Remove un-used WakeupGen register defines.
Current OMAP code doesn't use any of the OMAP_WKG_ENB_SECURE_* registers. So remove those defines. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index d79321b..548de90b 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -16,18 +16,10 @@ #define OMAP_WKG_ENB_B_0 0x14 #define OMAP_WKG_ENB_C_0 0x18 #define OMAP_WKG_ENB_D_0 0x1c -#define OMAP_WKG_ENB_SECURE_A_00x20 -#define OMAP_WKG_ENB_SECURE_B_00x24 -#define OMAP_WKG_ENB_SECURE_C_00x28 -#define OMAP_WKG_ENB_SECURE_D_00x2c #define OMAP_WKG_ENB_A_1 0x410 #define OMAP_WKG_ENB_B_1 0x414 #define OMAP_WKG_ENB_C_1 0x418 #define OMAP_WKG_ENB_D_1 0x41c -#define OMAP_WKG_ENB_SECURE_A_10x420 -#define OMAP_WKG_ENB_SECURE_B_10x424 -#define OMAP_WKG_ENB_SECURE_C_10x428 -#define OMAP_WKG_ENB_SECURE_D_10x42c #define OMAP_AUX_CORE_BOOT_0 0x800 #define OMAP_AUX_CORE_BOOT_1 0x804 #define OMAP_PTMSYNCREQ_MASK 0xc00 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
Signed-off-by: Santosh Shilimkar santosh.shilim...@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 plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -64,10 +65,10 @@ endif ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \ - cpuidle34xx.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \ - cpuidle44xx.o +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o +obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o @@ -84,85 +85,84 @@ endif # PRCM obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \ - vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o \ - cm44xx.o prcm_mpu44xx.o \ - prminst44xx.o vc44xx_data.o \ - vp44xx_data.o prm44xx.o +obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o +obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o +obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o +obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o -obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \ - voltagedomains2xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \ - voltagedomains3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ - voltagedomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP2) += voltagedomains2xxx_data.o +obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) +obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o -obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) \ - powerdomain2xxx_3xxx.o \ - powerdomains2xxx_data.o \ - powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) \ - powerdomain2xxx_3xxx.o \ - powerdomains3xxx_data.o \ - powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \ - powerdomain44xx.o \ - powerdomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) +obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_data.o +obj-$(CONFIG_ARCH_OMAP2) += powerdomain2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_3xxx_data.o +obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) +obj-$(CONFIG_ARCH_OMAP3) += powerdomain2xxx_3xxx.o +obj
[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.shilim...@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) dma_common_ch_end = CCDN; else dma_common_ch_end = CCFN; diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ecdb3da..c046a19 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -843,7 +843,7 @@ omap_dma_set_prio_lch(int lch, unsigned char read_prio, } l = p-dma_read(CCR, lch); l = ~((1 6) | (1 26)); - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) l |= ((read_prio 0x1) 6) | ((write_prio 0x1) 26); else l |= ((read_prio 0x1) 6); @@ -2057,7 +2057,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev) } } - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) omap_dma_set_global_params(DMA_DEFAULT_ARB_RATE, DMA_DEFAULT_FIFO_DEPTH, 0); -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: OMAP4: Reduce the static IO mapping
EMIF, GMPC and DMM driver can ioremap() the address
space as part of driver intialisation and there is
no need to have static IO mapping for them.
Hence remove the un-used static IP space and let
the respective drivers manage it as part if driver
init.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/io.c| 30 --
arch/arm/mach-omap2/iomap.h | 28
2 files changed, 0 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 065bd76..595a5dd 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -215,41 +215,11 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.type = MT_DEVICE,
},
{
- .virtual= OMAP44XX_GPMC_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_GPMC_PHYS),
- .length = OMAP44XX_GPMC_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_EMIF1_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_EMIF1_PHYS),
- .length = OMAP44XX_EMIF1_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_EMIF2_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_EMIF2_PHYS),
- .length = OMAP44XX_EMIF2_SIZE,
- .type = MT_DEVICE,
- },
- {
- .virtual= OMAP44XX_DMM_VIRT,
- .pfn= __phys_to_pfn(OMAP44XX_DMM_PHYS),
- .length = OMAP44XX_DMM_SIZE,
- .type = MT_DEVICE,
- },
- {
.virtual= L4_PER_44XX_VIRT,
.pfn= __phys_to_pfn(L4_PER_44XX_PHYS),
.length = L4_PER_44XX_SIZE,
.type = MT_DEVICE,
},
- {
- .virtual= L4_EMU_44XX_VIRT,
- .pfn= __phys_to_pfn(L4_EMU_44XX_PHYS),
- .length = L4_EMU_44XX_SIZE,
- .type = MT_DEVICE,
- },
#ifdef CONFIG_OMAP4_ERRATA_I688
{
.virtual= OMAP4_SRAM_VA,
diff --git a/arch/arm/mach-omap2/iomap.h b/arch/arm/mach-omap2/iomap.h
index 0812b15..80b8892 100644
--- a/arch/arm/mach-omap2/iomap.h
+++ b/arch/arm/mach-omap2/iomap.h
@@ -37,9 +37,6 @@
#define OMAP4_L3_PER_IO_OFFSET 0xb110
#define OMAP4_L3_PER_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
-#define OMAP4_GPMC_IO_OFFSET 0xa900
-#define OMAP4_GPMC_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_GPMC_IO_OFFSET)
-
#define OMAP2_EMU_IO_OFFSET0xaa80 /* Emulation */
#define OMAP2_EMU_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_EMU_IO_OFFSET)
@@ -170,28 +167,3 @@
#define L4_ABE_44XX_VIRT (L4_ABE_44XX_PHYS + OMAP2_L4_IO_OFFSET)
#define L4_ABE_44XX_SIZE SZ_1M
-#define L4_EMU_44XX_PHYS L4_EMU_44XX_BASE
- /* 0x5400 -- 0xfe80 */
-#define L4_EMU_44XX_VIRT (L4_EMU_44XX_PHYS + OMAP2_EMU_IO_OFFSET)
-#define L4_EMU_44XX_SIZE SZ_8M
-
-#define OMAP44XX_GPMC_PHYS OMAP44XX_GPMC_BASE
- /* 0x5000 -- 0xf900 */
-#define OMAP44XX_GPMC_VIRT (OMAP44XX_GPMC_PHYS + OMAP4_GPMC_IO_OFFSET)
-#define OMAP44XX_GPMC_SIZE SZ_1M
-
-
-#define OMAP44XX_EMIF1_PHYSOMAP44XX_EMIF1_BASE
- /* 0x4c00 -- 0xfd10 */
-#define OMAP44XX_EMIF1_VIRT(OMAP44XX_EMIF1_PHYS + OMAP4_L3_PER_IO_OFFSET)
-#define OMAP44XX_EMIF1_SIZESZ_1M
-
-#define OMAP44XX_EMIF2_PHYSOMAP44XX_EMIF2_BASE
- /* 0x4d00 -- 0xfd20 */
-#define OMAP44XX_EMIF2_SIZESZ_1M
-#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF1_VIRT + OMAP44XX_EMIF1_SIZE)
-
-#define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
- /* 0x4e00 -- 0xfd30 */
-#define OMAP44XX_DMM_SIZE SZ_1M
-#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + OMAP44XX_EMIF2_SIZE)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ARM: All OMAP2PLUS machines use omap2 directory so just add one entry
All OMAP2PLUS arch based machines makes use of mach-omap2 directory. So just add one entry so that there is no need to patch this file for any OMAP2+ devices. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 047a207..7a6bde0 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -164,9 +164,7 @@ machine-$(CONFIG_ARCH_MXS) := mxs machine-$(CONFIG_ARCH_NETX):= netx machine-$(CONFIG_ARCH_NOMADIK) := nomadik machine-$(CONFIG_ARCH_OMAP1) := omap1 -machine-$(CONFIG_ARCH_OMAP2) := omap2 -machine-$(CONFIG_ARCH_OMAP3) := omap2 -machine-$(CONFIG_ARCH_OMAP4) := omap2 +machine-$(CONFIG_ARCH_OMAP2PLUS) := omap2 machine-$(CONFIG_ARCH_ORION5X) := orion5x machine-$(CONFIG_ARCH_PICOXCELL) := picoxcell machine-$(CONFIG_ARCH_PNX4008) := pnx4008 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function.
From: R Sricharan r.sricha...@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 p...@pwsan.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
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/prcm-common.h | 13 +
arch/arm/mach-omap2/prcm.c|8
arch/arm/mach-omap2/prminst44xx.c | 27 ---
6 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index bd8810c..8c86d29 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -32,6 +32,7 @@
#include prcm44xx.h
#include prm44xx.h
#include prcm_mpu44xx.h
+#include prcm-common.h
/*
* CLKCTRL_IDLEST_*: possible values for the CM_*_CLKCTRL.IDLEST bitfield:
@@ -49,14 +50,21 @@
#define CLKCTRL_IDLEST_INTERFACE_IDLE 0x2
#define CLKCTRL_IDLEST_DISABLED0x3
-static u32 _cm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
- [OMAP4430_INVALID_PRCM_PARTITION] = 0,
- [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE,
- [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE,
- [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE,
- [OMAP4430_SCRM_PARTITION] = 0,
- [OMAP4430_PRCM_MPU_PARTITION] = OMAP4430_PRCM_MPU_BASE,
-};
+static void __iomem *_cm_bases[OMAP4_MAX_PRCM_PARTITIONS];
+
+/**
+ * omap_cm_base_init - Populates the cm partitions
+ *
+ * Populates the base addresses of the _cm_bases
+ * array used for read/write of cm module registers.
+ */
+void omap_cm_base_init(void)
+{
+ _cm_bases[OMAP4430_PRM_PARTITION] = prm_base;
+ _cm_bases[OMAP4430_CM1_PARTITION] = cm_base;
+ _cm_bases[OMAP4430_CM2_PARTITION] = cm2_base;
+ _cm_bases[OMAP4430_PRCM_MPU_PARTITION] = prcm_mpu_base;
+}
/* Private functions */
@@ -106,7 +114,7 @@ u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- return __raw_readl(OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ return __raw_readl(_cm_bases[part] + inst + idx);
}
/* Write into a register in a CM instance */
@@ -115,7 +123,7 @@ void omap4_cminst_write_inst_reg(u32 val, u8 part, s16
inst, u16 idx)
BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- __raw_writel(val, OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ __raw_writel(val, _cm_bases[part] + inst + idx);
}
/* Read-modify-write a register in CM1. Caller must lock */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..8a6953a 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -166,6 +166,7 @@ static struct omap_globals omap4_globals = {
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
.cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
};
void __init omap2_set_globals_443x(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..0672fc5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -111,6 +111,7 @@ struct omap_globals {
void __iomem*prm;/* Power and Reset Management */
void __iomem*cm; /* Clock Management */
void __iomem*cm2;
+ void __iomem*prcm_mpu;
};
void omap2_set_globals_242x(void);
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 5aa5435..0b42143 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -410,6 +410,19 @@
extern void __iomem *prm_base;
extern void __iomem *cm_base;
extern void __iomem *cm2_base;
+extern void __iomem *prcm_mpu_base;
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5)
+extern void omap_prm_base_init(void);
+extern void omap_cm_base_init(void);
+#else
+static inline void omap_prm_base_init(void)
+{
+}
+static inline void omap_cm_base_init(void)
+{
+}
+#endif
/**
* struct omap_prcm_irq - describes a PRCM interrupt bit
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 626acfa..480f40a 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -42,6 +42,7 @@
void
Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver
Greg, On Wednesday 02 May 2012 10:46 AM, Greg KH wrote: On Fri, Apr 27, 2012 at 05:54:02PM +0530, Santosh Shilimkar wrote: Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com This all looks good to me now, thanks for reworking this. So, do you want me to take this through my driver tree to get to Linus for 3.5, or do you want it to go through somewhere else? If somewhere else, that's fine with me, consider this an: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org If you want me to take it, just let me know, whichever you prefer is fine with me. Can you take this one through your 3.5 driver tree please ? Thanks for help. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/7] ddr: add LPDDR2 data from JESD209-2
From: Aneesh V ane...@ti.com add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers. Right now this is used by the TI EMIF SDRAM controller driver. Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- include/memory/jedec_ddr.h | 175 lib/Kconfig|8 ++ lib/Makefile |2 + lib/jedec_ddr_data.c | 135 ++ 4 files changed, 320 insertions(+), 0 deletions(-) create mode 100644 include/memory/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c diff --git a/include/memory/jedec_ddr.h b/include/memory/jedec_ddr.h new file mode 100644 index 000..ddad0f8 --- /dev/null +++ b/include/memory/jedec_ddr.h @@ -0,0 +1,175 @@ +/* + * Definitions for DDR memories based on JEDEC specs + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Aneesh V ane...@ti.com + * + * 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 + * published by the Free Software Foundation. + */ +#ifndef __LINUX_JEDEC_DDR_H +#define __LINUX_JEDEC_DDR_H + +#include linux/types.h + +/* DDR Densities */ +#define DDR_DENSITY_64Mb 1 +#define DDR_DENSITY_128Mb 2 +#define DDR_DENSITY_256Mb 3 +#define DDR_DENSITY_512Mb 4 +#define DDR_DENSITY_1Gb5 +#define DDR_DENSITY_2Gb6 +#define DDR_DENSITY_4Gb7 +#define DDR_DENSITY_8Gb8 +#define DDR_DENSITY_16Gb 9 +#define DDR_DENSITY_32Gb 10 + +/* DDR type */ +#define DDR_TYPE_DDR2 1 +#define DDR_TYPE_DDR3 2 +#define DDR_TYPE_LPDDR2_S4 3 +#define DDR_TYPE_LPDDR2_S2 4 +#define DDR_TYPE_LPDDR2_NVM5 + +/* DDR IO width */ +#define DDR_IO_WIDTH_4 1 +#define DDR_IO_WIDTH_8 2 +#define DDR_IO_WIDTH_163 +#define DDR_IO_WIDTH_324 + +/* Number of Row bits */ +#define R9 9 +#define R1010 +#define R1111 +#define R1212 +#define R1313 +#define R1414 +#define R1515 +#define R1616 + +/* Number of Column bits */ +#define C7 7 +#define C8 8 +#define C9 9 +#define C1010 +#define C1111 +#define C1212 + +/* Number of Banks */ +#define B1 0 +#define B2 1 +#define B4 2 +#define B8 3 + +/* Refresh rate in nano-seconds */ +#define T_REFI_15_615600 +#define T_REFI_7_8 7800 +#define T_REFI_3_9 3900 + +/* tRFC values */ +#define T_RFC_90 9 +#define T_RFC_110 11 +#define T_RFC_130 13 +#define T_RFC_160 16 +#define T_RFC_210 21 +#define T_RFC_300 30 +#define T_RFC_350 35 + +/* Mode register numbers */ +#define DDR_MR00 +#define DDR_MR11 +#define DDR_MR22 +#define DDR_MR33 +#define DDR_MR44 +#define DDR_MR55 +#define DDR_MR66 +#define DDR_MR77 +#define DDR_MR88 +#define DDR_MR99 +#define DDR_MR10 10 +#define DDR_MR11 11 +#define DDR_MR16 16 +#define DDR_MR17 17 +#define DDR_MR18 18 + +/* + * LPDDR2 related defines + */ + +/* MR4 register fields */ +#define MR4_SDRAM_REF_RATE_SHIFT 0 +#define MR4_SDRAM_REF_RATE_MASK7 +#define MR4_TUF_SHIFT 7 +#define MR4_TUF_MASK (1 7) + +/* MR4 SDRAM Refresh Rate field values */ +#define SDRAM_TEMP_NOMINAL 0x3 +#define SDRAM_TEMP_RESERVED_4 0x4 +#define SDRAM_TEMP_HIGH_DERATE_REFRESH 0x5 +#define SDRAM_TEMP_HIGH_DERATE_REFRESH_AND_TIMINGS 0x6 +#define SDRAM_TEMP_VERY_HIGH_SHUTDOWN 0x7 + +#define NUM_DDR_ADDR_TABLE_ENTRIES 11 +#define NUM_DDR_TIMING_TABLE_ENTRIES 4 + +/* Structure for DDR addressing info from
[PATCH v5 0/7] Add TI EMIF SDRAM controller driver
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com v5: - Moved the EMIF driver to drivers/memory as per discussion thread [2] v4: - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL - Removed un-necessary #ifndef __ASSEMBLY__' - Minor formatting fix v2: - Fixed a bug found in the implementation of errata i728 workaround - Fixed the value of frequency printed in debugfs - Dropped the hwmod patch as Paul has already posted a a hwmod series [1] that adds hwmod for EMIF - Converted instances of __init to __init_or_module Regards Santosh [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855 [2] https://lkml.org/lkml/2012/4/12/173 Aneesh V (7): ddr: add LPDDR2 data from JESD209-2 memory: emif: add register definitions for EMIF memory: emif: add basic infrastructure for EMIF driver memory: emif: handle frequency and voltage change events memory: emif: add interrupt and temperature handling memory: emif: add one-time settings memory: emif: add debugfs entries for emif Documentation/memory-devices/ti-emif.txt | 57 + drivers/Kconfig |4 + drivers/Makefile |3 + drivers/memory/Kconfig | 22 + drivers/memory/Makefile |5 + drivers/memory/emif.c| 1670 ++ drivers/memory/emif.h| 589 +++ include/linux/platform_data/emif_plat.h | 128 +++ include/memory/jedec_ddr.h | 175 lib/Kconfig |8 + lib/Makefile |2 + lib/jedec_ddr_data.c | 135 +++ 12 files changed, 2798 insertions(+), 0 deletions(-) create mode 100644 Documentation/memory-devices/ti-emif.txt create mode 100644 drivers/memory/Kconfig create mode 100644 drivers/memory/Makefile create mode 100644 drivers/memory/emif.c create mode 100644 drivers/memory/emif.h create mode 100644 include/linux/platform_data/emif_plat.h create mode 100644 include/memory/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 6/7] memory: emif: add one-time settings
From: Aneesh V ane...@ti.com
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 148 +
1 files changed, 148 insertions(+), 0 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index a8dcf35..3dfffbb 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -78,6 +78,24 @@ static void set_ddr_clk_period(u32 freq)
}
/*
+ * Get bus width used by EMIF. Note that this may be different from the
+ * bus width of the DDR devices used. For instance two 16-bit DDR devices
+ * may be connected to a given CS of EMIF. In this case bus width as far
+ * as EMIF is concerned is 32, where as the DDR bus width is 16 bits.
+ */
+static u32 get_emif_bus_width(struct emif_data *emif)
+{
+ u32 width;
+ void __iomem*base = emif-base;
+
+ width = (readl(base + EMIF_SDRAM_CONFIG) NARROW_MODE_MASK)
+NARROW_MODE_SHIFT;
+ width = width == 0 ? 32 : 16;
+
+ return width;
+}
+
+/*
* Get the CL from SDRAM_CONFIG register
*/
static u32 get_cl(struct emif_data *emif)
@@ -372,6 +390,70 @@ static u32 get_sdram_tim_3_shdw(const struct
lpddr2_timings *timings,
return tim3;
}
+static u32 get_zq_config_reg(const struct lpddr2_addressing *addressing,
+ bool cs1_used, bool cal_resistors_per_cs)
+{
+ u32 zq = 0, val = 0;
+
+ val = EMIF_ZQCS_INTERVAL_US * 1000 / addressing-tREFI_ns;
+ zq |= val ZQ_REFINTERVAL_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQCL_DEFAULT_NS, T_ZQCS_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQCL_MULT_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQINIT_DEFAULT_NS, T_ZQCL_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQINIT_MULT_SHIFT;
+
+ zq |= ZQ_SFEXITEN_ENABLE ZQ_SFEXITEN_SHIFT;
+
+ if (cal_resistors_per_cs)
+ zq |= ZQ_DUALCALEN_ENABLE ZQ_DUALCALEN_SHIFT;
+ else
+ zq |= ZQ_DUALCALEN_DISABLE ZQ_DUALCALEN_SHIFT;
+
+ zq |= ZQ_CS0EN_MASK; /* CS0 is used for sure */
+
+ val = cs1_used ? 1 : 0;
+ zq |= val ZQ_CS1EN_SHIFT;
+
+ return zq;
+}
+
+static u32 get_temp_alert_config(const struct lpddr2_addressing *addressing,
+ const struct emif_custom_configs *custom_configs, bool cs1_used,
+ u32 sdram_io_width, u32 emif_bus_width)
+{
+ u32 alert = 0, interval, devcnt;
+
+ if (custom_configs (custom_configs-mask
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL))
+ interval = custom_configs-temp_alert_poll_interval_ms;
+ else
+ interval = TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS;
+
+ interval *= 100;/* Convert to ns */
+ interval /= addressing-tREFI_ns; /* Convert to refresh cycles */
+ alert |= (interval TA_REFINTERVAL_SHIFT);
+
+ /*
+* sdram_io_width is in 'log2(x) - 1' form. Convert emif_bus_width
+* also to this form and subtract to get TA_DEVCNT, which is
+* in log2(x) form.
+*/
+ emif_bus_width = __fls(emif_bus_width) - 1;
+ devcnt = emif_bus_width - sdram_io_width;
+ alert |= devcnt TA_DEVCNT_SHIFT;
+
+ /* DEVWDT is in 'log2(x) - 3' form */
+ alert |= (sdram_io_width - 2) TA_DEVWDT_SHIFT;
+
+ alert |= 1 TA_SFEXITEN_SHIFT;
+ alert |= 1 TA_CS0EN_SHIFT;
+ alert |= (cs1_used ? 1 : 0) TA_CS1EN_SHIFT;
+
+ return alert;
+}
+
static u32 get_read_idle_ctrl_shdw(u8 volt_ramp)
{
u32 idle = 0, val = 0;
@@ -815,6 +897,71 @@ static int __init_or_module setup_interrupts(struct
emif_data *emif, u32 irq)
}
+static void __init_or_module emif_onetime_settings(struct emif_data *emif)
+{
+ u32 pwr_mgmt_ctrl, zq, temp_alert_cfg;
+ void __iomem*base = emif-base;
+ const struct lpddr2_addressing *addressing;
+ const struct ddr_device_info*device_info;
+
+ device_info = emif-plat_data-device_info;
+ addressing = get_addressing_table(device_info);
+
+ /*
+* Init power management settings
+* We don't know the frequency yet. Use a high frequency
+* value for a conservative timeout setting
+*/
+ pwr_mgmt_ctrl = get_pwr_mgmt_ctrl(10, emif,
+ emif-plat_data-ip_rev);
+ emif-lpmode = (pwr_mgmt_ctrl LP_MODE_MASK) LP_MODE_SHIFT
[PATCH v5 7/7] memory: emif: add debugfs entries for emif
From: Aneesh V ane...@ti.com
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 138 +
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 3dfffbb..33a4396 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
@@ -47,6 +48,7 @@
* frequency change (i.e. corresponding to the
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
+ * @debugfs_root: dentry to the root folder for EMIF in debugfs
*/
struct emif_data {
u8 duplicate;
@@ -60,6 +62,7 @@ struct emif_data {
struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
+ struct dentry *debugfs_root;
};
static struct emif_data *emif1;
@@ -68,6 +71,130 @@ static unsigned longirq_state;
static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+static void do_emif_regdump_show(struct seq_file *s, struct emif_data *emif,
+ struct emif_regs *regs)
+{
+ u32 type = emif-plat_data-device_info-type;
+ u32 ip_rev = emif-plat_data-ip_rev;
+
+ seq_printf(s, EMIF register cache dump for %dMHz\n,
+ regs-freq/100);
+
+ seq_printf(s, ref_ctrl_shdw\t: 0x%08x\n, regs-ref_ctrl_shdw);
+ seq_printf(s, sdram_tim1_shdw\t: 0x%08x\n, regs-sdram_tim1_shdw);
+ seq_printf(s, sdram_tim2_shdw\t: 0x%08x\n, regs-sdram_tim2_shdw);
+ seq_printf(s, sdram_tim3_shdw\t: 0x%08x\n, regs-sdram_tim3_shdw);
+
+ if (ip_rev == EMIF_4D) {
+ seq_printf(s, read_idle_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_normal);
+ seq_printf(s, read_idle_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_volt_ramp);
+ } else if (ip_rev == EMIF_4D5) {
+ seq_printf(s, dll_calib_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_normal);
+ seq_printf(s, dll_calib_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_volt_ramp);
+ }
+
+ if (type == DDR_TYPE_LPDDR2_S2 || type == DDR_TYPE_LPDDR2_S4) {
+ seq_printf(s, ref_ctrl_shdw_derated\t: 0x%08x\n,
+ regs-ref_ctrl_shdw_derated);
+ seq_printf(s, sdram_tim1_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim1_shdw_derated);
+ seq_printf(s, sdram_tim3_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim3_shdw_derated);
+ }
+}
+
+static int emif_regdump_show(struct seq_file *s, void *unused)
+{
+ struct emif_data*emif = s-private;
+ struct emif_regs**regs_cache;
+ int i;
+
+ if (emif-duplicate)
+ regs_cache = emif1-regs_cache;
+ else
+ regs_cache = emif-regs_cache;
+
+ for (i = 0; i EMIF_MAX_NUM_FREQUENCIES regs_cache[i]; i++) {
+ do_emif_regdump_show(s, emif, regs_cache[i]);
+ seq_printf(s, \n);
+ }
+
+ return 0;
+}
+
+static int emif_regdump_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_regdump_show, inode-i_private);
+}
+
+static const struct file_operations emif_regdump_fops = {
+ .open = emif_regdump_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int emif_mr4_show(struct seq_file *s, void *unused)
+{
+ struct emif_data *emif = s-private;
+
+ seq_printf(s, MR4=%d\n, emif-temperature_level);
+ return 0;
+}
+
+static int emif_mr4_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_mr4_show, inode-i_private);
+}
+
+static const struct file_operations emif_mr4_fops = {
+ .open = emif_mr4_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int __init_or_module emif_debugfs_init
[PATCH v5 4/7] memory: emif: handle frequency and voltage change events
From: Aneesh V ane...@ti.com
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling needs to
be integrated with clock framework and regulator
framework respectively. This is not done today
due to missing pieces in the kernel.
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 894 -
drivers/memory/emif.h | 130 +++-
2 files changed, 1020 insertions(+), 4 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 7486d7e..bd116eb 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -21,6 +21,7 @@
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
+#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
@@ -37,20 +38,595 @@
* @node: node in the device list
* @base: base address of memory-mapped IO registers.
* @dev: device pointer.
+ * @addressing table with addressing information from the spec
+ * @regs_cache:An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
*/
struct emif_data {
u8 duplicate;
u8 temperature_level;
+ u8 lpmode;
struct list_headnode;
+ unsigned long irq_state;
void __iomem*base;
struct device *dev;
+ const struct lpddr2_addressing *addressing;
+ struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
+ struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
};
static struct emif_data *emif1;
+static spinlock_t emif_lock;
+static unsigned long irq_state;
+static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+/*
+ * Calculate the period of DDR clock from frequency value
+ */
+static void set_ddr_clk_period(u32 freq)
+{
+ /* Divide 10^12 by frequency to get period in ps */
+ t_ck = (u32)DIV_ROUND_UP_ULL(1ull, freq);
+}
+
+/*
+ * Get the CL from SDRAM_CONFIG register
+ */
+static u32 get_cl(struct emif_data *emif)
+{
+ u32 cl;
+ void __iomem*base = emif-base;
+
+ cl = (readl(base + EMIF_SDRAM_CONFIG) CL_MASK) CL_SHIFT;
+
+ return cl;
+}
+
+static void set_lpmode(struct emif_data *emif, u8 lpmode)
+{
+ u32 temp;
+ void __iomem *base = emif-base;
+
+ temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
+ temp = ~LP_MODE_MASK;
+ temp |= (lpmode LP_MODE_SHIFT);
+ writel(temp, base + EMIF_POWER_MANAGEMENT_CONTROL);
+}
+
+static void do_freq_update(void)
+{
+ struct emif_data *emif;
+
+ /*
+* Workaround for errata i728: Disable LPMODE during FREQ_UPDATE
+*
+* i728 DESCRIPTION:
+* The EMIF automatically puts the SDRAM into self-refresh mode
+* after the EMIF has not performed accesses during
+* EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM number of DDR clock cycles
+* and the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set
+* to 0x2. If during a small window the following three events
+* occur:
+* - The SR_TIMING counter expires
+* - And frequency change is requested
+* - And OCP access is requested
+* Then it causes instable clock on the DDR interface.
+*
+* WORKAROUND
+* To avoid the occurrence of the three events, the workaround
+* is to disable the self-refresh when requesting a frequency
+* change. Before requesting a frequency change the software must
+* program EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x0. When the
+* frequency change has been done, the software can reprogram
+* EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x2
[PATCH v5 5/7] memory: emif: add interrupt and temperature handling
From: Aneesh V ane...@ti.com
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2 device from the MR4 mode register in the
device. EMIF generates an interrupt whenever it identifies
a temperature level change between two consecutive pollings.
Some of the timing parameters need to be de-rated at high
temperatures. The interrupt handler takes care of doing
this and also takes care of going back to nominal settings
when temperature falls back to nominal levels.
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 211 -
1 files changed, 209 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index bd116eb..a8dcf35 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -545,6 +545,42 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+}
+
+/*
* Program EMIF shadow registers that are not dependent on temperature
* or voltage
*/
@@ -627,6 +663,158 @@ out:
writel(ref_ctrl, base + EMIF_SDRAM_REFRESH_CTRL_SHDW);
}
+static irqreturn_t handle_temp_alert(void __iomem *base, struct emif_data
*emif)
+{
+ u32 old_temp_level;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ spin_lock_irqsave(emif_lock, irq_state);
+ old_temp_level = emif-temperature_level;
+ get_temperature_level(emif);
+
+ if (unlikely(emif-temperature_level == old_temp_level)) {
+ goto out;
+ } else if (!emif-curr_regs) {
+ dev_err(emif-dev, temperature alert before registers are
calculated, not de-rating timings\n);
+ goto out;
+ }
+
+ if (emif-temperature_level old_temp_level ||
+ emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
+ /*
+* Temperature coming down - defer handling to thread OR
+* Temperature far too high - do kernel_power_off() from
+* thread context
+*/
+ ret = IRQ_WAKE_THREAD;
+ } else {
+ /* Temperature is going up - handle immediately */
+ setup_temperature_sensitive_regs(emif, emif-curr_regs);
+ do_freq_update();
+ }
+
+out:
+ spin_unlock_irqrestore(emif_lock, irq_state);
+ return ret;
+}
+
+static irqreturn_t emif_interrupt_handler(int irq, void *dev_id)
+{
+ u32 interrupts;
+ struct emif_data*emif = dev_id;
+ void __iomem*base = emif-base;
+ struct device *dev = emif-dev;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ /* Save the status and clear it */
+ interrupts = readl(base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+ writel(interrupts, base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+
+ /*
+* Handle temperature alert
+* Temperature alert should be same for all ports
+* So
[PATCH v5 2/7] memory: emif: add register definitions for EMIF
From: Aneesh V ane...@ti.com Add register offsets and bit field definitions for EMIF module in TI SoCs Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- drivers/memory/emif.h | 454 + 1 files changed, 454 insertions(+), 0 deletions(-) create mode 100644 drivers/memory/emif.h diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h new file mode 100644 index 000..44b97df --- /dev/null +++ b/drivers/memory/emif.h @@ -0,0 +1,454 @@ +/* + * Defines for the EMIF driver + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@ti.com) + * + * 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 + * published by the Free Software Foundation. + */ +#ifndef __EMIF_H +#define __EMIF_H + +/* Registers offset */ +#define EMIF_MODULE_ID_AND_REVISION0x +#define EMIF_STATUS0x0004 +#define EMIF_SDRAM_CONFIG 0x0008 +#define EMIF_SDRAM_CONFIG_20x000c +#define EMIF_SDRAM_REFRESH_CONTROL 0x0010 +#define EMIF_SDRAM_REFRESH_CTRL_SHDW 0x0014 +#define EMIF_SDRAM_TIMING_10x0018 +#define EMIF_SDRAM_TIMING_1_SHDW 0x001c +#define EMIF_SDRAM_TIMING_20x0020 +#define EMIF_SDRAM_TIMING_2_SHDW 0x0024 +#define EMIF_SDRAM_TIMING_30x0028 +#define EMIF_SDRAM_TIMING_3_SHDW 0x002c +#define EMIF_LPDDR2_NVM_TIMING 0x0030 +#define EMIF_LPDDR2_NVM_TIMING_SHDW0x0034 +#define EMIF_POWER_MANAGEMENT_CONTROL 0x0038 +#define EMIF_POWER_MANAGEMENT_CTRL_SHDW0x003c +#define EMIF_LPDDR2_MODE_REG_DATA 0x0040 +#define EMIF_LPDDR2_MODE_REG_CONFIG0x0050 +#define EMIF_OCP_CONFIG0x0054 +#define EMIF_OCP_CONFIG_VALUE_10x0058 +#define EMIF_OCP_CONFIG_VALUE_20x005c +#define EMIF_IODFT_TEST_LOGIC_GLOBAL_CONTROL 0x0060 +#define EMIF_IODFT_TEST_LOGIC_CTRL_MISR_RESULT 0x0064 +#define EMIF_IODFT_TEST_LOGIC_ADDRESS_MISR_RESULT 0x0068 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_1 0x006c +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_2 0x0070 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_3 0x0074 +#define EMIF_PERFORMANCE_COUNTER_1 0x0080 +#define EMIF_PERFORMANCE_COUNTER_2 0x0084 +#define EMIF_PERFORMANCE_COUNTER_CONFIG0x0088 +#define EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT 0x008c +#define EMIF_PERFORMANCE_COUNTER_TIME 0x0090 +#define EMIF_MISC_REG 0x0094 +#define EMIF_DLL_CALIB_CTRL0x0098 +#define EMIF_DLL_CALIB_CTRL_SHDW 0x009c +#define EMIF_END_OF_INTERRUPT 0x00a0 +#define EMIF_SYSTEM_OCP_INTERRUPT_RAW_STATUS 0x00a4 +#define EMIF_LL_OCP_INTERRUPT_RAW_STATUS 0x00a8 +#define EMIF_SYSTEM_OCP_INTERRUPT_STATUS 0x00ac +#define EMIF_LL_OCP_INTERRUPT_STATUS 0x00b0 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_SET 0x00b4 +#define EMIF_LL_OCP_INTERRUPT_ENABLE_SET 0x00b8 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_CLEAR 0x00bc +#define EMIF_LL_OCP_INTERRUPT_ENABLE_CLEAR 0x00c0 +#define EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG 0x00c8 +#define EMIF_TEMPERATURE_ALERT_CONFIG 0x00cc +#define EMIF_OCP_ERROR_LOG 0x00d0 +#define EMIF_READ_WRITE_LEVELING_RAMP_WINDOW 0x00d4 +#define EMIF_READ_WRITE_LEVELING_RAMP_CONTROL 0x00d8 +#define EMIF_READ_WRITE_LEVELING_CONTROL 0x00dc +#define EMIF_DDR_PHY_CTRL_10x00e4 +#define EMIF_DDR_PHY_CTRL_1_SHDW 0x00e8 +#define EMIF_DDR_PHY_CTRL_20x00ec +#define EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING 0x0100 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING 0x0104 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING 0x0108 +#define EMIF_READ_WRITE_EXECUTION_THRESHOLD0x0120 +#define EMIF_COS_CONFIG0x0124 +#define EMIF_PHY_STATUS_1 0x0140 +#define EMIF_PHY_STATUS_2
[PATCH v5 3/7] memory: emif: add basic infrastructure for EMIF driver
From: Aneesh V ane...@ti.com EMIF is an SDRAM controller used in various Texas Instruments SoCs. EMIF supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols. Add the basic infrastructure for EMIF driver that includes driver registration, probe, parsing of platform data etc. Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- Documentation/memory-devices/ti-emif.txt | 57 ++ drivers/Kconfig |4 + drivers/Makefile |3 + drivers/memory/Kconfig | 22 +++ drivers/memory/Makefile |5 + drivers/memory/emif.c| 289 ++ drivers/memory/emif.h|7 + include/linux/platform_data/emif_plat.h | 128 + 8 files changed, 515 insertions(+), 0 deletions(-) create mode 100644 Documentation/memory-devices/ti-emif.txt create mode 100644 drivers/memory/Kconfig create mode 100644 drivers/memory/Makefile create mode 100644 drivers/memory/emif.c create mode 100644 include/linux/platform_data/emif_plat.h diff --git a/Documentation/memory-devices/ti-emif.txt b/Documentation/memory-devices/ti-emif.txt new file mode 100644 index 000..f4ad9a7 --- /dev/null +++ b/Documentation/memory-devices/ti-emif.txt @@ -0,0 +1,57 @@ +TI EMIF SDRAM Controller Driver: + +Author + +Aneesh V ane...@ti.com + +Location + +driver/memory/emif.c + +Supported SoCs: +=== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +== +Device Drivers + Memory devices + Texas Instruments EMIF driver + +Description +=== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): += +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: + +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs + +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. diff --git a/drivers/Kconfig b/drivers/Kconfig index d236aef..b0e0629 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -140,4 +140,8 @@ source drivers/virt/Kconfig source drivers/devfreq/Kconfig +# memory + +source drivers/memory/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 95952c8..9cc81ee 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -134,3 +134,6 @@ obj-$(CONFIG_VIRT_DRIVERS) += virt/ obj-$(CONFIG_HYPERV) += hv/ obj-$(CONFIG_PM_DEVFREQ) += devfreq/ + +# Memory drivers +obj-$(CONFIG_MEMORY) += memory/ diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig new file mode 100644 index 000..b08327c --- /dev/null +++ b/drivers/memory/Kconfig @@ -0,0 +1,22 @@ +# +# Memory devices +# + +menuconfig MEMORY + bool Memory Controller drivers + +if MEMORY + +config TI_EMIF + tristate Texas Instruments EMIF driver + select DDR + help + This driver is for the EMIF module available in Texas Instruments + SoCs. EMIF is an SDRAM controller that, based on its revision, + supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. + This driver takes care of only LPDDR2 memories presently. The + functions of the driver includes re-configuring AC timing + parameters and other settings during frequency, voltage and + temperature changes + +endif diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile new file mode 100644 index
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
Greg, On Monday 23 April 2012 08:14 PM, Shilimkar, Santosh wrote: On Mon, Apr 23, 2012 at 7:57 PM, Greg KH g...@kroah.com wrote: On Mon, Apr 23, 2012 at 04:34:46PM +0530, Shilimkar, Santosh wrote: Afzal, On Mon, Apr 23, 2012 at 4:26 PM, Mohammed, Afzal af...@ti.com wrote: Hi Aneesh, On Fri, Apr 13, 2012 at 01:28:55, V, Aneesh wrote: Thanks. I will wait for your review then. Once I have your comments I will re-work and submit in the new directory structure proposed. Do you have a plan on submitting EMIF driver in the new proposed (drivers/memory) directory. Or shall I submit GPMC driver by creating the new memory directory. Greg mentioned that he plans to do a review of EMIF driver. We were waiting for his comments before sending the updated series. No, don't wait for me, please resend, I was waiting for you :) Thanks Greg !! Will start working on updating the patch set and post it on list. Have posted the updated version [1] as per discussion on this thread. Regards Santosh [1] http://www.spinics.net/lists/arm-kernel/msg171869.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
+ Tero On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote: Hi Grazvydas, Kevin, I did some gather some performance measurements and statistics using custom tracepoints in __omap3_enter_idle. All the details are at http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis . Nice data. The setup is: - Beagleboard (OMAP3530) at 500MHz, - l-o master kernel + functional power states + per-device PM QoS. It has been checked that the changes from l-o master do not have an impact on the performance. - The data transfer is performed using dd from a file in JFFS2 to /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. On Tue, Apr 17, 2012 at 4:30 PM, Kevin Hilman khil...@ti.com wrote: Grazvydas Ignotas nota...@gmail.com writes: On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote: It would be helpful now to narrow down what are the big contributors to the overhead in omap_sram_idle(). Most of the code there is skipped for C1 because the next states for MPU and CORE are both ON. Ok I did some tests, all in mostly idle system with just init, busybox shell and dd doing a NAND read to /dev/null . ... MB/s is throughput that dd reports, mA and approx. current draw during the transfer, read from fuel gauge that's onboard. MB/s| mA|comment 3.7|218|mainline f549e088b80 3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1] 4.4|220|[1] + pwrdm_p*_transition commented [2] 3.8|225|[1] + omap34xx_do_sram_idle-cpu_do_idle [3] 4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4] 4.0|224|[1] + 'Deny idle' [5] 5.1|210|[2] + [4] + [5] 5.2|202|[5] + omap_sram_idle-cpu_do_idle [6] 5.5|243|!CONFIG_PM 6.1|282|busywait DMA end (for reference) Here are the results (BW in MB/s) on Beagleboard: - 4.7: without using DMA, - Using DMA 2.1: [0] 2.1: [1] only C1 2.6: [1]+[2] no pre_ post_ 2.3: [1]+[5] no pwrdm_for_each_clkdm 2.8: [1]+[5]+[2] 3.1: [1]+[5]+[6] no omap_sram_idle 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON So indeed this shows there is some serious performance issue with the C1 C-state. Looks like other clock-domain (notably l4, per, AON) should be denied idle in C1 to avoid the huge penalties. It might just do the trick. Thanks for the detailed experiments. This definitely confirms we have some serious unwanted overhead for C1, and our C-state latency values are clearly way off base, since they only account HW latency and not any of the SW latency introduced in omap_sram_idle(). There are 2 primary differences that I see as possible causes. I list them here with a couple more experiments for you to try to help us narrow this down. 1) powerdomain accounting: pwrdm_pre_transition(), pwrdm_post_transition() Could you try using omap_sram_idle() and just commenting out those calls? Does that help performance? Those iterate over all the powerdomains, so defintely add some overhead, but I don't think it would be as significant as what you're seeing. Seems to be taking good part of it. Much more likely is... 2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds Could not notice any difference. To me it looks like this results from many small things adding up.. Idle is called so often that pwrdm_p*_transition() and those pwrdm_for_each_clkdm() walks start slowing everything down, perhaps because they access lots of registers on slow buses? From the list of contributors, the main ones are: (140us) pwrdm_pre_transition and pwrdm_post_transition, I have observed this one on OMAP4 too. There was a plan to remove this as part of Tero's PD/CD use-counting series. (105us) omap2_gpio_prepare_for_idle and omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in the latency-critical C-states, Yes. In C1 when you deny idle for per, there should be no need to call this. But even in the case when it is called, why is it taking 105 uS. Needs to dig further. (78us) pwrdm_for_each_clkdm(mpu, core, deny_idle/allow_idle), Depending on OPP, a PRCM read can take upto ~12-14 uS, so above shouldn't be surprising. (33us estimated) omap_set_pwrdm_state(mpu, core, neon), This is again dominated by PRCM read (11 us) clkdm_allow_idle(mpu). Is this needed? I guess yes other wise when C2+ is attempted MPU CD can't idle. Here are a few questions and suggestions: - In case of latency critical C-states could the high-latency code be bypassed in favor of a much simpler version? Pushing the concept a bit farther one could have a C1 state that just relaxes the cpu (no WFI), a C2 state which bypasses a lot of code in __omap3_enter_idle, and the rest of the C-states as we have today, We should do that. Infact C1 state should be as lite as possible like WFI or so. - Is it needed to iterate through all the power and clock domains in order to keep them active? That iteration should be removed. - Trying to
Re: [PATCH-V3 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Vaibhav, On Friday 13 April 2012 03:09 PM, Vaibhav Hiremath wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation without any major code changes, uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. History: Changes from V2: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/092037.html - Added early_param support to read clocksource selection from user through kernel parameter (clocksource=) - Converted to ocp_if changes from Paul Changes from V1: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081037.html - Based on Tony's comment, added pbase size argument to omap_init_clocksource_32k(), to avoid cpu_is_xxx() check. - Added commit description based on discussion on list (Thanks to Santosh here) - Reorder patch sequence Vaibhav Hiremath (3): ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database ARM: OMAP: Make OMAP clocksource source selection using kernel param This versions of series seems to fine with me. Feel free to add, Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP4: Remove un-used control module headers and defines.
On Thursday 12 April 2012 06:27 PM, Cousson, Benoit wrote: Hi Santosh, On 4/12/2012 12:31 PM, Santosh Shilimkar wrote: Benoit, On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote: Most of the OMAP4 control module register defines are not used and can be removed. Keep only needed defines and move them to common control module header just like other OMAP versions. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- What do you think about this patch ? I'm fine with it. I'm just wondering if we have to send it right now or along with the control module driver implementation we've just started. Let's do that as part of the driver implementation. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix DMA vs memory ordering
On Saturday 14 April 2012 06:54 PM, Russell King - ARM Linux wrote: Using coherent DMA memory with the OMAP DMA engine results in unpredictable behaviour due to memory ordering issues; as things stand, there is no guarantee that data written to coherent DMA memory will be visible to the DMA hardware. This is because the OMAP dma_write() accessor contains no barriers, necessary on ARMv6 and above. The effect of this can be seen in comments in the OMAP serial driver, which incorrectly talks about cache flushing for the coherent DMA stuff. Rather than adding barriers to the accessors, add it in the DMA support code just before we enable DMA, and just after we disable DMA. This avoids having barriers for every DMA register access. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- I don't why the synchronisation in dma_[start/stop] was missing. The patch indeed make complete sense. Is this why no one uses DMA with the serial driver? Will check if this patch helps in some of the DMA issues seen in serial driver. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.
This was the root cause of the console sluggishness issue, I have been
observing on OMAP4 devices and also can be potential reason for some
other UART wakeup issues.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/serial.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c9503a7..b28aae1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -108,8 +108,14 @@ static void omap_uart_set_noidle(struct platform_device
*pdev)
static void omap_uart_set_smartidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
+ u8 idlemode;
- omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
+ if (od-hwmods[0]-class-sysc-idlemodes SIDLE_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+
+ omap_hwmod_set_slave_idlemode(od-hwmods[0], idlemode);
}
#else
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On Thursday 12 April 2012 08:30 AM, Greg KH wrote: On Wed, Apr 11, 2012 at 08:44:39PM -0600, Paul Walmsley wrote: Cc Mark Greer, Mark Salter Hi Greg, Aneesh, On Sat, 17 Mar 2012, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. Just checking to see what the current state of this series is. Greg, are you considering this for merging, or are there remaining issues? Aneesh, do you have any remaining issues to resolve with this set? What about the review comment about devfreq? Devfreq is not suitable for this driver. I already replied on this thread [1] Acting on frequency change is just one function of the controller driver and that too need not bed to attached with devfreq. The driver has features like temperature handling as per JDEC specs, active power managements modes, system wide suspend power management like self refresh and also configuration which can help memory hotplug for power savings and initialising the DDR timings to avoid boot-loader defaults.The controller IP works in conjunction with PRCM (OMAP Power IP) block to achieve some of this functionality. I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Regards Santosh [1] https://lkml.org/lkml/2012/3/19/178 This is useful not only for OMAP4 and AM3517/3505, but also will probably be useful for the C6x chips that Mark Salter is working on. It's still in my to-review queue, that I'm slowly making my way through. So it's not lost, but I would like to get the devfreq interface question cleared up first. Let us know if you need more clarification on devfreq part. Thanks for looking into it. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
On Thursday 12 April 2012 03:13 PM, Tarun Kanti DebBarma wrote:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
v2: removed tiocp_cfg from struct timer_regs {}
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP4: Remove un-used control module headers and defines.
Benoit, On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote: Most of the OMAP4 control module register defines are not used and can be removed. Keep only needed defines and move them to common control module header just like other OMAP versions. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- What do you think about this patch ? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: mm: Add v7_flush_dcache_by_level() API
Couple of patches on the ARMv7 cache code. First patch adds v7_flush_dcache_by_level() API and second patch updates the setup function to use the same. R Sricharan (1): ARM: mm: Add v7_flush_dcache_by_level() API. Santosh Shilimkar (1): ARM: mm: Flush only CPU local cache instead of all cache levels. arch/arm/mm/cache-v7.S | 56 ++- arch/arm/mm/proc-v7.S |3 +- 2 files changed, 47 insertions(+), 12 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: mm: Add v7_flush_dcache_by_level() API.
From: R Sricharan r.sricha...@ti.com
On ARMv7 based SOC with an integrated L2 cache, there is a need
to have a flush API to operate on each cache level. In few low
power modes, L2 cache is retained where as L1 is lost. The current
v7_flush_dcache_all(), flushes all the levels and it would be quite
expensive.
So introduce v7_flush_dcache_by_level() API which takes a
parameter (cache level), and flush only on that level.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/cache-v7.S | 56 ++-
1 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index a655d3d..cbeff42 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -43,12 +43,32 @@ ENDPROC(v7_flush_icache_all)
*/
ENTRY(v7_flush_dcache_all)
dmb @ ensure ordering with previous
memory accesses
+ mov r8, lr @ store lr
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
beq finished@ if loc is 0, then no need to
clean
mov r10, #0 @ start clean at cache level 0
loop1:
+ bl v7_flush_dcache_current_level
+skip:
+ add r10, r10, #2@ increment cache number
+ cmp r3, r10 @
+ bgt loop1
+finished:
+ mov r10, #0 @ swith back to cache level 0
+ mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
+ dsb
+ isb
+ mov pc, r8 @ restore lr
+ENDPROC(v7_flush_dcache_all)
+/*
+ * v7_flush_dcache_current_level()
+ *
+ * Flush the D-cache by specifed level like l1, l2 etc.
+ * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ */
+ENTRY(v7_flush_dcache_current_level)
add r2, r10, r10, lsr #1@ work out 3x current cache
level
mov r1, r0, lsr r2 @ extract cache type bits from
clidr
and r1, r1, #7 @ mask of the bits for current
cache only
@@ -84,17 +104,31 @@ loop3:
bge loop3
subsr7, r7, #1 @ decrement the index
bge loop2
-skip:
- add r10, r10, #2@ increment cache number
- cmp r3, r10
- bgt loop1
-finished:
+ mov pc, lr
+ENDPROC(v7_flush_dcache_current_level)
+
+/*
+ * v7_flush_dcache_by_level()
+ * r0 - cache level to be flushed
+ *
+ * Flush the D-cache by specifed level like l1, l2 etc.
+ * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ */
+ENTRY(v7_flush_dcache_by_level)
+ dmb @ ensure ordering with previous
memory accesses
+ mov r8, lr @ store the lr
+ mov r10, r0 @ temp storage
+ sub r10, r10, #1
+ mov r10, r10, lsl #1
+ mrc p15, 1, r0, c0, c0, 1 @ read clidr
+ bl v7_flush_dcache_current_level
+finished1:
mov r10, #0 @ swith back to cache level 0
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
dsb
isb
- mov pc, lr
-ENDPROC(v7_flush_dcache_all)
+ mov pc, r8 @ restore lr
+ENDPROC(v7_flush_dcache_by_level)
/*
* v7_flush_cache_all()
@@ -108,14 +142,14 @@ ENDPROC(v7_flush_dcache_all)
*
*/
ENTRY(v7_flush_kern_cache_all)
- ARM( stmfd sp!, {r4-r5, r7, r9-r11, lr})
- THUMB(stmfd sp!, {r4-r7, r9-r11, lr})
+ ARM( stmfd sp!, {r4-r5, r7-r11, lr})
+ THUMB(stmfd sp!, {r4-r11, lr} )
bl v7_flush_dcache_all
mov r0, #0
ALT_SMP(mcr p15, 0, r0, c7, c1, 0) @ invalidate I-cache inner
shareable
ALT_UP(mcr p15, 0, r0, c7, c5, 0) @ I+BTB cache invalidate
- ARM( ldmfd sp!, {r4-r5, r7, r9-r11, lr})
- THUMB(ldmfd sp!, {r4-r7, r9-r11, lr})
+ ARM( ldmfd sp!, {r4-r5, r7-r11, lr})
+ THUMB(ldmfd sp!, {r4-r11, lr} )
mov pc, lr
ENDPROC(v7_flush_kern_cache_all)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: mm: Flush only CPU local cache instead of all cache levels.
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.
But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.
Fix this code by restricting the cache flush to local cpu
cache or L1.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-v7.S |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f1c8486..96cfc31 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,8 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ mov r0, #0x1
+ bl v7_flush_dcache_by_level
ldmia r12, {r0-r5, r7, r9, r11, lr}
mrc p15, 0, r0, c0, c0, 0 @ read main ID register
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
On Tuesday 03 April 2012 08:36 PM, Santosh Shilimkar wrote: On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. Thanks for rebasing this. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase This branch by itself seems to work fine. However, when combining with other stuff that has merged for v3.4, it hangs during boot. I haven't yet isolated the problem, but it's easy to reproduce by combining your branch with v3.4-rc1: git checkout -b test/coupled-v3.4 v3.4-rc1 git merge -s recursive -X ours santosh/for_3.5/omap4_coupled_cpuidle-rebase [1] This hangs on boot, and it seems like a coupled state deadlock because commenting out the coupled states in the C-state creation of cpuidle44xx.c makes it boot just fine. I managed to reproduce the issue. Just to ensure that any OMAP changes have not introduced the regression I merged all Tony's pull request on my branch and tried it out. OMAP changes are fine and coupled idle continue to work. Started bisecting the commits. For bisect I have to create a series which is not dependent on Len's cpuidle updates. First round of bisect was not successful so tried one more time. Was very close to narrowing down on commit but then encountered set of commits where either CPUIDLE itself is broken(deeper C-states are not getting attempted) or I get softIRQ 08 pending error. The last bad commit in bisect was ... [8682df25ca9afd3aac30f2c72d00bd98de2118e8] Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core So far looks like, one of below series has introduced a race which is getting highlighted with coupled cpuidle patchset. 9b612fa Merge branch 'fortglx/3.4/clocksource' of git://git.linaro.org/people/jstultz/linux into timers/core 8682df2 Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core 97ac984 Merge branch 'fortglx/3.4/time' of git://git.linaro.org/people/jstultz/linux into timers/core Finally managed to crack down the issue. The broad-cast clock-event was remaining in shut-down mode and hence we were loosing the OS tick after entering to low power states. The cases where it use to work was mainly because of external interrupts like NFS etc. Have posted a patch [1] on LKML which fixes the issue. Waiting for feedback from Thomas on it. Have updated the git tree with patch [1] + 3.4-rc2 and same is available here[2] Regards Santosh [1] https://lkml.org/lkml/2012/4/9/13 [2] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/coupled_cpuidle-rebase -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Thursday 05 April 2012 04:01 PM, Hiremath, Vaibhav wrote: On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote: There seems to be limitation for ARM architecture, it is restricted by sched_clock implementation present in arch/arm/kernel/sched_clock.c. Natively, clocksource framework does support change in rate/frequency for registered timer, using, Any kind of switching of timing sources introduces loss of time issues by the mere fact that you can't instantly know the counter values of both timing sources at precisely the same instant - because CPUs can only do one thing at a time. So any kind of repeated dynamic switching _will_ result in a gradual loss of time - which will be indeterminant as it depends on the frequency of the switching and the relative delta between the two. To put it another way - it is not possible to maintain high precision and accuracy while dynamically switching your timing sources. I'm not about to lift the restriction that there's only one source for sched_clock() just for OMAP. That'd require a lot of additional code - it's not just about adjusting the multiplier and shift, you also have to correct the returned ns value as well, which means synchronizing against two counters. (And as I've pointed out above, that's impossible to do accurately.) Thanks a ton Russell for confirming on this, I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. So this means, we have to use compile time option, as existing implementation in arch/arm/mach-omap2/timer.c. Thanks again, I will repost patches shortly with the code changes (mentioned in my last email) I suggest you wait for Kevin and Tony to look at it. Am still going back to what I proposed initially. Why not the conditional way as shown in the patch [1] I proposed or your initial patch with some updates? Something like this. if(commandline.clksource == gpt) omap2_gptimer_clocksource_init(gptimer_id, fck_source); else if (omap_init_clocksource_32k()) omap2_gptimer_clocksource_init(gptimer_id, fck_source); This won't need compile time option and gives you all everybody wants. 1. Ability to use gpt as a clock-source for perf like stuff 2. Hardware like AMXX where 32K synctimer doesn't exist which means omap_init_clocksource_32k() will fail and use gptimer. 3. For OMAP, it will continue to use 32K sync timer. What am I missing Vaibhav? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. Thanks for rebasing this. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase This branch by itself seems to work fine. However, when combining with other stuff that has merged for v3.4, it hangs during boot. I haven't yet isolated the problem, but it's easy to reproduce by combining your branch with v3.4-rc1: git checkout -b test/coupled-v3.4 v3.4-rc1 git merge -s recursive -X ours santosh/for_3.5/omap4_coupled_cpuidle-rebase [1] This hangs on boot, and it seems like a coupled state deadlock because commenting out the coupled states in the C-state creation of cpuidle44xx.c makes it boot just fine. I managed to reproduce the issue. Just to ensure that any OMAP changes have not introduced the regression I merged all Tony's pull request on my branch and tried it out. OMAP changes are fine and coupled idle continue to work. Started bisecting the commits. For bisect I have to create a series which is not dependent on Len's cpuidle updates. First round of bisect was not successful so tried one more time. Was very close to narrowing down on commit but then encountered set of commits where either CPUIDLE itself is broken(deeper C-states are not getting attempted) or I get softIRQ 08 pending error. The last bad commit in bisect was ... [8682df25ca9afd3aac30f2c72d00bd98de2118e8] Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core So far looks like, one of below series has introduced a race which is getting highlighted with coupled cpuidle patchset. 9b612fa Merge branch 'fortglx/3.4/clocksource' of git://git.linaro.org/people/jstultz/linux into timers/core 8682df2 Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core 97ac984 Merge branch 'fortglx/3.4/time' of git://git.linaro.org/people/jstultz/linux into timers/core Will try to continue the debug tomorrow. let me know if you find some thing interesting in your day time. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 1/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote: Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com CC: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei tom.leim...@gmail.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 2/3] ARM: OMAP2+: hwmod data: Add 32k-sync timer data to hwmod database
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote: Add 32k-sync timer hwmod data to omap2 3 hwmod table and also enable existing hwmod data for omap4 (was disabled before). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com CC: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei tom.leim...@gmail.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
Thanks for the change log update Vaibhav.
Some more comments.
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86 -
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index a2e6d07..3f96a00 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -72,6 +72,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc410
Shouldn't you just update OMAP1_32K_TIMER_BASE ?
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR 0x00
#define OMAP1_32K_TIMER_TCR 0x04
@@ -185,7 +186,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
If pbase is NULL, you might not want to call the init.
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5c9acea..f35db1a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+ * First check for availability for 32k-sync timer.
+ *
+ * In case of failure in finding 32k_counter module or
+ * registering it as clocksource, execution will fallback to
+ * gp-timer.
+ */
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
Don't hardcode the offset here. This is error prone when the IP
changes so use the register define.
+ size = oh-slaves[0]-addr-pa_end -
+ oh-slaves[0]-addr-pa_start;
+ res = omap_init_clocksource_32k(pbase, size);
+ if (!res)
+ return;
+ }
If 'OMAP_32K_TIMER' is not selected, does omap_init_clocksource_32k()
fails too ?
+ /* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res
Re: OMAP4 errata i740
+ Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
On Fri, Mar 30, 2012 at 12:04 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the
timers with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and don't
get into unknown issue; I changed my code for this, and it is working for
me without any issues.
Let's not make this more complicated. I guess below simple patch should sort
out the issue. I briefly tested it on OMAP4 and it works. let me know
if it helps AMxxx machines.
Regards
Santosh
From 0a9283e26174d76ff2753ac88521b61a26b24e8f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 30 Mar 2012 12:43:29 +0530
Subject: [PATCH] ARM: OMAP: Make OMAP clocksource source selection runtime.
Current OMAP code support couple of clocksource options based on compilation
flag. The 32KHz based sync timer and a gptimer based clock source which can
run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options.
1. 32KHz synctimer
2. Sysclock based(e.g 38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can give the
high precision than synctimer so expected usage was 2 and not 3.
Unfortunatlly
option 2, clocksource doesn't meet the requirement of free-running clock
as per clocksource need. It stops in low power states when sysclock is cut.
That makes gptimer based clocksource option useless for OMAP2/3/4 devices
with sysclock as a clock input. Option 3 will still work but it is no better'
than 32K synctimer based clocksource.
So ideally we can kill the gptimer based clocksource option but there are
some
OMAP based derivative SoCs like AM which doesn't have synictimer
hardware IP
and need to fallback on 32KHz based gptimer clocksource.
Considering above, make synctimer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Not-yet-signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..3878e59 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
-omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -276,7 +261,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
{
int res
Re: OMAP4 errata i740
On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) Not at all. At least it will not be worst than the current WA. I think Archit is right, at least this is the exact same question I'm asking to the designers :-). Am not sure what do you mean by here. What Archit said is statitically setting up DSS/ISS sysnconfig to no standby. It will definitely break PM. The WA was doing runtime this with clockdomain APIs. If you say manage the sysconfig runtime in driver, then it will work. With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. This is exactly what will happen if you set the clock domain in NO_IDLE. So in any case, you cannot have autoidle during the Guess I was not clear. The idea was to put CD in no_idle when DSS active and allow idle when not active. Looks like you saying OK to hack sysconfig for which we have been pushing back on drivers not to do it. Ofcourse errata and various reset bugs have broken that rule anyways. Regards Santosh Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Friday 30 March 2012 04:59 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 15:12:19, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: ... Santosh others, Do you think, it makes sense to clean up the CONFIG_OMAP_32K_TIMER usage in mach-omap2/timer.c file now? Specifically below code-snippet - #ifdef CONFIG_OMAP_32K_TIMER #define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 #endif And lets make 32k_fclk as default clocksource for gptimer, if it is being used as clocksource. Atleast with this I can clean whole omap2/3/4 families, and I can take omap1 thing later . (as I have to understand/read about omap1 first). If you agree, I can include this cleanup also in my next version of patch- series. What's your opinion here? I am ok with this clean up. But I let Tony take decision on it. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On Friday 30 March 2012 05:30 PM, Cousson, Benoit wrote: On 3/30/2012 1:20 PM, Shilimkar, Santosh wrote: [..] Playing with clock domain state from the driver is just not acceptable. Sorry for small digration but the clock-domain/power domain APIs were coming in between CPUIDLE code movement to drivers/idle/* How do we deal with that code which is today lying under platform code. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase Special thanks to Kevin Hilman and Colin Cross on their help on this series. Kevin Hilman (1): ARM: OMAP4: CPUidle: add synchronization for coupled idle states Santosh Shilimkar (2): ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus ARM: OMAP4: cpuidle: Use coupled cpuidle states to implement SMP cpuidle. arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/cpuidle44xx.c | 187 - arch/arm/mach-omap2/timer.c |4 +- 3 files changed, 124 insertions(+), 68 deletions(-) Regards Santosh [1] http://lwn.net/Articles/486484/ [2] Power Management git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
For coupled cpuidle to work when both cpus are active, it needs a global timer
that can handle events for both cpus. This timer is used as the broadcast
clock-event when the per-cpu timer hardware stop in low power states.
Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and
set the irq to allow the clockevent core to determine the affinity of the
timer.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fc73567..e33f9c4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,7 @@ static struct clock_event_device clockevent_gpt = {
.name = gp timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
+ .rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
};
@@ -225,7 +226,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
clockevent_delta2ns(3, clockevent_gpt);
/* Timer internal resynch latency. */
- clockevent_gpt.cpumask = cpumask_of(0);
+ clockevent_gpt.cpumask = cpu_all_mask;
+ clockevent_gpt.irq = omap_dm_timer_get_irq(clkev);
clockevents_register_device(clockevent_gpt);
pr_info(OMAP clockevent source: GPTIMER%d at %lu Hz\n,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP4: cpuidle: Use coupled cpuidle states to implement SMP cpuidle.
OMAP4 CPUDILE driver is converted mainly based on notes from the
coupled cpuidle patch series.
The changes include :
- Register both CPUs and C-states to cpuidle driver.
- Set struct cpuidle_device.coupled_cpus
- Set struct cpuidle_device.safe_state to non coupled state.
- Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
- Separate -enter hooks for coupled simple idle.
- CPU0 wait loop for CPU1 power transition.
- CPU1 wakeup mechanism for the idle exit.
- Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.
Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
on the intermediate version of this patch.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Kevin Hilman khil...@ti.com
Cc: Colin Cross ccr...@android.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/cpuidle44xx.c | 167 ++---
2 files changed, 101 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e20c8ab..250786e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,6 +54,7 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
select ARM_CPU_SUSPEND if PM
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if CPU_IDLE
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f386cbe..5724393 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -21,6 +21,7 @@
#include common.h
#include pm.h
#include prm.h
+#include clockdomain.h
#ifdef CONFIG_CPU_IDLE
@@ -44,10 +45,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
-static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
+static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
+static struct clockdomain *cpu_clkdm[NR_CPUS];
/**
- * omap4_enter_idle - Programs OMAP4 to enter the specified state
+ * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -56,34 +58,40 @@ static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle(struct cpuidle_device *dev,
+static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ local_fiq_disable();
+ omap_do_wfi();
+ local_fiq_enable();
+
+ return index;
+}
+
+static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
struct omap4_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
- u32 cpu1_state;
int cpu_id = smp_processor_id();
local_fiq_disable();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
-* CPU0 has to stay ON (i.e in C1) until CPU1 is OFF state.
+* CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
* of triggeing all the possible low power modes once CPU1 is
* out of coherency and in OFF mode.
-* Update dev-last_state so that governor stats reflects right
-* data.
*/
- cpu1_state = pwrdm_read_pwrst(cpu1_pd);
- if (cpu1_state != PWRDM_POWER_OFF) {
- index = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[index]);
+ if (dev-cpu == 0) {
+ while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF)
+ cpu_relax();
}
- if (index 0)
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
-
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -91,25 +99,35 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (cx-cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
- pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
- omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
-
- /*
-* Call idle CPU cluster PM enter notifier chain
-* to save GIC and wakeupgen context.
-*/
- if ((cx-mpu_state == PWRDM_POWER_RET)
- (cx-mpu_logic_state == PWRDM_POWER_OFF))
- cpu_cluster_pm_enter();
+ if (dev-cpu == 0) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state
[PATCH 3/3] ARM: OMAP4: CPUidle: add synchronization for coupled idle states
From: Kevin Hilman khil...@ti.com
With coupled idle states, a failure for any CPU to hit a low power
state must be coordinated such that all CPUs abort.
On OMAP4, when entering a coupled state, CPU0 has to wait for CPU1 to
enter its low power state before it can enter its low power state.
This is implemented by letting CPU0 wait for the CPU1 powerdomain to
hit off. However, there are conditions where CPU1 might abort/fail
and not hit off while CPU0 is waiting for it. For example, a CPU1
wakeup or a failed attempt to hit off due to hardware conditions.
To avoid the deadlock where CPU0 would continually wait for CPU1 to
hit off-mode, this patch adds a flag to signal when each CPU has come
out of its low-power state. CPU0 then checks whether CPU1 has hit off
*or* has already completed its attempt to hit off. If the latter,
CPU0 must abort its attempt to hit a low-power state so the coupled
state enter method can return.
In addition, cpuidle_coupled_parallel_barrier() is used to ensure the
clearing of the 'done' flag is synchronized on all CPUs.
Cc: Colin Cross ccr...@android.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 5724393..fcf6653 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -48,6 +48,9 @@ struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
static struct clockdomain *cpu_clkdm[NR_CPUS];
+static atomic_t abort_barrier;
+static bool cpu_done[NR_CPUS];
+
/**
* omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
* @dev: cpuidle device
@@ -88,8 +91,20 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
* out of coherency and in OFF mode.
*/
if (dev-cpu == 0) {
- while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF)
+ while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF) {
cpu_relax();
+
+ /*
+* CPU1 could have already entered exited idle
+* without hitting off because of a wakeup
+* or a failed attempt to hit off mode. Check for
+* that here, otherwise we could spin forever
+* waiting for CPU1 off.
+*/
+ if (cpu_done[1])
+ goto fail;
+
+ }
}
/*
@@ -113,6 +128,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
}
omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+ cpu_done[dev-cpu] = true;
if (dev-cpu == 0) {
/* Wakeup CPU1 only if it is not offlined */
@@ -137,6 +153,10 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
if (omap4_mpuss_read_prev_context_state())
cpu_cluster_pm_exit();
+fail:
+ cpuidle_coupled_parallel_barrier(dev, abort_barrier);
+ cpu_done[dev-cpu] = false;
+
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
local_fiq_enable();
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/7] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
+ Jean, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: The cpuidle API allows to declare statically the states in the driver structure. Let's use it. We do no longer need the fill_cstate function called at runtime and by the way adding more instructions at boot time. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- Jean added the fill_cstate() kind of helpers o.w in the old cpuidle code9OMAP30, static tables were used. Ofcourse those tables were not uinsg the cpuidle driver structure. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/7] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 0455858..254f97b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
OK
Regards
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote: On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? I execute default idle loop. yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote: On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: The 'valid' field is never used in the code, let's remove it. Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org --- It is used during the registration. This field has been very useful for debug when need to disable a C-state etc. So unless and until there is a strong reason, i would like to retain it. IMO if it used for debug purpose, it should be moved to the debug code and if the debug code is not upstream, then that 'valid' should not be here but in the out-of-tree code. When I said debug, I mean CPUIDLE debug and not any special debug code. By the way, this may be a debate for nothing because a patchset is on the way to disable C-states from sysfs. I see but sysfs won't solve that because you want to disable certain C-state so that CPUIDLE driver don't use that state. Let say if the C4 which is OSWR is broken. In such cases, just setting valid flag let you disable it. Again I don't have strong objection to this change. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP. It will always use 32k-counter, and never fall back to dmtimer. Then the only options we have here is, 1) Register both the timers, 32k-counter and dmtimer for clocksource; let Kernel pick up best rating clocksource out of these two. In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better Rating. User can choose the 32k-counter clocksource via bootargs. Impact: without bootargs for clocksource selection, kernel will choose dmtimer, impacting loss of time during suspend/resume. This is the right option. The problem is gptimer clocksource doesn't work across power transitions and hence it is broken. Even for the perf, with PM enabled, dmtimer can't be used or it needs to be used with 32KHz clock which makes it no better than sync timer. So here keeping 32K sync timer is default clocksource makes sense since it is the only working and viable option. So what can be done is register both 32K and gptimer together but make gptimer clocksource registration depends on PM enabled. This should solve all the needs I guess. 2) Let the current code be as is, means, the clocksource registration will Happened based on #ifdef CONFIG_OMAP_32K_TIMER and this option selection will be Controlled by Kconfig rules. We should get rid off CONFIG_OMAP_32K_TIMER. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.
On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.
The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.
Further investigation revealed that it applies to gptimer1 and watchdog
timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.
The changelog describes the problem ver well, but doesn't actually
describe the fix (enable static dep.) Can you update the changelog do
describe the fix, and why it fixes the problem.
Sure. Updated patch below. The idea is to ensure that synctimer is
syncronised before software does any reads on the counter. The BUG
will get fixed in future OMAP designs
Attaching the patch in case thunderbird email client eats the tabs.
Regards
Santosh
From 2edeebbd434627d1d0a9d96f6c5bda044a68fa70 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 Mar 2012 20:34:45 +0530
Subject: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue
with 32K synctimer.
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.
The issue is due to the synchronization methodology used in the
SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched
off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.
Further investigation revealed that it applies to gptimer1 and watchdog
timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.
The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.
By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU
is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces
the OCP clock to be running and allow the counter value to be updated
properly
in the OCP clock domain.
The bug is going to fixed in future OMAP versions.
Reported-Tested-by: dave.l...@linaro.org
[dave.l...@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c264ef7..974f7ea 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -196,7 +196,7 @@ static void omap_default_idle(void)
static int __init omap4_pm_init(void)
{
int ret;
- struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
+ struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
if (!cpu_is_omap44xx())
@@ -220,14 +220,19 @@ static int __init omap4_pm_init(void)
* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+* The L4 wakeup depedency is added to workaround the OCP sync hardware
+* BUG with 32K synctimer which lead to incorrect timer value read
+* from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+* are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup(mpuss_clkdm);
emif_clkdm = clkdm_lookup(l3_emif_clkdm);
l3_1_clkdm = clkdm_lookup(l3_1_clkdm);
l3_2_clkdm = clkdm_lookup(l3_2_clkdm);
l4_per_clkdm = clkdm_lookup(l4_per_clkdm);
+ l4wkup = clkdm_lookup(l4_wkup_clkdm);
ducati_clkdm = clkdm_lookup(ducati_clkdm);
- if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
+ if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) ||
(!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
goto err2;
@@ -235,6 +240,7 @@ static int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup
[PATCH 1/2] ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the pwrdm_wait_transition().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Rajendra Nayak rna...@ti.com
CC: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8a18d1b..96ad3dbe 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -972,7 +972,13 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm)
int pwrdm_state_switch(struct powerdomain *pwrdm)
{
- return _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
+ int ret;
+
+ ret = pwrdm_wait_transition(pwrdm);
+ if (!ret)
+ ret = _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
+
+ return ret;
}
int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API
With patch 'ARM: OMAP: powerdomain: Wait for powerdomain transition
in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes
duplicate of pwrdm_state_switch().
Get rid off duplicate pwrdm_clkdm_state_switch() and update the
users of it with pwrdm_state_switch()
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Rajendra Nayak rna...@ti.com
CC: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/mach-omap2/clockdomain.c |7 +++
arch/arm/mach-omap2/powerdomain.c | 10 --
arch/arm/mach-omap2/powerdomain.h |1 -
4 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index f57ed5b..77db067 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -439,7 +439,7 @@ void omap2_clk_disable_unused(struct clk *clk)
clk-ops-disable(clk);
}
if (clk-clkdm != NULL)
- pwrdm_clkdm_state_switch(clk-clkdm);
+ pwrdm_state_switch(clk-clkdm-pwrdm.ptr);
}
#endif
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index ad07689..8664f5a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -840,7 +840,7 @@ void clkdm_allow_idle(struct clockdomain *clkdm)
spin_lock_irqsave(clkdm-lock, flags);
clkdm-_flags |= _CLKDM_FLAG_HWSUP_ENABLED;
arch_clkdm-clkdm_allow_idle(clkdm);
- pwrdm_clkdm_state_switch(clkdm);
+ pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
}
@@ -924,8 +924,7 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_enable(clkdm);
- pwrdm_wait_transition(clkdm-pwrdm.ptr);
- pwrdm_clkdm_state_switch(clkdm);
+ pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
pr_debug(clockdomain: clkdm %s: enabled\n, clkdm-name);
@@ -950,7 +949,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_disable(clkdm);
- pwrdm_clkdm_state_switch(clkdm);
+ pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
pr_debug(clockdomain: clkdm %s: disabled\n, clkdm-name);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..9611490 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -981,16 +981,6 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
return ret;
}
-int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
-{
- if (clkdm != NULL clkdm-pwrdm.ptr != NULL) {
- pwrdm_wait_transition(clkdm-pwrdm.ptr);
- return pwrdm_state_switch(clkdm-pwrdm.ptr);
- }
-
- return -EINVAL;
-}
-
int pwrdm_pre_transition(void)
{
pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..8f88d65 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -213,7 +213,6 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm);
int pwrdm_wait_transition(struct powerdomain *pwrdm);
int pwrdm_state_switch(struct powerdomain *pwrdm);
-int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP4: powerdomain: Misc powerdomain fix and associated cleanup
Paul, Can you please have at this series ? First patch is the bug fix and second one is the cleanup which you proposed some time back. Santosh Shilimkar (2): ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() ARM: OMAP: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/clockdomain.c |7 +++ arch/arm/mach-omap2/powerdomain.c | 14 +- arch/arm/mach-omap2/powerdomain.h |1 - 4 files changed, 9 insertions(+), 15 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.
The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.
Further investigation revealed that it applies to gptimer1 and watchdog timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.
The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.
Reported-Tested-by: dave.l...@linaro.org
[dave.l...@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c264ef7..974f7ea 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -196,7 +196,7 @@ static void omap_default_idle(void)
static int __init omap4_pm_init(void)
{
int ret;
- struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
+ struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
if (!cpu_is_omap44xx())
@@ -220,14 +220,19 @@ static int __init omap4_pm_init(void)
* MPUSS - L4_PER/L3_* and DUCATI - L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+* The L4 wakeup depedency is added to workaround the OCP sync hardware
+* BUG with 32K synctimer which lead to incorrect timer value read
+* from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+* are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup(mpuss_clkdm);
emif_clkdm = clkdm_lookup(l3_emif_clkdm);
l3_1_clkdm = clkdm_lookup(l3_1_clkdm);
l3_2_clkdm = clkdm_lookup(l3_2_clkdm);
l4_per_clkdm = clkdm_lookup(l4_per_clkdm);
+ l4wkup = clkdm_lookup(l4_wkup_clkdm);
ducati_clkdm = clkdm_lookup(ducati_clkdm);
- if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
+ if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) ||
(!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
goto err2;
@@ -235,6 +240,7 @@ static int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Add TI EMIF SDRAM controller driver
On Thursday 08 March 2012 09:24 PM, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com Aneesh V (7): misc: ddr: add LPDDR2 data from JESD209-2 misc: emif: add register definitions for EMIF misc: emif: add basic infrastructure for EMIF driver misc: emif: handle frequency and voltage change events misc: emif: add interrupt and temperature handling misc: emif: add one-time settings misc: emif: add debugfs entries for emif I have scanned all the patches again. Thanks a lot for taking forward this work. Feel free to add mine SOB for entire EMIF driver series. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/13] gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote: There are two ways through which wakeup_en register can be programmed using gpiolib APIs as shown below. It is seen that in the second case in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated correctly, its value is not programmed in wakeup_en register. Fix this. chip.irq_set_type()-gpio_irq_type()-_set_gpio_triggering()-set_gpio_trigger() chip.irq_set_wake()-gpio_wake_enable()-_set_gpio_wakeup() Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Looks good. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/13] gpio/omap: remove suspend/resume callbacks
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote: Both omap_gpio_suspend() and omap_gpio_resume() does programming of wakeup_en register. _gpio_rmw(base, bank-regs-wkup_en, 0x, 0); _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1); This is redundant in omap_gpio_suspend() because wakeup_en register automatically gets initialized in _set_gpio_wakeup() and set_gpio_trigger() while being called either from chip.irq_set_wake() or chip.irq_set_type(). This is redundant in omap_gpio_resume() because wakeup_en s/This is/This is also register is programmed in omap_gpio_restore_context() called which is called from runtime resume callback. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/13] gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote: There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask() which writes to dataout register and the dataout context must be saved. It is missing in the first function, _set_gpio_dataout_reg(). Fix this. Reported-by: Govindraj Raja govindraj.r...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Good catch. Is the suspend/resume caught this issue? This can go as a fix as well. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/13] gpio/omap: remove redundant decoding of gpio offset
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
void __iomem *reg = bank-base + bank-regs-datain;
return (__raw_readl(reg) GPIO_BIT(bank, gpio)) != 0;
}
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
void __iomem *reg = bank-base;
int gpio = chip-base + offset;
u32 mask = GPIO_BIT(bank, gpio);
if (gpio_is_input(bank, mask))
return _get_gpio_datain(bank, gpio);
else
return _get_gpio_dataout(bank, gpio);
}
Given that bank-width on OMAP is either 32 or 16, and GPIO numbers for
any GPIO chip are always aligned to 32 or 16, why does this code bother
adding the chips base gpio number and then modulo the width?
Surely this means if - for argument sake - you registered a GPIO chip
with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
chip 1 bit 0..7.
However, if you registered a GPIO chip with 16 lines first, it would
mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
chip 1 bit 0..15.
Surely this kind of behaviour is not intended?
Is there a reason why the bitmask can't just be (1 offset) where
offset is passed into these functions as GPIO number - chip-base ?
Reported-by: Russell King - ARM Linux li...@arm.linux.org.uk
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Looks good.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/13] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2e8e476..ccfbae0 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1227,7 +1227,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
+ if (!bank-workaround_enabled) {
This doesn't seem to be right.
Don't you want to avoid GPIO restore for banks which are in
always on domain. Infact the purpose of enabled_non_wakeup_gpios
is exactly that ? Isn't it.
What am I missing ?
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/13] gpio/omap: fix incorrect update to context.irqenable1
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with gpio_mask.
The overwriting makes sense only in the second case where irqenable
is explicitly read and updated with new gpio_mask before writing it
back. However, for consistency reading regs-irqenable into the
bank-context.irqenable1 takes care of both the scenarios.
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
if (bank-regs-irqenable_inv)
l = ~gpio_mask;
else
l |= gpio_mask;
}
Make the same change for _disable_gpio_irqbank().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
OK.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/13] gpio/omap: fix dataout register overwrite in _set_gpio_dataout_*
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote: In the existing _set_gpio_dataout_*() implementation, the dataout register is overwritten every time the function is called. This is not intended behavior because that would end up one user of a GPIO line overwriting what is written by another. Fix this so that previous value is always preserved until explicitly changed by respective user/driver of the GPIO line. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- This can also go as fix. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: fix section mismatch warning for omap4_hotplug_cpu()
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x8b80):
Section mismatch in reference from the function omap4_hotplug_cpu() to
the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1d5d010..fe9ab7c 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -300,7 +300,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
* @cpu : CPU ID
* @power_state: CPU low power state.
*/
-int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
+int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
{
unsigned int cpu_state = 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: Section mismatch warning fixes
Tony, Below are couple of section mismatch warning fixes for v3.3-rc5 Santosh Shilimkar (2): ARM: OMAP: fix section mismatch warning for omap4_hotplug_cpu() ARM: OMAP: Fix section mismatch warning for platform_cpu_die() arch/arm/mach-omap2/omap-hotplug.c|2 +- arch/arm/mach-omap2/omap-mpuss-lowpower.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: Fix section mismatch warning for platform_cpu_die()
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit omap4_hotplug_cpu().
This is often because platform_cpu_die lacks a __cpuinit
annotation or the annotation of omap4_hotplug_cpu is wrong.
Thanks to Russell King for suggesting __ref annotation trick
just like it's parent function for this warning becasue __cupinit
usage was definitely wrong to fix this warning..
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-hotplug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index adbe4d8..56c345b 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -33,7 +33,7 @@ int platform_cpu_kill(unsigned int cpu)
* platform-specific code to shutdown a CPU
* Called with IRQs disabled
*/
-void platform_cpu_die(unsigned int cpu)
+void __ref platform_cpu_die(unsigned int cpu)
{
unsigned int this_cpu;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
On Friday 17 February 2012 04:36 PM, Marc Zyngier wrote:
On 17/02/12 10:40, Shilimkar, Santosh wrote:
On Fri, Feb 17, 2012 at 3:17 PM, Marc Zyngier marc.zyng...@arm.com wrote:
Hi Santosh,
On Fri, 17 Feb 2012 13:18:37 +0530, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[..]
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 4285daa..265a18a 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -129,7 +129,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
-if (!IS_ERR(twd_clk))
+if ((!twd_evt) (!__this_cpu_ptr(twd_evt)) (!IS_ERR(twd_clk)))
Erm... Shouldn't that rather be:
if (twd_evt *__this_cpu_ptr(twd_evt) !IS_ERR(twd_clk))
My bad. You are right. Updated patch below.
Tested on OMAP3430 SDP with CPUFREQ enabled.
Regards
Santosh
From f58c515a9d1a2c729c05a726d5176843381952ae Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 17 Feb 2012 11:11:28 +0530
Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if local
timers are not initialised.
Current ARM local timer code registers CPUFREQ notifiers even in case
the twd_timer_setup() isn't called. That seems to be wrong and
would eventually lead to kernel crash on the CPU frequency transitions
on the SOCs where the local timer doesn't exist or broken because of
hardware BUG. Fix it by testing twd_evt and *__this_cpu_ptr(twd_evt).
The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
on OMAP3 SOC which doesn't have TWD.
Below is the dump for reference :
Unable to handle kernel paging request at virtual address 007e900
pgd = cdc2
[007e9000] *pgd=
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9)
PC is at twd_update_frequency+0x34/0x48
LR is at twd_update_frequency+0x10/0x48
pc : [c001382c]lr : [c0013808]psr: 6093
sp : ce311dd8 ip : fp :
r10: r9 : 0001 r8 : ce31
r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74
r3 : r2 : 007e9000 r1 : r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr
Control: 10c5387d Table: 8dc20019 DAC: 0015
Process sh (pid: 599, stack limit = 0xce3102f8)
Stack: (0xce311dd8 to 0xce312000)
1dc0: 6000c
1de0: 0001 0002 0
1e00: c093d8f0 ce311ebc 0001 0001 ce310
1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4
1e40: c005ef74 ce31 c0435cf0 ce311ebc 0
1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0
1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8
1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330
1ec0: 0007a120 0007a120 2201 ce357
1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034
1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930
1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358
1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c
1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c
1f80: 001fbac8 0007 001fbac8 4
1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0
1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202
1fe0: beb565f8 00101ffc 8e8c 6010 0001 0
[c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] )
[c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013)
[c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c)
[c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] ()
[c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f)
[c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2)
[c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333)
[c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf)
[c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24)
[c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc)
[c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4)
[c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi)
[c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs)
[c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write)
[c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s)
Code: e594300c e792210c e1a01000 e5840004 (e7930002)
---[ end trace 5da3b5167c1ecdda ]---
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/smp_twd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 4285daa..9834851 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -129,7
Re: [RFC PATCH 1/8] OMAP4: hwmod: add EMIF hw mod data
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: From: Benoit Cousson b-cous...@ti.com One line of change log will do here. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers Signed-off-by: Aneesh V ane...@ti.com Looks good to me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers Signed-off-by: Aneesh V ane...@ti.com Sorry.. Missed one minor comment. --- drivers/misc/Kconfig |8 ++ drivers/misc/Makefile |1 + drivers/misc/jedec_ddr_data.c | 141 + include/linux/jedec_ddr.h | 174 + 4 files changed, 324 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/jedec_ddr_data.c create mode 100644 include/linux/jedec_ddr.h [...] diff --git a/drivers/misc/jedec_ddr_data.c b/drivers/misc/jedec_ddr_data.c new file mode 100644 index 000..299c056 --- /dev/null +++ b/drivers/misc/jedec_ddr_data.c @@ -0,0 +1,141 @@ +/* + * DDR addressing details and AC timing parameters from JEDEC specs + * + * Copyright (C) 2010 Texas Instruments, Inc. Fix the year please. Should be 2012 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/8] misc: emif: add register definitions for EMIF
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Signed-off-by: Aneesh V ane...@ti.com --- drivers/misc/emif_regs.h | 461 ++ 1 files changed, 461 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/emif_regs.h Changelog please. O.w looks fine to me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/8] misc: emif: add basic infrastructure for EMIF driver
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Signed-off-by: Aneesh V ane...@ti.com
---
drivers/misc/Kconfig | 12 ++
drivers/misc/Makefile |1 +
drivers/misc/emif.c | 300
+
include/linux/emif.h | 160 ++
4 files changed, 473 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/emif.c
create mode 100644 include/linux/emif.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8337bf6..d68184a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -459,6 +459,18 @@ config DDR
information. This data is useful for drivers handling
DDR SDRAM controllers.
+config EMIF
Add TI prefix here since it's TI IP and not a generic one.
+ tristate Texas Instruments EMIF driver
+ select DDR
+ help
+ This driver is for the EMIF module available in Texas Instruments
+ SoCs. EMIF is an SDRAM controller that, based on its revision,
+ supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols.
+ This driver takes care of only LPDDR2 memories presently. The
+ functions of the driver includes re-configuring AC timing
+ parameters and other settings during frequency, voltage and
+ temperature changes
+
config ARM_CHARLCD
bool ARM Ltd. Character LCD Driver
depends on PLAT_VERSATILE
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4759166..076db0f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_C2PORT)+= c2port/
obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-$(CONFIG_HMC6352)+= hmc6352.o
obj-$(CONFIG_DDR)+= jedec_ddr_data.o
+obj-$(CONFIG_EMIF) += emif.o
obj-y+= eeprom/
obj-y+= cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
new file mode 100644
index 000..ba1e3f9
--- /dev/null
+++ b/drivers/misc/emif.c
@@ -0,0 +1,300 @@
+/*
+ * EMIF driver
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
Fix year. 2012
+ *
+ * Aneesh V ane...@ti.com
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * 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
+ * published by the Free Software Foundation.
+ */
+#include linux/kernel.h
+#include linux/reboot.h
+#include linux/emif.h
+#include linux/io.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/seq_file.h
+#include linux/module.h
+#include linux/spinlock.h
+#include emif_regs.h
+
+/**
+ * struct emif_data - Per device static data for driver's use
+ * @duplicate: Whether the DDR devices attached to
this EMIF
+ * instance are exactly same as that on EMIF1. In
+ * this case we can save some memory and processing
+ * @temperature_level: Maximum temperature of LPDDR2 devices
attached
+ * to this EMIF - read from MR4 register. If there
+ * are two devices attached to this EMIF, this
+ * value is the maximum of the two temperature
+ * levels.
+ * @irq: IRQ number
+ * @lock:lock for protecting temperature_level and
+ * associated actions from race conditions
+ * @base:base address of memory-mapped IO registers.
+ * @dev: device pointer.
+ * @addressing table with addressing information from
the spec
+ * @regs_cache: An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the
last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
+ * @plat_data: Pointer to saved platform data.
+ */
+struct emif_data {
+ u8 duplicate;
+ u8 temperature_level;
+ u32 irq;
+ spinlock_t
Re: [RFC PATCH 5/8] misc: emif: handle frequency and voltage change events
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Change SDRAM timings and other settings as necessary on voltage and frequency changes. We calculate these register settings based on data from the device data sheet and inputs such a frequency, voltage state(stable or ramping), temperature level etc. May be you want add TBD or FIXME for notifiers when they are available. Do that in commit log as well as in the code so that we don't forget about it. Signed-off-by: Aneesh V ane...@ti.com --- Rest of the patch looks fine. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/8] misc: emif: add interrupt and temperature handling
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
On thermal events SDRAM timing parameters are
adjusted to ensure safe operation
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Add some more details like MR4, EMIF polling frequency etc
for better understanding.
Signed-off-by: Aneesh V ane...@ti.com
---
drivers/misc/emif.c | 209
++-
1 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 36ba6f4..5c2b0ae 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -500,6 +500,45 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the
temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ unsigned long irqs;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ spin_lock_irqsave(emif-lock, irqs);
Add a line here.
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+ spin_unlock_irqrestore(emif-lock, irqs);
+}
+
rest of the patch looks fine to me
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 7/8] misc: emif: add one-time settings
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add settings that are not dependent on frequency or any other transient parameters Expand the changelog a bit. One time settings like SDRAM_CONFIG, PHY_CONTROL, TEMP alert etc. Signed-off-by: Aneesh V ane...@ti.com --- Patch looks fine. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] misc: emif: add debugfs entries for emif
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add debug entries for: 1. calculated registers per frequency 2. last polled value of MR4(temperature level of LPDDR2 memory) Signed-off-by: Aneesh V ane...@ti.com looks good. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8] Add TI EMIF SDRAM controller driver
Andrew, Greg, On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with DVFS. This can not be done now as DVFS support is not available yet in mainline. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. [...] arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110 ++ drivers/misc/Kconfig | 20 + drivers/misc/Makefile |2 + drivers/misc/emif.c| 1522 drivers/misc/emif_regs.h | 461 + drivers/misc/jedec_ddr_data.c | 141 +++ include/linux/emif.h | 257 + include/linux/jedec_ddr.h | 174 Any suggestion on where this driver can reside. It's a memory controller driver which supports standard DDR functionality as per JDEC specs including thermal alert. On top of that it does support DVFS using the TI PRCM IP block. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
(+ linux-arm, Marc) On Thursday 16 February 2012 11:54 PM, Kevin Hilman wrote: Hi Santosh, Using v3.3-rc3 and building an OMAP2+ kernel I noticed that CPUfreq transitions fault because of the TWD cpufreq notifiers being called even on OMAP3. Of course, the TWD doesn't exist on OMAP3, but the TWD init is still setting up notifiers. I tried just adding a !cpu_is_omap44xx() check in local_timer_setup(), but that didn't do it, so there's more timer init that needs to be fixed up. Can you have a look at this? It's easy to reproduce by just manually triggering a frequency change with the userspace governor. Here's what I did on my 3430/n900: Below patch fixes the issue. Regards Santosh From 3a16f7a6694c14e201fdf6ad195c821816b2de84 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Fri, 17 Feb 2012 11:11:28 +0530 Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if local timers are not initialised. Current ARM local timer code registers CPUFREQ notifiers even in case the twd_timer_setup() isn't called. That seems to be wrong and would eventually lead to kernel crash on the CPU frequency transitions on the SOCs where the local timer doesn't exist or broken because of hardware BUG. Fix it by uisng an initialised variable. Though the twd_timer_setup() is percpu, the idea here is to avoid the CPUFREQ registration. Hence percpu initialised variable is not used. The issue was observed with v3.3-rc3 and building an OMAP2+ kernel on OMAP3 SOC which doesn't have TWD. Below is the dump for reference : Unable to handle kernel paging request at virtual address 007e900 pgd = cdc2 [007e9000] *pgd= Internal error: Oops: 5 [#1] SMP Modules linked in: CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9) PC is at twd_update_frequency+0x34/0x48 LR is at twd_update_frequency+0x10/0x48 pc : [c001382c]lr : [c0013808]psr: 6093 sp : ce311dd8 ip : fp : r10: r9 : 0001 r8 : ce31 r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74 r3 : r2 : 007e9000 r1 : r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr Control: 10c5387d Table: 8dc20019 DAC: 0015 Process sh (pid: 599, stack limit = 0xce3102f8) Stack: (0xce311dd8 to 0xce312000) 1dc0: 6000c 1de0: 0001 0002 0 1e00: c093d8f0 ce311ebc 0001 0001 ce310 1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4 1e40: c005ef74 ce31 c0435cf0 ce311ebc 0 1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0 1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8 1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330 1ec0: 0007a120 0007a120 2201 ce357 1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034 1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930 1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358 1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c 1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c 1f80: 001fbac8 0007 001fbac8 4 1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0 1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202 1fe0: beb565f8 00101ffc 8e8c 6010 0001 0 [c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] ) [c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013) [c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c) [c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] () [c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f) [c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2) [c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333) [c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf) [c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24) [c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc) [c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4) [c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi) [c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs) [c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write) [c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s) Code: e594300c e792210c e1a01000 e5840004 (e7930002) ---[ end trace 5da3b5167c1ecdda ]--- Reported-by: Kevin Hilman khil...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/smp_twd.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c index 4285daa..753ae37 100644 --- a/arch/arm/kernel/smp_twd.c +++ b/arch/arm/kernel/smp_twd.c @@ -30,6 +30,7 @@ void __iomem *twd_base
Re: [PATCH] ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor.
On Wednesday 08 February 2012 04:08 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP4 cpuidle driver is reporting the state requested by governor rather than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..f128489 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -85,6 +85,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
new_state_idx = drv-safe_state_index;
+index = drv-safe_state_index;
How about just get rid of new_state_idx all together and just update
index and use it to index in to the states.
Make sense. Updated patch below.
Regards,
Santosh
From 939dc3eda7895043c03526110e2a6b41e9861146 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 5 Feb 2012 13:18:44 +0530
Subject: [PATCH 2/2] ARM: OMAP4: cpuidle: Fix the C-state reporting to
cpuidle governor.
OMAP4 cpuidle driver is reporting the state requested by governor rather
than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
While at this, get rid of new_state_idx, update and use
index in to the states.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..72e018b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -65,7 +65,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
int idle_time;
- int new_state_idx;
int cpu_id = smp_processor_id();
/* Used to keep track of the total time in idle */
@@ -84,8 +83,8 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
- new_state_idx = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
+ index = drv-safe_state_index;
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
}
if (index 0)
--
1.7.4.1
From 939dc3eda7895043c03526110e2a6b41e9861146 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 5 Feb 2012 13:18:44 +0530
Subject: [PATCH 2/2] ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor.
OMAP4 cpuidle driver is reporting the state requested by governor rather than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
While at this, get rid of new_state_idx, update and use
index in to the states.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..72e018b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -65,7 +65,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
int idle_time;
- int new_state_idx;
int cpu_id = smp_processor_id();
/* Used to keep track of the total time in idle */
@@ -84,8 +83,8 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
- new_state_idx = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
+ index = drv-safe_state_index;
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
}
if (index 0)
--
1.7.4.1
Re: [PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
On Saturday 11 February 2012 12:49 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120202 05:33]:
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Please update this to mention again commit that changed things
around for arm_memblock_steal() so it's clear why this is needed
as a fix.
Sure. Patch with updated change log below.
Regards,
Santosh
From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as
part of reserve callback
Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away
from the kernel} introduced arm_memblock_steal() which lead to
OMAP4_ERRATA_I688 to be broken and needed to be fixed.
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |4 ++--
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c| 25
-
arch/arm/plat-omap/common.c |1 +
arch/arm/plat-omap/include/plat/omap-secure.h |6 ++
6 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d965da4..e20c8ab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -364,8 +364,8 @@ config OMAP3_SDRC_AC_TIMING
going on could result in system crashes;
config OMAP4_ERRATA_I688
- bool OMAP4 errata: Async Bridge Corruption (BROKEN)
- depends on ARCH_OMAP4 BROKEN
+ bool OMAP4 errata: Async Bridge Corruption
+ depends on ARCH_OMAP4
select ARCH_HAS_BARRIERS
help
If a data is stalled inside asynchronous bridge because of back
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..7e9338e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+void omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index eb50c29..fb11b44 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -24,6 +24,7 @@
#include plat/irqs.h
#include plat/sram.h
+#include plat/omap-secure.h
#include mach/hardware.h
#include mach/omap-wakeupgen.h
@@ -43,6 +44,9 @@ static void __iomem *sar_ram_base;
void __iomem *dram_sync, *sram_sync;
+static phys_addr_t paddr;
+static u32 size;
+
void omap_bus_sync(void)
{
if (dram_sync sram_sync) {
@@ -52,18 +56,20 @@ void omap_bus_sync(void)
}
}
-static int __init omap_barriers_init(void)
+/* Steal one page physical memory for barrier implementation */
+int __init omap_barrier_reserve_memblock(void)
{
- struct map_desc dram_io_desc[1];
- phys_addr_t paddr;
- u32 size;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
size = ALIGN(PAGE_SIZE, SZ_1M);
paddr = arm_memblock_steal(size, SZ_1M);
+ return 0;
+}
+
+void __init omap_barriers_init(void)
+{
+ struct map_desc dram_io_desc[1];
+
dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
dram_io_desc[0].pfn = __phys_to_pfn(paddr);
dram_io_desc[0].length = size;
@@ -75,9 +81,10 @@ static int __init omap_barriers_init(void)
pr_info(OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n,
(long long) paddr, dram_io_desc[0].virtual);
- return 0;
}
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{}
#endif
void __init gic_init_irq(void)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..4de7d1e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -69,6 +69,7 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_memblock
