Re: Inventra Highspeed Dual Role Controller on TI OMAP 3503
that's no official documentation. It's better to check device's datasheet when you have such questions. Besides, imagine the pain it would be to patch that Kconfig entry everytime we have a new release of an OMAP processor. Maybe it would be better to say something like: available on many OMAP processors instead of mentioning each and every one of them. It would be even better if the availability could be discovered at runtime. Cheers, Peter. -- To unsubscribe from this list: send the line unsubscribe 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 0/4] omap: iovmm - fixes for iovmm module
From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module Date: Mon, 25 Oct 2010 21:10:02 +0200 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap
Hi Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 29, 2010 5:36 AM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org; b-cous...@ti.com;
khil...@deeprootsystems.com
Subject: Re: [PATCH 1/6] OMAP: powerdomain: Move powerdomain.c from
mach-omap2 to plat-omap
Hello Rajendra,
some comments:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
The platform-independent code would reside in plat-omap/powerdomain.c
and the platform-specific code will resides in
mach-omap2/powerdomain-.c files.
Since we're not implementing powerdomain support for OMAP1 right now, is
there any reason why we can't just leave the powerdomain-common stuff in
the mach-omap2/ directory for now?
There was no other reason why I moved these in plat-omap
except to keep the split similar to the way clock framework
is done. I should be able to keep this in mach-omap2 itself.
Regards,
Rajendra
Some of the hacks to include header files are done to make sure the
patch compiles and works fine. These hacks will be removed in the
subsequent patches.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/plat-omap/Makefile |6 +++---
arch/arm/{mach-omap2 = plat-omap}/powerdomain.c | 14
+++---
3 files changed, 11 insertions(+), 11 deletions(-)
rename arch/arm/{mach-omap2 = plat-omap}/powerdomain.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile
index 60e51bc..4bfadc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -9,7 +9,7 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o
gpmc.o timer-gp.o pm.o \
omap-2-3-common= irq.o sdrc.o
prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
-prcm-common= prcm.o powerdomain.o
+prcm-common= prcm.o
clock-common = clock.o
clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..424a9ae 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -13,9 +13,9 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# omap_device support (OMAP2+ only at the moment)
-obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP2) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP3) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_device.o powerdomain.o
The powerdomain code isn't directly related to the omap_device code, so
please create a new section in the mach-omap2/Makefile for this stuff.
Perhaps something like:
# OMAP PRCM powerdomain support
obj-$(CONFIG_ARCH_OMAP2) += powerdomain.o
obj-$(CONFIG_ARCH_OMAP3) += powerdomain.o
obj-$(CONFIG_ARCH_OMAP4) += powerdomain.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/plat-omap/powerdomain.c
similarity index 99%
rename from arch/arm/mach-omap2/powerdomain.c
rename to arch/arm/plat-omap/powerdomain.c
(see the first comment)
index 6527ec3..9204799 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -26,19 +26,19 @@
#include asm/atomic.h
-#include cm.h
-#include cm-regbits-34xx.h
-#include cm-regbits-44xx.h
-#include prm.h
-#include prm-regbits-34xx.h
-#include prm-regbits-44xx.h
+#include ../mach-omap2/cm.h
+#include ../mach-omap2/cm-regbits-34xx.h
+#include ../mach-omap2/cm-regbits-44xx.h
+#include ../mach-omap2/prm.h
+#include ../mach-omap2/prm-regbits-34xx.h
+#include ../mach-omap2/prm-regbits-44xx.h
#include plat/cpu.h
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/prcm.h
-#include pm.h
+#include ../mach-omap2/pm.h
enum {
PWRDM_STATE_NOW = 0,
--
1.7.0.4
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] Split powerdomain framework into plat specific/independent
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, November 29, 2010 6:04 AM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org; b-cous...@ti.com; khil...@deeprootsystems.com Subject: Re: [PATCH 0/6] Split powerdomain framework into plat specific/independent Hi Rajendra, As you've seen, I just did another review pass on these. All of the review comments are pretty minor, although some of them will require moving some of the functions to different files, mostly due to OMAP3 functions being present in an OMAP2xxx file. Thanks for the review. I'll do the necessary changes and post another version of the series soon. Regards, Rajendra Once those changes are made and the series reposted, I think these will be good to merge. regards - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Sat, Nov 27, 2010 at 12:53 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, Nov 27, 2010 at 12:18:55AM +0200, Ohad Ben-Cohen wrote:
But then there's the other (quite reasonable) claim that says we
shouldn't crash the machine because of a non fatal bug: if a crappy
driver messes up, the user (not the developer) will most probably
prefer the machine to keep running with degraded functionality rather
than boot.
There's also the quite reasonable expectation that we shouldn't corrupt
user data. With locking interfaces, if someone abuses them and they
fail to work, then the risk is data corruption due to races. The safe
thing in that case is to panic - terminate that thread before it does
anything unsafe, thereby preventing data corruption.
Makes sense.
I considered hwspinlock as a peripheral which doesn't qualify to take
down the system on failure, but in general I agree that there indeed
might be critical user data involved. Especially if this is a
framework and not just another driver.
But as a framework that can be used on non ARM architectures as well,
I do prefer to check for NULL pointers and not rely on the Oops.
If we had a macro that would be compiled out on architectures that
reliably produces an Oops on NULL dereference, but otherwise, would
BUG_ON on them, that should satisfy everyone.
The BUG_ON_MAPPABLE_NULL() macro below should achieve exactly that,
please tell me what you think, thanks!
arch/arm/include/asm/mman.h |1 +
include/asm-generic/bug.h | 40
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/mman.h b/arch/arm/include/asm/mman.h
index 41f99c5..d4ee003 100644
--- a/arch/arm/include/asm/mman.h
+++ b/arch/arm/include/asm/mman.h
@@ -1,4 +1,5 @@
#include asm-generic/mman.h
+#include asm/pgtable.h
#define arch_mmap_check(addr, len, flags) \
(((flags) MAP_FIXED (addr) FIRST_USER_ADDRESS) ? -EINVAL : 0)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index c2c9ba0..d211d9c 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -2,6 +2,11 @@
#define _ASM_GENERIC_BUG_H
#include linux/compiler.h
+#include asm/mman.h
+
+#ifndef arch_mmap_check
+#define arch_mmap_check(addr, len, flags) (0)
+#endif
#ifdef CONFIG_BUG
@@ -53,6 +58,41 @@ struct bug_entry {
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
#endif
+/**
+ * BUG_ON_MAPPABLE_NULL() - panic on NULL only if address 0 is mappable
+ * @addr: address to check
+ *
+ * In general, NULL dereference Oopses are not desirable, since they take down
+ * the system with them and make the user extremely unhappy. So as a general
+ * rule kernel code should avoid dereferencing NULL pointers by doing a
+ * simple check (when appropriate), and if needed, continue operating
+ * with reduced functionality rather than crash.
+ *
+ * _Critical_ kernel code, OTOH, that should not (/cannot) keep running when
+ * given an unexpected NULL pointer, should just crash. On some architectures,
+ * a NULL dereference will always reliably produce an Oops. On others, where
+ * the zero address can be mmapped, an Oops is not guaranteed. Relying on
+ * NULL dereference Oopses to happen on these architectures might lead to
+ * data corruptions (system will keep running despite a critical bug and
+ * the results will be horribly undefined). In addition, these situations
+ * can also have security implications - we have seen several privilege
+ * escalation exploits with which an attacker gained full control over the
+ * system due to NULL dereference bugs.
+ *
+ * This macro will BUG_ON if @addr is NULL on architectures where the zero
+ * addresses can be mapped. On other architectures, where the zero address
+ * can never be mapped, this macro is compiled out, so the system will just
+ * Oops when the @addr is dereferenced.
+ *
+ * As with BUG_ON, use this macro only if a NULL @addr cannot be tolerated.
+ * If proceeding with degraded functionality is an option, it's much
+ * better to just simply check for the NULL and returning instead of crashing
+ * the system.
+ */
+#define BUG_ON_MAPPABLE_NULL(addr) do { \
+ if (arch_mmap_check(0, 1, MAP_FIXED) == 0) BUG_ON(!addr); \
+} while(0)
+
/*
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant issues that need prompt attention if they should ever
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Sat, Nov 27, 2010 at 3:24 AM, David Brownell davi...@pacbell.net wrote: Your intent generic is fine, but you've not achieved it and thus I think you shouldn't imply that you have. Dropping the word generic should suffice; it _is_ a framework, and maybe the next person working with hardware spinlocks can finish generalizing (and add use cases). Sure, I can drop the word generic. Haven't looked at RT in a long time. Just look at the current RT patchset to see if it still has several spinlock variants. ISTR the raw spinlock stuff came from there not long ago. Much compile-time magic was involved in switching between variants. I'll take a look there and see if I catch anything relevant. Thanks, Ohad. - 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
[PATCH V4 2/2] omap4: platform changes for CMA3000
From 8082870cc704d901d98cf0d6af90e45860927ceb Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Thu, 26 Aug 2010 17:49:12 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver
Update 4430 SDP board file with platform data for accelerometer driver
and select the driver in kconfig
Signed-off-by: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 ++
arch/arm/mach-omap2/board-4430sdp.c | 30 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a928fd6..e87c049 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -255,6 +255,8 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select INPUT_TOUCHSCREEN
select TOUCHSCREEN_SYNTM12XX
+ select INPUT_MISC
+ select INPUT_CMA3000
+ select INPUT_CMA3000_I2C
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ed78cdb..8b94f1f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,8 @@
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
+#include linux/input/cma3000.h
+#include linux/interrupt.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -44,6 +46,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4SDP_MDM_PWR_EN_GPIO 157
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_CMA3000ACCL_GPIO 186
#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
@@ -485,6 +488,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3 = sdp4430_vaux3,
};
+static struct cma3000_platform_data cma3000_platform_data = {
+ .fuzz_x = 25,
+ .fuzz_y = 25,
+ .fuzz_z = 25,
+ .g_range = CMARANGE_8G,
+ .mode = CMAMODE_MOTDET,
+ .mdthr = 0x8,
+ .mdfftmr = 0x33,
+ .ffthr = 0x8,
+ .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+ if (gpio_request(OMAP4_CMA3000ACCL_GPIO, Accelerometer) 0) {
+ pr_err(Accelerometer GPIO request failed\n);
+ return;
+ }
+ gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl6030, 0x48),
@@ -518,6 +542,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO(hmc5843, 0x1e),
},
+ {
+ I2C_BOARD_INFO(cma3000_d01, 0x1c),
+ .platform_data = cma3000_platform_data,
+ .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+ },
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
@@ -570,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+ omap_cma3000accl_init();
}
static void __init omap_4430sdp_init(void)
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe 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] input: CMA3000 Accelerometer Driver
From 9985dc1211ae33baa877489c26920dfd1c29bb35 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Thu, 26 Aug 2010 17:44:48 +0530 Subject: [PATCH] input: CMA3000 Accelerometer Driver Add support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem Signed-off-by: Hemanth V heman...@ti.com Reviewed-by: Jonathan Cameron ji...@cam.ac.uk Reviewed-by: Sergio Aguirre saagui...@ti.com Reviewed-by: Shubhrajyoti shubhrajy...@ti.com --- This is V4 of patch, which currently doesnot support a sysfs interface. Discussions are ongoing to create a standard sysfs interface for sensors under input subsystem. This interface would be adopted by the driver subsequently. Documentation/input/cma3000_d0x.txt | 115 drivers/input/misc/Kconfig | 24 +++ drivers/input/misc/Makefile |2 + drivers/input/misc/cma3000_d0x.c | 334 ++ drivers/input/misc/cma3000_d0x.h | 53 ++ drivers/input/misc/cma3000_d0x_i2c.c | 142 ++ include/linux/input/cma3000.h| 60 ++ 7 files changed, 730 insertions(+), 0 deletions(-) create mode 100644 Documentation/input/cma3000_d0x.txt create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/input/cma3000.h diff --git a/Documentation/input/cma3000_d0x.txt b/Documentation/input/cma3000_d0x.txt new file mode 100644 index 000..9cc46af --- /dev/null +++ b/Documentation/input/cma3000_d0x.txt @@ -0,0 +1,115 @@ +Kernel driver for CMA3000-D0x + + +Supported chips: +* VTI CMA3000-D0x +Datasheet: + CMA3000-D0X Product Family Specification 8281000A.02.pdf + http://www.vti.fi/en/ + +Author: Hemanth V heman...@ti.com + + +Description +--- +CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and +Free fall modes. + +Motion Detect Mode: Its the low power mode where interrupts are generated only +when motion exceeds the defined thresholds. + +Measurement Mode: This mode is used to read the acceleration data on X,Y,Z +axis and supports 400, 100, 40 Hz sample frequency. + +Free fall Mode: This mode is intented to save system resources. + +Threshold values: Chip supports defining threshold values for above modes +which includes time and g value. Refer product specifications for more details. + +CMA3000 chip supports mutually exclusive I2C and SPI interfaces for +communication, currently the driver supports I2C based communication only. +Initial configuration for bus mode is set in non volatile memory and can later +be modified through bus interface command. + +Driver reports acceleration data through input subsystem. It generates ABS_MISC +event with value 1 when free fall is detected. + +Platform data need to be configured for initial default values. + +Platform Data +- +fuzz_x: Noise on X Axis + +fuzz_y: Noise on Y Axis + +fuzz_z: Noise on Z Axis + +g_range: G range in milli g i.e 2000 or 8000 + +mode: Default Operating mode + +mdthr: Motion detect g range threshold value + +mdfftmr: Motion detect and free fall time threshold value + +ffthr: Free fall g range threshold value + +Input Interface +-- +Input driver version is 1.0.0 +Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 +Input device name: cma3000-accelerometer +Supported events: + Event type 0 (Sync) + Event type 3 (Absolute) +Event code 0 (X) + Value 47 + Min-8000 + Max 8000 + Fuzz 200 +Event code 1 (Y) + Value-28 + Min-8000 + Max 8000 + Fuzz 200 +Event code 2 (Z) + Value905 + Min-8000 + Max 8000 + Fuzz 200 +Event code 40 (Misc) + Value 0 + Min0 + Max1 + Event type 4 (Misc) + + +Register/Platform parameters Description + + +mode: + 0: power down mode + 1: 100 Hz Measurement mode + 2: 400 Hz Measurement mode + 3: 40 Hz Measurement mode + 4: Motion Detect mode (default) + 5: 100 Hz Free fall mode + 6: 40 Hz Free fall mode + 7: Power off mode + +grange: + 2000: 2000 mg or 2G Range + 8000: 8000 mg or 8G Range + +mdthr: + X: X * 71mg (8G Range) + X: X * 18mg (2G Range) + +mdfftmr: + X: (X 0x70) * 100 ms (MDTMR) + (X 0x0F) * 2.5 ms (FFTMR 400 Hz) + (X 0x0F) * 10 ms (FFTMR 100 Hz) + +ffthr: + X: (X 2) * 18mg (2G Range) + X: (X 0x0F) * 71 mg (8G Range) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index b99b8cb..d5e5fd6 100644 --- a/drivers/input/misc/Kconfig +++
Re: PATCH V4 1/2] input: CMA3000 Accelerometer Driver
On 11/29/10 10:57, Hemanth V wrote: From 9985dc1211ae33baa877489c26920dfd1c29bb35 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Thu, 26 Aug 2010 17:44:48 +0530 Subject: [PATCH] input: CMA3000 Accelerometer Driver Add support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem Couple of nitpicks inline. There's one unneeded NULL assignment that should probably be cleaned up. I'd also like to see actual part numbers listed somewhere in the Kconfig help text. The removal of various temporary variables is something I know at least one other reviewer has commented on. Basically they may make the code look cleaner, but they add (marginally) to the review burden and that's annoys reviewers ;) Anyhow, all the comments are trivial. Nice driver Hemanth. Dmitry: This is clean and for now has none of the controversial sysfs interfaces so baring the input bits (which I'm not as familiar with and you might want to glance over) this looks ready to merge to me. Signed-off-by: Hemanth V heman...@ti.com Reviewed-by: Jonathan Cameron ji...@cam.ac.uk Reviewed-by: Sergio Aguirre saagui...@ti.com Reviewed-by: Shubhrajyoti shubhrajy...@ti.com Acked-by: Jonathan Cameron ji...@cam.ac.uk (no idea if the convention is to remove the Reviewed-by when someone has acked or not...) --- This is V4 of patch, which currently doesnot support a sysfs interface. Discussions are ongoing to create a standard sysfs interface for sensors under input subsystem. This interface would be adopted by the driver subsequently. Documentation/input/cma3000_d0x.txt | 115 drivers/input/misc/Kconfig | 24 +++ drivers/input/misc/Makefile |2 + drivers/input/misc/cma3000_d0x.c | 334 ++ drivers/input/misc/cma3000_d0x.h | 53 ++ drivers/input/misc/cma3000_d0x_i2c.c | 142 ++ include/linux/input/cma3000.h| 60 ++ 7 files changed, 730 insertions(+), 0 deletions(-) create mode 100644 Documentation/input/cma3000_d0x.txt create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/input/cma3000.h diff --git a/Documentation/input/cma3000_d0x.txt b/Documentation/input/cma3000_d0x.txt new file mode 100644 index 000..9cc46af --- /dev/null +++ b/Documentation/input/cma3000_d0x.txt @@ -0,0 +1,115 @@ +Kernel driver for CMA3000-D0x + + +Supported chips: +* VTI CMA3000-D0x +Datasheet: + CMA3000-D0X Product Family Specification 8281000A.02.pdf + http://www.vti.fi/en/ + +Author: Hemanth V heman...@ti.com + + +Description +--- +CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and +Free fall modes. + +Motion Detect Mode: Its the low power mode where interrupts are generated only +when motion exceeds the defined thresholds. + +Measurement Mode: This mode is used to read the acceleration data on X,Y,Z +axis and supports 400, 100, 40 Hz sample frequency. + +Free fall Mode: This mode is intented to save system resources. + +Threshold values: Chip supports defining threshold values for above modes +which includes time and g value. Refer product specifications for more details. + +CMA3000 chip supports mutually exclusive I2C and SPI interfaces for +communication, currently the driver supports I2C based communication only. +Initial configuration for bus mode is set in non volatile memory and can later +be modified through bus interface command. + +Driver reports acceleration data through input subsystem. It generates ABS_MISC +event with value 1 when free fall is detected. + +Platform data need to be configured for initial default values. + +Platform Data +- +fuzz_x: Noise on X Axis + +fuzz_y: Noise on Y Axis + +fuzz_z: Noise on Z Axis + +g_range: G range in milli g i.e 2000 or 8000 + +mode: Default Operating mode + +mdthr: Motion detect g range threshold value + +mdfftmr: Motion detect and free fall time threshold value + +ffthr: Free fall g range threshold value + +Input Interface +-- +Input driver version is 1.0.0 +Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 +Input device name: cma3000-accelerometer +Supported events: + Event type 0 (Sync) + Event type 3 (Absolute) +Event code 0 (X) + Value 47 + Min-8000 + Max 8000 + Fuzz 200 +Event code 1 (Y) + Value-28 + Min-8000 + Max 8000 + Fuzz 200 +Event code 2 (Z) + Value905 + Min-8000 + Max 8000 + Fuzz 200 +
[PATCH v2 04/17] OMAP2420,OMAP2430,OMAP3xx: change dss driver name in clock files
From: Senthilvadivu Guruswamy svad...@ti.com
dss driver renamed to omap_ is done to align all the omap device names
with the same convention.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..316f6f6 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gfx_2d_fck, gfx_2d_fck,CK_242X),
CLK(NULL, gfx_ick, gfx_ick, CK_242X),
/* DSS domain clocks */
- CLK(omapdss, ick, dss_ick, CK_242X),
- CLK(omapdss, dss1_fck, dss1_fck, CK_242X),
- CLK(omapdss, dss2_fck, dss2_fck, CK_242X),
- CLK(omapdss, tv_fck, dss_54m_fck, CK_242X),
+ CLK(omap_dss, ick, dss_ick, CK_242X),
+ CLK(omap_dss, dss1_fck, dss1_fck, CK_242X),
+ CLK(omap_dss, dss2_fck, dss2_fck, CK_242X),
+ CLK(omap_dss, tv_fck, dss_54m_fck, CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index e32afcb..b7fc6c6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1890,10 +1890,10 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omapdss, ick, dss_ick, CK_243X),
- CLK(omapdss, dss1_fck, dss1_fck, CK_243X),
- CLK(omapdss, dss2_fck, dss2_fck, CK_243X),
- CLK(omapdss, tv_fck, dss_54m_fck, CK_243X),
+ CLK(omap_dss, ick, dss_ick, CK_243X),
+ CLK(omap_dss, dss1_fck, dss1_fck, CK_243X),
+ CLK(omap_dss, dss2_fck, dss2_fck, CK_243X),
+ CLK(omap_dss, tv_fck, dss_54m_fck, CK_243X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d85ecd5..98dc66e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3347,13 +3347,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
- CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 |
CK_AM35XX),
- CLK(omapdss, tv_fck, dss_tv_fck,CK_3XXX),
- CLK(omapdss, video_fck,dss_96m_fck, CK_3XXX),
- CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_3XXX),
- CLK(omapdss, ick, dss_ick_3430es1, CK_3430ES1),
- CLK(omapdss, ick, dss_ick_3430es2, CK_3430ES2 |
CK_AM35XX),
+ CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 |
CK_AM35XX),
+ CLK(omap_dss, tv_fck, dss_tv_fck,CK_3XXX),
+ CLK(omap_dss, video_fck,dss_96m_fck, CK_3XXX),
+ CLK(omap_dss, dss2_fck, dss2_alwon_fck, CK_3XXX),
+ CLK(omap_dss, ick, dss_ick_3430es1, CK_3430ES1),
+ CLK(omap_dss, ick, dss_ick_3430es2, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 14/17] OMAP2,3: DSS: VENC Move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Move init exit methods to its driver probe, remove.
pdev member has to be maintained by its own drivers.
regulator has to be privately handled in each driver.
Replace printk to dev_dbg for boot time optimize.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
drivers/video/omap2/dss/core.c | 29 ---
drivers/video/omap2/dss/dss.h |1 -
drivers/video/omap2/dss/venc.c | 88 ++
4 files changed, 48 insertions(+), 72 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7ff747e..2e3c68b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,7 +302,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
- REGULATOR_SUPPLY(vdda_dac, omap_display);
+ REGULATOR_SUPPLY(vdda_dac, omap_venc);
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 3711553..6f9fc38 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,7 +43,6 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
- struct regulator *vdda_dac_reg;
} core;
static char *def_disp_name;
@@ -85,20 +84,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
-struct regulator *dss_get_vdda_dac(void)
-{
- struct regulator *reg;
-
- if (core.vdda_dac_reg != NULL)
- return core.vdda_dac_reg;
-
- reg = regulator_get(core.pdev-dev, vdda_dac);
- if (!IS_ERR(reg))
- core.vdda_dac_reg = reg;
-
- return reg;
-}
-
#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
static int dss_debug_show(struct seq_file *s, void *unused)
{
@@ -198,12 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = venc_init(pdev);
- if (r) {
- DSSERR(Failed to initialize venc\n);
- goto err_venc;
- }
-
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -253,8 +232,6 @@ err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
err_sdi:
- venc_exit();
-err_venc:
dpi_exit();
err_dpi:
@@ -268,7 +245,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- venc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
@@ -561,11 +537,6 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
- if (core.vdda_dac_reg != NULL) {
- regulator_put(core.vdda_dac_reg);
- core.vdda_dac_reg = NULL;
- }
-
platform_driver_unregister(omap_dss_driver);
omap_dss_bus_unregister();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 0029aff..734e052 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -172,7 +172,6 @@ struct platform_device;
struct bus_type *dss_get_bus(void);
struct regulator *dss_get_vdds_dsi(void);
struct regulator *dss_get_vdds_sdi(void);
-struct regulator *dss_get_vdda_dac(void);
/* display */
int dss_suspend_all_devices(void);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index ac63cee..4e84e71 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -289,6 +289,7 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
EXPORT_SYMBOL(omap_dss_ntsc_timings);
static struct {
+ struct platform_device *pdev;
void __iomem *base;
struct mutex venc_lock;
u32 wss_data;
@@ -306,6 +307,17 @@ static inline u32 venc_read_reg(int idx)
return l;
}
+static struct regulator *venc_get_vdda_dac(void)
+{
+ struct regulator *reg;
+
+ reg = regulator_get(venc.pdev-dev, vdda_dac);
+ if (!IS_ERR(reg))
+ venc.vdda_dac_reg = reg;
+
+ return reg;
+}
+
static void venc_write_config(const struct venc_config *config)
{
DSSDBG(write venc conf\n);
@@ -641,46 +653,6 @@ static struct omap_dss_driver venc_driver = {
};
/* driver end */
-
-
-int venc_init(struct platform_device *pdev)
-{
- u8 rev_id;
-
- mutex_init(venc.venc_lock);
-
- venc.wss_data = 0;
-
- venc.base = ioremap(VENC_BASE, SZ_1K);
- if (!venc.base) {
- DSSERR(can't ioremap VENC\n);
- return -ENOMEM;
- }
-
- venc.vdda_dac_reg = dss_get_vdda_dac();
- if (IS_ERR(venc.vdda_dac_reg)) {
- iounmap(venc.base);
- DSSERR(can't get VDDA_DAC regulator\n);
-
[PATCH v2 00/17] OMAP2,3: hwmod DSS Adaptation
From: Senthilvadivu Guruswamy svad...@ti.com Patch Base: === url = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch master Commit id: 063d907edaf3fbf9776c189c3e02f2c7a129d18c Description: Linux-omap rebuilt: Merged serial console fixes, cleanup v2 of the DSS hwmod patch series focus on fixing the review comments. OMAP4 support will be posted after the acceptance of this basic change in the dss2 design. This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omapdss driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omapdss driver. Omapdss platform driver - initialises necessary software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of omapdss driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DSS IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. Changes since RFC: --- 1) All the platform driver registration except DSS, were within the file core.c. Registeration of these driver got seperated to its own file. 2) Usage of regulators by different drivers are implemented. For Eg: Regulator used by VENC is moved to venc driver. But vdda_dac would be needed by DPI and DSI as well. 4) OMAP2420 and OMAP2430 hwmod database are generated in this v1. 5) Module support for omapdss driver can continue as the DSS HW IP specific platform
[PATCH v2 08/17] OMAP2,3: DSS: Create platform_driver for each DSS HW IP
From: Senthilvadivu Guruswamy svad...@ti.com
Platform driver of dsshw has to be registered before of dispc,
rfbi, dsi1, venc and omapdisplay driver should be after all
the hw IPs. Sequence it with arch_initcall and device_initcall_sync
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c |2 +-
drivers/video/omap2/dss/dispc.c | 28
drivers/video/omap2/dss/dsi.c | 29 -
drivers/video/omap2/dss/dss.c | 27 +++
drivers/video/omap2/dss/rfbi.c | 28
drivers/video/omap2/dss/venc.c | 28
6 files changed, 140 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..d165434 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -989,7 +989,7 @@ static int __init omap_dss_init2(void)
}
core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
#endif
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa40fa5..942dea5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3167,3 +3167,31 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = omap_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dispc_init(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
+
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aa4f7a5..037d366 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -292,7 +292,6 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
}
-
void dsi_save_context(void)
{
}
@@ -3304,3 +3303,31 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
}
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .driver = {
+ .name = omap_dsi1,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dsi1_init(void)
+{
+ return platform_driver_register(omap_dsi1hw_driver);
+}
+
+device_initcall(omap_dsi1_init);
+
+
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..6d0bd89 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -639,3 +639,30 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = omap_dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dss_init1(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+arch_initcall(omap_dss_init1);
+
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..a086233 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1054,3 +1054,31 @@ int rfbi_init_display(struct omap_dss_device *dssdev)
dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 0;
}
+
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_rfbihw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_rfbihw_driver = {
+ .probe = omap_rfbihw_probe,
+ .remove = omap_rfbihw_remove,
+ .driver = {
+ .name = omap_rfbi,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_rfbi_init(void)
+{
+ return platform_driver_register(omap_rfbihw_driver);
+}
+
+device_initcall(omap_rfbi_init);
+
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index
[PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Database generated for OMAP2420 Display Sub System.
Since dss is also considered as an IP as dispc,rfbi,
name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 283
1 files changed, 283 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..0f5ca11 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -37,6 +37,10 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_dss_dss_hwmod;
+static struct omap_hwmod omap2420_dss_dispc_hwmod;
+static struct omap_hwmod omap2420_dss_rfbi_hwmod;
+static struct omap_hwmod omap2420_dss_venc_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
/* L3 - L4_CORE interface */
@@ -58,6 +62,13 @@ static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] =
{
omap2420_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
+ .master = omap2420_dss_dss_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2420_l3_main_masters[] = {
omap2420_l3_main__l4_core,
@@ -463,6 +474,272 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap2420_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2420_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
+ omap2420_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap2420_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
+ omap2420_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_54m_fck },
+ { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2420_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap2420_dss_hwmod_class,
+ .main_clk = dss1_fck, /* instead of dss_fck */
+ .mpu_irqs = omap2420_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dss_irqs),
+ .sdma_reqs = omap2420_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap2420_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dss_slaves),
+ .masters= omap2420_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dss_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes =
[PATCH v2 13/17] OMAP2,3: DSS: DISPC Move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Move init exit methods to its driver probe,remove.
pdev member has to be maintained by its own drivers.
Replace printk with dev_dbg for boot time optimize
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c |9 -
drivers/video/omap2/dss/dispc.c | 75 +-
2 files changed, 34 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index edb025c..3711553 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -198,12 +198,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = dispc_init();
- if (r) {
- DSSERR(Failed to initialize dispc\n);
- goto err_dispc;
- }
-
r = venc_init(pdev);
if (r) {
DSSERR(Failed to initialize venc\n);
@@ -261,8 +255,6 @@ err_dsi:
err_sdi:
venc_exit();
err_venc:
- dispc_exit();
-err_dispc:
dpi_exit();
err_dpi:
@@ -277,7 +269,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
venc_exit();
- dispc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 942dea5..57de1c9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -173,6 +173,7 @@ struct dispc_irq_stats {
};
static struct {
+ struct platform_device *pdev;
void __iomem*base;
u32 fifo_size[3];
@@ -3079,47 +3080,6 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
}
-int dispc_init(void)
-{
- u32 rev;
-
- spin_lock_init(dispc.irq_lock);
-
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
- spin_lock_init(dispc.irq_stats_lock);
- dispc.irq_stats.last_reset = jiffies;
-#endif
-
- INIT_WORK(dispc.error_work, dispc_error_worker);
-
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
- if (!dispc.base) {
- DSSERR(can't ioremap DISPC\n);
- return -ENOMEM;
- }
-
- enable_clocks(1);
-
- _omap_dispc_initial_config();
-
- _omap_dispc_initialize_irq();
-
- dispc_save_context();
-
- rev = dispc_read_reg(DISPC_REVISION);
- printk(KERN_INFO OMAP DISPC rev %d.%d\n,
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- enable_clocks(0);
-
- return 0;
-}
-
-void dispc_exit(void)
-{
- iounmap(dispc.base);
-}
-
int dispc_enable_plane(enum omap_plane plane, bool enable)
{
DSSDBG(dispc_enable_plane %d, %d\n, plane, enable);
@@ -3171,11 +3131,44 @@ int dispc_setup_plane(enum omap_plane plane,
/* DISPC HW IP initialisation */
static int omap_dispchw_probe(struct platform_device *pdev)
{
+ u32 rev;
+ dispc.pdev = pdev;
+
+ spin_lock_init(dispc.irq_lock);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+ spin_lock_init(dispc.irq_stats_lock);
+ dispc.irq_stats.last_reset = jiffies;
+#endif
+
+ INIT_WORK(dispc.error_work, dispc_error_worker);
+
+ dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ if (!dispc.base) {
+ DSSERR(can't ioremap DISPC\n);
+ return -ENOMEM;
+ }
+
+ enable_clocks(1);
+
+ _omap_dispc_initial_config();
+
+ _omap_dispc_initialize_irq();
+
+ dispc_save_context();
+
+ rev = dispc_read_reg(DISPC_REVISION);
+ dev_dbg(pdev-dev, OMAP DISPC rev %d.%d\n,
+ FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
+
+ enable_clocks(0);
+
return 0;
}
static int omap_dispchw_remove(struct platform_device *pdev)
{
+ iounmap(dispc.base);
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 16/17] OMAP2,3: DSS: Use platform device to get baseaddr
From: Senthilvadivu Guruswamy svad...@ti.com
DSS, DISPC, DSI, RFBI, VENC baseaddr got from platform_device.
Hardcoding of base addr could be removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dispc.c | 11 ---
drivers/video/omap2/dss/dsi.c | 12 +---
drivers/video/omap2/dss/dss.c | 11 ---
drivers/video/omap2/dss/rfbi.c | 10 +++---
drivers/video/omap2/dss/venc.c | 11 ---
5 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 57de1c9..7ce65c6 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -42,8 +42,6 @@
#include dss_features.h
/* DISPC */
-#define DISPC_BASE 0x48050400
-
#define DISPC_SZ_REGS SZ_1K
struct dispc_reg { u16 idx; };
@@ -3132,6 +3130,8 @@ int dispc_setup_plane(enum omap_plane plane,
static int omap_dispchw_probe(struct platform_device *pdev)
{
u32 rev;
+ struct resource *dispc_mem;
+
dispc.pdev = pdev;
spin_lock_init(dispc.irq_lock);
@@ -3143,7 +3143,12 @@ static int omap_dispchw_probe(struct platform_device
*pdev)
INIT_WORK(dispc.error_work, dispc_error_worker);
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+ if (!dispc_mem) {
+ DSSERR(can't get IORESOURCE_MEM DISPC\n);
+ return -EINVAL;
+ }
+ dispc.base = ioremap(dispc_mem-start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR(can't ioremap DISPC\n);
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a8f3335..4d38de0 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,8 +42,6 @@
/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
-#define DSI_BASE 0x4804FC00
-
struct dsi_reg { u16 idx; };
#define DSI_REG(idx) ((const struct dsi_reg) { idx })
@@ -3239,6 +3237,7 @@ int dsi_init(struct platform_device *pdev)
{
u32 rev;
int r;
+ struct resource *dsi_mem;
spin_lock_init(dsi.errors_lock);
dsi.errors = 0;
@@ -3265,7 +3264,13 @@ int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
#endif
- dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+ dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+ if (!dsi_mem) {
+ DSSERR(can't get IORESOURCE_MEM DSI\n);
+ r = -EINVAL;
+ goto err0;
+ }
+ dsi.base = ioremap(dsi_mem-start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR(can't ioremap DSI\n);
r = -ENOMEM;
@@ -3292,6 +3297,7 @@ err2:
iounmap(dsi.base);
err1:
destroy_workqueue(dsi.workqueue);
+err0:
return r;
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index b622d04..f544160 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -35,8 +35,6 @@
#include dss.h
#include dss_features.h
-#define DSS_BASE 0x4805
-
#define DSS_SZ_REGSSZ_512
struct dss_reg {
@@ -569,8 +567,15 @@ int dss_init(bool skip_init)
{
int r;
u32 rev;
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+ if (!dss_mem) {
+ DSSERR(can't get IORESOURCE_MEM DSS\n);
+ r = -EINVAL;
+ goto fail0;
+ }
+ dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index fde8893..f167e8d 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,8 +36,6 @@
#include plat/display.h
#include dss.h
-#define RFBI_BASE 0x48050800
-
struct rfbi_reg { u16 idx; };
#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
@@ -1017,6 +1015,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
{
u32 rev;
u32 l;
+ struct resource *rfbi_mem;
rfbi.pdev = pdev;
@@ -1026,7 +1025,12 @@ static int omap_rfbihw_probe(struct platform_device
*pdev)
atomic_set(rfbi.cmd_fifo_full, 0);
atomic_set(rfbi.cmd_pending, 0);
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+ if (!rfbi_mem) {
+ DSSERR(can't get IORESOURCE_MEM RFBI\n);
+ return -EINVAL;
+ }
+ rfbi.base = ioremap(rfbi_mem-start,
[PATCH v2 15/17] OMAP2,3: DSS: DSI Move init, exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Move init exit methods to its driver probe, remove.
pdev member has to be maintained by its own drivers.
regulator has to be privately handled in each driver.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
drivers/video/omap2/dss/core.c |8
drivers/video/omap2/dss/dsi.c | 28 ++--
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 2e3c68b..2c3ddd8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -527,6 +527,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omap_display),
+ REGULATOR_SUPPLY(vdds_dsi, omap_dsi1),
};
static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 6f9fc38..21944d7 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -190,11 +190,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_sdi;
}
- r = dsi_init(pdev);
- if (r) {
- DSSERR(Failed to initialize DSI\n);
- goto err_dsi;
- }
}
r = dss_initialize_debugfs();
@@ -227,9 +222,6 @@ err_register:
dss_uninitialize_debugfs();
err_debugfs:
if (cpu_is_omap34xx())
- dsi_exit();
-err_dsi:
- if (cpu_is_omap34xx())
sdi_exit();
err_sdi:
dpi_exit();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 037d366..a8f3335 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -222,6 +222,7 @@ struct dsi_irq_stats {
static struct
{
+ struct platform_device *pdev;
void __iomem*base;
struct dsi_clock_info current_cinfo;
@@ -3271,7 +3272,7 @@ int dsi_init(struct platform_device *pdev)
goto err1;
}
- dsi.vdds_dsi_reg = dss_get_vdds_dsi();
+ dsi.vdds_dsi_reg = dsi_get_vdds_dsi();
if (IS_ERR(dsi.vdds_dsi_reg)) {
DSSERR(can't get VDDS_DSI regulator\n);
r = PTR_ERR(dsi.vdds_dsi_reg);
@@ -3306,11 +3307,20 @@ void dsi_exit(void)
/* DSI1 HW IP initialisation */
static int omap_dsi1hw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dsi.pdev = pdev;
+ r = dsi_init(pdev);
+ if (r) {
+ DSSERR(Failed to initialize DSI\n);
+ goto err_dsi;
+ }
+err_dsi:
+ return r;
}
static int omap_dsi1hw_remove(struct platform_device *pdev)
{
+ dsi_exit();
return 0;
}
@@ -3330,4 +3340,18 @@ static int __init omap_dsi1_init(void)
device_initcall(omap_dsi1_init);
+static struct regulator *dsi_get_vdds_dsi(void)
+{
+ struct regulator *reg;
+
+ if (dsi.vdds_dsi_reg != NULL)
+ return dsi.vdds_dsi_reg;
+
+ reg = regulator_get(dsi.pdev-dev, vdds_dsi);
+ if (!IS_ERR(reg))
+ dsi.vdds_dsi_reg = reg;
+
+ return reg;
+}
+
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 07/17] OMAP2,3: DSS: Build omap_device for each DSS HWIP
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the hwmod database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 +
arch/arm/plat-omap/include/plat/display.h |6 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f6eabe..9ae546e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -934,10 +934,60 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ },
+};
+
int __init omap_display_init(struct omap_dss_board_info
*board_data)
{
int r = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int i;
+ struct omap_display_platform_data pdata;
+ char *omap2_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc };
+ char *omap3_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc, dss_dsi1 };
+ char *omap2_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc };
+ char *omap3_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
+ char *(*oh_name)[];
+ char *(*dev_name)[];
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_name = omap2_oh_name;
+ dev_name = omap2_dev_name;
+ oh_count = ARRAY_SIZE(omap2_oh_name);
+ } else {
+ oh_name = omap3_oh_name;
+ dev_name = omap3_dev_name;
+ oh_count = ARRAY_SIZE(omap3_oh_name);
+ }
+
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+
+ for (i = 0; i oh_count; i++) {
+ oh = omap_hwmod_lookup((*oh_name)[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, (*oh_name)[i]);
+ return r;
+ }
+ od = omap_device_build((*dev_name)[i], -1, oh, pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+ (*oh_name)[i]);
+ }
omap_display_device.dev.platform_data = board_data;
r = platform_device_register(omap_display_device);
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 871bbae..23afd6d 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,7 @@
#include linux/platform_device.h
#include asm/atomic.h
+
#define DISPC_IRQ_FRAMEDONE(1 0)
#define DISPC_IRQ_VSYNC(1 1)
#define DISPC_IRQ_EVSYNC_EVEN (1 2)
@@ -224,6 +225,11 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+struct omap_display_platform_data {
+ struct omap_dss_board_info *board_data;
+ /* TODO: Additional members to be added when PM is considered */
+};
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 17/17] OMAP2,3: DSS: Get DSS IRQ from platform device
From: Senthilvadivu Guruswamy svad...@ti.com
DSS IRQ got from platform device.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dss.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index f544160..8fafae9 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -565,7 +565,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
int dss_init(bool skip_init)
{
- int r;
+ int r, dss_irq;
u32 rev;
struct resource *dss_mem;
@@ -611,15 +611,18 @@ int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq != -ENXIO) {
+ r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, OMAP DSS, NULL);
- if (r 0) {
- DSSERR(omap2 dss: request_irq failed\n);
- goto fail1;
+ if (r 0) {
+ DSSERR(omap2 dss: request_irq failed\n);
+ goto fail1;
+ }
}
if (cpu_is_omap34xx()) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 12/17] OMAP2,3: DSS: RFBI Move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Move init exit methods to its driver probe,remove.
pdev member has to be maintained by its own drivers.
Replace printk with dev_dbg for boot time optimize
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c |9
drivers/video/omap2/dss/rfbi.c | 80 ++--
2 files changed, 36 insertions(+), 53 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5b0f551..edb025c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -192,12 +192,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = rfbi_init();
- if (r) {
- DSSERR(Failed to initialize rfbi\n);
- goto err_rfbi;
- }
-
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
@@ -271,8 +265,6 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
-err_rfbi:
return r;
}
@@ -287,7 +279,6 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a086233..fde8893 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings *t);
static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
static struct {
+ struct platform_device *pdev;
void __iomem*base;
unsigned long l4_khz;
@@ -957,50 +958,6 @@ void rfbi_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-int rfbi_init(void)
-{
- u32 rev;
- u32 l;
-
- spin_lock_init(rfbi.cmd_lock);
-
- init_completion(rfbi.cmd_done);
- atomic_set(rfbi.cmd_fifo_full, 0);
- atomic_set(rfbi.cmd_pending, 0);
-
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
- if (!rfbi.base) {
- DSSERR(can't ioremap RFBI\n);
- return -ENOMEM;
- }
-
- rfbi_enable_clocks(1);
-
- msleep(10);
-
- rfbi.l4_khz = dss_clk_get_rate(DSS_CLK_ICK) / 1000;
-
- /* Enable autoidle and smart-idle */
- l = rfbi_read_reg(RFBI_SYSCONFIG);
- l |= (1 0) | (2 3);
- rfbi_write_reg(RFBI_SYSCONFIG, l);
-
- rev = rfbi_read_reg(RFBI_REVISION);
- printk(KERN_INFO OMAP RFBI rev %d.%d\n,
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- rfbi_enable_clocks(0);
-
- return 0;
-}
-
-void rfbi_exit(void)
-{
- DSSDBG(rfbi_exit\n);
-
- iounmap(rfbi.base);
-}
-
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev)
{
int r;
@@ -1058,11 +1015,46 @@ int rfbi_init_display(struct omap_dss_device *dssdev)
/* RFBI HW IP initialisation */
static int omap_rfbihw_probe(struct platform_device *pdev)
{
+ u32 rev;
+ u32 l;
+
+ rfbi.pdev = pdev;
+
+ spin_lock_init(rfbi.cmd_lock);
+
+ init_completion(rfbi.cmd_done);
+ atomic_set(rfbi.cmd_fifo_full, 0);
+ atomic_set(rfbi.cmd_pending, 0);
+
+ rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ if (!rfbi.base) {
+ DSSERR(can't ioremap RFBI\n);
+ return -ENOMEM;
+ }
+
+ rfbi_enable_clocks(1);
+
+ msleep(10);
+
+ rfbi.l4_khz = dss_clk_get_rate(DSS_CLK_ICK) / 1000;
+
+ /* Enable autoidle and smart-idle */
+ l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l |= (1 0) | (2 3);
+ rfbi_write_reg(RFBI_SYSCONFIG, l);
+
+ rev = rfbi_read_reg(RFBI_REVISION);
+ dev_dbg(pdev-dev, OMAP RFBI rev %d.%d\n,
+ FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
+
+ rfbi_enable_clocks(0);
+
return 0;
}
static int omap_rfbihw_remove(struct platform_device *pdev)
{
+ iounmap(rfbi.base);
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 03/17] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Database generated for Display Sub System applicable for
OMAP3430-ES2 onwards and OMAP36xx.
dss is also considered as an IP as dispc,rfbi, and named as dss_dss.
For all the IP modules in DSS, same clock is needed for enabling.
hwmod sees as independent IPs, so same clock has to be
repeated as .mainclk in each IP.
OMAP3430ES1 do not have IDLEST bit to poll on for dss IP. So this hwmod
is not applicable for 3430ES1.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 339
1 files changed, 339 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a8bed84..6e719b7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -42,6 +42,11 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
+static struct omap_hwmod omap3xxx_dss_dss_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
@@ -72,6 +77,13 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] =
{
omap3xxx_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+ .master = omap3xxx_dss_dss_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l3_main_masters[] = {
omap3xxx_l3_main__l4_core,
@@ -613,6 +625,326 @@ static struct omap_hwmod_class i2c_class = {
.sysc = i2c_sysc,
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap3xxx_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .name = dsi1, .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+ omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap3xxx_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
+ omap3xxx_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_tv_fck },
+ { .role = dssclk, .clk = dss_96m_fck },
+ { .role = sys_clk, .clk = dss2_alwon_fck },
+};
+
+static struct omap_hwmod omap3xxx_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap3xxx_dss_hwmod_class,
+ .main_clk = dss1_alwon_fck, /* instead of dss_fck */
+ .mpu_irqs = omap3xxx_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dss_irqs),
+ .sdma_reqs = omap3xxx_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_DSS1_SHIFT,
+ .module_offs = OMAP3430_DSS_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap3xxx_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dss_slaves),
+ .masters= omap3xxx_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dss_masters),
+ .omap_chip =
[PATCH v2 06/17] OMAP2,3 board files DSS Driver register moved to devices.c
From: Senthilvadivu Guruswamy svad...@ti.com
Move DSS driver register from board file to devices.c
Regulator initialisation done with driver name instead
of device structure name.
Changed driver name from omapdss to omap_display as the
driver takes care of panel information.
Board files that have dss registeration are updated.
3430sdp, am3517evm, cm-t35, devkit8000, igep0020,
omap3evm, omap3pandora, omap3stalker, rx-51
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 25 -
arch/arm/mach-omap2/board-am3517evm.c| 14 +-
arch/arm/mach-omap2/board-cm-t35.c | 22 +-
arch/arm/mach-omap2/board-devkit8000.c | 12 ++--
arch/arm/mach-omap2/board-igep0020.c | 20 +++-
arch/arm/mach-omap2/board-omap3beagle.c | 14 +++---
arch/arm/mach-omap2/board-omap3evm.c | 22 --
arch/arm/mach-omap2/board-omap3pandora.c | 16
arch/arm/mach-omap2/board-omap3stalker.c | 16 +++-
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
arch/arm/mach-omap2/board-rx51-video.c | 15 +--
11 files changed, 31 insertions(+), 154 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..7ff747e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -301,22 +301,8 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = sdp3430_lcd_device,
};
-static struct platform_device sdp3430_dss_device = {
- .name = omapdss,
- .id = -1,
- .dev= {
- .platform_data = sdp3430_dss_data,
- },
-};
-
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= sdp3430_dss_device.dev,
-};
-
-static struct platform_device *sdp3430_devices[] __initdata = {
- sdp3430_dss_device,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
@@ -540,10 +526,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
- {
- .supply = vdds_dsi,
- .dev= sdp3430_dss_device.dev,
- }
+ REGULATOR_SUPPLY(vdds_dsi, omap_display),
};
static struct regulator_init_data sdp3430_vpll2 = {
@@ -797,7 +780,7 @@ static void __init omap_3430sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
- platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..19a8be7 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -367,23 +367,12 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
.default_device = am3517_evm_lcd_device,
};
-static struct platform_device am3517_evm_dss_device = {
- .name = omapdss,
- .id = -1,
- .dev= {
- .platform_data = am3517_evm_dss_data,
- },
-};
-
/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
};
-static struct platform_device *am3517_evm_devices[] __initdata = {
- am3517_evm_dss_device,
-};
static void __init am3517_evm_init_irq(void)
{
@@ -487,8 +476,7 @@ static void __init am3517_evm_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
am3517_evm_i2c_init();
- platform_add_devices(am3517_evm_devices,
- ARRAY_SIZE(am3517_evm_devices));
+ omap_display_init(am3517_evm_dss_data);
omap_serial_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..fac5fe1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -390,14 +390,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
.default_device = cm_t35_dvi_device,
};
-static struct platform_device cm_t35_dss_device = {
- .name = omapdss,
- .id = -1,
- .dev= {
- .platform_data = cm_t35_dss_data,
- },
-};
-
static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,/* 0: slave, 1: master */
@@ -457,7 +449,7 @@
[PATCH v2 09/17] OMAP2,3: DSS: Move clocks from core driver to dss driver
From: Senthilvadivu Guruswamy svad...@ti.com
clks are moved to dss platform driver. clk_get/put
APIs use dss device instead of core platform device.
It leaves the core driver omap_display to take care of
panel registration with the custom bus. dss driver would
take care of the clocks needed by DISPC,RFBI,DSI,VENC.
TODO: The clock content would be adapted to omap_hwmod in a
seperate series.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 372 +--
drivers/video/omap2/dss/dss.c | 380 +++-
drivers/video/omap2/dss/dss.h | 14 +-
3 files changed, 390 insertions(+), 376 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index d165434..a6b3b61 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -34,32 +34,18 @@
#include linux/regulator/consumer.h
#include plat/display.h
-#include plat/clock.h
#include dss.h
#include dss_features.h
static struct {
struct platform_device *pdev;
- int ctx_id;
-
- struct clk *dss_ick;
- struct clk *dss1_fck;
- struct clk *dss2_fck;
- struct clk *dss_54m_fck;
- struct clk *dss_96m_fck;
- unsignednum_clks_enabled;
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
struct regulator *vdda_dac_reg;
} core;
-static void dss_clk_enable_all_no_ctx(void);
-static void dss_clk_disable_all_no_ctx(void);
-static void dss_clk_enable_no_ctx(enum dss_clock clks);
-static void dss_clk_disable_no_ctx(enum dss_clock clks);
-
static char *def_disp_name;
module_param_named(def_disp, def_disp_name, charp, 0);
MODULE_PARM_DESC(def_disp_name, default display name);
@@ -69,297 +55,6 @@ unsigned int dss_debug;
module_param_named(debug, dss_debug, bool, 0644);
#endif
-/* CONTEXT */
-static int dss_get_ctx_id(void)
-{
- struct omap_dss_board_info *pdata = core.pdev-dev.platform_data;
- int r;
-
- if (!pdata-get_last_off_on_transaction_id)
- return 0;
- r = pdata-get_last_off_on_transaction_id(core.pdev-dev);
- if (r 0) {
- dev_err(core.pdev-dev, getting transaction ID failed,
- will force context restore\n);
- r = -1;
- }
- return r;
-}
-
-int dss_need_ctx_restore(void)
-{
- int id = dss_get_ctx_id();
-
- if (id 0 || id != core.ctx_id) {
- DSSDBG(ctx id %d - id %d\n,
- core.ctx_id, id);
- core.ctx_id = id;
- return 1;
- } else {
- return 0;
- }
-}
-
-static void save_all_ctx(void)
-{
- DSSDBG(save context\n);
-
- dss_clk_enable_no_ctx(DSS_CLK_ICK | DSS_CLK_FCK1);
-
- dss_save_context();
- dispc_save_context();
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_save_context();
-#endif
-
- dss_clk_disable_no_ctx(DSS_CLK_ICK | DSS_CLK_FCK1);
-}
-
-static void restore_all_ctx(void)
-{
- DSSDBG(restore context\n);
-
- dss_clk_enable_all_no_ctx();
-
- dss_restore_context();
- dispc_restore_context();
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_restore_context();
-#endif
-
- dss_clk_disable_all_no_ctx();
-}
-
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
-/* CLOCKS */
-static void core_dump_clocks(struct seq_file *s)
-{
- int i;
- struct clk *clocks[5] = {
- core.dss_ick,
- core.dss1_fck,
- core.dss2_fck,
- core.dss_54m_fck,
- core.dss_96m_fck
- };
-
- seq_printf(s, - CORE -\n);
-
- seq_printf(s, internal clk count\t\t%u\n, core.num_clks_enabled);
-
- for (i = 0; i 5; i++) {
- if (!clocks[i])
- continue;
- seq_printf(s, %-15s\t%lu\t%d\n,
- clocks[i]-name,
- clk_get_rate(clocks[i]),
- clocks[i]-usecount);
- }
-}
-#endif /* defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
*/
-
-static int dss_get_clock(struct clk **clock, const char *clk_name)
-{
- struct clk *clk;
-
- clk = clk_get(core.pdev-dev, clk_name);
-
- if (IS_ERR(clk)) {
- DSSERR(can't get clock %s, clk_name);
- return PTR_ERR(clk);
- }
-
- *clock = clk;
-
- DSSDBG(clk %s, rate %ld\n, clk_name, clk_get_rate(clk));
-
- return 0;
-}
-
-static int dss_get_clocks(void)
-{
- int r;
-
- core.dss_ick = NULL;
- core.dss1_fck = NULL;
- core.dss2_fck = NULL;
- core.dss_54m_fck = NULL;
- core.dss_96m_fck = NULL;
-
- r = dss_get_clock(core.dss_ick, ick);
- if (r)
- goto err;
-
- r = dss_get_clock(core.dss1_fck, dss1_fck);
-
[PATCH v2 05/17] OMAP2,3 DSS Driver register moved to mach_omap2
From: Senthilvadivu Guruswamy svad...@ti.com
Move DSS driver register from board file to devices.c
Changed device name from omapdss to omap_display as the
driver takes care of panel information.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/devices.c | 32 +
arch/arm/plat-omap/include/plat/display.h |4 +++
drivers/video/omap2/dss/core.c|2 +-
3 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5a0c148..0f6eabe 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/dma.h
+#include plat/display.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -923,6 +924,37 @@ static inline void omap_hdq_init(void) {}
#endif
/*---*/
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+ .name = omap_display,
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
+};
+
+int __init omap_display_init(struct omap_dss_board_info
+ *board_data)
+{
+ int r = 0;
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0)
+ printk(KERN_ERR Unable to register OMAP-Display device\n);
+
+ return r;
+}
+
+#else
+int __init omap_display_init(struct omap_dss_board_info *board_data)
+{
+return 0;
+}
+#endif
+
+/*---*/
#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index c915a66..871bbae 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
#include linux/list.h
#include linux/kobject.h
#include linux/device.h
+#include linux/platform_device.h
#include asm/atomic.h
#define DISPC_IRQ_FRAMEDONE(1 0)
@@ -220,6 +221,9 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
};
+/* Init with the board info */
+extern int omap_display_init(struct omap_dss_board_info *board_data);
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8e89f60..48d20d8 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -715,7 +715,7 @@ static struct platform_driver omap_dss_driver = {
.suspend= omap_dss_suspend,
.resume = omap_dss_resume,
.driver = {
- .name = omapdss,
+ .name = omap_display,
.owner = THIS_MODULE,
},
};
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 10/17] OMAP2,3: DSS: Move dss_feature_init to dss
From: Senthilvadivu Guruswamy svad...@ti.com Move dss_feature_init call from core to dss as it involves HW related configuration. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com --- drivers/video/omap2/dss/core.c |2 -- drivers/video/omap2/dss/dss.c |3 +++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c index a6b3b61..0d5f6dd 100644 --- a/drivers/video/omap2/dss/core.c +++ b/drivers/video/omap2/dss/core.c @@ -187,8 +187,6 @@ static int omap_dss_probe(struct platform_device *pdev) core.pdev = pdev; - dss_features_init(); - dss_init_overlay_managers(pdev); dss_init_overlays(pdev); diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c index 59a632d..99dd490 100644 --- a/drivers/video/omap2/dss/dss.c +++ b/drivers/video/omap2/dss/dss.c @@ -33,6 +33,7 @@ #include plat/display.h #include plat/clock.h #include dss.h +#include dss_features.h #define DSS_BASE 0x4805 @@ -966,6 +967,8 @@ static int omap_dsshw_probe(struct platform_device *pdev) dss.pdev = pdev; + dss_features_init(); + r = dss_get_clocks(); if (r) goto err_clocks; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe 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 11/17] OMAP2,3: DSS: DSS Move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Move init exit methods to its driver probe remove.
pdev member has to be maintained by its own drivers.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 16
drivers/video/omap2/dss/dss.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 0d5f6dd..5b0f551 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -192,18 +192,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
- if (r) {
- DSSERR(Failed to initialize DSS\n);
- goto err_dss;
- }
-
r = rfbi_init();
if (r) {
DSSERR(Failed to initialize rfbi\n);
@@ -285,8 +273,6 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
-err_dss:
return r;
}
@@ -307,8 +293,6 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 99dd490..b622d04 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -964,6 +964,7 @@ void dss_debug_dump_clocks(struct seq_file *s)
static int omap_dsshw_probe(struct platform_device *pdev)
{
int r;
+ int skip_init = 0;
dss.pdev = pdev;
@@ -978,6 +979,19 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, dss.ctx_id);
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR(Failed to initialize DSS\n);
+ goto err_dss;
+ }
+
+err_dss:
dss_clk_disable_all_no_ctx();
err_clocks:
@@ -988,6 +1002,8 @@ static int omap_dsshw_remove(struct platform_device *pdev)
{
int c;
+ dss_exit();
+
/* these should be removed at some point */
c = dss.dss_ick-usecount;
if (c 0) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 02/17] OMAP2430: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Database generated for OMAP2430 Display Sub System.
Since dss is also considered as an IP as dispc,rfbi,
name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 282
1 files changed, 282 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..7f85c97 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -37,6 +37,10 @@ static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_dss_dss_hwmod;
+static struct omap_hwmod omap2430_dss_dispc_hwmod;
+static struct omap_hwmod omap2430_dss_rfbi_hwmod;
+static struct omap_hwmod omap2430_dss_venc_hwmod;
static struct omap_hwmod omap2430_wd_timer2_hwmod;
/* L3 - L4_CORE interface */
@@ -58,6 +62,13 @@ static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[] =
{
omap2430_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2430_dss__l3 = {
+ .master = omap2430_dss_dss_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2430_l3_main_masters[] = {
omap2430_l3_main__l4_core,
@@ -461,6 +472,271 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap2430_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2430_dss_irqs[] = {
+ { .irq = 25 },
+};
+static struct omap_hwmod_dma_info omap2430_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_masters[] = {
+ omap2430_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap2430_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
+ omap2430_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_54m_fck },
+ { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2430_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap2430_dss_hwmod_class,
+ .main_clk = dss1_fck, /* instead of dss_fck */
+ .mpu_irqs = omap2430_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dss_irqs),
+ .sdma_reqs = omap2430_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap2430_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dss_slaves),
+ .masters= omap2430_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dss_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes =
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
Gregory CLEMENT gregory.clem...@free-electrons.com writes:
As request by Grant Likely, there is no more cover letter. Full changelog is
following.
I am still reluctant to add this changelog in the patch description, as it
adds no value to
the patch itself: when it was needed I try to updat comments or patch
description.
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
A couple more comments...
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
You should use CONFIG_SUSPEND here
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master = dev_get_drvdata(pdev-dev);
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_cs *cs;
+
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /* We need to toggle CS state for OMAP take this
+ * change in account.
+ */
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
This is adding legacy PM methods. Instead, you should add a struct
dev_pm_ops and add the resume method there.
Kevin
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT
Arno Steffen had written, on 11/26/2010 05:41 AM, the following: minor comment: $subject could be the commit message probably.. and a smaller subject like OMAP3: fix typo in OMAP3_IVA_MASK could be used otherwise, looks good to me. Signed-off-by: Arno Steffen arno.stef...@googlemail.com --- arch/arm/mach-omap2/control.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..5325297 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -309,7 +309,7 @@ #defineFEAT_SGX_NONE 2 #define OMAP3_IVA_SHIFT12 -#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT) +#define OMAP3_IVA_MASK (1 OMAP3_IVA_SHIFT) #defineFEAT_IVA0 #defineFEAT_IVA_NONE 1 -- 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: plat-omap: counter_32k: use IS_ERR() instead of NULL check
Vasiliy Kulikov seg...@openwall.com writes: clk_get() returns ERR_PTR() on error, not NULL. Signed-off-by: Vasiliy Kulikov seg...@openwall.com Acked-by: Kevin Hilman khil...@deeprootsystems.com --- Cannot compile this driver, so it is not tested at all. arch/arm/plat-omap/counter_32k.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 155fe43..c1e0d00 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -164,7 +164,7 @@ static int __init omap_init_clocksource_32k(void) return -ENODEV; sync_32k_ick = clk_get(NULL, omap_32ksync_ick); - if (sync_32k_ick) + if (!IS_ERR(sync_32k_ick)) clk_enable(sync_32k_ick); clocksource_32k.mult = clocksource_hz2mult(32768, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/25/2010 01:49 AM, Kevin Hilman wrote:
This bit of meta-description and changelog should go after the '---'
just after your signoff. That way, git tools can still auto-apply the
email, and git ignores stuff after the '---' so it doesn't end up in the
git history.
Thanks for the advice
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
I haven't actually tested it, only reviewed it, so you can add a
Reviewed by for me, but I'm not SPI-aware enough to ack this patch or
test it thoroughly. Also, I have some more comments below...
Thanks I will add it in my next version.
Also, in the last patch I suggested you do more of a save/restore of
this value instead of a restore to a hard-coded value. IOW, save the
value in the suspend method, restore it in resume. I thought you had
agreed to that. I'm not an SPI expert, so not sure if it makes sense,
but it seems more robust that way and more future proof.
Well I took in account your suggestion and I didn't restore anymore an
hardcore value. The state of the CS is already store in cs-chconf0, so
now I use it. The tricky part is omap2_mcspi_enable_clocks restore the
register when clock was disable, but for OMAP2_MCSPI_CHCONF_FORCE bit, we
had to toggle it. When resumed from OFF mode the OMAP2_MCSPI_CHCONF0
register have default value, which means that OMAP2_MCSPI_CHCONF_FORCE
is 0. So if we want that OMAP2_MCSPI_CHCONF_FORCE=0 is taken in account
we have to first write a 1 and then a 0. But if we want that
OMAP2_MCSPI_CHCONF_FORCE=1, then we have nothing more to do, because in
omap2_mcspi_enable_clocks this bit was change from 0 (its default value)
to 1. That's why I only do a change when OMAP2_MCSPI_CHCONF_FORCE have to
be changed to 0.
I suppose this means that I had to add more comment around my code about
it.
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
This is where any changelog and extra info for reviewers should go.
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
please fix multi-line comment style. Search for 'multi-line' in
CodingStyle.
OK, I though CodingStyle was about burning GNU coding standards ;)
More seriously I keep the same style that other multi-line comment
in this file. But I have no problem to change it.
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+struct spi_master *master = dev_get_drvdata(pdev-dev);
+struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+struct omap2_mcspi_cs *cs;
+
+omap2_mcspi_enable_clocks(mcspi);
+list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+node) {
+if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+/* We need to toggle CS state for OMAP take this
+ * change in account.
+ */
multi-line coding style
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+}
+}
+omap2_mcspi_disable_clocks(mcspi);
+return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+.resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
Kevin
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting,
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/29/2010 03:22 PM, Kevin Hilman wrote:
Gregory CLEMENT gregory.clem...@free-electrons.com writes:
As request by Grant Likely, there is no more cover letter. Full changelog is
following.
I am still reluctant to add this changelog in the patch description, as it
adds no value to
the patch itself: when it was needed I try to updat comments or patch
description.
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
A couple more comments...
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
You should use CONFIG_SUSPEND here
OK I will do this.
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+struct spi_master *master = dev_get_drvdata(pdev-dev);
+struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+struct omap2_mcspi_cs *cs;
+
+omap2_mcspi_enable_clocks(mcspi);
+list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+node) {
+if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+/* We need to toggle CS state for OMAP take this
+ * change in account.
+ */
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+}
+}
+omap2_mcspi_disable_clocks(mcspi);
+return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+.resume = omap2_mcspi_resume,
This is adding legacy PM methods. Instead, you should add a struct
dev_pm_ops and add the resume method there.
OK, I shouldn't copy and paste an old driver!
Thanks for your advices.
Kevin
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
* Pedanekar, Hemant hema...@ti.com [101022 10:58]:
Tony Lindgren wrote on Friday, September 17, 2010 3:55 AM:
* Hemant Pedanekar hema...@ti.com [100811 10:03]:
This patch updates the common machine spcific source files with support
for TI816X.
Note that the nr_irqs is overridden in INTC driver since the number of
IRQs on TI816X are different (128) comapared to other OMAPs (96).
snip
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -419,6 +441,9 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
+ } else if (cpu_is_ti816x()) {
+ ti816x_check_revision();
+ return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
This does not look right, at this point you should just know
the processor class set by the set_globals call.
Please take a look at plat-omap/common.c and add an entry for
omap2_set_globals_ti816x. This gets called very early from the board-*.c
file, so you can initialize things.
Tony,
Do you mean following changes in the patch I sent earlier?
No, I'm mostly wondering how come you can't use cpu_is_omap34xx
for ti816x and then detect based on the values set in
omap2_set_globals. Then cpu_is_ti816x just becomes a set of features.
In general, we should initialize more things in set_globals
if necessary rather than sprinkle cpu_is_omap tests all over
the place to add support for new omaps.
Tony,
Though based on Cortex A8, TI816X series has differences in PRCM, PLL, clock
structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For example,
consider following:
File - arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X as
there are no CM_IDELST registers.
Thanks
-
Hemant--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/25/2010 09:58 AM, Hemanth V wrote: - Original Message - From: Gregory CLEMENT gregory.clem...@free-electrons.com To: linux-omap linux-omap@vger.kernel.org; spi-devel-gene...@lists.sourceforge.net Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely grant.lik...@secretlab.ca; Kevin Hilman khil...@deeprootsystems.com Sent: Thursday, November 25, 2010 3:49 AM Subject: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition As request by Grant Likely, there is no more cover letter. Full changelog is following. I am still reluctant to add this changelog in the patch description, as it adds no value to the patch itself: when it was needed I try to updat comments or patch description. I understand that Grant Likely would need an ack from other user as this patch fix a corner case. Kevin Hilman made a few comments on this patch so he could add his Ack by or at least his Review by. I was trying to run some tests with this patch. I find that the resume function registered by this patch doesnot seem to get called during system wide suspend/resume, since spi_resume only calls the resume routine registered by spi client driver. Is there something I am missing. In fact the resume function for this driver won't be called by spi bus but by platform bus. Indeed this function is registered in a platform_driver structure. Thanks Hemanth -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v2 1/8] usb: ehci-omap: update clock names to be more generic
From: Keshava Munegowda keshava_mgo...@ti.com
Rename usbhost2_120m_fck to usbhost_hs_fck and usbhost1_48m_fck
to usbhost_fs_fck, to better reflect the clocks' functionalities.
In OMAP4, the frequencies for the corresponding clocks are not
necessarily the same as with OMAP3, however the functionalities
are.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 44 +-
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 116ae28..d042bde 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -156,8 +156,8 @@ struct ehci_hcd_omap {
struct device *dev;
struct clk *usbhost_ick;
- struct clk *usbhost2_120m_fck;
- struct clk *usbhost1_48m_fck;
+ struct clk *usbhost_hs_fck;
+ struct clk *usbhost_fs_fck;
struct clk *usbtll_fck;
struct clk *usbtll_ick;
@@ -286,19 +286,19 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
}
clk_enable(omap-usbhost_ick);
- omap-usbhost2_120m_fck = clk_get(omap-dev, usbhost_120m_fck);
- if (IS_ERR(omap-usbhost2_120m_fck)) {
- ret = PTR_ERR(omap-usbhost2_120m_fck);
+ omap-usbhost_hs_fck = clk_get(omap-dev, usbhost_120m_fck);
+ if (IS_ERR(omap-usbhost_hs_fck)) {
+ ret = PTR_ERR(omap-usbhost_hs_fck);
goto err_host_120m_fck;
}
- clk_enable(omap-usbhost2_120m_fck);
+ clk_enable(omap-usbhost_hs_fck);
- omap-usbhost1_48m_fck = clk_get(omap-dev, usbhost_48m_fck);
- if (IS_ERR(omap-usbhost1_48m_fck)) {
- ret = PTR_ERR(omap-usbhost1_48m_fck);
+ omap-usbhost_fs_fck = clk_get(omap-dev, usbhost_48m_fck);
+ if (IS_ERR(omap-usbhost_fs_fck)) {
+ ret = PTR_ERR(omap-usbhost_fs_fck);
goto err_host_48m_fck;
}
- clk_enable(omap-usbhost1_48m_fck);
+ clk_enable(omap-usbhost_fs_fck);
if (omap-phy_reset) {
/* Refer: ISSUE1 */
@@ -472,8 +472,8 @@ err_tll_ick:
clk_put(omap-usbtll_fck);
err_tll_fck:
- clk_disable(omap-usbhost1_48m_fck);
- clk_put(omap-usbhost1_48m_fck);
+ clk_disable(omap-usbhost_fs_fck);
+ clk_put(omap-usbhost_fs_fck);
if (omap-phy_reset) {
if (gpio_is_valid(omap-reset_gpio_port[0]))
@@ -484,8 +484,8 @@ err_tll_fck:
}
err_host_48m_fck:
- clk_disable(omap-usbhost2_120m_fck);
- clk_put(omap-usbhost2_120m_fck);
+ clk_disable(omap-usbhost_hs_fck);
+ clk_put(omap-usbhost_hs_fck);
err_host_120m_fck:
clk_disable(omap-usbhost_ick);
@@ -550,16 +550,16 @@ static void omap_stop_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
omap-usbhost_ick = NULL;
}
- if (omap-usbhost1_48m_fck != NULL) {
- clk_disable(omap-usbhost1_48m_fck);
- clk_put(omap-usbhost1_48m_fck);
- omap-usbhost1_48m_fck = NULL;
+ if (omap-usbhost_fs_fck != NULL) {
+ clk_disable(omap-usbhost_fs_fck);
+ clk_put(omap-usbhost_fs_fck);
+ omap-usbhost_fs_fck = NULL;
}
- if (omap-usbhost2_120m_fck != NULL) {
- clk_disable(omap-usbhost2_120m_fck);
- clk_put(omap-usbhost2_120m_fck);
- omap-usbhost2_120m_fck = NULL;
+ if (omap-usbhost_hs_fck != NULL) {
+ clk_disable(omap-usbhost_hs_fck);
+ clk_put(omap-usbhost_hs_fck);
+ omap-usbhost_hs_fck = NULL;
}
if (omap-usbtll_ick != NULL) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] usb: ehci-omap: use clkdev aliases for functional clocks
Use the recently updated aliases to get functional clocks needed by
the driver. This allows the driver to acquire OMAP4-specific clocks
without having to use different clock names for OMAP3 and OMAP4.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d60efdc..7a4682c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -287,14 +287,14 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
}
clk_enable(omap-usbhost_ick);
- omap-usbhost_hs_fck = clk_get(omap-dev, usbhost_120m_fck);
+ omap-usbhost_hs_fck = clk_get(omap-dev, hs_fck);
if (IS_ERR(omap-usbhost_hs_fck)) {
ret = PTR_ERR(omap-usbhost_hs_fck);
goto err_host_120m_fck;
}
clk_enable(omap-usbhost_hs_fck);
- omap-usbhost_fs_fck = clk_get(omap-dev, usbhost_48m_fck);
+ omap-usbhost_fs_fck = clk_get(omap-dev, fs_fck);
if (IS_ERR(omap-usbhost_fs_fck)) {
ret = PTR_ERR(omap-usbhost_fs_fck);
goto err_host_48m_fck;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] omap: clock: add clkdev aliases for EHCI clocks
Add clkdev aliases for the USBHOST and USBTLL clocks on OMAP3 and
OMAP4, so that the driver can refer to the clocks using a common alias.
This will disappear when the driver is converted to use the hwmod
database, but until then this patch is needed.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock3xxx_data.c |5 +
arch/arm/mach-omap2/clock44xx_data.c |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d85ecd5..a04cb03 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3278,6 +3278,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2 | CK_AM35XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2 | CK_AM35XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2 | CK_AM35XX),
+ CLK(ehci-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2 |
CK_AM35XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3313,6 +3314,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_343X),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2 | CK_AM35XX),
+ CLK(ehci-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2 |
CK_AM35XX),
CLK(mmci-omap-hs.2, ick, mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, icr_ick, icr_ick, CK_343X),
CLK(omap-aes, ick, aes2_ick, CK_343X),
@@ -3358,8 +3360,11 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2 |
CK_AM35XX),
+ CLK(ehci-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2 |
CK_AM35XX),
+ CLK(ehci-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2 | CK_AM35XX),
+ CLK(ehci-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 1599836..f473e89 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2937,6 +2937,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_fck,uart3_fck,
CK_443X),
CLK(NULL, uart4_fck,uart4_fck,
CK_443X),
CLK(NULL, usb_host_fs_fck, usb_host_fs_fck,
CK_443X),
+ CLK(ehci-omap.0, fs_fck, usb_host_fs_fck,
CK_443X),
CLK(NULL, usb_host_hs_utmi_p3_clk,
usb_host_hs_utmi_p3_clk, CK_443X),
CLK(NULL, usb_host_hs_hsic60m_p1_clk,
usb_host_hs_hsic60m_p1_clk,CK_443X),
CLK(NULL, usb_host_hs_hsic60m_p2_clk,
usb_host_hs_hsic60m_p2_clk,CK_443X),
@@ -2948,6 +2949,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_host_hs_hsic480m_p2_clk,
usb_host_hs_hsic480m_p2_clk, CK_443X),
CLK(NULL, usb_host_hs_func48mclk,
usb_host_hs_func48mclk,CK_443X),
CLK(NULL, usb_host_hs_fck, usb_host_hs_fck,
CK_443X),
+ CLK(ehci-omap.0, hs_fck, usb_host_hs_fck,
CK_443X),
+ CLK(ehci-omap.0, usbhost_ick, dummy_ck,
CK_443X),
CLK(NULL, otg_60m_gfclk,otg_60m_gfclk,
CK_443X),
CLK(NULL, usb_otg_hs_xclk, usb_otg_hs_xclk,
CK_443X),
CLK(musb_hdrc,ick,
usb_otg_hs_ick,CK_443X),
@@ -2956,6 +2959,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
CLK(NULL, usb_tll_hs_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(ehci-omap.0, usbtll_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(ehci-omap.0, usbtll_fck, dummy_ck,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
[PATCH v2 2/8] usb: ehci-omap: don't hard-code TLL channel count
From: Keshava Munegowda keshava_mgo...@ti.com
Make the TLL channel count a parameter instead of a hardcoded
value. This allows us to be flexible with future OMAP revisions
which could have a different number of channels.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d042bde..d60efdc 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -191,13 +191,14 @@ struct ehci_hcd_omap {
/*-*/
-static void omap_usb_utmi_init(struct ehci_hcd_omap *omap, u8 tll_channel_mask)
+static void omap_usb_utmi_init(struct ehci_hcd_omap *omap, u8 tll_channel_mask,
+ u8 tll_channel_count)
{
unsigned reg;
int i;
/* Program the 3 TLL channels upfront */
- for (i = 0; i OMAP_TLL_CHANNEL_COUNT; i++) {
+ for (i = 0; i tll_channel_count; i++) {
reg = ehci_omap_readl(omap-tll_base, OMAP_TLL_CHANNEL_CONF(i));
/* Disable AutoIdle, BitStuffing and use SDR Mode */
@@ -217,7 +218,7 @@ static void omap_usb_utmi_init(struct ehci_hcd_omap *omap,
u8 tll_channel_mask)
ehci_omap_writel(omap-tll_base, OMAP_TLL_SHARED_CONF, reg);
/* Enable channels now */
- for (i = 0; i OMAP_TLL_CHANNEL_COUNT; i++) {
+ for (i = 0; i tll_channel_count; i++) {
reg = ehci_omap_readl(omap-tll_base, OMAP_TLL_CHANNEL_CONF(i));
/* Enable only the reg that is needed */
@@ -438,7 +439,7 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
tll_ch_mask |= OMAP_TLL_CHANNEL_3_EN_MASK;
/* Enable UTMI mode for required TLL channels */
- omap_usb_utmi_init(omap, tll_ch_mask);
+ omap_usb_utmi_init(omap, tll_ch_mask, OMAP_TLL_CHANNEL_COUNT);
}
if (omap-phy_reset) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] omap: usb: ehci: introduce HSIC mode
The EHCI controller in OMAP4 supports a new interface mode - HSIC.
Add this to the list of modes supported on OMAP3.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/plat/usb.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..9b1893f 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -11,6 +11,7 @@ enum ehci_hcd_omap_mode {
EHCI_HCD_OMAP_MODE_UNKNOWN,
EHCI_HCD_OMAP_MODE_PHY,
EHCI_HCD_OMAP_MODE_TLL,
+ EHCI_HCD_OMAP_MODE_HSIC,
};
enum ohci_omap3_port_mode {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] usb: ehci-omap: add helpers for checking port mode
Introduce helper functions to test port mode. These checks are
performed in several places in the driver, and these helpers
improve readability.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 7a4682c..dd9d5c1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -127,6 +127,9 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
+#define is_ehci_phy_mode(x)(x == EHCI_HCD_OMAP_MODE_PHY)
+#define is_ehci_tll_mode(x)(x == EHCI_HCD_OMAP_MODE_TLL)
+
/*-*/
static inline void ehci_omap_writel(void __iomem *base, u32 reg, u32 val)
@@ -387,27 +390,27 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
/* Bypass the TLL module for PHY mode operation */
if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
dev_dbg(omap-dev, OMAP3 ES version = ES2.1\n);
- if ((omap-port_mode[0] == EHCI_HCD_OMAP_MODE_PHY) ||
- (omap-port_mode[1] == EHCI_HCD_OMAP_MODE_PHY) ||
- (omap-port_mode[2] == EHCI_HCD_OMAP_MODE_PHY))
+ if (is_ehci_phy_mode(omap-port_mode[0]) ||
+ is_ehci_phy_mode(omap-port_mode[1]) ||
+ is_ehci_phy_mode(omap-port_mode[2]))
reg = ~OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
else
reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
} else {
dev_dbg(omap-dev, OMAP3 ES version ES2.1\n);
- if (omap-port_mode[0] == EHCI_HCD_OMAP_MODE_PHY)
+ if (is_ehci_phy_mode(omap-port_mode[0]))
reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- else if (omap-port_mode[0] == EHCI_HCD_OMAP_MODE_TLL)
+ else if (is_ehci_tll_mode(omap-port_mode[0]))
reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- if (omap-port_mode[1] == EHCI_HCD_OMAP_MODE_PHY)
+ if (is_ehci_phy_mode(omap-port_mode[1]))
reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS;
- else if (omap-port_mode[1] == EHCI_HCD_OMAP_MODE_TLL)
+ else if (is_ehci_tll_mode(omap-port_mode[1]))
reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS;
- if (omap-port_mode[2] == EHCI_HCD_OMAP_MODE_PHY)
+ if (is_ehci_phy_mode(omap-port_mode[2]))
reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
- else if (omap-port_mode[2] == EHCI_HCD_OMAP_MODE_TLL)
+ else if (is_ehci_tll_mode(omap-port_mode[2]))
reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] arm: omap4: usb: add platform init code for EHCI
- Add platform init code for EHCI on OMAP4
- Add pad configuration for PHY and TLL modes
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-ehci.c | 144 +--
1 files changed, 136 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
index b11bf38..25eeada 100644
--- a/arch/arm/mach-omap2/usb-ehci.c
+++ b/arch/arm/mach-omap2/usb-ehci.c
@@ -34,22 +34,15 @@
static struct resource ehci_resources[] = {
{
- .start = OMAP34XX_EHCI_BASE,
- .end= OMAP34XX_EHCI_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP34XX_UHH_CONFIG_BASE,
- .end= OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP34XX_USBTLL_BASE,
- .end= OMAP34XX_USBTLL_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* general IRQ */
- .start = INT_34XX_EHCI_IRQ,
.flags = IORESOURCE_IRQ,
}
};
@@ -214,13 +207,148 @@ static void setup_ehci_io_mux(const enum
ehci_hcd_omap_mode *port_mode)
return;
}
+static void setup_4430ehci_io_mux(const enum ehci_hcd_omap_mode *port_mode)
+{
+ switch (port_mode[0]) {
+ case EHCI_HCD_OMAP_MODE_PHY:
+ omap_mux_init_signal(usbb1_ulpiphy_stp,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(usbb1_ulpiphy_clk,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dir,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_nxt,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat1,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat2,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat3,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat4,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat5,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat6,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpiphy_dat7,
+ OMAP_PIN_INPUT_PULLDOWN);
+ break;
+ case EHCI_HCD_OMAP_MODE_TLL:
+ omap_mux_init_signal(usbb1_ulpitll_stp,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(usbb1_ulpitll_clk,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dir,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_nxt,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat1,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat2,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat3,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat4,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat5,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat6,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb1_ulpitll_dat7,
+ OMAP_PIN_INPUT_PULLDOWN);
+ break;
+ case EHCI_HCD_OMAP_MODE_UNKNOWN:
+ default:
+ break;
+ }
+ switch (port_mode[1]) {
+ case EHCI_HCD_OMAP_MODE_PHY:
+ omap_mux_init_signal(usbb2_ulpiphy_stp,
+ OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(usbb2_ulpiphy_clk,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb2_ulpiphy_dir,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb2_ulpiphy_nxt,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb2_ulpiphy_dat0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb2_ulpiphy_dat1,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(usbb2_ulpiphy_dat2,
+
[PATCH v2 4/4] omap4: 4430sdp: enable the ehci port on 4430SDP
From: Keshava Munegowda keshava_mgo...@ti.com
The OMAP4 SDP has an SMSC3320 PHY hooked up to EHCI on Port1.
The PHY power is controlled by GPIO 157.
Turn on the PHY power, and register the controller at init.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..d7cb968 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -42,6 +42,7 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4SDP_MDM_PWR_EN_GPIO 157
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
@@ -225,6 +226,16 @@ static void __init omap_4430sdp_init_irq(void)
omap_gpio_init();
}
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+ .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 = false,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL,
+};
+
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_PERIPHERAL,
@@ -514,6 +525,15 @@ static void __init omap_4430sdp_init(void)
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
+
+ /* Power on the ULPI PHY */
+ if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
+ /* FIXME: Assumes pad is already muxed for GPIO mode */
+ gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, USBB1 PHY VMDM_3V3);
+ gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
+ }
+ usb_ehci_init(ehci_pdata);
+
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] arm: omap4: add USBHOST and related base addresses
Add base addresses for USBHOST, USBTLL, EHCI and OHCI to the header file. This will disappear when the drivers are converted to use the hwmod database, however this patch is needed until then. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/omap44xx.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h index 8b3f12f..ea2b8a6 100644 --- a/arch/arm/plat-omap/include/plat/omap44xx.h +++ b/arch/arm/plat-omap/include/plat/omap44xx.h @@ -52,5 +52,10 @@ #define OMAP4_MMU1_BASE0x55082000 #define OMAP4_MMU2_BASE0x4A066000 +#define OMAP44XX_USBTLL_BASE (L4_44XX_BASE + 0x62000) +#define OMAP44XX_UHH_CONFIG_BASE (L4_44XX_BASE + 0x64000) +#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800) +#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00) + #endif /* __ASM_ARCH_OMAP44XX_H */ -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] arm: omap4: Add support for EHCI
This series adds the platform init code for the EHCI controller on OMAP4 and allows the EHCI driver to be built on OMAP4. The patches are based on v2.6.37-rc3, and they apply cleanly on linux-next as of today. Pin-muxing is done at one shot in the usb-ehci.c file, as is done on OMAP3. None of the signals are on multiple pads, so this was easy. This part depends on the mux framework series from Benoit which is already queued up. Also register the controller on the OMAP4 SDP. This is already done for the Pandaboard. This is a precursor to adapting the driver to hwmod; I didn't want to hold up the EHCI driver so long - as the ethernet controller on the Pandaboard needs EHCI to work. I'll send out RFC patches for this work in a while. The complete series (including the series going via linux-usb) is available in my development tree [1] in the omap4-ehci-upstream-v2 branch, if anyone wants to test. - Anand [1] git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git Anand Gadiyar (3): arm: omap4: add USBHOST and related base addresses arm: omap4: usb: add platform init code for EHCI arm: omap4: select USB_ARCH_HAS_EHCI Keshava Munegowda (1): omap4: 4430sdp: enable the ehci port on 4430SDP arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/board-4430sdp.c| 20 arch/arm/mach-omap2/usb-ehci.c | 144 ++-- arch/arm/plat-omap/include/plat/omap44xx.h |5 + 4 files changed, 162 insertions(+), 8 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 v2 3/4] arm: omap4: select USB_ARCH_HAS_EHCI
The OMAP4 has an on-chip EHCI controller. Select USB_ARCH_HAS_EHCI to allow the EHCI driver to be built on OMAP4. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ab784bf..766727c 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -44,6 +44,7 @@ config ARCH_OMAP4 select ARM_GIC select PL310_ERRATA_588369 select ARM_ERRATA_720789 + select USB_ARCH_HAS_EHCI comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] usb: ehci-omap: Add OMAP4 support
Update the ehci-omap glue layer to support the controller in the
OMAP4. Major differences from OMAP3 is that the OMAP4 has per-port
clocking, and supports ULPI output clocking mode. The old input
clocking mode is not supported.
Also, there are only 2 externally available ports as against 3
in the OMAP3. The third port is internally tied off and should
not be used.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 258 ++---
1 files changed, 214 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index dd9d5c1..0374eb4 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -1,11 +1,12 @@
/*
- * ehci-omap.c - driver for USBHOST on OMAP 34xx processor
+ * ehci-omap.c - driver for USBHOST on OMAP3/4 processors
*
- * Bus Glue for OMAP34xx USBHOST 3 port EHCI controller
- * Tested on OMAP3430 ES2.0 SDP
+ * Bus Glue for the EHCI controllers in OMAP3/4
+ * Tested on several OMAP3 boards, and OMAP4 Pandaboard
*
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
+ * Copyright (C) 2007-2010 Texas Instruments, Inc.
* Author: Vikram Pandita vikram.pand...@ti.com
+ * Author: Anand Gadiyar gadi...@ti.com
*
* Copyright (C) 2009 Nokia Corporation
* Contact: Felipe Balbi felipe.ba...@nokia.com
@@ -26,11 +27,14 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * TODO (last updated Feb 12, 2010):
+ * TODO (last updated Nov 21, 2010):
* - add kernel-doc
* - enable AUTOIDLE
* - add suspend/resume
* - move workarounds to board-files
+ * - factor out code common to OHCI
+ * - add HSIC and TLL support
+ * - convert to use hwmod and runtime PM
*/
#include linux/platform_device.h
@@ -114,6 +118,23 @@
#define OMAP_UHH_HOSTCONFIG_P2_CONNECT_STATUS (1 9)
#define OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS (1 10)
+/* OMAP4-specific defines */
+#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 2)
+#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 2)
+
+#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 4)
+#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 4)
+#define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0)
+
+#define OMAP4_P1_MODE_CLEAR(3 16)
+#define OMAP4_P1_MODE_TLL (1 16)
+#define OMAP4_P1_MODE_HSIC (3 16)
+#define OMAP4_P2_MODE_CLEAR(3 18)
+#define OMAP4_P2_MODE_TLL (1 18)
+#define OMAP4_P2_MODE_HSIC (3 18)
+
+#define OMAP_REV2_TLL_CHANNEL_COUNT2
+
#defineOMAP_UHH_DEBUG_CSR (0x44)
/* EHCI Register Set */
@@ -127,8 +148,16 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
+/* Values of UHH_REVISION - Note: these are not given in the TRM */
+#define OMAP_EHCI_REV1 0x0010 /* OMAP3 */
+#define OMAP_EHCI_REV2 0x50700100 /* OMAP4 */
+
+#define is_omap_ehci_rev1(x) (x-omap_ehci_rev == OMAP_EHCI_REV1)
+#define is_omap_ehci_rev2(x) (x-omap_ehci_rev == OMAP_EHCI_REV2)
+
#define is_ehci_phy_mode(x)(x == EHCI_HCD_OMAP_MODE_PHY)
#define is_ehci_tll_mode(x)(x == EHCI_HCD_OMAP_MODE_TLL)
+#define is_ehci_hsic_mode(x) (x == EHCI_HCD_OMAP_MODE_HSIC)
/*-*/
@@ -163,6 +192,10 @@ struct ehci_hcd_omap {
struct clk *usbhost_fs_fck;
struct clk *usbtll_fck;
struct clk *usbtll_ick;
+ struct clk *xclk60mhsp1_ck;
+ struct clk *xclk60mhsp2_ck;
+ struct clk *utmi_p1_fck;
+ struct clk *utmi_p2_fck;
/* FIXME the following two workarounds are
* board specific not silicon-specific so these
@@ -179,6 +212,9 @@ struct ehci_hcd_omap {
/* phy reset workaround */
int phy_reset;
+ /* IP revision */
+ u32 omap_ehci_rev;
+
/* desired phy_mode: TLL, PHY */
enum ehci_hcd_omap_mode port_mode[OMAP3_HS_USB_PORTS];
@@ -337,6 +373,80 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
}
clk_enable(omap-usbtll_ick);
+ omap-omap_ehci_rev = ehci_omap_readl(omap-uhh_base,
+ OMAP_UHH_REVISION);
+ dev_dbg(omap-dev, OMAP UHH_REVISION 0x%x\n,
+ omap-omap_ehci_rev);
+
+ /*
+* Enable per-port clocks as needed (newer controllers only).
+* -
[PATCH v2 0/8] usb: ehci-omap: add OMAP4 support
This series adds support for the EHCI controller on OMAP4 chips. (This enables the ethernet controller on the Pandaboard - finally!). I've tested the series on an OMAP4 SDP, a Pandaboard, and a beagleboard - all with a single kernel binary. The complete series (including the part that can go via linux-omap) is available in my development tree at [1] in the omap4-ehci-upstream-v2 branch. What changed in v2: - Split out OMAP platform code into a separate series which can go through linux-omap - Add a changelog for one patch which I missed out in v1 - Explicitly CC Paul for the clkdev aliases, and Tony for a change to a platform header file needed for build. Dependencies: - None What's pending: - OHCI support - Support for TLL and HSIC modes - Factoring out code common to ehci-omap and ohci-omap3 - Conversion to use omap_device and the hwmod database - Runtime PM support - Anand [1] git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git Anand Gadiyar (5): omap: clock: add clkdev aliases for EHCI clocks usb: ehci-omap: use clkdev aliases for functional clocks usb: ehci-omap: add helpers for checking port mode omap: usb: ehci: introduce HSIC mode usb: ehci-omap: Add OMAP4 support Keshava Munegowda (3): usb: ehci-omap: update clock names to be more generic usb: ehci-omap: don't hard-code TLL channel count usb: ehci: introduce CONFIG_USB_EHCI_HCD_OMAP arch/arm/mach-omap2/clock3xxx_data.c |5 + arch/arm/mach-omap2/clock44xx_data.c |5 + arch/arm/plat-omap/include/plat/usb.h |1 + drivers/usb/host/Kconfig |8 + drivers/usb/host/ehci-hcd.c |2 +- drivers/usb/host/ehci-omap.c | 314 + 6 files changed, 264 insertions(+), 71 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 v2 3/8] usb: ehci: introduce CONFIG_USB_EHCI_HCD_OMAP
From: Keshava Munegowda keshava_mgo...@ti.com Introduce the CONFIG_USB_EHCI_HCD_OMAP option to select EHCI support on OMAP3 and later chips. This scales better than having a long line of dependencies for each new OMAP with EHCI support. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com --- drivers/usb/host/Kconfig|8 drivers/usb/host/ehci-hcd.c |2 +- 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 6f4f8e6..7c1f843 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -133,6 +133,14 @@ config USB_EHCI_MXC ---help--- Variation of ARC USB block used in some Freescale chips. +config USB_EHCI_HCD_OMAP + bool EHCI support for OMAP3 and later chips + depends on USB_EHCI_HCD ARCH_OMAP + default y + --- help --- + Enables support for the on-chip EHCI controller on + OMAP3 and later chips. + config USB_EHCI_HCD_PPC_OF bool EHCI support for PPC USB controller on OF platform bus depends on USB_EHCI_HCD PPC_OF diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 502a7e6..1c80441 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1171,7 +1171,7 @@ MODULE_LICENSE (GPL); #definePLATFORM_DRIVER ehci_hcd_au1xxx_driver #endif -#ifdef CONFIG_ARCH_OMAP3 +#ifdef CONFIG_USB_EHCI_HCD_OMAP #include ehci-omap.c #definePLATFORM_DRIVER ehci_hcd_omap_driver #endif -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
* Mark Brown broo...@opensource.wolfsonmicro.com [101127 02:10]: On Fri, Nov 26, 2010 at 09:45:17AM -0800, Tony Lindgren wrote: By the way, all the board specific data should be __initdata eventually. Now we're hogging memory for the regulators for all the boards compiled in.. Yeah. Some of it will need to be __devinitdata for hotpluggable things but most of it should be __initdata. I'll update the regulator API to copy the constraints before the next merge window. OK sounds good to me. 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: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
On Mon, Nov 29, 2010 at 10:18:31AM -0800, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [101127 02:10]: Yeah. Some of it will need to be __devinitdata for hotpluggable things but most of it should be __initdata. I'll update the regulator API to copy the constraints before the next merge window. OK sounds good to me. FWIW the patch is regulator: Copy constraints from regulators when initialising them, posted for review today. -- To unsubscribe from this list: send the line unsubscribe 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 4/8] omap: clock: add clkdev aliases for EHCI clocks
On Mon, 29 Nov 2010, Anand Gadiyar wrote: Add clkdev aliases for the USBHOST and USBTLL clocks on OMAP3 and OMAP4, so that the driver can refer to the clocks using a common alias. This will disappear when the driver is converted to use the hwmod database, but until then this patch is needed. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Paul Walmsley p...@pwsan.com Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap serial console with PM fixes
Hi Linus, Please pull two patches to fix omap serial console with PM enabled: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Both fix issues are related to conversion from 8250 to omap-serial done in commit 6f251e9db1093c187addc309b5f2f7fe3efd2995 (OMAP: UART: omap_device conversions, remove implicit 8520 assumptions). With the commit above, we are now idling devices using omap generic code instead of tinkering with the uart registers directly. However, we may now have pr_debug and pr_warning in the idle path that we did not have earlier. Without the second patch in this series the system may hang when PM is enabled. The first patch in the series fixes a related issue if only some of the uarts are enabled. Apologies for the rather intrusive fix this late. The long term fix is to let omap-serial.c manage it's own idle state but that's not ready yet and can't be done as a fix. An alternative fix for the -rc series would be to remove the pr_debug and pr_warning from the idle path, but that really only fixes the symptoms, not the cause. Regards, Tony The following changes since commit 0b9466ccea3c4ec363737288dd9467bf978c9c2d: Merge master.kernel.org:/home/rmk/linux-2.6-arm (2010-11-25 07:41:10 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Kevin Hilman (1): OMAP: UART: don't resume UARTs that are not enabled. Paul Walmsley (1): OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled arch/arm/mach-omap2/pm24xx.c |7 +++ arch/arm/mach-omap2/pm34xx.c | 10 ++ arch/arm/mach-omap2/serial.c |7 ++- 3 files changed, 23 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/6] TI816X: Update common OMAP machine specific sources
* Pedanekar, Hemant hema...@ti.com [101129 09:07]:
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
Though based on Cortex A8, TI816X series has differences in PRCM, PLL, clock
structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For example,
consider following:
File - arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X as
there are no CM_IDELST registers.
OK, so places like these will need different handling, and should
then be based on some idlest flag that gets set during the init
based on cpu_is_omap24xx() || cpu_is_omap3430() || cpu_is_omap3630().
Have you looked at defining cpu_is_ti816x() based on features?
Something like:
#define cpu_is_ti816x() (cpu_is_omap34xx() \
(omap3_has_xyz())
Where xyz is based on some runtime detected flag, just like
we do for sgx and iva.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] [OMAP] gpio: Allow for extended GPIO space
* Cory Maccarrone darkstar6...@gmail.com [101125 07:23]: On Mon, Aug 2, 2010 at 4:51 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100720 06:59]: This change copies from the s3c24xx the ability for a board to specify if it wants 64 or 128 more GPIOs in the board space. This is needed to get the HTC Herald board's extra htcpld gpios to work as actual gpios. snip +config OMAP_GPIO_EXTRA + int + default 128 if OMAP_GPIO_EXTRA128 + default 64 if OMAP_GPIO_EXTRA64 + default 0 + +config OMAP_GPIO_EXTRA64 + bool + help + Add an extra 64 gpio numbers to the available GPIO pool. This is + available for boards that need extra gpios for external devices. + +config OMAP_GPIO_EXTRA128 + bool + help + Add an extra 128 gpio numbers to the available GPIO pool. This is + available for boards that need extra gpios for external devices. + Let's wait on this and the following patch a a little, I believe there are already patches in the works to deal with this for the multi-arm support. So this should get solved eventually in a generic way. Regards, Tony Has anything happened with this recently? I haven't been keeping up too much, and I notice the latest linus-tree kernel still needs these patches (or something similar) for me to be able to use the htcpld on herald. Well I'm working on a patch series that combines all mach-omap1 defconfigs into one, still need to sort out few places to make it work. That means we must be able to compile in all the needed options without breaking things, so let's not make this a Kconfig option. Or at least it should be possible to enable it for all mach-omap1 machines. AFAIK, you should be able to just define it the same way as TWL4030_IRQ_BASE in arch/arm/plat-omap/include/plat/irqs.h, maybe based it on CONFIG_ARCH_OMAP7XX? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v2] OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all
From: Richard Woodruff r-woodru...@ti.com Analysis in TI kernel with ETM showed that using cache mapped flush in kernel instead of SO mapped flush cost drops by 65% (3.39mS down to 1.17mS) for clean_l2 which is used during sleep sequences. Overall: - speed up - unfortunately there isn't a good alternative flush method today - code reduction and less maintenance and potential bug in unmaintained code This also fixes the bug with the clean_l2 function usage. Reported-by: Tony Lindgren t...@atomide.com [...@ti.com: ported rkw's proposal to 2.6.37-rc2] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Richard Woodruff r-woodru...@ti.com --- v2: typo correction 'reuse' v1: http://marc.info/?l=linux-omapm=129013171325210w=2 arch/arm/mach-omap2/sleep34xx.S | 79 ++ 1 files changed, 13 insertions(+), 66 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2fb205a..2c20fcf 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -520,72 +520,17 @@ clean_caches: cmp r9, #1 /* Check whether L2 inval is required or not*/ bne skip_l2_inval clean_l2: - /* read clidr */ - mrc p15, 1, r0, c0, c0, 1 - /* extract loc from clidr */ - andsr3, r0, #0x700 - /* left align loc bit field */ - mov r3, r3, lsr #23 - /* if loc is 0, then no need to clean */ - beq finished - /* start clean at cache level 0 */ - mov r10, #0 -loop1: - /* work out 3x current cache level */ - add r2, r10, r10, lsr #1 - /* extract cache type bits from clidr*/ - mov r1, r0, lsr r2 - /* mask of the bits for current cache only */ - and r1, r1, #7 - /* see what cache we have at this level */ - cmp r1, #2 - /* skip if no cache, or just i-cache */ - blt skip - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - /* isb to sych the new cssrcsidr */ - isb - /* read the new csidr */ - mrc p15, 1, r1, c0, c0, 0 - /* extract the length of the cache lines */ - and r2, r1, #7 - /* add 4 (line length offset) */ - add r2, r2, #4 - ldr r4, assoc_mask - /* find maximum number on the way size */ - andsr4, r4, r1, lsr #3 - /* find bit position of way size increment */ - clz r5, r4 - ldr r7, numset_mask - /* extract max number of the index size*/ - andsr7, r7, r1, lsr #13 -loop2: - mov r9, r4 - /* create working copy of max way size*/ -loop3: - /* factor way and cache number into r11 */ - orr r11, r10, r9, lsl r5 - /* factor index number into r11 */ - orr r11, r11, r7, lsl r2 - /*clean invalidate by set/way */ - mcr p15, 0, r11, c7, c10, 2 - /* decrement the way*/ - subsr9, r9, #1 - bge loop3 - /*decrement the index */ - subsr7, r7, #1 - bge loop2 -skip: - add r10, r10, #2 - /* increment cache number */ - cmp r3, r10 - bgt loop1 -finished: - /*swith back to cache level 0 */ - mov r10, #0 - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - isb + /* +* Jump out to kernel flush routine +* - reuse that code is better +* - it executes in a cached space so is faster than refetch per-block +* - 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 + skip_l2_inval: /* Data memory barrier and Data sync barrier */ mov r1, #0 @@ -668,5 +613,7 @@ cache_pred_disable_mask: .word 0xE7FB control_stat: .word CONTROL_STAT +kernel_flush: + .word v7_flush_dcache_all ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe 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/5] OMAP3630: PM: Erratum i608: disable RTA
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by overriding the
restore pointer for 3630 to allow us restore handler as the first point of
entry before caches are touched and is common for GP and HS devices.
to disable earlier than this could be possible by modifying the ppa for HS
devices, but not for GP devices.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v2: fixed missing b restore for 3430 es3.1 code.
introduced erratum handling logic here splitting it out of uart errata
typo fixes for erratum
v1: http://marc.info/?l=linux-omapm=129013172825240w=2
arch/arm/mach-omap2/control.c |5 -
arch/arm/mach-omap2/control.h |5 +
arch/arm/mach-omap2/pm34xx.c| 23 +++
arch/arm/mach-omap2/sleep34xx.S | 26 ++
4 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..728f268 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0
+ if (cpu_is_omap3630())
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(get_omap3630_restore_pointer());
+ else if (omap_rev() != OMAP3430_REV_ES3_0
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..d7911c5 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -204,6 +204,10 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only RTA - Retention till Accesss control registers and bits */
+#define OMAP36XX_CONTROL_MEM_RTA_CTRL 0x40C
+#define OMAP36XX_RTA_DISABLE 0x0
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
@@ -347,6 +351,7 @@ extern void omap3_save_scratchpad_contents(void);
extern void omap3_clear_scratchpad_contents(void);
extern u32 *get_restore_pointer(void);
extern u32 *get_es3_restore_pointer(void);
+extern u32 *get_omap3630_restore_pointer(void);
extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..bd426cc 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -54,6 +54,10 @@
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
+#define RTA_ERRATUM_i608 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -979,6 +983,14 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void pm_errata_configure(void)
+{
+ if (cpu_is_omap34xx()) {
+ if (cpu_is_omap3630())
+ pm34xx_errata |= RTA_ERRATUM_i608;
+ }
+}
+
static int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
@@ -988,6 +1000,8 @@ static int __init omap3_pm_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ pm_errata_configure();
+
printk(KERN_ERR Power Management for TI OMAP3.\n);
/* XXX prcm_setup_regs needs to be before enabling hw
@@ -1035,6 +1049,15 @@ static int __init omap3_pm_init(void)
pm_idle = omap3_pm_idle;
omap3_idle_init();
+ /*
+* RTA is disabled during initialization as per erratum i608
+* it is safer to disable rta by the bootloader, but we would like
+* to be doubly sure here and prevent any mishaps.
+*/
+ if (IS_PM34XX_ERRATUM(RTA_ERRATUM_i608))
+ omap_ctrl_writel(OMAP36XX_RTA_DISABLE,
+ OMAP36XX_CONTROL_MEM_RTA_CTRL);
+
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
omap3_secure_ram_storage =
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 3fbd1e5..cc3507b 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++
[PATCH 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable/enable is done from public side
while, on OMAP3430, this is done in the secure side.
[...@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on 3630]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
v2: rebased out to this series independent of HS bugfixes
v1: http://marc.info/?l=linux-omapm=129013171125204w=2
arch/arm/mach-omap2/pm.h|6 ++
arch/arm/mach-omap2/pm34xx.c|3 +++
arch/arm/mach-omap2/sleep34xx.S | 30 ++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..aff39d0 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,4 +85,10 @@ extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+#if defined(CONFIG_PM)
+extern void enable_omap3630_toggle_l2_on_restore(void);
+#else
+static inline void enable_omap3630_toggle_l2_on_restore(void) { }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bd426cc..e0ade5f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -988,6 +988,9 @@ static void pm_errata_configure(void)
if (cpu_is_omap34xx()) {
if (cpu_is_omap3630())
pm34xx_errata |= RTA_ERRATUM_i608;
+ /* Enable the l2 cache toggling in sleep logic */
+ if (cpu_is_omap3630())
+ enable_omap3630_toggle_l2_on_restore();
}
}
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index cc3507b..d2eda01 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -111,6 +111,19 @@ ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_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
+ * 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
+ /* Setup so that we will disable and enable l2 */
+ mov r1, #0x1
+ 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
@@ -283,6 +296,14 @@ restore:
moveq r9, #0x3@ MPU OFF = L1 and L2 lost
movne r9, #0x1@ Only L1 and L2 lost = avoid L2 invalidation
bne logic_l1_restore
+
+ ldr r0, l2dis_3630
+ cmp r0, #0x1@ should we disable L2 on 3630?
+ bne skipl2dis
+ mrc p15, 0, r0, c1, c0, 1
+ bic r0, r0, #2 @ disable L2 cache
+ mcr p15, 0, r0, c1, c0, 1
+skipl2dis:
ldr r0, control_stat
ldr r1, [r0]
and r1, #0x700
@@ -343,6 +364,13 @@ smi:.word 0xE1600070 @ Call SMI monitor
(smieq)
mov r12, #0x2
.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
+ ldr r1, l2dis_3630
+ cmp r1, #0x1@ Do we need to re-enable L2 on 3630?
+ bne skipl2reen
+ mrc p15, 0, r1, c1, c0, 1
+ orr r1, r1, #2 @ re-enable L2 cache
+ mcr p15, 0, r1, c1, c0, 1
+skipl2reen:
mov r1, #0
/* Invalidate all instruction caches to PoU
* and flush branch target cache */
@@ -678,6 +706,8 @@ control_mem_rta:
.word CONTROL_MEM_RTA_CTRL
kernel_flush:
.word v7_flush_dcache_all
+l2dis_3630:
+ .word 0
/* these 2 words need to be at the end !!! */
kick_counter:
.word 0
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 v2] OMAP3: PM: Erratum i581 support: dll kick strategy
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Erratum i581 impacts OMAP3 platforms. PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing the DPLL not to be locked at times. IMPORTANT: *) This is not a complete workaround implementation as recommended by the silicon erratum. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. *) This code is mostly important for inactive and retention. The ROM code waits for the maximum dll lock time when resuming from off mode. So for off mode this code isn't really needed. This should eventually get refactored as part of cleanups to sleep34xx.S Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- v2: typo correction- erratum, support, added comment from Peter from the thread to commit message v1: http://marc.info/?l=linux-omapm=129013172525234w=2 arch/arm/mach-omap2/sleep34xx.S | 52 +++--- 1 files changed, 47 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2c20fcf..3fbd1e5 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -42,6 +42,7 @@ 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 SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is @@ -554,31 +555,67 @@ skip_l2_inval: /* Make sure SDRC accesses are ok */ wait_sdrc_ok: + +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. */ + ldr r4, cm_idlest_ckgen +wait_dpll3_lock: + ldr r5, [r4] + tst r5, #1 + beq wait_dpll3_lock + ldr r4, cm_idlest1_core +wait_sdrc_ready: ldr r5, [r4] -and r5, r5, #0x2 -cmp r5, #0 -bne wait_sdrc_ok +tst r5, #0x2 +bne wait_sdrc_ready + /* allow DLL powerdown upon hw idle req */ ldr r4, sdrc_power ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: +is_dll_in_lock_mode: + /* Is dll in lock mode? */ ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxnelr /* wait till dll locks */ -ldr r4, sdrc_dlla_status +wait_dll_lock_timed: + ldr r4, wait_dll_lock_counter + add r4, r4, #1 + str r4, wait_dll_lock_counter + ldr r4, sdrc_dlla_status +movr6, #8 /* Wait 20uS for lock */ +wait_dll_lock: + subsr6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* disable/reenable DLL if not locked */ +kick_dll: + ldr r4, sdrc_dlla_ctrl + ldr r5, [r4] + mov r6, r5 + bic r6, #(13) /* disable dll */ + str r6, [r4] + dsb + orr r6, r6, #(13) /* enable dll */ + str r6, [r4] + dsb + ldr r4, kick_counter + add r4, r4, #1 + str r4, kick_counter + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V +cm_idlest_ckgen: + .word CM_IDLEST_CKGEN_V sdrc_dlla_status: .word SDRC_DLLA_STATUS_V sdrc_dlla_ctrl: @@ -615,5 +652,10 @@ control_stat: .word CONTROL_STAT kernel_flush: .word v7_flush_dcache_all + /* these 2 words need to be at the end !!! */ +kick_counter: + .word 0 +wait_dll_lock_counter: + .word 0 ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable, while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted revisions
of silicon.
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v2: rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e0ade5f..6f33631 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -55,6 +55,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -399,6 +400,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+* Erratum i583: implementation for ES rev Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
+
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -991,6 +1003,8 @@ static void pm_errata_configure(void)
/* Enable the l2 cache toggling in sleep logic */
if (cpu_is_omap3630())
enable_omap3630_toggle_l2_on_restore();
+ if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_2))
+ pm34xx_errata |= SDRC_WAKEUP_ERRATUM_i583;
}
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/5 v2] OMAP: idle path errata fixes
Hi, as discussed in [1], here is step 2 - idle path errata fixes http://marc.info/?l=linux-omapm=129045338806957w=2 Eduardo Valentin (1): OMAP3630: PM: Erratum i583: disable coreoff if ES1.2 Nishanth Menon (1): OMAP3630: PM: Erratum i608: disable RTA Peter 'p2' De Schrijver (2): OMAP3: PM: Erratum i581 support: dll kick strategy OMAP3630: PM: Disable L2 cache while invalidating L2 cache Richard Woodruff (1): OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all arch/arm/mach-omap2/control.c |5 +- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/pm.h|6 ++ arch/arm/mach-omap2/pm34xx.c| 40 arch/arm/mach-omap2/sleep34xx.S | 187 --- 5 files changed, 171 insertions(+), 72 deletions(-) Bloat-o-meter results (Vs 2.6.37-rc3): add/remove: 1/0 grow/shrink: 7/0 up/down: 257/0 (257) function old new delta omap3_pm_init 17761916+140 omap_sram_idle 9961048 +52 omap3_save_scratchpad_contents 732 760 +28 vermagic 45 60 +15 linux_banner 133 147 +14 omap2_init_mmc 10321036 +4 pm34xx_errata - 2 +2 kernel_config_data 13899 13901 +2 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
[PATCH v5 0/4] OMAP: mailbox: fixes and enhancements
Here is the revised set taking into account comments received on previous patch set - Dropped the OMAP: mailbox: fix rx interrupt disable in omap4 patch. This patch will be sent along with mailbox hwmod changes. - Fixed the typo kifo to kfifo in OMAP: mailbox: send message in process context patch. References: http://marc.info/?l=linux-omapm=129069379825760w=2 http://marc.info/?l=linux-omapm=129060518315342w=2 The previous versions of this patch set can be found here === http://www.spinics.net/lists/linux-omap/msg40714.html http://www.spinics.net/lists/arm-kernel/msg104544.html http://www.spinics.net/lists/linux-omap/msg39988.html http://www.spinics.net/lists/linux-omap/msg39931.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html Fernando Guzman Lugo (1): OMAP: mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (3): OMAP: mailbox: fix checkpatch warnings OMAP: mailbox: send message in process context OMAP: mailbox: add notification support for multiple readers arch/arm/plat-omap/include/plat/mailbox.h |8 +- arch/arm/plat-omap/mailbox.c | 130 + 2 files changed, 81 insertions(+), 57 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 v5 1/4] OMAP: mailbox: change full flag per mailbox queue instead of global
From: Fernando Guzman Lugo x0095...@ti.com
The variable rq_full flag is a global variable, so if there are multiple
mailbox users there will be conflicts. Now there is a full flag per
mailbox queue.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..48e161c 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,12 @@ static void mbox_rx_work(struct work_struct *work)
if (mq-callback)
mq-callback((void *)msg);
+ spin_lock_irq(mq-lock);
+ if (mq-full) {
+ mq-full = false;
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ }
+ spin_unlock_irq(mq-lock);
}
}
@@ -170,7 +175,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] OMAP: mailbox: fix checkpatch warnings
Fix the following checkpatch warnings observed in mailbox module. WARNING: please, no space for starting a line, excluding comments + fail_alloc_rxq:$ WARNING: please, no space for starting a line, excluding comments + fail_alloc_txq:$ WARNING: please, no space for starting a line, excluding comments + fail_request_irq:$ WARNING: line over 80 characters + mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t)); Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/plat-omap/mailbox.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 48e161c..d9aa87c 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -281,11 +281,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox) return 0; - fail_alloc_rxq: +fail_alloc_rxq: mbox_queue_free(mbox-txq); - fail_alloc_txq: +fail_alloc_txq: free_irq(mbox-irq, mbox); - fail_request_irq: +fail_request_irq: if (mbox-ops-shutdown) mbox-ops-shutdown(mbox); @@ -396,7 +396,8 @@ static int __init omap_mbox_init(void) /* kfifo size sanity check: alignment and minimal size */ mbox_kfifo_size = ALIGN(mbox_kfifo_size, sizeof(mbox_msg_t)); - mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t)); + mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, + sizeof(mbox_msg_t)); return 0; } -- 1.7.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] OMAP: mailbox: send message in process context
Schedule the Tasklet to send only when mailbox fifo is full and there are
pending messages in kfifo, else send the message directly in the Process
context. This would avoid needless scheduling of Tasklet for every message
transfer
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d9aa87c..cc58b44 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
struct omap_mbox_queue *mq = mbox-txq;
int ret = 0, len;
- spin_lock(mq-lock);
+ spin_lock_bh(mq-lock);
if (kfifo_avail(mq-fifo) sizeof(msg)) {
ret = -ENOMEM;
goto out;
}
+ if (kfifo_is_empty(mq-fifo) !__mbox_poll_for_space(mbox)) {
+ mbox_fifo_write(mbox, msg);
+ goto out;
+ }
+
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
tasklet_schedule(mbox-txq-tasklet);
out:
- spin_unlock(mq-lock);
+ spin_unlock_bh(mq-lock);
return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] OMAP: mailbox: add notification support for multiple readers
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along with fixing the above stated issue, this patch adds the
flexibility option to register notifications from
multiple readers to the events received on a mailbox instance.
The discussion regarding this can be referred here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |7 +-
arch/arm/plat-omap/mailbox.c | 103 -
2 files changed, 61 insertions(+), 49 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 13f2ef3..cc3921e 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -46,7 +46,6 @@ struct omap_mbox_queue {
struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
- int (*callback)(void *);
struct omap_mbox*mbox;
bool full;
};
@@ -58,13 +57,15 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+ int use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index cc58b44..459b319 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -28,6 +28,7 @@
#include linux/slab.h
#include linux/kfifo.h
#include linux/err.h
+#include linux/notifier.h
#include plat/mailbox.h
@@ -150,8 +151,8 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
spin_lock_irq(mq-lock);
if (mq-full) {
mq-full = false;
@@ -249,41 +250,40 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
+ mutex_lock(mbox_configured_lock);
+ if (!mbox_configured++) {
+ if (likely(mbox-ops-startup)) {
ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
- return ret;
- }
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
+ if (unlikely(ret))
+ goto fail_startup;
+ } else
+ goto fail_startup;
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (ret) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
-
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ if (!mbox-use_count++) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
+ mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_txq;
+ }
+ mbox-txq = mq;
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
-
Re: [PATCH] OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT
* Nishanth Menon n...@ti.com [101129 06:20]: Arno Steffen had written, on 11/26/2010 05:41 AM, the following: minor comment: $subject could be the commit message probably.. and a smaller subject like OMAP3: fix typo in OMAP3_IVA_MASK could be used otherwise, looks good to me. Also, please Cc linux-arm-kernel mailing list too. Otherwise I have to repost your patch.. 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: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
Hi Olof,
On Sat, Nov 27, 2010 at 12:51 AM, Olof Johansson o...@lixom.net wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
...
Anyway, above plus a __WARN() would be OK with me.
Np, but let's wait a bit to see if something like the
BUG_ON_MAPPABLE_NULL macro materializes or not. That should satisfy
everyone in a generic way.
+ /*
+ * We can be sure the other core's memory operations
+ * are observable to us only _after_ we successfully take
+ * the hwspinlock, so we must make sure that subsequent memory
+ * operations will not be reordered before we actually took the
+ * hwspinlock.
+ *
+ * Note: the implicit memory barrier of the spinlock above is too
+ * early, so we need this additional explicit memory barrier.
+ */
+ mb();
rmb() should be sufficient here.
It's not.
We need to make sure that our writes, too, will not be reordered
before that barrier. Otherwise, we might end up changing protected
shared memory during the critical section of the remote processor
(before we acquire the lock we must not read from, or write to, the
protected shared memory).
I guess I need to add a comment about this.
How is the shared memory mapped? It should be mapped such that speculative
writes shouldn't be happening, and presumably such that hardware-triggered
prefetces won't happen either.
That's up to the users of hwspinlock to take care of, we shouldn't
worry about it here.
For those cases a DMB should be sufficient
on ARM, a DSB shouldn't be needed?
Maybe it would make more sense to move the barriers down into the
implementation-specific layer, where the appropriate low-level barries
can be used instead of the generic rmb()/wmb()/mb() ones that tend to
be heavy-handed where implementations don't match generic requirements.
...
Still, could be useful to push down to hardware-specific layers and use
just the specific barrier needed.
But that's what mb/wmb/rmb are for - we use mb because we care of both
read and write reordering - and then it's up to platform-specific code
to implement it correctly. We shouldn't worry about the
platform-specific implementation of mb/wmb/rmb in drivers.
+ /* this implies an unrecoverable bug. at least rant */
+ WARN_ON(tmp != hwlock);
I don't see how this could ever happen?
It can't. Unless there's a bug somewhere.
If it's an unrecoverable bug, then you should panic(). Or BUG_ON(),
which can also be compiled out.
Sure.
Anyway, I'm not going to argue more over this one (and the others like
it). It just seemed redundant and other subsystems tend to rely on
low-level services working correctly. :)
It's not entirely about checking other subsystems: in a way, one can
also look at it as sanity checks to the hwspinlock framework itself.
For example, when we fetch an hwlock object, and then make sure the id
of the hwlock really match the id we looked for, we get a sanity-level
confidence that our data isn't messed up, and that the radix tree was
pretty much used correctly so far.
If, for some reason, that check would fail, that doesn't necessarily
mean the radix code is faulty: it just means something went really
bad, and for some reason the incorrect object is stored with the id we
looked for. It can also be hwspinlock's fault.
It's important to detect such an anomaly as early as possible,
otherwise the wrong lock is going to be used, user data might be
corrupted, and in general, it's going to be vry hard to debug
this.
So I consider this a low-cost check with very high value, and if it
would be triggered even once in the lifetime of hwspinlock, it's well
worth it.
+/**
+ * hwspinlock_unregister() - unregister an hw spinlock
+ * @id: index of the specific hwspinlock to unregister
+ *
+ * This function should be called from the underlying platform-specific
+ * implementation, to unregister an existing (and unused) hwspinlock.
+ *
+ * Can be called from an atomic context (will not sleep) but not from
+ * within interrupt context.
+ *
+ * Returns the address of hwspinlock @id on success, or NULL on failure
Why not just return int for success / fail and have the driver keep track
of the lock pointers too?
Because it's elegant. This way drivers don't need to keep track of the
pointers.
It can be changed, with an extra cost of code (duplicated for each
implementation) and memory, but why would we want to do that ?
Functions should be short and sweet, and do just one thing
Do you consider radix_tree_delete() inappropriate then ?
It is now a hwspinlock_unregister_and_return(). Making a function to
lookup
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
Now force CS to be in inactive state only if it was inactive when it was suspended. Note that it's a bug if CS is active in any suspend state (including OFF). That strongly suggests $SUBJECT is an incomplete workaround for that other bug... When SPI wake up from OFF mode, CS is in the wrong state: force it to the inactive state. Best report the bug that the suspend/OFF state was mis-handled... That is, it didn't correctly ENTER that OFF mode... In fact ... I'd like to see that fixed more than the $SUBJECT issue, so the root cause gets resolved... CS should only be active while a SPI message is being processed, and such processing must have completed before suspend/OFF/... starts -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] OMAP3630: PM: Erratum i608: disable RTA
Nishant,
On Tue, Nov 30, 2010 at 01:49, Nishanth Menon n...@ti.com wrote:
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by overriding the
restore pointer for 3630 to allow us restore handler as the first point of
entry before caches are touched and is common for GP and HS devices.
to disable earlier than this could be possible by modifying the ppa for HS
devices, but not for GP devices.
Signed-off-by: Ambresh K ambr...@ti.com
not in Cc?
Signed-off-by: Nishanth Menon n...@ti.com
---
v2: fixed missing b restore for 3430 es3.1 code.
introduced erratum handling logic here splitting it out of uart errata
typo fixes for erratum
v1: http://marc.info/?l=linux-omapm=129013172825240w=2
arch/arm/mach-omap2/control.c | 5 -
arch/arm/mach-omap2/control.h | 5 +
arch/arm/mach-omap2/pm34xx.c | 23 +++
arch/arm/mach-omap2/sleep34xx.S | 26 ++
4 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..728f268 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0
+ if (cpu_is_omap3630())
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(get_omap3630_restore_pointer());
+ else if (omap_rev() != OMAP3430_REV_ES3_0
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..d7911c5 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -204,6 +204,10 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only RTA - Retention till Accesss control registers and bits */
+#define OMAP36XX_CONTROL_MEM_RTA_CTRL 0x40C
+#define OMAP36XX_RTA_DISABLE 0x0
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK 0x254
@@ -347,6 +351,7 @@ extern void omap3_save_scratchpad_contents(void);
extern void omap3_clear_scratchpad_contents(void);
extern u32 *get_restore_pointer(void);
extern u32 *get_es3_restore_pointer(void);
+extern u32 *get_omap3630_restore_pointer(void);
extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..bd426cc 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -54,6 +54,10 @@
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
+#define RTA_ERRATUM_i608 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -979,6 +983,14 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void pm_errata_configure(void)
+{
+ if (cpu_is_omap34xx()) {
+ if (cpu_is_omap3630())
Is it required to have both the cpu_is checks*? Why?
+ pm34xx_errata |= RTA_ERRATUM_i608;
+ }
+}
+
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 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
Nishant,
On Tue, Nov 30, 2010 at 01:49, Nishanth Menon n...@ti.com wrote:
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable/enable is done from public side
while, on OMAP3430, this is done in the secure side.
[...@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on
3630]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
v2: rebased out to this series independent of HS bugfixes
v1: http://marc.info/?l=linux-omapm=129013171125204w=2
arch/arm/mach-omap2/pm.h | 6 ++
arch/arm/mach-omap2/pm34xx.c | 3 +++
arch/arm/mach-omap2/sleep34xx.S | 30 ++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..aff39d0 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,4 +85,10 @@ extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+#if defined(CONFIG_PM)
+extern void enable_omap3630_toggle_l2_on_restore(void);
+#else
+static inline void enable_omap3630_toggle_l2_on_restore(void) { }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bd426cc..e0ade5f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -988,6 +988,9 @@ static void pm_errata_configure(void)
if (cpu_is_omap34xx()) {
if (cpu_is_omap3630())
pm34xx_errata |= RTA_ERRATUM_i608;
+ /* Enable the l2 cache toggling in sleep logic */
+ if (cpu_is_omap3630())
+ enable_omap3630_toggle_l2_on_restore();
This can simply be like this:
...
...
- if (cpu_is_omap3630())
+ if (cpu_is_omap3630()) {
pm34xx_errata |= RTA_ERRATUM_i608;
+/* Enable the l2 cache toggling in sleep logic */
+ enable_omap3630_toggle_l2_on_restore();
+ }
...
...
}
}
--
To unsubscribe from this list: send the line unsubscribe 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:DSS: possible bug in WAITFOR_VSYNC ioctl
On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. It seems like the WAITFORGO semantics could be layered on top of drivers using deferred I/O pretty easily, but the question is whether this is something that userspace plans to make general use of or not. If the only user of it in userspace code is OMAP-specific, then there's probably not a lot of point in moving it over to be generic, but if there are sufficient cases where userspace cares about this information independent of WAITFORVSYNC for manual update displays, then we can certainly look at moving it over for those cases. -- To unsubscribe from this list: send the line unsubscribe 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:DSS: possible bug in WAITFOR_VSYNC ioctl
On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. It seems like the WAITFORGO semantics could be layered on top of drivers using deferred I/O pretty easily, but the question is whether this is something that userspace plans to make general use of or not. If the only user of it in userspace code is OMAP-specific, then there's probably not a lot of point in moving it over to be generic, but if there are sufficient cases where userspace cares about this information independent of WAITFORVSYNC for manual update displays, then we can certainly look at moving it over for those cases. Also, WAITFORGO is a pretty abysmal name. It seems like what you want is a WAITFORHWSYNC or something similar. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
Hi, Nishanth Menon
What would happen without this patch? L2 data corruption after back
from OFF mode?
--
Best Regards
Hu Tao
On Tue, Nov 30, 2010 at 4:19 AM, Nishanth Menon n...@ti.com wrote:
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable/enable is done from public side
while, on OMAP3430, this is done in the secure side.
[...@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on
3630]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
v2: rebased out to this series independent of HS bugfixes
v1: http://marc.info/?l=linux-omapm=129013171125204w=2
arch/arm/mach-omap2/pm.h | 6 ++
arch/arm/mach-omap2/pm34xx.c | 3 +++
arch/arm/mach-omap2/sleep34xx.S | 30 ++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..aff39d0 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,4 +85,10 @@ extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+#if defined(CONFIG_PM)
+extern void enable_omap3630_toggle_l2_on_restore(void);
+#else
+static inline void enable_omap3630_toggle_l2_on_restore(void) { }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bd426cc..e0ade5f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -988,6 +988,9 @@ static void pm_errata_configure(void)
if (cpu_is_omap34xx()) {
if (cpu_is_omap3630())
pm34xx_errata |= RTA_ERRATUM_i608;
+ /* Enable the l2 cache toggling in sleep logic */
+ if (cpu_is_omap3630())
+ enable_omap3630_toggle_l2_on_restore();
}
}
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index cc3507b..d2eda01 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -111,6 +111,19 @@ ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_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
+ * 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
+ /* Setup so that we will disable and enable l2 */
+ mov r1, #0x1
+ 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
@@ -283,6 +296,14 @@ restore:
moveq r9, #0x3 @ MPU OFF = L1 and L2 lost
movne r9, #0x1 @ Only L1 and L2 lost = avoid L2 invalidation
bne logic_l1_restore
+
+ ldr r0, l2dis_3630
+ cmp r0, #0x1 @ should we disable L2 on 3630?
+ bne skipl2dis
+ mrc p15, 0, r0, c1, c0, 1
+ bic r0, r0, #2 @ disable L2 cache
+ mcr p15, 0, r0, c1, c0, 1
+skipl2dis:
ldr r0, control_stat
ldr r1, [r0]
and r1, #0x700
@@ -343,6 +364,13 @@ smi: .word 0xE1600070 @ Call SMI monitor
(smieq)
mov r12, #0x2
.word 0xE1600070 @ Call SMI monitor (smieq)
logic_l1_restore:
+ ldr r1, l2dis_3630
+ cmp r1, #0x1 @ Do we need to re-enable L2 on 3630?
+ bne skipl2reen
+ mrc p15, 0, r1, c1, c0, 1
+ orr r1, r1, #2 @ re-enable L2 cache
+ mcr p15, 0, r1, c1, c0, 1
+skipl2reen:
mov r1, #0
/* Invalidate all instruction caches to PoU
* and flush branch target cache */
@@ -678,6 +706,8 @@ control_mem_rta:
.word CONTROL_MEM_RTA_CTRL
kernel_flush:
.word v7_flush_dcache_all
+l2dis_3630:
+ .word 0
/* these 2 words need to be at the end !!! */
kick_counter:
.word 0
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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
RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
-Original Message- From: Paul Mundt [mailto:let...@linux-sh.org] Sent: Tuesday, November 30, 2010 12:05 PM To: Ville Syrj?l? Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. It seems like the WAITFORGO semantics could be layered on top of drivers using deferred I/O pretty easily, but the question is whether this is something that userspace plans to make general use of or not. If the only user of it in userspace code is OMAP-specific, then there's probably not a lot of point in moving it over to be generic, but if there are sufficient cases where userspace cares about this information independent of WAITFORVSYNC for manual update displays, then we can certainly look at moving it over for those cases. [Hiremath, Vaibhav] As part of this thread, I was referring to couple of other platforms like Samsung S3C, etc... and neither they do have GO bit concept nor OMAP3 like issue (I was referring to). In case of S3C, the device is capable of giving interrupt for all VFP, vsync, VBP, etc... instances if timing cycle and I believe driver makes use of vsync under WAITFORVSYNC. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
-Original Message- From: Paul Mundt [mailto:let...@linux-sh.org] Sent: Tuesday, November 30, 2010 12:10 PM To: Ville Syrj?l? Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. It seems like the WAITFORGO semantics could be layered on top of drivers using deferred I/O pretty easily, but the question is whether this is something that userspace plans to make general use of or not. If the only user of it in userspace code is OMAP-specific, then there's probably not a lot of point in moving it over to be generic, but if there are sufficient cases where userspace cares about this information independent of WAITFORVSYNC for manual update displays, then we can certainly look at moving it over for those cases. Also, WAITFORGO is a pretty abysmal name. It seems like what you want is a WAITFORHWSYNC or something similar. [Hiremath, Vaibhav] Yes exactly, this name fits to the use-case and sounds ok to me. Tomi, Any comments? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] omap-sham: OMAP SHA1/MD5 driver fixes and improvements
Thanks. On 27/11/10 10:39, ext Herbert Xu wrote: On Fri, Nov 19, 2010 at 04:04:21PM +0200, Dmitry Kasatkin wrote: Hi, Here is a set of patches which provides fixes and improvements. Based on Herbert feedback it also includes fixes so that calling final() is not mandatory. All applied. Thanks Dmitry! -- To unsubscribe from this list: send the line unsubscribe 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 1/2] input: CMA3000 Accelerometer Driver
On Mon, Nov 29, 2010 at 11:28:13AM +, Jonathan Cameron wrote:
On 11/29/10 10:57, Hemanth V wrote:
From 9985dc1211ae33baa877489c26920dfd1c29bb35 Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Thu, 26 Aug 2010 17:44:48 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver
Add support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.
Driver reports acceleration data through input subsystem
Couple of nitpicks inline. There's one unneeded NULL assignment
that should probably be cleaned up. I'd also like to see actual
part numbers listed somewhere in the Kconfig help text.
The removal of various temporary variables is something I know
at least one other reviewer has commented on. Basically they may
make the code look cleaner, but they add (marginally) to the
review burden and that's annoys reviewers ;)
Anyhow, all the comments are trivial. Nice driver Hemanth.
Dmitry: This is clean and for now has none of the controversial
sysfs interfaces so baring the input bits (which I'm not as
familiar with and you might want to glance over) this looks
ready to merge to me.
Yep, almost there.
Hemanth, does the driver still work if you apply the patch below?
Thanks.
--
Dmitry
Input: cma3000 - misc fixes
From: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/misc/Kconfig | 18 +-
drivers/input/misc/cma3000_d0x.c | 344 --
drivers/input/misc/cma3000_d0x.h | 30 +--
drivers/input/misc/cma3000_d0x_i2c.c | 117 ++--
include/linux/input/cma3000.h| 10 -
5 files changed, 286 insertions(+), 233 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d5e5fd6..f0d9017 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -449,10 +449,10 @@ config INPUT_ADXL34X_SPI
module will be called adxl34x-spi.
config INPUT_CMA3000
- tristate VTI CMA3000 Tri-axis accelerometer
- help
- Say Y here if you want to use VTI CMA3000_D0x Accelerometer
- driver
+ tristate VTI CMA3000 Tri-axis accelerometer
+ help
+ Say Y here if you want to use VTI CMA3000_D0x Accelerometer
+ driver
This driver currently only supports I2C interface to the
controller. Also select the I2C method.
@@ -463,11 +463,11 @@ config INPUT_CMA3000
module will be called cma3000_d0x.
config INPUT_CMA3000_I2C
- tristate Support I2C bus connection
- depends on INPUT_CMA3000 I2C
- help
- Say Y here if you want to use VTI CMA3000_D0x Accelerometer
- through I2C interface.
+ tristate Support I2C bus connection
+ depends on INPUT_CMA3000 I2C
+ help
+ Say Y here if you want to use VTI CMA3000_D0x Accelerometer
+ through I2C interface.
To compile this driver as a module, choose M here: the
module will be called cma3000_d0x_i2c.
diff --git a/drivers/input/misc/cma3000_d0x.c b/drivers/input/misc/cma3000_d0x.c
index 158add9..421502a 100644
--- a/drivers/input/misc/cma3000_d0x.c
+++ b/drivers/input/misc/cma3000_d0x.c
@@ -1,7 +1,5 @@
/*
- * cma3000_d0x.c
* VTI CMA3000_D0x Accelerometer driver
- * Supports I2C interface
*
* Copyright (C) 2010 Texas Instruments
* Author: Hemanth V heman...@ti.com
@@ -19,10 +17,11 @@
* this program. If not, see http://www.gnu.org/licenses/.
*/
+#include linux/types.h
#include linux/interrupt.h
#include linux/delay.h
+#include linux/slab.h
#include linux/input.h
-#include linux/platform_device.h
#include linux/input/cma3000.h
#include cma3000_d0x.h
@@ -63,10 +62,29 @@
#define BIT_TO_2G 18
#define BIT_TO_8G 71
+struct cma3000_accl_data {
+ const struct cma3000_bus_ops *bus_ops;
+ const struct cma3000_platform_data *pdata;
+
+ struct device *dev;
+ struct input_dev *input_dev;
+
+ int bit_to_mg;
+ int irq;
+
+ int g_range;
+ u8 mode;
+
+ struct mutex mutex;
+ bool opened;
+ bool suspended;
+};
+
#define CMA3000_READ(data, reg, msg) \
- ((data)-bus_ops-read(data, reg, msg))
+ (data-bus_ops-read(data-dev, reg, msg))
#define CMA3000_SET(data, reg, val, msg) \
- ((data)-bus_ops-write(data, reg, val, msg))
+ ((data)-bus_ops-write(data-dev, reg, val, msg))
+
/*
* Conversion for each of the eight modes to g, depending
* on G range i.e 2G or 8G. Some modes always operate in
@@ -74,29 +92,29 @@
*/
static int mode_to_mg[8][2] = {
- {0, 0},
- {BIT_TO_8G, BIT_TO_2G},
- {BIT_TO_8G, BIT_TO_2G},
- {BIT_TO_8G, BIT_TO_8G},
- {BIT_TO_8G, BIT_TO_8G},
- {BIT_TO_8G, BIT_TO_2G},
- {BIT_TO_8G, BIT_TO_2G},
-
