[PATCH] ARM: ensure all sched_clock() implementations are notrace marked
ftrace requires sched_clock() to be notrace. Ensure that all
implementations are so marked.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-ixp4xx/common.c |2 +-
arch/arm/mach-mmp/time.c |2 +-
arch/arm/mach-pxa/time.c |2 +-
arch/arm/mach-sa1100/generic.c|2 +-
arch/arm/mach-tegra/timer.c |2 +-
arch/arm/plat-iop/time.c |2 +-
arch/arm/plat-omap/counter_32k.c |2 +-
arch/arm/plat-orion/time.c|2 +-
arch/arm/plat-versatile/sched-clock.c |2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 82fc003..e0b91d8 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -424,7 +424,7 @@ static void __init ixp4xx_clocksource_init(void)
/*
* sched_clock()
*/
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
cycle_t cyc = ixp4xx_get_cycles(NULL);
struct clocksource *cs = clocksource_ixp4xx;
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 0c0ab09..a2ea33d 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -75,7 +75,7 @@ static inline uint32_t timer_read(void)
return __raw_readl(TIMERS_VIRT_BASE + TMR_CVWR(0));
}
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
unsigned long long v = cnt32_to_63(timer_read());
return (v * tcr2ns_scale) TCR2NS_SCALE_FACTOR;
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index caf92c0..b8d9dff 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -51,7 +51,7 @@ static void __init set_oscr2ns_scale(unsigned long oscr_rate)
oscr2ns_scale++;
}
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
unsigned long long v = cnt32_to_63(OSCR);
return (v * oscr2ns_scale) OSCR2NS_SCALE_FACTOR;
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 3c1fcd6..33b4969 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -119,7 +119,7 @@ unsigned int sa11x0_getspeed(unsigned int cpu)
*
* ( * 1E9 / 3686400 = * 78125 / 288)
*/
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
unsigned long long v = cnt32_to_63(OSCR);
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index b49f2f5..19a6f7e 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -110,7 +110,7 @@ static struct clocksource tegra_clocksource = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
return cnt32_to_63(timer_readl(TIMERUS_CNTR_1US)) * 1000;
}
diff --git a/arch/arm/plat-iop/time.c b/arch/arm/plat-iop/time.c
index cd6d54f..2bb7db4 100644
--- a/arch/arm/plat-iop/time.c
+++ b/arch/arm/plat-iop/time.c
@@ -52,7 +52,7 @@ static struct clocksource iop_clocksource = {
/*
* IOP sched_clock() implementation via its clocksource.
*/
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
cycle_t cyc = iop_clocksource_read(NULL);
struct clocksource *cs = iop_clocksource;
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 8f149f5..0de0583 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -109,7 +109,7 @@ static struct clocksource clocksource_32k = {
* Returns current time from boot in nsecs. It's OK for this to wrap
* around for now, as it's just a relative time stamp.
*/
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
return clocksource_cyc2ns(clocksource_32k.read(clocksource_32k),
clocksource_32k.mult, clocksource_32k.shift);
diff --git a/arch/arm/plat-orion/time.c b/arch/arm/plat-orion/time.c
index 11e2583..123f96f 100644
--- a/arch/arm/plat-orion/time.c
+++ b/arch/arm/plat-orion/time.c
@@ -55,7 +55,7 @@ static u32 ticks_per_jiffy;
static unsigned long tclk2ns_scale;
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
unsigned long long v = cnt32_to_63(0x - readl(TIMER0_VAL));
return (v * tclk2ns_scale) TCLK2NS_SCALE_FACTOR;
diff --git a/arch/arm/plat-versatile/sched-clock.c
b/arch/arm/plat-versatile/sched-clock.c
index 9696ddc..42efd14 100644
--- a/arch/arm/plat-versatile/sched-clock.c
+++ b/arch/arm/plat-versatile/sched-clock.c
@@ -42,7 +42,7 @@
* long as there is always less than 89 seconds between successive
* calls to this function.
*/
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
{
unsigned long long v = cnt32_to_63(readl(REFCOUNTER));
--
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
On Thu, Dec 16, 2010 at 12:17, Omar Ramirez Luna omar.rami...@ti.com wrote:
Use runtime pm APIs to enable/disable mailbox clocks and
to configure SYSC register.
Based on the patch sent by Felipe Contreras:
https://patchwork.kernel.org/patch/101662/
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 27 +--
1 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..f5f72ba 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -14,6 +14,7 @@
#include linux/err.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/pm_runtime.h
#include plat/mailbox.h
#include mach/irqs.h
@@ -34,12 +35,8 @@
#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
/* SYSCONFIG: register bit definition */
-#define AUTOIDLE (1 0)
#define SOFTRESET (1 1)
-#define SMARTIDLE (2 3)
#define OMAP4_SOFTRESET (1 0)
-#define OMAP4_NOIDLE (1 2)
-#define OMAP4_SMARTIDLE (2 2)
/* SYSSTATUS: register bit definition */
#define RESETDONE (1 0)
Is this still required?
@@ -70,8 +67,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] OMAP: mailbox: build device using omap_device/omap_hwmod
couple of comments.
On Thu, Dec 16, 2010 at 12:17, Omar Ramirez Luna omar.rami...@ti.com wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Remove static platform_device and resource data within
omap mailbox driver; use the one defined in the hwmod
database along with omap_device framework for device
build and registration.
Add device latency functions to be used, so clock can be
enabled and sysconfig is configured.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c | 102
-
1 files changed, 20 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b5cafd3..7493c30 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -142,95 +142,33 @@ static inline void omap_init_camera(void)
#endif
snip
+
+ oh = omap_hwmod_lookup(mailbox);
+ if (!oh) {
+ pr_err(%s: unable to find hwmod\n, __func__);
+ return;
+ }
+
+ od = omap_device_build(omap-mailbox, -1, oh,
+ NULL, 0,
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
+ 0);
+ if (!od) {
Check for IS_ERR(od).
+ pr_err(%s: could not build device\n, __func__);
return;
This return can be removed.
}
- platform_device_register(mbox_device);
}
#else
static inline void omap_init_mbox(void) { }
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] OMAP: mailbox: build device using omap_device/omap_hwmod
On Thu, Dec 16, 2010 at 02:08:11PM +0530, Varadarajan, Charulatha wrote:
+ oh = omap_hwmod_lookup(mailbox);
+ if (!oh) {
+ pr_err(%s: unable to find hwmod\n, __func__);
+ return;
+ }
+
+ od = omap_device_build(omap-mailbox, -1, oh,
+ NULL, 0,
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
+ 0);
+ if (!od) {
Check for IS_ERR(od).
+ pr_err(%s: could not build device\n, __func__);
If you have an API which returns errors, and you're bothering to print
something when an error occurs, it's often useful to print the returned
error code, so that people can find out _why_ the error occurred.
--
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: twl4030_usb porting advice
On Wed, Dec 15, 2010 at 01:09:42PM +, Tomasz Mloduchowski wrote:
On 12/15/10 12:39, Felipe Balbi wrote:
On Wed, Dec 15, 2010 at 12:27:10PM +, Tomasz Mloduchowski wrote:
I would gladly welcome any pointers that could help me solve this
issue.
you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP
can't handle port handoff to companion OHCI controller, then it fails
not being able to enumerate the device. Try remuxing your port to OHCI
controller and disabling EHCI from Kconfig.
It actually is a HS device (it's a 4-port hub) - when booting the
vendor supplied kernel (based off 2.6.32, i.e. pre -IR redesign), the
device identifies as follows:
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
with the following boot messages:
usb 1-2: new high speed USB device using ehci-omap and address 2
usb 1-2: New USB device found, idVendor=05e3, idProduct=0608
usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-2: Product: USB2.0 Hub
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
I've pasted the boot log for my kernel:
http://pastie.org/1379102
And the boot log for the original kernel:
http://pastie.org/1379100
It could be a bug on the reset sequence on ehci-omap.c, do you have
anything connected to any of the hub ports ?
Please enable CONFIG_USB_DEBUG on your kernel config and grab a bit more
information.
Also, boot the machine without the device attached and after booting
run:
# dmesg -c
then attach the device, then grab the output of dmesg.
I don't have the ability to disconnect the hub - it's integrated on
the board :(
I see.
I've also made a mistake describing the pastebins - the working, PSP
kernel boot log is here:
http://pastie.org/1379102
while the non-working git kernel messages are here (with CONFIG_USB_DEBUG):
http://pastie.org/1379100
I'm quoting a snippet below for commenting.
[1.639892] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.646759] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
[1.646881] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
This is alarming. Please add this patch to get the error code:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 116ae28..5da3fa3 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -682,7 +682,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
if (IS_ERR(omap-regulator[i])) {
omap-regulator[i] = NULL;
dev_dbg(pdev-dev,
- failed to get ehci port%d regulator\n, i);
+ failed to get ehci port%d regulator -- %d\n, i,
+ PTR_ERR(omap-regulator[i]));
} else {
regulator_enable(omap-regulator[i]);
}
[1.646911] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
[1.647064] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x10
[1.647094] ehci-omap ehci-omap.0: TLL RESET DONE
[1.647094] ehci-omap ehci-omap.0: OMAP3 ES version ES2.1
[1.647125] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=21c
[2.649841] ehci-omap ehci-omap.0: phy reset operation timed out
This is also alarming... Let's increase the timeout just for a debugging
purpose:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 116ae28..fa8bff0 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -239,7 +239,7 @@ static void omap_usb_utmi_init(struct ehci_hcd_omap *omap,
u8 tll_channel_mask)
static void omap_ehci_soft_phy_reset(struct ehci_hcd_omap *omap, u8 port)
{
- unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ unsigned long timeout = jiffies + msecs_to_jiffies(1);
unsigned reg = 0;
reg = ULPI_FUNC_CTRL_RESET
beware, this might slow your boot time quite a lot :-p
The rest is just continuing the enumeration and there's not much
interesting there besides the unable to enumerate message, which could
be caused by the two problems above.
--
balbi
--
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 01/13] ARM: sched_clock: provide common infrastructure for sched_clock()
Provide common sched_clock() infrastructure for platforms to use to
create a 64-bit ns based sched_clock() implementation from a counter
running at a non-variable clock rate.
This implementation is based upon maintaining an epoch for the counter
and an epoch for the nanosecond time. When we desire a sched_clock()
time, we calculate the number of counter ticks since the last epoch
update, convert this to nanoseconds and add to the epoch nanoseconds.
We regularly refresh these epochs within the counter wrap interval.
We perform a similar calculation as above, and store the new epochs.
We read and write the epochs in such a way that sched_clock() can easily
(and locklessly) detect when an update is in progress, and repeat the
loading of these constants when they're known not to be stable. The
one caveat is that sched_clock() is not called in the middle of an
update.
Finally, if the clock rate is known at compile time, the counter to ns
conversion factors can be specified, allowing sched_clock() to be tightly
optimized. We ensure that these factors are correct by providing an
initialization function which performs a run-time check.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/Kconfig |3 +
arch/arm/include/asm/sched_clock.h | 116
arch/arm/kernel/Makefile |1 +
arch/arm/kernel/sched_clock.c | 69 +
4 files changed, 189 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/sched_clock.h
create mode 100644 arch/arm/kernel/sched_clock.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49778bb..ed7a0a7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -38,6 +38,9 @@ config HAVE_PWM
config SYS_SUPPORTS_APM_EMULATION
bool
+config HAVE_SCHED_CLOCK
+ bool
+
config GENERIC_GPIO
bool
diff --git a/arch/arm/include/asm/sched_clock.h
b/arch/arm/include/asm/sched_clock.h
new file mode 100644
index 000..f4480aa
--- /dev/null
+++ b/arch/arm/include/asm/sched_clock.h
@@ -0,0 +1,116 @@
+/*
+ * sched_clock.h: support for extending counters to full 64-bit ns counter
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef ASM_SCHED_CLOCK
+#define ASM_SCHED_CLOCK
+
+#include linux/kernel.h
+#include linux/types.h
+
+struct clock_data {
+ u64 epoch_ns;
+ u32 epoch_cyc;
+ u32 epoch_cyc_copy;
+ u32 mult;
+ u32 shift;
+};
+
+#define DEFINE_CLOCK_DATA(name)struct clock_data name
+
+static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
+{
+ return (cyc * mult) shift;
+}
+
+/*
+ * Atomically update the sched_clock epoch.
+ */
+static inline void update_sched_clock(struct clock_data *cd, u32 cyc, u32 mask)
+{
+ u64 ns = cd-epoch_ns +
+ cyc_to_ns((cyc - cd-epoch_cyc) mask, cd-mult, cd-shift);
+
+ /*
+* Write epoch_cyc and epoch_ns in a way that the update is
+* detectable in cyc_to_fixed_sched_clock().
+*/
+ cd-epoch_cyc = cyc;
+ smp_wmb();
+ cd-epoch_ns = ns;
+ smp_wmb();
+ cd-epoch_cyc_copy = cyc;
+}
+
+/*
+ * If your clock rate is known at compile time, using this will allow
+ * you to optimize the mult/shift loads away. Use init_fixed_sched_clock()
+ * with this to ensure that your mult/shift are correct.
+ *
+ * NB: you must provide locking around this function, which must include
+ * reading the cycle counter.
+ */
+static inline unsigned long long cyc_to_fixed_sched_clock(struct clock_data
*cd,
+ u32 cyc, u32 mask, u32 mult, u32 shift)
+{
+ u64 epoch_ns;
+ u32 epoch_cyc;
+
+ /*
+* Load the epoch_cyc and epoch_ns atomically. We do this by
+* ensuring that we always write epoch_cyc, epoch_ns and
+* epoch_cyc_copy in strict order, and read them in strict order.
+* If epoch_cyc and epoch_cyc_copy are not equal, then we're in
+* the middle of an update, and we should repeat the load.
+*/
+ do {
+ epoch_cyc = cd-epoch_cyc;
+ smp_rmb();
+ epoch_ns = cd-epoch_ns;
+ smp_rmb();
+ } while (epoch_cyc != cd-epoch_cyc_copy);
+
+ return epoch_ns + cyc_to_ns((cyc - epoch_cyc) mask, mult, shift);
+}
+
+/*
+ * Otherwise, you need to use this, which will obtain the mult/shift
+ * from the clock_data structure. Use init_sched_clock() with this.
+ *
+ * NB: you must provide locking around this function, which must include
+ * reading the cycle counter.
+ */
+static inline unsigned long long cyc_to_sched_clock(struct clock_data *cd,
+ u32 cyc, u32 mask)
+{
+ return cyc_to_fixed_sched_clock(cd, cyc, mask, cd-mult, cd-shift);
+}
+
+/*
+ * Initialize the clock data - calculate the appropriate multiplier
+ * and shift. Also
[PATCH 10/13] ARM: omap: convert sched_clock() to use new infrastructure
Convert omap to use the new sched_clock() infrastructure for extending
32bit counters to full 64-bit nanoseconds.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/Kconfig |1 +
arch/arm/plat-omap/counter_32k.c | 24 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 58e2fe3..726279f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -839,6 +839,7 @@ config ARCH_OMAP
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
select GENERIC_CLOCKEVENTS
+ select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
help
Support for TI's OMAP platform (OMAP1/2/3/4).
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 0de0583..65bde61 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -17,6 +17,8 @@
#include linux/clk.h
#include linux/io.h
+#include asm/sched_clock.h
+
#include plat/common.h
#include plat/board.h
@@ -109,10 +111,25 @@ static struct clocksource clocksource_32k = {
* Returns current time from boot in nsecs. It's OK for this to wrap
* around for now, as it's just a relative time stamp.
*/
+static DEFINE_CLOCK_DATA(cd);
+
+/*
+ * Constants generated by clocks_calc_mult_shift(m, s, 32768, NSEC_PER_SEC,
60).
+ * This gives a resolution of about 30us and a wrap period of about 36hrs.
+ */
+#define SC_MULT40u
+#define SC_SHIFT 17
+
unsigned long long notrace sched_clock(void)
{
- return clocksource_cyc2ns(clocksource_32k.read(clocksource_32k),
- clocksource_32k.mult, clocksource_32k.shift);
+ u32 cyc = clocksource_32k.read(clocksource_32k);
+ return cyc_to_fixed_sched_clock(cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
+}
+
+static void notrace omap_update_sched_clock(void)
+{
+ u32 cyc = clocksource_32k.read(clocksource_32k);
+ update_sched_clock(cd, cyc, (u32)~0);
}
/**
@@ -170,6 +187,9 @@ static int __init omap_init_clocksource_32k(void)
if (clocksource_register_hz(clocksource_32k, 32768))
printk(err, clocksource_32k.name);
+
+ init_fixed_sched_clock(cd, omap_update_sched_clock, 32,
+ 32768, SC_MULT, SC_SHIFT);
}
return 0;
}
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
Hello Gowda, Hello Kevin, On Mon, 22 Nov 2010 11:26:25 +0100 ext-madhusudhan.1.go...@nokia.com wrote: I did verify Thomas Petazzoni's patch - [PATCH] omap: prcm: switch to a chained IRQ handler mechanism, and I have below questions or comments. 1. I see for each WKUP_ST or IO_ST interrupt the _prcm_int_handle_wakeup handler is getting called 2 times which impacts on performance. printk(irq:%d,%d\n,irq,c); just before returning from the handler shows. [ 221.966308] irq wkst:377,2 [ 221.968597] irq wkst:377,0 I see, the code checking the below warning is removed, won't it be good to retain this check ? WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup but no wakeup sources are marked\n); Also need to address the corner case issue, for which I submitted the patch fix. [ 222.002563] irq wkst:368,3 [ 222.004913] irq iost:377,0 I am not sure to fully understand what's going on with thse WKUP_ST and IO_ST interrupts. Here is what I see : * When going to retention (i.e after echo 0 /debug/pm_debug/enable_off_mode), what happens is - PRCM main interrupt handler is called, it sees pending events at 0x201 (which means WKUP_ST and IO_ST) - it calls the interrupt handler for WKUP_ST, which happens to be _prcm_int_handle_wakeup, which says that c is 2. - it acks the WKUP_ST interrupt by clearing the bit in the PRCM status register - it calls the interrupt handler for IO_ST, which happens to also be _prcm_int_handle_wakeup, which says that c is 0 - it acks the IO_ST interrupt by clearing the corresponding bit in the PRCM status register - the PRCM main interrupt handler checks again the PRCM status register, and sees pending events to be 0x1 (which means WKUP_ST) - it calls again the WKUP_ST interrupt handler, which is _prcm_int_handle_wakeup, which says that c is 0 - it acks the WKUP_ST interrupt by clearing the bit in the PRCM status register - the PRCM main interrupt handler checks again the PRCM status register, and sees pending events to be 0x0, and returns. * When going to off (i.e after echo 1 /debug/pm_debug/enable_off_mode), what happens is : - PRCM main interrupt handler is called, it sees pending events at 0x200 (which means IO_ST) - it calls the interrupt handler for IO_ST, which happens to also be _prcm_int_handle_wakeup, which says that c is 1 - it acks the IO_ST interrupt by clearing the corresponding bit in the PRCM status register - the PRCM main interrupt handler checks again the PRCM status register, and sees pending events to be 0x200 (which means IO_ST) - it calls the interrupt handler for IO_ST, which happens to also be _prcm_int_handle_wakeup, which says that c is 0 - it acks the IO_ST interrupt by clearing the corresponding bit in the PRCM status register - the PRCM main interrupt handler checks again the PRCM status register, and sees pending events to be 0x0, and returns. See the end of my e-mail for a trace. This raises a few questions : * Why is the set of PRCM events different in the OFF and the retention case ? * Why do we need to ack the WKUP_ST event (in the first case) and the IO_ST event (in the second case) twice ? * The _prcm_int_handle_wakeup() was written to be called *once* for a given PRCM interrupt with IO_WT or WKUP_ST enabled. Now, it gets called twice since they are separate interrupt handlers for those two events. Is this a problem ? Should we rewrite _prcm_int_handle_wakeup() in two separate functions, one taking into account the IO_ST event and the other one taking into account the WKUP_ST event ? Thanks for your input, Thomas / # echo 0 /debug/pm_debug/enable_off_mode / # echo mem /sys/power/state [ 507.936614] PM: Syncing filesystems ... done. [ 507.951629] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 507.976470] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 508.009368] Suspending console(s) (use no_console_suspend to debug) [ 508.140106] PM: suspend of devices complete after 119.263 msecs [ 508.143951] omap_device: omap_i2c.1: new worst case deactivate latency 0: 183105 [ 508.144195] PM: late suspend of devices complete after 4.089 msecs [ 508.144287] Disabling non-boot CPUs ... [ 508.144927] omap_device: omap_uart.2: new worst case deactivate latency 0: 30517 [ 508.508300] omap_device: omap_uart.0: new worst case activate latency 0: 61035 [ 508.508453] Successfully put all powerdomains to target state [ 508.508636] prcm_irq_handler pending=0x201 [ 508.508666] calling irq 368 [ 508.508666] prcm_irq_mask 368 [ 508.508697] prcm_irq_ack 368 [ 508.508728] _prcm_int_handle_wakeup 368 : 2 [ 508.508728] prcm_irq_unmask 368 [ 508.508758] calling irq 377 [ 508.508758] prcm_irq_mask 377 [ 508.508789] prcm_irq_ack 377 [ 508.508819]
RE: [PATCH v6 0/12] dmtimer adaptation to platform_driver
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Wednesday, December 15, 2010 9:35 AM
To: linux-omap@vger.kernel.org
Cc: DebBarma, Tarun Kanti
Subject: [PATCH v6 0/12] dmtimer adaptation to platform_driver
dmtimer adaptation to platform_driver.
This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.
Tested on following platforms:
OMAP4430, OMAP3430, OMAP3630, OMAP2430
OMAP2420, OMAP1710(in-progress)
While validating on OMAP1710 I discovered that probe() is not triggered.
I will fix this problem in the next series.
--
Tarun
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
v6:
(1) Removed reset functions to mach-omap1/dmtimer.c.
Access to reset function from plat-omap/dmtimer.c is provided by means
of function pointer.
(2) Remove multiple calls to omap_device_build() for registering timer
devices
during early and regular initialization. Regular device registration is
now done
by reading data from temporary list. This list is populated during early
init
where timer data is read from hwmod database and corresponding memory
allocated.
(3) kfree(pdata) under error condition since platform_device_unregister
does
not free its pdata.
(4) Removed extra header inclusion in mach-omap2 and plat-omap
NOTE: omap_dm_timer.id field could not be removed because during regular
boot
there is no mechanism to match the current pdev with corresponding entry
in the
timer list which was partially initialized during early boot.
TODO:
(1) OFF Mode support
(2) Upgrade timeout implementation in low-level read/write access to
return
error condition to EXPORT APIs. This is re-frained in the present
implementation
because that would involve change to EXPORTED APIs. Besides, there is no
clear
design as yet which is agreed upon by the community.
v4:
(1) clock aliases are renamed as 32k_ck, sys_ck and alt_ck
(2) incorporate missing clk_put() for corresponding clk_get()
(3) modified clk_get()/clk_put() to be called once once in platform
driver.
(4) consistent header for new files
(5) check return value of omap_hwmod_for_each_by_class() in device init
routines.
(6) remove is_abe_timer field in dmtimer_platform_data structure. this is
no longer needed with new input clock source aliasing.
(7) proper splitting of patch series
(8) remove register map from hwmod database.
(9) remove clock source strings array from hwmod database and associated
structure declaration from plat/dmtimer.h. this is no longer needed.
(10) remove dev_attr from hwmod database. this is no longer needed.
(11) use register offsets to identify OMAP 4 registers instead of register
map.
(12) remove clock source name strings from hwmod database.
(13) introduce new mechanism for getting struct clk associated with clock
source
names. this is achieved by adding clock alisases for all supported clock
sources.
(14) remove clock setup functions in mach-omap2 for populating struct clk
associated with all input clock sources because this is no longer needed
with
above implementation.
(15) device names changed from dmtimer to omap-timer
(16) device index starts from 1 instead of 0
(17) remove .init_name from hwmod database. this is not needed.
(18) introduce separate functions for reading/writing interrupt registers
instead of
doing all operations within a single function.
v3:
(1) multi-line comment error correction
(2) provision to allow any of the available dmtimers as early timers
instead of restricting them to millisecond timers only.
(3) in 'struct omap_dmtimer{}' is_initialized flag is redundant and
so must be removed. if the element is found in the list it is already
initialized.
(4) remove 'found' flag in omap_dm_timer_request() and
omap_dm_timer_request_specific() functions.
this is not needed with alternate implementation.
(5) use .init_name to initialize device names so that it can be identified
during early boot as well. This is to avoid duplicate functions for clock
manipulations during early boot and later.
(6) remove redundant functions from mach-omap2 which are created just to
call pm functions like: pm_runtime_get_sync(),pm_runtime_put_sync(),..
and instead call them directly from plat-omap function api's.
(7) timer clock source names made part of hwmod database. source_clock[]
of type 'struct clk' is made part of platform data.
(8) clockactivity field initialized in hwmod database to preserve fclk
during idle. code which manipulate OCP config removed since they are
already taken care by hwmod framework.
(9) omap2_dm_timer_set_src() is optimized. Clock enable/disbale routines
moved to plat-omap layer and simplfied to the level so as not to sacrifice
intended functionality.
NOTE: During early boot clock management was requested to be placed upon
client drivers responsibility. this has not been done keeping in mind
that it would entail (i)
Re: [PATCH 0/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion
Hi Kevin, On Wed, Dec 15, 2010 at 9:42 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Govindraj.R govindraj.r...@ti.com writes: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 1) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 2) Runtime Conversion of McSPI driver Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 Can you summarize what this test does? On what platforms was this tested? How was it tested for OMAP1 and OMAP2? Using the above mentioned test module we had done some data transfer tests. Platforms used where : 1) OMAP2430 SDP. 2) OMAP3 (ZOOM boards zoom2/3). 3) OMAP4430 SDP [ Here even basic Ethernet functionality was checked which is over SPI interface] We boot tested on 2420/n800. Coming to omap1, This driver[omap2_mcspi.c] is applicable only from omap2_plus for omap1 omap_uwire.c is the spi driver file. Looking into the driver/spi/Kconfig and Makefile: KCONFIG SNIP config SPI_OMAP_UWIRE tristate OMAP1 MicroWire depends on ARCH_OMAP1 config SPI_OMAP24XX tristate McSPI driver for OMAP depends on ARCH_OMAP2PLUS MAKEFILE SNIP obj-$(CONFIG_SPI_OMAP_UWIRE)+= omap_uwire.o obj-$(CONFIG_SPI_OMAP24XX) += omap2_mcspi.o --- Thanks, Govindraj.R Kevin System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Benoit Cousson (1): OMAP4: hwmod data: Add McSPI Charulatha V (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP3: clocks: Update clock domain name for mcspi fck OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (1): OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/clock3xxx_data.c | 4 + arch/arm/mach-omap2/devices.c | 189 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ arch/arm/plat-omap/include/plat/mcspi.h | 11 + drivers/spi/omap2_mcspi.c | 225 +++--- 8 files changed, 1051 insertions(+), 300 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 -- 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
[PATCH v2 2/5] OMAP4: PM: Do not assume clkdm supports hw transitions
omap_set_pwrdm_state today assumes a clkdm supports hw_auto
transitions and hence leaves some which do not support this
in sw wkup state preventing low power transitions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
Changes in v2:
Rebased the patch on the previous patch in the series
The below branch is updated with this version of the patch
git://gitorious.org/omap-pm/linux.git for_2.6.38/power
arch/arm/mach-omap2/pm.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: linux/arch/arm/mach-omap2/pm.c
===
--- linux.orig/arch/arm/mach-omap2/pm.c 2010-12-16 11:47:35.0 +0530
+++ linux/arch/arm/mach-omap2/pm.c 2010-12-16 11:48:49.073228787 +0530
@@ -95,8 +95,7 @@
/*
* This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported. Function is assuming that clkdm doesn't have
- * hw_sup mode enabled.
+ * RET are supported.
*/
int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
{
@@ -137,7 +136,10 @@
switch (sleep_switch) {
case FORCEWAKEUP_SWITCH:
- omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+ if (pwrdm-pwrdm_clkdms[0]-flags CLKDM_CAN_ENABLE_AUTO)
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+ else
+ omap2_clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
break;
case LOWPOWERSTATE_SWITCH:
pwrdm_set_lowpwrstchange(pwrdm);
--
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 v2 1/5] OMAP4: PM: Use the low-power state change feature on OMAP4
For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking
up the domain to put it back to deeper sleep state.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
Changes in v2:
Changed implementation for better readability and code
reuse as suggested here
http://marc.info/?l=linux-omapm=129245686306262w=2
The below branch is updated with this version of the patch
git://gitorious.org/omap-pm/linux.git for_2.6.38/power
arch/arm/mach-omap2/pm.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
Index: linux/arch/arm/mach-omap2/pm.c
===
--- linux.orig/arch/arm/mach-omap2/pm.c 2010-12-15 17:29:42.361228780 +0530
+++ linux/arch/arm/mach-omap2/pm.c 2010-12-15 20:19:48.321228780 +0530
@@ -89,6 +89,10 @@
}
}
+/* Types of sleep_switch used in omap_set_pwrdm_state */
+#define FORCEWAKEUP_SWITCH 0
+#define LOWPOWERSTATE_SWITCH 1
+
/*
* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported. Function is assuming that clkdm doesn't have
@@ -114,9 +118,14 @@
return ret;
if (pwrdm_read_pwrst(pwrdm) PWRDM_POWER_ON) {
- omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = 1;
- pwrdm_wait_transition(pwrdm);
+ if ((pwrdm_read_pwrst(pwrdm) state)
+ (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
+ sleep_switch = LOWPOWERSTATE_SWITCH;
+ } else {
+ omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
+ pwrdm_wait_transition(pwrdm);
+ sleep_switch = FORCEWAKEUP_SWITCH;
+ }
}
ret = pwrdm_set_next_pwrst(pwrdm, state);
@@ -126,12 +135,19 @@
goto err;
}
- if (sleep_switch) {
+ switch (sleep_switch) {
+ case FORCEWAKEUP_SWITCH:
omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
+ break;
+ case LOWPOWERSTATE_SWITCH:
+ pwrdm_set_lowpwrstchange(pwrdm);
+ break;
+ default:
+ return ret;
}
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
err:
return ret;
}
--
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/13] ARM: sched_clock: provide common infrastructure for sched_clock()
On Thu, Dec 16, 2010 at 09:27:47AM +, Russell King - ARM Linux wrote:
Provide common sched_clock() infrastructure for platforms to use to
create a 64-bit ns based sched_clock() implementation from a counter
running at a non-variable clock rate.
Some of the comments in the patch were only relevant to a previous
version. He's an updated version with proper comments to avoid
confusion.
arch/arm/Kconfig |3 +
arch/arm/include/asm/sched_clock.h | 115
arch/arm/kernel/Makefile |1 +
arch/arm/kernel/sched_clock.c | 69 +
4 files changed, 188 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49778bb..ed7a0a7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -38,6 +38,9 @@ config HAVE_PWM
config SYS_SUPPORTS_APM_EMULATION
bool
+config HAVE_SCHED_CLOCK
+ bool
+
config GENERIC_GPIO
bool
diff --git a/arch/arm/include/asm/sched_clock.h
b/arch/arm/include/asm/sched_clock.h
new file mode 100644
index 000..82d4d3f
--- /dev/null
+++ b/arch/arm/include/asm/sched_clock.h
@@ -0,0 +1,115 @@
+/*
+ * sched_clock.h: support for extending counters to full 64-bit ns counter
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef ASM_SCHED_CLOCK
+#define ASM_SCHED_CLOCK
+
+#include linux/kernel.h
+#include linux/types.h
+
+struct clock_data {
+ u64 epoch_ns;
+ u32 epoch_cyc;
+ u32 epoch_cyc_copy;
+ u32 mult;
+ u32 shift;
+};
+
+#define DEFINE_CLOCK_DATA(name)struct clock_data name
+
+static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
+{
+ return (cyc * mult) shift;
+}
+
+/*
+ * Atomically update the sched_clock epoch. Your update callback will
+ * be called from a timer before the counter wraps - read the current
+ * counter value, and call this function to safely move the epochs
+ * forward.
+ */
+static inline void update_sched_clock(struct clock_data *cd, u32 cyc, u32 mask)
+{
+ u64 ns = cd-epoch_ns +
+ cyc_to_ns((cyc - cd-epoch_cyc) mask, cd-mult, cd-shift);
+
+ /*
+* Write epoch_cyc and epoch_ns in a way that the update is
+* detectable in cyc_to_fixed_sched_clock().
+*/
+ cd-epoch_cyc = cyc;
+ smp_wmb();
+ cd-epoch_ns = ns;
+ smp_wmb();
+ cd-epoch_cyc_copy = cyc;
+}
+
+/*
+ * If your clock rate is known at compile time, using this will allow
+ * you to optimize the mult/shift loads away. This is paired with
+ * init_fixed_sched_clock() to ensure that your mult/shift are correct.
+ */
+static inline unsigned long long cyc_to_fixed_sched_clock(struct clock_data
*cd,
+ u32 cyc, u32 mask, u32 mult, u32 shift)
+{
+ u64 epoch_ns;
+ u32 epoch_cyc;
+
+ /*
+* Load the epoch_cyc and epoch_ns atomically. We do this by
+* ensuring that we always write epoch_cyc, epoch_ns and
+* epoch_cyc_copy in strict order, and read them in strict order.
+* If epoch_cyc and epoch_cyc_copy are not equal, then we're in
+* the middle of an update, and we should repeat the load.
+*/
+ do {
+ epoch_cyc = cd-epoch_cyc;
+ smp_rmb();
+ epoch_ns = cd-epoch_ns;
+ smp_rmb();
+ } while (epoch_cyc != cd-epoch_cyc_copy);
+
+ return epoch_ns + cyc_to_ns((cyc - epoch_cyc) mask, mult, shift);
+}
+
+/*
+ * Otherwise, you need to use this, which will obtain the mult/shift
+ * from the clock_data structure. Use init_sched_clock() with this.
+ */
+static inline unsigned long long cyc_to_sched_clock(struct clock_data *cd,
+ u32 cyc, u32 mask)
+{
+ return cyc_to_fixed_sched_clock(cd, cyc, mask, cd-mult, cd-shift);
+}
+
+/*
+ * Initialize the clock data - calculate the appropriate multiplier
+ * and shift. Also setup a timer to ensure that the epoch is refreshed
+ * at the appropriate time interval, which will call your update
+ * handler.
+ */
+void init_sched_clock(struct clock_data *, void (*)(void),
+ unsigned int, unsigned long);
+
+/*
+ * Use this initialization function rather than init_sched_clock() if
+ * you're using cyc_to_fixed_sched_clock, which will warn if your
+ * constants are incorrect.
+ */
+static inline void init_fixed_sched_clock(struct clock_data *cd,
+ void (*update)(void), unsigned int bits, unsigned long rate,
+ u32 mult, u32 shift)
+{
+ init_sched_clock(cd, update, bits, rate);
+ if (cd-mult != mult || cd-shift != shift) {
+ pr_crit(sched_clock: wrong multiply/shift: %u%u vs
calculated %u%u\n
+ sched_clock: fix multiply/shift to avoid scheduler
hiccups\n,
+ mult, shift, cd-mult, cd-shift);
+ }
+}
+
+#endif
diff --git
Re: [PATCH 0/13] 64-bit sched_clock
There is one issue which remains with this code - that is the initialization ordering. init/main.c: setup_arch(command_line); ... sched_init(); ... early_irq_init(); init_IRQ(); ... timekeeping_init(); time_init(); sched_init() calls init_idle() which calls sched_clock() to set the start time for the idle thread. However, our sched_clock() is not initialized (in general) until init/main.c calls time_init(). This results in a big step in the sched_clock() return value during boot, which is probably not desirable. At the moment, I work around this by explicitly setting the epoch_ns to zero after the first update callback - but this means that sched_clock() will only start at this point, which may not be desirable for everyone. Some sched_clock() implementations rely upon clocksource code (they use the clocksource read function) and this is only initialized when the clocksource is registered. There's also the matter of the clock rate. It's probably not a good idea to register clocksources before timekeeping_init() has happened either. I can provide an init_early() method in the machine description which setup_arch() can call as the last thing it does - this will happen after the -reserve and -map_io callbacks, but before interrupts and timers have been setup. This is the ideal time to setup the sched_clock(). However, that means digging through lots of arch code to sort out what can be moved where, and that's going to be inherently unreliable. I think init_early() has merit in other ways - it'll allow us to remove crap from the -map_io callbacks which is doing stuff like registering clk structures and so forth. Any other suggestions? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Monday 06 December 2010, David Sin wrote: Tiling and Isometric Lightweight Engine for Rotation (TILER) driver = Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections. How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality. I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1] OMAP: GPIO: Correct IP version message during boot
With the commit 9a748053f5f58a77cd71864f1d7b804175b0e47d whose subject is OMAP: GPIO: Make omap_gpio_show_rev bank specific (see [1]), the IP version information for all the banks are shown during bootup, but it does not show the bank number. Use dev_info instead of printk in omap_gpio_show_rev() so that the bank id is displayed along with the IP version [1] http://www.spinics.net/lists/arm-kernel/msg105872.html Signed-off-by: Varadarajan, Charulatha ch...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/gpio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 8d493b9..47aeaeb 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -1554,7 +1554,7 @@ static void __init omap_gpio_show_rev(struct gpio_bank *bank) else return; - printk(KERN_INFO OMAP GPIO hardware version %d.%d\n, + dev_info(bank-dev, hardware version %d.%d\n, (rev 4) 0x0f, rev 0x0f); } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
Hi, On Thu, Dec 16, 2010 at 2:28 AM, Varadarajan, Charulatha ch...@ti.com wrote: On Thu, Dec 16, 2010 at 12:17, Omar Ramirez Luna omar.rami...@ti.com wrote: Use runtime pm APIs to enable/disable mailbox clocks and to configure SYSC register. Based on the patch sent by Felipe Contreras: https://patchwork.kernel.org/patch/101662/ Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/mailbox.c | 27 +-- 1 files changed, 5 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 40ddeca..f5f72ba 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -14,6 +14,7 @@ #include linux/err.h #include linux/platform_device.h #include linux/io.h +#include linux/pm_runtime.h #include plat/mailbox.h #include mach/irqs.h @@ -34,12 +35,8 @@ #define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) /* SYSCONFIG: register bit definition */ -#define AUTOIDLE (1 0) #define SOFTRESET (1 1) -#define SMARTIDLE (2 3) #define OMAP4_SOFTRESET (1 0) -#define OMAP4_NOIDLE (1 2) -#define OMAP4_SMARTIDLE (2 2) /* SYSSTATUS: register bit definition */ #define RESETDONE (1 0) Is this still required? Yes, mailbox uses the softreset every time it is requested (and that it has no current users at the time), it does it before configuring sysc, as opossed to what this patch does (where clk is enabled, sysc configured, and then softreset), but no harm was seen with this sequence. AFAIK, enabling/disabling hwmod handles prm reset but not softreset bit, that's why I left it there. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] OMAP: mailbox: build device using omap_device/omap_hwmod
On Thu, Dec 16, 2010 at 2:44 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Dec 16, 2010 at 02:08:11PM +0530, Varadarajan, Charulatha wrote:
+ oh = omap_hwmod_lookup(mailbox);
+ if (!oh) {
+ pr_err(%s: unable to find hwmod\n, __func__);
+ return;
+ }
+
+ od = omap_device_build(omap-mailbox, -1, oh,
+ NULL, 0,
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
+ 0);
+ if (!od) {
Check for IS_ERR(od).
+ pr_err(%s: could not build device\n, __func__);
If you have an API which returns errors, and you're bothering to print
something when an error occurs, it's often useful to print the returned
error code, so that people can find out _why_ the error occurred.
Agree.
Thanks,
Omar
--
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: [GIT PULL] OMAP DSS fixes for next rc
On Wed, Dec 15, 2010 at 05:20:08PM +0200, Tomi Valkeinen wrote: Hi Paul, Two OMAP DSS fixes for the next rc. Pulled and pushed out, thanks. I'll send these out for -rc7. -- 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: ensure all sched_clock() implementations are notrace marked
On Thu, Dec 16, 2010 at 1:48 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: ftrace requires sched_clock() to be notrace. Ensure that all implementations are so marked. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk It does seem better to have all of them explicity annotated anyway, even if it not required in most of the cases because they include linux/sched.h and the annotation in the declaration takes effect. Note that in order for this to be fully effective, all functions called from sched_clock() need to be notrace too. OMAP and u300 miss this. The following patches fix them up; perhaps you can fold them into this one. If not, I will rebase them later after this series is merged: http://www.spinics.net/lists/arm-kernel/msg104616.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38911.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
[OMAP 1710] Mainline Broken
Did anyone observe this? I am using omap_generic_1710_defconfig [...] input: omap-keypad as /devices/platform/omap-keypad/input/input0 TCP cubic registered NET: Registered protocol family 17 Registering the dns_resolver key type eth0: link up IP-Config: Complete: device=eth0, addr=172.24.191.106, mask=255.255.252.0, gw=172.24.188.1, host=myomap, domain=, nis-domain=(none), bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath= VFS: Mounted root (nfs filesystem) on device 0:10. Freeing init memory: 128K Kernel panic - not syncing: Attempted to kill init! Backtrace: [c0032104] (dump_backtrace+0x0/0x114) from [c027ecd4] (dump_stack+0x18/0x1c) r7:c0826000 r6:c0826000 r5:c0304ce8 r4:c0320254 [c027ecbc] (dump_stack+0x0/0x1c) from [c027ed38] (panic+0x60/0x188) [c027ecd8] (panic+0x0/0x188) from [c0047414] (do_exit+0x74/0x600) r3:6013 r2:c0826000 r1:c08260f8 r0:c02d6cff [c00473a0] (do_exit+0x0/0x600) from [c0047a38] (do_group_exit+0x98/0xcc) [c00479a0] (do_group_exit+0x0/0xcc) from [c00535e4] (get_signal_to_deliver+0x304/0x33c) r7:c08ba484 r6:c0828000 r5:c0829ee4 r4:0004 [c00532e0] (get_signal_to_deliver+0x0/0x33c) from [c0030fb8] (do_notify_resume+0x7c/0x638) [c0030f3c] (do_notify_resume+0x0/0x638) from [c002eb14] (work_pending+0x24/0x28) -- Tarun -- 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: [OMAP 1710] Mainline Broken
Hi, On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Did anyone observe this? I am using omap_generic_1710_defconfig [...] input: omap-keypad as /devices/platform/omap-keypad/input/input0 TCP cubic registered NET: Registered protocol family 17 Registering the dns_resolver key type eth0: link up IP-Config: Complete: device=eth0, addr=172.24.191.106, mask=255.255.252.0, gw=172.24.188.1, host=myomap, domain=, nis-domain=(none), bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath= VFS: Mounted root (nfs filesystem) on device 0:10. Freeing init memory: 128K Kernel panic - not syncing: Attempted to kill init! Seems your userspace is broken. Try add user_debug=31 to command line to see what exactly happens. Backtrace: [c0032104] (dump_backtrace+0x0/0x114) from [c027ecd4] (dump_stack+0x18/0x1c) r7:c0826000 r6:c0826000 r5:c0304ce8 r4:c0320254 [c027ecbc] (dump_stack+0x0/0x1c) from [c027ed38] (panic+0x60/0x188) [c027ecd8] (panic+0x0/0x188) from [c0047414] (do_exit+0x74/0x600) r3:6013 r2:c0826000 r1:c08260f8 r0:c02d6cff [c00473a0] (do_exit+0x0/0x600) from [c0047a38] (do_group_exit+0x98/0xcc) [c00479a0] (do_group_exit+0x0/0xcc) from [c00535e4] (get_signal_to_deliver+0x304/0x33c) r7:c08ba484 r6:c0828000 r5:c0829ee4 r4:0004 [c00532e0] (get_signal_to_deliver+0x0/0x33c) from [c0030fb8] (do_notify_resume+0x7c/0x638) [c0030f3c] (do_notify_resume+0x0/0x638) from [c002eb14] (work_pending+0x24/0x28) -- Tarun -- 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 thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite icq: 290551086 web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v4] AM35xx: Craneboard: Add USB EHCI support
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
History:
http://marc.info/?l=linux-omapw=2r=1s=Craneboard%3A+Add+USB+EHCI+supportq=t
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 53 +++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 8ba4047..1a80175 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -19,6 +19,7 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/gpio.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -27,8 +28,14 @@
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
#include mux.h
+#include control.h
+
+#define GPIO_USB_POWER 35
+#define GPIO_USB_NRESET38
+
/* Board initialization */
static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
@@ -51,10 +58,56 @@ static void __init am3517_crane_init_irq(void)
omap_init_irq();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = GPIO_USB_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_crane_init(void)
{
+ int ret;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ if (omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT)) {
+ pr_err(Can not cofigure mux for GPIO_USB_NRESET %d\n,
+ GPIO_USB_NRESET);
+ return;
+ }
+
+ if (omap_mux_init_gpio(GPIO_USB_POWER, OMAP_PIN_OUTPUT)) {
+ pr_err(Can not cofigure mux for GPIO_USB_POWER %d\n,
+
+ GPIO_USB_POWER);
+ return;
+ }
+
+ ret = gpio_request(GPIO_USB_POWER, usb_ehci_enable);
+ if (ret 0) {
+ pr_err(Cannot request GPIO %d\n, GPIO_USB_POWER);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_USB_POWER, 1);
+ if (ret 0)
+ goto err;
+
+
+ usb_ehci_init(ehci_pdata);
+ return;
+
+err:
+ gpio_free(GPIO_USB_POWER);
+ pr_err(Unable to initialize EHCI power\n);
+ return;
}
MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
--
1.7.1.226.g770c5
--
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: ensure all sched_clock() implementations are notrace marked
On Thu, Dec 16, 2010 at 08:42:23PM +0530, Rabin Vincent wrote: On Thu, Dec 16, 2010 at 1:48 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: ftrace requires sched_clock() to be notrace. Ensure that all implementations are so marked. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk It does seem better to have all of them explicity annotated anyway, even if it not required in most of the cases because they include linux/sched.h and the annotation in the declaration takes effect. Firstly, we shouldn't be relying upon that, and secondly, everywhere which defines sched_clock() should already be including linux/sched.h to avoid the sparse error. It sounds like there's also an exercise to make sure that is the case. Note that in order for this to be fully effective, all functions called from sched_clock() need to be notrace too. OMAP and u300 miss this. Yes, OMAP still suffers from this. However, I assume you haven't looked at the u300 sched_clock conversion patch which is part of a follow-on series on lakml? It sorts u300 out in that regard. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm-core broken
Hiremath, Vaibhav had written, on 12/15/2010 09:00 PM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Thursday, December 16, 2010 7:57 AM To: Kevin H; linux-omap@vger.kernel.org Subject: pm-core broken Hi Kevin, Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both fail - I think basically 3630 is broken atm!. [Hiremath, Vaibhav] Nishant, I am also seeing similar behavior on OMAP3EVM (AM/DM3730), where it does fail with message Powerdomain (core_pwrdm) didn't enter target state 0. But somehow I am not seeing issues with DSS power domain, not sure what could be happening. Really curious now. my results with SDP3630: http://pastebin.mozilla.org/890302 SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (7 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-23| RET:1 -1 (21 sec) IDLE:RET test | PASS | OFF: 23-23| RET:1 -23 (21 sec) are you on k.org? can you run my script http://pastebin.mozilla.org/889933 and provide the results for EVM? -- Regards, Nishanth Menon -- 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: ensure all sched_clock() implementations are notrace marked
On Thu, Dec 16, 2010 at 9:27 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 16, 2010 at 08:42:23PM +0530, Rabin Vincent wrote: On Thu, Dec 16, 2010 at 1:48 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: ftrace requires sched_clock() to be notrace. Ensure that all implementations are so marked. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk It does seem better to have all of them explicity annotated anyway, even if it not required in most of the cases because they include linux/sched.h and the annotation in the declaration takes effect. Firstly, we shouldn't be relying upon that, and secondly, everywhere which defines sched_clock() should already be including linux/sched.h to avoid the sparse error. It sounds like there's also an exercise to make sure that is the case. Yes. I believe I identified all the ones which weren't including the header in the last notrace series I sent out (versatile, plat-iop, omap, and u300 IIRC), but there's been some changes in various platforms' sched_clocks() and of course new platforms since then. Note that in order for this to be fully effective, all functions called from sched_clock() need to be notrace too. OMAP and u300 miss this. Yes, OMAP still suffers from this. However, I assume you haven't looked at the u300 sched_clock conversion patch which is part of a follow-on series on lakml? It sorts u300 out in that regard. Yes, I now see U300 no longer needs the notrace addition. It still could do with the #include linux/sched.h addition though, which was also being done as part of that patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
Omar,
On Thu, Dec 16, 2010 at 12:47 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Use runtime pm APIs to enable/disable mailbox clocks and
to configure SYSC register.
Based on the patch sent by Felipe Contreras:
https://patchwork.kernel.org/patch/101662/
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 27 +--
1 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..f5f72ba 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -14,6 +14,7 @@
#include linux/err.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/pm_runtime.h
#include plat/mailbox.h
#include mach/irqs.h
@@ -34,12 +35,8 @@
#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
/* SYSCONFIG: register bit definition */
-#define AUTOIDLE (1 0)
#define SOFTRESET (1 1)
-#define SMARTIDLE (2 3)
#define OMAP4_SOFTRESET (1 0)
-#define OMAP4_NOIDLE (1 2)
-#define OMAP4_SMARTIDLE (2 2)
/* SYSSTATUS: register bit definition */
#define RESETDONE (1 0)
@@ -70,8 +67,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -91,13 +86,8 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
u32 l;
unsigned long timeout;
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ pm_runtime_enable(mbox-dev-parent);
+ pm_runtime_get_sync(mbox-dev-parent);
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -130,12 +120,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
l = mbox_read_reg(MAILBOX_REVISION);
pr_debug(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f));
- if (cpu_is_omap44xx())
- l = OMAP4_SMARTIDLE;
- else
- l = SMARTIDLE | AUTOIDLE;
- mbox_write_reg(l, MAILBOX_SYSCONFIG);
-
The OMAP4 mailbox sysconfig register bits are laid out differently
from previous OMAP mailbox's. Example is smart idle bit location is
different from previous OMAPs. Can I know as how are you handling this
aspect in hwmod code ?
Thank you,
Best regards,
Hari Kanigeri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm-core broken
Nishanth Menon n...@ti.com writes: Hi Kevin, Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both fail - I think basically 3630 is broken atm!. Beagleboard: with omap2plus_defconfig + MLO, u-boot.bin from http://www.angstrom-distribution.org/demo/beagleboard/ filesystem is a minimal busybox that I had built and init=/bin/sh to prevent any other apps running in the background - I use the same on SDP3630 and 3430 platforms. branch: pm-core (from your tree). defconfig: omap2plus_defconfig - no changes other than disable RM680 board - currently causes a build failure. At least for Beagle (and I assume it's same for SDP, but don't have one to test with) the problem is that u-boot leaves the USB OTG block in a state that does not idle, and thus prevents CORE from hitting RET. The solution: ensure the USB OTG block is reset. Also in my tree, threre is an usb-otg-reset branch which you can merge with pm-core to test if this helps. Until we have the USB OTG hwmod conversion merged, this temporary hack is needed. After conversion to hwmod, all hwmod will be reset during boot so we are not affected by bootloader (mis)behavior. Kevin test script - same one I had send to ML earlier today replica here: http://pastebin.mozilla.org/889933 log: # ./suspend-idle.sh mount: no /proc/mounts [ 12.493682] PM: Syncing filesystems ... done. [ 12.749114] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 12.774780] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 12.807891] Suspending console(s) (use no_console_suspend to debug) [ 12.930480] PM: suspend of devices complete after 111.450 msecs [ 12.933990] omap_device: i2c_omap.1: new worst case deactivate latency 0: 152 587 [ 12.934234] PM: late suspend of devices complete after 3.692 msecs [ 12.934295] Disabling non-boot CPUs ... [ 12.934906] PM: Resume timer in 5.000 secs (163840 ticks at 32768 ticks/sec.) [ 12.935119] omap_device: omap-hsuart.1: new worst case deactivate latency 0: 30517 [ 17.848388] omap_device: omap-hsuart.0: new worst case activate latency 0: 91 552 [ 17.848541] Powerdomain (core_pwrdm) didn't enter target state 0 [ 17.848571] Powerdomain (dss_pwrdm) didn't enter target state 0 [ 17.848602] Could not enter target state in pm_suspend [ 17.850952] PM: early resume of devices complete after 1.983 msecs [ 18.238128] PM: resume of devices complete after 386.688 msecs [ 18.321746] Restarting tasks ... done. SUSPEND:OFF test | FAIL | OFF: 0-0| RET:0 -0 (6 sec) [ 19.755401] PM: Syncing filesystems ... done. [ 19.801116] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 19.829406] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 19.861419] Suspending console(s) (use no_console_suspend to debug) [ 19.984863] PM: suspend of devices complete after 112.487 msecs [ 19.988281] PM: late suspend of devices complete after 3.387 msecs [ 19.988311] Disabling non-boot CPUs ... [ 19.988616] PM: Resume timer in 5.000 secs (163840 ticks at 32768 ticks/sec.) [ 24.853942] Powerdomain (core_pwrdm) didn't enter target state 1 [ 24.853942] Powerdomain (dss_pwrdm) didn't enter target state 1 [ 24.853973] Could not enter target state in pm_suspend [ 24.855926] PM: early resume of devices complete after 1.739 msecs [ 25.243804] PM: resume of devices complete after 387.634 msecs [ 25.303649] Restarting tasks ... done. SUSPEND:RET test | FAIL | OFF: 0-0| RET:0 -0 (7 sec) IDLE:OFF test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) IDLE:RET test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) usbhost_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:15,RET:22,INA:0,ON:38,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-ME MBANK2-OFF:0 neon_pwrdm (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-M EMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (9) usbhost_clkdm-usbhost_pwrdm (0) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (0) core_l4_clkdm-core_pwrdm (11) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) SUSPEND:OFF test | FAIL | OFF: 0-0|
Re: [PATCH v2 1/5] OMAP4: PM: Use the low-power state change feature on OMAP4
Rajendra Nayak rna...@ti.com writes:
For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking
up the domain to put it back to deeper sleep state.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
Changes in v2:
Changed implementation for better readability and code
reuse as suggested here
http://marc.info/?l=linux-omapm=129245686306262w=2
The below branch is updated with this version of the patch
git://gitorious.org/omap-pm/linux.git for_2.6.38/power
arch/arm/mach-omap2/pm.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
Index: linux/arch/arm/mach-omap2/pm.c
===
--- linux.orig/arch/arm/mach-omap2/pm.c 2010-12-15 17:29:42.361228780
+0530
+++ linux/arch/arm/mach-omap2/pm.c2010-12-15 20:19:48.321228780 +0530
@@ -89,6 +89,10 @@
}
}
+/* Types of sleep_switch used in omap_set_pwrdm_state */
+#define FORCEWAKEUP_SWITCH 0
+#define LOWPOWERSTATE_SWITCH 1
+
/*
* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported. Function is assuming that clkdm doesn't have
@@ -114,9 +118,14 @@
return ret;
if (pwrdm_read_pwrst(pwrdm) PWRDM_POWER_ON) {
- omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = 1;
- pwrdm_wait_transition(pwrdm);
+ if ((pwrdm_read_pwrst(pwrdm) state)
+ (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
+ sleep_switch = LOWPOWERSTATE_SWITCH;
+ } else {
+ omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
+ pwrdm_wait_transition(pwrdm);
+ sleep_switch = FORCEWAKEUP_SWITCH;
+ }
}
ret = pwrdm_set_next_pwrst(pwrdm, state);
@@ -126,12 +135,19 @@
goto err;
}
- if (sleep_switch) {
+ switch (sleep_switch) {
+ case FORCEWAKEUP_SWITCH:
omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
+ break;
+ case LOWPOWERSTATE_SWITCH:
+ pwrdm_set_lowpwrstchange(pwrdm);
+ break;
+ default:
+ return ret;
}
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
err:
return ret;
}
--
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 v1] OMAP: GPIO: Correct IP version message during boot
Varadarajan, Charulatha ch...@ti.com writes: With the commit 9a748053f5f58a77cd71864f1d7b804175b0e47d whose subject is OMAP: GPIO: Make omap_gpio_show_rev bank specific (see [1]), the IP version information for all the banks are shown during bootup, but it does not show the bank number. Use dev_info instead of printk in omap_gpio_show_rev() so that the bank id is displayed along with the IP version [1] http://www.spinics.net/lists/arm-kernel/msg105872.html A related question, the commit above also changed the GPIO revision display from one-time to once per bank. Do we need to know the GPIO HW revision for each bank, or can we assume it's the same for all banks? Kevin Signed-off-by: Varadarajan, Charulatha ch...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/gpio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 8d493b9..47aeaeb 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -1554,7 +1554,7 @@ static void __init omap_gpio_show_rev(struct gpio_bank *bank) else return; - printk(KERN_INFO OMAP GPIO hardware version %d.%d\n, + dev_info(bank-dev, hardware version %d.%d\n, (rev 4) 0x0f, rev 0x0f); } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
Hi, On Thu, Dec 16, 2010 at 10:32 AM, Kanigeri, Hari h-kanige...@ti.com wrote: @@ -130,12 +120,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) l = mbox_read_reg(MAILBOX_REVISION); pr_debug(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f)); - if (cpu_is_omap44xx()) - l = OMAP4_SMARTIDLE; - else - l = SMARTIDLE | AUTOIDLE; - mbox_write_reg(l, MAILBOX_SYSCONFIG); - The OMAP4 mailbox sysconfig register bits are laid out differently from previous OMAP mailbox's. Example is smart idle bit location is different from previous OMAPs. Can I know as how are you handling this aspect in hwmod code ? hwmod framework provides definition for both IP models (omap_hwmod_sysc_type1for omap2/3 or omap_hwmod_sysc_type2 for omap4), these are located at arch/arm/mach-omap2/omap_hwmod_common_data.c Regards, Omar -- 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: ensure all sched_clock() implementations are notrace marked
On Thu, Dec 16, 2010 at 09:52:56PM +0530, Rabin Vincent wrote: Yes, I now see U300 no longer needs the notrace addition. It still could do with the #include linux/sched.h addition though, which was also being done as part of that patch. Okay, added to u300, tegra, iop, and omap which weren't including linux/sched.h explicitly. -- 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: [OMAP 1710] Mainline Broken
Belisko Marek marek.beli...@gmail.com writes: Hi, On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Did anyone observe this? I am using omap_generic_1710_defconfig [...] input: omap-keypad as /devices/platform/omap-keypad/input/input0 TCP cubic registered NET: Registered protocol family 17 Registering the dns_resolver key type eth0: link up IP-Config: Complete: device=eth0, addr=172.24.191.106, mask=255.255.252.0, gw=172.24.188.1, host=myomap, domain=, nis-domain=(none), bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath= VFS: Mounted root (nfs filesystem) on device 0:10. Freeing init memory: 128K Kernel panic - not syncing: Attempted to kill init! Seems your userspace is broken. Try add user_debug=31 to command line to see what exactly happens. Looks like you're mounting an NFS rootfs. Was it compiled for armv5? My hunch would be you're trying to run an armv6/armv7 userspace on the 1710 which is armv5. To get more debugging, ensure these are enabled in your defconfig: CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_USER=y CONFIG_DEBUG_ERRORS=y and in addition to cmdline suggested by Marek, add user_debug=0xf This will give verbose output for userspace exceptions as well and possibly confirm my hunch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: On Monday 06 December 2010, David Sin wrote: Tiling and Isometric Lightweight Engine for Rotation (TILER) driver = Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections. How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality. I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there. Arnd Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER. thanks, -- David Sin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 11:25:31AM -0600, David Sin wrote: On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: On Monday 06 December 2010, David Sin wrote: Tiling and Isometric Lightweight Engine for Rotation (TILER) driver = Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections. How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality. I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there. Arnd Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER. thanks, -- David Sin Hi Arnd, I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for virtually physically contiguous memory and sdram pages. thank you for your comments. BR, -- David Sin -- 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] OMAP: RM-680: fix omap2_init_common_hw compile break
This solves the following: arch/arm/mach-omap2/board-rm680.c: In function 'rm680_init_irq': arch/arm/mach-omap2/board-rm680.c:149: error: implicit declaration of function 'omap2_init_common_hw' And another occurence of the same functions in am3517crane board file. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/board-am3517crane.c |3 ++- arch/arm/mach-omap2/board-rm680.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c index 8ba4047..781ed25 100644 --- a/arch/arm/mach-omap2/board-am3517crane.c +++ b/arch/arm/mach-omap2/board-am3517crane.c @@ -47,7 +47,8 @@ static void __init am3517_crane_init_irq(void) omap_board_config = am3517_crane_config; omap_board_config_size = ARRAY_SIZE(am3517_crane_config); - omap2_init_common_hw(NULL, NULL); + omap2_init_common_infrastructure(); + omap2_init_common_devices(NULL, NULL); omap_init_irq(); } diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 8da65bd..e51e737 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -146,7 +146,8 @@ static void __init rm680_init_irq(void) struct omap_sdrc_params *sdrc_params; sdrc_params = nokia_get_sdram_timings(); - omap2_init_common_hw(sdrc_params, sdrc_params); + omap2_init_common_infrastructure(); + omap2_init_common_devices(sdrc_params, sdrc_params); omap_init_irq(); } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Thursday 16 December 2010 18:37:38 David Sin wrote: I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for virtually physically contiguous memory and sdram pages. As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory. I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7 v4] OMAP3: clean up ASM sleep code
From: Jean Pihet j-pi...@ti.com This patch only contains clean-ups and cosmetic changes, no functional change. Clean-up of the ASM sleep code, for better readability and easier maintenance. Applies on top of Nishant's latest idle path errata fixes step 2, cf. http://marc.info/?l=linux-omapm=129139584919242w=2 Jean Pihet (7): OMAP2+: use global values for the SRAM PA addresses OMAP3: remove hardcoded values from the ASM sleep code OMAP3: re-organize the ASM sleep code OMAP3: rework of the ASM sleep code execution paths OMAP3: add comments for low power code errata OMAP3: ASM sleep code format rework OMAP3: remove unused code from the ASM sleep code arch/arm/mach-omap2/control.c | 10 +- arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|1 - arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sdrc.h |7 + arch/arm/mach-omap2/sleep34xx.S | 714 +-- arch/arm/plat-omap/sram.c |7 +- 7 files changed, 401 insertions(+), 344 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
[PATCH 1/7] OMAP3: remove unused code from the ASM sleep code
From: Jean Pihet j-pi...@ti.com
Remove unused code:
- macros,
- variables,
- unused semaphore locking API. This API shall be added back
when needed,
- infinite loops for debug.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.h|1 -
arch/arm/mach-omap2/sleep34xx.S | 58 ---
2 files changed, 6 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index aff39d0..e458b2a 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr);
extern void omap3_save_scratchpad_contents(void);
extern unsigned int omap24xx_idle_loop_suspend_sz;
-extern unsigned int omap34xx_suspend_sz;
extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d2eda01..2191576 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -35,11 +35,7 @@
#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c
-#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
- OMAP3430_PM_PREPWSTST)
#define PM_PREPWSTST_CORE_P0x48306AE8
-#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
- OMAP3430_PM_PREPWSTST)
#define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL
#define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
#define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
@@ -62,36 +58,10 @@
#define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
#define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
-.text
-/* Function to acquire the semaphore in scratchpad */
-ENTRY(lock_scratchpad_sem)
- stmfd sp!, {lr} @ save registers on stack
-wait_sem:
- mov r0,#1
- ldr r1, sdrc_scratchpad_sem
-wait_loop:
- ldr r2, [r1]@ load the lock value
- cmp r2, r0 @ is the lock free ?
- beq wait_loop @ not free...
- swp r2, r0, [r1]@ semaphore free so lock it and proceed
- cmp r2, r0 @ did we succeed ?
- beq wait_sem@ no - try again
- ldmfd sp!, {pc} @ restore regs and return
-sdrc_scratchpad_sem:
-.word SDRC_SCRATCHPAD_SEM_V
-ENTRY(lock_scratchpad_sem_sz)
-.word . - lock_scratchpad_sem
-
-.text
-/* Function to release the scratchpad semaphore */
-ENTRY(unlock_scratchpad_sem)
- stmfd sp!, {lr} @ save registers on stack
- ldr r3, sdrc_scratchpad_sem
- mov r2,#0
- str r2,[r3]
- ldmfd sp!, {pc} @ restore regs and return
-ENTRY(unlock_scratchpad_sem_sz)
-.word . - unlock_scratchpad_sem
+
+/*
+ * API functions
+ */
.text
/* Function call to get the restore pointer for resume from OFF */
@@ -178,8 +148,7 @@ ENTRY(es3_sdrc_fix_sz)
/* Function to call rom code to save secure ram context */
ENTRY(save_secure_ram_context)
stmfd sp!, {r1-r12, lr} @ save registers on stack
-save_secure_ram_debug:
- /* b save_secure_ram_debug */ @ enable to debug save code
+
adr r3, api_params @ r3 points to parameters
str r0, [r3,#0x4] @ r0 has sdram address
ldr r12, high_mask
@@ -219,8 +188,7 @@ ENTRY(save_secure_ram_context_sz)
*/
ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
-loop:
- /*b loop*/ @Enable to debug by stepping through code
+
/* r0 contains restore pointer in sdram */
/* r1 contains information about saving context */
ldr r4, sdrc_power @ read the SDRC_POWER register
@@ -252,7 +220,6 @@ loop:
ldmfd sp!, {r0-r12, pc} @ restore regs and return
restore_es3:
- /*b restore_es3*/ @ Enable to debug restore code
ldr r5, pm_prepwstst_core_p
ldr r4, [r5]
and r4, r4, #0x3
@@ -272,7 +239,6 @@ copy_to_sram:
b restore
restore_3630:
- /*b restore_es3630*/@ Enable to debug restore code
ldr r1, pm_prepwstst_core_p
ldr r2, [r1]
and r2, r2, #0x3
@@ -284,7 +250,6 @@ restore_3630:
str r2, [r1]
/* Fall thru for the remaining logic */
restore:
- /* b restore*/ @ Enable to debug restore code
/* Check what was the reason for mpu reset and store the reason in r9*/
/* 1 - Only L1 and logic lost */
/* 2 - Only L2 lost - In this case, we wont be here */
@@ -493,7 +458,6 @@ usettbr0:
ldmfd sp!, {r0-r12, pc}
[PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses
From: Jean Pihet j-pi...@ti.com The SRAM PA addresses are locally defined and used in both the SRAM management code and the idle sleep code. A global macro defines the values at a centralized place, for easier maintenance. Tested on N900 and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/sdrc.h |7 +++ arch/arm/plat-omap/sram.c |7 ++- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h index 68f57bb..ada596b 100644 --- a/arch/arm/mach-omap2/sdrc.h +++ b/arch/arm/mach-omap2/sdrc.h @@ -74,5 +74,12 @@ static inline u32 sms_read_reg(u16 reg) */ #define SDRC_MPURATE_LOOPS 96 +/* + * OMAP2+: define the SRAM PA addresses. + * Used by the SRAM management code and the idle sleep code. + */ +#define OMAP2_SRAM_PA 0x4020 +#define OMAP3_SRAM_PA 0x4020 +#define OMAP4_SRAM_PA 0x4030 #endif diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 819ea0c..1a686c8 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -41,15 +41,12 @@ #define OMAP1_SRAM_PA 0x2000 #define OMAP1_SRAM_VA VMALLOC_END -#define OMAP2_SRAM_PA 0x4020 -#define OMAP2_SRAM_PUB_PA 0x4020f800 +#define OMAP2_SRAM_PUB_PA (OMAP2_SRAM_PA + 0xf800) #define OMAP2_SRAM_VA 0xfe40 #define OMAP2_SRAM_PUB_VA (OMAP2_SRAM_VA + 0x800) -#define OMAP3_SRAM_PA 0x4020 #define OMAP3_SRAM_VA 0xfe40 -#define OMAP3_SRAM_PUB_PA 0x40208000 +#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000) #define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000) -#define OMAP4_SRAM_PA 0x4030 #define OMAP4_SRAM_VA 0xfe40 #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) #define OMAP4_SRAM_PUB_VA (OMAP4_SRAM_VA + 0x4000) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] OMAP3: remove hardcoded values from the ASM sleep code
From: Jean Pihet j-pi...@ti.com Using macros from existing include files for registers addresses. Tested on N900 and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Based on original patch from Vishwa. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/control.h |2 ++ arch/arm/mach-omap2/sleep34xx.S | 29 ++--- 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d7911c5..72efefb 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -274,6 +274,8 @@ #define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860) #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\ + OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2191576..20dc0f4 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,20 +33,27 @@ #include sdrc.h #include control.h -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c - -#define PM_PREPWSTST_CORE_P0x48306AE8 +/* + * Registers access definitions + */ +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR\ + (SDRC_SCRATCHPAD_SEM_OFFS) +#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD +\ + OMAP3430_PM_PREPWSTST #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) #define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) -#define SRAM_BASE_P0x4020 -#define CONTROL_STAT 0x480022F0 -#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE\ - + OMAP36XX_CONTROL_MEM_RTA_CTRL) -#define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is - * available */ -#define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ - + SCRATCHPAD_MEM_OFFS) +#define SRAM_BASE_POMAP3_SRAM_PA +#define CONTROL_STAT OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS +#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE +\ + OMAP36XX_CONTROL_MEM_RTA_CTRL) + +/* Move this as correct place is available */ +#define SCRATCHPAD_MEM_OFFS0x310 +#define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE +\ + OMAP343X_CONTROL_MEM_WKUP +\ + SCRATCHPAD_MEM_OFFS) #define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER) #define SDRC_SYSCONFIG_P (OMAP343X_SDRC_BASE + SDRC_SYSCONFIG) #define SDRC_MR_0_P(OMAP343X_SDRC_BASE + SDRC_MR_0) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] OMAP3: re-organize the ASM sleep code
From: Jean Pihet j-pi...@ti.com
Organize the code in the following sections:
- register access macros,
- API functions,
- internal functions.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/sleep34xx.S | 114 +--
1 files changed, 61 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 20dc0f4..426af02 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -78,6 +78,7 @@ ENTRY(get_restore_pointer)
ldmfd sp!, {pc} @ restore regs and return
ENTRY(get_restore_pointer_sz)
.word . - get_restore_pointer
+
.text
/* Function call to get the restore pointer for 3630 resume from OFF */
ENTRY(get_omap3630_restore_pointer)
@@ -88,9 +89,18 @@ ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_restore_pointer
.text
+/* Function call to get the restore pointer for ES3 to resume from OFF */
+ENTRY(get_es3_restore_pointer)
+ stmfd sp!, {lr} @ save registers on stack
+ adr r0, restore_es3
+ ldmfd sp!, {pc} @ restore regs and return
+ENTRY(get_es3_restore_pointer_sz)
+ .word . - get_es3_restore_pointer
+
+ .text
/*
* L2 cache needs to be toggled for stable OFF mode functionality on 3630.
- * This function sets up a fflag that will allow for this toggling to take
+ * This function sets up a flag that will allow for this toggling to take
* place on 3630. Hopefully some version in the future maynot need this
*/
ENTRY(enable_omap3630_toggle_l2_on_restore)
@@ -100,58 +110,6 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
str r1, l2dis_3630
ldmfd sp!, {pc} @ restore regs and return
- .text
-/* Function call to get the restore pointer for for ES3 to resume from OFF */
-ENTRY(get_es3_restore_pointer)
- stmfd sp!, {lr} @ save registers on stack
- adr r0, restore_es3
- ldmfd sp!, {pc} @ restore regs and return
-ENTRY(get_es3_restore_pointer_sz)
- .word . - get_es3_restore_pointer
-
-ENTRY(es3_sdrc_fix)
- ldr r4, sdrc_syscfg @ get config addr
- ldr r5, [r4]@ get value
- tst r5, #0x100 @ is part access blocked
- it eq
- biceq r5, r5, #0x100 @ clear bit if set
- str r5, [r4]@ write back change
- ldr r4, sdrc_mr_0 @ get config addr
- ldr r5, [r4]@ get value
- str r5, [r4]@ write back change
- ldr r4, sdrc_emr2_0 @ get config addr
- ldr r5, [r4]@ get value
- str r5, [r4]@ write back change
- ldr r4, sdrc_manual_0 @ get config addr
- mov r5, #0x2@ autorefresh command
- str r5, [r4]@ kick off refreshes
- ldr r4, sdrc_mr_1 @ get config addr
- ldr r5, [r4]@ get value
- str r5, [r4]@ write back change
- ldr r4, sdrc_emr2_1 @ get config addr
- ldr r5, [r4]@ get value
- str r5, [r4]@ write back change
- ldr r4, sdrc_manual_1 @ get config addr
- mov r5, #0x2@ autorefresh command
- str r5, [r4]@ kick off refreshes
- bx lr
-sdrc_syscfg:
- .word SDRC_SYSCONFIG_P
-sdrc_mr_0:
- .word SDRC_MR_0_P
-sdrc_emr2_0:
- .word SDRC_EMR2_0_P
-sdrc_manual_0:
- .word SDRC_MANUAL_0_P
-sdrc_mr_1:
- .word SDRC_MR_1_P
-sdrc_emr2_1:
- .word SDRC_EMR2_1_P
-sdrc_manual_1:
- .word SDRC_MANUAL_1_P
-ENTRY(es3_sdrc_fix_sz)
- .word . - es3_sdrc_fix
-
/* Function to call rom code to save secure ram context */
ENTRY(save_secure_ram_context)
stmfd sp!, {r1-r12, lr} @ save registers on stack
@@ -576,6 +534,56 @@ skip_l2_inval:
/* restore regs and return */
ldmfd sp!, {r0-r12, pc}
+
+/*
+ * Internal functions
+ */
+
+ .text
+ENTRY(es3_sdrc_fix)
+ ldr r4, sdrc_syscfg @ get config addr
+ ldr r5, [r4]@ get value
+ tst r5, #0x100 @ is part access blocked
+ it eq
+ biceq r5, r5, #0x100 @ clear bit if set
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_mr_0 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_emr2_0 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+
[PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths
From: Jean Pihet j-pi...@ti.com
- Reworked and simplified the execution paths for better
readability and to avoid duplication of code,
- Added comments on the entry and exit points and the interaction
with the ROM code for OFF mode restore,
- Reworked the existing comments for better readability.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/control.c | 10 +-
arch/arm/mach-omap2/sleep34xx.S | 309 ++
2 files changed, 188 insertions(+), 131 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 728f268..5cb7276 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -239,7 +239,15 @@ void omap3_save_scratchpad_contents(void)
struct omap3_scratchpad_prcm_block prcm_block_contents;
struct omap3_scratchpad_sdrc_block sdrc_block_contents;
- /* Populate the Scratchpad contents */
+ /*
+* Populate the Scratchpad contents
+*
+* The get_*restore_pointer functions are used to get the resume
+* function pointer to be called by the ROM code when back from WFI
+* in OFF mode.
+* The restore pointer is stored into the scratchpad for later access
+* by the ROM code.
+*/
scratchpad_contents.boot_config_ptr = 0x0;
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 426af02..55ddd5a 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -70,6 +70,11 @@
* API functions
*/
+/*
+ * The get_*restore_pointer functions are returning the resume
+ * function pointer to be called by the ROM code when back from WFI
+ * in OFF mode.
+ */
.text
/* Function call to get the restore pointer for resume from OFF */
ENTRY(get_restore_pointer)
@@ -101,7 +106,7 @@ ENTRY(get_es3_restore_pointer_sz)
/*
* L2 cache needs to be toggled for stable OFF mode functionality on 3630.
* This function sets up a flag that will allow for this toggling to take
- * place on 3630. Hopefully some version in the future maynot need this
+ * place on 3630. Hopefully some version in the future maynot need this.
*/
ENTRY(enable_omap3630_toggle_l2_on_restore)
stmfd sp!, {lr} @ save registers on stack
@@ -143,34 +148,156 @@ ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
/*
+ * ==
+ * == Idle entry point ==
+ * ==
+ */
+
+/*
* Forces OMAP into idle state
*
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if needed
+ * and executes the WFI instruction
*
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- * wakes up it continues execution at the point it went to sleep.
+ * Notes:
+ * - this code gets copied to internal SRAM at boot.
+ * - when the OMAP wakes up it continues at different execution points
+ * depending on the low power mode (non-OFF vs OFF modes),
+ * cf. 'Resume path for xxx mode' comments.
*/
ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
- /* r0 contains restore pointer in sdram */
- /* r1 contains information about saving context */
- ldr r4, sdrc_power @ read the SDRC_POWER register
- ldr r5, [r4]@ read the contents of SDRC_POWER
- orr r5, r5, #0x40 @ enable self refresh on idle req
- str r5, [r4]@ write back to SDRC_POWER register
+ /*
+* r0 contains restore pointer in sdram
+* r1 contains information about saving context:
+* 0 - No context lost
+* 1 - Only L1 and logic lost
+* 2 - Only L2 lost
+* 3 - Both L1 and L2 lost
+*/
+ /* Save context only if required */
cmp r1, #0x0
- /* If context save is required, do that and execute wfi */
- bne save_context_wfi
+ beq omap3_do_wfi
+
+save_context_wfi:
+ mov r8, r0 @ Store SDRAM address in r8
+ mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
+ mov r4, #0x1@ Number of parameters for restore call
+ stmia r8!, {r4-r5}@ Push parameters for restore call
+ mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
+ stmia r8!, {r4-r5}@ Push parameters for restore call
+
+/* Check what that target sleep state is from r1 */
+ cmp r1, #0x2@ Only L2 lost, no need to save context
+ beq clean_caches
+
+l1_logic_lost:
+ /* Store sp and spsr to SDRAM */
+
[PATCH 6/7] OMAP3: add comments for low power code errata
From: Jean Pihet j-pi...@ti.com Errata covered: - 1.157 1.185 - i443 - i581 Tested on N900 and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm34xx.c|4 ++-- arch/arm/mach-omap2/sleep34xx.S | 11 +++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index adc0917..267f015 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -148,7 +148,7 @@ static void omap3_core_save_context(void) /* * Force write last pad into memory, as this can fail in some -* cases according to erratas 1.157, 1.185 +* cases according to errata 1.157, 1.185 */ omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), OMAP343X_CONTROL_MEM_WKUP + 0x2a0); @@ -446,7 +446,7 @@ void omap_sram_idle(void) /* * 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 errata 1.142. + * 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 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 55ddd5a..207f6e9 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -587,6 +587,7 @@ usettbr0: * Internal functions */ +/* This function implements the erratum ID i443 WA, applies to 34xx = ES3.0 */ .text ENTRY(es3_sdrc_fix) ldr r4, sdrc_syscfg @ get config addr @@ -632,6 +633,16 @@ sdrc_manual_1: ENTRY(es3_sdrc_fix_sz) .word . - es3_sdrc_fix +/* + * This function implements the erratum ID i581 WA: + * SDRC state restore before accessing the SDRAM + * + * Only used at return from non-OFF mode. For OFF + * mode the ROM code configures the SDRC and + * the DPLL before calling the restore code directly + * from DDR. + */ + /* Make sure SDRC accesses are ok */ wait_sdrc_ok: -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] OMAP3: ASM sleep code format rework
From: Jean Pihet j-pi...@ti.com
Cosmetic fixes to the code:
- white spaces and tabs,
- alignement,
- comments rephrase and typos,
- multi-line comments
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/sleep34xx.S | 221 +--
1 files changed, 118 insertions(+), 103 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 207f6e9..9c1c57e 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -1,6 +1,10 @@
/*
* linux/arch/arm/mach-omap2/sleep.S
*
+ * (C) Copyright 2010
+ * Texas Instruments
+ * Jean Pihet j-pi...@ti.com
+ *
* (C) Copyright 2007
* Texas Instruments
* Karthik Dasu karthik...@ti.com
@@ -78,20 +82,20 @@
.text
/* Function call to get the restore pointer for resume from OFF */
ENTRY(get_restore_pointer)
-stmfd sp!, {lr} @ save registers on stack
+ stmfd sp!, {lr} @ save registers on stack
adr r0, restore
-ldmfd sp!, {pc} @ restore regs and return
+ ldmfd sp!, {pc} @ restore regs and return
ENTRY(get_restore_pointer_sz)
-.word . - get_restore_pointer
+ .word . - get_restore_pointer
.text
/* Function call to get the restore pointer for 3630 resume from OFF */
ENTRY(get_omap3630_restore_pointer)
-stmfd sp!, {lr} @ save registers on stack
+ stmfd sp!, {lr} @ save registers on stack
adr r0, restore_3630
-ldmfd sp!, {pc} @ restore regs and return
+ ldmfd sp!, {pc} @ restore regs and return
ENTRY(get_omap3630_restore_pointer_sz)
-.word . - get_omap3630_restore_pointer
+ .word . - get_omap3630_restore_pointer
.text
/* Function call to get the restore pointer for ES3 to resume from OFF */
@@ -109,16 +113,16 @@ ENTRY(get_es3_restore_pointer_sz)
* place on 3630. Hopefully some version in the future maynot need this.
*/
ENTRY(enable_omap3630_toggle_l2_on_restore)
-stmfd sp!, {lr} @ save registers on stack
+ stmfd sp!, {lr} @ save registers on stack
/* Setup so that we will disable and enable l2 */
mov r1, #0x1
str r1, l2dis_3630
-ldmfd sp!, {pc} @ restore regs and return
+ ldmfd sp!, {pc} @ restore regs and return
+ .text
/* Function to call rom code to save secure ram context */
ENTRY(save_secure_ram_context)
stmfd sp!, {r1-r12, lr} @ save registers on stack
-
adr r3, api_params @ r3 points to parameters
str r0, [r3,#0x4] @ r0 has sdram address
ldr r12, high_mask
@@ -147,6 +151,7 @@ api_params:
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
+
/*
* ==
* == Idle entry point ==
@@ -160,13 +165,14 @@ ENTRY(save_secure_ram_context_sz)
* and executes the WFI instruction
*
* Notes:
- * - this code gets copied to internal SRAM at boot.
+ * - this code gets copied to internal SRAM at boot and after wake-up
+ * from OFF mode
* - when the OMAP wakes up it continues at different execution points
* depending on the low power mode (non-OFF vs OFF modes),
* cf. 'Resume path for xxx mode' comments.
*/
ENTRY(omap34xx_cpu_suspend)
- stmfd sp!, {r0-r12, lr} @ save registers on stack
+ stmfd sp!, {r0-r12, lr} @ save registers on stack
/*
* r0 contains restore pointer in sdram
@@ -271,9 +277,9 @@ clean_l2:
* - should be faster and will change with kernel
* - 'might' have to copy address, load and jump to it
*/
- ldr r1, kernel_flush
- mov lr, pc
- bx r1
+ ldr r1, kernel_flush
+ mov lr, pc
+ bx r1
omap3_do_wfi:
ldr r4, sdrc_power @ read the SDRC_POWER register
@@ -366,18 +372,18 @@ restore_3630:
/* Fall thru to common code for the remaining logic */
restore:
-/*
+ /*
* Check what was the reason for mpu reset and store the reason in r9:
* 0 - No context lost
- * 1 - Only L1 and logic lost
- * 2 - Only L2 lost - In this case, we wont be here
- * 3 - Both L1 and L2 lost
+* 1 - Only L1 and logic lost
+* 2 - Only L2 lost - In this case, we wont be here
+* 3 - Both L1 and L2 lost
*/
- ldr r1, pm_pwstctrl_mpu
+ ldr r1, pm_pwstctrl_mpu
ldr r2, [r1]
- and r2, r2, #0x3
- cmp r2, #0x0@ Check if target power state was OFF or RET
-moveq r9, #0x3@ MPU OFF = L1 and L2 lost
+ and r2, r2, #0x3
+ cmp r2, #0x0@ Check if target power state was OFF or RET
+ moveq r9, #0x3@ MPU OFF = L1 and L2
Re: pm-core broken
Kevin Hilman had written, on 12/16/2010 10:36 AM, the following: Nishanth Menon n...@ti.com writes: Hi Kevin, Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both fail - I think basically 3630 is broken atm!. Beagleboard: with omap2plus_defconfig + MLO, u-boot.bin from http://www.angstrom-distribution.org/demo/beagleboard/ filesystem is a minimal busybox that I had built and init=/bin/sh to prevent any other apps running in the background - I use the same on SDP3630 and 3430 platforms. branch: pm-core (from your tree). defconfig: omap2plus_defconfig - no changes other than disable RM680 board - currently causes a build failure. At least for Beagle (and I assume it's same for SDP, but don't have one to test with) the problem is that u-boot leaves the USB OTG block in a state that does not idle, and thus prevents CORE from hitting RET. The solution: ensure the USB OTG block is reset. Also in my tree, threre is an usb-otg-reset branch which you can merge with pm-core to test if this helps. Until we have the USB OTG hwmod conversion merged, this temporary hack is needed. After conversion to hwmod, all hwmod will be reset during boot so we are not affected by bootloader (mis)behavior. Arrgh.. we have some sort of regression for .37 formal release (off will probably broken as a result without these patches no for mainline bootloaders/custom bootloaders that dont understand the dependency clearly?). Anyways, with the 5 patches in usb-otg-reset - test results: SDP3630 (ES1.0): SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (8 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-22| RET:1 -1 (21 sec) IDLE:RET test | PASS | OFF: 22-22| RET:1 -24 (21 sec) SDP3430 (ES3.1): SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (7 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-21| RET:1 -1 (22 sec) IDLE:RET test | PASS | OFF: 21-21| RET:1 -23 (21 sec) Beagle C1 (ES3.0): SUSPEND:OFF test | FAIL | OFF: 0-0| RET:0 -0 (6 sec) SUSPEND:RET test | FAIL | OFF: 0-0| RET:0 -0 (6 sec) IDLE:OFF test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) IDLE:RET test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: RM-680: fix omap2_init_common_hw compile break
On Thu, Dec 16, 2010 at 11:27:18AM -0600, Omar Ramirez Luna wrote: diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c index 8ba4047..781ed25 100644 --- a/arch/arm/mach-omap2/board-am3517crane.c +++ b/arch/arm/mach-omap2/board-am3517crane.c @@ -47,7 +47,8 @@ static void __init am3517_crane_init_irq(void) omap_board_config = am3517_crane_config; omap_board_config_size = ARRAY_SIZE(am3517_crane_config); - omap2_init_common_hw(NULL, NULL); + omap2_init_common_infrastructure(); + omap2_init_common_devices(NULL, NULL); omap_init_irq(); Once I have the init_early() sorted, hopefully most of the abuse in these callbacks can be moved into the init_early() callback. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion
Hi Govindraj, Raja, Govindraj govindraj.r...@ti.com writes: On Wed, Dec 15, 2010 at 9:42 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Govindraj.R govindraj.r...@ti.com writes: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 1) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 2) Runtime Conversion of McSPI driver Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/ test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 Can you summarize what this test does? On what platforms was this tested? How was it tested for OMAP1 and OMAP2? Using the above mentioned test module we had done some data transfer tests. Platforms used used where : 1) OMAP2430 SDP. 2) OMAP3 (ZOOM boards zoom2/3). 3) OMAP4430 SDP [ Here even basic Ethernet functionality was checked which is over SPI interface] Can you describe a little more about the testing please? What exactly does the data transfer test do? Is it a loopback test? Does it use on-board SPI peripherals? If so, which ones, etc. We boot tested on 2420/n800. Coming to omap1, This driver[omap2_mcspi.c] is applicable only from omap2_plus for omap1 omap_uwire.c is the spi driver file. OK, thanks for clarification. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP3: clean up ASM idle code
Tony, On Tue, Dec 14, 2010 at 11:42 PM, Tony Lindgren t...@atomide.com wrote: Hi Jean, * jean.pi...@newoldbits.com jean.pi...@newoldbits.com [101214 09:28]: From: Jean Pihet j-pi...@ti.com This patch only contains clean-ups and cosmetic changes, no functional change. Clean up of the ASM code: - reorganized the code in logical sections: defines, API functions, internal functions and variables, - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - added comments on the entry and exit points and the interaction with the ROM code for OFF mode restore, - reworked the existing comments for better readability, - reworked the code formating, alignment and white spaces, - added comments for the i443 erratum workarounds, - changed the hardcoded values in favor of existing macros from include files, - clean up of non used symbols. Can you please split it further, it's not obvious from reading it that it does not change anything. That makes sense indeed. How about first do one or more patches to move the code around. Then rework the comments and formatting. I just re-sent the changes as a series '[PATCH 0/7 v4] OMAP3: clean up ASM sleep code'. The patches are now much more readable and it also allowed me to solve issues in a more generic way, cf. for example '[PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses'. Thanks, Tony Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com [101216 09:51]: From: Jean Pihet j-pi...@ti.com This patch only contains clean-ups and cosmetic changes, no functional change. Clean-up of the ASM sleep code, for better readability and easier maintenance. Applies on top of Nishant's latest idle path errata fixes step 2, cf. http://marc.info/?l=linux-omapm=129139584919242w=2 Jean Pihet (7): OMAP2+: use global values for the SRAM PA addresses OMAP3: remove hardcoded values from the ASM sleep code OMAP3: re-organize the ASM sleep code OMAP3: rework of the ASM sleep code execution paths OMAP3: add comments for low power code errata OMAP3: ASM sleep code format rework OMAP3: remove unused code from the ASM sleep code Thanks for splitting it into several patches, looks good to me. Assuming Kevin will queue these, so: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: RM-680: fix omap2_init_common_hw compile break
* Russell King - ARM Linux li...@arm.linux.org.uk [101216 10:05]: On Thu, Dec 16, 2010 at 11:27:18AM -0600, Omar Ramirez Luna wrote: diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c index 8ba4047..781ed25 100644 --- a/arch/arm/mach-omap2/board-am3517crane.c +++ b/arch/arm/mach-omap2/board-am3517crane.c @@ -47,7 +47,8 @@ static void __init am3517_crane_init_irq(void) omap_board_config = am3517_crane_config; omap_board_config_size = ARRAY_SIZE(am3517_crane_config); - omap2_init_common_hw(NULL, NULL); + omap2_init_common_infrastructure(); + omap2_init_common_devices(NULL, NULL); omap_init_irq(); Once I have the init_early() sorted, hopefully most of the abuse in these callbacks can be moved into the init_early() callback. Sounds good to me. Thanks, 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: pm-core broken
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 12/16/2010 10:36 AM, the following: Nishanth Menon n...@ti.com writes: Hi Kevin, Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both fail - I think basically 3630 is broken atm!. Beagleboard: with omap2plus_defconfig + MLO, u-boot.bin from http://www.angstrom-distribution.org/demo/beagleboard/ filesystem is a minimal busybox that I had built and init=/bin/sh to prevent any other apps running in the background - I use the same on SDP3630 and 3430 platforms. branch: pm-core (from your tree). defconfig: omap2plus_defconfig - no changes other than disable RM680 board - currently causes a build failure. At least for Beagle (and I assume it's same for SDP, but don't have one to test with) the problem is that u-boot leaves the USB OTG block in a state that does not idle, and thus prevents CORE from hitting RET. The solution: ensure the USB OTG block is reset. Also in my tree, threre is an usb-otg-reset branch which you can merge with pm-core to test if this helps. Until we have the USB OTG hwmod conversion merged, this temporary hack is needed. After conversion to hwmod, all hwmod will be reset during boot so we are not affected by bootloader (mis)behavior. Arrgh.. we have some sort of regression for .37 formal release (off will probably broken as a result without these patches no for mainline bootloaders/custom bootloaders that dont understand the dependency clearly?). Just to be clear, this is technically not a regression. This has always been true of mainline kernels since most IP blocks are not reset by the kernel. Bootloaders for various boards have always done strange (a.k.a broken) things and left the HW in a state that cannot properly idle. The only solution is to ensure all IPs are fully reset on boot. Anyways, with the 5 patches in usb-otg-reset - test results: SDP3630 (ES1.0): SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (8 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-22| RET:1 -1 (21 sec) IDLE:RET test | PASS | OFF: 22-22| RET:1 -24 (21 sec) SDP3430 (ES3.1): SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (7 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-21| RET:1 -1 (22 sec) IDLE:RET test | PASS | OFF: 21-21| RET:1 -23 (21 sec) Beagle C1 (ES3.0): SUSPEND:OFF test | FAIL | OFF: 0-0| RET:0 -0 (6 sec) SUSPEND:RET test | FAIL | OFF: 0-0| RET:0 -0 (6 sec) IDLE:OFF test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) IDLE:RET test | FAIL | OFF: 0-0| RET:0 -0 (21 sec) Your Beagle u-boot must be leaving something else on besides OTG. I'm using a relatively recent u-boot U-Boot 2010.12-rc1 (Nov 16 2010 - 08:31:35) that I built from source for my Beagle C3 (ES3.0), and suspend/idle test works for me: SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (6 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-4| RET:1 -4 (21 sec) IDLE:RET test | PASS | OFF: 4-4| RET:4 -11 (21 sec) Is it still CORE that's not hitting RET for you? Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory. I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need. Arnd Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you. BR, -- David Sin -- 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
[ANNOUNCE] Public x-loader git tree
Hi all, As all OMAP folks know, x-loader is a first-stage bootloader for OMAPs, derived from the u-boot base code. There have been several forks of the x-loader code within and outside of TI. X-loader has no upstream path as it is currently used only for TI-products. To avoid duplication of efforts, it's high time the code from these different trees was consolidated. Several contributors to x-loader have expressed a desire to have the code developed collaboratively in public. To this end, we have set up an x-loader git tree on gitorious, and seeded it with Steve Sakoman's x-loader tree [1] as of 15 December 2010. (Thanks Steve for unifying so much of the forked code, and getting rid of the dependency on u-boot, and more!). The tree is available at: http://gitorious.org/x-loader/x-loader And a wiki page at: http://gitorious.org/x-loader/pages/Home In addition, a mailing list has been set up at: http://groups.google.com/group/x-loader (Thanks Nishanth Menon for setting these up). Deva and I have volunteered to maintain the x-loader code - everyone is welcome to contribute and help make it better. (This is our first attempt at maintaining a software project - so any help is appreciated). Currently, thanks mainly to Steve's efforts, the tree builds for and works on the following platforms: the OMAP3 EVM, the Overo and Beagle (both 35xx and 37xx), and the Pandaboard. There are also configs for the 1710 h3, 2420 h4, 2430 SDP, 3430 SDP and 3430 Labrador boards - however these don't currently compile. They will be removed soon unless someone steps in to help bring them into shape and maintain them. (We can discuss this on the x-loader mailing list above ;) ). Patches are welcome for any new platforms that would like to be supported in this repository. If there are forked versions out there, let us know and we'll try and integrate them here. Feel free to use this tree, test it, report issues, and help keep the code in shape. - Anand and Deva [1] Steve Sakoman's x-loader tree: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=x-loader.git;a=summary -- 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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishanth Menon n...@ti.com writes:
Nishanth Menon had written, on 12/15/2010 06:05 PM, the following:
Kevin Hilman had written, on 12/15/2010 05:47 PM, the following:
I agree that this additional check in sram_idle should be removed, but
as long as I handle it in omap3_pm_off_mode_enable where the next
states are configured, is'nt that enough or am I missing something?
Setting the next states only sets the default states, but CPUidle
changes them.
Looking closer at omap3_pm_off_mode_enable() though, it already calls
into CPUidle and disables the valid bit for any states that have
*either* MPU or core off.You'll probably just need to extend this
approach to disable only CORE off state(s).
Thx. it is clear now. let me see how to clean this up.
k. Does the attached look any better now :)?
Yes, but, I still don't quite like it. Basically, I'm not crazy about
the errata knowledge being centralized in pm34xx.c. How about this:
Move the Errata handling core code (pm_errata_* PM_ERRATTA_*) to pm.[ch]
as a single patch. Then both pm34xx.c and cpuidle34xx.c would be free
to use it.
This would allow CPUidle handle the errata itself in the 'update_states'
function. Or even better, if CPUidle core can check this errata, it
should probably just never register C7 in the first place, because it is
*never* a valid C-state.
Make sense?
Kevin
I have removed the check
logic from sram_idle path instead made omap3_cpuidle_update_states
little more generic, updated validity of C state based on errata. This
now disables just those C states with core OFF on 3630 ES1.2
in a map, this will now look as follows:
+---+---+---+---++
| MPU | Core | OFF | OFF Enable-36xx|
| Dom | Dom | +---++
C state | State | State | Dis | ES1.1 | ES 1.2 |
+---+---+---+---++
1 | ON| ON| YES | YES | YES|
2 | ON| ON| YES | YES | YES|
3 | RET | ON| YES | YES | YES|
4 | OFF | ON| NO| YES | YES|
5 | RET | RET | YES | YES | YES|
6 | OFF | RET | NO| YES | YES|
7 | OFF | OFF | NO| NO| YES|
+---+---+---+---++
--
Regards,
Nishanth Menon
From bd3d8decf922d7425b9bc9025c7709a9414ad380 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 15 Dec 2010 18:40:29 -0600
Subject: [PATCH 1/2] OMAP3: PM: make omap3_cpuidle_update_states independent
of enable_off_mode
Currently omap3_cpuidle_update_states makes whole sale decision
on which C states to update based on enable_off_mode variable
Instead, achieve the same functionality by independently providing
mpu and core deepest states the system is allowed to achieve and
update the idle states accordingly.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 19 ++-
arch/arm/mach-omap2/pm.h |3 ++-
arch/arm/mach-omap2/pm34xx.c |2 +-
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d50b45..f80d3f6 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -293,25 +293,26 @@ select_state:
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/**
- * omap3_cpuidle_update_states - Update the cpuidle states.
+ * omap3_cpuidle_update_states() - Update the cpuidle states
+ * @mpu_deepest_state: Enable states upto and including this for mpu
domain
+ * @core_deepest_state: Enable states upto and including this for core
domain
*
- * Currently, this function toggles the validity of idle states based upon
- * the flag 'enable_off_mode'. When the flag is set all states are valid.
- * Else, states leading to OFF state set to be invalid.
+ * This goes through the list of states available and enables and disables
the
+ * validity of C states based on deepest state that can be achieved for the
+ * variable domain
*/
-void omap3_cpuidle_update_states(void)
+void omap3_cpuidle_update_states(u32 mpu_deepest_state, u32
core_deepest_state)
{
int i;
for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
struct omap3_processor_cx *cx = omap3_power_states[i];
- if (enable_off_mode) {
+ if ((cx-mpu_state = mpu_deepest_state)
+ (cx-core_state = core_deepest_state)) {
cx-valid = 1;
} else {
- if ((cx-mpu_state == PWRDM_POWER_OFF) ||
- (cx-core_state == PWRDM_POWER_OFF))
- cx-valid = 0;
+ cx-valid = 0;
}
}
}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index aff39d0..3597591 100644
[PATCH] Fix rounding in clocks_calc_mult_shift()
From: John Stultz john.stu...@linaro.org
Russell King reports:
| On the ARM dev boards, we have a 32-bit counter running at 24MHz. Calling
| clocks_calc_mult_shift(mult, shift, 24MHz, NSEC_PER_SEC, 60) gives
| us a multiplier of 2796202666 and a shift of 26.
|
| Over a large counter delta, this produces an error - lets take a count
| from 362976315 to 4280663372:
|
| (4280663372-362976315) * 2796202666 / 2^26 - (4280663372-362976315) *
(1000/24)
| = -38.91872422891230269990
|
| Can we do better?
|
| (4280663372-362976315) * 2796202667 / 2^26 - (4280663372-362976315) *
(1000/24)
| 19.45936211449532822051
|
| which is about twice as good as the 2796202666 multiplier.
|
| Looking at the equivalent divisions obtained, 2796202666 / 2^26 gives
| 41.6665673255920410ns per tick, whereas 2796202667 / 2^26 gives
| 41.6667163372039794ns. The actual value wanted is 1000/24 =
| 41.ns.
Fix this by ensuring we round to nearest when calculating the
multiplier.
Signed-off-by: John Stultz john.stu...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
This is the final piece for my sched_clock() patches, which is required
by the patches to operate correctly with the known-constants-at-compile-
time platforms to avoid the kernel complaining that the constants are
wrong. The above changelog was written by me, patch was from John, and
I tweaked the spacing to match the kernel style.
kernel/time/clocksource.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index c18d7ef..df140cd 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -152,6 +152,7 @@ clocks_calc_mult_shift(u32 *mult, u32 *shift, u32 from, u32
to, u32 minsec)
*/
for (sft = 32; sft 0; sft--) {
tmp = (u64) to sft;
+ tmp += from / 2;
do_div(tmp, from);
if ((tmp sftacc) == 0)
break;
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm-core broken
Kevin Hilman had written, on 12/16/2010 12:40 PM, the following: [...] Your Beagle u-boot must be leaving something else on besides OTG. I'm using a relatively recent u-boot U-Boot 2010.12-rc1 (Nov 16 2010 - 08:31:35) that I built from source for my Beagle C3 (ES3.0), and suspend/idle test works for me: SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (6 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-4| RET:1 -4 (21 sec) IDLE:RET test | PASS | OFF: 4-4| RET:4 -11 (21 sec) Is it still CORE that's not hitting RET for you? yeah, I just think I am darned blind! DSS power domain did not reach state on Beagle and am guessing that could be due to the evil bootloader I was using - anyways, hoping once Senthils' hwmod patches make in, it should be fixed as well.. unless someone has a reset of DSS clock patch or something.. similar to OTG. arrgh.. as far as I am concerned, problem known at least! for some reason, latest 201012-rc1|2|master etc u-boot.bin is goofing up on me.. will look at that later on if no one beats me to it. -- Regards, Nishanth Menon -- 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
BeagleBoard stops at booting kernel with 2.6.37-rc5
Hi, I'm working with linux mainline 2.6.37-rc5 and my custom beagleboard based platform stops at booting the kernel. Is there a fix for this? reading uImage 2432692 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.37-rc5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2432628 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Elvis Dowson -- 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: BeagleBoard stops at booting kernel with 2.6.37-rc5
On Thu, Dec 16, 2010 at 2:19 PM, Elvis Dowson elvis.dow...@mac.com wrote: Hi, I'm working with linux mainline 2.6.37-rc5 and my custom beagleboard based platform stops at booting the kernel. Is there a fix for this? reading uImage 2432692 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.37-rc5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2432628 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. If it stops there, double check your bootarg's as with 2.6.37+ you might be using the omap-serial vs the old generic serial driver... ttyO2 (O in Omap) vs ttyS2.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard stops at booting kernel with 2.6.37-rc5
Robert Nelson had written, on 12/16/2010 02:25 PM, the following: On Thu, Dec 16, 2010 at 2:19 PM, Elvis Dowson elvis.dow...@mac.com wrote: Hi, I'm working with linux mainline 2.6.37-rc5 and my custom beagleboard based platform stops at booting the kernel. Is there a fix for this? reading uImage 2432692 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.37-rc5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2432628 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. If it stops there, double check your bootarg's as with 2.6.37+ you might be using the omap-serial vs the old generic serial driver... ttyO2 (O in Omap) vs ttyS2.. one more thing: in fs - getty dependency might exist - you could choose something similar to what I did on my bare busybox install: http://nishanthmenon.blogspot.com/2010/10/tired-of-ttysx-and-ttyox.html -- Regards, Nishanth Menon -- 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: BeagleBoard stops at booting kernel with 2.6.37-rc5
Elvis, please enable earlyprintk in your kernel config and add earlyprintk to your boot args. this will provide a more detailed boot log even if the tty is incorrect. Dave On 12/16/2010 02:19 PM, Elvis Dowson wrote: Hi, I'm working with linux mainline 2.6.37-rc5 and my custom beagleboard based platform stops at booting the kernel. Is there a fix for this? reading uImage 2432692 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.37-rc5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2432628 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Elvis Dowson -- 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: BeagleBoard stops at booting kernel with 2.6.37-rc5
Hi, On Dec 17, 2010, at 12:25 AM, Robert Nelson wrote: If it stops there, double check your bootarg's as with 2.6.37+ you might be using the omap-serial vs the old generic serial driver... ttyO2 (O in Omap) vs ttyS2.. Thanks, that fixed the problem. I changed to ttyO2. Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm-core broken
Nishanth Menon had written, on 12/16/2010 02:15 PM, the following: Kevin Hilman had written, on 12/16/2010 12:40 PM, the following: [...] Your Beagle u-boot must be leaving something else on besides OTG. I'm using a relatively recent u-boot U-Boot 2010.12-rc1 (Nov 16 2010 - 08:31:35) that I built from source for my Beagle C3 (ES3.0), and suspend/idle test works for me: SUSPEND:OFF test | PASS | OFF: 0-1| RET:0 -0 (6 sec) SUSPEND:RET test | PASS | OFF: 1-1| RET:0 -1 (6 sec) IDLE:OFF test | PASS | OFF: 1-4| RET:1 -4 (21 sec)IDLE:RET test | PASS | OFF: 4-4| RET:4 -11 (21 sec) Is it still CORE that's not hitting RET for you? yeah, I just think I am darned blind! DSS power domain did not reach state on Beagle and am guessing that could be due to the evil bootloader I was using - anyways, hoping once Senthils' hwmod patches make in, it should be fixed as well.. unless someone has a reset of DSS clock patch or something.. similar to OTG. arrgh.. as far as I am concerned, problem known at least! for some reason, latest 201012-rc1|2|master etc u-boot.bin is goofing up on me.. will look at that later on if no one beats me to it. just to close the loop - enabling CONFIG_OMAP2_DSS in my .config (thanks Kevin for the offline suggestion), at least suspend works for OFF and RET states. Idle path some how hangs up - for the moment, I guess I will leave it alone unless someone else would like to dig further.. -- Regards, Nishanth Menon -- 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 0/4] Introduce hardware spinlock framework
On Tue, Dec 14, 2010 at 8:40 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Tue, Dec 14, 2010 at 7:06 PM, Greg KH g...@kroah.com wrote: Like the most important one, why is this generic code if it's only for one specific platform? We started out with an omap-specific driver, but Tony preferred that we make this a platform-agnostic framework, in order to keep the IPC drivers that will use it generic, and assuming that more users will show up for such framework. I was just told about additional users for this (thanks Mugdha): 1) There are several platforms (such as omap3530 and omapl1xx) that have no such hardware support, but would still need to use the same IPC drivers (to communicate with their DSP). The only way to achieve mutual exclusion on those platforms is by using a shared-memory synchronization algorithm called Peterson's Algorithm [1]. We would still need the same hwspinlock framework for that - the busy looping, the timeout, the various locking schemes, the resource allocation - are all still valid. The only difference is the actual lock implementation. 2) The C6474, which is a multi-core DSP device [2], have Linux running on one of its cores, and would be using the same IPC drivers, too. C6474 has hardware support for synchronization, which would also benefit from such hwspinlock module (btw the C6474 has a richer hardware module that would need more than the hwspinlock framework offer today - it also supports queuing, owner semantics and interrupt notification to let a processor know when it acquires a lock, so it wouldn't have to spin..) Thanks, Ohad. [1] http://en.wikipedia.org/wiki/Peterson's_algorithm [2] http://focus.ti.com/docs/prod/folders/print/tms320c6474.html To me it sounds reasonable, but both ways (framework / omap-specific driver) will work for us just fine, and I can switch back to a misc driver if this is preferred. The complete discussion of v1 is at: http://comments.gmane.org/gmane.linux.kernel/1049802 We also discussed this at v2 of the patches with David, see the complete discussion at: http://comments.gmane.org/gmane.linux.kernel/1067016 Thanks, Ohad. thanks, greg k-h -- 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 0/4] Introduce hardware spinlock framework
On Tue, Dec 14, 2010 at 08:40:28PM +0200, Ohad Ben-Cohen wrote: On Tue, Dec 14, 2010 at 7:06 PM, Greg KH g...@kroah.com wrote: Can you please have a look and say if this looks OK ? Look at what, I don't see a patch here. Here's the complete patchset: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39833.html If you prefer, I can resubmit. I've seen a lot of discussion about this, are all of the review comments now addressed? Yes, all comments were addressed in this v3 iteration, and this thread has been idle for about 10 days. That's because we are all busy with other things :( Sorry, I really don't have the time at the moment to review this code, nor does it seem to affect areas that I maintain, so I don't understand what you are looking for from me. confused, greg k-h -- 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
BeagleBoard hangs at Bluetooth subsystem startup with 2.6.37-rc6 mainline
Hi, I just updated to mainline linux kernel 2.6.37-rc6, and built a new omap3-console-image recipe based rootfs using OE. I get the following error with Bluetooth. I've disabled bluetooth in the kernel and do not have a bluetooth device connected to the custom beagleboard platform. With earlier rootfs builds it used to progress beyond this stage, even though bluetooth wasn't detect. Now it hangs at this point: Starting syslogd/klogd: done * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem: Can't get port settings: Input/output error Can't initialize device: Input/output error Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
On Thu, Dec 16, 2010 at 11:01 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote: Hi, On Thu, Dec 16, 2010 at 10:32 AM, Kanigeri, Hari h-kanige...@ti.com wrote: @@ -130,12 +120,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) l = mbox_read_reg(MAILBOX_REVISION); pr_debug(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f)); - if (cpu_is_omap44xx()) - l = OMAP4_SMARTIDLE; - else - l = SMARTIDLE | AUTOIDLE; - mbox_write_reg(l, MAILBOX_SYSCONFIG); - The OMAP4 mailbox sysconfig register bits are laid out differently from previous OMAP mailbox's. Example is smart idle bit location is different from previous OMAPs. Can I know as how are you handling this aspect in hwmod code ? hwmod framework provides definition for both IP models (omap_hwmod_sysc_type1for omap2/3 or omap_hwmod_sysc_type2 for omap4), these are located at arch/arm/mach-omap2/omap_hwmod_common_data.c Thanks, Omar. Best regards, Hari Kanigeri -- 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
What is the purpose of the different linux omap branches?
Hello All I see there is a master and a pm branch. What's the difference? Why would I use each of these? Also, when is 32.6.37 expected to be done? Thanks Charles -- 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: BeagleBoard hangs at Bluetooth subsystem startup with 2.6.37-rc6 mainline
Elvis Dowson had written, on 12/16/2010 03:13 PM, the following: Hi, I just updated to mainline linux kernel 2.6.37-rc6, and built a new omap3-console-image recipe based rootfs using OE. I get the following error with Bluetooth. I've disabled bluetooth in the kernel and do not have a bluetooth device connected to the custom beagleboard platform. With earlier rootfs builds it used to progress beyond this stage, even though bluetooth wasn't detect. Now it hangs at this point: Starting syslogd/klogd: done * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem: Can't get port settings: Input/output error Can't initialize device: Input/output error This belongs to OE ML - http://wiki.openembedded.net/index.php/Mailing_lists -- Regards, Nishanth Menon -- 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: BeagleBoard hangs at Bluetooth subsystem startup with 2.6.37-rc6 mainline
Hi, On Dec 17, 2010, at 1:13 AM, Elvis Dowson wrote: Starting syslogd/klogd: done * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem: Can't get port settings: Input/output error Can't initialize device: Input/output error Sorry for posting it in the wrong mailing list. I'm posting the solution, in case it helps someone else. This is related to the serial port configuration once again, and more specifically, you have to change the /etc/inittab file as follows: O:2345:respawn:/sbin/getty 115200 ttyO2 Best regards, Elvis Dowson -- 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 0/4] Introduce hardware spinlock framework
On Thu, Dec 16, 2010 at 11:08 PM, Greg KH g...@kroah.com wrote: I've seen a lot of discussion about this, are all of the review comments now addressed? Yes, all comments were addressed in this v3 iteration, and this thread has been idle for about 10 days. That's because we are all busy with other things :( Oh sure, my intention was only positive (to demonstrate that there are no outstanding comments), sorry if it sounded differently than intended. Sorry, I really don't have the time at the moment to review this code, nor does it seem to affect areas that I maintain, so I don't understand what you are looking for from me. Sorry for the noise - I contacted you because you maintain the driver core, in the hope you could suggest where this can go through. Tony, Andrew, can you please have a look ? Any comment or suggestion is appreciated. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP NAND redux
Hello All
Over the last while I have been working on getting ubifs working on omap3530
using 16-bit NAND with the latest 2.6.37 prefetch code. This is basically a
tweaked Overo kernel.
Here is what I found:
After initial exploration I found that there were three problem:
* ECC bytes not being read correctly during sub-page reads.
* Disabling prefetch meant that the flash was not being read at all.
* NAND access seems to have slowed down significantly.
Both these boiled down to one root cause. After the prefetch changes,
nand-IO_ADDR_R is set to an address that only works within the context of
the prefetch code. It no longer works if prefetch is disabled. Execution of:
static void omap_read_buf16(struct mtd_info *mtd, u_char *buf, int len)
{
struct nand_chip *nand = mtd-priv;
ioread16_rep(nand-IO_ADDR_R, buf, len / 2);
}
Even if prefetch is enabled, subpage reads that are not 32-bit aligned call
the above function which means the ECC does not read correctly - resulting in
ECC errors.
I managed to work around this by applying the following patch to force all
buffer reads to u32 alignment:
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -245,6 +245,18 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
int ret = 0;
u32 *p = (u32 *)buf;
+ /* u32 align the buffer and read */
+ /* NB: This assumes the buf ptr can be aligned *down* which is a
valid.
+* Assumption when dealing with ecc buffers etc.
+*/
+ u32 addr = (u32)p;
+
+ int diff = addr 3;
+ addr -= diff;
+ len += diff;
+ len = (len + 3) ~3;
+ p = (u32 *)addr;
+
/* take care of subpage reads */
if (len % 4) {
if (info-nand.options NAND_BUSWIDTH_16)
Yeah I know that is ugly, but it works!
Prefetch is enabled, dma is disabled. ECC is done in software.
OK, that gives me a working UBIFS, but I found something else...
NAND access has got way, way slower since 2.6.34.
I created a 2MB file foo then do the following:
sync; date; cp foo bar; sync; date
In 2.6.34 the time between the two dates was 3 seconds.
In 2.6.37 this now takes 14 seconds!
Now question time:
1) How well has the prefetch code been tested?
2) Does it work with prefetch disabled?
3) Has it been performance tested?
4) What should the value in nand-IO_ADDR_R be?
Thanks
Charles
--
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: What is the purpose of the different linux omap branches?
Charles Manning mannin...@actrix.gen.nz writes: I see there is a master and a pm branch. What's the difference? Why would I use each of these? Please use only the master branch. The pm branch (which I maintain) is an unstable branch only used for ongoing development of power management features which are under heavy development and rapid change. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP1: clock_data: use runtime cpu / machine checks
On Mon, Dec 13, 2010 at 1:24 AM, Paul Walmsley p...@pwsan.com wrote: Hello Janusz, Cory, On Sat, 11 Dec 2010, Janusz Krzysztofik wrote: Otherwise multi-omap1 configurations may set wrong clock speed. Created and tested against l-o master on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Thanks, this is a significant step forward in building a good omap1_defconfig. Cory, do you mind testing this out? If it works for you also, let's plan to take this for 2.6.38. Sure, no problem, I'll add it to my testing queue. - Cory -- 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] dspbridge: Fix atoi to support hexadecimal numbers correctly
Hi everybody,
Ping ?
On Sunday 12 December 2010 14:39:37 Laurent Pinchart wrote:
For some strange reason, the DSP base image node/object properties
description string stores hexadecimal numbers with a 'h' or 'H' suffix
instead of a '0x' prefix. This causes parsing issue because the
dspbridge atoi() implementation relies on strict_strtoul(), which will
return an error because of the trailing 'h' character.
As the atoi() return value is never checked for an error anyway, replace
strict_strtoul() with simple_strtoul() to ignore the suffix.
This fix gets rid of the following assertion failed messages that were
printed when running the dsp-dummy test application.
drivers/staging/tidspbridge/rmgr/nldr.c, line 1691:
Assertion (segid == MEMINTERNALID || segid == MEMEXTERNALID) failed.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/tidspbridge/rmgr/dbdcd.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c
b/drivers/staging/tidspbridge/rmgr/dbdcd.c index 3581a55..b76f26c 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -1020,8 +1020,6 @@ static s32 atoi(char *psz_buf)
{
char *pch = psz_buf;
s32 base = 0;
- unsigned long res;
- int ret_val;
while (isspace(*pch))
pch++;
@@ -1033,9 +1031,7 @@ static s32 atoi(char *psz_buf)
base = 16;
}
- ret_val = strict_strtoul(pch, base, res);
-
- return ret_val ? : res;
+ return simple_strtoul(pch, NULL, base);
}
/*
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Fri, Dec 17, 2010 at 5:02 AM, David Sin david...@ti.com wrote: On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory. I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need. Arnd Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you. I get the impression with the ARM graphics, that you just have a lot of separate drivers for separate IP blocks all providing some misc random interfaces to userspace where some binary driver binds all the functionality together into a useful whole, which seems like a really bad design. Generally on x86, the tiling hw is part of the GPU and is exposed as part of a coherent GPU driver. I'm just wonder what the use-cases for this tiler are and what open apps can use it for? Dave. -- 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
Section mismatch warnings 2.6.37-rc6
Hi, When I build the linux mainline 2.6.37-rc6, I get 3 section mismatch warnings. What do they indicate? $ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage -j6 LOCALVERSION= CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.data+0x1b70): Section mismatch in reference from the variable etb_driver to the function .init.text:etb_probe() The variable etb_driver references the function __init etb_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x1bbc): Section mismatch in reference from the variable etm_driver to the function .init.text:etm_probe() The variable etm_driver references the function __init etm_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x3477c): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() The variable twl_driver references the function __init twl_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Elvis Dowson -- 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] adding gpmc configuration functions, west bridge related
This patch adds and exports gpmc configuration functions.
'gpmc' configuration functions will be used by
westbridge device controller driver in staging tree.
This patch is required to get westbridge device controller driver
out of staging tree.
Signed-off-by: Sutharsan Ramamoorthy s...@cypress.com
---
diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff
linux-2.6.37_vanilla/arch/arm/mach-omap2/Makefile
linux-2.6.37-cywb/arch/arm/mach-omap2/Makefile
--- linux-2.6.37_vanilla/arch/arm/mach-omap2/Makefile 2010-11-29
20:42:04.0 -0800
+++ linux-2.6.37-cywb/arch/arm/mach-omap2/Makefile 2010-12-13
16:04:08.378446603 -0800
@@ -182,6 +182,7 @@ obj-y += $(usbfs-m)
$(usbfs-y)
obj-y += usb-musb.o
obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o
obj-y += usb-ehci.o
+obj-$(CONFIG_WESTBRIDGE_ASTORIA)+= usb-cywb-pnand.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff
linux-2.6.37_vanilla/arch/arm/mach-omap2/usb-cywb-pnand.c
linux-2.6.37-cywb/arch/arm/mach-omap2/usb-cywb-pnand.c
--- linux-2.6.37_vanilla/arch/arm/mach-omap2/usb-cywb-pnand.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.37-cywb/arch/arm/mach-omap2/usb-cywb-pnand.c 2010-12-14
15:51:13.710787480 -0800
@@ -0,0 +1,182 @@
+/*
+ * linux /arch/arm/mach-omap2/usb-cywb-pnand.c
+ *
+ * Copyright (C) 2010 Cypress Semiconductor
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ */
+
+#include linux/module.h
+
+#include plat/gpmc.h
+
+/*
+ * chip select number on GPMC ( 0..7 )
+ */
+#define AST_GPMC_CS 4
+
+/*
+ * for use by gpmc_set_timings api, measured in ns, not clocks
+ */
+#define WB_GPMC_BUSCYC_t(7 * 6)
+#define WB_GPMC_CS_t_o_n(0)
+#define WB_GPMC_ADV_t_o_n (0)
+#define WB_GPMC_OE_t_o_n(0)
+#define WB_GPMC_OE_t_o_f_f (5 * 6)
+#define WB_GPMC_WE_t_o_n(1 * 6)
+#define WB_GPMC_WE_t_o_f_f (5 * 6)
+#define WB_GPMC_RDS_ADJ (2 * 6)
+#define WB_GPMC_RD_t_a_c_c (WB_GPMC_OE_t_o_f_f + WB_GPMC_RDS_ADJ)
+#define WB_GPMC_WR_t_a_c_c (WB_GPMC_BUSCYC_t)
+
+#define GPMC_16BIT_MODE 0
+#define GPMC_RETIME 1
+
+/*
+ * GPMC_CONFIG7[cs] register bit fields
+ * AS_CS_MASK - 3 bit mask for A26,A25,A24,
+ * AS_CS_BADDR - 6 BIT VALUE A29 ...A24
+ * CSVALID_B - CSVALID bit on GPMC_CONFIG7[cs] register
+ */
+#define AS_CS_MASK (0X7 8)
+#define AS_CS_BADDR 0x02
+#define CSVALID_B (1 6)
+
+#define BLKSZ_4K 0x1000
+
+/*
+ * switch GPMC DATA bus mode
+ */
+void cywb_gpmc_enable_16bit_bus(bool dbus16_enabled)
+{
+ uint32_t tmp32;
+
+ /*
+* disable gpmc CS4 operation 1st
+*/
+ tmp32 = gpmc_cs_read_reg(AST_GPMC_CS,
+ GPMC_CS_CONFIG7) ~GPMC_CONFIG7_CSVALID;
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG7, tmp32);
+
+ /*
+* GPMC NAND data bus can be 8 or 16 bit wide
+*/
+ if (dbus16_enabled) {
+ printk(KERN_INFO enabling 16 bit bus\n);
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
+ (GPMC_CONFIG1_DEVICETYPE(2) |
+ GPMC_CONFIG1_WAIT_PIN_SEL(2) |
+ GPMC_CONFIG1_DEVICESIZE_16)
+ );
+ } else {
+ printk(KERN_INFO enabling 8 bit bus\n);
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
+ (GPMC_CONFIG1_DEVICETYPE(2) |
+ GPMC_CONFIG1_WAIT_PIN_SEL(2))
+ );
+ }
+
+ /*
+* re-enable astoria CS operation on GPMC
+*/
+gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG7,
+ (tmp32 | GPMC_CONFIG7_CSVALID));
+}
+
+int cywb_pnand_platform_retime(int action, bool dbus16_enabled)
+{
+ u32 tmp32;
+ struct gpmc_timings timings;
+ int retval;
+
+ switch (action) {
+
+ case GPMC_16BIT_MODE:
+ cywb_gpmc_enable_16bit_bus(dbus16_enabled);
+ retval = 0;
+ break;
+ case GPMC_RETIME:
+
Re: [PATCH] adding gpmc configuration functions, west bridge related
On Thu, Dec 16, 2010 at 04:33:50PM -0800, Sutharsan wrote:
This patch adds and exports gpmc configuration functions.
'gpmc' configuration functions will be used by
westbridge device controller driver in staging tree.
This patch is required to get westbridge device controller driver
out of staging tree.
Well, it's one step to getting the code out, not the only thing :)
Signed-off-by: Sutharsan Ramamoorthy s...@cypress.com
---
diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff
linux-2.6.37_vanilla/arch/arm/mach-omap2/Makefile
linux-2.6.37-cywb/arch/arm/mach-omap2/Makefile
--- linux-2.6.37_vanilla/arch/arm/mach-omap2/Makefile 2010-11-29
20:42:04.0 -0800
+++ linux-2.6.37-cywb/arch/arm/mach-omap2/Makefile2010-12-13
16:04:08.378446603 -0800
@@ -182,6 +182,7 @@ obj-y += $(usbfs-m)
$(usbfs-y)
obj-y+= usb-musb.o
obj-$(CONFIG_MACH_OMAP2_TUSB6010)+= usb-tusb6010.o
obj-y+= usb-ehci.o
+obj-$(CONFIG_WESTBRIDGE_ASTORIA)+= usb-cywb-pnand.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y+= $(onenand-m) $(onenand-y)
diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff
linux-2.6.37_vanilla/arch/arm/mach-omap2/usb-cywb-pnand.c
linux-2.6.37-cywb/arch/arm/mach-omap2/usb-cywb-pnand.c
--- linux-2.6.37_vanilla/arch/arm/mach-omap2/usb-cywb-pnand.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.37-cywb/arch/arm/mach-omap2/usb-cywb-pnand.c2010-12-14
15:51:13.710787480 -0800
@@ -0,0 +1,182 @@
+/*
+ * linux /arch/arm/mach-omap2/usb-cywb-pnand.c
+ *
+ * Copyright (C) 2010 Cypress Semiconductor
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
Do you _really_ mean any later version? Are you aware of the issues
involved here?
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
These two paragraphs are not needed.
+ */
+
+#include linux/module.h
+
+#include plat/gpmc.h
+
+/*
+ * chip select number on GPMC ( 0..7 )
+ */
+#define AST_GPMC_CS 4
+
+/*
+ * for use by gpmc_set_timings api, measured in ns, not clocks
+ */
+#define WB_GPMC_BUSCYC_t(7 * 6)
+#define WB_GPMC_CS_t_o_n(0)
+#define WB_GPMC_ADV_t_o_n (0)
+#define WB_GPMC_OE_t_o_n(0)
+#define WB_GPMC_OE_t_o_f_f (5 * 6)
+#define WB_GPMC_WE_t_o_n(1 * 6)
+#define WB_GPMC_WE_t_o_f_f (5 * 6)
+#define WB_GPMC_RDS_ADJ (2 * 6)
+#define WB_GPMC_RD_t_a_c_c (WB_GPMC_OE_t_o_f_f + WB_GPMC_RDS_ADJ)
+#define WB_GPMC_WR_t_a_c_c (WB_GPMC_BUSCYC_t)
+
+#define GPMC_16BIT_MODE 0
+#define GPMC_RETIME 1
+
+/*
+ * GPMC_CONFIG7[cs] register bit fields
+ * AS_CS_MASK - 3 bit mask for A26,A25,A24,
+ * AS_CS_BADDR - 6 BIT VALUE A29 ...A24
+ * CSVALID_B - CSVALID bit on GPMC_CONFIG7[cs] register
+ */
+#define AS_CS_MASK (0X7 8)
+#define AS_CS_BADDR 0x02
+#define CSVALID_B (1 6)
+
+#define BLKSZ_4K 0x1000
+
+/*
+ * switch GPMC DATA bus mode
+ */
+void cywb_gpmc_enable_16bit_bus(bool dbus16_enabled)
+{
+ uint32_t tmp32;
Ick, please use the real types for the kernel (u32 in this case.)
+
+ /*
+ * disable gpmc CS4 operation 1st
+ */
+ tmp32 = gpmc_cs_read_reg(AST_GPMC_CS,
+ GPMC_CS_CONFIG7) ~GPMC_CONFIG7_CSVALID;
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG7, tmp32);
+
+ /*
+ * GPMC NAND data bus can be 8 or 16 bit wide
+ */
+ if (dbus16_enabled) {
+ printk(KERN_INFO enabling 16 bit bus\n);
Why print this for the whole world to see? Also, no prefix saying
exactly what code is printing this out? Is this even needed?
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
+ (GPMC_CONFIG1_DEVICETYPE(2) |
+ GPMC_CONFIG1_WAIT_PIN_SEL(2) |
+ GPMC_CONFIG1_DEVICESIZE_16)
+ );
Odd place to put a trailing ')' character.
+ } else {
+ printk(KERN_INFO enabling 8 bit bus\n);
Same as above.
+ gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
+ (GPMC_CONFIG1_DEVICETYPE(2) |
+ GPMC_CONFIG1_WAIT_PIN_SEL(2))
+
Re: [PATCHv5 09/10] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Thara Gopinath th...@ti.com writes:
This patch adds debug support to the voltage and smartreflex drivers.
This means a whole bunch of voltage processor and smartreflex
parameters are now visible through the pm debugfs.
The voltage parameters can be viewed at
/debug/voltage/vdd_x/parameter
and the smartreflex parameters can be viewed at
/debug/voltage/vdd_x/smartreflex/parameter
Also smartreflex n-target values are now exposed out at
/debug/voltage/vdd_x/smartreflex/nvalue/voltage
This is a read-write interface which means user has the
flexibility to change the n-target values for any opp.
I think this comment needs updating, since the write
interface is now removed from this series as we agreed upon.
Kevin
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 46 -
arch/arm/mach-omap2/voltage.c | 66
+
2 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index eee23d0..52a05b3 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -31,6 +31,7 @@
#include pm.h
#define SMARTREFLEX_NAME_LEN 16
+#define NVALUE_NAME_LEN 40
#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
@@ -817,8 +818,9 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
- struct dentry *vdd_dbg_dir, *dbg_dir;
- int ret = 0;
+ struct dentry *vdd_dbg_dir, *dbg_dir, *nvalue_dir;
+ struct omap_volt_data *volt_data;
+ int i, ret = 0;
if (!sr_info) {
dev_err(pdev-dev, %s: unable to allocate sr_info\n,
@@ -897,6 +899,46 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUGO, dbg_dir,
(void *)sr_info, pm_sr_fops);
+ (void) debugfs_create_x32(errweight, S_IRUGO, dbg_dir,
+ sr_info-err_weight);
+ (void) debugfs_create_x32(errmaxlimit, S_IRUGO, dbg_dir,
+ sr_info-err_maxlimit);
+ (void) debugfs_create_x32(errminlimit, S_IRUGO, dbg_dir,
+ sr_info-err_minlimit);
+
+ nvalue_dir = debugfs_create_dir(nvalue, dbg_dir);
+ if (IS_ERR(nvalue_dir)) {
+ dev_err(pdev-dev, %s: Unable to create debugfs directory
+ for n-values\n, __func__);
+ return PTR_ERR(nvalue_dir);
+ }
+
+ omap_voltage_get_volttable(sr_info-voltdm, volt_data);
+ if (!volt_data) {
+ dev_warn(pdev-dev, %s: No Voltage table for the
+ corresponding vdd vdd_%s. Cannot create debugfs
+ entries for n-values\n,
+ __func__, sr_info-voltdm-name);
+ return -ENODATA;
+ }
+
+ for (i = 0; i sr_info-nvalue_count; i++) {
+ char *name;
+ char volt_name[32];
+
+ name = kzalloc(NVALUE_NAME_LEN + 1, GFP_KERNEL);
+ if (!name) {
+ dev_err(pdev-dev, %s: Unable to allocate memory
+ for n-value directory name\n, __func__);
+ return -ENOMEM;
+ }
+
+ strcpy(name, volt_);
+ sprintf(volt_name, %d, volt_data[i].volt_nominal);
+ strcat(name, volt_name);
+ (void) debugfs_create_x32(name, S_IRUGO | S_IWUGO, nvalue_dir,
+ (sr_info-nvalue_table[i].nvalue));
+ }
return ret;
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4ecdc68..1f84939 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -238,6 +238,47 @@ static struct dentry *voltage_dir;
static void (*vc_init) (struct omap_vdd_info *vdd);
static void (*vdd_data_configure) (struct omap_vdd_info *vdd);
+/* Voltage debugfs support */
+static int vp_volt_debug_get(void *data, u64 *val)
+{
+ struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
+ u8 vsel;
+
+ if (!vdd) {
+ pr_warning(Wrong paramater passed\n);
+ return -EINVAL;
+ }
+
+ vsel = prm_read_mod_reg(vdd-vp_reg.prm_mod, vdd-vp_offs.voltage);
+ pr_notice(curr_vsel = %x\n, vsel);
+
+ if (!vdd-pmic_info-vsel_to_uv) {
+ pr_warning(PMIC function to convert vsel to voltage
+ in uV not registerd\n);
+ return -EINVAL;
+ }
+
+ *val = vdd-pmic_info-vsel_to_uv(vsel);
+ return 0;
+}
+
+static int nom_volt_debug_get(void *data, u64 *val)
+{
+ struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
+
[PATCH 0/5] staging:tidspbridge - Audit headers file
The following set of patches performs a code clean up derived from a header files audit. Removes unused macros, constants, functions, structs, struct members, typedefs and its dependencies. Armando Uribe (5): staging:tidspbridge - Remove unused defined constants staging:tidspbridge - Remove unused functions staging:tidspbridge - Remove unused structs. staging:tidspbridge - Remove unused typedefs staging:tidspbridge - Remove trivial header files drivers/staging/tidspbridge/core/io_sm.c |4 - drivers/staging/tidspbridge/core/tiomap3430.c |2 - drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 +- .../tidspbridge/include/dspbridge/brddefs.h|2 - .../tidspbridge/include/dspbridge/cfgdefs.h| 19 --- .../staging/tidspbridge/include/dspbridge/chnl.h | 21 --- .../tidspbridge/include/dspbridge/chnldefs.h |3 - .../tidspbridge/include/dspbridge/chnlpriv.h | 13 -- .../staging/tidspbridge/include/dspbridge/cod.h| 13 +-- .../staging/tidspbridge/include/dspbridge/dbdefs.h | 26 .../tidspbridge/include/dspbridge/dbldefs.h| 141 --- .../staging/tidspbridge/include/dspbridge/dbll.h |6 - .../tidspbridge/include/dspbridge/dblldefs.h | 65 - .../tidspbridge/include/dspbridge/dehdefs.h| 32 - .../staging/tidspbridge/include/dspbridge/dev.h| 59 + .../staging/tidspbridge/include/dspbridge/disp.h | 15 ++- .../tidspbridge/include/dspbridge/dispdefs.h | 35 - .../staging/tidspbridge/include/dspbridge/drv.h| 31 + .../tidspbridge/include/dspbridge/drvdefs.h| 25 .../tidspbridge/include/dspbridge/dspapi-ioctl.h |8 - .../tidspbridge/include/dspbridge/dspdefs.h| 10 +- .../staging/tidspbridge/include/dspbridge/dspdrv.h |2 - .../staging/tidspbridge/include/dspbridge/dspio.h |4 +- .../tidspbridge/include/dspbridge/dspioctl.h |5 - .../tidspbridge/include/dspbridge/dynamic_loader.h |2 - .../tidspbridge/include/dspbridge/host_os.h|9 -- drivers/staging/tidspbridge/include/dspbridge/io.h | 29 ++--- .../staging/tidspbridge/include/dspbridge/io_sm.h | 143 +--- .../staging/tidspbridge/include/dspbridge/iodefs.h | 36 - .../staging/tidspbridge/include/dspbridge/ldr.h| 29 .../staging/tidspbridge/include/dspbridge/mbx_sh.h | 40 -- .../staging/tidspbridge/include/dspbridge/node.h | 20 +--- .../staging/tidspbridge/include/dspbridge/pwr.h|8 +- .../staging/tidspbridge/include/dspbridge/pwr_sh.h | 33 - .../include/dspbridge/resourcecleanup.h| 11 -- .../staging/tidspbridge/include/dspbridge/rms_sh.h |9 -- .../staging/tidspbridge/include/dspbridge/strm.h | 62 - .../tidspbridge/include/dspbridge/strmdefs.h |2 - drivers/staging/tidspbridge/pmgr/cod.c | 14 +-- drivers/staging/tidspbridge/pmgr/dbll.c| 41 -- drivers/staging/tidspbridge/pmgr/dev.c | 10 +- drivers/staging/tidspbridge/pmgr/io.c |1 - drivers/staging/tidspbridge/rmgr/dbdcd.c |2 +- drivers/staging/tidspbridge/rmgr/drv_interface.c |1 - drivers/staging/tidspbridge/rmgr/nldr.c|3 - drivers/staging/tidspbridge/rmgr/node.c|1 - 46 files changed, 55 insertions(+), 996 deletions(-) delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbldefs.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dehdefs.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dispdefs.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/drvdefs.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/iodefs.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/ldr.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/pwr_sh.h -- 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/5] staging:tidspbridge - Remove unused defined constants
Remove defined constants not being used. Signed-off-by: Armando Uribe x0095...@ti.com --- .../tidspbridge/include/dspbridge/brddefs.h|2 - .../tidspbridge/include/dspbridge/cfgdefs.h| 13 -- .../tidspbridge/include/dspbridge/chnldefs.h |3 - .../tidspbridge/include/dspbridge/chnlpriv.h | 13 -- .../staging/tidspbridge/include/dspbridge/cod.h|3 - .../staging/tidspbridge/include/dspbridge/dbdefs.h | 26 - .../tidspbridge/include/dspbridge/dbldefs.h| 11 - .../tidspbridge/include/dspbridge/dehdefs.h|1 - .../staging/tidspbridge/include/dspbridge/drv.h| 15 --- .../tidspbridge/include/dspbridge/dspdefs.h|6 --- .../staging/tidspbridge/include/dspbridge/dspdrv.h |2 - .../tidspbridge/include/dspbridge/dspioctl.h |5 -- .../tidspbridge/include/dspbridge/dynamic_loader.h |2 - .../staging/tidspbridge/include/dspbridge/io_sm.h |1 - .../staging/tidspbridge/include/dspbridge/iodefs.h |2 - .../staging/tidspbridge/include/dspbridge/mbx_sh.h | 40 .../staging/tidspbridge/include/dspbridge/pwr_sh.h |4 -- .../staging/tidspbridge/include/dspbridge/rms_sh.h |9 .../tidspbridge/include/dspbridge/strmdefs.h |2 - drivers/staging/tidspbridge/pmgr/dev.c |2 +- 20 files changed, 1 insertions(+), 161 deletions(-) diff --git a/drivers/staging/tidspbridge/include/dspbridge/brddefs.h b/drivers/staging/tidspbridge/include/dspbridge/brddefs.h index f80d9a5..725d7b3 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/brddefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/brddefs.h @@ -24,9 +24,7 @@ #define BRD_IDLE0x1/* Monitor Loaded, but suspended. */ #define BRD_RUNNING 0x2/* Monitor loaded, and executing. */ #define BRD_UNKNOWN 0x3/* Board state is indeterminate. */ -#define BRD_SYNCINIT0x4 #define BRD_LOADED 0x5 -#define BRD_LASTSTATE BRD_LOADED /* Set to highest legal board state. */ #define BRD_SLEEP_TRANSITION 0x6 /* Sleep transition in progress */ #define BRD_HIBERNATION 0x7/* MPU initiated hibernation */ #define BRD_RETENTION 0x8 /* Retention mode */ diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h index f403c01..c3f04f8 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h @@ -19,25 +19,12 @@ #ifndef CFGDEFS_ #define CFGDEFS_ -/* Maximum length of module search path. */ -#define CFG_MAXSEARCHPATHLEN255 - -/* Maximum length of general paths. */ -#define CFG_MAXPATH 255 - /* Host Resources: */ #define CFG_MAXMEMREGISTERS 9 -#define CFG_MAXIOPORTS 20 -#define CFG_MAXIRQS 7 -#define CFG_MAXDMACHANNELS 7 /* IRQ flag */ #define CFG_IRQSHARED 0x01 /* IRQ can be shared */ -/* DSP Resources: */ -#define CFG_DSPMAXMEMTYPES 10 -#define CFG_DEFAULT_NUM_WINDOWS 1 /* We support only one window. */ - /* A platform-related device handle: */ struct cfg_devnode; diff --git a/drivers/staging/tidspbridge/include/dspbridge/chnldefs.h b/drivers/staging/tidspbridge/include/dspbridge/chnldefs.h index 5bf5f6b..8f8f9ec 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/chnldefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/chnldefs.h @@ -22,9 +22,6 @@ /* Channel id option. */ #define CHNL_PICKFREE (~0UL) /* Let manager pick a free channel. */ -/* Channel manager limits: */ -#define CHNL_INITIOREQS 4 /* Default # of I/O requests. */ - /* Channel modes */ #define CHNL_MODETODSP 0 /* Data streaming to the DSP. */ #define CHNL_MODEFROMDSP 1 /* Data streaming from the DSP. */ diff --git a/drivers/staging/tidspbridge/include/dspbridge/chnlpriv.h b/drivers/staging/tidspbridge/include/dspbridge/chnlpriv.h index 9292100..1785c3e 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/chnlpriv.h +++ b/drivers/staging/tidspbridge/include/dspbridge/chnlpriv.h @@ -39,12 +39,6 @@ */ #define CHNL_PCPY 0 /* Proc-copy transport 0 */ -#define CHNL_MAXIRQ 0xff /* Arbitrarily large number. */ - -/* The following modes are private: */ -#define CHNL_MODEUSEREVENT 0x1000 /* User provided the channel event. */ -#define CHNL_MODEMASK 0x1001 - /* Higher level channel states: */ #define CHNL_STATEREADY0 /* Channel ready for I/O. */ #define CHNL_STATECANCEL 1 /* I/O was cancelled. */ @@ -56,13 +50,6 @@ /* Types of channel class libraries: */ #define CHNL_TYPESM 1 /* Shared memory driver. */ -#define CHNL_TYPEBM 2 /* Bus Mastering driver. */ - -/* Max string length of channel I/O completion event name - change if needed */ -#define CHNL_MAXEVTNAMELEN 32 - -/* Max memory pages lockable in
[PATCH 3/5] staging:tidspbridge - Remove unused structs
Remove unused structs and its dependencies, like references
in other structs or as arguments of certain functions.
Signed-off-by: Armando Uribe x0095...@ti.com
---
.../tidspbridge/include/dspbridge/cfgdefs.h|6 --
.../staging/tidspbridge/include/dspbridge/cod.h| 10 +
.../tidspbridge/include/dspbridge/dbldefs.h| 49
.../staging/tidspbridge/include/dspbridge/drv.h| 14 --
.../tidspbridge/include/dspbridge/dspapi-ioctl.h |8 ---
.../staging/tidspbridge/include/dspbridge/ldr.h| 29
drivers/staging/tidspbridge/pmgr/cod.c | 11 +
drivers/staging/tidspbridge/pmgr/dev.c |8 +---
drivers/staging/tidspbridge/rmgr/dbdcd.c |2 +-
9 files changed, 4 insertions(+), 133 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/ldr.h
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
index c3f04f8..0589a0a 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
@@ -58,10 +58,4 @@ struct cfg_hostres {
void __iomem *dw_dmmu_base;
};
-struct cfg_dspmemdesc {
- u32 mem_type; /* Type of memory. */
- u32 ul_min; /* Minimum amount of memory of this type. */
- u32 ul_max; /* Maximum amount of memory of this type. */
-};
-
#endif /* CFGDEFS_ */
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cod.h
b/drivers/staging/tidspbridge/include/dspbridge/cod.h
index 5efea91..53bd4bb 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cod.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cod.h
@@ -37,11 +37,6 @@ struct cod_manager;
/* COD library handle */
struct cod_libraryobj;
-/* COD attributes */
-struct cod_attrs {
- u32 ul_reserved;
-};
-
/*
* Function prototypes for writing memory to a DSP system, allocating
* and freeing DSP memory.
@@ -76,8 +71,6 @@ extern void cod_close(struct cod_libraryobj *lib);
* Parameters:
* manager:created manager object
* str_zl_file:ZL DLL filename, of length COD_MAXPATHLENGTH.
- * attrs: attributes to be used by this object. A NULL value
- * will cause default attrs to be used.
* Returns:
* 0:Success.
* -ESPIPE: ZL_Create failed.
@@ -89,8 +82,7 @@ extern void cod_close(struct cod_libraryobj *lib);
* Ensures:
*/
extern int cod_create(struct cod_manager **mgr,
-char *str_zl_file,
-const struct cod_attrs *attrs);
+char *str_zl_file);
/*
* cod_delete
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
b/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
index 9973098..5cf9dad 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
@@ -25,26 +25,6 @@
typedef s32 dbl_flags;
/*
- * dbl_sect_info
- * For collecting info on overlay sections
- */
-struct dbl_sect_info {
- const char *name; /* name of section */
- u32 sect_run_addr; /* run address of section */
- u32 sect_load_addr; /* load address of section */
- u32 size; /* size of section (target MAUs) */
- dbl_flags type; /* Code, data, or BSS */
-};
-
-/*
- * dbl_symbol
- * (Needed for dynamic load library)
- */
-struct dbl_symbol {
- u32 value;
-};
-
-/*
* dbl_alloc_fxn
* Allocate memory function. Allocate or reserve (if reserved == TRUE)
* size bytes of memory from segment space and return the address in
@@ -98,33 +78,4 @@ typedef bool(*dbl_sym_lookup) (void *handle, void *parg,
void *rmm_handle,
typedef s32(*dbl_write_fxn) (void *hdl, u32 dsp_address, void *buf,
u32 n, s32 mtype);
-/*
- * dbl_attrs
- */
-struct dbl_attrs {
- dbl_alloc_fxn alloc;
- dbl_free_fxn free;
- void *rmm_handle; /* Handle to pass to alloc, free functions */
- dbl_write_fxn write;
- void *input_params; /* Handle to pass to write, cinit function */
-
- dbl_log_write_fxn log_write;
- void *log_write_handle;
-
- /* Symbol matching function and handle to pass to it */
- dbl_sym_lookup sym_lookup;
- void *sym_handle;
- void *sym_arg;
-
- /*
-* These file manipulation functions should be compatible with the
-* C run time library functions of the same name.
-*/
-s32(*fread) (void *, size_t, size_t, void *);
-s32(*fseek) (void *, long, int);
-s32(*ftell) (void *);
-s32(*fclose) (void *);
- void *(*fopen) (const char *, const char *);
-};
-
[PATCH 4/5] staging:tidspbridge - Remove unused typedefs
Unsed typedefs are removed, because of there are not used or because previous clean ups. Signed-off-by: Armando Uribe x0095...@ti.com --- .../tidspbridge/include/dspbridge/dbldefs.h| 81 .../tidspbridge/include/dspbridge/dblldefs.h | 62 --- 2 files changed, 0 insertions(+), 143 deletions(-) delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbldefs.h diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h b/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h deleted file mode 100644 index 5cf9dad..000 --- a/drivers/staging/tidspbridge/include/dspbridge/dbldefs.h +++ /dev/null @@ -1,81 +0,0 @@ -/* - * dbldefs.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Copyright (C) 2005-2006 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef DBLDEFS_ -#define DBLDEFS_ - - -/* - * dbl_flags - * Specifies whether to load code, data, or symbols - */ -typedef s32 dbl_flags; - -/* - * dbl_alloc_fxn - * Allocate memory function. Allocate or reserve (if reserved == TRUE) - * size bytes of memory from segment space and return the address in - * *dsp_address (or starting at *dsp_address if reserve == TRUE). Returns 0 on - * success, or an error code on failure. - */ -typedef s32(*dbl_alloc_fxn) (void *hdl, s32 space, u32 size, u32 align, -u32 *dsp_address, s32 seg_id, s32 req, -bool reserved); - -/* - * dbl_free_fxn - * Free memory function. Free, or unreserve (if reserved == TRUE) size - * bytes of memory from segment space - */ -typedef bool(*dbl_free_fxn) (void *hdl, u32 addr, s32 space, u32 size, -bool reserved); - -/* - * dbl_log_write_fxn - * Function to call when writing data from a section, to log the info. - * Can be NULL if no logging is required. - */ -typedef int(*dbl_log_write_fxn) (void *handle, - struct dbl_sect_info *sect, u32 addr, - u32 bytes); - -/* - * dbl_sym_lookup - * Symbol lookup function - Find the symbol name and return its value. - * - * Parameters: - * handle - Opaque handle - * parg- Opaque argument. - * name- Name of symbol to lookup. - * sym - Location to store address of symbol structure. - * - * Returns: - * TRUE: Success (symbol was found). - * FALSE: Failed to find symbol. - */ -typedef bool(*dbl_sym_lookup) (void *handle, void *parg, void *rmm_handle, - const char *name, struct dbl_symbol ** sym); - -/* - * dbl_write_fxn - * Write memory function. Write n HOST bytes of memory to segment mtype - * starting at address dsp_address from the buffer buf. The buffer is - * formatted as an array of words appropriate for the DSP. - */ -typedef s32(*dbl_write_fxn) (void *hdl, u32 dsp_address, void *buf, -u32 n, s32 mtype); - -#endif /* DBLDEFS_ */ diff --git a/drivers/staging/tidspbridge/include/dspbridge/dblldefs.h b/drivers/staging/tidspbridge/include/dspbridge/dblldefs.h index 81821e5..30e0aa0 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/dblldefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/dblldefs.h @@ -348,29 +348,6 @@ typedef bool(*dbll_init_fxn) (void); typedef int(*dbll_load_fxn) (struct dbll_library_obj *lib, dbll_flags flags, struct dbll_attrs *attrs, u32 *entry); - -/* - * dbll_load_sect - * Load a named section from an library (for overlay support). - * Parameters: - * lib - Handle returned from dbll_open(). - * sec_name- Name of section to load. - * attrs - Contains write function and handle to pass to it. - * Returns: - * 0:Success. - * -ENXIO:Section not found. - * -ENOSYS: Function not implemented. - * Requires: - * Valid lib. - * sec_name != NULL. - * attrs != NULL. - * attrs-write != NULL. - * Ensures: - */ -typedef int(*dbll_load_sect_fxn) (struct dbll_library_obj *lib, -char *sz_sect_name, -struct dbll_attrs *attrs); - /* * dbll_open * dbll_open() returns a library handle that can be used to load/unload @@ -421,23 +398,6
[PATCH 5/5] staging:tidspbridge - Remove trivial header files
Remove the header files that contains few declarations
and can be merged onto more generic headers.
Signed-off-by: Armando Uribe x0095...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 +-
.../tidspbridge/include/dspbridge/dehdefs.h| 31 -
.../staging/tidspbridge/include/dspbridge/dev.h|4 +-
.../staging/tidspbridge/include/dspbridge/disp.h | 15 -
.../tidspbridge/include/dspbridge/dispdefs.h | 35
.../staging/tidspbridge/include/dspbridge/drv.h|4 ++-
.../tidspbridge/include/dspbridge/drvdefs.h| 25 --
.../tidspbridge/include/dspbridge/dspdefs.h|4 +-
.../staging/tidspbridge/include/dspbridge/dspio.h |3 +-
drivers/staging/tidspbridge/include/dspbridge/io.h | 13 +++-
.../staging/tidspbridge/include/dspbridge/io_sm.h |7 +++-
.../staging/tidspbridge/include/dspbridge/iodefs.h | 34 ---
.../staging/tidspbridge/include/dspbridge/node.h |2 +-
.../staging/tidspbridge/include/dspbridge/pwr.h|8 -
.../staging/tidspbridge/include/dspbridge/pwr_sh.h | 29
drivers/staging/tidspbridge/pmgr/io.c |1 -
drivers/staging/tidspbridge/rmgr/drv_interface.c |1 -
drivers/staging/tidspbridge/rmgr/node.c|1 -
18 files changed, 51 insertions(+), 170 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dispdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/drvdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/iodefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/pwr_sh.h
diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
index fb9026e..8e2b50f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
@@ -29,13 +29,13 @@
/* --- Platform Manager */
#include dspbridge/brddefs.h
#include dspbridge/dev.h
-#include dspbridge/iodefs.h
+#include dspbridge/io.h
/* Hardware Abstraction Layer */
#include hw_defs.h
#include hw_mmu.h
-#include dspbridge/pwr_sh.h
+#include dspbridge/pwr.h
/* --- Bridge Driver */
#include dspbridge/dspdeh.h
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
deleted file mode 100644
index 5341471..000
--- a/drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * dehdefs.h
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * Definition for Bridge driver module DEH.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-#ifndef DEHDEFS_
-#define DEHDEFS_
-
-#include dspbridge/mbx_sh.h /* shared mailbox codes */
-
-/* DEH object manager */
-struct deh_mgr;
-
-/* Magic code used to determine if DSP signaled exception. */
-#define DEH_BASEMBX_DEH_BASE
-#define DEH_LIMIT MBX_DEH_LIMIT
-
-#endif /* _DEHDEFS_H */
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dev.h
b/drivers/staging/tidspbridge/include/dspbridge/dev.h
index 4d4196b..37d1fff 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dev.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dev.h
@@ -23,9 +23,9 @@
#include dspbridge/chnldefs.h
#include dspbridge/cmm.h
#include dspbridge/cod.h
-#include dspbridge/dehdefs.h
+#include dspbridge/dspdeh.h
#include dspbridge/nodedefs.h
-#include dspbridge/dispdefs.h
+#include dspbridge/disp.h
#include dspbridge/dspdefs.h
#include dspbridge/dmm.h
#include dspbridge/host_os.h
diff --git a/drivers/staging/tidspbridge/include/dspbridge/disp.h
b/drivers/staging/tidspbridge/include/dspbridge/disp.h
index 82bf721..41738c5 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/disp.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/disp.h
@@ -22,7 +22,20 @@
#include dspbridge/dbdefs.h
#include dspbridge/nodedefs.h
#include dspbridge/nodepriv.h
-#include dspbridge/dispdefs.h
+
+struct disp_object;
+
+/* Node Dispatcher attributes */
+struct disp_attr {
+ u32 ul_chnl_offset; /* Offset of channel ids reserved for RMS */
+ /* Size of buffer for sending data to RMS */
+ u32 ul_chnl_buf_size;
+ int proc_family;/* eg, 5000 */
+ int
[PATCH 2/5] staging:tidspbridge - Remove unused functions
Remove functions that are not used at all, also remove the dependencies
of this functions like struct members, comments and calls.
Signed-off-by: Armando Uribe x0095...@ti.com
---
drivers/staging/tidspbridge/core/io_sm.c |4 -
drivers/staging/tidspbridge/core/tiomap3430.c |2 -
.../staging/tidspbridge/include/dspbridge/chnl.h | 21 ---
.../staging/tidspbridge/include/dspbridge/dbll.h |6 -
.../tidspbridge/include/dspbridge/dblldefs.h |3 -
.../staging/tidspbridge/include/dspbridge/dev.h| 55
.../staging/tidspbridge/include/dspbridge/dspio.h |1 -
.../tidspbridge/include/dspbridge/host_os.h|9 --
drivers/staging/tidspbridge/include/dspbridge/io.h | 16 ---
.../staging/tidspbridge/include/dspbridge/io_sm.h | 135
.../staging/tidspbridge/include/dspbridge/node.h | 18 ---
.../include/dspbridge/resourcecleanup.h| 11 --
.../staging/tidspbridge/include/dspbridge/strm.h | 62 -
drivers/staging/tidspbridge/pmgr/cod.c |3 -
drivers/staging/tidspbridge/pmgr/dbll.c| 41 --
drivers/staging/tidspbridge/rmgr/nldr.c|3 -
16 files changed, 0 insertions(+), 390 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 9289522..90e89ee 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -1682,10 +1682,6 @@ int bridge_io_get_proc_load(struct io_mgr *hio_mgr,
return 0;
}
-void io_sm_init(void)
-{
- /* Do nothing */
-}
#if defined(CONFIG_TIDSPBRIDGE_BACKTRACE) || defined(CONFIG_TIDSPBRIDGE_DEBUG)
void print_dsp_debug_trace(struct io_mgr *hio_mgr)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index cb45e93..cacd30e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -255,8 +255,6 @@ void bridge_drv_entry(struct bridge_drv_interface
**drv_intf,
DBC_REQUIRE(driver_file_name != NULL);
- io_sm_init(); /* Initialization of io_sm module */
-
if (strcmp(driver_file_name, UMA) == 0)
*drv_intf = drv_interface_fxns;
else
diff --git a/drivers/staging/tidspbridge/include/dspbridge/chnl.h
b/drivers/staging/tidspbridge/include/dspbridge/chnl.h
index 8733b3b..92f6a13 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/chnl.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/chnl.h
@@ -25,27 +25,6 @@
#include dspbridge/chnlpriv.h
/*
- * chnl_close
- * Purpose:
- * Ensures all pending I/O on this channel is cancelled, discards all
- * queued I/O completion notifications, then frees the resources allocated
- * for this channel, and makes the corresponding logical channel id
- * available for subsequent use.
- * Parameters:
- * chnl_obj: Channel object handle.
- * Returns:
- * 0:Success;
- * -EFAULT:Invalid chnl_obj.
- * Requires:
- * chnl_init(void) called.
- * No thread must be blocked on this channel's I/O completion event.
- * Ensures:
- * 0:The I/O completion event for this channel is freed.
- * chnl_obj is no longer valid.
- */
-extern int chnl_close(struct chnl_object *chnl_obj);
-
-/*
* chnl_create
* Purpose:
* Create a channel manager object, responsible for opening new channels
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbll.h
b/drivers/staging/tidspbridge/include/dspbridge/dbll.h
index b018676..46a9e00 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbll.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbll.h
@@ -42,18 +42,12 @@ extern bool dbll_init(void);
extern int dbll_load(struct dbll_library_obj *lib,
dbll_flags flags,
struct dbll_attrs *attrs, u32 * entry);
-extern int dbll_load_sect(struct dbll_library_obj *zl_lib,
-char *sec_name, struct dbll_attrs *attrs);
extern int dbll_open(struct dbll_tar_obj *target, char *file,
dbll_flags flags,
struct dbll_library_obj **lib_obj);
extern int dbll_read_sect(struct dbll_library_obj *lib,
char *name, char *buf, u32 size);
-extern void dbll_set_attrs(struct dbll_tar_obj *target,
- struct dbll_attrs *pattrs);
extern void dbll_unload(struct dbll_library_obj *lib, struct dbll_attrs
*attrs);
-extern int dbll_unload_sect(struct dbll_library_obj *lib,
- char *sect_name, struct dbll_attrs *attrs);
#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
bool dbll_find_dsp_symbol(struct dbll_library_obj *zl_lib, u32 address,
u32 offset_range, u32 *sym_addr_output, char
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Kevin Hilman had written, on 12/16/2010 12:57 PM, the following: Nishanth Menon n...@ti.com writes: Nishanth Menon had written, on 12/15/2010 06:05 PM, the following: Kevin Hilman had written, on 12/15/2010 05:47 PM, the following: I agree that this additional check in sram_idle should be removed, but as long as I handle it in omap3_pm_off_mode_enable where the next states are configured, is'nt that enough or am I missing something? Setting the next states only sets the default states, but CPUidle changes them. Looking closer at omap3_pm_off_mode_enable() though, it already calls into CPUidle and disables the valid bit for any states that have *either* MPU or core off.You'll probably just need to extend this approach to disable only CORE off state(s). Thx. it is clear now. let me see how to clean this up. k. Does the attached look any better now :)? Yes, but, I still don't quite like it. Basically, I'm not crazy about the errata knowledge being centralized in pm34xx.c. How about this: Move the Errata handling core code (pm_errata_* PM_ERRATTA_*) to pm.[ch] as a single patch. Then both pm34xx.c and cpuidle34xx.c would be free to use it. This would allow CPUidle handle the errata itself in the 'update_states' function. Or even better, if CPUidle core can check this errata, it should probably just never register C7 in the first place, because it is *never* a valid C-state. Make sense? hmm.. IMHO at the problems themselves: a) cpuidle_params_table - this needs to become dynamically generated if you'd like cpuidle to not know about the existance of the invalid states at all(C7 has to disappear from it's radar - but extending it to a generic solution where an inbetween C state might be disabled as well) b) extending the problem further - cpu idle state latencies by themselves might vary between boards(PMIC variances causing delta in voltage setup times as an example).. I suppose we have some way to plug that data in as well? but irrelevant to this discussion. or maybe some board would like to have a customized additional c state which is not really practical for other platforms for what ever reasons.. c) if cpuidle where to get pm errata info, it is nice thing to do, but, dont you think it is an overkill atm for just one errata? d) omap_init_power_states may need some cleanups as well.. too many = assignments IMHO.. e) On the topic of argument that the states controlled by enable_off_mode is dynamic, though even though enable_off_mode is a variable, it is in debugfs - not really a dynamic variant in a product.. with that in mind, we may want to have off OR not have off mode in a product board file and folks would probably call omap3_pm_off_mode_enable or set the variable and set it to 1. That makes it even more crazy IMHO. f) Finally, where do we detect the erratas? it is more handy to have them in one place - pm34xx.c was chosen to make it independent of silicon type - pm44xx.c might endup having different set with it's own requirements - so not all together convinced it should be in pm.[ch]. I have tried to restrict the detection and usage purely to the file that needs it - pm34xx.c I think I agree to your overall thought that C state by itself should'nt have been registered, but would'nt it be better to do the cpuidle cleanups in a different context? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
Hi Thara, Thara Gopinath th...@ti.com writes: This patch series introduces smartreflex and voltage driver support for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. [...] This patch series has been tested on OMAP3430 SDP with omap2plus_defconfig with the following menuconfig options enabled. Any testing on 3630? System type - TI OMAP Implementations - Smartreflex Support System type - TI OMAP Implementations - Class 3 mode of Smartreflex Implementation Major Changes in v5 - Rebased to k.org 2.6.37-rc3 - Rebased to Nishant Menon's latest opp patches - Voltage pmic info structure extended to include a vast set of PMIC dependent parameters. - Smartreflex software n-target values support removed from the kernel. Instead n-target values are exposed as debugfs entries which can be written into by the user if needed. - Introduced a new file arch/arm/mach-omap2/omap_twl.c for specifying OMAP and TWL related info for the voltage layer. - Remove default enabling of smartreflex autocompensation during boot on OMAP3430 ES3.1 chips. Instead an API is provided that can be called from board files in case autocompensation needs to be enabled during boot up itself. - Other review comments on v4 This series is looking good. I have a couple minor comments on specific patches. Also, it needs (hopefully only) one more rebase/repost. First, a few things have changed at the PRCM API level that need to be updated. I have a untested patch (below) that should fix this for you, that you'll need to split and apply to the OMAP3 and OMAP4 voltage driver patches. To test with those changes, you can rebase onto my pm-core branch, which contains not only the PRCM API changes, but also Nishanth's latest OPP branch, and several other clock, hwmod, PM core changes queued for 2.6.38 Second, please also Cc the linux-arm-kernel mailing list, so if/when we merge this into linux-omap, it doesn't need a last minute repost. Thanks, 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: Section mismatch warnings 2.6.37-rc6
On Fri, Dec 17, 2010 at 7:53 AM, Elvis Dowson elvis.dow...@mac.com wrote: Hi, When I build the linux mainline 2.6.37-rc6, I get 3 section mismatch warnings. What do they indicate? That tells us these 3 functions need to check for the right usage of '__init'. And which defconfig are you using? $ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage -j6 LOCALVERSION= CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.data+0x1b70): Section mismatch in reference from the variable etb_driver to the function .init.text:etb_probe() The variable etb_driver references the function __init etb_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x1bbc): Section mismatch in reference from the variable etm_driver to the function .init.text:etm_probe() The variable etm_driver references the function __init etm_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x3477c): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() The variable twl_driver references the function __init twl_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, I've sent a patch to twl driver maintainer to fix that. Thanks, -- Bryan Wu bryan...@canonical.com Kernel Developer +86.138-1617-6545 Mobile Ubuntu Kernel Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Section mismatch warnings 2.6.37-rc6
On Dec 17, 2010, at 5:39 AM, Bryan Wu wrote: That tells us these 3 functions need to check for the right usage of '__init'. And which defconfig are you using? I configured a custom beagleboard platform with the omap2plus_defconfig. Would it be possible for you send me a link to the patch, so that I can apply it to my local repo? Elvis Dowson -- 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/7] OMAP2+: use global values for the SRAM PA addresses
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com Sent: Thursday, December 16, 2010 11:21 PM To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org; Jean Pihet Subject: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses From: Jean Pihet j-pi...@ti.com The SRAM PA addresses are locally defined and used in both the SRAM management code and the idle sleep code. A global macro defines the values at a centralized place, for easier maintenance. Tested on N900 and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/sdrc.h |7 +++ arch/arm/plat-omap/sram.c |7 ++- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h index 68f57bb..ada596b 100644 --- a/arch/arm/mach-omap2/sdrc.h +++ b/arch/arm/mach-omap2/sdrc.h @@ -74,5 +74,12 @@ static inline u32 sms_read_reg(u16 reg) */ #define SDRC_MPURATE_LOOPS 96 +/* + * OMAP2+: define the SRAM PA addresses. + * Used by the SRAM management code and the idle sleep code. + */ +#define OMAP2_SRAM_PA0x4020 +#define OMAP3_SRAM_PA 0x4020 +#define OMAP4_SRAM_PA0x4030 Header choice is wrong. Certainly SDRC is not the place. Right place should be #include plat/sram.h OMAP4 doesn't even have SDRC IP #endif diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 819ea0c..1a686c8 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -41,15 +41,12 @@ #define OMAP1_SRAM_PA0x2000 #define OMAP1_SRAM_VAVMALLOC_END -#define OMAP2_SRAM_PA0x4020 -#define OMAP2_SRAM_PUB_PA0x4020f800 +#define OMAP2_SRAM_PUB_PA(OMAP2_SRAM_PA + 0xf800) #define OMAP2_SRAM_VA0xfe40 #define OMAP2_SRAM_PUB_VA(OMAP2_SRAM_VA + 0x800) -#define OMAP3_SRAM_PA 0x4020 #define OMAP3_SRAM_VA 0xfe40 -#define OMAP3_SRAM_PUB_PA 0x40208000 +#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000) #define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000) -#define OMAP4_SRAM_PA0x4030 #define OMAP4_SRAM_VA0xfe40 #define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000) #define OMAP4_SRAM_PUB_VA(OMAP4_SRAM_VA + 0x4000) -- 1.7.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 -- 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 5/7] OMAP3: rework of the ASM sleep code execution paths
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
Sent: Thursday, December 16, 2010 11:21 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
Jean Pihet
Subject: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths
From: Jean Pihet j-pi...@ti.com
- Reworked and simplified the execution paths for better
readability and to avoid duplication of code,
- Added comments on the entry and exit points and the interaction
with the ROM code for OFF mode restore,
- Reworked the existing comments for better readability.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/control.c | 10 +-
arch/arm/mach-omap2/sleep34xx.S | 309
++
2 files changed, 188 insertions(+), 131 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
index 728f268..5cb7276 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -239,7 +239,15 @@ void omap3_save_scratchpad_contents(void)
struct omap3_scratchpad_prcm_block prcm_block_contents;
struct omap3_scratchpad_sdrc_block sdrc_block_contents;
- /* Populate the Scratchpad contents */
+ /*
+ * Populate the Scratchpad contents
+ *
+ * The get_*restore_pointer functions are used to get the resume
+ * function pointer to be called by the ROM code when back from
WFI
+ * in OFF mode.
Align your text here.
+ * The restore pointer is stored into the scratchpad for later
access
+ * by the ROM code.
The text needs to be reworked a bit.
The get_*restore_pointer functions are used to provide a physical
restore
address where ROM code jumps while waking up from MPU OFF/OSWR state.
The restore pointer is stored into the scratchpad
+ */
scratchpad_contents.boot_config_ptr = 0x0;
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
omap2/sleep34xx.S
index 426af02..55ddd5a 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -70,6 +70,11 @@
* API functions
*/
+/*
+ * The get_*restore_pointer functions are returning the resume
+ * function pointer to be called by the ROM code when back from WFI
+ * in OFF mode.
Ditto
The get_*restore_pointer functions are used to provide a physical
restore
address where ROM code jumps while waking up from MPU OFF/OSWR state.
The restore pointer is stored into the scratchpad
+ */
.text
/* Function call to get the restore pointer for resume from OFF */
ENTRY(get_restore_pointer)
@@ -101,7 +106,7 @@ ENTRY(get_es3_restore_pointer_sz)
/*
* L2 cache needs to be toggled for stable OFF mode functionality on
3630.
* This function sets up a flag that will allow for this toggling to
take
- * place on 3630. Hopefully some version in the future maynot need this
+ * place on 3630. Hopefully some version in the future maynot need
this.
'maynot' . may not
*/
ENTRY(enable_omap3630_toggle_l2_on_restore)
stmfd sp!, {lr} @ save registers on stack
@@ -143,34 +148,156 @@ ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
/*
+ * ==
+ * == Idle entry point ==
+ * ==
+ */
+
+/*
* Forces OMAP into idle state
*
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if
needed
+ * and executes the WFI instruction
*
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *wakes up it continues execution at the point it went to sleep.
+ * Notes:
+ * - this code gets copied to internal SRAM at boot.
+ * - when the OMAP wakes up it continues at different execution points
+ * depending on the low power mode (non-OFF vs OFF modes),
+ * cf. 'Resume path for xxx mode' comments.
*/
ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
- /* r0 contains restore pointer in sdram */
- /* r1 contains information about saving context */
- ldr r4, sdrc_power @ read the SDRC_POWER register
- ldr r5, [r4]@ read the contents of SDRC_POWER
- orr r5, r5, #0x40 @ enable self refresh on idle req
- str r5, [r4]@ write back to SDRC_POWER
register
+ /*
+ * r0 contains restore pointer in sdram
+ * r1 contains information about saving context:
+ * 0 - No context lost
+ * 1 - Only L1 and logic lost
+ * 2 - Only L2 lost
+ * 3 - Both L1 and L2 lost
+
RE: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code
Jean, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com Sent: Thursday, December 16, 2010 11:21 PM To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org; Jean Pihet Subject: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code From: Jean Pihet j-pi...@ti.com This patch only contains clean-ups and cosmetic changes, no functional change. Clean-up of the ASM sleep code, for better readability and easier maintenance. Applies on top of Nishant's latest idle path errata fixes step 2, cf. http://marc.info/?l=linux-omapm=129139584919242w=2 Thanks for cleanup. Have few minor comments on these patches. Jean Pihet (7): OMAP2+: use global values for the SRAM PA addresses OMAP3: remove hardcoded values from the ASM sleep code OMAP3: re-organize the ASM sleep code OMAP3: rework of the ASM sleep code execution paths OMAP3: add comments for low power code errata OMAP3: ASM sleep code format rework OMAP3: remove unused code from the ASM sleep code arch/arm/mach-omap2/control.c | 10 +- arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|1 - arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sdrc.h |7 + arch/arm/mach-omap2/sleep34xx.S | 714 +- - arch/arm/plat-omap/sram.c |7 +- 7 files changed, 401 insertions(+), 344 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
Kevin, -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, December 17, 2010 7:01 AM To: Thara Gopinath Cc: linux-omap@vger.kernel.org; p...@pwsan.com; b-cous...@ti.com; vishwanath...@ti.com; saw...@ti.com; n...@ti.com Subject: Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support Hi Thara, Thara Gopinath th...@ti.com writes: This patch series introduces smartreflex and voltage driver support for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. [...] This patch series has been tested on OMAP3430 SDP with omap2plus_defconfig with the following menuconfig options enabled. Any testing on 3630? I tested this on ZOOM3 and it works fine. Vishwa System type - TI OMAP Implementations - Smartreflex Support System type - TI OMAP Implementations - Class 3 mode of Smartreflex Implementation Major Changes in v5 - Rebased to k.org 2.6.37-rc3 - Rebased to Nishant Menon's latest opp patches - Voltage pmic info structure extended to include a vast set of PMIC dependent parameters. - Smartreflex software n-target values support removed from the kernel. Instead n-target values are exposed as debugfs entries which can be written into by the user if needed. - Introduced a new file arch/arm/mach-omap2/omap_twl.c for specifying OMAP and TWL related info for the voltage layer. - Remove default enabling of smartreflex autocompensation during boot on OMAP3430 ES3.1 chips. Instead an API is provided that can be called from board files in case autocompensation needs to be enabled during boot up itself. - Other review comments on v4 This series is looking good. I have a couple minor comments on specific patches. Also, it needs (hopefully only) one more rebase/repost. First, a few things have changed at the PRCM API level that need to be updated. I have a untested patch (below) that should fix this for you, that you'll need to split and apply to the OMAP3 and OMAP4 voltage driver patches. To test with those changes, you can rebase onto my pm-core branch, which contains not only the PRCM API changes, but also Nishanth's latest OPP branch, and several other clock, hwmod, PM core changes queued for 2.6.38 Second, please also Cc the linux-arm-kernel mailing list, so if/when we merge this into linux-omap, it doesn't need a last minute repost. Thanks, 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
[PATCH v4 0/2] OMAP_VOUT: Allow omap_vout to build without VRFB
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's, making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS, since OMAP4 doesn't have VRFB block. A new enum called vout_rotation_type is introduced to differentiate between no rotation and vrfb rotation. A member rotation_type is introduced in omapvideo_info, this allows to call vrfb specific functions only if the rotation type is VOUT_ROT_VRFB When the rotation_type is set to VOUT_ROT_NONE, the S_CTRL ioctl prevents the user setting a non zero rotation or non zero mirror value. Archit Taneja (2): OMAP_VOUT: CLEANUP: Move some functions and macros from omap_vout OMAP_VOUT: Create separate file for VRFB related API's drivers/media/video/omap/Kconfig |2 +- drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 566 + drivers/media/video/omap/omap_vout_vrfb.c | 390 drivers/media/video/omap/omap_vout_vrfb.h | 40 ++ drivers/media/video/omap/omap_voutdef.h | 78 drivers/media/video/omap/omap_voutlib.c | 44 +++ drivers/media/video/omap/omap_voutlib.h |2 + 8 files changed, 640 insertions(+), 483 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h -- Version 4: - Some minor fixes, renaming of git commits, patches 2 and 3 merged into 1. Version 3: - Introduce a new enum at V4L2 driver level which cleanly differentiates between vrfb rotation and no rotation, incorporate comments given for v2 Version 2: - Don't try to enable SDRAM rotation , return an error if non zero rotation is attempted when rotation_type is set to SDMA rotation. Version 1: http://www.mail-archive.com/linux-media@vger.kernel.org/msg21937.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
[PATCH v4 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros from omap_vout
Move some inline functions from omap_vout.c to omap_voutdef.h and independent
functions like omap_vout_alloc_buffer/omap_vout_free_buffer to omap_voutlib.c.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c| 109 ---
drivers/media/video/omap/omap_voutdef.h | 62 +
drivers/media/video/omap/omap_voutlib.c | 44
drivers/media/video/omap/omap_voutlib.h |2 +
4 files changed, 108 insertions(+), 109 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 15f8793..e1df01c 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -35,17 +35,14 @@
#include linux/sched.h
#include linux/types.h
#include linux/platform_device.h
-#include linux/dma-mapping.h
#include linux/irq.h
#include linux/videodev2.h
-#include linux/slab.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include plat/dma.h
-#include plat/vram.h
#include plat/vrfb.h
#include plat/display.h
@@ -56,7 +53,6 @@ MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
MODULE_LICENSE(GPL);
-
/* Driver Configuration macros */
#define VOUT_NAME omap_vout
@@ -65,31 +61,6 @@ enum omap_vout_channels {
OMAP_VIDEO2,
};
-enum dma_channel_state {
- DMA_CHAN_NOT_ALLOTED,
- DMA_CHAN_ALLOTED,
-};
-
-#define QQVGA_WIDTH160
-#define QQVGA_HEIGHT 120
-
-/* Max Resolution supported by the driver */
-#define VID_MAX_WIDTH 1280/* Largest width */
-#define VID_MAX_HEIGHT 720 /* Largest height */
-
-/* Mimimum requirement is 2x2 for DSS */
-#define VID_MIN_WIDTH 2
-#define VID_MIN_HEIGHT 2
-
-/* 2048 x 2048 is max res supported by OMAP display controller */
-#define MAX_PIXELS_PER_LINE 2048
-
-#define VRFB_TX_TIMEOUT 1000
-#define VRFB_NUM_BUFS 4
-
-/* Max buffer size tobe allocated during init */
-#define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)
-
static struct videobuf_queue_ops video_vbq_ops;
/* Variables configurable through module params*/
static u32 video1_numbuffers = 3;
@@ -172,49 +143,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Allocate buffers
- */
-static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
-{
- u32 order, size;
- unsigned long virt_addr, addr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
- virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
- addr = virt_addr;
-
- if (virt_addr) {
- while (size 0) {
- SetPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- }
- *phys_addr = (u32) virt_to_phys((void *) virt_addr);
- return virt_addr;
-}
-
-/*
- * Free buffers
- */
-static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
-{
- u32 order, size;
- unsigned long addr = virtaddr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
-
- while (size 0) {
- ClearPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- free_pages((unsigned long) virtaddr, order);
-}
-
-/*
* Function for allocating video buffers
*/
static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
@@ -369,43 +297,6 @@ static void omap_vout_release_vrfb(struct omap_vout_device
*vout)
}
/*
- * Return true if rotation is 90 or 270
- */
-static inline int rotate_90_or_270(const struct omap_vout_device *vout)
-{
- return (vout-rotation == dss_rotation_90_degree ||
- vout-rotation == dss_rotation_270_degree);
-}
-
-/*
- * Return true if rotation is enabled
- */
-static inline int rotation_enabled(const struct omap_vout_device *vout)
-{
- return vout-rotation || vout-mirror;
-}
-
-/*
- * Reverse the rotation degree if mirroring is enabled
- */
-static inline int calc_rotation(const struct omap_vout_device *vout)
-{
- if (!vout-mirror)
- return vout-rotation;
-
- switch (vout-rotation) {
- case dss_rotation_90_degree:
- return dss_rotation_270_degree;
- case dss_rotation_270_degree:
- return dss_rotation_90_degree;
- case dss_rotation_180_degree:
- return dss_rotation_0_degree;
- default:
- return dss_rotation_180_degree;
- }
-}
-
-/*
* Free the V4L2 buffers
*/
static void omap_vout_free_buffers(struct omap_vout_device *vout)
diff --git a/drivers/media/video/omap/omap_voutdef.h
[PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related API's
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's,
making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS,
since OMAP4 doesn't have VRFB block.
Added new enum vout_rotation_type and rotation_type member to omapvideo_info,
this is initialized based on the arch type in omap_vout_probe. The rotation_type
var is now used to choose between vrfb and non-vrfb calls.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/Kconfig |2 +-
drivers/media/video/omap/Makefile |1 +
drivers/media/video/omap/omap_vout.c | 457 ++---
drivers/media/video/omap/omap_vout_vrfb.c | 390
drivers/media/video/omap/omap_vout_vrfb.h | 40 +++
drivers/media/video/omap/omap_voutdef.h | 16 +
6 files changed, 532 insertions(+), 374 deletions(-)
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig
index e63233f..5f8abea 100644
--- a/drivers/media/video/omap/Kconfig
+++ b/drivers/media/video/omap/Kconfig
@@ -5,7 +5,7 @@ config VIDEO_OMAP2_VOUT
select VIDEOBUF_DMA_CONTIG
select OMAP2_DSS
select OMAP2_VRAM
- select OMAP2_VRFB
+ select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/video/omap/Makefile
b/drivers/media/video/omap/Makefile
index b287880..bc47569 100644
--- a/drivers/media/video/omap/Makefile
+++ b/drivers/media/video/omap/Makefile
@@ -5,3 +5,4 @@
# OMAP2/3 Display driver
omap-vout-y := omap_vout.o omap_voutlib.o
obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
+obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index e1df01c..e6c0fde 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -42,12 +42,9 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-#include plat/dma.h
-#include plat/vrfb.h
-#include plat/display.h
-
#include omap_voutlib.h
#include omap_voutdef.h
+#include omap_vout_vrfb.h
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
@@ -143,41 +140,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Function for allocating video buffers
- */
-static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
- unsigned int *count, int startindex)
-{
- int i, j;
-
- for (i = 0; i *count; i++) {
- if (!vout-smsshado_virt_addr[i]) {
- vout-smsshado_virt_addr[i] =
- omap_vout_alloc_buffer(vout-smsshado_size,
- vout-smsshado_phy_addr[i]);
- }
- if (!vout-smsshado_virt_addr[i] startindex != -1) {
- if (V4L2_MEMORY_MMAP == vout-memory i = startindex)
- break;
- }
- if (!vout-smsshado_virt_addr[i]) {
- for (j = 0; j i; j++) {
- omap_vout_free_buffer(
- vout-smsshado_virt_addr[j],
- vout-smsshado_size);
- vout-smsshado_virt_addr[j] = 0;
- vout-smsshado_phy_addr[j] = 0;
- }
- *count = 0;
- return -ENOMEM;
- }
- memset((void *) vout-smsshado_virt_addr[i], 0,
- vout-smsshado_size);
- }
- return 0;
-}
-
-/*
* Try format
*/
static int omap_vout_try_format(struct v4l2_pix_format *pix)
@@ -270,36 +232,9 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
}
/*
- * Wakes up the application once the DMA transfer to VRFB space is completed.
- */
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
-{
- struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
-
- t-tx_status = 1;
- wake_up_interruptible(t-wait);
-}
-
-/*
- * Release the VRFB context once the module exits
- */
-static void omap_vout_release_vrfb(struct omap_vout_device *vout)
-{
- int i;
-
- for (i = 0; i VRFB_NUM_BUFS; i++)
- omap_vrfb_release_ctx(vout-vrfb_context[i]);
-
- if (vout-vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
- vout-vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout-vrfb_dma_tx.dma_ch);
- }
-}
-
-/*
* Free the V4L2 buffers
*/
-static void omap_vout_free_buffers(struct
Re: twl4030_usb porting advice
On 12/16/10 09:09, Felipe Balbi wrote: On Wed, Dec 15, 2010 at 01:09:42PM +, Tomasz Mloduchowski wrote: On 12/15/10 12:39, Felipe Balbi wrote: On Wed, Dec 15, 2010 at 12:27:10PM +, Tomasz Mloduchowski wrote: I would gladly welcome any pointers that could help me solve this issue. you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP can't handle port handoff to companion OHCI controller, then it fails not being able to enumerate the device. Try remuxing your port to OHCI controller and disabling EHCI from Kconfig. It actually is a HS device (it's a 4-port hub) - when booting the vendor supplied kernel (based off 2.6.32, i.e. pre -IR redesign), the device identifies as follows: I've also made a mistake describing the pastebins - the working, PSP kernel boot log is here: http://pastie.org/1379102 while the non-working git kernel messages are here (with CONFIG_USB_DEBUG): http://pastie.org/1379100 I'm quoting a snippet below for commenting. [ 1.639892] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.646759] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96 [ 1.646881] ehci-omap ehci-omap.0: failed to get ehci port1 regulator This is alarming. Please add this patch to get the error code: This is also alarming... Let's increase the timeout just for a debugging purpose: I've applied both patches. The new kernel log in its entirety resides here: http://pastie.org/1384896 And the line of interest is [2.085449] ehci-omap ehci-omap.0: failed to get ehci port1 regulator -- 0 Unfortunately, I don't understand what an error code of '0' might mean here, but it surely does something. Cheers, Tomasz -- 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
