* [PATCH RESEND] ARM: smp_twd: Reconfigure clockevents after cpufreq change
From: Thomas Gleixner @ 2011-10-06 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKnu2ModYp+F0kq6qVo9SQJ88GR_EwGNgH2WZXJrXUeR1xyzQw@mail.gmail.com>
On Thu, 6 Oct 2011, Linus Walleij wrote:
> 2011/9/6 Linus Walleij <linus.walleij@stericsson.com>:
>
> > From: Colin Cross <ccross@android.com>
> >
> > The localtimer's clock changes with the cpu clock. After a
> > cpufreq transition, update the clockevent's frequency and
> > reprogram the next clock event.
>
> Thomas do you think you can have a look at this patch and ACK
> it if it looks OK to you? It's the use of clockevents_update_freq()
> function you added after we discussed this in Budapest.
>
> Since it's likely the first user of that infrastructure we need
> to get it right.
The usage is correct.
> Here is the entire patch i Russells tracker:
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6956/2
The only thing what puzzles me is:
> + if (!IS_ERR_OR_NULL(twd_clk))
> + twd_timer_rate = clk_get_rate(twd_clk);
> + else
> + twd_calibrate_rate();
How is made sure that the cpu freq update thing is not called when
twd_clk is not available or am I missing something ?
Thanks,
tglx
^ permalink raw reply
* [PATCH v2] omap: dmtimer: convert printk to pr_err / WARN
From: Víctor Manuel Jáquez Leal @ 2011-10-06 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317898106-1891-1-git-send-email-vjaquez@igalia.com>
Convert a printk(KERN_ERR) message in the driver to pr_err(), and
use WARN() instead of a custom log message with a stack dump.
Signed-off-by: V?ctor Manuel J?quez Leal <vjaquez@igalia.com>
---
arch/arm/plat-omap/dmtimer.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index ee9f6eb..dead0f3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -322,7 +322,7 @@ static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
while (!(omap_dm_timer_read_reg(timer, OMAP_TIMER_SYS_STAT_REG) & 1)) {
c++;
if (c > 100000) {
- printk(KERN_ERR "Timer failed to reset\n");
+ pr_err("Timer failed to reset\n");
return;
}
}
@@ -397,9 +397,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
spin_lock_irqsave(&dm_timer_lock, flags);
if (id <= 0 || id > dm_timer_count || dm_timers[id-1].reserved) {
spin_unlock_irqrestore(&dm_timer_lock, flags);
- printk("BUG: warning at %s:%d/%s(): unable to get timer %d\n",
- __FILE__, __LINE__, __func__, id);
- dump_stack();
+ WARN(1, "unable to get timer %d\n", id);
return NULL;
}
--
1.7.6.3
^ permalink raw reply related
* [PATCH 2/2] hw_random: add driver for atmel true hardware random number generator
From: Peter Korsgaard @ 2011-10-06 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006160200.GF1931@totoro>
>>>>> "Jamie" == Jamie Iles <jamie@jamieiles.com> writes:
Jamie> Hi Peter,
Jamie> A couple of minor nits inline, but otherwise looks nice to me!
Thanks for the review.
Jamie> Could you do:
Jamie> struct atmel_trng {
Jamie> struct clk *clk;
Jamie> void __iomem *base;
Jamie> struct hwrng rng;
Jamie> };
Sure. Multiple trngs doesn't make much sense, but that approach leads to
slightly less lines, so ok.
I'll send an updated patch shortly.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCHv2] hw_random: add driver for atmel true hardware random number generator
From: Peter Korsgaard @ 2011-10-06 17:56 UTC (permalink / raw)
To: linux-arm-kernel
For the IP block on 9g45/9g46/9m10/9m11.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Changes since v1:
- Embed struct hwrng in struct atmel_trng as suggested by Jamie Iles.
drivers/char/hw_random/Kconfig | 13 +++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/atmel-rng.c | 158 ++++++++++++++++++++++++++++++++++++
3 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 drivers/char/hw_random/atmel-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 1d2ebc7..e013587 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -60,6 +60,19 @@ config HW_RANDOM_AMD
If unsure, say Y.
+config HW_RANDOM_ATMEL
+ tristate "Atmel Random Number Generator support"
+ depends on HW_RANDOM && ARCH_AT91SAM9G45
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Atmel AT91 devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called atmel-rng.
+
+ If unsure, say Y.
+
config HW_RANDOM_GEODE
tristate "AMD Geode HW Random Number Generator support"
depends on HW_RANDOM && X86_32 && PCI
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index c88f244..b2ff526 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -7,6 +7,7 @@ rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
obj-$(CONFIG_HW_RANDOM_INTEL) += intel-rng.o
obj-$(CONFIG_HW_RANDOM_AMD) += amd-rng.o
+obj-$(CONFIG_HW_RANDOM_ATMEL) += atmel-rng.o
obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
n2-rng-y := n2-drv.o n2-asm.o
diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
new file mode 100644
index 0000000..241df2e
--- /dev/null
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2011 Peter Korsgaard <jacmet@sunsite.dk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/hw_random.h>
+#include <linux/platform_device.h>
+
+#define TRNG_CR 0x00
+#define TRNG_ISR 0x1c
+#define TRNG_ODATA 0x50
+
+#define TRNG_KEY 0x524e4700 /* RNG */
+
+struct atmel_trng {
+ struct clk *clk;
+ void __iomem *base;
+ struct hwrng rng;
+};
+
+static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ struct atmel_trng *trng = container_of(rng, struct atmel_trng, rng);
+ u32 *data = buf;
+
+ /* data ready? */
+ if (readl(trng->base + TRNG_ODATA) & 1) {
+ *data = readl(trng->base + TRNG_ODATA);
+ return 4;
+ } else
+ return 0;
+}
+
+static int atmel_trng_probe(struct platform_device *pdev)
+{
+ struct atmel_trng *trng;
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+ if (!trng)
+ return -ENOMEM;
+
+ if (!devm_request_mem_region(&pdev->dev, res->start,
+ resource_size(res), pdev->name))
+ return -EBUSY;
+
+ trng->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!trng->base)
+ return -EBUSY;
+
+ trng->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(trng->clk))
+ return PTR_ERR(trng->clk);
+
+ ret = clk_enable(trng->clk);
+ if (ret)
+ goto err_enable;
+
+ writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+ trng->rng.name = pdev->name;
+ trng->rng.read = atmel_trng_read;
+
+ ret = hwrng_register(&trng->rng);
+ if (ret)
+ goto err_register;
+
+ platform_set_drvdata(pdev, trng);
+
+ return 0;
+
+err_register:
+ clk_disable(trng->clk);
+err_enable:
+ clk_put(trng->clk);
+
+ return ret;
+}
+
+static int __devexit atmel_trng_remove(struct platform_device *pdev)
+{
+ struct atmel_trng *trng = platform_get_drvdata(pdev);
+
+ hwrng_unregister(&trng->rng);
+
+ writel(TRNG_KEY, trng->base + TRNG_CR);
+ clk_disable(trng->clk);
+ clk_put(trng->clk);
+
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int atmel_trng_suspend(struct device *dev)
+{
+ struct atmel_trng *trng = dev_get_drvdata(dev);
+
+ clk_disable(trng->clk);
+
+ return 0;
+}
+
+static int atmel_trng_resume(struct device *dev)
+{
+ struct atmel_trng *trng = dev_get_drvdata(dev);
+
+ return clk_enable(trng->clk);
+}
+
+static const struct dev_pm_ops atmel_trng_pm_ops = {
+ .suspend = atmel_trng_suspend,
+ .resume = atmel_trng_resume,
+};
+#endif /* CONFIG_PM */
+
+static struct platform_driver atmel_trng_driver = {
+ .probe = atmel_trng_probe,
+ .remove = __devexit_p(atmel_trng_remove),
+ .driver = {
+ .name = "atmel-trng",
+ .owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &atmel_trng_pm_ops,
+#endif /* CONFIG_PM */
+ },
+};
+
+static int __init atmel_trng_init(void)
+{
+ return platform_driver_register(&atmel_trng_driver);
+}
+module_init(atmel_trng_init);
+
+static void __exit atmel_trng_exit(void)
+{
+ platform_driver_unregister(&atmel_trng_driver);
+}
+module_exit(atmel_trng_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Peter Korsgaard <jacmet@sunsite.dk>");
+MODULE_DESCRIPTION("Atmel true random number generator driver");
--
1.7.6.3
^ permalink raw reply related
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Pavel Machek @ 2011-10-06 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4zjRpEx_yLwXx74uipPN-Q2hun3AdLxKw2EYOy00cDm3Q@mail.gmail.com>
> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> >> From: Barry Song <baohua.song@csr.com>
> >>
> >> Some devices like mmc are async detected very slow. For example,
> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> >> mmc partitions then add disk.
> >>
> >> we do have wait_for_device_probe and scsi_complete_async_scans
> >> before calling swsusp_check, but it is not enough to wait mmc.
> >>
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > I assume that such a device would need "rootwait" to boot in the first
> > place; why don't you "overload" the param to also enable waiting in
> > the resume path?
>
> not real. for an embedded product, the type of the rootfs, the place
> of the rootfs and the way to mount rootfs are pretty flexible.
> even though both rootfs and resume file use mmc, they will be in
> different partitions at least. so i don't think rootwait can overload
> resumewait.
It would be good to at least model it the same way. rootdelay allows
you to specify time, which is important for USB devices...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
From: Paul Walmsley @ 2011-10-06 18:29 UTC (permalink / raw)
To: linux-arm-kernel
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup. To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed. (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)
Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it. This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:
http://www.spinics.net/lists/linux-omap/msg58735.html
Convert this test to a feature test with a chip-by-chip whitelist.
Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause. Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Tested-by: Steve Sakoman <sakoman@gmail.com>
---
This version adds Steve's Tested-by:.
arch/arm/mach-omap2/id.c | 6 +++-
arch/arm/mach-omap2/pm34xx.c | 44 +++++++++++++++++---------------
arch/arm/plat-omap/include/plat/cpu.h | 17 +++++++++---
3 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..707fbb1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -201,8 +201,12 @@ static void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
- if (!cpu_is_omap3505() && !cpu_is_omap3517())
+ if (cpu_is_omap3430() || cpu_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
+ if ((omap_rev() == OMAP3430_REV_ES3_1 ||
+ omap_rev() == OMAP3430_REV_ES3_1_2) ||
+ cpu_is_omap3630())
+ omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..a6156bd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -99,31 +99,28 @@ static void omap3_enable_io_chain(void)
{
int timeout = 0;
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
- OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout > 1000) {
- printk(KERN_ERR "Wake up daisy chain "
- "activation failed.\n");
- return;
- }
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
+ OMAP3430_ST_IO_CHAIN_MASK)) {
+ timeout++;
+ if (timeout > 1000) {
+ printk(KERN_ERR "Wake up daisy chain "
+ "activation failed.\n");
+ return;
}
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
+ WKUP_MOD, PM_WKEN);
}
}
static void omap3_disable_io_chain(void)
{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
}
static void omap3_core_save_context(void)
@@ -376,7 +373,8 @@ void omap_sram_idle(void)
(per_next_state < PWRDM_POWER_ON ||
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_enable_io_chain();
}
/* Block console output in case it is on one of the OMAP UARTs */
@@ -475,7 +473,8 @@ console_still_active:
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- omap3_disable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_disable_io_chain();
}
pwrdm_post_transition();
@@ -870,6 +869,9 @@ static int __init omap3_pm_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ if (!omap3_has_io_chain_ctrl())
+ pr_warning("PM: no software I/O chain control; some wakeups may be lost\n");
+
pm_errata_configure();
/* XXX prcm_setup_regs needs to be before enabling hw
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..3a280aa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -477,6 +477,13 @@ void omap2_check_revision(void);
/*
* Runtime detection of OMAP3 features
+ *
+ * OMAP3_HAS_IO_CHAIN_CTRL: Some later members of the OMAP3 chip
+ * family have OS-level control over the I/O chain clock. This is
+ * to avoid a window during which wakeups could potentially be lost
+ * during powerdomain transitions. If this bit is set, it
+ * indicates that the chip does support OS-level control of this
+ * feature.
*/
extern u32 omap_features;
@@ -488,9 +495,10 @@ extern u32 omap_features;
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUP BIT(6)
#define OMAP3_HAS_SDRC BIT(7)
-#define OMAP4_HAS_MPU_1GHZ BIT(8)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_IO_CHAIN_CTRL BIT(8)
+#define OMAP4_HAS_MPU_1GHZ BIT(9)
+#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
+#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -507,12 +515,11 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL)
/*
* Runtime detection of OMAP4 features
*/
-extern u32 omap_features;
-
#define OMAP4_HAS_FEATURE(feat, flag) \
static inline unsigned int omap4_has_ ##feat(void) \
{ \
--
1.7.6.3
^ permalink raw reply related
* [PATCH] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
From: Paul Walmsley @ 2011-10-06 19:11 UTC (permalink / raw)
To: linux-arm-kernel
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup. To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed. (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)
Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it. This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:
http://www.spinics.net/lists/linux-omap/msg58735.html
Convert this test to a feature test with a chip-by-chip whitelist.
Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
---
arch/arm/mach-omap2/id.c | 6 +++-
arch/arm/mach-omap2/pm34xx.c | 44 +++++++++++++++++---------------
arch/arm/plat-omap/include/plat/cpu.h | 17 +++++++++---
3 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..eb1b8e4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -201,8 +201,12 @@ static void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
- if (!cpu_is_omap3505() && !cpu_is_omap3517())
+ if (cpu_is_omap3430() || cpu_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
+ if ((omap_rev() == OMAP3430_REV_ES3_1 &&
+ omap_rev() == OMAP3430_REV_ES3_1_2) ||
+ cpu_is_omap3630())
+ omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..a6156bd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -99,31 +99,28 @@ static void omap3_enable_io_chain(void)
{
int timeout = 0;
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
- OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout > 1000) {
- printk(KERN_ERR "Wake up daisy chain "
- "activation failed.\n");
- return;
- }
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
+ OMAP3430_ST_IO_CHAIN_MASK)) {
+ timeout++;
+ if (timeout > 1000) {
+ printk(KERN_ERR "Wake up daisy chain "
+ "activation failed.\n");
+ return;
}
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
+ WKUP_MOD, PM_WKEN);
}
}
static void omap3_disable_io_chain(void)
{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
}
static void omap3_core_save_context(void)
@@ -376,7 +373,8 @@ void omap_sram_idle(void)
(per_next_state < PWRDM_POWER_ON ||
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_enable_io_chain();
}
/* Block console output in case it is on one of the OMAP UARTs */
@@ -475,7 +473,8 @@ console_still_active:
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- omap3_disable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_disable_io_chain();
}
pwrdm_post_transition();
@@ -870,6 +869,9 @@ static int __init omap3_pm_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ if (!omap3_has_io_chain_ctrl())
+ pr_warning("PM: no software I/O chain control; some wakeups may be lost\n");
+
pm_errata_configure();
/* XXX prcm_setup_regs needs to be before enabling hw
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..3a280aa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -477,6 +477,13 @@ void omap2_check_revision(void);
/*
* Runtime detection of OMAP3 features
+ *
+ * OMAP3_HAS_IO_CHAIN_CTRL: Some later members of the OMAP3 chip
+ * family have OS-level control over the I/O chain clock. This is
+ * to avoid a window during which wakeups could potentially be lost
+ * during powerdomain transitions. If this bit is set, it
+ * indicates that the chip does support OS-level control of this
+ * feature.
*/
extern u32 omap_features;
@@ -488,9 +495,10 @@ extern u32 omap_features;
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUP BIT(6)
#define OMAP3_HAS_SDRC BIT(7)
-#define OMAP4_HAS_MPU_1GHZ BIT(8)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_IO_CHAIN_CTRL BIT(8)
+#define OMAP4_HAS_MPU_1GHZ BIT(9)
+#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
+#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -507,12 +515,11 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL)
/*
* Runtime detection of OMAP4 features
*/
-extern u32 omap_features;
-
#define OMAP4_HAS_FEATURE(feat, flag) \
static inline unsigned int omap4_has_ ##feat(void) \
{ \
--
1.7.6.3
^ permalink raw reply related
* [PATCH v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
From: Tony Lindgren @ 2011-10-06 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B03B4EC6066@dbde02.ent.ti.com>
* Pedanekar, Hemant <hemantp@ti.com> [111004 02:07]:
> Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM:
>
> > On 10/03/11 18:45, Pedanekar, Hemant wrote:
> >> Hi Igor,
> >>
> >> Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM:
> >>
> >>> Hi Hemant,
> >>>
> >>> On 09/29/11 04:09, Hemant Pedanekar wrote:
> >>>> This patch adds minimal support and build configuration for TI8148 EVM.
> >>>> Also adds support for low level debugging on UART1 console on the EVM.
> >>>>
> >>>> Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with
> >>>> machine info for TI8148 EVM and renamed as board-ti81xxevm.c.
> >>>
> >>> Should we really rename the existing file?
> >>> Shouldn't we just stick to the name of the file submitted first?
> >>> (e.g. board-ti8168evm.c) and just add the support for the new
> >>> TI8148 EVM in to the existing file?
> >>
> >> But won't this be misleading?
> >
> > Misleading? For whom?
> > Actually, I don't really care how you call that file.
> > What I care (and I think not just me) is uniformity, so
> > if we decide to rename all those files that have multiple
> > boards supported in them, I'm fine with it.
> >
> > So pros for my proposed approach would be:
> > 1) Currently, there are already board files with multiple boards
> > supported in them that follow the approach and renaming them is
> > really unnecessary. 2) git log will not break.
> > 3) boards that cannot be named after the convention like 81xx
> > but can be added to the same file will not require further renaming
> > (like 82x8 - I don't really know if that will exist, just wondering).
> > 4) This renaming is really what Linus likes ;)
> >
> > cons:
> > 1) Misleading?
> >
> > Currently, I don't think this renaming is good for anything,
> > especially that majority of the board stuff should be transformed
> > to the DT descriptors.
>
> Igor,
> I agree on the DT part and also understand the "pros" you mentioned.
>
> I can submit the v4 of patches with TI8148 EVM support added in exisitng
> board-ti8168evm.c.
>
> Tony,
> Are you OK with the above approach?
Yes, let's not do renaming unless it's really needed. We'll be getting
rid of the board-*.c files anyways with device tree. So let's consider
the board-*.c files to be in minimal maintenance mode until they will
eventually get removed.
Regards,
Tony
^ permalink raw reply
* [RFC/PATCH 1/7] ARM: ARM11 MPCore: pgd_alloc is not preempt safe
From: George G. Davis @ 2011-10-06 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006163520.GA21464@n2100.arm.linux.org.uk>
On Oct 6, 2011, at 12:35 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 06, 2011 at 01:08:28AM -0400, gdavis at mvista.com wrote:
>> @@ -31,6 +32,9 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
>> if (!new_pgd)
>> goto no_pgd;
>>
>> + if (cache_ops_need_broadcast())
>> + get_cpu();
>
> Is there something wrong with preempt_disable() here and preempt_enable()
> below?
I used the {get,put}_cpu() variants merely to (try to) make it clear that we want
this region to be non-preemptible for the current CPU.
> If it's preempt that we're concerned about, these are the correct
> interfaces to be used.
Since {get,put}_cpu() are wrappers for preempt_{enable,disable}, it works
either way and I'm happy to just use preempt_{enable,disable} instead. It
achieves the same goal with slightly less overhead. Also, while we're on
the subject of preempt_enable, an earlier version of this change used
preempt_enable_no_resched() but I chose to avoid the no_reched flavor
since I felt that it was worth minimizing scheduler latencies.
I'll change all of the {get,put}_cpu() variants to preempt_{enable,disable}
and submit an updated series.
Thanks!
--
Regards,
George
>> +
>> memset(new_pgd, 0, USER_PTRS_PER_PGD * sizeof(pgd_t));
>>
>> /*
>> @@ -42,6 +46,9 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
>>
>> clean_dcache_area(new_pgd, PTRS_PER_PGD * sizeof(pgd_t));
>>
>> + if (cache_ops_need_broadcast())
>> + put_cpu();
>> +
^ permalink raw reply
* [PATCH 0/2] AM3517EVM: Add support for MMC1
From: Tony Lindgren @ 2011-10-06 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1313754751-11752-1-git-send-email-abhilash.kv@ti.com>
* Abhilash K V <abhilash.kv@ti.com> [110819 04:19]:
> This patch-set adds support for MMC1 slot on the
> AM3517 EVM's base-board.
> These patches are dependent on the following patch-set
> http://marc.info/?l=linux-omap&m=131247357813228&w=2
> which gets the AM3517 EVM booting.
>
> The patches are tested on master of tmlind/linux-omap-2.6.git.
> Kernel version is 3.0.0-rc7 and last commit on top of which these patches
> were added is:
>
> 885cf6ff7d3dad4cc44be74b0577d3a554d3ab71: Linux-omap rebuilt:
> Updated to -rc7, added new boards
>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
> Abhilash K V (1):
> AM3517: Support for MMC1
>
> Vaibhav Hiremath (1):
> AM3517EVM: Add support for base-board MMC slot
>
> arch/arm/mach-omap2/board-am3517evm.c | 22 ++++++++++++++++++++++
> arch/arm/mach-omap2/hsmmc.c | 10 +++++++++-
> 2 files changed, 31 insertions(+), 1 deletions(-)
>
Adding these both to board branch thanks.
Tony
^ permalink raw reply
* [RFC/PATCH 6/7] ARM: ARM11 MPCore: DMA_CACHE_RWFO operations are not preempt safe
From: George G. Davis @ 2011-10-06 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006164034.GB21464@n2100.arm.linux.org.uk>
On Oct 6, 2011, at 12:40 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 06, 2011 at 01:08:33AM -0400, gdavis at mvista.com wrote:
>> v6_dma_inv_range:
>> #ifdef CONFIG_DMA_CACHE_RWFO
>> +#ifdef CONFIG_PREEMPT
>> + stmdb sp!, {r4, r10, r11}
>> + get_thread_info r10
>> + ldr r4, [r10, #TI_PREEMPT] @ get preempt count
>> + add r11, r4, #1 @ increment it
>> + str r11, [r10, #TI_PREEMPT] @ disable preempt
>> +#endif
>
> r11 is the frame pointer. On kernels built with the frame pointer
> enabled, this register must either be a valid frame pointer or zero.
Doh!
> There's no reason to use r4, r10 and r11 here - you could use r4, r5
> and ip (r12) - and then there's no need to save ip as that's allowed
> to be corrupted by called functions.
OK, I'll make these changes in the next round.
Thanks again!
--
Regards,
George
^ permalink raw reply
* [PATCH] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
From: Steve Sakoman @ 2011-10-06 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110061310390.4611@utopia.booyaka.com>
On Thu, Oct 6, 2011 at 12:11 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> The way that we detect which OMAP3 chips support I/O wakeup and
> software I/O chain clock control is broken.
>
> Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
> than the AM3505/3517. ?The TI81xx family of SoCs are at present
> considered to be OMAP3 SoCs, but don't support I/O wakeup. ?To resolve
> this, convert the existing blacklist approach to an explicit,
> whitelist support, in which only SoCs which are known to support I/O
> wakeup are listed. ?(At present, this only includes OMAP34xx,
> OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)
>
> Also, the current code incorrectly detects the presence of a
> software-controllable I/O chain clock on several chips that don't
> support it. ?This results in writes to reserved bitfields, unnecessary
> delays, and console messages on kernels running on those chips:
>
> ? ?http://www.spinics.net/lists/linux-omap/msg58735.html
>
> Convert this test to a feature test with a chip-by-chip whitelist.
>
> Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
> and doing some testing to help isolate the cause.
Thanks for doing this patch so quickly!
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Dave Hylands <dhylands@gmail.com>
> Cc: Steve Sakoman <sakoman@gmail.com>
> ---
> ?arch/arm/mach-omap2/id.c ? ? ? ? ? ? ?| ? ?6 +++-
> ?arch/arm/mach-omap2/pm34xx.c ? ? ? ? ?| ? 44 +++++++++++++++++---------------
> ?arch/arm/plat-omap/include/plat/cpu.h | ? 17 +++++++++---
> ?3 files changed, 40 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 37efb86..eb1b8e4 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -201,8 +201,12 @@ static void __init omap3_check_features(void)
> ? ? ? ?OMAP3_CHECK_FEATURE(status, ISP);
> ? ? ? ?if (cpu_is_omap3630())
> ? ? ? ? ? ? ? ?omap_features |= OMAP3_HAS_192MHZ_CLK;
> - ? ? ? if (!cpu_is_omap3505() && !cpu_is_omap3517())
> + ? ? ? if (cpu_is_omap3430() || cpu_is_omap3630())
> ? ? ? ? ? ? ? ?omap_features |= OMAP3_HAS_IO_WAKEUP;
> + ? ? ? if ((omap_rev() == OMAP3430_REV_ES3_1 &&
> + ? ? ? ? ? ?omap_rev() == OMAP3430_REV_ES3_1_2) ||
Perhaps I'm confused but shouldn't it be an || instead of &&?
We're testing for ES3.1 *or* ES3.12?
Otherwise looks good. I'll test on my old Overo COMs.
Steve
> + ? ? ? ? ? cpu_is_omap3630())
> + ? ? ? ? ? ? ? omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
>
> ? ? ? ?omap_features |= OMAP3_HAS_SDRC;
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7255d9b..a6156bd 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -99,31 +99,28 @@ static void omap3_enable_io_chain(void)
> ?{
> ? ? ? ?int timeout = 0;
>
> - ? ? ? if (omap_rev() >= OMAP3430_REV_ES3_1) {
> - ? ? ? ? ? ? ? omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_WKEN);
> - ? ? ? ? ? ? ? /* Do a readback to assure write has been done */
> - ? ? ? ? ? ? ? omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
> -
> - ? ? ? ? ? ? ? while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
> - ? ? ? ? ? ? ? ? ? ? ? ?OMAP3430_ST_IO_CHAIN_MASK)) {
> - ? ? ? ? ? ? ? ? ? ? ? timeout++;
> - ? ? ? ? ? ? ? ? ? ? ? if (timeout > 1000) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? printk(KERN_ERR "Wake up daisy chain "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"activation failed.\n");
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return;
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WKUP_MOD, PM_WKEN);
> + ? ? ? omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_WKEN);
> + ? ? ? /* Do a readback to assure write has been done */
> + ? ? ? omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
> +
> + ? ? ? while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
> + ? ? ? ? ? ? ? ?OMAP3430_ST_IO_CHAIN_MASK)) {
> + ? ? ? ? ? ? ? timeout++;
> + ? ? ? ? ? ? ? if (timeout > 1000) {
> + ? ? ? ? ? ? ? ? ? ? ? printk(KERN_ERR "Wake up daisy chain "
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"activation failed.\n");
> + ? ? ? ? ? ? ? ? ? ? ? return;
> ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ? ? omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WKUP_MOD, PM_WKEN);
> ? ? ? ?}
> ?}
>
> ?static void omap3_disable_io_chain(void)
> ?{
> - ? ? ? if (omap_rev() >= OMAP3430_REV_ES3_1)
> - ? ? ? ? ? ? ? omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_WKEN);
> + ? ? ? omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_WKEN);
> ?}
>
> ?static void omap3_core_save_context(void)
> @@ -376,7 +373,8 @@ void omap_sram_idle(void)
> ? ? ? ? ? ?(per_next_state < PWRDM_POWER_ON ||
> ? ? ? ? ? ? core_next_state < PWRDM_POWER_ON)) {
> ? ? ? ? ? ? ? ?omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
> - ? ? ? ? ? ? ? omap3_enable_io_chain();
> + ? ? ? ? ? ? ? if (omap3_has_io_chain_ctrl())
> + ? ? ? ? ? ? ? ? ? ? ? omap3_enable_io_chain();
> ? ? ? ?}
>
> ? ? ? ?/* Block console output in case it is on one of the OMAP UARTs */
> @@ -475,7 +473,8 @@ console_still_active:
> ? ? ? ? ? ? core_next_state < PWRDM_POWER_ON)) {
> ? ? ? ? ? ? ? ?omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PM_WKEN);
> - ? ? ? ? ? ? ? omap3_disable_io_chain();
> + ? ? ? ? ? ? ? if (omap3_has_io_chain_ctrl())
> + ? ? ? ? ? ? ? ? ? ? ? omap3_disable_io_chain();
> ? ? ? ?}
>
> ? ? ? ?pwrdm_post_transition();
> @@ -870,6 +869,9 @@ static int __init omap3_pm_init(void)
> ? ? ? ?if (!cpu_is_omap34xx())
> ? ? ? ? ? ? ? ?return -ENODEV;
>
> + ? ? ? if (!omap3_has_io_chain_ctrl())
> + ? ? ? ? ? ? ? pr_warning("PM: no software I/O chain control; some wakeups may be lost\n");
> +
> ? ? ? ?pm_errata_configure();
>
> ? ? ? ?/* XXX prcm_setup_regs needs to be before enabling hw
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
> index 67b3d75..3a280aa 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -477,6 +477,13 @@ void omap2_check_revision(void);
>
> ?/*
> ?* Runtime detection of OMAP3 features
> + *
> + * OMAP3_HAS_IO_CHAIN_CTRL: Some later members of the OMAP3 chip
> + * ? ?family have OS-level control over the I/O chain clock. ?This is
> + * ? ?to avoid a window during which wakeups could potentially be lost
> + * ? ?during powerdomain transitions. ?If this bit is set, it
> + * ? ?indicates that the chip does support OS-level control of this
> + * ? ?feature.
> ?*/
> ?extern u32 omap_features;
>
> @@ -488,9 +495,10 @@ extern u32 omap_features;
> ?#define OMAP3_HAS_192MHZ_CLK ? ? ? ? ? BIT(5)
> ?#define OMAP3_HAS_IO_WAKEUP ? ? ? ? ? ?BIT(6)
> ?#define OMAP3_HAS_SDRC ? ? ? ? ? ? ? ? BIT(7)
> -#define OMAP4_HAS_MPU_1GHZ ? ? ? ? ? ? BIT(8)
> -#define OMAP4_HAS_MPU_1_2GHZ ? ? ? ? ? BIT(9)
> -#define OMAP4_HAS_MPU_1_5GHZ ? ? ? ? ? BIT(10)
> +#define OMAP3_HAS_IO_CHAIN_CTRL ? ? ? ? ? ? ? ?BIT(8)
> +#define OMAP4_HAS_MPU_1GHZ ? ? ? ? ? ? BIT(9)
> +#define OMAP4_HAS_MPU_1_2GHZ ? ? ? ? ? BIT(10)
> +#define OMAP4_HAS_MPU_1_5GHZ ? ? ? ? ? BIT(11)
>
>
> ?#define OMAP3_HAS_FEATURE(feat,flag) ? ? ? ? ? ? ? ? ? \
> @@ -507,12 +515,11 @@ OMAP3_HAS_FEATURE(isp, ISP)
> ?OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
> ?OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
> ?OMAP3_HAS_FEATURE(sdrc, SDRC)
> +OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL)
>
> ?/*
> ?* Runtime detection of OMAP4 features
> ?*/
> -extern u32 omap_features;
> -
> ?#define OMAP4_HAS_FEATURE(feat, flag) ? ? ? ? ? ? ? ? ?\
> ?static inline unsigned int omap4_has_ ##feat(void) ? ? \
> ?{ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> --
> 1.7.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only
From: Paul Walmsley @ 2011-10-06 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Based on the documents that I have here, there doesn't appear to be an
equivalent to erratum i443 for OMAP3630, so restrict this one to OMAP34xx
chips.
Also, explicitly restrict this erratum to EMU and HS devices.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
---
Unfortunately, I don't have any HS/EMU devices in my testbed, so it's not
possible for me to test this one on anything but GP chips.
arch/arm/mach-omap2/pm34xx.c | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a6156bd..9e14ae5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -407,13 +407,14 @@ void omap_sram_idle(void)
omap3_intc_prepare_idle();
/*
- * On EMU/HS devices ROM code restores a SRDC value
- * from scratchpad which has automatic self refresh on timeout
- * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443.
- * Hence store/restore the SDRC_POWER register here.
- */
- if (omap_rev() >= OMAP3430_REV_ES3_0 &&
- omap_type() != OMAP2_DEVICE_TYPE_GP &&
+ * On EMU/HS devices ROM code restores a SRDC value
+ * from scratchpad which has automatic self refresh on timeout
+ * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443.
+ * Hence store/restore the SDRC_POWER register here.
+ */
+ if (cpu_is_omap3430() && omap_rev() >= OMAP3430_REV_ES3_0 &&
+ (omap_type() == OMAP2_DEVICE_TYPE_EMU ||
+ omap_type() == OMAP2_DEVICE_TYPE_SEC) &&
core_next_state == PWRDM_POWER_OFF)
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
@@ -430,8 +431,9 @@ void omap_sram_idle(void)
omap34xx_do_sram_idle(save_state);
/* Restore normal SDRC POWER settings */
- if (omap_rev() >= OMAP3430_REV_ES3_0 &&
- omap_type() != OMAP2_DEVICE_TYPE_GP &&
+ if (cpu_is_omap3430() && omap_rev() >= OMAP3430_REV_ES3_0 &&
+ (omap_type() == OMAP2_DEVICE_TYPE_EMU ||
+ omap_type() == OMAP2_DEVICE_TYPE_SEC) &&
core_next_state == PWRDM_POWER_OFF)
sdrc_write_reg(sdrc_pwr, SDRC_POWER);
--
1.7.6.3
^ permalink raw reply related
* [PATCH] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
From: Paul Walmsley @ 2011-10-06 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDS+nno3=sDDwdF6Ew6qG-8mN9bCeawCpho+AJo=jE9QVk0ag@mail.gmail.com>
On Thu, 6 Oct 2011, Steve Sakoman wrote:
> Perhaps I'm confused but shouldn't it be an || instead of &&?
>
> We're testing for ES3.1 *or* ES3.12?
You're correct - thanks for catching this. v2 on its way.
- Paul
^ permalink raw reply
* [PATCH v2] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
From: Paul Walmsley @ 2011-10-06 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDS+nno3=sDDwdF6Ew6qG-8mN9bCeawCpho+AJo=jE9QVk0ag@mail.gmail.com>
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup. To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed. (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)
Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it. This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:
http://www.spinics.net/lists/linux-omap/msg58735.html
Convert this test to a feature test with a chip-by-chip whitelist.
Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause. Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
---
arch/arm/mach-omap2/id.c | 6 +++-
arch/arm/mach-omap2/pm34xx.c | 44 +++++++++++++++++---------------
arch/arm/plat-omap/include/plat/cpu.h | 17 +++++++++---
3 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..707fbb1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -201,8 +201,12 @@ static void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
- if (!cpu_is_omap3505() && !cpu_is_omap3517())
+ if (cpu_is_omap3430() || cpu_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
+ if ((omap_rev() == OMAP3430_REV_ES3_1 ||
+ omap_rev() == OMAP3430_REV_ES3_1_2) ||
+ cpu_is_omap3630())
+ omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..a6156bd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -99,31 +99,28 @@ static void omap3_enable_io_chain(void)
{
int timeout = 0;
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
- OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout > 1000) {
- printk(KERN_ERR "Wake up daisy chain "
- "activation failed.\n");
- return;
- }
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
+ OMAP3430_ST_IO_CHAIN_MASK)) {
+ timeout++;
+ if (timeout > 1000) {
+ printk(KERN_ERR "Wake up daisy chain "
+ "activation failed.\n");
+ return;
}
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
+ WKUP_MOD, PM_WKEN);
}
}
static void omap3_disable_io_chain(void)
{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
}
static void omap3_core_save_context(void)
@@ -376,7 +373,8 @@ void omap_sram_idle(void)
(per_next_state < PWRDM_POWER_ON ||
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_enable_io_chain();
}
/* Block console output in case it is on one of the OMAP UARTs */
@@ -475,7 +473,8 @@ console_still_active:
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- omap3_disable_io_chain();
+ if (omap3_has_io_chain_ctrl())
+ omap3_disable_io_chain();
}
pwrdm_post_transition();
@@ -870,6 +869,9 @@ static int __init omap3_pm_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ if (!omap3_has_io_chain_ctrl())
+ pr_warning("PM: no software I/O chain control; some wakeups may be lost\n");
+
pm_errata_configure();
/* XXX prcm_setup_regs needs to be before enabling hw
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..3a280aa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -477,6 +477,13 @@ void omap2_check_revision(void);
/*
* Runtime detection of OMAP3 features
+ *
+ * OMAP3_HAS_IO_CHAIN_CTRL: Some later members of the OMAP3 chip
+ * family have OS-level control over the I/O chain clock. This is
+ * to avoid a window during which wakeups could potentially be lost
+ * during powerdomain transitions. If this bit is set, it
+ * indicates that the chip does support OS-level control of this
+ * feature.
*/
extern u32 omap_features;
@@ -488,9 +495,10 @@ extern u32 omap_features;
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUP BIT(6)
#define OMAP3_HAS_SDRC BIT(7)
-#define OMAP4_HAS_MPU_1GHZ BIT(8)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_IO_CHAIN_CTRL BIT(8)
+#define OMAP4_HAS_MPU_1GHZ BIT(9)
+#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
+#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -507,12 +515,11 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(io_chain_ctrl, IO_CHAIN_CTRL)
/*
* Runtime detection of OMAP4 features
*/
-extern u32 omap_features;
-
#define OMAP4_HAS_FEATURE(feat, flag) \
static inline unsigned int omap4_has_ ##feat(void) \
{ \
--
1.7.6.3
^ permalink raw reply related
* [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
From: Tony Lindgren @ 2011-10-06 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANfBPZ-AAZx9TxO88EgxCtOUsWrsYzbK+M2d6cVSS7Kf-LwS3w@mail.gmail.com>
* S, Venkatraman <svenkatr@ti.com> [110825 07:23]:
> On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > Hi Venkat,
> >
> > On 8/24/2011 9:46 PM, S, Venkatraman wrote:
> >>
> >> As part of an effort to get single ARM kernel binary [1],
> >> multiple ?definitions of NR_IRQS under various platforms
> >> have to be reconciled and abstracted away from common code.
> >>
> >> This patch series takes the small step of populating the
> >> machine descriptors with the pre-existing nr_irqs field.
> >> Eventually, the common irq handler code will only look at this
> >> field and not the compile time constant.
> >
> > Not related to this patch, but still on that topic. The current NR_IRQS
> > depends as well on board stuff, like for example : the Phoenix
> > IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE.
> > Is there a plan to get rid of this static defines?
> >
>
> Currently, the goal is to get rid of the singleton nature
> of NR_IRQS. Then it just becomes a property of the
> platform, and the arm common code should not see this define.
> This cleanup has to be done across multiple SoCs, not just OMAP.
>
> After I get to complete some meaningful cleanup of NR_IRQS,
> I can look into the static defines that you mention.
I suggest we wait on this patch as the NR_IRQS should be the
board specific true number of interrupts including chained
interrupts from external devices like twl. So just setting
it to NR_IRQS does not help much. Also, the board-*.c files
will be going aways with device tree at some point.
Regards,
Tony
^ permalink raw reply
* [PATCH] OMAP2: Devkit8000: Remove double omap_mux_init_gpio
From: Tony Lindgren @ 2011-10-06 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315321909-5593-1-git-send-email-weber@corscience.de>
* Thomas Weber <weber@corscience.de> [110906 07:38]:
> Remove the init of card detect pin because
> omap_mux_init_gpio() is called during hsmmc initialization
> for the write protect and card detect pin.
Thanks, adding this into fixes-part2 branch.
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: dmtimer: Fix warning
From: Tony Lindgren @ 2011-10-06 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317278657-12414-1-git-send-email-afzal@ti.com>
* Afzal Mohammed <afzal@ti.com> [110928 23:10]:
> Fix,
>
> arch/arm/mach-omap2/timer.c: In function 'omap_timer_init':
> arch/arm/mach-omap2/timer.c:482: warning: assignment from incompatible pointer type
This should already be fixed when I merged together the
dt-base branch.
Regards,
Tony
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> Fix on tony/master
>
> arch/arm/mach-omap2/timer.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 1140e98..e49fc7b 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -434,7 +434,7 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
> int ret = 0;
> char *name = "omap_timer";
> struct dmtimer_platform_data *pdata;
> - struct omap_device *od;
> + struct platform_device *pdev;
> struct omap_timer_capability_dev_attr *timer_dev_attr;
> struct powerdomain *pwrdm;
>
> @@ -476,12 +476,12 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
> #ifdef CONFIG_PM
> pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
> #endif
> - od = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
> + pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
> omap2_dmtimer_latency,
> ARRAY_SIZE(omap2_dmtimer_latency),
> 0);
>
> - if (IS_ERR(od)) {
> + if (IS_ERR(pdev)) {
> pr_err("%s: Can't build omap_device for %s: %s.\n",
> __func__, name, oh->name);
> ret = -EINVAL;
> --
> 1.6.2.4
>
^ permalink raw reply
* [PATCH v2 0/2] arm: omap4: hsmmc: pbias fixes
From: Tony Lindgren @ 2011-10-06 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317644571-25175-1-git-send-email-balajitk@ti.com>
* Balaji T K <balajitk@ti.com> [111003 04:48]:
> MMC1 pbias and speed control fix for SDMMC1 extended I/O cell
> Rebase to git://github.com/tmlind/linux.git fixes
> commit 122a98589349fe3388ffb7b996b54614951c934a
> Author: Tapani Utriainen <tapani@technexion.com>
> Date: Fri Sep 30 11:05:56 2011 -0700
>
> ARM: OMAP: irq: loop counter fix in omap_init_irq()
>
>
> Balaji T K (2):
> arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
> arm: omap4: hsmmc: configure SDMMC1_DR0 properly
Thanks adding both to fixes-part2 branch.
Regards,
Tony
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Tony Lindgren @ 2011-10-06 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E877E29.7000309@gmail.com>
* Rob Herring <robherring2@gmail.com> [111001 13:21]:
> On 09/30/2011 05:29 PM, Kevin Hilman wrote:
> > Hi Arnd,
> >
> > Kevin Hilman <khilman@ti.com> writes:
> >
> >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
> >> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
> >> in the irq/core branch of Thomas' tip tree[3].
> >>
> >> In the past, I noticed you merged external trees like this to solve
> >> dependencies.
> >>
> >> Could you pull the irq/core branch into your tree to meet this
> >> dependency?
> >
> > On second thought, since Santosh's branch is the only one with this
> > dependency (and we also have a dependency on Russell's devel-stable)
> > I'll just build up a branch for Santosh's series that includes
> > rmk/devel-stable and tglx/irq-core.
> >
>
> Any new platforms will have a dependency on rmk/devel-stable with the
> mach header clean-up. I'll probably have a dependency on tglx's tree as
> well.
Sounds like Arnd should pull this into some branch then.
Tony
^ permalink raw reply
* [PATCH 0/2] ARM: OMAP2+: timer fixes / cleanup
From: Tony Lindgren @ 2011-10-06 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317763241-21422-1-git-send-email-b-cousson@ti.com>
* Benoit Cousson <b-cousson@ti.com> [111004 13:46]:
> Hi Tony,
>
> Here is the series to fix the warning and remove the redundant
> latency structure that be removed since the timer runtime PM
> adaptation was just pulled.
>
> I was just able to test that on OMAP4.
>
> Patches are based on Kevin's for_3.2/omap_device-2 branch
> and are available here:
> git://gitorious.org/omap-pm/linux.git for_3.2/timer_fixes
Thanks, applying both into fixes-part2 branch.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] omap: dmtimer: convert printk to pr_err / WARN
From: Tony Lindgren @ 2011-10-06 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317922204-12512-1-git-send-email-vjaquez@igalia.com>
* V?ctor Manuel J?quez Leal <vjaquez@igalia.com> [111006 09:56]:
> Convert a printk(KERN_ERR) message in the driver to pr_err(), and
> use WARN() instead of a custom log message with a stack dump.
>
> Signed-off-by: V?ctor Manuel J?quez Leal <vjaquez@igalia.com>
Looks like this won't apply with the changes we have queued up,
care to refresh this against linux-omap master branch (or dmtimer
branch)?
Regards,
Tony
> ---
> arch/arm/plat-omap/dmtimer.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index ee9f6eb..dead0f3 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -322,7 +322,7 @@ static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
> while (!(omap_dm_timer_read_reg(timer, OMAP_TIMER_SYS_STAT_REG) & 1)) {
> c++;
> if (c > 100000) {
> - printk(KERN_ERR "Timer failed to reset\n");
> + pr_err("Timer failed to reset\n");
> return;
> }
> }
> @@ -397,9 +397,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
> spin_lock_irqsave(&dm_timer_lock, flags);
> if (id <= 0 || id > dm_timer_count || dm_timers[id-1].reserved) {
> spin_unlock_irqrestore(&dm_timer_lock, flags);
> - printk("BUG: warning at %s:%d/%s(): unable to get timer %d\n",
> - __FILE__, __LINE__, __func__, id);
> - dump_stack();
> + WARN(1, "unable to get timer %d\n", id);
> return NULL;
> }
>
> --
> 1.7.6.3
>
^ permalink raw reply
* [PATCHv2] hw_random: add driver for atmel true hardware random number generator
From: Baruch Siach @ 2011-10-06 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317923791-31200-1-git-send-email-jacmet@sunsite.dk>
Hi Peter,
On Thu, Oct 06, 2011 at 07:56:30PM +0200, Peter Korsgaard wrote:
> For the IP block on 9g45/9g46/9m10/9m11.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
[snip]
> +static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
> + bool wait)
> +{
> + struct atmel_trng *trng = container_of(rng, struct atmel_trng, rng);
> + u32 *data = buf;
> +
> + /* data ready? */
> + if (readl(trng->base + TRNG_ODATA) & 1) {
> + *data = readl(trng->base + TRNG_ODATA);
> + return 4;
Shouldn't you check for max >= 4 before writing to *buf?
> + } else
> + return 0;
> +}
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list
From: Paul Walmsley @ 2011-10-06 20:39 UTC (permalink / raw)
To: linux-arm-kernel
Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
remove OMAP_CHIP*") tests the inverse condition of what it should be
testing for the return value from omap_hwmod_register(). This causes
several IP blocks to not be registered on several OMAP3 family devices.
Fixing that bug also unmasked another bug, originally reported by
Chase Maupin <chase.maupin@ti.com> and then subsequently by Abhilash K
V <abhilash.kv@ti.com>, which caused SmartReflex IP blocks to be
registered on SoCs that don't support them.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Chase Maupin <chase.maupin@ti.com>
Cc: Abhilash K V <abhilash.kv@ti.com>
---
This fixes a pretty embarrassing "brown paper bag" bug of mine in one of
the cleanup patches. Tony, it would be good if you could send this to
Arnd ASAP and merge into your cleanup branch. Tested on 3430SDP, 37XX
EVM, and OMAP3503.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..53b6706 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -13,6 +13,8 @@
*
* XXX these should be marked initdata for multi-OMAP kernels
*/
+#include <linux/err.h>
+
#include <plat/omap_hwmod.h>
#include <mach/irqs.h>
#include <plat/cpu.h>
@@ -3161,8 +3163,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
&omap3xxx_i2c3_hwmod,
- &omap34xx_sr1_hwmod,
- &omap34xx_sr2_hwmod,
/* gpio class */
&omap3xxx_gpio1_hwmod,
@@ -3240,7 +3240,7 @@ int __init omap3xxx_hwmod_init(void)
/* Register hwmods common to all OMAP3 */
r = omap_hwmod_register(omap3xxx_hwmods);
- if (!r)
+ if (IS_ERR_VALUE(r))
return r;
rev = omap_rev();
@@ -3265,7 +3265,7 @@ int __init omap3xxx_hwmod_init(void)
};
r = omap_hwmod_register(h);
- if (!r)
+ if (IS_ERR_VALUE(r))
return r;
/*
--
1.7.6.3
^ permalink raw reply related
* [PATCH] ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list
From: Tony Lindgren @ 2011-10-06 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110061433540.4611@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [111006 13:05]:
>
> Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
> remove OMAP_CHIP*") tests the inverse condition of what it should be
> testing for the return value from omap_hwmod_register(). This causes
> several IP blocks to not be registered on several OMAP3 family devices.
>
> Fixing that bug also unmasked another bug, originally reported by
> Chase Maupin <chase.maupin@ti.com> and then subsequently by Abhilash K
> V <abhilash.kv@ti.com>, which caused SmartReflex IP blocks to be
> registered on SoCs that don't support them.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Chase Maupin <chase.maupin@ti.com>
> Cc: Abhilash K V <abhilash.kv@ti.com>
> ---
>
> This fixes a pretty embarrassing "brown paper bag" bug of mine in one of
> the cleanup patches. Tony, it would be good if you could send this to
> Arnd ASAP and merge into your cleanup branch. Tested on 3430SDP, 37XX
> EVM, and OMAP3503.
OK thanks, applying into fixes-part2 branch.
Regards,
Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox