Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On Mon, May 14, 2012 at 8:38 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 05/12/2012 05:49 PM, Linus Walleij wrote: We have some pinctrl drivers implementing gpiolib too already, and it's unavoidable I think, as some recent discussion about matcing struct gpio_chip and pinctrl GPIO ranges shows. I strongly believe we should only do this when the exact same HW module is both pinctrl and GPIO. Yep so this is what I have done for pinctrl-nomadik.c When there are separate HW modules, we should have separate drivers. The fact that the two drivers need to co-ordinate with each-other isn't a good argument to make them one driver. So this matches the pinctrl-u300.c/pinctrl-coh901.c design pattern. Maybe -simple isn't such a good name for this thing. Noone thinks any kind of pin control is simple in any sense of the word anyway :-D Tony, would pinctrl-dt-only.c be a better name perhaps? That might be OK for the filename, but it doesn't seem like a useful change for the DT compatible value. Oh I didn't think of these. Hm from a generic world running Windows Mobile etc I take it that this is seen as simple mappings then? Yours, Linus Walleij -- 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 4/6] ARM: OMAP4: PMU: Add runtime PM support
Jon, On Wed, May 16, 2012 at 6:05 AM, Ming Lei ming@canonical.com wrote: On Tuesday, May 15, 2012, Jon Hunter jon-hun...@ti.com wrote: Hi Ming, On 05/14/2012 11:53 PM, Ming Lei wrote: On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4 [1]. In Ming's original patch the CTI interrupts were being enabled during runtime when the PMU was used but they were only configured once during init. Therefore move the configuration of the CTI interrupts to the runtime PM functions. As Shilimkar pointed out, you need to give the reason why the change is introduced in the patch. Yes will do. I have been waiting to get some feedback on HW_AUTO versus SW_SLEEP from design before posting a V2. I will enhance the changelog. Looks pandaboard will hang during kernel boot with the latest next tree, so perf can't be tested now. Once the problem is fixed, l will run perf test and provide my feedback. After bisecting, looks it is the 1st commit which triggers kernel boot hang: commit 5f3aa31f77733605f04a5a92ddc475ffd439585f Merge: 0f131ea ce4deaa Author: Stephen Rothwell s...@canb.auug.org.au Date: Mon May 14 18:55:39 2012 +1000 Merge remote-tracking branch 'arm-soc/for-next' These 6 patches can't be applied against previous commit, so I can't verify these patches now. Thanks, -- Ming Lei -- 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: [PATCHv5 1/8] ARM: OMAP4: suspend: Program all domains to retention
On Tue, 2012-05-15 at 12:52 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. minor: this should probably go at the end of the series, after retention is supported. Otherwise, ending up with only this patch applied (e.g. during a git bisect) will lead to a broken boot I suspect. Ok, will move this to the end. -Tero Kevin Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 8856253..31990d5 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -101,12 +101,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- 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: Panda: USB crash with today's linux-next
On Tue, May 15, 2012 at 01:14:29PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120514 12:41]: On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120514 11:19]: * Felipe Balbi ba...@ti.com [120514 11:04]: That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ? I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization. That's mostly done.. Just need to update the patches for it. Mostly done meaning all the MMC core should need is an IRQ number part that is :) but you've done it for omap_hsmmc.c, right ? What I meant is that the whole card detection should be done at the MMC framework level. Yes what I did was just try to start gettting rid of the platform callbacks. I mean, if we tell MMC core what's the card detect IRQ number, it should be able to implement a generic version of omap_hsmmc_detect(). All that thing does is read the current gpio status number and call mmc_detect_change(). mmc_detect_change() then kicks a delayed work, which shouldn't be needed because omap_hsmmc_detect() (or the generic of it) is already using a threaded IRQ. Yeah maybe it's doable.. The MMC driver needs to read the status of the card insert, but maybe that should be just just gpio_get_value(). Then ideally the MMC driver would not have any knowledge how the GPIO is handled as it can come from whatever gpiochip using internal GPIO or TWL GPIO. correct. -- balbi signature.asc Description: Digital signature
Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
On Tue, 2012-05-15 at 14:44 -0700, Kevin Hilman wrote: Santosh, Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits: bit 0 == Secure Enable bit 1 == Non-Secure Enable The Non-Secure banked register has not changed. For those without the r1pX TRM handy, please include what this look like before (presumably 1 bit?) The changelog and in-code comments should both be enhanced. Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration will cause a problem to CPU0 Non-Secure SW. Please describe the problem, so we can better understand the specifics of the workaround. Santosh, can you provide a better changelog for this? Also, is there an erratum number for this? Nothing public. I don't think there are any public documents about ROM code, including erratas. The workaround must be: 1) Before doing the CPU1 wakeup, CPU0 must disable the GIC distributor 2) CPU1 must re-enable the GIC distributor on it's wakeup path. Again, because the problem was not described, I am not entirely sure why the workaround must be this, and how it fixes the problem. Remember to put yourself in the shoes of a reviewer who has not been deeply involved in the code, so what seems obvious to you will not be obvious to the reviewer without having to study the code and dig in to the TRMs. With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts Hmm, so I guess this means that CPU0 always has to wakeup first, even on GP devices? Yes. Also, the changelog doesn't describe what power states this affects, and whether it's an idle problem or just a supend problem. A quick glance at the code suggests that only suspend is being addressed by this patch. However, with the addition of coupled CPUidle (coming very soon now), won't we have this same problem in idle? IMO, this patch should address both. My understanding is that this happens if mpu_pwrdm goes off. Cpuidle support is not added to this patch as it does not exist yet. Probably shouldn't be that big fix. This workaround also assumes that you always want CPU1 to wakeup immediately after CPU0. I guess that will be the case for the coupled states that would be affected by this bug, but the changelog should describe that as well Yes, this patch assumes both CPUs attempt to wake-up, thus cpu1 is stuck in the hold loop. The device-off set patch #17 addresses this issue and puts cpu1 back to idle immediately if no wake request is received from cpu0. That patch should be possible to move to this set if needed. Some minor comments below... Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/omap-headsmp.S| 36 + arch/arm/mach-omap2/omap-mpuss-lowpower.c |9 ++- arch/arm/mach-omap2/omap-smp.c| 28 +- arch/arm/mach-omap2/omap4-common.c|8 +- 5 files changed, 80 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 57da7f4..48d1ebe 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -199,6 +199,7 @@ static inline void __iomem *omap4_get_scu_base(void) #endif extern void __init gic_init_irq(void); +extern void gic_dist_disable(void); extern void omap_smc1(u32 fn, u32 arg); extern void __iomem *omap4_get_sar_ram_base(void); extern void omap_do_wfi(void); @@ -206,6 +207,7 @@ extern void omap_do_wfi(void); #ifdef CONFIG_SMP /* Needed for secondary core boot */ extern void omap_secondary_startup(void); +extern void omap_secondary_startup_4460(void); extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); extern void omap_auxcoreboot_addr(u32 cpu_addr); extern u32 omap_read_auxcoreboot0(void); diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 503ac77..d602555 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -43,3 +43,39 @@ hold:ldr r12,=0x103 b secondary_startup ENDPROC(omap_secondary_startup) +ENTRY(omap_secondary_startup_4460) +hold_2:ldr r12,=0x103 + dsb + smc #0 @ read from AuxCoreBoot0 + mov r0, r0, lsr #9 + mrc p15, 0, r4, c0, c0, 5 + and r4, r4, #0x0f + cmp r0, r4 + bne hold_2 + + /* +* GIC distributor control register has changed between +* CortexA9 r1pX
Re: [PATCHv5 6/8] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states
On Tue, 2012-05-15 at 15:36 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Tero Kristo t-kri...@ti.com
Looks OK, but these new functions need some kerneldoc to describe the
decision making.
Will add.
-Tero
Kevin
---
arch/arm/mach-omap2/powerdomain44xx.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 601325b..ab00736 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -151,6 +151,21 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_POWER_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
{
u32 m, v;
@@ -179,6 +194,21 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_POWER_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -217,9 +247,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
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: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. But... Isn't the iface clock only needed to program DSS? When the DSS is just running independently, plain func clock should be enough, right? Or is iface clock used for the communication between DSS and CORE/DPLL/wakeup/something? I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. So I think that the high thresholds of 3071 and 3008 are so close to each other that there shouldn't be any real difference in practice, presuming everything works. But, for whatever reason, fetching of the pixels becomes much more inefficient or with much higher start latency, causing the underflows. I guess we'd need HW people to debug this, but their interest in OMAP3 is probably long gone. So I think I'll just have to use values that seem to work for the use cases we test. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo t-kri...@ti.com
I'll gladly take a patch that makes enable_off_mode OMAP3-only, but I am
not interested managing another new flag for OSWR.
For OMAP4, this should just be the default, and any drivers that are
broken just need to be fixed either by implementing context save/restore
or by using constraints.
Well, it is not flag as such, as it is static variable internal to
pm-debug.c. I could drop this, however it is extremely useful as a
testing feature. Without this, it is difficult to test CSWR / OSWR. If
you have taken a look at the device-off set, I am actually adding the
flag back for omap4 there for enabling device off. If this flag is also
dropped, the device will always just go to device off, in which case
testing CSWR / OSWR becomes an issue again, and I don't think this is
ideal.
Speaking of enable_off_mode, it might be possible to change it also be
static and remove all the references to it from code. Currently it is
only used from cpuidle34xx.c.
-Tero
Kevin
---
arch/arm/mach-omap2/pm-debug.c | 20
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 16
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..d9a8e42 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -39,6 +39,7 @@
#include pm.h
u32 enable_off_mode;
+static u32 enable_oswr_mode;
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
@@ -247,10 +248,13 @@ static int option_set(void *data, u64 val)
omap_pm_enable_off_mode();
else
omap_pm_disable_off_mode();
- if (cpu_is_omap34xx())
- omap3_pm_off_mode_enable(val);
+
+ omap3_pm_off_mode_enable(val);
}
+ if (option == enable_oswr_mode)
+ omap4_pm_oswr_mode_enable(val);
+
return 0;
}
@@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
pwrdm_for_each(pwrdms_setup, (void *)d);
- (void) debugfs_create_file(enable_off_mode, S_IRUGO | S_IWUSR, d,
- enable_off_mode, pm_dbg_option_fops);
+ if (cpu_is_omap34xx())
+ (void) debugfs_create_file(enable_off_mode,
+ S_IRUGO | S_IWUSR, d, enable_off_mode,
+ pm_dbg_option_fops);
+
+ if (cpu_is_omap44xx())
+ (void) debugfs_create_file(enable_oswr_mode,
+ S_IRUGO | S_IWUSR, d, enable_oswr_mode,
+ pm_dbg_option_fops);
+
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..c36ab63 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -17,6 +17,7 @@
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
+extern void omap4_pm_oswr_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index cc85576..07ac0d3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -115,6 +115,22 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
}
+void omap4_pm_oswr_mode_enable(int enable)
+{
+ u32 next_logic_state;
+ struct power_state *pwrst;
+
+ if (enable)
+ next_logic_state = PWRDM_POWER_OFF;
+ else
+ next_logic_state = PWRDM_POWER_RET;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ pwrst-next_logic_state = next_logic_state;
+ pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-next_logic_state);
+ }
+}
+
/**
* omap_default_idle - OMAP4 default ilde routine.'
*
--
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: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote: Santosh, Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits: bit 0 == Secure Enable bit 1 == Non-Secure Enable The Non-Secure banked register has not changed. For those without the r1pX TRM handy, please include what this look like before (presumably 1 bit?) The changelog and in-code comments should both be enhanced. You are right. There was only one bit previously which was used for secure/non-secure mode. So ROM over-writes the non-secure bit accidentally. Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration will cause a problem to CPU0 Non-Secure SW. Please describe the problem, so we can better understand the specifics of the workaround. Also, is there an erratum number for this? The workaround must be: 1) Before doing the CPU1 wakeup, CPU0 must disable the GIC distributor 2) CPU1 must re-enable the GIC distributor on it's wakeup path. Again, because the problem was not described, I am not entirely sure why the workaround must be this, and how it fixes the problem. Remember to put yourself in the shoes of a reviewer who has not been deeply involved in the code, so what seems obvious to you will not be obvious to the reviewer without having to study the code and dig in to the TRMs. Agree and sorry for assuming that the TRM reference should be enough. With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts Hmm, so I guess this means that CPU0 always has to wakeup first, even on GP devices? Yes. Thats the case otherwise too, on all OMAP4 devices :-( Also, the changelog doesn't describe what power states this affects, and whether it's an idle problem or just a supend problem. A quick glance at the code suggests that only suspend is being addressed by this patch. However, with the addition of coupled CPUidle (coming very soon now), won't we have this same problem in idle? IMO, this patch should address both. MPU OSWR and onwards states only. Will add that info in the changelog. This workaround also assumes that you always want CPU1 to wakeup immediately after CPU0. I guess that will be the case for the coupled states that would be affected by this bug, but the changelog should describe that as well You are right. It does affect couple idle as well. The old idle code was relying on hotplug path and this fix is in that path which helps suspend as well as cpuidle with CPU1 hotplug in/out Actually this BUG is really nasty and the WA is worst. Some minor comments below... Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/omap-headsmp.S| 36 + arch/arm/mach-omap2/omap-mpuss-lowpower.c |9 ++- arch/arm/mach-omap2/omap-smp.c| 28 +- arch/arm/mach-omap2/omap4-common.c|8 +- 5 files changed, 80 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 57da7f4..48d1ebe 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -199,6 +199,7 @@ static inline void __iomem *omap4_get_scu_base(void) #endif extern void __init gic_init_irq(void); +extern void gic_dist_disable(void); extern void omap_smc1(u32 fn, u32 arg); extern void __iomem *omap4_get_sar_ram_base(void); extern void omap_do_wfi(void); @@ -206,6 +207,7 @@ extern void omap_do_wfi(void); #ifdef CONFIG_SMP /* Needed for secondary core boot */ extern void omap_secondary_startup(void); +extern void omap_secondary_startup_4460(void); extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); extern void omap_auxcoreboot_addr(u32 cpu_addr); extern u32 omap_read_auxcoreboot0(void); diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 503ac77..d602555 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -43,3 +43,39 @@ hold: ldr r12,=0x103 b secondary_startup ENDPROC(omap_secondary_startup) +ENTRY(omap_secondary_startup_4460) +hold_2: ldr r12,=0x103 +dsb +smc #0 @ read from AuxCoreBoot0 +mov r0, r0, lsr #9 +mrc p15, 0, r4, c0, c0, 5 +and r4, r4, #0x0f +cmp r0, r4 +bne hold_2 + +/* + * GIC distributor control register has changed between + * CortexA9 r1pX and r2pX. The Control Register secure + * banked version is now composed of
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 2012-05-16 at 12:08 +0300, Tomi Valkeinen wrote: On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to me, sounds a bit related to dpll autoidle. By default it's 0, interface and functional clocks can be switched off. I tested the three other values, but none of them had any effect. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
I guess that custom set_timer_src should not be there at all anymore.
Well at least for OMAP2+.
We should just use the regular clock API to change the parent. I do not
see why we should add that wrapper on top of the clock API and thus
store some internal clock name inside the timer device init code.
Regards,
Benoit
u32 timer_capability;
};
... where timer_capability is a bit mask that indicates the timer features
supported and uses the HWMOD timer capabilities flags described in
plat/dmtimer.h. For OMAP2+ devices this allows us to read the timer
capabilities from the HWMOD data and for OMAP1 devices the flags are simply
populated by the timer initialisation code. Eventually, the aim is to read the
timer capabilities from the device tree blob.
This series includes some fixes as well as clean-up. If it is preferred to split
the series into fixes and clean-up I can do that, but wanted to get some
feedback on this approach.
This series is based upon the current linux-omap master branch. I have built
both omap1 and omap2plus configurations as well as booted the respective kernels
on the omap5912 OSK (omap1), omap2430 SDP, OMAP3430 Beagle and OMAP4460 PANDA.
Jon Hunter (9):
ARM: OMAP: Remove unnecessary clk structure
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP: Represent timer features using HWMOD flags
ARM: OMAP2+: HWMOD: Correct timer device attributes
ARM: OMAP2+: Fix external clock support for dmtimers
ARM: OMAP: Remove loses_context variable from timer platform data
ARM: OMAP: Remove timer function pointer for context loss counter
ARM: OMAP: Add flag to indicate if a timer needs a manual reset
arch/arm/mach-omap1/timer.c|3 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 24 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
arch/arm/mach-omap2/timer.c| 22 ++---
arch/arm/plat-omap/dmtimer.c | 49
arch/arm/plat-omap/include/plat/dmtimer.h | 21 ++--
7 files changed, 57 insertions(+), 78 deletions(-)
--
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] remoteproc for 3.4
Hi Linus, Please pull a tiny but quite important remoteproc fix for 3.4. The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3: Linux 3.4-rc6 (2012-05-06 15:07:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git tags/rproc-for-linus for you to fetch changes up to 6fd98c124c66b0b0001bc4217392d891b1ad4a02: remoteproc: fix off-by-one bug in __rproc_free_vrings (2012-05-13 23:15:42 +0300) Fix a nasty off-by-one remoteproc bug which leaks memory when a remote processor is shut down and, on certain circumstances, can indirectly prevent it from being reloaded. Subramaniam Chanderashekarapuram (1): remoteproc: fix off-by-one bug in __rproc_free_vrings drivers/remoteproc/remoteproc_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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] misc omap fixes for 3.5
Hi Tony, Two important fixes from Juan that are necessary to utilize the DSP on OMAP4, and a trivial hwspinlock cleanup. I tried to keep things as simple as possible, but please tell me if you want this pull request anyway differently (e.g. split to two separate fixes/cleanups requests, use an annotated signed tag, etc..). The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3: Linux 3.4-rc6 (2012-05-06 15:07:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-tony Juan Gutierrez (2): ARM: OMAP: enable mailbox irq per instance ARM: OMAP4: fix irq and clock name for dsp-iommu Ohad Ben-Cohen (1): ARM: OMAP4: hwspinlocks_init() should be static arch/arm/mach-omap2/hwspinlock.c |2 +- arch/arm/mach-omap2/mailbox.c|2 -- arch/arm/mach-omap2/omap-iommu.c |6 ++ arch/arm/plat-omap/mailbox.c | 13 + 4 files changed, 12 insertions(+), 11 deletions(-) Thanks, Ohad. -- 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: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hi Tomi, On 5/16/2012 11:08 AM, Tomi Valkeinen wrote: On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. The issues your are facing seems to be the well known DSS low power refresh mode we've been trying to use since OMAP2 :-). DPLL3 = CORE DPLL, whereas DPLL4 = PER DPLL, so that's normal that only the DPLL3 change is affecting the issue. But... Isn't the iface clock only needed to program DSS? When the DSS is just running independently, plain func clock should be enough, right? Or is iface clock used for the communication between DSS and CORE/DPLL/wakeup/something? No, the DSS does have two ports, the slave one for the register access and a master one for the DMA inside the DSS to fetch the data from the memory. So basically, what is happening is that as soon as you allow MSTANDBY to happen, the DSS will allow the iclk to be gated, and assuming the interconnect is not used by any other initiator (like USB), the CORE DPLL (DPLL3) can be gated. The issue is that when the DSS will reach the low threshold, it will de-assert the MSTANDBY to be able to get some fresh data. But since the DPLL3 was in idle, it will take several tens of us before the clock is re-enabled and thus before the interconnect can be used by the DSS to get the data. Meanwhile the DSS FIFO is still getting low. If the latency to re-enable the DPLL + interconnect is above the duration that the FIFO DSS can support, you do have some FIFO underflow. I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. That's weird, in theory what should matter is only the diff between the high and low. Well the low value should be as high as possible as well to support the wakeup latency. So I think that the high thresholds of 3071 and 3008 are so close to each other that there shouldn't be any real difference in practice, presuming everything works. But, for whatever reason, fetching of the pixels becomes much more inefficient or with much higher start latency, causing the underflows. I guess we'd need HW people to debug this, but their interest in OMAP3 is probably long gone. So I think I'll just have to use values that seem to work for the use cases we test. Anyway, in this case, a PM QoS constraint should be set on the interconnect to ensure that potentially the DPLL3 will not be autogated as soon as the iclk is gated. The point is that whereas you set the FIFO to support the wakeup latency or you prevent the idle mode because you conside the DSS cannot support that latency because FIFO cannot be merged. Except that I'm not sure the PM QoS OMAP is in mainline yet :-( Regards, Benoit -- 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 3/6] arm: omap4: support pmu
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote: + + /*configure CTI0 for pmu irq routing*/ + cti_init(omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6); + cti_unlock(omap4_cti[0]); + cti_map_trigger(omap4_cti[0], 1, 6, 2); + + /*configure CTI1 for pmu irq routing*/ + cti_init(omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6); + cti_unlock(omap4_cti[1]); + cti_map_trigger(omap4_cti[1], 1, 6, 2); As pointed in another thread, the above line should be changed to below: cti_map_trigger(omap4_cti[1], 1, 6, 3); which can avoid irq flood issue at high frequency sample mode. For detailed description about the issue and fix, see below link: http://permalink.gmane.org/gmane.linux.linaro.devel/10532 Thanks, -- Ming Lei -- 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: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Kevin, On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote: On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote: Santosh, Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits: bit 0 == Secure Enable bit 1 == Non-Secure Enable The Non-Secure banked register has not changed. For those without the r1pX TRM handy, please include what this look like before (presumably 1 bit?) The changelog and in-code comments should both be enhanced. You are right. There was only one bit previously which was used for secure/non-secure mode. So ROM over-writes the non-secure bit accidentally. Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration will cause a problem to CPU0 Non-Secure SW. Please describe the problem, so we can better understand the specifics of the workaround. Below is the updated changelog. -- ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change With MPUSS programmed to OSWR(Open Switch retention), GIC context is lost. On the CPU wakeup paths, ROM code gets executed which will setup GIC secure configurations and restore the GIC context if it was saved based on SAR_BACKUP_STATUS. The ROM Code GIC distributor restoration is split in two parts: CPU specific register done by each CPU and common register done by only one CPU. If the GIC Distributor Control Register = 1, the second CPU will not do the common GIC restoration. GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits vs only one bit before r1px: bit 0 == Secure Enable bit 1 == Non-Secure Enable Hence the value of Control register will be 3 and not 1 as the r1pX based ROM code expects. So he CPU1 on it's wakeup ROM code path, will go to the GIC initialization procedure and will so reset the full GIC and NS GIC distributor Enable bit will get cleared. Since the GIC distributor gets disabled in a live system, CPU1 will hang because the interrupts stop firing. Workaround for the issue: 1) Before doing the CPU1 wakeup, CPU0 must disable the GIC distributor and wait for it to be enabled. 2) CPU1 must re-enable the GIC distributor on it's wakeup path. With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts. The BUG is applicable to only OMAP4460(r2pX) devices. OMAP4470(r2Px), ROM code is fixed for this BUG. Let me know if it clarifies the issue ? 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: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Tero,
On Monday 14 May 2012 03:33 PM, Tero Kristo wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
GIC distributor control register has changed between CortexA9 r1pX and
r2pX. The Control Register secure banked version is now composed of 2
bits:
bit 0 == Secure Enable
bit 1 == Non-Secure Enable
[..]
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index deffbf1..c3eb9e8 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,7 @@
/* SCU base address */
static void __iomem *scu_base;
+bool omap4_smp_romcode_errata;
static DEFINE_SPINLOCK(boot_lock);
@@ -104,6 +105,24 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
* 4.3.4.2 Power States of CPU0 and CPU1
*/
if (booted) {
+ /*
+ * GIC distributor control register has changed between
+ * CortexA9 r1pX and r2pX. The Control Register secure
+ * banked version is now composed of 2 bits:
+ * bit 0 == Secure Enable
+ * bit 1 == Non-Secure Enable
+ * The Non-Secure banked register has not changed
+ * Because the ROM Code is based on the r1pX GIC, the CPU1
+ * GIC restoration will cause a problem to CPU0 Non-Secure SW.
+ * The workaround must be:
+ * 1) Before doing the CPU1 wakeup, CPU0 must disable
+ * the GIC distributor
+ * 2) CPU1 must re-enable the GIC distributor on
+ * it's wakeup path.
+ */
+ if (omap4_smp_romcode_errata)
For safety, disable local IRQ here.
local_irq_disable();
+ gic_dist_disable();
+
And CPU0 needs to wait here till CPU1 re-enables the distributor
to avoid any random issues.
The BUG is applicable for CPUIDLE as well with MPUSS OSWR state, but
we can fix the idle in another patch to avoid dependency.
Basically above 3 lines should also be part of idle code where we
wakeup the CPU1 using force wakeup.
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 1/2] of: Add generic device tree DMA helpers
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
If you read the whole exchange between I and Stephen, we converged on a
scheme of clients' node having nothing to specify and DMAC told all about
every client in one palce. Which resembles closer to reality and is
much simpler.
I already started on a patchset and should be able submit for review
in a day or two.
--
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 1/2] of: Add generic device tree DMA helpers
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
If you read the whole exchange between I and Stephen, we converged on a
scheme of clients' node having nothing to specify and DMAC told all about
every client in one palce. Which resembles closer to reality and is
much simpler.
I already started on a patchset and should be able submit for review
in a day or two.
Ok. I look forward to your implementation :-)
Jon
--
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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
I guess that custom set_timer_src should not be there at all anymore.
Well at least for OMAP2+.
We should just use the regular clock API to change the parent. I do not
see why we should add that wrapper on top of the clock API and thus
store some internal clock name inside the timer device init code.
Yes I really wanted to eliminate that function pointer too, but it was a
little trickier. The OMAP2+ code does use the clock framework to switch
the parent already, but the problem is that the OMAP1 code does not. So
we cannot have a common function for OMAP1 and OMAP2+.
One option would be to move the OMAP2+ function into the dmtimer because
it already uses the clock framework and then only populate the function
pointer for OMAP1. However, I admit this is ugly.
Let me look at this some more to see what I can do. I can at least test
on my old omap1 board now for prototyping :-)
Did you look at the rest of the series? Let me know if you are ok with
the approach and have any concerns on my hwmod changes/fix-ups ;-)
Cheers
Jon
--
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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
+ Tarun for any comments
On Wednesday 16 May 2012 05:05 AM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
};
... where timer_capability is a bit mask that indicates the timer features
supported and uses the HWMOD timer capabilities flags described in
plat/dmtimer.h. For OMAP2+ devices this allows us to read the timer
capabilities from the HWMOD data and for OMAP1 devices the flags are simply
populated by the timer initialisation code. Eventually, the aim is to read the
timer capabilities from the device tree blob.
This series includes some fixes as well as clean-up. If it is preferred to
split
the series into fixes and clean-up I can do that, but wanted to get some
feedback on this approach.
This series is based upon the current linux-omap master branch. I have built
both omap1 and omap2plus configurations as well as booted the respective
kernels
on the omap5912 OSK (omap1), omap2430 SDP, OMAP3430 Beagle and OMAP4460 PANDA.
Jon Hunter (9):
ARM: OMAP: Remove unnecessary clk structure
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP: Represent timer features using HWMOD flags
ARM: OMAP2+: HWMOD: Correct timer device attributes
ARM: OMAP2+: Fix external clock support for dmtimers
ARM: OMAP: Remove loses_context variable from timer platform data
ARM: OMAP: Remove timer function pointer for context loss counter
ARM: OMAP: Add flag to indicate if a timer needs a manual reset
arch/arm/mach-omap1/timer.c|3 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 24 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
arch/arm/mach-omap2/timer.c| 22 ++---
arch/arm/plat-omap/dmtimer.c | 49
arch/arm/plat-omap/include/plat/dmtimer.h | 21 ++--
7 files changed, 57 insertions(+), 78 deletions(-)
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 07:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
I think you're both talking about slightly different things.
Jon: You're talking about the driver code.
Jassi: You're talking about the device tree.
By including a property in the DMA client's DT node that describes which
DMA controller services it, the device (the DT node) knows about the
DMA controllers.
By moving the information to the DMA controller and specifying which DMA
clients can be serviced, that DMA client DT node no longer contains any
information about the DMA controller that serves it, and hence it's not
bound to a single controller, and hence can select from 1 of n
controllers at run-time if applicable given the HW.
Either way, the DMA client driver is just going to call some DMA channel
request API, and hence not know anything directly about the DMA controller.
--
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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/16/2012 01:14 AM, Linus Walleij wrote: On Mon, May 14, 2012 at 8:38 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 05/12/2012 05:49 PM, Linus Walleij wrote: ... Maybe -simple isn't such a good name for this thing. Noone thinks any kind of pin control is simple in any sense of the word anyway :-D Tony, would pinctrl-dt-only.c be a better name perhaps? That might be OK for the filename, but it doesn't seem like a useful change for the DT compatible value. Oh I didn't think of these. Hm from a generic world running Windows Mobile etc I take it that this is seen as simple mappings then? I can't think of anything that's much better than pinctrl-simple. Perhaps pinctrl-generic; at least that doesn't imply it's simple if we keep adding features:-) -- 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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 08:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that there some).
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/channel number is
different, then by using a global token how can I determine what the
options available for this client are?
Take your example ...
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = 891, 7, // Map mmc1_tx onto i/f 7
927, 8, // Map mmc1_rx onto i/f 8
...
};
But now I have another dmac which has the following options ...
pdma1: pdma@1000 {
...
dma_map = 598, 2, // Map mmc1_tx onto i/f 2
230, 3, // Map mmc1_rx onto i/f 3
...
};
Other than using a comment or yet another token to represent the client,
it is not clear from the arbitrary token value itself what my options are.
One way around this would be to have an enable/disable flag along with
the token such as ...
mmc1: mmc@13002000 {
...
dma_tx = 891, 1 // default tx channel
dma_rx = 927, 1 // default rx channel
dma_tx = 598, 0 // other available tx channel
dma_rx = 230, 0 // other available rx channel
...
};
That being said, we could take the same approach with using the dmac
phandle instead of the token. So you would have ...
mmc1: mmc@13002000 {
...
// phandle + channel + enable/disable
dma_tx = pdma0, 7, 1 // default tx channel
dma_rx = pdma0, 8, 1 // default rx channel
dma_tx = pdma1, 2, 0 // other available tx channel
dma_rx = pdma1, 3, 0 // other available rx channel
...
};
Then you could eliminate the random token and dma map from the dmac.
Seems easier to read too.
Cheers
Jon
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 10:44 AM, Stephen Warren wrote:
On 05/16/2012 07:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac
controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and
another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
I think you're both talking about slightly different things.
Jon: You're talking about the driver code.
Jassi: You're talking about the device tree.
Yes you are right. However, I do see Jassi's point now.
By including a property in the DMA client's DT node that describes which
DMA controller services it, the device (the DT node) knows about the
DMA controllers.
By moving the information to the DMA controller and specifying which DMA
clients can be serviced, that DMA client DT node no longer contains any
information about the DMA controller that serves it, and hence it's not
bound to a single controller, and hence can select from 1 of n
controllers at run-time if applicable given the HW.
Yes I see the need for this. My concern (and I just sent another
follow-up) was how readable is the device-tree for a human by using such
a token. Is it intuitive enough for a human to understand the options
available.
Cheers
Jon
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 10:01 AM, Jon Hunter wrote:
...
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that there some).
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/channel number is
different, then by using a global token how can I determine what the
options available for this client are?
Take your example ...
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
I believe those properties (in the DMA client) should be completely
omitted; there's no need for them.
Also, we definitely should not be using some platform-wide unique
value, but rather the phandle of the DMA client, plus some
client-defined client channel ID. ...
(oh, and - rather than _ is idiomatic for DT property names)
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = 891, 7, // Map mmc1_tx onto i/f 7
927, 8, // Map mmc1_rx onto i/f 8
...
};
So this would become:
pdma2: pdma@1080 {
...
dma-map =
... entries for channels 0.. 6
mmc1, 0, // Map mmc1_tx onto i/f 7
mmc1, 1, // Map mmc1_rx onto i/f 8
... ;
...
};
This (a) follows existing DT practice of using phandle + specifier, and
(b) makes it easy to know exactly what clients you're talking about,
since all you need to do is search for the label mmc1 throughout the DT.
But now I have another dmac which has the following options ...
pdma1: pdma@1000 {
...
dma_map = 598, 2, // Map mmc1_tx onto i/f 2
230, 3, // Map mmc1_rx onto i/f 3
...
};
Which would become something very similar:
pdma1: pdma@1000 {
...
dma-map =
... entries for channels 0.. 1
mmc1, 0, // Map mmc1_tx onto i/f 2
mmc1, 1, // Map mmc1_rx onto i/f 3
... ;
...
};
Note that dma-map here is describing the list of DMA requests that the
DMA controller knows about. As far as the binding goes, these are
irrelevant to channels; only the driver for the DMAC knows whether it
needs to use a specific channel ID to service a particular DMA request
signal, or not.
Other than using a comment or yet another token to represent the client,
it is not clear from the arbitrary token value itself what my options are.
One way around this would be to have an enable/disable flag along with
the token such as ...
mmc1: mmc@13002000 {
...
dma_tx = 891, 1 // default tx channel
dma_rx = 927, 1 // default rx channel
dma_tx = 598, 0 // other available tx channel
dma_rx = 230, 0 // other available rx channel
...
};
That being said, we could take the same approach with using the dmac
phandle instead of the token. So you would have ...
mmc1: mmc@13002000 {
...
// phandle + channel + enable/disable
dma_tx = pdma0, 7, 1 // default tx channel
dma_rx = pdma0, 8, 1 // default rx channel
dma_tx = pdma1, 2, 0 // other available tx channel
dma_rx = pdma1, 3, 0 // other available rx channel
...
};
Then you could eliminate the random token and dma map from the dmac.
Seems easier to read too.
--
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 1/2] of: Add generic device tree DMA helpers
On 16 May 2012 21:31, Jon Hunter jon-hun...@ti.com wrote:
On 05/16/2012 08:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
See below.
I think such client-req_line map should be provided to the dmac
controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and
another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that there some).
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/channel number is
different, then by using a global token how can I determine what the
options available for this client are?
Simple - you/client need not know about any option at all :)
Client driver would simply request some channel and if it
doesn't get it, it bails out.
It would be the DMACs' DT node that would contain that info.
Take your example ...
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = 891, 7, // Map mmc1_tx onto i/f 7
927, 8, // Map mmc1_rx onto i/f 8
...
};
But now I have another dmac which has the following options ...
pdma1: pdma@1000 {
...
dma_map = 598, 2, // Map mmc1_tx onto i/f 2
230, 3, // Map mmc1_rx onto i/f 3
...
};
No, rather the pdma1 node should look like
pdma1: pdma@1000 {
...
dma_map = 891, 2, // Map mmc1_tx onto i/f 2
927, 3, // Map mmc1_rx onto i/f 3
...
};
Because the tokens 891 and 927 are came from the client's node/driver.
After the DMAC driver has probed both pdma-0 1, it would
know that MMC1 could be served by 2 DMACs. And basically
its the dmac driver that should be making about routing decisions,
not the client.
Btw, everything remains same, only we have now decided to not
use tokens but phandle+req_sig_ids instead.
--
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 1/2] of: Add generic device tree DMA helpers
On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/16/2012 10:01 AM, Jon Hunter wrote:
...
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that there some).
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/channel number is
different, then by using a global token how can I determine what the
options available for this client are?
Take your example ...
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
I believe those properties (in the DMA client) should be completely
omitted; there's no need for them.
Also, we definitely should not be using some platform-wide unique
value, but rather the phandle of the DMA client, plus some
client-defined client channel ID. ...
(oh, and - rather than _ is idiomatic for DT property names)
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = 891, 7, // Map mmc1_tx onto i/f 7
927, 8, // Map mmc1_rx onto i/f 8
...
};
So this would become:
pdma2: pdma@1080 {
...
dma-map =
... entries for channels 0.. 6
mmc1, 0, // Map mmc1_tx onto i/f 7
mmc1, 1, // Map mmc1_rx onto i/f 8
... ;
...
};
This (a) follows existing DT practice of using phandle + specifier, and
(b) makes it easy to know exactly what clients you're talking about,
since all you need to do is search for the label mmc1 throughout the DT.
But now I have another dmac which has the following options ...
pdma1: pdma@1000 {
...
dma_map = 598, 2, // Map mmc1_tx onto i/f 2
230, 3, // Map mmc1_rx onto i/f 3
...
};
Which would become something very similar:
pdma1: pdma@1000 {
...
dma-map =
... entries for channels 0.. 1
mmc1, 0, // Map mmc1_tx onto i/f 2
mmc1, 1, // Map mmc1_rx onto i/f 3
... ;
...
};
Note that dma-map here is describing the list of DMA requests that the
DMA controller knows about. As far as the binding goes, these are
irrelevant to channels; only the driver for the DMAC knows whether it
needs to use a specific channel ID to service a particular DMA request
signal, or not.
OK, my guts feel people might be interested in what's cooking on
my side. I started with the binding text first and then would write
code based upon that approach.
The following might be tweaked as I look deeper into client and DMAC
drivers while deciding upon what the helper functions should be optimally...
8
Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver
DMA Model:-
Only the most common characteristics of a dma setup are assumed
in this binding.
Client: Some h/w controller that could request a DMA controller in
the system to perform data transfer on its behalf. Example SPI, MMC,
I2S etc.
DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc.
The assumed model of the DMAC, in this binding, has P peripheral
interfaces (P request signals) that could request a data transfer
and C physical channels that actually do the data transfers, hence,
at most C out of P peripherals could be served by the DMAC at any
point of time. Usually C := P, but not always. Usually, any of the
physical channels could be employed by the DMAC driver to serve any
client.
The DMAC driver identifies a client by its i/f number, 'peri_id'
on the given DMAC. For example, TX for SPI has 7th while RX_TX
(half-duplex) for MMC has 10th peripheral interface (request-signal)
on a given DMAC. Usually, any of the physical channels could be
employed by the DMAC driver to serve a client.
* DMA Controller
Required property:
- #map-cells: Number of elements in each chan-map entry.
At least 3 elements are required by this binding.
- chan-map: List of entries that specify clients' 'peri_id'.
and also possibly DMAC specific per-client data.
The first element of each entry being the client's
phandle. The second the direction of data transfer
w.r.t the client 1 for RX, 2 for TX and 3 for RX|TX.
The third the 'peri_id' of the client's request signal
on the DMAC.
Optional properties:
- #dma-peri-ifs: P, usually the DMAC driver would simply assume the
Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Santosh Shilimkar santosh.shilim...@ti.com writes: Kevin, On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote: On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote: Santosh, Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits: bit 0 == Secure Enable bit 1 == Non-Secure Enable The Non-Secure banked register has not changed. For those without the r1pX TRM handy, please include what this look like before (presumably 1 bit?) The changelog and in-code comments should both be enhanced. You are right. There was only one bit previously which was used for secure/non-secure mode. So ROM over-writes the non-secure bit accidentally. Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration will cause a problem to CPU0 Non-Secure SW. Please describe the problem, so we can better understand the specifics of the workaround. Below is the updated changelog. Much better, thanks. But it still took me several reads to fully understand. Maybe it's because the cold I have is stuffing up my head, so it takes me awhile to understand... Anyways, some minor comments to help clarify... Sorry to be so picky about changelogs, but this is a really nasty bug, and the workaround has some rather important side effects, so I want the description of the bug and the workaround to be well described. -- ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change With MPUSS programmed to OSWR(Open Switch retention), GIC context is lost. On the CPU wakeup paths, ROM code gets executed which will setup GIC secure configurations and restore the GIC context if it was saved based on SAR_BACKUP_STATUS. The ROM Code GIC distributor restoration is split in two parts: CPU specific register done by each CPU and common register done by only one CPU. If the GIC Distributor Control Register = 1, the second CPU will not do the common GIC restoration. s/second CPU/second CPU to wake up/ GIC distributor control register has changed between CortexA9 r1pX and r2pX. The Control Register secure banked version is now composed of 2 bits vs only one bit before r1px: before r1pX? bit 0 == Secure Enable bit 1 == Non-Secure Enable And what did this look like for r1pX?Presumably bit0 was non-secure enable? Hence the value of Control register will be 3 and not 1 as the r1pX based ROM code expects. Why will it be 3? Will it be 3 on GP devices? So he CPU1 on it's wakeup ROM code path, will s/it's/its/ go to the GIC initialization procedure and will so reset the full GIC and NS GIC distributor Enable bit will get cleared. This is where it's confusing. On r2pX, NS enable bit is bit 1. It's not mentioned here, but I'm assuming that it's bit 0 on r1pX, right? (I can't seem to find an r1pX TRM) Since ROM code is r1pX-based, I would assume that it would continue to clear bit 0, which is only now the secure enable bit? Or, is it the case that ROM code clears all the bits? That should be described. Since the GIC distributor gets disabled in a live system, CPU1 will hang because the interrupts stop firing. 1) Before doing the CPU1 wakeup, CPU0 must disable the GIC distributor and wait for it to be enabled. what does 'disable GIC distributor' mean. secure? non-secure? both? 2) CPU1 must re-enable the GIC distributor on it's wakeup path. Describe why this works. e.g. because it cause ROM code to skip its broken restore path. With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts. The BUG is applicable to only OMAP4460(r2pX) devices. OMAP4470(r2Px), ROM code is fixed for this BUG. OMAP4470 (also r2pX) is not affected by this bug because ROM code has been fixed. Kevin Let me know if it clarifies the issue ? 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 -- 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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 11:22 AM, Jassi Brar wrote:
[...]
OK, my guts feel people might be interested in what's cooking on
my side. I started with the binding text first and then would write
code based upon that approach.
The following might be tweaked as I look deeper into client and DMAC
drivers while deciding upon what the helper functions should be optimally...
8
Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver
DMA Model:-
Only the most common characteristics of a dma setup are assumed
in this binding.
Client: Some h/w controller that could request a DMA controller in
the system to perform data transfer on its behalf. Example SPI, MMC,
I2S etc.
DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc.
The assumed model of the DMAC, in this binding, has P peripheral
interfaces (P request signals) that could request a data transfer
and C physical channels that actually do the data transfers, hence,
at most C out of P peripherals could be served by the DMAC at any
point of time. Usually C := P, but not always. Usually, any of the
physical channels could be employed by the DMAC driver to serve any
client.
The DMAC driver identifies a client by its i/f number, 'peri_id'
on the given DMAC. For example, TX for SPI has 7th while RX_TX
(half-duplex) for MMC has 10th peripheral interface (request-signal)
on a given DMAC. Usually, any of the physical channels could be
employed by the DMAC driver to serve a client.
* DMA Controller
Required property:
- #map-cells: Number of elements in each chan-map entry.
At least 3 elements are required by this binding.
- chan-map: List of entries that specify clients' 'peri_id'.
and also possibly DMAC specific per-client data.
The first element of each entry being the client's
phandle. The second the direction of data transfer
w.r.t the client 1 for RX, 2 for TX and 3 for RX|TX.
The third the 'peri_id' of the client's request signal
on the DMAC.
Optional properties:
- #dma-peri-ifs: P, usually the DMAC driver would simply assume the
number of entries in the 'chan-map' property to be the
effective number of peripheral request interfaces on the
DMAC. If specified, it should be at least the number of
entries in the 'chan-map' property.
- #dma-channels: C, if specified, it should neither be more than
the value of 'dma-peri-ifs' nor equal to zero.
If unspecified, it is assumed to be equal to the value of
'dma-peri-ifs', i.e, C := P
- #private-data: Peculiarities of the DMAC setup, not taken into
account by this generic model. The decoding of it would
be private to the DMAC's driver. For ex, some DMAC drivers
for dmaengine would specify dma_cap_mask_t for the DMAC,
if they don't need to specify it on a per-client basis
(i.e, via 4th element of a 'chan-map' entry).
Example:
dma-controller@0 {
compatible = foo,dmac-xxx;
#private-data = 0x80808080;
#dma-peri-ifs = 32;
#dma-channels = 8;
#map-cells = 3;
chan-map =
i2s1 1 2, /* peri_id of I2S's RX is 2 */
i2s1 2 3, /* peri_id of I2S's TX is 3 */
mmc1 3 5, /* peri_id of MMC's RX_TX is 5 */
spi1 1 6,
spi1 2 8,
...;
};
* Client Controller
Required property: None.
The client's DT node doesn't need any DMA specifier.
Typically it would only comment about the data transfer
direction associated with each of its request signal.
Preferably also mentioned in the binding.
Optional property: None.
May be I am still missing something here, but in the case where a client
can use one of two dma controllers, how do you specify which to use? Who
decides?
I was under the impression that you would use the phandle of the dma
controller to specify which controller is used in the client node.
For example ...
i2s1: i2s@70002800 {
/* This controller has a request-signal for TX and RX each
* i.e, the driver is going to request a channel for RX(1)
* and another for TX(2).
*/
dma = dma-controller0
...
};
Cheers
Jon
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 11:16 AM, Jassi Brar wrote:
On 16 May 2012 21:31, Jon Hunter jon-hun...@ti.com wrote:
On 05/16/2012 08:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is
return.
See below.
I think such client-req_line map should be provided to the dmac
controller
driver via its dt node in some format. The dmac driver could then
populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and
another
for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
But the client is required to specify the dmac that would serve it.
Which is more
than simply asking for some suitable channel.
No this is not the case with what I propose. The client knows nothing
about the dmac.
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that there some).
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/channel number is
different, then by using a global token how can I determine what the
options available for this client are?
Simple - you/client need not know about any option at all :)
Client driver would simply request some channel and if it
doesn't get it, it bails out.
It would be the DMACs' DT node that would contain that info.
Yes, but what if I am doing some custom application and want to modify
the mapping that is being used? So I just wanted to make sure it is easy
to understand assuming that you understand what your h/w is capable of.
Take your example ...
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = 891, 7, // Map mmc1_tx onto i/f 7
927, 8, // Map mmc1_rx onto i/f 8
...
};
But now I have another dmac which has the following options ...
pdma1: pdma@1000 {
...
dma_map = 598, 2, // Map mmc1_tx onto i/f 2
230, 3, // Map mmc1_rx onto i/f 3
...
};
No, rather the pdma1 node should look like
pdma1: pdma@1000 {
...
dma_map = 891, 2, // Map mmc1_tx onto i/f 2
927, 3, // Map mmc1_rx onto i/f 3
...
};
Because the tokens 891 and 927 are came from the client's node/driver.
After the DMAC driver has probed both pdma-0 1, it would
know that MMC1 could be served by 2 DMACs. And basically
its the dmac driver that should be making about routing decisions,
not the client.
Btw, everything remains same, only we have now decided to not
use tokens but phandle+req_sig_ids instead.
Ok, yes Stephen clarified that too. Makes sense.
Cheers
Jon
--
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 1/2] of: Add generic device tree DMA helpers
On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote: What is still unclear to me, is if you use this token approach how readable is the device-tree? For example, if you have a client that can use one of two dmac and for each dmac the request/channel number is different, then by using a global token how can I determine what the options available for this client are? Simple - you/client need not know about any option at all :) Client driver would simply request some channel and if it doesn't get it, it bails out. It would be the DMACs' DT node that would contain that info. Yes, but what if I am doing some custom application and want to modify the mapping that is being used? So I just wanted to make sure it is easy to understand assuming that you understand what your h/w is capable of. Any scenario when a client would want to choose which dma controller it runs on? Because when we say a client could be provided a channel on any of the two given dmacs, it implies that the client wouldn't feel any difference. -- 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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 12:24 PM, Jassi Brar wrote: On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote: What is still unclear to me, is if you use this token approach how readable is the device-tree? For example, if you have a client that can use one of two dmac and for each dmac the request/channel number is different, then by using a global token how can I determine what the options available for this client are? Simple - you/client need not know about any option at all :) Client driver would simply request some channel and if it doesn't get it, it bails out. It would be the DMACs' DT node that would contain that info. Yes, but what if I am doing some custom application and want to modify the mapping that is being used? So I just wanted to make sure it is easy to understand assuming that you understand what your h/w is capable of. Any scenario when a client would want to choose which dma controller it runs on? Because when we say a client could be provided a channel on any of the two given dmacs, it implies that the client wouldn't feel any difference. That's not my point. I am saying for some reason, maybe QoS, _I_ want to specify which mapping used. I am the one that knows how the h/w is being used and _I_ want to customise the dma/channel mapping in the DT, such that when the client asks for it I know what it is getting. Yes to the client, it does not care, but I do. Jon -- 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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 11:37 AM, Jon Hunter wrote: On 05/16/2012 12:24 PM, Jassi Brar wrote: On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote: What is still unclear to me, is if you use this token approach how readable is the device-tree? For example, if you have a client that can use one of two dmac and for each dmac the request/channel number is different, then by using a global token how can I determine what the options available for this client are? Simple - you/client need not know about any option at all :) Client driver would simply request some channel and if it doesn't get it, it bails out. It would be the DMACs' DT node that would contain that info. Yes, but what if I am doing some custom application and want to modify the mapping that is being used? So I just wanted to make sure it is easy to understand assuming that you understand what your h/w is capable of. Any scenario when a client would want to choose which dma controller it runs on? Because when we say a client could be provided a channel on any of the two given dmacs, it implies that the client wouldn't feel any difference. That's not my point. I am saying for some reason, maybe QoS, _I_ want to specify which mapping used. I am the one that knows how the h/w is being used and _I_ want to customise the dma/channel mapping in the DT, such that when the client asks for it I know what it is getting. Yes to the client, it does not care, but I do. If you really need to do that, you could always just lie in the DT node of the DMA controllers you don't want to use, and omit the entry for the DMA client(s) you don't want to use it. Still, this all seems like policy that the DT file shouldn't really be influencing. Admittedly, I'm not sure how else you'd achieve this. -- 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: [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo t-kri...@ti.com
I'll gladly take a patch that makes enable_off_mode OMAP3-only, but I am
not interested managing another new flag for OSWR.
For OMAP4, this should just be the default, and any drivers that are
broken just need to be fixed either by implementing context save/restore
or by using constraints.
Well, it is not flag as such, as it is static variable internal to
pm-debug.c. I could drop this, however it is extremely useful as a
testing feature. Without this, it is difficult to test CSWR / OSWR.
I understand its usefulness for testing (and I will use it to test this
series), but IMO it should live out of tree. Having this in tree makes
it possible for drivers to be merged that don't support off-mode. I
added this flag to OMAP3 as a short-term feature hoping that drivers
would eventually be converted, and I was wrong. We still have drivers
that don't support off-mode upstream. I don't want to make that mistake
again.
If you have taken a look at the device-off set, I am actually adding
the flag back for omap4 there for enabling device off. If this flag is
also dropped, the device will always just go to device off, in which
case testing CSWR / OSWR becomes an issue again, and I don't think
this is ideal.
Speaking of enable_off_mode, it might be possible to change it also be
static and remove all the references to it from code. Currently it is
only used from cpuidle34xx.c.
I would prefer to get rid of all of these flags, and use the new sysfs
controls[1] for CPUidle C-states to disable/enable certain C-states for
debugging/testing.
Kevin
[1] Example shell snippet using new sysfs interface:
# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
if [ -e ${state} ]; then
echo 1 ${state}/disable
fi
done
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 12:46 PM, Stephen Warren wrote: On 05/16/2012 11:37 AM, Jon Hunter wrote: On 05/16/2012 12:24 PM, Jassi Brar wrote: On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote: What is still unclear to me, is if you use this token approach how readable is the device-tree? For example, if you have a client that can use one of two dmac and for each dmac the request/channel number is different, then by using a global token how can I determine what the options available for this client are? Simple - you/client need not know about any option at all :) Client driver would simply request some channel and if it doesn't get it, it bails out. It would be the DMACs' DT node that would contain that info. Yes, but what if I am doing some custom application and want to modify the mapping that is being used? So I just wanted to make sure it is easy to understand assuming that you understand what your h/w is capable of. Any scenario when a client would want to choose which dma controller it runs on? Because when we say a client could be provided a channel on any of the two given dmacs, it implies that the client wouldn't feel any difference. That's not my point. I am saying for some reason, maybe QoS, _I_ want to specify which mapping used. I am the one that knows how the h/w is being used and _I_ want to customise the dma/channel mapping in the DT, such that when the client asks for it I know what it is getting. Yes to the client, it does not care, but I do. If you really need to do that, you could always just lie in the DT node of the DMA controllers you don't want to use, and omit the entry for the DMA client(s) you don't want to use it. Exactly. The point I am trying to make, is that whatever binding we have it needs to be intuitive such that someone who knows the hardware could customise by removing entries, etc. This is probably a mute point now that we are not using the token scheme, but I wanted to be clear that I could see people customising the stock dev-trees in the kernel for their particular application. That's all. Jon -- 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: [PATCHv2 01/19] ARM: OMAP4: PM: powerdomain: Add HWSAR flag to L3INIT
Tero Kristo t-kri...@ti.com writes:
From: Santosh Shilimkar santosh.shilim...@ti.com
L3INIT powerdomain has USB HOST and USB TLL modules which support
hardware save-and-restore (HW SAR) mechanism.
This patch updates the L3INIT power domain to mark them as capable
of doing H/w save and restore and provides functions to do them
explicitly.
Note: Eventually, these custom function implementation will be
abstracted and might be done in hwmod or in other layer.
Why not do it the right way now?
Also, these new functions need kerneldoc.
Kevin
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain44xx.c | 41
+++
arch/arm/mach-omap2/powerdomains44xx_data.c |2 +-
2 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index ab00736..37f7e12 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -23,6 +23,10 @@
#include prm44xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
+#include cm-regbits-44xx.h
+#include prcm44xx.h
+#include cm2_44xx.h
+#include cminst44xx.h
static int omap4_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
@@ -238,6 +242,41 @@ static int omap4_pwrdm_wait_transition(struct
powerdomain *pwrdm)
return 0;
}
+static int omap4_pwrdm_enable_hdwr_sar(struct powerdomain *pwrdm)
+{
+ /*
+ * FIXME: This should be fixed right way by moving it into HWMOD
+ * or clock framework since sar control is moved to module level
+ */
+ omap4_cminst_rmw_inst_reg_bits(OMAP4430_SAR_MODE_MASK,
+ 1 OMAP4430_SAR_MODE_SHIFT, OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+ OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET);
+ omap4_cminst_rmw_inst_reg_bits(OMAP4430_SAR_MODE_MASK,
+ 1 OMAP4430_SAR_MODE_SHIFT, OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+ OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET);
+ return 0;
+}
+
+static int omap4_pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm)
+{
+ /*
+ * FIXME: This should be fixed right way by moving it into HWMOD
+ * or clock framework since sar control is moved to module level
+ */
+ omap4_cminst_rmw_inst_reg_bits(OMAP4430_SAR_MODE_MASK,
+ 0 OMAP4430_SAR_MODE_SHIFT, OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+ OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET);
+ omap4_cminst_rmw_inst_reg_bits(OMAP4430_SAR_MODE_MASK,
+ 0 OMAP4430_SAR_MODE_SHIFT, OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+ OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET);
+
+ return 0;
+}
+
struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_set_next_pwrst = omap4_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
@@ -255,4 +294,6 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
+ .pwrdm_enable_hdwr_sar = omap4_pwrdm_enable_hdwr_sar,
+ .pwrdm_disable_hdwr_sar = omap4_pwrdm_disable_hdwr_sar,
};
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 704664c..d8701ce 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -276,7 +276,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* l3init_bank1 */
},
- .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE | PWRDM_HAS_HDWR_SAR,
};
/* l4per_44xx_pwrdm: Target peripherals power domain */
--
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: [PATCHv2 02/19] ARM: OMAP4: Add SAR ROM base address
Tero Kristo t-kri...@ti.com writes: Added in preparation for device off mode. SAR ROM contains the mapping from SAR RAM to IO registers, and this will eventually be parsed during init time to do the reverse before device off. Signed-off-by: Tero Kristo t-kri...@ti.com This should be combined with the patch that uses the #define. Kevin --- arch/arm/plat-omap/include/plat/omap44xx.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h index c0d478e..1a45700 100644 --- a/arch/arm/plat-omap/include/plat/omap44xx.h +++ b/arch/arm/plat-omap/include/plat/omap44xx.h @@ -46,6 +46,7 @@ #define OMAP44XX_MCPDM_BASE 0x40132000 #define OMAP44XX_MCPDM_L3_BASE 0x49032000 #define OMAP44XX_SAR_RAM_BASE0x4a326000 +#define OMAP44XX_SAR_ROM_BASE0x4a05e000 #define OMAP44XX_MAILBOX_BASE(L4_44XX_BASE + 0xF4000) #define OMAP44XX_HSUSB_OTG_BASE (L4_44XX_BASE + 0xAB000) -- 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 1/2] of: Add generic device tree DMA helpers
On Wednesday 16 May 2012, Jassi Brar wrote: On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:- Only the most common characteristics of a dma setup are assumed in this binding. Client: Some h/w controller that could request a DMA controller in the system to perform data transfer on its behalf. Example SPI, MMC, I2S etc. DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc. The assumed model of the DMAC, in this binding, has P peripheral interfaces (P request signals) that could request a data transfer and C physical channels that actually do the data transfers, hence, at most C out of P peripherals could be served by the DMAC at any point of time. Usually C := P, but not always. Usually, any of the physical channels could be employed by the DMAC driver to serve any client. The DMAC driver identifies a client by its i/f number, 'peri_id' on the given DMAC. For example, TX for SPI has 7th while RX_TX (half-duplex) for MMC has 10th peripheral interface (request-signal) on a given DMAC. Usually, any of the physical channels could be employed by the DMAC driver to serve a client. I'm still anything but convinced by this model. Basically it's the exact opposite of what we do for every other subsystem (irq, pinctrl, regulator, gpio, ...), where the device using some infrastructure contains the information about who provides it, whereas here you move all the information into the device that provides the functionality, and have no handle in the device using it by which the driver can identify it. I believe that it can work and that it solves the problem you are faced with at minimal complexity, but you put the burden of this complexity on everybody who does not have this issue, and make the general binding confusing and harder to read. It also adds much more data to the device tree (in source and binary form) because you need to describe every device using a dma controller and have a label to reference it. More importantly, you make it very hard to add devices in a board file to a dma controller that already has descriptions for some channels, because you cannot easily extend the chan-map unless you rewrite all of it. We really need something simpler than this for the common case. I have already made suggestions for how to make it still possible to cover the corner case of multiple dma engines connected to the same slave, which would keep the complexity local to those devices that actually need it. Arnd -- 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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
I guess that custom set_timer_src should not be there at all anymore.
Well at least for OMAP2+.
We should just use the regular clock API to change the parent. I do not
see why we should add that wrapper on top of the clock API and thus
store some internal clock name inside the timer device init code.
I have been looking into this and in order to get rid for the above
function pointer we would need to move at a minimum the following
functions from omap-mach2/clkt_clksel.c into the platform code.
_get_clksel_by_parent()
_get_div_and_fieldval()
_write_clksel_reg()
omap2_init_clksel_parent()
omap2_clksel_set_parent()
However, it may be simpler just to move the clkt_clksel.c file
completely. I have tested the above functions on omap1 and they are
working well. However, before doing this we would need to get Paul's
buy-in that this is the right thing to do.
Paul, do you have any thoughts on this? We were trying to see if we
could eliminate the dmtimer function pointer for setting the timer clock
source.
Also, the only other minor issue I see is that for omap1 devices instead
of having sys_ck as the name the clock name is armxor_ck. We cannot
rename armxor_ck as it is used by many peripherals but we could use a
#define to workaround this or add a dummy clock node.
Cheers
Jon
--
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 1/2] of: Add generic device tree DMA helpers
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:- Only the most common characteristics of a dma setup are assumed in this binding. Client: Some h/w controller that could request a DMA controller in the system to perform data transfer on its behalf. Example SPI, MMC, I2S etc. DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc. The assumed model of the DMAC, in this binding, has P peripheral interfaces (P request signals) that could request a data transfer and C physical channels that actually do the data transfers, hence, at most C out of P peripherals could be served by the DMAC at any point of time. Usually C := P, but not always. Usually, any of the physical channels could be employed by the DMAC driver to serve any client. The DMAC driver identifies a client by its i/f number, 'peri_id' on the given DMAC. For example, TX for SPI has 7th while RX_TX (half-duplex) for MMC has 10th peripheral interface (request-signal) on a given DMAC. Usually, any of the physical channels could be employed by the DMAC driver to serve a client. Btw, just to be clear... this is not _my_ setup. The dma controller manuals might use different terms but underneath most(if not all) dma controllers fit this model. At lease every dmac on Samsung SoCs and ARM's PL330 and PL08x does. In fact, I have trouble imaging some dmac not conforming to this model... but then again it could be just me. I'm still anything but convinced by this model. Basically it's the exact opposite of what we do for every other subsystem (irq, pinctrl, regulator, gpio, ...), where the device using some infrastructure contains the information about who provides it, whereas here you move all the information into the device that provides the functionality, and have no handle in the device using it by which the driver can identify it. The idea was that a client shouldn't need to know/tell which dma controller serves it or which peripheral interface of a dma controller. I think in future third-party device IPs, like ARM's Primecell, are only gonna get more common so it makes even more sense. I believe that it can work and that it solves the problem you are faced with at minimal complexity, but you put the burden of this complexity on everybody who does not have this issue, and make the general binding confusing and harder to read. I am sorry if I gave you the wrong impression, but I didn't intend to just scratch my personal itch. I truly believed I and Stephen reached a generic solution i.e, as much as it could be. It also adds much more data to the device tree (in source and binary form) because you need to describe every device using a dma controller and have a label to reference it. I don't see why one can't add entries to chan-map as and when more clients appear for the DMAC ? It should be perfectly ok to specify less than the maximum possible clients in chan-map. Requiring labels - yes, doesn't sound very nice, but many nodes already do. More importantly, you make it very hard to add devices in a board file to a dma controller that already has descriptions for some channels, because you cannot easily extend the chan-map unless you rewrite all of it. I am not sure I understand the point. We really need something simpler than this for the common case. I have already made suggestions for how to make it still possible to cover the corner case of multiple dma engines connected to the same slave, which would keep the complexity local to those devices that actually need it. Thanks $DEITY, I posted a preview. Maybe I should put it on hold. And thank you for speaking up immediately. Really! -- 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: [PATCHv2 03/19] ARM: OMAP4: PM: Add device-off support
+Jean for functional power states Tero Kristo t-kri...@ti.com writes: This patch adds device off support to OMAP4 device type. Description is rather thin for a patch that is doing so much. OFF mode is disabled by default, why? however, there are two ways to enable OFF mode: a) In the board file, call omap4_pm_off_mode_enable(1) b) Enable OFF mode using the debugfs entry echo 1/sys/kernel/debug/pm_debug/enable_off_mode (conversely echo '0' will disable it as well). This part needs to be a separate patch. But, as stated in the core retention series, I'd like to move away from these global flags all together. The way we manage the disabling of certain states (like off) is already clumsy for OMAP3, and it's getting worse with OMAP4. Basically, I think this feature needs to be supported by using constraints on functional power states. Having checks all over the place is getting unwieldy and not attractive to maintain. The combination of constraints and functional power states should make this much more manageable. Until we have that, I'd prefer to keep the debugfs enable/disable stuff as separate patches at the end of the series used only for testing. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [t-kri...@ti.com: largely re-structured the code] then the sign-off above from Santosh probably doesn't apply anymore. You should change that to a Cc and just mention tht this is based upon some original work from Santosh. First, some general comments: There is a lot going on in this patch, so it is hard to follow what all is related, and why. Just a quick glance suggests it needs to be broken up into at least a few parts: - low-level PRM support: new APIs for various off-mode features) (should probably be done on top of functional power states) - powerdomain core support or achievable states (should probably be done on top of functional power states) - IRQ/GIC context save/restore - secure RAM save/restore (this has been tightly coupled to the GIC but it's not obvious why) - PM debug support to enable/disable off-mode (for testing only, not for merge) Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 10 - arch/arm/mach-omap2/omap-wakeupgen.c | 47 +++- arch/arm/mach-omap2/pm-debug.c| 17 +-- arch/arm/mach-omap2/pm.h | 20 + arch/arm/mach-omap2/pm44xx.c | 45 +++ arch/arm/mach-omap2/prm44xx.c | 66 + 6 files changed, 197 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c index e02c082..7418e7c 100644 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c @@ -60,6 +60,7 @@ #include prcm44xx.h #include prm44xx.h #include prm-regbits-44xx.h +#include cm44xx.h #ifdef CONFIG_SMP @@ -263,9 +264,13 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) * In MPUSS OSWR or device OFF, interrupt controller contest is lost. */ mpuss_clear_prev_logic_pwrst(); - if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET) + if (omap4_device_next_state_off()) + save_state = 3; Why? I don't see why this check is needed in addition to the mpuss_pd check added just below? + else if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET) (pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF)) save_state = 2; + else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) + save_state = 3; cpu_clear_prev_logic_pwrst(cpu); set_cpu_next_pwrst(cpu, power_state); @@ -288,6 +293,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) wakeup_cpu = smp_processor_id(); set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON); + if (omap4_device_prev_state_off()) + omap4_device_clear_prev_off_state(); + The 'clear prev off state' is subsequently removed in the last patch ARM: OMAP4: powerdomain: update mpu / core off counters during device off. Why is it needed here? pwrdm_post_transition(); return 0; diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index 42cd7fb..805d08d 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -32,6 +32,7 @@ #include omap4-sar-layout.h #include common.h +#include pm.h #define NR_REG_BANKS 4 #define MAX_IRQS 128 @@ -46,6 +47,8 @@ static void __iomem *sar_base; static DEFINE_SPINLOCK(wakeupgen_lock); static unsigned int irq_target_cpu[NR_IRQS]; +static struct powerdomain *mpuss_pd; + /* * Static helper functions. */ @@ -259,7 +262,7 @@ static void irq_save_context(void) /* * Clear
Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com SAR/ROM code restores only CORE DPLL to its original state post wakeup from OFF mode. The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER) are saved and restored here during an OFF transition. [n...@ti.com: minor cleanups] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Some general comments: - the register dump/print doesn't belong here. If needed, should be a debug feature if needed. - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. Kevin -- 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: [PATCHv2 05/19] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode
Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com Restore all CM1/2 module registers as they are lost in OFF mode. Save and restore? Also, as in the previous patch. Can this be done using cluster PM notifier as well?(I realize that this series was probably done before the PM notifiers were upstream, but now that we have them, we should use them.) Kevin -- 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: [PATCHv2 06/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF
Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com The SAR RAM is maintained during Device OFF mode. so why is this patch bothering to save and restore it? -ECONFUSED The register layout is fixed in SAR ROM. SAR is split into 4 banks with different privilege accesses based on device type --- Access mode BankAddress Range --- HS/GP : Public 1 0x4A32_6000 - 0x4A32_6FFF (4kB) HS/GP : Public 2 0x4A32_7000 - 0x4A32_73FF (1kB) HS/EMU : Secured GP : Public 3 0x4A32_8000 - 0x4A32_87FF (2kB) HS/GP :Secure write once. 4 0x4A32_9000 - 0x4A32_93FF (1kB) --- The save process is done entirely by software and restore is done by hardware using the auto-restore feature. The restore feature is enabled by default and cannot be disabled. The software must save the data to be restored in a dedicated location in SAR RAM. Some general comments: - can the cluster PM notifier be used for the save path? - This patch adds lots of data that is immediately removed by the next patch. Probably the two just need to be combined. - BUG_ON() should not be used unless there is absolutely no recovery path, since it casues a full kernel panic. Instead, some error recovery should be added. Kevin -- 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: [PATCHv2 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA
Tero Kristo t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com The ROM BUG is when MPU Domain OFF wake up sequence that can compromise IVA and Tesla execution. At wakeup from MPU OFF on HS device only (not GP device), when restoring the Secure RAM, the ROM Code reconfigures the clocks the same way it is done at Cold Reset. Ouch. The IVAHD Clocks and Power Domain settings are: IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF The TESLA Clocks and Power Domain settings are: TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF This patch fixes the low power OFF mode code so that the these registers are saved and restore across MPU OFF state. Also because of this limitation, MPU OFF alone is not targeted without device OFF to avoid IVAHD and TESLA execution impact I don't see where this restriction is implemented. And, can this be hooked into cluster PM notifiers. Kevin -- 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: [PATCHv2 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA
On 05/16/2012 04:05 PM, Kevin Hilman wrote: Tero Kristot-kri...@ti.com writes: From: Santosh Shilimkarsantosh.shilim...@ti.com The ROM BUG is when MPU Domain OFF wake up sequence that can compromise IVA and Tesla execution. At wakeup from MPU OFF on HS device only (not GP device), when restoring the Secure RAM, the ROM Code reconfigures the clocks the same way it is done at Cold Reset. Ouch. The IVAHD Clocks and Power Domain settings are: IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF The TESLA Clocks and Power Domain settings are: TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF This patch fixes the low power OFF mode code so that the these registers are saved and restore across MPU OFF state. Also because of this limitation, MPU OFF alone is not targeted without device OFF to avoid IVAHD and TESLA execution impact I don't see where this restriction is implemented. And, can this be hooked into cluster PM notifiers. Especially since this only effects a subset of revisions, installing the notifier only on effected revisions also removes any overhead on working revisions. Kevin -- 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: [PATCHv2 11/19] ARM: OMAP4: PM: save/restore CM L3INSTR registers when MPU hits OSWR/OFF mode
Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com On HS devices on the way out of MPU OSWR and OFF ROM code wrongly overwrites the CM L3INSTR registers. So to avoid this, save them and restore on the way out from MPU OSWR/OFF. This errata applies to all HS/EMU versions of OMAP4. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [t-kri...@ti.com: added omap4 pm errata support] Signed-off-by: Tero Kristo t-kri...@ti.com Let's use the cluster PM notifiers here too, using the PM errata check when registering the notifier. Kevin -- 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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
Hello Jon, On Wed, 16 May 2012, Jon Hunter wrote: I have been looking into this and in order to get rid for the above function pointer we would need to move at a minimum the following functions from omap-mach2/clkt_clksel.c into the platform code. By platform code, do you mean arch/arm/plat-omap? _get_clksel_by_parent() _get_div_and_fieldval() _write_clksel_reg() omap2_init_clksel_parent() omap2_clksel_set_parent() However, it may be simpler just to move the clkt_clksel.c file completely. I have tested the above functions on omap1 and they are working well. However, before doing this we would need to get Paul's buy-in that this is the right thing to do. Paul, do you have any thoughts on this? We were trying to see if we could eliminate the dmtimer function pointer for setting the timer clock source. So, just to see if I'm understanding you correctly, you are planning to implement clksel clocks in the clock framework for OMAP1, and then use clk_set_parent() in the DMTIMER driver ? If so, then yes, that sounds like the right thing to do. Eventually both OMAP2+ and OMAP1 will presumably switch to the common clock framework, once things settle down a bit and can be tested. Also, the only other minor issue I see is that for omap1 devices instead of having sys_ck as the name the clock name is armxor_ck. We cannot rename armxor_ck as it is used by many peripherals but we could use a #define to workaround this or add a dummy clock node. OMAP1 clockfw uses clkdev just like OMAP2+, so you should be able to define as many clock aliases as you want in mach-omap1/clock_data.c. - Paul -- 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: [PATCHv2 12/19] ARM: OMAP4: PM: update ROM return address for OSWR and OFF
Tero Kristo t-kri...@ti.com writes: From: Carlos Leija cile...@ti.com At wakeup from OFF/OSWR CPU1 will call secure HAL service through a local secure dispatcher with MMU off, Reviewers who are uninitaited in this level of detail need some more help here (even those who are deeply familiar will need more help in a few months when they forget the details.) So, some more detail about where this is in the code would be helpful here. thus ROM will save a PA return address. Later in the wakeup, when SMC driver calls an RPC through omap4_secure_dispatcher (MMU is on now), Again, pointer to where is this in the code would be helpful. Also, it's not obvious why RPC use used here. Is that referring to the fact that the secure calls on CPU1 are dispatched to CPU0? Whatever it means, it should be summarized in the changelog. ROM code won't log the new return address as RPCs are handled different. Thus ROM will attempt to return to a PA address when the MMU is on and the system will hang. We need to do this for OSWR state and OFF state of mpu power domain, not just for device off(mpu pd OFF). The code suggests that affects *all* OMAP4 revisions? Is that correct? And once again, can this be implmented using cluster PM notifiers, where the notifier is registered only on affected revisions? (Sheesh, the number of ROM code workaounds in this series is rather disconcerting.) Kevin -- 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: [PATCHv2 13/19] ARM: OMAP4: PM: Mark the PPI and SPI interrupts as non-secure for GP
Tero Kristo t-kri...@ti.com writes:
From: Axel Haslam axelhas...@gmail.com
ROM code restores part of the GIC context during wakeup from device
off mode from the SAR RAM. If the PPI and SPI interrupts are not
marked as non-secure on GP chips, this crashes the device during
wakeup, thus mark them as non-secure.
Signed-off-by: Axel Haslam axelhas...@gmail.com
[t-kri...@ti.com: fixed commit message, merged multiple patches to one]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/omap-wakeupgen.c | 21 +
arch/arm/mach-omap2/omap4-common.c |5 +
arch/arm/mach-omap2/omap4-sar-layout.h |3 +++
4 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 48d1ebe..0fbb4e2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -200,6 +200,7 @@ static inline void __iomem *omap4_get_scu_base(void)
extern void __init gic_init_irq(void);
extern void gic_dist_disable(void);
+extern u32 gic_readl(u32 offset, u8 idx);
extern void omap_smc1(u32 fn, u32 arg);
extern void __iomem *omap4_get_sar_ram_base(void);
extern void omap_do_wfi(void);
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 805d08d..b2165e4 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -41,6 +41,7 @@
#define CPU_ENA_OFFSET 0x400
#define CPU0_ID 0x0
#define CPU1_ID 0x1
+#define GIC_ISR_NON_SECURE 0x
nit: alignment with preceeding #defines
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
@@ -387,6 +388,7 @@ int __init omap_wakeupgen_init(void)
{
int i;
unsigned int boot_cpu = smp_processor_id();
+ int max_spi_reg;
/* Not supported on OMAP4 ES1.0 silicon */
if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -422,6 +424,25 @@ int __init omap_wakeupgen_init(void)
for (i = 0; i NR_IRQS; i++)
irq_target_cpu[i] = boot_cpu;
+ /*
+ * Find out how many interrupts are supported.
+ * OMAP4 supports max of 128 SPIs where as GIC can support
+ * up to 1020 interrupt sources. On OMAP4, maximum SPIs are
+ * fused in DIST_CTR bit-fields as 128. Hence the code is safe
+ * from reserved register writes since its well within 1020.
+ */
+ max_spi_reg = gic_readl(GIC_DIST_CTR, 0) 0x1f;
+
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ sar_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_16K);
+ sar_writel(GIC_ISR_NON_SECURE, ICDISR_CPU0_OFFSET, 0);
+ sar_writel(GIC_ISR_NON_SECURE, ICDISR_CPU1_OFFSET, 0);
+ for (i = 0; i max_spi_reg; i++)
+ sar_writel(GIC_ISR_NON_SECURE, ICDISR_SPI_OFFSET, i);
The above 4 lines are begging for some comments (something like the
changelog). Since later in the series more stuff is added here, the end
result has some readability problems.
+ iounmap(sar_base);
+ sar_base = NULL;
+ }
irq_hotplug_init();
irq_pm_init();
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 7ea4652..f6019f6 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -112,6 +112,11 @@ void gic_dist_disable(void)
__raw_writel(0x0, gic_dist_base_addr + GIC_DIST_CTRL);
}
+u32 gic_readl(u32 offset, u8 idx)
+{
probably want an 'if (gic_dist_base_addr)' like gic_dist_disable()
+ return __raw_readl(gic_dist_base_addr + offset + 4 * idx);
+}
+
#ifdef CONFIG_CACHE_L2X0
void __iomem *omap4_get_l2cache_base(void)
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h
b/arch/arm/mach-omap2/omap4-sar-layout.h
index eef2839..0056667 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -85,6 +85,9 @@
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
#define SAR_SECRAM_SAVED_AT_OFFSET (SAR_BANK3_OFFSET + 0x508)
+#define ICDISR_CPU0_OFFSET (SAR_BANK3_OFFSET + 0x50c)
+#define ICDISR_CPU1_OFFSET (SAR_BANK3_OFFSET + 0x510)
+#define ICDISR_SPI_OFFSET(SAR_BANK3_OFFSET + 0x514)
SAR_ prefix?
/* WakeUpGen save restore offset from OMAP44XX_SAR_RAM_BASE */
#define WAKEUPGENENB_OFFSET_CPU0 (SAR_BANK3_OFFSET + 0x684)
Kevin
--
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 1/2] of: Add generic device tree DMA helpers
On 05/16/2012 01:42 PM, Arnd Bergmann wrote: On Wednesday 16 May 2012, Jassi Brar wrote: On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:- Only the most common characteristics of a dma setup are assumed in this binding. Client: Some h/w controller that could request a DMA controller in the system to perform data transfer on its behalf. Example SPI, MMC, I2S etc. DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc. The assumed model of the DMAC, in this binding, has P peripheral interfaces (P request signals) that could request a data transfer and C physical channels that actually do the data transfers, hence, at most C out of P peripherals could be served by the DMAC at any point of time. Usually C := P, but not always. Usually, any of the physical channels could be employed by the DMAC driver to serve any client. The DMAC driver identifies a client by its i/f number, 'peri_id' on the given DMAC. For example, TX for SPI has 7th while RX_TX (half-duplex) for MMC has 10th peripheral interface (request-signal) on a given DMAC. Usually, any of the physical channels could be employed by the DMAC driver to serve a client. I'm still anything but convinced by this model. Basically it's the exact opposite of what we do for every other subsystem (irq, pinctrl, regulator, gpio, ...), where the device using some infrastructure contains the information about who provides it, whereas here you move all the information into the device that provides the functionality, and have no handle in the device using it by which the driver can identify it. Yes, I guess this is backwards. But, the HW is a little different too; GPIOs (and probably interrupts) don't have multiple places they could come from. The problem is that if we did something like this in the DMA client: dma-reqs = dmac1 DMAC1_DMA_REQ_6 dmac1 DMAC1_DMA_REQ_8; how do we know if the client is emitting 2 DMA request signals that get routed to two different inputs on the DMA controller, or whether this is two alternatives for the same signal. Perhaps we can separate each logical request into separate properties. This will make the simple case slightly more complex, since there are n properties rather than n entries in each property, but still allow the more complex case: Simple case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Multiple DMAC case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6 dmac2 DMA_2_DMA_REQ_8; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Then, when the DMA client calls the standard API to get DMA channel for my outbound DMA request n, the core code will kasprintf(dma-req-%d, n); to generate the property name. That's how pinctrl works. Does that seem better? -- 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: [PATCHv2 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
+Benoit
Tero Kristo t-kri...@ti.com writes:
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Signed-off-by: Tero Kristo t-kri...@ti.com
I think I mentioned this already (I'm already lost in what I've said for
thisseries), but I don't think the secure RAM stuff belongs in the
wakeupgen driver.
Also, this patch suggests that the OCM RAM block needs a proper hwmod
instead of manually fiddling with the l3_main_3 hwmod and the l4_secure clkdm.
Kevin
---
arch/arm/mach-omap2/omap-wakeupgen.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index b2165e4..c7c4db4 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -29,10 +29,12 @@
#include mach/omap-wakeupgen.h
#include mach/omap-secure.h
+#include plat/omap_hwmod.h
#include omap4-sar-layout.h
#include common.h
#include pm.h
+#include clockdomain.h
#define NR_REG_BANKS 4
#define MAX_IRQS 128
@@ -49,6 +51,8 @@ static DEFINE_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[NR_IRQS];
static struct powerdomain *mpuss_pd;
+static struct clockdomain *l4_secure_clkdm;
+static struct omap_hwmod *l3_main_3_oh;
/*
* Static helper functions.
@@ -300,10 +304,18 @@ static void save_secure_ram(void)
static void save_secure_all(void)
{
u32 ret;
+
+ omap_hwmod_enable(l3_main_3_oh);
+ clkdm_wakeup(l4_secure_clkdm);
+
ret = omap_secure_dispatcher(OMAP4_HAL_SAVEALL_INDEX,
FLAG_START_CRITICAL,
1, omap_secure_ram_mempool_base(),
0, 0, 0);
+
+ clkdm_allow_idle(l4_secure_clkdm);
+ omap_hwmod_idle(l3_main_3_oh);
+
if (ret != API_HAL_RET_VALUE_OK)
pr_err(Secure all context save failed\n);
}
@@ -441,6 +453,14 @@ int __init omap_wakeupgen_init(void)
sar_writel(GIC_ISR_NON_SECURE, ICDISR_SPI_OFFSET, i);
iounmap(sar_base);
sar_base = NULL;
+ } else {
+ l3_main_3_oh = omap_hwmod_lookup(l3_main_3);
+ if (!l3_main_3_oh)
+ pr_err(%s: failed to get l3_main_3_oh\n, __func__);
+
+ l4_secure_clkdm = clkdm_lookup(l4_secure_clkdm);
+ if (!l4_secure_clkdm)
+ pr_err(%s: failed to get l4_secure_clkdm\n, __func__);
}
irq_hotplug_init();
--
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: [PATCHv2 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
Tero Kristo t-kri...@ti.com writes:
From: Santosh Shilimkar santosh.shilim...@ti.com
Work around for Errata ID: i632 LPDDR2 Corruption After OFF Mode
Transition When CS1 Is Used On EMIF which impacts OMAP443x silicon
The issue occurs when EMIF_SDRAM_CONFIG is restored first before
EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
is not set properly, we apply the required workaround allowing
the restore sequence to work properly.
Please summarize the workaround here as well.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../include/mach/ctrl_module_wkup_44xx.h |2 +
arch/arm/mach-omap2/pm44xx.c | 37
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
index a0af9ba..b763a79 100644
--- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
+++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
@@ -28,6 +28,8 @@
#define OMAP4_CTRL_MODULE_WKUP_IP_REVISION 0x
#define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO 0x0004
#define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG 0x0010
+#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG0x0114
+#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG0x011c
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0 0x0460
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1 0x0464
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2 0x0468
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 215b80e..dfaa254 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -17,12 +17,18 @@
#include linux/err.h
#include linux/slab.h
#include asm/system_misc.h
+#include linux/io.h
+
+#include mach/ctrl_module_wkup_44xx.h
+#include mach/hardware.h
#include common.h
#include clockdomain.h
#include powerdomain.h
#include pm.h
+#define EMIF_SDRAM_CONFIG2_OFFSET0xc
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -215,6 +221,37 @@ static int __init omap4_pm_init(void)
pr_err(Power Management for TI OMAP4.\n);
+ /*
+ * Work around for OMAP443x Errata i632: LPDDR2 Corruption After OFF
+ * Mode Transition When CS1 Is Used On EMIF:
+ * Overwrite EMIF1/EMIF2
+ * SECURE_EMIF1_SDRAM_CONFIG2_REG
+ * SECURE_EMIF2_SDRAM_CONFIG2_REG
+ */
+ if (cpu_is_omap443x()) {
This should probably be done later in this function, after PM_ERRATUM
flags are setup, and then it should use a PM_ERRATUM flag instead of cpu_is*
+ void __iomem *secure_ctrl_mod;
+ void __iomem *emif1;
+ void __iomem *emif2;
+ u32 val;
+
+ secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
+ emif1 = ioremap(OMAP44XX_EMIF1_BASE, SZ_1M);
+ emif2 = ioremap(OMAP44XX_EMIF2_BASE, SZ_1M);
+
+ BUG_ON(!secure_ctrl_mod || !emif1 || !emif2);
Please avoid BUG_ON() and use proper error recovery. This is not a
condition where the entire kernel should panic.
+ val = __raw_readl(emif1 + EMIF_SDRAM_CONFIG2_OFFSET);
+ __raw_writel(val, secure_ctrl_mod +
+ OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG);
+ val = __raw_readl(emif2 + EMIF_SDRAM_CONFIG2_OFFSET);
+ __raw_writel(val, secure_ctrl_mod +
+ OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG);
+ wmb();
+ iounmap(secure_ctrl_mod);
+ iounmap(emif1);
+ iounmap(emif2);
+ }
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
Kevin
--
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: [PATCHv2 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
Hi Tero On Mon, 14 May 2012, Tero Kristo wrote: save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled, otherwise the secure ROM code will crash. Do we know why the l3_main_3 interconnect has to be enabled? Is this needed to access some L3 or instrumentation registers? - Paul -- 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: [PATCHv2 17/19] ARM: OMAP4: put cpu1 back to sleep if no wake request
Tero Kristo t-kri...@ti.com writes: If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back to off. Why is it waking up then? (I know the answer, but will forget. The changelog serves as my long-term memory.) This is needed during wakeup from device off to prevent cpu1 from being stuck indefinitely in the wakeup loop Why does it get stuck? and also to prevent wakeup problem on GP chips with device off mode. What wakeup problem? Signed-off-by: Tero Kristo t-kri...@ti.com Assembly code should have some comments to aid comprehension. --- arch/arm/mach-omap2/omap-headsmp.S | 45 --- 1 files changed, 41 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index d602555..59c6578 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -17,8 +17,37 @@ #include linux/linkage.h #include linux/init.h +#include mach/omap-secure.h +#include prcm_mpu44xx.h + +#define CPU1_PWRSTCTRL (OMAP4430_PRCM_MPU_BASE + OMAP4430_PRCM_MPU_CPU1_INST + \ + OMAP4_PM_CPU1_PWRSTCTRL_OFFSET) __CPUINIT + +ENTRY(omap_cpu1_off) + ldr r12, =CPU1_PWRSTCTRL + ldr r0, [r12] + and r0, #3 + cmp r0, #2 + beq exit_cpu1_off + + mov r0, #0x3 + mov r1, #0x0 + ldr r12, =OMAP4_MON_SCU_PWR_INDEX Help! no comments. + dsb + smc #0 The DO_SMC in sleep44xx.S suggests there should be another dsb here. + isb + dsb + dmb + wfi + nop + nop Shoudln't this use omap_do_wfi? Kevin +exit_cpu1_off: + mov pc, lr +ENDPROC(omap_cpu1_off) + /* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which @@ -27,32 +56,40 @@ * register AuxCoreBoot0. */ ENTRY(omap_secondary_startup) -hold:ldr r12,=0x103 + ldr r12,=0x103 dsb smc #0 @ read from AuxCoreBoot0 mov r0, r0, lsr #9 mrc p15, 0, r4, c0, c0, 5 and r4, r4, #0x0f cmp r0, r4 - bne hold + beq omap_cont_boot + + bl omap_cpu1_off + b omap_secondary_startup /* * we've been released from the wait loop,secondary_stack * should now contain the SVC stack for this core */ +omap_cont_boot: b secondary_startup ENDPROC(omap_secondary_startup) ENTRY(omap_secondary_startup_4460) -hold_2: ldr r12,=0x103 + ldr r12,=0x103 dsb smc #0 @ read from AuxCoreBoot0 mov r0, r0, lsr #9 mrc p15, 0, r4, c0, c0, 5 and r4, r4, #0x0f cmp r0, r4 - bne hold_2 + beq omap4460_cont_boot + + bl omap_cpu1_off + b omap_secondary_startup_4460 +omap4460_cont_boot: /* * GIC distributor control register has changed between * CortexA9 r1pX and r2pX. The Control Register secure -- 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: [PATCHv2 18/19] ARM: OMAP4460: wakeupgen: set GIC_CPU0 backup status flag always
Tero Kristo t-kri...@ti.com writes:
Without this, CPU0 will crash in the ROM code during wakeup from
device off. This patch also clears the GIC save area, to prevent
ROM code from writing garbage to the GIC registers during wakeup.
The actual GIC restore is done by kernel.
This bug fix applies only to OMAP4460, it is fixed on OMAP4470.
Signed-off-by: Tero Kristo t-kri...@ti.com
Please create/use PM_ERRATUM flag.
Kevin
---
arch/arm/mach-omap2/omap-wakeupgen.c | 14 ++
arch/arm/mach-omap2/omap4-sar-layout.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index c7c4db4..30da299 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -447,10 +447,24 @@ int __init omap_wakeupgen_init(void)
if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
sar_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_16K);
+ /* Clean GIC SAR area */
+ for (i = SAR_BACKUP_STATUS_OFFSET; i WAKEUPGENENB_OFFSET_CPU0;
+ i += 4)
+ sar_writel(0, i, 0);
+
sar_writel(GIC_ISR_NON_SECURE, ICDISR_CPU0_OFFSET, 0);
sar_writel(GIC_ISR_NON_SECURE, ICDISR_CPU1_OFFSET, 0);
for (i = 0; i max_spi_reg; i++)
sar_writel(GIC_ISR_NON_SECURE, ICDISR_SPI_OFFSET, i);
+
+ /*
+ * Set CPU0 GIC backup flag permanently for omap4460,
+ * this is needed because of the ROM code bug that breaks
+ * GIC during wakeup from device off
+ */
+ if (cpu_is_omap446x())
+ __raw_writel(SAR_BACKUP_STATUS_GIC_CPU0,
+ sar_base + SAR_BACKUP_STATUS_OFFSET);
iounmap(sar_base);
sar_base = NULL;
} else {
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h
b/arch/arm/mach-omap2/omap4-sar-layout.h
index 0056667..e621c51 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -88,6 +88,7 @@
#define ICDISR_CPU0_OFFSET (SAR_BANK3_OFFSET + 0x50c)
#define ICDISR_CPU1_OFFSET (SAR_BANK3_OFFSET + 0x510)
#define ICDISR_SPI_OFFSET(SAR_BANK3_OFFSET + 0x514)
+#define SAR_BACKUP_STATUS_GIC_CPU0 0x1
/* WakeUpGen save restore offset from OMAP44XX_SAR_RAM_BASE */
#define WAKEUPGENENB_OFFSET_CPU0 (SAR_BANK3_OFFSET + 0x684)
--
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 -next] mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq
The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
otherwise the following failure message should be dumped because
hardware handler is defined as NULL:
[3.383483] genirq: Threaded irq requested with handler=NULL and
!ONESHOT for irq 368
[3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
The patch fixes one kernel hang bug which is caused by mmc card
probe failure and root device can't be brought up.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ebaf62a..9a7a60a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1981,7 +1981,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
NULL,
omap_hsmmc_detect,
- IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
--
1.7.9.5
--
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 1/2] of: Add generic device tree DMA helpers
On 17 May 2012 05:29, Stephen Warren swar...@wwwdotorg.org wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:- Only the most common characteristics of a dma setup are assumed in this binding. Client: Some h/w controller that could request a DMA controller in the system to perform data transfer on its behalf. Example SPI, MMC, I2S etc. DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc. The assumed model of the DMAC, in this binding, has P peripheral interfaces (P request signals) that could request a data transfer and C physical channels that actually do the data transfers, hence, at most C out of P peripherals could be served by the DMAC at any point of time. Usually C := P, but not always. Usually, any of the physical channels could be employed by the DMAC driver to serve any client. The DMAC driver identifies a client by its i/f number, 'peri_id' on the given DMAC. For example, TX for SPI has 7th while RX_TX (half-duplex) for MMC has 10th peripheral interface (request-signal) on a given DMAC. Usually, any of the physical channels could be employed by the DMAC driver to serve a client. I'm still anything but convinced by this model. Basically it's the exact opposite of what we do for every other subsystem (irq, pinctrl, regulator, gpio, ...), where the device using some infrastructure contains the information about who provides it, whereas here you move all the information into the device that provides the functionality, and have no handle in the device using it by which the driver can identify it. Yes, I guess this is backwards. But, the HW is a little different too; GPIOs (and probably interrupts) don't have multiple places they could come from. The problem is that if we did something like this in the DMA client: dma-reqs = dmac1 DMAC1_DMA_REQ_6 dmac1 DMAC1_DMA_REQ_8; how do we know if the client is emitting 2 DMA request signals that get routed to two different inputs on the DMA controller, or whether this is two alternatives for the same signal. FWIW, I wouldn't lose sleep over the possibility of redundancy on same DMAC. If a client's request signal is routed to 2 inputs, they are usually on different DMACs. -- 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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
On Thu, May 17, 2012 at 1:44 AM, Jon Hunter jon-hun...@ti.com wrote:
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
I guess that custom set_timer_src should not be there at all anymore.
Well at least for OMAP2+.
We should just use the regular clock API to change the parent. I do not
see why we should add that wrapper on top of the clock API and thus
store some internal clock name inside the timer device init code.
Whatever is done within omap2_dm_timer_set_src() in mach-omap2/timer.c
can be implemented inside omap_dm_timer_set_source() in plat-omap/dmtimer.c
directly whereby we continue to use the generic clock APIs provided in
include/linux/clk.h.
I have been looking into this and in order to get rid for the above
function pointer we would need to move at a minimum the following
functions from omap-mach2/clkt_clksel.c into the platform code.
_get_clksel_by_parent()
_get_div_and_fieldval()
_write_clksel_reg()
omap2_init_clksel_parent()
omap2_clksel_set_parent()
However, it may be simpler just to move the clkt_clksel.c file
completely. I have tested the above functions on omap1 and they are
working well. However, before doing this we would need to get Paul's
buy-in that this is the right thing to do.
I am not sure if this is really needed though.
--
Tarun
Paul, do you have any thoughts on this? We were trying to see if we
could eliminate the dmtimer function pointer for setting the timer clock
source.
Also, the only other minor issue I see is that for omap1 devices instead
of having sys_ck as the name the clock name is armxor_ck. We cannot
rename armxor_ck as it is used by many peripherals but we could use a
#define to workaround this or add a dummy clock node.
Cheers
Jon
--
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 4/6] ARM: OMAP4: PMU: Add runtime PM support
On Wed, May 16, 2012 at 4:17 PM, Ming Lei ming@canonical.com wrote: Jon, On Wed, May 16, 2012 at 6:05 AM, Ming Lei ming@canonical.com wrote: On Tuesday, May 15, 2012, Jon Hunter jon-hun...@ti.com wrote: Hi Ming, On 05/14/2012 11:53 PM, Ming Lei wrote: On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4 [1]. In Ming's original patch the CTI interrupts were being enabled during runtime when the PMU was used but they were only configured once during init. Therefore move the configuration of the CTI interrupts to the runtime PM functions. As Shilimkar pointed out, you need to give the reason why the change is introduced in the patch. Yes will do. I have been waiting to get some feedback on HW_AUTO versus SW_SLEEP from design before posting a V2. I will enhance the changelog. Looks pandaboard will hang during kernel boot with the latest next tree, so perf can't be tested now. Once the problem is fixed, l will run perf test and provide my feedback. After bisecting, looks it is the 1st commit which triggers kernel boot hang: commit 5f3aa31f77733605f04a5a92ddc475ffd439585f Merge: 0f131ea ce4deaa Author: Stephen Rothwell s...@canb.auug.org.au Date: Mon May 14 18:55:39 2012 +1000 Merge remote-tracking branch 'arm-soc/for-next' The above kernel hang is caused by mmc driver probe failure, which can be fixed by the patch in below link: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68848.html After applying the patch, I can test the 6 patches and looks they work well about perf support on omap4, also perf can work well after S2R. Tested-by: Ming Lei ming@canonical.com Thanks, -- Ming Lei -- 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
