Re: omap udc driver problem with beagle board
2010/5/30 Felipe Balbi m...@felipebalbi.com: On Sun, May 30, 2010 at 11:53:49AM +0200, Marco Stornelli wrote: beagle board uses musb. You shouldn't be relying on the udc controller. Your Kconfig is just wrong. -- balbi Mmmdoes it mean that it's not possible to use g_ether driver? I read in several docs/wiki that it's possible. Marco -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap udc driver problem with beagle board
2010/5/30 Felipe Balbi m...@felipebalbi.com: On Sun, May 30, 2010 at 11:53:49AM +0200, Marco Stornelli wrote: beagle board uses musb. You shouldn't be relying on the udc controller. Your Kconfig is just wrong. -- balbi Oops, my fault. I see the error in the configuration. Thank you very much for your response. I'll try again. Regards, Marco -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap udc driver problem with beagle board
On Mon, May 31, 2010 at 09:06:35AM +0200, ext Marco Stornelli wrote: Oops, my fault. I see the error in the configuration. Thank you very much for your response. I'll try again. no problem. -- 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 v4 1/2] input: touchscreen: introduce tsc2005 driver
Hi, It seems this patch is just hanging out in the air since quite long. Can Tony or Dmitry please pick this? Thanks. cheers, -roger Koskinen Aaro (Nokia-D/Helsinki) wrote: From: Lauri Leukkunen lauri.leukku...@nokia.com Introduce a driver for the Texas Instruments TSC2005 touchscreen controller (http://focus.ti.com/docs/prod/folders/print/tsc2005.html). The patch is based on a driver by Lauri Leukkunen, with modifications by David Brownell, Phil Carmody, Imre Deak, Hiroshi DOYU, Ari Kauppi, Tony Lindgren, Jarkko Nikula, Eero Nurkkala and Roman Tereshonkov. Signed-off-by: Lauri Leukkunen lauri.leukku...@nokia.com [aaro.koski...@nokia.com: patch description, rebasing cleanup] Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Phil Carmody ext-phil.2.carm...@nokia.com Cc: Imre Deak imre.d...@nokia.com Cc: Hiroshi DOYU hiroshi.d...@nokia.com Cc: Ari Kauppi ext-ari.kau...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Jarkko Nikula jhnik...@gmail.com Cc: Eero Nurkkala ext-eero.nurkk...@nokia.com Cc: Roman Tereshonkov roman.tereshon...@nokia.com --- v4: Refreshed the patches against the current mainline (13bd8e4673d527a9e48f41956b11d391e7c2cfe0). No other changes as no comments were received. The v3 has some major modifications. I have tried to clean up and simplify the driver. All action takes place in thread context, SPI transfers are synchronous, the spinlock is removed, and there are no long sections with interrupts disabled. The driver should be now SMP safe. Also the following review comments are addressed: - Use del_timer_sync() instead of del_timer(). - Use mod_timer() always instead of add_timer(). - Use attribute_group. - Delete filtering and averaging which belong to upper layers. - Delete pen_down sysfs file. The previous version and comments can be seen here: http://marc.info/?t=12573411564r=1w=2 drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tsc2005.c | 678 +++ include/linux/spi/tsc2005.h | 41 +++ 4 files changed, 731 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/tsc2005.c create mode 100644 include/linux/spi/tsc2005.h diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index dfafc76..72c1797 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -548,6 +548,17 @@ config TOUCHSCREEN_TOUCHIT213 To compile this driver as a module, choose M here: the module will be called touchit213. +config TOUCHSCREEN_TSC2005 +tristate TSC2005 based touchscreens +depends on SPI_MASTER +help + Say Y here if you have a TSC2005 based touchscreen. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called tsc2005. + config TOUCHSCREEN_TSC2007 tristate TSC2007 based touchscreens depends on I2C diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index d61a3b4..61fa8b5 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o +obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c new file mode 100644 index 000..27ee361 --- /dev/null +++ b/drivers/input/touchscreen/tsc2005.c @@ -0,0 +1,678 @@ +/* + * TSC2005 touchscreen driver + * + * Copyright (C) 2006-2010 Nokia Corporation + * + * Author: Lauri Leukkunen lauri.leukku...@nokia.com + * based on TSC2301 driver by Klaus K. Pedersen klaus.k.peder...@nokia.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/input.h
Re: [PATCH v4 1/2] input: touchscreen: introduce tsc2005 driver
Roger Quadros wrote: Hi, It seems this patch is just hanging out in the air since quite long. Can Tony or Dmitry please pick this? Ah I see Tony has already Acked the board patch and wants it to go through input tree. That would mean Dmitry's tree right? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial attempt to make ARM use LMB
* Russell King - ARM Linux li...@arm.linux.org.uk [100528 17:26]: On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote: Also, the last patch in lmb branch ARM: use LMB to allocate system memory MMIO resource structures causes both osk5912 and n900 to hang very early. Maybe I'm missing some patch again.. I'll drop this patch for the time being - we don't have stuff in the right order yet for lmb_alloc() to work immediately after arm_lmb_init() with highmem present - lmb_alloc tries to allocate from unmapped or high memory, which we then use __va() on and referencing the resulting pointer causes an abort. However, using lmb_alloc() for the OMAP framebuffers shouldn't be an issue because the problem only happens if you want to immediately dereference the memory. OK. Looks like your lmb branch still has it and is from the 23rd, maybe you forgot to push out the update lmb branch? 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
[APPLIED] [PATCH v2] omap: Stalker board: switch over to gpio_set_debounce
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 34ebd9a47caa9f4fc7bb28a08b89f712f409e55c PatchWorks http://patchwork.kernel.org/patch/103017/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=34ebd9a47caa9f4fc7bb28a08b89f712f409e55c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
Hello, 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 OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: 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 | 31 ++--- sound/soc/omap/omap-mcbsp.c | 112 +++--- 4 files changed, 114 insertions(+), 41 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/5] OMAP3: 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 6462968..f8ffeee 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
[RFC PATCH 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
[RFC PATCH 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 | 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..d6ed761 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,52 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+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);
+ 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 / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(bs, frames);
+
+}
+
+static int hw_rule_psize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *ps = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *c = 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.min = 8;
+ frames.max = size / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(ps, frames);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
@@ -185,33 +231,43 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
if (!cpu_dai-active)
err = omap_mcbsp_request(bus_id);
+ /*
+* 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 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)
+*/
+
+ /*
+* The first rule is for the buffer size, we should not allow smaller
+* buffer than the FIFO size to avoid underruns
+*/
+ snd_pcm_hw_rule_add(substream-runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+ hw_rule_bsize_by_channels, mcbsp_data,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1);
+
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
[RFC PATCH 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
[RFC PATCH 2/5] OMAP3: 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 | 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,
},
{
.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,
},
{
.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,
},
{
.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_SZARRAY_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.
--
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
Re: Commit 0c8219f0... breaks omap7xx support
* Cory Maccarrone darkstar6...@gmail.com [100529 06:56]: On Mon, Mar 15, 2010 at 11:29 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100309 15:38]: On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren t...@atomide.com wrote: Does your system boot without any patches if DEBUG_LL is not set in your .config? No, it doesn't. Seems like the debugging code is still trying to run, even disabled. If I add in that check, it'll boot with DEBUG_LL not set, but won't without that. Sorry for the delay on this. How about with the following patch with DEBUG_LL not set? Note that this is using the shift register now too. Regards, Tony Sorry I took so long on this one. This patch worked beautifully for me on the latest kernel tree. Any chance of it getting in for one of the RCs of this next kernel? Yeah this we should be able to merge as a fix. Can I add your Testedy-by to the 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: [PATCH v4 1/2] input: touchscreen: introduce tsc2005 driver
On 31/05/10 09:36 +0200, Quadros Roger (Nokia-D/Helsinki) wrote: Hi, It seems this patch is just hanging out in the air since quite long. Can Tony or Dmitry please pick this? I wouldn't mind if one of the listed authors adopted this patch, I've had nothing to do with it in the last two and a half years. /lauri Signed-off-by: Lauri Leukkunen lauri.leukku...@nokia.com [aaro.koski...@nokia.com: patch description, rebasing cleanup] Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Phil Carmody ext-phil.2.carm...@nokia.com Cc: Imre Deak imre.d...@nokia.com Cc: Hiroshi DOYU hiroshi.d...@nokia.com Cc: Ari Kauppi ext-ari.kau...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Jarkko Nikula jhnik...@gmail.com Cc: Eero Nurkkala ext-eero.nurkk...@nokia.com Cc: Roman Tereshonkov roman.tereshon...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Monday 31 May 2010 11:16:50 Ujfalusi Peter (Nokia-D/Tampere) wrote:
...
@@ -185,33 +231,43 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream, if (!cpu_dai-active)
err = omap_mcbsp_request(bus_id);
+ /*
+ * 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 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)
+ */
+
+ /*
+ * The first rule is for the buffer size, we should not allow smaller
+ * buffer than the FIFO size to avoid underruns
+ */
+ snd_pcm_hw_rule_add(substream-runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+ hw_rule_bsize_by_channels, mcbsp_data,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1);
+
Obviously this hw_rule must be moved after checking the CPU type, since it is
only valid for OMAP3 class of devices.
I'll fix this in the v2 series.
I have been testing this on OMAP3...
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.
+ * In case os threshold mode, the rule will ensure, that the
+ * period size is not bigger than the maximum allowed threshold
+ * value.
*/
- 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)
- max_period = omap_mcbsp_get_max_tx_threshold(bus_id);
- else
- max_period = omap_mcbsp_get_max_rx_threshold(bus_id);
-
- max_period++;
- max_period = 1;
-
if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- snd_pcm_hw_constraint_minmax(substream-runtime,
- SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
- 32, max_period);
+ snd_pcm_hw_rule_add(substream-runtime, 0,
+ SNDRV_PCM_HW_PARAM_CHANNELS,
+ hw_rule_psize_by_channels, substream,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1);
}
return err;
--
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 v4 1/2] input: touchscreen: introduce tsc2005 driver
* Lauri Leukkunen lauri.leukku...@nokia.com [100531 11:35]: On 31/05/10 09:36 +0200, Quadros Roger (Nokia-D/Helsinki) wrote: Hi, It seems this patch is just hanging out in the air since quite long. Can Tony or Dmitry please pick this? This should go via Dmitry's queue. I wouldn't mind if one of the listed authors adopted this patch, I've had nothing to do with it in the last two and a half years. Or Roger could look after it as he is already active trying to get it merged :) Regards, Tony Signed-off-by: Lauri Leukkunen lauri.leukku...@nokia.com [aaro.koski...@nokia.com: patch description, rebasing cleanup] Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Phil Carmody ext-phil.2.carm...@nokia.com Cc: Imre Deak imre.d...@nokia.com Cc: Hiroshi DOYU hiroshi.d...@nokia.com Cc: Ari Kauppi ext-ari.kau...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Jarkko Nikula jhnik...@gmail.com Cc: Eero Nurkkala ext-eero.nurkk...@nokia.com Cc: Roman Tereshonkov roman.tereshon...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/5/30 Rafael J. Wysocki r...@sisk.pl: On Saturday 29 May 2010, Arve Hjønnevåg wrote: 2010/5/29 Rafael J. Wysocki r...@sisk.pl: On Saturday 29 May 2010, Arve Hjønnevåg wrote: 2010/5/28 Rafael J. Wysocki r...@sisk.pl: On Friday 28 May 2010, Arve Hjønnevåg wrote: On Fri, May 28, 2010 at 1:44 AM, Florian Mickler flor...@mickler.org wrote: On Thu, 27 May 2010 20:05:39 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: ... To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call? I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle. It is, if the following two conditions hold simultaneously: (a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in. (b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending. I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions). I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense. If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started. However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle. What about timers? When you suspend timers stop (otherwise it is just a deep-idle mode), and this could cause problems. Some drivers rely on timers if the hardware does not have a completion interrupt. It is not uncommon to see send command x then wait 200ms in a some hardware specs. QoS should be used in such cases. 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? -- 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
[GIT PULL] omap iommu: updates for 2.6.35-rc1
Hi Tony, Here are the latest updates for omap iommu module. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update ducati mmu irq define name omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt Satish (1): omap iommu: Fix Memory leak arch/arm/mach-omap2/Makefile|5 +++- arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- arch/arm/plat-omap/iovmm.c |4 ++- 7 files changed, 73 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
On Fri, May 28, 2010 at 9:32 PM, David Brownell davi...@pacbell.net wrote: --- On Fri, 5/28/10, Steve Sakoman sako...@gmail.com wrote: By the way ... the #ifdeffery should indeed vanish from all board configs except the Davinci DM6446 EVM. That board is kind of quirky in terms of USB support, and needs jumpering to get host or peripheral mode (and can't do OTG). For Overo this patch actually makes quite a bit of sense (and I have been using something similar for quite some time). The Overo COM itself has no USB connector -- the customer can choose or create a daughter card with the type of USB connector appropriate to their application, So that would be another exception ... because it doesn't have a fixed USB connector (and thus does not convey to users any specific details about what modes it supports). Another issue is that OTG depends on PM, so if I build PM-less kernel (PM is still more or less in development on OMAPs), Kconfig will only allow host or peripheral for musb, which doesn't match OTG selection in the board file, and the driver fails. If a board is configured as host and driver is set to only support peripheral it is perfectly fine for the driver not to allow that. But why is the driver refusing OTG board setting if it's compiled to only support host/peripheral? If I apply [1], it works perfectly fine for me. What's wrong with degrading OTG to host/peripheral, did you really mean to NAK [1], David? Why can't I compile musb in a periperal/host-only mode if I have OTG connector? I have to patch around this every time :( [1] http://marc.info/?l=linux-usbm=127367875600618w=2 - 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
On Mon, May 31, 2010 at 11:44:05AM +0200, ext Grazvydas Ignotas wrote: If a board is configured as host and driver is set to only support peripheral it is perfectly fine for the driver not to allow that. But why is the driver refusing OTG board setting if it's compiled to only support host/peripheral? If I apply [1], it works perfectly fine for me. What's wrong with degrading OTG to host/peripheral, did you really mean to NAK [1], David? Why can't I compile musb in a periperal/host-only mode if I have OTG connector? otg depends on usb suspend, which depends on runtime pm (I guess), without suspend, host negotiation protocol will never work which is required on OTG. I believe that was Dave's reasoning. -- 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: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Mon, 2010-05-31 at 11:16 +0300, Peter Ujfalusi wrote:
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 | 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..d6ed761 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,52 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+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.
+ 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 / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(bs, frames);
+
+}
+
+static int hw_rule_psize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *ps = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
ditto
+ 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.min = 8;
+ frames.max = size / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(ps, frames);
+}
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
To unsubscribe from this list: send the line unsubscribe 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 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
+ 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 / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(bs, frames);
+
+}
+
+static int hw_rule_psize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *ps = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
ditto
Same here:
I mean:
ps == Period Size
c == Channels
Thanks
Liam
Never the less, I can change them,
Thanks,
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: [GIT PULL] omap iommu: updates for 2.6.35-rc1
* Hiroshi DOYU hiroshi.d...@nokia.com [100531 12:32]: Hi Tony, Here are the latest updates for omap iommu module. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update ducati mmu irq define name omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt Satish (1): omap iommu: Fix Memory leak This would be into for-next then. During the -rc cycle we can only merge real fixes and regressions as requested by Linus: http://lwn.net/Articles/389982/ Do you want to merge some of these as fixes? Maybe both omap iommu: update ducati mmu irq define name and omap iommu: Fix Memory leak patches should be merged as fixes? If so, then maybe put together another branch for the fixes. Also, have all these patches been reviewed also on the linux-arm-kernel list? I don't want to pull them until that's done. BTW, I've put together a quick checklist for merging patches via git: http://www.elinux.org/OMAP_patch_merging_process Cheers, 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
[APPLIED] [PATCH 14/18 FIX] omap: Overo: Add support for second ethernet
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 8620d0262e1fb2593891aa2102f608341b90dc99 PatchWorks http://patchwork.kernel.org/patch/101544/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8620d0262e1fb2593891aa2102f608341b90dc99 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 0/1] omap3: pm: Delink OPP layer from cpufreq
The OPP layer is currently contained in CONFIG_CPU_FREQ. When the ARM frequency is set via bootarg 'mpurate' the OPP layer is required to: - verify that specified mpurate is valid and available in the OPP table. - get voltage corresponding to specified frequency. This is initial attempt to make OPP layer available without cpufreq. Since, this is initial version, i am making changes in board-omap3evm.c only. same change will be required in other board files as well. Will do so in next version of the patch. I have also updated the OPP tables for OMAP3430 to include support for 720MHz. It will be a separate patch when I submit it next. [1] http://marc.info/?l=linux-omapm=127495955603835w=2 Sanjeev Premi (1): omap3: pm: Delink opp layer and cpufreq arch/arm/mach-omap2/Makefile |6 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq
The OPP layer was contained in the CONFIG_CPU_FREQ.
This patch removes this containment relation.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/Makefile |6 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
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
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ac08f99..4e51a99 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -55,10 +55,8 @@ AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
endif
-# CPU Frequency
-ifeq ($(CONFIG_CPU_FREQ),y)
-obj-$(CONFIG_ARCH_OMAP3) += cpufreq34xx.o
-endif
+# OPP definitions for OMAP3
+obj-$(CONFIG_ARCH_OMAP3) += opp34xx_data.o
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0a3f5b6..cb97c5d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -50,11 +50,11 @@
#include plat/common.h
#include plat/mcspi.h
#include plat/display.h
+#include plat/opp.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
-#include omap3-opp.h
#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
deleted file mode 100644
index 8747dd6..000
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ /dev/null
@@ -1,164 +0,0 @@
-/*
- * arch/arm/mach-omap2/cpufreq34xx.c
- * OMAP3 resource init/change_level/validate_level functions
- *
- * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
- * Nishanth Menon
- * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
- * Kevin Hilman
- * Copyright (C) 2010 Nokia Corporation.
- * Eduardo Valentin
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- * History:
- *
- */
-
-#include linux/module.h
-#include linux/err.h
-
-#include plat/opp.h
-#include plat/cpu.h
-#include omap3-opp.h
-
-static struct omap_opp_def __initdata omap34xx_mpu_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 12500, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 25000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 5, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 55000, 127),
- /* OPP5 */
- OMAP_OPP_DEF(true, 6, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap34xx_l3_rate_table[] = {
- /*
-* OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
-* almost the same than the one at 83MHz thus providing very little
-* gain for the power point of view. In term of energy it will even
-* increase the consumption due to the very negative performance
-* impact that frequency will do to the MPU and the whole system in
-* general.
-*/
- OMAP_OPP_DEF(false, 4150, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 8300, 105),
- /* OPP3 */
- OMAP_OPP_DEF(true, 16600, 115),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap34xx_dsp_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 9000, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 18000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 36000, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 4, 127),
- /* OPP5 */
- OMAP_OPP_DEF(true, 43000, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
- /* OPP1 - OPP50 */
- OMAP_OPP_DEF(true, 3, 93),
- /* OPP2 - OPP100 */
- OMAP_OPP_DEF(true, 6, 110),
- /* OPP3 - OPP-Turbo */
- OMAP_OPP_DEF(false, 8, 126),
- /* OPP4 - OPP-SB
Re: [PATCH v4 1/2] input: touchscreen: introduce tsc2005 driver
* Tony Lindgren t...@atomide.com [100531 11:44]: * Lauri Leukkunen lauri.leukku...@nokia.com [100531 11:35]: I wouldn't mind if one of the listed authors adopted this patch, I've had nothing to do with it in the last two and a half years. Or Roger could look after it as he is already active trying to get it merged :) Sorry I meant Aaro as he sent the patches, although Roger could also maintain it. Anyways, up to you guys to figure out who will maintain it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap4: Fix multi-omap boot with reset un-used clocks
* Paul Walmsley p...@pwsan.com [100520 02:05]: Hi, On Wed, 19 May 2010, Santosh Shilimkar wrote: This patch uses ENABLE_ON_INIT flag on the emif clock nodes to avoid the emif clk getting cut as part of reset un-used clock routine which prevents boot. Since omap4 omap2_clk_init() calls clk_enable_init_clocks() which increases the usecount on all ENABLE_ON_INIT clocks, it prevents omap2_clk_disable_unused() from disabling the clock. The real fix is to have driver for EMIF and do clock get/enable as part of it. The EMIF driver is planned to be done HWMOD way so till that available to keep omap3_defconfig booting on OMAP4430, this patch is necessary. (Will updated the auto-gen script for 44xx accordingly) The fix was suggested by Paul Walmsley Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, I've added Nishanth's Tested-by: and fixed the patch changelog; the following patch is now queued for 2.6.35-rc, unless there are any further comments. FYI, I'll also added this into omap-testing branch while we're waiting for your clock fixes branch to be available. 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] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
--- On Mon, 5/31/10, Grazvydas Ignotas nota...@gmail.com wrote: Another issue is that OTG depends on PM, so if I build PM-less kernel (PM is still more or less in development on OMAPs), Kconfig will only allow host or peripheral for musb, which doesn't match OTG selection in the board file, and the driver fails. As Felipe partially explained: OTG implies HNP, and HNP requires suspending the USB link, which requires some PM support... -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3630: Update ES1.1 silicon revision detection
Manjunatha GK wrote:
This patch updates ES1.1 silicon revision ID for OMAP3630
processor. The silicon revision can be read by reading hawkeye
and revision bits in IDCODE register.
Tested on 3630sdp(with ES1.1 silicon) and Zoom3(with ES1.0) silicon.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Tony Lindgren t...@atomide.com
Ping?
FWIW, tested on other OMAP3 ES1.1 boards too.
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/include/plat/cpu.h |3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..dd26092 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -259,11 +259,20 @@ void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
- /* FALLTHROUGH */
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP3630_REV_ES1_0;
+ /* Handle 36xx devices */
omap_chip.oc |= CHIP_IS_OMAP3630ES1;
+
+ switch(rev) {
+ case 0: /* Take care of early samples */
+ omap_revision = OMAP3630_REV_ES1_0;
+ break;
+ case 1:
+ /* Fall through */
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_1;
+ omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
+ }
}
}
@@ -339,6 +348,9 @@ void __init omap3_cpuinfo(void)
case OMAP_REVBITS_00:
strcpy(cpu_rev, 1.0);
break;
+ case OMAP_REVBITS_01:
+ strcpy(cpu_rev, 1.1);
+ break;
case OMAP_REVBITS_10:
strcpy(cpu_rev, 2.0);
break;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..04c7baa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -66,6 +66,7 @@ unsigned int omap_rev(void);
* family. This difference can be handled separately.
*/
#define OMAP_REVBITS_00 0x00
+#define OMAP_REVBITS_01 0x01
#define OMAP_REVBITS_10 0x10
#define OMAP_REVBITS_20 0x20
#define OMAP_REVBITS_30 0x30
@@ -376,6 +377,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3430_REV_ES3_1_2 0x34305034
#define OMAP3630_REV_ES1_0 0x36300034
+#define OMAP3630_REV_ES1_1 0x36300134
#define OMAP35XX_CLASS 0x3534
#define OMAP3503_REV(v) (OMAP35XX_CLASS |
(0x3503 16) | (v 8))
@@ -411,6 +413,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define CHIP_IS_OMAP3430ES3_1(1 6)
#define CHIP_IS_OMAP3630ES1 (1 7)
#define CHIP_IS_OMAP4430ES1 (1 8)
+#define CHIP_IS_OMAP3630ES1_1 (1 9)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
--
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
--
To unsubscribe from this list: send the line unsubscribe 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] [MMC] omap: Remove BUG_ON for disabled interrupts
* Cory Maccarrone darkstar6...@gmail.com [100530 05:22]: This change removes a BUG_ON for when interrupts are disabled during an MMC request. During boot, interrupts can be disabled when a request is made, causing this bug to be triggered. In reality, there's no reason this should halt the kernel, as the driver has proved reliable in spite of disabled interrupts, and additionally, there's nothing in this code that would require interrupts to be enabled. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- drivers/mmc/host/omap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 2b28168..d98ddcf 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, mmc_omap_start_command(host, req-cmd); if (host-dma_in_use) omap_start_dma(host-dma_ch); - BUG_ON(irqs_disabled()); } static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) This looks safe to me. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3630: Update ES1.1 silicon revision detection
On 05/31/2010 03:50 PM, Gadiyar, Anand wrote:
Manjunatha GK wrote:
This patch updates ES1.1 silicon revision ID for OMAP3630
processor. The silicon revision can be read by reading hawkeye
and revision bits in IDCODE register.
Tested on 3630sdp(with ES1.1 silicon) and Zoom3(with ES1.0) silicon.
Signed-off-by: Manjunatha GKmanj...@ti.com
Cc: Nishanth Menonn...@ti.com
Cc: Tony Lindgrent...@atomide.com
Ping?
FWIW, tested on other OMAP3 ES1.1 boards too.
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/include/plat/cpu.h |3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..dd26092 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -259,11 +259,20 @@ void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
- /* FALLTHROUGH */
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP3630_REV_ES1_0;
+ /* Handle 36xx devices */
omap_chip.oc |= CHIP_IS_OMAP3630ES1;
+
+ switch(rev) {
+ case 0: /* Take care of early samples */
+ omap_revision = OMAP3630_REV_ES1_0;
+ break;
+ case 1:
+ /* Fall through */
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_1;
+ omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
just a late realization relooking at the code: omap_chip.oc is ES1 and
ES1_1?
+ }
}
}
@@ -339,6 +348,9 @@ void __init omap3_cpuinfo(void)
case OMAP_REVBITS_00:
strcpy(cpu_rev, 1.0);
break;
+ case OMAP_REVBITS_01:
+ strcpy(cpu_rev, 1.1);
+ break;
case OMAP_REVBITS_10:
strcpy(cpu_rev, 2.0);
break;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..04c7baa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -66,6 +66,7 @@ unsigned int omap_rev(void);
* family. This difference can be handled separately.
*/
#define OMAP_REVBITS_00 0x00
+#define OMAP_REVBITS_010x01
#define OMAP_REVBITS_10 0x10
#define OMAP_REVBITS_20 0x20
#define OMAP_REVBITS_30 0x30
@@ -376,6 +377,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3430_REV_ES3_1_2 0x34305034
#define OMAP3630_REV_ES1_00x36300034
+#define OMAP3630_REV_ES1_1 0x36300134
#define OMAP35XX_CLASS0x3534
#define OMAP3503_REV(v) (OMAP35XX_CLASS |
(0x3503 16) | (v 8))
@@ -411,6 +413,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define CHIP_IS_OMAP3430ES3_1 (1 6)
#define CHIP_IS_OMAP3630ES1 (1 7)
#define CHIP_IS_OMAP4430ES1 (1 8)
+#define CHIP_IS_OMAP3630ES1_1 (1 9)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
--
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
--
To unsubscribe from this list: send the line unsubscribe 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
Nishanth Menon n...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat; \
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a check
in that sense. if you look at it from features variable, yeah it is updating
it, but the idea of usage of the Macro is: check in status if feature X is
available.. which is what it does ;). btw, the intent of the current patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in common.c,
the check_feature and id.c has not set that bit, the variable will remain 0,
hence omap_has_sgx() will return 0 unless someone enables that for lets say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was meant
solely to reorganize and provide an infrastructure for further development.
I don't agree. The patch / series is about making them 'generic', where generic
is, to the minimum, making the features exposed for major silicon versions.
If they are not usable beyond OMAP3, it's not generic.
[Apologies for the delayed reply, seem to have a delayed delivery issue]
-Venkat.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: Not using suspend is exactly the point. As Alan has argued, propagating suspend blockers up into all regions of userspace will take much longer than fixing the hardware. Strange, that's not what I heard as the possible solution. 20100527232043.784d5...@lxorguk.ukuu.org.uk 20100528101755.7b5f6...@lxorguk.ukuu.org.uk -- To unsubscribe from this list: send the line unsubscribe 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 Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: If current hardware can't cope, too friggin bad, get better hardware. But the truth is, all your OMAP phones really can deal with it. That's rubbish and you know it. We do software workarounds for hardware problems all the time ... try doing a git grep -i errata in arch x86, or imagine a USB subsystem that only supported sane standards conforming devices: that would have an almost zero intersect with the current USB device market. The job of the kernel is to accommodate hardware as best it can ... sometimes it might not be able to, but most of the time it does a pretty good job. Sure, and if x86 could wake from S3 on a keypress/mouse movement etc.. you could use S3 as idle state.. not sure people would love the wakeup-latency, but that's a QoS matter. But if there simply are no suitable wakeup sources from an idle state (S3 really is nothing more than a hardware idle state) then it might not be suitable for transparent idle modes and no amount of software hackery will solve that. So what I'm saying is, if your hardware can't generate the needed wakeup events, the auto-suspend stuff won't work either. If it can it can be implemented as a regular idle mode. The facts are that C states and S states are different and are entered differently. For some omap hardware, the power consumption in the lowest C state (with all the ancillary power control) is the same as S3, that's fine, suspend from idle works as well as suspend to ram modulo bad apps. For quite a lot of MSM hardware, the lowest C state power consumption is quite a bit above S3. Wth is MSM? But really, why can't existing hardware get shipped with existing hacks, and for future hardware that does behave we have a proper solution? -- To unsubscribe from this list: send the line unsubscribe 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 Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: Correct, I strongly oppose using suspend. Not running runnable tasks is not a sane solution. Look, this is getting into the realms of a pointless semantic quibble. The problem is that untrusted tasks need to be forcibly suspended when they have no legitimate work to do and the user hasn't authorised them to continue even if the scheduler sees them as runnable. Whether that's achieved by suspending the entire system or forcibly idling the tasks (using blocking states or freezers or something) so the scheduler can suspend from idle is something to be discussed, So what happens if you task is CPU bound and gets suspended and is holding a resource (lock, whatever) that is required by someone else that didn't get suspended? That's the classic inversion problem, and is caused by not running runnable tasks. but the net result is that we have to stop a certain set of tasks in such a way that they can still receive certain external events ... semantically, this is equivalent to not running runnable tasks in my book. Why would be care about external events? Clearly these apps are ill behaved, otherwise they would have listened to the environment telling them to idle. Why would you try to let buggy apps work as intended instead of break them as hard as possible? Such policy promotes crappy code since people get away with it. (Perhaps this whole thing is because the word runnable means different things ... I'm thinking a task that would consume power ... are you thinking in the scheduler R state?) Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care. Realistically, the main thing we need to do is stop timers posted against the task (which is likely polling in a main loop, that being the usual form of easy to write but power crazy app behaviour) from waking the task and bringing the system out of suspend (whether from idle or forced). Sure, that same main loop will probably receive a message along the lines of, 'hey, screen is off, we ought to go sleep'. If after that it doesn't listen, and more serious messages don't get responded to, simply kill the thing. Again, there is no reason what so ever to tolerate broken apps, it only promotes crappy apps. -- To unsubscribe from this list: send the line unsubscribe 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 05/31/2010 07:06 PM, Venkatraman S wrote:
Nishanth Menonn...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.comwrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((statusOMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a check
in that sense. if you look at it from features variable, yeah it is updating
it, but the idea of usage of the Macro is: check in status if feature X is
available.. which is what it does ;). btw, the intent of the current patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
Thanks.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in common.c,
the check_feature and id.c has not set that bit, the variable will remain 0,
hence omap_has_sgx() will return 0 unless someone enables that for lets say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was meant
solely to reorganize and provide an infrastructure for further development.
I don't agree. The patch / series is about making them 'generic', where generic
is, to the minimum, making the features exposed for major silicon versions.
If they are not usable beyond OMAP3, it's not generic.
Which part is not generic? I am unable to comprehend your contention
here. Are you contending that ISP, l2cache, neon, isp are *not* generic
OMAP features? or are you contending that since I did not add the
OMAP2,4 logic to detect the same, this patch is not valid?
all silicon revisions CAN use the function omap_has_sgx() now, even
though I have not added detection logic to actually populate the same.
if you do have a patch for detecting actual OMAP4/2 features feel free
to add to the patch list, I am more than happy to ack them, if they look
good - I personally dont have a omap4 platform at the very moment to
write and post a patch - however trivial it may be.
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: [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 +-
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 ;) )..
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
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ac08f99..4e51a99 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -55,10 +55,8 @@ AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
endif
-# CPU Frequency
-ifeq ($(CONFIG_CPU_FREQ),y)
-obj-$(CONFIG_ARCH_OMAP3) += cpufreq34xx.o
-endif
+# OPP definitions for OMAP3
+obj-$(CONFIG_ARCH_OMAP3) += opp34xx_data.o
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0a3f5b6..cb97c5d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -50,11 +50,11 @@
#includeplat/common.h
#includeplat/mcspi.h
#includeplat/display.h
+#includeplat/opp.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
-#include omap3-opp.h
#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
deleted file mode 100644
index 8747dd6..000
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ /dev/null
@@ -1,164 +0,0 @@
-/*
- * arch/arm/mach-omap2/cpufreq34xx.c
- * OMAP3 resource init/change_level/validate_level functions
- *
- * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
- * Nishanth Menon
- * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
- * Kevin Hilman
- * Copyright (C) 2010 Nokia Corporation.
- * Eduardo Valentin
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- * History:
- *
- */
-
-#includelinux/module.h
-#includelinux/err.h
-
-#includeplat/opp.h
-#includeplat/cpu.h
-#include omap3-opp.h
-
-static struct omap_opp_def __initdata omap34xx_mpu_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 12500, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 25000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 5, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 55000, 127),
- /* OPP5 */
- OMAP_OPP_DEF(true, 6, 135),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap34xx_l3_rate_table[] = {
- /*
-* OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
-* almost the same than the one at 83MHz thus providing very little
-* gain for the power point of view. In term of energy it will even
-* increase the consumption due to the very negative performance
-* impact that frequency will do to the MPU and the whole system in
-* general.
-*/
- OMAP_OPP_DEF(false, 4150, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 8300, 105),
- /* OPP3 */
- OMAP_OPP_DEF(true, 16600, 115),
- /* Terminator */
- OMAP_OPP_DEF(0, 0, 0)
-};
-
-static struct omap_opp_def __initdata omap34xx_dsp_rate_table[] = {
- /* OPP1 */
- OMAP_OPP_DEF(true, 9000, 975000),
- /* OPP2 */
- OMAP_OPP_DEF(true, 18000, 1075000),
- /* OPP3 */
- OMAP_OPP_DEF(true, 36000, 120),
- /* OPP4 */
- OMAP_OPP_DEF(true, 4, 127),
- /* OPP5 */
-
Re: [RFC PATCH 2/5] OMAP3: McBSP: Change the way how the FIFO is handled
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..
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,
},
{
.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,
},
{
.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,
},
{
.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.
--
To unsubscribe from this list: send the line unsubscribe 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
Nishanth Menon menon.nisha...@gmail.com wrote:
On 05/31/2010 07:06 PM, Venkatraman S wrote:
Nishanth Menonn...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat)
\
if (((status OMAP3_ ##feat## _MASK)
\
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) {
\
- omap3_features |= OMAP3_HAS_ ##feat;
\
+ omap_features |= OMAP_HAS_ ##feat;
\
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a
check
in that sense. if you look at it from features variable, yeah it is
updating
it, but the idea of usage of the Macro is: check in status if feature X
is
available.. which is what it does ;). btw, the intent of the current
patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
Thanks.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in
common.c,
the check_feature and id.c has not set that bit, the variable will remain
0,
hence omap_has_sgx() will return 0 unless someone enables that for lets
say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was
meant
solely to reorganize and provide an infrastructure for further
development.
I don't agree. The patch / series is about making them 'generic', where
generic
is, to the minimum, making the features exposed for major silicon
versions.
If they are not usable beyond OMAP3, it's not generic.
Which part is not generic? I am unable to comprehend your contention here.
Are you contending that ISP, l2cache, neon, isp are *not* generic OMAP
features? or are you contending that since I did not add the OMAP2,4 logic
to detect the same, this patch is not valid?
all silicon revisions CAN use the function omap_has_sgx() now, even though I
have not added detection logic to actually populate the same. if you do have
a patch for detecting actual OMAP4/2 features feel free to add to the patch
list, I am more than happy to ack them, if they look good - I personally
dont have a omap4 platform at the very moment to write and post a patch -
however trivial it may be.
It is this..
or are you contending that since I did not add the OMAP2,4 logic
to detect the same, this patch is not valid?
I understand that you might not have all platforms to test with, but
let's not provide a
'generic feature api' without it being available for the supported platforms.
It's incomplete without it.
Regards,
Venkat.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On 05/31/2010 09:46 PM, S, Venkatraman wrote:
I understand that you might not have all platforms to test with, but
let's not provide a
'generic feature api' without it being available for the supported platforms.
It's incomplete without it.
well.. if you did read 0/6
http://marc.info/?l=linux-omapm=127458581708411w=2
Caveat: this series just introduces the framework by reorganizing
the existing data, it does not attempt to define what the features
for OMAP1,2,3,4 would be. As usual, comments are welcome.
:) anyways, these are how the three follow on patches will look like
(sample omap1,2,4 patches are attached), feel free to ack them after
testing - but this patch 6/6 needs to be done prior to the remaining
being added - that is one more reason why i stopped where I did.
Feel free to modify to rectify my patches and post good ones, as you
see, you will need to do 6/6 before doing anything further anyways..
Regards,
Nishanth Menon
From a4f7d23139f8ccfc6b0e910017a759faa0d59578 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:03:28 -0500
Subject: [PATCH 1/3] omap: id: introduce omap4 feature
introduce basic omap4 feature framework
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap2/id.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 01555b6..e3f5994 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -267,6 +267,19 @@ static void __init omap3_check_revision(void)
}
}
+static void __init omap4_check_features(void)
+{
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ if (cpu_is_omap4430())
+ omap_features |= OMAP_HAS_L2CACHE |
+ OMAP_HAS_IVA |
+ OMAP_HAS_SGX |
+ OMAP_HAS_NEON;
+}
+
static void __init omap4_check_revision(void)
{
u32 idcode;
@@ -382,6 +395,7 @@ void __init omap2_check_revision(void)
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
+ omap4_check_features();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
--
1.6.3.3
From 0e4c9df9870c29da19234a1f4be5227a289b6463 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:10:31 -0500
Subject: [PATCH 2/3] omap: id: introduce omap24xx generic features
introduce generic features for omap2. omap2 uses mbx, not sgx, and
it still has a dsp, though not iva2 as omap3 uses..
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap2/id.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f5994..fe634dd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -102,6 +102,16 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static void __init omap24xx_check_features(void)
+{
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ omap_features |= OMAP_HAS_L2CACHE |
+ OMAP_HAS_IVA;
+}
+
static void __init omap24xx_check_revision(void)
{
int i, j;
@@ -388,6 +398,7 @@ void __init omap2_check_revision(void)
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
+ omap24xx_check_features();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
--
1.6.3.3
From c297e29bfd27c373af8d9bdc428f72cad2ef4e7a Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:13:57 -0500
Subject: [PATCH 3/3] omap: id: add feature check for omap1
add a minimalist feature - l2cache for omap1.
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap1/id.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index 91dbb71..b98a17f 100644
--- a/arch/arm/mach-omap1/id.c
+++ b/arch/arm/mach-omap1/id.c
@@ -200,5 +200,11 @@ void __init omap1_check_revision(void)
printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n,
die_rev, omap_revision 0xff, system_serial_low,
system_serial_high);
+
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ omap_features |= OMAP_HAS_L2CACHE;
}
--
1.6.3.3
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Sat, 29 May 2010 20:12:14 +0200 Peter Zijlstra pet...@infradead.org wrote: On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: Correct, I strongly oppose using suspend. Not running runnable tasks is not a sane solution. Look, this is getting into the realms of a pointless semantic quibble. The problem is that untrusted tasks need to be forcibly suspended when they have no legitimate work to do and the user hasn't authorised them to continue even if the scheduler sees them as runnable. Whether that's achieved by suspending the entire system or forcibly idling the tasks (using blocking states or freezers or something) so the scheduler can suspend from idle is something to be discussed, So what happens if you task is CPU bound and gets suspended and is holding a resource (lock, whatever) that is required by someone else that didn't get suspended? That's the classic inversion problem, and is caused by not running runnable tasks. The trick with the approach currently discussed (i.e. opportunistic suspend, if you missed it): We suspend the whole machine. And I really think, this is the only way to do it. It is a big hammer, shure. But if you can pull it of... but the net result is that we have to stop a certain set of tasks in such a way that they can still receive certain external events ... semantically, this is equivalent to not running runnable tasks in my book. Why would be care about external events? Clearly these apps are ill behaved, otherwise they would have listened to the environment telling them to idle. Why would you try to let buggy apps work as intended instead of break them as hard as possible? Such policy promotes crappy code since people get away with it. If I have a simple shell script then I don't wanna jump through hoops just to please your fragile kernel. And before you judge code that does not behave to work with YOUR buggy kernel, i would think twice. This cuts both ways. Just because the problem is too hard for you, this does not excuse forcing crappy kernels on other people. I think you have a point in that it is _in general_ not easily possible to solve. But for this case this is clearly a simple, to the point and working solution for android based phones. Der Wurm muss dem Fisch schmecken, nicht dem Angler. (Perhaps this whole thing is because the word runnable means different things ... I'm thinking a task that would consume power ... are you thinking in the scheduler R state?) Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care. Realistically, the main thing we need to do is stop timers posted against the task (which is likely polling in a main loop, that being the usual form of easy to write but power crazy app behaviour) from waking the task and bringing the system out of suspend (whether from idle or forced). Sure, that same main loop will probably receive a message along the lines of, 'hey, screen is off, we ought to go sleep'. If after that it doesn't listen, and more serious messages don't get responded to, simply kill the thing. I think this would be a possibility. And maybe even sane. But I also think this has nothing to do with suspend_blockers. They block suspend. You know? Again, there is no reason what so ever to tolerate broken apps, it only promotes crappy apps. This simple doesn't solve the problem. Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe 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 22:12:19 +0200 Florian Mickler flor...@mickler.org wrote: On Sat, 29 May 2010 20:12:14 +0200 Peter Zijlstra pet...@infradead.org wrote: Why would you try to let buggy apps work as intended instead of break them as hard as possible? Such policy promotes crappy code since people get away with it. If I have a simple shell script then I don't wanna jump through hoops just to please your fragile kernel. Also why should that code on one device kill my uptime and on the other machine (my wall-plugged desktop) work just well? That doesn't sound right. Clearly opportunistic suspend is a workaround for battery-driven devices and no general solution. But it is not specific to android. At least not inherently. It could be useful for any embedded or mobile device where you can clearly distinguish important functions from convenience functions. I really can't understand the whole _fundamental_ opposition to this design choice. Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe 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 Sat, 29 May 2010, James Bottomley wrote: The job of the kernel is to accommodate hardware as best it can ... sometimes it might not be able to, but most of the time it does a pretty good job. The facts are that C states and S states are different and are entered differently. That's an x86'ism which is going away. And that's really completely irrelevant for the mobile device space. Can we please stop trying to fix todays x86 based laptop problems? They are simply not fixable. For some omap hardware, the power consumption in the lowest C state (with all the ancillary power control) is the same as S3, that's fine, suspend from idle works as well as suspend to ram modulo bad apps. For quite a lot of MSM hardware, the lowest C state power consumption is quite a bit above S3. It's not acceptable to tell those people tough, your battery runs out in 30 minutes because you bought the wrong hardware. We have to figure out how to get to S3 ... whether this is from idle or some other mechanism is again a discussion point, but not doing it is not an option. If you'd have read the answers from Alan carefully, then you'd have noticed that even x86 hardware is getting to the point where OMAP is today. i.e. support of transparent suspend from idle. If that wouldn't happen then x86 would be simply unusable for mobile devices. It's that easy. And we really do _NOT_ care about the existing laptop hardware which does not provide that because it's a lost case. Not only due to the missing (or just disabled) wakeup sources, also due to the fact that you cannot do sensible power management by completely disabling clock and/or power of unused devices in the chipset. There is a damn good reason why the mobile space is _NOT_ x86 based at the moment. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Sat, 2010-05-29 at 20:12 +0200, Peter Zijlstra wrote: On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: Correct, I strongly oppose using suspend. Not running runnable tasks is not a sane solution. Look, this is getting into the realms of a pointless semantic quibble. The problem is that untrusted tasks need to be forcibly suspended when they have no legitimate work to do and the user hasn't authorised them to continue even if the scheduler sees them as runnable. Whether that's achieved by suspending the entire system or forcibly idling the tasks (using blocking states or freezers or something) so the scheduler can suspend from idle is something to be discussed, So what happens if you task is CPU bound and gets suspended and is holding a resource (lock, whatever) that is required by someone else that didn't get suspended? That's the classic inversion problem, and is caused by not running runnable tasks. OK ... but if the options are running and S3 for the entire platform, then all tasks get suspended and this isn't a problem. This is why the current wakelock implementation on the android platform works flawlessly today. Inversion only becomes a problem if tasks get individually idled, so you can see that, from the android point of view, we're creating a problem which their implementation doesn't have. In this view, S3 suspend does look elegant: it solves the inversion problem by suspending everything, it controls rogue applications' power consumption and it gets certain hardware into a lower power state than is possible from suspend from idle. The inelegance of the S3 suspend solution is the requirement to use these suspend blockers through kernel and user space to get the whole thing up again to respond to an event, which is an inelegance suspend from idle doesn't have. but the net result is that we have to stop a certain set of tasks in such a way that they can still receive certain external events ... semantically, this is equivalent to not running runnable tasks in my book. Why would be care about external events? Clearly these apps are ill behaved, otherwise they would have listened to the environment telling them to idle. That's not a correct characterisation. Badly behaved apps from a power point of view can do useful things for the user. The object is to contain the badness while still getting useful stuff done. Why would you try to let buggy apps work as intended instead of break them as hard as possible? Such policy promotes crappy code since people get away with it. (Perhaps this whole thing is because the word runnable means different things ... I'm thinking a task that would consume power ... are you thinking in the scheduler R state?) Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care. Realistically, the main thing we need to do is stop timers posted against the task (which is likely polling in a main loop, that being the usual form of easy to write but power crazy app behaviour) from waking the task and bringing the system out of suspend (whether from idle or forced). Sure, that same main loop will probably receive a message along the lines of, 'hey, screen is off, we ought to go sleep'. If after that it doesn't listen, and more serious messages don't get responded to, simply kill the thing. Again, there is no reason what so ever to tolerate broken apps, it only promotes crappy apps. Actually, no, if this were a correct view, we wouldn't have the huge x86 hardware work around problem because we'd just be able to tell manufacturers of shoddy or badly standards compliant stuff where to stick it. The great strength of the x86 commodity platform revolution was the fact that the hardware became cheap, plentiful and outside the ambit of a single walled garden manufacturer. It's great weakness is integration problems and shoddy hardware. We tolerate the weakness because the strength vastly outweighs it: and toleration to us in the kernel means driver work arounds ... it also means that if a device doesn't work with the kernel, we get blamed (rather than the manufacturer). By the same token, the revolution in smart phones is driven in quite a large part by the provision of third party applications. This commodity app view is almost the direct software analogue of the commodity platform view that has been so successful in hardware; Therefore, fair play seems to demand that we don't draw a hard line for software applications that we wouldn't draw for hardware devices. 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 Saturday 29 May 2010, Peter Zijlstra wrote: On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: Correct, I strongly oppose using suspend. Not running runnable tasks is not a sane solution. Look, this is getting into the realms of a pointless semantic quibble. The problem is that untrusted tasks need to be forcibly suspended when they have no legitimate work to do and the user hasn't authorised them to continue even if the scheduler sees them as runnable. Whether that's achieved by suspending the entire system or forcibly idling the tasks (using blocking states or freezers or something) so the scheduler can suspend from idle is something to be discussed, So what happens if you task is CPU bound and gets suspended and is holding a resource (lock, whatever) that is required by someone else that didn't get suspended? That's the classic inversion problem, and is caused by not running runnable tasks. That, among other things, is why suspend uses the freezer which guarantees that nothing like this will happen. but the net result is that we have to stop a certain set of tasks in such a way that they can still receive certain external events ... semantically, this is equivalent to not running runnable tasks in my book. Why would be care about external events? Clearly these apps are ill behaved, otherwise they would have listened to the environment telling them to idle. Why would you try to let buggy apps work as intended instead of break them as hard as possible? Such policy promotes crappy code since people get away with it. Yeah, and that's why Windows owns desktop market. ;-) (Perhaps this whole thing is because the word runnable means different things ... I'm thinking a task that would consume power ... are you thinking in the scheduler R state?) Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care. Realistically, the main thing we need to do is stop timers posted against the task (which is likely polling in a main loop, that being the usual form of easy to write but power crazy app behaviour) from waking the task and bringing the system out of suspend (whether from idle or forced). Sure, that same main loop will probably receive a message along the lines of, 'hey, screen is off, we ought to go sleep'. If after that it doesn't listen, and more serious messages don't get responded to, simply kill the thing. Again, there is no reason what so ever to tolerate broken apps, it only promotes crappy apps. Do you realistically think that by hurting the _user_ you will make the _developer_ write better code? No, really. If the user likes the app very much (or depends on it or whatever makes him use it), he will rather switch the platform to one that allows him to run that app without _visible_ problems than complain to the developer, because _the_ _user_ _doesn't_ _realize_ that the app is broken. From the user's perspective, the platform that has problems with the app is broken, because the app apparently runs without problems on concurrent platforms. The whole no reason to tolerate broken apps midset is simply misguided IMO, because it's based on unrealistic assumptions. That's because in general users only need the platform for running apps they like (or need or whatever). If they can't run apps they like on a given platform, or it is too painful to them to run their apps on it, they will rather switch to another platform than stop using the apps. Thanks, 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)
Hi, again! My two mails were probably a bit pointless and not helping to find a solution. There are notable and useful approaches mentioned by Peter to the mitigation problem. It's just that it's not the one and only way to think about this. Just rants, Flo -- To unsubscribe from this list: send the line unsubscribe 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, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote: On Sat, 29 May 2010, James Bottomley wrote: The job of the kernel is to accommodate hardware as best it can ... sometimes it might not be able to, but most of the time it does a pretty good job. The facts are that C states and S states are different and are entered differently. That's an x86'ism which is going away. And that's really completely irrelevant for the mobile device space. Can we please stop trying to fix todays x86 based laptop problems? They are simply not fixable. 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. For some omap hardware, the power consumption in the lowest C state (with all the ancillary power control) is the same as S3, that's fine, suspend from idle works as well as suspend to ram modulo bad apps. For quite a lot of MSM hardware, the lowest C state power consumption is quite a bit above S3. It's not acceptable to tell those people tough, your battery runs out in 30 minutes because you bought the wrong hardware. We have to figure out how to get to S3 ... whether this is from idle or some other mechanism is again a discussion point, but not doing it is not an option. If you'd have read the answers from Alan carefully, then you'd have noticed that even x86 hardware is getting to the point where OMAP is today. i.e. support of transparent suspend from idle. If that wouldn't happen then x86 would be simply unusable for mobile devices. It's that easy. And we really do _NOT_ care about the existing laptop hardware which does not provide that because it's a lost case. Not only due to the missing (or just disabled) wakeup sources, also due to the fact that you cannot do sensible power management by completely disabling clock and/or power of unused devices in the chipset. There is a damn good reason why the mobile space is _NOT_ x86 based at the moment. So not at all interested in x86 at the moment. 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. 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 Sat, 29 May 2010, James Bottomley wrote:
On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.
Strange, that's not what I heard as the possible solution. I thought he
was advocating expressing the kernel side of suspend blockers as QoS
constraints. Once we have QoS constraints correctly done in the kernel,
userspace still has to express its requirements. If the requirements
are static, then they can be done from policy files or in some other
static way but if they're dynamic, they'll still have to be in the
applications ... in about the same places the android wakelocks are.
That's wrong. You only need the explicit dynamic QoS constraints for
applications which follow the scheme:
while (1) {
if (event_available())
process_event();
else
do_useless_crap_which_consumes_power();
}
which need the following annotation:
while (1) {
block_suspend();
if (event_available()) {
process_event();
unblock_suspend();
} else {
unblock_suspend();
do_useless_crap_which_consumes_power();
}
}
Plus the kernel counterpart of drivers which take the suspend blocker
in the interrupt handler and release it when the event queue is empty.
So that's done for making polling event handling power efficient.
Even worse, you need the same annotation for non polling mode and it
enforces the use of select() because you cannot take a suspend blocker
across a blocking read() without adding more invasive interactions to
the kernel..
So the sane app looks like:
while (1) {
select();
block_suspend();
process_events();
unblock_suspend();
}
I'm really tired of arguing that this promotion of programming style
is the worst idea ever, so let's look how you can do the same thing
QoS based.
s/block_suspend()/qos(INTERACTIVE)/ and
s/unblock_suspend()/qos(NONE)/ and
s/block_magic()/qos_magic()/ in the drivers.
Yes, it's mostly the same, with a subtle difference:
While android can use it in the big hammer approach to disable the
existing user initiated suspend via /sys/power/state, the rest of the
world can benefit as well in various ways.
- Sane applications which use a blocking event wait can be handled
with a static QoS setting simply because a blocking read relies on
the QoS state of the underlying I/O system.
- Idle based suspend as the logical consequence of idle states is
just a matter of QoS constraint based decisions.
- Untrusted apps can be confined in cgroups. The groups are set to
QoS(None) when user land decides that it's time to safe power
(e.g. screen lock kicks in)
- QoS states can block applications from I/O when the I/O system is
set to a state which is exclusive.
- ...
So that allows to use the same mechanism for more than the android
sledge hammer approach and confines the controversial use cases into
android specific files without adding a hard to maintain user space
interface which would prevent or at least make it hard to do some of
the above mentioned things which we want to see implemented.
While I personally disagree with the android approach, I REALLY want
to provide them a mechanism to make it work, but not for the price
that it actively prevents solutions which are considered to be
technically superior by a relevant group of developers/maintainers.
You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.
I don't think anyone disagrees with this. As long as we find a long term
solution that satisfies the android case, everyone will be happy.
See above.
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
[RFC] [PATCH v3 0/4] OMAP4 Keyboard Controller Support
Keyboard controller for OMAP4 includes - built-in scanning algorithm - debouncing feature - handling mechanism up to 9 x 9 keys - wake-up event generation Dependency on hwmod changes for OMAP4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28188.html Tested using SDP4430 board in Kevin Hillman's tree, origin/pm-wip/mmc branch commit 14ed0ad58d8dcfdde319ec6bbf66c3c318e5cd02 Author: Benoit Cousson b-cous...@ti.com OMAP4: hwmod: Add remaining hwmod support for OMAP4430 ES1.0 -- v1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26502.html v2 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28334.html v3 Dmitry.Torokhov | Rework in driver code http://www.mail-archive.com/linux-omap@vger.kernel.org/msg29297.html -- [PATCH v3 1/4] OMAP4: Keyboard controller support [PATCH v3 2/4] OMAP4: Keyboard device registration [PATCH v3 3/4] OMAP4: Keyboard board support [PATCH v3 4/4] OMAP4: Keyboard kernel configuration -- arch/arm/configs/omap_4430sdp_defconfig|3 arch/arm/mach-omap2/board-4430sdp.c| 104 + arch/arm/mach-omap2/devices.c | 59 + 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 + 7 files changed, 487 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH v3 1/4] OMAP4: Keyboard controller support
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
arch/arm/plat-omap/include/plat/omap4-keypad.h | 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);
+};
+
+extern int omap4_init_kp(struct omap4_keypad_platform_data *kpd);
+
+#endif
+
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 64c1023..ebeeac4 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -403,6 +403,16 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
+config KEYBOARD_OMAP4
+ tristate TI OMAP4 keypad support
+ depends on ARCH_OMAP4
+ default n
+ help
+ Say Y here if you want to use the OMAP4 keypad.
+
+ To compile this driver as a module, choose M here: the
+ module will be called omap4-keypad.
+
config KEYBOARD_TWL4030
tristate TI TWL4030/TWL5030/TPS659x0 keypad support
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 706c6b5..7e2987e 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_OMAP)+= omap-keypad.o
+obj-$(CONFIG_KEYBOARD_OMAP4) += omap4-keypad.o
obj-$(CONFIG_KEYBOARD_OPENCORES) += opencores-kbd.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o
obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
new file mode 100644
index 000..5e224f2
--- /dev/null
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -0,0 +1,288 @@
+/*
+ * OMAP4 Keypad Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Abraham Arce x0066...@ti.com
+ * Initial Code: Syed Rafiuddin rafiuddin.s...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/errno.h
+#include linux/io.h
+#include linux/input.h
+#include linux/slab.h
+
+#include plat/omap4-keypad.h
+
+/* OMAP4 registers */
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG0x10
+#define OMAP4_KBD_SYSSTATUS0x14
+#define OMAP4_KBD_IRQSTATUS0x18
+#define OMAP4_KBD_IRQENABLE0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS0x40
+#define OMAP4_KBD_FULLCODE31_0
[RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
Register keyboard device with hwmod framework
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/devices.c | 59 +
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..64d68a9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/clk.h
+#include linux/slab.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -26,6 +27,9 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/omap4-keypad.h
#include mux.h
@@ -136,6 +140,61 @@ static inline void omap_init_camera(void)
}
#endif
+#ifdef CONFIG_ARCH_OMAP4
+
+struct omap_device_pm_latency omap_keyboard_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap4_keypad_platform_data *pdata;
+
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
+
+ length = snprintf(oh_name, hw_mod_name_len, kbd);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
+
+ pdata = kzalloc(sizeof(struct omap4_keypad_platform_data), GFP_KERNEL);
+ if (!pdata) {
+ WARN(1, Keyboard pdata memory allocation failed\n);
+ return -ENOMEM;
+ }
+
+ pdata = kp;
+
+ pdata-base = oh-_rt_va;
+ pdata-irq = oh-mpu_irqs[0].irq;
+ pdata-device_enable = omap_device_enable;
+ pdata-device_idle = omap_device_idle;
+ pdata-device_shutdown = omap_device_shutdown;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(struct matrix_keypad_platform_data),
+ omap_keyboard_latency,
+ ARRAY_SIZE(omap_keyboard_latency), 1);
+ WARN(IS_ERR(od), Could not build omap_device for %s %s\n,
+ name, oh_name);
+
+ return 0;
+}
+
+#endif
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#define MBOX_REG_SIZE 0x120
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH v3 3/4] OMAP4: Keyboard board support
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 104 +++
1 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index be7a786..ab6ac99 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -30,6 +30,9 @@
#include plat/control.h
#include plat/timer-gp.h
#include plat/usb.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+#include plat/omap4-keypad.h
#include asm/hardware/gic.h
#include asm/hardware/cache-l2x0.h
@@ -37,6 +40,102 @@
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+static int sdp4430_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(0, 1, KEY_R),
+ KEY(0, 2, KEY_T),
+ KEY(0, 3, KEY_HOME),
+ KEY(0, 4, KEY_F5),
+ KEY(0, 5, KEY_UNKNOWN),
+ KEY(0, 6, KEY_I),
+ KEY(0, 7, KEY_LEFTSHIFT),
+
+ KEY(1, 0, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(1, 2, KEY_G),
+ KEY(1, 3, KEY_SEND),
+ KEY(1, 4, KEY_F6),
+ KEY(1, 5, KEY_UNKNOWN),
+ KEY(1, 6, KEY_K),
+ KEY(1, 7, KEY_ENTER),
+
+ KEY(2, 0, KEY_X),
+ KEY(2, 1, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(2, 3, KEY_END),
+ KEY(2, 4, KEY_F7),
+ KEY(2, 5, KEY_UNKNOWN),
+ KEY(2, 6, KEY_DOT),
+ KEY(2, 7, KEY_CAPSLOCK),
+
+ KEY(3, 0, KEY_Z),
+ KEY(3, 1, KEY_KPPLUS),
+ KEY(3, 2, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(3, 4, KEY_F8),
+ KEY(3, 5, KEY_UNKNOWN),
+ KEY(3, 6, KEY_O),
+ KEY(3, 7, KEY_SPACE),
+
+ KEY(4, 0, KEY_W),
+ KEY(4, 1, KEY_Y),
+ KEY(4, 2, KEY_U),
+ KEY(4, 3, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(4, 5, KEY_UNKNOWN),
+ KEY(4, 6, KEY_L),
+ KEY(4, 7, KEY_LEFT),
+
+ KEY(5, 0, KEY_S),
+ KEY(5, 1, KEY_H),
+ KEY(5, 2, KEY_J),
+ KEY(5, 3, KEY_F3),
+ KEY(5, 4, KEY_F9),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(5, 6, KEY_M),
+ KEY(5, 7, KEY_RIGHT),
+
+ KEY(6, 0, KEY_Q),
+ KEY(6, 1, KEY_A),
+ KEY(6, 2, KEY_N),
+ KEY(6, 3, KEY_BACK),
+ KEY(6, 4, KEY_BACKSPACE),
+ KEY(6, 5, KEY_UNKNOWN),
+ KEY(6, 6, KEY_P),
+ KEY(6, 7, KEY_UP),
+
+ KEY(7, 0, KEY_PROG1),
+ KEY(7, 1, KEY_PROG2),
+ KEY(7, 2, KEY_PROG3),
+ KEY(7, 3, KEY_PROG4),
+ KEY(7, 4, KEY_F4),
+ KEY(7, 5, KEY_UNKNOWN),
+ KEY(7, 6, KEY_OK),
+ KEY(7, 7, KEY_DOWN),
+};
+
+static struct matrix_keymap_data sdp4430_keymap_data = {
+ .keymap = sdp4430_keymap,
+ .keymap_size= ARRAY_SIZE(sdp4430_keymap),
+};
+
+static struct omap4_keypad_platform_data sdp4430_keypad_data = {
+ .keymap_data= sdp4430_keymap_data,
+ .rows = 8,
+ .cols = 8,
+ .device_enable = omap_device_enable,
+ .device_shutdown= omap_device_shutdown,
+ .device_idle= omap_device_idle,
+};
+
+static struct platform_device sdp4430_keypad_device = {
+ .name = omap4-keypad,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_keypad_data,
+ },
+};
+
static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias = ks8851,
@@ -109,6 +208,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_keypad_device,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
@@ -193,6 +293,10 @@ static void __init omap_4430sdp_init(void)
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
+ status = omap4_init_kp(sdp4430_keypad_data);
+ if (status)
+ pr_err(Keypad initialization failed: %d\n, status);
+
status = omap_ethernet_init();
if (status) {
pr_err(Ethernet initialization failed: %d\n, status);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend. 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 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 :) 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
[RFC] [PATCH v3 4/4] OMAP4: Keyboard kernel configuration
From: Syed Rafiuddin rafiuddin.s...@ti.com Update OMAP4430 configuration to enable OMAP4 keyboard driver Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Signed-off-by: Abraham Arce x0066...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index d87a349..b7928d4 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -439,7 +439,8 @@ CONFIG_INPUT_EVDEV=y # # Input Device Drivers # -# CONFIG_INPUT_KEYBOARD is not set +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_OMAP4=y # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. Thanks, 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 Mon, 31 May 2010, James Bottomley wrote: On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote: On Sat, 29 May 2010, James Bottomley wrote: The job of the kernel is to accommodate hardware as best it can ... sometimes it might not be able to, but most of the time it does a pretty good job. The facts are that C states and S states are different and are entered differently. That's an x86'ism which is going away. And that's really completely irrelevant for the mobile device space. Can we please stop trying to fix todays x86 based laptop problems? They are simply not fixable. 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. Those machines can go from idle into S2RAM just fine w/o touching the /sys/power/state S2RAM mechanism. It's just a deeper C state, really. The confusion is that S3 is considered to be a complete different mechanism - which is true for PC style x86 - but not relevant for hardware which is sane from the PM point of view. Now some people think, that suspend blockers are a cure for the existing x86/ACPI/BIOS mess, which cannot go to S3 from idle, but that's simply not feasible. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Monday 31 May 2010, Thomas Gleixner wrote:
On Sat, 29 May 2010, James Bottomley wrote:
On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.
Strange, that's not what I heard as the possible solution. I thought he
was advocating expressing the kernel side of suspend blockers as QoS
constraints. Once we have QoS constraints correctly done in the kernel,
userspace still has to express its requirements. If the requirements
are static, then they can be done from policy files or in some other
static way but if they're dynamic, they'll still have to be in the
applications ... in about the same places the android wakelocks are.
That's wrong. You only need the explicit dynamic QoS constraints for
applications which follow the scheme:
while (1) {
if (event_available())
process_event();
else
do_useless_crap_which_consumes_power();
}
which need the following annotation:
while (1) {
block_suspend();
if (event_available()) {
process_event();
unblock_suspend();
} else {
unblock_suspend();
do_useless_crap_which_consumes_power();
}
}
Plus the kernel counterpart of drivers which take the suspend blocker
in the interrupt handler and release it when the event queue is empty.
So that's done for making polling event handling power efficient.
Even worse, you need the same annotation for non polling mode and it
enforces the use of select() because you cannot take a suspend blocker
across a blocking read() without adding more invasive interactions to
the kernel..
So the sane app looks like:
while (1) {
select();
block_suspend();
process_events();
unblock_suspend();
}
I'm really tired of arguing that this promotion of programming style
is the worst idea ever, so let's look how you can do the same thing
QoS based.
s/block_suspend()/qos(INTERACTIVE)/ and
s/unblock_suspend()/qos(NONE)/ and
s/block_magic()/qos_magic()/ in the drivers.
Yes, it's mostly the same, with a subtle difference:
While android can use it in the big hammer approach to disable the
existing user initiated suspend via /sys/power/state, the rest of the
world can benefit as well in various ways.
- Sane applications which use a blocking event wait can be handled
with a static QoS setting simply because a blocking read relies on
the QoS state of the underlying I/O system.
- Idle based suspend as the logical consequence of idle states is
just a matter of QoS constraint based decisions.
- Untrusted apps can be confined in cgroups. The groups are set to
QoS(None) when user land decides that it's time to safe power
(e.g. screen lock kicks in)
- QoS states can block applications from I/O when the I/O system is
set to a state which is exclusive.
- ...
So that allows to use the same mechanism for more than the android
sledge hammer approach and confines the controversial use cases into
android specific files without adding a hard to maintain user space
interface which would prevent or at least make it hard to do some of
the above mentioned things which we want to see implemented.
I generally agree.
I think the Alan Stern's recent proposal goes along these lines, but it has
the advantage of being a bit more specific. ;-)
Thanks,
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 Tue, 1 Jun 2010, Rafael J. Wysocki wrote: On Monday 31 May 2010, Thomas Gleixner wrote: So that allows to use the same mechanism for more than the android sledge hammer approach and confines the controversial use cases into android specific files without adding a hard to maintain user space interface which would prevent or at least make it hard to do some of the above mentioned things which we want to see implemented. I generally agree. I think the Alan Stern's recent proposal goes along these lines, but it has the advantage of being a bit more specific. ;-) Yes, Alan Stern's proposal is going into that direction and I'm not opposed. Just wanted to get the overall picture straight for James :) 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 00:05:19 +0200 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. I did. See next line in my original. ... by which I mean that they will not be seen until some other event effects a wake-up. By seen I mean a user-space process has had a chance to react to the event, including having the opportunity to abort the suspend (or ensure an immediate wake-up). Another way of saying it might be that the event - as an abstract concept - does not reach it's final destination promptly. This final destination may be well outside the kernel. 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). Yes, a suspend-toggle switch is inherently racy. It is only wake-up sources that are not inherently racy that are interesting. e.g. a serial line from a GSM device which reports You have an SMS message. I want to be able to turn my freerunner upside-down by which I tell it (via the accelerometers) that I am done and want it to turn off. If a TXT message comes in just then, I don't want it to suspend, I want it to make an alert noise. I can put code in to ignore the accelerometer if a txt has just recently come in, but if the TXT arrives just as the write to /sys/power/state starts, the UART interrupt handler could have completed before it has the PRE_SUSPEND method called. So the suspend will complete and the wakeup from the UART will have been lost in that the event didn't get all the way to its destination: my ear. 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. Thanks, NeilBrown 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
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, 2010-05-31 at 23:41 +0200, Thomas Gleixner wrote:
On Sat, 29 May 2010, James Bottomley wrote:
On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.
Strange, that's not what I heard as the possible solution. I thought he
was advocating expressing the kernel side of suspend blockers as QoS
constraints. Once we have QoS constraints correctly done in the kernel,
userspace still has to express its requirements. If the requirements
are static, then they can be done from policy files or in some other
static way but if they're dynamic, they'll still have to be in the
applications ... in about the same places the android wakelocks are.
That's wrong. You only need the explicit dynamic QoS constraints for
applications which follow the scheme:
while (1) {
if (event_available())
process_event();
else
do_useless_crap_which_consumes_power();
}
which need the following annotation:
while (1) {
block_suspend();
if (event_available()) {
process_event();
unblock_suspend();
} else {
unblock_suspend();
do_useless_crap_which_consumes_power();
}
}
Plus the kernel counterpart of drivers which take the suspend blocker
in the interrupt handler and release it when the event queue is empty.
So that's done for making polling event handling power efficient.
Even worse, you need the same annotation for non polling mode and it
enforces the use of select() because you cannot take a suspend blocker
across a blocking read() without adding more invasive interactions to
the kernel..
So the sane app looks like:
while (1) {
select();
block_suspend();
process_events();
unblock_suspend();
}
I'm really tired of arguing that this promotion of programming style
is the worst idea ever, so let's look how you can do the same thing
QoS based.
s/block_suspend()/qos(INTERACTIVE)/ and
s/unblock_suspend()/qos(NONE)/ and
s/block_magic()/qos_magic()/ in the drivers.
So this is the re-expression in terms of a QoS API that I mentioned ...
as I said, I think it's the way forwards. (from the android point of
view, it keeps the user space expression in exactly the same place as
the original wake locks, or suspend blocks, which is why it looks like a
rename to them).
Yes, it's mostly the same, with a subtle difference:
While android can use it in the big hammer approach to disable the
existing user initiated suspend via /sys/power/state, the rest of the
world can benefit as well in various ways.
- Sane applications which use a blocking event wait can be handled
with a static QoS setting simply because a blocking read relies on
the QoS state of the underlying I/O system.
- Idle based suspend as the logical consequence of idle states is
just a matter of QoS constraint based decisions.
- Untrusted apps can be confined in cgroups. The groups are set to
QoS(None) when user land decides that it's time to safe power
(e.g. screen lock kicks in)
- QoS states can block applications from I/O when the I/O system is
set to a state which is exclusive.
- ...
I understand this ... it's effectively the alan stern approach. I've
already said that looks like the way forwards.
So that allows to use the same mechanism for more than the android
sledge hammer approach and confines the controversial use cases into
android specific files without adding a hard to maintain user space
interface which would prevent or at least make it hard to do some of
the above mentioned things which we want to see implemented.
Yes, which is why I think something like this can be made to work ... I
don't really see that we differ on the broad brush picture. As long as
the acceptable implementation accomplishes what everyone wants, I think
we're home.
James
While I personally disagree with the android approach, I REALLY want
to provide them a mechanism to make it work, but not for the price
that it actively prevents solutions which are considered to be
technically superior by a relevant group of developers/maintainers.
You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.
I don't think anyone disagrees with this. As long as we find a long term
solution that satisfies the android case, everyone will be happy.
See above.
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
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tuesday 01 June 2010, Neil Brown wrote: On Tue, 1 Jun 2010 00:05:19 +0200 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. I did. See next line in my original. ... by which I mean that they will not be seen until some other event effects a wake-up. OK, sorry. By seen I mean a user-space process has had a chance to react to the event, including having the opportunity to abort the suspend (or ensure an immediate wake-up). Another way of saying it might be that the event - as an abstract concept - does not reach it's final destination promptly. This final destination may be well outside the kernel. 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). Yes, a suspend-toggle switch is inherently racy. For this reason we generally have to assume that some events occuring during suspend will only be seen by user space after resume. Now, since we make such an assumption anyway, there's a little point working around some races related to it while leaving the others as they are (that wouldn't improve things all that much). It is only wake-up sources that are not inherently racy that are interesting. e.g. a serial line from a GSM device which reports You have an SMS message. I want to be able to turn my freerunner upside-down by which I tell it (via the accelerometers) that I am done and want it to turn off. If a TXT message comes in just then, I don't want it to suspend, I want it to make an alert noise. I can put code in to ignore the accelerometer if a txt has just recently come in, but if the TXT arrives just as the write to /sys/power/state starts, the UART interrupt handler could have completed before it has the PRE_SUSPEND method called. So the suspend will complete and the wakeup from the UART will have been lost in that the event didn't get all the way to its destination: my ear. 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
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, Neil Brown wrote: 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). It can be closed, when the state transition from normal event delivery to wakeup mode is state safe, which it is on most platforms which are designed for the mobile space. Not so the current PC style x86 platforms, which are not relevant for the problem at hand at all. Really, that stuff is going either to gain sane properties or it's just going into the irrelevant realm. Any attempt to solve the current x86/ACPI/BIOS/mess is waste of time and is inevitably going to prevent progress. If you really want _all_ events to be delivered timely, the only way to go is to avoid using suspend (and use the idle framework for power management). Amen. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 02:32:20 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Tuesday 01 June 2010, Neil Brown wrote: I want to be able to turn my freerunner upside-down by which I tell it (via the accelerometers) that I am done and want it to turn off. If a TXT message comes in just then, I don't want it to suspend, I want it to make an alert noise. I can put code in to ignore the accelerometer if a txt has just recently come in, but if the TXT arrives just as the write to /sys/power/state starts, the UART interrupt handler could have completed before it has the PRE_SUSPEND method called. So the suspend will complete and the wakeup from the UART will have been lost in that the event didn't get all the way to its destination: my ear. 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? But if the event comes in as a level-triggered (or latched) interrupt, then the driver simply chooses not to acknowledge the interrupt after PRE_SUSPEND until RESUME. Then any suspend would immediately be woken. Maybe the window for ignoring interrupt would have to be a bit smaller than that, but it should be a well defined window that can be locked. Why cannot we carry this sort of guarantee all the way up to user-space and beyond? Am I completely misunderstanding the hardware? And if you are right that the race window cannot be closed, then the whole suspend-blocker infrastructure is pointless as the purpose of it is simply to close that window. If it really does not and cannot work, then it would be best to reject it for that reason rather than for less concrete aesthetic arguments. But presumably it does work in practice on Android hardware so . confused. Having just seen the email from Thomas, maybe you mean that it cannot be closed on devices using ACPI, but can on other devices. I can sort-of imagine how that would be the case (I tried reading an ACPI spec once - my hat is of to those of you who understand it). That shouldn't prevent us from closing the race window on sane hardware that allows it. This would, I think, be sufficient for Android's needs. I'm hoping we can get agreement on: - there is a race with suspend - it can be closed on the sort of hardware that is typically used in the mobile space - closing it would address the need which lead to the suspend-block proposal. If we have agreement on that, we can move on to - should we close the race? (hopefully yes because bugs should be fixed). - how should we close the race? (lots of room for exploration there). Thanks, NeilBrown -- To unsubscribe from this list: send the line unsubscribe 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: And if you are right that the race window cannot be closed, then the whole suspend-blocker infrastructure is pointless as the purpose of it is simply to close that window. If it really does not and cannot work, then it would be best to reject it for that reason rather than for less concrete aesthetic arguments. But presumably it does work in practice on Android hardware so . confused. Having just seen the email from Thomas, maybe you mean that it cannot be closed on devices using ACPI, but can on other devices. I can sort-of imagine how that would be the case (I tried reading an ACPI spec once - my hat is of to those of you who understand it). That shouldn't prevent us from closing the race window on sane hardware that allows it. This would, I think, be sufficient for Android's needs. I'm hoping we can get agreement on: - there is a race with suspend That's a matter of how you define suspend. If suspend is another deep idle state and the hardware is sane, there is no race at all - assumed that the driver/platform developer got it right. It's not rocket science to transition from normal irq delivery to wakeup based delivery raceless (except for PC style x86 hardware of today) If suspend is the thing we are used to via /sys/power/state then the race will persist forever except for the suspend blocker workaround, which we can express in QoS terms as well w/o adding another suspend related user space API. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. And if you are right that the race window cannot be closed, then the whole suspend-blocker infrastructure is pointless as the purpose of it is simply to close that window. If it really does not and cannot work, then it would be best to reject it for that reason rather than for less concrete aesthetic arguments. But presumably it does work in practice on Android hardware so . confused. The point you're missing is that Android works with regard to wakeup events. It doesn't necessarily always receive non-wakeup events (although I don't know how Android classifies events -- maybe everything is a wakeup event for them). 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 03:49:37 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Tue, 1 Jun 2010, Neil Brown wrote: And if you are right that the race window cannot be closed, then the whole suspend-blocker infrastructure is pointless as the purpose of it is simply to close that window. If it really does not and cannot work, then it would be best to reject it for that reason rather than for less concrete aesthetic arguments. But presumably it does work in practice on Android hardware so . confused. Having just seen the email from Thomas, maybe you mean that it cannot be closed on devices using ACPI, but can on other devices. I can sort-of imagine how that would be the case (I tried reading an ACPI spec once - my hat is of to those of you who understand it). That shouldn't prevent us from closing the race window on sane hardware that allows it. This would, I think, be sufficient for Android's needs. I'm hoping we can get agreement on: - there is a race with suspend That's a matter of how you define suspend. I define suspend as echo mem /sys/power/state If suspend is another deep idle state and the hardware is sane, there is no race at all - assumed that the driver/platform developer got it right. It's not rocket science to transition from normal irq delivery to wakeup based delivery raceless (except for PC style x86 hardware of today) If suspend is the thing we are used to via /sys/power/state then the race will persist forever except for the suspend blocker workaround, which we can express in QoS terms as well w/o adding another suspend related user space API. I'm not interested in adding another user-space API if it can possibly be avoided, and I think it can. But that is a later step in the process. 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 you agree that it is appropriate for try to fix this bug, then the next step would be to get the Android devs to agree that a fix could - in principle - address the need for which they created suspend-blockers. Arve: can you confirm that? Then, with a clear and agreed goal, we can look at possible fixes. Thanks, NeilBrown 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, 31 May 2010 22:10:00 -0400 (EDT) Alan Stern st...@rowland.harvard.edu 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. I am only thinking of wakeup event. (And I am only thinking of suspend as initiated by writing 'mem' to /sys/power/state.) I agree that non-wakeup events can easily be delayed by suspend, and this is by design and no-one wants it to change. 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. 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. And if you are right that the race window cannot be closed, then the whole suspend-blocker infrastructure is pointless as the purpose of it is simply to close that window. If it really does not and cannot work, then it would be best to reject it for that reason rather than for less concrete aesthetic arguments. But presumably it does work in practice on Android hardware so . confused. The point you're missing is that Android works with regard to wakeup events. It doesn't necessarily always receive non-wakeup events (although I don't know how Android classifies events -- maybe everything is a wakeup event for them). 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. A UART asserts 'data ready' which is routed to an IO interrupt line that wakes the device. This is a wakeup event. 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 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. Thanks, NeilBrown -- To unsubscribe from this list: send the line unsubscribe 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 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
+ 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.
+ 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.
--
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: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Mon, May 31, 2010 at 11:44:52PM +0200, ext Arce, Abraham wrote: + pdata = kzalloc(sizeof(struct omap4_keypad_platform_data), GFP_KERNEL); you will never free this. [..] + pdata-device_enable = omap_device_enable; this is undefined at least here or previous patch. + pdata-device_idle = omap_device_idle; same for this + pdata-device_shutdown = omap_device_shutdown; and this. -- 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: [RFC] [PATCH v3 3/4] OMAP4: Keyboard board support
On Mon, May 31, 2010 at 11:45:39PM +0200, ext Arce, Abraham wrote:
+static struct omap4_keypad_platform_data sdp4430_keypad_data = {
+ .keymap_data= sdp4430_keymap_data,
+ .rows = 8,
+ .cols = 8,
+ .device_enable = omap_device_enable,
+ .device_shutdown= omap_device_shutdown,
+ .device_idle= omap_device_idle,
again all three are undefined
--
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: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
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 ?? -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend. -- 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)
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. Even if you may loose key events while suspending I think it is still valuable to have reliable alarms. I gave an example earlier why reliable alarms are useful (dvr application). -- 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)
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. -- 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
[PATCH 7/8] omap iommu: move iommu_disable at fault to the above layer
The function prefix omap2_iommu_ indicates that the prefixed
function belongs to omap2_iommu_ops to provide iommu basic
functionalities for the above layers. It's better to avoid the
prefixed function called in the same prefixed ones internally, like
nested here. Now iommu_disable is called just after fault_isr() in
the above layer. This is a little bit more sensible to keep the
consistency of module layers.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/iommu2.c |2 +-
arch/arm/plat-omap/iommu.c |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index edf7cd4..14ee686 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -172,7 +172,7 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
printk(\n);
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
- omap2_iommu_disable(obj);
+
return stat;
}
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 688ae66..a202a2c 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -800,6 +800,8 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!stat)
return IRQ_HANDLED;
+ iommu_disable(obj);
+
iopgd = iopgd_offset(obj, da);
if (!iopgd_is_table(*iopgd)) {
--
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 2/8] omap iommu: Introduce iopgd_is_table MACRO
A bit more strict comparison.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iommu.c |8
arch/arm/plat-omap/iopgtable.h |2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index bc094db..341c481 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -653,7 +653,7 @@ void iopgtable_lookup_entry(struct iommu *obj, u32 da, u32
**ppgd, u32 **ppte)
if (!*iopgd)
goto out;
- if (*iopgd IOPGD_TABLE)
+ if (iopgd_is_table(*iopgd))
iopte = iopte_offset(iopgd, da);
out:
*ppgd = iopgd;
@@ -670,7 +670,7 @@ static size_t iopgtable_clear_entry_core(struct iommu *obj,
u32 da)
if (!*iopgd)
return 0;
- if (*iopgd IOPGD_TABLE) {
+ if (iopgd_is_table(*iopgd)) {
int i;
u32 *iopte = iopte_offset(iopgd, da);
@@ -745,7 +745,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
if (!*iopgd)
continue;
- if (*iopgd IOPGD_TABLE)
+ if (iopgd_is_table(*iopgd))
iopte_free(iopte_offset(iopgd, 0));
*iopgd = 0;
@@ -785,7 +785,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
iopgd = iopgd_offset(obj, da);
- if (!(*iopgd IOPGD_TABLE)) {
+ if (!iopgd_is_table(*iopgd)) {
dev_err(obj-dev, %s: da:%08x pgd:%p *pgd:%08x\n, __func__,
da, iopgd, *iopgd);
return IRQ_NONE;
diff --git a/arch/arm/plat-omap/iopgtable.h b/arch/arm/plat-omap/iopgtable.h
index ab23b6a..f2e6b64 100644
--- a/arch/arm/plat-omap/iopgtable.h
+++ b/arch/arm/plat-omap/iopgtable.h
@@ -63,6 +63,8 @@
#define IOPGD_SECTION (2 0)
#define IOPGD_SUPER(1 18 | 2 0)
+#define iopgd_is_table(x) (((x) 3) == IOPGD_TABLE)
+
#define IOPTE_SMALL(2 0)
#define IOPTE_LARGE(1 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 4/8] omap iommu: Fix Memory leak
From: Satish x0124...@ti.com
The memory allocated for sgt structure is not freed on error
when sg_alloc_table is called in sgtable_alloc().
Signed-off-by: Satish Kumar x0124...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: vimal singh vimal.neww...@gmail.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index e43983b..8ce0de2 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -140,8 +140,10 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags)
return ERR_PTR(-ENOMEM);
err = sg_alloc_table(sgt, nr_entries, GFP_KERNEL);
- if (err)
+ if (err) {
+ kfree(sgt);
return ERR_PTR(err);
+ }
pr_debug(%s: sgt:%p(%d entries)\n, __func__, sgt, nr_entries);
--
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 5/8] omap iommu: update irq mask to be specific about twl and tlb
From: Kanigeri, Hari h-kanige...@ti.com Revise the IRQ mask definitions to handle the MMU faults related to TWL fault as well as TLB miss fault. Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/mach-omap2/iommu2.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index e82da68..ebbdae2 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -44,9 +44,13 @@ #define MMU_IRQ_EMUMISS(1 2) #define MMU_IRQ_TRANSLATIONFAULT (1 1) #define MMU_IRQ_TLBMISS(1 0) -#define MMU_IRQ_MASK \ - (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \ -MMU_IRQ_TRANSLATIONFAULT) + +#define __MMU_IRQ_FAULT\ + (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_EMUMISS | MMU_IRQ_TRANSLATIONFAULT) +#define MMU_IRQ_MASK \ + (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_TLBMISS) +#define MMU_IRQ_TWL_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT) +#define MMU_IRQ_TLB_MISS_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TLBMISS) /* MMU_CNTL */ #define MMU_CNTL_SHIFT 1 @@ -96,7 +100,7 @@ static int omap2_iommu_enable(struct iommu *obj) l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE); iommu_write_reg(obj, l, MMU_SYSCONFIG); - iommu_write_reg(obj, MMU_IRQ_MASK, MMU_IRQENABLE); + iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE); iommu_write_reg(obj, pa, MMU_TTB); l = iommu_read_reg(obj, MMU_CNTL); -- 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 8/8] omap iommu: Make omap-iommu.o built-in
This is a platform device registration. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/mach-omap2/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ea52b03..6c6d7c6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -89,7 +89,10 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o mailbox_mach-objs := mailbox.o -obj-$(CONFIG_OMAP_IOMMU) := iommu2.o omap-iommu.o +obj-$(CONFIG_OMAP_IOMMU) += iommu2.o + +iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o +obj-y += $(iommu-m) $(iommu-y) i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o obj-y += $(i2c-omap-m) $(i2c-omap-y) -- 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 1/8] omap iommu: update ducati mmu irq define name
From: Kanigeri, Hari h-kanige...@ti.com
2.6.34-rc6 kernel has the Ducati mmu irq define name changed, which is
resulting in compilation error.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index eb9bee7..f5a1aad 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -59,7 +59,7 @@ static struct platform_device
*omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
static struct iommu_device omap4_devices[] = {
{
.base = OMAP4_MMU1_BASE,
- .irq = INT_44XX_DUCATI_MMU_IRQ,
+ .irq = OMAP44XX_IRQ_DUCATI_MMU,
.pdata = {
.name = ducati,
.nr_tlb_entries = 32,
--
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 3/8] omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr
Follow Linux pagetable accessor name convention. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/iopgtable.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/iopgtable.h b/arch/arm/plat-omap/iopgtable.h index f2e6b64..c3e93bb 100644 --- a/arch/arm/plat-omap/iopgtable.h +++ b/arch/arm/plat-omap/iopgtable.h @@ -72,12 +72,12 @@ #define iopgd_index(da)(((da) IOPGD_SHIFT) (PTRS_PER_IOPGD - 1)) #define iopgd_offset(obj, da) ((obj)-iopgd + iopgd_index(da)) -#define iopte_paddr(iopgd) (*iopgd ~((1 10) - 1)) -#define iopte_vaddr(iopgd) ((u32 *)phys_to_virt(iopte_paddr(iopgd))) +#define iopgd_page_paddr(iopgd)(*iopgd ~((1 10) - 1)) +#define iopgd_page_vaddr(iopgd)((u32 *)phys_to_virt(iopgd_page_paddr(iopgd))) /* to find an entry in the second-level page table. */ #define iopte_index(da)(((da) IOPTE_SHIFT) (PTRS_PER_IOPTE - 1)) -#define iopte_offset(iopgd, da)(iopte_vaddr(iopgd) + iopte_index(da)) +#define iopte_offset(iopgd, da)(iopgd_page_vaddr(iopgd) + iopte_index(da)) static inline u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa, u32 flags) -- 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 6/8] omap iommu: add functionality to get TLB miss interrupt
From: Kanigeri, Hari h-kanige...@ti.com
In order to enable TLB miss interrupt, the TWL should be
disabled. This patch provides the functionality to get the
MMU fault interrupt for a TLB miss in the cases where the
users are working with the locked TLB entries and with TWL
disabled.
New interface is added to select twl and to enable TLB miss
interrupt.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/iommu2.c| 32 ++
arch/arm/plat-omap/include/plat/iommu.h |2 +
arch/arm/plat-omap/iommu.c | 17
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index ebbdae2..edf7cd4 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -65,6 +65,26 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+
+static void __iommu_set_twl(struct iommu *obj, bool on)
+{
+ u32 l = iommu_read_reg(obj, MMU_CNTL);
+
+ if (on)
+ iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ else
+ iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+
+ l = ~MMU_CNTL_MASK;
+ if (on)
+ l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
+ else
+ l |= (MMU_CNTL_MMU_EN);
+
+ iommu_write_reg(obj, l, MMU_CNTL);
+}
+
+
static int omap2_iommu_enable(struct iommu *obj)
{
u32 l, pa;
@@ -100,13 +120,9 @@ static int omap2_iommu_enable(struct iommu *obj)
l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
iommu_write_reg(obj, l, MMU_SYSCONFIG);
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
iommu_write_reg(obj, pa, MMU_TTB);
- l = iommu_read_reg(obj, MMU_CNTL);
- l = ~MMU_CNTL_MASK;
- l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
- iommu_write_reg(obj, l, MMU_CNTL);
+ __iommu_set_twl(obj, true);
return 0;
}
@@ -122,6 +138,11 @@ static void omap2_iommu_disable(struct iommu *obj)
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
+static void omap2_iommu_set_twl(struct iommu *obj, bool on)
+{
+ __iommu_set_twl(obj, false);
+}
+
static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
{
int i;
@@ -304,6 +325,7 @@ static const struct iommu_functions omap2_iommu_ops = {
.enable = omap2_iommu_enable,
.disable= omap2_iommu_disable,
+ .set_twl= omap2_iommu_set_twl,
.fault_isr = omap2_iommu_fault_isr,
.tlb_read_cr= omap2_tlb_read_cr,
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0752af9..33c7d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -80,6 +80,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
+ void (*set_twl)(struct iommu *obj, bool on);
u32 (*fault_isr)(struct iommu *obj, u32 *ra);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -143,6 +144,7 @@ extern void iotlb_cr_to_e(struct cr_regs *cr, struct
iotlb_entry *e);
extern u32 iotlb_cr_to_virt(struct cr_regs *cr);
extern int load_iotlb_entry(struct iommu *obj, struct iotlb_entry *e);
+extern void iommu_set_twl(struct iommu *obj, bool on);
extern void flush_iotlb_page(struct iommu *obj, u32 da);
extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
extern void flush_iotlb_all(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 341c481..688ae66 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -370,6 +370,23 @@ void flush_iotlb_all(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(flush_iotlb_all);
+/**
+ * iommu_set_twl - enable/disable table walking logic
+ * @obj: target iommu
+ * @on:enable/disable
+ *
+ * Function used to enable/disable TWL. If one wants to work
+ * exclusively with locked TLB entries and receive notifications
+ * for TLB miss then call this function to disable TWL.
+ */
+void iommu_set_twl(struct iommu *obj, bool on)
+{
+ clk_enable(obj-clk);
+ arch_iommu-set_twl(obj, on);
+ clk_disable(obj-clk);
+}
+EXPORT_SYMBOL_GPL(iommu_set_twl);
+
#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
--
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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On Tue, Jun 1, 2010 at 12:48 AM, Nishanth Menon n...@ti.com wrote: On 05/31/2010 09:46 PM, S, Venkatraman wrote: I understand that you might not have all platforms to test with, but let's not provide a 'generic feature api' without it being available for the supported platforms. It's incomplete without it. well.. if you did read 0/6 http://marc.info/?l=linux-omapm=127458581708411w=2 Caveat: this series just introduces the framework by reorganizing the existing data, it does not attempt to define what the features for OMAP1,2,3,4 would be. As usual, comments are welcome. I did see this. My point was the 6/6 claims to do $foo (where $foo= make it generic) doesn't fit with a caveat description (My patch doesn't do $foo) :) anyways, these are how the three follow on patches will look like (sample omap1,2,4 patches are attached), feel free to ack them after testing - but this patch 6/6 needs to be done prior to the remaining being added - that is one more reason why i stopped where I did. 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 -- To unsubscribe from this list: send the line unsubscribe 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 12:20:12 +1000 Neil Brown ne...@suse.de wrote: On Tue, 1 Jun 2010 03:49:37 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: If suspend is another deep idle state and the hardware is sane, there is no race at all - assumed that the driver/platform developer got it right. It's not rocket science to transition from normal irq delivery to wakeup based delivery raceless (except for PC style x86 hardware of today) If suspend is the thing we are used to via /sys/power/state then the race will persist forever except for the suspend blocker workaround, which we can express in QoS terms as well w/o adding another suspend related user space API. Can you explain the difference between the /sys/power/state thing? Is it the reprogramming of wake-sources as mentioned by Raffael? In an idle based suspend I assume there would be no new wake-sources on suspending. I'm not interested in adding another user-space API if it can possibly be avoided, and I think it can. But that is a later step in the process. 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... Well as far as I get it, the workaround is to not suspend in sitations where a race is likely to occur. (I.e. block suspend) 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 you agree that it is appropriate for try to fix this bug, then the next step would be to get the Android devs to agree that a fix could - in principle - address the need for which they created suspend-blockers. Arve: can you confirm that? Then, with a clear and agreed goal, we can look at possible fixes. Thanks, NeilBrown Thanks, tglx cheers, Flo -- To unsubscribe from this list: send the line unsubscribe 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
Hello Tony, can you please add these patches? Or is something to change? Thomas Am 18.05.2010 14:05, schrieb Thomas Weber: Some of these patches were submitted earlier but got no comments so I am sending them one more time. These patches correct errors that were done while using the board code from beagle board for Devkit8000. The Devkit8000 uses the TPS65930, an reduced version of the TWL4030. So not all power supplies from the TWL4030 are available. There were also a wrong comment about the pins supported by the vmmc1. The DSS2 do not need a VDVI any longer so it is removed. The definition of the supplies are changed to use the new REGULATOR_SUPPLY macro. The pins for lcd and dvi powerdown are corrected. Kan-Ru Chen (1): OMAP2: Devkit8000: Setup LCD reset Thomas Weber (13): OMAP2: Devkit8000: Cleanup for supplies OMAP2: Devkit8000: change lcd panel to generic OMAP2: Devkit8000: Enable DVI-D output OMAP2: Devkit8000: Remove unneeded VDVI OMAP2: Devkit8000: Remove nonexisting vsim OMAP2: Devkit8000: Remove en-/disable for tv panel OMAP2: Devkit8000: Use the REGULATOR_SUPPLY macro OMAP2: Devkit8000: Fixing comment about pins used OMAP2: Devkit8000: Fix whitespace with tab OMAP2: Devkit8000: Fix comment OMAP2: Devkit8000: Using gpio_is_valid OMAP2: Devkit8000: Remove unused omap_board_config OMAP2: Devkit8000: Correct regulator arch/arm/mach-omap2/board-devkit8000.c | 125 +++- 1 files changed, 58 insertions(+), 67 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
