Re: [RFC] [PATCH v3 1/4] OMAP4: Keyboard controller support
On Tue, Jun 01, 2010 at 07:43:19AM +0300, Felipe Balbi wrote:
On Mon, May 31, 2010 at 11:44:02PM +0200, ext Arce, Abraham wrote:
diff --git a/arch/arm/plat-omap/include/plat/omap4-keypad.h
b/arch/arm/plat-omap/include/plat/omap4-keypad.h
new file mode 100644
index 000..7a6ce70
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap4-keypad.h
@@ -0,0 +1,23 @@
+#ifndef ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+#define ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+
+#include linux/input/matrix_keypad.h
+
+struct omap4_keypad_platform_data {
+ const struct matrix_keymap_data *keymap_data;
+
+ u8 rows;
+ u8 cols;
rows and cols should be passed by struct matryx_keymap_data
There isn't such member in matrix_keymap_data, it only contains length
of the keymap.
+ u16 irq;
+ void __iomem *base;
base and irq are to be passed by struct resource
+ int (*device_enable) (struct platform_device *pdev);
+ int (*device_shutdown) (struct platform_device *pdev);
+ int (*device_idle) (struct platform_device *pdev);
why are you passing these three here ?? I would expect those to be
driver specific not board specific.
Except that driver does not seem t be using them... I am not quite sure
why they are needed.
+ error = request_irq(keypad_data-irq, omap4_keypad_interrupt,
+IRQF_TRIGGER_FALLING,
+omap4-keypad, keypad_data);
+ if (error) {
+ dev_err(pdev-dev, failed to register interrupt\n);
+ goto err_free_input;
+ }
+
+ error = input_register_device(keypad_data-input);
register the input device before enabling the irq line please, you
might end up with 'spurious' irqs happening during probe otherwise.
It is OK to register input device after registering IRQ. As soon as
input device is allocated with input_alloc_device() it can accept
events (although they will not go anywhere).
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Friday, May 28, 2010 2:43 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on suspend and resume.
This allows device drivers to get rid of direct management of their
clocks in their suspend/resume paths, and let omap_device do it for
them.
We currently use the _noirq (late suspend, early resume) versions of
the suspend/resume methods to ensure that the device is not disabled
too early for any drivers also using the _noirq methods.
NOTE: only works for devices with omap_hwmod support.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm_bus.c | 61
++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
#endif /* CONFIG_PM_RUNTIME */
+#ifdef CONFIG_SUSPEND
+int platform_pm_suspend_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev-driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (!drv)
+ return 0;
+
+ if (drv-pm) {
+ if (drv-pm-suspend_noirq)
+ ret = drv-pm-suspend_noirq(dev);
+ }
+
+ if (omap_device_is_valid(odev)) {
+ if (odev-flags OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, no automatic bus-level
system resume.\n);
+ return 0;
+ }
+
+ dev_dbg(dev, %s\n, __func__);
+ omap_device_idle(pdev);
Is it expected that a device is always in enabled state at this point?
If the device is already in idle a call to omap_device_idle unconditionally
throws up warnings from the omap_device api.
+ } else {
+ dev_dbg(dev, not an omap_device\n);
+ }
+
+ return ret;
+}
+
+int platform_pm_resume_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev-driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (omap_device_is_valid(odev)) {
+ if (odev-flags OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, no automatic bus-level
system resume.\n);
+ return 0;
+ }
+
+ dev_dbg(dev, %s\n, __func__);
+ omap_device_enable(pdev);
+ } else {
+ dev_dbg(dev, not an omap_device\n);
+ }
+
+ if (!drv)
+ return 0;
+
+ if (drv-pm) {
+ if (drv-pm-resume_noirq)
+ ret = drv-pm-resume_noirq(dev);
+ }
+
+ return ret;
+}
+#endif /* CONFIG_SUSPEND */
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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 v3 1/4] OMAP4: Keyboard controller support
On Tue, Jun 01, 2010 at 08:09:54AM +0200, ext Dmitry Torokhov wrote: There isn't such member in matrix_keymap_data, it only contains length of the keymap. sorry, I had the idea in mind that KEY(row, col, val) would do something different. -- 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 6/6] omap: move generic omap3 features to generic
On 06/01/2010 08:34 AM, Venkatraman S wrote: If you can post them formally as part of the series, I can test and ack them (with OMAP3, OMAP4) My original comment was even if these were not implemented due to some constraints, they should be mentioned in the code (as TODO / FIXME etc). The caveat description is not going to show up in commit logs or printks okie.. the 3 RFC patches following to the list. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Hi, ext Arve Hjønnevåg wrote: It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. Sorry if i'm asking something that was already said, but the thread is quite complex and i am not sure i have been able to grasp all of it. So, regardless of the SW implementation: -1) are you focusing on good HW or do you want to address all at the same time? -2) would you be ok with addressing bad HW as a special case, which requires workarounds and shouldn't dictate the overall design? -3) do you agree with the assumption that new HW is expected to get reasonably better and therefore workarounds at point 2) will progressively be confined to devices less and less common? -4) going to the definition of good and bad (maybe this should have come earlier in the list), can we define good HW as HW where: * suspend state and lowest achievable runtime idle state are basically equivalent from both power consumption and latency pov * the HW itself is properly able to track wakeup sources while it is in its deepest power state (as example OMAP3 has few independent wake-capable pads and a wake ring where one only gets the information that at least one of the pads belonging to such ring has received a wakeup) * wakeup sources can be dynamically masked at HW level, so that if a peripheral is not interesting, it doesn't wakeup the system (for example the camera button when the camera cover is closed) -5) HW that is not capable of properly generating asynchronous signal is most likely the cause for extra timers in kernel and it should be considered bad - in any other case having recurring in-kernel timers should be treated as bugs, if their existence is not tied to some meaningful work thanks, 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: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Mon, 31 May 2010 14:57:22 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
On Monday 31 May 2010 13:00:21 ext Liam Girdwood wrote:
...
+static int hw_rule_bsize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *bs = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
Best to make these variable names more meaningful.
Sure, I can change that. I have picked these, since all code, which adds
hw_rule
(and the writing an ALSA driver manual) are using variables like this.
In Here I mean:
bs == Buffer Size
c == Channels
Change also function names. They should start with omap_mcbsp_.
hw_rule_bsize_by_channels
hw_rule_psize_by_channels
-
omap_mcbsp_(calc_max_bufsize, rule_max_buf, or something)
omap_mcbsp_(calc_max_periodsize)
--
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: [RFC PATCH 2/5] OMAP3: McBSP: Change the way how the FIFO is handled
On Monday 31 May 2010 20:41:12 ext Nishanth Menon wrote:
On 05/31/2010 11:16 AM, Peter Ujfalusi wrote:
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
From users of McBSP, now it is expected to use this method.
Asking for threshold 1 means that the value written to threshold
registers are going to be 0, which means 1 word threshold.
just a 2cent minor comment: maybe omap_mcbsp_platform_data needs
structure documentation.. it might be difficult for folks to figure that
out from commit ID itself..
I can add comments in the mach-omap2/mcbsp.c like this:
Signed-off-by: Peter Ujfalusipeter.ujfal...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c | 10 +-
arch/arm/plat-omap/mcbsp.c | 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 016fe60..9139958 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,7 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -142,7 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x3FF,
+ .buffer_size= 0x500,
+ .buffer_size= 0x500, /* The FIFO has 1024 + 256 locations */
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
@@ -152,7 +152,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -161,7 +161,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -170,7 +170,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
},
};
#define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 51d8abf..6462968 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -497,7 +497,8 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH2, threshold);
+ if (threshold threshold= mcbsp-max_tx_thres)
+ MCBSP_WRITE(mcbsp, THRSH2, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
@@ -519,7 +520,8 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH1, threshold);
+ if (threshold threshold= mcbsp-max_rx_thres)
+ MCBSP_WRITE(mcbsp, THRSH1, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
@@ -1696,8 +1698,8 @@ static inline void __devinit
omap34xx_device_init(struct omap_mcbsp *mcbsp)
{
mcbsp-dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
if (cpu_is_omap34xx()) {
- mcbsp-max_tx_thres = max_thres(mcbsp);
- mcbsp-max_rx_thres = max_thres(mcbsp);
+ mcbsp-max_tx_thres = max_thres(mcbsp) - 0x10;
+ mcbsp-max_rx_thres = max_thres(mcbsp) - 0x10;
/*
* REVISIT: Set dmap_op_mode to THRESHOLD as default
* for mcbsp2 instances.
Is this
Re: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tue, 1 Jun 2010 09:47:09 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: I like the following naming: omap_mcbsp_hwrule_min_buffersize() omap_mcbsp_hwrule_max_periodsize() Looks clear to me. Also, I think there is no point to limit the lower period size in threshold mode to 32, so I will remove that as well I think. What was the reason why period size cannot be bigger than threshold? This constraint was there before your patch but I don't remember reason for it. Should it be opposite that period size cannot be smaller than threshold? -- 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] OMAP: DMTIMER: Ack pending interrupt always when stopping a timer
* Kevin Hilman khil...@deeprootsystems.com [100525 19:07]: Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com The kernel timer queue is being run currently from a GP timer running in a one shot mode, which works in a way that when it expires, it will also stop. Usually during this situation, the interrupt handler will ack the interrupt, load a new value to the timer and start it again. During suspend, the situation is slightly different, as we disable interrupts just before timekeeping is suspended, which leaves a small window where the timer can expire before it is stopped, and will leave the interrupt flag pending. This pending interrupt will prevent ARM sleep entry, thus now we ack it always when we are attempting to stop a timer. Signed-off-by: Tero Kristo tero.kri...@nokia.com Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/dmtimer.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index c64875f..023d664 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -541,11 +541,13 @@ void omap_dm_timer_stop(struct omap_dm_timer *timer) * timer is stopped */ udelay(350 / clk_get_rate(timer-fclk) + 1); - /* Ack possibly pending interrupt */ - omap_dm_timer_write_reg(timer, OMAP_TIMER_STAT_REG, - OMAP_TIMER_INT_OVERFLOW); #endif } +#ifdef CONFIG_ARCH_OMAP2PLUS + /* Ack possibly pending interrupt */ + omap_dm_timer_write_reg(timer, OMAP_TIMER_STAT_REG, + OMAP_TIMER_INT_OVERFLOW); +#endif } EXPORT_SYMBOL_GPL(omap_dm_timer_stop); I'll add this to omap-fixes queue, but will remove the ifdef CONFIG_ARCH_OMAP2PLUS around clearing the interrupt as the situation would be the same for omap1 if ever used the same way. 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: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tuesday 01 June 2010 10:38:28 ext Jarkko Nikula wrote: On Tue, 1 Jun 2010 09:47:09 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: I like the following naming: omap_mcbsp_hwrule_min_buffersize() omap_mcbsp_hwrule_max_periodsize() Looks clear to me. Also, I think there is no point to limit the lower period size in threshold mode to 32, so I will remove that as well I think. What was the reason why period size cannot be bigger than threshold? This constraint was there before your patch but I don't remember reason for it. When DMA is used to push the data to McBSP on OMAP3: The McBSP threshold means, that if threshold amount of locations (words) are free in the buffer, than the DMA request line will be asserted, and McBSP expects that DMA will transfer _exactly_ threshold number of words in response to the DMA request. So, if threshold is 1 (in register it is 0), than McBSP requests for new word, whenever a single location is free in the FIFO. The DMA should send 1 word per DMA request. If threshold is configured to 100 (99 in register), than McBSP will asserts the DMA request line, when 100 locations are free. Than DMA has to send 100 words per DMA request. So we need to limit the period size (which is used to configure the DMA's elem count - number of words per DMA request) that it shall never be bigger than the threshold. Should it be opposite that period size cannot be smaller than threshold? No. -- Péter -- To unsubscribe from this list: send the line unsubscribe 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: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
Hi Resending... On Tuesday 01 June 2010 10:38:28 ext Jarkko Nikula wrote: On Tue, 1 Jun 2010 09:47:09 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: I like the following naming: omap_mcbsp_hwrule_min_buffersize() omap_mcbsp_hwrule_max_periodsize() Looks clear to me. Also, I think there is no point to limit the lower period size in threshold mode to 32, so I will remove that as well I think. What was the reason why period size cannot be bigger than threshold? This constraint was there before your patch but I don't remember reason for it. When DMA is used to push the data to McBSP on OMAP3: The McBSP threshold means, that if threshold amount of locations (words) are free in the buffer, than the DMA request line will be asserted, and McBSP expects that DMA will transfer exactly threshold number of words in response to the DMA request. So, if threshold is 1 (in register it is 0), than McBSP requests for new word, whenever a single location is free in the FIFO. The DMA should send 1 word per DMA request. If threshold is configured to 100 (99 in register), than McBSP will asserts the DMA request line, when 100 locations are free. Than DMA has to send 100 words per DMA request. So we need to limit the period size (which is used to configure the DMA's elem count - number of words per DMA request) that it shall never be bigger than the threshold. Should it be opposite that period size cannot be smaller than threshold? No. Well... One thing I was wondering about for a long time. If we change the way how McBSP/DMA is used on OMAP3 (we could use the frame mode for that): We place constraint on the period step to be the size of the threshold selected. So userspace can have bigger periods than the McBSP FIFO and still gain benefit from the usage of the FIFO. So period size is x * threshold. We configure McBSP threshold We configure DMA to push threshold amount of word per request. In the DMA callback, we count, and when the x-th DMA request has been served, than we call elapsed. If there is interest, I might look at this. I guess this could be useful on McBSP1,3,4, and 5, which has small FIFO... -- Péter -- To unsubscribe from this list: send the line unsubscribe 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 00/14] Multiple fixes for Devkit8000
* Thomas Weber we...@corscience.de [100601 08:31]: Hello Tony, can you please add these patches? Or is something to change? Well this looks OK, but for the next merge window. If you have some fixes that are real regressions or major bugs as requested by Linus: http://lwn.net/Articles/389982/ Then please send those separately for the current -rc series. Oh, and some of the patches are missing a description. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [OMAP1] Add MMC board code common to HTC devices
On Fri, May 28, 2010 at 10:28:04PM -0700, Cory Maccarrone wrote:
This change adds the htc-mmc.c and htc-mmc.h files that
contain common setup code for many OMAP850-based HTC
smartphones. This code is a port of the code used by
the linwizard project to support devices such as the
HTC Wizard, HTC Herald, HTC Opal, etc.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/htc-mmc.c | 104
+
arch/arm/mach-omap1/htc-mmc.h | 26 ++
2 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/htc-mmc.c
create mode 100644 arch/arm/mach-omap1/htc-mmc.h
diff --git a/arch/arm/mach-omap1/htc-mmc.c b/arch/arm/mach-omap1/htc-mmc.c
new file mode 100644
index 000..4fa8bb4
--- /dev/null
+++ b/arch/arm/mach-omap1/htc-mmc.c
@@ -0,0 +1,104 @@
+/*
+ * linux/arch/arm/mach-omap1/htc-mmc.c
+ *
+ * Copyright (C) 2007 Instituto Nokia de Tecnologia - INdT
+ * Author: Felipe Balbi felipe.l...@indt.org.br
+ *
+ * This code is based on linux/arch/arm/mach-omap2/board-n800-mmc.c, which
is:
+ * Copyright (C) 2006 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include plat/mmc.h
+#include asm/mach-types.h
+
+#include linux/gpio.h
+#include linux/delay.h
+
+#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
+
+#define OMAP_MMC_REG_SYSC (0xfffb7800 + 0x32)
+#define OMAP_MMC_REG_SYSS (0xfffb7800 + 0x34)
Where are these used?
+static int slot_cover_open;
+static struct device *mmc_device;
+
+static int htc_mmc_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+#ifdef CONFIG_MMC_DEBUG
+ dev_dbg(dev, Set slot %d power: %s (vdd %d)\n, slot + 1,
+ power_on ? on : off, vdd);
+#endif
+ if (slot != 0) {
+ dev_err(dev, No such slot %d\n, slot + 1);
+ return -ENODEV;
+ }
+
+ return 0;
+}
No-op?
+static int htc_mmc_set_bus_mode(struct device *dev, int slot, int bus_mode)
+{
+#ifdef CONFIG_MMC_DEBUG
+ dev_dbg(dev, Set slot %d bus_mode %s\n, slot + 1,
+ bus_mode == MMC_BUSMODE_OPENDRAIN ? open-drain : push-pull);
+#endif
+ if (slot != 0) {
+ dev_err(dev, No such slot %d\n, slot + 1);
+ return -ENODEV;
+ }
+
+ /* Treated on upper level */
+
+ return bus_mode;
+}
+
+static int htc_mmc_get_cover_state(struct device *dev, int slot)
+{
+ BUG_ON(slot != 0);
+ return slot_cover_open;
+}
Just a complicated way to return zero...
+static int htc_mmc_late_init(struct device *dev)
+{
+ mmc_device = dev;
+ return 0;
+}
What is this good for?
+static void htc_mmc_cleanup(struct device *dev)
+{
+}
+
+static struct omap_mmc_platform_data htc_mmc1_data = {
+ .nr_slots = 1,
+ .switch_slot= NULL,
+ .init = htc_mmc_late_init,
+ .cleanup= htc_mmc_cleanup,
+ .slots[0] = {
+ .set_power = htc_mmc_set_power,
+ .set_bus_mode = htc_mmc_set_bus_mode,
+ .get_ro = NULL,
+ .get_cover_state= htc_mmc_get_cover_state,
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ MMC_VDD_32_33 | MMC_VDD_33_34,
+ .name = mmcblk,
+ .nomux = 1,
+ .wires = 4,
+ .switch_pin = -1,
+ },
+};
To me above seems completely no-op, so it could be simplified this way:
static struct omap_mmc_platform_data htc_mmc1_data = {
.nr_slots = 1,
.switch_slot= NULL,
.slots[0] = {
.ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = mmcblk,
.nomux = 1,
.wires = 4,
.switch_pin = -1,
},
};
Now, once this file contains only one structure definition, is it worth
to let it exist at all? What about adding it to board-htcherald.c instead?
+
+static struct omap_mmc_platform_data *htc_mmc_data[1];
+
+void __init htc_mmc_init(void)
+{
+ /* register it */
+ htc_mmc_data[0] = htc_mmc1_data;
+ omap1_init_mmc(htc_mmc_data, 1);
+}
+#endif
+
diff --git a/arch/arm/mach-omap1/htc-mmc.h b/arch/arm/mach-omap1/htc-mmc.h
new file mode 100644
index 000..480de14
--- /dev/null
+++ b/arch/arm/mach-omap1/htc-mmc.h
@@ -0,0 +1,26 @@
+/*
+ *
Re: [RFC ] [PATCH V2 2/2] Platform changes for CMA3000
* Hemanth V heman...@ti.com [100521 09:49]: From: Hemanth V heman...@ti.com Date: Thu, 20 May 2010 20:33:03 +0530 Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver Patch description? 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] omap: pandora: add support for wl1251 wifi chip
* Grazvydas Ignotas nota...@gmail.com [100527 12:37]: Define platform data and setup GPIOs so that TI wl1251 wifi chip and it's driver can function. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- I could have sent this earlier but it depended on the wifi tree, hope this can still go in for -rc2, it's just platform data anyway. Sorry, we have to add this into for-next for 2.6.36 merge window, see the comments at: http://lwn.net/Articles/389982/ 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 3/9] OMAP2/3/4 : Dual mode timer device registration.
* Benoit Cousson b-cous...@ti.com [100531 01:57]: + +#define NO_EARLY_TIMERS2 The NO_ is a little bit confusing, you should maybe use _COUNT. Also NR_ is commonly used. 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: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tue, 1 Jun 2010 11:19:30 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: If threshold is configured to 100 (99 in register), than McBSP will asserts the DMA request line, when 100 locations are free. Than DMA has to send 100 words per DMA request. So we need to limit the period size (which is used to configure the DMA's elem count - number of words per DMA request) that it shall never be bigger than the threshold. Now I get it with some get hands dirty testing :-) So this is a feature of SDMA that in threshold mode the transfer size must equal or smaller than threshold (as says the TRM). Still don't understand why the transfer size is dependent on peripheral FIFO threshold size but that's the fact and we must obey it as Eduardo's original patch and your's are doing. If there is interest, I might look at this. I guess this could be useful on McBSP1,3,4, and 5, which has small FIFO... Yes, have a packet based DMA transfer saving power and then we have bunch of interrupts coming :-) -- 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 0/9] OMAP: DMTIMER: Convert platform driver so as to make use of hwmod + omap device framework for OMAP2 PLUS
* Thara Gopinath th...@ti.com [100529 17:31]: This patch series converts the OMAP Dual Mode Timer into a platform driver. This involves using of hwmod structures and omap_device layer for OMAP2/3/4 dmtimers and generic linux platform device layer for OMAP1. As a result of this patch series the dmtimer platform driver resides in arch/arm/plat-omap directory and arch specific implementations and device registerations reside in arch/arm/mach-omap1 and arch/arm/mach-omap2 for OMAP1 and OMAP2 PLUS respectively. This patch series has been compile tested for OMAP1 using omap_1610_h2_defconfig, compile tested for OMAP2 using omap3_defconfig and boot and sanity tested for OMAP3/OMAP4 again using omap3_defconfig. Boot testing has been done on OMAP3430 SDP and OMAP4430 SDP boards. All testing has been done on origin/origin/pm-wip/hwmods-omap4 branch off Kevin Hilman's tree as these patches have dependencies on runtime pm API's and OMAP4 autogenerated hwmod data base. It would be great if somebody could test these patches on OMAP1 and OMAP2 platforms. Looks good, but the problem I see with this series is that it's not an incremental set of patches where each patch can be verified to compile and work for all the omaps. Please restructure your series so each patch keeps working and we end up with the actual timer code under plat-omap you should be able to add all the hwmod and platform data, then add a patch that changes the timer code to use the platform data as the last patch. 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: [RFC ] [PATCH V2 2/2] Platform changes for CMA3000
- Original Message - From: Tony Lindgren t...@atomide.com To: Hemanth V heman...@ti.com Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Sent: Tuesday, June 01, 2010 2:05 PM Subject: Re: [RFC ] [PATCH V2 2/2] Platform changes for CMA3000 * Hemanth V heman...@ti.com [100521 09:49]: From: Hemanth V heman...@ti.com Date: Thu, 20 May 2010 20:33:03 +0530 Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver Patch description? This basically adds platform changes i.e platform data and GPIO configuration. Thought I could get away without duplicating the info :) -- To unsubscribe from this list: send the line unsubscribe 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 v3 2/4] OMAP4: Keyboard device registration
* Arce, Abraham x0066...@ti.com [100601 00:39]:
Register keyboard device with hwmod framework
Please test this with omap3_defconfig too, and make sure it does not break
things for omap2 and omap3.
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap4_keypad_platform_data *pdata;
+
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
if (!cpu_is_omap44xx())
return -ENODEV;
Might be needed here.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] kmemleak: Fix false positive with special scan
Hi, 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 introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. For this version 2, to avoid client kernel module being unloaded before unregistering special conversion, module reference count is used. This was pointed by Phil Carmody. 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 attribution bits. Right now I don't have other use cases but I hope that there could be some that this special scan works with. Test: # echo scan kmemleak # modprobe kmemleak-special-test [ 1328.260162] Stored 1...@dfc5ac00 - 9fc5ac01 [ 1328.264984] Stored 1...@dfc5b800 - 9fc5b801 [ 1328.269500] Stored 1...@dfc5b400 - 9fc5b401 [ 1328.273895] Stored 1...@dfc5b000 - 9fc5b001 [ 1328.278381] Stored 1...@deb9bc00 - 9eb9bc01 [ 1328.282714] Stored 1...@deea6c00 - 9eea6c01 [ 1328.287139] Stored 1...@deea7c00 - 9eea7c01 [ 1328.291473] Stored 1...@deea7800 - 9eea7801 # echo scan kmemleak [ 1344.062591] kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # rmmod kmemleak-special-test # echo scan kmemleak # modprobe kmemleak-special-test timeout=60 [ 71.758850] Stored 1...@dfc5b000 - 9fc5b001 [ 71.763702] Stored 1...@dfc5b400 - 9fc5b401 [ 71.768066] Stored 1...@dfc5b800 - 9fc5b801 [ 71.772583] Stored 1...@dfc5bc00 - 9fc5bc01 [ 71.776977] Stored 1...@deea6000 - 9eea6001 [ 71.781341] Stored 1...@deea6400 - 9eea6401 [ 71.785736] Stored 1...@deea6800 - 9eea6801 [ 71.790069] Stored 1...@deea6c00 - 9eea6c01 [ 71.794433] kmemleak_special_init: Registered special scan: bf000360 # echo scan kmemleak [ 79.588836] custom_conversion: Converted 9fc5b001 - dfc5b000 [ 79.594696] custom_conversion: Converted 9fc5b401 - dfc5b400 [ 79.600494] custom_conversion: Converted 9fc5b801 - dfc5b800 [ 79.606292] custom_conversion: Converted 9fc5bc01 - dfc5bc00 [ 79.612060] custom_conversion: Converted 9eea6001 - deea6000 [ 79.617889] custom_conversion: Converted 9eea6401 - deea6400 [ 79.623687] custom_conversion: Converted 9eea6801 - deea6800 [ 79.629486] custom_conversion: Converted 9eea6c01 - deea6c00 # rmmod kmemleak-special-test rmmod: cannot unload 'kmemleak_special_test': Resource temporarily unavailable # lsmod kmemleak-special-test Module Size Used byNot tainted kmemleak_special_test 1467 1 # [ 131.800354] no_special_func: Unregistered special scan bf000360 # lsmod kmemleak-special-test Module Size Used byNot tainted kmemleak_special_test 1467 0 # rmmod kmemleak-special-test Hiroshi DOYU (3): kmemleak: Fix false positives with special scan kmemleak: Add special scan test case omap iommu: kmemleak: Fix false positive with special scan arch/arm/plat-omap/iommu.c | 19 +++ include/linux/kmemleak.h |5 ++ mm/Makefile|2 +- mm/kmemleak-special-test.c | 94 mm/kmemleak.c | 114 ++- 5 files changed, 230 insertions(+), 4 deletions(-) create mode 100644 mm/kmemleak-special-test.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] kmemleak: Add special scan test case
From: Hiroshi DOYU hiroshi.d...@nokia.com
For this test case, a pointer is converted to a physical address with
attribution bits. This test can be executed either with special scan
or without special scan. For special scan case, specifying the testing
period second with the kernel module parameter timeout. Afther that
timeout, special scan is unregistered automatically. Without this
timeout, you will get false positives with kmemleak scan.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
mm/Makefile|2 +-
mm/kmemleak-special-test.c | 94
2 files changed, 95 insertions(+), 1 deletions(-)
create mode 100644 mm/kmemleak-special-test.c
diff --git a/mm/Makefile b/mm/Makefile
index 8982504..5d08581 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -44,4 +44,4 @@ obj-$(CONFIG_CGROUP_MEM_RES_CTLR) += memcontrol.o
page_cgroup.o
obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o
obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
-obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
+obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o kmemleak-special-test.o
diff --git a/mm/kmemleak-special-test.c b/mm/kmemleak-special-test.c
new file mode 100644
index 000..ed6788c
--- /dev/null
+++ b/mm/kmemleak-special-test.c
@@ -0,0 +1,94 @@
+/*
+ * kmemleak: special scan test
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@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.
+ */
+
+#include linux/module.h
+#include linux/kmemleak.h
+
+static int timeout;
+module_param(timeout, int, 0644);
+MODULE_PARM_DESC(timeout, special scan mode timeout);
+
+#define MAXELEM 8
+static u32 elem[MAXELEM];
+
+static void no_special_func(struct work_struct *unused)
+{
+ kmemleak_no_special(elem);
+ pr_info(%s: Unregistered special scan %p\n, __func__, elem);
+}
+static DECLARE_DELAYED_WORK(no_special_work, no_special_func);
+
+static unsigned long custom_conversion(void *unused, unsigned long orig)
+{
+ u32 addr = orig;
+
+ addr = ~1;
+ addr = (u32)phys_to_virt(addr);
+
+ pr_info(%s: Converted %08lx - %08x\n, __func__, orig, addr);
+
+ return addr;
+}
+
+static int __init kmemleak_special_init(void)
+{
+ int i, err;
+
+ for (i = 0; i ARRAY_SIZE(elem); i++) {
+ void *virt;
+
+ virt = kmalloc(SZ_1K, GFP_KERNEL);
+ if (!virt)
+ continue;
+
+ memset(virt, 0xa5, SZ_1K); /* fill out some markers */
+ *(char *)virt = i;
+
+ elem[i] = virt_to_phys(virt) | 1;
+ pr_info(Stored %...@%p - %08x\n, SZ_1K, virt, elem[i]);
+ }
+
+ if (!timeout)
+ return 0;
+
+ err = kmemleak_special_scan(elem, sizeof(elem),
+ custom_conversion, NULL, THIS_MODULE);
+ if (err) {
+ pr_warning(%s: Couldn't register special scan\n,
+ __func__);
+ return -ENOMEM;
+ }
+ pr_info(%s: Registered special scan: %p\n, __func__, elem);
+
+ schedule_delayed_work(no_special_work,
+ msecs_to_jiffies(timeout * 1000));
+ return 0;
+}
+module_init(kmemleak_special_init);
+
+static void __exit kmemleak_special_exit(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(elem); i++) {
+ u32 val;
+
+ val = elem[i];
+ val = ~1;
+ kfree(phys_to_virt(val));
+ }
+}
+module_exit(kmemleak_special_exit);
+
+MODULE_DESCRIPTION(kmemleak: special scan test);
+MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com);
+MODULE_LICENSE(GPL v2);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] omap iommu: kmemleak: Fix false positive with special scan
From: Hiroshi DOYU hiroshi.d...@nokia.com
The fist level iommu page table address is registered with the address
conversion function for kmemleak special scan.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iommu.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index a202a2c..5a19e86 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -894,6 +894,19 @@ void iommu_put(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(iommu_put);
+static unsigned long kmemleak_special_conv(void *data, unsigned long orig)
+{
+ u32 *iopgd;
+ struct iommu *obj = (struct iommu *)data;
+
+ iopgd = iopgd_offset(obj, orig);
+
+ if (!iopgd_is_table(*iopgd))
+ return 0;
+
+ return (u32)iopgd_page_vaddr(iopgd);
+}
+
/*
* OMAP Device MMU(IOMMU) detection
*/
@@ -967,6 +980,11 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
BUG_ON(!IS_ALIGNED((unsigned long)obj-iopgd, IOPGD_TABLE_SIZE));
+ err = kmemleak_special_scan(p, IOPGD_TABLE_SIZE, kmemleak_special_conv,
+ obj, THIS_MODULE);
+ if (err)
+ dev_warn(pdev-dev, kmemleak: failed to add special scan\n);
+
dev_info(pdev-dev, %s registered\n, obj-name);
return 0;
@@ -991,6 +1009,7 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
platform_set_drvdata(pdev, NULL);
iopgtable_clear_entry_all(obj);
+ kmemleak_no_special(obj-iopgd);
free_pages((unsigned long)obj-iopgd, get_order(IOPGD_TABLE_SIZE));
irq = platform_get_irq(pdev, 0);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] kmemleak: Fix false positives with special scan
From: Hiroshi DOYU hiroshi.d...@nokia.com
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 introducing a new special memory block with a specified
calculation formula. A client module can register its area with a
function, which kmemleak could scan and calculate a pointer with a
registered special function.
To avoid client being unloaded before unregistering special
conversion, module reference is introduced. This was pointed by Phil
Carmody.
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 attribution bits.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Acked-by: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |5 ++
mm/kmemleak.c| 114 -
2 files changed, 116 insertions(+), 3 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..1ff1cbc 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -35,6 +35,11 @@ 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 int kmemleak_special_scan(const void *ptr, size_t size,
+unsigned long (*fn)(void *, unsigned long), void *data,
+struct module *owner) __ref;
+extern void kmemleak_no_special(const void *ptr) __ref;
+
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
gfp_t gfp)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..872d5f3 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -249,6 +249,88 @@ static struct early_log
early_log[CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE] __initdata;
static int crt_early_log __initdata;
+/* scan area which requires special conversion */
+struct special_block {
+ void *start;
+ void *end;
+ unsigned long (*fn)(void *, unsigned long);
+ void *data;
+ struct module *owner;
+};
+#define SPECIAL_MAX (PAGE_SIZE / sizeof(struct special_block))
+static struct special_block special_block[SPECIAL_MAX];
+static DEFINE_SPINLOCK(special_block_lock);
+
+int kmemleak_special_scan(const void *ptr, size_t size,
+ unsigned long (*fn)(void *, unsigned long), void *data,
+ struct module *owner)
+{
+ struct special_block *sp;
+ int i, err = 0;
+
+ if (!ptr || (size == 0) || !fn)
+ return -EINVAL;
+
+ spin_lock(special_block_lock);
+
+ if (!try_module_get(owner)) {
+ err = -ENODEV;
+ goto err_module_get;
+ }
+
+ sp = special_block;
+ for (i = 0; i SPECIAL_MAX; i++, sp++) {
+ if (!sp-start)
+ break;
+ }
+
+ if (i == SPECIAL_MAX) {
+ err = -ENOMEM;
+ goto err_no_entry;
+ }
+ sp-start = (void *)ptr;
+ sp-end = (void *)ptr + size;
+ sp-fn = fn;
+ sp-data = data;
+ sp-owner = owner;
+
+ spin_unlock(special_block_lock);
+
+ return 0;
+
+err_no_entry:
+ module_put(owner);
+err_module_get:
+ spin_unlock(special_block_lock);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(kmemleak_special_scan);
+
+void kmemleak_no_special(const void *ptr)
+{
+ int i;
+
+ spin_lock(special_block_lock);
+
+ for (i = 0; i SPECIAL_MAX; i++) {
+ struct special_block *sp;
+
+ sp = special_block[i];
+ if (sp-start == ptr) {
+ module_put(sp-owner);
+ memset(sp, 0, sizeof(*sp));
+ break;
+ }
+ }
+
+ if (i == SPECIAL_MAX)
+ pr_warning(Couldn't find entry\n);
+
+ spin_unlock(special_block_lock);
+}
+EXPORT_SYMBOL_GPL(kmemleak_no_special);
+
static void kmemleak_disable(void);
/*
@@ -983,8 +1065,9 @@ static int scan_should_stop(void)
* Scan a memory block (exclusive range) for valid pointers and add those
* found to the gray list.
*/
-static void scan_block(void *_start, void *_end,
- struct kmemleak_object *scanned, int allow_resched)
+static void __scan_block(void *_start, void *_end,
+struct kmemleak_object *scanned, int allow_resched,
+struct special_block *sp)
{
unsigned long *ptr;
unsigned long *start = PTR_ALIGN(_start, BYTES_PER_POINTER);
@@ -1005,7 +1088,10 @@ static void
Re: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tuesday 01 June 2010 12:29:21 ext Jarkko Nikula wrote: On Tue, 1 Jun 2010 11:19:30 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: If threshold is configured to 100 (99 in register), than McBSP will asserts the DMA request line, when 100 locations are free. Than DMA has to send 100 words per DMA request. So we need to limit the period size (which is used to configure the DMA's elem count - number of words per DMA request) that it shall never be bigger than the threshold. Now I get it with some get hands dirty testing :-) So this is a feature of SDMA that in threshold mode the transfer size must equal or smaller than threshold (as says the TRM). No exactly. This is the feature of McBSP, that the SDMA must transfer exactly the same number of words as the McBSP threshold on DMA request. Still don't understand why the transfer size is dependent on peripheral FIFO threshold size but that's the fact and we must obey it as Eduardo's original patch and your's are doing. Because, if you want to transfer in one SDMA burst more than the space free in the McBSP FIFO, than where would the rest go? If there is interest, I might look at this. I guess this could be useful on McBSP1,3,4, and 5, which has small FIFO... Yes, have a packet based DMA transfer saving power and then we have bunch of interrupts coming :-) I guess it could be better than having 128 word long periods on McBSP1, 3, 4, and 5. With small period size the applications also need to be woken up, but if we silently handling the DMA IRQs, and the application is only woken up by every 10. DMA IRQ, it might still save some power? -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Neil Brown wrote: I think you have acknowledged that there is a race with suspend - thanks. Next step was can it be closed. You seem to suggest that it can, but you describe it as a work around rather than a bug fix... Do you agree that the race is a bug, and therefore it is appropriate to fix it assuming an acceptable fix can be found (which I think it can)? If we can fix it, yes we definitely should do and not work around it. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe 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 v3] AM35x: Add musb support
Hi,
[..]
+* We have to override VBUS/ID signals when MUSB is configured into
the
+* host-only mode -- ID pin will float if no cable is connected, so
the
+* controller won't be able to drive VBUS thinking that it's a B-
device.
+* Otherwise, we want to use the OTG mode and enable VBUS
comparators.
+*/
+ devconf2 = ~CONF2_OTGMODE;
+#ifdef CONFIG_USB_MUSB_HOST
+ devconf2 |= CONF2_FORCE_HOST;
Well, this is only necessary if the board doesn't have pulldown on
the USB ID signal. On DA830 EVM, rev. of the board A had it, and it got
removed on the later revisions (presumably it conflicted with OTG
function?), so this override became necessary. So, make sure this is
indeed necessary on your board as using the overrides isn't generally
desirable (they all also override VBUS sensing in addition to ID pin).
Yes, it's not needed for AM3517EVM
-Ajay
+#else
+ devconf2 |= CONF2_SESENDEN | CONF2_VBDTCTEN;
+#endif
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ usb_musb_init(musb_board_data);
+}
+
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst
= {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, 31 May 2010, Arve Hjønnevåg wrote: On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 31 May 2010, James Bottomley wrote: For MSM hardware, it looks possible to unify the S and C states by doing suspend to ram from idle but I'm not sure how much work that is. On ARM, it's not rocket science and we have in tree support for this already (OMAP). I have done the same thing on a Samsung part as a prove of concept two years ago and it's really easy as the hardware is sane. Hint: It's designed for mobile devices :) We already enter the same power state from idle and suspend on msm. In the absence of misbehaving apps, the difference in power consumption is entirely caused by periodic timers in the user-space framework _and_ kernel. It only takes a few timers triggering per second (I think 3 if they do no work) to double the average power consumption on the G1 if the radio is off. We originally added wakelocks because the hardware we had at the time had much lower power consumption in suspend then idle, but we still use suspend because it saves power. So how do you differentiate between timers which _should_ fire and those you do not care about ? We have mechanisms in place to defer timers so the wakeups are minimized. If that's not enough we need to revisit. Thanks, tglx
Re: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tue, 1 Jun 2010 13:30:10 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: Because, if you want to transfer in one SDMA burst more than the space free in the McBSP FIFO, than where would the rest go? I would have expected peripheral to deassert the DMA request but I haven't read the TRM so detail and experimenting with bigger period sizes didn't work so some /dev/null effect was obviously happening :-) I guess it could be better than having 128 word long periods on McBSP1, 3, 4, and 5. With small period size the applications also need to be woken up, but if we silently handling the DMA IRQs, and the application is only woken up by every 10. DMA IRQ, it might still save some power? This is worth to experiment. Probably more interrupts with or without application wakeup reduction does not increase power as much as the savings are from core clocks being more idle. -- 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
[PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
Hello, Changes since RFC v2: - Comments added explaining the changes, and documenting the API in patch2 - In patch5: - Variable names changed in the hw_rule function - hw_rule function got renamed - The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3 Intro mail from the previous series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the _full_ size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP2: McBSP: Change the way how the FIFO is handled OMAP2: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h |2 + arch/arm/plat-omap/mcbsp.c | 51 ++- sound/soc/omap/omap-mcbsp.c | 113 --- 4 files changed, 129 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] OMAP: McBSP: Function to query the FIFO size
Users of McBSP can use the omap_mcbsp_get_fifo_size function to query
the size of the McBSP FIFO.
The function will return the FIFO size in words (the HW maximum).
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
arch/arm/plat-omap/mcbsp.c | 14 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1bd7021..e126951 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -473,6 +473,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
+u16 omap_mcbsp_get_fifo_size(unsigned int id);
u16 omap_mcbsp_get_tx_delay(unsigned int id);
u16 omap_mcbsp_get_rx_delay(unsigned int id);
int omap_mcbsp_get_dma_op_mode(unsigned int id);
@@ -483,6 +484,7 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int
id, u16 threshold)
{ }
static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
+static inline u16 omap_mcbsp_get_fifo_size(unsigned int id) { return 0; }
static inline u16 omap_mcbsp_get_tx_delay(unsigned int id) { return 0; }
static inline u16 omap_mcbsp_get_rx_delay(unsigned int id) { return 0; }
static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 4820cab..51d8abf 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -559,6 +559,20 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+u16 omap_mcbsp_get_fifo_size(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ return mcbsp-pdata-buffer_size;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_fifo_size);
+
#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */
#define MCBSP1345_FIFO_SIZE0x80 /* 128 locations */
/*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/5] OMAP2: McBSP: Change the way how the FIFO is handled
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
From users of McBSP, now it is expected to use this method.
Asking for threshold 1 means that the value written to threshold registers
are going to be 0, which means 1 word threshold.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c | 10 +-
arch/arm/plat-omap/mcbsp.c | 30 --
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 016fe60..ed9f562 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,7 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -142,7 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x3FF,
+ .buffer_size= 0x500, /* The FIFO has 1024 + 256 locations */
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
@@ -152,7 +152,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -161,7 +161,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -170,7 +170,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 51d8abf..d883bbf 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -480,9 +480,9 @@ int omap_st_is_enabled(unsigned int id)
EXPORT_SYMBOL(omap_st_is_enabled);
/*
- * omap_mcbsp_set_tx_threshold configures how to deal
- * with transmit threshold. the threshold value and handler can be
- * configure in here.
+ * omap_mcbsp_set_rx_threshold configures the transmit threshold in words.
+ * The threshold parameter is 1 based, and it is converted (threshold - 1)
+ * for the THRSH2 register.
*/
void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{
@@ -497,14 +497,15 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH2, threshold);
+ if (threshold threshold = mcbsp-max_tx_thres)
+ MCBSP_WRITE(mcbsp, THRSH2, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
/*
- * omap_mcbsp_set_rx_threshold configures how to deal
- * with receive threshold. the threshold value and handler can be
- * configure in here.
+ * omap_mcbsp_set_rx_threshold configures the receive threshold in words.
+ * The threshold parameter is 1 based, and it is converted (threshold - 1)
+ * for the THRSH1 register.
*/
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
{
@@ -519,7 +520,8 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH1, threshold);
+ if (threshold threshold = mcbsp-max_rx_thres)
+ MCBSP_WRITE(mcbsp, THRSH1, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
@@ -1696,8 +1698,16 @@ static inline void __devinit omap34xx_device_init(struct
omap_mcbsp *mcbsp)
{
mcbsp-dma_op_mode =
[PATCH v3 3/5] OMAP2: McBSP: Use the port's buffer_size when calculating tx delay
Sicne the platform data's buffer_size now holds the full size of the FIFO, there is no longer need to handle the ports differently. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- arch/arm/plat-omap/mcbsp.c |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index d883bbf..ac09c79 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -575,8 +575,6 @@ u16 omap_mcbsp_get_fifo_size(unsigned int id) } EXPORT_SYMBOL(omap_mcbsp_get_fifo_size); -#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */ -#define MCBSP1345_FIFO_SIZE0x80 /* 128 locations */ /* * omap_mcbsp_get_tx_delay returns the number of used slots in the McBSP FIFO */ @@ -595,10 +593,7 @@ u16 omap_mcbsp_get_tx_delay(unsigned int id) buffstat = MCBSP_READ(mcbsp, XBUFFSTAT); /* Number of slots are different in McBSP ports */ - if (mcbsp-id == 2) - return MCBSP2_FIFO_SIZE - buffstat; - else - return MCBSP1345_FIFO_SIZE - buffstat; + return mcbsp-pdata-buffer_size - buffstat; } EXPORT_SYMBOL(omap_mcbsp_get_tx_delay); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] ASoC: omap-mcbsp: Save, and use wlen for threshold configuration
Save the word length configuration of McBSP, and use that information
to calculate, and configure the threshold in McBSP.
Previously the calculation was only correct when the stream had 16bit
audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6f44cb4..b06d8f1 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -59,6 +59,7 @@ struct omap_mcbsp_data {
int configured;
unsigned intin_freq;
int clk_div;
+ int wlen;
};
#define to_mcbsp(priv) container_of((priv), struct omap_mcbsp_data, bus_id)
@@ -155,19 +156,21 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
- int samples;
+ int words;
/* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- samples = snd_pcm_lib_period_bytes(substream) 1;
+ /* The FIFO size depends on the McBSP word configuration */
+ words = snd_pcm_lib_period_bytes(substream) /
+ (mcbsp_data-wlen / 8);
else
- samples = 1;
+ words = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
- omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, samples - 1);
+ omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, words);
else
- omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, samples - 1);
+ omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
@@ -409,6 +412,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
}
omap_mcbsp_config(bus_id, mcbsp_data-regs);
+ mcbsp_data-wlen = wlen;
mcbsp_data-configured = 1;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128 * 4 = 512 bytes
It is simpler to place constraint for buffer and period based on channels.
McBSP3 as example again (16 or 32 bit samples):
1 channel (mono): size is 128 frames (128 words)
2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
Use the second method to place hw_rule on buffer size, and in threshold
mode to period size.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 99 ++-
1 files changed, 78 insertions(+), 21 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b06d8f1..8a55c9a 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,51 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *buffer_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct omap_mcbsp_data *mcbsp_data = rule-private;
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ size = omap_mcbsp_get_fifo_size(mcbsp_data-bus_id);
+
+ frames.min = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(buffer_size, frames);
+
+}
+
+static int omap_mcbsp_hwrule_max_periodsize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *period_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct snd_pcm_substream *substream = rule-private;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ size = omap_mcbsp_get_max_tx_threshold(mcbsp_data-bus_id);
+ else
+ size = omap_mcbsp_get_max_rx_threshold(mcbsp_data-bus_id);
+
+ frames.max = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(period_size, frames);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
@@ -185,33 +230,45 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
if (!cpu_dai-active)
err = omap_mcbsp_request(bus_id);
+ /*
+* OMAP3 McBSP FIFO is word structured.
+* McBSP2 has 1024 + 256 = 1280 word long buffer,
+* McBSP1,3,4,5 has 128 word long buffer
+* This means that the size of the FIFO depends on the sample format.
+* For example on McBSP3:
+* 16bit samples: size is 128 * 2 = 256 bytes
+* 32bit samples: size is 128 * 4 = 512 bytes
+* It is simpler to place constraint for buffer and period based on
+* channels.
+* McBSP3 as example again (16 or 32 bit samples):
+* 1 channel (mono): size is 128 frames (128 words)
+* 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
+* 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
+*/
if (cpu_is_omap343x()) {
int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
- int max_period;
/*
-* McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer.
-* Set constraint for minimum buffer size to the same than FIFO
-* size in order to avoid underruns in playback startup because
-* HW is keeping the DMA request active until FIFO is filled.
-*/
- if (bus_id == 1)
- snd_pcm_hw_constraint_minmax(substream-runtime,
- SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
- 4096, UINT_MAX);
-
- if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
-
Re: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Tuesday 01 June 2010 14:20:47 ext Jarkko Nikula wrote: On Tue, 1 Jun 2010 13:30:10 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: Because, if you want to transfer in one SDMA burst more than the space free in the McBSP FIFO, than where would the rest go? I would have expected peripheral to deassert the DMA request but I haven't read the TRM so detail and experimenting with bigger period sizes didn't work so some /dev/null effect was obviously happening :-) And for exchange I have tried the following: in element mode (DMA is set to transfer 1 word on DMA request). I have configured the McBSP threshold to max - 4 words. It does not work either. Playback did not start. I think McBSP is waiting to receive max - 4 samples, while only one word arrived Or something, don't know... I guess it could be better than having 128 word long periods on McBSP1, 3, 4, and 5. With small period size the applications also need to be woken up, but if we silently handling the DMA IRQs, and the application is only woken up by every 10. DMA IRQ, it might still save some power? This is worth to experiment. Probably more interrupts with or without application wakeup reduction does not increase power as much as the savings are from core clocks being more idle. Although application can also configure the avail_min, so it will be not woken up for every period -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Tue, 1 Jun 2010 14:18:19 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: Hello, Changes since RFC v2: - Comments added explaining the changes, and documenting the API in patch2 - In patch5: - Variable names changed in the hw_rule function - hw_rule function got renamed - The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3 To whole series: Acked-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: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq
-Original Message- From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: Monday, May 31, 2010 10:59 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq On 05/31/2010 03:39 PM, Sanjeev Premi wrote: The OPP layer was contained in the CONFIG_CPU_FREQ. This patch removes this containment relation. Signed-off-by: Sanjeev Premipr...@ti.com --- arch/arm/mach-omap2/Makefile |6 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- [snip]--[snip] you sure this is the only board file having omap3-opp.h ? anyway.. the need for board files to use opp_init is gone with my patch http://marc.info/?l=linux-omapm=127507237109393w=2 so I wont harp on it, I would rather post a cleanup patch for all board files once the patch is in..(or mebbe kevin could drop the patch that adds opp_init_table to board files ;) ).. [sp] You didn't reead the 0/1 of the patch series, where I have clearly mentioned that I will make changes to the other board specific files once there rest of the changes are well discussed. There may be, possibly, more changes in the board specific files and we can review them in the context of this file and then same can be repeated for other board files. arch/arm/mach-omap2/cpufreq34xx.c | 164 arch/arm/mach-omap2/omap3-opp.h | 20 arch/arm/mach-omap2/opp34xx_data.c| 166 + arch/arm/mach-omap2/pm34xx.c |1 - arch/arm/plat-omap/Makefile |7 +- arch/arm/plat-omap/cpu-omap.c | 47 + arch/arm/plat-omap/include/plat/opp.h | 82 +--- arch/arm/plat-omap/opp.c | 46 - 10 files changed, 225 insertions(+), 316 deletions(-) delete mode 100644 arch/arm/mach-omap2/cpufreq34xx.c delete mode 100644 arch/arm/mach-omap2/omap3-opp.h create mode 100644 arch/arm/mach-omap2/opp34xx_data.c [sp] finding it difficult to align with this change, you introduce omap3_pm_init_opp_table later into plat/opp.h which defeats generic nature of opp.h - as it was supposed to be used for other omaps as well.. In that case the function omap3_pm_init_opp_table() can be made generic by renaming to omap_pm_init_opp_table and can be implemented for each omap family. If opp table has to be implementyed for each family then why have different funtion with family specific prefixes? Also, what this headerf ile is/was doing? only defining the function to return -EINVAL when CONFIG_CPU_FREQ is not selected; which is not required. For OPP layer to be used this table needs to be populated. Now, there is only one place this function is used, so why do/should be need a header for the same. [snip]--[snip] +obj-y+= opp.o +obj-$(CONFIG_TWL4030_POWER) += opp_twl_tps.o NAK. you just need TWL4030_CORE not power here. any reason to retain power? it has no dependency on power.. [sp] Isn't this purpose of this opp to TWL linkage is to define the voltages in terms the PMIC connected; and later make sure that correct voltages are set via the PMIC? This is very much related to POWER. We could also do it on CORE; but I don't see this as a big issue. But TWL4030 has more feature beyond PMIC but this is not the case with other simpler PMICs and I wanted to use CONFIG option that can be easier for someone else make the port easy to spot as a necessary change. [snip]--[snip] + freq_table[i].index = i; + freq_table[i].frequency = CPUFREQ_TABLE_END; + + *table =freq_table[0]; +} +#endif + e why? it used to be here and was moved to opp.c - see http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p m.git;a=commit;h=9a6b00f70e9f4bce30ad4f8fab41a24bd3706dbd you are essentially reverting that patch! [sp] May be I am reverting the patch, but I don't see this function being used anywhere else. Most of the other cpufreq related initialization is happening at this place. Only the function omap_cpu_init() calls this function and it is in the same file. It also helps in need of an additional header; which seem to make de-linking more complex - in terms of #ifdefs. [snip]--[snip] +/** + * omap3_pm_init_opp_table() - Initialize the OPP table for OMAP3 devices. + * + * Initializes the OPP table for the current OMAP3 device. + */ +int __init omap3_pm_init_opp_table(void); NAK. opp. is meant to be used by omap2, OMAP4 etc.. when you removed from omap3-opp.h, it kinda needed you to have it here, which breaks the generic nature of this header. [sp] See my comment earlier. The function for init-ing the OPP table can be made generic. Then (after rename) this is a generic function itself. Rather than making sweelping changes, I am only delinking the OPP layer and CPU freq. These
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, 31 May 2010, Arve Hjønnevåg wrote: 2010/5/31 Rafael J. Wysocki r...@sisk.pl: On Monday 31 May 2010, Arve Hjønnevåg wrote: 2010/5/30 Rafael J. Wysocki r...@sisk.pl: ... I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? Assume for a while that you don't use suspend blockers, OK? I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers. It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle. Thanks, tglx
Re: [PATCH v3 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
Hi,
On Tuesday 01 June 2010 14:18:24 Ujfalusi Peter (Nokia-D/Tampere) wrote:
...
+static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params
*params, +struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *buffer_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct omap_mcbsp_data *mcbsp_data = rule-private;
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ size = omap_mcbsp_get_fifo_size(mcbsp_data-bus_id);
+
+ frames.min = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(buffer_size, frames);
+
+}
Just noticed this extra line after the return...
Should I resend?
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Tue, Jun 01, 2010 at 02:18:19PM +0300, Peter Ujfalusi wrote: Changes since RFC v2: - Comments added explaining the changes, and documenting the API in patch2 - In patch5: - Variable names changed in the hw_rule function - hw_rule function got renamed - The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3 All of these look sensible enough from an ASoC point of view, though I can't say too much about the OMAP specifics. Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128 * 4 = 512 bytes
It is simpler to place constraint for buffer and period based on channels.
McBSP3 as example again (16 or 32 bit samples):
1 channel (mono): size is 128 frames (128 words)
2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
Use the second method to place hw_rule on buffer size, and in threshold
mode to period size.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
Hello,
The only change since v3 is the removal of blank line from the end of
omap_mcbsp_hwrule_min_buffersize function.
This patch should replace the one in the v3 series.
Peter
sound/soc/omap/omap-mcbsp.c | 98 +-
1 files changed, 77 insertions(+), 21 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b06d8f1..aebd3af 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,50 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *buffer_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct omap_mcbsp_data *mcbsp_data = rule-private;
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ size = omap_mcbsp_get_fifo_size(mcbsp_data-bus_id);
+
+ frames.min = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(buffer_size, frames);
+}
+
+static int omap_mcbsp_hwrule_max_periodsize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *period_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct snd_pcm_substream *substream = rule-private;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ size = omap_mcbsp_get_max_tx_threshold(mcbsp_data-bus_id);
+ else
+ size = omap_mcbsp_get_max_rx_threshold(mcbsp_data-bus_id);
+
+ frames.max = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(period_size, frames);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
@@ -185,33 +229,45 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
if (!cpu_dai-active)
err = omap_mcbsp_request(bus_id);
+ /*
+* OMAP3 McBSP FIFO is word structured.
+* McBSP2 has 1024 + 256 = 1280 word long buffer,
+* McBSP1,3,4,5 has 128 word long buffer
+* This means that the size of the FIFO depends on the sample format.
+* For example on McBSP3:
+* 16bit samples: size is 128 * 2 = 256 bytes
+* 32bit samples: size is 128 * 4 = 512 bytes
+* It is simpler to place constraint for buffer and period based on
+* channels.
+* McBSP3 as example again (16 or 32 bit samples):
+* 1 channel (mono): size is 128 frames (128 words)
+* 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
+* 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
+*/
if (cpu_is_omap343x()) {
int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
- int max_period;
/*
-* McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer.
-* Set constraint for minimum buffer size to the same than FIFO
-* size in order to avoid underruns in playback startup because
-* HW is keeping the DMA request active until FIFO is filled.
-*/
- if (bus_id == 1)
- snd_pcm_hw_constraint_minmax(substream-runtime,
-
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. -- Matthew Garrett | mj...@srcf.ucam.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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Neil Brown wrote: With wakeup events the problem isn't so bad. Wakeup events are always noticed, and if the system is designed properly they will either abort a suspend-in-progress or else cause the system to resume as soon as the suspend is complete. (Linux is not yet properly designed in this sense.) This is exactly the issue. Linux doesn't get this right. A wakeup that is processed by the driver just before suspend may not get all the way out to it's final destination (possibly in meat-space) until after some other event wakes the device. It is not possible to guarantee full delivery of a wakeup event with Linux in its current state. This is a bug. That wasn't what I meant. An important requirement is that a wakeup event received after the device has been suspended, but before the system suspend is complete, should cause the system suspend to abort. This is one of the things suspend blockers were meant to help with. In theory it should already work correctly -- but it doesn't. That's a real bug. The other things you're talking about aren't really bugs. That is, they are things which the kernel _ought_ to do but it wasn't _intended_ to do. They are misfeatures: failures of design, not failures of execution. I don't think I'm missing that. Wakeup events are the only events of interest. But wakeup events are more than just low-level hardware events. They are also the virtual events that are a direct consequence of the original hardware event. This is a matter of semantics and it is highly debatable. A UART asserts 'data ready' which is routed to an IO interrupt line that wakes the device. This is a wakeup event. Yes. So are the bits that appear on the data line which represent the data So are the characters that appear on the serial port So is the here is a message from the GSM processor event So is the there is a new TXT message event So is the 'beep beep beep' out the speaker event None of those things can cause the system to wake up after it is suspended. Indeed, they can't happen at all if the CPU isn't running (unless the GSM processor runs autonomously -- let's ignore such details). Hence it makes little sense to call them wakeup events. All these events are wakeup events, and should abort or instant-resume the system. Currently only the first can be guaranteed to do this (... and maybe the second, depending on the details of the implementation). suspend-blocks effectively pass a lock from one event to the next to ensure that all of these event block the suspend. There are various other ways to achieve the same thing, and I think it can be done with no significant change to the API. But some how we need to allow all of these events to be linked wake-up events, not just the first one. That's not entirely clear. Yes, for Android's use case that's what you want. But in other situations maybe you don't. Consider the example of someone who closes the lid of their laptop and throws it in a backpack. The computer should suspend immediately; it shouldn't be delayed by these virtual wakeup events. Alan Stern -- To unsubscribe from this list: send the line unsubscribe 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 v3 2/4] OMAP4: Keyboard device registration
Hi Tony,
Please test this with omap3_defconfig too, and make sure it does not break
things for omap2 and omap3.
Tested, no problems...
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap4_keypad_platform_data *pdata;
+
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
if (!cpu_is_omap44xx())
return -ENODEV;
I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what you are
suggesting is to check at runtime?
Best Regards
Abraham
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] [OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
On Fri, May 28, 2010 at 10:28 PM, Cory Maccarrone darkstar6...@gmail.com wrote: This adds MMC support to the HTC Herald, including importing the htc-mmc.c and htc-mmc.h code for building. This change also adds I2C support to the HTC Herald board, as well as adding the HTCPLD driver for the PLD used on this phone. It also adds in the gpio-keys entries for the front directional keys and selector and the cursor keys on the slide-out keyboard, and gpio-leds support for the LEDs attached to the htcpld. The Kconfig was also modified to add 64 GPIOs and IRQs to the default maximum number of each for the HTC herald. This is needed because the HTCPLD chip on this board exposes an additional 32 gpios and 16 irqs that would not fit in the default limits. The defconfig has been updated to reflect the changes. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- arch/arm/configs/htcherald_defconfig | 376 + arch/arm/mach-omap1/Kconfig | 2 + arch/arm/mach-omap1/Makefile | 2 +- arch/arm/mach-omap1/board-htcherald.c | 267 +++- 4 files changed, 600 insertions(+), 47 deletions(-) diff --git a/arch/arm/configs/htcherald_defconfig b/arch/arm/configs/htcherald_defconfig index e0ef0d1..42deef6 100644 --- a/arch/arm/configs/htcherald_defconfig +++ b/arch/arm/configs/htcherald_defconfig @@ -1,13 +1,15 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc8 -# Sat Dec 5 12:16:24 2009 +# Linux kernel version: 2.6.34 +# Fri May 28 21:34:49 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y +# CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,6 +21,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config @@ -33,6 +36,13 @@ CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y @@ -46,13 +56,13 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -67,6 +77,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y +CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -87,10 +98,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y @@ -126,14 +141,41 @@ CONFIG_LBDAF=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is
Re: [PATCH 1/4] [OMAP1] Add MMC board code common to HTC devices
On Tue, Jun 1, 2010 at 3:19 AM, Ladislav Michl ladislav.mi...@seznam.cz wrote:
On Fri, May 28, 2010 at 10:28:04PM -0700, Cory Maccarrone wrote:
This change adds the htc-mmc.c and htc-mmc.h files that
contain common setup code for many OMAP850-based HTC
smartphones. This code is a port of the code used by
the linwizard project to support devices such as the
HTC Wizard, HTC Herald, HTC Opal, etc.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/htc-mmc.c | 104
+
arch/arm/mach-omap1/htc-mmc.h | 26 ++
2 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/htc-mmc.c
create mode 100644 arch/arm/mach-omap1/htc-mmc.h
diff --git a/arch/arm/mach-omap1/htc-mmc.c b/arch/arm/mach-omap1/htc-mmc.c
new file mode 100644
index 000..4fa8bb4
--- /dev/null
+++ b/arch/arm/mach-omap1/htc-mmc.c
@@ -0,0 +1,104 @@
+/*
+ * linux/arch/arm/mach-omap1/htc-mmc.c
+ *
+ * Copyright (C) 2007 Instituto Nokia de Tecnologia - INdT
+ * Author: Felipe Balbi felipe.l...@indt.org.br
+ *
+ * This code is based on linux/arch/arm/mach-omap2/board-n800-mmc.c, which
is:
+ * Copyright (C) 2006 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include plat/mmc.h
+#include asm/mach-types.h
+
+#include linux/gpio.h
+#include linux/delay.h
+
+#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
+
+#define OMAP_MMC_REG_SYSC (0xfffb7800 + 0x32)
+#define OMAP_MMC_REG_SYSS (0xfffb7800 + 0x34)
Where are these used?
+static int slot_cover_open;
+static struct device *mmc_device;
+
+static int htc_mmc_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+#ifdef CONFIG_MMC_DEBUG
+ dev_dbg(dev, Set slot %d power: %s (vdd %d)\n, slot + 1,
+ power_on ? on : off, vdd);
+#endif
+ if (slot != 0) {
+ dev_err(dev, No such slot %d\n, slot + 1);
+ return -ENODEV;
+ }
+
+ return 0;
+}
No-op?
+static int htc_mmc_set_bus_mode(struct device *dev, int slot, int bus_mode)
+{
+#ifdef CONFIG_MMC_DEBUG
+ dev_dbg(dev, Set slot %d bus_mode %s\n, slot + 1,
+ bus_mode == MMC_BUSMODE_OPENDRAIN ? open-drain :
push-pull);
+#endif
+ if (slot != 0) {
+ dev_err(dev, No such slot %d\n, slot + 1);
+ return -ENODEV;
+ }
+
+ /* Treated on upper level */
+
+ return bus_mode;
+}
+
+static int htc_mmc_get_cover_state(struct device *dev, int slot)
+{
+ BUG_ON(slot != 0);
+ return slot_cover_open;
+}
Just a complicated way to return zero...
+static int htc_mmc_late_init(struct device *dev)
+{
+ mmc_device = dev;
+ return 0;
+}
What is this good for?
+static void htc_mmc_cleanup(struct device *dev)
+{
+}
+
+static struct omap_mmc_platform_data htc_mmc1_data = {
+ .nr_slots = 1,
+ .switch_slot = NULL,
+ .init = htc_mmc_late_init,
+ .cleanup = htc_mmc_cleanup,
+ .slots[0] = {
+ .set_power = htc_mmc_set_power,
+ .set_bus_mode = htc_mmc_set_bus_mode,
+ .get_ro = NULL,
+ .get_cover_state = htc_mmc_get_cover_state,
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ MMC_VDD_32_33 | MMC_VDD_33_34,
+ .name = mmcblk,
+ .nomux = 1,
+ .wires = 4,
+ .switch_pin = -1,
+ },
+};
To me above seems completely no-op, so it could be simplified this way:
static struct omap_mmc_platform_data htc_mmc1_data = {
.nr_slots = 1,
.switch_slot = NULL,
.slots[0] = {
.ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = mmcblk,
.nomux = 1,
.wires = 4,
.switch_pin = -1,
},
};
Now, once this file contains only one structure definition, is it worth
to let it exist at all? What about adding it to board-htcherald.c instead?
+
+static struct omap_mmc_platform_data *htc_mmc_data[1];
+
+void __init htc_mmc_init(void)
+{
+ /* register it */
+ htc_mmc_data[0] = htc_mmc1_data;
+ omap1_init_mmc(htc_mmc_data, 1);
+}
+#endif
+
diff --git a/arch/arm/mach-omap1/htc-mmc.h b/arch/arm/mach-omap1/htc-mmc.h
new file mode 100644
index
[PATCHv2 4/4] [OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
This change adds in MMC and I2C support to the HTC Herald board, as well as adding the HTCPLD driver for the PLD used on this phone. It also adds in the gpio-keys entries for the front directional keys and selector and the cursor keys on the slide-out keyboard, and gpio-leds support for the LEDs attached to the htcpld. The Kconfig was also modified to add 64 GPIOs and IRQs to the default maximum number of each for the HTC herald. This is needed because the HTCPLD chip on this board exposes an additional 32 gpios and 16 irqs that would not fit in the default limits. The defconfig has been updated to reflect the changes. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- arch/arm/configs/htcherald_defconfig | 376 + arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/board-htcherald.c | 288 - 4 files changed, 621 insertions(+), 47 deletions(-) diff --git a/arch/arm/configs/htcherald_defconfig b/arch/arm/configs/htcherald_defconfig index e0ef0d1..42deef6 100644 --- a/arch/arm/configs/htcherald_defconfig +++ b/arch/arm/configs/htcherald_defconfig @@ -1,13 +1,15 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc8 -# Sat Dec 5 12:16:24 2009 +# Linux kernel version: 2.6.34 +# Fri May 28 21:34:49 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y +# CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,6 +21,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config @@ -33,6 +36,13 @@ CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y @@ -46,13 +56,13 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -67,6 +77,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y +CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -87,10 +98,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y @@ -126,14 +141,41 @@ CONFIG_LBDAF=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is not set +# CONFIG_INLINE_WRITE_UNLOCK_BH is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set +# CONFIG_MUTEX_SPIN_ON_OWNER is not set CONFIG_FREEZER=y # @@ -144,8 +186,11 @@ CONFIG_MMU=y # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set #
Re: [PATCHv2 4/4] [OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
On Tue, Jun 1, 2010 at 8:41 AM, Cory Maccarrone darkstar6...@gmail.com wrote: This change adds in MMC and I2C support to the HTC Herald board, as well as adding the HTCPLD driver for the PLD used on this phone. It also adds in the gpio-keys entries for the front directional keys and selector and the cursor keys on the slide-out keyboard, and gpio-leds support for the LEDs attached to the htcpld. The Kconfig was also modified to add 64 GPIOs and IRQs to the default maximum number of each for the HTC herald. This is needed because the HTCPLD chip on this board exposes an additional 32 gpios and 16 irqs that would not fit in the default limits. The defconfig has been updated to reflect the changes. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- arch/arm/configs/htcherald_defconfig | 376 + arch/arm/mach-omap1/Kconfig | 2 + arch/arm/mach-omap1/Makefile | 2 +- arch/arm/mach-omap1/board-htcherald.c | 288 - 4 files changed, 621 insertions(+), 47 deletions(-) diff --git a/arch/arm/configs/htcherald_defconfig b/arch/arm/configs/htcherald_defconfig index e0ef0d1..42deef6 100644 --- a/arch/arm/configs/htcherald_defconfig +++ b/arch/arm/configs/htcherald_defconfig @@ -1,13 +1,15 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc8 -# Sat Dec 5 12:16:24 2009 +# Linux kernel version: 2.6.34 +# Fri May 28 21:34:49 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y +# CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,6 +21,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config @@ -33,6 +36,13 @@ CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y @@ -46,13 +56,13 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -67,6 +77,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y +CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -87,10 +98,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y @@ -126,14 +141,41 @@ CONFIG_LBDAF=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is not set +# CONFIG_INLINE_WRITE_UNLOCK_BH is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set +#
[PATCHv3 4/4] [OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
This change adds in MMC and I2C support to the HTC Herald board, as well as adding the HTCPLD driver for the PLD used on this phone. It also adds in the gpio-keys entries for the front directional keys and selector and the cursor keys on the slide-out keyboard, and gpio-leds support for the LEDs attached to the htcpld. The Kconfig was also modified to add 64 GPIOs and IRQs to the default maximum number of each for the HTC herald. This is needed because the HTCPLD chip on this board exposes an additional 32 gpios and 16 irqs that would not fit in the default limits. The defconfig has been updated to reflect the changes. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- arch/arm/configs/htcherald_defconfig | 376 + arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-htcherald.c | 288 - 3 files changed, 620 insertions(+), 46 deletions(-) diff --git a/arch/arm/configs/htcherald_defconfig b/arch/arm/configs/htcherald_defconfig index e0ef0d1..42deef6 100644 --- a/arch/arm/configs/htcherald_defconfig +++ b/arch/arm/configs/htcherald_defconfig @@ -1,13 +1,15 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc8 -# Sat Dec 5 12:16:24 2009 +# Linux kernel version: 2.6.34 +# Fri May 28 21:34:49 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y +# CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,6 +21,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config @@ -33,6 +36,13 @@ CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y @@ -46,13 +56,13 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -67,6 +77,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y +CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -87,10 +98,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y @@ -126,14 +141,41 @@ CONFIG_LBDAF=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is not set +# CONFIG_INLINE_WRITE_UNLOCK_BH is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set +# CONFIG_MUTEX_SPIN_ON_OWNER is not set CONFIG_FREEZER=y # @@ -144,8 +186,11 @@ CONFIG_MMU=y # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set +#
Re: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
#endif /* CONFIG_PM_RUNTIME */
+#ifdef CONFIG_SUSPEND
+int platform_pm_suspend_noirq(struct device *dev)
+{
+struct device_driver *drv = dev-driver;
+struct platform_device *pdev = to_platform_device(dev);
+struct omap_device *odev = to_omap_device(pdev);
+int ret = 0;
+
+if (!drv)
+return 0;
+
+if (drv-pm) {
+if (drv-pm-suspend_noirq)
+ret = drv-pm-suspend_noirq(dev);
+}
+
+if (omap_device_is_valid(odev)) {
+if (odev-flags OMAP_DEVICE_NO_BUS_SUSPEND) {
+dev_dbg(dev, no automatic bus-level
system resume.\n);
+return 0;
+}
+
+dev_dbg(dev, %s\n, __func__);
+omap_device_idle(pdev);
Is it expected that a device is always in enabled state at this point?
If the device is already in idle a call to omap_device_idle unconditionally
throws up warnings from the omap_device api.
Hmm, good point. The device may already be idled (via runtime PM, or
maybe because it was never enabled.)
There are two options:
1. fixup the warnings in the omap_device_idle() to allow multiple
calls to _idle()
2. Add an omap_device_is_idle() check before calling _idle()
I much prefer (1).
Paul?
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: [RFC] [PATCH v3 1/4] OMAP4: Keyboard controller support
Arce, Abraham x0066...@ti.com writes:
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
arch/arm/plat-omap/include/plat/omap4-keypad.h | 23 ++
drivers/input/keyboard/Kconfig | 10 +
drivers/input/keyboard/Makefile|1 +
drivers/input/keyboard/omap4-keypad.c | 288
4 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap4-keypad.h
create mode 100644 drivers/input/keyboard/omap4-keypad.c
diff --git a/arch/arm/plat-omap/include/plat/omap4-keypad.h
b/arch/arm/plat-omap/include/plat/omap4-keypad.h
new file mode 100644
index 000..7a6ce70
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap4-keypad.h
@@ -0,0 +1,23 @@
+#ifndef ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+#define ARCH_ARM_PLAT_OMAP4_KEYPAD_H
+
+#include linux/input/matrix_keypad.h
+
+struct omap4_keypad_platform_data {
+ const struct matrix_keymap_data *keymap_data;
+
+ u8 rows;
+ u8 cols;
+
+ u16 irq;
+ void __iomem *base;
+
+ int (*device_enable) (struct platform_device *pdev);
+ int (*device_shutdown) (struct platform_device *pdev);
+ int (*device_idle) (struct platform_device *pdev);
+};
Abraham,
Please drop these from this driver. First, they are not used in the driver,
and 2nd, new drivers should use the runtime PM API for this as needed.
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: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
Felipe Balbi felipe.ba...@nokia.com writes: On Tue, Jun 01, 2010 at 06:47:34AM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: +pdata-device_enable = omap_device_enable; this is undefined at least here or previous patch. or does it come from omap_device layers ?? It's part of the omap_device layer. But, drivers no longer should be calling these hooks using platform_data. Instead, drivers should use the runtime PM API. The runtime PM core for OMAP will use the omap_device API. 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: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote: I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what you are suggesting is to check at runtime? you need to add both checks. If you build omap3-only or omap2-only you don't want that code to be compiled, but if you build omap1-2-3-4 kernel, you want it to work correctly on all cases. -- 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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver
I re-added your reviewers to the cc... On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. There are at least two other ambient light sensor drivers: drivers/misc/isl29003.c and drivers/misc/tsl2550.c. Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. -- To unsubscribe from this list: send the line unsubscribe 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 v3 2/4] OMAP4: Keyboard device registration
On Tue, Jun 01, 2010 at 09:53:58PM +0300, Felipe Balbi wrote: On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote: I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what you are suggesting is to check at runtime? you need to add both checks. If you build omap3-only or omap2-only you don't want that code to be compiled, but if you build omap1-2-3-4 kernel, you want it to work correctly on all cases. It sould be nice if cpu_is_xxx were stubbed out for wrong arches withing the same group (like omap, etc) so we could reduce the #ifdef clutter. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver
On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote: On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. There are at least two other ambient light sensor drivers: drivers/misc/isl29003.c and drivers/misc/tsl2550.c. Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? Jonathan proposed the ALS framework for these type of devices, but it was rejected (don't know about the reasons, I didn't follow the discussions). The new idea is to put such drivers in the industrial IO subsystem, but I don't know how mature that approach is currently. For the time being, these drivers cook up whatever sysfs interface they like, and their userspace ABIs are not standardized, unfortunately. It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. FWIW, I put some documentation about the isl29003 to Documentation/misc-devices when I wrote the driver. Daniel -- To unsubscribe from this list: send the line unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver
On 06/01/10 21:12, Andrew Morton wrote: I re-added your reviewers to the cc... On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. There are at least two other ambient light sensor drivers: drivers/misc/isl29003.c and drivers/misc/tsl2550.c. for ref there is also drivers/staging/iio/light/tsl2563.c and intent to pick up the other two soon (probably when, hopefully IIO leaves staging, we could do it now if people prefer. Having two drivers in the short term is also an option). As for abi cleanup. We had all authors and contributors to all the above agreeing to standardization changes for ALS (and probably all the users ;) so we are probably in a position to change things now before there are too many users! Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? Sadly that was one of the things ALS was meant to clean up. I've proposed one under IIO that is effectively the equivalent of hwmon (we have a lot of overlap in supported device types with hwmon, so as Greg KH suggested have matched their interface where it exists). illuminance0_input (measured in lux) The other exports of light sensors are remarkably inconsistent across different devices. At the moment all the in kernel drivers only support polled reading via sysfs. There are tsl2563 interrupt patches on linux-iio list (not that it is particularly relevant here). I've also proposed some other naming for the weird bits of tsl2563 in that patch series. (http://marc.info/?l=linux-iiom=127473503113241w=2) It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. Agreed, but we get back to the debate of what we should standardise on. The main point of ALS before it died was exactly putting this standardization in place (admittedly the interface was slightly different from what we are proposing in IIO, but that was before Greg pointed out that sharing with hwmon would be a good idea!) I have to admit I'm a little loath to spend too much time on this given the amount of time wasted previously (ALS). Jonathan -- To unsubscribe from this list: send the line unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver
On Tue, 1 Jun 2010 22:27:15 +0200 Daniel Mack dan...@caiaq.de wrote: On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote: On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. There are at least two other ambient light sensor drivers: drivers/misc/isl29003.c and drivers/misc/tsl2550.c. Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? Jonathan proposed the ALS framework for these type of devices, but it was rejected (don't know about the reasons, I didn't follow the discussions). The new idea is to put such drivers in the industrial IO subsystem, but I don't know how mature that approach is currently. For the time being, these drivers cook up whatever sysfs interface they like, and their userspace ABIs are not standardized, unfortunately. Well can we fix that? Look at the existing drivers, pick one and make this new driver provide the same interface? It's not a grand plan - more of an incremental baby step, but it's better than this random proliferation. -- To unsubscribe from this list: send the line unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver
On 06/01/10 21:27, Daniel Mack wrote: On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote: On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. There are at least two other ambient light sensor drivers: drivers/misc/isl29003.c and drivers/misc/tsl2550.c. Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? Jonathan proposed the ALS framework for these type of devices, but it was rejected (don't know about the reasons, I didn't follow the discussions). Ah the wonder of emails crossing ;) For the interested... http://lkml.org/lkml/2010/3/1/367 (the main objections are Linus' email) The new idea is to put such drivers in the industrial IO subsystem, but I don't know how mature that approach is currently. We haven't lifted any that didn't start there as moving things into staging due to a dependency being there seemed a controversial thing to do. For the time being, these drivers cook up whatever sysfs interface they like, and their userspace ABIs are not standardized, unfortunately. It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. FWIW, I put some documentation about the isl29003 to Documentation/misc-devices when I wrote the driver. Daniel -- To unsubscribe from this list: send the line unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver
On Tue, 01 Jun 2010 21:39:10 +0100 Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote: It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. Agreed, but we get back to the debate of what we should standardise on. I'd suggest standardising on one of the existing drivers. That way we have two compliant drivers and only need to change (n-2) others. If we pick some new standard then we need to change (n) drivers. And we can't change the drivers, really. They'd all end up needing to provide two interfaces: one for the shiny-new-standard and one legacy. The main point of ALS before it died was exactly putting this standardization in place (admittedly the interface was slightly different from what we are proposing in IIO, but that was before Greg pointed out that sharing with hwmon would be a good idea!) I have to admit I'm a little loath to spend too much time on this given the amount of time wasted previously (ALS). Well, it's not a waste. This is very important! We appear to be making a big mess which we can never fix up. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. Did I miss anything? James -- To unsubscribe from this list: send the line unsubscribe 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 0/3] Enable CPU frequency and power tracking in cpuacct cgroup
On Fri, May 21, 2010 at 10:05 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Mike Chan m...@android.com writes: On Thu, May 20, 2010 at 2:01 PM, Thomas Renninger tr...@suse.de wrote: Hi Mike, On Thursday 20 May 2010 08:42:21 pm Mike Chan wrote: v2: Rebased off of Thomas Renninger's patch for cgroups_cpuacct refactoring, thanks. A general comment: I don't know much about the cgroup stuff. Perhaps Paul Menage or Balbir Singh can look and sign off on the API's? I am also not sure how exactly power can be measured on this arch based on If you know how much time was spent at each frequency executing code, you can calculate how much power was consumed if the platform (with hooks) provide power numbers (in milliWatts) for the power at frequency X. I did some initial testing on Motorola Droid comparing to a power meter and I got within 2% variance. frequency accounting (there also were some threads I was not aware of?) A signed-off-by or reviewed-by from someone who is more involved in this omap stuff would probably not that bad. OMAP was the closest with mainline support I could provide an example how to use these hooks. I'm hoping for some blessing from some people on the linux-omap list for that. However can we possibly just stack the first two patches to get the API in? This will make it easier to fixup the omap hooks if they don't get in. This looks like a great enhancement to me. Speaking for OMAP PM... I'd suggest getting the generic stuff upstream (or into -next) soon and then work out the OMAP specifics after. Since the OMAP OPP layer is going through some churn (but stabilizing and will be submitted for 2.6.36), I'd suggest we queue the OMAP-specific parts of this along with the OPP layer changes. So it looks like there is no objections to this API and I'm OK with dropping the omap hooks for now until things are settled in 2.6.36. So are things good with Thomas' re-factoring patch for cpuacct as well as the first 2 patches? -- Mike 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] misc : ROHM BH1780GLI Ambient light sensor Driver
On 06/01/10 21:54, Andrew Morton wrote: On Tue, 01 Jun 2010 21:39:10 +0100 Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote: It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. Agreed, but we get back to the debate of what we should standardise on. I'd suggest standardising on one of the existing drivers. That way we have two compliant drivers and only need to change (n-2) others. If we pick some new standard then we need to change (n) drivers. I agree but take into account that we are getting a number of superficially similar interfaces in kernel (hwmon, various sensors in misc and IIO) and it makes sense to my mind to share interfaces across these where possible (this is exactly the argument Greg made when we carried the equivalent standardization out in IIO - for ref, the spec is in staging/drivers/iio/Documentation/sysfs-class-iio) (gah, the name needs a change to reflect our move to a sysfs bus - oops) And we can't change the drivers, really. They'd all end up needing to provide two interfaces: one for the shiny-new-standard and one legacy. True enough. We argued we could do with out this before because we were fairly sure that we knew everyone who was using the sensors (also 1 was in staging and another extremely) The main point of ALS before it died was exactly putting this standardization in place (admittedly the interface was slightly different from what we are proposing in IIO, but that was before Greg pointed out that sharing with hwmon would be a good idea!) I have to admit I'm a little loath to spend too much time on this given the amount of time wasted previously (ALS). Well, it's not a waste. This is very important! We appear to be making a big mess which we can never fix up. I agree entirely, picking a driver to copy is the way to go. (personally I'd argue for the tsl2563 for the reasons above) I'm just moaning about the time wasted the previous time we tried to clean this stuff up :) Note that 'if' these drivers do end up in IIO we will have to add the abi as per the tsl2563 (can keep the others around for a while). We have a consistent abi over 6+ sensor types so far and we aren't going to want to break it for this one. There are still unresolved corners in our abi but they are all event related so this device is nowhere near them. Either way, I agree entirely that matching any existing driver is a good thing even if it isn't the one I'd personally prefer! Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
--- On Tue, 6/1/10, James Bottomley james.bottom...@suse.de wrote: As long as you can set a wakeup timer, an S state is just a C state with side effects. I've seen similar statements on this endless thread before; they're not quite true... The significant one is that entering an S state stops the process scheduler and any in-kernel timers. There's a structural difference too, related to peripheral device activity and power states. Specifically, peripherals can be active in C states (erforming I/O, maybe with DMA etc) and will in general not be in lowest power states (PCI etc). Whereas entry to ACPI S-states involves calling the AML code to put those peripherals into lowest power modes ... ones they can't in general enter at run time. (An additional task of that bytecode is to activate any wakeup logic, which again is not generally functional in except in S-states). The point being perhaps more that ACPI doesn't map well to the more power-efficient architectures (often built on ARM) ... hardware vendors provide all kinds of PM hooks, and Linux can choose between them so it's more power-miserly than if it tried to emulate an ACPI based platform. I've seen some Linux systems which put DRAM into self-refresh during certain idle modes, for example, not just during suspend-to-RAM, if it's known that no DMA is active. (Why not save that power if it's safe?) Likewise, disable some oscillators and PLLs if they're not needed (the clock API allows that to be done regardless of C-states etc). The notion of suspend gets introduced on such systems primarily to match the ACPI-ish models that exist ... rather than because they necessarily make good matches for the hardware. Which has left a puzzle: how and why to use such suspend models? Maybe that's underlying some of the pushback for the notion of automagic entry to suspend states. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tuesday 01 June 2010, Arve Hjønnevåg wrote: On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Monday 31 May 2010, Neil Brown wrote: On Thu, 27 May 2010 23:40:29 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Thu, 27 May 2010, Rafael J. Wysocki wrote: On Thursday 27 May 2010, Thomas Gleixner wrote: On Thu, 27 May 2010, Alan Stern wrote: On Thu, 27 May 2010, Felipe Balbi wrote: On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no mem should be replaced by an idle suspend to ram mechanism Well, what about when I want the machine to suspend _regardless_ of whether or not it's idle at the moment? That actually happens quite often to me. :-) Fair enough. Let's agree on a non ambigous terminology then: forced: suspend which you enforce via user interaction, which also implies that you risk losing wakeups depending on the hardware properties Reasonable definition I think. However the current implementation doesn't exactly match it. With the current implementation you risk losing wakeups *independent* of the hardware properties. Define losing, please. Currently, we simply don't regard hardware signals occuring _during_ the suspend operation itself as wakeups (unless they are wakeup interrupts to be precise, because these _are_ taken into account by our current code). The reason is that the meaning of given event may be _different_ at run time and after the system has been suspended. For example, consider a power button on a PC box. If it's pressed at run time, it usually means power off the system to the kernel. After the system has been suspended, however, it means wake up. So, you have to switch from one interpretation of the event to the other and that's not an atomic operaition (to put it lightly). Even with ideal hardware events can be lost - by which I mean that they will not be seen until some other event effects a wake-up. e.g. the interrupt which signals the event happens immediately before the suspend is requested (or maybe at the same time as), but the process which needs to handle the event doesn't get a chance to see it before the suspend procedure freezes that process, and even if it did it would have no way to abort the suspend. So I submit that the current implementation doesn't match your description of forced, is therefore buggy, and that if it were fixed, that would be sufficient to meet the immediate needs of android. I don't really think it may be fixed with respect to every possible kind of hardware. On platforms where I/O interrupts are wakeup events it should work right now. On other platforms it may be impossible to overcome hardware limitations. There is no reason you cannot make the rtc alarms work reliably on x86 hardware. They usually work, but not in 100% of cases. Generally, x86 hardware is a broad category, where modern ones have much more interesting capabilities than the older. Even if you may loose key events while suspending I think it is still valuable to have reliable alarms. I don't think anyone will argue with that. :-) Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tuesday 01 June 2010, Alan Stern wrote: On Tue, 1 Jun 2010, Neil Brown wrote: As I said before, we generally can't prevent such things from happening, because even if we handle the particular race described above, it still is possible that the event will be lost if it arrives just a bit later (eg. during a suspend-toggle switch). So the PRE_SUSPEND thing won't really solve the entire problem while increasing complexity. My freerunner has a single core so without CONFIG_PREEMPT it may be that there is no actual race-window - maybe the PRE_SUSPENDs will all run before a soft_irq thread has a chance to finish handling of the interrupt (my knowledge of these details is limits). But on a muilti-core device I think there would definitely be a race-window. Yes, there always will be a race window. The only thing we can do is to narrow it, but we cannot really close it (at least not on a PC, but I'm not really sure it can be closed at all). Well you are the expert so I assume you are right, but I would really like to understand why this is. I guess that if the event was delivered as an edge-triggered interrupt which the interrupt controller couldn't latch, then it might get lost. Is that what happens? You're barking up the wrong tree. If I understand correctly, Rafael is saying that there's a race involving events which are not _wakeup_ events. If a non-wakeup event arrives shortly before a suspend, it can have its normal effect. If it arrives while a suspend is in progress, its delivery may be delayed until the system resumes. And if it arrives after the system is fully suspended, it may never be noticed at all. With wakeup events the problem isn't so bad. Wakeup events are always noticed, and if the system is designed properly they will either abort a suspend-in-progress or else cause the system to resume as soon as the suspend is complete. (Linux is not yet properly designed in this sense.) Or maybe I'm misunderstanding also, and Rafael is saying that there's a race involving events whose meaning changes depending on whether or not the system is asleep. This is obviously true and clearly unavoidable. In fact I was referring to both in different places. That's why what I said wasn't too clear, sorry about that. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tuesday 01 June 2010, Alan Stern wrote: On Tue, 1 Jun 2010, Neil Brown wrote: With wakeup events the problem isn't so bad. Wakeup events are always noticed, and if the system is designed properly they will either abort a suspend-in-progress or else cause the system to resume as soon as the suspend is complete. (Linux is not yet properly designed in this sense.) This is exactly the issue. Linux doesn't get this right. A wakeup that is processed by the driver just before suspend may not get all the way out to it's final destination (possibly in meat-space) until after some other event wakes the device. It is not possible to guarantee full delivery of a wakeup event with Linux in its current state. This is a bug. That wasn't what I meant. An important requirement is that a wakeup event received after the device has been suspended, but before the system suspend is complete, should cause the system suspend to abort. This is one of the things suspend blockers were meant to help with. In theory it should already work correctly -- but it doesn't. That's a real bug. The other things you're talking about aren't really bugs. That is, they are things which the kernel _ought_ to do but it wasn't _intended_ to do. They are misfeatures: failures of design, not failures of execution. I don't think I'm missing that. Wakeup events are the only events of interest. But wakeup events are more than just low-level hardware events. They are also the virtual events that are a direct consequence of the original hardware event. This is a matter of semantics and it is highly debatable. A UART asserts 'data ready' which is routed to an IO interrupt line that wakes the device. This is a wakeup event. Yes. So are the bits that appear on the data line which represent the data So are the characters that appear on the serial port So is the here is a message from the GSM processor event So is the there is a new TXT message event So is the 'beep beep beep' out the speaker event None of those things can cause the system to wake up after it is suspended. Indeed, they can't happen at all if the CPU isn't running (unless the GSM processor runs autonomously -- let's ignore such details). Hence it makes little sense to call them wakeup events. All these events are wakeup events, and should abort or instant-resume the system. Currently only the first can be guaranteed to do this (... and maybe the second, depending on the details of the implementation). suspend-blocks effectively pass a lock from one event to the next to ensure that all of these event block the suspend. There are various other ways to achieve the same thing, and I think it can be done with no significant change to the API. But some how we need to allow all of these events to be linked wake-up events, not just the first one. That's not entirely clear. Yes, for Android's use case that's what you want. But in other situations maybe you don't. Consider the example of someone who closes the lid of their laptop and throws it in a backpack. The computer should suspend immediately; it shouldn't be delayed by these virtual wakeup events. BTW, this is an important point. We've already had some bug reports regarding such unwanted wakeup events. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. Is the original idea of having that information in debugfs objectionable? Rafael -- To unsubscribe from this list: send the line unsubscribe 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] [omap1] omap7xx clocks, mux, serial fixes
This change adds in the necessary clocks and mux pins for UART
control on omap7xx devices. I also made a change in the serial
code to only try and initialize two UARTs in omap_serial_init, as
these devices don't have three.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/clock_data.c | 20
arch/arm/mach-omap1/mux.c |4
arch/arm/mach-omap1/serial.c |7 +++
arch/arm/plat-omap/include/plat/mux.h |4
4 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index aa8558a..9240bc1 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -478,6 +478,24 @@ static struct clk usb_dc_ck7xx = {
.enable_bit = 8,
};
+static struct clk uart1_7xx = {
+ .name = uart1_ck,
+ .ops= clkops_generic,
+ /* Direct from ULPD, no parent */
+ .rate = 1200,
+ .enable_reg = OMAP1_IO_ADDRESS(SOFT_REQ_REG),
+ .enable_bit = 9,
+};
+
+static struct clk uart2_7xx = {
+ .name = uart2_ck,
+ .ops= clkops_generic,
+ /* Direct from ULPD, no parent */
+ .rate = 1200,
+ .enable_reg = OMAP1_IO_ADDRESS(SOFT_REQ_REG),
+ .enable_bit = 11,
+};
+
static struct clk mclk_1510 = {
.name = mclk,
.ops= clkops_generic,
@@ -620,7 +638,9 @@ static struct omap_clk omap_clks[] = {
/* ULPD clocks */
CLK(NULL, uart1_ck, uart1_1510,CK_1510 | CK_310),
CLK(NULL, uart1_ck, uart1_16xx.clk, CK_16XX),
+ CLK(NULL, uart1_ck, uart1_7xx, CK_7XX),
CLK(NULL, uart2_ck, uart2_ck, CK_16XX | CK_1510 |
CK_310),
+ CLK(NULL, uart2_ck, uart2_7xx, CK_7XX),
CLK(NULL, uart3_ck, uart3_1510,CK_1510 | CK_310),
CLK(NULL, uart3_ck, uart3_16xx.clk, CK_16XX),
CLK(NULL, usb_clko, usb_clko, CK_16XX | CK_1510 |
CK_310),
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 8434137..6a9b42f 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -70,6 +70,10 @@ MUX_CFG_7XX(SPI_7XX_3, 6, 13,4, 12, 1,
0)
MUX_CFG_7XX(SPI_7XX_4, 6, 17,4, 16, 1, 0)
MUX_CFG_7XX(SPI_7XX_5, 8, 25,0, 24, 0, 0)
MUX_CFG_7XX(SPI_7XX_6, 9,5,0,4, 0, 0)
+
+/* UART pins */
+MUX_CFG_7XX(UART_7XX_1, 3, 21,0, 20, 0, 0)
+MUX_CFG_7XX(UART_7XX_2, 8,1,6,0, 0, 0)
};
#define OMAP7XX_PINS_SZARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 349de90..b78d074 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -122,6 +122,13 @@ void __init omap_serial_init(void)
for (i = 0; i ARRAY_SIZE(serial_platform_data) - 1; i++) {
+ /* Don't look at UARTs higher than 2 for omap7xx */
+ if (cpu_is_omap7xx() i 1) {
+ serial_platform_data[i].membase = NULL;
+ serial_platform_data[i].mapbase = 0;
+ continue;
+ }
+
/* Static mapping, never released */
serial_platform_data[i].membase =
ioremap(serial_platform_data[i].mapbase, SZ_2K);
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index c7472a2..82c374c 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -191,6 +191,10 @@ enum omap7xx_index {
SPI_7XX_4,
SPI_7XX_5,
SPI_7XX_6,
+
+ /* UART */
+ UART_7XX_1,
+ UART_7XX_2,
};
enum omap1xxx_index {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [omap1] Bluetooth device code common to HTC smartphones
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.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/htc-bt.c | 183 +
arch/arm/mach-omap1/include/mach/htc-bt.h | 22
2 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/htc-bt.c
create mode 100644 arch/arm/mach-omap1/include/mach/htc-bt.h
diff --git a/arch/arm/mach-omap1/htc-bt.c b/arch/arm/mach-omap1/htc-bt.c
new file mode 100644
index 000..2e748ba
--- /dev/null
+++ b/arch/arm/mach-omap1/htc-bt.c
@@ -0,0 +1,183 @@
+/*
+ * Bluetooth built-in chip control
+ *
+ * Copyright (c) 2010 Cory Maccarrone
+ * Based on tosa-bt.c copyright (c) 2008 Dmitry Baryshkov
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/rfkill.h
+#include linux/clk.h
+
+#include plat/mux.h
+
+#include mach/htc-bt.h
+
+static struct clk *uart_ck;
+
+static void htc_bt_on(struct htc_bt_data *data)
+{
+ gpio_set_value(data-gpio_pwr, 1);
+
+ if (uart_ck)
+ clk_enable(uart_ck);
+
+ mdelay(1000);
+
+ if (data-gpio_enable)
+ gpio_set_value(data-gpio_enable, 1);
+}
+
+static void htc_bt_off(struct htc_bt_data *data)
+{
+ gpio_set_value(data-gpio_pwr, 0);
+
+ if (uart_ck)
+ clk_disable(uart_ck);
+
+ mdelay(1000);
+
+ if (data-gpio_enable)
+ gpio_set_value(data-gpio_enable, 0);
+}
+
+static int htc_bt_set_block(void *data, bool blocked)
+{
+ if (!blocked)
+ htc_bt_on(data);
+ else
+ htc_bt_off(data);
+
+ return 0;
+}
+
+static const struct rfkill_ops htc_bt_rfkill_ops = {
+ .set_block = htc_bt_set_block,
+};
+
+static int htc_bt_probe(struct platform_device *dev)
+{
+ int rc;
+ struct rfkill *rfk;
+
+ struct htc_bt_data *data = dev-dev.platform_data;
+
+ /* Configure the GPIOs */
+ if (data-gpio_enable) {
+ rc = gpio_request(data-gpio_enable, Bluetooth enable);
+ if (rc)
+ goto err_enable;
+ rc = gpio_direction_output(data-gpio_enable, 0);
+ if (rc)
+ goto err_enable_dir;
+ }
+
+ rc = gpio_request(data-gpio_pwr, Bluetooth power);
+ if (rc)
+ goto err_pwr;
+ rc = gpio_direction_output(data-gpio_pwr, 0);
+ if (rc)
+ goto err_pwr_dir;
+
+ /* Get the clocks */
+ if (data-uart_clock != NULL) {
+ uart_ck = clk_get(NULL, data-uart_clock);
+ if (IS_ERR(uart_ck)) {
+ pr_warn(htc-bt: Could not get uart clock\n);
+ uart_ck = NULL;
+ } else
+ clk_disable(uart_ck);
+ } else
+ uart_ck = NULL;
+
+ /* MUX pins for UART */
+ omap_cfg_reg(UART_7XX_1);
+ omap_cfg_reg(UART_7XX_2);
+
+ /* Configure RFKill */
+ rfk = rfkill_alloc(htc-bt, dev-dev, RFKILL_TYPE_BLUETOOTH,
+ htc_bt_rfkill_ops, data);
+ if (!rfk) {
+ rc = -ENOMEM;
+ goto err_rfk_alloc;
+ }
+
+ rfkill_set_led_trigger_name(rfk, htc-bt);
+
+ rc = rfkill_register(rfk);
+ if (rc)
+ goto err_rfkill;
+
+ platform_set_drvdata(dev, rfk);
+
+ return 0;
+
+err_rfkill:
+ rfkill_destroy(rfk);
+err_rfk_alloc:
+ htc_bt_off(data);
+err_pwr_dir:
+ gpio_free(data-gpio_pwr);
+err_pwr:
+err_enable_dir:
+ if (data-gpio_enable)
+ gpio_free(data-gpio_enable);
+err_enable:
+ return rc;
+}
+
+static int __devexit htc_bt_remove(struct platform_device *dev)
+{
+ struct htc_bt_data *data = dev-dev.platform_data;
+ struct rfkill *rfk = platform_get_drvdata(dev);
+
+ platform_set_drvdata(dev, NULL);
+
+ if (rfk) {
+ rfkill_unregister(rfk);
+ rfkill_destroy(rfk);
+ }
+ rfk = NULL;
+
+ htc_bt_off(data);
+
+ gpio_free(data-gpio_pwr);
+ if (data-gpio_enable)
+ gpio_free(data-gpio_enable);
+
+ return 0;
+}
+
+static struct platform_driver htc_bt_driver = {
+ .probe = htc_bt_probe,
+ .remove = __devexit_p(htc_bt_remove),
+
+ .driver = {
+ .name = htc-bt,
+ .owner = THIS_MODULE,
+ },
+};
+
+
+static int __init htc_bt_init(void)
+{
+ return platform_driver_register(htc_bt_driver);
+}
+
+static void __exit htc_bt_exit(void)
+{
+
[PATCH] [htcherald] Add board support for UARTs, bluetooth
This change adds bluetooth and UART initialization support to the HTC Herald board driver. This allows use of the serial bluetooth adapter attached to UART1 using hciattach. The defconfig was updated to add in bluetooth core support, as well as to clean up some unneeded cruft. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- arch/arm/configs/htcherald_defconfig | 159 +++-- arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/board-htcherald.c | 23 + 3 files changed, 75 insertions(+), 109 deletions(-) diff --git a/arch/arm/configs/htcherald_defconfig b/arch/arm/configs/htcherald_defconfig index 26c8def..9272fa4 100644 --- a/arch/arm/configs/htcherald_defconfig +++ b/arch/arm/configs/htcherald_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.34 -# Sun May 30 15:54:07 2010 +# Tue Jun 1 14:47:13 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -255,11 +255,11 @@ CONFIG_ARCH_OMAP1=y CONFIG_OMAP_MUX=y # CONFIG_OMAP_MUX_DEBUG is not set CONFIG_OMAP_MUX_WARNINGS=y -CONFIG_OMAP_MCBSP=y +# CONFIG_OMAP_MCBSP is not set # CONFIG_OMAP_MBOX_FWK is not set CONFIG_OMAP_MPU_TIMER=y # CONFIG_OMAP_32K_TIMER is not set -CONFIG_OMAP_SERIAL_WAKE=y +# CONFIG_OMAP_SERIAL_WAKE is not set # CONFIG_OMAP_PM_NONE is not set CONFIG_OMAP_PM_NOOP=y @@ -338,7 +338,7 @@ CONFIG_PAGE_OFFSET=0xC000 CONFIG_PREEMPT=y CONFIG_HZ=100 CONFIG_AEABI=y -CONFIG_OABI_COMPAT=y +# CONFIG_OABI_COMPAT is not set CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set @@ -356,7 +356,7 @@ CONFIG_ZONE_DMA_FLAG=0 CONFIG_VIRT_TO_BUS=y # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 -CONFIG_LEDS=y +# CONFIG_LEDS is not set CONFIG_ALIGNMENT_TRAP=y # CONFIG_UACCESS_WITH_MEMCPY is not set @@ -383,9 +383,6 @@ CONFIG_CMDLINE=mem=32M console=ttyS0,115200 ip=dhcp # # At least one emulation must be selected # -CONFIG_FPE_NWFPE=y -# CONFIG_FPE_NWFPE_XP is not set -# CONFIG_FPE_FASTFPE is not set # CONFIG_VFP is not set # @@ -482,21 +479,33 @@ CONFIG_DEFAULT_TCP_CONG=cubic # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set -# CONFIG_BT is not set +CONFIG_BT=y +CONFIG_BT_L2CAP=y +# CONFIG_BT_L2CAP_EXT_FEATURES is not set +CONFIG_BT_SCO=y +CONFIG_BT_RFCOMM=y +CONFIG_BT_RFCOMM_TTY=y +CONFIG_BT_BNEP=y +CONFIG_BT_BNEP_MC_FILTER=y +CONFIG_BT_BNEP_PROTO_FILTER=y +CONFIG_BT_HIDP=y + +# +# Bluetooth device drivers +# +# CONFIG_BT_HCIBTSDIO is not set +CONFIG_BT_HCIUART=y +# CONFIG_BT_HCIUART_H4 is not set +# CONFIG_BT_HCIUART_BCSP is not set +CONFIG_BT_HCIUART_LL=y +# CONFIG_BT_HCIVHCI is not set +# CONFIG_BT_MRVL is not set # CONFIG_AF_RXRPC is not set -CONFIG_WIRELESS=y -# CONFIG_CFG80211 is not set -# CONFIG_LIB80211 is not set - -# -# CFG80211 needs to be enabled for MAC80211 -# - -# -# Some wireless drivers require a rate control algorithm -# +# CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set -# CONFIG_RFKILL is not set +CONFIG_RFKILL=y +CONFIG_RFKILL_LEDS=y +CONFIG_RFKILL_INPUT=y # CONFIG_NET_9P is not set # CONFIG_CAIF is not set @@ -527,32 +536,11 @@ CONFIG_BLK_DEV_LOOP=y # DRBD disabled because PROC_FS, INET or CONNECTOR not selected # # CONFIG_BLK_DEV_NBD is not set -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=16 -CONFIG_BLK_DEV_RAM_SIZE=8192 -# CONFIG_BLK_DEV_XIP is not set +# CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MG_DISK is not set -CONFIG_MISC_DEVICES=y -# CONFIG_AD525X_DPOT is not set -# CONFIG_ICS932S401 is not set -# CONFIG_ENCLOSURE_SERVICES is not set -# CONFIG_ISL29003 is not set -# CONFIG_SENSORS_TSL2550 is not set -# CONFIG_DS1682 is not set -# CONFIG_TI_DAC7512 is not set -# CONFIG_C2PORT is not set - -# -# EEPROM support -# -# CONFIG_EEPROM_AT24 is not set -# CONFIG_EEPROM_AT25 is not set -# CONFIG_EEPROM_LEGACY is not set -# CONFIG_EEPROM_MAX6875 is not set -# CONFIG_EEPROM_93CX6 is not set -# CONFIG_IWMC3200TOP is not set +# CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set @@ -573,32 +561,10 @@ CONFIG_NETDEVICES=y # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_VETH is not set -# CONFIG_PHYLIB is not set -CONFIG_NET_ETHERNET=y -CONFIG_MII=y -# CONFIG_AX88796 is not set -CONFIG_SMC91X=y -# CONFIG_DM9000 is not set -# CONFIG_ENC28J60 is not set -# CONFIG_ETHOC is not set -# CONFIG_SMC911X is not set -# CONFIG_SMSC911X is not set -# CONFIG_DNET is not set -# CONFIG_IBM_NEW_EMAC_ZMII is not set -# CONFIG_IBM_NEW_EMAC_RGMII is not set -# CONFIG_IBM_NEW_EMAC_TAH is not set -# CONFIG_IBM_NEW_EMAC_EMAC4 is not set -# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set -# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set -# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set -# CONFIG_B44 is not set -# CONFIG_KS8842 is not set -# CONFIG_KS8851 is not set -#
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? Well, android only needs two states (block and don't block), so that gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to describe these, but if all we're arguing over is the define name, that's progress. The other piece they need is the suspend block name, which comes with the stats API, and finally we need to decide what the actual constraint is called (which is how the dev node gets its name) ... 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. Is the original idea of having that information in debugfs objectionable? Well ... debugfs is usually used to get around the sysfs rules. In this case, pm_qos has a dev interface ... I don't specifically object to using debugfs, but I don't see any reason to forbid it from being a simple dev read interface either. James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 10:47:49 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 1 Jun 2010, Neil Brown wrote: With wakeup events the problem isn't so bad. Wakeup events are always noticed, and if the system is designed properly they will either abort a suspend-in-progress or else cause the system to resume as soon as the suspend is complete. (Linux is not yet properly designed in this sense.) This is exactly the issue. Linux doesn't get this right. A wakeup that is processed by the driver just before suspend may not get all the way out to it's final destination (possibly in meat-space) until after some other event wakes the device. It is not possible to guarantee full delivery of a wakeup event with Linux in its current state. This is a bug. That wasn't what I meant. An important requirement is that a wakeup event received after the device has been suspended, but before the system suspend is complete, should cause the system suspend to abort. This is one of the things suspend blockers were meant to help with. In theory it should already work correctly -- but it doesn't. That's a real bug. The other things you're talking about aren't really bugs. That is, they are things which the kernel _ought_ to do but it wasn't _intended_ to do. They are misfeatures: failures of design, not failures of execution. A fairly subtle distinction, but I can accept it. We are working with a design failure. But when a design failure results in a feature not being usable in a race-free way, I would still call that failure of design a bug - a bug in the design. I don't think I'm missing that. Wakeup events are the only events of interest. But wakeup events are more than just low-level hardware events. They are also the virtual events that are a direct consequence of the original hardware event. This is a matter of semantics and it is highly debatable. A UART asserts 'data ready' which is routed to an IO interrupt line that wakes the device. This is a wakeup event. Yes. So are the bits that appear on the data line which represent the data So are the characters that appear on the serial port So is the here is a message from the GSM processor event So is the there is a new TXT message event So is the 'beep beep beep' out the speaker event None of those things can cause the system to wake up after it is suspended. Indeed, they can't happen at all if the CPU isn't running (unless the GSM processor runs autonomously -- let's ignore such details). Hence it makes little sense to call them wakeup events. I think we are seeing this very differently. In my mind these are in one sense all the same event, just represented in different ways. One of the reasons that we have an OS is to support levels of abstraction. A disk drives stores sectors, but I want to store files A monitor displays pixels, but I want to display text A network sends packets, but I want to send Email. The OS (including but not only the kernel) handles the conversion. It is still my Email that is going out over the network even though the network card has no concept of 'email'. Similarly the event of importance above in the notification that a TXT has arrived. At the lowest level, it appears as 'data-ready' on a UART. At the highest level is it sound-waves in the air. But it is the same event. And the role of the OS is to allow me to treat it all as one event - one abstract concept. Obviously the involvement of the kernel ends when the event reaches or crosses the boundary to user-space, and user-space must be responsible for taking it to the boundary to meat-space. But the kernel needs to ensure that this holistic wake-up event can be handled without racing with a suspend request. If you just protect the lowest level representation of the event, but don't allow the higher level representations to be protected, then it is a bit like a filesystem that requires you to send SCSI commands to the disk drive if you want to be sure your data is safe. All these events are wakeup events, and should abort or instant-resume the system. Currently only the first can be guaranteed to do this (... and maybe the second, depending on the details of the implementation). suspend-blocks effectively pass a lock from one event to the next to ensure that all of these event block the suspend. There are various other ways to achieve the same thing, and I think it can be done with no significant change to the API. But some how we need to allow all of these events to be linked wake-up events, not just the first one. That's not entirely clear. Yes, for Android's use case that's what you want. But in other situations maybe you don't. Consider the example of someone who closes the lid of their laptop and throws it in a backpack. The computer should suspend immediately; it shouldn't be delayed by these virtual wakeup events.
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? Well, android only needs two states (block and don't block), so that gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to describe these, but if all we're arguing over is the define name, that's progress. I think we need separate state constraints for suspend and idle low power modes. On the msm platform only a subset of the interrupts can wake up from the low power mode, so we block the use if the low power mode from idle while other interrupts are enabled. We do not block suspend however if those interrupts are not marked as wakeup interrupts. Most constraints that prevent suspend are not hardware specific and should not prevent entering low power modes from idle. In other words we may need to prevent low power idle modes while allowing suspend, and we may need to prevent suspend while allowing low power idle modes. It would also be good to not have an implementation that gets slower and slower the more clients you have. With binary constraints this is trivial. The other piece they need is the suspend block name, which comes with the stats API, and finally we need to decide what the actual constraint is called (which is how the dev node gets its name) ... 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) 4. It would be useful to change pm_qos_add_request to not allocate anything so can add constraints from init functions that currently cannot fail. After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. Is the original idea of having that information in debugfs objectionable? Well ... debugfs is usually used to get around the sysfs rules. In this case, pm_qos has a dev interface ... I don't specifically object to using debugfs, but I don't see any reason to forbid it from being a simple dev read interface either. We don't currently have a dev interface for stats so this is not an immediate requirement. The suspend blocker debugfs interface is just as good as the proc interface we have for wakelocks. -- Arve Hjønnevåg -- To unsubscribe from
RE: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
-Original Message- From: Arve Hjønnevåg [mailto:a...@android.com] Sent: Tuesday, June 01, 2010 6:11 PM To: James Bottomley Cc: Rafael J. Wysocki; Matthew Garrett; Thomas Gleixner; Peter Zijlstra; ty...@mit.edu; LKML; Florian Mickler; Linux PM; Linux OMAP Mailing List; felipe.ba...@nokia.com; Alan Cox; Alan Stern; Gross, Mark; Neil Brown Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? Well, android only needs two states (block and don't block), so that gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to describe these, but if all we're arguing over is the define name, that's progress. I think we need separate state constraints for suspend and idle low power modes. On the msm platform only a subset of the interrupts can wake up from the low power mode, so we block the use if the low power mode from idle while other interrupts are enabled. We do not block suspend however if those interrupts are not marked as wakeup interrupts. Most constraints that prevent suspend are not hardware specific and should not prevent entering low power modes from idle. In other words we may need to prevent low power idle modes while allowing suspend, and we may need to prevent suspend while allowing low power idle modes. It would also be good to not have an implementation that gets slower and slower the more clients you have. With binary constraints this is trivial. [mtg: ] agreed. The other piece they need is the suspend block name, which comes with the stats API, and finally we need to decide what the actual constraint is called (which is how the dev node gets its name) ... 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) 4. It would be useful to change pm_qos_add_request to not allocate anything so can add constraints from init functions that currently cannot fail. [mtg: ] I'm not sure how to do this but I agree it would be good. I guess we could have a block of pm_qos requests pre-allocated statically and re-use them. In practice there will not be more than a handful of requests ever. Dynamic allocation does seem like a bit of a waste. After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. This is all nice but, all this does is implement the exact same thing as the wake lock / suspend blocker API as a pm_qos request-class. It leaves the overlapping constraint issue from ISR to user mode in place depending on exactly how the oppertunistic suspend is implemented. I expect it will be via a notifier on the pm_qos request-class update that would do exactly what the wake lock code does today. just load up an a suspend_on_non_interactivity driver that registers for the call back, have it enabled by the user mode PM, and you have the equivelent architecture as what was proposed by the wake lock patches. it gives the Android guys what they want, without adding a new subsystem, minimizing the changes and makes most of the architecture much more politicaly acceptible. But doesn't it have the same issues with getting the overlapping constraints right from wake up source to user mode and dealing with the wake up envents in a sane way? Instead of sprinkling suspend-blockers about the kernel we'll sprinkle pm_qos_requests about. I like getting more users of pm_qos, but isn't this the same thing? I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. I don't think the status would be a big deal to add. However; I am really burned out by this discussion. I am willing to stub this out ASAP if it puts this behind us if the principles in the discussion are in more or less agreement. --mgross For the record, I still like my low power event idea, which could coexist with the above. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 Gross, Mark mark.gr...@intel.com: ... 4. It would be useful to change pm_qos_add_request to not allocate anything so can add constraints from init functions that currently cannot fail. [mtg: ] I'm not sure how to do this but I agree it would be good. I guess we could have a block of pm_qos requests pre-allocated statically and re-use them. In practice there will not be more than a handful of requests ever. Dynamic allocation does seem like a bit of a waste. The calling code will have to store a pointer to your structure anyway, you may as well have them provide the whole structure. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: 2010/5/31 Rafael J. Wysocki r...@sisk.pl: On Monday 31 May 2010, Arve Hjønnevåg wrote: 2010/5/30 Rafael J. Wysocki r...@sisk.pl: ... I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? Assume for a while that you don't use suspend blockers, OK? I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers. It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle. Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 31 May 2010, James Bottomley wrote: For MSM hardware, it looks possible to unify the S and C states by doing suspend to ram from idle but I'm not sure how much work that is. On ARM, it's not rocket science and we have in tree support for this already (OMAP). I have done the same thing on a Samsung part as a prove of concept two years ago and it's really easy as the hardware is sane. Hint: It's designed for mobile devices :) We already enter the same power state from idle and suspend on msm. In the absence of misbehaving apps, the difference in power consumption is entirely caused by periodic timers in the user-space framework _and_ kernel. It only takes a few timers triggering per second (I think 3 if they do no work) to double the average power consumption on the G1 if the radio is off. We originally added wakelocks because the hardware we had at the time had much lower power consumption in suspend then idle, but we still use suspend because it saves power. So how do you differentiate between timers which _should_ fire and those you do not care about ? Only alarms are allowed to fire while suspended. We have mechanisms in place to defer timers so the wakeups are minimized. If that's not enough we need to revisit. Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] OMAP3: McBSP: Change the way how the FIFO is handled
On 06/01/2010 09:59 AM, Peter Ujfalusi wrote:
On Monday 31 May 2010 20:41:12 ext Nishanth Menon wrote:
On 05/31/2010 11:16 AM, Peter Ujfalusi wrote:
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
From users of McBSP, now it is expected to use this method.
Asking for threshold 1 means that the value written to threshold
registers are going to be 0, which means 1 word threshold.
just a 2cent minor comment: maybe omap_mcbsp_platform_data needs
structure documentation.. it might be difficult for folks to figure that
out from commit ID itself..
I can add comments in the mach-omap2/mcbsp.c like this:
I had meant more of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-doc-nano-HOWTO.txt;h=27a52b35d55bf1b6009551c97f400da5c14f59bc;hb=HEAD#l84
but i suspect that it is out of the scope of this patch at least.. and
the comments below might be helpful at the least.
Signed-off-by: Peter Ujfalusipeter.ujfal...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c | 10 +-
arch/arm/plat-omap/mcbsp.c | 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 016fe60..9139958 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,7 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -142,7 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x3FF,
+ .buffer_size= 0x500,
+ .buffer_size= 0x500, /* The FIFO has 1024 + 256 locations */
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
@@ -152,7 +152,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -161,7 +161,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -170,7 +170,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops=omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80,
},
};
#define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 51d8abf..6462968 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -497,7 +497,8 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH2, threshold);
+ if (threshold threshold= mcbsp-max_tx_thres)
+ MCBSP_WRITE(mcbsp, THRSH2, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
@@ -519,7 +520,8 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH1, threshold);
+ if (threshold threshold= mcbsp-max_rx_thres)
+ MCBSP_WRITE(mcbsp, THRSH1, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
@@ -1696,8 +1698,8 @@ static inline void __devinit
omap34xx_device_init(struct omap_mcbsp *mcbsp)
{
mcbsp-dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
if (cpu_is_omap34xx()) {
- mcbsp-max_tx_thres =
Re: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq
On 06/01/2010 03:01 PM, Premi, Sanjeev wrote: -Original Message- From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: Monday, May 31, 2010 10:59 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq On 05/31/2010 03:39 PM, Sanjeev Premi wrote: The OPP layer was contained in the CONFIG_CPU_FREQ. This patch removes this containment relation. Signed-off-by: Sanjeev Premipr...@ti.com --- arch/arm/mach-omap2/Makefile |6 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- [snip]--[snip] you sure this is the only board file having omap3-opp.h ? anyway.. the need for board files to use opp_init is gone with my patch http://marc.info/?l=linux-omapm=127507237109393w=2 so I wont harp on it, I would rather post a cleanup patch for all board files once the patch is in..(or mebbe kevin could drop the patch that adds opp_init_table to board files ;) ).. [sp] You didn't reead the 0/1 of the patch series, where I have clearly mentioned that I will make changes to the other board specific files once there rest of the changes are well discussed. There may be, possibly, more changes in the board specific files and we can review them in the context of this file and then same can be repeated for other board files. ok arch/arm/mach-omap2/cpufreq34xx.c | 164 arch/arm/mach-omap2/omap3-opp.h | 20 arch/arm/mach-omap2/opp34xx_data.c| 166 + arch/arm/mach-omap2/pm34xx.c |1 - arch/arm/plat-omap/Makefile |7 +- arch/arm/plat-omap/cpu-omap.c | 47 + arch/arm/plat-omap/include/plat/opp.h | 82 +--- arch/arm/plat-omap/opp.c | 46 - 10 files changed, 225 insertions(+), 316 deletions(-) delete mode 100644 arch/arm/mach-omap2/cpufreq34xx.c delete mode 100644 arch/arm/mach-omap2/omap3-opp.h create mode 100644 arch/arm/mach-omap2/opp34xx_data.c [sp] finding it difficult to align with this change, you introduce omap3_pm_init_opp_table later into plat/opp.h which defeats generic nature of opp.h - as it was supposed to be used for other omaps as well.. In that case the function omap3_pm_init_opp_table() can be made generic by renaming to omap_pm_init_opp_table and can be implemented for each omap family. Do you intend to handle multiomap case by calling each omap[1234]_pm_init_opp_table() if cpu_is_omap34xx() etc? you will still need a custom omap family specific init_opp_table - that is what this header provides. If opp table has to be implementyed for each family then why have different funtion with family specific prefixes? opp table contents will be different for each family and they should all build and co-exist in a single uImage. Also, what this headerf ile is/was doing? only defining the function to return -EINVAL when CONFIG_CPU_FREQ is not selected; which is not required. For OPP layer to be used this table needs to be populated. Now, there is only one place this function is used, so why do/should be need a header for the same. To allow the the external function that triggers it to be able to use it.. :) [snip]--[snip] +obj-y += opp.o +obj-$(CONFIG_TWL4030_POWER)+= opp_twl_tps.o NAK. you just need TWL4030_CORE not power here. any reason to retain power? it has no dependency on power.. [sp] Isn't this purpose of this opp to TWL linkage is to define the voltages in terms the PMIC connected; and later make sure that correct voltages are set via the PMIC? This is very much related no it does not. these are just translation functions, as long as _CORE exists, it means that the system uses twl and we should be good to go. to POWER. We could also do it on CORE; but I don't see this as a big issue. ok. But TWL4030 has more feature beyond PMIC but this is not the case with other simpler PMICs and I wanted to use CONFIG option that can be easier for someone else make the port easy to spot as a necessary change. i am aligned with the change, except that I believe you should not be using POWER as the prefix for the config build dependency. [snip]--[snip] + freq_table[i].index = i; + freq_table[i].frequency = CPUFREQ_TABLE_END; + + *table =freq_table[0]; +} +#endif + e why? it used to be here and was moved to opp.c - see http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p m.git;a=commit;h=9a6b00f70e9f4bce30ad4f8fab41a24bd3706dbd you are essentially reverting that patch! [sp] May be I am reverting the patch, but I don't see this function being used anywhere else. Most of the other cpufreq related initialization is happening at this place. Only the function omap_cpu_init() calls this function and it is in the same file. It also helps in need of an additional header; which seem to
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 James Bottomley james.bottom...@suse.de: On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? Well, android only needs two states (block and don't block), so that gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to describe these, but if all we're arguing over is the define name, that's progress. I think we need separate state constraints for suspend and idle low power modes. On the msm platform only a subset of the interrupts can wake up from the low power mode, so we block the use if the low power mode from idle while other interrupts are enabled. We do not block suspend however if those interrupts are not marked as wakeup interrupts. Most constraints that prevent suspend are not hardware specific and should not prevent entering low power modes from idle. In other words we may need to prevent low power idle modes while allowing suspend, and we may need to prevent suspend while allowing low power idle modes. Well, as I said, pm_qos is s32 ... it's easy to make the constraint ternary instead of binary. No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. It would also be good to not have an implementation that gets slower and slower the more clients you have. With binary constraints this is trivial. Well, that's an implementation detail ... ordering the list or using a True. I think we also need timeout support in the short term though which is also somewhat simpler to implement in an efficient way for binary constraints. btree would significantly fix that. However, the most number of constraint users I've seen in android is around 60 ... that's not huge from a kernel linear list perspective, so is this really a concern? ... particularly when most uses don't necessarily change the constrain, so a list search isn't done. The search is done every time any of them changes. The other piece they need is the suspend block name, which comes with the stats API, and finally we need to decide what the actual constraint is called (which is how the dev node gets its name) ... 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) 4. It would be useful to change pm_qos_add_request to not allocate anything so can add constraints from init functions that currently cannot fail. Sure .. we do that for the delayed work queues, it's just an API which takes the structure as an argument leaving it the responsibility of the caller to free. After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint
[PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
I think you have acknowledged that there is a race with suspend - thanks.
Next step was can it be closed.
You seem to suggest that it can, but you describe it as a work around
rather than a bug fix...
Do you agree that the race is a bug, and therefore it is appropriate to
fix it assuming an acceptable fix can be found (which I think it can)?
If we can fix it, yes we definitely should do and not work around it.
Thanks,
tglx
OK.
Here is my suggestion.
While I think this patch would actually work, and hope the ugly aspects are
reasonably balanced by the simplicity, I present it primarily as a base for
improvement.
The important part is to present how drivers and user-space can co-operate
to avoid losing wake-events. The details of what happens in the kernel are
certainly up for discussion (as is everything else really of course).
The user-space suspend daemon avoids losing wake-events by using
fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
is ready to be read by user-space. This may involve:
- the one daemon processing all wake events
- Both the suspend daemon and the main event handling daemon opening any
given device that delivers wake events (this should work with input
events ... unless grabbing is needed)
- The event handling daemon giving the suspend-daemon's pid as F_OWNER, and
using poll/select to get the events itself.
When 'mem' is written to /sys/power/state, suspend_prepare waits in an
interruptible wait until any wake-event that might have been initiated before
the suspend was request, has had a chance to be queued for user-space and
trigger kill_fasync.
Currently this wait is a configurable time after the last wake-event was
initiated. This is hackish, but simple and probably adequate.
If more precise timing is needed and achievable, that can be added later. It
would be an entirely internal change and would not affect the API further.
Some of the code developed for suspend-blockers might be a starting point for
this.
Drivers should call pm_suspend_delay() whenever a wake-event occurs. This
simply records the time so that the suspend process knows if there is in fact
any need to wait at all.
The delay to wait after the last pm_suspend_delay() is limited to 10 seconds
and can be set by kernel parameter suspend_block_delay=number-of-milliseconds
It defaults to 2 jiffies (which is possibly too short).
- Would this fix the bug??
- and address the issues that suspend-blockers was created to address?
- or are the requirements on user-space too onerous?
Thanks,
NeilBrown
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..ccbadd0 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -142,11 +142,13 @@ extern void arch_suspend_disable_irqs(void);
extern void arch_suspend_enable_irqs(void);
extern int pm_suspend(suspend_state_t state);
+extern void pm_suspend_delay(void);
#else /* !CONFIG_SUSPEND */
#define suspend_valid_only_mem NULL
static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
+static inlint void pm_suspend_delay(void) {}
#endif /* !CONFIG_SUSPEND */
/* struct pbe is used for creating lists of pages that should be restored
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..07897b9 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -46,6 +46,69 @@ bool valid_state(suspend_state_t state)
return suspend_ops suspend_ops-valid suspend_ops-valid(state);
}
+/*
+ * Devices that process potential wake-up events report each
+ * wake-up events by pm_suspend_delay();
+ * This ensures that suspend won't happen for a little while
+ * so the event has a chance to get to user-space.
+ * pm_suspend calls wait_for_blockers to wait the required
+ * little while and to check for signals.
+ * A process that requests a suspend should arrange (via
+ * fcntl(F_GETOWN)) to get signalled whenever a wake-up event
+ * is queued for user-space. This will ensure that if a suspend
+ * is requested at much the same time as a wakeup event arrives, either
+ * the suspend will be interrupted, or it will complete quickly.
+ *
+ * The little while is a heuristic to avoid having to explicitly
+ * track every event through the kernel with associated locking and unlocking.
+ * It should be more than the longest time it can take between an interrupt
+ * occurring and the corresponding event being queued to userspace
+ * (and the accompanying kill_fasync call).
+ * This duration is configurable at boot time, has a lower limit of 2
+ * jiffies and an upper limit of 10 seconds. It defaults to the minimum.
+ */
+static unsigned long little_while_jiffies = 2;
+static int __init
