Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Any news on this? This thread seems to have gone a little quiet... Cheers, Joe -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Paul Walmsley p...@pwsan.com, khil...@ti.com Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org, Joe Woodward j...@terrafix.co.uk Date: Tue, 08 May 2012 16:26:38 +0300 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. And two more interesting points about the problem: Setting DISPC's SIDLEMODE to no-idle seems to remove the issue. With some DISPC's fifo high/low threshold values things seem to work, while with others we get underflows. And as the required bandwidth here is quite small, and the threshold values I tested are close to each other, I don't think it's really a proper bandwidth issue. I'm guessing that certain threshold values cause somehow un-optimal accesses to the memory, and with smart-idle this somehow causes problems. Archit, you looked into the thresholds some time ago. I recall that some threshold values were bad in some way? Were those only for OMAP4? Tomi -- 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 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On 05/14/2012 04:43 PM, mani wrote: Dear Kim, I have a query here .. My point is that it would be better for read to not preempt write-for-page_reclaim. And we can identify it by PG_reclaim. You can get the idea. I think If there is no page available then no read will proceed. When read request comes it reclaim the pages (starts the write if syncable pages ) and get back after reclaiming the pages. Only then a read request will come to the MMC subsystem. And i think the reclaim algorithm will reclaim some substantial amount of pages at a time instead of a single page. So if we get few pages during the reclamation so there will be no problem in halting the another write ops for proceeding the reads ? Can we think of a scenario when we are reclaiming the pages and write ops is going on where as a high priority read for the interrupt handler is pending ? Please correct me if i am wrong. For example, System can have lots of order-0 pages but little order-big pages. In this case, for getting big contiguos memory, reclaimer should write out dirty pages while it can handle order-0 page read request. Thanks Regards Manish -- Kind regards, Minchan Kim -- 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 Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, 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 =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
Hi Mark,
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44
+
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
- sizeof(am35xx_mdio_pdata));
+ sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
- sizeof(am35xx_emac_pdata));
+ sizeof(am35xx_emac_pdata),
+ pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include plat/omap_device.h
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY100
-#if defined(CONFIG_TI_DAVINCI_EMAC) || defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if IS_ENABLED(CONFIG_TI_DAVINCI_EMAC)
+extern struct omap_device_pm_latency am35xx_emac_pm_lats[];
+extern int am35xx_emac_pm_lats_size;
Re: [PATCH 1/4] MFD: palmas PMIC device support
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ maps - could we factor it out into regmap-irq? It'd also be
nice if it were using an irq_domain - while it's far from essential it
is something Grant has been pushing and I believe it'll be required when
you do device tree support.
+ if (palmas-irq_mask != reg_mask) {
+ addr = PALMAS_BASE_TO_REG(PALMAS_INTERRUPT_BASE,
+ PALMAS_INT1_MASK);
+ reg = palmas-irq_mask 0xFF;
+ regmap_write(palmas-regmap[slave], addr, reg);
This looks like you've open coded some regmap_update_bits() calls?
+ if (!palmas-irq_base) {
+ dev_warn(palmas-dev, No interrupt support, no IRQ base\n);
+ return -EINVAL;
+ }
If you use an irqdomain you can automatically allocate the interrupt
range much more easily (even if you don't if you pass -1 as the base
irq_alloc_descs() it's supposed to figure things out to you - it looks
like you're not calling irq_alloc_decs()).
With the irqdomain you should also find that as the interrupts are
always registered (even if they can't fire) then you can just assume
they're there in function drivers which makes the code simpler.
+ ret = request_threaded_irq(palmas-irq, NULL, palmas_irq, IRQF_ONESHOT,
+palmas-irq, palmas);
+
+ irq_set_irq_type(palmas-irq, IRQ_TYPE_LEVEL_LOW);
Why not just IRQF_TRIGGER_LOW?
+static const struct mfd_cell palmas_children[] = {
+};
I'd just go ahead and fill this in, it makes merging much easier as the
function drivers don't have a merge dependency on the core.
+static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] =
{
+ {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .cache_type = REGCACHE_NONE,
Shouldn't need to explicitly set REGCACHE_NONE. max_register might be
useful to get you register dumps in debugfs.
+ palmas = kzalloc(sizeof(struct palmas), GFP_KERNEL);
+ if (palmas == NULL)
+ return -ENOMEM;
devm_kzalloc().
+ ret = irq_alloc_descs(-1, 0, PALMAS_NUM_IRQ, 0);
+ if (ret 0) {
+ dev_err(i2c-dev, failed to allocate IRQ descs\n);
+ goto err;
+ }
Oh, here's the irq_alloc_descs() call - seems useful to put it in the
generic irq init?
+ palmas-regmap[i] = regmap_init_i2c(palmas-i2c_clients[i],
+ palmas_regmap_config[i]);
devm_regmap_init_i2c().
+static const struct i2c_device_id palmas_i2c_id[] = {
+ { palmas, PALMAS_ID_TWL6035 },
+};
+MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
I'd suggest also including the part names as an option (so having an
entry for twl6035) - makes life easier for users as they don't need to
think about if the device is compatible.
+/* Bit definitions for MONTHS_REG */
+#define MONTHS_REG_MONTH10x10
+#define MONTHS_REG_MONTH1_SHIFT 4
+#define MONTHS_REG_MONTH0_MASK 0x0f
+#define MONTHS_REG_MONTH0_SHIFT 0
Some of these registers should be namespaced (many are already).
signature.asc
Description: Digital signature
[PATCHv10 00/10] I2C fixes
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang Also update the patches with comments. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit 9ff00d58a915b6747ba2e843ab2d04c712b4dc32: Merge tag 'for-linus-3.4-20120513' of git://git.infradead.org/linux-mtd (2012-05-13 11:33:09 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-fixes Shubhrajyoti D (9): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags drivers/i2c/busses/i2c-omap.c | 127 - 1 files changed, 62 insertions(+), 65 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 03/10] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c851672..bf07ffd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1127,10 +1127,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
u16 iv;
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 01/10] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCHv10 07/10] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Correct the error handling.
drivers/i2c/busses/i2c-omap.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 44e8cfa..a72874e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -585,7 +585,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1011,7 +1013,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ goto err_free_mem;
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1103,12 +1107,16 @@ omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0)
+ return ret;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 06/10] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: linux...@vger.kernel.org Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com -- - Enhanced the cc list to include linux-pm drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fec8d5c..44e8cfa 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1108,7 +1108,9 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 02/10] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This causes a warning when pm_runtime_enable checks for the count match.Fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- - Remove attempting from the changelogs. drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 4f4188d..c851672 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1090,6 +1090,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1110,6 +,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 04/10] I2C: OMAP: Prevent the register access after pm_runtime_put in probe
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks in the error cases.
Fix the same by moving the pm_runtime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Changed the $SUBJECT as it was too generic.
- Dropping attempting
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bf07ffd..1777d79 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1061,8 +1061,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1082,6 +1080,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 05/10] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Added Jon's signoff
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 1777d79..fec8d5c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -473,7 +473,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -541,12 +541,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
return -ETIMEDOUT;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 10/10] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c0aa16b..0f536b2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -173,7 +173,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -718,11 +718,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -881,8 +881,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1020,7 +1020,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 08/10] I2C: OMAP: prevent the overwrite of the errata flags
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Prevent the overwrite of the errata flags.Move the errata handling to a unified place in probe to prevent such errors. Thus preventing the overwrite of erratum 1p153. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- - Update the changelogs to be more explainatory. drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index a72874e..43b0efb 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -427,11 +427,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1019,6 +1014,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 09/10] I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF(Transmit underflow) flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- XUDF is expanded to transmit underflow
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 43b0efb..c0aa16b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -730,7 +730,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -743,6 +742,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] REGULATOR: regulator driver for Palmas series chips
On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote:
Looks good, quite a few of the things below are updates for very
recently introduced APIs.
+static int palmas_smps_read(struct palmas *palmas, unsigned int reg,
+ unsigned int *dest)
+{
+ int slave;
+ unsigned int addr;
+
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_SMPS_BASE);
+ addr = PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, reg);
+
+ return regmap_read(palmas-regmap[slave], addr, dest);
+}
Looks like the LDO and SPMS regulators both use the same regmap?
+ .get_voltage= palmas_get_voltage_smps,
Why not get_voltage_sel?
+ .set_voltage_sel= palmas_set_voltage_smps_sel,
+ .list_voltage = palmas_list_voltage_smps,
Implementing map_voltage() too would be nice.
+static int palmas_is_enabled_smps10(struct regulator_dev *dev)
+{
+ struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+ unsigned int reg;
+
+ palmas_smps_read(pmic-palmas, PALMAS_SMPS10_STATUS, reg);
+
+ reg = SMPS10_BOOST_EN;
+
Should be able to use regulator_is_enabled_regmap() and friends.
+static int palmas_list_voltage_smps10(struct regulator_dev *dev,
+ unsigned selector)
+{
+ if (selector)
+ return 500;
+
+ return 375;
This could be written a little more transparently!
+static int palmas_get_voltage_smps10(struct regulator_dev *dev)
+{
+ struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+ int selector;
+ unsigned int reg;
+
+ palmas_smps_read(pmic-palmas, PALMAS_SMPS10_CTRL, reg);
+
+ selector = (reg SMPS10_VSEL) 3;
+
+ return palmas_list_voltage_smps10(dev, selector);
Should be get_voltage_sel() really, or beter still should be using
regulator_set_voltage_sel_regmap(). Similarly for the set (which is
already using _sel()).
+static int palmas_enable_ldo(struct regulator_dev *dev)
+{
+ struct palmas_pmic *pmic = rdev_get_drvdata(dev);
+ int id = rdev_get_id(dev);
+ unsigned int reg;
+
+ palmas_ldo_read(pmic-palmas, palmas_regs_info[id].ctrl_addr, reg);
+
+ reg |= LDO1_CTRL_MODE_ACTIVE;
+
+ palmas_ldo_write(pmic-palmas, palmas_regs_info[id].ctrl_addr, reg);
Could use the core regmap stuff for the LDOs too.
+ /* Adjust selector to match list_voltage ranges */
+ if (selector 49)
+ selector = 49;
+
+ return palmas_list_voltage_ldo(dev, selector);
get_voltage_sel().
+ if (!pdata)
+ return -EINVAL;
+ if (!pdata-reg_data)
+ return -EINVAL;
I'd expect the driver to be able to register the regulators with no
platform data at all.
+ pmic = kzalloc(sizeof(*pmic), GFP_KERNEL);
+ if (!pmic)
+ return -ENOMEM;
devm_kzalloc()
+ pmic-desc = kcalloc(PALMAS_NUM_REGS,
+ sizeof(struct regulator_desc), GFP_KERNEL);
+ if (!pmic-desc) {
+ ret = -ENOMEM;
+ goto err_free_pmic;
+ }
Just embed this in the pmic struct? It's always the same size.
+ pmic-rdev = kcalloc(PALMAS_NUM_REGS,
+ sizeof(struct regulator_dev *), GFP_KERNEL);
Similarly heere.
signature.asc
Description: Digital signature
RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
On Sat, May 12, 2012 at 03:24:51, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). OK so far. This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... OK, I see what you mean now. I was confusing because this patch doesn't touch sdrc.c, or the Makefile for sdrc.c. I think I understand the source of confusion here, but now we are on same page... So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. That being the case, for readability sake, I suggest you change the Makefile to use the new config option for sdrc.c as well. Will submit the patch for this today. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Provide GPMC memory to OMAP nand/onenand as resource
Hi Tony, Artem, This series modifies GPMC to provide OMAP onenand nand peripherals with GPMC allocated address space as resource. This conversion helps in smooth migration of gpmc code to driver. This series has been made over [1-3], but is not functionally dependent on those, only depedency is w.r.t avoiding trivial merge conflict (if [3] is not taken before this series), and that too would affect only nand mtd driver. This is targeted for 3.5, if this can be taken for 3.5, it also helps in making mtd drivers feel less vibration when GPMC gets converted to driver. Regards Afzal [1] http://marc.info/?l=linux-omapm=133675123118577w=2 [2] http://marc.info/?l=linux-omapm=133675123718579w=2 [3] http://marc.info/?l=linux-omapm=133675124818580w=2 Afzal Mohammed (4): ARM: OMAP2+: gpmc-nand: update resource with memory ARM: OMAP2+: gpmc-onenand: provide memory as resource mtd: nand: omap2: obtain memory from resource mtd: onenand: omap2: obtain memory from resource arch/arm/mach-omap2/gpmc-nand.c|4 +++- arch/arm/mach-omap2/gpmc-onenand.c | 23 ++- arch/arm/plat-omap/include/plat/nand.h |1 - drivers/mtd/nand/omap2.c | 19 +++ drivers/mtd/onenand/omap2.c| 29 - 5 files changed, 56 insertions(+), 20 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP2+: gpmc-nand: update resource with memory
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d4e803c..c0320d2 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -90,12 +90,14 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- gpmc_nand_data-phys_base);
+ (unsigned long *)gpmc_nand_resource.start);
if (err 0) {
dev_err(dev, Cannot request GPMC CS\n);
return err;
}
+ gpmc_nand_resource.end = gpmc_nand_resource.start + NAND_IO_SIZE - 1;
+
/* Set timings in GPMC */
err = omap2_nand_gpmc_retime(gpmc_nand_data);
if (err 0) {
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: gpmc-onenand: provide memory as resource
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in onenand driver.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index a0fa9bb..71d7c07 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -23,11 +23,19 @@
#include plat/board.h
#include plat/gpmc.h
+#defineONENAND_IO_SIZE SZ_128K
+
static struct omap_onenand_platform_data *gpmc_onenand_data;
+static struct resource gpmc_onenand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
static struct platform_device gpmc_onenand_device = {
.name = omap2-onenand,
.id = -1,
+ .num_resources = 1,
+ .resource = gpmc_onenand_resource,
};
static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
@@ -390,6 +398,8 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
+ int err;
+
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
gpmc_onenand_device.dev.platform_data = gpmc_onenand_data;
@@ -401,8 +411,19 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
+ err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
+ (unsigned long *)gpmc_onenand_resource.start);
+ if (err 0) {
+ pr_err(%s: Cannot request GPMC CS\n, __func__);
+ return;
+ }
+
+ gpmc_onenand_resource.end = gpmc_onenand_resource.start +
+ ONENAND_IO_SIZE - 1;
+
if (platform_device_register(gpmc_onenand_device) 0) {
- printk(KERN_ERR Unable to register OneNAND device\n);
+ pr_err(%s: Unable to register OneNAND device\n, __func__);
+ gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
}
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] mtd: nand: omap2: obtain memory from resource
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1 -
drivers/mtd/nand/omap2.c | 19 +++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 86e4d9c..290cef5 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -26,7 +26,6 @@ struct omap_nand_platform_data {
booldev_ready;
int gpmc_irq;
enum nand_ioxfer_type;
- unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 25f930c..f69ecc1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
+ unsigned long mem_size;
struct completion comp;
int dma_ch;
int gpmc_irq;
@@ -1049,6 +1050,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
struct omap_nand_platform_data *pdata;
int err;
int i, offset;
+ struct resource *res;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1068,7 +1070,6 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-pdev = pdev;
info-gpmc_cs = pdata-cs;
- info-phys_base = pdata-phys_base;
info-reg = pdata-reg;
info-mtd.priv = info-nand;
@@ -1081,13 +1082,23 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* NAND write protect off */
gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0);
- if (!request_mem_region(info-phys_base, NAND_IO_SIZE,
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ err = -EINVAL;
+ dev_err(pdev-dev, error getting memory resource\n);
+ goto out_free_info;
+ }
+
+ info-phys_base = res-start;
+ info-mem_size = resource_size(res);
+
+ if (!request_mem_region(info-phys_base, info-mem_size,
pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, NAND_IO_SIZE);
+ info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1229,7 +1240,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
return 0;
out_release_mem_region:
- release_mem_region(info-phys_base, NAND_IO_SIZE);
+ release_mem_region(info-phys_base, info-mem_size);
out_free_info:
kfree(info);
--
1.7.10
--
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 4/4] mtd: onenand: omap2: obtain memory from resource
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/onenand/omap2.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 398a827..3ff893d 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -48,13 +48,13 @@
#define DRIVER_NAME omap2-onenand
-#define ONENAND_IO_SIZESZ_128K
#define ONENAND_BUFRAM_SIZE(1024 * 5)
struct omap2_onenand {
struct platform_device *pdev;
int gpmc_cs;
unsigned long phys_base;
+ unsigned int mem_size;
int gpio_irq;
struct mtd_info mtd;
struct onenand_chip onenand;
@@ -626,6 +626,7 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
struct omap2_onenand *c;
struct onenand_chip *this;
int r;
+ struct resource *res;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -647,20 +648,24 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
c-gpio_irq = 0;
}
- r = gpmc_cs_request(c-gpmc_cs, ONENAND_IO_SIZE, c-phys_base);
- if (r 0) {
- dev_err(pdev-dev, Cannot request GPMC CS\n);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ r = -EINVAL;
+ dev_err(pdev-dev, error getting memory resource\n);
goto err_kfree;
}
- if (request_mem_region(c-phys_base, ONENAND_IO_SIZE,
+ c-phys_base = res-start;
+ c-mem_size = resource_size(res);
+
+ if (request_mem_region(c-phys_base, c-mem_size,
pdev-dev.driver-name) == NULL) {
- dev_err(pdev-dev, Cannot reserve memory region at 0x%08lx,
- size: 0x%x\n, c-phys_base, ONENAND_IO_SIZE);
+ dev_err(pdev-dev, Cannot reserve memory region at 0x%08lx,
size: 0x%x\n,
+ c-phys_base, c-mem_size);
r = -EBUSY;
- goto err_free_cs;
+ goto err_kfree;
}
- c-onenand.base = ioremap(c-phys_base, ONENAND_IO_SIZE);
+ c-onenand.base = ioremap(c-phys_base, c-mem_size);
if (c-onenand.base == NULL) {
r = -ENOMEM;
goto err_release_mem_region;
@@ -776,9 +781,7 @@ err_release_gpio:
err_iounmap:
iounmap(c-onenand.base);
err_release_mem_region:
- release_mem_region(c-phys_base, ONENAND_IO_SIZE);
-err_free_cs:
- gpmc_cs_free(c-gpmc_cs);
+ release_mem_region(c-phys_base, c-mem_size);
err_kfree:
kfree(c);
@@ -800,7 +803,7 @@ static int __devexit omap2_onenand_remove(struct
platform_device *pdev)
gpio_free(c-gpio_irq);
}
iounmap(c-onenand.base);
- release_mem_region(c-phys_base, ONENAND_IO_SIZE);
+ release_mem_region(c-phys_base, c-mem_size);
gpmc_cs_free(c-gpmc_cs);
kfree(c);
--
1.7.10
--
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
[PATCHv5 0/8] ARM: OMAP4: core retention support
Hi, Changes compared to previous version: - Patch 6 now adds support for reading prev logic and mem states instead of tweaking the _update_logic_membank_counters function directly. - Some version of [PATCH] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup from Govindraj is needed, otherwise UART can't wake up the device from suspend. Tested with omap4460 GP panda + omap4430 EMU blaze devices. Patches also available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-ret-v5 -Tero -- 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
[PATCHv5 1/8] ARM: OMAP4: suspend: Program all domains to retention
From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. 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) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time
From: Rajendra Nayak rna...@ti.com
With no driver handling DSP, if brought out of reset, it stays
active and does not assert standby. This leads to IVAHD powerdomain not
transitioning and hence preventing chip retention.
This patch is no longer needed once Paul's powerdomain fixes are merged:
http://marc.info/?l=linux-omapm=133040749621183w=2
Just provided for testing purposes.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6abc757..fd305bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1160,6 +1160,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.name = dsp,
.class = omap44xx_dsp_hwmod_class,
.clkdm_name = tesla_clkdm,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_dsp_irqs,
.rst_lines = omap44xx_dsp_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
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. Since 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.
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
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 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.
+*/
+ ldr r1, =0x48241000
+ ldr r0, [r1]
+ orr r0, #1
+ str r0, [r1]
+
+ /*
+* we've been released from the wait loop,secondary_stack
+* should now contain the SVC stack for this core
+*/
+ b secondary_startup
+ENDPROC(omap_secondary_startup_4460)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13670aa..e02c082 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -68,6 +68,7 @@ struct omap4_cpu_pm_info {
void __iomem *scu_sar_addr;
void __iomem *wkup_sar_addr;
void __iomem *l2x0_sar_addr;
+ void (*secondary_startup)(void);
};
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
@@ -300,6 +301,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
{
unsigned int cpu_state = 0;
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu);
if (omap_rev() == OMAP4430_REV_ES1_0)
return -ENXIO;
@@ -309,7 +311,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
clear_cpu_prev_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(omap_secondary_startup));
+ set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));
scu_pwrst_prepare(cpu, power_state);
/*
@@ -360,6 +362,11 @@ int __init omap4_mpuss_init(void)
[PATCHv5 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 44 +++--
arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +++-
2 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8683d6f..601f5a5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1520,6 +1520,36 @@ static void _reconfigure_io_chain(void)
}
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (!(oh-flags HWMOD_CONTEXT_REG))
+ return;
+
+ r = omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
+
+ omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
+oh-clkdm-pwrdm.ptr-prcm_offs,
+oh-prcm.omap4.context_offs);
+}
+
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1599,6 +1629,8 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
+ _omap4_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
@@ -2724,17 +2756,21 @@ ohsps_unlock:
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
- * count for this device.
+ * Returns the context loss count of associated @oh
+ * upon success, or zero if no context loss data is available.
*
- * Returns the context loss count of the powerdomain assocated with @oh
- * upon success, or zero if no powerdomain exists for @oh.
+ * On OMAP4, this queries the per-hwmod context loss register,
+ * assuming one exists. If not, or on OMAP2/3, this queries the
+ * enclosing powerdomain context loss count.
*/
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
+ if (oh-flags HWMOD_CONTEXT_REG)
+ return oh-prcm.omap4.context_lost_counter;
+
pwrdm = omap_hwmod_get_pwrdm(oh);
if (pwrdm)
ret = pwrdm_get_context_loss_count(pwrdm);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index f247dee..8f5510b 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -364,9 +364,12 @@ struct omap_hwmod_omap2_prcm {
/**
* struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data
- * @clkctrl_reg: PRCM address of the clock control register
- * @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM
+ * @clkctrl_offs: offset of the PRCM clock control register
+ * @rstctrl_offs: offset of the XXX_RSTCTRL register located in the PRM
+ * @context_offs: offset of the RM_*_CONTEXT register
* @submodule_wkdep_bit: bit shift of the WKDEP range
+ * @modulemode: allowable modulemodes
+ * @context_lost_counter: Count of module level context lost
*/
struct omap_hwmod_omap4_prcm {
u16 clkctrl_offs;
@@ -374,6 +377,7 @@ struct omap_hwmod_omap4_prcm {
u16 context_offs;
u8 submodule_wkdep_bit;
u8 modulemode;
+ unsignedcontext_lost_counter;
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
[PATCHv5 6/8] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states
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
---
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,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state
This will make it easier to handle next logic states for power domains
during suspend. With this patch, the parameter is also programmed to
retention for every powerdomain, thus all powerdomains enter CSWR
state after this patch.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 31990d5..cc85576 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -26,6 +26,7 @@
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
+ u32 next_logic_state;
#ifdef CONFIG_SUSPEND
u32 saved_state;
u32 saved_logic_state;
@@ -51,7 +52,7 @@ static int omap4_pm_suspend(void)
/* Set targeted power domain states by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
- pwrdm_set_logic_retst(pwrst-pwrdm, PWRDM_POWER_OFF);
+ pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-next_logic_state);
}
/*
@@ -108,6 +109,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
pwrst-pwrdm = pwrdm;
pwrst-next_state = PWRDM_POWER_RET;
+ pwrst-next_logic_state = PWRDM_POWER_RET;
list_add(pwrst-node, pwrst_list);
return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
From: Rajendra Nayak rna...@ti.com
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relyed on the power domain level context status.
Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
hwmods already have a valid 'context_offs' populated in .prcm structure.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 104 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 91 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index fd305bc..16836ca 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -128,6 +128,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
.name = dmm,
.class = omap44xx_dmm_hwmod_class,
.clkdm_name = l3_emif_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MEMIF_DMM_CLKCTRL_OFFSET,
@@ -184,6 +185,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
.name = emif_fw,
.class = omap44xx_emif_fw_hwmod_class,
.clkdm_name = l3_emif_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MEMIF_EMIF_FW_CLKCTRL_OFFSET,
@@ -229,6 +231,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
.name = l3_instr,
.class = omap44xx_l3_hwmod_class,
.clkdm_name = l3_instr_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L3INSTR_L3_INSTR_CLKCTRL_OFFSET,
@@ -328,6 +331,7 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
.name = l3_main_1,
.class = omap44xx_l3_hwmod_class,
.clkdm_name = l3_1_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.mpu_irqs = omap44xx_l3_main_1_irqs,
.prcm = {
.omap4 = {
@@ -430,6 +434,7 @@ static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
.name = l3_main_2,
.class = omap44xx_l3_hwmod_class,
.clkdm_name = l3_2_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L3_2_L3_2_CLKCTRL_OFFSET,
@@ -486,6 +491,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
.name = l3_main_3,
.class = omap44xx_l3_hwmod_class,
.clkdm_name = l3_instr_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L3INSTR_L3_3_CLKCTRL_OFFSET,
@@ -577,6 +583,7 @@ static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
.name = l4_cfg,
.class = omap44xx_l4_hwmod_class,
.clkdm_name = l4_cfg_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4CFG_L4_CFG_CLKCTRL_OFFSET,
@@ -605,6 +612,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod = {
.name = l4_per,
.class = omap44xx_l4_hwmod_class,
.clkdm_name = l4_per_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_L4PER_CLKCTRL_OFFSET,
@@ -633,6 +641,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
.name = l4_wkup,
.class = omap44xx_l4_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
@@ -807,6 +816,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.name = aess,
.class = omap44xx_aess_hwmod_class,
.clkdm_name = abe_clkdm,
+ .flags = HWMOD_CONTEXT_REG,
.mpu_irqs = omap44xx_aess_irqs,
.sdma_reqs = omap44xx_aess_sdma_reqs,
.main_clk = aess_fck,
@@ -898,7 +908,7 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
.name = counter_32k,
.class = omap44xx_counter_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
- .flags = HWMOD_SWSUP_SIDLE,
+ .flags = HWMOD_CONTEXT_REG | HWMOD_SWSUP_SIDLE,
.main_clk = sys_32k_ck,
.prcm = {
.omap4 = {
@@ -982,6 +992,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.name = dma_system,
.class =
[PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
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
---
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.'
*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/19] ARM: OMAP4: device off support
Hi, Changes compared to previous version: - generic: dropped a few redundant cpu_is_omapXxxx checks - generic: changed the ordering of patches a bit to allow new code + their users to be added in the same patch - patch 3: removed dpll/cm/sar calls from this patch - patch 4: added call to dpll save/restore to idle loop - patch 5: indentation changes, added call to cm save/restore to idle loop merged cm1/cm2 save/restore funcs to single cm save/restores - patch 6: added call to sar_save to idle loop - patch 12: added errata flag for the feature instead of runtime cpu type check - patch 15: reads the value of the register to be restored instead of using a magic number Device off requires I2C save/restore context patch to function properly, otherwise MMC driver sees issues during wakeup from off. Tested with omap4460 GP panda + omap4430 EMU blaze devices. Patches also available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off-v2 -Tero -- 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
[PATCHv2 01/19] ARM: OMAP4: PM: powerdomain: Add HWSAR flag to L3INIT
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.
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 */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 02/19] ARM: OMAP4: Add SAR ROM base address
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 --- 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_BASE0x40132000 #define OMAP44XX_MCPDM_L3_BASE 0x49032000 #define OMAP44XX_SAR_RAM_BASE 0x4a326000 +#define OMAP44XX_SAR_ROM_BASE 0x4a05e000 #define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000) #define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/19] ARM: OMAP4: PM: Add device-off support
This patch adds device off support to OMAP4 device type.
OFF mode is disabled by default, 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).
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: largely re-structured the code]
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;
+ 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();
+
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 WakeupGen SAR backup status.
*/
-void irq_sar_clear(void)
+static void irq_sar_clear(void)
{
u32 val;
val = __raw_readl(sar_base + SAR_BACKUP_STATUS_OFFSET);
@@ -271,7 +274,7 @@ void irq_sar_clear(void)
* Save GIC and Wakeupgen interrupt context using secure API
* for HS/EMU devices.
*/
-static void irq_save_secure_context(void)
+static void irq_save_secure_gic(void)
{
u32 ret;
ret = omap_secure_dispatcher(OMAP4_HAL_SAVEGIC_INDEX,
@@ -282,6 +285,40 @@ static void irq_save_secure_context(void)
}
#endif
+static void save_secure_ram(void)
+{
+ u32 ret;
+ ret = omap_secure_dispatcher(OMAP4_HAL_SAVESECURERAM_INDEX,
+ FLAG_START_CRITICAL,
+ 1, omap_secure_ram_mempool_base(),
+ 0, 0, 0);
+ if (ret != API_HAL_RET_VALUE_OK)
+ pr_err(Secure ram context save failed\n);
+}
+
+static void save_secure_all(void)
+{
+ u32 ret;
+ ret = omap_secure_dispatcher(OMAP4_HAL_SAVEALL_INDEX,
+ FLAG_START_CRITICAL,
+ 1, omap_secure_ram_mempool_base(),
+ 0, 0, 0);
+ if (ret != API_HAL_RET_VALUE_OK)
+ pr_err(Secure all context save failed\n);
+}
+
+static void irq_save_secure_context(void)
+{
+ if (omap4_device_next_state_off()) {
+ save_secure_all();
+ } else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
+ irq_save_secure_gic();
+ save_secure_ram();
+ } else {
+ irq_save_secure_gic();
+ }
+}
+
#ifdef CONFIG_HOTPLUG_CPU
static int __cpuinit irq_cpu_hotplug_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
@@ -388,5 +425,11 @@ int __init omap_wakeupgen_init(void)
irq_hotplug_init();
irq_pm_init();
+ mpuss_pd =
[PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
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
---
arch/arm/mach-omap2/cm44xx.h |5 +
arch/arm/mach-omap2/dpll44xx.c| 271 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 +-
3 files changed, 285 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
index 3380bee..5fba0fa 100644
--- a/arch/arm/mach-omap2/cm44xx.h
+++ b/arch/arm/mach-omap2/cm44xx.h
@@ -23,4 +23,9 @@
#define OMAP4_CM_CLKSTCTRL 0x
#define OMAP4_CM_STATICDEP 0x0004
+#ifndef __ASSEMBLER__
+extern void omap4_dpll_prepare_off(void);
+extern void omap4_dpll_resume_off(void);
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 9c6a296..d9ec05d 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -14,6 +14,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/bitops.h
+#include linux/delay.h
#include plat/cpu.h
#include plat/clock.h
@@ -21,6 +22,96 @@
#include clock.h
#include clock44xx.h
#include cm-regbits-44xx.h
+#include cm1_44xx.h
+#include cm2_44xx.h
+#include prcm44xx.h
+#include cminst44xx.h
+#include cm44xx.h
+
+#define MAX_DPLL_WAIT_TRIES100
+
+struct dpll_reg {
+ u16 offset;
+ u32 val;
+};
+
+struct omap4_dpll_regs {
+ char *name;
+ u32 mod_partition;
+ u32 mod_inst;
+ struct dpll_reg clkmode;
+ struct dpll_reg autoidle;
+ struct dpll_reg idlest;
+ struct dpll_reg clksel;
+ struct dpll_reg div_m2;
+ struct dpll_reg div_m3;
+ struct dpll_reg div_m4;
+ struct dpll_reg div_m5;
+ struct dpll_reg div_m6;
+ struct dpll_reg div_m7;
+ struct dpll_reg clkdcoldo;
+};
+
+static struct omap4_dpll_regs dpll_regs[] = {
+ /* MPU DPLL */
+ { .name = mpu,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_MPU_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_MPU_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_MPU_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_MPU_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_MPU_OFFSET},
+ },
+ /* IVA DPLL */
+ { .name = iva,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_IVA_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_IVA_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_IVA_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_IVA_OFFSET},
+ .div_m4 = {.offset = OMAP4_CM_DIV_M4_DPLL_IVA_OFFSET},
+ .div_m5 = {.offset = OMAP4_CM_DIV_M5_DPLL_IVA_OFFSET},
+ },
+ /* ABE DPLL */
+ { .name = abe,
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_ABE_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_ABE_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_ABE_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_ABE_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_ABE_OFFSET},
+ .div_m3 = {.offset = OMAP4_CM_DIV_M3_DPLL_ABE_OFFSET},
+ },
+ /* USB DPLL */
+ { .name = usb,
+ .mod_partition = OMAP4430_CM2_PARTITION,
+ .mod_inst = OMAP4430_CM2_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_USB_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_USB_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_USB_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_USB_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_USB_OFFSET},
+ .clkdcoldo= {.offset = OMAP4_CM_CLKDCOLDO_DPLL_USB_OFFSET},
+},
+ /* PER DPLL */
+ { .name = per,
+ .mod_partition = OMAP4430_CM2_PARTITION,
+ .mod_inst = OMAP4430_CM2_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_PER_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_PER_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_PER_OFFSET},
+ .clksel
[PATCHv2 05/19] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode
From: Rajendra Nayak rna...@ti.com
Restore all CM1/2 module registers as they are lost in OFF mode.
[n...@ti.com: minor clean ups]
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: Axel Haslam axelhas...@gmail.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm44xx.c | 328 +
arch/arm/mach-omap2/cm44xx.h |2 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c |2 +
3 files changed, 332 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cm44xx.c b/arch/arm/mach-omap2/cm44xx.c
index 535d66e..1958808 100644
--- a/arch/arm/mach-omap2/cm44xx.c
+++ b/arch/arm/mach-omap2/cm44xx.c
@@ -21,8 +21,11 @@
#include iomap.h
#include common.h
#include cm.h
+#include cm44xx.h
#include cm1_44xx.h
#include cm2_44xx.h
+#include cminst44xx.h
+#include prcm44xx.h
#include cm-regbits-44xx.h
/* CM1 hardware module low-level functions */
@@ -50,3 +53,328 @@ void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 reg)
{
__raw_writel(val, OMAP44XX_CM2_REGADDR(inst, reg));
}
+
+#define MAX_CM_REGISTERS 51
+
+struct omap4_cm_reg {
+ u16 offset;
+ u32 val;
+};
+
+struct omap4_cm_regs {
+ u16 mod_off;
+ u16 no_reg;
+ struct omap4_cm_reg reg[MAX_CM_REGISTERS];
+};
+
+static struct omap4_cm_regs cm1_regs[] = {
+ /* OMAP4430_CM1_OCP_SOCKET_MOD */
+ { .mod_off = OMAP4430_CM1_OCP_SOCKET_INST, .no_reg = 1,
+ {
+ { OMAP4_CM_CM1_PROFILING_CLKCTRL_OFFSET }
+ },
+ },
+ /* OMAP4430_CM1_CKGEN_MOD */
+ { .mod_off = OMAP4430_CM1_CKGEN_INST, .no_reg = 4,
+ {
+ { OMAP4_CM_CLKSEL_CORE_OFFSET },
+ { OMAP4_CM_CLKSEL_ABE_OFFSET },
+ { OMAP4_CM_DLL_CTRL_OFFSET },
+ { OMAP4_CM_DYN_DEP_PRESCAL_OFFSET }
+ },
+ },
+ /* OMAP4430_CM1_MPU_MOD */
+ { .mod_off = OMAP4430_CM1_MPU_INST, .no_reg = 4,
+ {
+ { OMAP4_CM_MPU_CLKSTCTRL_OFFSET },
+ { OMAP4_CM_MPU_STATICDEP_OFFSET },
+ { OMAP4_CM_MPU_DYNAMICDEP_OFFSET },
+ { OMAP4_CM_MPU_MPU_CLKCTRL_OFFSET }
+ },
+ },
+ /* OMAP4430_CM1_TESLA_MOD */
+ { .mod_off = OMAP4430_CM1_TESLA_INST, .no_reg = 4,
+ {
+ { OMAP4_CM_TESLA_CLKSTCTRL_OFFSET },
+ { OMAP4_CM_TESLA_STATICDEP_OFFSET },
+ { OMAP4_CM_TESLA_DYNAMICDEP_OFFSET },
+ { OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET }
+ },
+ },
+ /* OMAP4430_CM1_ABE_MOD */
+ { .mod_off = OMAP4430_CM1_ABE_INST, .no_reg = 15,
+ {
+ { OMAP4_CM1_ABE_CLKSTCTRL_OFFSET },
+ { OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_PDM_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_DMIC_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_MCASP_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_MCBSP1_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_MCBSP2_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_MCBSP3_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_SLIMBUS_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_TIMER5_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_TIMER6_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_TIMER7_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_TIMER8_CLKCTRL_OFFSET },
+ { OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET }
+ },
+ },
+};
+
+static struct omap4_cm_regs cm2_regs[] = {
+ /* OMAP4430_CM2_OCP_SOCKET_MOD */
+ { .mod_off = OMAP4430_CM2_OCP_SOCKET_INST, .no_reg = 1,
+ {
+ { OMAP4_CM_CM2_PROFILING_CLKCTRL_OFFSET }
+ },
+ },
+ /* OMAP4430_CM2_CKGEN_MOD */
+ { .mod_off = OMAP4430_CM2_CKGEN_INST, .no_reg = 12,
+ {
+ { OMAP4_CM_CLKSEL_DUCATI_ISS_ROOT_OFFSET },
+ { OMAP4_CM_CLKSEL_USB_60MHZ_OFFSET },
+ { OMAP4_CM_SCALE_FCLK_OFFSET },
+ { OMAP4_CM_CORE_DVFS_PERF1_OFFSET },
+ { OMAP4_CM_CORE_DVFS_PERF2_OFFSET },
+ { OMAP4_CM_CORE_DVFS_PERF3_OFFSET },
+ { OMAP4_CM_CORE_DVFS_PERF4_OFFSET },
+ { OMAP4_CM_CORE_DVFS_CURRENT_OFFSET },
+ { OMAP4_CM_IVA_DVFS_PERF_TESLA_OFFSET },
+ { OMAP4_CM_IVA_DVFS_PERF_IVAHD_OFFSET },
+ { OMAP4_CM_IVA_DVFS_PERF_ABE_OFFSET },
+
[PATCHv2 08/19] ARM: OMAP4: SAR: generate overwrite data based on SAR ROM contents
omap_sar_overwrite() now uses offsets detected during init time from
the SAR ROM contents.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-sar.c | 159 +---
1 files changed, 115 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-sar.c b/arch/arm/mach-omap2/omap-sar.c
index b49ae16..4244ee6 100644
--- a/arch/arm/mach-omap2/omap-sar.c
+++ b/arch/arm/mach-omap2/omap-sar.c
@@ -38,7 +38,52 @@ struct sar_ram_entry {
u32 ram_addr;
};
+struct sar_overwrite_entry {
+ u32 reg_addr;
+ u32 sar_offset;
+ bool valid;
+};
+
+enum {
+ MEMIF_CLKSTCTRL_IDX,
+ SHADOW_FREQ_CFG2_IDX,
+ SHADOW_FREQ_CFG1_IDX,
+ MEMIF_CLKSTCTRL_2_IDX,
+ HSUSBHOST_CLKCTRL_IDX,
+ HSUSBHOST_CLKCTRL_2_IDX,
+ OW_IDX_SIZE
+};
+
static struct sar_ram_entry *sar_ram_layout[3];
+static struct sar_overwrite_entry *sar_overwrite_data;
+
+static struct sar_overwrite_entry omap4_sar_overwrite_data[OW_IDX_SIZE] = {
+ [MEMIF_CLKSTCTRL_IDX] = { .reg_addr = 0x4a009e0c },
+ [SHADOW_FREQ_CFG2_IDX] = { .reg_addr = 0x4a004e2c },
+ [SHADOW_FREQ_CFG1_IDX] = { .reg_addr = 0x4a004e30 },
+ [MEMIF_CLKSTCTRL_2_IDX] = { .reg_addr = 0x4a009e0c },
+ [HSUSBHOST_CLKCTRL_IDX] = { .reg_addr = 0x4a009e54 },
+ [HSUSBHOST_CLKCTRL_2_IDX] = { .reg_addr = 0x4a009e54 },
+};
+
+static void check_overwrite_data(u32 io_addr, u32 ram_addr, int size)
+{
+ int i;
+
+ while (size) {
+ for (i = 0; i OW_IDX_SIZE; i++) {
+ if (sar_overwrite_data[i].reg_addr == io_addr
+ !sar_overwrite_data[i].valid) {
+ sar_overwrite_data[i].sar_offset = ram_addr;
+ sar_overwrite_data[i].valid = true;
+ break;
+ }
+ }
+ size--;
+ io_addr += 4;
+ ram_addr += 4;
+ }
+}
/*
* omap_sar_save :
@@ -166,53 +211,76 @@ int omap_sar_save(void)
void omap_sar_overwrite(void)
{
u32 val = 0;
- u32 usb_offset = 0x2ec;
- u32 usb_offset2 = 0x91c;
-
- /* Overwriting Phase1 data to be restored */
- /* CM2 MEMIF_CLKTRCTRL = SW_WKUP, before FREQ UPDATE */
- __raw_writel(0x2, sar_ram_base + SAR_BANK1_OFFSET + 0xd0);
- /* CM1 CM_SHADOW_FREQ_CONFIG2, Enable FREQ UPDATE */
- val = __raw_readl(OMAP4430_CM_SHADOW_FREQ_CONFIG2);
- /*
-* FIXME: Implement FREQ UPDATE for L#/M5 before enabling this
-* val |= 1 OMAP4430_FREQ_UPDATE_SHIFT;
-*/
- __raw_writel(val, sar_ram_base + SAR_BANK1_OFFSET + 0x100);
- /* CM1 CM_SHADOW_FREQ_CONFIG1, Enable FREQ UPDATE */
- val = __raw_readl(OMAP4430_CM_SHADOW_FREQ_CONFIG1);
- val |= 1 OMAP4430_FREQ_UPDATE_SHIFT;
- val = ~OMAP4430_DLL_OVERRIDE_2_2_MASK;
- __raw_writel(val, sar_ram_base + SAR_BANK1_OFFSET + 0x104);
- /* CM2 MEMIF_CLKTRCTRL = HW_AUTO, after FREQ UPDATE */
- __raw_writel(0x3, sar_ram_base + SAR_BANK1_OFFSET + 0x124);
-
- /* Overwriting Phase2a data to be restored */
- /* CM_L3INIT_USB_HOST_CLKCTRL: SAR_MODE = 1, MODULEMODE = 2 */
- __raw_writel(0x0012,
-sar_ram_base + SAR_BANK1_OFFSET + usb_offset);
- /* CM_L3INIT_USB_TLL_CLKCTRL: SAR_MODE = 1, MODULEMODE = 1 */
- __raw_writel(0x0011,
-sar_ram_base + SAR_BANK1_OFFSET + usb_offset + 4);
- /* CM2 CM_SDMA_STATICDEP : Enable static depedency for SAR modules */
- __raw_writel(0x90e8,
-sar_ram_base + SAR_BANK1_OFFSET + usb_offset + 8);
-
- /* Overwriting Phase2b data to be restored */
- /* CM_L3INIT_USB_HOST_CLKCTRL: SAR_MODE = 0, MODULEMODE = 0 */
- val = __raw_readl(OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL);
- val = (OMAP4430_CLKSEL_UTMI_P1_MASK | OMAP4430_CLKSEL_UTMI_P2_MASK);
- __raw_writel(val, sar_ram_base + SAR_BANK1_OFFSET + usb_offset2);
- /* CM_L3INIT_USB_TLL_CLKCTRL: SAR_MODE = 0, MODULEMODE = 0 */
- __raw_writel(0x000,
-sar_ram_base + SAR_BANK1_OFFSET + usb_offset2 + 4);
- /* CM2 CM_SDMA_STATICDEP : Clear the static depedency */
- __raw_writel(0x0040,
-sar_ram_base + SAR_BANK1_OFFSET + usb_offset2 + 8);
+ u32 offset = 0;
+
+ if (sar_overwrite_data[MEMIF_CLKSTCTRL_IDX].valid)
+ __raw_writel(0x2, sar_ram_base +
+ sar_overwrite_data[MEMIF_CLKSTCTRL_IDX].sar_offset);
+
+ if (sar_overwrite_data[SHADOW_FREQ_CFG1_IDX].valid) {
+ offset = sar_overwrite_data[SHADOW_FREQ_CFG1_IDX].sar_offset;
+ val = __raw_readl(sar_ram_base + offset);
+ val |= 1 OMAP4430_FREQ_UPDATE_SHIFT;
+ val = ~OMAP4430_DLL_OVERRIDE_2_2_MASK;
+ __raw_writel(val, sar_ram_base +
[PATCHv2 06/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF
From: Santosh Shilimkar santosh.shilim...@ti.com
The SAR RAM is maintained during Device OFF mode. The register layout
is fixed in SAR ROM. SAR is split into 4 banks with different
privilege accesses based on device type
---
Access modeBankAddress Range
---
HS/GP : Public 1 0x4A32_6000 - 0x4A32_6FFF (4kB)
HS/GP : Public 2 0x4A32_7000 - 0x4A32_73FF (1kB)
HS/EMU : Secured
GP : Public3 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.
[with contributions for 4460, cleanups from:
Rajeev Kulkarni raje...@ti.com
Nishanth Menon n...@ti.com
Axel Haslam axelhas...@gmail.com
Avinash.H.M avinas...@ti.com]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: dropped huge data tables as they are no longer needed
with subsequent patches that generate the layouts based on SAR ROM
contents, also dropped unnecessary dmm-44xx.h header file.]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/cm1_44xx.h |2 +
arch/arm/mach-omap2/cm2_44xx.h |2 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c |7 +
arch/arm/mach-omap2/omap-sar.c | 330
arch/arm/mach-omap2/omap4-common.c | 28 ---
arch/arm/mach-omap2/omap4-sar-layout.h | 50 +
arch/arm/mach-omap2/pm.h | 12 +
arch/arm/plat-omap/include/plat/omap44xx.h |5 +
9 files changed, 409 insertions(+), 29 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-sar.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..a978679 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \
- sleep44xx.o
+ sleep44xx.o omap-sar.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h
index 1bc00dc..c21b660 100644
--- a/arch/arm/mach-omap2/cm1_44xx.h
+++ b/arch/arm/mach-omap2/cm1_44xx.h
@@ -218,8 +218,10 @@
#define OMAP4430_CM1_ABE_WDT3_CLKCTRL
OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_INST, 0x0088)
/* Function prototypes */
+#ifndef __ASSEMBLER__
extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx);
extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx);
extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+#endif
#endif
diff --git a/arch/arm/mach-omap2/cm2_44xx.h b/arch/arm/mach-omap2/cm2_44xx.h
index b9de72d..3e8871e 100644
--- a/arch/arm/mach-omap2/cm2_44xx.h
+++ b/arch/arm/mach-omap2/cm2_44xx.h
@@ -450,8 +450,10 @@
#define OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL
OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CEFUSE_INST, 0x0020)
/* Function prototypes */
+#ifndef __ASSEMBLER__
extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx);
extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx);
extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+#endif
#endif
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 68923af..2d994dd 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -233,6 +233,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
{
unsigned int save_state = 0;
unsigned int wakeup_cpu;
+ int ret;
if (omap_rev() == OMAP4430_REV_ES1_0)
return -ENXIO;
@@ -265,6 +266,11 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
*/
mpuss_clear_prev_logic_pwrst();
if (omap4_device_next_state_off()) {
+ /* Save the device context to SAR RAM */
+ ret = omap_sar_save();
+ if (ret)
+ goto sar_save_failed;
+ omap_sar_overwrite();
omap4_cm_prepare_off();
omap4_dpll_prepare_off();
save_state = 3;
@@ -302,6 +308,7 @@ int
[PATCHv2 09/19] ARM: OMAP4: PM: add errata support
Added similar PM errata flag support as omap3 has. A few errata flags
will be added in subsequent patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ce1e27f..e53ee3c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -130,6 +130,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id) 0
+#endif
+
#ifdef CONFIG_OMAP_SMARTREFLEX
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8f0ec56..8238097 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -35,6 +35,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/19] ARM: OMAP4: PM: save/restore CM L3INSTR registers when MPU hits OSWR/OFF mode
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
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 35 -
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c |8 ++
3 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 73e45a5..f555ac2 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -95,6 +95,12 @@ static struct reg_tuple ivahd_reg[] = {
{.addr = OMAP4430_PM_IVAHD_PWRSTCTRL}
};
+static struct reg_tuple l3instr_reg[] = {
+ {.addr = OMAP4430_CM_L3INSTR_L3_3_CLKCTRL},
+ {.addr = OMAP4430_CM_L3INSTR_L3_INSTR_CLKCTRL},
+ {.addr = OMAP4430_CM_L3INSTR_OCP_WP1_CLKCTRL},
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -262,6 +268,28 @@ static inline void restore_ivahd_tesla_regs(void)
__raw_writel(ivahd_reg[i].val, ivahd_reg[i].addr);
}
+static inline void save_l3instr_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_L3INSTR_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(l3instr_reg); i++)
+ l3instr_reg[i].val = __raw_readl(l3instr_reg[i].addr);
+}
+
+static inline void restore_l3instr_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_L3INSTR_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(l3instr_reg); i++)
+ __raw_writel(l3instr_reg[i].val, l3instr_reg[i].addr);
+}
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -321,13 +349,16 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
omap4_cm_prepare_off();
omap4_dpll_prepare_off();
save_ivahd_tesla_regs();
+ save_l3instr_regs();
save_state = 3;
} else if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET)
(pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF)) {
save_ivahd_tesla_regs();
+ save_l3instr_regs();
save_state = 2;
} else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
save_ivahd_tesla_regs();
+ save_l3instr_regs();
save_state = 3;
}
@@ -352,8 +383,10 @@ 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_mpuss_read_prev_context_state())
+ if (omap4_mpuss_read_prev_context_state()) {
restore_ivahd_tesla_regs();
+ restore_l3instr_regs();
+ }
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index d2d468e..b971f6f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -131,6 +131,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
#define PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM (1 0)
+#define PM_OMAP4_ROM_L3INSTR_ERRATUM (1 1)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 3870c08..8591df2 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -274,6 +274,14 @@ static int __init omap4_pm_init(void)
omap_type() != OMAP2_DEVICE_TYPE_GP)
pm44xx_errata |= PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM;
+ /*
+* Similar to above errata, ROM code modifies L3INSTR clock
+* registers also and these must be saved / restored during
+* MPU OSWR / device off.
+*/
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ pm44xx_errata |= PM_OMAP4_ROM_L3INSTR_ERRATUM;
+
#ifdef CONFIG_SUSPEND
omap_pm_suspend = omap4_pm_suspend;
#endif
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/19] ARM: OMAP4: Auto generate SAR layout contents
SAR layout contents are now generated automatically based on SAR ROM
contents during boot.
u32 offset description
-- -
0 pointer to next entry
1 size of DMA transfer in bytes
2 SAR RAM address for save / restore
3 IO address for save / restore
sar_layout_generate() parses this info and stores the resulting data to
a list of sar_ram_entry structs, which in turn will be used by sar_save.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-sar.c | 270 +++-
1 files changed, 183 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-sar.c b/arch/arm/mach-omap2/omap-sar.c
index 141aebc..b49ae16 100644
--- a/arch/arm/mach-omap2/omap-sar.c
+++ b/arch/arm/mach-omap2/omap-sar.c
@@ -2,7 +2,8 @@
* OMAP4 Save Restore source file
*
* Copyright (C) 2010 Texas Instruments, Inc.
- * Written by Santosh Shilimkar santosh.shilim...@ti.com
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ * Tero Kristo t-kri...@ti.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -14,6 +15,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/clk.h
+#include linux/slab.h
#include iomap.h
#include pm.h
@@ -25,35 +27,18 @@
#include cminst44xx.h
static void __iomem *sar_ram_base;
-static void __iomem *omap4_sar_modules[MAX_SAR_MODULES];
static struct powerdomain *l3init_pwrdm;
static struct clockdomain *l3init_clkdm;
static struct clk *usb_host_ck, *usb_tll_ck;
-/*
- * SAR_RAM1 register layout consist of EMIF1, EMIF2, CM1, CM2,
- * CONTROL_CORE efuse, DMM and USB TLL registers.
- * The layout is arranged is a two dimentional array like
- * below,
- * const u32 sar_ramX_layout[nb_regs_sets][4] = {
- * {module_index, reg_offset, size, sar_ram_offset},
- * }
- */
-static const u32 omap443x_sar_ram1_layout[][4] = {
-};
-
-/*
- * SAR_RAM2 register layout consist of SYSCTRL_PADCONF_CORE regsiters
- */
-static const u32 omap443x_sar_ram2_layout[][4] = {
+struct sar_ram_entry {
+ void __iomem *io_base;
+ u32 offset;
+ u32 size;
+ u32 ram_addr;
};
-/*
- * SAR_RAM3 and SAR_RAM4 layout is not listed since moslty it's handle by
- * secure software.
- */
-static const u32 omap443x_sar_ram3_layout[][4] = {
-};
+static struct sar_ram_entry *sar_ram_layout[3];
/*
* omap_sar_save :
@@ -63,25 +48,20 @@ static const u32 omap443x_sar_ram3_layout[][4] = {
* @sar_bank_offset - where to backup
* @sar_layout - constant table containing the backup info
*/
-static void sar_save(u32 nb_regs, u32 sar_bank, const u32
sar_layout_table[][4])
+static void sar_save(struct sar_ram_entry *entry)
{
- u32 reg_val, size, i, j;
+ u32 reg_val, size, i;
void __iomem *reg_read_addr, *sar_wr_addr;
- for (i = 0; i nb_regs; i++) {
- if (omap4_sar_modules[(sar_layout_table[i][MODULE_ADDR_IDX])]) {
- size = sar_layout_table[i][MODULE_NB_REGS_IDX];
- reg_read_addr =
- omap4_sar_modules[sar_layout_table[i]
- [MODULE_ADDR_IDX]]
- + sar_layout_table[i][MODULE_OFFSET_IDX];
- sar_wr_addr = sar_ram_base + sar_bank +
- sar_layout_table[i][SAR_RAM_OFFSET_IDX];
- for (j = 0; j size; j++) {
- reg_val = __raw_readl(reg_read_addr + j * 4);
- __raw_writel(reg_val, sar_wr_addr + j * 4);
- }
+ while (entry-size) {
+ size = entry-size;
+ reg_read_addr = entry-io_base + entry-offset;
+ sar_wr_addr = sar_ram_base + entry-ram_addr;
+ for (i = 0; i size; i++) {
+ reg_val = __raw_readl(reg_read_addr + i * 4);
+ __raw_writel(reg_val, sar_wr_addr + i * 4);
}
+ entry++;
}
}
@@ -100,8 +80,7 @@ static void save_sar_bank3(void)
l4_secure_clkdm = clkdm_lookup(l4_secure_clkdm);
clkdm_wakeup(l4_secure_clkdm);
- sar_save(ARRAY_SIZE(omap443x_sar_ram3_layout), SAR_BANK3_OFFSET,
-omap443x_sar_ram3_layout);
+ sar_save(sar_ram_layout[2]);
clkdm_allow_idle(l4_secure_clkdm);
}
@@ -155,8 +134,7 @@ int omap_sar_save(void)
clk_enable(usb_tll_ck);
/* Save SAR BANK1 */
- sar_save(ARRAY_SIZE(omap443x_sar_ram1_layout), SAR_BANK1_OFFSET,
-omap443x_sar_ram1_layout);
+ sar_save(sar_ram_layout[0]);
clk_disable(usb_host_ck);
clk_disable(usb_tll_ck);
@@ -164,8 +142,7 @@ int omap_sar_save(void)
clkdm_allow_idle(l3init_clkdm);
/* Save SAR BANK2 */
-
[PATCHv2 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA
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.
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
This erratum impacts only OMAP4430 HS/EMU and is fixed on devices from
OMAP4430 ES2.3 onwards.
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
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 53 +
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm44xx.c | 11 ++
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 2d994dd..73e45a5 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -52,6 +52,7 @@
#include plat/omap44xx.h
+#include iomap.h
#include common.h
#include omap4-sar-layout.h
#include pm.h
@@ -76,6 +77,24 @@ static DEFINE_PER_CPU(struct omap4_cpu_pm_info,
omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+struct reg_tuple {
+ void __iomem *addr;
+ u32 val;
+};
+
+static struct reg_tuple tesla_reg[] = {
+ {.addr = OMAP4430_CM_TESLA_CLKSTCTRL},
+ {.addr = OMAP4430_CM_TESLA_TESLA_CLKCTRL},
+ {.addr = OMAP4430_PM_TESLA_PWRSTCTRL},
+};
+
+static struct reg_tuple ivahd_reg[] = {
+ {.addr = OMAP4430_CM_IVAHD_CLKSTCTRL},
+ {.addr = OMAP4430_CM_IVAHD_IVAHD_CLKCTRL},
+ {.addr = OMAP4430_CM_IVAHD_SL2_CLKCTRL},
+ {.addr = OMAP4430_PM_IVAHD_PWRSTCTRL}
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -215,6 +234,34 @@ static void save_l2x0_context(void)
{}
#endif
+static inline void save_ivahd_tesla_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(tesla_reg); i++)
+ tesla_reg[i].val = __raw_readl(tesla_reg[i].addr);
+
+ for (i = 0; i ARRAY_SIZE(ivahd_reg); i++)
+ ivahd_reg[i].val = __raw_readl(ivahd_reg[i].addr);
+}
+
+static inline void restore_ivahd_tesla_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(tesla_reg); i++)
+ __raw_writel(tesla_reg[i].val, tesla_reg[i].addr);
+
+ for (i = 0; i ARRAY_SIZE(ivahd_reg); i++)
+ __raw_writel(ivahd_reg[i].val, ivahd_reg[i].addr);
+}
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -273,11 +320,14 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
omap_sar_overwrite();
omap4_cm_prepare_off();
omap4_dpll_prepare_off();
+ save_ivahd_tesla_regs();
save_state = 3;
} else if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET)
(pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF)) {
+ save_ivahd_tesla_regs();
save_state = 2;
} else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
+ save_ivahd_tesla_regs();
save_state = 3;
}
@@ -302,6 +352,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_mpuss_read_prev_context_state())
+ restore_ivahd_tesla_regs();
+
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e53ee3c..d2d468e 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -130,6 +130,8 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
[PATCHv2 12/19] ARM: OMAP4: PM: update ROM return address for OSWR and OFF
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, 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), 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).
Signed-off-by: Carlos Leija cile...@ti.com
Signed-off-by: Praneeth Bajjuri prane...@ti.com
Signed-off-by: Bryan Buckley bryan.buck...@ti.com
[t-kri...@ti.com: merged the two patches into one]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-secure.h |1 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 13 +
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c |8
4 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index c90a435..d9bde61 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -43,6 +43,7 @@
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
/* Secure PPA(Primary Protected Application) APIs */
+#define OMAP4_PPA_SERVICE_00x21
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index f555ac2..1f06f97 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -52,6 +52,8 @@
#include plat/omap44xx.h
+#include mach/omap-secure.h
+
#include iomap.h
#include common.h
#include omap4-sar-layout.h
@@ -384,6 +386,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
if (omap4_mpuss_read_prev_context_state()) {
+ /*
+* Dummy dispatcher call after OSWR and OFF
+* Restore the right return Kernel address (with MMU on) for
+* subsequent calls to secure ROM. Otherwise the return address
+* will be to a PA return address and the system will hang.
+*/
+ if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_RETURN_ADDRESS_ERRATUM))
+ omap_secure_dispatcher(OMAP4_PPA_SERVICE_0,
+ FLAG_START_CRITICAL,
+ 0, 0, 0, 0, 0);
+
restore_ivahd_tesla_regs();
restore_l3instr_regs();
}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b971f6f..1d24b96 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -132,6 +132,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM (1 0)
#define PM_OMAP4_ROM_L3INSTR_ERRATUM (1 1)
+#define PM_OMAP4_ROM_RETURN_ADDRESS_ERRATUM(1 2)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8591df2..215b80e 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -282,6 +282,14 @@ static int __init omap4_pm_init(void)
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
pm44xx_errata |= PM_OMAP4_ROM_L3INSTR_ERRATUM;
+ /*
+* Restore the right return Kernel address (with MMU on) for
+* subsequent calls to secure ROM. Otherwise the return address
+* will be to a PA return address and the system will hang.
+*/
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ pm44xx_errata |= PM_OMAP4_ROM_RETURN_ADDRESS_ERRATUM;
+
#ifdef CONFIG_SUSPEND
omap_pm_suspend = omap4_pm_suspend;
#endif
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 13/19] ARM: OMAP4: PM: Mark the PPI and SPI interrupts as non-secure for GP
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_ID0x0
#define CPU1_ID0x1
+#define GIC_ISR_NON_SECURE 0x
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);
+ 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)
+{
+ 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)
/* WakeUpGen save restore offset from OMAP44XX_SAR_RAM_BASE */
#define WAKEUPGENENB_OFFSET_CPU0 (SAR_BANK3_OFFSET + 0x684)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
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
---
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();
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 18/19] ARM: OMAP4460: wakeupgen: set GIC_CPU0 backup status flag always
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
---
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)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 17/19] ARM: OMAP4: put cpu1 back to sleep if no wake request
If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back to off. This is needed during wakeup from device off to prevent cpu1 from being stuck indefinitely in the wakeup loop and also to prevent wakeup problem on GP chips with device off mode. Signed-off-by: Tero Kristo t-kri...@ti.com --- 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 + dsb + smc #0 + + isb + dsb + dmb + wfi + nop + nop +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 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 16/19] TEMP: ARM: OMAP4: prevent voltage transitions
During device off, the off-mode voltage transitions are enabled on reset.
Because the voltage control logic is not still completely functional for
OMAP4, we must disable the voltage transitions for device off for now.
This can only be done by disabling the I2C channel it seems.
This patch does not prevent voltage scaling done by voltdm-scale / DVFS.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index dfaa254..5d97b21 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -26,6 +26,9 @@
#include clockdomain.h
#include powerdomain.h
#include pm.h
+#include voltage.h
+#include prm44xx.h
+#include prm-regbits-44xx.h
#define EMIF_SDRAM_CONFIG2_OFFSET 0xc
@@ -210,6 +213,7 @@ static int __init omap4_pm_init(void)
int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ struct voltagedomain *mpu_voltdm;
if (!cpu_is_omap44xx())
return -ENODEV;
@@ -292,6 +296,24 @@ static int __init omap4_pm_init(void)
goto err2;
}
+ /*
+* XXX: voltage config is not still completely valid for
+* OMAP4, and this causes crashes on some platform during
+* device off because voltage transitions for device off
+* are enabled on reset. Thus, we have to disable the I2C
+* channel completely in the VOLTCTRL register to avoid
+* trouble. Remove this once voltconfigs are valid.
+*/
+ mpu_voltdm = voltdm_lookup(mpu);
+ if (!mpu_voltdm) {
+ pr_err(Failed to get MPU voltdm\n);
+ goto err2;
+ }
+ mpu_voltdm-write(OMAP4430_VDD_MPU_I2C_DISABLE_MASK |
+ OMAP4430_VDD_CORE_I2C_DISABLE_MASK |
+ OMAP4430_VDD_IVA_I2C_DISABLE_MASK,
+ OMAP4_PRM_VOLTCTRL_OFFSET);
+
ret = omap4_mpuss_init();
if (ret) {
pr_err(Failed to initialise OMAP4 MPUSS\n);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
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.
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_SYSCONFIG0x0010
+#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG 0x0114
+#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG 0x011c
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_00x0460
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_10x0464
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_20x0468
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_OFFSET 0xc
+
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()) {
+ 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);
+
+ 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);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 19/19] ARM: OMAP4: powerdomain: update mpu / core off counters during device off
Currently device off does not have any counters / timers of its own
and it is impossible to track the time spent in this state. In device
off, MPU / CORE powerdomains enter OSWR, so normally the RETENTION
state times / counts are increased during device off.
This patch adds a new field to the powerdomain struct for context loss
register, which is checked during pwrdm_post_transition to see if
a device off type context loss has happened. If this is the case,
the counters + timers for OFF state are touched instead of RETENTION.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |1 -
arch/arm/mach-omap2/powerdomain.c |9 +
arch/arm/mach-omap2/powerdomain.h |2 ++
arch/arm/mach-omap2/powerdomains44xx_data.c |2 ++
arch/arm/mach-omap2/prm44xx.c | 15 +++
arch/arm/mach-omap2/prm44xx.h |2 ++
6 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1f06f97..f187025 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -404,7 +404,6 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
- omap4_device_clear_prev_off_state();
}
sar_save_failed:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..f13bb2c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -156,6 +156,15 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
break;
case PWRDM_STATE_PREV:
prev = pwrdm_read_prev_pwrst(pwrdm);
+
+ /*
+* If powerdomain has context offset defined, check if
+* the domain has lost context (i.e. entered off)
+*/
+ if (pwrdm-context_offs)
+ if (omap4_pwrdm_lost_context_rff(pwrdm-prcm_offs,
+pwrdm-context_offs))
+ prev = PWRDM_POWER_OFF;
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..a427645 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -82,6 +82,7 @@ struct powerdomain;
* @name: Powerdomain name
* @voltdm: voltagedomain containing this powerdomain
* @prcm_offs: the address offset from CM_BASE/PRM_BASE
+ * @context_offs: the address offset for the CONTEXT register
* @prcm_partition: (OMAP4 only) the PRCM partition ID containing @prcm_offs
* @pwrsts: Possible powerdomain power states
* @pwrsts_logic_ret: Possible logic power states when pwrdm in RETENTION
@@ -106,6 +107,7 @@ struct powerdomain {
struct voltagedomain *ptr;
} voltdm;
const s16 prcm_offs;
+ const s16 context_offs;
const u8 pwrsts;
const u8 pwrsts_logic_ret;
const u8 flags;
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index d8701ce..c4de02f 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,6 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs= OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_L3_1_L3_1_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
@@ -205,6 +206,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs= OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 86c6c6b..de9132f 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -289,6 +289,21 @@ static void __init omap44xx_prm_enable_io_wakeup(void)
OMAP4_PRM_IO_PMCTRL_OFFSET);
}
+bool omap4_pwrdm_lost_context_rff(s16 inst, s16 offset)
+{
+ u32 val;
+
+ val = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, inst, offset);
+
+ if (val OMAP4430_LOSTCONTEXT_RFF_MASK) {
+ omap4_prminst_write_inst_reg(val, OMAP4430_PRM_PARTITION, inst,
+
Re: [PATCH 1/4] MFD: palmas PMIC device support
On 14/05/12 17:28, Mark Brown wrote:
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ maps - could we factor it out into regmap-irq? It'd also be
nice if it were using an irq_domain - while it's far from essential it
is something Grant has been pushing and I believe it'll be required when
you do device tree support.
The IRQ map is not dense. It is split into 4 registers which are not
contiguous. I think the overhead of translating to 4 reqmap irqs would
negate the point of using regmap irq. I can add to TODO to add this
handling to regmap_irq.
I am confused on the whole irq_domain business, is it replacement for
sparse irq? I don't see many users in drivers/mfd and not much
Documentation.
+if (palmas-irq_mask != reg_mask) {
+addr = PALMAS_BASE_TO_REG(PALMAS_INTERRUPT_BASE,
+PALMAS_INT1_MASK);
+reg = palmas-irq_mask 0xFF;
+regmap_write(palmas-regmap[slave], addr, reg);
This looks like you've open coded some regmap_update_bits() calls?
I did not notice this, but yes it could, I shall convert.
+if (!palmas-irq_base) {
+dev_warn(palmas-dev, No interrupt support, no IRQ base\n);
+return -EINVAL;
+}
If you use an irqdomain you can automatically allocate the interrupt
range much more easily (even if you don't if you pass -1 as the base
irq_alloc_descs() it's supposed to figure things out to you - it looks
like you're not calling irq_alloc_decs()).
As you noticed later I put the irq_alloc_descs in the wrong location I
shall fix.
With the irqdomain you should also find that as the interrupts are
always registered (even if they can't fire) then you can just assume
they're there in function drivers which makes the code simpler.
+ret = request_threaded_irq(palmas-irq, NULL, palmas_irq, IRQF_ONESHOT,
+ palmas-irq, palmas);
+
+irq_set_irq_type(palmas-irq, IRQ_TYPE_LEVEL_LOW);
Why not just IRQF_TRIGGER_LOW?
I was copying the style from other MFD drivers, I this method seems the
more popular. I am not fixed on this style though so I will change.
+static const struct mfd_cell palmas_children[] = {
+};
I'd just go ahead and fill this in, it makes merging much easier as the
function drivers don't have a merge dependency on the core.
OK I shall do this!
+static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS]
= {
+{
+.reg_bits = 8,
+.val_bits = 8,
+.cache_type = REGCACHE_NONE,
Shouldn't need to explicitly set REGCACHE_NONE. max_register might be
useful to get you register dumps in debugfs.
Ok, I was just making it clear that I was not caching, I know that
NONE=0, I shall add the max_register fields though.
+palmas = kzalloc(sizeof(struct palmas), GFP_KERNEL);
+if (palmas == NULL)
+return -ENOMEM;
devm_kzalloc().
I had meant to do this, will fix.
+ret = irq_alloc_descs(-1, 0, PALMAS_NUM_IRQ, 0);
+if (ret 0) {
+dev_err(i2c-dev, failed to allocate IRQ descs\n);
+goto err;
+}
Oh, here's the irq_alloc_descs() call - seems useful to put it in the
generic irq init?
As noted yes wrong location, will fix.
+palmas-regmap[i] = regmap_init_i2c(palmas-i2c_clients[i],
+palmas_regmap_config[i]);
devm_regmap_init_i2c().
Will fix!
+static const struct i2c_device_id palmas_i2c_id[] = {
+{ palmas, PALMAS_ID_TWL6035 },
+};
+MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
I'd suggest also including the part names as an option (so having an
entry for twl6035) - makes life easier for users as they don't need to
think about if the device is compatible.
Ok, I did have this then changed my mind, but I can add them back easy
enough.
+/* Bit definitions for MONTHS_REG */
+#define MONTHS_REG_MONTH1 0x10
+#define MONTHS_REG_MONTH1_SHIFT 4
+#define MONTHS_REG_MONTH0_MASK 0x0f
+#define MONTHS_REG_MONTH0_SHIFT 0
Some of these registers should be namespaced (many are already).
I can do this, it will take some of the register definitions pretty
close to 72 chars though.
Thanks for taking time to review.
Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MFD: palmas PMIC device support
On Mon, May 14, 2012 at 07:26:31PM +0900, Graeme Gregory wrote: On 14/05/12 17:28, Mark Brown wrote: On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote: drivers/mfd/palmas-irq.c | 241 + The IRQ support here seems to be following a pretty common pattern for dense IRQ maps - could we factor it out into regmap-irq? It'd also be nice if it were using an irq_domain - while it's far from essential it is something Grant has been pushing and I believe it'll be required when you do device tree support. The IRQ map is not dense. It is split into 4 registers which are not contiguous. I think the overhead of translating to 4 reqmap irqs would negate the point of using regmap irq. I can add to TODO to add this handling to regmap_irq. If the register blocks are nicely spaced we can probably find a framework way to do this. I am confused on the whole irq_domain business, is it replacement for sparse irq? I don't see many users in drivers/mfd and not much Documentation. regmap-irq in -next as of today has an example of using them for this type of device (and of course half the point of regmap-irq is that it avoids individual drivers needing to worry so much about things like this, they can just use data!). I also posted a patch for wm831x though that's got a bunch of noise in the function drivers due to passing the interrupt numbers through as resources, the core should be fairly clear though and is a bit more direct. signature.asc Description: Digital signature
RE: [PATCH v4 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value
Hi All, On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote: Some boards depend on bootloader to update chip select value for NAND. It is felt that Kernel should not depend on bootloader to get CS, as for a particular board CS is hardwired and is fixed, hence this can directly be updated in Kernel. But as CS value for boards that depend on this behaviour is not available, educate gpmc driver to acquire chip select value for NAND. this ideally should be removed once CS for those boards are available. Do you know how many boards require this? If so which are those boards? devkit8000, beagle board, omap3touchbook, overo. Beagle board, found out to be zero. I need a help. Can someone familiar with boards - devkit8000, omap3touchbook, overo boards, let me know GPMC CS on which NAND is connected. Hi Tony, I am planning to provide actual CS # used for NAND on above boards instead of finding the value at runtime. Is there any reason that NAND CS# is found out at runtime ? (hence remove necessity of omap_nand_flash_init()). Presence of this also causes an additional dependency of bootloader. As CS # depends on wiring on the board, my understanding is that it will be fixed for a given board. Are you ok if acquiring NAND CS # is removed ? Removal of this helps in simplifying gpmc driver (undergoing conversion). Regards Afzal -- 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: [PATCHv9 06/10] I2C: OMAP: Fix the crash in i2c remove
On Saturday 12 May 2012 11:40 PM, Wolfram Sang wrote:
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
I'd really like a comment from the PM experts if each and every driver
has to ensure that the clocks are enabled on remove like this?
Just resent cc ing linux-pm
BTW also found that
Some others are also doing the same. eg:
drivers/mmc/host/omap_hsmmc.c
static int __devexit omap_hsmmc_remove(struct platform_device *pdev)
{
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
pm_runtime_get_sync(host-dev);
mmc_remove_host(host-mmc);
2. drivers/usb/musb/musb_core.c
static void musb_shutdown(struct platform_device *pdev)
{
struct musb *musb = dev_to_musb(pdev-dev);
unsigned long flags;
pm_runtime_get_sync(musb-controller);
Anyways will wait for feedback.
---
drivers/i2c/busses/i2c-omap.c |
--
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
Hi, On Mon, May 14, 2012 at 02:49:11PM +0300, Tomi Valkeinen wrote: Hi Felipe, I'm seeing the following crash on Panda, when booting with today's linux-next, using the attached config. Tomi [1.923400] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [1.923400] Unable to handle kernel NULL pointer dereference at virtual address 0036 [1.938171] pgd = c0004000 [1.941009] [0036] *pgd= [1.944763] Internal error: Oops: 5 [#1] SMP ARM [1.949584] Modules linked in: [1.952789] CPU: 0Not tainted (3.4.0-rc7-next-20120514-10436-g7769ab8 #450) [1.960540] PC is at kobject_get+0xc/0x4c [1.964721] LR is at get_device+0x14/0x1c [1.968933] pc : [c0250d60]lr : [c02ac47c]psr: 2113 sp : ebc31d98 ip : 0003 fp : eb36d1dc [1.979553] r10: eb36c128 r9 : eb349880 r8 : fc0ab000 [1.985015] r7 : eb348408 r6 : c06f2830 r5 : eb348408 r4 : 001a [1.991851] r3 : eb349880 r2 : r1 : c04bf2b4 r0 : 001a [1.998687] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [2.006317] Control: 10c53c7d Table: 8000404a DAC: 0017 [2.012329] Process swapper/0 (pid: 1, stack limit = 0xebc302f8) [2.018615] Stack: (0xebc31d98 to 0xebc32000) [2.023162] 1d80: eb349880 c0c788f4 [2.031707] 1da0: eb348408 c02ac47c eb349880 c033d604 eb36c128 c035bdc8 c035bdb0 007c [2.040283] 1dc0: eb348400 0010 eb348408 c047dddc ebeba630 c0c76fd8 eb348408 [2.048828] 1de0: c0c76fd8 c0c76fe8 c071c0ac c0728b80 009e c02b0e68 [2.057373] 1e00: c02b0e50 c02afab8 c02b10f0 eb348408 c02afcd0 c0c76f94 [2.065948] 1e20: c0728b80 c02ae1dc ebc412d8 ebebbe94 eb348408 eb34843c c070fbc0 c02af9dc [2.074493] 1e40: eb348408 eb348408 c070fbc0 c02aefb8 eb348408 eb348410 ebd7c808 c02ad840 [2.083038] 1e60: c06f8438 ebebbd78 eb3498c0 ebebbd40 c0690444 eb348400 [2.091583] 1e80: eb348408 0003 eb3498c0 ebebbd40 c0690444 c0728b80 009e c02b1480 [2.100158] 1ea0: eb348400 ebd7c808 eb3498c0 ebd7dd00 c047e7a0 ebd7c808 c0c76fd8 [2.108703] 1ec0: c0c76fe8 c071c16c c02b0e68 c02b0e50 c02afab8 ebd7c808 [2.117248] 1ee0: c071c16c ebd7c83c c067882c c0728b80 c02afccc c071c16c c02afc38 [2.125793] 1f00: c02ae258 ebc412a8 ebd76790 c071c16c c070fbc0 ebebbdc0 c02af16c [2.134368] 1f20: c0598c20 ebc489c0 c071c16c c0728b80 ebc3 c067882c [2.142913] 1f40: c0690444 c0728b80 009e c02b0200 c0678844 c0728b80 ebc3 [2.151458] 1f60: c067882c c0728b80 c0008730 c061fe04 c06207e4 c149014e c066dbe4 [2.160003] 1f80: c0678850 c05dc310 0001 0006 0006 c058cec4 c0678844 [2.168579] 1fa0: 001c 0006 c0678850 c067882c c0690444 c0728b80 009e c0647928 [2.177124] 1fc0: 0006 0006 c06471c4 c0647810 c0014f34 [2.185668] 1fe0: 0013 c0014f34 818a 3a80a8aa [2.194244] [c0250d60] (kobject_get+0xc/0x4c) from [c02ac47c] (get_device+0x14/0x1c) [2.202697] [c02ac47c] (get_device+0x14/0x1c) from [c033d604] (usb_get_transceiver+0x1c/0x28) [2.212005] [c033d604] (usb_get_transceiver+0x1c/0x28) from [c035bdc8] (omap2430_musb_init+0x 18/0x184) [2.222106] [c035bdc8] (omap2430_musb_init+0x18/0x184) from [c047dddc] (musb_probe+0x1bc/0x5a 0) [2.231567] [c047dddc] (musb_probe+0x1bc/0x5a0) from [c02b0e68] (platform_drv_probe+0x18/0x1c looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c -- balbi signature.asc Description: Digital signature
Re: Panda: USB crash with today's linux-next
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c Ah. Perhaps it's then about this? [0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) [0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 [0.356079] VUSB: 3300 mV normal standby [0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 Tomi signature.asc Description: This is a digitally signed message part
Re: Panda: USB crash with today's linux-next
On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote: On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c Ah. Perhaps it's then about this? [0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) [0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 [0.356079] VUSB: 3300 mV normal standby [0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ? -- balbi signature.asc Description: Digital signature
Re: Panda: USB crash with today's linux-next
Hi, On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote: On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote: On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c Ah. Perhaps it's then about this? [0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) [0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 [0.356079] VUSB: 3300 mV normal standby [0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ? Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver... -- balbi signature.asc Description: Digital signature
Re: [PATCH] omap: dma: Clear status registers on enable/disable irq.
On Sunday 06 of May 2012 18:50:16 Jarkko Nikula wrote: On 05/04/2012 10:39 PM, Janusz Krzysztofik wrote: This seems like a nice fix to me. As it affects all omaps, I'd like to see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a try with some audio tests? OK, I can do, but perhaps not before next Saturday, when I'm back home, able to actually listen to the audio, not only watch the IRQ counters rising up ;-). Ok from omap3 Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com Works for me on OMAP1. Tested-by: Janusz Krzyszofik jkrzy...@tis.inet.pl -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds
On Friday 11 of May 2012 09:53:07 Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120510 15:31]: Janusz Krzysztofik reported the following build break on OMAP1 builds that don't include CONFIG_ARCH_OMAP16XX: LD .tmp_vmlinux1 arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' make: *** [.tmp_vmlinux1] Error 1 This was caused by commit d3645d39ad0ed9f09535065676ea0ba114f93cdf (ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus). Fix by declaring an empty ocpi_enable() on non-16XX builds, which should work until the OCPI code is moved out to drivers/. Thanks applying into fixes-for-cleanup branch. Tony FWIW, works with OMAP1510 only config on my Amstrad Delta. Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl -- 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 01/11] OMAP2+: Add SoC specific map_io functions
Salut Thomas, Sorry for the delay. On 5/4/2012 5:59 PM, Thomas Petazzoni wrote: Hello Benoit, Le Fri, 23 Sep 2011 22:23:09 +0200, Benoit Coussonb-cous...@ti.com a écrit : Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tony Lindgrent...@atomide.com Do you know if some progress has been made on having a generic DT aware map_io function, or is the per-SoC -map_io() function still the recommended way of handling SoC having different requirements of static mappings at boot time? Mmm, Maybe I'm wrong, but I'm not sure people are really pushing to store that inside DT. But to be honest, I don't really know :-) Tony might have some clue. 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 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44
+
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
+sizeof(am35xx_emac_pdata),
+pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include plat/omap_device.h
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY 100
-#if defined(CONFIG_TI_DAVINCI_EMAC) ||
defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if
Re: Panda: USB crash with today's linux-next
On 5/14/2012 2:47 PM, Felipe Balbi wrote: Hi, On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote: On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote: On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c Ah. Perhaps it's then about this? [0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) [0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 [0.356079] VUSB: 3300 mV normal standby [0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ? Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver... Well, yeah, I did not clean all that mess. That being said, we did have some issue recently as well, but due to the increase of IRQ number and the fact the NR_IRQS is still used since SPARSE_IRQ migration is not completed. At least we saw similar issue with OMAP5. Maybe increasing NR_IRQS will fix that, but in this case, it looks like the IRQ might already been used by someone else. This is probably because something is still using the hard coded IRQ BASE number from the irqs.h define. I was planning to get rid of them to highlight the broken driver / board that might still used them. But this is on my TODO list :-( 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: Panda: USB crash with today's linux-next
Hi, On Mon, May 14, 2012 at 07:06:25PM +0200, Cousson, Benoit wrote: On 5/14/2012 2:47 PM, Felipe Balbi wrote: Hi, On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote: On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote: On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c Ah. Perhaps it's then about this? [0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) [0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 [0.356079] VUSB: 3300 mV normal standby [0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ? Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver... Well, yeah, I did not clean all that mess. That being said, we did have some issue recently as well, but due to the increase of IRQ number and the fact the NR_IRQS is still used since SPARSE_IRQ migration is not completed. At least we saw similar issue with OMAP5. Maybe increasing NR_IRQS will fix that, but in this case, it looks like the IRQ might already been used by someone else. This is probably because something is still using the hard coded IRQ BASE number from the irqs.h define. I was planning to get rid of them to highlight the broken driver / board that might still used them. But this is on my TODO list :-( another thing you might want to add to your TODO list is implementing irq_chip properly on twl6030-irq: $ git grep -e EXPORT_SYMBOL drivers/mfd/twl6030-irq.c drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect_config); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect); $ git grep -e twl6030_interrupt_\(mask\|unmask\) drivers/ drivers/mfd/twl6030-irq.c:int twl6030_interrupt_unmask(u8 bit_mask, u8 offset) drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask); drivers/mfd/twl6030-irq.c:int twl6030_interrupt_mask(u8 bit_mask, u8 offset) drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask); drivers/mfd/twl6030-irq.c: twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK, drivers/mfd/twl6030-irq.c: twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_mask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_mask(TWL6030_RTC_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(0x05, REG_INT_MSK_LINE_C); drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(0x05, REG_INT_MSK_STS_C); drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK, 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. -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm: omap3: am35x: Set proper powerdomain states
On Mon, Apr 30, 2012 at 02:26:48PM -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com The am35x family of SoCs only support the PWRSTS_ON state so create a new set of powerdomain structures that ensure that only the ON state is entered. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- Ping? -- 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
* 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. I posted some patches to take care of the card detection in the MMC driver by leaving out the platform callbacks: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html That's using gpiochip_find_by_name(), but after talking with Grant about that, we agreed gpiochip_find_by_name() should be local as there's no guarantees about anything with the gpiochip names. Regards, Tony -- 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
* 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 :) I posted some patches to take care of the card detection in the MMC driver by leaving out the platform callbacks: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html That's using gpiochip_find_by_name(), but after talking with Grant about that, we agreed gpiochip_find_by_name() should be local as there's no guarantees about anything with the gpiochip names. Regards, Tony -- 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/12/2012 05:49 PM, Linus Walleij wrote: On Thu, May 10, 2012 at 7:05 PM, Stephen Warren swar...@wwwdotorg.org wrote: Also, were you intending pinctrl-simple to actually be the GPIO controller itself? That'd be another case that one might consider fairly simple, but then extends to being gpio-simple as well as pinctrl-simple... 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. 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. And irrespective of how the drivers are structured, if there are two HW modules, we really need two separate nodes in DT to describe them, since the SW architecture (1 vs. 2 drivers) shouldn't influence the DT representation unduly. 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. -- 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 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. 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. -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
On Mon, 14 May 2012, Cousson, Benoit wrote: Salut Thomas, Sorry for the delay. On 5/4/2012 5:59 PM, Thomas Petazzoni wrote: Hello Benoit, Le Fri, 23 Sep 2011 22:23:09 +0200, Benoit Coussonb-cous...@ti.com a écrit : Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tony Lindgrent...@atomide.com Do you know if some progress has been made on having a generic DT aware map_io function, or is the per-SoC -map_io() function still the recommended way of handling SoC having different requirements of static mappings at boot time? Mmm, Maybe I'm wrong, but I'm not sure people are really pushing to store that inside DT. But to be honest, I don't really know :-) In general, static vs dynamic IO mappings are just some Linux implementation details. This distinction does not belong in DT. Nicolas
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
Mark A. Greer mgr...@animalcreek.com writes:
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44
+
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
- sizeof(am35xx_mdio_pdata));
+ sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long
mdio_bus_freq, u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
- sizeof(am35xx_emac_pdata));
+ sizeof(am35xx_emac_pdata),
+ pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include plat/omap_device.h
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY 100
-#if defined(CONFIG_TI_DAVINCI_EMAC) ||
defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if
Re: [PATCH] ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
Vaibhav Hiremath hvaib...@ti.com writes: From: Kevin Hilman khil...@ti.com There are certain fields inside 'struct dpll_data' which are included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it difficult to use it for new devices like, am33xx, ti81xx, etc... So remove the ifdef completely, this will add few fields to the struct unused, but it improves readability and maintainability of the code. Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: R Sricharan r.sricha...@ti.com --- Since Kevin had provided this idea and code change, making this patch under his authorship. Be sure to give yourself credit for writing the changelog. Normally, if you make changes/additions to patch, you can add a line just before your signoff. Something like: [hvaib...@ti.com: wrote detailed changelog] 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: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Tomi Valkeinen tomi.valkei...@ti.com writes: On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, 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 =). Unfortunately, without the bandwidth to dig into this deeply myself, I don't have much to add. As we know, it's not unheard of for various IPs to have bugs in smart-idle mode ;) The one thing I can say is that the reason it probably worked on earlier kernels was because the UART driver was not actually idling, so you were probably never hitting low power states. 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: MUSB problem
Actually, I was too hasty saying that this worked even with this error. I can ping out from my board, but any higher level of traffic, e.g. SSH into the box, falls over The problems vanish when I disable MUSB DMA. What gives? I'm also seeing this on a variety of kernels, from 2.6.34 to 3.3.0. I must explicitly set musb_hdrc.use_dma=n for the smsc95xx card to function. The latest kernel I have tested this against is: Linux WC-11003A 3.3.0 #1 PREEMPT Fri May 11 18:05:35 PDT 2012 armv7l GNU/Linux -- 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/2] arm: omap3: am35x: Convert emac to hwmod disable hlt when open
+Sekhar, Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com Paul, Kevin, These patches convert the davinci emac support for the am35x SoC to use hwmod and add enable_hlt()/disable_hlt() calls to the pm_runtime hooks for that driver. Great. I didn't look closely at the hwmod data, but the approach is right here, IMO. I have converted the davinci_emac driver to use pm_runtime but I can't formally submit it yet since it requires some changes on the mach-davinci side that haven't happened yet. I will send it as an RFC in a reply to this thread. Sekhar, are you planning to add runtime PM core support to davinci? I recommend looking at the simple OMAP1 layer that implements a basic clocks-only runtime PM layer. Kevin The patches are based on: git://git.pwsan.com/linux-2.6 am35xx_hwmod_data_fixes_a_3.5 Mark -- Mark A. Greer (2): arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support arm: omap3: am35x: Disable hlt when using Davinci EMAC arch/arm/mach-omap2/am35xx-emac.c | 120 ++-- arch/arm/mach-omap2/am35xx-emac.h | 16 +++- arch/arm/mach-omap2/board-am3517evm.c |3 +- arch/arm/mach-omap2/board-cm-t3517.c |3 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/include/mach/am35xx.h |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 7 files changed, 183 insertions(+), 48 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: [RFC 00/12] OMAP DMA engine conversion
On Mon, 2012-04-23 at 17:04 +0100, Russell King - ARM Linux wrote: For the full text, please see http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html This version contains updates for some of the comments received from the previous round, and adds the OMAP1/2 MMC and SPI drivers to the conversion. I've also added a note to feature-removal noting that the existing APIs will be removed around 2013 - I'm planning January for that at the moment. Having drivers around which are unconverted blocks further work on the DMA engine conversion, so it's actually important that we get as many drivers converted as soon as possible. Anything which isn't converted will probably have its DMA code removed, or if that results in the driver not being usable, the driver itself will be removed. This series is still in RFC mode... Hi Russell, What is the state of this series, would be good to have this merged in upcoming merge window. Documentation/feature-removal-schedule.txt | 11 + arch/arm/mach-omap1/board-h2-mmc.c |1 - arch/arm/mach-omap1/board-h3-mmc.c |1 - arch/arm/mach-omap1/board-nokia770.c |1 - arch/arm/mach-omap2/board-n8x0.c |1 - arch/arm/mach-omap2/hsmmc.c|1 - arch/arm/plat-omap/dma.c | 14 + arch/arm/plat-omap/include/plat/mmc.h |2 - drivers/dma/Kconfig| 10 + drivers/dma/Makefile |2 + drivers/dma/omap-dma.c | 521 drivers/dma/sa11x0-dma.c | 249 - drivers/dma/virt-dma.c | 99 ++ drivers/dma/virt-dma.h | 138 drivers/mmc/host/omap.c| 369 +--- drivers/mmc/host/omap_hsmmc.c | 206 ++-- drivers/spi/spi-omap2-mcspi.c | 228 +++-- 17 files changed, 1268 insertions(+), 586 deletions(-) ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- ~Vinod -- 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 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.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 ++--
1 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 636533d..b02aa81 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -18,6 +18,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/platform_data/omap4-keypad.h
+#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/irqs.h
@@ -434,13 +435,22 @@ static struct omap_device_pm_latency omap_pmu_latency[]
= {
};
static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
static void omap4_enable_cti(int irq)
{
- if (irq == OMAP44XX_IRQ_CTI0)
+ pm_runtime_get_sync(pmu_dev-dev);
+ if (irq == OMAP44XX_IRQ_CTI0) {
+ /* configure CTI0 for pmu irq routing */
+ cti_unlock(omap4_cti[0]);
+ cti_map_trigger(omap4_cti[0], 1, 6, 2);
cti_enable(omap4_cti[0]);
- else if (irq == OMAP44XX_IRQ_CTI1)
+ } else if (irq == OMAP44XX_IRQ_CTI1) {
+ /* configure CTI1 for pmu irq routing */
+ cti_unlock(omap4_cti[1]);
+ cti_map_trigger(omap4_cti[1], 1, 6, 2);
The above line should be changed to below
cti_map_trigger(omap4_cti[1], 1, 6, 3);
See below link for addressed irq flood issue.
http://permalink.gmane.org/gmane.linux.linaro.devel/10532
cti_enable(omap4_cti[1]);
+ }
}
static void omap4_disable_cti(int irq)
@@ -449,6 +459,7 @@ static void omap4_disable_cti(int irq)
cti_disable(omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(omap4_cti[1]);
+ pm_runtime_put(pmu_dev-dev);
}
static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t
handler)
@@ -461,27 +472,20 @@ static irqreturn_t omap4_pmu_handler(int irq, void
*dev, irq_handler_t handler)
return handler(irq, dev);
}
-static void __init omap4_configure_pmu_irq(void)
+static int __init omap4_configure_pmu(void)
{
- void __iomem *base0;
- void __iomem *base1;
+ omap4_cti[0].base = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ omap4_cti[1].base = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
- base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
- base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
- if (!base0 !base1) {
+ if (!omap4_cti[0].base || !omap4_cti[1].base) {
pr_err(ioremap for OMAP4 CTI failed\n);
- return;
+ return -ENOMEM;
}
- /*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);
+ cti_init(omap4_cti[0], omap4_cti[0].base, OMAP44XX_IRQ_CTI0, 6);
+ cti_init(omap4_cti[1], omap4_cti[1].base, OMAP44XX_IRQ_CTI1, 6);
- /*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);
+ return 0;
}
static struct platform_device* __init omap4_init_pmu(void)
@@ -492,6 +496,9 @@ static struct platform_device* __init omap4_init_pmu(void)
struct omap_hwmod* oh[3];
char *dev_name = arm-pmu;
+ if (omap4_configure_pmu())
+ return NULL;
+
hw = l3_main_3;
oh[0] = omap_hwmod_lookup(hw);
if (!oh[0]) {
@@ -530,14 +537,11 @@ static void __init omap_init_pmu(void)
} else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = omap3_pmu_resource;
} else if (cpu_is_omap44xx()) {
- struct platform_device *pd;
-
- pd = omap4_init_pmu();
- if (!pd)
+ pmu_dev = omap4_init_pmu();
+ if (!pmu_dev)
return;
- omap_device_enable(od-pdev);
- omap4_configure_pmu_irq();
+
spi_complete oops
Hello. I develop driver to communicate to some chip via spi. Chip generate interrupts in which i run workqueue. Inside workqueue's handler i need to exchange data white chip again. Sometimes i got OOPS in spi_complete as args == NULL. What can be the reason of this? SPI message .complete and .context set up in __spy_sync call. I run kernel 3.1.5 on Variscite OM4460 board. WBR, -- Rumjantsev Egor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
On Tue, May 15, 2012 at 03:54:11, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: From: Kevin Hilman khil...@ti.com There are certain fields inside 'struct dpll_data' which are included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it difficult to use it for new devices like, am33xx, ti81xx, etc... So remove the ifdef completely, this will add few fields to the struct unused, but it improves readability and maintainability of the code. Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: R Sricharan r.sricha...@ti.com --- Since Kevin had provided this idea and code change, making this patch under his authorship. Be sure to give yourself credit for writing the changelog. Normally, if you make changes/additions to patch, you can add a line just before your signoff. Something like: [hvaib...@ti.com: wrote detailed changelog] Ok... Paul, Can you please add above statement, when you merge it into your repo? Thanks, Vaibhav -- 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 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Thanks, Kevin -- Regards and Thanks, Keerthy -- 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
