Re: Serial console not working after waking up from sleep
Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform smsc911x.0: LATE suspend platform musb_hdrc: LATE suspend platform omap2-nand: LATE suspend serial8250 serial8250.2: LATE suspend, may wakeup serial8250 serial8250.1: LATE suspend, may wakeup serial8250 serial8250.0: LATE suspend, may wakeup platform overo_lcd: LATE suspend i2c_omap i2c_omap.3: LATE suspend i2c_omap i2c_omap.1: LATE suspend PM: late suspend of devices complete after 103.088 msecs Successfully put all powerdomains to target state i2c_omap i2c_omap.1: EARLY resume i2c_omap i2c_omap.3: EARLY resume platform overo_lcd: EARLY resume serial8250 serial8250.0: EARLY resume serial8250 serial8250.1: EARLY resume serial8250 serial8250.2: EARLY resume platform omap2-nand: EARLY resume platform musb_hdrc: EARLY resume platform smsc911x.0: EARLY resume platform smsc911x.1: EARLY resume platform omap2_mcspi.1: EARLY resume platform omap2_mcspi.2: EARLY resume platform omap2_mcspi.3: EARLY resume platform omap2_mcspi.4: EARLY resume arm-pmu arm-pmu.0: EARLY resume platform omap_rng: EARLY resume platform omapfb: EARLY resume i2c i2c-1: EARLY resume twl 1-0048: EARLY resume dummy 1-0049: EARLY resume dummy 1-004a: EARLY resume dummy 1-004b: EARLY resume twl4030_gpio twl4030_gpio: EARLY resume
RE: [PATCH 10/13 v3] OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 10/13 v3] OMAP: GPIO: Add gpio dev_attr and correct clks
in
OMAP4 hwmod struct
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 37
+++-
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 20f5f8c..b4c0878 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/gpio.h
#include omap_hwmod_common_data.h
@@ -1272,6 +1273,12 @@ static struct omap_hwmod omap44xx_fdif_hwmod = {
* general purpose io module
*/
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .gpio_bank_count = 6,
Why do you need that information?
The point is that this struct is in theory a per instance data not a
global one. If needed, you should be able to get that from the number of
iteration done during the init of hwmods.
Even though it is possible to get it through number of iterations, more
efficient approach would be to keep this information here. My point is that
this information can be auto-generated and hence it is better to keep it in
hwmod database itself.
FYI, in a meeting we recently had with Kevin, we discussed about global data
information getting duplicated for each instance and it was agreed that it is
okay to have pointers duplicated for each instance.
+ .gpio_bank_bits = 32,
+ .dbck_flag = true,
+};
Since this structure is the same than OMAP3, you should maybe consider
sharing it.
They are in different _data.c files. I feel that it will be good if they are
kept decoupled as we need not have to mix up different SoC data. Here it's only
a coincidence that OMAP3 and OMAP4 have same data.
+
static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1305,7 +1312,7 @@ static struct omap_hwmod_addr_space
omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master =omap44xx_l4_wkup_hwmod,
.slave =omap44xx_gpio1_hwmod,
- .clk= l4_wkup_clk_mux_ck,
+ .clk= gpio1_ick,
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1325,7 +1332,7 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.class =omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
- .main_clk = gpio1_ick,
+ .main_clk = NULL,
Removing the line is enough. It will be null by default.
Agreed.
I'm still not 100% sure that this is the good way to control the GPIO
module mode, but at least this is cleaner than the previous clock mapping.
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 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha Vch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver (eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this
should not be moved to hwmod dev_attr because this is only an info required for
the driver to identify the chip ID and accordingly access functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete cleanup.
What does 'method' mean in that context? Maybe the name should be revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed once the whole GPIO code is cleaned up. This patch
series doesn't bother to clean up GPIO code as the changes would be huge and
intended only for HWMOD FW adaptation. Cleaning up GPIO code would come as a
separate series and we can address this then.
+ pdata-virtual_irq_start = IH_GPIO_BASE + 32 * id;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(*pdata), omap_gpio_latency,
+ ARRAY_SIZE(omap_gpio_latency),
+ false);
+ WARN(IS_ERR(od), Cant build omap_device for %s:%s.\n,
+ name, oh-name);
+
+ id++;
+ return 0;
+}
+
+static int __init gpio_init(int method)
+{
+ return omap_hwmod_for_each_by_class(gpio, omap2_init_gpio,
+ (void *)method);
+}
+
+/*
+ * gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence gpio_init is a postcore_initcall.
+ */
+#ifdef CONFIG_ARCH_OMAP2
+static int __init omap24xx_gpio_init(void)
+{ if (!cpu_is_omap24xx())
+ return -EINVAL;
+
+ return gpio_init(METHOD_GPIO_24XX);
+}
+postcore_initcall(omap24xx_gpio_init);
+#endif
+
--
To unsubscribe from this list: send the line unsubscribe 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 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com;
a...@linux-foundation.org; linux-
o...@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com;
Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS
chip GPIO init
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS
chip
GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha Vch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver
(eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this should not be moved
to hwmod dev_attr because
this is only an info required for the driver to identify the chip ID and
accordingly access
functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete
cleanup.
What does 'method' mean in that context? Maybe the name should be revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed
once the whole GPIO code is cleaned up. This patch series doesn't bother to
clean up GPIO code as the
changes would be huge and intended only for HWMOD FW adaptation. Cleaning up
GPIO code would come as
a separate series and we can address this then.
Sorry if my comment is not aligned but I thought we are addressing the
gpio clean up as well.
If we are re-vamping the code so much, is it not the right time to clean up as
well ??
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe 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: Alternative for defconfig
* Felipe Contreras felipe.contre...@gmail.com [100611 19:03]: On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Huh? I thought he was only threatening to remove them[1]. I don't think he said he was going to do that without any alternative in place. My suggestion[2] was to have minimal defconfigs so that we could do $ cp arch/arm/configs/omap3_beagle_baseconfig .config $ echo | make ARCH=arm oldconfig [1] http://article.gmane.org/gmane.linux.kernel/994194 [2] http://article.gmane.org/gmane.linux.kernel/995412 Sounds like the defconfigs will be going though and we'll use some Kconfig based system that's still open. I believe Russell said he is not taking any more defconfig patches, so we should not merge them either. Anyways, we already have multi-omap mostly working for both mach-omap1 and mach-omap2. So the remaining things to do are: 1. For mach-omap1, patch entry-macro.S to allow compiling in 7xx, 15xx and 16xx. This can be done in a similar way as for mach-omap2. The only issue is how to detect 7xx from other mach-omap1 omaps. If anybody has a chance to work on this, please go for it! 2. The old omap_cfg_reg mux function needs to disappear for mach-omap2 and use the new mux code instead. I'm currently working on this and should have it ready for testing this week. 3. To boot both ARMv6 and 7, we need to get rid of CONFIG_HAS_TLS_REG. I already have a patch for that, I'll try to update that during this week. 4. To make CONFIG_VFP work for both ARMv6 and 7, we need to fix CONFIG_VFPv3 so it boots on ARMv6 too. It currently oopses. Will take a look at this after I'm done with the CONFIG_HAS_TLS_REG. This is another one where some help would be nice. To reproduce, boot Linux on ARMv6 with CONFIG_VFPv3 set. 5. After all this works, we can participate on building in multiple ARM platforms :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDHC card affected by preemption model in 2.6.35
Mathieu Poirier mathieu.poir...@canonical.com wrote: On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: HW: Beagleboard rev. C2 and C4 Processor: OMAP3 Kernel: 2.6.35-rc2 Driver: mmci-omap-hs I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY. When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. When booting, a failing card (PREEMPT_VOLUNTARY) will output the following: [ 2.283355] mmc0: error -110 whilst initialising SD card I have also seen transfer errors such as this one: [ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr 26, card status 0xc00 When working properly (PREEMPT_NONE), you get: [ 27.026519] mmc0: new high speed SDHC card at address 0007 [ 27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB We seem to have a little timing problem - has anyone seen the same issue ? Can driver mmci-omap-hs actually work under PREEMPT_VOLUNTARY ? Thanks, Mathieu. I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful. Thanks, Venkat. Venkat, Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console. As for the cards, had failures with 3 different manufacturer: - Patriot Memory, MicroSD card, 8GB, class 4, SDHC. - Kinston, 4GB, class 6, SDHC. - Sandisk, 4GB, Class 2, SDHC. I am more than willing to test kernels for you if need be. Thanks, Mathieu. For MMC/SD logs to be sent to the console, you need to a) echo 8 /proc/sys/kernel/printk in the shell and b) insert the card If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG) Apologies - I should have explained this initially. Regards, Venkat. -- To unsubscribe from this list: send the line unsubscribe 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: Serial console not working after waking up from sleep
Hi, On Wed, Jun 16, 2010 at 08:09, Michael Trimarchi mich...@panicking.kicks-ass.org wrote: Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform smsc911x.0: LATE suspend platform musb_hdrc: LATE suspend platform omap2-nand: LATE suspend serial8250 serial8250.2: LATE suspend, may wakeup serial8250 serial8250.1: LATE suspend, may wakeup serial8250 serial8250.0: LATE suspend, may wakeup platform overo_lcd: LATE suspend i2c_omap i2c_omap.3: LATE suspend i2c_omap i2c_omap.1: LATE suspend PM: late suspend of devices complete after 103.088 msecs Successfully put all powerdomains to target state i2c_omap i2c_omap.1: EARLY resume i2c_omap i2c_omap.3: EARLY resume platform overo_lcd: EARLY resume serial8250 serial8250.0: EARLY resume serial8250 serial8250.1: EARLY resume serial8250 serial8250.2: EARLY resume platform omap2-nand: EARLY resume platform musb_hdrc: EARLY resume platform smsc911x.0: EARLY resume platform smsc911x.1: EARLY resume platform omap2_mcspi.1: EARLY resume platform omap2_mcspi.2: EARLY resume platform omap2_mcspi.3: EARLY resume platform omap2_mcspi.4: EARLY resume arm-pmu arm-pmu.0: EARLY resume platform omap_rng:
RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, June 16, 2010 12:51 PM
To: Varadarajan, Charulatha; Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com; Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org]
On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-
o...@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com;
Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS
chip
GPIO init
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak,
Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS
chip
GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio
APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha Vch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver
(eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this should not be moved
to
hwmod dev_attr because
this is only an info required for the driver to identify the chip ID and
accordingly access
functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete
cleanup.
What does 'method' mean in that context? Maybe the name should be
revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed
once the whole GPIO code is cleaned up. This patch series doesn't bother to
clean up GPIO code as the
changes would be huge and intended only for HWMOD FW adaptation. Cleaning up
GPIO code would come as
a separate series and we can address this then.
Sorry if my comment is not aligned but I thought we are addressing the
Re: [PATCH 10/13 v3] OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 37
+++-
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 20f5f8c..b4c0878 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/gpio.h
#include omap_hwmod_common_data.h
@@ -1272,6 +1273,12 @@ static struct omap_hwmod omap44xx_fdif_hwmod = {
* general purpose io module
*/
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .gpio_bank_count = 6,
Why do you need that information?
The point is that this struct is in theory a per instance data not a
global one. If needed, you should be able to get that from the number of
iteration done during the init of hwmods.
Even though it is possible to get it through number of iterations, more
efficient approach would be to keep this information here. My point is that
this information can be auto-generated and hence it is better to keep it in
hwmod database itself.
It is still a duplication of an information we already have indirectly.
The number of GPIO bank is exactly the number of hwmod gpio instances.
You do not need any other parameters to get that.
FYI, in a meeting we recently had with Kevin, we discussed about global data
information getting duplicated for each instance and it was agreed that it is okay to
have pointers duplicated for each instance.
I'm not OK with that. If we start mixing the pure IP specific
information with the global one it will be a mess, and it will prevent
the easy reuse accross SoC familly.
hwmod structure is an IP information. The number of GPIO is an
integration information that has nothing to do inside the hwmod. If we
want to add an extra instance of GPIO in OMAP4440 for example, we will
not be able to reuse the current 4430 data.
So please, don't do that.
BTW, you didn't answer the first answer, do you really need that?
+ .gpio_bank_bits = 32,
+ .dbck_flag = true,
+};
Since this structure is the same than OMAP3, you should maybe consider
sharing it.
They are in different _data.c files. I feel that it will be good if they are
kept decoupled as we need not have to mix up different SoC data. Here it's only
a coincidence that OMAP3 and OMAP4 have same data
No it is not a coincidence, it is because we are re-using the same IP
implementation. In that case, it is not a big deal, but you should try
to reuse as most as you can already existing data.
Benoit
+
static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1305,7 +1312,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master =omap44xx_l4_wkup_hwmod,
.slave =omap44xx_gpio1_hwmod,
- .clk= l4_wkup_clk_mux_ck,
+ .clk= gpio1_ick,
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1325,7 +1332,7 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.class =omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
- .main_clk = gpio1_ick,
+ .main_clk = NULL,
Removing the line is enough. It will be null by default.
Agreed.
I'm still not 100% sure that this is the good way to control the GPIO
module mode, but at least this is cleaner than the previous clock mapping.
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 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
On 6/16/2010 9:21 AM, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com;
a...@linux-foundation.org; linux-
o...@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com;
Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha Vch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver
(eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this should not be moved to
hwmod dev_attr because
this is only an info required for the driver to identify the chip ID and
accordingly access
functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete cleanup.
What does 'method' mean in that context? Maybe the name should be revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed
once the whole GPIO code is cleaned up. This patch series doesn't bother to
clean up GPIO code as the
changes would be huge and intended only for HWMOD FW adaptation. Cleaning up
GPIO code would come as
a separate series and we can address this then.
Sorry if my comment is not aligned but I thought we are addressing the
gpio clean up as well.
If we are re-vamping the code so much, is it not the right time to clean up as
well ??
I agree with Santosh, you are already cleaning a bunch of things, and in
that case you can easily take advantage of HWMOD to remove a good amount
of useless code.
We'd better do that right now, instead of waiting a next phase that
might never happen...
And BTW, this 'method' is a IP version dependent information and not a
Soc specific one. You can potentially use the HW revision field, if it
is available for the GPIO.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/14] omap: mailbox: bunch of cleanups
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v4 00/14] omap: mailbox: bunch of cleanups Date: Fri, 11 Jun 2010 17:51:35 +0200 From: Felipe Contreras --global Hi, These are hopefully non-functional changes. Just shuffling code around, and removing unecessary stuff. This v4 includes minor changes suggested by Felipe Balbi, Hiroshi, and Russell. Comments from Felipe Balbi, Tony Lindgren, Hiroshi DOYU, and Russell King. Applied against: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox Only [PATCH 1/14] isn't used since the original patch is correct but messed up at applying just in my branch. -- To unsubscribe from this list: send the line unsubscribe 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] omap4: Fix multi-omap boot with reset un-used clocks
On Mon, 31 May 2010, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [100520 02:05]: Hi, On Wed, 19 May 2010, Santosh Shilimkar wrote: This patch uses ENABLE_ON_INIT flag on the emif clock nodes to avoid the emif clk getting cut as part of reset un-used clock routine which prevents boot. Since omap4 omap2_clk_init() calls clk_enable_init_clocks() which increases the usecount on all ENABLE_ON_INIT clocks, it prevents omap2_clk_disable_unused() from disabling the clock. The real fix is to have driver for EMIF and do clock get/enable as part of it. The EMIF driver is planned to be done HWMOD way so till that available to keep omap3_defconfig booting on OMAP4430, this patch is necessary. (Will updated the auto-gen script for 44xx accordingly) The fix was suggested by Paul Walmsley Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, I've added Nishanth's Tested-by: and fixed the patch changelog; the following patch is now queued for 2.6.35-rc, unless there are any further comments. FYI, I'll also added this into omap-testing branch while we're waiting for your clock fixes branch to be available. Acked-by: Paul Walmsley p...@pwsan.com Feel free to send this one upstream separately if you like, until the clock -rc series is ready. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
On 6/16/2010 10:46 AM, Varadarajan, Charulatha wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, June 16, 2010 12:51 PM
To: Varadarajan, Charulatha; Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com; Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org]
On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-
o...@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com;
Basak, Partha
Subject: RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
khil...@deeprootsystems.com; t...@atomide.com
Subject: Re: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip
GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha Vch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver
(eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this should not be moved to
hwmod dev_attr because
this is only an info required for the driver to identify the chip ID and
accordingly access
functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete cleanup.
What does 'method' mean in that context? Maybe the name should be revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed
once the whole GPIO code is cleaned up. This patch series doesn't bother to
clean up GPIO code as the
changes would be huge and intended only for HWMOD FW adaptation. Cleaning up
GPIO code would come as
a separate series and we can address this then.
Sorry if my comment is not aligned but I thought we are addressing the
gpio clean up as well.
If we are re-vamping the code so much, is it not the right time to clean up as
well ??
We are not addressing GPIO code clean up in this series. As you mentioned, we
are revamping the code so much just for doing HWMOD FW adaptation. If we
attempt to clean up the whole GPIO code along with this,
[RFC] DSS2: Need to make dsi, sdi, rfbi as platform drivers instead of a library in omapdss driver
Hi, When I started with RFC patch DSS: Movement of base addr, silicon specific data from driver to platform_device, I see a lot of encapsulation of OMAP DSS IPs into the omapdss driver. The previous RFC patch would only be good enough to handle base address and IRQ for multi-omap. But it won't address the PRCM power management handled in HWMOD APIs. The encapsulation of all the DSS IPs like RFBI, DSI, SDI, VENC into omapdss driver would prevent these drivers being handled from the platform database. For Eg: HWMOD adaptation to DSS would not be possible unless these libraries are made as platform drivers. HWMOD would provide dynamic usage of multi-omap data like base addr,irq. HWMOD would also manage the PRCM clocks needed for the dss. I would make an RFC patch by introducing these IPs as platform drivers which would comply and ease for HWMOD adpatation. Before I go ahead make the changes in the code, I would like to get opinions on this proposed changes. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Proposed change: Omapdss platform driver - initialises necessary Ips dss, dispc. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registerd to the custom bus. Dsi platform driver - initialises DSI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. SDI platform driver - initialises SDI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. RFBI platform driver - initialises RFBI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. DPI platform driver - initialises DPI IP - should also take care of dsi pll inits from the dsi platform driver. - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. Regards, Senthil-- To unsubscribe from this list: send the line unsubscribe 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] DSS2: Need to make dsi, sdi, rfbi as platform drivers instead of a library in omapdss driver
On Wed, 2010-06-16 at 12:52 +0200, ext Guruswamy, Senthilvadivu wrote: Hi, When I started with RFC patch DSS: Movement of base addr, silicon specific data from driver to platform_device, I see a lot of encapsulation of OMAP DSS IPs into the omapdss driver. The previous RFC patch would only be good enough to handle base address and IRQ for multi-omap. But it won't address the PRCM power management handled in HWMOD APIs. The encapsulation of all the DSS IPs like RFBI, DSI, SDI, VENC into omapdss driver would prevent these drivers being handled from the platform database. For Eg: HWMOD adaptation to DSS would not be possible unless these libraries are made as platform drivers. HWMOD would provide dynamic usage of multi-omap data like base addr,irq. HWMOD would also manage the PRCM clocks needed for the dss. I would make an RFC patch by introducing these IPs as platform drivers which would comply and ease for HWMOD adpatation. Before I go ahead make the changes in the code, I would like to get opinions on this proposed changes. I haven't looked at how HWMODs work, but I don't see any downsides to having the DSS HW modules as platform devices, if that is required. But the interface modules (DSI/DPI/RFBI/SDI) will still be tightly connected to the core DSS module, even if they are separate drivers. I'm not sure what complexities this may bring. This also raises the question that should the interface modules each have a bus of their own? This is something I've pondered for a long time, and sounds to me to be a cleaner architecture, but it may be a bigger change. 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
[PATCH v3 0/8] nand support on omap3 boards
The following set of patches applies on top of for-next branch. And these are the patches required to enable nand (nor and onenand for sdp only) for different platform. v3: patch rebase on latest nand patch and depend on - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html v2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26479.html rework to use full nand in partition table of ZOOM2/3; ZOOM1(LDP)support added. v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg22205.html Sukumar Ghorai (8): omap3 flash: rename board-sdp-flash.c to be use by other boards omap3: add support for NAND on zoom2 board omap3: add support for NAND on zoom3 board omap-3630-sdp : Add support for Flash omap-3630-sdp: enable Flash device support omap3: add support for NAND on LDP board zoom2: enable NAND support zoom3: enable NAND support arch/arm/configs/omap_3630sdp_defconfig | 31 +++- arch/arm/configs/omap_zoom2_defconfig| 24 +++- arch/arm/configs/omap_zoom3_defconfig| 24 +++- arch/arm/mach-omap2/Makefile |6 +- arch/arm/mach-omap2/board-3430sdp.c | 16 ++- arch/arm/mach-omap2/board-3630sdp.c | 120 arch/arm/mach-omap2/board-ldp.c | 35 arch/arm/mach-omap2/board-flash.c| 253 ++ arch/arm/mach-omap2/board-sdp-flash.c| 267 -- arch/arm/mach-omap2/board-zoom2.c| 49 + arch/arm/mach-omap2/board-zoom3.c| 48 + arch/arm/mach-omap2/include/mach/board-flash.h | 28 +++ arch/arm/mach-omap2/include/mach/board-sdp.h | 21 -- 11 files changed, 628 insertions(+), 294 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards
rename board-sdp-flash.c(board-flash.c) and board-sdp.h(board-flash.h) to
used by other board e.g. zoom
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/board-3430sdp.c| 16 ++-
arch/arm/mach-omap2/board-flash.c | 253 ++
arch/arm/mach-omap2/board-sdp-flash.c | 267
arch/arm/mach-omap2/include/mach/board-flash.h | 28 +++
arch/arm/mach-omap2/include/mach/board-sdp.h | 21 --
6 files changed, 296 insertions(+), 291 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-flash.c
delete mode 100755 arch/arm/mach-omap2/board-sdp-flash.c
create mode 100644 arch/arm/mach-omap2/include/mach/board-flash.h
delete mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6c6d7c6..0d854f1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -117,7 +117,7 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
hsmmc.o \
- board-sdp-flash.o
+ board-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f474a80..4b8595b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,7 +41,7 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
-#include mach/board-sdp.h
+#include mach/board-flash.h
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
@@ -667,6 +667,18 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+/*
+ * SDP3430 V2 Board CS organization
+ * Different from SDP3430 V1. Now 4 switches used to specify CS
+ *
+ * See also the Switch S8 settings in the comments.
+ */
+static char chip_sel_3430[][GPMC_CS_NUM] = {
+ {PDC_NOR, PDC_NAND, PDC_ONENAND, DBG_MPDB, 0, 0, 0, 0}, /* S8: */
+ {PDC_ONENAND, PDC_NAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1110 */
+ {PDC_NAND, PDC_ONENAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1101 */
+};
+
static struct mtd_partition sdp_nor_partitions[] = {
/* bootloader (U-Boot, etc) in first sector */
{
@@ -797,7 +809,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_smc91x_init();
- sdp_flash_init(sdp_flash_partitions);
+ board_flash_init(sdp_flash_partitions, chip_sel_3430);
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
new file mode 100755
index 000..ac834aa
--- /dev/null
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -0,0 +1,253 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.h
+#include mach/board-flash.h
+
+#define REG_FPGA_REV 0x10
+#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
+#define MAX_SUPPORTED_GPMC_CONFIG 3
+
+#define DEBUG_BASE 0x0800 /* debug board */
+
+/* various memory sizes */
+#define FLASH_SIZE_SDPV1 SZ_64M /* NOR flash (64 Meg aligned) */
+#define FLASH_SIZE_SDPV2 SZ_128M /* NOR flash (256 Meg aligned) */
+
+static struct physmap_flash_data board_nor_data = {
+ .width = 2,
+};
+
+static struct resource board_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device board_nor_device = {
+ .name = physmap-flash,
+ .id = 0,
+ .dev= {
+ .platform_data = board_nor_data,
+ },
+ .num_resources = 1,
+ .resource = board_nor_resource,
+};
+
+static void
+__init board_nor_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
+{
+ int err;
+
+ board_nor_data.parts= nor_parts;
+ board_nor_data.nr_parts = nr_parts;
+
+ /* Configure start address and size of NOR device */
+ if
[PATCH v3 7/8] zoom2: enable NAND support
update config file to support for NAND in zoom2. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/configs/omap_zoom2_defconfig | 24 +++- 1 files changed, 23 insertions(+), 1 deletions(-) arch/arm/configs/omap_zoom2_defconfig diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index 881faea..ec58688 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -440,7 +440,22 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y -# CONFIG_MTD is not set +CONFIG_MTD=y +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_OMAP_PREFETCH=y +CONFIG_MTD_NAND_IDS=y # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -1248,6 +1263,13 @@ CONFIG_MISC_FILESYSTEMS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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 v3 5/8] omap3: add support for NAND on LDP board
patch adds NAND support to LDP board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-ldp.c | 35 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6c67126..af715fa 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE) +=
board-omap3beagle.o \
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+ board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index fefd7e6..778afab 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -38,6 +38,7 @@
#include plat/board.h
#include plat/common.h
#include plat/gpmc.h
+#include mach/board-zoom.h
#include asm/delay.h
#include plat/control.h
@@ -388,6 +389,38 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static struct mtd_partition ldp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = File System - NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = MTDPART_SIZ_FULL, /* 96MB, 0x600 */
+ },
+
+};
+
static void __init omap_ldp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -400,6 +433,8 @@ static void __init omap_ldp_init(void)
ads7846_dev_init();
omap_serial_init();
usb_musb_init(musb_board_data);
+ board_nand_init(ldp_nand_partitions,
+ ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS);
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
--
To unsubscribe from this list: send the line unsubscribe 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 v3 8/8] zoom3: enable NAND support
update config file to support for NAND on zoom3 board. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/configs/omap_zoom3_defconfig | 24 +++- 1 files changed, 23 insertions(+), 1 deletions(-) arch/arm/configs/omap_zoom3_defconfig diff --git a/arch/arm/configs/omap_zoom3_defconfig b/arch/arm/configs/omap_zoom3_defconfig index 5e55b55..e3e53cd --- a/arch/arm/configs/omap_zoom3_defconfig +++ b/arch/arm/configs/omap_zoom3_defconfig @@ -461,7 +461,22 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y -# CONFIG_MTD is not set +CONFIG_MTD=y +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_OMAP_PREFETCH=y +CONFIG_MTD_NAND_IDS=y # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -1311,6 +1326,13 @@ CONFIG_MISC_FILESYSTEMS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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 v3 6/8] omap-3630-sdp: enable Flash device support
update config file to support for NAND, OneNAND, NOR on omap 3630-sdp board. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/configs/omap_3630sdp_defconfig | 31 ++- 1 files changed, 30 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_3630sdp_defconfig b/arch/arm/configs/omap_3630sdp_defconfig index 609f348..8c75c19 --- a/arch/arm/configs/omap_3630sdp_defconfig +++ b/arch/arm/configs/omap_3630sdp_defconfig @@ -461,7 +461,29 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y -# CONFIG_MTD is not set +CONFIG_MTD=y +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_OMAP_PREFETCH=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_ONENAND=y +CONFIG_MTD_ONENAND_OMAP2=y # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -1310,6 +1332,13 @@ CONFIG_MISC_FILESYSTEMS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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 v3 4/8] omap-3630-sdp : Add support for Flash
add support for NAND, OneNAND, NOR on omap 3630-sdp board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-3630sdp.c | 120 +++
2 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a795eb6..400f9cf
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -133,6 +133,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) +=
board-zoom3.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
+ board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 504d2bd..a3f24cb
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -22,6 +22,7 @@
#include plat/usb.h
#include mach/board-zoom.h
+#include mach/board-flash.h
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
@@ -93,12 +94,131 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+/*
+ * SDP3630 CS organization
+ * See also the Switch S8 settings in the comments.
+ */
+static char chip_sel_sdp[][GPMC_CS_NUM] = {
+ {PDC_NOR, PDC_NAND, PDC_ONENAND, DBG_MPDB, 0, 0, 0, 0}, /* S8: */
+ {PDC_ONENAND, PDC_NAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1110 */
+ {PDC_NAND, PDC_ONENAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1101 */
+};
+
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 40 * (64 * 2048),
+ },
+
[PATCH v3 3/8] omap3: add support for NAND on zoom3 board
patch adds NAND support to zoom3 board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 43 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e7159b0..00f4cfd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2) +=
board-zoom2.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
+ board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..692c6c6 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -34,6 +34,47 @@ static void __init omap_zoom_map_io(void)
static struct omap_board_config_kernel zoom_config[] __initdata = {
};
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 3328 * (64 * 2048), /* 416M, 0x1A00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1C00*/
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1E00*/
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
@@ -66,6 +107,8 @@ static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
+ board_nand_init(zoom_nand_partitions,
+ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
--
To unsubscribe from this list: send the line unsubscribe 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 v3 2/8] omap3: add support for NAND on zoom2 board
This patch adds NAND support to ZOOM2 board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom2.c | 43 +
arch/arm/mach-omap2/include/mach/board-zoom.h |6 +++
3 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0d854f1..e7159b0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -126,6 +126,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
+ board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 803ef14..549f274 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -77,10 +77,53 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 3328 * (64 * 2048), /* 416M, 0x1A00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1C00*/
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1E00*/
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
static void __init omap_zoom2_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
zoom_peripherals_init();
+ board_nand_init(zoom_nand_partitions,
+ ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
}
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..3af69d2 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -1,5 +1,11 @@
/*
* Defines for zoom boards
*/
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#define ZOOM_NAND_CS0
+
+extern void __init board_nand_init(struct mtd_partition *, u8 nr_parts, u8 cs);
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP DSS fixes for 2.6.35-rc4
Hi Linus, Please pull these two fixes for the OMAP framebuffer driver. Tomi The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linus Torvalds (1): Linux 2.6.35-rc1 are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Janusz Krzysztofik (1): OMAPFB: LCDC: change update_mode to DISABLED when going suspend Tomi Valkeinen (1): OMAP: OMAPFB: fix rfbi.c compile error drivers/video/omap/lcdc.c | 14 ++ drivers/video/omap/rfbi.c |5 +++-- 2 files changed, 5 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 0/5 v2] Serial HWMOD updation and uart4 support for 3630
Changes from v1: * Incorporated : OMAP clock: Add uart4_ick/fck definitions for 3630 * using omap_mux_request_signal to retreive padconf offset as per Tony's comments. http://marc.info/?l=linux-omapm=127609369220618w=2 This patch series as a dependecy on the patch for omap_mux_request_signal posted earlier https://patchwork.kernel.org/patch/105962/ * Clean up certain comments. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30348.html Patch series is based on remotes/origin/pm-wip/uart branch from Kevin's PM tree. 1.) Add support for UART4 for 3630. 2.) Modify Serial hwmod to avoid hwmod lookup using name string. Govindraj.R (5): OMAP clock: Add uart4_ick/fck definitions for 3630 OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs OMAP3: serial: Fix uart4 handling for 3630 OMAP3: PM: Add prepare idle and resume idle call for uart4 Serial: Avoid using hwmod lookup using name string. arch/arm/mach-omap2/clock3xxx_data.c | 22 ++ arch/arm/mach-omap2/cm-regbits-34xx.h |2 + arch/arm/mach-omap2/pm34xx.c | 17 - arch/arm/mach-omap2/prcm-common.h |2 + arch/arm/mach-omap2/prm-regbits-34xx.h |1 + arch/arm/mach-omap2/serial.c | 114 +++- 6 files changed, 111 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 1/5 v2] OMAP clock: Add uart4_ick/fck definitions for 3630
Add uart4 clock data.
This is only valid for omap 36xx family of chips.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 41b155a..581c378 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -2465,6 +2465,16 @@ static struct clk uart3_fck = {
.recalc = followparent_recalc,
};
+static struct clk uart4_fck = {
+ .name = uart4_fck,
+ .ops= clkops_omap2_dflt_wait,
+ .parent = per_48m_fck,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = per_clkdm,
+ .recalc = followparent_recalc,
+};
+
static struct clk gpt2_fck = {
.name = gpt2_fck,
.ops= clkops_omap2_dflt_wait,
@@ -2715,6 +2725,16 @@ static struct clk uart3_ick = {
.recalc = followparent_recalc,
};
+static struct clk uart4_ick = {
+ .name = uart4_ick,
+ .ops= clkops_omap2_dflt_wait,
+ .parent = per_l4_ick,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_ICLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = per_clkdm,
+ .recalc = followparent_recalc,
+};
+
static struct clk gpt9_ick = {
.name = gpt9_ick,
.ops= clkops_omap2_dflt_wait,
@@ -3344,6 +3364,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, per_96m_fck, per_96m_fck, CK_3XXX),
CLK(NULL, per_48m_fck, per_48m_fck, CK_3XXX),
CLK(NULL, uart3_fck,uart3_fck, CK_3XXX),
+ CLK(NULL, uart4_fck,uart4_fck, CK_36XX),
CLK(NULL, gpt2_fck, gpt2_fck, CK_3XXX),
CLK(NULL, gpt3_fck, gpt3_fck, CK_3XXX),
CLK(NULL, gpt4_fck, gpt4_fck, CK_3XXX),
@@ -3367,6 +3388,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, gpio2_ick,gpio2_ick, CK_3XXX),
CLK(NULL, wdt3_ick, wdt3_ick, CK_3XXX),
CLK(NULL, uart3_ick,uart3_ick, CK_3XXX),
+ CLK(NULL, uart4_ick,uart4_ick, CK_36XX),
CLK(NULL, gpt9_ick, gpt9_ick, CK_3XXX),
CLK(NULL, gpt8_ick, gpt8_ick, CK_3XXX),
CLK(NULL, gpt7_ick, gpt7_ick, CK_3XXX),
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 2/5 v2] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
To standarize among other uarts (1 to 3), we shall now:
- Enable uart4 autodile bit.
- Enable uart4 wakeup in PER.
- Allow uart4 to wakeup the MPU.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/pm34xx.c | 15 +--
arch/arm/mach-omap2/prcm-common.h |2 ++
arch/arm/mach-omap2/prm-regbits-34xx.h |1 +
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index fe82b79..4f959a7 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -649,6 +649,8 @@
#define OMAP3430_ST_MCBSP2_MASK(1 0)
/* CM_AUTOIDLE_PER */
+#define OMAP3630_AUTO_UART4_MASK (1 18)
+#define OMAP3630_AUTO_UART4_SHIFT 18
#define OMAP3430_AUTO_GPIO6_MASK (1 17)
#define OMAP3430_AUTO_GPIO6_SHIFT 17
#define OMAP3430_AUTO_GPIO5_MASK (1 16)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2e96771..a120d4f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -753,6 +753,14 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 omap3630_auto_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_AUTO_UART4_MASK : 0;
+ u32 omap3630_en_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_EN_UART4_MASK : 0;
+ u32 omap3630_grpsel_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_GRPSEL_UART4_MASK : 0;
+
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
@@ -839,6 +847,7 @@ static void __init prcm_setup_regs(void)
CM_AUTOIDLE);
cm_write_mod_reg(
+ omap3630_auto_uart4_mask |
OMAP3430_AUTO_GPIO6_MASK |
OMAP3430_AUTO_GPIO5_MASK |
OMAP3430_AUTO_GPIO4_MASK |
@@ -915,14 +924,16 @@ static void __init prcm_setup_regs(void)
OMAP3430_DSS_MOD, PM_WKEN);
/* Enable wakeups in PER */
- prm_write_mod_reg(OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
+ prm_write_mod_reg(omap3630_en_uart4_mask |
+ OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
OMAP3430_EN_GPIO4_MASK | OMAP3430_EN_GPIO5_MASK |
OMAP3430_EN_GPIO6_MASK | OMAP3430_EN_UART3_MASK |
OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
OMAP3430_EN_MCBSP4_MASK,
OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
- prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2_MASK |
+ prm_write_mod_reg(omap3630_grpsel_uart4_mask |
+ OMAP3430_GRPSEL_GPIO2_MASK |
OMAP3430_GRPSEL_GPIO3_MASK |
OMAP3430_GRPSEL_GPIO4_MASK |
OMAP3430_GRPSEL_GPIO5_MASK |
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 86edcf9..298a22a 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -425,6 +425,8 @@
#define OMAP3430_EN_MCBSP2_SHIFT 0
/* CM_IDLEST_PER, PM_WKST_PER shared bits */
+#define OMAP3630_ST_UART4_SHIFT18
+#define OMAP3630_ST_UART4_MASK (1 18)
#define OMAP3430_ST_GPIO6_SHIFT17
#define OMAP3430_ST_GPIO6_MASK (1 17)
#define OMAP3430_ST_GPIO5_SHIFT16
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 7fd6023..9e63cb7 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -122,6 +122,7 @@
#define OMAP3430_MEMRETSTATE_MASK (1 8)
/* PM_MPUGRPSEL_PER, PM_IVA2GRPSEL_PER shared bits */
+#define OMAP3630_GRPSEL_UART4_MASK (1 18)
#define OMAP3430_GRPSEL_GPIO6_MASK (1 17)
#define OMAP3430_GRPSEL_GPIO5_MASK (1 16)
#define OMAP3430_GRPSEL_GPIO4_MASK (1 15)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Muxmode usage needed for uart4 for 3630, for padconf
wakeup on uart4_rx line. uart4_rx signal is available
under mode-2 in gpmc_wait3. Thus have to ensure we are
in right mux mode before accesing any padconf register.
So ensure right mux mode for uarti padconf access.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 43 +
1 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index da9fee6..128e19b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -42,6 +42,7 @@
#include prm.h
#include pm.h
#include cm.h
+#include mux.h
#include prm-regbits-34xx.h
#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
@@ -68,6 +69,7 @@ struct omap_uart_state {
u32 wk_mask;
u32 padconf;
u32 dma_enabled;
+ u16 muxmode;
struct clk *ick;
struct clk *fck;
@@ -229,8 +231,20 @@ static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
omap_device_idle(uart-pdev);
}
+static inline void omap_uart_set_muxmode(struct omap_uart_state *uart)
+{
+ u16 w = omap_ctrl_readw(uart-padconf);
+
+ w = ~0x7;
+ w |= uart-muxmode;
+ omap_ctrl_writew(w, uart-padconf);
+}
+
static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
{
+ if (uart-muxmode uart-padconf)
+ omap_uart_set_muxmode(uart);
+
/* Set wake-enable bit */
if (uart-wk_en uart-wk_mask) {
u32 v = __raw_readl(uart-wk_en);
@@ -248,6 +262,9 @@ static void omap_uart_enable_wakeup(struct omap_uart_state
*uart)
static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
{
+ if (uart-muxmode uart-padconf)
+ omap_uart_set_muxmode(uart);
+
/* Clear wake-enable bit */
if (uart-wk_en uart-wk_mask) {
u32 v = __raw_readl(uart-wk_en);
@@ -338,6 +355,9 @@ void omap_uart_resume_idle(int num)
if (num == uart-num) {
omap_uart_enable_clocks(uart);
+ if (uart-muxmode uart-padconf)
+ omap_uart_set_muxmode(uart);
+
/* Check for IO pad wakeup */
if (cpu_is_omap34xx() uart-padconf) {
u16 p = omap_ctrl_readw(uart-padconf);
@@ -416,28 +436,41 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 0);
if (cpu_is_omap34xx()) {
- u32 mod = (uart-num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+ u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
- u32 padconf = 0;
+ u16 padconf = 0;
+ u16 muxmode = 0;
uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
uart-wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1);
switch (uart-num) {
case 0:
wk_mask = OMAP3430_ST_UART1_MASK;
- padconf = 0x182;
+ padconf = omap_mux_request_signal(uart1_rx);
break;
case 1:
wk_mask = OMAP3430_ST_UART2_MASK;
- padconf = 0x17a;
+ padconf = omap_mux_request_signal(uart2_rx);
break;
case 2:
wk_mask = OMAP3430_ST_UART3_MASK;
- padconf = 0x19e;
+ padconf = omap_mux_request_signal(uart3_rx_irrx);
+ break;
+ case 3:
+ wk_mask = OMAP3630_ST_UART4_MASK;
+ /**
+* get uart4_rx mux pin offset.
+* uart4_rx signal is available in gpmc_wait3
+* in mux_mode 2. Refer to OMAP36XX TRM and
+* /mach-omap2/mux34xx.c file for further details.
+*/
+ padconf = omap_mux_request_signal(gpmc_wait3);
+ muxmode = OMAP_MUX_MODE2;
break;
}
uart-wk_mask = wk_mask;
uart-padconf = padconf;
+ uart-muxmode = muxmode;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 4/5 v2] OMAP3: PM: Add prepare idle and resume idle call for uart4
Add prepare idle and resume idle call for uart4 used by 3630.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a120d4f..50c20a2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -394,6 +394,7 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
+ omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF) {
if (core_next_state == PWRDM_POWER_ON) {
@@ -474,6 +475,7 @@ void omap_sram_idle(void)
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
omap_uart_resume_idle(2);
+ omap_uart_resume_idle(3);
if (per_state_modified)
pwrdm_set_next_pwrst(per_pwrdm, PWRDM_POWER_OFF);
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[pm-wip/uart][PATCH 5/5 v2] Serial: Avoid using hwmod lookup using name string
Avoid using hwmod lookup using name string rather
retreive port info using the hwmod class interface.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 ++---
1 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 128e19b..0380ac8 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,8 +56,6 @@
*/
#define DEFAULT_TIMEOUT 0
-#define MAX_UART_HWMOD_NAME_LEN16
-
struct omap_uart_state {
int num;
int can_sleep;
@@ -601,52 +599,45 @@ static void serial_out_override(struct uart_port *up, int
offset, int value)
}
#endif
-void __init omap_serial_early_init(void)
+static int omap_serial_port_init(struct omap_hwmod *oh, void *user)
{
- int i = 0;
+ struct omap_uart_state *uart;
+ static int i;
- do {
- char oh_name[MAX_UART_HWMOD_NAME_LEN];
- struct omap_hwmod *oh;
- struct omap_uart_state *uart;
+ uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
+ if (WARN_ON(!uart))
+ return -ENOMEM;
- snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
-uart%d, i + 1);
- oh = omap_hwmod_lookup(oh_name);
- if (!oh)
- break;
+ uart-oh = oh;
+ uart-num = i++;
+ list_add_tail(uart-node, uart_list);
+ num_uarts++;
- uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
- if (WARN_ON(!uart))
- return;
+ /*
+* During UART early init, device need to be probed
+* to determine SoC specific init before omap_device
+* is ready. Therefore, don't allow idle here
+*/
- uart-oh = oh;
- uart-num = i++;
- list_add_tail(uart-node, uart_list);
- num_uarts++;
+ uart-oh-flags |= HWMOD_INIT_NO_IDLE;
- /*
-* NOTE: omap_hwmod_init() has not yet been called,
-* so no hwmod functions will work yet.
-*/
+ /*
+* Since UART hwmod is idle/enabled inside the
+* idle loop, interrupts are already disabled and
+* thus no locking is needed. Since the mutex-based
+* locking in hwmod might sleep, allowing locking
+* may introduce problems.
+*/
- /*
-* During UART early init, device need to be probed
-* to determine SoC specific init before omap_device
-* is ready. Therefore, don't allow idle here
-*/
- uart-oh-flags |= HWMOD_INIT_NO_IDLE;
-
- /*
-* Since UART hwmod is idle/enabled inside the
-* idle loop, interrupts are already disabled and
-* thus no locking is needed. Since the mutex-based
-* locking in hwmod might sleep, allowing locking
-* may introduce problems.
-*/
- uart-oh-flags |= HWMOD_NO_IDLE_LOCKING;
+ uart-oh-flags |= HWMOD_NO_IDLE_LOCKING;
- } while (1);
+ return 0;
+}
+
+void __init omap_serial_early_init(void)
+{
+ omap_hwmod_for_each_by_class(uart,
+ omap_serial_port_init, NULL);
}
/**
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: DSS2: Switching GFX from LCD to TV
From 53711271c3f22c8038f4961a9f9c2035b3e82d7f Mon Sep 17 00:00:00 2001
From: Sujeet Baranwal s-baran...@ti.com
Date: Tue, 1 Jun 2010 19:29:24 +0530
Subject: [PATCH] OMAP: DSS2: Switching GFX from LCD to TV
1. Added a sysfs entry for setting overlay input_size
in order to switch the GFX pipeline from LCD to TV.
2. the following sysfx entry has been added
echo width,height /sys/devices/platform/omapdss/overlay0/input_size
Signed-off-by: Srinivas Pulukuru srinivas.puluk...@ti.com
Signed-off-by: Sujeet Baranwal s-baran...@ti.com
Acked-by: Axel Castaneda x0055...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
---
drivers/video/omap2/dss/overlay.c| 33 +-
drivers/video/omap2/omapfb/omapfb-main.c |7 ++
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 8233658..4e9966f 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -117,6 +117,36 @@ static ssize_t overlay_input_size_show(struct omap_overlay
*ovl, char *buf)
ovl-info.width, ovl-info.height);
}
+static ssize_t overlay_input_size_store(struct omap_overlay *ovl,
+ const char *buf, size_t size)
+{
+ int r;
+ char *last;
+ struct omap_overlay_info info;
+
+ ovl-get_overlay_info(ovl, info);
+
+ info.width = simple_strtoul(buf, last, 10);
+ ++last;
+ if (last - buf = size)
+ return -EINVAL;
+
+ info.height = simple_strtoul(last, last, 10);
+
+ r = ovl-set_overlay_info(ovl, info);
+ if (r)
+ return r;
+
+ if (ovl-manager) {
+ r = ovl-manager-apply(ovl-manager);
+ if (r)
+ return r;
+ }
+
+ return size;
+}
+
+
static ssize_t overlay_screen_width_show(struct omap_overlay *ovl, char *buf)
{
return snprintf(buf, PAGE_SIZE, %d\n, ovl-info.screen_width);
@@ -268,7 +298,8 @@ struct overlay_attribute {
static OVERLAY_ATTR(name, S_IRUGO, overlay_name_show, NULL);
static OVERLAY_ATTR(manager, S_IRUGO|S_IWUSR,
overlay_manager_show, overlay_manager_store);
-static OVERLAY_ATTR(input_size, S_IRUGO, overlay_input_size_show, NULL);
+static OVERLAY_ATTR(input_size, S_IRUGO|S_IWUSR,
+ overlay_input_size_show, overlay_input_size_store);
static OVERLAY_ATTR(screen_width, S_IRUGO, overlay_screen_width_show, NULL);
static OVERLAY_ATTR(position, S_IRUGO|S_IWUSR,
overlay_position_show, overlay_position_store);
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..73ecc9f 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -46,6 +46,8 @@ static char *def_vram;
static int def_vrfb;
static int def_rotate;
static int def_mirror;
+unsigned int omapfb_size;
+module_param_named(fb_size, omapfb_size, int, 0644);
#ifdef DEBUG
unsigned int omapfb_debug;
@@ -1444,6 +1446,11 @@ static int omapfb_alloc_fbmem_display(struct fb_info
*fbi, unsigned long size,
}
}
+ if (omapfb_size){
+ if (omapfb_size size)
+ size = omapfb_size;
+ }
+
if (!size)
return 0;
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial console not working after waking up from sleep
Hi, Jean, Yes I looked at the the OMAP_Power_management page, but the known problem section doesn't seem to describe my problem. What I am encountering is that the serial console does output correctly after resume, but everything goes south after a few lines, thus, the garbage strings... any ideas？ Han On Wed, Jun 16, 2010 at 4:43 AM, Jean Pihet jpi...@mvista.com wrote: Hi, On Wed, Jun 16, 2010 at 08:09, Michael Trimarchi mich...@panicking.kicks-ass.org wrote: Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform smsc911x.0: LATE suspend platform musb_hdrc: LATE suspend platform omap2-nand: LATE suspend serial8250 serial8250.2: LATE suspend, may wakeup serial8250 serial8250.1: LATE suspend, may wakeup serial8250 serial8250.0: LATE suspend, may wakeup platform overo_lcd: LATE suspend i2c_omap i2c_omap.3: LATE suspend i2c_omap i2c_omap.1: LATE suspend PM: late suspend of devices complete after 103.088 msecs Successfully put all powerdomains to target state i2c_omap i2c_omap.1: EARLY resume i2c_omap i2c_omap.3: EARLY resume platform overo_lcd: EARLY resume serial8250 serial8250.0: EARLY resume serial8250 serial8250.1: EARLY
On the APIs for Enabling and Disabling Wakeup capability.
Hello Paul, I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Thanks to clarify. Partha -- To unsubscribe from this list: send the line unsubscribe 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: Serial console not working after waking up from sleep
Hi, michael, I have the no_console_suspend option in my boot command line, I am not sure if that is the option you were trying to point me to in the last email? anyway, I added no_debug_console into my boot command arg, but that doesn't seem to help with my problem. any ideas? Thanks, Han On Wed, Jun 16, 2010 at 2:09 AM, Michael Trimarchi mich...@panicking.kicks-ass.org wrote: Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform smsc911x.0: LATE suspend platform musb_hdrc: LATE suspend platform omap2-nand: LATE suspend serial8250 serial8250.2: LATE suspend, may wakeup serial8250 serial8250.1: LATE suspend, may wakeup serial8250 serial8250.0: LATE suspend, may wakeup platform overo_lcd: LATE suspend i2c_omap i2c_omap.3: LATE suspend i2c_omap i2c_omap.1: LATE suspend PM: late suspend of devices complete after 103.088 msecs Successfully put all powerdomains to target state i2c_omap i2c_omap.1: EARLY resume i2c_omap i2c_omap.3: EARLY resume platform overo_lcd: EARLY resume serial8250 serial8250.0: EARLY resume serial8250 serial8250.1: EARLY resume serial8250 serial8250.2: EARLY resume platform omap2-nand: EARLY resume
Re: Serial console not working after waking up from sleep
Hi Han Wang wrote: Hi, michael, I have the no_console_suspend option in my boot command line, I am not sure if that is the option you were trying to point me to in the last email? I have said that i have no problem when I remove that option. Can you try to echo 0 to timeout of the serial device? Michael anyway, I added no_debug_console into my boot command arg, but that doesn't seem to help with my problem. any ideas? Thanks, Han On Wed, Jun 16, 2010 at 2:09 AM, Michael Trimarchi mich...@panicking.kicks-ass.org wrote: Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform smsc911x.0: LATE suspend platform musb_hdrc: LATE suspend platform omap2-nand: LATE suspend serial8250 serial8250.2: LATE suspend, may wakeup serial8250 serial8250.1: LATE suspend, may wakeup serial8250 serial8250.0: LATE suspend, may wakeup platform overo_lcd: LATE suspend i2c_omap i2c_omap.3: LATE suspend i2c_omap i2c_omap.1: LATE suspend PM: late suspend of devices complete after 103.088 msecs Successfully put all powerdomains to target state i2c_omap i2c_omap.1: EARLY resume i2c_omap i2c_omap.3: EARLY resume platform overo_lcd: EARLY resume serial8250 serial8250.0: EARLY resume serial8250 serial8250.1: EARLY resume serial8250 serial8250.2: EARLY resume platform
RE: On the APIs for Enabling and Disabling Wakeup capability.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Basak, Partha Sent: Wednesday, June 16, 2010 8:10 PM To: p...@pwsan.com Cc: khil...@deeprootsystems.com; Kalliguddi, Hema; Nayak, Rajendra; linux- o...@vger.kernel.org Subject: On the APIs for Enabling and Disabling Wakeup capability. Hello Paul, I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. We also need the API omap_hwmod_set_slave_idlemode to be exposed as an omap_device API. Net-net, the following APIs which are exported in hwmod layer needs to be wrapped under omap_device_layer as well so that drivers can use them: omap_hwmod_enable_wakeup omap_hwmod_disable_wakeup omap_hwmod_set_slave_idlemode These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Thanks to clarify. Partha -- To unsubscribe from this list: send the line unsubscribe 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 10/13 v3] OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 37
+++--
---
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 20f5f8c..b4c0878 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/gpio.h
#include omap_hwmod_common_data.h
@@ -1272,6 +1273,12 @@ static struct omap_hwmod omap44xx_fdif_hwmod = {
* general purpose io module
*/
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .gpio_bank_count = 6,
Why do you need that information?
The point is that this struct is in theory a per instance data not a
global one. If needed, you should be able to get that from the number of
iteration done during the init of hwmods.
Even though it is possible to get it through number of iterations, more
efficient approach would be to keep this information here. My point is that
this
information can be auto-generated and hence it is better to keep it in hwmod
database itself.
It is still a duplication of an information we already have indirectly.
The number of GPIO bank is exactly the number of hwmod gpio instances.
You do not need any other parameters to get that.
FYI, in a meeting we recently had with Kevin, we discussed about global
data
information getting duplicated for each instance and it was agreed that it is
okay
to have pointers duplicated for each instance.
I'm not OK with that. If we start mixing the pure IP specific
information with the global one it will be a mess, and it will prevent
the easy reuse accross SoC familly.
hwmod structure is an IP information. The number of GPIO is an
integration information that has nothing to do inside the hwmod. If we
want to add an extra instance of GPIO in OMAP4440 for example, we will
not be able to reuse the current 4430 data.
I guess, irq no and dma channel information are also integration information
that are auto-generated in 4430 database. Shall we consider gpio_bank_count too?
So please, don't do that.
BTW, you didn't answer the first answer, do you really need that?
It is used in save/restore context which would be called
from sram_idle path.
Considering implementing using iterations count, there would be an
additional loop that would do this counting and the final value
would be passed as pdata-gpio_bank_count through each device data.
static int gpio_bank_count;
void omap_get_gpio_count (void) {
gpio_bank_count++;
}
int omap2_init_gpio (struct omap_hwmod *oh, void*user)
{
...
...
pdata-gpio_bank_count = gpio_bank_count;
omap_device_build(...);
...
...
}
void gpio_init ()
{
...
...
omap_hwmod_for_each_by_class(gpio, omap_get_gpio_count(oh, NULL));
...
...
omap_hwmod_for_each_by_class(gpio, omap2_init_gpio(oh, NULL));
}
Do we need to consider this?
+ .gpio_bank_bits = 32,
+ .dbck_flag = true,
+};
Since this structure is the same than OMAP3, you should maybe consider
sharing it.
They are in different _data.c files. I feel that it will be good if they are
kept decoupled as we need not have to mix up different SoC data. Here it's
only a
coincidence that OMAP3 and OMAP4 have same data
No it is not a coincidence, it is because we are re-using the same IP
implementation. In that case, it is not a big deal, but you should try
to reuse as most as you can already existing data.
They are in two different omap_hwmod__data.c files. Is there a way to share
this data?
Benoit
+
static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1305,7 +1312,7 @@ static struct omap_hwmod_addr_space
omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master =omap44xx_l4_wkup_hwmod,
.slave =omap44xx_gpio1_hwmod,
- .clk= l4_wkup_clk_mux_ck,
+ .clk= gpio1_ick,
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1325,7 +1332,7 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.class
RE: [PATCH 11/13 v3] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio
APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..993995a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
[snip]
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+struct omap_device *od;
+struct omap_gpio_platform_data *pdata;
+char *name = omap-gpio;
+static int id;
+struct omap_gpio_dev_attr *gpio_dev_data;
+
+if (!oh)
+pr_err(Could not look up omap gpio %d\n, id + 1);
+
+pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+GFP_KERNEL);
+if (!pdata) {
+pr_err(Memory allocation failed gpio%d\n, id + 1);
+return -ENOMEM;
+}
+
+gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+pdata-gpio_attr = gpio_dev_data;
+pdata-method = (int)user;
That method seems to be an IP version specific information and not a Soc
specific one. You should store that in the hwmod dev_attr.
'method' is chip ID information mapped to GPIO driver specific enum that is
passed to the driver
(eg., METHOD_GPIO_24XX, METHOD_GPIO_44XX). I think this should not be
moved to
hwmod dev_attr because
this is only an info required for the driver to identify the chip ID and
accordingly access
functions/ registers.
Also this 'method' would be removed once GPIO code undergoes a complete
cleanup.
What does 'method' mean in that context? Maybe the name should be
revisited?
Agree. 'method' is used throughout OMAP GPIO code. As mentioned above, this
field would be removed
once the whole GPIO code is cleaned up. This patch series doesn't bother to
clean up GPIO code as the
changes would be huge and intended only for HWMOD FW adaptation. Cleaning
up
GPIO code would come as
a separate series and we can address this then.
Sorry if my comment is not aligned but I thought we are addressing the
gpio clean up as well.
If we are re-vamping the code so much, is it not the right time to clean up
as
well ??
I agree with Santosh, you are already cleaning a bunch of things, and in
that case you can easily take advantage of HWMOD to remove a good amount
of useless code.
We'd better do that right now, instead of waiting a next phase that
might never happen...
Since hwmod migration would change mainly the init part of the code, I started
working on hwmod migration as part of the first series. Once we agree upon the
final patch set for GPIO hwmod migration, I can work on top of the hwmod
migration patch series to clean up the GPIO code and send a dependent series.
This will help sending the changes in smaller chunks.
I would add a TODO section in patch description outlining the cleanup to be
done in the next patch series.
Tony,
Can you add your feedback?
Please refer
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26065.html for the
old context.
And BTW, this 'method' is a IP version dependent information and not a
Soc specific one. You can potentially use the HW revision field, if it
is available for the GPIO.
I agree that it is not SoC specific. But I still feel that it is better not to
have 'method' as part of dev_attr, considering that, after clean-up, this
information will no longer be needed.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] OMAP4 Keyboard Controller Support
Keyboard controller for OMAP4 includes - built-in scanning algorithm - debouncing feature - handling mechanism up to 9 x 9 keys - wake-up event generation Tested using SDP4430 board in Kevin Hillman's tree, pm-wip/hwmods-omap4 branch --- v1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26502.html v2 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28334.html v3 Dmitry.Torokhov | Rework in driver code http://www.mail-archive.com/linux-omap@vger.kernel.org/msg29297.html v4 Felipe.Balbi.01| rows, cols, base and irq definitions Felipe.Balbi.02| device_* calls Felipe.Balbi.03| input device registration before irq enabling Felipe.Balbi.04| kzalloc allocation never to be freed Tony.Lindgren.01 | test in omap2 and omap3 Tony.Lindgren.02 | add cpu_is_omap44xx() Kevin.Hillman.01 | drop device_* calls Kevin.Hillman.01 | use runtime PM API Tomas.Petazzoni.01 | oh_name declaration --- Abraham Arce (3): OMAP4: Keyboard controller support OMAP4: Keyboard device registration OMAP4: Keyboard board support Syed Rafiuddin (1): OMAP4: Keyboard kernel configuration arch/arm/configs/omap_4430sdp_defconfig|3 +- arch/arm/mach-omap2/board-4430sdp.c| 99 arch/arm/mach-omap2/devices.c | 50 arch/arm/plat-omap/include/plat/omap4-keypad.h | 19 ++ drivers/input/keyboard/Kconfig | 10 + drivers/input/keyboard/Makefile|1 + drivers/input/keyboard/omap4-keypad.c | 288 7 files changed, 469 insertions(+), 1 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap4-keypad.h create mode 100644 drivers/input/keyboard/omap4-keypad.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
[PATCH v4 1/4] OMAP4: Keyboard controller support
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
arch/arm/plat-omap/include/plat/omap4-keypad.h | 19 ++
drivers/input/keyboard/Kconfig | 10 +
drivers/input/keyboard/Makefile|1 +
drivers/input/keyboard/omap4-keypad.c | 288
4 files changed, 318 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap4-keypad.h
create mode 100644 drivers/input/keyboard/omap4-keypad.c
diff --git a/arch/arm/plat-omap/include/plat/omap4-keypad.h
b/arch/arm/plat-omap/include/plat/omap4-keypad.h
new file mode 100644
index 000..d11c3ab
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap4-keypad.h
@@ -0,0 +1,19 @@
+#ifndef ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+#define ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+
+#include linux/input/matrix_keypad.h
+
+struct omap4_keypad_platform_data {
+ const struct matrix_keymap_data *keymap_data;
+
+ u8 rows;
+ u8 cols;
+
+ u16 irq;
+ void __iomem *base;
+};
+
+extern int omap4_init_kp(struct omap4_keypad_platform_data *kpd);
+
+#endif
+
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index d8fa5d7..af5ef6e 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -393,6 +393,16 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
+config KEYBOARD_OMAP4
+ tristate TI OMAP4 keypad support
+ depends on ARCH_OMAP4
+ default n
+ help
+ Say Y here if you want to use the OMAP4 keypad.
+
+ To compile this driver as a module, choose M here: the
+ module will be called omap4-keypad.
+
config KEYBOARD_TWL4030
tristate TI TWL4030/TWL5030/TPS659x0 keypad support
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 4596d0c..fe48826 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_OMAP)+= omap-keypad.o
+obj-$(CONFIG_KEYBOARD_OMAP4) += omap4-keypad.o
obj-$(CONFIG_KEYBOARD_OPENCORES) += opencores-kbd.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o
obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
new file mode 100644
index 000..5e224f2
--- /dev/null
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -0,0 +1,288 @@
+/*
+ * OMAP4 Keypad Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Abraham Arce x0066...@ti.com
+ * Initial Code: Syed Rafiuddin rafiuddin.s...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/errno.h
+#include linux/io.h
+#include linux/input.h
+#include linux/slab.h
+
+#include plat/omap4-keypad.h
+
+/* OMAP4 registers */
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG0x10
+#define OMAP4_KBD_SYSSTATUS0x14
+#define OMAP4_KBD_IRQSTATUS0x18
+#define OMAP4_KBD_IRQENABLE0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_320x48
+
+/* OMAP4 bit definitions */
+#define OMAP4_DEF_SYSCONFIG_SOFTRST(1 1)
+#define OMAP4_DEF_SYSCONFIG_ENAWKUP(1
[PATCH v4 2/4] OMAP4: Keyboard device registration
Register keyboard device with hwmod framework
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 +
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 03e6c9e..d229901 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/clk.h
+#include linux/slab.h
#include mach/hardware.h
#include mach/irqs.h
@@ -29,6 +30,9 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/dma.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/omap4-keypad.h
#include mux.h
@@ -139,6 +143,52 @@ static inline void omap_init_camera(void)
}
#endif
+#ifdef CONFIG_ARCH_OMAP4
+
+struct omap_device_pm_latency omap_keyboard_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap4_keypad_platform_data *pdata;
+
+ unsigned int id = 0;
+ char *name = omap4-keypad;
+ char *oh_name = kbd;
+
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
+
+ pdata = kp;
+
+ pdata-base = oh-_rt_va;
+ pdata-irq = oh-mpu_irqs[0].irq;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(struct matrix_keypad_platform_data),
+ omap_keyboard_latency,
+ ARRAY_SIZE(omap_keyboard_latency), 1);
+ WARN(IS_ERR(od), Could not build omap_device for %s %s\n,
+ name, oh_name);
+
+ return 0;
+}
+
+#endif
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#define MBOX_REG_SIZE 0x120
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap4: Fix multi-omap boot with reset un-used clocks
* Paul Walmsley p...@pwsan.com [100616 12:16]: On Mon, 31 May 2010, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [100520 02:05]: Hi, On Wed, 19 May 2010, Santosh Shilimkar wrote: This patch uses ENABLE_ON_INIT flag on the emif clock nodes to avoid the emif clk getting cut as part of reset un-used clock routine which prevents boot. Since omap4 omap2_clk_init() calls clk_enable_init_clocks() which increases the usecount on all ENABLE_ON_INIT clocks, it prevents omap2_clk_disable_unused() from disabling the clock. The real fix is to have driver for EMIF and do clock get/enable as part of it. The EMIF driver is planned to be done HWMOD way so till that available to keep omap3_defconfig booting on OMAP4430, this patch is necessary. (Will updated the auto-gen script for 44xx accordingly) The fix was suggested by Paul Walmsley Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, I've added Nishanth's Tested-by: and fixed the patch changelog; the following patch is now queued for 2.6.35-rc, unless there are any further comments. FYI, I'll also added this into omap-testing branch while we're waiting for your clock fixes branch to be available. Acked-by: Paul Walmsley p...@pwsan.com Feel free to send this one upstream separately if you like, until the clock -rc series is ready. OK, thanks, will add into omap-fixes-for-linus. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] OMAP4: Keyboard board support
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 99 +++
1 files changed, 99 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4a5d66..db30f15 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -34,12 +34,106 @@
#include plat/timer-gp.h
#include plat/usb.h
#include plat/mmc.h
+#include plat/omap4-keypad.h
#include hsmmc.h
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+static int sdp4430_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(0, 1, KEY_R),
+ KEY(0, 2, KEY_T),
+ KEY(0, 3, KEY_HOME),
+ KEY(0, 4, KEY_F5),
+ KEY(0, 5, KEY_UNKNOWN),
+ KEY(0, 6, KEY_I),
+ KEY(0, 7, KEY_LEFTSHIFT),
+
+ KEY(1, 0, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(1, 2, KEY_G),
+ KEY(1, 3, KEY_SEND),
+ KEY(1, 4, KEY_F6),
+ KEY(1, 5, KEY_UNKNOWN),
+ KEY(1, 6, KEY_K),
+ KEY(1, 7, KEY_ENTER),
+
+ KEY(2, 0, KEY_X),
+ KEY(2, 1, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(2, 3, KEY_END),
+ KEY(2, 4, KEY_F7),
+ KEY(2, 5, KEY_UNKNOWN),
+ KEY(2, 6, KEY_DOT),
+ KEY(2, 7, KEY_CAPSLOCK),
+
+ KEY(3, 0, KEY_Z),
+ KEY(3, 1, KEY_KPPLUS),
+ KEY(3, 2, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(3, 4, KEY_F8),
+ KEY(3, 5, KEY_UNKNOWN),
+ KEY(3, 6, KEY_O),
+ KEY(3, 7, KEY_SPACE),
+
+ KEY(4, 0, KEY_W),
+ KEY(4, 1, KEY_Y),
+ KEY(4, 2, KEY_U),
+ KEY(4, 3, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(4, 5, KEY_UNKNOWN),
+ KEY(4, 6, KEY_L),
+ KEY(4, 7, KEY_LEFT),
+
+ KEY(5, 0, KEY_S),
+ KEY(5, 1, KEY_H),
+ KEY(5, 2, KEY_J),
+ KEY(5, 3, KEY_F3),
+ KEY(5, 4, KEY_F9),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(5, 6, KEY_M),
+ KEY(5, 7, KEY_RIGHT),
+
+ KEY(6, 0, KEY_Q),
+ KEY(6, 1, KEY_A),
+ KEY(6, 2, KEY_N),
+ KEY(6, 3, KEY_BACK),
+ KEY(6, 4, KEY_BACKSPACE),
+ KEY(6, 5, KEY_UNKNOWN),
+ KEY(6, 6, KEY_P),
+ KEY(6, 7, KEY_UP),
+
+ KEY(7, 0, KEY_PROG1),
+ KEY(7, 1, KEY_PROG2),
+ KEY(7, 2, KEY_PROG3),
+ KEY(7, 3, KEY_PROG4),
+ KEY(7, 4, KEY_F4),
+ KEY(7, 5, KEY_UNKNOWN),
+ KEY(7, 6, KEY_OK),
+ KEY(7, 7, KEY_DOWN),
+};
+
+static struct matrix_keymap_data sdp4430_keymap_data = {
+ .keymap = sdp4430_keymap,
+ .keymap_size= ARRAY_SIZE(sdp4430_keymap),
+};
+
+static struct omap4_keypad_platform_data sdp4430_keypad_data = {
+ .keymap_data= sdp4430_keymap_data,
+ .rows = 8,
+ .cols = 8,
+};
+
+static struct platform_device sdp4430_keypad_device = {
+ .name = omap4-keypad,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_keypad_data,
+ },
+};
+
static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias = ks8851,
@@ -112,6 +206,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_keypad_device,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
@@ -380,6 +475,10 @@ static void __init omap_4430sdp_init(void)
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
+ status = omap4_init_kp(sdp4430_keypad_data);
+ if (status)
+ pr_err(Keypad initialization failed: %d\n, status);
+
status = omap_ethernet_init();
if (status) {
pr_err(Ethernet initialization failed: %d\n, status);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] OMAP4: Keyboard kernel configuration
From: Syed Rafiuddin rafiuddin.s...@ti.com Update OMAP4430 configuration to enable OMAP4 keyboard driver Signed-off-by: Abraham Arce x0066...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 1fb0456..54c924f 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -578,7 +578,8 @@ CONFIG_INPUT_EVDEV=y # # Input Device Drivers # -# CONFIG_INPUT_KEYBOARD is not set +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_OMAP4=y # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] arm: omap: switch over to gpio_set_debounce
On Mon, May 17, 2010 at 1:02 PM, felipe.ba...@nokia.com wrote: From: Felipe Balbi felipe.ba...@nokia.com stop using the omap-specific implementations for gpio debouncing now that gpiolib provides its own support. hmm, this gives me: [0.00] WARNING: at drivers/gpio/gpiolib.c:104 gpio_ensure_requested+0x50/0xcc() [0.00] autorequest GPIO-96 [0.00] Modules linked in: [0.00] [c00302bc] (unwind_backtrace+0x0/0xec) from [c00510dc] (warn_slowpath_common+0x4c/0x64) [0.00] [c00510dc] (warn_slowpath_common+0x4c/0x64) from [c0051174] (warn_slowpath_fmt+0x2c/0x3) [0.00] [c0051174] (warn_slowpath_fmt+0x2c/0x3c) from [c0166c2c] (gpio_ensure_requested+0x50/0x) [0.00] [c0166c2c] (gpio_ensure_requested+0x50/0xcc) from [c0166d14] (gpio_set_debounce+0x6c/0x) [0.00] [c0166d14] (gpio_set_debounce+0x6c/0xb0) from [c000ee84] (omap3pandora_init+0x94/0xcc) [0.00] [c000ee84] (omap3pandora_init+0x94/0xcc) from [c000b300] (customize_machine+0x18/0x24) ..and later gpio-keys is unable to request the same GPIO because of above autorequest. So how is this supposed to be used here, should I request all GPIOs I want to have debouncing on, setup debounce time and release them for gpio-keys to take? Or should I wait for this to get supported in gpio-keys? -- To unsubscribe from this list: send the line unsubscribe 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 10/13 v3] OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct
On 6/16/2010 5:41 PM, Varadarajan, Charulatha wrote:
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 37 +++--
---
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 20f5f8c..b4c0878 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/gpio.h
#include omap_hwmod_common_data.h
@@ -1272,6 +1273,12 @@ static struct omap_hwmod omap44xx_fdif_hwmod = {
* general purpose io module
*/
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .gpio_bank_count = 6,
Why do you need that information?
The point is that this struct is in theory a per instance data not a
global one. If needed, you should be able to get that from the number of
iteration done during the init of hwmods.
Even though it is possible to get it through number of iterations, more
efficient approach would be to keep this information here. My point is that this
information can be auto-generated and hence it is better to keep it in hwmod
database itself.
It is still a duplication of an information we already have indirectly.
The number of GPIO bank is exactly the number of hwmod gpio instances.
You do not need any other parameters to get that.
FYI, in a meeting we recently had with Kevin, we discussed about global data
information getting duplicated for each instance and it was agreed that it is
okay
to have pointers duplicated for each instance.
I'm not OK with that. If we start mixing the pure IP specific
information with the global one it will be a mess, and it will prevent
the easy reuse accross SoC familly.
hwmod structure is an IP information. The number of GPIO is an
integration information that has nothing to do inside the hwmod. If we
want to add an extra instance of GPIO in OMAP4440 for example, we will
not be able to reuse the current 4430 data.
I guess, irq no and dma channel information are also integration information
that are auto-generated in 4430 database. Shall we consider gpio_bank_count too?
I don't think you shall. irq and dma are information related to the
instance itself. The number of gpio is just a soc information.
So please, don't do that.
BTW, you didn't answer the first answer, do you really need that?
It is used in save/restore context which would be called
from sram_idle path.
Considering implementing using iterations count, there would be an
additional loop that would do this counting and the final value
would be passed as pdata-gpio_bank_count through each device data.
static int gpio_bank_count;
void omap_get_gpio_count (void) {
gpio_bank_count++;
}
int omap2_init_gpio (struct omap_hwmod *oh, void*user)
{
...
...
pdata-gpio_bank_count = gpio_bank_count;
omap_device_build(...);
...
...
}
void gpio_init ()
{
...
...
omap_hwmod_for_each_by_class(gpio,omap_get_gpio_count(oh, NULL));
...
...
omap_hwmod_for_each_by_class(gpio,omap2_init_gpio(oh, NULL));
}
Do we need to consider this?
I think you need to reconsider the usage of gpio_bank_count.
The omap_gpio_save_context should not use that variable at all. This
seems to be a legacy of the old none platform_driver code.
That should solve your problem.
Benoit
+ .gpio_bank_bits = 32,
+ .dbck_flag = true,
+};
Since this structure is the same than OMAP3, you should maybe consider
sharing it.
They are in different _data.c files. I feel that it will be good if they are
kept decoupled as we need not have to mix up different SoC data. Here it's only
a
coincidence that OMAP3 and OMAP4 have same data
No it is not a coincidence, it is because we are re-using the same IP
implementation. In that case, it is not a big deal, but you should try
to reuse as most as you can already existing data.
They are in two different omap_hwmod__data.c files. Is there a way to share
this data?
You can use omap_hwmod_common_data.c if you want.
Benoit
Benoit
+
static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1305,7 +1312,7 @@ static struct omap_hwmod_addr_space
omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master =omap44xx_l4_wkup_hwmod,
.slave
Re: [PATCH 12/13 v3] OMAP: GPIO: Implement GPIO as a platform device
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
OMAP2PLUS GPIO uses runtime APIs.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.
Inorder to convert GPIO as platform device, modifications are
required in clock_data.c file for OMAP1 so that device names
can be used to obtain clock instead of getting clocks by
name/NULL ptr.
omap_gpio_init() does nothing now and this function would be
removed in the next patch as it's usage is spread across most of
the board files.
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Rajendra Nayakrna...@ti.com
---
[snip]
+static inline int init_gpio_info(struct platform_device *pdev)
+{
+ gpio_bank = kzalloc(gpio_bank_count * sizeof(struct gpio_bank),
+ GFP_KERNEL);
This is the real issue with the gpio_bank_count.
You are creating a global driver information related to all instances of
this device with a per device variable.
You should store the registers per device, and that will remove the need
for that global information.
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: Serial console not working after waking up from sleep
You can do a telnet to the device... you should be able to work with it but your serial session will show the garbage. Regards, Rene -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Michael Trimarchi Sent: Wednesday, June 16, 2010 9:47 AM To: Han Wang Cc: linux-omap@vger.kernel.org Subject: Re: Serial console not working after waking up from sleep Hi Han Wang wrote: Hi, michael, I have the no_console_suspend option in my boot command line, I am not sure if that is the option you were trying to point me to in the last email? I have said that i have no problem when I remove that option. Can you try to echo 0 to timeout of the serial device? Michael anyway, I added no_debug_console into my boot command arg, but that doesn't seem to help with my problem. any ideas? Thanks, Han On Wed, Jun 16, 2010 at 2:09 AM, Michael Trimarchi mich...@panicking.kicks-ass.org wrote: Han Wang wrote: Hi, I am testing the 2.6.35-rc1 pm branch code on Overo. The system boots ok. (I can provide booting log if that is necessary) However, when I use echo mem /sys/power/state to send overo to sleep and wake it up by enter a key into serial console. I got garbage characters in the serial console, and I can not enter anything into the console anymore. I wonder if anyone has encountered a similar problem, and please give me some suggestion. I have appended command log below. r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep PM: Adding info for No Bus:vcs63 PM: Adding info for No Bus:vcsa63 Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep i2c_omap i2c_omap.1: preparing suspend i2c_omap i2c_omap.3: preparing suspend platform overo_lcd: preparing suspend serial8250 serial8250.0: preparing suspend, may wakeup serial8250 serial8250.1: preparing suspend, may wakeup serial8250 serial8250.2: preparing suspend, may wakeup platform omap2-nand: preparing suspend platform musb_hdrc: preparing suspend platform smsc911x.0: preparing suspend platform smsc911x.1: preparing suspend platform omap2_mcspi.1: preparing suspend platform omap2_mcspi.2: preparing suspend platform omap2_mcspi.3: preparing suspend platform omap2_mcspi.4: preparing suspend arm-pmu arm-pmu.0: preparing suspend platform omap_rng: preparing suspend platform omapfb: preparing suspend twl4030_gpio twl4030_gpio: preparing suspend mmci-omap-hs mmci-omap-hs.0: preparing suspend mmci-omap-hs mmci-omap-hs.1: preparing suspend twl_reg twl_reg.17: preparing suspend twl_reg twl_reg.18: preparing suspend twl_reg twl_reg.19: preparing suspend twl4030_usb twl4030_usb: preparing suspend, may wakeup twl_reg twl_reg.6: preparing suspend serial8250 serial8250: preparing suspend mmcblk mmc0:fb2a: legacy suspend serial8250 serial8250: suspend i2c i2c-3: suspend twl_reg twl_reg.6: suspend twl4030_usb twl4030_usb: suspend, may wakeup twl_reg twl_reg.19: suspend twl_reg twl_reg.18: suspend twl_reg twl_reg.17: suspend mmci-omap-hs mmci-omap-hs.1: suspend mmci-omap-hs mmci-omap-hs.0: suspend twl4030_gpio twl4030_gpio: suspend dummy 1-004b: suspend dummy 1-004a: suspend dummy 1-0049: suspend twl 1-0048: suspend, may wakeup i2c i2c-1: suspend platform omapfb: suspend platform omap_rng: suspend arm-pmu arm-pmu.0: suspend platform omap2_mcspi.4: suspend platform omap2_mcspi.3: suspend platform omap2_mcspi.2: suspend platform omap2_mcspi.1: suspend platform smsc911x.1: suspend platform smsc911x.0: suspend platform musb_hdrc: suspend platform omap2-nand: suspend serial8250 serial8250.2: suspend, may wakeup serial8250 serial8250.1: suspend, may wakeup serial8250 serial8250.0: suspend, may wakeup platform overo_lcd: suspend i2c_omap i2c_omap.3: suspend i2c_omap i2c_omap.1: suspend PM: suspend of devices complete after 201.965 msecs serial8250 serial8250: LATE suspend i2c i2c-3: LATE suspend twl_reg twl_reg.6: LATE suspend twl4030_usb twl4030_usb: LATE suspend, may wakeup twl_reg twl_reg.19: LATE suspend twl_reg twl_reg.18: LATE suspend twl_reg twl_reg.17: LATE suspend mmci-omap-hs mmci-omap-hs.1: LATE suspend mmci-omap-hs mmci-omap-hs.0: LATE suspend twl4030_gpio twl4030_gpio: LATE suspend dummy 1-004b: LATE suspend dummy 1-004a: LATE suspend dummy 1-0049: LATE suspend twl 1-0048: LATE suspend, may wakeup i2c i2c-1: LATE suspend platform omapfb: LATE suspend platform omap_rng: LATE suspend arm-pmu arm-pmu.0: LATE suspend platform omap2_mcspi.4: LATE suspend platform omap2_mcspi.3: LATE suspend platform omap2_mcspi.2: LATE suspend platform omap2_mcspi.1: LATE suspend platform smsc911x.1: LATE suspend platform
Re: [PATCH] mailbox: change full flag per mailbox queue instead of global
On Mon, Jun 14, 2010 at 11:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
As pointed by Ben Ohand, the variable rq_full flag is a global
variable, so if there are multiple mailbox users there will be
conflics. Now there is a full flag per mailbox queue.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 1 +
arch/arm/plat-omap/mailbox.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
Thanks, Fernando, it looks good !
Since the original patch wasn't merged yet, it might make more sense
to squash it with this fix into a single patch, instead of introducing
this fix as a new patch. what do you think ?
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 729166b..a6144b8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -47,6 +47,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox *mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8d86b0b..a1e274e 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -30,7 +30,6 @@
static struct omap_mbox *mboxes;
static DEFINE_RWLOCK(mboxes_lock);
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -140,9 +139,9 @@ static void mbox_rx_work(struct work_struct *work)
while (1) {
spin_lock_irqsave(q-queue_lock, flags);
rq = blk_fetch_request(q);
- if (rq_full) {
+ if (mbox-rxq-full) {
omap_mbox_enable_irq(mbox, IRQ_RX);
- rq_full = false;
+ mbox-rxq-full = false;
}
spin_unlock_irqrestore(q-queue_lock, flags);
if (!rq)
@@ -183,7 +182,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
rq = blk_get_request(q, WRITE, GFP_ATOMIC);
if (unlikely(!rq)) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mbox-rxq-full = true;
goto nomem;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP FB code to set DISPC_TIMING_{H,V} doesn't match TRM
The TRM and the OMAP FB driver have different ideas about the widths
of various bit fields in the DISPC_TIMING_{H,V} registers. This patch
is based on what the TRM (TI document SPRUF98G) says.
Note: this patch changes the meanings of the vertical timing values
by one scan line. It still works with my display, but it might break
things for other people.
---
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index c7c6455..e58574b 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -795,17 +795,17 @@ static void set_lcd_timings(void)
unsigned long fck;
l = dispc_read_reg(DISPC_TIMING_H);
- l = ~(FLD_MASK(0, 6) | FLD_MASK(8, 8) | FLD_MASK(20, 8));
- l |= ( max(1, (min(64, panel-hsw))) - 1 ) 0;
- l |= ( max(1, (min(256, panel-hfp))) - 1 ) 8;
- l |= ( max(1, (min(256, panel-hbp))) - 1 ) 20;
+ l = ~(FLD_MASK(0, 8) | FLD_MASK(8, 12) | FLD_MASK(20, 12));
+ l |= ( max(1, (min(256, panel-hsw))) - 1 ) 0;
+ l |= ( max(1, (min(4096, panel-hfp))) - 1 ) 8;
+ l |= ( max(1, (min(4096, panel-hbp))) - 1 ) 20;
dispc_write_reg(DISPC_TIMING_H, l);
l = dispc_read_reg(DISPC_TIMING_V);
- l = ~(FLD_MASK(0, 6) | FLD_MASK(8, 8) | FLD_MASK(20, 8));
- l |= ( max(1, (min(64, panel-vsw))) - 1 ) 0;
- l |= ( max(0, (min(255, panel-vfp))) - 0 ) 8;
- l |= ( max(0, (min(255, panel-vbp))) - 0 ) 20;
+ l = ~(FLD_MASK(0, 8) | FLD_MASK(8, 12) | FLD_MASK(20, 12));
+ l |= ( max(1, (min(256, panel-vsw))) - 1 ) 0;
+ l |= ( max(1, (min(4096, panel-vfp))) - 1 ) 8;
+ l |= ( max(1, (min(4096, panel-vbp))) - 1 ) 20;
dispc_write_reg(DISPC_TIMING_V, l);
l = dispc_read_reg(DISPC_POL_FREQ);
--
To unsubscribe from this list: send the line unsubscribe 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: SDHC card affected by preemption model in 2.6.35
On Wed, 2010-06-16 at 14:13 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: HW: Beagleboard rev. C2 and C4 Processor: OMAP3 Kernel: 2.6.35-rc2 Driver: mmci-omap-hs I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY. When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. When booting, a failing card (PREEMPT_VOLUNTARY) will output the following: [ 2.283355] mmc0: error -110 whilst initialising SD card I have also seen transfer errors such as this one: [ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr 26, card status 0xc00 When working properly (PREEMPT_NONE), you get: [ 27.026519] mmc0: new high speed SDHC card at address 0007 [ 27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB We seem to have a little timing problem - has anyone seen the same issue ? Can driver mmci-omap-hs actually work under PREEMPT_VOLUNTARY ? Thanks, Mathieu. I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful. Thanks, Venkat. Venkat, Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console. As for the cards, had failures with 3 different manufacturer: - Patriot Memory, MicroSD card, 8GB, class 4, SDHC. - Kinston, 4GB, class 6, SDHC. - Sandisk, 4GB, Class 2, SDHC. I am more than willing to test kernels for you if need be. Thanks, Mathieu. For MMC/SD logs to be sent to the console, you need to a) echo 8 /proc/sys/kernel/printk in the shell and b) insert the card If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG) Apologies - I should have explained this initially. Regards, Venkat. Venkat, I am indeed booting from the card itself, making things more difficult. DEBUG_LL has been configured since the very beginning and still not much to look at on the console. To see something I had to pass loglevel=8 on the kernel command line. At that point there is tones of stuff coming out and the card is initialized properly, which points to a timing issue. Since I couldn't reproduce the failure when debug messages are enabled, I turned them back off and started to instrument the code on the hunt for the failure. I have cornered the source of the problem in drivers/mmc/core/sd_ops.c, function mmc_sd_switch. When the kernel is configured with PREEMPT_NONE, the value of data.error is set to 0 after mmc_wait_for_req returns. When PREEMPT_VOLUNTARY is configured, data.error gets set to -110 upon mmc_wait_for_req returning, which prevent the remaining of the configuration to take place. I am out of time for today but tomorrow I'll dive in mmc_wait_for_req. Send me a line if the above rings a bell or you find something. Ghorai, please find an answer to your question in the above trail. Thanks, Mathieu. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE: driver version 0.3
From: Ramirez Luna, Omar driver version 0.3 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/dsp/bridge/rmgr/drv_interface.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] dspbridge: miscellaneous fixes and cleanups
From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Hi, A few trivial patches. The important one is the fix to build when MCBSP is disabled. Felipe Contreras (4): dspbridge: fix build when OMAP_MCBSP=n dspbridge: dev: fix dev_create_device() dspbridge: remove _tiomap_mmu.h dspbridge: remove _tiomap_util.h drivers/dsp/bridge/core/_tiomap_mmu.h| 41 -- drivers/dsp/bridge/core/_tiomap_util.h | 43 -- drivers/dsp/bridge/core/dsp-clock.c |6 ++ drivers/dsp/bridge/core/mmu_fault.c |1 - drivers/dsp/bridge/core/tiomap3430.c | 89 ++ drivers/dsp/bridge/core/tiomap3430_pwr.c |3 +- drivers/dsp/bridge/core/ue_deh.c |1 - drivers/dsp/bridge/pmgr/dev.c| 22 --- 8 files changed, 49 insertions(+), 157 deletions(-) delete mode 100644 drivers/dsp/bridge/core/_tiomap_mmu.h delete mode 100644 drivers/dsp/bridge/core/_tiomap_util.h Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] OMAP2/3: hwmod: remove '_hwmod' suffix from names
As per new naming convention for hwmods, remove the redundant _hwmod suffix
from all hwmod names.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e5530c5..284fb23 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2420_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3,
.class = l3_hwmod_class,
.masters= omap2420_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
@@ -89,7 +89,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2420_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap2420_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
@@ -109,7 +109,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2420_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class = l4_hwmod_class,
.masters= omap2420_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0852d95..1e780b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2430_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3,
.class = l3_hwmod_class,
.masters= omap2430_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
@@ -91,7 +91,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2430_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap2430_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
@@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2430_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class = l4_hwmod_class,
.masters= omap2430_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 074347f..f1df4c9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -73,7 +73,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap3xxx_l3_hwmod = {
- .name = l3_hwmod,
+ .name = l3,
.class = l3_hwmod_class,
.masters= omap3xxx_l3_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
@@ -141,7 +141,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[]
= {
/* L4 CORE */
static struct omap_hwmod omap3xxx_l4_core_hwmod = {
- .name = l4_core_hwmod,
+ .name = l4_core,
.class = l4_hwmod_class,
.masters= omap3xxx_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
@@ -161,7 +161,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[]
= {
/* L4 PER */
static struct omap_hwmod omap3xxx_l4_per_hwmod = {
- .name = l4_per_hwmod,
+ .name = l4_per,
.class = l4_hwmod_class,
.masters= omap3xxx_l4_per_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
@@ -181,7 +181,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
- .name = l4_wkup_hwmod,
+ .name = l4_wkup,
.class = l4_hwmod_class,
.masters= omap3xxx_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
[PATCH 02/12] OMAP: hwmod: add class for DSP hwmods
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 1e80b91..09f1e98 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -66,3 +66,6 @@ struct omap_hwmod_class mpu_hwmod_class = {
.name = mpu
};
+struct omap_hwmod_class dsp_hwmod_class = {
+ .name = dsp
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 3645a28..d03ebfa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -20,5 +20,6 @@
extern struct omap_hwmod_class l3_hwmod_class;
extern struct omap_hwmod_class l4_hwmod_class;
extern struct omap_hwmod_class mpu_hwmod_class;
+extern struct omap_hwmod_class dsp_hwmod_class;
#endif
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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 00/12] rework OPP layer to handle device-based OPPs
The current OPP layer is based on a unique identifier (OPP_MPU, OPP_DSP, OPP_L3) which is not terribly portable or scalable for future devices. Since we'd also like to be able to manage OPPs for any device (as recently agreed upon during an OMAP PM meeting in TI Bangalore[1]), this patch changes the OPP API to be device-based instead of unique-ID based. Essentially, this means passing a 'struct device' instead of a unique ID to determine which set of OPPs to be used. The main part of this patch is PATCH 08/12 where the OPP API changes are made. The earlier parts of the series are prep work for this and the remaining parts are updating users of the OPP API. Applies on top of current PM branch. [1] http://omappedia.org/wiki/Proceedings_of_the_PM_SW_Workshop_Jun_2010 Kevin Hilman (12): OMAP2/3: hwmod: remove '_hwmod' suffix from names OMAP: hwmod: add class for DSP hwmods OMAP3: hwmod: add data for OMAP3 IVA2 OMAP: omap_device: ensure hwmod tracks attached omap_device pointer OMAP: create omap_devices for MPU, DSP, L3 OMAP: voltage: use device_initcall() OMAP: SR: use device_initcall() OMAP2: OPP: update API to be device-based OMAP3: CPUfreq: update to device-based OPP API OMAP: voltage: update to new device-based OPP API OMAP: SRF: update to new device-based OPP API OMAP: SRF: must be initialized before allowing constraints to be set arch/arm/mach-omap2/cpufreq34xx.c| 180 + arch/arm/mach-omap2/devices.c|2 + arch/arm/mach-omap2/io.c | 68 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 49 +++- arch/arm/mach-omap2/omap_hwmod_common_data.c |3 + arch/arm/mach-omap2/omap_hwmod_common_data.h |1 + arch/arm/mach-omap2/resource34xx.c | 95 --- arch/arm/mach-omap2/sr_device.c |2 +- arch/arm/mach-omap2/voltage.c| 12 +- arch/arm/plat-omap/cpu-omap.c| 12 +- arch/arm/plat-omap/include/plat/common.h |4 + arch/arm/plat-omap/include/plat/opp.h| 57 ++--- arch/arm/plat-omap/omap-pm-srf.c |7 + arch/arm/plat-omap/omap_device.c |8 +- arch/arm/plat-omap/opp.c | 396 +++--- 17 files changed, 474 insertions(+), 434 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/omap_device.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f899603..6614cba 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -359,8 +359,8 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_device *od; char *pdev_name2; struct resource *res = NULL; - int res_count; - struct omap_hwmod **hwmods; + int i, res_count; + struct omap_hwmod *oh, **hwmods; if (!ohs || oh_cnt == 0 || !pdev_name) return ERR_PTR(-EINVAL); @@ -416,6 +416,10 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, else ret = omap_device_register(od); + /* each hwmod has a pointer to its attached omap_device */ + for (i = 0, oh = hwmods[0]; i oh_cnt; i++, oh++) + oh-od = od; + if (ret) goto odbs_exit4; -- 1.7.0.2 -- To unsubscribe from this list: send the line unsubscribe 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 05/12] OMAP: create omap_devices for MPU, DSP, L3
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the omap_device and
hwmod level.
Because these omap_devices are based on platform_devices, they cannot
be created until the driver core has been initialized. Therefore, move
the init of these into a device_initcall(). Also, OMAP PM init cannot
be done until after this step as it depends on the OPP layer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c|2 +
arch/arm/mach-omap2/io.c | 68 --
arch/arm/plat-omap/include/plat/common.h |4 ++
3 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 03e6c9e..62920ac 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/clk.h
+#include linux/err.h
#include mach/hardware.h
#include mach/irqs.h
@@ -29,6 +30,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/dma.h
+#include plat/omap_device.h
#include mux.h
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 78d37c0..12a2836 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -44,7 +44,7 @@
#include plat/clockdomain.h
#include clockdomains.h
-#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include omap3-opp.h
/*
@@ -311,12 +311,71 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
-void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
-struct omap_sdrc_params *sdrc_cs1)
+static struct omap_device_pm_latency *pm_lats;
+
+static struct device *mpu_dev; /* FIXME: needs clean SMP support */
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap_get_mpu_device(void)
+{
+ WARN_ON_ONCE(!mpu_dev);
+ return mpu_dev;
+}
+
+struct device *omap_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+
+struct device *omap_get_l3_device(void)
{
+ WARN_ON_ONCE(!l3_dev);
+ return l3_dev;
+}
+
+static int _init_omap_device(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ const char *name = oh-name;
+ struct device **new_dev = (struct device **)user;
+
+ od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, false);
+ if (WARN(IS_ERR(od), Could not build omap_device for %s\n, name))
+ return -ENODEV;
+
+ *new_dev = od-pdev.dev;
+
+ return 0;
+}
+
+/*
+ * Build omap_devices for processors and bus.
+ */
+static void omap_init_processor_devices(void)
+{
+ omap_hwmod_for_each_by_class(mpu, _init_omap_device, mpu_dev);
+ omap_hwmod_for_each_by_class(dsp, _init_omap_device, dsp_dev);
+ omap_hwmod_for_each_by_class(l3, _init_omap_device, l3_dev);
+}
+
+static int __init omap2_late_common_init(void)
+{
+ omap_init_processor_devices();
+
/* initialize the opp table if board file has not done so */
omap3_pm_init_opp_table();
+ omap_pm_if_init();
+
+ return 0;
+}
+device_initcall(omap2_late_common_init);
+
+void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
+struct omap_sdrc_params *sdrc_cs1)
+{
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
@@ -325,6 +384,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
+
omap2_mux_init();
omap_pm_if_early_init();
@@ -342,7 +402,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap_serial_early_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
omap_hwmod_late_init();
- omap_pm_if_init();
+
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 5e4afbe..4ac08ca 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -89,4 +89,8 @@ void omap2_set_globals_uart(struct omap_globals *);
} \
})
+struct device *omap_get_mpu_device(void);
+struct device *omap_get_dsp_device(void);
+struct device *omap_get_l3_device(void);
+
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 06/12] OMAP: voltage: use device_initcall()
FIXME: this should be fixed in the SR/voltage v4 series Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/voltage.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c index b6d4f23..6e84ea1 100644 --- a/arch/arm/mach-omap2/voltage.c +++ b/arch/arm/mach-omap2/voltage.c @@ -1196,4 +1196,4 @@ static int __init omap_voltage_init(void) } return 0; } -arch_initcall(omap_voltage_init); +device_initcall(omap_voltage_init); -- 1.7.0.2 -- To unsubscribe from this list: send the line unsubscribe 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 07/12] OMAP: SR: use device_initcall()
DROP ME: this should be fixed in SR/voltage v4 series
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 5ca0253..dbf7603 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -174,4 +174,4 @@ static int __init omap_devinit_smartreflex(void)
{
return omap_hwmod_for_each_by_class(smartreflex, sr_dev_init, NULL);
}
-subsys_initcall(omap_devinit_smartreflex);
+device_initcall(omap_devinit_smartreflex);
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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 09/12] OMAP3: CPUfreq: update to device-based OPP API
Update usage of OPP API to use new device-based API. This requires
getting the 'struct device' for the MPU and using that with the OPP
API.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/cpu-omap.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 0674405..b086795 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -89,6 +89,7 @@ static int omap_target(struct cpufreq_policy *policy,
#endif
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
unsigned long freq;
+ struct device *mpu_dev = omap_get_mpu_device();
#endif
int ret = 0;
@@ -115,7 +116,7 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
- if (opp_find_freq_ceil(OPP_MPU, freq))
+ if (opp_find_freq_ceil(mpu_dev, freq))
omap_pm_cpu_set_freq(freq);
#endif
return ret;
@@ -134,10 +135,13 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
policy-cur = policy-min = policy-max = omap_getspeed(0);
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx()) {
clk_init_cpufreq_table(freq_table);
- else
- opp_init_cpufreq_table(OPP_MPU, freq_table);
+ } else {
+ struct device *mpu_dev = omap_get_mpu_device();
+
+ opp_init_cpufreq_table(mpu_dev, freq_table);
+ }
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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 08/12] OMAP2: OPP: update API to be device-based
The current OPP layer is based on a unique identifier (OPP_MPU,
OPP_DSP, OPP_L3) which is not terribly portable or scalable for future
devices.
Since we'd also like to be able to manage OPPs for any device, this
patch changes the OPP API to be device-based instead of unique-ID
based. Essentially, this means passing a 'struct device' instead of a
unique ID to determine which set of OPPs to be used.
While making the API change, I also significantly changed the
internal management of OPPs to use a list per-device and within
each per-device struct, a list to manage OPPs. This resulted in
basically a rewrite of the internals.
Another signifcant change is that I removed the opp_init_list()
function in favor of just using multiple calls to opp_add(). In
combination with the internal list-based implmentation, this permitted
the removal of the need for using termin
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpufreq34xx.c | 180 ++--
arch/arm/plat-omap/include/plat/opp.h | 57 ++---
arch/arm/plat-omap/opp.c | 396 ++--
3 files changed, 261 insertions(+), 372 deletions(-)
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index b9d75cf..9d453b8 100644
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -1,5 +1,4 @@
/*
- * arch/arm/mach-omap2/cpufreq34xx.c
* OMAP3 resource init/change_level/validate_level functions
*
* Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
@@ -27,111 +26,80 @@
#include plat/cpu.h
#include omap3-opp.h
-static struct omap_opp_def __initdata omap34xx_mpu_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 12500, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 25000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 5, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 55000, 127),
- /* OPP5 */
- OMAP_OPP_DEF(true, 6, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+ /* MPU OPP1 */
+ OMAP_OPP_DEF(mpu, true, 12500, 975000),
+ /* MPU OPP2 */
+ OMAP_OPP_DEF(mpu, true, 25000, 1075000),
+ /* MPU OPP3 */
+ OMAP_OPP_DEF(mpu, true, 5, 120),
+ /* MPU OPP4 */
+ OMAP_OPP_DEF(mpu, true, 55000, 127),
+ /* MPU OPP5 */
+ OMAP_OPP_DEF(mpu, true, 6, 135),
-static struct omap_opp_def __initdata omap34xx_l3_rate_table[] = {
/*
-* OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
+* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
* almost the same than the one at 83MHz thus providing very little
* gain for the power point of view. In term of energy it will even
* increase the consumption due to the very negative performance
* impact that frequency will do to the MPU and the whole system in
* general.
*/
- OMAP_OPP_DEF(false, 4150, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 8300, 105),
- /* OPP3 */
- OMAP_OPP_DEF(true, 16600, 115),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap34xx_dsp_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 9000, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 18000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 36000, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 4, 127),
- /* OPP5 */
- OMAP_OPP_DEF(true, 43000, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
+ OMAP_OPP_DEF(l3, false, 4150, 975000),
+ /* L3 OPP2 */
+ OMAP_OPP_DEF(l3, true, 8300, 105),
+ /* L3 OPP3 */
+ OMAP_OPP_DEF(l3, true, 16600, 115),
+
+
+ /* DSP OPP1 */
+ OMAP_OPP_DEF(dsp, true, 9000, 975000),
+ /* DSP OPP2 */
+ OMAP_OPP_DEF(dsp, true, 18000, 1075000),
+ /* DSP OPP3 */
+ OMAP_OPP_DEF(dsp, true, 36000, 120),
+ /* DSP OPP4 */
+ OMAP_OPP_DEF(dsp, true, 4, 127),
+ /* DSP OPP5 */
+ OMAP_OPP_DEF(dsp, true, 43000, 135),
};
-
-static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
- /* OPP1 - OPP50 */
- OMAP_OPP_DEF(true, 3, 93),
- /* OPP2 - OPP100 */
- OMAP_OPP_DEF(true, 6, 110),
- /* OPP3 - OPP-Turbo */
- OMAP_OPP_DEF(false, 8, 126),
- /* OPP4 - OPP-SB */
- OMAP_OPP_DEF(false, 10, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
- /* OPP1 - OPP50 */
- OMAP_OPP_DEF(true, 1,
[PATCH 11/12] OMAP: SRF: update to new device-based OPP API
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/resource34xx.c | 95 ++-
1 files changed, 60 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 7f39fc3..70b41bc 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -170,14 +170,15 @@ static DEFINE_MUTEX(dvfs_mutex);
*
* NOTE: this function is a standin for the timebeing as opp_id is deprecated
*/
-static int __deprecated opp_to_freq(unsigned long *freq, enum opp_t opp_type,
+static int __deprecated opp_to_freq(unsigned long *freq, struct device *dev,
u8 opp_id)
{
struct omap_opp *opp;
- BUG_ON(!freq || opp_type = OPP_TYPES_MAX);
+ if (WARN_ON(!freq))
+ return -EINVAL;
- opp = opp_find_by_opp_id(opp_type, opp_id);
+ opp = opp_find_by_opp_id(dev, opp_id);
if (IS_ERR(opp))
return -EINVAL;
@@ -189,20 +190,19 @@ static int __deprecated opp_to_freq(unsigned long *freq,
enum opp_t opp_type,
/**
* freq_to_opp - convert a frequency back to OPP ID (DEPRECATED)
* @opp_id: opp ID returned back to caller
- * @opp_type: OPP type where we need to look.
+ * @opp_dev: device where we need to look for OPPs
* @freq: frequency we are searching for
*
* return 0 and opp_id is populated if we find the freq, else, we return error
*
* NOTE: this function is a standin for the timebeing as opp_id is deprecated
*/
-static int __deprecated freq_to_opp(u8 *opp_id, enum opp_t opp_type,
+static int __deprecated freq_to_opp(u8 *opp_id, struct device *dev,
unsigned long freq)
{
struct omap_opp *opp;
- BUG_ON(opp_type = OPP_TYPES_MAX);
- opp = opp_find_freq_ceil(opp_type, freq);
+ opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp))
return -EINVAL;
*opp_id = opp_get_opp_id(opp);
@@ -223,10 +223,12 @@ void init_opp(struct shared_resource *resp)
* to the opp set by u-boot.
*/
if (strcmp(resp-name, vdd1_opp) == 0) {
+ struct device *dev = omap_get_mpu_device();
+
vdd1_resp = resp;
dpll1_clk = clk_get(NULL, dpll1_ck);
dpll2_clk = clk_get(NULL, dpll2_ck);
- ret = freq_to_opp(opp_id, OPP_MPU, dpll1_clk-rate);
+ ret = freq_to_opp(opp_id, dev, dpll1_clk-rate);
if (ret) {
pr_err(%s: initializing %s failed! !match for %ld\n,
__func__, resp-name, dpll1_clk-rate);
@@ -241,10 +243,12 @@ void init_opp(struct shared_resource *resp)
}
curr_vdd1_opp = opp_id;
} else if (strcmp(resp-name, vdd2_opp) == 0) {
+ struct device *dev = omap_get_l3_device();
+
vdd2_resp = resp;
dpll3_clk = clk_get(NULL, dpll3_m2_ck);
l3_clk = clk_get(NULL, l3_ick);
- ret = freq_to_opp(opp_id, OPP_L3, l3_clk-rate);
+ ret = freq_to_opp(opp_id, dev, l3_clk-rate);
if (ret) {
pr_err(%s: initializing %s failed! !match for %ld\n,
__func__, resp-name, l3_clk-rate);
@@ -305,16 +309,20 @@ static int program_opp_freq(int res, int target_level,
int current_level)
#ifndef CONFIG_CPU_FREQ
unsigned long mpu_cur_freq;
#endif
+ struct device *l3_dev = omap_get_l3_device();
/* Check if I can actually switch or not */
if (res == VDD1_OPP) {
- ret = opp_to_freq(mpu_freq, OPP_MPU, target_level);
- ret |= opp_to_freq(dsp_freq, OPP_DSP, target_level);
+ struct device *mpu_dev = omap_get_mpu_device();
+ struct device *dsp_dev = omap_get_dsp_device();
+
+ ret = opp_to_freq(mpu_freq, mpu_dev, target_level);
+ ret |= opp_to_freq(dsp_freq, dsp_dev, target_level);
#ifndef CONFIG_CPU_FREQ
- ret |= opp_to_freq(mpu_cur_freq, OPP_MPU, current_level);
+ ret |= opp_to_freq(mpu_cur_freq, mpu_dev, current_level);
#endif
} else {
- ret = opp_to_freq(l3_freq, OPP_L3, target_level);
+ ret = opp_to_freq(l3_freq, l3_dev, target_level);
}
/* we would have caught all bad levels earlier.. */
if (unlikely(ret))
@@ -349,14 +357,14 @@ static int program_opp_freq(int res, int target_level,
int current_level)
return target_level;
}
-static int program_opp(int res, enum opp_t opp_type, int target_level,
+static int program_opp(int res, struct device *dev, int target_level,
int current_level)
{
int i, ret = 0, raise;
unsigned long freq;
/* See if have a freq associated, if not, invalid opp */
- ret = opp_to_freq(freq, opp_type, target_level);
+ ret
[PATCH 12/12] OMAP: SRF: must be initialized before allowing constraints to be set
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/omap-pm-srf.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c
index 5ebcda3..bf9163e 100644
--- a/arch/arm/plat-omap/omap-pm-srf.c
+++ b/arch/arm/plat-omap/omap-pm-srf.c
@@ -29,6 +29,8 @@
#define LAT_RES_POSTAMBLE _latency
#define MAX_LATENCY_RES_NAME 30
+static int initialized;
+
/**
* get_lat_res_name - gets the latency resource name given a power domain name
* @pwrdm_name: Name of the power domain.
@@ -52,6 +54,9 @@ void get_lat_res_name(const char *pwrdm_name, char
**lat_name, int size)
void omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
{
+ if (!initialized)
+ return;
+
if (!dev || t -1) {
WARN_ON(1);
return;
@@ -291,6 +296,8 @@ int __init omap_pm_if_early_init(void)
int __init omap_pm_if_init(void)
{
resource_init(resources_omap);
+ initialized = 1;
+
return 0;
}
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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 03/12] OMAP3: hwmod: add data for OMAP3 IVA2
Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f1df4c9..571bb37 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -33,6 +33,7 @@
*/
static struct omap_hwmod omap3xxx_mpu_hwmod;
+static struct omap_hwmod omap3xxx_iva2_hwmod;
static struct omap_hwmod omap3xxx_l3_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
@@ -205,6 +206,45 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * IVA2_2 interface data
+ */
+
+static struct omap_hwmod_addr_space omap3xxx_iva2_addrs[] = {
+ {
+ .pa_start = 0x5c00,
+ .pa_end = 0x5eff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap3xxx_l3__iva2 = {
+ .master = omap3xxx_l3_hwmod,
+ .slave = omap3xxx_iva2_hwmod,
+ .clk= iva2_ck,
+ .addr = omap3xxx_iva2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_iva2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_iva2_masters[] = {
+ omap3xxx_l3__iva2,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap3xxx_iva2_hwmod = {
+ .name = dsp,
+ .class = dsp_hwmod_class,
+ .main_clk = iva2_ck,
+ .masters= omap3xxx_iva2_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
/* SR common */
static struct omap_hwmod_sysc_fields omap34xx_sr_sysc_fields = {
.clkact_shift = 20,
@@ -373,6 +413,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
+ omap3xxx_iva2_hwmod,
omap34xx_sr1_hwmod,
omap34xx_sr2_hwmod,
omap36xx_sr1_hwmod,
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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 10/12] OMAP: voltage: update to new device-based OPP API
The OPP API has changed to a device-based API. This patch updates
the usage of that API in the voltage layer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/voltage.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6e84ea1..d289691 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -102,7 +102,7 @@ struct vp_reg_val {
* @vp_reg : the register values, shifts, masks for various
* vp registers
* @volt_clk : the clock associated with the vdd.
- * @opp_type : the type of OPP associated with this vdd.
+ * @opp_dev: the 'struct device' associated with this vdd.
* @volt_data_count: Number of distinct voltages supported by this vdd.
* @nominal_volt : Nominal voltaged for this vdd.
* cmdval_reg : Voltage controller cmdval register.
@@ -113,7 +113,7 @@ struct omap_vdd_info{
struct vp_reg_offs vp_offs;
struct vp_reg_val vp_reg;
struct clk *volt_clk;
- int opp_type;
+ struct device *opp_dev;
int volt_data_count;
int id;
unsigned long nominal_volt;
@@ -385,7 +385,7 @@ static void __init omap3_vdd_data_configure(int vdd)
vdd_info[vdd].volt_clk = clk_get(NULL, dpll1_ck);
WARN(IS_ERR(vdd_info[vdd].volt_clk),
unable to get clock for VDD%d\n, vdd + 1);
- vdd_info[vdd].opp_type = OPP_MPU;
+ vdd_info[vdd].opp_dev = omap_get_mpu_device();
vdd_info[vdd].vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
vdd_info[vdd].cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET;
@@ -411,7 +411,7 @@ static void __init omap3_vdd_data_configure(int vdd)
vdd_info[vdd].volt_clk = clk_get(NULL, l3_ick);
WARN(IS_ERR(vdd_info[vdd].volt_clk),
unable to get clock for VDD%d\n, vdd + 1);
- vdd_info[vdd].opp_type = OPP_L3;
+ vdd_info[vdd].opp_dev = omap_get_l3_device();
vdd_info[vdd].vp_reg.tranxdone_status =
OMAP3430_VP2_TRANXDONE_ST_MASK;
vdd_info[vdd].cmdval_reg = OMAP3_PRM_VC_CMD_VAL_1_OFFSET;
@@ -843,7 +843,7 @@ unsigned long get_curr_voltage(int vdd)
}
freq = vdd_info[vdd].volt_clk-rate;
- opp = opp_find_freq_ceil(vdd_info[vdd].opp_type, freq);
+ opp = opp_find_freq_ceil(vdd_info[vdd].opp_dev, freq);
if (IS_ERR(opp)) {
pr_warning(%s: Unable to find OPP for VDD%d freq%ld\n,
__func__, vdd + 1, freq);
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe 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: On the APIs for Enabling and Disabling Wakeup capability.
Basak, Partha p-bas...@ti.com writes: I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Hi Partha, First, we need to dig up the Errata details for that USB problem to better understand the USB-specific issue. In addition, Paul and I discussed the option of automatically managing the wakeup during the hwmod enable/idle, since there isn't really a need to have the wakeup enabled when the hwmod is active. Do you see any disadvantages to that? That would be much cleaner than manually managing the wakeup feature per-driver. 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: On the APIs for Enabling and Disabling Wakeup capability.
Kevin, Kevin, There is no errata in the USB which needs the Enable/Disable wakeup to be done Seperately. If it can be handled with omap_devie_enable/idle Apis it is sufficient. But there is a need of setting the Auto idle bit seperately as for the USBOTG there is a need to set the Autoidle only after configuring the smart idle. It is recommended in the TRM not set the auto idle and smart idle together. This I discussed with Partha he sent a mail to you. For setting autoidle there is an api at hwmod layer but not yet omap device layer. Is there a plan to add API at omap device layer for enabling/disabling the autoidle? Regards, Hema -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, June 17, 2010 5:56 AM To: Basak, Partha Cc: p...@pwsan.com; Kalliguddi, Hema; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: Re: On the APIs for Enabling and Disabling Wakeup capability. Basak, Partha p-bas...@ti.com writes: I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Hi Partha, First, we need to dig up the Errata details for that USB problem to better understand the USB-specific issue. In addition, Paul and I discussed the option of automatically managing the wakeup during the hwmod enable/idle, since there isn't really a need to have the wakeup enabled when the hwmod is active. Do you see any disadvantages to that? That would be much cleaner than manually managing the wakeup feature per-driver. 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/5] arm: omap: switch over to gpio_set_debounce
Hi, On Wed, Jun 16, 2010 at 07:26:30PM +0200, ext Grazvydas Ignotas wrote: hmm, this gives me: yeah, funny thing is that this patch was cooking in the mailing list for over a month since I said I didn't have the boards and they were compile-tested only. Anyways, [0.00] WARNING: at drivers/gpio/gpiolib.c:104 gpio_ensure_requested+0x50/0xcc() [0.00] autorequest GPIO-96 [0.00] Modules linked in: [0.00] [c00302bc] (unwind_backtrace+0x0/0xec) from [c00510dc] (warn_slowpath_common+0x4c/0x64) [0.00] [c00510dc] (warn_slowpath_common+0x4c/0x64) from [c0051174] (warn_slowpath_fmt+0x2c/0x3) [0.00] [c0051174] (warn_slowpath_fmt+0x2c/0x3c) from [c0166c2c] (gpio_ensure_requested+0x50/0x) [0.00] [c0166c2c] (gpio_ensure_requested+0x50/0xcc) from [c0166d14] (gpio_set_debounce+0x6c/0x) [0.00] [c0166d14] (gpio_set_debounce+0x6c/0xb0) from [c000ee84] (omap3pandora_init+0x94/0xcc) [0.00] [c000ee84] (omap3pandora_init+0x94/0xcc) from [c000b300] (customize_machine+0x18/0x24) ..and later gpio-keys is unable to request the same GPIO because of above autorequest. So how is this supposed to be used here, should I request all GPIOs I want to have debouncing on, setup debounce time and release them for gpio-keys to take? Or should I wait for this to get supported in gpio-keys? to me it looks like the *_keys_gpio_init() function should be passed down to gpio-keys as a -setup() callback and you should probably also pass a -teardown() which would clear debounce time when you remove the driver. Then only call those functions after gpio has been requested. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe 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: DSS: Fix for dsi_pll to dpll4 clk switch
When switching between clocks, The new functional clock is effective when the next vertical blanking interval occurs. GOLCD bit has to be set for the new clock to take effect. Signed-off-by: Kishore Y kishor...@ti.com Signed-off-by: Mukund Mittal mmit...@ti.com Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com --- drivers/video/omap2/dss/dpi.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c index 960e977..5d778d6 100644 --- a/drivers/video/omap2/dss/dpi.c +++ b/drivers/video/omap2/dss/dpi.c @@ -214,10 +214,15 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev) #ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL dss_select_dispc_clk_source(DSS_SRC_DSS1_ALWON_FCLK); + dispc_go(OMAP_DSS_CHANNEL_LCD); + while (dispc_go_busy(OMAP_DSS_CHANNEL_LCD)) + ; dsi_pll_uninit(); dss_clk_disable(DSS_CLK_FCK2); #endif + dispc_enable_channel(OMAP_DSS_CHANNEL_LCD, 0); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1); if (cpu_is_omap34xx()) -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
