Re: [PATCH] MAINTAINERS: Add list entries linux-...@vger.kernel.org and linux-arm-kernel@ to OMAP sections
* Joe Perches j...@perches.com [090807 18:07]: On Fri, 2009-08-07 at 11:01 +0300, Tony Lindgren wrote: * Joe Perches j...@perches.com [090806 19:35]: Perhaps it's useful for OMAP patches and bug reports to CC entries to the primary and secondary ARM lists. Added a pattern entry for OMAP USB as well. ... I think let's not add the drivers. The related driver list and linux-omap list should be enough for these. Fine by me. I fixed up your M: entry as well. Oh thanks :) Signed-off-by: Joe Perches j...@perches.com Acked-by: Tony Lindgren t...@atomide.com diff --git a/MAINTAINERS b/MAINTAINERS index b1114cf..6a82733 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3660,8 +3660,10 @@ F: drivers/video/riva/ F: drivers/video/nvidia/ OMAP SUPPORT -M: Tony Lindgren t...@atomide.com t...@atomide.com +M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org W: http://www.muru.com/linux/omap/ W: http://linux.omap.com/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git @@ -3671,12 +3673,16 @@ F:arch/arm/*omap* OMAP CLOCK FRAMEWORK SUPPORT M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/*omap*/*clock* OMAP POWER MANAGEMENT SUPPORT M: Kevin Hilman khil...@deeprootsystems.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/*omap*/*pm* -- To unsubscribe from this list: send the line unsubscribe 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
[APPLIED] [PATCH] omap2: compile usb-tusb6010.c
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-upstream Initial commit ID (Likely to change): c3459357f00c2759c4e09ce1440f10eafad0e24c PatchWorks http://patchwork.kernel.org/patch/39916/ 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=c3459357f00c2759c4e09ce1440f10eafad0e24c -- To unsubscribe from this list: send the line unsubscribe 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: PM branch updated
Hi Kevin, On Friday 07 August 2009 19:11:20 Kevin Hilman wrote: Jean Pihet jpi...@mvista.com writes: On Thursday 06 August 2009 19:13:06 Kevin Hilman wrote: Kevin Hilman wrote: I just pushed an updated PM branch which was rebased to current omap/master (which is based on v2.6.31-rc5) Also, please check out http://elinux.org/OMAP_Power_Management This page includes the stuff I normally put in the announcment of a new PM branch, but also tries to describe how to use the various features of the PM branch (which has been sorely missing for a while.) I think this page had been long-awaited. Thanks a lot for putting it together. One question about it: What about the cpufreq interface for doing DVFS? Is it preferred way to change OPPs or is it using /sys/power/vddx_opp? I think cpufreq utils are more standard, easier to use and to understand. CPUfreq is much preferred. The /sys/power/vdd* are just for manual testing and more fore PM developers than PM users. Ok, thanks for the confirmation. Hey, sounds like a perfect opportunity for you to update the wiki. ;) Exactly! http://elinux.org/OMAP_Power_Management has been updated with per-feature usage, CPUfreq kernel interface and debugging info for power users ;p Can you check it? Kevin Jean -- To unsubscribe from this list: send the line unsubscribe 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/3] Enhance ASoC on OMAP1510 by implementing DMA channel linking
Current implementation of ASoC OMAP PCM makes use of DMA channel self linking feature for all machines but OMAP1510. This is caused by channel linking not supported on OMAP1510 in current OMAP DMA implementation. Instead, DMA interrputs are counted as periods, and after all periods in a buffer has been detected, DMA transfer is started again for a new buffer content. The period counter is also used as a software replacement for a hardware DMA progress counter that has been found unusable on OMAP1510 in case of playback. In my attempts to debug random PCM hangups, I was wondering what could happen if a single interrupt was missing, ie. the period index was not incremented for a period. It seems that the transfer would just hang after the current buffer processed, as DMA would not be started again, waiting for a missing period. Furthermore, software calculated PCM pointer accuracy can suffer from missing DMA interrupts. Even if OMAP1510 DMA hardware does not support channel linking in a way like newer models do, it has some other features that could be used for the purpose. Interrupt status flags, passed to OMAP PCM interrupt handler routine, can be used to get more accurate DMA progress counter software calculation. Even if these enhancements did not help me in eliminating random PCM hangups completely, I find them worth of sharing. There are three patches in the series: [RFC][PATCH 1/3] ARM: OMAP: DMA: Add support for DMA channel self linking on OMAP1510 [RFC][PATCH 2/3] ASoC: OMAP: Make use of DMA channel self linking on OMAP1510 [RFC][PATCH 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/3] ARM: OMAP: DMA: Add support for DMA channel self linking on OMAP1510
Implement DMA channel self linking on OMAP1510 using AUTO_INIT and REPEAT
flags of the DMA CCR register.
Created against linux-2.6.31-rc5.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Note:
In its current form, enable_lnk() seems not very consistent (ie. result of a
conditional assignment is then overwritten unconditionally). As rather
different from OMAP1510 that I am familiar with, I am not quite sure how
support for other OMAP models should really look like. So I decided to leave
it as is and put my bit in a separate block, adding an additional FIXME
comment.
--- linux-2.6.31-rc5/arch/arm/plat-omap/dma.c.orig 2009-08-07
13:38:02.0 +0200
+++ linux-2.6.31-rc5/arch/arm/plat-omap/dma.c 2009-08-10 09:01:41.0
+0200
@@ -653,8 +653,21 @@ static inline void enable_lnk(int lch)
{
u32 l;
+ if (omap_dma_in_1510_mode()) {
+ /* only self linking is supported */
+ if (dma_chan[lch].next_lch == lch) {
+ /* set AUTO_INIT | REPEAT bits in CCR */
+ l = dma_read(CCR(lch));
+ l |= 3 8;
+ dma_write(l, CCR(lch));
+ }
+ return;
+ }
+
l = dma_read(CLNK_CTRL(lch));
+ /* FIXME:
+* this conditional assignment is then overwritten unconditionally */
if (cpu_class_is_omap1())
l = ~(1 14);
@@ -675,13 +688,21 @@ static inline void disable_lnk(int lch)
{
u32 l;
- l = dma_read(CLNK_CTRL(lch));
+ if (omap_dma_in_1510_mode())
+ l = dma_read(CCR(lch));
+ else
+ l = dma_read(CLNK_CTRL(lch));
/* Disable interrupts */
if (cpu_class_is_omap1()) {
dma_write(0, CICR(lch));
- /* Set the STOP_LNK bit */
- l |= 1 14;
+ if (omap_dma_in_1510_mode()) {
+ /* Unset AUTO_INIT REPEAT bits */
+ l = ~(3 8);
+ } else {
+ /* Set the STOP_LNK bit */
+ l |= 1 14;
+ }
}
if (cpu_class_is_omap2()) {
@@ -690,7 +711,10 @@ static inline void disable_lnk(int lch)
l = ~(1 15);
}
- dma_write(l, CLNK_CTRL(lch));
+ if (omap_dma_in_1510_mode())
+ dma_write(l, CCR(lch));
+ else
+ dma_write(l, CLNK_CTRL(lch));
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
@@ -928,7 +952,7 @@ void omap_start_dma(int lch)
{
u32 l;
- if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
+ if (dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -979,7 +1003,7 @@ void omap_stop_dma(int lch)
{
u32 l;
- if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
+ if (dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -1130,7 +1154,7 @@ int omap_dma_running(void)
*/
void omap_dma_link_lch(int lch_head, int lch_queue)
{
- if (omap_dma_in_1510_mode()) {
+ if (omap_dma_in_1510_mode() (lch_head != lch_queue)) {
printk(KERN_ERR DMA linking is not supported in 1510 mode\n);
BUG();
return;
@@ -1152,7 +1176,7 @@ EXPORT_SYMBOL(omap_dma_link_lch);
*/
void omap_dma_unlink_lch(int lch_head, int lch_queue)
{
- if (omap_dma_in_1510_mode()) {
+ if (omap_dma_in_1510_mode() (lch_head != lch_queue)) {
printk(KERN_ERR DMA linking is not supported in 1510 mode\n);
BUG();
return;
@@ -1822,7 +1846,7 @@ static int omap1_dma_handle_ch(int ch)
if (unlikely(csr OMAP_DMA_DROP_IRQ))
printk(KERN_WARNING DMA synchronization event drop occurred
with device %d\n, dma_chan[ch].dev_id);
- if (likely(csr OMAP_DMA_BLOCK_IRQ))
+ if (likely(csr OMAP_DMA_BLOCK_IRQ) (dma_chan[ch].next_lch != ch))
dma_chan[ch].flags = ~OMAP_DMA_ACTIVE;
if (likely(dma_chan[ch].callback != NULL))
dma_chan[ch].callback(ch, csr, dma_chan[ch].data);
--
To unsubscribe from this list: send the line unsubscribe 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/3] ASoC: OMAP: Make use of DMA channel self linking on OMAP1510
Use newly implemented DMA channel self linking on OMAP1510 like on other OMAP
models. Remove unnecessary DMA transfer restart from interrupt handler
routine.
The interrupt routine used to maintain a period index, originally needed for
counting up periods up to a full buffer in order to restart the DMA transfer.
For some time, this counter is also used as a replacement for hardware DMA
progress counter that has been found unusable on OMAP1510 in case of playback.
Thus, the period index calculation cannot be omitted completely. However, the
accuracy of this counter can still suffer from missing DMA interrupts.
In order to work correctly, it requires patch 1 from this series also applied:
[RFC][PATCH 1/3] ARM: OMAP: DMA: Add support for DMA channel self linking on
OMAP1510
Created against linux-2.6.31-rc5.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c.orig 2009-08-07
13:38:23.0 +0200
+++ linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c 2009-08-10 08:31:08.0
+0200
@@ -59,16 +59,18 @@ static void omap_pcm_dma_irq(int ch, u16
struct omap_runtime_data *prtd = runtime-private_data;
unsigned long flags;
- if (cpu_is_omap1510()) {
+ if ((cpu_is_omap1510())
+ (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)) {
/*
-* OMAP1510 doesn't support DMA chaining so have to restart
-* the transfer after all periods are transferred
+* OMAP1510 doesn't fully support DMA progress counter
+* and there is no software emulation implemented yet,
+* so have to maintain our own playback progress counter
+* that can be used by omap_pcm_pointer() instead.
*/
spin_lock_irqsave(prtd-lock, flags);
if (prtd-period_index = 0) {
if (++prtd-period_index == runtime-periods) {
prtd-period_index = 0;
- omap_start_dma(prtd-dma_ch);
}
}
spin_unlock_irqrestore(prtd-lock, flags);
@@ -100,7 +102,7 @@ static int omap_pcm_hw_params(struct snd
prtd-dma_data = dma_data;
err = omap_request_dma(dma_data-dma_req, dma_data-name,
omap_pcm_dma_irq, substream, prtd-dma_ch);
- if (!err !cpu_is_omap1510()) {
+ if (!err) {
/*
* Link channel with itself so DMA doesn't need any
* reprogramming while looping the buffer
@@ -119,8 +121,7 @@ static int omap_pcm_hw_free(struct snd_p
if (prtd-dma_data == NULL)
return 0;
- if (!cpu_is_omap1510())
- omap_dma_unlink_lch(prtd-dma_ch, prtd-dma_ch);
+ omap_dma_unlink_lch(prtd-dma_ch, prtd-dma_ch);
omap_free_dma(prtd-dma_ch);
prtd-dma_data = NULL;
--
To unsubscribe from this list: send the line unsubscribe 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/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
Enhance period index accuracy, particularly just before buffer rewind, by
making use of DMA interrupt status flags in addition to simply counting
interrupts
This patch applies on top of patch 2 from this series:
[RFC][PATCH 2/3] ASoC: OMAP: Make use of DMA channel self linking on OMAP1510
Created against linux-2.6.31-rc5.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c.orig 2009-08-10
08:31:08.0 +0200
+++ linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c 2009-08-10 08:55:09.0
+0200
@@ -68,13 +68,28 @@ static void omap_pcm_dma_irq(int ch, u16
* that can be used by omap_pcm_pointer() instead.
*/
spin_lock_irqsave(prtd-lock, flags);
- if (prtd-period_index = 0) {
- if (++prtd-period_index == runtime-periods) {
+ if (stat OMAP_DMA_LAST_IRQ) {
+ /* last period of a buffer has been started */
+ if (prtd-period_index == (runtime-periods - 1)) {
+ /* we are in sync, do nothing */
+ spin_unlock_irqrestore(prtd-lock, flags);
+ return;
+ } else if (prtd-period_index = 0) {
+ /* possible IRQ loss, update the pointer */
+ prtd-period_index = runtime-periods - 1;
+ }
+ } else if (prtd-period_index = 0) {
+ /* playback in progress - increment the counter,
+* check for end of buffer */
+ if ((++prtd-period_index = runtime-periods) ||
+ (stat OMAP_DMA_BLOCK_IRQ)) {
+ /* end of buffer reached, loop back */
prtd-period_index = 0;
}
}
spin_unlock_irqrestore(prtd-lock, flags);
- }
+ } else if (stat OMAP_DMA_LAST_IRQ)
+ return;
snd_pcm_period_elapsed(substream);
}
@@ -175,7 +190,8 @@ static int omap_pcm_prepare(struct snd_p
dma_params.frame_count = runtime-periods;
omap_set_dma_params(prtd-dma_ch, dma_params);
- omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ);
+ omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ |
+ (cpu_is_omap1510() ? OMAP_DMA_LAST_IRQ : 0));
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe 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 16/20] ASoC: OMAP: Use McBSP threshold again
Hi Jarkko,
On Wed, Aug 05, 2009 at 09:48:56AM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:39 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
Now this patch implements again the McBSP threshold
usage for OMAP ASoC.
We figured out that there is no need to have so much
SW control in order to have DMA in idle state during
audio streaming. Configuring McBSP threshold value
and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-pcm.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
@@ -192,6 +203,12 @@ static int omap_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
prtd-period_index = 0;
+ /* Configure McBSP internal buffer usage */
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ omap_mcbsp_set_tx_threshold(bus_id, samples - 1);
+ else
+ omap_mcbsp_set_rx_threshold(bus_id, samples - 1);
+
omap_start_dma(prtd-dma_ch);
break;
Oops, didn't notice this before. This will hard glue the DMA and McBSP
together. Even currently there is only McBSP based DAI link driver,
there can be others as well. EAC DAI for OMAP2420 would be necessary
for instance if one wants to develop ASoC support for Nokia N800. Nokia
N810 could use that too.
True. And the same comment is valid for the patch which adds op mode selection.
My idea to un-glue them is to put some callbacks in omap_mcbsp_data of
omap-mcbsp.c,
and share it as something more generic, so that they can be called from
omap-pcm.c.
Something like:
struct omap_dma_data {
unsigned intbus_id;
unsigned intfmt;
/*
* Flags indicating is the bus already activated and configured by
* another substream
*/
int active;
int configured;
/* threshold callbacks can be added then here */
void*data; /* struct omap_mcbsp_reg_cfg
regs; can go here */
};
And this goes in omap-pcm.h.
what do you think??
--
Jarkko
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP1: AMS_DELTA: add modem support
Jonathan, Tony,
Any chance for this patch ready for 2.6.32 inclusion? Or maybe v2, that has no
external dependencies and can be updated later to v3 when Vikram's changes
get accepted upstream?
Thanks,
Janusz
Monday 06 July 2009 12:24:27 Janusz Krzysztofik wrote:
This patch adds support for modem device found on Amstrad E3 (Delta) board.
Based on earlier patch by Jonathan McDowell, available at
http://the.earth.li/pub/e3/2.6.19/ams-delta-modem.patch.
Modified after Ladislav Michl's arch/arm/mach-omap1/board-voiceblue.c.
This version, unlike v2, is dependent on 8250 driver changes getting
accepted upstream:
Refer: http://patchwork.kernel.org/patch/31884/
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Registering the modem platform device from a separate arch_initcall (and
not from init_machine() callback) preserves serial console port at ttyS0.
OMAP mux pin set up just for case if Amstrad bootloader is ever replaced.
Warning:
could cause compilation break if 8250 patch is not integrated first
--- linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c.orig
2009-07-04
16:39:37.0 +0200 +++
linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c2009-07-05
13:41:08.0 +0200 @@ -15,8 +15,11 @@
#include linux/kernel.h
#include linux/init.h
#include linux/input.h
+#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/serial_8250.h
+#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -235,6 +238,41 @@ static void __init ams_delta_init(void)
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
}
+static struct plat_serial8250_port ams_delta_modem_ports[] = {
+ {
+ .membase= (void *) AMS_DELTA_MODEM_VIRT,
+ .mapbase= AMS_DELTA_MODEM_PHYS,
+ .irq= -EINVAL, /* changed later */
+ .flags = UPF_BOOT_AUTOCONF,
+ .irqflags = IRQF_TRIGGER_RISING,
+ .iotype = UPIO_MEM,
+ .regshift = 1,
+ .uartclk= BASE_BAUD * 16,
+ },
+ { },
+};
+
+static struct platform_device ams_delta_modem_device = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = ams_delta_modem_ports,
+ },
+};
+
+static int __init ams_delta_modem_init(void)
+{
+ omap_cfg_reg(M14_1510_GPIO2);
+ ams_delta_modem_ports[0].irq = gpio_to_irq(2);
+
+ ams_delta_latch2_write(
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+
+ return platform_device_register(ams_delta_modem_device);
+}
+arch_initcall(ams_delta_modem_init);
+
static void __init ams_delta_map_io(void)
{
omap1_map_common_io();
--
To unsubscribe from this list: send the line unsubscribe 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 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
Monday 10 August 2009 10:50:06 Janusz Krzysztofik wrote: Enhance period index accuracy, particularly just before buffer rewind, by making use of DMA interrupt status flags in addition to simply counting interrupts Sorry, this one is still buggy an can break other OMAP models. Please, do not apply, but wait for next version. However, comments are welcome. The bug hits when multiple interrupt flags are set in parallel. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe 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: Audio on OMAP3
On Sun, Aug 09, 2009 at 02:34:18PM -0600, Gary Thomas wrote: Thanks. How is this normally configured - ALSA or OSS? It's all ALSA. There is some OSS emulation for ALSA. What tools have been used (simple busybox system, not Android)? It's all standard ALSA stuff from the point of view of userspace. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP1: AMS_DELTA: add modem support
On Mon, Aug 10, 2009 at 11:12:48AM +0200, Janusz Krzysztofik wrote:
Jonathan, Tony,
Any chance for this patch ready for 2.6.32 inclusion? Or maybe v2,
that has no external dependencies and can be updated later to v3 when
Vikram's changes get accepted upstream?
Vikram's patch is in linux-next, so there shouldn't be a problem with
this version of your patch for 2.6.32. I haven't been able to test it
myself (though I hope to next week), but it looks ok from a brief
inspection, so:
Acked-By: Jonathan McDowell nood...@earth.li
Monday 06 July 2009 12:24:27 Janusz Krzysztofik wrote:
This patch adds support for modem device found on Amstrad E3 (Delta) board.
Based on earlier patch by Jonathan McDowell, available at
http://the.earth.li/pub/e3/2.6.19/ams-delta-modem.patch.
Modified after Ladislav Michl's arch/arm/mach-omap1/board-voiceblue.c.
This version, unlike v2, is dependent on 8250 driver changes getting
accepted upstream:
Refer: http://patchwork.kernel.org/patch/31884/
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Registering the modem platform device from a separate arch_initcall (and
not from init_machine() callback) preserves serial console port at ttyS0.
OMAP mux pin set up just for case if Amstrad bootloader is ever replaced.
Warning:
could cause compilation break if 8250 patch is not integrated first
--- linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c.orig
2009-07-04
16:39:37.0 +0200 +++
linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c 2009-07-05
13:41:08.0 +0200 @@ -15,8 +15,11 @@
#include linux/kernel.h
#include linux/init.h
#include linux/input.h
+#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/serial_8250.h
+#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -235,6 +238,41 @@ static void __init ams_delta_init(void)
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
}
+static struct plat_serial8250_port ams_delta_modem_ports[] = {
+ {
+ .membase= (void *) AMS_DELTA_MODEM_VIRT,
+ .mapbase= AMS_DELTA_MODEM_PHYS,
+ .irq= -EINVAL, /* changed later */
+ .flags = UPF_BOOT_AUTOCONF,
+ .irqflags = IRQF_TRIGGER_RISING,
+ .iotype = UPIO_MEM,
+ .regshift = 1,
+ .uartclk= BASE_BAUD * 16,
+ },
+ { },
+};
+
+static struct platform_device ams_delta_modem_device = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = ams_delta_modem_ports,
+ },
+};
+
+static int __init ams_delta_modem_init(void)
+{
+ omap_cfg_reg(M14_1510_GPIO2);
+ ams_delta_modem_ports[0].irq = gpio_to_irq(2);
+
+ ams_delta_latch2_write(
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+
+ return platform_device_register(ams_delta_modem_device);
+}
+arch_initcall(ams_delta_modem_init);
+
static void __init ams_delta_map_io(void)
{
omap1_map_common_io();
J.
--
Revd. Jonathan McDowell, ULC | I am a passenger.
--
To unsubscribe from this list: send the line unsubscribe 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] Fixed processing of bootarg 'mpurate'
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 06, 2009 8:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] Fixed processing of bootarg 'mpurate'
Sanjeev Premi pr...@ti.com writes:
The argument 'mpurate' had no effect on the MPU
frequency. This patch fixes the same.
It also ensures that DSP frequency is set according
to the OPP definitions.
Signed-off-by: Sanjeev Premi pr...@ti.com
Can you break this into two patches. One that simply fixes the MPU
rate setting bug and that applies against linux-omap master and
can be queued for omap-fixes.
Created a patch on l-o master against the commit:
4baadee : OMAP3: EHCI: Allow EHCI to work as a module again
The DSP rate setting is a separate problem and could be done in
a patch against the PM branch.
Based on the patch for mpurate, a created another one for setting
the dsp frequency against pm branch:
70a1f22 : OMAP3: PM: USBHOST: clear wakeup events on both hosts
Both patches follow this mail.
Best regards,
Sanjeev
Kevin
---
arch/arm/mach-omap2/clock34xx.c | 57
+++---
1 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index c2e5ef8..a9e7e82 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -29,6 +29,7 @@
#include linux/err.h
#include linux/cpufreq.h
+#include mach/cpu.h
#include mach/clock.h
#include mach/sram.h
#include mach/omap-pm.h
@@ -42,6 +43,7 @@
#include prm-regbits-34xx.h
#include cm.h
#include cm-regbits-34xx.h
+#include omap3-opp.h
static const struct clkops clkops_noncore_dpll_ops;
@@ -1083,6 +1085,11 @@ void omap2_clk_prepare_for_reboot(void)
*/
static int __init omap2_clk_arch_init(void)
{
+ unsigned short opp=0;
+ unsigned short i;
+ unsigned long dsprate;
+ struct omap_opp *opp_table;
+
if (!mpurate)
return -EINVAL;
@@ -1092,12 +1099,49 @@ static int __init omap2_clk_arch_init(void)
printk(KERN_ERR Could not find matching MPU rate\n);
#endif
+ if (clk_set_rate(dpll1_ck, mpurate))
+ printk(KERN_ERR *** Unable to set MPU rate\n);
+ omap3_dpll_recalc(dpll1_ck);
+
+ /* Get the OPP corresponding to the mpurate */
+ if (mpu_opps) {
+ opp_table = mpu_opps;
+
+ for (i=0; opp_table[i].opp_id = MAX_VDD1_OPP; i++)
+ if (opp_table[i].rate == mpurate)
+ break;
+
+ opp = opp_table[i].opp_id;
+
+ pr_debug(Switched to OPP:%d\n, opp);
+ }
+
+ /* Get dsprate corresponding to the opp */
+ if ((dsp_opps) (opp = VDD1_OPP1) (opp = VDD1_OPP5)) {
+ opp_table = dsp_opps;
+
+ for (i=0; opp_table[i].opp_id = MAX_VDD1_OPP; i++)
+ if (opp_table[i].opp_id == opp)
+ break;
+
+ dsprate = opp_table[i].rate;
+
+ if (clk_set_rate(dpll2_ck, dsprate))
+ printk(KERN_ERR *** Unable to set IVA2
rate\n);
+ omap3_dpll_recalc(dpll2_ck);
+ }
+
recalculate_root_clocks();
- printk(KERN_INFO Switched to new clocking rate
(Crystal/DPLL3/MPU):
+ printk(KERN_INFO Switched to new clocking rate
(Crystal/Core/MPU):
%ld.%01ld/%ld/%ld MHz\n,
- (osc_sys_ck.rate / 100), (osc_sys_ck.rate /
10) % 10,
- (core_ck.rate / 100), (dpll1_fck.rate / 100)) ;
+ (osc_sys_ck.rate / 100), ((osc_sys_ck.rate /
10) % 10),
+ (core_ck.rate / 100), (dpll1_ck.rate / 100)) ;
+
+ printk(KERN_INFO IVA2 clocking rate: %ld MHz\n,
+ (dpll2_ck.rate / 100)) ;
+
+ calibrate_delay();
return 0;
}
@@ -1156,10 +1200,13 @@ int __init omap2_clk_init(void)
recalculate_root_clocks();
- printk(KERN_INFO Clocking rate (Crystal/DPLL/ARM core):
+ printk(KERN_INFO Clocking rate (Crystal/DPLL/MPU core):
%ld.%01ld/%ld/%ld MHz\n,
(osc_sys_ck.rate / 100), (osc_sys_ck.rate /
10) % 10,
- (core_ck.rate / 100), (arm_fck.rate / 100));
+ (core_ck.rate / 100), (dpll1_ck.rate /
100));
+
+ printk(KERN_INFO IVA2 clocking rate: %ld MHz\n,
+ (dpll2_ck.rate / 100)) ;
/*
* Only enable those clocks we will need, let the drivers
--
1.6.2.2
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH] Fixed processing of bootarg 'mpurate'
The argument 'mpurate' had no effect on the MPU frequency. This patch fixes the same. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/clock34xx.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 045da92..0c62aad 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -27,6 +27,7 @@ #include linux/limits.h #include linux/bitops.h +#include mach/cpu.h #include mach/clock.h #include mach/sram.h #include asm/div64.h @@ -948,13 +949,18 @@ static int __init omap2_clk_arch_init(void) if (clk_set_rate(virt_prcm_set, mpurate)) printk(KERN_ERR Could not find matching MPU rate\n); #endif + if (clk_set_rate(dpll1_ck, mpurate)) + printk(KERN_ERR *** Unable to set MPU rate\n); + omap3_dpll_recalc(dpll1_ck); recalculate_root_clocks(); - printk(KERN_INFO Switched to new clocking rate (Crystal/DPLL3/MPU): + printk(KERN_INFO Switched to new clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, - (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, - (core_ck.rate / 100), (dpll1_fck.rate / 100)) ; + (osc_sys_ck.rate / 100), ((osc_sys_ck.rate / 10) % 10), + (core_ck.rate / 100), (arm_fck.rate / 100)) ; + + calibrate_delay(); return 0; } @@ -1013,7 +1019,7 @@ int __init omap2_clk_init(void) recalculate_root_clocks(); - printk(KERN_INFO Clocking rate (Crystal/DPLL/ARM core): + printk(KERN_INFO Clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, (core_ck.rate / 100), (arm_fck.rate / 100)); -- 1.6.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs
gpio_get() should return DATAIN register value when the GPIO
is configured as input whereas it should return DATAOUT register
value when the GPIO is configured as output.
Now /sys/kernel/debug/gpio shows proper values for output GPIOs
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/plat-omap/gpio.c | 121 +
1 files changed, 89 insertions(+), 32 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 26b387c..9c16ca8 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -476,14 +476,12 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int
gpio, int enable)
__raw_writel(l, reg);
}
-static int __omap_get_gpio_datain(int gpio)
+static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
- struct gpio_bank *bank;
void __iomem *reg;
if (check_gpio(gpio) 0)
return -EINVAL;
- bank = get_gpio_bank(gpio);
reg = bank-base;
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP1
@@ -524,6 +522,53 @@ static int __omap_get_gpio_datain(int gpio)
(1 get_gpio_index(gpio))) != 0;
}
+static int _get_gpio_dataout(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg;
+
+ if (check_gpio(gpio) 0)
+ return -EINVAL;
+ reg = bank-base;
+
+ switch (bank-method) {
+#ifdef CONFIG_ARCH_OMAP1
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP15XX
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP16XX
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DATAOUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP730
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP850
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
+ defined(CONFIG_ARCH_OMAP4)
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_DATAOUT;
+ break;
+#endif
+ default:
+ return -EINVAL;
+ }
+
+ return (__raw_readl(reg) (1 get_gpio_index(gpio))) != 0;
+}
+
#define MOD_REG_BIT(reg, bit_mask, set)\
do { \
int l = __raw_readl(base + reg); \
@@ -1350,9 +1395,49 @@ static int gpio_input(struct gpio_chip *chip, unsigned
offset)
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base;
+
+ switch (bank-method) {
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_IO_CNTL;
+ break;
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DIRECTION;
+ break;
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_OE;
+ break;
+ }
+ return __raw_readl(reg) mask;
+}
+
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return __omap_get_gpio_datain(chip-base + offset);
+ struct gpio_bank *bank;
+ void __iomem *reg;
+ int gpio;
+ u32 mask;
+
+ gpio = chip-base + offset;
+ bank = get_gpio_bank(gpio);
+ reg = bank-base;
+ mask = 1 get_gpio_index(gpio);
+
+ if (gpio_is_input(bank, mask))
+ return _get_gpio_datain(bank, gpio);
+ else
+ return _get_gpio_dataout(bank, gpio);
}
static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
@@ -1886,34 +1971,6 @@ arch_initcall(omap_gpio_sysinit);
#include linux/debugfs.h
#include linux/seq_file.h
-static int gpio_is_input(struct gpio_bank *bank, int mask)
-{
- void __iomem *reg = bank-base;
-
- switch (bank-method) {
- case METHOD_MPUIO:
- reg += OMAP_MPUIO_IO_CNTL;
- break;
- case METHOD_GPIO_1510:
- reg += OMAP1510_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_1610:
- reg += OMAP1610_GPIO_DIRECTION;
- break;
- case METHOD_GPIO_730:
- reg += OMAP730_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_850:
- reg += OMAP850_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_24XX:
- reg += OMAP24XX_GPIO_OE;
- break;
- }
- return __raw_readl(reg) mask;
-}
-
-
static int dbg_gpio_show(struct
[PATCH 0/2] omap3 beagle patches
Two patches that make linux-omap boot on beagle board again Felipe Balbi (2): arm: omap: beagle: add missing twl4030 usb platform_data arm: omap: beagle: update defconfig arch/arm/configs/omap3_beagle_defconfig | 357 --- arch/arm/mach-omap2/board-omap3beagle.c |5 + 2 files changed, 238 insertions(+), 124 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] arm: omap: beagle: add missing twl4030 usb platform_data
without it twl4030_usb driver will not probe.
Reported-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/board-omap3beagle.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index b6a68d5..f9f011f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -249,11 +249,16 @@ static struct regulator_init_data beagle_vpll2 = {
.consumer_supplies = beagle_vdvi_supply,
};
+static struct twl4030_usb_data beagle_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
static struct twl4030_platform_data beagle_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
+ .usb= beag_usb_data,
.gpio = beagle_gpio_data,
.vmmc1 = beagle_vmmc1,
.vsim = beagle_vsim,
--
1.6.3.3.385.g60647
--
To unsubscribe from this list: send the line unsubscribe 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/2] arm: omap: beagle: update defconfig
enable pm, twl4030-core, twl4030-regulator, twl4030-usb and
put musb into otg mode.
Without all of this, current l-o will oops on beagle board with a null
pointer dereference as shown below:
3musb_hdrc musb_hdrc: musb_init_controller failed with status -19
1Unable to handle kernel NULL pointer dereference at virtual address 0028
1pgd = c0004000
1[0028] *pgd=
Internal error: Oops: 5 [#1]
dModules linked in:
CPU: 0Not tainted (2.6.31-rc5-omap1-05833-g4baadee-dirty #44)
PC is at musb_platform_suspend+0x34/0x78
LR is at musb_platform_exit+0xc/0x20
pc : [c01e0e84]lr : [c01e0ed4]psr: a013
sp : c7819e00 ip : 0064 fp :
r10: r9 : c782b150 r8 : c03814a0
r7 : c788ac20 r6 : c782b0d0 r5 : c782b0d0 r4 : c782b0d0
r3 : d80ab000 r2 : 0004 r1 : c0318df1 r0 :
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc78182e8)
Stack: (0xc7819e00 to 0xc781a000)
9e00: c782b0d0 c01e0ed4 c01dfbac ffed c782b0d0 c001a5d0
9e20: 0001 c7819e5c 0003 c03658d8 c03658e0 005c d80ab000
9e40: c03658bc c782b000 c039365c c7819ea4 c0165420 c780e7a8
9e60: c0165420 005f c780e7a8 c00d6fa8 c785c788 c0275d78
9e80: c7819ec0 c788c8a8 c00d775c c788c8a8 c00d7378 c788c908 c788c8a8
9ea0: c7819ec0 c00d7450 c7819ec0 c788c8a8 c785c788 0001 c00d81cc
9ec0: c785c788 c03658e0 c03658e0 c0383a84 c788ac20 c03814a0
9ee0: c01aa234 c03658e0 c01a94d8 c03658e0 c0365914
9f00: c0383a84 c788ac20 c03814a0 c01a95e4 c01a9584 c0383a84 c01a8e00
9f20: c78034d8 c7841290 c0020440 c0383a68 c0383a84 c01a8720 c028f04c c028f04c
9f40: 0001 c0020440 c0383a68 c0383a84 c0019904 c01a98b4
9f60: c0020440 c0383a68 c0019904 c01aa69c c0020440
9f80: c002529c c7819fb4 c02f76b8 8124 024e c036fe00 c78400a0
9fa0: c036fef0 015f c03912c0 c00d197c c02f76b8 c7841680 c7819fc6 c006f0a4
9fc0: 35333f60 0031 0180 c0020440
9fe0: c0008574 c0026cd0 003bef00 0267fe20
[c01e0e84] (musb_platform_suspend+0x34/0x78) from [c01e0ed4]
(musb_platform_exit+0xc/0x20)
[c01e0ed4] (musb_platform_exit+0xc/0x20) from [c01dfbac]
(musb_free+0x94/0xd8)
[c01dfbac] (musb_free+0x94/0xd8) from [c001a5d0] (musb_probe+0xb2c/0xc24)
[c001a5d0] (musb_probe+0xb2c/0xc24) from [c01aa234]
(platform_drv_probe+0x18/0x1c)
[c01aa234] (platform_drv_probe+0x18/0x1c) from [c01a94d8]
(driver_probe_device+0xa0/0x14c)
[c01a94d8] (driver_probe_device+0xa0/0x14c) from [c01a95e4]
(__driver_attach+0x60/0x84)
[c01a95e4] (__driver_attach+0x60/0x84) from [c01a8e00]
(bus_for_each_dev+0x44/0x74)
[c01a8e00] (bus_for_each_dev+0x44/0x74) from [c01a8720]
(bus_add_driver+0x9c/0x214)
[c01a8720] (bus_add_driver+0x9c/0x214) from [c01a98b4]
(driver_register+0xa8/0x130)
[c01a98b4] (driver_register+0xa8/0x130) from [c01aa69c]
(platform_driver_probe+0x10/0x60)
[c01aa69c] (platform_driver_probe+0x10/0x60) from [c002529c]
(do_one_initcall+0x54/0x194)
[c002529c] (do_one_initcall+0x54/0x194) from [c0008574]
(kernel_init+0x8c/0x108)
[c0008574] (kernel_init+0x8c/0x108) from [c0026cd0]
(kernel_thread_exit+0x0/0x8)
Code: e5932404 e3822004 e5832404 e5900074 (e5903028)
4---[ end trace 1b75b31a2719ed1c ]---
by using gdb we can see that's the otg pointer from otg_set_suspend() as
shown below:
(gdb) l *(musb_platform_suspend + 0x34)
0xc01e27bc is in musb_platform_suspend (include/linux/usb/otg.h:128).
123
124 /* Context: can sleep */
125 static inline int
126 otg_set_suspend(struct otg_transceiver *otg, int suspend)
127 {
128 if (otg-set_suspend != NULL)
129 return otg-set_suspend(otg, suspend);
130 else
131 return 0;
132 }
Fix this problem by enabling all the necessary drivers on the defconfig.
Reported-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/configs/omap3_beagle_defconfig | 357 ---
1 files changed, 233 insertions(+), 124 deletions(-)
diff --git a/arch/arm/configs/omap3_beagle_defconfig
b/arch/arm/configs/omap3_beagle_defconfig
index c4726f0..40574b6 100644
--- a/arch/arm/configs/omap3_beagle_defconfig
+++ b/arch/arm/configs/omap3_beagle_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.27-rc8
-# Wed Oct 1 17:14:22 2008
+# Linux kernel version: 2.6.31-rc1-omap1
+# Mon Aug 10 13:54:06 2009
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -9,7 +9,6 @@ CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
-# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
Re: [PATCH][OMAP]: Adding flash devices support back for OMAP3430 SDP boards
Adding Linux-Omap mailing list too...
-vimal
Adding flash devices support back for OMAP3430 SDP boards.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
mach-omap2/Makefile |1
mach-omap2/board-3430sdp-flash.c | 267
+++
mach-omap2/board-3430sdp.c |3
plat-omap/include/mach/gpmc.h|2
4 files changed, 273 insertions(+)
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-om
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \
+board-3430sdp-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_NOKIA_N800)+= board-n800.o \
board-n800-mmc.o \
--- a/arch/arm/plat-omap/include/mach/gpmc.h
+++ b/arch/arm/plat-omap/include/mach/gpmc.h
@@ -27,6 +27,8 @@
#define GPMC_CONFIG 0x50
#define GPMC_STATUS 0x54
+#define GPMC_CS0_BASE0x60
+#define GPMC_CS_SIZE 0x30
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -54,6 +54,8 @@
#define TWL4030_MSECURE_GPIO 22
+extern void sdp3430_flash_init(void);
+
static int sdp3430_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -492,6 +494,7 @@ static void __init omap_3430sdp_init(voi
spi_register_board_info(sdp3430_spi_board_info,
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
+ sdp3430_flash_init();
omap_serial_init();
usb_musb_init();
board_smc91x_init();
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3430sdp-flash.c
@@ -0,0 +1,267 @@
+/*
+ * linux/arch/arm/mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (c) 2007 Texas Instruments
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author: Rohit Choraria rohi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mtd/onenand_regs.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include mach/onenand.h
+#include mach/board.h
+#include mach/gpmc.h
+#include mach/nand.h
+
+#define NAND_BLOCK_SIZESZ_128K
+
+/* NAND */
+/* IMPORTANT NOTE ON MAPPING
+ * 3430SDP - 34XX
+ * --
+ * NOR always on 0x0400 for SDPV1
+ * NOR always on 0x1000 for SDPV2
+ * MPDB always on 0x0800
+ * NAND always on 0x0C00
+ * OneNand Mapped to 0x2000
+ * Boot Mode(NAND/NOR). The other on CS1
+ */
+#define FLASH_BASE_SDPV1 0x0400 /* NOR flash (64 Meg aligned) */
+#define FLASH_BASE_SDPV2 0x1000 /* NOR flash (256 Meg aligned) */
+#define DEBUG_BASE 0x0800 /* debug board */
+#define NAND_BASE 0x0C00 /* NAND flash */
+#define ONENAND_MAP0x2000 /* OneNand flash */
+
+/* various memory sizes */
+#define FLASH_SIZE_SDPV1 SZ_64M
+#define FLASH_SIZE_SDPV2 SZ_128M
+
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags
[PATCH 1.5/5] OMAP: Fix testing of cpu defines for mach-omap1
Looks like this is needed before the 2/5 patch for DMA workaround patch to keep compile working on mach-omap1 machines. Regards, Tony From f60e4730feab2b3d0101d059534123e04fc26862 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 10 Aug 2009 14:04:15 +0300 Subject: [PATCH] OMAP: Fix testing of cpu defines for mach-omap1 There's no need to keep these defines limited in the ifdef block for mach-omap2. It will just cause problems testing for the CPU revision in the common code, like the next patch does for the DMA errata. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 285eaa3..11e73d9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -378,9 +378,6 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ cpu_is_omap44xx()) -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \ - defined(CONFIG_ARCH_OMAP4) - /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 #define OMAP2420_REV_ES1_0 0x24200024 @@ -436,5 +433,3 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); - -#endif/* defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) */
Re: [PATCH v3] OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs
* Roger Quadros ext-roger.quad...@nokia.com [090810 14:45]:
gpio_get() should return DATAIN register value when the GPIO
is configured as input whereas it should return DATAOUT register
value when the GPIO is configured as output.
Now /sys/kernel/debug/gpio shows proper values for output GPIOs
Thanks, will update my omap-fixes queue with this.
Tony
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/plat-omap/gpio.c | 121
+
1 files changed, 89 insertions(+), 32 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 26b387c..9c16ca8 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -476,14 +476,12 @@ static void _set_gpio_dataout(struct gpio_bank *bank,
int gpio, int enable)
__raw_writel(l, reg);
}
-static int __omap_get_gpio_datain(int gpio)
+static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
- struct gpio_bank *bank;
void __iomem *reg;
if (check_gpio(gpio) 0)
return -EINVAL;
- bank = get_gpio_bank(gpio);
reg = bank-base;
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP1
@@ -524,6 +522,53 @@ static int __omap_get_gpio_datain(int gpio)
(1 get_gpio_index(gpio))) != 0;
}
+static int _get_gpio_dataout(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg;
+
+ if (check_gpio(gpio) 0)
+ return -EINVAL;
+ reg = bank-base;
+
+ switch (bank-method) {
+#ifdef CONFIG_ARCH_OMAP1
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP15XX
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP16XX
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DATAOUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP730
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP850
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
+ defined(CONFIG_ARCH_OMAP4)
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_DATAOUT;
+ break;
+#endif
+ default:
+ return -EINVAL;
+ }
+
+ return (__raw_readl(reg) (1 get_gpio_index(gpio))) != 0;
+}
+
#define MOD_REG_BIT(reg, bit_mask, set) \
do { \
int l = __raw_readl(base + reg); \
@@ -1350,9 +1395,49 @@ static int gpio_input(struct gpio_chip *chip, unsigned
offset)
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base;
+
+ switch (bank-method) {
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_IO_CNTL;
+ break;
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DIRECTION;
+ break;
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_OE;
+ break;
+ }
+ return __raw_readl(reg) mask;
+}
+
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return __omap_get_gpio_datain(chip-base + offset);
+ struct gpio_bank *bank;
+ void __iomem *reg;
+ int gpio;
+ u32 mask;
+
+ gpio = chip-base + offset;
+ bank = get_gpio_bank(gpio);
+ reg = bank-base;
+ mask = 1 get_gpio_index(gpio);
+
+ if (gpio_is_input(bank, mask))
+ return _get_gpio_datain(bank, gpio);
+ else
+ return _get_gpio_dataout(bank, gpio);
}
static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
@@ -1886,34 +1971,6 @@ arch_initcall(omap_gpio_sysinit);
#include linux/debugfs.h
#include linux/seq_file.h
-static int gpio_is_input(struct gpio_bank *bank, int mask)
-{
- void __iomem *reg = bank-base;
-
- switch (bank-method) {
- case METHOD_MPUIO:
- reg += OMAP_MPUIO_IO_CNTL;
- break;
- case METHOD_GPIO_1510:
- reg += OMAP1510_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_1610:
- reg += OMAP1610_GPIO_DIRECTION;
- break;
- case METHOD_GPIO_730:
- reg += OMAP730_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_850:
- reg += OMAP850_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_24XX:
- reg += OMAP24XX_GPIO_OE;
-
Re: [PATCH 2/2] arm: omap: beagle: update defconfig
Hello Felipe, I was about to ack your patches. But just one question? On Mon, Aug 10, 2009 at 01:48:59PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: +# # I2C GPIO expanders: # # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set +# CONFIG_GPIO_TWL4030 is not set Can you also enable CONFIG_GPIO_TWL4030 ?? So we can use CONFIG_MMC_OMAP_HS in beagle without problems. I think enabling mmc by default is also worth. -- 1.6.3.3.385.g60647 -- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs, v3
Here's an update from Roger for this one that builds without
CONFIG_DEBUG_FS.
Tony
From b37c45b8c27c049dc44673e40fd63820fd9a9d91 Mon Sep 17 00:00:00 2001
From: Roger Quadros ext-roger.quad...@nokia.com
Date: Wed, 5 Aug 2009 16:53:24 +0300
Subject: [PATCH] OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs
gpio_get() should return DATAIN register value when the GPIO
is configured as input whereas it should return DATAOUT register
value when the GPIO is configured as output.
Now /sys/kernel/debug/gpio shows proper values for output GPIOs
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 26b387c..9c16ca8 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -476,14 +476,12 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
__raw_writel(l, reg);
}
-static int __omap_get_gpio_datain(int gpio)
+static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
- struct gpio_bank *bank;
void __iomem *reg;
if (check_gpio(gpio) 0)
return -EINVAL;
- bank = get_gpio_bank(gpio);
reg = bank-base;
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP1
@@ -524,6 +522,53 @@ static int __omap_get_gpio_datain(int gpio)
(1 get_gpio_index(gpio))) != 0;
}
+static int _get_gpio_dataout(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg;
+
+ if (check_gpio(gpio) 0)
+ return -EINVAL;
+ reg = bank-base;
+
+ switch (bank-method) {
+#ifdef CONFIG_ARCH_OMAP1
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP15XX
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP16XX
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DATAOUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP730
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP850
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
+ defined(CONFIG_ARCH_OMAP4)
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_DATAOUT;
+ break;
+#endif
+ default:
+ return -EINVAL;
+ }
+
+ return (__raw_readl(reg) (1 get_gpio_index(gpio))) != 0;
+}
+
#define MOD_REG_BIT(reg, bit_mask, set) \
do { \
int l = __raw_readl(base + reg); \
@@ -1350,9 +1395,49 @@ static int gpio_input(struct gpio_chip *chip, unsigned offset)
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base;
+
+ switch (bank-method) {
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_IO_CNTL;
+ break;
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DIRECTION;
+ break;
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DIR_CONTROL;
+ break;
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_OE;
+ break;
+ }
+ return __raw_readl(reg) mask;
+}
+
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return __omap_get_gpio_datain(chip-base + offset);
+ struct gpio_bank *bank;
+ void __iomem *reg;
+ int gpio;
+ u32 mask;
+
+ gpio = chip-base + offset;
+ bank = get_gpio_bank(gpio);
+ reg = bank-base;
+ mask = 1 get_gpio_index(gpio);
+
+ if (gpio_is_input(bank, mask))
+ return _get_gpio_datain(bank, gpio);
+ else
+ return _get_gpio_dataout(bank, gpio);
}
static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
@@ -1886,34 +1971,6 @@ arch_initcall(omap_gpio_sysinit);
#include linux/debugfs.h
#include linux/seq_file.h
-static int gpio_is_input(struct gpio_bank *bank, int mask)
-{
- void __iomem *reg = bank-base;
-
- switch (bank-method) {
- case METHOD_MPUIO:
- reg += OMAP_MPUIO_IO_CNTL;
- break;
- case METHOD_GPIO_1510:
- reg += OMAP1510_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_1610:
- reg += OMAP1610_GPIO_DIRECTION;
- break;
- case METHOD_GPIO_730:
- reg += OMAP730_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_850:
- reg += OMAP850_GPIO_DIR_CONTROL;
- break;
- case METHOD_GPIO_24XX:
- reg += OMAP24XX_GPIO_OE;
- break;
- }
- return __raw_readl(reg) mask;
-}
-
-
static int dbg_gpio_show(struct seq_file *s, void *unused)
{
unsigned i, j, gpio;
Git pull request for omap fixes for 2.6.31, v2
* Tony Lindgren t...@atomide.com [090807 12:14]: * Russell King - ARM Linux li...@arm.linux.org.uk [090807 12:06]: On Fri, Aug 07, 2009 at 12:01:48PM +0300, Tony Lindgren wrote: Here's the pull request for you. I'll hold off merging this for a bit - I've sent Linus two pull requests over the last couple of weeks, both of which so far haven't produced a reaction. It would be unfair for me to merge more stuff onto that branch until Linus has pulled. OK thanks. Looks like I did not test this series enough.. I've updated it now for the two patches as posted here earlier today. Updated pull request below. Regards, Tony The following changes since commit ed680c4ad478d0fee9740f7d029087f181346564: Linus Torvalds (1): Linux 2.6.31-rc5 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Janboe Ye (1): OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size Roger Quadros (4): OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs OMAP3: RX51: Define TWL4030 USB transceiver in board file OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up OMAP3: RX51: Updated rx51_defconfig Sergio Aguirre (1): OMAP3: Overo: Fix smsc911x platform device resource value Tony Lindgren (1): OMAP: Fix testing of cpu defines for mach-omap1 Vikram Pandita (1): OMAP2/3: DMA errata correction arch/arm/configs/rx51_defconfig |7 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |5 + arch/arm/mach-omap2/mmc-twl4030.c|6 ++ arch/arm/plat-omap/dma.c |4 +- arch/arm/plat-omap/gpio.c| 121 +++--- arch/arm/plat-omap/include/mach/cpu.h|5 - arch/arm/plat-omap/sram.c|4 +- 8 files changed, 110 insertions(+), 44 deletions(-)
Re: Audio on OMAP3
Mark Brown wrote: On Sun, Aug 09, 2009 at 02:34:18PM -0600, Gary Thomas wrote: Thanks. How is this normally configured - ALSA or OSS? It's all ALSA. There is some OSS emulation for ALSA. Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and I got this: Advanced Linux Sound Architecture Driver Version 1.0.20. Platform driver 'soc-audio' needs updating - please use dev_pm_ops No device for DAI AD73311 Asahi Kasei AK4104 ALSA SoC Codec Driver No device for DAI AK4535 Cirrus Logic CS4270 ALSA SoC Codec Driver No device for DAI PCM3008 HiFi No device for DAI SSM2602 No device for DAI tlv320aic23 No device for DAI tlv320aic3x No device for DAI twl4030 No device for DAI twl4030 Voice No device for DAI UDA134X No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI WM8510 HiFi No device for DAI WM8728 No device for DAI WM8750 No device for DAI WM8971 No device for DAI WM8990 ADC/DAC Primary ALSA device list: No soundcards found. Is there more configury/setup required, beyond just enabling the drivers? Is there an example board that uses this? Is the code in the mainline linux-omap tree? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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: Audio on OMAP3
Gary Thomas wrote: Mark Brown wrote: On Sun, Aug 09, 2009 at 02:34:18PM -0600, Gary Thomas wrote: Thanks. How is this normally configured - ALSA or OSS? It's all ALSA. There is some OSS emulation for ALSA. Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and I got this: Advanced Linux Sound Architecture Driver Version 1.0.20. Platform driver 'soc-audio' needs updating - please use dev_pm_ops No device for DAI AD73311 Asahi Kasei AK4104 ALSA SoC Codec Driver No device for DAI AK4535 Cirrus Logic CS4270 ALSA SoC Codec Driver No device for DAI PCM3008 HiFi No device for DAI SSM2602 No device for DAI tlv320aic23 No device for DAI tlv320aic3x No device for DAI twl4030 No device for DAI twl4030 Voice No device for DAI UDA134X No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI WM8510 HiFi No device for DAI WM8728 No device for DAI WM8750 No device for DAI WM8971 No device for DAI WM8990 ADC/DAC Primary ALSA device list: No soundcards found. Is there more configury/setup required, beyond just enabling the drivers? Is there an example board that uses this? Is the code in the mainline linux-omap tree? I found some in sound/soc/omap/... - trying to understand them now. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote:
Hi,
On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
Someting strange is going on. If I boot with the MUSB-OTG adapter -
thumbdrive plugged in, and then modprobe the driver, it finds the
thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive
multiple times, and each time it is enumerated.
If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the
musb driver, and then plug in the OTG adaptor -thumbdrive, it is not
enumerated.
Any idea why I need the OTG adapter - thumbdrive plugged in at kernel
boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c
what happens. You should have a print about the link status, see if that
is ID.
Then try something like this patch:
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..4bc5b7f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
Felipe,
Thanks for the patch. With the following modified patch (to fit my tree
as my pull was from the Kevin's PM tree, commit
7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm:
diff --exclude CVS -uNr linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c
linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c
--- linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c 2009-08-09
12:52:51.0 -0400
+++ linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c 2009-08-09
03:38:20.0 -0400
@@ -250,6 +250,8 @@
};
struct twl4030_usb {
+ /* used for driving or not vbus */
+ struct work_struct vbus_work;
struct otg_transceiver otg;
struct device *dev;
@@ -263,6 +265,7 @@
u8 linkstat;
u8 asleep;
boolirq_enabled;
+booldrive_vbus;
};
/* internal define on top of container_of */
@@ -344,6 +347,18 @@
return twl4030_usb_write(twl, reg + 2, bits);
}
+static void twl4030_vbus_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct
twl4030_usb, vbus_work);
+
+ if (twl-drive_vbus)
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+ else
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+}
+
/*-*/
static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
@@ -374,12 +389,16 @@
if (linkstat == USB_LINK_ID) {
twl-otg.default_a = true;
twl-otg.state = OTG_STATE_A_IDLE;
+ twl-drive_vbus = true;
} else {
twl-otg.default_a = false;
twl-otg.state = OTG_STATE_B_IDLE;
+ twl-drive_vbus = false;
}
spin_unlock_irq(twl-lock);
+ schedule_work(twl-vbus_work);
+
return linkstat;
}
@@ -657,6 +676,8 @@
if (!twl)
return -ENOMEM;
+ INIT_WORK(twl-vbus_work, twl4030_vbus_work);
+
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
twl-otg.dev= twl-dev;
With it I can enumerate my OTG adapter/thumbdrive on insertion.
--
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe 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: Audio on OMAP3
On Mon, Aug 10, 2009 at 07:19:33AM -0600, Gary Thomas wrote: Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and You need to provide a machine-specific driver which tells the McBSP and TWL4030 drivers how they are connected together on your particular board. There are several examples of this for standard reference boards in the OMAP directory - if your audio hardware is based closely enough on one of those then you should be able to just use the same driver. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, August 07, 2009 1:53 PM
To: Kevin Hilman
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
snip--snip
Adding conditionals like
if (omap3_has_iva2())
...
and
if (omap3_has_sgx())
...
rather than having a long list of cpu_is checks that have
to be changed
each time a new SoC comes out.
Agreed.
Tony
Tony, Kevin,
Here is a work in progress patch implementing the conditionals.
I am looking for your suggestions on these:
1) The detection of ES2.0 is different between OMAP3530 and OMAP3430.
For 3430 ES2.0, (idcode 28) == 0x0
For 3530 ES2.0, (idcode 28) == 0x1
What can be easy way to make this distinction?
2) How do we handle the power domain differences between OMAP34x
and the new OMAP3517 and OMAP05 devices. The hawkeye is different,
but, would it make sense to omap_revision to be like:
0x34050034, 0x34170034 - when we reuse the 34xx class.
3) Currently, the macros like OMAP3430_REV_ES1_0 are defined to
be whole numbers. I am trying to change them to something like:
#define OMAP34XX_REV(type,rev) (OMAP34XX_CLASS (type 16) (rev 12))
And use as (if needed):
#define OMAP3430_REV_ES3_1 OMAP34XX_REV(0x30, 0x4)
#define OMAP3403_REV_ES3_1 OMAP34XX_REV(0x03, 0x4)
What is your view?
In fact, wouldn't it be better if we tested for si rev independent
from si type?
4) These macros are, possibly, duplicating the data in omap_revision:
#define CHIP_IS_OMAP3430ES3_0 (1 5)
#define CHIP_IS_OMAP3430ES3_1 (1 6)
But, might be used for faster checking. Is this duplication necessary?
5) Assuming that we are able to maintain current, macros, would this
help in reducing the duplication?
struct omap_id {
u16 id; /* e.g. 0x3430, 0x3517, ... */
u8 class; /* 34x */
u8 subclass; /* 0x30, 0x03, 0x05, 0x15, 0x17 ... */
u8 rev;/* 0x10 (for ES 1.0), 0x21 (for ES2.1) etc. */
/* use nibble as decimal separator */
}
I have tried many approaches, before sending this mail,
so there might be few duplications in the code below.
The cpu_is_35xx() macros are also incomplete for now.
Best regards,
Sanjeev
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..f17d4db 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -25,9 +25,47 @@
#include mach/control.h
#include mach/cpu.h
+#define OMAP3_CONTROL_OMAP_STATUS 0x044c
+
+#define OMAP3_SGX_SHIFT13
+#define OMAP3_SGX_MASK (3 OMAP3_SGX_SHIFT)
+#defineFEAT_SGX_FULL 0
+#defineFEAT_SGX_HALF 1
+#defineFEAT_SGX_NONE 2
+
+#define OMAP3_IVA_SHIFT12
+#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT)
+#defineFEAT_IVA0
+#defineFEAT_IVA_NONE 1
+
+#define OMAP3_L2CACHE_SHIFT10
+#define OMAP3_L2CACHE_MASK (3 OMAP3_L2CACHE_SHIFT)
+#defineFEAT_L2CACHE_0KB0
+#defineFEAT_L2CACHE_64KB 1
+#defineFEAT_L2CACHE_128KB 2
+#defineFEAT_L2CACHE_256KB 3
+
+#define OMAP3_ISP_SHIFT5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#defineFEAT_ISP0
+#defineFEAT_ISP_NONE 1
+
+#define OMAP3_NEON_SHIFT 4
+#define OMAP3_NEON_MASK(1 OMAP3_NEON_SHIFT)
+#defineFEAT_NEON 0
+#defineFEAT_NEON_NONE 1
+
static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
+struct omap_feature {
+ u8 avail;
+ u32 attrib;
+};
+
+static struct omap_feature feat_sgx;
+static struct omap_feature feat_iva;
+static struct omap_feature feat_l2cache;
unsigned int omap_rev(void)
{
@@ -35,6 +73,24 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+unsigned int omap3_has_sgx(void)
+{
+ return feat_sgx.avail;
+}
+EXPORT_SYMBOL(omap3_has_sgx);
+
+unsigned int omap3_has_iva(void)
+{
+ return feat_iva.avail;
+}
+EXPORT_SYMBOL(omap3_has_iva);
+
+unsigned int omap3_has_l2cache(void)
+{
+ return feat_l2cache.avail;
+}
+EXPORT_SYMBOL(omap3_has_l2cache);
+
/**
* omap_chip_is - test whether currently running OMAP matches a chip type
* @oc: omap_chip_t to test against
@@ -155,12 +211,32 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
}
-void __init omap34xx_check_revision(void)
+void __init omap3_check_features(void)
+{
+ u32 status;
+
+ status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
+
+ /* Check for SGX
RE: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
-Original Message-
From: linux-i2c-ow...@vger.kernel.org [mailto:linux-i2c-
ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
Sent: Monday, August 03, 2009 3:20 PM
To: Paul Walmsley
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Menon,
Nishanth; Pandita, Vikram
Subject: RE: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, August 03, 2009 2:36 AM
To: Sonasath, Moiz
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Menon,
Nishanth; Pandita, Vikram
Subject: Re: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
Hello Moiz,
A few remaining comments, most of these from an earlier message.
On Tue, 21 Jul 2009, Sonasath, Moiz wrote:
When an XRDY/XDR is hit, wait for XUDF before writing data to
DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.
Do a Busy-wait for XUDF, before writing data to DATA_REG. While
waiting
if there is NACK | AL, set the appropriate error flags, ack the
pending
interrupts and return from the ISR.
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram panditavikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-
omap.c
index 05b5e4c..8deaf87 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
+ err = 0;
+complete:
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
- err = 0;
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
data to send\n);
break;
}
+
+ /*
+ * OMAP3430 Errata 1.153: When an XRDY/XDR
+ * is hit, wait for XUDF before writing data
+ * to DATA_REG. Otherwise some data bytes can
+ * be lost while transferring them from the
+ * memory to the I2C interface.
+ */
Based on this description, shouldn't this patch also zero the transmit
FIFO threshold? Consider what the transmit path becomes after this
patch:
1. Fill transmit FIFO
2. Leave ISR wait for interrupt
3. Interrupt happens due to XDR/XRDY (transmit FIFO low-water-mark
reached)
4. Busy-wait until transmit FIFO shift register completely empty
5. If more data to send, go to step #1
i2c-omap.c currently sets the transmit FIFO threshold to 1/2 of the
total
FIFO size[1]. This means that, in the worst case, I2C3, the I2C ISR
will
busy-wait in step 4 for the time it takes 32 bytes to be transmitted.
This is time that the MPU spends doing nothing but spinning, wasting
power. This seems unnecessary and wasteful. The time the driver spends
busy-waiting in the ISR should be reduced to the lowest possible
duration.
To do this, what I suggest that you additionally do in the patch is to
reduce the transit FIFO threshold/low-water-mark, controlled by
I2C_BUF.XTRSH, to the lowest possible value. This should maximize the
time spent between steps 2 and 3 and minimize the time spent between
steps
3 and 5.
Is there a reason why this can't be done?
Yes, this is actually lined up in my list of actions. I will be working on
this to test the functionality and stability of I2C code with the
threshold set to zero.
I did some analysis and testing of the code with threshold set to zero, we
cannot make the threshold zero with the present code in place, as this would
hamper the functionality of the draining feature because in this case the XDR
interrupt will not be triggered.
XDR- when TX FIFO level equal/below the XTRSH AND TXSTAT is less than XTRSH
XRDY- when TX FIFO level equal/below the XTRSH AND TXSTAT is equal/greater
than XTRSH
This in turn causes XRDY to be triggered always (even when there are only last
few bytes left to be transmitted) and therefore the code tries to transmit data
when the upper application is out of data.
+
+ if (cpu_is_omap34xx()) {
Does this erratum apply to the I2C IP block on OMAP2430? It also has
FIFO
transmit capability. It would be ideal if you can find out from the I2C
IP block designers. If you cannot, please consider adding a comment
that
this may also apply to the I2C block on OMAP2430.
In
[APPLIED] [PATCH 1/2] OMAP: remove OMAP_TAG_SERIAL_CONSOLE
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-upstream Initial commit ID (Likely to change): 7e1e03cb6dd027405cd07f20f3f6998b721d5ff3 PatchWorks http://patchwork.kernel.org/patch/39778/ 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=7e1e03cb6dd027405cd07f20f3f6998b721d5ff3 -- To unsubscribe from this list: send the line unsubscribe 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] REMOVE OMAP LEGACY CODE: Remove omap boot parsing code
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-upstream Initial commit ID (Likely to change): 219cb58bd7748f7002c64623e52fa369de2369d8 PatchWorks http://patchwork.kernel.org/patch/39619/ 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=219cb58bd7748f7002c64623e52fa369de2369d8 -- To unsubscribe from this list: send the line unsubscribe 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 2/2] OMAP: remove OMAP_TAG_UART
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-upstream Initial commit ID (Likely to change): 5ea0fbdf56dd4e127ce620d49606e2bf68e7 PatchWorks http://patchwork.kernel.org/patch/39779/ 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=5ea0fbdf56dd4e127ce620d49606e2bf68e7 -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: GPIO: Avoid generating extra IRQs
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-upstream Initial commit ID (Likely to change): ad23735d6744e7eeec4d2f012aa2ed2c1f8d64a9 PatchWorks http://patchwork.kernel.org/patch/33855/ 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=ad23735d6744e7eeec4d2f012aa2ed2c1f8d64a9 -- To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
Hi, On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote: On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote: Hi, On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote: On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote: Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? which board are you using ? ok, got you. it's 35xx-based with twl4030. when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID. Then try something like this patch: diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 9e3e7a5..4bc5b7f 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c Felipe, Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm: Great, I'll clean it up and send it to Greg for mainline integration. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
I am using linux-omap pm-2.6.29
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=s
hortlog;h=pm-2.6.29 branch,found a dead lock condition in:
arch/arm/plat-omap/resource.c-resource_release().
The dead lock happens when using resource_request(vdd1_opp,dev,...)
and resource_release(vdd1_opp, dev) to set and release vdd1 opp
constraint. The scenario is:
plat-omap/resource.c/resource_release(vdd1_opp,
dev)==resource.c/update_resource_level()=mach-omap2/resource34xx.c/se
t_opp(). In set_opp(), if the target_level of vdd1 is less than
OPP3,will release the constraint set on VDD2 by calling
resource_release(), but it will never return because can not get the
mutex which is holding by the previous caller.
int resource_release(const char *name, struct device *dev)
{ ...
down(res_mutex);
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
up(res_mutex);
return ret;
}
int set_opp(struct shared_resource *resp, u32 target_level) {
.
if (resp == vdd1_resp) {
if (target_level 3)
resource_release(vdd2_opp, vdd2_dev); }
The patch to fix this issue is below, will you pls review it and let me
know your feedback?
From: Limei Wang e12...@motorola.com
Date: Fri, 7 Aug 2009 11:40:35 -0500
Subject: [PATCH] OMAP PM: Fix dead lock bug in
resourc_release(vdd1_opp).
Signed-off-by: Limei Wang e12...@motorola.com
---
arch/arm/plat-omap/resource.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c index ec31727..876fd12 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -418,10 +418,12 @@ int resource_release(const char *name, struct
device *dev)
list_del(user-node);
free_user(user);
- /* Recompute and set the current level for the resource */
- ret = update_resource_level(resp);
res_unlock:
up(res_mutex);
+
+ /* Recompute and set the current level for the resource */
+ if (!ret)
+ ret = update_resource_level(resp);
return ret;
}
EXPORT_SYMBOL(resource_release);
--
1.5.6.3
This is wrong for several reasons.
First, you're not fixing the problem, you're just moving the call
outside of the lock, thus creating other locking problems.
Second, the various error paths would break because
update_resource_level() would be called on the 'res_unlock' error path
where it is not currently being called.
A per-resource mutex as suggest by Romit seems like the right approach
to fixing this problem.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3 1:2] [MTD][NAND]omap: Adding support for nand prefetch-read and post-write, in MPU mode.
* vimal singh vimalsi...@ti.com [090713 13:56]:
Patch updated for ' ioreadX / iowriteX and ioreadX_rep / iowriteX_rep' as per
David Brownell's comment. I updated 'omap_(read/write)_buf16' fucntions also
for this.
-vimal
This patch adds prefetch support to access nand flash in mpu mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Sorry for the delay. I've looked at the GPMC part, and that now looks OK
to me. So I'm OK for this to get integrated via the MTD list.
Acked-by: Tony Lindgren t...@atomide.com
---
---
arch/arm/mach-omap2/gpmc.c | 63
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig |8 +
drivers/mtd/nand/omap2.c | 161
+++--
4 files changed, 226 insertions(+), 10 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -57,6 +57,11 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#define PREFETCH_FIFOTHRESHOLD (0x40 8)
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH (0x1 7)
+#define DMA_MPU_MODE 2
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -386,6 +391,63 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+/**
+ * gpmc_prefetch_enable - configures and starts prefetch transfer
+ * @cs: nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+int gpmc_prefetch_enable(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+
+ if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefetch read / post write and
+ * enable the engine. Set which cs is has requested for.
+ */
+ prefetch_config1 = ((cs CS_NUM_SHIFT) |
+ PREFETCH_FIFOTHRESHOLD |
+ ENABLE_PREFETCH |
+ (dma_mode DMA_MPU_MODE) |
+ (0x1 is_write));
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ return -EBUSY;
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+
+ return 0;
+}
+EXPORT_SYMBOL(gpmc_prefetch_enable);
+
+/**
+ * gpmc_prefetch_reset - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_reset(void)
+{
+ /* Stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Reset/disable the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x0);
+}
+EXPORT_SYMBOL(gpmc_prefetch_reset);
+
+/**
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -452,6 +514,5 @@ void __init gpmc_init(void)
l = 0x03 3;
l |= (0x02 3) | (1 0);
gpmc_write_reg(GPMC_SYSCONFIG, l);
-
gpmc_mem_init();
}
Index: mtd-2.6/arch/arm/plat-omap/include/mach/gpmc.h
===
--- mtd-2.6.orig/arch/arm/plat-omap/include/mach/gpmc.h
+++ mtd-2.6/arch/arm/plat-omap/include/mach/gpmc.h
@@ -103,6 +103,10 @@ extern int gpmc_cs_request(int cs, unsig
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
+extern int gpmc_prefetch_enable(int cs, int dma_mode,
+ unsigned int u32_count, int is_write);
+extern void gpmc_prefetch_reset(void);
+extern int gpmc_prefetch_status(void);
extern void __init gpmc_init(void);
#endif
Index: mtd-2.6/drivers/mtd/nand/Kconfig
===
--- mtd-2.6.orig/drivers/mtd/nand/Kconfig
+++ mtd-2.6/drivers/mtd/nand/Kconfig
@@ -80,6 +80,14 @@ config MTD_NAND_OMAP2
help
Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
+config MTD_NAND_OMAP_PREFETCH
+ bool GPMC prefetch support for NAND Flash device
+ depends on MTD_NAND MTD_NAND_OMAP2
+
RE: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
Hello Moiz,
On Mon, 10 Aug 2009, Sonasath, Moiz wrote:
I did some analysis and testing of the code with threshold set to zero,
we cannot make the threshold zero with the present code in place, as
this would hamper the functionality of the draining feature because in
this case the XDR interrupt will not be triggered.
XDR- when TX FIFO level equal/below the XTRSH AND TXSTAT is less than XTRSH
XRDY- when TX FIFO level equal/below the XTRSH AND TXSTAT is
equal/greater than XTRSH
This in turn causes XRDY to be triggered always (even when there are
only last few bytes left to be transmitted) and therefore the code tries
to transmit data when the upper application is out of data.
Thanks for looking into this. How about just changing
if (dev-fifo_size) {
if (stat OMAP_I2C_STAT_XRDY)
num_bytes = dev-fifo_size;
else/* read TXSTAT on XDR interrupt */
num_bytes = omap_i2c_read_reg(dev,
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
to something like:
if (dev-fifo_size) { /* 2430 and beyond */
if (stat OMAP_I2C_STAT_XRDY)
num_bytes = clamp(dev-buf_len, 1, dev-fifo_size);
else
num_bytes = omap_i2c_read_reg(dev,
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
in the ISR?
The transmit and receive FIFO thresholds should also be split, so the
short transmit FIFO threshold doesn't affect the receive FIFO threshold.
I checked with the I2C IP team, yes the errata applies to the I2C block
on OMAP2430 and OMAP2420. I will send out a patch to include OMAP24XX
for this erratum.
Great, thanks for checking this. Might as well combine it with the same
patch and make it a revision test based on the I2C controller revision
reg.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH v3] OMAP1: AMS_DELTA: add modem support
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap1-upstream Initial commit ID (Likely to change): 92c79d20ca55625ad36ee79ec1356558a3aeb061 PatchWorks http://patchwork.kernel.org/patch/34220/ 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=92c79d20ca55625ad36ee79ec1356558a3aeb061 -- To unsubscribe from this list: send the line unsubscribe 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 1/2] OMAP2: add board file for Nokia N800 and N810
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap2-upstream Initial commit ID (Likely to change): 2090e81379175234ce310d7255d3a533adb104a5 PatchWorks http://patchwork.kernel.org/patch/40109/ 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=2090e81379175234ce310d7255d3a533adb104a5 -- To unsubscribe from this list: send the line unsubscribe 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 2/2] OMAP2: n8x0: add n8x0_defconfig
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap2-upstream Initial commit ID (Likely to change): bf1e615e10df3c9fcd200ceb4261ae926c89d438 PatchWorks http://patchwork.kernel.org/patch/40110/ 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=bf1e615e10df3c9fcd200ceb4261ae926c89d438 -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2: Zoom2: Pass irqflags to 8250 driver
* Vikram Pandita vikram.pand...@ti.com [090623 02:29]:
Pass irqflags to 8250 driver from zoom2 board file
Zoom2 has IRQF_TRIGGER_RISING requirement for the 8250 GPIO irq
This patch is dependent on 8250 driver changes getting accepted upstream:
Refer: http://patchwork.kernel.org/patch/31884/
FYI, I'll archive this for now, please resubmit once the related changes
are integrated. Or if resubmitting the related changes, please submit this
too via the serial list.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
Warning:
could cause compilation break if 8250 patch is not integrated first
arch/arm/mach-omap2/board-zoom-debugboard.c |2 ++
arch/arm/mach-omap2/serial.c|2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index bac5c43..f546063 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -12,6 +12,7 @@
#include linux/gpio.h
#include linux/serial_8250.h
#include linux/smsc911x.h
+#include linux/interrupt.h
#include mach/gpmc.h
@@ -84,6 +85,7 @@ static struct plat_serial8250_port serial_platform_data[] =
{
.mapbase= 0x1000,
.irq= OMAP_GPIO_IRQ(102),
.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+ .irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= QUART_CLK,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b094c15..45d4884 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -429,7 +429,7 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
omap_ctrl_writew(v, uart-padconf);
}
- p-flags |= UPF_SHARE_IRQ;
+ p-irqflags |= IRQF_SHARED;
ret = request_irq(p-irq, omap_uart_interrupt, IRQF_SHARED,
serial idle, (void *)uart);
WARN_ON(ret);
--
1.6.0.3.613.g9f8f13
--
To unsubscribe from this list: send the line unsubscribe 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 v2] OMAP2: Zoom2: Pass irqflags to 8250 driver
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, August 10, 2009 11:39 AM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v2] OMAP2: Zoom2: Pass irqflags to 8250 driver
* Vikram Pandita vikram.pand...@ti.com [090623 02:29]:
Pass irqflags to 8250 driver from zoom2 board file
Zoom2 has IRQF_TRIGGER_RISING requirement for the 8250 GPIO irq
This patch is dependent on 8250 driver changes getting accepted upstream:
Refer: http://patchwork.kernel.org/patch/31884/
FYI, I'll archive this for now, please resubmit once the related changes
are integrated. Or if resubmitting the related changes, please submit this
too via the serial list.
Looks like the dependency patch is already in linux-next tree at [1].
The dependency patch is already lined up stream.
So looks like you can line this irqflag change for zoom2.
[1]
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=7053133124d5cdf207c1168c7a0c582a18e12ea7
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
Warning:
could cause compilation break if 8250 patch is not integrated first
arch/arm/mach-omap2/board-zoom-debugboard.c |2 ++
arch/arm/mach-omap2/serial.c|2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-
debugboard.c
index bac5c43..f546063 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -12,6 +12,7 @@
#include linux/gpio.h
#include linux/serial_8250.h
#include linux/smsc911x.h
+#include linux/interrupt.h
#include mach/gpmc.h
@@ -84,6 +85,7 @@ static struct plat_serial8250_port serial_platform_data[]
= {
.mapbase= 0x1000,
.irq= OMAP_GPIO_IRQ(102),
.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= QUART_CLK,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b094c15..45d4884 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -429,7 +429,7 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
omap_ctrl_writew(v, uart-padconf);
}
-p-flags |= UPF_SHARE_IRQ;
+p-irqflags |= IRQF_SHARED;
ret = request_irq(p-irq, omap_uart_interrupt, IRQF_SHARED,
serial idle, (void *)uart);
WARN_ON(ret);
--
1.6.0.3.613.g9f8f13
--
To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 19:16 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote: On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote: Hi, On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote: On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote: Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? which board are you using ? ok, got you. it's 35xx-based with twl4030. when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID. Then try something like this patch: diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 9e3e7a5..4bc5b7f 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c Felipe, Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm: Great, I'll clean it up and send it to Greg for mainline integration. Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] ARM: OMAP: 3430SDP: Fix defconfig
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap3-upstream Initial commit ID (Likely to change): 1605f5e5b96c20a63e8f8c3f1ddbc16c983a85e8 PatchWorks http://patchwork.kernel.org/patch/32010/ 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=1605f5e5b96c20a63e8f8c3f1ddbc16c983a85e8 -- To unsubscribe from this list: send the line unsubscribe 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] Fixed processing of bootarg 'mpurate'
On Mon, 10 Aug 2009, Sanjeev Premi wrote: The argument 'mpurate' had no effect on the MPU frequency. This patch fixes the same. Thanks, I'll plan to squeeze this into the .32 merge window, with a couple of minor changes described below. Please review the changes: Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/clock34xx.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 045da92..0c62aad 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -27,6 +27,7 @@ #include linux/limits.h #include linux/bitops.h +#include mach/cpu.h #include mach/clock.h #include mach/sram.h #include asm/div64.h @@ -948,13 +949,18 @@ static int __init omap2_clk_arch_init(void) if (clk_set_rate(virt_prcm_set, mpurate)) printk(KERN_ERR Could not find matching MPU rate\n); #endif The previous four lines (including the three above) have been removed from clock34xx.c. + if (clk_set_rate(dpll1_ck, mpurate)) + printk(KERN_ERR *** Unable to set MPU rate\n); + omap3_dpll_recalc(dpll1_ck); I dropped the omap3_dpll_recalc(dpll1_ck); since the following recalculate_root_clocks() should handle this. recalculate_root_clocks(); - printk(KERN_INFO Switched to new clocking rate (Crystal/DPLL3/MPU): + printk(KERN_INFO Switched to new clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, -(osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, -(core_ck.rate / 100), (dpll1_fck.rate / 100)) ; +(osc_sys_ck.rate / 100), ((osc_sys_ck.rate / 10) % 10), +(core_ck.rate / 100), (arm_fck.rate / 100)) ; + + calibrate_delay(); return 0; } @@ -1013,7 +1019,7 @@ int __init omap2_clk_init(void) recalculate_root_clocks(); - printk(KERN_INFO Clocking rate (Crystal/DPLL/ARM core): + printk(KERN_INFO Clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, (core_ck.rate / 100), (arm_fck.rate / 100)); -- 1.6.2.2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH 2/2] rx51_defconfig: add twl4030 to rx51 default
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap3-upstream Initial commit ID (Likely to change): 6d8f62040f0d095e78d92213f3daa5bb525a510a PatchWorks http://patchwork.kernel.org/patch/14747/ 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=6d8f62040f0d095e78d92213f3daa5bb525a510a -- To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows: Jan 1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector... 1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it? -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3: MMC: Add mux for pins
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap3-upstream Initial commit ID (Likely to change): c1ad6cbf71b9dec5b0b54891d6feb387924e38a0 PatchWorks http://patchwork.kernel.org/patch/31803/ 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=c1ad6cbf71b9dec5b0b54891d6feb387924e38a0 -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: update OMAP3 Beagle defconfig
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap3-upstream Initial commit ID (Likely to change): 4ae796c139eda7c40b856f951d4db99d43d597f6 PatchWorks http://patchwork.kernel.org/patch/32514/ 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=4ae796c139eda7c40b856f951d4db99d43d597f6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] OMAP3:Zoom2: Add TWL4030 support
* Vikram Pandita vikram.pand...@ti.com [090622 19:41]:
Add TWL4030 CORE and TWL4030 drivers to Zoom2 board file
TWL drivers enabled are:
bci
madc
usb
keypad
mmc
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Adding this to my omap3-upstream queue.
Tony
---
arch/arm/mach-omap2/board-zoom2.c | 204
+++--
1 files changed, 193 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index bcc0f76..9ecf75c 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -12,17 +12,83 @@
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
+#include linux/input.h
#include linux/gpio.h
#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include mach/common.h
#include mach/usb.h
+#include mach/keypad.h
#include mmc-twl4030.h
+/* Zoom2 has Qwerty keyboard*/
+static int zoom2_twl4030_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(1, 0, KEY_R),
+ KEY(2, 0, KEY_T),
+ KEY(3, 0, KEY_HOME),
+ KEY(6, 0, KEY_I),
+ KEY(7, 0, KEY_LEFTSHIFT),
+ KEY(0, 1, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(2, 1, KEY_G),
+ KEY(3, 1, KEY_SEND),
+ KEY(6, 1, KEY_K),
+ KEY(7, 1, KEY_ENTER),
+ KEY(0, 2, KEY_X),
+ KEY(1, 2, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(3, 2, KEY_END),
+ KEY(6, 2, KEY_DOT),
+ KEY(7, 2, KEY_CAPSLOCK),
+ KEY(0, 3, KEY_Z),
+ KEY(1, 3, KEY_KPPLUS),
+ KEY(2, 3, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(6, 3, KEY_O),
+ KEY(7, 3, KEY_SPACE),
+ KEY(0, 4, KEY_W),
+ KEY(1, 4, KEY_Y),
+ KEY(2, 4, KEY_U),
+ KEY(3, 4, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(6, 4, KEY_L),
+ KEY(7, 4, KEY_LEFT),
+ KEY(0, 5, KEY_S),
+ KEY(1, 5, KEY_H),
+ KEY(2, 5, KEY_J),
+ KEY(3, 5, KEY_F3),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(6, 5, KEY_M),
+ KEY(4, 5, KEY_ENTER),
+ KEY(7, 5, KEY_RIGHT),
+ KEY(0, 6, KEY_Q),
+ KEY(1, 6, KEY_A),
+ KEY(2, 6, KEY_N),
+ KEY(3, 6, KEY_BACKSPACE),
+ KEY(6, 6, KEY_P),
+ KEY(7, 6, KEY_UP),
+ KEY(6, 7, KEY_SELECT),
+ KEY(7, 7, KEY_DOWN),
+ KEY(0, 7, KEY_PROG1), /*MACRO 1 User defined */
+ KEY(1, 7, KEY_PROG2), /*MACRO 2 User defined */
+ KEY(2, 7, KEY_PROG3), /*MACRO 3 User defined */
+ KEY(3, 7, KEY_PROG4), /*MACRO 4 User defined */
+ 0
+};
+
+static struct twl4030_keypad_data zoom2_kp_twl4030_data = {
+ .rows = 8,
+ .cols = 8,
+ .keymap = zoom2_twl4030_keymap,
+ .keymapsize = ARRAY_SIZE(zoom2_twl4030_keymap),
+ .rep= 1,
+};
static void __init omap_zoom2_init_irq(void)
{
omap2_init_common_hw(NULL);
@@ -38,10 +104,129 @@ static struct omap_board_config_kernel zoom2_config[]
__initdata = {
{ OMAP_TAG_UART,zoom2_uart_config },
};
+
+
+static struct regulator_consumer_supply zoom2_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply zoom2_vsim_supply = {
+ .supply = vmmc_aux,
+};
+
+static struct regulator_consumer_supply zoom2_vmmc2_supply = {
+ .supply = vmmc,
+};
+
+/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
+static struct regulator_init_data zoom2_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom2_vmmc1_supply,
+};
+
+/* VMMC2 for MMC2 card */
+static struct regulator_init_data zoom2_vmmc2 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 185,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom2_vmmc2_supply,
+};
+
+/* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
+static struct regulator_init_data zoom2_vsim = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 300,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+
[APPLIED] [PATCH v3 2/2] OMAP3:Zoom2: Update board defconfig
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap3-upstream Initial commit ID (Likely to change): 37e46a1dfc1095bb994ad05b6e6f6b448ec4ab37 PatchWorks http://patchwork.kernel.org/patch/31808/ 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=37e46a1dfc1095bb994ad05b6e6f6b448ec4ab37 -- To unsubscribe from this list: send the line unsubscribe 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: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 21:48 +0300, Felipe Balbi wrote: On Mon, Aug 10, 2009 at 01:28:43PM -0400, Peter Barada wrote: On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows: Jan 1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector... 1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it? donno yet, no clue unfortunately. but could you try the following Since
Re: [RFC] [PATCH 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
Monday 10 August 2009 11:43:25 Janusz Krzysztofik wrote: Monday 10 August 2009 10:50:06 Janusz Krzysztofik wrote: Enhance period index accuracy, particularly just before buffer rewind, by making use of DMA interrupt status flags in addition to simply counting interrupts Sorry, this one is still buggy To be clear: I meant only patch 3/3 was buggy, others seemed OK. an can break other OMAP models. Overstatement. The bug hits when multiple interrupt flags are set in parallel. Under heavy debugging, for the first time I have noticed several consecutive DMA interrupt requests with all three flags set alltogether: FRAME, LAST and BLOCK. It looks hopeless, doesn't it? Keeping the period index at 0 will not report any progress, other choices (increment, set max) will lead to buffer loss, right? Anyway, that observation seems to prove the requirement for a more accurate period counter. Improving it should help under heavy load. I think it is worth of trying, even if there may be other corner cases still not addressed. v2 of the patch will follow next. Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
From: Jon Hunter jon-hun...@ti.com
Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.
The OMAP3 can boot from several devices including USB. The sequence of the
devices the OMAP will attempt to boot from is configured via the sys_boot
pins on the device. If USB is one of the devices the OMAP boot ROM attempts
to boot from on power-on, then the interface clock to the MUSB peripheral will
be enabled by the boot ROM and the MUSB peripheral will be accessible when the
kernel boots. However, if USB is not one of the devices OMAP will attempt to
boot from then the interface clock is not enabled and the MUSB peripheral will
not be accessible on start-up.
If the MUSB peripheral is not accessible when the kernel boots, then the
kernel will crash when attempting to access the OTG_SYSCONFIG in the function
musb_platform_init(). The actual cause of the crash is the write to the
OTG_SYSCONFIG register in the function usb_musb_pm_init() to reset the MUSB
peripheral which occurs prior to calling musb_platform_init(). The function
usb_musb_pm_init() does not check to see if the interface clock for the MUSB
peripheral is enabled before writing to MUSB register. This write access does
not generate a data-abort at this point, but because this write does not
complete all future accesses to the MUSB controller will generate data-aborts
regardless of whether the interface clock has been enabled at a later stage.
The only way I have found to recover from this is resetting the device.
My understanding is that the interconnect works in this way to prevent a bad
access locking up the system.
This patch crudely ensures the interface clock for the MUSB in the function
usb_musb_pm_init() is enabled. This patch also ensures that the interface
clock is disabled after the reset is complete. My reasoning for always
disabling the clock rather than maintaing its state is:
1). If the MUSB peripheral is not being used then the interface clock should
be disabled.
2). The musb_set_clock() function uses a static variable called clk_on to
determine if the MUSB interface clock is on or off. On boot-up clk_on will be
0 and so this function assumes that the clock is off by default which may not
be the case in the current code.
I have also added a while-loop to wait for the reset of the MUSB module to
complete before this function exits and the interface clock it disabled.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/usb-musb.c | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3efa19c..7cfe9bb 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -32,25 +32,51 @@
#include mach/irqs.h
#include mach/mux.h
#include mach/usb.h
+#include cm.h
#define OTG_SYSCONFIG 0x404
#define OTG_SYSC_SOFTRESET BIT(1)
+#define OTG_SYSSTATUS 0x408
+#define OTG_SYSS_RESETDONE BIT(0)
static void __init usb_musb_pm_init(void)
{
- void __iomem *otg_base;
+ void __iomem *cm_base, *otg_base;
+ unsigned int cm_iclken_core;
if (!cpu_is_omap34xx())
return;
+ cm_base = ioremap(OMAP3430_CM_BASE, SZ_4K);
+ if (WARN_ON(!cm_base))
+ return;
+
otg_base = ioremap(OMAP34XX_HSUSB_OTG_BASE, SZ_4K);
- if (WARN_ON(!otg_base))
+ if (WARN_ON(!otg_base)) {
+ iounmap(cm_base);
return;
+ }
+
+ /* Ensure the inferface clock for MUSB is enabled */
+ cm_iclken_core = __raw_readl(OMAP34XX_CM_REGADDR(CORE_MOD,
+ CM_ICLKEN1));
+ __raw_writel((cm_iclken_core |
+ (1 OMAP3430_EN_HSOTGUSB_SHIFT)),
+ OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1));
/* Reset OTG controller. After reset, it will be in
* force-idle, force-standby mode. */
__raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+ while (!(OTG_SYSS_RESETDONE __raw_readl(otg_base + OTG_SYSSTATUS)))
+ cpu_relax();
+
+ /* Ensure the interface clock for MUSB is disabled */
+ __raw_writel((cm_iclken_core
+ ~(1 OMAP3430_EN_HSOTGUSB_SHIFT)),
+ OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1));
+
+ iounmap(cm_base);
iounmap(otg_base);
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio on OMAP3
Mark Brown wrote: On Mon, Aug 10, 2009 at 07:19:33AM -0600, Gary Thomas wrote: Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and You need to provide a machine-specific driver which tells the McBSP and TWL4030 drivers how they are connected together on your particular board. There are several examples of this for standard reference boards in the OMAP directory - if your audio hardware is based closely enough on one of those then you should be able to just use the same driver. My hardware is much like the Beagle, so I started with that driver. Got it going fine, thanks. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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/3 v2] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
Enhance period index accuracy, particularly just before buffer rewind, by
making use of DMA interrupt status flags in addition to simply counting up
interrupts.
Corrections since v1:
1. Fix buggy DMA interrupt handling in case of multiple status flags set in
parallel.
2. Enable OMAP_DMA_LAST_IRQ only for playback on OMAP1510.
This patch applies on top of patch 2 from this series:
[RFC][PATCH 2/3] ASoC: OMAP: Make use of DMA channel self linking on OMAP1510
Created against linux-2.6.31-rc5.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c.orig 2009-08-10
22:41:25.0 +0200
+++ linux-2.6.31-rc5/sound/soc/omap/omap-pcm.c 2009-08-10 23:15:46.0
+0200
@@ -68,13 +68,27 @@ static void omap_pcm_dma_irq(int ch, u16
* that can be used by omap_pcm_pointer() instead.
*/
spin_lock_irqsave(prtd-lock, flags);
+ if ((stat == OMAP_DMA_LAST_IRQ)
+ (prtd-period_index == runtime-periods - 1)) {
+ /* we are in sync, do nothing */
+ spin_unlock_irqrestore(prtd-lock, flags);
+ return;
+ }
if (prtd-period_index = 0) {
- if (++prtd-period_index == runtime-periods) {
+ if (stat OMAP_DMA_BLOCK_IRQ) {
+ /* end of buffer reached, loop back */
+ prtd-period_index = 0;
+ } else if (stat OMAP_DMA_LAST_IRQ) {
+ /* update the counter for the last period */
+ prtd-period_index = runtime-periods - 1;
+ } else if (++prtd-period_index = runtime-periods) {
+ /* end of buffer missed? loop back */
prtd-period_index = 0;
}
}
spin_unlock_irqrestore(prtd-lock, flags);
- }
+ } else if (stat == OMAP_DMA_LAST_IRQ)
+ return;
snd_pcm_period_elapsed(substream);
}
@@ -175,7 +189,12 @@ static int omap_pcm_prepare(struct snd_p
dma_params.frame_count = runtime-periods;
omap_set_dma_params(prtd-dma_ch, dma_params);
- omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ);
+ if ((cpu_is_omap1510())
+ (substream-stream == SNDRV_PCM_STREAM_PLAYBACK))
+ omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ |
+ OMAP_DMA_LAST_IRQ);
+ else
+ omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: Add list entries linux-...@vger.kernel.org and linux-arm-kernel@ to OMAP sections
Resend for Andrew Morton On Fri, 2009-08-07 at 11:01 +0300, Tony Lindgren wrote: * Joe Perches j...@perches.com [090806 19:35]: Perhaps it's useful for OMAP patches and bug reports to CC entries to the primary and secondary ARM lists. Added a pattern entry for OMAP USB as well. ... I think let's not add the drivers. The related driver list and linux-omap list should be enough for these. Fine by me. I fixed up your M: entry as well. Signed-off-by: Joe Perches j...@perches.com Acked-by: Tony Lindgren t...@atomide.com diff --git a/MAINTAINERS b/MAINTAINERS index b1114cf..6a82733 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3660,8 +3660,10 @@ F: drivers/video/riva/ F: drivers/video/nvidia/ OMAP SUPPORT -M: Tony Lindgren t...@atomide.com t...@atomide.com +M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org W: http://www.muru.com/linux/omap/ W: http://linux.omap.com/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git @@ -3671,12 +3673,16 @@ F: arch/arm/*omap* OMAP CLOCK FRAMEWORK SUPPORT M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/*omap*/*clock* OMAP POWER MANAGEMENT SUPPORT M: Kevin Hilman khil...@deeprootsystems.com L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only) +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/*omap*/*pm* -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSPBRIDGE: Tie Resource accounting to Process Context
This patch series uses filp-private data to get access to a PROCESS_CONTEXT pointer which in turn tracks all the resources tied to an open file handle. This will help in: 1. Implementation of clean resource accounting. 2. Proper resource cleanup irrespective of multithreading or multitasking in user space applications. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] DSPBRIDGE: Pass filp-private to all the ioctl wrappers
This patch enables passing of filp-private_data to all the ioctl wrappers functions. This change will facilitate retrival of PROCESS_CONTEXT pointer in ioctl, and will remove the call to DRV_GetProcContext(). Signed-off-by: Ameya Palande ameya.pala...@nokia.com --- arch/arm/plat-omap/include/dspbridge/_dcd.h | 135 --- drivers/dsp/bridge/pmgr/wcd.c | 112 +++--- drivers/dsp/bridge/rmgr/drv_interface.c |3 +- 3 files changed, 138 insertions(+), 112 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/_dcd.h b/arch/arm/plat-omap/include/dspbridge/_dcd.h index b6a8d9e..6e6aec5 100644 --- a/arch/arm/plat-omap/include/dspbridge/_dcd.h +++ b/arch/arm/plat-omap/include/dspbridge/_dcd.h @@ -72,7 +72,7 @@ */ extern DSP_STATUS WCD_CallDevIOCtl(unsigned int cmd, union Trapped_Args *args, - u32 *pResult); + u32 *pResult, void *pr_ctxt); /* * WCD_Init @@ -119,69 +119,94 @@ extern void WCD_Exit(void); /* MGR wrapper functions */ - extern u32 MGRWRAP_EnumNode_Info(union Trapped_Args *args); - extern u32 MGRWRAP_EnumProc_Info(union Trapped_Args *args); - extern u32 MGRWRAP_RegisterObject(union Trapped_Args *args); - extern u32 MGRWRAP_UnregisterObject(union Trapped_Args *args); - extern u32 MGRWRAP_WaitForBridgeEvents(union Trapped_Args *args); + extern u32 MGRWRAP_EnumNode_Info(union Trapped_Args *args, + void *pr_ctxt); + extern u32 MGRWRAP_EnumProc_Info(union Trapped_Args *args, + void *pr_ctxt); + extern u32 MGRWRAP_RegisterObject(union Trapped_Args *args, + void *pr_ctxt); + extern u32 MGRWRAP_UnregisterObject(union Trapped_Args *args, + void *pr_ctxt); + extern u32 MGRWRAP_WaitForBridgeEvents(union Trapped_Args *args, + void *pr_ctxt); #ifndef RES_CLEANUP_DISABLE - extern u32 MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args); + extern u32 MGRWRAP_GetProcessResourcesInfo(union Trapped_Args *args, + void *pr_ctxt); #endif /* CPRC (Processor) wrapper Functions */ - extern u32 PROCWRAP_Attach(union Trapped_Args *args); - extern u32 PROCWRAP_Ctrl(union Trapped_Args *args); - extern u32 PROCWRAP_Detach(union Trapped_Args *args); - extern u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args); - extern u32 PROCWRAP_EnumResources(union Trapped_Args *args); - extern u32 PROCWRAP_GetState(union Trapped_Args *args); - extern u32 PROCWRAP_GetTrace(union Trapped_Args *args); - extern u32 PROCWRAP_Load(union Trapped_Args *args); - extern u32 PROCWRAP_RegisterNotify(union Trapped_Args *args); - extern u32 PROCWRAP_Start(union Trapped_Args *args); - extern u32 PROCWRAP_ReserveMemory(union Trapped_Args *args); - extern u32 PROCWRAP_UnReserveMemory(union Trapped_Args *args); - extern u32 PROCWRAP_Map(union Trapped_Args *args); - extern u32 PROCWRAP_UnMap(union Trapped_Args *args); - extern u32 PROCWRAP_FlushMemory(union Trapped_Args *args); - extern u32 PROCWRAP_Stop(union Trapped_Args *args); - extern u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args); + extern u32 PROCWRAP_Attach(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_EnumResources(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_GetState(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_GetTrace(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_Load(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_RegisterNotify(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_Start(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_ReserveMemory(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_UnReserveMemory(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_Map(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_UnMap(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_FlushMemory(union Trapped_Args *args, + void *pr_ctxt); + extern u32 PROCWRAP_Stop(union Trapped_Args *args, void *pr_ctxt); + extern u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args, + void *pr_ctxt); /* NODE wrapper
[PATCH 02/13] DSPBRIDGE: Use pr_ctxt in NODE_Allocate
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/node.h |4 ++-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/node.c | 49 +++
3 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/node.h
b/arch/arm/plat-omap/include/dspbridge/node.h
index d253962..db3be05 100644
--- a/arch/arm/plat-omap/include/dspbridge/node.h
+++ b/arch/arm/plat-omap/include/dspbridge/node.h
@@ -68,6 +68,7 @@
#include dspbridge/nodedefs.h
#include dspbridge/dispdefs.h
#include dspbridge/nldrdefs.h
+#include dspbridge/drv.h
/*
* NODE_Allocate
@@ -104,7 +105,8 @@
*pArgs,
OPTIONAL IN CONST struct DSP_NODEATTRIN
*pAttrIn,
- OUT struct NODE_OBJECT **phNode);
+ OUT struct NODE_OBJECT **phNode,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* NODE_AllocMsgBuf
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 23ed3a7..05afb2c 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1170,7 +1170,7 @@ u32 NODEWRAP_Allocate(union Trapped_Args *args, void
*pr_ctxt)
if (DSP_SUCCEEDED(status)) {
status = NODE_Allocate(args-ARGS_NODE_ALLOCATE.hProcessor,
nodeId, (struct DSP_CBDATA *)pArgs,
- pAttrIn, hNode);
+ pAttrIn, hNode, pr_ctxt);
}
cp_to_usr(args-ARGS_NODE_ALLOCATE.phNode, hNode, status, 1);
func_cont:
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 5ff87e9..b7bdf08 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -389,7 +389,8 @@ DSP_STATUS NODE_Allocate(struct PROC_OBJECT *hProcessor,
IN CONST struct DSP_UUID *pNodeId,
OPTIONAL IN CONST struct DSP_CBDATA *pArgs,
OPTIONAL IN CONST struct DSP_NODEATTRIN *pAttrIn,
- OUT struct NODE_OBJECT **phNode)
+ OUT struct NODE_OBJECT **phNode,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
struct NODE_MGR *hNodeMgr;
struct DEV_OBJECT *hDevObject;
@@ -418,11 +419,7 @@ DSP_STATUS NODE_Allocate(struct PROC_OBJECT *hProcessor,
#endif
#ifndef RES_CLEANUP_DISABLE
- HANDLE hDrvObject;
HANDLE nodeRes;
- u32 hProcess;
- struct PROCESS_CONTEXT *pPctxt = NULL;
- DSP_STATUS res_status = DSP_SOK;
#endif
DBC_Require(cRefs 0);
@@ -789,45 +786,9 @@ func_cont2:
#ifndef RES_CLEANUP_DISABLE
if (DSP_SUCCEEDED(status)) {
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject,
- REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDrvObject,
-pPctxt, *phNode, 0);
- if (pPctxt == NULL) {
- DRV_InsertProcContext(
- (struct DRV_OBJECT *)hDrvObject,
- pPctxt);
- if (pPctxt != NULL) {
- DRV_ProcUpdatestate(pPctxt,
- PROC_RES_ALLOCATED);
- DRV_ProcSetPID(pPctxt, hProcess);
- pPctxt-hProcessor =
-(DSP_HPROCESSOR)hProcessor;
- }
- }
- }
- }
- if (DSP_SUCCEEDED(status)) {
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
- res_status = CFG_GetObject((u32 *)hDrvObject,
- REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDrvObject,
-pPctxt, *phNode, 0);
- if (pPctxt != NULL) {
- DRV_InsertNodeResElement(*phNode, nodeRes,
-pPctxt);
- DRV_ProcNodeUpdateHeapStatus(nodeRes, true);
-
[PATCH 05/13] DSPBRIDGE: Use pr_ctxt in PROC_Attach
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/proc.h |3 +-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/proc.c | 51 +-
3 files changed, 13 insertions(+), 43 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 832b518..1737761 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -95,7 +95,8 @@
extern DSP_STATUS PROC_Attach(u32 uProcessor,
OPTIONAL CONST struct DSP_PROCESSORATTRIN
*pAttrIn,
- OUT DSP_HPROCESSOR *phProcessor);
+ OUT DSP_HPROCESSOR *phProcessor,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* PROC_AutoStart =
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index a574278..ddb2aea 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -681,7 +681,7 @@ u32 PROCWRAP_Attach(union Trapped_Args *args, void *pr_ctxt)
}
status = PROC_Attach(args-ARGS_PROC_ATTACH.uProcessor, pAttrIn,
- processor);
+ processor, pr_ctxt);
cp_to_usr(args-ARGS_PROC_ATTACH.phProcessor, processor, status, 1);
func_end:
return status;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 4ab4a88..c475436 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -237,7 +237,7 @@ func_end:
*/
DSP_STATUS
PROC_Attach(u32 uProcessor, OPTIONAL CONST struct DSP_PROCESSORATTRIN *pAttrIn,
- OUT DSP_HPROCESSOR *phProcessor)
+ OUT DSP_HPROCESSOR *phProcessor, struct PROCESS_CONTEXT *pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
struct DEV_OBJECT *hDevObject;
@@ -246,19 +246,19 @@ PROC_Attach(u32 uProcessor, OPTIONAL CONST struct
DSP_PROCESSORATTRIN *pAttrIn,
struct DRV_OBJECT *hDrvObject = NULL;
u32 devType;
-#ifndef RES_CLEANUP_DISABLE
- HANDLE hDRVObject;
- u32 hProcess;
- DSP_STATUS res_status = DSP_SOK;
- struct PROCESS_CONTEXT *pPctxt = NULL;
-#endif
-
DBC_Require(cRefs 0);
DBC_Require(phProcessor != NULL);
GT_3trace(PROC_DebugMask, GT_ENTER, Entered PROC_Attach, args:\n\t
uProcessor: 0x%x\n\tpAttrIn: 0x%x\n\tphProcessor:
0x%x\n, uProcessor, pAttrIn, phProcessor);
+
+ if (pr_ctxt-hProcessor) {
+ pr_err(DSP: PROC_Attach() on same file handle is
+ not supported!\n);
+ goto func_end;
+ }
+
/* Get the Driver and Manager Object Handles */
status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
if (DSP_SUCCEEDED(status)) {
@@ -380,41 +380,10 @@ PROC_Attach(u32 uProcessor, OPTIONAL CONST struct
DSP_PROCESSORATTRIN *pAttrIn,
storage for notification \n);
MEM_FreeObject(pProcObject);
}
-func_end:
#ifndef RES_CLEANUP_DISABLE
- if (DSP_FAILED(status))
- goto func_cont;
-
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
- if (DSP_FAILED(res_status))
- goto func_cont;
-
- DRV_GetProcContext(hProcess, (struct DRV_OBJECT *)hDRVObject,
-pPctxt, NULL, 0);
- if (pPctxt == NULL) {
- DRV_InsertProcContext((struct DRV_OBJECT *)hDRVObject, pPctxt);
- if (pPctxt != NULL) {
- DRV_ProcUpdatestate(pPctxt, PROC_RES_ALLOCATED);
- DRV_ProcSetPID(pPctxt, hProcess);
- }
- }
-func_cont:
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDRVObject, pPctxt,
-NULL, 0);
- if (pPctxt != NULL)
- pPctxt-hProcessor = (DSP_HPROCESSOR)*phProcessor;
-
- }
+ pr_ctxt-hProcessor = pProcObject;
#endif
+func_end:
DBC_Ensure((status == DSP_EFAIL *phProcessor == NULL) ||
(DSP_SUCCEEDED(status)
MEM_IsValidHandle(pProcObject, PROC_SIGNATURE)) ||
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] DSPBRIDGE: Support multiple processor objects per process context
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/drv.h |5 +-
arch/arm/plat-omap/include/dspbridge/proc.h | 23 ++
drivers/dsp/bridge/rmgr/drv.c | 23 --
drivers/dsp/bridge/rmgr/drv_interface.c | 13 +-
drivers/dsp/bridge/rmgr/proc.c | 61 ++
5 files changed, 79 insertions(+), 46 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index c468461..efc3a92 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -180,8 +180,9 @@ struct PROCESS_CONTEXT{
* (To maintain a linked list of process contexts) */
struct PROCESS_CONTEXT *next;
- /* Processor info to which the process is related */
- DSP_HPROCESSOR hProcessor;
+ /* List of Processors */
+ struct list_head processor_list;
+ spinlock_t proc_list_lock;
/* DSP Node resources */
struct NODE_RES_OBJECT *pNodeList;
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index f5b0c50..1936a4e 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -66,6 +66,29 @@
#include dspbridge/devdefs.h
#include dspbridge/drv.h
+/* The PROC_OBJECT structure. */
+struct PROC_OBJECT {
+ struct LST_ELEM link; /* Link to next PROC_OBJECT */
+ u32 dwSignature;/* Used for object validation */
+ struct DEV_OBJECT *hDevObject; /* Device this PROC represents */
+ u32 hProcess; /* Process owning this Processor */
+ struct MGR_OBJECT *hMgrObject; /* Manager Object Handle */
+ u32 uAttachCount; /* Processor attach count */
+ u32 uProcessor; /* Processor number */
+ u32 uTimeout; /* Time out count */
+ enum DSP_PROCSTATE sState; /* Processor state */
+ u32 ulUnit; /* DDSP unit number */
+ bool bIsAlreadyAttached;/*
+* True if the Device below has
+* GPP Client attached
+*/
+ struct NTFY_OBJECT *hNtfy; /* Manages notifications */
+ struct WMD_DEV_CONTEXT *hWmdContext;/* WMD Context Handle */
+ struct WMD_DRV_INTERFACE *pIntfFxns;/* Function interface to WMD */
+ char *g_pszLastCoff;
+ struct list_head proc_object;
+};
+
/*
* PROC_Attach
* Purpose:
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 4a4ebfa..e64b997 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -278,9 +278,19 @@ DSP_STATUS DRV_InsertProcContext(struct DRV_OBJECT
*hDrVObject, HANDLE hPCtxt)
struct DRV_OBJECT*hDRVObject;
GT_0trace(curTrace, GT_ENTER, \n In DRV_InsertProcContext\n);
+
status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
DBC_Assert(hDRVObject != NULL);
+
*pCtxt = MEM_Calloc(1 * sizeof(struct PROCESS_CONTEXT), MEM_PAGED);
+ if (!*pCtxt) {
+ pr_err(DSP: MEM_Calloc failed in DRV_InsertProcContext\n);
+ return DSP_EMEMORY;
+ }
+
+ spin_lock_init((*pCtxt)-proc_list_lock);
+ INIT_LIST_HEAD((*pCtxt)-processor_list);
+
GT_0trace(curTrace, GT_ENTER,
\n In DRV_InsertProcContext Calling
DRV_GetProcCtxtList\n);
@@ -1005,6 +1015,7 @@ static DSP_STATUS PrintProcessInformation(void)
struct DMM_RES_OBJECT *pDMMRes = NULL;
struct STRM_RES_OBJECT *pSTRMRes = NULL;
struct DSPHEAP_RES_OBJECT *pDSPHEAPRes = NULL;
+ struct PROC_OBJECT *proc_obj_ptr;
DSP_STATUS status = DSP_SOK;
u32 tempCount;
u32 procID;
@@ -1031,11 +1042,11 @@ static DSP_STATUS PrintProcessInformation(void)
GT_0trace(curTrace, GT_4CLASS, \nThe Process
is in DeAllocated state\n);
}
- GT_1trace(curTrace, GT_4CLASS, \nThe hProcessor
-handle is: 0X%x\n,
- (u32)pCtxtList-hProcessor);
- if (pCtxtList-hProcessor != NULL) {
- PROC_GetProcessorId(pCtxtList-hProcessor, procID);
+
+ spin_lock(pCtxtList-proc_list_lock);
+ list_for_each_entry(proc_obj_ptr, pCtxtList-processor_list,
+ proc_object) {
+ PROC_GetProcessorId(proc_obj_ptr, procID);
if (procID == DSP_UNIT) {
GT_0trace(curTrace, GT_4CLASS,
\nProcess connected to
@@ -1049,6 +1060,8 @@ static
[PATCH 04/13] DSPBRIDGE: Use pr_ctxt in PROC_UnMap and NODE_Delete
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/node.h |3 +-
arch/arm/plat-omap/include/dspbridge/proc.h |3 +-
drivers/dsp/bridge/pmgr/wcd.c |4 +-
drivers/dsp/bridge/rmgr/drv.c |8 +++--
drivers/dsp/bridge/rmgr/node.c | 37 +++
drivers/dsp/bridge/rmgr/proc.c | 29 ++---
6 files changed, 34 insertions(+), 50 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/node.h
b/arch/arm/plat-omap/include/dspbridge/node.h
index db3be05..e8952f5 100644
--- a/arch/arm/plat-omap/include/dspbridge/node.h
+++ b/arch/arm/plat-omap/include/dspbridge/node.h
@@ -309,7 +309,8 @@
* Ensures:
* DSP_SOK:hNode is invalid.
*/
- extern DSP_STATUS NODE_Delete(struct NODE_OBJECT *hNode);
+ extern DSP_STATUS NODE_Delete(struct NODE_OBJECT *hNode,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* NODE_DeleteMgr
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index ff1573f..832b518 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -623,7 +623,8 @@
* Ensures:
* Details:
*/
- extern DSP_STATUS PROC_UnMap(DSP_HPROCESSOR hProcessor, void *pMapAddr);
+ extern DSP_STATUS PROC_UnMap(DSP_HPROCESSOR hProcessor, void *pMapAddr,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* PROC_UnReserveMemory
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index bf8f672..a574278 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1094,7 +1094,7 @@ u32 PROCWRAP_UnMap(union Trapped_Args *args, void
*pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_UnMap: entered\n);
status = PROC_UnMap(args-ARGS_PROC_UNMAPMEM.hProcessor,
- args-ARGS_PROC_UNMAPMEM.pMapAddr);
+ args-ARGS_PROC_UNMAPMEM.pMapAddr, pr_ctxt);
return status;
}
@@ -1296,7 +1296,7 @@ u32 NODEWRAP_Delete(union Trapped_Args *args, void
*pr_ctxt)
u32 retVal;
GT_0trace(WCD_debugMask, GT_ENTER, NODEWRAP_Delete: entered\n);
- retVal = NODE_Delete(args-ARGS_NODE_DELETE.hNode);
+ retVal = NODE_Delete(args-ARGS_NODE_DELETE.hNode, pr_ctxt);
return retVal;
}
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 66e4a4d..4a4ebfa 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -453,13 +453,15 @@ static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt)
GT_1trace(curTrace, GT_5CLASS,
Calling Node_Delete for Node:
0x%x\n, pNodeRes-hNode);
- status = NODE_Delete(pNodeRes-hNode);
+ status = NODE_Delete(pNodeRes-hNode,
+ pCtxt);
GT_1trace(curTrace, GT_5CLASS,
the status after the NodeDelete %x\n,
status);
} else if ((nState == NODE_ALLOCATED)
|| (nState == NODE_CREATED))
- status = NODE_Delete(pNodeRes-hNode);
+ status = NODE_Delete(pNodeRes-hNode,
+ pCtxt);
}
}
}
@@ -571,7 +573,7 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
pDMMList = pDMMList-next;
if (pDMMRes-dmmAllocated) {
status = PROC_UnMap(pDMMRes-hProcessor,
-(void *)pDMMRes-ulDSPResAddr);
+(void *)pDMMRes-ulDSPResAddr, pCtxt);
status = PROC_UnReserveMemory(pDMMRes-hProcessor,
(void *)pDMMRes-ulDSPResAddr);
pDMMRes-dmmAllocated = 0;
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index a6d4d25..d3f0e34 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -322,7 +322,8 @@ static struct DSP_BUFFERATTR NODE_DFLTBUFATTRS = {
0, /* uAlignment */
};
-static void DeleteNode(struct NODE_OBJECT *hNode);
+static void DeleteNode(struct NODE_OBJECT *hNode,
+ struct PROCESS_CONTEXT *pr_ctxt);
static void DeleteNodeMgr(struct NODE_MGR *hNodeMgr);
static void FillStreamConnect(struct NODE_OBJECT *hNode1,
struct NODE_OBJECT *hNode2, u32 uStream1,
@@ -780,7 +781,7 @@
[PATCH 03/13] DSPBRIDGE: Use pr_ctxt in PROC_Map
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/proc.h |4 +++-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/node.c |2 +-
drivers/dsp/bridge/rmgr/proc.c | 26 +-
4 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 486652e..ff1573f 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -64,6 +64,7 @@
#include dspbridge/cfgdefs.h
#include dspbridge/devdefs.h
+#include dspbridge/drv.h
/*
* PROC_Attach
@@ -578,7 +579,8 @@
void *pMpuAddr,
u32 ulSize,
void *pReqAddr,
- void **ppMapAddr, u32 ulMapAttr);
+ void **ppMapAddr, u32 ulMapAttr,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* PROC_ReserveMemory
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 05afb2c..bf8f672 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1023,7 +1023,7 @@ u32 PROCWRAP_Map(union Trapped_Args *args, void *pr_ctxt)
args-ARGS_PROC_MAPMEM.pMpuAddr,
args-ARGS_PROC_MAPMEM.ulSize,
args-ARGS_PROC_MAPMEM.pReqAddr, pMapAddr,
-args-ARGS_PROC_MAPMEM.ulMapAttr);
+args-ARGS_PROC_MAPMEM.ulMapAttr, pr_ctxt);
if (DSP_SUCCEEDED(status)) {
if (put_user(pMapAddr, args-ARGS_PROC_MAPMEM.ppMapAddr))
status = DSP_EINVALIDARG;
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index b7bdf08..a6d4d25 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -561,7 +561,7 @@ func_cont:
status = PROC_Map(hProcessor, (void *)pAttrIn-pGPPVirtAddr,
pNode-createArgs.asa.taskArgs.uHeapSize,
(void *)pNode-createArgs.asa.taskArgs.uDSPHeapResAddr,
- (void **)pMappedAddr, mapAttrs);
+ (void **)pMappedAddr, mapAttrs, pr_ctxt);
if (DSP_FAILED(status)) {
GT_1trace(NODE_debugMask, GT_5CLASS,
NODE_Allocate: Failed to map memory
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index c6bfda1..0ee0656 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -1412,7 +1412,8 @@ func_end:
* Maps a MPU buffer to DSP address space.
*/
DSP_STATUS PROC_Map(DSP_HPROCESSOR hProcessor, void *pMpuAddr, u32 ulSize,
- void *pReqAddr, void **ppMapAddr, u32 ulMapAttr)
+ void *pReqAddr, void **ppMapAddr, u32 ulMapAttr,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
u32 vaAlign;
u32 paAlign;
@@ -1422,11 +1423,7 @@ DSP_STATUS PROC_Map(DSP_HPROCESSOR hProcessor, void
*pMpuAddr, u32 ulSize,
struct PROC_OBJECT *pProcObject = (struct PROC_OBJECT *)hProcessor;
#ifndef RES_CLEANUP_DISABLE
- u32 hProcess;
- HANDLEpCtxt = NULL;
- HANDLEhDrvObject;
HANDLEdmmRes;
- DSP_STATUS res_status = DSP_SOK;
#endif
GT_6trace(PROC_DebugMask, GT_ENTER, Entered PROC_Map, args:\n\t
@@ -1476,22 +1473,9 @@ DSP_STATUS PROC_Map(DSP_HPROCESSOR hProcessor, void
*pMpuAddr, u32 ulSize,
#ifndef RES_CLEANUP_DISABLE
if (DSP_SUCCEEDED(status)) {
- /* Update the node and stream resource status */
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject,
- REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- if (DRV_GetProcContext(hProcess,
- (struct DRV_OBJECT *)hDrvObject, pCtxt, NULL,
- (u32)pMpuAddr) != DSP_ENOTFOUND) {
- DRV_InsertDMMResElement(dmmRes, pCtxt);
- DRV_UpdateDMMResElement(dmmRes, (u32)pMpuAddr,
- ulSize, (u32)pReqAddr,
- (u32)*ppMapAddr, hProcessor);
- }
- }
+ DRV_InsertDMMResElement(dmmRes, pr_ctxt);
+ DRV_UpdateDMMResElement(dmmRes, (u32)pMpuAddr, ulSize,
+ (u32)pReqAddr, (u32)*ppMapAddr, hProcessor);
}
#endif
func_end:
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap
[PATCH 11/13] DSPBRIDGE: Use pr_ctxt in STRM_AllocateBuffer
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/strm.h |3 +-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/strm.c | 28 ++
3 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/strm.h
b/arch/arm/plat-omap/include/dspbridge/strm.h
index 23a9f17..9929210 100644
--- a/arch/arm/plat-omap/include/dspbridge/strm.h
+++ b/arch/arm/plat-omap/include/dspbridge/strm.h
@@ -84,7 +84,8 @@
extern DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
OUT u8 **apBuffer,
- u32 uNumBufs);
+ u32 uNumBufs,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* STRM_Close
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index c9b29ea..4fdcb18 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1493,7 +1493,7 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
status = STRM_AllocateBuffer(args-ARGS_STRM_ALLOCATEBUFFER.hStream,
args-ARGS_STRM_ALLOCATEBUFFER.uSize,
-apBuffer, uNumBufs);
+apBuffer, uNumBufs, pr_ctxt);
cp_to_usr(args-ARGS_STRM_ALLOCATEBUFFER.apBuffer, apBuffer, status,
uNumBufs);
if (apBuffer)
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index e25818f..d68251f 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -154,18 +154,15 @@ static void DeleteStrmMgr(struct STRM_MGR *hStrmMgr);
* Allocates buffers for a stream.
*/
DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm, u32 uSize,
- OUT u8 **apBuffer, u32 uNumBufs)
+ OUT u8 **apBuffer, u32 uNumBufs,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
u32 uAllocated = 0;
u32 i;
- #ifndef RES_CLEANUP_DISABLE
- DSP_STATUS res_status = DSP_SOK;
- u32 hProcess;
- HANDLE pCtxt = NULL;
- HANDLE hDrvObject;
+#ifndef RES_CLEANUP_DISABLE
HANDLE hSTRMRes;
- #endif
+#endif
DBC_Require(cRefs 0);
DBC_Require(apBuffer != NULL);
@@ -203,20 +200,9 @@ DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
if (DSP_FAILED(status))
goto func_end;
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
- if (DSP_FAILED(res_status))
- goto func_end;
-
- DRV_GetProcContext(hProcess, (struct DRV_OBJECT *)hDrvObject,
-pCtxt, NULL, 0);
- if (pCtxt != NULL) {
- if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pCtxt) !=
- DSP_ENOTFOUND) {
- DRV_ProcUpdateSTRMRes(uNumBufs, hSTRMRes, pCtxt);
- }
+ if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pr_ctxt) !=
+ DSP_ENOTFOUND) {
+ DRV_ProcUpdateSTRMRes(uNumBufs, hSTRMRes, pr_ctxt);
}
#endif
func_end:
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] DSPBRIDGE: Use pr_ctxt in DRV_RemoveProcContext
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
.../plat-omap/include/dspbridge/resourcecleanup.h |2 +-
drivers/dsp/bridge/rmgr/drv.c | 32 ++--
drivers/dsp/bridge/rmgr/drv_interface.c|4 +-
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index b43fa16..5592f38 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -43,7 +43,7 @@ extern DSP_STATUS DRV_GetProcContext(u32 phProcess,
extern DSP_STATUS DRV_RemoveAllResources(HANDLE pPctxt);
extern DSP_STATUS DRV_RemoveProcContext(struct DRV_OBJECT *hDRVObject,
-HANDLE hPCtxt, HANDLE hProcess);
+HANDLE hPCtxt);
extern DSP_STATUS DRV_GetNodeResElement(HANDLE hNode, HANDLE nodeRes,
HANDLE pCtxt);
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index e64b997..6cfd349 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -317,36 +317,36 @@ DSP_STATUS DRV_InsertProcContext(struct DRV_OBJECT
*hDrVObject, HANDLE hPCtxt)
/* Delete a process context from process resource context list */
DSP_STATUS DRV_RemoveProcContext(struct DRV_OBJECT *hDRVObject,
-HANDLE hPCtxt, HANDLE hProcess)
+ HANDLE pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
- struct PROCESS_CONTEXT*pCtxt2 = NULL;
- struct PROCESS_CONTEXT*pTmp = NULL;
- struct PROCESS_CONTEXT*pCtxtList = NULL;
+ struct PROCESS_CONTEXT *pr_ctxt_list = NULL;
+ struct PROCESS_CONTEXT *ptr_prev;
DBC_Assert(hDRVObject != NULL);
- DRV_GetProcContext((u32)hProcess, hDRVObject, pCtxt2, NULL, 0);
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 12);
- DRV_GetProcCtxtList(pCtxtList, hDRVObject);
+ DRV_GetProcCtxtList(pr_ctxt_list, hDRVObject);
+ ptr_prev = pr_ctxt_list;
+
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 13);
- pTmp = pCtxtList;
- while ((pCtxtList != NULL) (pCtxtList != pCtxt2)) {
- pTmp = pCtxtList;
- pCtxtList = pCtxtList-next;
+ while (pr_ctxt_list (pr_ctxt_list != pr_ctxt)) {
+ ptr_prev = pr_ctxt_list;
+ pr_ctxt_list = pr_ctxt_list-next;
GT_0trace(curTrace, GT_ENTER,
DRV_RemoveProcContext: 2);
}
+
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 3);
- if (hDRVObject-procCtxtList == pCtxt2)
- hDRVObject-procCtxtList = pCtxt2-next;
- if (pCtxtList == NULL)
+ if (!pr_ctxt_list)
return DSP_ENOTFOUND;
- else if (pTmp-next != NULL)
- pTmp-next = pTmp-next-next;
+ else if (pr_ctxt_list-next != NULL)
+ ptr_prev-next = pr_ctxt_list-next;
+ else
+ hDRVObject-procCtxtList = NULL;
- MEM_Free(pCtxt2);
+ MEM_Free(pr_ctxt);
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 7);
return status;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 1cb3d74..fa79695 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -481,7 +481,7 @@ static int __devexit omap34xx_bridge_remove(struct
platform_device *pdev)
}
pTmp = pCtxtclosed-next;
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
-pCtxtclosed, (void *)pCtxtclosed-pid);
+ pCtxtclosed);
pCtxtclosed = pTmp;
}
@@ -630,7 +630,7 @@ static int bridge_release(struct inode *ip, struct file
*filp)
PROC_Detach(proc_obj_ptr, pr_ctxt);
}
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
- pr_ctxt, (void *)pr_ctxt-pid);
+ pr_ctxt);
} else {
status = -EIO;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] DSPBRIDGE: Use pr_ctxt in STRM_Close
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/strm.h |3 ++-
drivers/dsp/bridge/pmgr/wcd.c |6 +-
drivers/dsp/bridge/rmgr/drv.c |5 +++--
drivers/dsp/bridge/rmgr/strm.c | 27 +--
4 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/strm.h
b/arch/arm/plat-omap/include/dspbridge/strm.h
index 36b128d..23a9f17 100644
--- a/arch/arm/plat-omap/include/dspbridge/strm.h
+++ b/arch/arm/plat-omap/include/dspbridge/strm.h
@@ -102,7 +102,8 @@
* STRM_Init(void) called.
* Ensures:
*/
- extern DSP_STATUS STRM_Close(struct STRM_OBJECT *hStrm);
+ extern DSP_STATUS STRM_Close(struct STRM_OBJECT *hStrm,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* STRM_Create
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index cf3fc2d..c9b29ea 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1507,11 +1507,7 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
*/
u32 STRMWRAP_Close(union Trapped_Args *args, void *pr_ctxt)
{
- u32 retVal;
-
- retVal = STRM_Close(args-ARGS_STRM_CLOSE.hStream);
-
- return retVal;
+ return STRM_Close(args-ARGS_STRM_CLOSE.hStream, pr_ctxt);
}
/*
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 6cfd349..bf7d0b2 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -801,14 +801,15 @@ static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt)
pSTRMRes-uNumBufs);
MEM_Free(apBuffer);
}
- status = STRM_Close(pSTRMRes-hStream);
+ status = STRM_Close(pSTRMRes-hStream, pCtxt);
if (DSP_FAILED(status)) {
if (status == DSP_EPENDING) {
status = STRM_Reclaim(pSTRMRes-hStream,
pBufPtr, ulBytes,
(u32 *)ulBufSize, dwArg);
if (DSP_SUCCEEDED(status))
- status = STRM_Close(pSTRMRes-hStream);
+ status = STRM_Close(pSTRMRes-hStream,
+ pCtxt);
}
}
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index 4a05ed4..e25818f 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -228,22 +228,17 @@ func_end:
* Purpose:
* Close a stream opened with STRM_Open().
*/
-DSP_STATUS STRM_Close(struct STRM_OBJECT *hStrm)
+DSP_STATUS STRM_Close(struct STRM_OBJECT *hStrm,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
struct WMD_DRV_INTERFACE *pIntfFxns;
struct CHNL_INFO chnlInfo;
DSP_STATUS status = DSP_SOK;
-
#ifndef RES_CLEANUP_DISABLE
-u32 hProcess;
-HANDLE pCtxt = NULL;
-HANDLE hDrvObject;
HANDLE hSTRMRes;
-DSP_STATUS res_status = DSP_SOK;
#endif
-
DBC_Require(cRefs 0);
GT_1trace(STRM_debugMask, GT_ENTER, STRM_Close: hStrm: 0x%x\n, hStrm);
@@ -276,21 +271,9 @@ DSP_STATUS STRM_Close(struct STRM_OBJECT *hStrm)
if (DSP_FAILED(status))
goto func_end;
- /* Update the node and stream resource status */
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
- if (DSP_FAILED(res_status))
- goto func_end;
-
- DRV_GetProcContext(hProcess, (struct DRV_OBJECT *)hDrvObject,
-pCtxt, NULL, 0);
- if (pCtxt != NULL) {
- if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pCtxt) !=
- DSP_ENOTFOUND) {
- DRV_ProcRemoveSTRMResElement(hSTRMRes, pCtxt);
- }
+ if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pr_ctxt) !=
+ DSP_ENOTFOUND) {
+ DRV_ProcRemoveSTRMResElement(hSTRMRes, pr_ctxt);
}
func_end:
#endif
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] DSPBRIDGE: Use pr_ctxt in STRM_Open
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/strm.h |4 ++-
drivers/dsp/bridge/pmgr/wcd.c |3 +-
drivers/dsp/bridge/rmgr/strm.c | 28 +++---
3 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/strm.h
b/arch/arm/plat-omap/include/dspbridge/strm.h
index 5825615..36b128d 100644
--- a/arch/arm/plat-omap/include/dspbridge/strm.h
+++ b/arch/arm/plat-omap/include/dspbridge/strm.h
@@ -59,6 +59,7 @@
#include dspbridge/dev.h
#include dspbridge/strmdefs.h
+#include dspbridge/proc.h
/*
* STRM_AllocateBuffer
@@ -307,7 +308,8 @@
*/
extern DSP_STATUS STRM_Open(struct NODE_OBJECT *hNode, u32 uDir,
u32 uIndex, IN struct STRM_ATTR *pAttr,
- OUT struct STRM_OBJECT **phStrm);
+ OUT struct STRM_OBJECT **phStrm,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* STRM_PrepareBuffer
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 4f902a3..cf3fc2d 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1626,7 +1626,8 @@ u32 STRMWRAP_Open(union Trapped_Args *args, void *pr_ctxt)
}
status = STRM_Open(args-ARGS_STRM_OPEN.hNode,
args-ARGS_STRM_OPEN.uDirection,
- args-ARGS_STRM_OPEN.uIndex, attr, pStrm);
+ args-ARGS_STRM_OPEN.uIndex, attr, pStrm,
+ pr_ctxt);
cp_to_usr(args-ARGS_STRM_OPEN.phStream, pStrm, status, 1);
return status;
}
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index b6dbe46..4a05ed4 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -626,7 +626,9 @@ DSP_STATUS STRM_Issue(struct STRM_OBJECT *hStrm, IN u8
*pBuf, u32 ulBytes,
* XDAIS socket node on the DSP.
*/
DSP_STATUS STRM_Open(struct NODE_OBJECT *hNode, u32 uDir, u32 uIndex,
- IN struct STRM_ATTR *pAttr, OUT struct STRM_OBJECT **phStrm)
+ IN struct STRM_ATTR *pAttr,
+ OUT struct STRM_OBJECT **phStrm,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
struct STRM_MGR *hStrmMgr;
struct WMD_DRV_INTERFACE *pIntfFxns;
@@ -637,13 +639,10 @@ DSP_STATUS STRM_Open(struct NODE_OBJECT *hNode, u32 uDir,
u32 uIndex,
DSP_STATUS status = DSP_SOK;
struct CMM_OBJECT *hCmmMgr = NULL; /* Shared memory manager hndl */
- #ifndef RES_CLEANUP_DISABLE
- DSP_STATUS res_status = DSP_SOK;
- u32 hProcess;
- HANDLE pCtxt = NULL;
- HANDLE hDrvObject;
- HANDLE hSTRMRes;
- #endif
+#ifndef RES_CLEANUP_DISABLE
+ HANDLE hSTRMRes;
+#endif
+
DBC_Require(cRefs 0);
DBC_Require(phStrm != NULL);
DBC_Require(pAttr != NULL);
@@ -779,18 +778,7 @@ func_cont:
(void)DeleteStrm(pStrm);
#ifndef RES_CLEANUP_DISABLE
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDrvObject, pCtxt,
-hNode, 0);
- if (pCtxt != NULL)
- DRV_ProcInsertSTRMResElement(*phStrm, hSTRMRes, pCtxt);
-
- }
+ DRV_ProcInsertSTRMResElement(*phStrm, hSTRMRes, pr_ctxt);
#endif
/* ensure we return a documented error code */
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] DSPBRIDGE: Use pr_ctxt in PROC_Detach
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/proc.h |3 ++-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/drv_interface.c |4 ++--
drivers/dsp/bridge/rmgr/proc.c | 24 ++--
4 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 1737761..f5b0c50 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -163,7 +163,8 @@
* Ensures:
* PROC Object is destroyed.
*/
- extern DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor);
+ extern DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* PROC_EnumNodes
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index ddb2aea..4f902a3 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -744,7 +744,7 @@ u32 PROCWRAP_Detach(union Trapped_Args *args, void *pr_ctxt)
GT_1trace(WCD_debugMask, GT_ENTER,
PROCWRAP_Detach: entered args\n0x%x
hProceesor \n, args-ARGS_PROC_DETACH.hProcessor);
- retVal = PROC_Detach(args-ARGS_PROC_DETACH.hProcessor);
+ retVal = PROC_Detach(args-ARGS_PROC_DETACH.hProcessor, pr_ctxt);
return retVal;
}
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 9ac7f19..7d4a6ea 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -474,7 +474,7 @@ static int __devexit omap34xx_bridge_remove(struct
platform_device *pdev)
GT_1trace(driverTrace, GT_5CLASS, ***Cleanup of
process***%d\n, pCtxtclosed-pid);
DRV_RemoveAllResources(pCtxtclosed);
- PROC_Detach(pCtxtclosed-hProcessor);
+ PROC_Detach(pCtxtclosed-hProcessor, pCtxtclosed);
pTmp = pCtxtclosed-next;
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
pCtxtclosed, (void *)pCtxtclosed-pid);
@@ -619,7 +619,7 @@ static int bridge_release(struct inode *ip, struct file
*filp)
if (DSP_SUCCEEDED(dsp_status)) {
flush_signals(current);
DRV_RemoveAllResources(pr_ctxt);
- PROC_Detach(pr_ctxt-hProcessor);
+ PROC_Detach(pr_ctxt-hProcessor, pr_ctxt);
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
pr_ctxt, (void *)pr_ctxt-pid);
} else {
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index c475436..323054f 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -220,7 +220,8 @@ DSP_STATUS PROC_CleanupAllResources(void)
***Cleanup of
process***%d\n, pCtxtclosed-pid);
if (pCtxtclosed-hProcessor)
- PROC_Detach(pCtxtclosed-hProcessor);
+ PROC_Detach(pCtxtclosed-hProcessor,
+ pCtxtclosed);
}
pCtxtclosed = pCtxtclosed-next;
}
@@ -604,32 +605,19 @@ DSP_STATUS PROC_Ctrl(DSP_HPROCESSOR hProcessor, u32 dwCmd,
* Destroys the Processor Object. Removes the notification from the Dev
* List.
*/
-DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor)
+DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor,
+ struct PROCESS_CONTEXT *pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
struct PROC_OBJECT *pProcObject = (struct PROC_OBJECT *)hProcessor;
-#ifndef RES_CLEANUP_DISABLE
- HANDLE hDRVObject;
- u32 hProcess;
- DSP_STATUS res_status = DSP_SOK;
- struct PROCESS_CONTEXT *pPctxt = NULL;
-#endif
DBC_Require(cRefs 0);
GT_1trace(PROC_DebugMask, GT_ENTER, Entered PROC_Detach, args:\n\t
hProcessor: 0x%x\n, hProcessor);
if (MEM_IsValidHandle(pProcObject, PROC_SIGNATURE)) {
#ifndef RES_CLEANUP_DISABLE
- /* Return PID instead of process handle */
- hProcess = pProcObject-hProcess;
- res_status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
- (struct DRV_OBJECT *)hDRVObject, pPctxt,
-NULL, 0);
- if (pPctxt != NULL)
- pPctxt-hProcessor = NULL;
- }
+ if (pr_ctxt != NULL)
+ pr_ctxt-hProcessor = NULL;
[PATCH 12/13] DSPBRIDGE: Use pr_ctxt in STRM_FreeBuffer_
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/strm.h |3 +-
drivers/dsp/bridge/pmgr/wcd.c |2 +-
drivers/dsp/bridge/rmgr/drv.c |2 +-
drivers/dsp/bridge/rmgr/strm.c | 33 ++
4 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/strm.h
b/arch/arm/plat-omap/include/dspbridge/strm.h
index 9929210..71ea2a6 100644
--- a/arch/arm/plat-omap/include/dspbridge/strm.h
+++ b/arch/arm/plat-omap/include/dspbridge/strm.h
@@ -175,7 +175,8 @@
* Ensures:
*/
extern DSP_STATUS STRM_FreeBuffer(struct STRM_OBJECT *hStrm,
- u8 **apBuffer, u32 uNumBufs);
+ u8 **apBuffer, u32 uNumBufs,
+ struct PROCESS_CONTEXT *pr_ctxt);
/*
* STRM_GetEventHandle
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 4fdcb18..8ba6895 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1528,7 +1528,7 @@ u32 STRMWRAP_FreeBuffer(union Trapped_Args *args, void
*pr_ctxt)
if (DSP_SUCCEEDED(status)) {
status = STRM_FreeBuffer(args-ARGS_STRM_FREEBUFFER.hStream,
-apBuffer, uNumBufs);
+apBuffer, uNumBufs, pr_ctxt);
}
cp_to_usr(args-ARGS_STRM_FREEBUFFER.apBuffer, apBuffer, status,
uNumBufs);
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index bf7d0b2..e880ea8 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -798,7 +798,7 @@ static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt)
apBuffer = MEM_Alloc((pSTRMRes-uNumBufs *
sizeof(u8 *)), MEM_NONPAGED);
status = STRM_FreeBuffer(pSTRMRes-hStream, apBuffer,
- pSTRMRes-uNumBufs);
+ pSTRMRes-uNumBufs, pCtxt);
MEM_Free(apBuffer);
}
status = STRM_Close(pSTRMRes-hStream, pCtxt);
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index d68251f..0ef43ea 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -194,7 +194,7 @@ DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
}
}
if (DSP_FAILED(status))
- STRM_FreeBuffer(hStrm, apBuffer, uAllocated);
+ STRM_FreeBuffer(hStrm, apBuffer, uAllocated, pr_ctxt);
#ifndef RES_CLEANUP_DISABLE
if (DSP_FAILED(status))
@@ -363,18 +363,14 @@ void STRM_Exit(void)
* Frees the buffers allocated for a stream.
*/
DSP_STATUS STRM_FreeBuffer(struct STRM_OBJECT *hStrm, u8 **apBuffer,
- u32 uNumBufs)
+ u32 uNumBufs, struct PROCESS_CONTEXT *pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
u32 i = 0;
- #ifndef RES_CLEANUP_DISABLE
- DSP_STATUS res_status = DSP_SOK;
- u32 hProcess;
- HANDLE pCtxt = NULL;
- HANDLE hDrvObject;
- HANDLE hSTRMRes = NULL;
- #endif
+#ifndef RES_CLEANUP_DISABLE
+ HANDLE hSTRMRes = NULL;
+#endif
DBC_Require(cRefs 0);
DBC_Require(apBuffer != NULL);
@@ -398,22 +394,9 @@ DSP_STATUS STRM_FreeBuffer(struct STRM_OBJECT *hStrm, u8
**apBuffer,
}
}
#ifndef RES_CLEANUP_DISABLE
- /* Update the node and stream resource status */
- /* Return TGID instead of process handle */
- hProcess = current-tgid;
-
- res_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDrvObject, pCtxt,
-NULL, 0);
- if (pCtxt != NULL) {
- if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pCtxt) !=
- DSP_ENOTFOUND) {
- DRV_ProcUpdateSTRMRes(uNumBufs-i, hSTRMRes,
-pCtxt);
- }
- }
+ if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pr_ctxt) !=
+ DSP_ENOTFOUND) {
+ DRV_ProcUpdateSTRMRes(uNumBufs-i, hSTRMRes, pr_ctxt);
}
#endif
return status;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] DSPBRIDGE: Removal of DRV_GetProcContext
Use filp-private_data instead of DRV_GetProcContext
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
.../plat-omap/include/dspbridge/resourcecleanup.h |5 --
drivers/dsp/bridge/rmgr/drv.c | 71
2 files changed, 0 insertions(+), 76 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index 5592f38..9ddf1b3 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -35,11 +35,6 @@ extern DSP_STATUS DRV_ProcUpdatestate(HANDLE pCtxt,
extern DSP_STATUS DRV_ProcSetPID(HANDLE pCtxt, s32 hProcess);
-extern DSP_STATUS DRV_GetProcContext(u32 phProcess,
- struct DRV_OBJECT *hDrvObject,
- HANDLE hPCtxt, DSP_HNODE hNode,
- u32 pMapAddr);
-
extern DSP_STATUS DRV_RemoveAllResources(HANDLE pPctxt);
extern DSP_STATUS DRV_RemoveProcContext(struct DRV_OBJECT *hDRVObject,
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index e880ea8..0432a4b 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -198,77 +198,6 @@ DSP_STATUS DRV_GetProcCtxtList(struct PROCESS_CONTEXT
**pPctxt,
return status;
}
-
-
-/* Get a particular process context based on process handle (phProcess) */
-DSP_STATUS DRV_GetProcContext(u32 phProcess,
- struct DRV_OBJECT *hDrvObject,
- HANDLE hPCtxt, DSP_HNODE hNode,
- u32 pMapAddr)
-{
- struct PROCESS_CONTEXT **pCtxt = (struct PROCESS_CONTEXT **)hPCtxt;
- DSP_STATUS status = DSP_SOK;
- struct PROCESS_CONTEXT *pCtxtList = NULL;
- struct DRV_OBJECT *pDrvObject = (struct DRV_OBJECT *)hDrvObject;
- struct NODE_RES_OBJECT *pTempNode2 = NULL;
- struct NODE_RES_OBJECT *pTempNode = NULL;
- struct DMM_RES_OBJECT *pTempDMM2 = NULL;
- struct DMM_RES_OBJECT *pTempDMM = NULL;
- s32 pCtxtFound = 0;
-
- DBC_Assert(pDrvObject != NULL);
- pCtxtList = pDrvObject-procCtxtList;
- GT_0trace(curTrace, GT_ENTER, 2DRV_GetProcContext: 2);
- while ((pCtxtList != NULL) (pCtxtList-pid != phProcess)) {
- pCtxtList = pCtxtList-next;
- GT_0trace(curTrace, GT_ENTER, 2DRV_GetProcContext: 3);
- }
- if (pCtxtList == NULL) {
- if (hNode != NULL) {
- pCtxtList = pDrvObject-procCtxtList;
- while ((pCtxtList != NULL) (pCtxtFound == 0)) {
- pTempNode = pCtxtList-pNodeList;
- while ((pTempNode != NULL)
- (pTempNode-hNode != hNode)) {
- pTempNode2 = pTempNode;
- pTempNode = pTempNode-next;
- }
- if (pTempNode != NULL) {
- pCtxtFound = 1;
- status = DSP_SOK;
- } else {
- pCtxtList = pCtxtList-next;
- }
- }
- } else if ((pMapAddr != 0) (pCtxtFound == 0)) {
- pCtxtList = pDrvObject-procCtxtList;
- while ((pCtxtList != NULL) (pCtxtFound == 0)) {
- pTempDMM = pCtxtList-pDMMList;
- while ((pTempDMM != NULL)
-(pTempDMM-ulDSPAddr != pMapAddr)) {
- pTempDMM2 = pTempDMM;
- pTempDMM = pTempDMM-next;
- }
- if (pTempDMM != NULL) {
- pCtxtFound = 1;
- status = DSP_SOK;
- } else {
- pCtxtList = pCtxtList-next;
- }
- }
- if (pCtxtList == NULL)
- status = DSP_ENOTFOUND;
-
- }
- } else{
- status = DSP_SOK;
- }
- GT_0trace(curTrace, GT_ENTER, 2DRV_GetProcContext: 4);
- *pCtxt = pCtxtList;
- return status;
-}
-
-
/* Add a new process context to process context list */
DSP_STATUS DRV_InsertProcContext(struct DRV_OBJECT *hDrVObject, HANDLE hPCtxt)
{
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: pm: Fix overflow when doing powerdomain deps lookups.
Signed-off-by: Mike Chan m...@android.com
---
arch/arm/mach-omap2/powerdomain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 0334609..6077629 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -90,7 +90,7 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
if (!pwrdm || !deps || !omap_chip_is(pwrdm-omap_chip))
return ERR_PTR(-EINVAL);
- for (pd = deps; pd; pd++) {
+ for (pd = deps; pd-pwrdm_name; pd++) {
if (!omap_chip_is(pd-omap_chip))
continue;
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
