[RFC] OMAP PM: Device wakeup latency constraint framework
From: Vibhore Vardhan vvard...@ti.com
This patch implements device wakeup latency constraint framework.
Using omap_pm_set_max_dev_wakeup_lat(), drivers can specify the
maximum amount of time for a device to become accessible after
its clocks are enabled. This is done by restricting the power
states that the parent powerdomain of a device can be put into.
Only power states with profiled wakeup latency value less than
the requested constraint get selected while the constraint is
active.
This patch is dependent on OMAP PM: MPU/DMA Latency constraints
patch (https://patchwork.kernel.org/patch/113855/)
Baseline used: linux-next
Tested on: Zoom 3630
Signed-off-by: Vibhore Vardhan vvard...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 164 +
arch/arm/mach-omap2/powerdomains34xx.h| 60 +
arch/arm/plat-omap/include/plat/powerdomain.h | 32 +
3 files changed, 256 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 6527ec3..16edec6 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -23,6 +23,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/slab.h
#include asm/atomic.h
@@ -133,6 +134,13 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
+ /* Initialize priority ordered list for wakeup latency constraint */
+ spin_lock_init(pwrdm-wakeuplat_lock);
+ plist_head_init(pwrdm-wakeuplat_dev_list, pwrdm-wakeuplat_lock);
+
+ /* res_mutex protects res_list add and del ops */
+ mutex_init(pwrdm-wakeuplat_mutex);
+
pr_debug(powerdomain: registered %s\n, pwrdm-name);
return 0;
@@ -1075,3 +1083,159 @@ int pwrdm_post_transition(void)
return 0;
}
+/**
+ * pwrdm_wakeuplat_set_constraint - Set powerdomain wakeup latency constraint
+ * @pwrdm: struct powerdomain * to which requesting device belongs to
+ * @dev: struct device * of requesting device
+ * @t: wakeup latency constraint in microseconds
+ *
+ * Adds new entry to powerdomain's wakeup latency constraint list.
+ * If the requesting device already exists in the list, old value is
+ * overwritten. Checks whether current power state is still adequate.
+ * Returns -EINVAL if the powerdomain or device pointer is NULL,
+ * or -ENOMEM if kmalloc fails, or -ERANGE if constraint can't be met,
+ * or returns 0 upon success.
+ */
+int pwrdm_wakeuplat_set_constraint (struct powerdomain *pwrdm,
+ struct device *dev, unsigned long t)
+{
+ struct wakeuplat_dev_list *user;
+ int found = 0, ret = 0;
+
+ if (!pwrdm || !dev) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ mutex_lock(pwrdm-wakeuplat_mutex);
+
+ plist_for_each_entry(user, pwrdm-wakeuplat_dev_list, node) {
+ if (user-dev == dev) {
+ found = 1;
+ break;
+ }
+ }
+
+ /* Add new entry to the list or update existing request */
+ if (found user-constraint_us == t) {
+ goto exit_set;
+ } else if (!found) {
+ user = kzalloc(sizeof(struct wakeuplat_dev_list), GFP_KERNEL);
+ if (!user) {
+ pr_err(OMAP PM: FATAL ERROR: kzalloc failed\n);
+ ret = -ENOMEM;
+ goto exit_set;
+ }
+ user-dev = dev;
+ } else {
+ plist_del(user-node, pwrdm-wakeuplat_dev_list);
+ }
+
+ plist_node_init(user-node, t);
+ plist_add(user-node, pwrdm-wakeuplat_dev_list);
+ user-node.prio = user-constraint_us = t;
+
+ ret = pwrdm_wakeuplat_update_pwrst(pwrdm);
+
+exit_set:
+ mutex_unlock(pwrdm-wakeuplat_mutex);
+
+ return ret;
+}
+
+/**
+ * pwrdm_wakeuplat_release_constraint - Release powerdomain wkuplat constraint
+ * @pwrdm: struct powerdomain * to which requesting device belongs to
+ * @dev: struct device * of requesting device
+ *
+ * Removes device's entry from powerdomain's wakeup latency constraint list.
+ * Checks whether current power state is still adequate.
+ * Returns -EINVAL if the powerdomain or device pointer is NULL or
+ * no such entry exists in the list, or returns 0 upon success.
+ */
+int pwrdm_wakeuplat_release_constraint (struct powerdomain *pwrdm,
+ struct device *dev)
+{
+ struct wakeuplat_dev_list *user;
+ int found = 0, ret = 0;
+
+ if (!pwrdm || !dev) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ mutex_lock(pwrdm-wakeuplat_mutex);
+
+ plist_for_each_entry(user,
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
On Mon, Aug 09, 2010 at 01:36:18PM +0300, Felipe Balbi wrote:
On Thu, Jun 03, 2010 at 01:09:01PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
From: Felipe Balbi felipe.ba...@nokia.com
dev_vdbg() is only compiled when VERBOSE is defined, so
there's no need to wrap dev_dbg() on #ifdef VERBOSE .. #endif
as we can use dev_vdbg() directly.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
ping, any comments to this one ? It's been pending for quite a long
time.
Now picked up into my test-spi branch. I'll add it to linux-next after the
merge window closes.
g.
drivers/spi/omap2_mcspi.c | 36 +---
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..d703927 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -489,10 +489,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed out\n);
goto out;
}
-#ifdef VERBOSE
-dev_dbg(spi-dev, write-%d %02x\n,
+dev_vdbg(spi-dev, write-%d %02x\n,
word_len, *tx);
-#endif
__raw_writel(*tx++, tx_reg);
}
if (rx != NULL) {
@@ -506,10 +504,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
(l OMAP2_MCSPI_CHCONF_TURBO)) {
omap2_mcspi_set_enable(spi, 0);
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
-dev_dbg(spi-dev, read-%d %02x\n,
+dev_vdbg(spi-dev, read-%d %02x\n,
word_len, *(rx - 1));
-#endif
if (mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_RXS) 0) {
dev_err(spi-dev,
@@ -522,10 +518,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
-dev_dbg(spi-dev, read-%d %02x\n,
+dev_vdbg(spi-dev, read-%d %02x\n,
word_len, *(rx - 1));
-#endif
}
} while (c);
} else if (word_len = 16) {
@@ -542,10 +536,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed out\n);
goto out;
}
-#ifdef VERBOSE
-dev_dbg(spi-dev, write-%d %04x\n,
+dev_vdbg(spi-dev, write-%d %04x\n,
word_len, *tx);
-#endif
__raw_writel(*tx++, tx_reg);
}
if (rx != NULL) {
@@ -559,10 +551,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
(l OMAP2_MCSPI_CHCONF_TURBO)) {
omap2_mcspi_set_enable(spi, 0);
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
-dev_dbg(spi-dev, read-%d %04x\n,
+dev_vdbg(spi-dev, read-%d %04x\n,
word_len, *(rx - 1));
-#endif
if (mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_RXS) 0) {
dev_err(spi-dev,
@@ -575,10 +565,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
-dev_dbg(spi-dev, read-%d %04x\n,
+dev_vdbg(spi-dev, read-%d %04x\n,
word_len, *(rx - 1));
-#endif
}
} while (c);
} else if (word_len = 32) {
@@ -595,10 +583,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed out\n);
goto out;
}
-#ifdef VERBOSE
-dev_dbg(spi-dev, write-%d %08x\n,
+dev_vdbg(spi-dev, write-%d %08x\n,
Re: [PATCH 4/5] [omap1] Bluetooth device code common to HTC smartphones
* Cory Maccarrone darkstar6...@gmail.com [100809 20:21]: On Mon, Aug 9, 2010 at 12:43 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100808 20:22]: On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100802 18:23]: This change adds in a bluetooth controld driver/rfkill interface to the serial bluetooth controller found on many HTC smartphones such as the HTC Herald and HTC Wizard. To me it looks like most of this should be in drivers/bluetooth/omap7xx.c or something like that. Then you can just pass it the gpio numbers in the platform_data. Not sure I agree that it fits there. The driver isn't really a bluetooth driver -- it's really just an RFKILL interface, and some code to toggle UART clocks on and off, plus GPIO work on a board-specific level. In principle, the gpios could be set and the clocks enabled in the board files, and this driver wouldn't be necessary to get working bluetooth (as we'd use hciattach on /dev/ttyS*). But then, we can't toggle it off for power saving. Maybe a better place would be plat-omap/? But it really is more specific to these HTC boards, not the architecture itself. Hmm well what we've used earlier is to set something like set_power function pointer in the platform data, then call that in the driver if set. But in this case the driver is 8250.c, so let's not mess with that.. This issue should get properly solved with the omap specific serial driver once we get that merged as then we can have hooks for set_power in addition to cutting serial clocks when idle. So really, the only point of this driver is to be able to power on and off the external bluetooth chip, which is why I submitted it as helper code to the board files. Yeah. Can you take a look at the omap specific serial driver to get it working on omap1? Then you can have your GPIO functions set in the board-*.c file as set_power or similar, and the UART driver can idle properly. I can look at it. Where is the code for that, arch/arm/mach-omap2/serial.c? It's been floating on the list for a while now, here's the latest version: http://www.spinics.net/lists/linux-omap/msg31786.html Probably doing the platform data initialization is the biggest part that needs to be done for omap1, the driver itself should not need much changes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
Hi, On Tue, Aug 10, 2010 at 08:33:41AM +0200, ext Grant Likely wrote: Now picked up into my test-spi branch. I'll add it to linux-next after the merge window closes. ok, thanks Grant -- 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
Re: beginner questions on being added to the linux tree
* Stephen Rothwell s...@canb.auug.org.au [100810 04:02]: Hi Jacob, On Mon, 9 Aug 2010 19:36:01 -0500 Jacob Tanenbaum jacob.tanenb...@logicpd.com wrote: I work for LogicPD and am trying to add new support for there OMAP3 development boards to the kernel, I have a working version of some of the base support and was wondering how to get that ready to be merged in during this merge window. We have tested the code against the most recent version of linux-next I can get to build and was wondering where to go. Do I send merge requests to the linux-next list or a series of patches. I have sent patches to the omap and arm lists and got some minor syntax errors reported by them (spaces instead of tabs and the like) and was wondering where to go from here. I only merge other people's trees, so you need to set up a git tree somewhere and tell me (cc'ing linux-next and all other appropriate lists/people) where it is and which branch to fetch. I then fetch that branch each day and merge it with everything else. Getting your code merged by Linus during this merge window is up to Linus and Russell or Tony, I guess. But I cannot take new trees now until after -rc1 is out. So if you really want your code merged during this merge window, your best bet is to convince Russell and/or Tony. Yeah, it's too late for this merge window. But after -rc1 I'll start queuing things up for the next merge window. That way your patches will go to Stephen's for-next tree and then get pulled into the mainline tree during the next merge window. Having your tree in linux-next may be useful for ongoing development unless Tony thinks it may be better for you to just submit your code through his omap tree. If you have patches coming on continuous basis, then maintaining a git branch makes sense. For occasional sets of patches, it's probably easier to just email them to the list. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
I know, the sourceforge list is a bit of a pain. As all sourceforge lists are. I don't even know who the admin of that list is. One of the Russian MontaVista crew created that list, and presumably maintains it. -- To unsubscribe from this list: send the line unsubscribe 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: Zoom3 not booting with omap3_defconfig
* Aguirre, Sergio saagui...@ti.com [100809 21:54]: Hi, I'm trying to boot from NFS with my Zoom3 board with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058) But, I'm not successful so far. :( Seems that it can't detect the eth0 device. (See attached log: bad.txt) Now, If I take omap_zoom3_defconfig from just before commit: commit 80690ccc41f01df6edfb6684006824d8edff189e Author: Vincent Sanders vi...@simtec.co.uk Date: Tue Aug 3 21:19:21 2010 +0100 Remove ARM default configurations which duplicate omap3_defconfig I'm able to boot fine (see attached log: good.txt) So, somehow, current omap3_defconfig doesn't seem to be as functional as omap_zoom3_defconfig used to be... Hmm looks like the smc91x does not get detected for some reason. Is there something that everybody knows, and I'm missing on how to make a usable Zoom3 .config? Maybe try to diff your good and bad config? net eth0: SMSC911x/921x identified at 0xe080c000, IRQ: 318 This line seems to be missing in your bad config. Maybe check if there's some difference in mux settings between these two configs? Also, can you please try using your working config, then enable support for omap2 and omap4 and see if that breaks it somehow? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
-Original Message-
From: Bob Liu [mailto:lliu...@gmail.com]
Sent: Saturday, August 07, 2010 7:54 AM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
On Sat, Aug 7, 2010 at 1:27 AM, Hema HK hem...@ti.com wrote:
From: Hema HK hem...@ti.com
With OMAP core-off support musb was not functional as
context was getting
lost after wakeup from core-off. And also musb was blocking
the core-off
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and
force standby mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 4 ++
arch/arm/mach-omap2/usb-musb.c | 21 ++
arch/arm/plat-omap/include/plat/usb.h | 2 +
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 48
+++---
5 files changed, 71 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
2010-08-06 09:23:01.153862710 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2010-08-06
10:44:06.393863125 -0400
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ /* Save MUSB context */
+ musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /* restore MUSB context */
+ musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
2010-08-06 09:24:23.690112596 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
2010-08-06 10:44:06.385862697 -0400
@@ -120,6 +120,27 @@
}
}
+void musb_context_save_restore(int save)
+{
+ struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
+ struct omap_device *od = oh-od;
+ struct platform_device *pdev = od-pdev;
+ struct device *dev = pdev-dev;
+ struct device_driver *drv = dev-driver;
+
+ if (drv) {
+ struct musb_hdrc_platform_data *pdata =
dev-platform_data;
+ const struct dev_pm_ops *pm = drv-pm;
+ if (!pdata-is_usb_active(dev)) {
+
+ if (save)
+ pm-suspend(dev);
+ else
+ pm-resume_noirq(dev);
+ }
+ }
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h
2010-08-06 09:23:01.137862514 -0400
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
2010-08-06 10:44:06.381864367 -0400
@@ -79,6 +79,8 @@
extern void usb_ohci_init(const struct
ohci_hcd_omap_platform_data *pdata);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
2010-08-06 09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06
10:44:06.369863527 -0400
@@ -2427,11 +2427,6 @@
}
musb_save_context(musb);
-
- if (musb-set_clock)
- musb-set_clock(musb-clock, 0);
- else
-
RE: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for platform device implementation
-Original Message-
From: Varadarajan, Charulatha
Sent: Tuesday, August 10, 2010 10:49 AM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: RE: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for
platform device implementation
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 3:51 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: Re: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation
for
platform device implementation
Charulatha V ch...@ti.com writes:
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init()
does
the module init by clearing the status register and initializing the
GPIO control register. omap_gpio_chip_init() initializes the chip
request,
free, get, set and other function pointers and sets the gpio irq
handler.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
[...]
+static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
+{
+ if (cpu_class_is_omap2()) {
+ if (cpu_is_omap44xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_IRQSTATUSCLR0);
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_DEBOUNCENABLE);
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
+ } else if (cpu_is_omap34xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQENABLE1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQSTATUS1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_DEBOUNCE_EN);
+
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48306814);
This autoidle stuff should be removed in this series as setting this is
handled by the hwmod layer.
Okay.
This code is incorrectly setting the PRCM_SYSCONFIG(0x48306814) register inside
GPIO module which is incorrect. Ideally it should be moved to generic code like
prcm_setup_regs() inside PM44xx.c/PM34xx.c. Having said that, the reset value
of PRCM_SYSCONFIG is 0x01, so it would be safe just to remove this.
Now, coming to setting of AutoIdle (in CM_AUTOIDLE_XXX registers), even though
prcm_reg_ids are being populated, hwmod framework is not setting these
anywhere, all CM_AutoIdle settings are being done one-time in side
prcm_setup_regs().
Kevin, as you pointed out this needs to be done in the framework. Can we do it
as part of enabling the slave clocks? How does the following look?
static int _enable_clocks(struct omap_hwmod *oh)
{
int i;
pr_debug(omap_hwmod: %s: enabling clocks\n, oh-name);
if (oh-_clk)
clk_enable(oh-_clk);
if (oh-slaves_cnt 0) {
for (i = 0; i oh-slaves_cnt; i++) {
struct omap_hwmod_ocp_if *os = oh-slaves[i];
struct clk *c = os-_clk;
if (c (os-flags OCPIF_SWSUP_IDLE))
clk_enable(c);
else
/*TODO: Set CM_AutoIdle here*/
}
}
/* The opt clocks are controlled by the device driver. */
return 0;
}
+ } else if (cpu_is_omap24xx()) {
+ static const u32 non_wakeup_gpios[] = {
+ 0xe203ffc0, 0x08700040
+ };
+ if (id ARRAY_SIZE(non_wakeup_gpios))
+ bank-non_wakeup_gpios = non_wakeup_gpios[id];
+
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48019010);
ditto
Okay.
+ }
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
Hi,
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Saturday, August 07, 2010 8:55 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
Hello.
Hema HK wrote:
With OMAP core-off support musb was not functional as
context was getting
lost after wakeup from core-off. And also musb was blocking
the core-off
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and
force standby mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
[...]
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
2010-08-06 09:24:23.690112596 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
2010-08-06 10:44:06.385862697 -0400
@@ -120,6 +120,27 @@
}
}
+void musb_context_save_restore(int save)
+{
+struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
+struct omap_device *od = oh-od;
+struct platform_device *pdev = od-pdev;
+struct device *dev = pdev-dev;
+struct device_driver *drv = dev-driver;
+
+if (drv) {
+struct musb_hdrc_platform_data *pdata =
dev-platform_data;
+const struct dev_pm_ops *pm = drv-pm;
Should be an empty line after the declaration block...
Ok.
+if (!pdata-is_usb_active(dev)) {
+
+if (save)
+pm-suspend(dev);
+else
+pm-resume_noirq(dev);
+}
+}
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
2010-08-06 09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.c
2010-08-06 10:44:06.369863527 -0400
@@ -2427,11 +2427,6 @@
}
musb_save_context(musb);
-
-if (musb-set_clock)
-musb-set_clock(musb-clock, 0);
-else
-clk_disable(musb-clock);
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2443,12 +2438,6 @@
if (!musb-clock)
return 0;
-
-if (musb-set_clock)
-musb-set_clock(musb-clock, 1);
-else
-clk_enable(musb-clock);
-
musb_restore_context(musb);
The same question again: are you sure that clocks are auto-gated on
non-OMAP platfroms?
Bon Lui confirmed that there is no clock for blackfin.
Index: linux-omap-pm/drivers/usb/musb/omap2430.c
===
--- linux-omap-pm.orig/drivers/usb/musb/omap2430.c
2010-08-06 09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/omap2430.c
2010-08-06 10:44:30.093914217 -0400
[...]
@@ -259,15 +273,42 @@
void musb_platform_save_context(struct musb *musb,
struct musb_context_registers *musb_context)
{
-musb_context-otg_sysconfig = musb_readl(musb-mregs,
OTG_SYSCONFIG);
-musb_context-otg_forcestandby =
musb_readl(musb-mregs, OTG_FORCESTDBY);
If you're not saving the registers, you should remove the
corresponding
fields from 'struct musb_context_registers'.
Agreed. I will remove them from the structure.
+/*
+ * As per the omap-usbotg specification, configure it
to forced standby
+ * and force idle mode when no activity on usb.
+ */
+void __iomem *musb_base = musb-mregs;
+
+musb_writel(musb_base, OTG_FORCESTDBY, 0);
+
+musb_writel(musb_base, OTG_SYSCONFIG, musb_readl(musb_base,
+OTG_SYSCONFIG) ~(NOSTDBY |
SMARTSTDBY));
+
+musb_writel(musb_base, OTG_SYSCONFIG, musb_readl(musb_base,
+OTG_SYSCONFIG) ~(AUTOIDLE));
Pointless parens around AUTOIDLE...
Ok. I will remove.
+musb_writel(musb_base, OTG_SYSCONFIG, musb_readl(musb_base,
+OTG_SYSCONFIG) ~(NOIDLE | SMARTIDLE));
+
+musb_writel(musb_base, OTG_FORCESTDBY, 1);
}
void musb_platform_restore_context(struct musb
RE: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Monday, August 09, 2010 10:14 PM
To: Kalliguddi, Hema; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi; Tony
Lindgren; Kevin Hilman
Subject: RE: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hema HK
Sent: Friday, August 06, 2010 10:57 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi;
Tony Lindgren;
Kevin Hilman
Subject: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
From: Hema HK hem...@ti.com
With OMAP core-off support musb was not functional as
context was getting
lost after wakeup from core-off. And also musb was blocking
the core-off
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and
force standby
mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++
arch/arm/mach-omap2/usb-musb.c| 21 ++
arch/arm/plat-omap/include/plat/usb.h |2 +
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 48
+++---
5 files changed, 71 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2010-08-06
09:23:01.153862710 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2010-08-06
10:44:06.393863125 -0400
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+/* Save MUSB context */
+musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+/* restore MUSB context */
+musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
2010-08-06
09:24:23.690112596 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c 2010-08-06
10:44:06.385862697 -0400
@@ -120,6 +120,27 @@
}
}
+void musb_context_save_restore(int save)
+{
+struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
Might be good idea to check (oh) before proceeding?
if (!oh) {
/* error message */
return;
}
You are right. I will put a check.
+struct omap_device *od = oh-od;
+struct platform_device *pdev = od-pdev;
+struct device *dev = pdev-dev;
+struct device_driver *drv = dev-driver;
+
+if (drv) {
+struct musb_hdrc_platform_data *pdata =
dev-platform_data;
+const struct dev_pm_ops *pm = drv-pm;
+if (!pdata-is_usb_active(dev)) {
+
+if (save)
+pm-suspend(dev);
+else
+pm-resume_noirq(dev);
+}
+}
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h 2010-08-
06 09:23:01.137862514 -0400
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
2010-08-06
10:44:06.381864367 -0400
@@ -79,6 +79,8 @@
extern void usb_ohci_init(const struct ohci_hcd_omap_platform_data
*pdata);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
Index:
RE: DSS2 patch series
Hi, -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Thursday, August 05, 2010 1:40 PM To: Taneja, Archit Cc: Semwal, Sumit; linux-omap@vger.kernel.org Subject: RE: DSS2 patch series On Thu, 2010-08-05 at 09:06 +0200, ext Taneja, Archit wrote: Hi, Also, we should think how to reduce if (cpu_is_omap44xx()) lines. There should be some kind of DSS capability list somewhere, which would tell the features available. I haven't thought this more, but it'd be very nice if we could use the DSS HW version number to decide what features there are. However, TI answered that information about DSS HW version numbers is not available, and thus cannot be used =(. Perhaps you could try to dig out some information from inside TI? I read the DSS_REVISON, DISPC_REVISION etc registers on 3430, 3630, 4430: 3430: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 3630: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 4430: DSS rev 4.0, DISPC rev 4.0, DSI rev 3.0, RFBI rev 3.5 I haven't tried on OMAP2 yet.. Don't you think these revision numbers are enough to differentiate the features of each IP block? Perhaps. The problem is, I don't know what the version numbers mean, ie. when are they changed, what are the changes. I would hope you that you could find some internal info inside TI that would explain the differences =). [Archit] I have collected some information about what these revision numbers mean from the TI folks. The following is what I have gathered: -For each broad version of OMAP, like OMAP3430, OMAP3630, OMAP4430 and so on, there is an independent revision list. These are changed/incremented when the corresponding IP blocks are modified. The numbers which we see are probably the ones which were chosen to put into the silicon. So, it is possible that the revision numbers of ES_1 of OMAP3430 is exactly the same as the ES_1 of OMAP3630 even if the IP blocks have changed. This is what is seen in the prints of the revision of 3430 and 3630 I sent in the previous mail. These revision numbers are hence useful only within the revisions of a particular OMAP. It looks like that there is no single revision chain since OMAP2. -After discussions with more TI DSS folks, it seems that some changes that we may need to make in DSS software may not be dependent on the DSS hardware at all. For example, the patch OMAP3630:DSS2: Updating MAX divider value was introduced because of a change in PRCM. So it seems that we will need to have omap2, omap3 and omap4 checks , best we can do is prevent them from scattering around, i.e have them at a single place during initialization. How do you think we can clean things up? Archit We can of course reverse engineer the version numbers, and hope that we decipher them correctly. For OMAP3430/3630/4430 the differences look clear. But how about OMAP rev changes? For example, at some 3430 revision the bitfield lengths of video timing registers were changed. Does it show on DSS/DISPC version numbers? I don't think I have boards with those revs, so I can't check. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [RFC] Remove the debug print noise
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shubhrajyoti D
Sent: Monday, August 02, 2010 6:18 PM
To: linux-omap@vger.kernel.org
Cc: Datta, Shubhrajyoti
Subject: [PATCH] [RFC] Remove the debug print noise
This patch intends to make the i2cdetect more readable.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7674efb..3a97d2c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -626,7 +626,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (r 0)
return r;
if (r == 0) {
- dev_err(dev-dev, controller timed out\n);
+ dev_dbg(dev-dev, controller timed out\n);
Did you compile the code? I thought it would be as below:
dev_dbg(dev-dev, controller timed out\n);
omap_i2c_init(dev);
return -ETIMEDOUT;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for platform device implementation
On 8/10/2010 9:20 AM, Basak, Partha wrote:
From: Varadarajan, Charulatha
Sent: Tuesday, August 10, 2010 10:49 AM
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 3:51 AM
Charulatha Vch...@ti.com writes:
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init()
does
the module init by clearing the status register and initializing the
GPIO control register. omap_gpio_chip_init() initializes the chip
request,
free, get, set and other function pointers and sets the gpio irq
handler.
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
[...]
+static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
+{
+ if (cpu_class_is_omap2()) {
+ if (cpu_is_omap44xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_IRQSTATUSCLR0);
+ __raw_writel(0x, bank-base +
+OMAP4_GPIO_DEBOUNCENABLE);
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
+ } else if (cpu_is_omap34xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQENABLE1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQSTATUS1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_DEBOUNCE_EN);
+
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48306814);
This autoidle stuff should be removed in this series as setting this is
handled by the hwmod layer.
Okay.
This code is incorrectly setting the PRCM_SYSCONFIG(0x48306814) register inside
GPIO module which is incorrect. Ideally it should be moved to generic code like
prcm_setup_regs() inside PM44xx.c/PM34xx.c. Having said that, the reset value
of PRCM_SYSCONFIG is 0x01, so it would be safe just to remove this.
That's weird, do you know where it come from? Maybe it is re-enable
because someone disable it at some point?
It is indeed a dirty hack, but it will be good to understand the
rational, if any?
The code is from that commit: 5492fb1a ARM: OMAP: Add 3430 gpio support
from Khasim Syed Mohammed (Added in Cc).
It seems to be a bad copy paste of the 2420 code (omap_writel(1 0,
0x48019010)). That one is indeed changing the GPIO SYSCONFIG.
Now, coming to setting of AutoIdle (in CM_AUTOIDLE_XXX registers), even though
prcm_reg_ids are being populated, hwmod framework is not setting these
anywhere, all CM_AutoIdle settings are being done one-time in side
prcm_setup_regs().
In this case, Kevin was referring to the SYSCONFIG autoidle setting not
the PRCM one. But the following point is still valid.
Kevin, as you pointed out this needs to be done in the framework.
Yep, good point, it was indeed already suggested by the comment:
/*
* Enable interface clock autoidle for all modules.
* Note that in the long run this should be done by clockfw
*/
Except that doing that in hwmod make more sense now. hwmod probably
didn't exist at that time.
Everything is in place in the hwmod prcm struct to set this setting from
the hwmod core code.
Can we do it as part of enabling the slave clocks? How does the following look?
static int _enable_clocks(struct omap_hwmod *oh)
{
int i;
pr_debug(omap_hwmod: %s: enabling clocks\n, oh-name);
if (oh-_clk)
clk_enable(oh-_clk);
if (oh-slaves_cnt 0) {
for (i = 0; i oh-slaves_cnt; i++) {
struct omap_hwmod_ocp_if *os = oh-slaves[i];
struct clk *c = os-_clk;
if (c (os-flags OCPIF_SWSUP_IDLE))
clk_enable(c);
else
/*TODO: Set CM_AutoIdle here*/
}
}
/* The opt clocks are controlled by the device driver. */
return 0;
}
It should be done only once, so it is better to do that at _setup time
instead.
Please note that this is an OMAP23 setting only. That bit does not
exist anymore in OMAP4.
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 V2 6/8] usb: musb: Offmode fix for idle path
Hello. Kalliguddi, Hema wrote: With OMAP core-off support musb was not functional as context was getting lost after wakeup from core-off. And also musb was blocking the core-off after loading the gadget driver even with no cable connected sometimes. Added the conext save/restore api in the platform layer which will be called in the idle and wakeup path. Changed the usb sysconfig settings as per the usbotg functional spec. When the device is not active, configure to force idle and force standby mode. When it is being used, configure in smart standby and smart idle mode. So while attempting to coreoff the usb is configured to force standby and force idle mode, after wakeup configured in smart idle and smart standby. Signed-off-by: Hema HK hem...@ti.com Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com [...] Index: linux-omap-pm/drivers/usb/musb/musb_core.c === --- linux-omap-pm.orig/drivers/usb/musb/musb_core.c 2010-08-06 09:24:21.069863329 -0400 +++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06 10:44:06.369863527 -0400 @@ -2427,11 +2427,6 @@ } musb_save_context(musb); - - if (musb-set_clock) - musb-set_clock(musb-clock, 0); - else - clk_disable(musb-clock); spin_unlock_irqrestore(musb-lock, flags); return 0; } @@ -2443,12 +2438,6 @@ if (!musb-clock) return 0; - - if (musb-set_clock) - musb-set_clock(musb-clock, 1); - else - clk_enable(musb-clock); - musb_restore_context(musb); The same question again: are you sure that clocks are auto-gated on non-OMAP platfroms? Bon Lui confirmed that there is no clock for blackfin. What about DaVinci (and the coming DA8xx)? WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] omap2: fix assorted compiler warnings
This patch fixes these compiler warnings:
CC arch/arm/mach-omap2/mux.o
arch/arm/mach-omap2/mux.c: In function 'omap_mux_init_gpio':
arch/arm/mach-omap2/mux.c:90: warning: 'gpio_mux' may be used uninitial
ized in this function
CC arch/arm/plat-omap/gpio.o
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_resume_after_idle':
arch/arm/plat-omap/gpio.c:2152: warning: 'l' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_prepare_for_idle':
arch/arm/plat-omap/gpio.c:2085: warning: 'l2' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c:2085: warning: 'l1' may be used uninitialized
in this function
CC arch/arm/mach-omap2/board-omap4panda.o
arch/arm/mach-omap2/board-omap4panda.c: In function 'omap4_panda_init':
arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 's
tatus'
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |2 --
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
}
static void __init omap4_panda_init(void)
{
- int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
int __init omap_mux_init_gpio(int gpio, int val)
{
struct omap_mux_entry *e;
- struct omap_mux *gpio_mux;
+ struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 9b7e354..ba3b9ab 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2082,7 +2082,7 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
if (bank-dbck_enable_mask)
clk_disable(bank-dbck);
@@ -2149,7 +2149,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
if (bank-dbck_enable_mask)
clk_enable(bank-dbck);
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for platform device implementation
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, August 10, 2010 4:15 PM
To: Basak, Partha
Cc: Varadarajan, Charulatha; Kevin Hilman; linux-omap@vger.kernel.org;
p...@pwsan.com; Nayak, Rajendra; Syed Mohammed, Khasim
Subject: Re: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for
platform device implementation
On 8/10/2010 9:20 AM, Basak, Partha wrote:
From: Varadarajan, Charulatha
Sent: Tuesday, August 10, 2010 10:49 AM
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 3:51 AM
Charulatha Vch...@ti.com writes:
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init()
does
the module init by clearing the status register and initializing the
GPIO control register. omap_gpio_chip_init() initializes the chip
request,
free, get, set and other function pointers and sets the gpio irq
handler.
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
[...]
+static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
+{
+if (cpu_class_is_omap2()) {
+if (cpu_is_omap44xx()) {
+__raw_writel(0x, bank-base +
+OMAP4_GPIO_IRQSTATUSCLR0);
+__raw_writel(0x, bank-base +
+ OMAP4_GPIO_DEBOUNCENABLE);
+/* Initialize interface clk ungated, module
enabled */
+__raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
+} else if (cpu_is_omap34xx()) {
+__raw_writel(0x, bank-base +
+OMAP24XX_GPIO_IRQENABLE1);
+__raw_writel(0x, bank-base +
+OMAP24XX_GPIO_IRQSTATUS1);
+__raw_writel(0x, bank-base +
+OMAP24XX_GPIO_DEBOUNCE_EN);
+
+/* Initialize interface clk ungated, module
enabled */
+__raw_writel(0, bank-base +
OMAP24XX_GPIO_CTRL);
+/* Enable autoidle for the OCP interface */
+omap_writel(1 0, 0x48306814);
This autoidle stuff should be removed in this series as setting this
is
handled by the hwmod layer.
Okay.
This code is incorrectly setting the PRCM_SYSCONFIG(0x48306814) register
inside GPIO module which is incorrect. Ideally it should be moved to
generic code like prcm_setup_regs() inside PM44xx.c/PM34xx.c. Having said
that, the reset value of PRCM_SYSCONFIG is 0x01, so it would be safe just
to remove this.
That's weird, do you know where it come from? Maybe it is re-enable
because someone disable it at some point?
It is indeed a dirty hack, but it will be good to understand the
rational, if any?
The code is from that commit: 5492fb1a ARM: OMAP: Add 3430 gpio support
from Khasim Syed Mohammed (Added in Cc).
It seems to be a bad copy paste of the 2420 code (omap_writel(1 0,
0x48019010)). That one is indeed changing the GPIO SYSCONFIG.
Now, coming to setting of AutoIdle (in CM_AUTOIDLE_XXX registers), even
though prcm_reg_ids are being populated, hwmod framework is not setting
these anywhere, all CM_AutoIdle settings are being done one-time in side
prcm_setup_regs().
In this case, Kevin was referring to the SYSCONFIG autoidle setting not
the PRCM one. But the following point is still valid.
Kevin, as you pointed out this needs to be done in the framework.
Yep, good point, it was indeed already suggested by the comment:
/*
* Enable interface clock autoidle for all modules.
* Note that in the long run this should be done by clockfw
*/
Except that doing that in hwmod make more sense now. hwmod probably
didn't exist at that time.
Everything is in place in the hwmod prcm struct to set this setting from
the hwmod core code.
Can we do it as part of enabling the slave clocks? How does the
following look?
static int _enable_clocks(struct omap_hwmod *oh)
{
int i;
pr_debug(omap_hwmod: %s: enabling clocks\n, oh-name);
if (oh-_clk)
clk_enable(oh-_clk);
if (oh-slaves_cnt 0) {
for (i = 0; i oh-slaves_cnt; i++) {
struct omap_hwmod_ocp_if *os = oh-slaves[i];
struct clk *c = os-_clk;
if (c (os-flags OCPIF_SWSUP_IDLE))
clk_enable(c);
else
/*TODO: Set CM_AutoIdle here*/
}
}
/* The opt clocks
[APPLIED] [PATCH] omap3: id: fix 3630 rev detection
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 5c61cf9fcab4ff75af9403bb378e772b74e4ddd1 PatchWorks http://patchwork.kernel.org/patch/117282/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=5c61cf9fcab4ff75af9403bb378e772b74e4ddd1 -- To unsubscribe from this list: send the line unsubscribe 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] [RFC] Remove the debug print noise
On Tue, Aug 10, 2010 at 12:39:32PM +0200, ext DebBarma, Tarun Kanti wrote:
@@ -626,7 +626,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (r 0)
return r;
if (r == 0) {
- dev_err(dev-dev, controller timed out\n);
+ dev_dbg(dev-dev, controller timed out\n);
Did you compile the code? I thought it would be as below:
dev_dbg(dev-dev, controller timed out\n);
read the code more carefully. Check the definition of struct
omap_i2c_dev. It holds a pointer to a struct device already.
--
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
RE: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 4:36 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: Re: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform
device
Charulatha V ch...@ti.com writes:
@@ -650,21 +511,28 @@ static void _set_gpio_debounce(struct gpio_bank
*bank, unsigned gpio,
__raw_writel(debounce, reg);
reg = bank-base;
- if (cpu_is_omap44xx())
+ if (bank-method == METHOD_GPIO_44XX)
reg += OMAP4_GPIO_DEBOUNCENABLE;
else
reg += OMAP24XX_GPIO_DEBOUNCE_EN;
val = __raw_readl(reg);
+ if (!bank-dbck) {
+ struct platform_device *pdev = to_platform_device(bank-dev);
+ struct omap_device *odev = to_omap_device(pdev);
insert empty line
+ if (odev-hwmods[0]-opt_clks-_clk)
+ bank-dbck = odev-hwmods[0]-opt_clks-_clk;
This is not correct always as opt_clks points to an array of optional clocks
which can have more than one element.
The correct approach would be to scan through the list of optional clocks and
pick up the one with role === dbclk.
As was discussed in Bangalore, drivers should have no knowledge of hwmod
internals.
Instead, please propose an API to hwmod for getting the optional
clock(s), or possibly cleaner, an API to directly enable/disable
optional clocks for an omap_device.
As per our discussion with Paul you during workshop, I believe, optional
clock control should be done using clock APIs. So, I would go by your
suggestion 1 of exposing an API to expose the optional clocks in the hwmod,
something like:
struct omap_hwmod_opt_clk * omap_hwmod_get_opt_clks(struct omap_hwmod
*oh);
If agreed, Charu will send updated patch.
Kevin
+ if (IS_ERR(bank-dbck))
+ dev_err(bank-dev, Could not get gpio dbck\n);
+ }
+
--
To unsubscribe from this list: send the line unsubscribe 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 6/8] usb: musb: Offmode fix for idle path
Hi, -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Tuesday, August 10, 2010 4:50 PM To: Kalliguddi, Hema Cc: Sergei Shtylyov; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman Subject: Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path Hello. Kalliguddi, Hema wrote: With OMAP core-off support musb was not functional as context was getting lost after wakeup from core-off. And also musb was blocking the core-off after loading the gadget driver even with no cable connected sometimes. Added the conext save/restore api in the platform layer which will be called in the idle and wakeup path. Changed the usb sysconfig settings as per the usbotg functional spec. When the device is not active, configure to force idle and force standby mode. When it is being used, configure in smart standby and smart idle mode. So while attempting to coreoff the usb is configured to force standby and force idle mode, after wakeup configured in smart idle and smart standby. Signed-off-by: Hema HK hem...@ti.com Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com [...] Index: linux-omap-pm/drivers/usb/musb/musb_core.c === --- linux-omap-pm.orig/drivers/usb/musb/musb_core.c 2010-08-06 09:24:21.069863329 -0400 +++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06 10:44:06.369863527 -0400 @@ -2427,11 +2427,6 @@ } musb_save_context(musb); - - if (musb-set_clock) - musb-set_clock(musb-clock, 0); - else - clk_disable(musb-clock); spin_unlock_irqrestore(musb-lock, flags); return 0; } @@ -2443,12 +2438,6 @@ if (!musb-clock) return 0; - - if (musb-set_clock) - musb-set_clock(musb-clock, 1); - else - clk_enable(musb-clock); - musb_restore_context(musb); The same question again: are you sure that clocks are auto-gated on non-OMAP platfroms? Bon Lui confirmed that there is no clock for blackfin. What about DaVinci (and the coming DA8xx)? I checked with Ajay, it is not auto gated for for Davinci so I can't just remove this. I am thinking of adding a member variable(clk_autogated) in them usb_hdrc_platform_data structure and check this in the musb_suspend() And musb_resume() APIs. Do you see any problem with it? Regards, Hema WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe 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: don't power off a panel twice
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now add a variable panel_enabled
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-generic.c | 11 +++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 11 +++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 +++
drivers/video/omap2/displays/panel-taal.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c| 11 +++
.../video/omap2/displays/panel-tpo-td043mtea1.c|9 +
6 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..607f11a 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -22,6 +22,8 @@
#include plat/display.h
+static int panel_enabled;
+
static struct omap_video_timings generic_panel_timings = {
/* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
.x_res = 640,
@@ -39,6 +41,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -48,6 +53,7 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err1;
}
+ panel_enabled = 1;
return 0;
err1:
@@ -58,10 +64,14 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (panel_enabled == 0)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
omapdss_dpi_display_disable(dssdev);
+ panel_enabled = 0;
}
static int generic_panel_probe(struct omap_dss_device *dssdev)
@@ -155,6 +165,7 @@ static struct omap_dss_driver generic_driver = {
static int __init generic_panel_drv_init(void)
{
+ panel_enabled = 0;
return omap_dss_register_driver(generic_driver);
}
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..b5205d4 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -24,6 +24,8 @@
#include plat/display.h
+static int panel_enabled;
+
static struct omap_video_timings sharp_lq_timings = {
.x_res = 480,
.y_res = 272,
@@ -43,6 +45,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -55,6 +60,7 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err1;
}
+ panel_enabled = 1;
return 0;
err1:
@@ -65,6 +71,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (panel_enabled == 0)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
@@ -72,6 +81,7 @@ static void sharp_lq_panel_power_off(struct omap_dss_device
*dssdev)
msleep(100);
omapdss_dpi_display_disable(dssdev);
+ panel_enabled = 0;
}
static int sharp_lq_panel_probe(struct omap_dss_device *dssdev)
@@ -146,6 +156,7 @@ static struct omap_dss_driver sharp_lq_driver = {
static int __init sharp_lq_panel_drv_init(void)
{
+ panel_enabled = 0;
return omap_dss_register_driver(sharp_lq_driver);
}
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..3750fdc 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -31,6 +31,8 @@ struct sharp_data {
struct backlight_device *bl;
};
+static int panel_enabled;
+
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
.y_res = 640,
@@ -135,6 +137,9 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
int r = 0;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -147,6 +152,7 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
if (r)
goto err1;
}
+ panel_enabled = 1;
return 0;
err1:
@@ -157,6 +163,9 @@ err0:
static void sharp_ls_power_off(struct
[APPLIED] [PATCHv2] omap2: fix assorted compiler warnings
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): fc39c9bf6e2e67a4c11e926ec6b2bb1093defd50 PatchWorks http://patchwork.kernel.org/patch/118553/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=fc39c9bf6e2e67a4c11e926ec6b2bb1093defd50 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap: n8x0: Audio update to N810
* Jarkko Nikula jhnik...@gmail.com [100809 10:50]: Hi With this set and a fix [1] it is possible to get ALSA SoC on N810 working. This set is generated against mainline commit e320cea but applies also to linux-omap (board-n8x0.c has cbus patches in linux-omap). I've added these into omap for-next for 2.6.37. Let me know if these should go in along with other ASoC patches. Regards, Tony 1. http://marc.info/?l=linux-omapm=128109830113485w=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: [PATCH] omap3: Remove non-existent config option
Tony, -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Friday, August 06, 2010 1:03 PM To: t...@atomide.com; Kanigeri, Hari Cc: Marathe, Yogesh; linux-omap@vger.kernel.org; Premi, Sanjeev Subject: Re: [PATCH] omap3: Remove non-existent config option Hi Hari, On Thu, 5 Aug 2010 17:12:11 +0200 ext Kanigeri, Hari h-kanige...@ti.com wrote: Hiroshi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU Sent: Wednesday, August 04, 2010 6:20 AM To: t...@atomide.com Cc: Marathe, Yogesh; linux-omap@vger.kernel.org; Premi, Sanjeev Subject: Re: [PATCH] omap3: Remove non-existent config option From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH] omap3: Remove non-existent config option Date: Wed, 4 Aug 2010 13:11:47 +0200 * Marathe, Yogesh yogesh_mara...@ti.com [100803 11:03]: ping.. Hiroshi ack/nak? Nak. http://www.spinics.net/lists/linux-omap/msg32869.html tidspbridge is in staging now. Can you please elaborate what this means ? Yogesh patch enables the IOMMU for BRIDGE by default and we need this as IOMMU is going to get use in 3430. Ok, I misunderstood this intention, sorry. Tony, please put this into your queue for next merge. Is this patch taken? Regards, Yogesh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CONFIG_CPU_IDLE broken for N900
Hi, When I enable CONFIG_CPU_IDLE and boot kernel, it hangs around the point when it switches to user space. I am able to reproduce this for 2.6.35 on linux-omap and linux-2.6 trees. Has anyone else noticed the same thing for omap3 based boards? Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2: Fix a cpu type check problem.
cpu_is_omap3517() and cpu_is_omap3505() are the subgroups of cpu_is_omap34xx(),
so we should check cpu_is_omap3517() and cpu_is_omap3505() first, then check
cpu_is_omap34xx().
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 138646d..dfdce2d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3417,7 +3417,13 @@ int __init omap3xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg = CK_3XXX;
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap3517()) {
+ cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
+ cpu_clkflg |= CK_3517;
+ } else if (cpu_is_omap3505()) {
+ cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
+ cpu_clkflg |= CK_3505;
+ } else if (cpu_is_omap34xx()) {
cpu_mask = RATE_IN_3XXX;
cpu_clkflg |= CK_343X;
@@ -3432,12 +3438,6 @@ int __init omap3xxx_clk_init(void)
cpu_mask |= RATE_IN_3430ES2PLUS;
cpu_clkflg |= CK_3430ES2;
}
- } else if (cpu_is_omap3517()) {
- cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
- cpu_clkflg |= CK_3517;
- } else if (cpu_is_omap3505()) {
- cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
- cpu_clkflg |= CK_3505;
}
if (omap3_has_192mhz_clk())
--
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: CONFIG_CPU_IDLE broken for N900
On Tue, 2010-08-10 at 14:21 +0200, Palande Ameya (Nokia-MS/Helsinki) wrote: Hi, When I enable CONFIG_CPU_IDLE and boot kernel, it hangs around the point when it switches to user space. I am able to reproduce this for 2.6.35 on linux-omap and linux-2.6 trees. Has anyone else noticed the same thing for omap3 based boards? Broken on linux-omap-pm as well! Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe 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 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, August 10, 2010 5:51 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak, Rajendra; Basak, Partha Subject: Re: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class Charulatha V ch...@ti.com writes: This patch makes GPIO driver to use dev_pm_ops instead of sysdev_class. With this approach, gpio_bank_suspend gpio_bank_resume are not part of sys_dev_class. According to this patch, a GPIO bank relinquishes the clock using PM runtime APIs when all the gpios in that bank are freed. This does not match the code. The only clock associated with a GPIO hwmod is the optional clock for the debounce clock. This clock is managed by the driver itself, not by using the PM runtime API. It also relinquishes the clocks in the idle-path too, as it is possible to have a GPIO bank requested and still allow PER domain to go to OFF state. This doesn't make sense to me. What clocks are you referring to? The main clock is there for OMAP24xx, but not relevant for OMAP3 4. In the idle path (interrupt disabled context), PM runtime APIs cannot be used as they are not mutex-free functions. Hence omap_device APIs are used in the idle and resume after idle path. This needs much more fleshing out. Exactly what mutexes are causing the problems here. As pointed out in previous discussions, the ones in the PM runtime core should not be a problem in this path. Therefore, I'll assume the problems are coming from the mutexes when the device code (mach-omap2/gpio.c) calls into the hwmod layer. More on this in comments on the next patch. Sorry, this has not been documented correctly. The issue has more to do unconditional enabling of interrupts. We have received a patch from you on using pm_runtime functions in Idle path. We will try on GPIO and revert back. To summarize, 1. pm_runtime_get_sync() for any gpio bank is called when one of the gpios is requested on the bank, in which, no other gpio is being used (when mod_usage becomes non-zero) 2. omap_device_enable() is called during gpio resume after idle, only if the particular bank is being used (if mod_usage is non-zero) context is saved/restored in the idle path, but... 3. pm_runtime_put_sync() is called when the last used gpio in that gpio bank is freed (when mod_usage becomes zero) in this path, the bank is now runtime suspended, but context has not been saved for it. That should be fine, since this bank is no longer used, but now let's assume there was an off-mode transition and context is lost. Then, gpio_request() is called which will trigger a pm_runtime_get_sync() and gpio_bank_runtime_resume() will be called. In this case, it's not terribly clear that runtime_resume is doing sane things if context has just been lost. Seems like runtime_resume should be a nop in this case since any re-init will be be done in gpio_request(). Runtime_suspend/resume for GPIO is not doing any save/restore context. In that sense, they are NOP. Context save/restore is taken care of only in the Idle path based on target power state and last power state respectively. 4. omap_device_idle() is called during idle, if the particular bank is being used (if mod_usage is non-zero) This mixture of pm_runtime_* and omap_device_* APIs is confusing at best. There should be a single path into the drivers runtime_suspend hooks. Namely, when pm_runtime_put_* is called and the usecount goes to zero. If you can't use the runtime PM APIs, then we need to understand *exactly* why and work on a solution for that particular problem. On my omap34xx/omap3evm, I had to disable the omap_device_* calls in the idle path since as they were causing strange crashes, and as stated above, I'm not sure what the purpose is. With this patch, GPIO's prepare_for_idle and resume_after_idle APIs makes use of the parameter save_context and restore_context respectively inorder to identify if save context/restore context needs to be done. Why? Links to related discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32833.html For suspend/resume path to work, this patch has dependency of 1. reverting the following patch: OMAP: bus-level PM: enable use of runtime PM API for suspend/resume http://dev.omapzoom.org/?p=swarch/linux-omap-adv.git;a=commitdiff; h=8041359e18e49bf8a3d41f15894db9e476f3a8fc (or) 2. Remove the locking in the omap_hwmod_for_each* function Did you mean 'and' instead of 'or'? If you meant 'or', then clearly (20 is preferred over (1), and I have a patch to fix that in the current pm-wip/runtime branch. If you meant 'and', then you need to describe the root cause for (1). Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Basak, Partha p-bas...@ti.com
Re: [PATCH] omap3: Remove non-existent config option
* Marathe, Yogesh yogesh_mara...@ti.com [100810 15:12]: From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] please put this into your queue for next merge. Is this patch taken? I'll add this to omap for-next queue. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap: n8x0: Audio update to N810
On Tue, 10 Aug 2010 15:07:34 +0300 Tony Lindgren t...@atomide.com wrote: With this set and a fix [1] it is possible to get ALSA SoC on N810 working. This set is generated against mainline commit e320cea but applies also to linux-omap (board-n8x0.c has cbus patches in linux-omap). I've added these into omap for-next for 2.6.37. Let me know if these should go in along with other ASoC patches. Ok, good. This is independent set so no need for any special procedure :-) -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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: CONFIG_CPU_IDLE broken for N900
On Tue, 10 Aug 2010 15:35:18 +0300 Ameya Palande ameya.pala...@nokia.com wrote: When I enable CONFIG_CPU_IDLE and boot kernel, it hangs around the point when it switches to user space. I am able to reproduce this for 2.6.35 on linux-omap and linux-2.6 trees. Has anyone else noticed the same thing for omap3 based boards? Broken on linux-omap-pm as well! I'm able to reproduce with 2.6.35-rc1 but not with l-o head. It seems that the commit below fixes this. commit c786bcf12e092802496f1bc440b2b189144612a5 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Jun 3 17:13:22 2010 + OMAP3: PM: fix IO daisy chain enable to use PM_WKEN reg -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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: CONFIG_CPU_IDLE broken for N900
Hi Jarkko, On Tue, 2010-08-10 at 15:03 +0200, ext Jarkko Nikula wrote: On Tue, 10 Aug 2010 15:35:18 +0300 Ameya Palande ameya.pala...@nokia.com wrote: When I enable CONFIG_CPU_IDLE and boot kernel, it hangs around the point when it switches to user space. I am able to reproduce this for 2.6.35 on linux-omap and linux-2.6 trees. Has anyone else noticed the same thing for omap3 based boards? Broken on linux-omap-pm as well! I'm able to reproduce with 2.6.35-rc1 but not with l-o head. It seems that the commit below fixes this. commit c786bcf12e092802496f1bc440b2b189144612a5 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Jun 3 17:13:22 2010 + OMAP3: PM: fix IO daisy chain enable to use PM_WKEN reg Just tested it on linux-omap with omap3_defconfig and found that it is broken. When kernel bootup is complete, and it switches to user space, device hangs. When I disable CPU IDLE, it works.. Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe 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 6/8] usb: musb: Offmode fix for idle path
Hello.
Kalliguddi, Hema wrote:
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hema HK
Sent: Friday, August 06, 2010 10:57 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren;
Kevin Hilman
Subject: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
From: Hema HK hem...@ti.com
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and force standby
mode.
When it is being used, configure in smart standby and smart idle mode.
So while attempting to coreoff the usb is configured to force standby and
force idle mode, after wakeup configured in smart idle and smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Index: linux-omap-pm/drivers/usb/musb/omap2430.c
===
--- linux-omap-pm.orig/drivers/usb/musb/omap2430.c 2010-08-06
09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/omap2430.c 2010-08-06
10:44:30.093914217 -0400
[...]
@@ -259,15 +273,42 @@
void musb_platform_save_context(struct musb *musb,
struct musb_context_registers *musb_context)
{
- musb_context-otg_sysconfig = musb_readl(musb-mregs, OTG_SYSCONFIG);
- musb_context-otg_forcestandby = musb_readl(musb-mregs,
OTG_FORCESTDBY);
+ /*
+* As per the omap-usbotg specification, configure it to forced standby
+* and force idle mode when no activity on usb.
+*/
+ void __iomem *musb_base = musb-mregs;
+
Just to clarify, have you already taken care of ioremap() /
request_mem_region() for musb_base?
This is already done.
Not quite. MUSB driver doesn't call request_mem_region().
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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: CONFIG_CPU_IDLE broken for N900
On Tue, 10 Aug 2010 16:43:16 +0300 Ameya Palande ameya.pala...@nokia.com wrote: I'm able to reproduce with 2.6.35-rc1 but not with l-o head. It seems that the commit below fixes this. commit c786bcf12e092802496f1bc440b2b189144612a5 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Jun 3 17:13:22 2010 + OMAP3: PM: fix IO daisy chain enable to use PM_WKEN reg Just tested it on linux-omap with omap3_defconfig and found that it is broken. When kernel bootup is complete, and it switches to user space, device hangs. When I disable CPU IDLE, it works.. And I was too fast, problem is there in l-o head but it seems to hang in different places for me. Above commit removed Wake up daisy chain activation failed. error that was slowing down the boot but this issue seems to be different. I can boot up to Debian console login but system hangs during user space boot if I send something over serial. This happend with omap3_defconfig in l-o head using N900. However, the same kernel works fine on Beagle. Can this be some silicon dependent issue? -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2: Fix a cpu type check problem.
On 08/10/10 15:36, Stanley.Miao wrote:
cpu_is_omap3517() and cpu_is_omap3505() are the subgroups of
cpu_is_omap34xx(),
so we should check cpu_is_omap3517() and cpu_is_omap3505() first, then check
cpu_is_omap34xx().
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
Tested-by: Igor Grinberg grinb...@compulab.co.il
I've just ran into this yesterday evening.
Having a patch for this on the next day made me :)
Tested on AM3517.
---
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 138646d..dfdce2d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3417,7 +3417,13 @@ int __init omap3xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg = CK_3XXX;
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap3517()) {
+ cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
+ cpu_clkflg |= CK_3517;
+ } else if (cpu_is_omap3505()) {
+ cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
+ cpu_clkflg |= CK_3505;
+ } else if (cpu_is_omap34xx()) {
cpu_mask = RATE_IN_3XXX;
cpu_clkflg |= CK_343X;
@@ -3432,12 +3438,6 @@ int __init omap3xxx_clk_init(void)
cpu_mask |= RATE_IN_3430ES2PLUS;
cpu_clkflg |= CK_3430ES2;
}
- } else if (cpu_is_omap3517()) {
- cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
- cpu_clkflg |= CK_3517;
- } else if (cpu_is_omap3505()) {
- cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
- cpu_clkflg |= CK_3505;
}
if (omap3_has_192mhz_clk())
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe 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] mailbox: change full flag per mailbox queue instead of global
Hi Hiroshi,
On Mon, Jun 14, 2010 at 7:51 PM, 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
It looks like this fix didn't get thru - can you please review and ack/nack ?
Thanks,
Ohad.
---
arch/arm/plat-omap/include/plat/mailbox.h | 1 +
arch/arm/plat-omap/mailbox.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
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] ARM: OMAP: Beagle: support MMC gpio_wp differences on xM
The omap3630 based BeagleBoard xM uses a MicroSD card slot with
no write protection.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 87969c7..15929be 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -185,7 +185,9 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- if (system_rev = 0x20 system_rev = 0x34301000) {
+ if (cpu_is_omap3630()) {
+ mmc[0].gpio_wp = -EINVAL;
+ } else if (system_rev = 0x20 system_rev = 0x34301000) {
omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] omap: mailbox: convert block api to kfifo
Hi Rene, On Wed, Jun 9, 2010 at 8:38 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Jun 8, 2010 at 7:16 PM, Sapiens, Rene rene.sapi...@ti.com wrote: In mbox_rx_work() you are removing the lines that enable back the mbox irq for the RX case, but inside __mbox_rx_interrupt() this interrupt is disabled in the case that the kfifo for Rx mailbox gets full. So I think that we need to enable it back as soon as there is space in this kfifo. Actually these irq on/off lines are not part of my patch; they are introduced by patch 05/10 on top of which my patches were rebased. Nevertheless I agree with you - the kfifo migration patch should not affect that irq on/off behavior. It's probably just a rebase gotcha. But now that you point me to this irq on/off thing, it looks a bit broken in terms of multiple concurrent mbox support since it relies on a global rq_full state. I guess it'd be better to hold that rq_full state in the relevant mbox queue state itself. Fernando what do you think ? Yes, you are right Ohad. Only should be disable the new message interrupt of the mailbox which kfifo is full. Once Fernando's fix will get thru, we will be able to fix the rebase error that you pointed out. Unfortunately I will not have any email access in the next 3 weeks, and I was hoping maybe you could submit a fix for this once Fernando's fix is accepted ? I would really like us to fix this early in the days of 2.6.36, maybe even during the merge window. Thanks a lot, Ohad. regards, Fernando. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, August 09, 2010 9:01 PM
To: Basak, Partha
Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja,
Govindraj; Varadarajan, Charulatha
Subject: Re: Issues with calling pm_runtime functions in
platform_pm_suspend_noirq/IRQ disabled context.
Basak, Partha p-bas...@ti.com writes:
Finally, we have omap_sram_idle():
In particular, for USB, while executing SRAM_Idle, is we use
pm_runtime
functions, we see spurious IO-Pad interrupts.
Your message doesn't specify what PM runtime functions you are
executing.
But if those functions are calling mutex_lock(), then they obviously
must
not be called from omap_sram_idle() in interrupt context.
It's not clear from your message why you need to call PM runtime
functions
from the idle loop. I'd suggest that you post the problematic code in
question to the list.
USB issue:
Please refer to the USB patch attached (will be sent to the list as well
in a few minutes)
As I mentioned previously, few drivers like GPIO, USB UART have clock-
disable/enable + context save/restore in Idle path(omap_sram_idle()).
In particular, I am referring to calling of the functions
pm_runtime_put_sync() pm_runtime_get_sync() for USB around wfi.
Now, the following call sequence from omap_sram_idle()will enable IRQs:
pm_runtime_put_sync--
__pm_runtime_put--
pm_runtime_idle--
spin_unlock_irq(),
__pm_runtime_idle(),--
spin_unlock_irq,
spin_unlock_irq
The functions pm_runtime_idle() __ pm_runtime_idle() do not use
spin_lock_irqsave spin_unlock_irqrestore. This leads to enabling of
the interrupts in omap_sram_idle unconditionally, which for USB in
particular is leading to IO-pad interrupt being triggered which does
not come otherwise.
You seem to have correctly identified the problem. Can you try the
patch below (untested) which attempts to address the root cause you've
identified?
Kevin
To work around this problem, instead of using Runtime APIs, we are using
omap_device_enable/disable, which in-turn call to __omap_hwmod_enable/idle
Simply put, I am not talking about grabbing a mutex when interrupts are
disabled, rather of a scenario where interrupts are getting enabled as a
side-effect of calling these functions in omap_sram_idle().
From be3aeea5f8d29c8ce2fa278f48aef849eb682282 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Mon, 9 Aug 2010 08:12:39 -0700
Subject: [PATCH] PM: allow runtime PM get/put from interrupts-disabled
context
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle sequence, interrupts may already be disabled when
runtime PM for these devices is initiated (using the _sync versions of
the runtime PM API.)
Currently, the runtime PM core assumes methods are called with
interrupts enabled. However, if it is called with interrupts
disabled, the internal locking unconditionally enables interrupts, for
example:
pm_runtime_put_sync()
__pm_runtime_put()
pm_runtime_idle()
spin_lock_irq()
__pm_runtime_idle()
spin_unlock_irq() --- interrupts unconditionally
enabled
dev-bus-pm-runtime_idle()
spin_lock_irq()
spin_unlock_irq()
To fix, use the save/restore versions of the spinlock API.
Reported-by: Partha Basak p-bas...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/base/power/runtime.c | 68 ++---
include/linux/pm.h |1 +
2 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index b0ec0e9..b02ef35 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -80,24 +80,24 @@ static int __pm_runtime_idle(struct device *dev)
dev-power.idle_notification = true;
if (dev-bus dev-bus-pm dev-bus-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-
power.lock_flags);
dev-bus-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-type dev-type-pm dev-type-pm-
runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-
power.lock_flags);
dev-type-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-class dev-class-pm
RE: [PATCH 09/10] omap: mailbox: convert block api to kfifo
Hi Ohad, Sure I will do it. Regards, Rene -Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, August 10, 2010 9:43 AM To: Guzman Lugo, Fernando; Sapiens, Rene Cc: Hiroshi DOYU; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kanigeri, Hari Subject: Re: [PATCH 09/10] omap: mailbox: convert block api to kfifo Hi Rene, On Wed, Jun 9, 2010 at 8:38 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Jun 8, 2010 at 7:16 PM, Sapiens, Rene rene.sapi...@ti.com wrote: In mbox_rx_work() you are removing the lines that enable back the mbox irq for the RX case, but inside __mbox_rx_interrupt() this interrupt is disabled in the case that the kfifo for Rx mailbox gets full. So I think that we need to enable it back as soon as there is space in this kfifo. Actually these irq on/off lines are not part of my patch; they are introduced by patch 05/10 on top of which my patches were rebased. Nevertheless I agree with you - the kfifo migration patch should not affect that irq on/off behavior. It's probably just a rebase gotcha. But now that you point me to this irq on/off thing, it looks a bit broken in terms of multiple concurrent mbox support since it relies on a global rq_full state. I guess it'd be better to hold that rq_full state in the relevant mbox queue state itself. Fernando what do you think ? Yes, you are right Ohad. Only should be disable the new message interrupt of the mailbox which kfifo is full. Once Fernando's fix will get thru, we will be able to fix the rebase error that you pointed out. Unfortunately I will not have any email access in the next 3 weeks, and I was hoping maybe you could submit a fix for this once Fernando's fix is accepted ? I would really like us to fix this early in the days of 2.6.36, maybe even during the merge window. Thanks a lot, Ohad. regards, Fernando. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] omap: mailbox: convert block api to kfifo
On Tue, Aug 10, 2010 at 6:00 PM, Sapiens, Rene rene.sapi...@ti.com wrote: Hi Ohad, Sure I will do it. Thanks a lot, Rene ! Ohad. Regards, Rene -Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, August 10, 2010 9:43 AM To: Guzman Lugo, Fernando; Sapiens, Rene Cc: Hiroshi DOYU; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kanigeri, Hari Subject: Re: [PATCH 09/10] omap: mailbox: convert block api to kfifo Hi Rene, On Wed, Jun 9, 2010 at 8:38 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Jun 8, 2010 at 7:16 PM, Sapiens, Rene rene.sapi...@ti.com wrote: In mbox_rx_work() you are removing the lines that enable back the mbox irq for the RX case, but inside __mbox_rx_interrupt() this interrupt is disabled in the case that the kfifo for Rx mailbox gets full. So I think that we need to enable it back as soon as there is space in this kfifo. Actually these irq on/off lines are not part of my patch; they are introduced by patch 05/10 on top of which my patches were rebased. Nevertheless I agree with you - the kfifo migration patch should not affect that irq on/off behavior. It's probably just a rebase gotcha. But now that you point me to this irq on/off thing, it looks a bit broken in terms of multiple concurrent mbox support since it relies on a global rq_full state. I guess it'd be better to hold that rq_full state in the relevant mbox queue state itself. Fernando what do you think ? Yes, you are right Ohad. Only should be disable the new message interrupt of the mailbox which kfifo is full. Once Fernando's fix will get thru, we will be able to fix the rebase error that you pointed out. Unfortunately I will not have any email access in the next 3 weeks, and I was hoping maybe you could submit a fix for this once Fernando's fix is accepted ? I would really like us to fix this early in the days of 2.6.36, maybe even during the merge window. Thanks a lot, Ohad. regards, Fernando. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/2] OMAP4: PRCM: Add prcm_mpu_base to omap_globals
OMAP4 has a local PRCM (for individual CPU control) block.
Hence add a new prcm_mpu_base to handle this in the omap_globals
structure.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/prcm.c |5 +
arch/arm/plat-omap/common.c |1 +
arch/arm/plat-omap/include/plat/common.h |1 +
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index c201374..4df30d0 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -35,6 +35,7 @@
#include prm-regbits-24xx.h
static void __iomem *prm_base;
+static void __iomem *prcm_mpu_base;
static void __iomem *cm_base;
static void __iomem *cm2_base;
@@ -282,6 +283,10 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
prm_base = ioremap(omap2_globals-prm, SZ_8K);
WARN_ON(!prm_base);
}
+ if (omap2_globals-prcm_mpu) {
+ prcm_mpu_base = ioremap(omap2_globals-prcm_mpu, SZ_8K);
+ WARN_ON(!prcm_mpu_base);
+ }
if (omap2_globals-cm) {
cm_base = ioremap(omap2_globals-cm, SZ_8K);
WARN_ON(!cm_base);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3008e71..8603a46 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -338,6 +338,7 @@ static struct omap_globals omap4_globals = {
.tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
.ctrl = OMAP443X_CTRL_BASE,
.prm= OMAP4430_PRM_BASE,
+ .prcm_mpu = OMAP4430_PRCM_MPU_BASE,
.cm = OMAP4430_CM_BASE,
.cm2= OMAP4430_CM2_BASE,
.uart1_phys = OMAP4_UART1_BASE,
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..47baf9d 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -48,6 +48,7 @@ struct omap_globals {
unsigned long sms;/* SDRAM Memory Scheduler */
unsigned long ctrl; /* System Control Module */
unsigned long prm;/* Power and Reset Management */
+ unsigned long prcm_mpu; /* Local MPU PRM */
unsigned long cm; /* Clock Management */
unsigned long cm2;
unsigned long uart1_phys;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/2] Fix prm/cm accessor api's usage on OMAP4
Hi, This RFC patch series fixes the prm and cm accessor api usage which is broken today on OMAP4. OMAP's have always had PRCM split into PRM for power and reset management and CM for clock management. In OMAP4 the split (physically) is not very straight forward and there are instances of clock management control registers in PRM and vice versa. However it still makes sense, even on OMAP4 to logically split PRCM into PRM and CM for better understanding and to avoid adding additonal complexity in higher level frameworks which rely on the accessor api;s to do the low level register accesses. Hence this patch series makes sure that any clock management code can use the cm_read/write* accessor apis (without knowing the physical split) and power and reset management code can use prm_read/write* accessor api;s. regards, Rajendra Rajendra Nayak (2): OMAP4: PRCM: Add prcm_mpu_base to omap_globals OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4 arch/arm/mach-omap2/cm.h |4 +- arch/arm/mach-omap2/prcm-common.h| 58 +++- arch/arm/mach-omap2/prcm.c | 73 -- arch/arm/mach-omap2/prm.h|4 +- arch/arm/plat-omap/common.c |1 + arch/arm/plat-omap/include/plat/common.h |1 + 6 files changed, 112 insertions(+), 29 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
[RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4
OMAP's have always had PRCM split into PRM for power and reset management and CM for clock management. In OMAP4 the split (physically) is not very straight forward and there are instances of clock management control registers in PRM and vice versa. However it still makes sense, even on OMAP4 to logically split PRCM into PRM and CM for better understanding and to avoid adding additonal complexity in higher level frameworks which rely on the accessor api;s to do the low level register accesses. Hence this patch makes sure that any clock management code can use the cm_read/write* accessor apis (without knowing the physical split) and power and reset management code can use prm_read/write* accessor api;s. To do this the submodule offsets within PRM/CM1 and CM2 have additonal info embedded in them specifying what base address to use while trying to access registers in the given submodule. The 16 bit signed submodule offset is defined for OMAP4 as Bit 15| Bit 14:13 | Bit 12:0 Sign bit | base identifier | submodule offset from base For older OMAP's the base identifier is always set to 0. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/cm.h |4 +- arch/arm/mach-omap2/prcm-common.h | 58 --- arch/arm/mach-omap2/prcm.c| 68 ++-- arch/arm/mach-omap2/prm.h |4 +- 4 files changed, 105 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a02ca30..7b7ef09 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -23,9 +23,9 @@ #define OMAP34XX_CM_REGADDR(module, reg) \ OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) #define OMAP44XX_CM1_REGADDR(module, reg) \ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + ((module) (MOD_MASK)) + (reg)) #define OMAP44XX_CM2_REGADDR(module, reg) \ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + ((module) (MOD_MASK)) + (reg)) #include cm44xx.h diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 995b7ed..b93d33e 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -57,10 +57,26 @@ #define BITFIELD(l_bit, u_bit) \ (BITS(u_bit) ~((BITS(l_bit)) 1)) -/* OMAP44XX specific module offsets */ +/* + * OMAP44XX specific module offsets + * The 16 bit submodule offset is defined for OMAP4 as + * Bit 15| Bit 14:13 | Bit 12:0 + * Sign bit | base identifier | submodule offset from base + */ -/* CM1 instances */ +#define DEFAULT_BASE 0x0 +#define PRM_BASE 0x1 +#define PRCM_MPU_BASE 0x2 +#define CM2_BASE 0x3 +#define BASE_ID_SHIFT 13 +#define MOD_MASK ((1 BASE_ID_SHIFT)-1) + +#define PRM_BASE_ID(PRM_BASE BASE_ID_SHIFT) +#define PRCM_MPU_BASE_ID (PRCM_MPU_BASE BASE_ID_SHIFT) +#define CM2_BASE_ID(CM2_BASE BASE_ID_SHIFT) + +/* CM1 instances */ #define OMAP4430_CM1_OCP_SOCKET_MOD0x #define OMAP4430_CM1_CKGEN_MOD 0x0100 #define OMAP4430_CM1_MPU_MOD 0x0300 @@ -71,19 +87,19 @@ /* CM2 instances */ -#define OMAP4430_CM2_OCP_SOCKET_MOD0x -#define OMAP4430_CM2_CKGEN_MOD 0x0100 -#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 -#define OMAP4430_CM2_CORE_MOD 0x0700 -#define OMAP4430_CM2_IVAHD_MOD 0x0f00 -#define OMAP4430_CM2_CAM_MOD 0x1000 -#define OMAP4430_CM2_DSS_MOD 0x1100 -#define OMAP4430_CM2_GFX_MOD 0x1200 -#define OMAP4430_CM2_L3INIT_MOD0x1300 -#define OMAP4430_CM2_L4PER_MOD 0x1400 -#define OMAP4430_CM2_CEFUSE_MOD0x1600 -#define OMAP4430_CM2_RESTORE_MOD 0x1e00 -#define OMAP4430_CM2_INSTR_MOD 0x1f00 +#define OMAP4430_CM2_OCP_SOCKET_MOD0x | CM2_BASE_ID +#define OMAP4430_CM2_CKGEN_MOD 0x0100 | CM2_BASE_ID +#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 | CM2_BASE_ID +#define OMAP4430_CM2_CORE_MOD 0x0700 | CM2_BASE_ID +#define OMAP4430_CM2_IVAHD_MOD 0x0f00 | CM2_BASE_ID +#define OMAP4430_CM2_CAM_MOD 0x1000 | CM2_BASE_ID +#define OMAP4430_CM2_DSS_MOD 0x1100 | CM2_BASE_ID +#define OMAP4430_CM2_GFX_MOD 0x1200 | CM2_BASE_ID +#define OMAP4430_CM2_L3INIT_MOD0x1300 | CM2_BASE_ID +#define OMAP4430_CM2_L4PER_MOD 0x1400 | CM2_BASE_ID +#define OMAP4430_CM2_CEFUSE_MOD0x1600 | CM2_BASE_ID +#define OMAP4430_CM2_RESTORE_MOD 0x1e00 | CM2_BASE_ID +#define
RE: [RFC v.4] omap: hwspinlock: Added hwspinlock driver
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Que, Simon Sent: Wednesday, July 07, 2010 1:55 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ohad Ben-Cohen; Shilimkar, Santosh Subject: [RFC v.4] omap: hwspinlock: Added hwspinlock driver Hello, This is the fourth and final RFC for the hardware spinlock driver. I have incorporated some changes and fixes based on Santosh's comments. Please give your comments. Thanks, Simon = From d4794eff60e5e509581fedaf2660b0d2d92463ab Mon Sep 17 00:00:00 2001 From: Simon Que s...@ti.com Date: Wed, 23 Jun 2010 18:40:30 -0500 Subject: [PATCH] omap: hwspinlock: Added hwspinlock driver Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each hardware spinlock. It will pass spinlock register addresses to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Signed-off-by: Simon Que s...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/hwspinlocks.c| 71 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/hwspinlock.c | 295 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ arch/arm/plat-omap/include/plat/omap44xx.h |2 + 7 files changed, 402 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..5f5c87b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand- m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-$(CONFIG_ARCH_OMAP4) += hwspinlocks.o \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach- omap2/hwspinlocks.c new file mode 100644 index 000..58a6483 --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,71 @@ +/* + * OMAP hardware spinlock device initialization + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Que 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 + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of
Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Hi Catalin,
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Tue, 29 Jun 2010 07:44:23 +0300 (EEST)
From: ext Catalin Marinas catalin.mari...@arm.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Mon, 28 Jun 2010 16:46:12 +0200
Hi,
(and sorry for the delay)
On Fri, 2010-06-18 at 07:04 +0100, Hiroshi DOYU wrote:
This is another version of kmemleak: Fix false positive, which
introduces another alias tree to keep track of all alias address of
each objects, based on the discussion(*1)
You can also find the previous one(*2), which uses special scan area
for alias addresses with a conversion function.
Compared with both methods, it seems that the current one takes a bit
longer to scan as below, tested with 512 elementes of (*3).
kmemleak: Fix false positive with alias:
# time echo scan /mnt/kmemleak
real0m 8.40s
user0m 0.00s
sys 0m 8.40s
kmemleak: Fix false positive with special scan:
# time echo scan /mnt/kmemleak
real0m 3.96s
user0m 0.00s
sys 0m 3.96s
Have you tried without your patches (just the test module but without
aliasing the pointers)? I'm curious what's the impact of your first set
of patches.
IIRC, not much difference against the one with the first patches. I'll
measure it again later.
For our case(*4) to reduce false positives for the 2nd level IOMMU
pagetable allocation, the previous special scan seems to be enough
lightweight, although there might be possiblity to improve alias
one and also I might misunderstand the original proposal of aliasing.
The performance impact is indeed pretty high, though some parts of the
code look over-engineered to me (the __scan_block function with a loop
going through an array of two function pointers - I think the compiler
cannot figure out what to inline). You could just extend the
find_and_get_object() to search both trees under a single spinlock
region (as locking also takes time).
Ok, a good point.
Now there's not much difference with the attached patch, a new version
of alias.
/ # modprobe kmemleak-special-test use_alias=0
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 2.30s
user0m 0.00s
sys 0m 2.30s
/ # modprobe kmemleak-special-test use_alias=1
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 3.91s
user0m 0.00s
sys 0m 3.91s
From a5670d69b2cafe85f6f26f6951097210d3b9917f Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hiroshi.d...@nokia.com
Date: Thu, 17 Jun 2010 13:36:45 +0300
Subject: [PATCH 1/1] kmemleak: Fix false positive with address alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |8 ++
mm/kmemleak.c| 208 +++---
2 files changed, 204 insertions(+), 12 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..9e2af3a 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,8 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
+extern void kmemleak_unalias(const void *alias) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +94,12 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
+static inline void kmemleak_unalias(const void *alias)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..3875cb7 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct
TVP5146 support on OMAP3EVM?
I'm evaluating OMAP using the OMAP3EVM eval board. I originally had a 2.6.32 kernel 'linux-omap-psp-2.6.32' (http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=summary). I have since moved to the latest 'devel' branch on omap3camera (2.6.35). There, as on the current linux-omap, there seems to no longer be support for the TVP5146 decoder *on the OMAP3EVM*. In my 2.6.32 branch, there was a file board-omap3evm-camera.c which defined the TVP on the OMAP3EVM. Has support for the TVP5146 decoder on the OMAP3EVM been dropped, or am I overlooking something? Does anyone know of a demo for the OMAP3EVM for capturing images to test the OMAP? The TVP seems ideal because I don't need a daughter card with an image sensor, just video input. Perhaps I need to fall back on the 2.6.29 kernel that came with the board with PSP-02.01.03.11. thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich -- To unsubscribe from this list: send the line unsubscribe 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] mailbox: change full flag per mailbox queue instead of global
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH] mailbox: change full flag per mailbox queue instead of global Date: Tue, 10 Aug 2010 16:36:42 +0200 Hi Hiroshi, On Mon, Jun 14, 2010 at 7:51 PM, 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 It looks like this fix didn't get thru - can you please review and ack/nack ? Sure. Fernando, could you rebase this patch against the latest omap/master? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 09, 2010 11:04 PM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Nayak,
Rajendra; Shilimkar, Santosh
Subject: Re: [PATCH 1/3] OMAP4: prcm: Add temporarily helper
functions for rmw and read inside the PRM
On 8/9/2010 7:30 PM, Kevin Hilman wrote:
Benoit Coussonb-cous...@ti.com writes:
Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so
define temp
version until the proper ones are defined.
Curious what we're waiting for for the final versions of these?
That should be soon... Rajendra is working on that... among hundreds
other stuff.
Benoit
I just posted a couple of RFC patches for these now which
can be found here
https://patchwork.kernel.org/patch/118566/
https://patchwork.kernel.org/patch/118568/
Kevin
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/prcm.c | 24
arch/arm/plat-omap/include/plat/prcm.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c
b/arch/arm/mach-omap2/prcm.c
index 96f4616..d4388d3 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -216,6 +216,30 @@ u32 prm_read_mod_bits_shift(s16
domain, s16 idx, u32 mask)
return v;
}
+/* Read a PRM register, AND it, and shift the result down
to bit 0 */
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v= mask;
+ v= __ffs(mask);
+
+ return v;
+}
+
+/* Read-modify-write a register in a PRM module. Caller
must lock */
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v= ~mask;
+ v |= bits;
+ __raw_writel(v, reg);
+
+ return v;
+}
/* Read a register in a CM module */
u32 cm_read_mod_reg(s16 module, u16 idx)
{
diff --git a/arch/arm/plat-omap/include/plat/prcm.h
b/arch/arm/plat-omap/include/plat/prcm.h
index 9fbd914..ab77442 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -38,6 +38,8 @@ u32 prm_read_mod_reg(s16 module, u16 idx);
void prm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 prm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module,
s16 idx);
u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask);
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg);
u32 cm_read_mod_reg(s16 module, u16 idx);
void cm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
--
To unsubscribe from this list: send the line unsubscribe 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] mailbox: change full flag per mailbox queue instead of global
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Tuesday, August 10, 2010 10:58 AM To: Guzman Lugo, Fernando; o...@wizery.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH] mailbox: change full flag per mailbox queue instead of global From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH] mailbox: change full flag per mailbox queue instead of global Date: Tue, 10 Aug 2010 16:36:42 +0200 Hi Hiroshi, On Mon, Jun 14, 2010 at 7:51 PM, 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 It looks like this fix didn't get thru - can you please review and ack/nack ? Sure. Fernando, could you rebase this patch against the latest omap/master? No problem, I will send it again. Regards, Fernando. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: omap_hwmod: remove locking from hwmod_for_each iterators
Remove unnecessary locking in the 'for_each' iterators. Any locking should
be taken care of by using hwmod API functions in the functions called by the
iterators.
In addition, having locking here causes lockdep to detect possible circular
dependencies (originally reported by Partha Basak p-bas...@ti.com.)
For example, during init (#0 below) you have the hwmod_mutex acquired
(hwmod_for_each_by_class()) then the dpm_list_mtx acquired
(device_pm_add()). Later, during suspend the dpm_list_mtx is aquired
first (dpm_suspend_noirq()), then the omap_hwmod_mutex is acquired
(omap_hwmod_idle()).
[ 810.170593] ===
[ 810.170593] [ INFO: possible circular locking dependency detected ]
[ 810.170623] 2.6.35-rc5-00131-g56e767c-dirty #34
[ 810.170654] ---
[ 810.170654] sh/670 is trying to acquire lock:
[ 810.170684] (omap_hwmod_mutex){+.+.+.}, at: [c004fe84]
omap_hwmod_idle+0x1c/0x38
[ 810.170745]
[ 810.170745] but task is already holding lock:
[ 810.170776] (dpm_list_mtx){+.+...}, at: [c023baf8]
dpm_suspend_noirq+0x28/0x188
[ 810.170806]
[ 810.170837] which lock already depends on the new lock.
[ 810.170837]
[ 810.170837]
[ 810.170837] the existing dependency chain (in reverse order) is:
[ 810.170867]
[ 810.170867] - #1 (dpm_list_mtx){+.+...}:
[ 810.170898][c009bc3c] lock_acquire+0x60/0x74
[ 810.170959][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.170989][c023bcc0] device_pm_add+0x14/0xcc
[ 810.171020][c0235304] device_add+0x3b8/0x564
[ 810.171051][c0238834] platform_device_add+0x104/0x160
[ 810.171112][c005f2a8] omap_device_build_ss+0x14c/0x1c8
[ 810.171142][c005f36c] omap_device_build+0x48/0x50
[ 810.171173][c004d34c] omap2_init_gpio+0xf0/0x15c
[ 810.171203][c004f254] omap_hwmod_for_each_by_class+0x60/0xa4
[ 810.171264][c0040340] do_one_initcall+0x58/0x1b4
[ 810.171295][c0008574] kernel_init+0x98/0x150
[ 810.171325][c0041968] kernel_thread_exit+0x0/0x8
[ 810.171356]
[ 810.171356] - #0 (omap_hwmod_mutex){+.+.+.}:
[ 810.171386][c009b4e4] __lock_acquire+0x108c/0x1784
[ 810.171447][c009bc3c] lock_acquire+0x60/0x74
[ 810.171478][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.171508][c004fe84] omap_hwmod_idle+0x1c/0x38
[ 810.171539][c005eb9c] omap_device_idle_hwmods+0x20/0x3c
[ 810.171600][c005ec88] _omap_device_deactivate+0x58/0x14c
[ 810.171630][c005ef50] omap_device_idle+0x4c/0x6c
[ 810.171661][c0053e7c] platform_pm_runtime_suspend+0x4c/0x74
[ 810.171691][c023c9f8] __pm_runtime_suspend+0x204/0x34c
[ 810.171722][c023cbe0] pm_runtime_suspend+0x20/0x34
[ 810.171752][c0053dbc] platform_pm_runtime_idle+0x8/0x10
[ 810.171783][c023c344] __pm_runtime_idle+0x15c/0x198
[ 810.171813][c023c3f8] pm_runtime_idle+0x1c/0x30
[ 810.171844][c0053dac] platform_pm_suspend_noirq+0x48/0x50
[ 810.171875][c023ad4c] pm_noirq_op+0xa0/0x184
[ 810.171905][c023bb7c] dpm_suspend_noirq+0xac/0x188
[ 810.171936][c00a5d00] suspend_devices_and_enter+0x94/0x1d8
[ 810.171966][c00a5f00] enter_state+0xbc/0x120
[ 810.171997][c00a5654] state_store+0xa4/0xb8
[ 810.172027][c01ea9e0] kobj_attr_store+0x18/0x1c
[ 810.172088][c0129acc] sysfs_write_file+0x10c/0x144
[ 810.172119][c00df83c] vfs_write+0xb0/0x148
[ 810.172149][c00df984] sys_write+0x3c/0x68
[ 810.172180][c0040920] ret_fast_syscall+0x0/0x3c
[ 810.172210]
[ 810.172210] other info that might help us debug this:
[ 810.172210]
[ 810.172241] 4 locks held by sh/670:
[ 810.172241] #0: (buffer-mutex){+.+.+.}, at: [c01299e8]
sysfs_write_file+0x28/0x144
[ 810.172302] #1: (s_active#5){.+.+.+}, at: [c0129aa8]
sysfs_write_file+0xe8/0x144
[ 810.172363] #2: (pm_mutex){+.+.+.}, at: [c00a5e64] enter_state+0x20/0x120
[ 810.172393] #3: (dpm_list_mtx){+.+...}, at: [c023baf8]
dpm_suspend_noirq+0x28/0x188
Tested-by: Partha Basak p-bas...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cb911d7..5941d5b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1204,13 +1204,11 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(omap_hwmod_mutex);
return ret;
}
@@ -1703,8 +1701,6 @@ int omap_hwmod_for_each_by_class(const char
RE: TVP5146 support on OMAP3EVM?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Michael Jones Sent: Tuesday, August 10, 2010 9:16 PM To: linux-omap@vger.kernel.org Subject: TVP5146 support on OMAP3EVM? I'm evaluating OMAP using the OMAP3EVM eval board. I originally had a 2.6.32 kernel 'linux-omap-psp-2.6.32' (http://arago- project.org/git/people/?p=sriram/ti-psp-omap.git;a=summary). I have since moved to the latest 'devel' branch on omap3camera (2.6.35). There, as on the current linux-omap, there seems to no longer be support for the TVP5146 decoder *on the OMAP3EVM*. In my 2.6.32 branch, there was a file board- omap3evm-camera.c which defined the TVP on the OMAP3EVM. [Hiremath, Vaibhav] First of all I still have to add support for OMAP3EVM and TVP5146 decoder ontop of latest omap3camera/devel branch and that is the reason you won't find support for board-omap3evm-camera.c. Has support for the TVP5146 decoder on the OMAP3EVM been dropped, or am I overlooking something? [Hiremath, Vaibhav] No, you are not overlooking anything here, as I mentioned above the fact is, earlier you were using PSP release which supports TVP5146 video decoder interface. I had started working on this sometime back but again had to put on hold due to other high priority issues, but yes soon I will be adding support for OMAP3EVM on top of omap3camera/devel branch. I will keep you posted on this. Thanks, Vaibhav Does anyone know of a demo for the OMAP3EVM for capturing images to test the OMAP? The TVP seems ideal because I don't need a daughter card with an image sensor, just video input. Perhaps I need to fall back on the 2.6.29 kernel that came with the board with PSP-02.01.03.11. thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans- Joachim Reich -- To unsubscribe from this list: send the line unsubscribe 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] [SPI] SPI100k: Fix 8-bit and RX-only transfers
On Mon, Aug 2, 2010 at 9:34 AM, Cory Maccarrone darkstar6...@gmail.com wrote: On Sat, May 29, 2010 at 5:12 PM, Cory Maccarrone darkstar6...@gmail.com wrote: This change fixes 8-bit transfers and RX-only transfers. The SPI100k framework requires minimum 16-bit words to be written, so 8-bit transfers must be shited by 8 bits and sent out as a 16-bit word. Additionally, receive-only transfers were failing due to the perceived need to fill the TX buffer with something. This is in fact not needed. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- drivers/spi/omap_spi_100k.c | 23 --- 1 files changed, 12 insertions(+), 11 deletions(-) [...] Adding another name to the list. This patch has been in my next-spi branch for a while, and I have a pull request pending out to Linus. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe 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] PM: runtime PM + idle: allow usage when interrupts are disabled
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle sequence, interrupts will likely be disabled when
runtime PM for these devices is initiated.
Currently, the runtime PM core assumes methods are called with
interrupts enabled. However, if it is called with interrupts
disabled, the internal locking unconditionally enables interrupts, for
example:
pm_runtime_put_sync()
__pm_runtime_put()
pm_runtime_idle()
spin_lock_irq()
__pm_runtime_idle()
spin_unlock_irq() --- interrupts unconditionally enabled
dev-bus-pm-runtime_idle()
spin_lock_irq()
spin_unlock_irq()
Unconditionally enabling interrupts late in the idle sequence is not
desired behavior. To fix, use the save/restore versions of the
spinlock API.
Reported-by: Partha Basak p-bas...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
RFC: I'm not crazy about having the 'flags' in struct dev_pm_info, but
since the locks are taken and released in separate functions, this
seems better than changing the function APIs to pass around the flags.
drivers/base/power/runtime.c | 68 ++---
include/linux/pm.h |1 +
2 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index b78c401..0caaef1 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -80,24 +80,24 @@ static int __pm_runtime_idle(struct device *dev)
dev-power.idle_notification = true;
if (dev-bus dev-bus-pm dev-bus-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-bus-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-type dev-type-pm dev-type-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-type-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-class dev-class-pm
dev-class-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-class-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
}
dev-power.idle_notification = false;
@@ -115,9 +115,9 @@ int pm_runtime_idle(struct device *dev)
{
int retval;
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
retval = __pm_runtime_idle(dev);
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
return retval;
}
@@ -226,11 +226,13 @@ int __pm_runtime_suspend(struct device *dev, bool from_wq)
if (dev-power.runtime_status != RPM_SUSPENDING)
break;
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock,
+ dev-power.lock_flags);
schedule();
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock,
+ dev-power.lock_flags);
}
finish_wait(dev-power.wait_queue, wait);
goto repeat;
@@ -240,27 +242,27 @@ int __pm_runtime_suspend(struct device *dev, bool from_wq)
dev-power.deferred_resume = false;
if (dev-bus dev-bus-pm dev-bus-pm-runtime_suspend) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
retval = dev-bus-pm-runtime_suspend(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
dev-power.runtime_error = retval;
} else if (dev-type dev-type-pm
dev-type-pm-runtime_suspend) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
retval = dev-type-pm-runtime_suspend(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
dev-power.runtime_error = retval;
} else if (dev-class dev-class-pm
Re: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
Basak, Partha p-bas...@ti.com writes: Instead, please propose an API to hwmod for getting the optional clock(s), or possibly cleaner, an API to directly enable/disable optional clocks for an omap_device. As per our discussion with Paul you during workshop, I believe, optional clock control should be done using clock APIs. So, I would go by your suggestion 1 of exposing an API to expose the optional clocks in the hwmod, something like: struct omap_hwmod_opt_clk * omap_hwmod_get_opt_clks(struct omap_hwmod *oh); If agreed, Charu will send updated patch. OK with me. -- To unsubscribe from this list: send the line unsubscribe 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 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
Basak, Partha p-bas...@ti.com writes:
[...]
In the idle path (interrupt disabled context), PM runtime APIs cannot
be used as they are not mutex-free functions. Hence omap_device APIs
are used in the idle and resume after idle path.
This needs much more fleshing out.
Exactly what mutexes are causing the problems here. As pointed out in
previous discussions, the ones in the PM runtime core should not be a
problem in this path. Therefore, I'll assume the problems are coming
from the mutexes when the device code (mach-omap2/gpio.c) calls into the
hwmod layer. More on this in comments on the next patch.
Sorry, this has not been documented correctly. The issue has more to
do unconditional enabling of interrupts. We have received a patch from
you on using pm_runtime functions in Idle path. We will try on GPIO
and revert back.
OK
To summarize,
1. pm_runtime_get_sync() for any gpio bank is called when one of the
gpios
is requested on the bank, in which, no other gpio is being used (when
mod_usage becomes non-zero)
2. omap_device_enable() is called during gpio resume after idle, only
if the particular bank is being used (if mod_usage is non-zero)
context is saved/restored in the idle path, but...
3. pm_runtime_put_sync() is called when the last used gpio in that
gpio bank is freed (when mod_usage becomes zero)
in this path, the bank is now runtime suspended, but context has not
been saved for it. That should be fine, since this bank is no longer
used, but now let's assume there was an off-mode transition and context
is lost. Then, gpio_request() is called which will trigger
a pm_runtime_get_sync() and gpio_bank_runtime_resume() will be called.
In this case, it's not terribly clear that runtime_resume is doing sane
things if context has just been lost. Seems like runtime_resume should
be a nop in this case since any re-init will be be done in gpio_request().
Runtime_suspend/resume for GPIO is not doing any save/restore
context. In that sense, they are NOP. Context save/restore is taken
care of only in the Idle path based on target power state and last
power state respectively.
OK, I didn't explain the problem I'm suspecting very well. Imagine this
sequence of events:
- mod_usage becomes zero
- pm_runtime_put_sync()
- gpio_bank_runtime_suspend() [ no context is saved ]
[ off-mode transition, context is lost]
- gpio_request()
- pm_runtime_get_sync()
- gpio_bank_runtime_resume()
In this path, no context is saved, and no context is restored, which is
what I would expect, since there's no need to save context if nobody is
using that gpio bank anymore. However, gpio_bank_runtime_resume() is
doing lots of reads/writes and read-modify-writes on GPIO bank registers
that may have undefined contents after a context loss.
The point is that the GPIO register twiddling in
gpio_bank_runtime_resume() does not seem to be needed if there are no
users of that GPIO bank.
[...]
static void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -395,15 +385,17 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
- omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF) {
if (core_next_state == PWRDM_POWER_ON) {
per_next_state = PWRDM_POWER_RET;
pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
per_state_modified = 1;
- } else
- omap3_per_save_context();
+ }
}
+ if (per_next_state == PWRDM_POWER_OFF)
+ omap2_gpio_prepare_for_idle(true);
+ else
+ omap2_gpio_prepare_for_idle(false);
Why is this better than passing the next power state?
This would keep the GPIO function omap2_gpio_prepare_for_idle agnostic of
Power state definition dependencies.
And why is this better?
Personally, I think the GPIO code should be told about the powerdomain
state so it can make it's own decision about whether or not to save
context.
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
[LogicPD] smsc911x_soft_reset: Failed to complete reset same problem as Zoom3
On linux-next commit ID 81e09f50c93edff607259cbe374a3006c9c5fa74 Has the same problem the LogicPD Torpedo has the same problem [2.411743] eth0: smsc911x_soft_reset: Failed to complete reset [2.417846] eth0: smsc911x_open: soft reset failed [2.422668] IP-Config: Failed to open eth0 [2.426879] IP-Config: No network devices available. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Monday, August 09, 2010 4:36 PM To: linux-omap@vger.kernel.org Subject: [Zoom3] smsc911x_soft_reset: Failed to complete reset (sometimes...) Hi all, Seems that, with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058), and doing this change: diff --git a/drivers/net/smsc911x.h b/drivers/net/smsc911x.h index 016360c..2cd4f5a 100644 --- a/drivers/net/smsc911x.h +++ b/drivers/net/smsc911x.h @@ -23,7 +23,7 @@ #define TX_FIFO_LOW_THRESHOLD ((u32)1600) #define SMSC911X_EEPROM_SIZE ((u32)7) -#define USE_DEBUG 0 +#define USE_DEBUG 1 /* This is the maximum number of packets to be received every * NAPI poll */ I see in the console sometimes (not always) these error messages: [2.682342] eth0: smsc911x_soft_reset: Failed to complete reset [2.688385] eth0: smsc911x_open: soft reset failed [2.693176] IP-Config: Failed to open eth0 [2.697326] IP-Config: No network devices available. Is somebody also experiencing this? NOTE: It doesn't seem consistent. I had to reboot several times the board, To reproduce it. Sometimes it comes at the first try. Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe 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 11/15] wireless: wl1271: introduce platform device support
On Tue, Jul 6, 2010 at 8:42 PM, Nicolas Pitre n...@fluxnic.net wrote: Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like: /* * Indicate to the core SDIO layer that we're not requiring that the * function remain powered. If all functions for the card are in the * same no power state, then the host controller can remove power from * the card. Note: the function driver must preserve hardware states if * necessary. */ int sdio_release_power(struct sdio_func *func); /* * Indicate to the core SDIO layer that we want power back for this * SDIO function. The power may or may not actually have been removed * since last call to sdio_release_power(), so the function driver must * not assume any preserved state at the hardware level and re-perform * all the necessary hardware config. This function returns 0 when * power is actually restored, or some error code if this cannot be * achieved. One error reason might be that the card is no longer * available on the bus (was removed while powered down and card * detection didn't trigger yet). */ int sdio_claim_power(struct sdio_func *func); That's it. When the network interface is down and the hardware is not needed, you call sdio_release_power(). When the request to activate the network interface is received, you call sdio_claim_power() and configure the hardware appropriately. If sdio_claim_power() returns an error, then you just return an error to the network request, and eventually the driver's remove method will be called if this is indeed because the card was removed. After playing with this a little, I am getting convinced that the way to go here is to add runtime pm support to MMC/SDIO. It just fits perfectly into this model: Runtime PM already takes care of usage count per device (so it would tell if an SDIO function is idle), takes into account parent-child relationships (so if all SDIO functions are idle, it would automatically send an idle request to the card device), doesn't break existing drivers (drivers needs to explicitly enable it), play along nicely with the system suspend/resume, etc.. I'm going to split the patches to two: - first half would be basic wl1271 support for omap/zoom. it's pretty straight forward and can probably already go thru. - second half would be adding runtime PM to SDIO/MMC. I'll post some initial patches to set off a discussion. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dspbridge and the omapl1x
Hello authors of staging/tidspbridge patches, We have been watching the progress in staging/dspbridge with great excitement. Unfortunately we are using the OMAPL138 which is a davinci family member which has support for DSPLink not DSPBridge. We are attracted to DSPBridge over DSPLink because it appears to have better dynamic resource management and it is headed for mainline (fingers crossed). Is omapl1x support part of the roadmap for dspbridge? Is there anything we can do to help? Are there interfaces to which we can program that would insulate us from changes during a future migration from DSPLink to DSPBridge? Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: don't power off a panel twice
On Tue, Aug 10, 2010 at 5:16 AM, Stanley.Miao
stanley.m...@windriver.com wrote:
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now add a variable panel_enabled
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-generic.c | 11 +++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 11 +++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 +++
drivers/video/omap2/displays/panel-taal.c | 6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c | 11 +++
.../video/omap2/displays/panel-tpo-td043mtea1.c | 9 +
6 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..607f11a 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -22,6 +22,8 @@
#include plat/display.h
+static int panel_enabled;
+
static struct omap_video_timings generic_panel_timings = {
/* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
.x_res = 640,
@@ -39,6 +41,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -48,6 +53,7 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err1;
}
+ panel_enabled = 1;
return 0;
err1:
@@ -58,10 +64,14 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (panel_enabled == 0)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
omapdss_dpi_display_disable(dssdev);
+ panel_enabled = 0;
}
static int generic_panel_probe(struct omap_dss_device *dssdev)
@@ -155,6 +165,7 @@ static struct omap_dss_driver generic_driver = {
static int __init generic_panel_drv_init(void)
{
+ panel_enabled = 0;
return omap_dss_register_driver(generic_driver);
}
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..b5205d4 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -24,6 +24,8 @@
#include plat/display.h
+static int panel_enabled;
+
static struct omap_video_timings sharp_lq_timings = {
.x_res = 480,
.y_res = 272,
@@ -43,6 +45,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -55,6 +60,7 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err1;
}
+ panel_enabled = 1;
return 0;
err1:
@@ -65,6 +71,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (panel_enabled == 0)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
@@ -72,6 +81,7 @@ static void sharp_lq_panel_power_off(struct omap_dss_device
*dssdev)
msleep(100);
omapdss_dpi_display_disable(dssdev);
+ panel_enabled = 0;
}
static int sharp_lq_panel_probe(struct omap_dss_device *dssdev)
@@ -146,6 +156,7 @@ static struct omap_dss_driver sharp_lq_driver = {
static int __init sharp_lq_panel_drv_init(void)
{
+ panel_enabled = 0;
return omap_dss_register_driver(sharp_lq_driver);
}
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..3750fdc 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -31,6 +31,8 @@ struct sharp_data {
struct backlight_device *bl;
};
+static int panel_enabled;
+
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
.y_res = 640,
@@ -135,6 +137,9 @@ static int sharp_ls_power_on(struct omap_dss_device
*dssdev)
{
int r = 0;
+ if (panel_enabled)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -147,6 +152,7 @@ static int sharp_ls_power_on(struct omap_dss_device
*dssdev)
if (r)
Re: dspbridge and the omapl1x
Ben, We are attracted to DSPBridge over DSPLink because it appears to have better dynamic resource management and it is headed for mainline (fingers crossed). Do you mean dynamic memory management ? Can you please elaborate on what feature you are referring to ? Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe 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/9] native support for wl1271 on ZOOM
This patch series adds native support for wl1271 on ZOOM. Changes since v2: - mmc/sdio power manipulation is removed, and will be posted separately in the shape of mmc/sdio runtime pm. - the platform device is back, used to deliver board-specific platform data (i.e. irq and ref clock) Patches are based on linux-next (as of Aug 7th), and tested on ZOOM2. Please note that I am going to have a very limited email access in the next three weeks, so I might not respond right away. Thanks, Ohad Ben-Cohen (9): wireless: wl1271: make wl12xx.h common to both spi and sdio wireless: wl1271: support return value for the set power func wireless: wl1271: add platform driver to get board data wireless: wl1271: take irq info from private board data wireless: wl1271: make ref_clock configurable by board omap: hsmmc: remove unused variable omap: zoom: add fixed regulator device for wlan omap: hsmmc: support mmc3 regulator power control omap: zoom: add mmc3/wl1271 device support arch/arm/mach-omap2/board-zoom-peripherals.c | 69 +++ arch/arm/mach-omap2/hsmmc.c | 10 ++- drivers/mmc/host/omap_hsmmc.c| 68 +-- drivers/net/wireless/wl12xx/wl1251_sdio.c|2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271.h | 15 +++- drivers/net/wireless/wl12xx/wl1271_boot.c|9 +- drivers/net/wireless/wl12xx/wl1271_boot.h|1 - drivers/net/wireless/wl12xx/wl1271_io.h |8 +- drivers/net/wireless/wl12xx/wl1271_main.c|4 +- drivers/net/wireless/wl12xx/wl1271_sdio.c| 120 +++--- drivers/net/wireless/wl12xx/wl1271_spi.c |8 ++- include/linux/spi/wl12xx.h | 34 --- include/linux/wl12xx.h | 35 14 files changed, 311 insertions(+), 74 deletions(-) delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/9] wireless: wl1271: make wl12xx.h common to both spi and sdio
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2 +-
include/linux/spi/wl12xx.h| 34 -
include/linux/wl12xx.h| 34 +
5 files changed, 37 insertions(+), 37 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index b901b61..a319df1 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index 27fdfaa..a6faf3e 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -26,7 +26,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 4cb99c5..c3fdab7 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a223ecb..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo kalle.v...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_platform_data {
- void (*set_power)(bool enable);
- /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
- int irq;
- bool use_eeprom;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..137ac89
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Contact: Kalle Valo kalle.v...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef _LINUX_WL12XX_H
+#define _LINUX_WL12XX_H
+
+struct wl12xx_platform_data {
+ void (*set_power)(bool enable);
+ /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
+ int irq;
+ bool use_eeprom;
+};
+
+#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/9] wireless: wl1271: support return value for the set power func
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless/wl12xx/wl1271_io.h |8 +---
drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_sdio.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_spi.c |4 +++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index dd3cee6..faa5925 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -313,7 +313,7 @@ struct wl1271_if_operations {
bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
- void (*power)(struct wl1271 *wl, bool enable);
+ int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..4a5b92c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,12 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
}
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
{
- wl-if_ops-power(wl, true);
- set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ int ret = wl-if_ops-power(wl, true);
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
b/drivers/net/wireless/wl12xx/wl1271_main.c
index 9d68f00..e6e0852 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -621,7 +621,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
msleep(WL1271_PRE_POWER_ON_SLEEP);
- wl1271_power_on(wl);
+ ret = wl1271_power_on(wl);
+ if (ret 0)
+ goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 7059b5c..c41293a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -152,7 +152,7 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int
addr, void *buf,
}
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
struct sdio_func *func = wl_to_func(wl);
@@ -167,6 +167,8 @@ static void wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
sdio_disable_func(func);
sdio_release_host(func);
}
+
+ return 0;
}
static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index c3fdab7..de56d8d 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -312,10 +312,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
}
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
{
if (wl-set_power)
wl-set_power(enable);
+
+ return 0;
}
static struct wl1271_if_operations spi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/9] wireless: wl1271: take irq info from private board data
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 5b43626..b565e64 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -38,9 +38,6 @@
#include wl12xx_80211.h
#include wl1271_io.h
-
-#define RX71_WL1271_IRQ_GPIO 42
-
#ifndef SDIO_VENDOR_ID_TI
#define SDIO_VENDOR_ID_TI 0x0097
#endif
@@ -191,6 +188,7 @@ static int wl1271_plat_probe(struct platform_device *pdev)
struct wl12xx_platform_data *pdata;
struct platform_driver *pdriver;
struct wl12xx_plat_instance *pinstance;
+ int irq;
pdata = pdev-dev.platform_data;
if (!pdata) {
@@ -198,6 +196,13 @@ static int wl1271_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ wl1271_error(no platform irq data);
+ return -ENODEV;
+ }
+ pdata-irq = irq;
+
pdriver = container_of(pdev-dev.driver, struct platform_driver,
driver);
pinstance = container_of(pdriver, struct wl12xx_plat_instance, pdriver);
@@ -290,12 +295,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
goto out_free;
}
- wl-irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
- if (wl-irq 0) {
- ret = wl-irq;
- wl1271_error(could not get irq!);
- goto put_data;
- }
+ wl-irq = wlan_data-irq;
ret = request_irq(wl-irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret 0) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/9] wireless: wl1271: make ref_clock configurable by board
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by the board
files that set up the device, instead of having a hard coded
value in the driver source itself.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h |1 +
drivers/net/wireless/wl12xx/wl1271_boot.c |9 +
drivers/net/wireless/wl12xx/wl1271_boot.h |1 -
drivers/net/wireless/wl12xx/wl1271_sdio.c |1 +
drivers/net/wireless/wl12xx/wl1271_spi.c |2 ++
include/linux/wl12xx.h|1 +
6 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 013eabb..f0988a4 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -342,6 +342,7 @@ struct wl1271 {
void (*set_power)(bool enable);
int irq;
+ int ref_clock;
spinlock_t wl_lock;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c
b/drivers/net/wireless/wl12xx/wl1271_boot.c
index f36430b..95c636a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -457,17 +457,18 @@ int wl1271_boot(struct wl1271 *wl)
{
int ret = 0;
u32 tmp, clk, pause;
+ int ref_clock = wl-ref_clock;
wl1271_boot_hw_version(wl);
- if (REF_CLOCK == 0 || REF_CLOCK == 2 || REF_CLOCK == 4)
+ if (ref_clock == 0 || ref_clock == 2 || ref_clock == 4)
/* ref clk: 19.2/38.4/38.4-XTAL */
clk = 0x3;
- else if (REF_CLOCK == 1 || REF_CLOCK == 3)
+ else if (ref_clock == 1 || ref_clock == 3)
/* ref clk: 26/52 */
clk = 0x5;
- if (REF_CLOCK != 0) {
+ if (ref_clock != 0) {
u16 val;
/* Set clock type (open drain) */
val = wl1271_top_reg_read(wl, OCP_REG_CLK_TYPE);
@@ -516,7 +517,7 @@ int wl1271_boot(struct wl1271 *wl)
wl1271_debug(DEBUG_BOOT, clk2 0x%x, clk);
/* 2 */
- clk |= (REF_CLOCK 1) 4;
+ clk |= (ref_clock 1) 4;
wl1271_write32(wl, DRPW_SCRATCH_START, clk);
wl1271_set_partition(wl, part_table[PART_WORK]);
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.h
b/drivers/net/wireless/wl12xx/wl1271_boot.h
index f829699..f73b0b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.h
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.h
@@ -46,7 +46,6 @@ struct wl1271_static_data {
/* delay between retries */
#define INIT_LOOP_DELAY 50
-#define REF_CLOCK2
#define WU_COUNTER_PAUSE_VAL 0x3FF
#define WELP_ARM_COMMAND_VAL 0x4
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index b565e64..bfb18b6 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -296,6 +296,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
}
wl-irq = wlan_data-irq;
+ wl-ref_clock = wlan_data-board_ref_clock;
ret = request_irq(wl-irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret 0) {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index de56d8d..ced0a9e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -372,6 +372,8 @@ static int __devinit wl1271_probe(struct spi_device *spi)
goto out_free;
}
+ wl-ref_clock = pdata-board_ref_clock;
+
wl-irq = spi-irq;
if (wl-irq 0) {
wl1271_error(irq missing in platform data);
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 137ac89..ef6eed9 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -29,6 +29,7 @@ struct wl12xx_platform_data {
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
+ int board_ref_clock;
};
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/9] omap: hsmmc: remove unused variable
Make this go away: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2328: warning: unused variable 'state' Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/mmc/host/omap_hsmmc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..d50e917 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2272,7 +2272,6 @@ static int omap_hsmmc_suspend(struct device *dev) int ret = 0; struct platform_device *pdev = to_platform_device(dev); struct omap_hsmmc_host *host = platform_get_drvdata(pdev); - pm_message_t state = PMSG_SUSPEND; /* unused by MMC core */ if (host host-suspended) return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/9] omap: zoom: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -27,6 +28,8 @@
#include mux.h
#include hsmmc.h
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.2,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/9] omap: hsmmc: split mmc23 power control
Prepare for mmc3 regulator power control by splitting the power
control functions of mmc2 and mmc3, and expecting mmc3 to have
a single, dedicated, regulator support.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c | 10 --
drivers/mmc/host/omap_hsmmc.c | 67
2 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..5d3d789 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -174,7 +174,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc23_before_set_reg(struct device *dev, int slot,
+static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
@@ -325,14 +325,16 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c-transceiver = 1;
if (c-transceiver c-wires 4)
c-wires = 4;
- /* FALLTHROUGH */
- case 3:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].before_set_reg =
hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 3:
+ mmc-slots[0].before_set_reg = NULL;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d50e917..6f5cea0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -258,7 +258,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_2_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -309,6 +309,31 @@ static int omap_hsmmc_23_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
+static int omap_hsmmc_3_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int ret = 0;
+
+ if (power_on) {
+ ret = mmc_regulator_set_ocr(host-vcc, vdd);
+ /* Enable interface voltage rail, if needed */
+ if (ret == 0 host-vcc) {
+ ret = regulator_enable(host-vcc);
+ if (ret 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+ } else {
+ if (host-vcc)
+ ret = regulator_disable(host-vcc);
+ if (ret == 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+
+ return ret;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -319,7 +344,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_set_mode(host-vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_2_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -358,6 +383,31 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_enable(host-vcc_aux);
}
+static int omap_hsmmc_3_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int err = 0;
+
+ /*
+* If we don't see a Vcc regulator, assume it's a fixed
+* voltage always-on regulator.
+*/
+ if (!host-vcc)
+ return 0;
+
+ if (cardsleep) {
+ /* VCC can be turned off if card is asleep */
+ if (sleep)
+ err = mmc_regulator_set_ocr(host-vcc, 0);
+ else
+ err = mmc_regulator_set_ocr(host-vcc, vdd);
+ }
+
+ return err;
+}
+
static int
[PATCH v3 9/9] omap: zoom: add mmc3/wl1271 device support
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index de88635..82776bc 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,8 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -29,6 +31,7 @@
#include hsmmc.h
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -185,6 +188,28 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_zoom_wlan_data = {
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+};
+
+static struct resource omap_zoom_wl1271_resources[] = {
+ {
+ .start = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ .end = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ .flags = IORESOURCE_IRQ,
+ }
+};
+static struct platform_device omap_zoom_wl1271 = {
+ .name = wl1271_plat.2,
+ .id = -1,
+ .resource = omap_zoom_wl1271_resources,
+ .num_resources = ARRAY_SIZE(omap_zoom_wl1271_resources),
+ .dev = {
+ .platform_data = omap_zoom_wlan_data,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -202,6 +227,14 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+ {
+ .name = wl1271,
+ .mmc= 3,
+ .wires = 4,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ },
{} /* Terminator */
};
@@ -313,6 +346,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ platform_device_register(omap_zoom_wl1271);
omap_i2c_init();
platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM: fix the error messages printed when the system suspend
On Mon, Aug 9, 2010 at 9:30 PM, stanley.miao stanley.m...@windriver.com wrote: Cliff Brake wrote: Functionally, what does this statement mean? The 3503 seems to have the EN_IO [8] bit, but I've yet to figure out what the EN_IO_CHAIN [16] means. Please reference to Chapter 4.11 PRCM Off-Mode Management in OMAP35x TRM. Thanks for the pointer. Do you know offhand what TI documentation details the differences between the 3503 and the 3530 in this regard. I'm also trying to piece together what practical impact this will have on a system. I have an older 3503 system, and it is still spewing Wake up daisy chain activation failed messages. Do you expect the following patch would have fixed this? So I then instrumented the following macros: CLIFF: cpu_is_omap3503 = 0 CLIFF: cpu_is_omap3515 = 0 CLIFF: cpu_is_omap3525 = 0 CLIFF: cpu_is_omap3530 = 0 CLIFF: is_omap3430 = 0 CLIFF: omap3_has_iva = 2 CLIFF: omap3_has_sgx = 0 CLIFF: omap3_has_io_wakeup = 64 Perhaps it is not a 3503??? The kernel prints the following on bootup: OMAP3525 ES2.1 (l2cache iva neon isp ) But, then I look at u-boot, and see: OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max clock-600Mhz So not everyone is telling the same story. Anyway, it seems we have a problem in that the cpu_is_xxx macros are not working. Thanks, Cliff commit ad0c63f1d623ea9d3e0c0521d5ce9cd522c4e1f0 Author: stanley.miao stanley.m...@windriver.com Date: Mon Aug 2 14:21:40 2010 +0300 OMAP3: AM3505/3517 do not have IO wakeup capability AM3505/3517 doesn't have IO wakeup capability, so we do not need to set the bit OMAP3430_EN_IO and the bit OMAP3430_EN_IO_CHAIN in the register PM_WKEN_WKUP when the system enters suspend state. Tested on AM3517EVM and OMAP3530EVM. Signed-off-by: Stanley.Miao stanley.m...@windriver.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/9] wireless: wl1271: add platform driver to get board data
Dynamically create and register a platform driver, that will
be used to to receive board-specific information like irq and
reference clock numbers.
The driver is created dynamically in order to avoid the 1-device
limitation of a fixed platform driver name.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h | 12
drivers/net/wireless/wl12xx/wl1271_sdio.c | 103 +++--
2 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index faa5925..013eabb 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -31,6 +31,7 @@
#include linux/list.h
#include linux/bitops.h
#include net/mac80211.h
+#include linux/platform_device.h
#include wl1271_conf.h
#include wl1271_ini.h
@@ -319,8 +320,19 @@ struct wl1271_if_operations {
void (*disable_irq)(struct wl1271 *wl);
};
+/* exact size needed for wl1271_plat.x */
+#define WL12XX_PLAT_NAME_LEN 14
+
+struct wl12xx_plat_instance {
+ struct platform_driver pdriver;
+ char name[WL12XX_PLAT_NAME_LEN];
+ struct wl12xx_platform_data *pdata;
+ struct completion data_ready;
+};
+
struct wl1271 {
struct platform_device *plat_dev;
+ struct wl12xx_plat_instance *pinstance;
struct ieee80211_hw *hw;
bool mac80211_registered;
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index c41293a..5b43626 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -28,7 +28,11 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/completion.h
#include wl1271.h
#include wl12xx_80211.h
@@ -182,10 +186,84 @@ static struct wl1271_if_operations sdio_ops = {
.disable_irq= wl1271_sdio_disable_interrupts
};
+static int wl1271_plat_probe(struct platform_device *pdev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct platform_driver *pdriver;
+ struct wl12xx_plat_instance *pinstance;
+
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ wl1271_error(no platform data);
+ return -ENODEV;
+ }
+
+ pdriver = container_of(pdev-dev.driver, struct platform_driver,
+ driver);
+ pinstance = container_of(pdriver, struct wl12xx_plat_instance, pdriver);
+
+ pinstance-pdata = pdata;
+
+ complete(pinstance-data_ready);
+
+ return 0;
+}
+
+static struct wl12xx_platform_data *wl1271_get_data(struct wl1271 *wl, int id)
+{
+ int ret;
+ struct wl12xx_plat_instance *pinstance;
+
+ #define WL1271_PLAT_NAME wl1271_plat.%d
+
+ pinstance = kzalloc(sizeof(*pinstance), GFP_KERNEL);
+ if (!pinstance)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(pinstance-data_ready);
+
+ pinstance-pdriver.probe = wl1271_plat_probe;
+
+ ret = snprintf(pinstance-name, ARRAY_SIZE(pinstance-name),
+ WL1271_PLAT_NAME, id);
+ if (ret = WL12XX_PLAT_NAME_LEN) {
+ wl1271_error(truncated plat drv name\n);
+ goto out_free;
+ }
+
+ pinstance-pdriver.driver.name = pinstance-name;
+ pinstance-pdriver.driver.owner = THIS_MODULE;
+
+ ret = platform_driver_register(pinstance-pdriver);
+ if (ret 0) {
+ wl1271_error(failed to register plat driver: %d, ret);
+ goto out_free;
+ }
+
+ ret = wait_for_completion_interruptible_timeout(pinstance-data_ready,
+ msecs_to_jiffies(15000));
+ if (ret = 0) {
+ wl1271_error(can't get platform device (%d), ret);
+ ret = (ret == 0 ? -EAGAIN : ret);
+ goto unreg;
+ }
+
+ wl-pinstance = pinstance;
+
+ return pinstance-pdata;
+
+unreg:
+ platform_driver_unregister(pinstance-pdriver);
+out_free:
+ kfree(pinstance);
+ return ERR_PTR(ret);
+}
+
static int __devinit wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
struct ieee80211_hw *hw;
+ struct wl12xx_platform_data *wlan_data;
struct wl1271 *wl;
int ret;
@@ -205,17 +283,24 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func-card-quirks |= MMC_QUIRK_LENIENT_FN0;
+ wlan_data = wl1271_get_data(wl, func-card-host-index);
+ if (IS_ERR(wlan_data)) {
+ ret = PTR_ERR(wlan_data);
+ wl1271_error(missing wlan data (needed for irq/ref_clk)!);
+ goto
Re: CONFIG_CPU_IDLE broken for N900
Ameya Palande ameya.pala...@nokia.com writes:
When I enable CONFIG_CPU_IDLE and boot kernel, it hangs around the point
when it switches to user space. I am able to reproduce this for 2.6.35
on linux-omap and linux-2.6 trees.
Has anyone else noticed the same thing for omap3 based boards?
I was able to reproduce on my n900 and found the problem. I believe
this is the same problem that has been haunting the Overo folks in that
their console (on UART2 like n900) was not responding after suspend.
The patch below fixes the problem for me, and will post an official
version shortly.
Tested with l-o master (omap3_defconfig + CONFIG_CPU_IDLE=y) as well
with current PM branch. PM branch (specifically pm-fixes sub-branch)
has been updated to include this fix.
Kevin
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fb4994a..7b03426 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -480,7 +480,9 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup() core_next_state PWRDM_POWER_ON) {
+ if (omap3_has_io_wakeup()
+ (per_next_state PWRDM_POWER_ON ||
+core_next_state PWRDM_POWER_ON)) {
prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
omap3_disable_io_chain();
}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Sat, Aug 07, 2010 at 11:28:13AM -0600, Grant Likely wrote: On Sat, Aug 7, 2010 at 12:35 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Fri, Aug 6, 2010 at 5:46 PM, Greg KH gre...@suse.de wrote: That would be nice, but take your standard PC today: ls /sys/devices/platform/ Fixed MDIO bus.0 i8042 pcspkr power serial8250 uevent vesafb.0 There are tty devices below the serial port, which is nice to see, but the others? I don't know what type of bus they would be on, do you? [...] I wouldn't have any problem modifying those specific drivers to register under something like /sys/devices/legacy, but I don't really think it is in any way necessary. Or for that matter, make those drivers explicitly use /sys/devices/platform so that I don't cause churn on PCs. :-) I'd like to be rid of it as default behaviour for embedded though. Yes, that would be the easier (and better) solution. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: ensure IO wakeups are properly disabled
From: Kevin Hilman khil...@ti.com
During idle, if the PER powerdomain transitions and CORE does not (as
is the case with the lower C-states when using CPUidle) the IO pad
wakeups are not being disabled in the idle path after they are
enabled.
This patch ensures that the check for disabling IO wakeups also checks
for PER transitions, matching the check done to enable IO wakeups.
Found when debugging PM/CPUidle related problems reported by Ameya
Palande ameya.pala...@nokia.com. Problems were triggered
particularily on boards with UART2 consoles (n900, Overo) since UART2
is in the PER powerdomain.
Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
as with current PM branch. Boards tested: n900, Overo, omap3evm.
Cc: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
This should go into 2.6.36-rc2 as it's a fix for a serious regression.
arch/arm/mach-omap2/pm34xx.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fb4994a..7b03426 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -480,7 +480,9 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup() core_next_state PWRDM_POWER_ON) {
+ if (omap3_has_io_wakeup()
+ (per_next_state PWRDM_POWER_ON ||
+core_next_state PWRDM_POWER_ON)) {
prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
omap3_disable_io_chain();
}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo serial problems after resume, vs. Beagleboard
On Tue, Jun 22, 2010 at 7:31 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Mike Rapoport m...@compulab.co.il writes: Kevin Hilman wrote: Peter Tseng tsenpe...@gmail.com writes: I am seeing some discrepancies between the Overo (I believe I have a Water) and the Beagleboard (I have a Rev. B5) when resuming after a suspend to RAM. Not that it is much comfort, but I have the same problem on Overo but don't see it on any other OMAP3 board. I have yet to debug this particular issue further. I had the same issue on CM-T35 and when I've disabled CONFIG_CPU_IDLE in the kernel configuration the issue disappeared. Maybe it'll be of some help. That just masks the problem by not auto-gating the UART clocks. OK, I think I finally figured out this problem. A similar thing was reported on the n900 recently and got me to thinking that it must be something fishy going on with the PER powerdomain since both n900 and Overo are using a UART2 console, and UART2 is in PER. Anyways, I just posted a patch[1] that should fix this. I'd appreciate if anyone else with an Overo could confirm that things are back to working as expected with CONFIG_CPU_IDLE. Thanks, Kevin [1] https://patchwork.kernel.org/patch/118709/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP OPP layer
This series introduces a layer to manage Operating Performance Points (OPPs) for OMAP SoCs. Special thanks to Nishanth for doing the bulk of the grunt work for this series and to Thara for doing significant review, testing and updates. Kevin Hilman (1): omap3: pm: remove OPP interfaces from OMAP PM layer Nishanth Menon (1): OMAP: introduce OPP layer for device-specific OPPs Paul Walmsley (1): omap: opp: twl/tps: Introduce TWL/TPS-specific code Thara Gopinath (1): OMAP: Remove dependency of generic opp layer on cpufreq. Documentation/arm/OMAP/omap_pm| 93 + arch/arm/mach-omap2/io.c |3 +- arch/arm/plat-omap/Makefile |8 +- arch/arm/plat-omap/include/plat/omap-pm.h | 31 +- arch/arm/plat-omap/include/plat/opp.h | 160 arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 + arch/arm/plat-omap/omap-pm-noop.c | 11 +- arch/arm/plat-omap/opp.c | 513 + arch/arm/plat-omap/opp_twl_tps.c | 41 ++ 9 files changed, 847 insertions(+), 34 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/opp.h create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h create mode 100644 arch/arm/plat-omap/opp.c create mode 100644 arch/arm/plat-omap/opp_twl_tps.c -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon n...@ti.com
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
Documentation/arm/OMAP/omap_pm| 93 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 160 ++
arch/arm/plat-omap/opp.c | 513 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..b046ebc 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,96 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2.
[PATCH 0/4] OMAP OPP layer
This series introduces a layer to manage Operating Performance Points (OPPs) for OMAP SoCs. Special thanks to Nishanth for doing the bulk of the grunt work for this series and to Thara for doing significant review, testing and updates. Kevin Hilman (1): omap3: pm: remove OPP interfaces from OMAP PM layer Nishanth Menon (1): OMAP: introduce OPP layer for device-specific OPPs Paul Walmsley (1): omap: opp: twl/tps: Introduce TWL/TPS-specific code Thara Gopinath (1): OMAP: Remove dependency of generic opp layer on cpufreq. Documentation/arm/OMAP/omap_pm| 93 + arch/arm/mach-omap2/io.c |3 +- arch/arm/plat-omap/Makefile |8 +- arch/arm/plat-omap/include/plat/omap-pm.h | 31 +- arch/arm/plat-omap/include/plat/opp.h | 160 arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 + arch/arm/plat-omap/omap-pm-noop.c | 11 +- arch/arm/plat-omap/opp.c | 513 + arch/arm/plat-omap/opp_twl_tps.c | 41 ++ 9 files changed, 847 insertions(+), 34 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/opp.h create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h create mode 100644 arch/arm/plat-omap/opp.c create mode 100644 arch/arm/plat-omap/opp_twl_tps.c -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon n...@ti.com
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
Documentation/arm/OMAP/omap_pm| 93 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 160 ++
arch/arm/plat-omap/opp.c | 513 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..b046ebc 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,96 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2.
[PATCH 2/4] omap: opp: twl/tps: Introduce TWL/TPS-specific code
From: Paul Walmsley p...@pwsan.com
The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 +
arch/arm/plat-omap/opp_twl_tps.c | 41 +
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h
create mode 100644 arch/arm/plat-omap/opp_twl_tps.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 70b012d..faf831d 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# OPP support in (OMAP3+ only at the moment)
ifdef CONFIG_CPU_FREQ
obj-$(CONFIG_ARCH_OMAP3) += opp.o
+obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
endif
# omap_device support (OMAP2+ only at the moment)
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h
b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
new file mode 100644
index 000..8784e5f
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -0,0 +1,21 @@
+/*
+ * opp_twl_tps.h - TWL/TPS-specific headers for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ *
+ * 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.
+ *
+ * XXX This code belongs as part of some other TWL/TPS code.
+ */
+#ifndef _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+#define _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+
+#include linux/kernel.h
+
+unsigned long omap_twl_vsel_to_uv(const u8 vsel);
+u8 omap_twl_uv_to_vsel(unsigned long uV);
+
+#endif
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-omap/opp_twl_tps.c
new file mode 100644
index 000..112f106
--- /dev/null
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -0,0 +1,41 @@
+/*
+ * opp_twl_tps.c - TWL/TPS-specific functions for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * 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.
+ *
+ * XXX This code should be part of some other TWL/TPS code.
+ */
+
+#include plat/opp_twl_tps.h
+
+/**
+ * omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
+ * @vsel: TWL/TPS VSEL value to convert
+ *
+ * Returns the microvolts DC that the TWL/TPS family of PMICs should
+ * generate when programmed with @vsel.
+ */
+unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return (((vsel * 125) + 6000)) * 100;
+}
+
+/**
+ * omap_twl_uv_to_vsel - convert microvolts DC to TWL/TPS VSEL value
+ * @uv: microvolts DC to convert
+ *
+ * Returns the VSEL value necessary for the TWL/TPS family of PMICs to
+ * generate an output voltage equal to or greater than @uv microvolts DC.
+ */
+u8 omap_twl_uv_to_vsel(unsigned long uv)
+{
+ /* Round up to higher voltage */
+ return DIV_ROUND_UP(uv - 60, 12500);
+}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] omap3: pm: remove OPP interfaces from OMAP PM layer
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
Signed-off-by: Romit Dasgupta ro...@ti.com
---
arch/arm/mach-omap2/io.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 31 +---
arch/arm/plat-omap/omap-pm-noop.c | 11 +-
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..c09bf10 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,8 +323,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
- /* The OPP tables have to be registered before a clk init */
- omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap_pm_if_early_init();
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..c5b533d 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,24 +19,7 @@
#include linux/clk.h
#include powerdomain.h
-
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data. Can vary by OMAP chip and board.
- */
-struct omap_opp {
- unsigned long rate;
- u8 opp_id;
- u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
+#include plat/opp.h
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
* framework starts. The _if_ is to avoid name collisions with the
* PM idle-loop code.
*/
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
/**
* omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
* The main initialization code. OPP tables are passed in here. The
* _if_ is to avoid name collisions with the PM idle-loop code.
*/
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
int __init omap_pm_if_init(void);
+#endif
/**
* omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
#include plat/powerdomain.h
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
/*
* Device-driver-originated constraints (via board-*.c files)
*/
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
/* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
{
- mpu_opps = mpu_opp_table;
- dsp_opps = dsp_opp_table;
- l3_opps = l3_opp_table;
return 0;
}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAP: Remove dependency of generic opp layer on cpufreq.
From: Thara Gopinath th...@ti.com
This patch removes the dependency of the opp layer on cpufreq layer.
OPP layer is now enabled to compile and exist in the system
irrespective of whether cpu freq layer is enabled or not.
[NM Note:
Original Patch: https://patchwork.kernel.org/patch/111664/
Still pending: http://marc.info/?l=linux-omapm=127530955314582w=2
To be squashed to patch 1
]
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/Makefile |4 ++--
arch/arm/plat-omap/include/plat/opp.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index faf831d..852fa33 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -13,7 +13,7 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# OPP support in (OMAP3+ only at the moment)
-ifdef CONFIG_CPU_FREQ
+ifdef CONFIG_PM
obj-$(CONFIG_ARCH_OMAP3) += opp.o
obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
endif
@@ -37,4 +37,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
\ No newline at end of file
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 403b69b..f9feb8d 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -61,7 +61,7 @@ struct omap_opp_def {
struct omap_opp;
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_PM
unsigned long opp_get_voltage(const struct omap_opp *opp);
@@ -156,5 +156,5 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
-#endif /* CONFIG_CPU_FREQ */
+#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP OPP layer
Sorry for the duplicate series... I had a git-send-email hiccup on my side. :( 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
[PATCHv2] mailbox: change full flag per mailbox queue instead of global
As pointed by Ohad Ben-Cohen, 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.
Version 2:
- Rebase to the latest.
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 | 10 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..261f6b8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ boolfull;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..c59c9c3 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -145,7 +144,12 @@ static void mbox_rx_work(struct work_struct *work)
while (kfifo_len(mq-fifo) = sizeof(msg)) {
len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
-
+ spin_lock_irq(mq-lock);
+ if (mq-full) {
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ mq-full = false;
+ }
+ spin_unlock_irq(mq-lock);
if (mq-callback)
mq-callback((void *)msg);
}
@@ -170,7 +174,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
1.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-OPP][PATCH 1/2] omap: pm: opp: remove opp_id
Remove the concept of opp_id now that SRF is gone from pm branch
the new framework should exist on silicon variants without the
notion of opp ids
This also removes the deprecated functions opp_get_opp_id and
opp_find_by_opp_id.
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
NOTE: for those desiring to live with SRF will have to revert this
patch
arch/arm/plat-omap/include/plat/opp.h | 15 --
arch/arm/plat-omap/opp.c | 47 -
2 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index f9feb8d..997b56e 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -82,10 +82,6 @@ int opp_enable(struct omap_opp *opp);
int opp_disable(struct omap_opp *opp);
-struct omap_opp *__deprecated opp_find_by_opp_id(struct device *dev,
- u8 opp_id);
-u8 __deprecated opp_get_opp_id(struct omap_opp *opp);
-
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
#else
@@ -139,17 +135,6 @@ static inline int opp_disable(struct omap_opp *opp)
return 0;
}
-static inline struct omap_opp *__deprecated
-opp_find_by_opp_id(struct omap_opp *opps, u8 opp_id)
-{
- return ERR_PTR(-EINVAL);
-}
-
-static inline u8 __deprecated opp_get_opp_id(struct omap_opp *opp)
-{
- return 0;
-}
-
static inline
void opp_init_cpufreq_table(struct omap_opp *opps,
struct cpufreq_frequency_table **table)
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index b9b7bda..a246bb9 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -27,7 +27,6 @@
* @enabled: true/false - marking this OPP as enabled/disabled
* @rate: Frequency in hertz
* @u_volt:Nominal voltage in microvolts corresponding to this OPP
- * @opp_id:opp identifier (deprecated)
* @dev_opp: contains the device_opp struct
*
* This structure stores the OPP information for a given domain.
@@ -38,7 +37,6 @@ struct omap_opp {
bool enabled;
unsigned long rate;
unsigned long u_volt;
- u8 opp_id;
struct device_opp *dev_opp;
};
@@ -132,50 +130,6 @@ unsigned long opp_get_freq(const struct omap_opp *opp)
}
/**
- * opp_find_by_opp_id - look up OPP by OPP ID (deprecated)
- * @opp_type: OPP type where we want the look up to happen.
- * @opp_id:OPP ID to search for
- *
- * Returns the struct omap_opp pointer corresponding to the given OPP
- * ID @opp_id, or returns NULL on error.
- */
-struct omap_opp * __deprecated opp_find_by_opp_id(struct device *dev,
- u8 opp_id)
-{
- struct device_opp *dev_opp;
- struct omap_opp *temp_opp, *opp = ERR_PTR(-ENODEV);
-
- dev_opp = find_device_opp(dev);
- if (IS_ERR(dev_opp))
- return opp;
-
- list_for_each_entry(temp_opp, dev_opp-opp_list, node) {
- if (temp_opp-enabled temp_opp-opp_id == opp_id) {
- opp = temp_opp;
- break;
- }
- }
-
- return opp;
-}
-
-/**
- * opp_get_opp_id() - Provide OPP ID corresponding to an OPP (deprecated)
- * @opp: opp for which frequency has to be returned for
- *
- * Returns an OPP ID for the OPP required, if error, returns 0
- */
-u8 __deprecated opp_get_opp_id(struct omap_opp *opp)
-{
- if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
- pr_err(%s: Invalid parameter being passed\n, __func__);
- return 0;
- }
-
- return opp-opp_id;
-}
-
-/**
* opp_get_opp_count() - Get number of opps enabled in the opp list
* @opp_type: OPP type we want to count
*
@@ -413,7 +367,6 @@ int opp_add(const struct omap_opp_def *opp_def)
/* renumber (deprecated) OPP IDs based on new order */
i = 0;
list_for_each_entry(opp, dev_opp-opp_list, node)
- opp-opp_id = i++;
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
Make opp3xx data which is registered with the opp layer
dependent purely on CONFIG_PM as opp layer and pm.c users
are CONFIG_PM dependent not cpufreq dependent.
so we rename the data definition to opp3xxx_data.c (inline with what
we have for omap2), also move the build definition to be under
the existing CONFIG_PM build instead of CPUFREQ.
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Note:
This takes care of the discussion on opp file renaming and making
it independent of cpufreq, unless I missed something else
arch/arm/mach-omap2/Makefile |5 +
.../mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} |0
2 files changed, 1 insertions(+), 4 deletions(-)
rename arch/arm/mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0b188fa..43d7372 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -58,11 +58,8 @@ obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+=
smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
-endif
+obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
-# CPU Frequency
-ifeq ($(CONFIG_CPU_FREQ),y)
-obj-$(CONFIG_ARCH_OMAP3) += cpufreq34xx.o
endif
# PRCM
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/opp3xxx_data.c
similarity index 100%
rename from arch/arm/mach-omap2/cpufreq34xx.c
rename to arch/arm/mach-omap2/opp3xxx_data.c
--
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-OPP][PATCH 0/2] OMAP: pm: opp: few additional cleanups
Cleanup opp layer on pending topics:
SRF is dead, so remove the opp_id concept from opp layer, no more
deprecated functions for us.. (series is based on khilman's pm branch)
There are two things pending with opp layer as pointed in the discussion
with Sanjeev:
a) we need to make the opp data definition a little more CPUFREQ independent
- i have taken this up in patch 2/2
b) The thing pending: how do we fit in mpurate?
Problem that Sanjeev pointed out in the thread[1] was this:
lets say a bootloader running at freq x, runs kernel at freq y, should'nt the
kernel verify if this is a valid freq for that board before setting it?
The call sequence currently is:
(1) arch/arm/plat-omap/clock.c omap_clk_setup
(2) arch/arm/mach-omap2/clock.c omap2_clk_switch_mpurate_at_boot
(3) arch/arm/mach-omap2/opp3xxx_data.c omap3_pm_init_opp_table
mpurate is populated at (1), used at (2) and the opp table against which
it can be verified is at (3). here in lies the chicken-or-egg problem :(.
since the operating frequencies are decided based on board behavior as well,
we cant really set the frequency at (2) as we do now, and we may want to
consider the option of moving it down beyond (3).
Note: we will also have to consider the fact that we may need a higher/different
voltage for that mpu frequency as well.. which may mean this handling be
moved out of the clock.c to pm.c instead..
Does anyone have a suggestion as to how we'd want to proceed?
Nishanth Menon (2):
omap: pm: opp: remove opp_id
omap3: opp: make independent of cpufreq
arch/arm/mach-omap2/Makefile |5 +--
.../mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} |0
arch/arm/plat-omap/include/plat/opp.h | 15 --
arch/arm/plat-omap/opp.c | 47
4 files changed, 1 insertions(+), 66 deletions(-)
rename arch/arm/mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} (100%)
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Regards,
Nishanth Menon
Ref:
[1]: http://marc.info/?t=12749597273r=1w=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
[PM-OPP][PATCH v2 1/2] omap: pm: opp: remove opp_id
Remove the concept of opp_id now that SRF is gone from pm branch
the new framework should exist on silicon variants without the
notion of opp ids
This also removes the deprecated functions opp_get_opp_id and
opp_find_by_opp_id.
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v1: original patch https://patchwork.kernel.org/patch/118723/
v2: I missed cleaning up opp_add properly :( (I should have removed
the variable i and removed the list walk for renumbering..) apologies
on the spam..
Note: for folks using SRF, you'd have to revert this patch
arch/arm/plat-omap/include/plat/opp.h | 15 -
arch/arm/plat-omap/opp.c | 52 -
2 files changed, 0 insertions(+), 67 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index f9feb8d..997b56e 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -82,10 +82,6 @@ int opp_enable(struct omap_opp *opp);
int opp_disable(struct omap_opp *opp);
-struct omap_opp *__deprecated opp_find_by_opp_id(struct device *dev,
- u8 opp_id);
-u8 __deprecated opp_get_opp_id(struct omap_opp *opp);
-
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
#else
@@ -139,17 +135,6 @@ static inline int opp_disable(struct omap_opp *opp)
return 0;
}
-static inline struct omap_opp *__deprecated
-opp_find_by_opp_id(struct omap_opp *opps, u8 opp_id)
-{
- return ERR_PTR(-EINVAL);
-}
-
-static inline u8 __deprecated opp_get_opp_id(struct omap_opp *opp)
-{
- return 0;
-}
-
static inline
void opp_init_cpufreq_table(struct omap_opp *opps,
struct cpufreq_frequency_table **table)
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index b9b7bda..17f93b2 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -27,7 +27,6 @@
* @enabled: true/false - marking this OPP as enabled/disabled
* @rate: Frequency in hertz
* @u_volt:Nominal voltage in microvolts corresponding to this OPP
- * @opp_id:opp identifier (deprecated)
* @dev_opp: contains the device_opp struct
*
* This structure stores the OPP information for a given domain.
@@ -38,7 +37,6 @@ struct omap_opp {
bool enabled;
unsigned long rate;
unsigned long u_volt;
- u8 opp_id;
struct device_opp *dev_opp;
};
@@ -132,50 +130,6 @@ unsigned long opp_get_freq(const struct omap_opp *opp)
}
/**
- * opp_find_by_opp_id - look up OPP by OPP ID (deprecated)
- * @opp_type: OPP type where we want the look up to happen.
- * @opp_id:OPP ID to search for
- *
- * Returns the struct omap_opp pointer corresponding to the given OPP
- * ID @opp_id, or returns NULL on error.
- */
-struct omap_opp * __deprecated opp_find_by_opp_id(struct device *dev,
- u8 opp_id)
-{
- struct device_opp *dev_opp;
- struct omap_opp *temp_opp, *opp = ERR_PTR(-ENODEV);
-
- dev_opp = find_device_opp(dev);
- if (IS_ERR(dev_opp))
- return opp;
-
- list_for_each_entry(temp_opp, dev_opp-opp_list, node) {
- if (temp_opp-enabled temp_opp-opp_id == opp_id) {
- opp = temp_opp;
- break;
- }
- }
-
- return opp;
-}
-
-/**
- * opp_get_opp_id() - Provide OPP ID corresponding to an OPP (deprecated)
- * @opp: opp for which frequency has to be returned for
- *
- * Returns an OPP ID for the OPP required, if error, returns 0
- */
-u8 __deprecated opp_get_opp_id(struct omap_opp *opp)
-{
- if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
- pr_err(%s: Invalid parameter being passed\n, __func__);
- return 0;
- }
-
- return opp-opp_id;
-}
-
-/**
* opp_get_opp_count() - Get number of opps enabled in the opp list
* @opp_type: OPP type we want to count
*
@@ -344,7 +298,6 @@ int opp_add(const struct omap_opp_def *opp_def)
struct omap_opp *opp, *new_opp;
struct platform_device *pdev;
struct list_head *head;
- int i;
/* find the correct hwmod, and device */
if (!opp_def-hwmod_name) {
@@ -410,11 +363,6 @@ int opp_add(const struct omap_opp_def *opp_def)
if (new_opp-enabled)
dev_opp-enabled_opp_count++;
- /* renumber (deprecated) OPP IDs based on new order */
- i = 0;
- list_for_each_entry(opp, dev_opp-opp_list, node)
- opp-opp_id = i++;
-
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send
Re: [PATCH] OMAP: DSS2: don't power off a panel twice
Laine Walker-Avina wrote:
On Tue, Aug 10, 2010 at 5:16 AM, Stanley.Miao
stanley.m...@windriver.com wrote:
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Instead of adding a new variable and a bunch of extra code, I solved
this problem on my local tree by just not doing anything if we're
already not active. See the follwoing for the generic panel driver.
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..abc03f4 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -91,9 +91,12 @@ static int generic_panel_enable(struct
omap_dss_device *dssdev)
static void generic_panel_disable(struct omap_dss_device *dssdev)
{
- generic_panel_power_off(dssdev);
+ if(dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ {
+ generic_panel_power_off(dssdev);
- dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+ }
}
Yes, This is a good idea. If we add this check into power_off(), will it
be better ? How do you think ?
Stanley.
static int generic_panel_suspend(struct omap_dss_device *dssdev)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] OMAP: DSS2: don't power off a panel twice
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now check the state of a dssdev
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-acx565akm.c |6 ++
drivers/video/omap2/displays/panel-generic.c |6 ++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 ++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 ++
drivers/video/omap2/displays/panel-taal.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c|6 ++
.../video/omap2/displays/panel-tpo-td043mtea1.c|6 ++
7 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..374cbeb 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -587,6 +587,9 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
mutex_lock(md-mutex);
r = omapdss_sdi_display_enable(dssdev);
@@ -642,6 +645,9 @@ static void acx_panel_power_off(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
mutex_lock(md-mutex);
if (!md-enabled) {
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..395a68d 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -39,6 +39,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -58,6 +61,9 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..0c6896c 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -43,6 +43,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..9a138f6 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -135,6 +135,9 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
int r = 0;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -157,6 +160,9 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index aaf5d30..c649f06 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -635,6 +635,9 @@ static int taal_power_on(struct omap_dss_device *dssdev)
u8 id1, id2, id3;
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
if (r)
@@ -715,6 +718,9 @@ static void taal_power_off(struct omap_dss_device *dssdev)
{
struct taal_data *td = dev_get_drvdata(dssdev-dev);
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
dsi_bus_lock();
cancel_delayed_work(td-esd_work);
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
Re: [PATCH] OMAP: DSS2: don't power off a panel twice
On 08/11/2010 11:09 AM, stanley.miao wrote:
Laine Walker-Avina wrote:
On Tue, Aug 10, 2010 at 5:16 AM, Stanley.Miao
stanley.m...@windriver.com wrote:
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Instead of adding a new variable and a bunch of extra code, I solved
this problem on my local tree by just not doing anything if we're
already not active. See the follwoing for the generic panel driver.
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..abc03f4 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -91,9 +91,12 @@ static int generic_panel_enable(struct
omap_dss_device *dssdev)
static void generic_panel_disable(struct omap_dss_device *dssdev)
{
-generic_panel_power_off(dssdev);
+if(dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+{
+generic_panel_power_off(dssdev);
-dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+}
}
Yes, This is a good idea. If we add this check into power_off(), will it
be better ? How do you think ?
Both you guys' patches can solve a issue here:
https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/588243
Laine,
I suspect we still need whose checks in suspend/resume routines, Stanley's V2
patch should be better.
Although I did following test on my Beagle board, I failed to see any oops.
r...@beagle1:/# echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
r...@beagle1:/# echo mem /sys/power/state
Thanks,
--
Bryan Wu bryan...@canonical.com
Kernel Developer+86.138-1617-6545 Mobile
Ubuntu Kernel Team | Hardware Enablement Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap_hwmod: remove locking from hwmod_for_each iterators
Hi Kevin,
On Tue, 10 Aug 2010, Kevin Hilman wrote:
Remove unnecessary locking in the 'for_each' iterators. Any locking should
be taken care of by using hwmod API functions in the functions called by the
iterators.
In addition, having locking here causes lockdep to detect possible circular
dependencies (originally reported by Partha Basak p-bas...@ti.com.)
For example, during init (#0 below) you have the hwmod_mutex acquired
(hwmod_for_each_by_class()) then the dpm_list_mtx acquired
(device_pm_add()). Later, during suspend the dpm_list_mtx is aquired
first (dpm_suspend_noirq()), then the omap_hwmod_mutex is acquired
(omap_hwmod_idle()).
[ 810.170593] ===
[ 810.170593] [ INFO: possible circular locking dependency detected ]
[ 810.170623] 2.6.35-rc5-00131-g56e767c-dirty #34
[ 810.170654] ---
[ 810.170654] sh/670 is trying to acquire lock:
[ 810.170684] (omap_hwmod_mutex){+.+.+.}, at: [c004fe84]
omap_hwmod_idle+0x1c/0x38
[ 810.170745]
[ 810.170745] but task is already holding lock:
[ 810.170776] (dpm_list_mtx){+.+...}, at: [c023baf8]
dpm_suspend_noirq+0x28/0x188
[ 810.170806]
[ 810.170837] which lock already depends on the new lock.
[ 810.170837]
[ 810.170837]
[ 810.170837] the existing dependency chain (in reverse order) is:
[ 810.170867]
[ 810.170867] - #1 (dpm_list_mtx){+.+...}:
[ 810.170898][c009bc3c] lock_acquire+0x60/0x74
[ 810.170959][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.170989][c023bcc0] device_pm_add+0x14/0xcc
[ 810.171020][c0235304] device_add+0x3b8/0x564
[ 810.171051][c0238834] platform_device_add+0x104/0x160
[ 810.171112][c005f2a8] omap_device_build_ss+0x14c/0x1c8
[ 810.171142][c005f36c] omap_device_build+0x48/0x50
[ 810.171173][c004d34c] omap2_init_gpio+0xf0/0x15c
[ 810.171203][c004f254] omap_hwmod_for_each_by_class+0x60/0xa4
[ 810.171264][c0040340] do_one_initcall+0x58/0x1b4
[ 810.171295][c0008574] kernel_init+0x98/0x150
[ 810.171325][c0041968] kernel_thread_exit+0x0/0x8
[ 810.171356]
[ 810.171356] - #0 (omap_hwmod_mutex){+.+.+.}:
[ 810.171386][c009b4e4] __lock_acquire+0x108c/0x1784
[ 810.171447][c009bc3c] lock_acquire+0x60/0x74
[ 810.171478][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.171508][c004fe84] omap_hwmod_idle+0x1c/0x38
[ 810.171539][c005eb9c] omap_device_idle_hwmods+0x20/0x3c
[ 810.171600][c005ec88] _omap_device_deactivate+0x58/0x14c
[ 810.171630][c005ef50] omap_device_idle+0x4c/0x6c
[ 810.171661][c0053e7c] platform_pm_runtime_suspend+0x4c/0x74
[ 810.171691][c023c9f8] __pm_runtime_suspend+0x204/0x34c
[ 810.171722][c023cbe0] pm_runtime_suspend+0x20/0x34
[ 810.171752][c0053dbc] platform_pm_runtime_idle+0x8/0x10
[ 810.171783][c023c344] __pm_runtime_idle+0x15c/0x198
[ 810.171813][c023c3f8] pm_runtime_idle+0x1c/0x30
[ 810.171844][c0053dac] platform_pm_suspend_noirq+0x48/0x50
[ 810.171875][c023ad4c] pm_noirq_op+0xa0/0x184
[ 810.171905][c023bb7c] dpm_suspend_noirq+0xac/0x188
[ 810.171936][c00a5d00] suspend_devices_and_enter+0x94/0x1d8
[ 810.171966][c00a5f00] enter_state+0xbc/0x120
[ 810.171997][c00a5654] state_store+0xa4/0xb8
[ 810.172027][c01ea9e0] kobj_attr_store+0x18/0x1c
[ 810.172088][c0129acc] sysfs_write_file+0x10c/0x144
[ 810.172119][c00df83c] vfs_write+0xb0/0x148
[ 810.172149][c00df984] sys_write+0x3c/0x68
[ 810.172180][c0040920] ret_fast_syscall+0x0/0x3c
The intention of the mutex_lock() in the omap_hwmod_for_each*() case is to
protect against changes to omap_hwmod_list during the list iteration. It
is true that omap_hwmod_list is only likely to change very early in boot,
as the hwmods are registered, so perhaps this is not necessary in
practice. But at least theoretically it seems necessary, since I don't
think that list_for_each_entry() is safe if a list addition is in progress
simultaneously.
On the other hand, taking the mutex during most of the other
omap_hwmod calls, such as
omap_hwmod_{enable,idle,shutdown,enable_clocks,disable_clocks,reset,enable_wakeup,disable_wakeup}
is definitely not needed since those functions do not affect
omap_hwmod_list. The goal of the mutex there was simply to protect
against concurrent calls to those functions. To do that, perhaps the lock
could be moved into the struct omap_hwmod? I believe you suggested this
during our PM discussions in Bengaluru. That would carry a slight memory
space penalty, but would also deserialize hwmod operations on an SMP
system. If you agree, perhaps you might spin a patch for that instead?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH] OMAP3: PM: ensure IO wakeups are properly disabled
On Tue, 10 Aug 2010 16:53:51 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com During idle, if the PER powerdomain transitions and CORE does not (as is the case with the lower C-states when using CPUidle) the IO pad wakeups are not being disabled in the idle path after they are enabled. This patch ensures that the check for disabling IO wakeups also checks for PER transitions, matching the check done to enable IO wakeups. Found when debugging PM/CPUidle related problems reported by Ameya Palande ameya.pala...@nokia.com. Problems were triggered particularily on boards with UART2 consoles (n900, Overo) since UART2 is in the PER powerdomain. Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well as with current PM branch. Boards tested: n900, Overo, omap3evm. Cc: Ameya Palande ameya.pala...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- I don't see the problem on N900 anymore after applying this patch. Feel free to add: Tested-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] mailbox: change full flag per mailbox queue instead of global
From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv2] mailbox: change full flag per mailbox queue instead of global Date: Wed, 11 Aug 2010 03:12:49 +0200 As pointed by Ohad Ben-Cohen, 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. Version 2: - Rebase to the latest. Reported-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Ok for me. Tony, could you take this in? since it's a single patch for fix. -- To unsubscribe from this list: send the line unsubscribe 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 v5] OMAP: GPIO: Implement GPIO as a platform device
On Tue, 10 Aug 2010, Basak, Partha wrote: As per our discussion with Paul you during workshop, I believe, optional clock control should be done using clock APIs. So, I would go by your suggestion 1 of exposing an API to expose the optional clocks in the hwmod, something like: struct omap_hwmod_opt_clk * omap_hwmod_get_opt_clks(struct omap_hwmod *oh); If agreed, Charu will send updated patch. This should be done by modifying the hwmod code to call clk_add_alias() for the clock names for the optional clocks. I don't think any extra API is needed. - 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
