[PATCH 0/2] Combine zoom board-files
Those boards are so similar that they don't
deserve separate board files.
Felipe Balbi (2):
arm: omap: combine zoom2 and zoom3 board-files
arm: omap: zoom: substitute gpio number with symbolic name
arch/arm/mach-omap2/Makefile |4 +-
.../arm/mach-omap2/{board-zoom2.c = board-zoom.c} | 54 +++--
arch/arm/mach-omap2/board-zoom3.c | 133
3 files changed, 47 insertions(+), 144 deletions(-)
rename arch/arm/mach-omap2/{board-zoom2.c = board-zoom.c} (72%)
delete mode 100644 arch/arm/mach-omap2/board-zoom3.c
--
1.7.3.1.120.g38a18
--
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/2] arm: omap: combine zoom2 and zoom3 board-files
They are extremely similar anyway, let's get rid
of one file.
While at that, also remove the empty zoom_config
variable.
Tested-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/Makefile |4 +-
.../arm/mach-omap2/{board-zoom2.c = board-zoom.c} | 52 +++--
arch/arm/mach-omap2/board-zoom3.c | 133
3 files changed, 45 insertions(+), 144 deletions(-)
rename arch/arm/mach-omap2/{board-zoom2.c = board-zoom.c} (73%)
delete mode 100644 arch/arm/mach-omap2/board-zoom3.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..a57ae62 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -140,12 +140,12 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
board-rx51-peripherals.o \
board-rx51-video.o \
hsmmc.o
-obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
-obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom.c
similarity index 73%
rename from arch/arm/mach-omap2/board-zoom2.c
rename to arch/arm/mach-omap2/board-zoom.c
index 694c926..4215abc 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -1,6 +1,7 @@
/*
- * Copyright (C) 2009 Texas Instruments Inc.
+ * Copyright (C) 2009-2010 Texas Instruments Inc.
* Mikkel Christensen m...@ti.com
+ * Felipe Balbi ba...@ti.com
*
* Modified from mach-omap2/board-ldp.c
*
@@ -20,17 +21,24 @@
#include plat/common.h
#include plat/board.h
+#include plat/usb.h
#include mach/board-zoom.h
#include board-flash.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
+#include sdram-hynix-h8mbx00u0mer-0em.h
-static void __init omap_zoom2_init_irq(void)
+static void __init omap_zoom_init_irq(void)
{
- omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
-mt46h32m32lf6_sdrc_params);
+ if (machine_is_omap_zoom2())
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+ else if (machine_is_omap_zoom3())
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+
omap_init_irq();
omap_gpio_init();
}
@@ -132,20 +140,46 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
};
-static void __init omap_zoom2_init(void)
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .phy_reset = true,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = 64,
+ .reset_gpio_port[2] = -EINVAL,
+};
+
+static void __init omap_zoom_init(void)
{
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
- zoom_peripherals_init();
+ if (machine_is_omap_zoom2()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ } else if (machine_is_omap_zoom3()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
+ }
+
board_nand_init(zoom_nand_partitions,
ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
+ zoom_peripherals_init();
}
MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
.boot_params= 0x8100,
.map_io = omap3_map_io,
.reserve= omap_reserve,
- .init_irq = omap_zoom2_init_irq,
- .init_machine = omap_zoom2_init,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
+ .timer = omap_timer,
+MACHINE_END
+
+MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
.timer = omap_timer,
MACHINE_END
diff --git
[PATCH 2/2] arm: omap: zoom: substitute gpio number with symbolic name
It's easier to understand what that number means and
also avoids problems if we ever have to change it.
Tested-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-zoom.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index 4215abc..d641be8 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -30,6 +30,8 @@
#include sdram-micron-mt46h32m32lf-6.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#define ZOOM3_EHCI_RESET_GPIO 64
+
static void __init omap_zoom_init_irq(void)
{
if (machine_is_omap_zoom2())
@@ -146,7 +148,7 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
.reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 64,
+ .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
.reset_gpio_port[2] = -EINVAL,
};
@@ -156,7 +158,7 @@ static void __init omap_zoom_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
usb_ehci_init(ehci_pdata);
}
--
1.7.3.1.120.g38a18
--
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: linux-next - multi-omap image fails to boot on omap3/4
On Wed, Oct 20, 2010 at 5:16 AM, Gadiyar, Anand gadi...@ti.com wrote: On Wed, Oct 20, 2010 at 5:02 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [101019 15:48]: * Gadiyar, Anand gadi...@ti.com [101019 11:26]: On Tue, Oct 19, 2010 at 11:51 PM, Tony Lindgren t...@atomide.com wrote: * Anand Gadiyar gadi...@ti.com [101019 07:41]: Hi all, linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards. earlyprintk does not provide any additional prints after Uncompressing Linux... done, booting the kernel. Any ideas where to look? Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine. So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason. I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while. Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write. Oops, sorry it's still broken, wrong tree. I've started bisecting again - I needed to pick commit 5bac0926121e (driver core: platform_bus: allow runtime override of dev_pm_ops) to solve the build break. Will report back if I find something. I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine. - Anand -- 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/3] drivers: cleanup Kconfig stuff
Hi, On Tue, Oct 19, 2010 at 07:13:07PM -0500, Kevin Hilman wrote: One thing I don't like about this is that there is currently no way to 'select' as a module. Yeah, I remember suggesting to add module to Kconfig language which would do the job of selecting as module. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff
On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: Hi Roger, On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. -- regards, -roger -- 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/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 02:46:49AM -0500, Roger Quadros wrote: On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: Hi Roger, On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. It's the same thing I've been trying to say. No gadget driver is controller-specific. Even though this one is called g_nokia.ko it doesn't only Nokia can use it, neither does it mean nokia will always use MUSB. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/4] iommu: create new api to set valid da range
On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
Some IOMMUs cannot use the whole 0x0 - 0x range.
With this new API the valid range can be set.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
I don't see the point in having an API. It could be done through
platform data, and the usage of 0xF000 instead of ULONG_MAX is
independent of this.
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..db919254 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -43,6 +43,7 @@ static struct iommu_device omap3_devices[] = {
.name = iva2,
.nr_tlb_entries = 32,
.clk_name = iva2_ck,
+ .start_addr = 0x1100,
},
},
#endif
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..94f3a9a 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -50,6 +50,8 @@ struct iommu {
int (*isr)(struct iommu *obj);
void *ctx; /* iommu context: registres saved area */
+
+ u32 start_addr;
};
struct cr_regs {
@@ -103,6 +105,7 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+ u32 start_addr;
};
#if defined(CONFIG_ARCH_OMAP1)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6336ae2..3023d0b 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -926,6 +926,10 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
obj-name = pdata-name;
obj-dev = pdev-dev;
obj-ctx = (void *)obj + sizeof(*obj);
+ obj-start_addr = pdata-start_addr;
+
+ if (!obj-start_addr)
+ obj-start_addr = PAGE_SIZE;
mutex_init(obj-iommu_lock);
mutex_init(obj-mmap_lock);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index f318476..fd0c93f 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -284,7 +284,7 @@ static struct iovm_struct *alloc_iovm_area(struct
iommu *obj, u32 da,
/*
* Reserve the first page for NULL
*/
- start = PAGE_SIZE;
+ start = obj-start_addr;
if (flags IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
--
Felipe Contreras
--
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: [PATCHv4 4/4] iommu: create new api to set valid da range
From: ext felipe.contre...@gmail.com felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:35:50 +0200 On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done through platform data, and the usage of 0xF000 instead of ULONG_MAX is independent of this. Using platform data is better, but why dropping da_end? -- 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/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 3:13 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Tony Lindgren t...@atomide.com writes: So if you have something that's needed on almost every omap, you can select it there. One thing I don't like about this is that there is currently no way to 'select' as a module. In order to get to a minimal kernel, in theory, we don't need regulator, i2c, MFD, or twl4030* built in. They should all be built as modules. Yes, there are some assumptions made today that some of these things are built in, and then are used from init code, but that is broken. If someone is looking for a good omap-kernel-janitors project, I would suggest getting to a *really* minimal OMAP2+ kernel with everything possible built as modules to be a very good project. Yes, one use-case would be to select things as modules by default only if ARCH_OMAP2PLUS_TYPICAL is selected. But not everyone needs many of these things, I expect to be able to do ARCH_OMAP2PLUS_TYPICAL=n, and manually enable USB stuff USB_MUSB_HDRC=y, without having to know the dependencies myself. That was the idea: simplify the defconfigs so that they are truly minimal (they boot), and then people can add whatever they need (like USB). -- Felipe Contreras -- 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/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 10:46 AM, Roger Quadros roger.quad...@nokia.com wrote: On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. How do you expect people to know that? The Kconfig should define what USB_G_NOKIA needs to work, so that people can enable those things without go Googling hunting for a workable defconfig. Right now people can build g_nokia modules that don't work, and that shouldn't be allowed by the Kconfig. -- Felipe Contreras -- 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 9/9] arch: arm: fixed typos
Hello Jiri, hello Andrea, On Wed, Oct 20, 2010 at 12:54:33AM +0200, Andrea Gelmini wrote: 2010/10/19 Jiri Kosina jkos...@suse.cz: Hi, and thanks a lot for your reply. Could you please refresh it (and probably incorporate Andrea's changes as well) and resend it to me? OK, as I have a script to create my series there is no problem to refresh it ... Well, I already merged all the patches. I don't care about credit, so they can be commit with Uwe name. But, some tree had already applied part of my patches. I guess it would be better to wait for the next push time to re-apply all of them. I will resend when the dust settles after .37-rc1. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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/3] drivers: cleanup Kconfig stuff
On 10/20/2010 11:53 AM, ext felipe.contre...@gmail.com wrote: On Wed, Oct 20, 2010 at 10:46 AM, Roger Quadrosroger.quad...@nokia.com wrote: On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. How do you expect people to know that? The Kconfig should define what USB_G_NOKIA needs to work, so that people can enable those things without go Googling hunting for a workable defconfig. Right now people can build g_nokia modules that don't work, and that shouldn't be allowed by the Kconfig. USB_G_NOKIA just needs a USB gadget controller to work. The gadget controller used for the board should come from the board's Kconfig which will ideally be supplied by the board's vendor. For example, can't USB_GADGET_MUSB_HDRC be selected in MACH_NOKIA_RX51 in arch/arm/mach-omap2/Kconfig? or is there a better place to put it? -- regards, -roger -- 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/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 12:14 PM, Roger Quadros roger.quad...@nokia.com wrote: On 10/20/2010 11:53 AM, ext felipe.contre...@gmail.com wrote: On Wed, Oct 20, 2010 at 10:46 AM, Roger Quadrosroger.quad...@nokia.com wrote: On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. How do you expect people to know that? The Kconfig should define what USB_G_NOKIA needs to work, so that people can enable those things without go Googling hunting for a workable defconfig. Right now people can build g_nokia modules that don't work, and that shouldn't be allowed by the Kconfig. USB_G_NOKIA just needs a USB gadget controller to work. The gadget controller used for the board should come from the board's Kconfig which will ideally be supplied by the board's vendor. Ok, but USB_OMAP is not supposed to work on the N900? (I tried and it didn't) For example, can't USB_GADGET_MUSB_HDRC be selected in MACH_NOKIA_RX51 in arch/arm/mach-omap2/Kconfig? or is there a better place to put it? I don't think so, because people might not want USB at all. The ideal case would be for USB_GADGET_MUSB_HDRC to be selected automatically when the user selects USB and USB_GADGET, but that's not happening because USB_GADGET_OMAP is selected first (all the dependencies are met). -- Felipe Contreras -- 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: [PATCHv4 4/4] iommu: create new api to set valid da range
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:58:16 +0200 On Wed, Oct 20, 2010 at 11:45 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext felipe.contre...@gmail.com felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:35:50 +0200 On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done through platform data, and the usage of 0xF000 instead of ULONG_MAX is independent of this. Using platform data is better, but why dropping da_end? Because it's always 0xF000. Do you know of any instance where it's not? We should try to avoid forcing unnecessary limitations and dependencies. The usage of device virtual address space range depends on dsp(coprocessor) side S/W implimentation or configuration. -- 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/3] Add OMAP hardware spinlock misc driver
On Tue, Oct 19, 2010 at 04:31:30PM -0700, Daniel Walker wrote: On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote: OMAP4 introduces a Spinlock hardware module, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware module is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patchset adds a new misc driver for this OMAP hwspinlock module. Does this code interface with some hardware unit (other than the other processors) to accomplish this locking ? The reason I ask is because MSM has similar code, and from what I can tell the MSM version has some structures in memory but that's all. It just operates on the structures in memory. It might be worth looking over the two implementation so we aren't both remaking the wheel. Ohad's message to which you replied had: To: linux-omap@vger.kernel.org, linux-ker...@vger.kernel.org, linux-arm-ker...@lists.infradead.org Cc: Ohad Ben-Cohen o...@wizery.com, Hari Kanigeri h-kanige...@ti.com, Benoit Cousson b-cous...@ti.com, Tony Lindgren t...@atomide.com, Greg KH g...@kroah.com, Grant Likely grant.lik...@secretlab.ca, a...@linux-foundation.org, Suman Anna s-a...@ti.com Yours has: To: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com, Benoit Cousson b-cous...@ti.com, Tony Lindgren t...@atomide.com, Greg KH g...@kroah.com, linux-ker...@vger.kernel.org, Grant Likely grant.lik...@secretlab.ca, ma...@codeaurora.org, a...@linux-foundation.org, Suman Anna s-a...@ti.com, ma...@codeaurora.orgmattw, linux-arm-ker...@lists.infradead.org which includes an invalid address ma...@codeaurora.orgmattw. Is there a reason why you're excluding the linux-omap list from your message and subsequent discussion? -- 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/3] Add OMAP hardware spinlock misc driver
[resubmitting due to l-o being dropped from this discussion fork. Thanks Russell for catching this] On Wed, Oct 20, 2010 at 1:31 AM, Daniel Walker dwal...@codeaurora.org wrote: On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote: OMAP4 introduces a Spinlock hardware module, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware module is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patchset adds a new misc driver for this OMAP hwspinlock module. Does this code interface with some hardware unit (other than the other processors) to accomplish this locking ? Yes, it's a special-purpose hardware peripheral. The reason I ask is because MSM has similar code, and from what I can tell the MSM version has some structures in memory but that's all. It just operates on the structures in memory. That's interesting. We did have thoughts of making this a generic framework, in the hope that it would be useful for other vendors too, but we didn't find additional users. It might be worth looking over the two implementation so we aren't both remaking the wheel. Indeed. Where is that MSM code ? Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, October 20, 2010 5:31 AM
To: Varadarajan, Charulatha
Cc: Cousson, Benoit; Paul Walmsley; linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap2plus: wdt: Fix boot warn when
CONFIG_PM_RUNTIME=n
Varadarajan, Charulatha ch...@ti.com writes:
Paul, Benoit,
Please provide your input on this.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, October 12, 2010 11:57 PM
To: Cousson, Benoit
Cc: Varadarajan, Charulatha; Paul Walmsley;
linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap2plus: wdt: Fix boot warn when
CONFIG_PM_RUNTIME=n
Cousson, Benoit b-cous...@ti.com writes:
Adding more folks to the discussion.
On 10/12/2010 9:30 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 12:45 PM
To: Varadarajan, Charulatha
Hi Charu,
On 10/11/2010 2:02 PM, Varadarajan, Charulatha wrote:
Fix the below warning during boot
[0.00] WARNING: at
arch/arm/mach-omap2/omap_hwmod.c:1185
_omap_hwmod_enable+0x34/0x150()
[0.00] omap_hwmod: wd_timer2: enabled state can
only be entered
from initialized, idle, or disabled state
[0.00] Modules linked in:
[0.00] [c0050460] (unwind_backtrace+0x0/0xe4) from
[c0083954] (warn_slowpath_common+0x4c/0x64)
[0.00] [c0083954]
(warn_slowpath_common+0x4c/0x64) from
[c00839ec] (warn_slowpath_fmt+0x2c/0x3c)
[0.00] [c00839ec] (warn_slowpath_fmt+0x2c/0x3c) from
[c0059be4] (_omap_hwmod_enable+0x34/0x150)
[0.00] [c0059be4]
(_omap_hwmod_enable+0x34/0x150) from
[c0059d28] (omap_hwmod_enable+0x28/0x3c)
[0.00] [c0059d28] (omap_hwmod_enable+0x28/0x3c) from
[c005580c] (omap2_disable_wdt+0x48/0xdc)
[0.00] [c005580c] (omap2_disable_wdt+0x48/0xdc) from
[c0058898] (omap_hwmod_for_each_by_class+0x60/0xa4)
[0.00] [c0058898]
(omap_hwmod_for_each_by_class+0x60/0xa4)
from [c000f6d0] (omap2_init_devices+0x44/0x330)
[0.00] [c000f6d0]
(omap2_init_devices+0x44/0x330) from
[c0049578] (do_one_initcall+0xcc/0x1a4)
[0.00] [c0049578] (do_one_initcall+0xcc/0x1a4) from
[c0008780] (kernel_init+0x148/0x210)
[0.00] [c0008780] (kernel_init+0x148/0x210)
from [c004acb8]
(kernel_thread_exit+0x0/0x8)
[0.00] ---[ end trace 1b75b31a2719ed1f ]---
[0.00] wd_timer2: Could not enable clocks for
omap2_disable_wdt
When CONFIG_PM_RUNTIME is not defined, watchdog timer
clocks are not
disabled after a watchdog reset. Hence in
omap2_disable_wdt(), it is
not required to enable clocks before accessing the
watchdog timer
registers if CONFIG_PM_RUNTIME is not defined.
I'm not a big fan of adding some dependencies with
CONFIG_PM_RUNTIME
inside this code.
The real root cause is not CONFIG_PM_RUNTIME, but mostly the
skip_setup_idle variable added in
arch/arm/mach-omap2/io.c by Paul.
Yes.
So I'd rather use that parameter as an input for the
omap2_disable_wdt.
I also thought about this, but we need to
1. call omap2_disable_wdt() in omap2_init_common_hw()
rather than
omap2_init_devices(). That would involve movement of
omap2_disable_wdt() from devices.c to io.c.
(or)
2. make skip_setup_idle global
(or)
3. make omap2_disable_wdt() global and call it from
omap2_init_common_hw() and pass skip_setup_idle as parameter.
I felt that the usage of CONFIG_PM_RUNTIME is better than
the above.
But still we may consider any of the above options or any other
option. Please suggest.
It is maybe easier, but I don't think it is better...
As I said, CONFIG_PM_RUNTIME is not the root cause of your
issue, just
an indirect cause. OK, maybe strictly speaking, it is the
root cause,
since it started for that... but that not the cause that
we should
consider in your case.
If we decide to remove that CONFIG_PM_RUNTIME dependency
in the io /
hwmod code, nobody will be able to find the relation with
your code in
WDT.
That's why you should not do that, for my point of view.
Paul, Kevin,
Any thoughts on that point?
I agree that this is not strictly a dependency on PM_RUNTIME.
What's really needed is a way for low-level hwmod users like
this to be
able to check whether the hwmod is already enabled.
Something like this
(completely untested):
bool omap_hwmod_is_enabled(struct omap_hwmod *oh)
{
return (oh-_state == _HWMOD_STATE_ENABLED);
}
Okay. Would do the needful and send the patch soon.
Kevin,
Thanks. This is similar to what we were discussing internally and
I would prefer this. But is it a good idea to allow drivers to
know the state of oh and then enable/idle the device?
Or
RE: [PATCH 1/1] OMAP: DSS2: Add NEC NL8048HL11-01B display panel
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nilofer, Samreen
Sent: Thursday, October 14, 2010 4:55 PM
To: linux-omap@vger.kernel.org
Cc: Erik Gilling; Subbu Venkatesh; Mittal, Mukund; Rajkumar N; Nilofer,
Samreen
Subject: [PATCH 1/1] OMAP: DSS2: Add NEC NL8048HL11-01B display panel
From: Erik Gilling konk...@android.com
NEC WVGA LCD NL8048HL11-01B panel support has been added.
This panel is being used in zoom2/zoom3/3630 sdp boards.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
CC: Subbu Venkatesh subramani.venkat...@windriver.com
CC: Erik Gilling konk...@android.com
---
This panel driver has orginated from panel-zoom2 from the L25.x
releases.Refer Commit:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=75fc121865125d9e3ca3
b36f1f19f86b394e1f6b
[Hiremath, Vaibhav] Does this cleanly apply on linux-omap/master branch or
tomi's dss2 repo?
You should not be generating patches from any local/custom repositories.
drivers/video/omap2/displays/Kconfig |7 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 381
3 files changed, 389 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-
01b.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..f8152cf 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -20,6 +20,13 @@ config PANEL_SHARP_LQ043T1DG01
help
LCD Panel used in TI's OMAP3517 EVM boards
+config PANEL_NEC_NL8048HL11_01B
+ tristate NEC NL8048HL11-01B Panel
+ depends on OMAP2_DSS
+ help
+ This NEC NL8048HL11-01B panel is TFT LCD
+ used in the Zoom2/3/3630 sdp boards.
+
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..8ece91c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
new file mode 100644
index 000..cdc0d8f
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -0,0 +1,381 @@
+/*
+ * Support for NEC-nl8048hl11-01b panel driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * Author: Erik Gilling konk...@android.com
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include plat/display.h
+#include linux/backlight.h
+#include linux/fb.h
+
[Hiremath, Vaibhav] It would be nice if you gather all linux/xxx.h file
together, keep one line gap and add all plat/xxx.h file here.
+#define LCD_XRES 800
+#define LCD_YRES 480
+/*
+ * NEC PIX Clock Ratings
+ * MIN:21.8MHz TYP:23.8MHz MAX:25.7MHz
+ */
+#define LCD_PIXEL_CLOCK 23800
+
+struct nec_8048_data {
+ struct backlight_device *bl;
+};
+
+/*
+ * NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_8048_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_8048_bl_update_status(struct backlight_device *bl)
+{
+ struct omap_dss_device *dssdev = dev_get_drvdata(bl-dev);
+ int level;
+
+
Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff
On 10/20/2010 12:23 PM, ext Felipe Contreras wrote: On Wed, Oct 20, 2010 at 12:14 PM, Roger Quadrosroger.quad...@nokia.com wrote: On 10/20/2010 11:53 AM, ext felipe.contre...@gmail.com wrote: On Wed, Oct 20, 2010 at 10:46 AM, Roger Quadrosroger.quad...@nokia.com wrote: On 10/19/2010 05:33 PM, ext Felipe Contreras wrote: On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadrosroger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. It won't work on N900 because N900 has MUSB USB gadget controller and it needs to be selected somehow while building for N900. You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while building for N900 and not here because g_nokia is not MUSB specific. How do you expect people to know that? The Kconfig should define what USB_G_NOKIA needs to work, so that people can enable those things without go Googling hunting for a workable defconfig. Right now people can build g_nokia modules that don't work, and that shouldn't be allowed by the Kconfig. USB_G_NOKIA just needs a USB gadget controller to work. The gadget controller used for the board should come from the board's Kconfig which will ideally be supplied by the board's vendor. Ok, but USB_OMAP is not supposed to work on the N900? (I tried and it didn't) No it won't work. USB_OMAP was for older OMAP's. MUSB is on OMAP3 and later. But MUSB is not limited to OMAP SoC. For example, can't USB_GADGET_MUSB_HDRC be selected in MACH_NOKIA_RX51 in arch/arm/mach-omap2/Kconfig? or is there a better place to put it? I don't think so, because people might not want USB at all. The ideal case would be for USB_GADGET_MUSB_HDRC to be selected automatically when the user selects USB and USB_GADGET, but that's not happening because USB_GADGET_OMAP is selected first (all the dependencies are met). Yes you are right. In think with the current setup (i.e. controller selection at kconfig and limitation to one controller per config) we will never be able to satisfy all users. We might need to move to some kind of gadget controller framework and runtime controller selection to solve this problem. -- regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
Hi, On 10/20/2010 03:04 PM, ext Samreen wrote: The defconfig options for display are taken in the respective Kconfig to enable display by default on OMAP3 platforms Signed-off-by: Samreensamr...@ti.com --- Version3: Eliminate the separate default number of FBs for different architecture. Keeping default FBs as 3 as before. Version2: Enables by default NEC panel used in zoom2/3/3630sdp, instead of Sharp LQ043T1DG01 panel enabled in previous version of this patch drivers/video/omap2/displays/Kconfig |3 +++ drivers/video/omap2/dss/Kconfig |6 -- drivers/video/omap2/omapfb/Kconfig |1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index f8152cf..d818e44 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -3,6 +3,7 @@ menu OMAP2/3 Display Device Drivers config PANEL_GENERIC tristate Generic Panel + default y I fail to understand why all displays should be enabled by default? Care to explain please? -- regards, -roger -- 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: DSS2 crash with shutdown -h now
On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit arc...@ti.com wrote: Hi, linux-omap-ow...@vger.kernel.org wrote: I'm using a 2.6.35 kernel, and the generic panel driver. I see this crash about 25% of the time, so I suspect a race condition. Is anyone else encountering this? Steve Unmounting local filesystems... Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 Internal error: : 1028 [#1] last sysfs file: /sys/devices/virtual/vc/vcs12/uevent Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846 CPU: 0 Not tainted (2.6.35 #1) PC is at dss_select_dispc_clk_source+0x20/0x40 LR is at omapdss_dpi_display_disable+0x20/0x50 pc : [c01f74d4] lr : [c01ffc80] psr: 6013 sp : ded59e38 ip : 0090 fp : 0001 r10: 0001 r9 : ded58000 r8 : c0032084 r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00 r3 : r2 : fa05 r1 : c05d062c r0 : 0002 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9ed84019 DAC: 0015 Process halt (pid: 503, stack limit = 0xded582f0) Stack: (0xded59e38 to 0xded5a000) 9e20: c057da00 c020a430 9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170 dfe02400 c057d4cc 9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969 cdef0123 9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001 dfc299c0 9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013 ded59f08 9ec0: 0001 0014 ded58000 0001 0001 c0063068 ded59f08 9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001 9f00: 0006 c0063d2c 0014 0164 01f7 dfc299f8 9f20: 0164 dfc299f0 c057f598 fffd c006e810 9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00 dec41080 dec92540 9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58 dec927a8 ded58000 9f80: 0006 0025 0006 9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc 9fc0: 0006 0058 0001 0001 0001 0001 9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead [c01f74d4] (dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430] (generic_panel_disable+0xc/0x18) [c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48] (dss_disable_device+0x20/0x2c) [c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424] (bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c) from [c0230ba4] (platform_drv_shutdown+0x1c/0x24) [c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8] (device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94) from [c0065d58] (kernel_halt+0x10/0x2c) [c0065d58] (kernel_halt+0x10/0x2c) from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4] (sys_reboot+0x118/0x1dc) from [c0031f00] (ret_fast_syscall+0x0/0x30) Code: e5833000 eafd e59f101c e5912000 (e5923040) OMAPFB: pan_display(0) OMAPFB: setcmap OMAPFB: setcmap OMAPFB: setcmap Are you running a fb app while shutting down? My test method is to use a relatively minimal rootfs. It does launch a console session on the fb using a USB KB on musb, which sits at the login prompt throughout the test. I do not login via this console session. I login via serial port, wait till uptime reports 10 minutes, then issue 'shutdown -h now' Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
Hi, On Wed, 2010-10-20 at 14:04 +0200, ext Samreen wrote: The defconfig options for display are taken in the respective Kconfig to enable display by default on OMAP3 platforms Signed-off-by: Samreen samr...@ti.com --- Version3: Eliminate the separate default number of FBs for different architecture. Keeping default FBs as 3 as before. Version2: Enables by default NEC panel used in zoom2/3/3630sdp, instead of Sharp LQ043T1DG01 panel enabled in previous version of this patch drivers/video/omap2/displays/Kconfig |3 +++ drivers/video/omap2/dss/Kconfig |6 -- drivers/video/omap2/omapfb/Kconfig |1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index f8152cf..d818e44 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -3,6 +3,7 @@ menu OMAP2/3 Display Device Drivers config PANEL_GENERIC tristate Generic Panel + default y help Generic panel driver. Used for DVI output for Beagle and OMAP3 SDP. @@ -10,6 +11,7 @@ config PANEL_GENERIC config PANEL_SHARP_LS037V7DW01 tristate Sharp LS037V7DW01 LCD Panel depends on OMAP2_DSS + default y select BACKLIGHT_CLASS_DEVICE help LCD Panel used in TI's SDP3430 and EVM boards @@ -23,6 +25,7 @@ config PANEL_SHARP_LQ043T1DG01 config PANEL_NEC_NL8048HL11_01B tristate NEC NL8048HL11-01B Panel depends on OMAP2_DSS + default y help This NEC NL8048HL11-01B panel is TFT LCD used in the Zoom2/3/3630 sdp boards. What kernel is this based on? There's no Nec driver on my or Linus' tree. If you enable those panels by default, why not enable all the rest of the panels also? And should DSI/SDI/RFBI be enabled also by default, and all the panels that require those? Where do we draw the line? I feel the only sane options are to keep everything off by default, or all on by default. And setting all on by default doesn't sound too good either... diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index 43b6440..f3244a2 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -1,6 +1,7 @@ menuconfig OMAP2_DSS tristate OMAP2/3 Display Subsystem support (EXPERIMENTAL) depends on ARCH_OMAP2 || ARCH_OMAP3 + default y help OMAP2/3 Display Subsystem support. @@ -9,7 +10,7 @@ if OMAP2_DSS config OMAP2_VRAM_SIZE int VRAM size (MB) range 0 32 - default 0 + default 4 help The amount of SDRAM to reserve at boot time for video RAM use. This VRAM will be used by omapfb and other drivers that need @@ -102,7 +103,8 @@ config OMAP2_DSS_FAKE_VSYNC config OMAP2_DSS_MIN_FCK_PER_PCK int Minimum FCK/PCK ratio (for scaling) range 0 32 - default 0 + default 4 if ARCH_OMAP2 || ARCH_OMAP3 + default 0 if ARCH_OMAP4 Why is the ratio set to 4 on all OMAP2/3 boards? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 7:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Ohad Ben-Cohen o...@wizery.com writes: From: Simon Que s...@ti.com Add driver for OMAP's Hardware Spinlock module. The OMAP Hardware Spinlock module, initially introduced in OMAP4, provides hardware assistance for synchronization between the multiple processors in the device (Cortex-A9, Cortex-M3 and C64x+ DSP). ... +config OMAP_HWSPINLOCK + bool OMAP Hardware Spinlock module Should be tristate Agree, so it can also be built as a module by default. e.g., when building multi-OMAP kernels, no reason or this to be built-in. It can then be loaded as a module on OMAP4 only. But considering the current built-in use cases (i2c) we would then need to have the relevant MACH_OMAP4_* select OMAP_HWSPINLOCK (only on the OMAP4 machines on which the I2C bus is shared). Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 crash with shutdown -h now
On Wed, Oct 20, 2010 at 7:44 AM, Steve Sakoman sako...@gmail.com wrote: On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit arc...@ti.com wrote: Hi, linux-omap-ow...@vger.kernel.org wrote: I'm using a 2.6.35 kernel, and the generic panel driver. I see this crash about 25% of the time, so I suspect a race condition. Is anyone else encountering this? Steve Unmounting local filesystems... Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 Internal error: : 1028 [#1] last sysfs file: /sys/devices/virtual/vc/vcs12/uevent Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846 CPU: 0 Not tainted (2.6.35 #1) PC is at dss_select_dispc_clk_source+0x20/0x40 LR is at omapdss_dpi_display_disable+0x20/0x50 pc : [c01f74d4] lr : [c01ffc80] psr: 6013 sp : ded59e38 ip : 0090 fp : 0001 r10: 0001 r9 : ded58000 r8 : c0032084 r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00 r3 : r2 : fa05 r1 : c05d062c r0 : 0002 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9ed84019 DAC: 0015 Process halt (pid: 503, stack limit = 0xded582f0) Stack: (0xded59e38 to 0xded5a000) 9e20: c057da00 c020a430 9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170 dfe02400 c057d4cc 9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969 cdef0123 9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001 dfc299c0 9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013 ded59f08 9ec0: 0001 0014 ded58000 0001 0001 c0063068 ded59f08 9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001 9f00: 0006 c0063d2c 0014 0164 01f7 dfc299f8 9f20: 0164 dfc299f0 c057f598 fffd c006e810 9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00 dec41080 dec92540 9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58 dec927a8 ded58000 9f80: 0006 0025 0006 9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc 9fc0: 0006 0058 0001 0001 0001 0001 9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead [c01f74d4] (dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430] (generic_panel_disable+0xc/0x18) [c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48] (dss_disable_device+0x20/0x2c) [c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424] (bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c) from [c0230ba4] (platform_drv_shutdown+0x1c/0x24) [c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8] (device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94) from [c0065d58] (kernel_halt+0x10/0x2c) [c0065d58] (kernel_halt+0x10/0x2c) from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4] (sys_reboot+0x118/0x1dc) from [c0031f00] (ret_fast_syscall+0x0/0x30) Code: e5833000 eafd e59f101c e5912000 (e5923040) OMAPFB: pan_display(0) OMAPFB: setcmap OMAPFB: setcmap OMAPFB: setcmap Are you running a fb app while shutting down? My test method is to use a relatively minimal rootfs. It does launch a console session on the fb using a USB KB on musb, which sits at the login prompt throughout the test. I do not login via this console session. I login via serial port, wait till uptime reports 10 minutes, then issue 'shutdown -h now' Hi Steve 10 minutes? Sounds very much like: http://www.spinics.net/lists/linux-omap/msg34582.html *there might be a newer patch, that's just the one i had marked on my list.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/4] omap4 hsmmc: Adding card detect support for MMC1
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of kishore kadiyala
Sent: Friday, October 01, 2010 8:15 PM
To: Varadarajan, Charulatha
Cc: Samuel Ortiz; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; t...@atomide.com; a...@linux-
foundation.org; Chikkature Rajashekar, Madhusudhan;
adrian.hun...@nokia.com
Subject: Re: [PATCH v4 1/4] omap4 hsmmc: Adding card detect support for
MMC1
On Fri, Oct 1, 2010 at 8:11 PM, Varadarajan, Charulatha ch...@ti.com
wrote:
snip
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 6de90bf..e64894c 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -141,6 +141,16 @@
#define TWL6030_CHARGER_CTRL_INT_MASK 0x10
#define TWL6030_CHARGER_FAULT_INT_MASK 0x60
+#define TWL6030_MMCCTRL 0xEE
+#define VMMC_AUTO_OFF (0x1 3)
+#define SW_FC (0x1 2)
+#define STS_MMC 0x1
+
+#define TWL6030_CFG_INPUT_PUPD3 0xF2
+#define MMC_PU (0x1 3)
+#define MMC_PD (0x1 2)
+
+
#define TWL4030_CLASS_ID 0x4030
#define TWL6030_CLASS_ID 0x6030
@@ -173,6 +183,27 @@ int twl_i2c_read(u8 mod_no, u8
*value, u8 reg, unsigned num_bytes);
int twl6030_interrupt_unmask(u8 bit_mask, u8 offset);
int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
+/* Card detect Configuration for MMC1 Controller on OMAP4 */
+#ifdef CONFIG_TWL4030_CORE
+int twl6030_mmc_card_detect_config(void);
+#else
+static inline int twl6030_mmc_card_detect_config(void)
+{
+ pr_debug(twl6030_mmc_card_detect_config not
supported\n);
+ return 0;
+}
+#endif
+
+/* MMC1 Controller on OMAP4 uses Phoenix irq for
Card detect */
+#ifdef CONFIG_TWL4030_CORE
+int twl6030_mmc_card_detect(struct device *dev, int slot);
+#else
+static inline int twl6030_mmc_card_detect(struct
device *dev, int slot)
+{
+ pr_debug(Call back twl6030_mmc_card_detect
not supported\n);
Use dev_dbg() instead of pr_debug...
Same comment applies across this patch series whereever pr_err/pr_debug
APIs are used.
Couldn't get it how it makes a difference ? could you explain
One things which I can think of is dev_dbg() would contain the
device name so that you know which device the error is associated with.
-tarun
+ return -EIO;
+}
+#endif
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
--
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: DSS2 crash with shutdown -h now
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Robert Nelson
Sent: Wednesday, October 20, 2010 6:33 PM
To: Steve Sakoman
Cc: linux-omap@vger.kernel.org
Subject: Re: DSS2 crash with shutdown -h now
On Wed, Oct 20, 2010 at 7:44 AM, Steve Sakoman sako...@gmail.com wrote:
On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit arc...@ti.com wrote:
Hi,
linux-omap-ow...@vger.kernel.org wrote:
I'm using a 2.6.35 kernel, and the generic panel driver.
I see this crash about 25% of the time, so I suspect a race condition.
Is anyone else encountering this?
Steve
Unmounting local filesystems...
Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa050040 Internal error: : 1028 [#1] last sysfs file:
/sys/devices/virtual/vc/vcs12/uevent
Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846
CPU: 0 Not tainted (2.6.35 #1)
PC is at dss_select_dispc_clk_source+0x20/0x40
LR is at omapdss_dpi_display_disable+0x20/0x50
pc : [c01f74d4] lr : [c01ffc80] psr: 6013
sp : ded59e38 ip : 0090 fp : 0001
r10: 0001 r9 : ded58000 r8 : c0032084
r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00
r3 : r2 : fa05 r1 : c05d062c r0 : 0002
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 9ed84019 DAC: 0015 Process
halt (pid: 503, stack limit = 0xded582f0)
Stack: (0xded59e38 to 0xded5a000)
9e20:
c057da00 c020a430
9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170
dfe02400 c057d4cc
9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969
cdef0123
9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001
dfc299c0
9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013
ded59f08
9ec0: 0001 0014 ded58000 0001 0001 c0063068
ded59f08
9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001
9f00: 0006 c0063d2c 0014 0164 01f7
dfc299f8
9f20: 0164 dfc299f0 c057f598 fffd
c006e810
9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00
dec41080 dec92540
9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58
dec927a8 ded58000
9f80: 0006 0025
0006
9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc
9fc0: 0006 0058 0001 0001 0001
0001
9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead
[c01f74d4]
(dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80]
(omapdss_dpi_display_disable+0x20/0x50)
[c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430]
(generic_panel_disable+0xc/0x18)
[c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48]
(dss_disable_device+0x20/0x2c)
[c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424]
(bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c)
from
[c0230ba4] (platform_drv_shutdown+0x1c/0x24)
[c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8]
(device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94)
from
[c0065d58] (kernel_halt+0x10/0x2c) [c0065d58]
(kernel_halt+0x10/0x2c)
from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4]
(sys_reboot+0x118/0x1dc) from [c0031f00]
(ret_fast_syscall+0x0/0x30)
Code: e5833000 eafd e59f101c e5912000 (e5923040)
OMAPFB: pan_display(0)
OMAPFB: setcmap
OMAPFB: setcmap
OMAPFB: setcmap
Are you running a fb app while shutting down?
My test method is to use a relatively minimal rootfs. It does launch
a console session on the fb using a USB KB on musb, which sits at the
login prompt throughout the test. I do not login via this console
session.
I login via serial port, wait till uptime reports 10 minutes, then
issue 'shutdown -h now'
Hi Steve
10 minutes?
Sounds very much like: http://www.spinics.net/lists/linux-
omap/msg34582.html
Yes, I also think that this patch would solve the issue.
Steve,
If you wish to disable display auto blanking, you can add this in your
bootargs: consoleblank=0
With that the crash would not be seen.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=Documentation/kernel-parameters.txt
-Thanks,
Mayuresh
*there might be a newer patch, that's just the one i had marked on my
list..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCH 3/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen o...@wizery.com wrote: ... i2c-omap, which is subsys_initcall (the I2C bus is shared between the A9 and the M3 on some OMAP4 boards). ... Man. this is getting ugly. I think we need to discuss how to solve this at the Plumbers micro-conference. It kind of fits in with the whole embedded (ab)use of the device model topic anyway. Actually, this particular case isn't bad, but the moving of i2c and spi busses to an earlier initcall is just band-aiding the real problem of driver probe order dependencies. +1 On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Rather than moving towards having more drivers have to be built in (and depend on their probe order) we need to be moving towards building all these drivers as modules, including omap-i2c. +1 This whole thing is a mess, and today it's being solved in the wrong, non-scalable and error-prone way. The question is whether we want to gate hwspinlock until this issue is solved ? On Wed, Oct 20, 2010 at 3:20 AM, Ryan Mallon r...@bluewatersys.com wrote: The issue of probe order still needs to be resolved for those of us who do want all the drivers built into the kernel. What about doing something similar to the way suspend/resume and the device hierarchy interact ? device_resume waits for its parent to be resumed before waking up the device - this sounds similar to what -probe() should do: wait for its device dependency to probe first (so in this case, i2c-omap should wait for hwspinlock). Conversely, device_suspend waits for all its children to be suspended before continuing, which sounds just like what -remove() should do (so again, in this case, the hwspinlock device should wait for all its users to be removed before bailing). This is just a quick thought, I haven't even began to think of all the use cases and requirements. -- 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/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 3:33 PM, Roger Quadros roger.quad...@nokia.com wrote: On 10/20/2010 12:23 PM, ext Felipe Contreras wrote: On Wed, Oct 20, 2010 at 12:14 PM, Roger Quadrosroger.quad...@nokia.com wrote: USB_G_NOKIA just needs a USB gadget controller to work. The gadget controller used for the board should come from the board's Kconfig which will ideally be supplied by the board's vendor. Ok, but USB_OMAP is not supposed to work on the N900? (I tried and it didn't) No it won't work. USB_OMAP was for older OMAP's. MUSB is on OMAP3 and later. But MUSB is not limited to OMAP SoC. config USB_GADGET_OMAP depends ARCH_OMAP So how about s/ARCH_OMAP/ARCH_OMAP1/ Then USB_GADGET_MUSB_HDRC would be selected by default on OMAP2+. For example, can't USB_GADGET_MUSB_HDRC be selected in MACH_NOKIA_RX51 in arch/arm/mach-omap2/Kconfig? or is there a better place to put it? I don't think so, because people might not want USB at all. The ideal case would be for USB_GADGET_MUSB_HDRC to be selected automatically when the user selects USB and USB_GADGET, but that's not happening because USB_GADGET_OMAP is selected first (all the dependencies are met). Yes you are right. In think with the current setup (i.e. controller selection at kconfig and limitation to one controller per config) we will never be able to satisfy all users. We might need to move to some kind of gadget controller framework and runtime controller selection to solve this problem. Definitely, for multi-omap. But for OMAP1/OMAP2+ setting ARCH_OMAP1 as I just suggested would do the trick. -- Felipe Contreras -- 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/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: And to allow early board code to reserve specific hwspinlock numbers for predefined use-cases, we probably want to be before arch_initcall. There's no reason for board code to have to do this at initcall time. If we want to have allow both allocations of predefined hwspinlocks with omap_hwspinlock_request_specific(int), and dynamic allocations (where we don't care about the specific instance of the hwspinlock we will get) with omap_hwspinlock_request(), we must ensure that the former _specific() API will never be called after the latter. If we will allow drivers to call omap_hwspinlock_request() before all callers of omap_hwspinlock_request_specific() completed, then things will break (because drivers might start getting hwspinlocks that are predefined for dedicated use cases on the system). So if we want the _specific API to work, we can only allow early board code to use it in order to reserve those predefined hwspinlocks before drivers get the chance to call omap_hwspinlock_request(). The tempting alternative is not to provide the omap_hwspinlock_request_specific() API at all (which is something we discussed internally). Let's take the i2c-omap for example. It sounds like it must have a predefined hwspinlock, but what if: 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock 2. Obviously, the hwspinlock id number must be communicated to the M3 BIOS, so the i2c-omap will publish that id using a small shared memory entry that will be allocated for this sole purpose 3. we will make sure that 1+2 completes before the remote processor is taken out of reset This does not require any smart IPC and it will allow us to get rid of the omap_hwspinlock_request_specific() API and its early-callers requirement. All we will be left to take care of is the order of the -probe() execution (assuming we want both the i2c and the hwspinlock drivers to be device_initcall) This kind of thing needs to be done by platform_data function pointers, as is done for every other driver that needs platform-specific driver customization. Why would we need platform-specific function pointers here ? I'm not sure I'm following this one. Thanks, Ohad. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 3:54 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Oct 20, 2010 at 04:23:13AM -0500, Felipe Contreras wrote: Ok, but USB_OMAP is not supposed to work on the N900? (I tried and it didn't) h, that's old. That's from the omap1. It's the old omap_udc.c Ok, then the dependency should be ARCH_OMAP1, not ARCH_OMAP. I don't think so, because people might not want USB at all. The ideal case would be for USB_GADGET_MUSB_HDRC to be selected automatically when the user selects USB and USB_GADGET, but that's not happening because USB_GADGET_OMAP is selected first (all the dependencies are met). And how is that different from: default y if ARCH_OMAP3 ? If you don't want USB at all, you'll disable it by hand, the default is on. Select on board Kconfig. TWL4030_USB is inside drivers/usb/Kconfig and drivers/usb/otg/Kconfig, which means in order to achieve the same on the board config you would have to do: default y if USB_SUPPORT (USB || USB_GADGET) ARCH_OMAP3 Seems to be more convoluted to me. Besides, I think TWL4030_USB and the full description of it doesn't give any hints to the people reading drivers/usb/otg/Kconfig what is it used for. 'default y if ARCH_OMAP3' achieves that. Plus, there is no big change: config USB_MUSB_HDRC - select TWL4030_USB if MACH_OMAP_3430SDP config TWL4030_USB + default y if ARCH_OMAP3 -- Felipe Contreras -- 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/3] drivers: cleanup Kconfig stuff
hi, On Wed, Oct 20, 2010 at 09:52:06AM -0500, Felipe Contreras wrote: TWL4030_USB is inside drivers/usb/Kconfig and drivers/usb/otg/Kconfig, which means in order to achieve the same on the board config you would have to do: default y if USB_SUPPORT (USB || USB_GADGET) ARCH_OMAP3 Seems to be more convoluted to me. Besides, I think TWL4030_USB and the full description of it doesn't give any hints to the people reading drivers/usb/otg/Kconfig what is it used for. 'default y if ARCH_OMAP3' achieves that. no it doesn't. No user will 'cat drivers/usb/otg/Kconfig | grep -A 10 TWL4030' and check the 'default y if ARCH_OMAP3 if you think help is not enough, fix help. Plus, there is no big change: config USB_MUSB_HDRC - select TWL4030_USB if MACH_OMAP_3430SDP config TWL4030_USB + default y if ARCH_OMAP3 what's the problem with: diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ab784bf..3af9580 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -215,6 +215,7 @@ config MACH_NOKIA_RX51 depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select TWL4030_USB config MACH_OMAP_ZOOM2 bool OMAP3 Zoom2 board -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4 4/4] iommu: create new api to set valid da range
-Original Message-
From: felipe.contre...@gmail.com [mailto:felipe.contre...@gmail.com]
Sent: Wednesday, October 20, 2010 3:36 AM
To: Guzman Lugo, Fernando
Cc: hiroshi.d...@nokia.com; felipe.contre...@nokia.com;
david.co...@nokia.com; linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range
On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo
x0095...@ti.com wrote:
Some IOMMUs cannot use the whole 0x0 - 0x range.
With this new API the valid range can be set.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
I don't see the point in having an API. It could be done
Thanks to this api we can make this:
A new kconfig parameter for DMM size is added. Also DMM is
allocated in the last part of the IVA MMU capable address.
So that DMM address are far away of shared memory address
reducing the probability of shared memory corruption.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/staging/tidspbridge/Kconfig|8
drivers/staging/tidspbridge/core/tiomap3430.c | 18 --
.../tidspbridge/include/dspbridge/dsp-mmu.h|3 +++
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/Kconfig
b/drivers/staging/tidspbridge/Kconfig
index 672008f..37e47f5 100644
--- a/drivers/staging/tidspbridge/Kconfig
+++ b/drivers/staging/tidspbridge/Kconfig
@@ -42,6 +42,14 @@ config TIDSPBRIDGE_MEMPOOL_SIZE
Allocate specified size of memory at booting time to avoid allocation
failure under heavy memory fragmentation after some use time.
+config TIDSPBRIDGE_DMM_SIZE
+ hex DMM capable memory size (Byte)
+ depends on TIDSPBRIDGE
+ default 0x1000
+ help
+ Memory size of DSP virtural address for Dynamic Memory Mapping.
+ Please make sure the size is 4K aligned.
+
config TIDSPBRIDGE_DEBUG
bool Debug Support
depends on TIDSPBRIDGE
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index c28dcf1..31f1dd6 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -345,7 +345,6 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
OMAP343X_CONTROL_IVA2_BOOTMOD));
}
}
-
if (!status) {
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2_MASK, 0,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
@@ -362,6 +361,11 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
if (!status) {
dev_context-dsp_mmu = mmu;
sm_sg = dev_context-sh_s;
+ /* Set valid range to map shared memory */
+ status = iommu_set_da_range(mmu, sm_sg-seg0_da,
+ sm_sg-seg1_da + sm_sg-seg1_size);
+ }
+ if (!status) {
sg0_da = iommu_kmap(mmu, sm_sg-seg0_da, sm_sg-seg0_pa,
sm_sg-seg0_size, IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
if (IS_ERR_VALUE(sg0_da)) {
@@ -411,7 +415,17 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
l4_i++;
}
}
-
+ if (!status) {
+ /* Set valid range for DMM mapings */
+ if (MAX_DSP_MMU_DA - CONFIG_TIDSPBRIDGE_DMM_SIZE
+ sm_sg-seg1_da + sm_sg-seg1_size) {
+ dev_err(bridge, DMM size too big!\n);
+ status = -ENOMEM;
+ } else {
+ status = iommu_set_da_range(mmu, MAX_DSP_MMU_DA -
+ CONFIG_TIDSPBRIDGE_DMM_SIZE, MAX_DSP_MMU_DA);
+ }
+ }
/* Lock the above TLB entries and get the BIOS and load monitor timer
* information */
if (!status) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
b/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
index cb38d4c..bbbe9e6 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
@@ -22,6 +22,9 @@
#include plat/iommu.h
#include plat/iovmm.h
+/* Last patch is not mapped to detect buffer overflow in DSP side */
+#define MAX_DSP_MMU_DA 0xF000
+
/**
* dsp_mmu_init() - initialize dsp_mmu module and returns a handle
*
--
1.6.3.3
With this patch we ara mapping SHM (shared memory) at the beginning of
Iva2 iommu capabile address, it is from 0x1100 to 0x203f which
Include some parts not used. And we can mapped the DMM at the end of
The Iva2 iommu capable address it is from 0xF000 - DMMSIZE to 0xF000.
This way we have separated the DMM part from SHM range and DMM buffer can not
Be allocated near
RE: [PATCHv4 4/4] iommu: create new api to set valid da range
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Wednesday, October 20, 2010 4:27 AM To: felipe.contre...@gmail.com Cc: Guzman Lugo, Fernando; felipe.contre...@nokia.com; david.co...@nokia.com; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:58:16 +0200 On Wed, Oct 20, 2010 at 11:45 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext felipe.contre...@gmail.com felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:35:50 +0200 On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done through platform data, and the usage of 0xF000 instead of ULONG_MAX is independent of this. Using platform data is better, but why dropping da_end? Because it's always 0xF000. Do you know of any instance where it's not? We should try to avoid forcing unnecessary limitations and dependencies. The usage of device virtual address space range depends on dsp(coprocessor) side S/W implimentation or configuration. I am agree. The valid range depends on the user (dsp or something else) The only limitation of see in the iommu is that range has to be Page aligned and that should be the only limitation. Regards, Fernando. -- 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/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 04:09:22PM +0200, Ohad Ben-Cohen wrote: On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen o...@wizery.com wrote: ... i2c-omap, which is subsys_initcall (the I2C bus is shared between the A9 and the M3 on some OMAP4 boards). ... Man. this is getting ugly. I think we need to discuss how to solve this at the Plumbers micro-conference. It kind of fits in with the whole embedded (ab)use of the device model topic anyway. Actually, this particular case isn't bad, but the moving of i2c and spi busses to an earlier initcall is just band-aiding the real problem of driver probe order dependencies. +1 :-) On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Rather than moving towards having more drivers have to be built in (and depend on their probe order) we need to be moving towards building all these drivers as modules, including omap-i2c. +1 -1. Like Ryan points out below, the problem isn't modules vs. built-in, it is drivers depending on implicit init order which sort of works, but is fragile and will break in subtle ways. It needs to work in both cases, and the only solution to fix the dependency issue. I completely agree that more drivers need to support modules, but that is an orthogonal issue. I suspect that in most cases the driver model already provides the needed functionality via the parent-child relationships, and a lot of the problems can be removed by getting the driver of the parent device to register the children. It gets more complex (like in this case) when a single device needs multiple devices to be initialized before it is probed. I can think of a couple of ways to solve this. One option is for such drivers to explicitly look for its dependant devices and defer .probe() work until they appear. I hacked up some code for this a while back, but I never pursued it through to completion[1]. Another option is to defer even registering the dependent devices until the prerequisites are all probed. This could potentially be done in board support code by using a bus notifier to look for the critical device. [1]http://forum.soft32.com/linux/RFC-drivers-base-Add-bus_register_notifier_alldev-variant-ftopict478522.html This whole thing is a mess, and today it's being solved in the wrong, non-scalable and error-prone way. The question is whether we want to gate hwspinlock until this issue is solved ? No, don't gate hwspinlock. I don't see any reason to defer it for this issue. On Wed, Oct 20, 2010 at 3:20 AM, Ryan Mallon r...@bluewatersys.com wrote: The issue of probe order still needs to be resolved for those of us who do want all the drivers built into the kernel. +1 What about doing something similar to the way suspend/resume and the device hierarchy interact ? device_resume waits for its parent to be resumed before waking up the device - this sounds similar to what -probe() should do: wait for its device dependency to probe first (so in this case, i2c-omap should wait for hwspinlock). Conversely, device_suspend waits for all its children to be suspended before continuing, which sounds just like what -remove() should do (so again, in this case, the hwspinlock device should wait for all its users to be removed before bailing). This works for the simple hierarchy case, but it doesn't help the multi-dependency case. g. -- 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/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 04:38:32PM +0200, Ohad Ben-Cohen wrote: On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: And to allow early board code to reserve specific hwspinlock numbers for predefined use-cases, we probably want to be before arch_initcall. There's no reason for board code to have to do this at initcall time. If we want to have allow both allocations of predefined hwspinlocks with omap_hwspinlock_request_specific(int), and dynamic allocations (where we don't care about the specific instance of the hwspinlock we will get) with omap_hwspinlock_request(), we must ensure that the former _specific() API will never be called after the latter. If we will allow drivers to call omap_hwspinlock_request() before all callers of omap_hwspinlock_request_specific() completed, then things will break (because drivers might start getting hwspinlocks that are predefined for dedicated use cases on the system). So if we want the _specific API to work, we can only allow early board code to use it in order to reserve those predefined hwspinlocks before drivers get the chance to call omap_hwspinlock_request(). The tempting alternative is not to provide the omap_hwspinlock_request_specific() API at all (which is something we discussed internally). Let's take the i2c-omap for example. It sounds like it must have a predefined hwspinlock, but what if: 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock 2. Obviously, the hwspinlock id number must be communicated to the M3 BIOS, so the i2c-omap will publish that id using a small shared memory entry that will be allocated for this sole purpose 3. we will make sure that 1+2 completes before the remote processor is taken out of reset This does not require any smart IPC and it will allow us to get rid of the omap_hwspinlock_request_specific() API and its early-callers requirement. All we will be left to take care of is the order of the -probe() execution (assuming we want both the i2c and the hwspinlock drivers to be device_initcall) Having fought with this kind of thing before, I would strongly recommend making the interface either all-dynamic, or all-predefined, but not a mixture of the two. This kind of thing needs to be done by platform_data function pointers, as is done for every other driver that needs platform-specific driver customization. Why would we need platform-specific function pointers here ? I'm not sure I'm following this one. Thanks, Ohad. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff
On Wed, Oct 20, 2010 at 6:15 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Oct 20, 2010 at 09:52:06AM -0500, Felipe Contreras wrote: TWL4030_USB is inside drivers/usb/Kconfig and drivers/usb/otg/Kconfig, which means in order to achieve the same on the board config you would have to do: default y if USB_SUPPORT (USB || USB_GADGET) ARCH_OMAP3 Seems to be more convoluted to me. Besides, I think TWL4030_USB and the full description of it doesn't give any hints to the people reading drivers/usb/otg/Kconfig what is it used for. 'default y if ARCH_OMAP3' achieves that. no it doesn't. No user will 'cat drivers/usb/otg/Kconfig | grep -A 10 TWL4030' and check the 'default y if ARCH_OMAP3 if you think help is not enough, fix help. Users would not need to care... if they enable USB and USB_GADGET, it will be selected automatically for OMAP3, which is what users would expect. I was talking more about developers. How should the help be fixed? Select y if you are using an OMAP3 system that has TWL4030 Plus, there is no big change: config USB_MUSB_HDRC - select TWL4030_USB if MACH_OMAP_3430SDP config TWL4030_USB + default y if ARCH_OMAP3 what's the problem with: diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ab784bf..3af9580 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -215,6 +215,7 @@ config MACH_NOKIA_RX51 depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select TWL4030_USB config MACH_OMAP_ZOOM2 bool OMAP3 Zoom2 board 1) Do you think all the OMAP3 boards should add that? 2) What if you don't want to use USB? -- Felipe Contreras -- 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] spi/omap2_mcspi: Verify TX reg is empty after TX only xfer with DMA
* Ilkka Koskinen ilkka.koski...@nokia.com [101019 06:55]:
In case of TX only with DMA, the driver assumes that the data
has been transferred once DMA callback in invoked. However,
SPI's shift register may still contain data. Thus, the driver
is supposed to verify that the register is empty and the end of
the SPI transfer has been reached.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
Tested-by: Tuomas Katila ext-tuomas.2.kat...@nokia.com
Grant, can you please queue this one?
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/spi/omap2_mcspi.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..a2e053c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -296,6 +296,19 @@ static int omap2_mcspi_enable_clocks(struct omap2_mcspi
*mcspi)
return 0;
}
+static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
+{
+ unsigned long timeout;
+
+ timeout = jiffies + msecs_to_jiffies(1000);
+ while (!(__raw_readl(reg) bit)) {
+ if (time_after(jiffies, timeout))
+ return -1;
+ cpu_relax();
+ }
+ return 0;
+}
+
static unsigned
omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
{
@@ -309,11 +322,14 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
u32 l;
u8 * rx;
const u8* tx;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
l = mcspi_cached_chconf0(spi);
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+
count = xfer-len;
c = count;
word_len = cs-word_len;
@@ -382,6 +398,16 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(mcspi_dma-dma_tx_completion);
dma_unmap_single(NULL, xfer-tx_dma, count, DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
}
if (rx != NULL) {
@@ -435,19 +461,6 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
return count;
}
-static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
-{
- unsigned long timeout;
-
- timeout = jiffies + msecs_to_jiffies(1000);
- while (!(__raw_readl(reg) bit)) {
- if (time_after(jiffies, timeout))
- return -1;
- cpu_relax();
- }
- return 0;
-}
-
static unsigned
omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer)
{
--
1.6.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: [PATCHv4 4/4] iommu: create new api to set valid da range
On Wed, Oct 20, 2010 at 6:22 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done Thanks to this api we can make this: A new kconfig parameter for DMM size is added. Also DMM is allocated in the last part of the IVA MMU capable address. So that DMM address are far away of shared memory address reducing the probability of shared memory corruption. Ok, that's why it's usually a good idea to send a patch that makes use of the new API. -- Felipe Contreras -- 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/2] arm: omap: combine zoom2 and zoom3 board-files
* Felipe Balbi ba...@ti.com [101019 23:16]: They are extremely similar anyway, let's get rid of one file. While at that, also remove the empty zoom_config variable. Nice, that saves up some memory. 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] spi/omap2_mcspi: disable channel after TX_ONLY transfer in PIO mode
On Tue, Oct 19, 2010 at 06:03:27PM +0800, Jason Wang wrote: In the TX_ONLY transfer, the SPI controller also receives data simultaneously and saves them in the rx register. After the TX_ONLY transfer, the rx register will hold the random data received during the last tx transaction. If the direct following transfer is RX_ONLY, this random data has the possibility to affect this transfer like this: When the SPI controller is changed from TX_ONLY to RX_ONLY, the random data makes the rx register full immediately and triggers a dummy write automatically(in SPI RX_ONLY transfers, we need a dummy write to trigger the first transaction). So the first data received in the RX_ONLY transfer will be that random data instead of something meaningful. We can avoid this by inserting a Disable/Re-enable toggle of the channel after the TX_ONLY transfer, since it purges the rx register. Signed-off-by: Jason Wang jason77.w...@gmail.com Tested-by: Grazvydas Ignotas nota...@gmail.com Acked-by: Tony Lindgren t...@atomide.com Applied, thanks. g. --- Hi Grant, The touchpanel driver can't work correctly on the omap3evm platform, This is due to a omap2_mcspi driver issue, now fix it. drivers/spi/omap2_mcspi.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index b3a94ca..43fab41 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer) } else if (mcspi_wait_for_reg_bit(chstat_reg, OMAP2_MCSPI_CHSTAT_EOT) 0) dev_err(spi-dev, EOT timed out\n); + + /* disable chan to purge rx datas received in TX_ONLY transfer, + * otherwise these rx datas will affect the direct following + * RX_ONLY transfer. + */ + omap2_mcspi_set_enable(spi, 0); } out: omap2_mcspi_set_enable(spi, 1); -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi/omap2_mcspi: Verify TX reg is empty after TX only xfer with DMA
On Wed, Oct 20, 2010 at 09:23:57AM -0700, Tony Lindgren wrote:
* Ilkka Koskinen ilkka.koski...@nokia.com [101019 06:55]:
In case of TX only with DMA, the driver assumes that the data
has been transferred once DMA callback in invoked. However,
SPI's shift register may still contain data. Thus, the driver
is supposed to verify that the register is empty and the end of
the SPI transfer has been reached.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
Tested-by: Tuomas Katila ext-tuomas.2.kat...@nokia.com
Grant, can you please queue this one?
Acked-by: Tony Lindgren t...@atomide.com
Applied, thanks.
g.
---
drivers/spi/omap2_mcspi.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..a2e053c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -296,6 +296,19 @@ static int omap2_mcspi_enable_clocks(struct
omap2_mcspi *mcspi)
return 0;
}
+static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
+{
+ unsigned long timeout;
+
+ timeout = jiffies + msecs_to_jiffies(1000);
+ while (!(__raw_readl(reg) bit)) {
+ if (time_after(jiffies, timeout))
+ return -1;
+ cpu_relax();
+ }
+ return 0;
+}
+
static unsigned
omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
{
@@ -309,11 +322,14 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
u32 l;
u8 * rx;
const u8* tx;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
l = mcspi_cached_chconf0(spi);
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+
count = xfer-len;
c = count;
word_len = cs-word_len;
@@ -382,6 +398,16 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(mcspi_dma-dma_tx_completion);
dma_unmap_single(NULL, xfer-tx_dma, count, DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
}
if (rx != NULL) {
@@ -435,19 +461,6 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
return count;
}
-static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
-{
- unsigned long timeout;
-
- timeout = jiffies + msecs_to_jiffies(1000);
- while (!(__raw_readl(reg) bit)) {
- if (time_after(jiffies, timeout))
- return -1;
- cpu_relax();
- }
- return 0;
-}
-
static unsigned
omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer)
{
--
1.6.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: DSS2 crash with shutdown -h now
On Wed, Oct 20, 2010 at 6:02 AM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Oct 20, 2010 at 7:44 AM, Steve Sakoman sako...@gmail.com wrote: On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit arc...@ti.com wrote: Hi, linux-omap-ow...@vger.kernel.org wrote: I'm using a 2.6.35 kernel, and the generic panel driver. I see this crash about 25% of the time, so I suspect a race condition. Is anyone else encountering this? Steve Unmounting local filesystems... Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 Internal error: : 1028 [#1] last sysfs file: /sys/devices/virtual/vc/vcs12/uevent Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846 CPU: 0 Not tainted (2.6.35 #1) PC is at dss_select_dispc_clk_source+0x20/0x40 LR is at omapdss_dpi_display_disable+0x20/0x50 pc : [c01f74d4] lr : [c01ffc80] psr: 6013 sp : ded59e38 ip : 0090 fp : 0001 r10: 0001 r9 : ded58000 r8 : c0032084 r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00 r3 : r2 : fa05 r1 : c05d062c r0 : 0002 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9ed84019 DAC: 0015 Process halt (pid: 503, stack limit = 0xded582f0) Stack: (0xded59e38 to 0xded5a000) 9e20: c057da00 c020a430 9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170 dfe02400 c057d4cc 9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969 cdef0123 9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001 dfc299c0 9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013 ded59f08 9ec0: 0001 0014 ded58000 0001 0001 c0063068 ded59f08 9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001 9f00: 0006 c0063d2c 0014 0164 01f7 dfc299f8 9f20: 0164 dfc299f0 c057f598 fffd c006e810 9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00 dec41080 dec92540 9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58 dec927a8 ded58000 9f80: 0006 0025 0006 9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc 9fc0: 0006 0058 0001 0001 0001 0001 9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead [c01f74d4] (dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430] (generic_panel_disable+0xc/0x18) [c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48] (dss_disable_device+0x20/0x2c) [c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424] (bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c) from [c0230ba4] (platform_drv_shutdown+0x1c/0x24) [c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8] (device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94) from [c0065d58] (kernel_halt+0x10/0x2c) [c0065d58] (kernel_halt+0x10/0x2c) from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4] (sys_reboot+0x118/0x1dc) from [c0031f00] (ret_fast_syscall+0x0/0x30) Code: e5833000 eafd e59f101c e5912000 (e5923040) OMAPFB: pan_display(0) OMAPFB: setcmap OMAPFB: setcmap OMAPFB: setcmap Are you running a fb app while shutting down? My test method is to use a relatively minimal rootfs. It does launch a console session on the fb using a USB KB on musb, which sits at the login prompt throughout the test. I do not login via this console session. I login via serial port, wait till uptime reports 10 minutes, then issue 'shutdown -h now' Hi Steve 10 minutes? Sounds very much like: http://www.spinics.net/lists/linux-omap/msg34582.html *there might be a newer patch, that's just the one i had marked on my list.. I used a variant of the v2 patch in that thread and I can confirm that it does fix the issue. Thanks! Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 6/7] usb: ehci: Introduce CONFIG_USB_EHCI_HCD_OMAP3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Friday, August 20, 2010 4:14 AM To: Gadiyar, Anand Cc: Balbi Felipe (Nokia-MS/Helsinki); Munegowda, Keshava; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [RFC] [PATCH 6/7] usb: ehci: Introduce CONFIG_USB_EHCI_HCD_OMAP3 On Fri, Aug 20, 2010 at 08:32:04AM +0200, ext Gadiyar, Anand wrote: We have the ability to support OMAP2 and OMAP3 in the same kernel image (for example when you build with omap3_defconfig). So USB_ARCH_HAS_EHCI will get selected due to OMAP3 being present. However, no platform devices will be registered in the OMAP2 board files, so this should be okay (will try this on OMAP2 to check). correct :-) so it shouldn't be a problem the driver won't try to probe. Curious - Oct 20th now - 2 months? - any chance of seeing a non RFC patch to l-o for the same? https://patchwork.kernel.org/project/linux-omap/list/?page=1 does not show me a refreshed patchset that will apply anymore. 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 v2 3/3] drivers: cleanup Kconfig stuff
Hi, On Wed, Oct 20, 2010 at 11:22:17AM -0500, Felipe Contreras wrote: Users would not need to care... if they enable USB and USB_GADGET, it will be selected automatically for OMAP3, which is what users would expect. wouldn't a user expect USB to be enabled if the board _has_ a USB connector ? I was talking more about developers. How should the help be fixed? Select y if you are using an OMAP3 system that has TWL4030 If you have the TWL4030 family of PMIC chips and want to use USB, you probably need this. If unsure, say Y. 1) Do you think all the OMAP3 boards should add that? why not ? 2) What if you don't want to use USB? what if you don't want to use USB and we use your choice of: default y if ARCH_OMAP3 ?? what's the big difference ? The default will be USB enabled and if you don't want, just drop it. The thing is that in most cases we want to support what is wired on the board. RX51 has a USB micro-B connector, so by default we want USB peripheral enabled and host disabled. If a user (or developer for that matter) wants to play with the unsupported host mode on RX51, he will enable that part by himself and pray for it to work. If, on the other hand, a camera developer doesn't need USB at all and decides to save a few bytes on the binary, he will make sure to disable it. The thing is that there's no way to make everybody happy, so we stick to what the board is wired to do. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
Ohad Ben-Cohen o...@wizery.com writes: On Tue, Oct 19, 2010 at 7:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Ohad Ben-Cohen o...@wizery.com writes: From: Simon Que s...@ti.com Add driver for OMAP's Hardware Spinlock module. The OMAP Hardware Spinlock module, initially introduced in OMAP4, provides hardware assistance for synchronization between the multiple processors in the device (Cortex-A9, Cortex-M3 and C64x+ DSP). ... +config OMAP_HWSPINLOCK + bool OMAP Hardware Spinlock module Should be tristate Agree, so it can also be built as a module by default. e.g., when building multi-OMAP kernels, no reason or this to be built-in. It can then be loaded as a module on OMAP4 only. But considering the current built-in use cases (i2c) we would then need to have the relevant MACH_OMAP4_* select OMAP_HWSPINLOCK (only on the OMAP4 machines on which the I2C bus is shared). Yes, that is ok. At least then it can be tested by default as a module. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] usb: trivial Kconfig cleanups
On Tue, Oct 19, 2010 at 05:03:27AM -0500, Felipe Contreras wrote: Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/usb/core/Kconfig |3 --- drivers/usb/gadget/Kconfig |2 +- drivers/usb/musb/Kconfig | 17 - for drivers/usb/musb/Kconfig: Acked-by: Felipe Balbi ba...@ti.com -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: add hwspinlock device
Ohad Ben-Cohen o...@wizery.com writes: On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: And to allow early board code to reserve specific hwspinlock numbers for predefined use-cases, we probably want to be before arch_initcall. There's no reason for board code to have to do this at initcall time. If we want to have allow both allocations of predefined hwspinlocks with omap_hwspinlock_request_specific(int), and dynamic allocations (where we don't care about the specific instance of the hwspinlock we will get) with omap_hwspinlock_request(), we must ensure that the former _specific() API will never be called after the latter. If we will allow drivers to call omap_hwspinlock_request() before all callers of omap_hwspinlock_request_specific() completed, then things will break (because drivers might start getting hwspinlocks that are predefined for dedicated use cases on the system). So if we want the _specific API to work, we can only allow early board code to use it in order to reserve those predefined hwspinlocks before drivers get the chance to call omap_hwspinlock_request(). The tempting alternative is not to provide the omap_hwspinlock_request_specific() API at all (which is something we discussed internally). Let's take the i2c-omap for example. It sounds like it must have a predefined hwspinlock, but what if: 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock 2. Obviously, the hwspinlock id number must be communicated to the M3 BIOS, so the i2c-omap will publish that id using a small shared memory entry that will be allocated for this sole purpose 3. we will make sure that 1+2 completes before the remote processor is taken out of reset This does not require any smart IPC and it will allow us to get rid of the omap_hwspinlock_request_specific() API and its early-callers requirement. Yes, that would indeed simplify things. All we will be left to take care of is the order of the -probe() execution (assuming we want both the i2c and the hwspinlock drivers to be device_initcall) I understand the dependency between i2c and hwspinlock for some platforms with a shared i2c bus. Besides that being a broken hardware design, I can see the need for the i2c driver to take a hwspinlock for i2c xfers, but why does the i2c driver need to take the hwspinlock at probe time? Presumably, this is before the remote cores are executing code. This kind of thing needs to be done by platform_data function pointers, as is done for every other driver that needs platform-specific driver customization. Why would we need platform-specific function pointers here ? I'm not sure I'm following this one. So that board code (built-in) does not call the hwspinlock driver (potentially a module.) The way to solve this is to have platform_data with function pointers, so that when the driver's -probe() is done, it can call cany custom hooks registered by the board code. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 8:37 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Let's take the i2c-omap for example. It sounds like it must have a predefined hwspinlock, but what if: 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock 2. Obviously, the hwspinlock id number must be communicated to the M3 BIOS, so the i2c-omap will publish that id using a small shared memory entry that will be allocated for this sole purpose 3. we will make sure that 1+2 completes before the remote processor is taken out of reset This does not require any smart IPC and it will allow us to get rid of the omap_hwspinlock_request_specific() API and its early-callers requirement. Yes, that would indeed simplify things. Balaji, Nishant, are you OK with this ? It means that the I2C driver will dynamically get a hwspinlock and then it would need to announce the id of that hwspinlock before the M3 is taken out of reset. It will help us get rid of static allocations that will never scale nicely and static vs. dynamic allocation races. All we will be left to take care of is the order of the -probe() execution (assuming we want both the i2c and the hwspinlock drivers to be device_initcall) I understand the dependency between i2c and hwspinlock for some platforms with a shared i2c bus. Besides that being a broken hardware design, I can see the need for the i2c driver to take a hwspinlock for i2c xfers, but why does the i2c driver need to take the hwspinlock at probe time? It doesn't; it just needs to reserve a hwspinlock, and for that, we need the hwspinlock driver in place. Presumably, this is before the remote cores are executing code. This kind of thing needs to be done by platform_data function pointers, as is done for every other driver that needs platform-specific driver customization. Why would we need platform-specific function pointers here ? I'm not sure I'm following this one. So that board code (built-in) does not call the hwspinlock driver (potentially a module.) The way to solve this is to have platform_data with function pointers, so that when the driver's -probe() is done, it can call cany custom hooks registered by the board code. Sorry, still not following. Do you refer to the i2c driver calling the hwspinlcok_request function at probe time via platform_data function pointers ? With the previous _request_specific() allocation API, the important issue to follow was the timing: it had to be called before any driver gets the chance to call the dynamic _request() API. That's why we had to have early board code calling it. Obviously the hwspinlock instance would then had to be delivered to the driver via platform data. But now, if we get rid of that static allocation method entirely, i2c_omap can just call hwspinlock_request() on probe(), but again, no pdata function pointers are involved because this API is EXPORT_SYMBOL'ed. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 ES2 support
Hi Tony, On 10/20/2010 1:06 AM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [101019 15:14]: Hi Tony, Upon Nishanth request, here is the updated version... It takes into account your proposal to store partition information in a partition structure instead of inside every pad entries. The mechanism relies on the uniqueness of the pad name in each partition to find the correct partition during iteration. OK, using the offset defines won't be unique necessarily.. They should. The defines are all based on pad names that are all unique. Assuming HW folks didn't messed up the spec... Removed as well some cpu_is_xxx calls from the core code by adding a couple of flags during partition init. That's great. Please note that due to low level access to mux api from the RX51 board code, I have to disable the mux change to build properly with omap2plus_defconfig. Look like you do have some idea to fix that :-) I was thinking of: - brute force approach that consist of keeping all the data after init, and thus allowing removing the __init in the omap_mux_init_signal API - or adding some flag in the pad entry to keep them after init . Well I was thinking we just register a board specific dynamic mux table and then call that when hitting retention or off and restore after that. Still need to think about that a bit more, I don't know if we want the automatic muxing of gpio pins still in addition to that. OK, you were thinking of the MMC remux case only. That might be enough for the moment, because the other needs I heard about does not seems to be in mainline anyway (USB or modem link). Boot tested on SDP4430 with ES1.0 ES2.0 with omap2plus_defconfig. Still require some real driver to use that mux API in order to validate it. You can test by echoing wrong values after booting via /sys to mess up the MMC data lines and then type sync :) I played with debugfs a little bit but was trying to avoid messing up with pins already used... in fact I should do the opposite. That's a nice technique... The series is on top of lo/master (2.6.36-rc8) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v2 For pulling anything in, the git branches need to be based on something that's immutable. So preferrably v2.6.35 or some recent -rc tag in this case. Or rebase it on v2.6.36 after that's been released. In that case only the ES1 can be there. ES2 support will be in 2.6.37 only. That's why I have a dependency with lo/master. Do you want to split the series in two parts? Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] 32k sync timer meets hwmod
Hi Felipe, Just one minor comment about the subjects. On 10/19/2010 11:22 AM, Felipe Balbi wrote: Hi all, Converted 32k-sync timer to platform_driver and now using pm_runtime and hwmod. Tested on 3430 by me and 4430 by Tarun If someone could test on 2430 and 2420, I would be really glad. Felipe Balbi (5): arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver arm: omap: counter-32k: convert to pm_runtime API clocksource: move omap 32k timer to drivers/clocksource arm: omap: introduce 32k timer hwmod for omap2/3/4 arm: omap: 32k: move to omap_device_build 32k-sync, counter-32k, 32k timer, and then 32k... That's a lot of different names for that IP :) You should maybe stick to counter-32k and add a comment saying that the synctimer32k name was so bad, that we renamed it counter-32k. Thanks, Benoit arch/arm/mach-omap1/devices.c | 24 +++ arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 36 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/counter_32k.c | 183 -- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-32k.c | 231 13 files changed, 512 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/plat-omap/counter_32k.c create mode 100644 drivers/clocksource/omap-32k.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] arm: omap: introduce 32k timer hwmod for omap2/3/4
On 10/19/2010 11:22 AM, Balbi, Felipe wrote:
Add 32k timer hwmod to the database.
Signed-off-by: Felipe Balbiba...@ti.com
Could you add my sign-off as well on this one for the OMAP4 part?
Thanks,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
4 files changed, 216 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..05b9d2a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -557,6 +557,57 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2420_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2420_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master =omap2420_l4_wkup_hwmod,
+ .slave =omap2420_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr = omap2420_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2420_counter_32k_slaves[] = {
+ omap2420_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2420_counter_32k_hwmod = {
+ .name = counter_32k,
+ .class =omap2420_counter_hwmod_class,
+ .main_clk = sync_32k_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2420_counter_32k_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_counter_32k_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +620,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+ omap2420_counter_32k_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..96e9b12 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -569,6 +569,57 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2430_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2430_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master =omap2430_l4_wkup_hwmod,
+ .slave =omap2430_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr = omap2430_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2430_counter_32k_slaves[] = {
+ omap2430_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2430_counter_32k_hwmod = {
+ .name = counter_32k,
+ .class =omap2430_counter_hwmod_class,
+ .main_clk = sync_32k_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2430_counter_32k_slaves,
+
Re: [PATCH 0/3] Add OMAP hardware spinlock misc driver
On Wed, 2010-10-20 at 10:53 +0100, Russell King - ARM Linux wrote: To: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com, Benoit Cousson b-cous...@ti.com, Tony Lindgren t...@atomide.com, Greg KH g...@kroah.com, linux-ker...@vger.kernel.org, Grant Likely grant.lik...@secretlab.ca, ma...@codeaurora.org, a...@linux-foundation.org, Suman Anna s-a...@ti.com, ma...@codeaurora.orgmattw, linux-arm-ker...@lists.infradead.org which includes an invalid address ma...@codeaurora.orgmattw. Is there a reason why you're excluding the linux-omap list from your message and subsequent discussion? I was trying to add Matt to the CC, but I guess I accidentally deleted some CC's .. So it was purely an accident. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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/3] Add OMAP hardware spinlock misc driver
Indeed. Where is that MSM code ? We don't have an equivalent feature on MSM, nor any plans for one. Daniel was thinking of an internal test feature that had been deprecated a while ago. - Bryan -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 11:08 PM, Arnd Bergmann a...@arndb.de wrote:
Right. There are two more things to consider though:
If you know that interrupts are disabled, you may still want to avoid
having to save the interrupt flag to the stack, to save some cycles
saving and restoring it. I don't know how expensive that is on ARM,
some other architectures take an microseconds to restore the interrupt
enabled flag from a register.
To do this we need to introduce a new set of API which will not
disable interrupts, and which should only be used when the caller
knows that interrupts are already disabled.
This will save some cycles, but my concern is that this API will be
abused by drivers, and will eventually be used to take the hwspinlocks
for lengthy period of times (which might even involve sleeping).
Given that the access to the L4 interconnect is anyway slow I also
feel that the gain is negligible.
Nevertheless, it's a viable way to squeeze some cycles.
We don't have a use case in which we know the interrupts are already
disabled, but when we will, we will consider adding such API.
Even in the case where you know that interrupts are enabled, you may
want to avoid saving the interrupt flag to the stack, the simpler
API (one argument instead of two) gives less room for screwing up.
This sounds like adding a set of API that resembles spin_{unlock,lock}_irq.
My gut feeling here is that while this may be useful and simple at
certain places, it is somewhat error prone; a driver which would
erroneously use this at the wrong place will end up enabling
interrupts where it really shouldn't.
Don't you feel that proving a simple spin_lock_irqsave-like API is
actually safer and less error prone ?
I guess that is one of the reasons why spin_lock_irqsave is much more
popular than spin_lock_irq - people just know it will never screw up.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: UART: fix wakeup registers for OMAP24xx UART2
On OMAP24xx, UART2 WKEN and WKST registers are in PM_WKEN2_CORE and
PM_WKST2_CORE respecitvely. Fix the OMAP2 register init to use the
correct registers on OMAP24xx.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Tony, this should probably squeeze in for 2.6.37 as well.
arch/arm/mach-omap2/serial.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ba8a5cc..becf0e3 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -515,14 +515,8 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
uart-padconf = padconf;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
+ u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
- if (cpu_is_omap2430()) {
- uart-wk_en = OMAP2430_PRM_REGADDR(CORE_MOD, PM_WKEN1);
- uart-wk_st = OMAP2430_PRM_REGADDR(CORE_MOD, PM_WKST1);
- } else if (cpu_is_omap2420()) {
- uart-wk_en = OMAP2420_PRM_REGADDR(CORE_MOD, PM_WKEN1);
- uart-wk_st = OMAP2420_PRM_REGADDR(CORE_MOD, PM_WKST1);
- }
switch (uart-num) {
case 0:
wk_mask = OMAP24XX_ST_UART1_MASK;
@@ -531,10 +525,19 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
wk_mask = OMAP24XX_ST_UART2_MASK;
break;
case 2:
+ wk_en = OMAP24XX_PM_WKEN2;
+ wk_st = OMAP24XX_PM_WKST2;
wk_mask = OMAP24XX_ST_UART3_MASK;
break;
}
uart-wk_mask = wk_mask;
+ if (cpu_is_omap2430()) {
+ uart-wk_en = OMAP2430_PRM_REGADDR(CORE_MOD, wk_en);
+ uart-wk_st = OMAP2430_PRM_REGADDR(CORE_MOD, wk_st);
+ } else if (cpu_is_omap2420()) {
+ uart-wk_en = OMAP2420_PRM_REGADDR(CORE_MOD, wk_en);
+ uart-wk_st = OMAP2420_PRM_REGADDR(CORE_MOD, wk_st);
+ }
} else {
uart-wk_en = NULL;
uart-wk_st = NULL;
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: PM: formalize idle notifications
Currently in the idle path, we have custom function calls into device
code to handle device specific actions that need to be coordinated CPU
idle transitions. Rather than continue this ad-hoc method of calling
device code from the PM core, create a formal way for device/driver
code to register for idle notifications.
Idle notifications are done late in the idle path when interrupts are
disabled, hence use atomic notifier chains. These notifications will
also be atomic with respect to CPU idle transitions.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.c | 26 ++
arch/arm/mach-omap2/pm24xx.c |4
arch/arm/mach-omap2/pm34xx.c |5 +
arch/arm/plat-omap/include/plat/common.h | 11 +++
4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 59ca03b..343e8d6 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/err.h
+#include linux/notifier.h
#include plat/omap-pm.h
#include plat/omap_device.h
@@ -28,6 +29,31 @@ static struct device *iva_dev;
static struct device *l3_dev;
static struct device *dsp_dev;
+/* idle notifications late in the idle path (atomic, interrupts disabled) */
+static ATOMIC_NOTIFIER_HEAD(idle_notifier);
+
+void omap_idle_notifier_register(struct notifier_block *n)
+{
+ atomic_notifier_chain_register(idle_notifier, n);
+}
+EXPORT_SYMBOL_GPL(omap_idle_notifier_register);
+
+void omap_idle_notifier_unregister(struct notifier_block *n)
+{
+ atomic_notifier_chain_unregister(idle_notifier, n);
+}
+EXPORT_SYMBOL_GPL(omap_idle_notifier_unregister);
+
+void omap_idle_notifier_start(void)
+{
+ atomic_notifier_call_chain(idle_notifier, OMAP_IDLE_START, NULL);
+}
+
+void omap_idle_notifier_end(void)
+{
+ atomic_notifier_call_chain(idle_notifier, OMAP_IDLE_END, NULL);
+}
+
struct device *omap2_get_mpuss_device(void)
{
WARN_ON_ONCE(!mpu_dev);
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index a40457d..cb1b333 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -108,6 +108,8 @@ static void omap2_enter_full_retention(void)
omap2_gpio_prepare_for_idle(PWRDM_POWER_RET);
+ omap_idle_notifier_start();
+
if (omap2_pm_debug) {
omap2_pm_dump(0, 0, 0);
getnstimeofday(ts_preidle);
@@ -140,6 +142,8 @@ no_sleep:
tmp = timespec_to_ns(ts_idle) * NSEC_PER_USEC;
omap2_pm_dump(0, 1, tmp);
}
+
+ omap_idle_notifier_end();
omap2_gpio_resume_after_idle();
clk_enable(osc_ck);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..713bd04 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
#include plat/prcm.h
#include plat/gpmc.h
#include plat/dma.h
+#include plat/common.h
#include asm/tlbflush.h
@@ -375,6 +376,8 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ omap_idle_notifier_start();
+
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
@@ -471,6 +474,8 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ omap_idle_notifier_end();
+
pwrdm_post_transition();
omap2_clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index a9d69a0..1ca32cf 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -27,6 +27,8 @@
#ifndef __ARCH_ARM_MACH_OMAP_COMMON_H
#define __ARCH_ARM_MACH_OMAP_COMMON_H
+#include linux/notifier.h
+
#include plat/i2c.h
struct sys_timer;
@@ -95,4 +97,13 @@ extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
extern struct device *omap4_get_dsp_device(void);
+#define OMAP_IDLE_START 1
+#define OMAP_IDLE_END 2
+
+/* idle notifications late in the idle path (atomic, interrupts disabled) */
+extern void omap_idle_notifier_register(struct notifier_block *n);
+extern void omap_idle_notifier_unregister(struct notifier_block *n);
+extern void omap_idle_notifier_start(void);
+extern void omap_idle_notifier_end(void);
+
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP: INTC: use idle notifier for autoidle management
Move INTC autoidle management from custom hook to use the new idle
notifier.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/irq.c | 36 +--
arch/arm/mach-omap2/pm34xx.c |3 --
arch/arm/plat-omap/include/plat/irqs.h |2 -
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 32eeabe..cb51f74 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -14,10 +14,12 @@
#include linux/init.h
#include linux/interrupt.h
#include linux/io.h
+#include linux/notifier.h
+
+#include plat/common.h
#include mach/hardware.h
#include asm/mach/irq.h
-
/* selected INTC register offsets */
#define INTC_REVISION 0x
@@ -186,6 +188,24 @@ int omap_irq_pending(void)
return 0;
}
+static int omap3_intc_idle_notifier(struct notifier_block *n,
+ unsigned long val,
+ void *p)
+{
+ if (val == OMAP_IDLE_START)
+ /* Disable autoidle as it can stall interrupt controller */
+ intc_bank_write_reg(0, irq_banks[0], INTC_SYSCONFIG);
+ else
+ /* Re-enable autoidle */
+ intc_bank_write_reg(1, irq_banks[0], INTC_SYSCONFIG);
+
+ return 0;
+}
+
+static struct notifier_block omap3_intc_notifier = {
+ .notifier_call = omap3_intc_idle_notifier,
+};
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
@@ -224,6 +244,9 @@ void __init omap_init_irq(void)
set_irq_handler(i, handle_level_irq);
set_irq_flags(i, IRQF_VALID);
}
+
+ if (cpu_is_omap34xx())
+ omap_idle_notifier_register(omap3_intc_notifier);
}
#ifdef CONFIG_ARCH_OMAP3
@@ -282,15 +305,4 @@ void omap3_intc_suspend(void)
omap_ack_irq(0);
}
-void omap3_intc_prepare_idle(void)
-{
- /* Disable autoidle as it can stall interrupt controller */
- intc_bank_write_reg(0, irq_banks[0], INTC_SYSCONFIG);
-}
-
-void omap3_intc_resume_idle(void)
-{
- /* Re-enable autoidle */
- intc_bank_write_reg(1, irq_banks[0], INTC_SYSCONFIG);
-}
#endif /* CONFIG_ARCH_OMAP3 */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 713bd04..4674748 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -407,8 +407,6 @@ void omap_sram_idle(void)
}
}
- omap3_intc_prepare_idle();
-
/*
* On EMU/HS devices ROM code restores a SRDC value
* from scratchpad which has automatic self refresh on timeout
@@ -454,7 +452,6 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
- omap3_intc_resume_idle();
/* PER */
if (per_next_state PWRDM_POWER_ON) {
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..b87c211 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -424,8 +424,6 @@ extern int omap_irq_pending(void);
void omap_intc_save_context(void);
void omap_intc_restore_context(void);
void omap3_intc_suspend(void);
-void omap3_intc_prepare_idle(void);
-void omap3_intc_resume_idle(void);
#endif
#include mach/hardware.h
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/2] OMAP: PM: add early idle notifier chain
Based on previous idle notification series, starting at: [PATCH 1/3] OMAP: PM: formalize idle notifications This series adds an additional early idle notifier chain triggered early in the CPUidle path with interrupts enabled. This allows users of early notifiers to use blocking calls. While in general, use of blocking calls in idle notifiers should be avoided, the current runtime PM API can sleep/schedule so cannot be done from atomic context. Use of early notifiers allows driver/device code to use the runtime PM API in their idle notifier callbacks. RFC: note that patch 2 enables interrupts in the CPUidle path, causing interrupts to be enabled during the governor state selection and device idle detection. What could go wrong here? Kevin Hilman (2): OMAP: PM: add early idle notifications OMAP3: CPUidle: trigger early idle notification call chain arch/arm/mach-omap2/cpuidle34xx.c| 27 --- arch/arm/mach-omap2/pm.c | 27 +++ arch/arm/plat-omap/include/plat/common.h |6 ++ 3 files changed, 57 insertions(+), 3 deletions(-) -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/2] OMAP: PM: add early idle notifications
Add an early idle notification chain for device/driver code
that wishes to be notified of idle transitions.
These are called early notifiers because they are run early in the
idle path, before interrupts are disabled. Since interrups are still
enabled, these notifiers can run potentially blocking code.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.c | 27 +++
arch/arm/plat-omap/include/plat/common.h |6 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 343e8d6..e927419 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -54,6 +54,33 @@ void omap_idle_notifier_end(void)
atomic_notifier_call_chain(idle_notifier, OMAP_IDLE_END, NULL);
}
+/* idle notifications early in the idle path (interrupts enabled) */
+static BLOCKING_NOTIFIER_HEAD(early_idle_notifier);
+
+void omap_early_idle_notifier_register(struct notifier_block *n)
+{
+ blocking_notifier_chain_register(early_idle_notifier, n);
+}
+EXPORT_SYMBOL_GPL(omap_early_idle_notifier_register);
+
+void omap_early_idle_notifier_unregister(struct notifier_block *n)
+{
+ blocking_notifier_chain_unregister(early_idle_notifier, n);
+}
+EXPORT_SYMBOL_GPL(omap_early_idle_notifier_unregister);
+
+void omap_early_idle_notifier_start(void)
+{
+ blocking_notifier_call_chain(early_idle_notifier,
+OMAP_IDLE_START, NULL);
+}
+
+void omap_early_idle_notifier_end(void)
+{
+ blocking_notifier_call_chain(early_idle_notifier,
+OMAP_IDLE_END, NULL);
+}
+
struct device *omap2_get_mpuss_device(void)
{
WARN_ON_ONCE(!mpu_dev);
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 1ca32cf..1bd57f1 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -106,4 +106,10 @@ extern void omap_idle_notifier_unregister(struct
notifier_block *n);
extern void omap_idle_notifier_start(void);
extern void omap_idle_notifier_end(void);
+/* idle notifications early in the idle path (interrupts enabled) */
+extern void omap_early_idle_notifier_register(struct notifier_block *n);
+extern void omap_early_idle_notifier_unregister(struct notifier_block *n);
+extern void omap_early_idle_notifier_start(void);
+extern void omap_early_idle_notifier_end(void);
+
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 2/2] OMAP3: CPUidle: trigger early idle notification call chain
During the early part of the CPUidle path (state selection by the
governer, checking for device activity, etc.) there is no (good)
reason to have interrupts disabled.
Therefore, enable interrupts early in the CPUidle path and then
trigger the early idle notifier call chain after device activity
checks and the next power states have been programmed. Interrupts are
then (re)disabled after the final state is selected.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d50b45..8c57360 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -30,6 +30,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/serial.h
+#include plat/common.h
#include pm.h
#include control.h
@@ -128,12 +129,14 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
- local_irq_disable();
- local_fiq_disable();
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
+ omap_early_idle_notifier_start();
+
+ local_irq_disable();
+ local_fiq_disable();
+
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -157,6 +160,8 @@ return_sleep_time:
local_irq_enable();
local_fiq_enable();
+ omap_early_idle_notifier_end();
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
@@ -459,6 +464,21 @@ struct cpuidle_driver omap3_idle_driver = {
.owner =THIS_MODULE,
};
+static int omap3_idle_prepare(struct cpuidle_device *dev)
+{
+ /*
+* Enable interrupts during the early part of the CPUidle path.
+* They are later (re)disabled when the final state is selected.
+*
+* The primary reason for this is to enable non-atomic idle
+* notifications to drivers that want to coordinate device
+* idle transitions with CPU idle transitions.
+*/
+ local_irq_enable();
+
+ return 0;
+}
+
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -482,6 +502,7 @@ int __init omap3_idle_init(void)
dev = per_cpu(omap3_idle_dev, smp_processor_id());
+ dev-prepare = omap3_idle_prepare;
for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
cx = omap3_power_states[i];
state = dev-states[count];
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: add hwspinlock device
Ohad Ben-Cohen o...@wizery.com writes: On Wed, Oct 20, 2010 at 8:37 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Let's take the i2c-omap for example. It sounds like it must have a predefined hwspinlock, but what if: 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock 2. Obviously, the hwspinlock id number must be communicated to the M3 BIOS, so the i2c-omap will publish that id using a small shared memory entry that will be allocated for this sole purpose 3. we will make sure that 1+2 completes before the remote processor is taken out of reset This does not require any smart IPC and it will allow us to get rid of the omap_hwspinlock_request_specific() API and its early-callers requirement. Yes, that would indeed simplify things. Balaji, Nishant, are you OK with this ? It means that the I2C driver will dynamically get a hwspinlock and then it would need to announce the id of that hwspinlock before the M3 is taken out of reset. It will help us get rid of static allocations that will never scale nicely and static vs. dynamic allocation races. All we will be left to take care of is the order of the -probe() execution (assuming we want both the i2c and the hwspinlock drivers to be device_initcall) I understand the dependency between i2c and hwspinlock for some platforms with a shared i2c bus. Besides that being a broken hardware design, I can see the need for the i2c driver to take a hwspinlock for i2c xfers, but why does the i2c driver need to take the hwspinlock at probe time? It doesn't; it just needs to reserve a hwspinlock, and for that, we need the hwspinlock driver in place. OK Presumably, this is before the remote cores are executing code. This kind of thing needs to be done by platform_data function pointers, as is done for every other driver that needs platform-specific driver customization. Why would we need platform-specific function pointers here ? I'm not sure I'm following this one. So that board code (built-in) does not call the hwspinlock driver (potentially a module.) The way to solve this is to have platform_data with function pointers, so that when the driver's -probe() is done, it can call cany custom hooks registered by the board code. Sorry, still not following. Do you refer to the i2c driver calling the hwspinlcok_request function at probe time via platform_data function pointers ? No, earlier in this discussion, in response to my question about users of this API early in boot, you said: And to allow early board code to reserve specific hwspinlock numbers for predefined use-cases, we probably want to be before arch_initcall. My suggestion to use platform_data + function pointers was to address the requesting of hwspinlocks in board/platform-specific code. If the _request_specific() API is removed, and board code no longer needs to call hwspinlock API, then this issue is moot. However, if board code ever needs to call the hwspinlock API, then pdata func pointers are needed to handle both the case of late driver probe or driver built as a module. With the previous _request_specific() allocation API, the important issue to follow was the timing: it had to be called before any driver gets the chance to call the dynamic _request() API. That's why we had to have early board code calling it. Obviously the hwspinlock instance would then had to be delivered to the driver via platform data. But now, if we get rid of that static allocation method entirely, i2c_omap can just call hwspinlock_request() on probe(), but again, no pdata function pointers are involved because this API is EXPORT_SYMBOL'ed. Agreed. If you get rid of the _request_specific() API, then this is not needed in the board code and pdata function pointers should not be needed. So then, we're back to how to ensure probe order of hwspinlock vs i2c. :/ I agree with others that this is a much broader problem, and should not hold up the hwspinlock driver, so for now, making hwspinlock have an initcall before subsys_initcall is OK with me. Probably arch_initcall() is fine here. I suggest you add a comment in the code at the initcall point as to why it is using arch_initcall(), namely it has to load before i2c because... Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] 32k sync timer meets hwmod
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Thursday, October 21, 2010 3:00 AM To: Balbi, Felipe Cc: Tony Lindgren; Linux OMAP Mailing List Subject: Re: [PATCH 0/5] 32k sync timer meets hwmod Hi Felipe, Just one minor comment about the subjects. On 10/19/2010 11:22 AM, Felipe Balbi wrote: Hi all, Converted 32k-sync timer to platform_driver and now using pm_runtime and hwmod. Tested on 3430 by me and 4430 by Tarun If someone could test on 2430 and 2420, I would be really glad. Felipe Balbi (5): arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver arm: omap: counter-32k: convert to pm_runtime API clocksource: move omap 32k timer to drivers/clocksource arm: omap: introduce 32k timer hwmod for omap2/3/4 arm: omap: 32k: move to omap_device_build 32k-sync, counter-32k, 32k timer, and then 32k... That's a lot of different names for that IP :) You should maybe stick to counter-32k and add a comment saying that the synctimer32k name was so bad, that we renamed it counter-32k. I have used counter-32k name for one of the clock source names in dmtimer. -tarun arch/arm/mach-omap1/devices.c | 24 +++ arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 36 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/counter_32k.c | 183 -- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-32k.c | 231 13 files changed, 512 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/plat-omap/counter_32k.c create mode 100644 drivers/clocksource/omap-32k.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/1] OMAP: DSS2: Add NEC NL8048HL11-01B display panel
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, October 20, 2010 5:57 PM
To: Nilofer, Samreen; linux-omap@vger.kernel.org
Cc: Erik Gilling; Subbu Venkatesh; Mittal, Mukund; Rajkumar N
Subject: RE: [PATCH 1/1] OMAP: DSS2: Add NEC NL8048HL11-01B
display panel
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nilofer, Samreen
Sent: Thursday, October 14, 2010 4:55 PM
To: linux-omap@vger.kernel.org
Cc: Erik Gilling; Subbu Venkatesh; Mittal, Mukund; Rajkumar N;
Nilofer, Samreen
Subject: [PATCH 1/1] OMAP: DSS2: Add NEC NL8048HL11-01B
display panel
From: Erik Gilling konk...@android.com
NEC WVGA LCD NL8048HL11-01B panel support has been added.
This panel is being used in zoom2/zoom3/3630 sdp boards.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
CC: Subbu Venkatesh subramani.venkat...@windriver.com
CC: Erik Gilling konk...@android.com
---
This panel driver has orginated from panel-zoom2 from the L25.x
releases.Refer Commit:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=75fc121865125d9e
3ca3
b36f1f19f86b394e1f6b
[Hiremath, Vaibhav] Does this cleanly apply on
linux-omap/master branch or tomi's dss2 repo?
You should not be generating patches from any local/custom
repositories.
[Samreen] These patch cleanly applies on Tomi' dss2 tree.
I have tested and validated this patch on tomi's tree.
drivers/video/omap2/displays/Kconfig |7 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 381
3 files changed, 389 insertions(+), 0 deletions(-) create mode
100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-
01b.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..f8152cf 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -20,6 +20,13 @@ config PANEL_SHARP_LQ043T1DG01
help
LCD Panel used in TI's OMAP3517 EVM boards
+config PANEL_NEC_NL8048HL11_01B
+ tristate NEC NL8048HL11-01B Panel
+ depends on OMAP2_DSS
+ help
+ This NEC NL8048HL11-01B panel is TFT LCD
+ used in the Zoom2/3/3630 sdp boards.
+
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..8ece91c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) +=
panel-nec-nl8048hl11-01b.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o diff
--git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
new file mode 100644
index 000..cdc0d8f
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -0,0 +1,381 @@
+/*
+ * Support for NEC-nl8048hl11-01b panel driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * Author: Erik Gilling konk...@android.com
+ * This program is free software; you can redistribute it and/or
+modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY
+ or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+ License
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General
Public License
along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include plat/display.h
+#include linux/backlight.h
+#include linux/fb.h
+
[Hiremath, Vaibhav] It would be nice if you gather all
linux/xxx.h file together, keep one line gap and add all
plat/xxx.h file here.
[Samreen]
Will fix this.
+#define LCD_XRES 800
+#define LCD_YRES 480
+/*
+ * NEC PIX Clock Ratings
+ * MIN:21.8MHz TYP:23.8MHz MAX:25.7MHz */
+#define LCD_PIXEL_CLOCK23800
+
+struct nec_8048_data {
+ struct backlight_device *bl;
+};
+
+/*
+ * NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below */
+
+static struct omap_video_timings
Re: [PATCH 4/5] arm: omap: introduce 32k timer hwmod for omap2/3/4
On Wed, Oct 20, 2010 at 04:32:04PM -0500, Cousson, Benoit wrote: On 10/19/2010 11:22 AM, Balbi, Felipe wrote: Add 32k timer hwmod to the database. Signed-off-by: Felipe Balbiba...@ti.com Could you add my sign-off as well on this one for the OMAP4 part? oops, my mistake, sorry for that. True, the OMAP4 part is done by Benoit, I'll add the sign-off and re-send after I get confirmation about 2430/2420. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 2/2] OMAP3: CPUidle: trigger early idle notification call chain
Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Thursday, October 21, 2010 5:09 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [RFC/PATCH 2/2] OMAP3: CPUidle: trigger early idle notification call
chain
During the early part of the CPUidle path (state selection by the
governer, checking for device activity, etc.) there is no (good)
reason to have interrupts disabled.
Therefore, enable interrupts early in the CPUidle path and then
trigger the early idle notifier call chain after device activity
checks and the next power states have been programmed. Interrupts are
then (re)disabled after the final state is selected.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 27 --
-
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
omap2/cpuidle34xx.c
index 0d50b45..8c57360 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -30,6 +30,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/serial.h
+#include plat/common.h
#include pm.h
#include control.h
@@ -128,12 +129,14 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
- local_irq_disable();
- local_fiq_disable();
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
+ omap_early_idle_notifier_start();
+
+ local_irq_disable();
+ local_fiq_disable();
+
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -157,6 +160,8 @@ return_sleep_time:
local_irq_enable();
local_fiq_enable();
+ omap_early_idle_notifier_end();
It appears that idle notifiers (for restore path) are called after
getnstimeofday is called which means time spent in idle callbacks are not
accounted in cpuidle time.
Will it not impact the cpuidle c state prediction and latency computation?
Regards
Vishwa
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
@@ -459,6 +464,21 @@ struct cpuidle_driver omap3_idle_driver = {
.owner =THIS_MODULE,
};
+static int omap3_idle_prepare(struct cpuidle_device *dev)
+{
+ /*
+ * Enable interrupts during the early part of the CPUidle path.
+ * They are later (re)disabled when the final state is selected.
+ *
+ * The primary reason for this is to enable non-atomic idle
+ * notifications to drivers that want to coordinate device
+ * idle transitions with CPU idle transitions.
+ */
+ local_irq_enable();
+
+ return 0;
+}
+
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -482,6 +502,7 @@ int __init omap3_idle_init(void)
dev = per_cpu(omap3_idle_dev, smp_processor_id());
+ dev-prepare = omap3_idle_prepare;
for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
cx = omap3_power_states[i];
state = dev-states[count];
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
