[PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Ajay Kumar Gupta]

Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.

Fixing it by starting DMAs using musb_h_tx_dma_start().

Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Babu Ravi ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
 drivers/usb/musb/musb_host.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index cf94511..e3ab40a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
} else  if (usb_pipeisoc(pipe)  dma) {
if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
-   offset, length))
+   offset, length)) {
+   if (is_cppi_enabled() || tusb_dma_omap())
+   musb_h_tx_dma_start(hw_ep);
return;
+   }
} else  if (tx_csr  MUSB_TXCSR_DMAENAB) {
DBG(1, not complete, but DMA enabled?\n);
return;
-- 
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

Re: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support

[David Brownell]

On Sunday 05 July 2009, Hemanth V wrote:
 Do you see any major changes required to support
 slave mode in the SPI core driver.

There *is* no such thing as a SPI core driver...


 We are able to 
 use the existing interface for slave mode also, but
 some APIs/ Structures could be made generic.

Three things are obvious:

 - A spi_master is not a slave side driver!

 - Control model would need to be inverted
* Chip select would be one input,
  not N outputs
* No clock rate controls at all
* latency issues ... driver can't necessarily
  respond quickly enough to guarantee no data
  loss (FIFOs help)
* Can't re-use /dev/spidev*
* Request queue would have a very different role

 - Some primitives are likely missing, for flow
   control (when hardware has a READY handshake)

I think a few proposals for how to handle slave
side have been circulated.


--
To unsubscribe from this list: send the line unsubscribe 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] flush the function in sdram is not correct because sram is changed.

[ye janboe]

resend because little format issue.

From fc5e771b808b5bf094846051a1c59c7e5e8ec149 Mon Sep 17 00:00:00 2001
From: janboe janboe...@gmail.com
Date: Fri, 28 Aug 2009 13:50:57 +0800
Subject: [PATCH] flush the function in sdram is not correct because
sram is changed.

Signed-off-by: janboe janboe...@gmail.com
---
 arch/arm/plat-omap/sram.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index f2b0fa6..f549d8a 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size)
omap_sram_ceil -= size;
omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
memcpy((void *)omap_sram_ceil, start, size);
-   flush_icache_range((unsigned long)start, (unsigned long)(start + size));
+   flush_icache_range((unsigned long)omap_sram_ceil,
+   (unsigned long)(omap_sram_ceil + size));

return (void *)omap_sram_ceil;
 }
-- 
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517

[Peter Ujfalusi]

On Thursday 27 August 2009 14:12:53 ext Jarkko Nikula wrote:
 On Thu, 27 Aug 2009 15:07:32 +0530

 Aggarwal, Anuj anuj.aggar...@ti.com wrote:
  Thanks Jarkko, the patch works for me.

 This is nice to hear.

 Can you, Peter or who has access to 2420 and 2430 TRMs to verify is the
 DEVCONF0 bits 3 and 4 selecting there also the McBSP1 CLKR and FSR
 sources like my patch is now assuming for all OMAP2-3.

On OMAP2:
DEVCONF:3 MCBSP1_CLKR
DEVCONF:4 MCBSP1_FSR

So it is correct for  both OMAP2 and OMAP3.

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] OMAP: Zoom2: Release Dbg board detect gpio

[Kevin Hilman]

Vikram Pandita vikram.pand...@ti.com writes:

 Release the Dbg board detection gpio once its purpose is served

 Signed-off-by: Vikram Pandita vikram.pand...@ti.com

Looks fine, I'll pull into my fixes queue.

Thanks,

Kevin

 ---
  arch/arm/mach-omap2/board-zoom-debugboard.c |7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c 
 b/arch/arm/mach-omap2/board-zoom-debugboard.c
 index 4dd714d..d80e448 100644
 --- a/arch/arm/mach-omap2/board-zoom-debugboard.c
 +++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
 @@ -130,6 +130,7 @@ static inline void __init zoom2_init_quaduart(void)
  static inline int omap_zoom2_debugboard_detect(void)
  {
   int debug_board_detect = 0;
 + int ret = 1;
  
   debug_board_detect = ZOOM2_SMSC911X_GPIO;
  
 @@ -141,10 +142,10 @@ static inline int omap_zoom2_debugboard_detect(void)
   gpio_direction_input(debug_board_detect);
  
   if (!gpio_get_value(debug_board_detect)) {
 - gpio_free(debug_board_detect);
 - return 0;
 + ret = 0;
   }
 - return 1;
 + gpio_free(debug_board_detect);
 + return ret;
  }
  
  static struct platform_device *zoom2_devices[] __initdata = {
 -- 
 1.6.3.3.334.g916e1

 --
 To unsubscribe from this list: send the line unsubscribe 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

[PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK position

[Thara Gopinath]

MPU power domain bank 0 bits are displayed in position of bank 1
in PWRSTS and PREPWRSTS registers. So read them from correct
position

Signed-off-by: Thara Gopinath th...@ti.com
---
Patch refresh issue.

 arch/arm/mach-omap2/powerdomain.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 2594cbf..6c5fee9 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -971,6 +971,16 @@ int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 
bank)
return -EEXIST;
 
/*
+* In 3430, for MPU domain bank 0 status bits
+* are displayed in the position of bank1 status bits
+* in PWST  . So the hack. Think of a cleaner
+* way of doing this
+*/
+   if (cpu_is_omap34xx())
+   if (!strcmp(mpu_pwrdm, pwrdm-name))
+   bank = 1;
+
+   /*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
 * but the type of value returned is the same for each
@@ -1018,6 +1028,15 @@ int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, 
u8 bank)
return -EEXIST;
 
/*
+* In 3430, for MPU domain bank 0 status bits
+* are displayed in the position of bank1 status bits
+* in PREPWST  . So the hack. Think of a cleaner
+* way of doing this
+*/
+   if (cpu_is_omap34xx())
+   if (!strcmp(mpu_pwrdm, pwrdm-name))
+   bank = 1;
+   /*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
 * but the type of value returned is the same for each
-- 
1.5.4.7

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] OMAP: misc. fixes for 2.6.32

[Kevin Hilman]

Tony,

I pushed a couple more fixes to my pm-upstream/fixes-32 branch.  You've
already pulled this branch into your for-next, so a re-pull will get
you just these two additional patches.

Thanks,

Kevin


Reddy, Teerth (1):
  OMAP3: PM: add T2 interrupt line mux setting, and enable on 3430SDP

Vikram Pandita (1):
  OMAP: Zoom2: release debug board detect gpio line

 arch/arm/mach-omap2/board-3430sdp.c |6 ++
 arch/arm/mach-omap2/board-zoom-debugboard.c |7 ---
 arch/arm/mach-omap2/mux.c   |5 +
 arch/arm/plat-omap/include/mach/mux.h   |3 +++
 4 files changed, 18 insertions(+), 3 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] OMAP3: PM: add T2 interrupt line mux setting, and enable on 3430SDP

[Kevin Hilman]

From: Reddy, Teerth tee...@ti.com

This patch changes for setting the padconf value for sys_nirq line
which is connected to T2 INTR1.  This will fix the T2 keypad wakeup
issue on OMAP3 SDP.

Signed-off-by: Teerth Reddy tee...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-3430sdp.c   |6 ++
 arch/arm/mach-omap2/mux.c |5 +
 arch/arm/plat-omap/include/mach/mux.h |3 +++
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 7e9b76c..31d9f56 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -473,6 +473,11 @@ static inline void board_smc91x_init(void)
 
 #endif
 
+static void enable_board_wakeup_source(void)
+{
+   omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+}
+
 static void __init omap_3430sdp_init(void)
 {
omap3430_i2c_init();
@@ -490,6 +495,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
usb_musb_init();
board_smc91x_init();
+   enable_board_wakeup_source();
 }
 
 static void __init omap_3430sdp_map_io(void)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f63f3a2..2daa595 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -542,6 +542,11 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT2, 0x5e8,
OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+
+/* SYS_NIRQ T2 INT1 */
+MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
+   OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
+   OMAP34XX_MUX_MODE0)
 };
 
 #define OMAP34XX_PINS_SZ   ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h 
b/arch/arm/plat-omap/include/mach/mux.h
index 2c57bad..98dfab6 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -885,6 +885,9 @@ enum omap34xx_index {
AH9_3430_MMC3_DAT1,
AF13_3430_MMC3_DAT2,
AF13_3430_MMC3_DAT3,
+
+   /* SYS_NIRQ T2 INT1 */
+   AF26_34XX_SYS_NIRQ,
 };
 
 struct omap_mux_cfg {
-- 
1.6.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 2/2] OMAP: Zoom2: release debug board detect gpio line

[Kevin Hilman]

From: Vikram Pandita vikram.pand...@ti.com

Release the Dbg board detection gpio once its purpose is served

Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-zoom-debugboard.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c 
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index e0948c9..1f13e2a 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -129,6 +129,7 @@ static inline void __init zoom2_init_quaduart(void)
 static inline int omap_zoom2_debugboard_detect(void)
 {
int debug_board_detect = 0;
+   int ret = 1;
 
debug_board_detect = ZOOM2_SMSC911X_GPIO;
 
@@ -140,10 +141,10 @@ static inline int omap_zoom2_debugboard_detect(void)
gpio_direction_input(debug_board_detect);
 
if (!gpio_get_value(debug_board_detect)) {
-   gpio_free(debug_board_detect);
-   return 0;
+   ret = 0;
}
-   return 1;
+   gpio_free(debug_board_detect);
+   return ret;
 }
 
 static struct platform_device *zoom2_devices[] __initdata = {
-- 
1.6.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] flush the function in sdram is not correct because sram is changed.

[Paul Walmsley]

Hello janboe,

On Fri, 28 Aug 2009, ye janboe wrote:

 From f10090bf307066f1317d7152c6f9a6f395007d4a Mon Sep 17 00:00:00 2001
 From: janboe janboe...@gmail.com
 Date: Fri, 28 Aug 2009 13:50:57 +0800
 Subject: [PATCH] flush the function in sdram is not correct because
 sram is changed.
 
 Signed-off-by: janboe janboe...@gmail.com

The technical part of the patch makes sense, but the patch format needs 
to be changed.  

Your subject line should start with something like [PATCH] OMAP SRAM:, 
and you should add a short patch description that describes the bug and 
why the patch does what it does to fix it.

Also your post should not include the From, Date, and Subject lines 
inside the E-mail.  You might wish to consider using 'git send-email' or 
at least 'git format-patch' if possible.


- Paul

 ---
  arch/arm/plat-omap/sram.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
 index f2b0fa6..253fcf7 100644
 --- a/arch/arm/plat-omap/sram.c
 +++ b/arch/arm/plat-omap/sram.c
 @@ -270,7 +270,7 @@ void * omap_sram_push(void * start, unsigned long size)
 omap_sram_ceil -= size;
 omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 memcpy((void *)omap_sram_ceil, start, size);
 -   flush_icache_range((unsigned long)start, (unsigned long)(start + 
 size));
 +   flush_icache_range((unsigned long)omap_sram_ceil, (unsigned
 long)(omap_sram_ceil + size));
 
 return (void *)omap_sram_ceil;
  }
 -- 
 1.6.3.3
 


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] flush the right address after memcpy in omap_sram_push

[ye janboe]

Signed-off-by: janboe janboe...@gmail.com
---
 arch/arm/plat-omap/sram.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index f2b0fa6..f549d8a 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size)
omap_sram_ceil -= size;
omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
memcpy((void *)omap_sram_ceil, start, size);
-   flush_icache_range((unsigned long)start, (unsigned long)(start + size));
+   flush_icache_range((unsigned long)omap_sram_ceil,
+   (unsigned long)(omap_sram_ceil + size));

return (void *)omap_sram_ceil;
 }
--
To unsubscribe from this list: send the line unsubscribe 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] flush the function in sdram is not correct because sram is changed.

[ye janboe]

Hi, Paul

I resent the patch after fix the format issue.

Please help to review it.

Thanks

Janboe

2009/8/28 Paul Walmsley p...@pwsan.com:
 Hello janboe,

 On Fri, 28 Aug 2009, ye janboe wrote:

 From f10090bf307066f1317d7152c6f9a6f395007d4a Mon Sep 17 00:00:00 2001
 From: janboe janboe...@gmail.com
 Date: Fri, 28 Aug 2009 13:50:57 +0800
 Subject: [PATCH] flush the function in sdram is not correct because
 sram is changed.

 Signed-off-by: janboe janboe...@gmail.com

 The technical part of the patch makes sense, but the patch format needs
 to be changed.

 Your subject line should start with something like [PATCH] OMAP SRAM:,
 and you should add a short patch description that describes the bug and
 why the patch does what it does to fix it.

 Also your post should not include the From, Date, and Subject lines
 inside the E-mail.  You might wish to consider using 'git send-email' or
 at least 'git format-patch' if possible.


 - Paul

 ---
  arch/arm/plat-omap/sram.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
 index f2b0fa6..253fcf7 100644
 --- a/arch/arm/plat-omap/sram.c
 +++ b/arch/arm/plat-omap/sram.c
 @@ -270,7 +270,7 @@ void * omap_sram_push(void * start, unsigned long size)
         omap_sram_ceil -= size;
         omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
         memcpy((void *)omap_sram_ceil, start, size);
 -       flush_icache_range((unsigned long)start, (unsigned long)(start + 
 size));
 +       flush_icache_range((unsigned long)omap_sram_ceil, (unsigned
 long)(omap_sram_ceil + size));

         return (void *)omap_sram_ceil;
  }
 --
 1.6.3.3




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH v3]OMAP3:PM: Fix OPP scale logic

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 While switching from higher OPP to lower OPP,
 current scale logic can fail by switching to lower
 voltage while frequency remains at old value.

 This patch adds a cleaner recovery logic and
 additional freq dpll checks. This changes
 program_freq_opp return type in the process
 for program_opp to handle error in a consistent
 manner.

 NOTE: I moved the *cur_opp setting to under the
 scratchpad locked region to allow for code
 simplicity - i wonder if anyone sees an issue with it

 Thanks to Roger in patiently catching my goofups :(

 Tested on:rx-51, ported to pm branch - untested linux-omap
 Patch generated on linux-omap pm branch, commit:
 7e7377395d6b4576341a6939bf2179f3946f2ea0

 Signed-off-by: Nishanth Menon n...@ti.com
 Cc: Roger Quadros ext-roger.quad...@nokia.com
 Cc: Kevin Hilman khil...@deeprootsystems.com 
 Cc: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/mach-omap2/resource34xx.c |   61 
 +++-
  1 files changed, 46 insertions(+), 15 deletions(-)

The fix looks good for adding the extra checks, but can you do some
more testing on current PM branch?  This currently doesn't even
compile on current PM branch.

Thanks,

Kevin


[...]
  CC  arch/arm/mach-omap2/resource34xx.o
distcc[24405] ERROR: compile /tmp/khilman/.ccache/resource34.tmp.vence.24379.i 
on localhost failed
/opt/home/khilman/work.local/kernel/omap/pm-next/arch/arm/mach-omap2/resource34xx.c:
 In function 'program_opp':
/opt/home/khilman/work.local/kernel/omap/pm-next/arch/arm/mach-omap2/resource34xx.c:333:
 error: 'PRCM_VDD1' undeclared (first use in this function)
/opt/home/khilman/work.local/kernel/omap/pm-next/arch/arm/mach-omap2/resource34xx.c:333:
 error: (Each undeclared identifier is reported only once
/opt/home/khilman/work.local/kernel/omap/pm-next/arch/arm/mach-omap2/resource34xx.c:333:
 error: for each function it appears in.)
make[2]: *** [arch/arm/mach-omap2/resource34xx.o] Error 1
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: *** Waiting for unfinished jobs

--
To unsubscribe from this list: send the line unsubscribe 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] flush the function in sdram is not correct because sram is changed.

[Paul Walmsley]

Hi Janboe,

On Fri, 28 Aug 2009, ye janboe wrote:

 Hi, Paul
 
 I resent the patch after fix the format issue.
 
 Please help to review it.

Thanks, you fixed one issue, but this other one still needs to be fixed:

  Your subject line should start with something like [PATCH] OMAP SRAM:,
  and you should add a short patch description that describes the bug and
  why the patch does what it does to fix it.

- Paul

 
 Thanks
 
 Janboe
 
 2009/8/28 Paul Walmsley p...@pwsan.com:
  Hello janboe,
 
  On Fri, 28 Aug 2009, ye janboe wrote:
 
  From f10090bf307066f1317d7152c6f9a6f395007d4a Mon Sep 17 00:00:00 2001
  From: janboe janboe...@gmail.com
  Date: Fri, 28 Aug 2009 13:50:57 +0800
  Subject: [PATCH] flush the function in sdram is not correct because
  sram is changed.
 
  Signed-off-by: janboe janboe...@gmail.com
 
  The technical part of the patch makes sense, but the patch format needs
  to be changed.
 
  Your subject line should start with something like [PATCH] OMAP SRAM:,
  and you should add a short patch description that describes the bug and
  why the patch does what it does to fix it.
 
  Also your post should not include the From, Date, and Subject lines
  inside the E-mail.  You might wish to consider using 'git send-email' or
  at least 'git format-patch' if possible.
 
 
  - Paul
 
  ---
   arch/arm/plat-omap/sram.c |    2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
  index f2b0fa6..253fcf7 100644
  --- a/arch/arm/plat-omap/sram.c
  +++ b/arch/arm/plat-omap/sram.c
  @@ -270,7 +270,7 @@ void * omap_sram_push(void * start, unsigned long size)
          omap_sram_ceil -= size;
          omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
          memcpy((void *)omap_sram_ceil, start, size);
  -       flush_icache_range((unsigned long)start, (unsigned long)(start + 
  size));
  +       flush_icache_range((unsigned long)omap_sram_ceil, (unsigned
  long)(omap_sram_ceil + size));
 
          return (void *)omap_sram_ceil;
   }
  --
  1.6.3.3
 
 
 
 
 


- Paul

[PATCH] OMAP SRAM: flush the right address after memcpy in omap_sram_push

[ye janboe]

the original flush operation is to flush the function address which is
copied from.
But we do not change the function code and it is not necessary to flush it.

Signed-off-by: janboe janboe...@gmail.com
---
 arch/arm/plat-omap/sram.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index f2b0fa6..f549d8a 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size)
omap_sram_ceil -= size;
omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
memcpy((void *)omap_sram_ceil, start, size);
-   flush_icache_range((unsigned long)start, (unsigned long)(start + size));
+   flush_icache_range((unsigned long)omap_sram_ceil,
+   (unsigned long)(omap_sram_ceil + size));

return (void *)omap_sram_ceil;
 }
--
To unsubscribe from this list: send the line unsubscribe 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] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello.

Ajay Kumar Gupta wrote:


Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.
  


  That's not true.


Fixing it by starting DMAs using musb_h_tx_dma_start().

Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Babu Ravi ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
  


  NAK.


diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index cf94511..e3ab40a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
} else  if (usb_pipeisoc(pipe)  dma) {
if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
-   offset, length))
+   offset, length)) {
+   if (is_cppi_enabled() || tusb_dma_omap())
+   musb_h_tx_dma_start(hw_ep);
return;
  


  It will have been already started by this moment -- from 
musb_start_urb() which is enough . Otherwise it wouldn't work, and I've 
made sure it *does* work.


WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Gupta, Ajay Kumar]

 -Original Message-
 From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
 Sent: Friday, August 28, 2009 2:53 PM
 To: Gupta, Ajay Kumar
 Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
 felipe.ba...@nokia.com; davi...@pacbell.net; Subbrathnam, Swaminathan; B,
 Ravi
 Subject: Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs
 
 Hello.
 
 Ajay Kumar Gupta wrote:
 
  Isochronous Tx DMA is getting programmed but never getting started
  for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.
 
 
That's not true.

We have tested and it doesn't work with current driver. Have you tested it and 
was it working for you ?

 
  Fixing it by starting DMAs using musb_h_tx_dma_start().
 
  Signed-off-by: Swaminathan S swami.i...@ti.com
  Signed-off-by: Babu Ravi ravib...@ti.com
  Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
 
 
NAK.
 
  diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
  index cf94511..e3ab40a 100644
  --- a/drivers/usb/musb/musb_host.c
  +++ b/drivers/usb/musb/musb_host.c
  @@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
  return;
  } else  if (usb_pipeisoc(pipe)  dma) {
  if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
  -   offset, length))
  +   offset, length)) {
  +   if (is_cppi_enabled() || tusb_dma_omap())
  +   musb_h_tx_dma_start(hw_ep);
  return;
 
 
It will have been already started by this moment -- from
 musb_start_urb() which is enough . Otherwise it wouldn't work, and I've
 made sure it *does* work.


This part is being done at musb_host_rx() doing next packet programming within 
same urb and *not* starting next urb. Thus musb_start_urb() doesn't come into 
this path. So it wouldn't start the DMAs.

In case of PIO, it does load the FIFO and sets the TXPKTREADY.

-Ajay

 
 WBR, Sergei
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello, I wrote:


Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.   


  That's not true.


  Well, this is only true iff URB_ISO_ASAP flag is *not* set for an 
URB. In this case, PIO is also not being started, so you should fix this 
too.



Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Babu Ravi ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
  

Fixing it by starting DMAs using musb_h_tx_dma_start().

  NAK.


  Still NAK...

WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Gupta, Ajay Kumar]

 This part is being done at musb_host_rx() 

musb_host_tx() ofcourse.

 doing next packet programming
 within same urb and *not* starting next urb. Thus musb_start_urb() doesn't
 come into this path. So it wouldn't start the DMAs.
 
 In case of PIO, it does load the FIFO and sets the TXPKTREADY.
 
 -Ajay
 
 
  WBR, Sergei
 
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb 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] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello.

Gupta, Ajay Kumar wrote:

-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Sent: Friday, August 28, 2009 2:53 PM
To: Gupta, Ajay Kumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
felipe.ba...@nokia.com; davi...@pacbell.net; Subbrathnam, Swaminathan; B,
Ravi
Subject: Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

Hello.

Ajay Kumar Gupta wrote:



Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.

  

   That's not true.



We have tested and it doesn't work with current driver. Have you tested it and 
was it working for you ?
  


  Not with the current driver, I must admit. I'll try it today...


diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index cf94511..e3ab40a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
} else  if (usb_pipeisoc(pipe)  dma) {
if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
-   offset, length))
+   offset, length)) {
+   if (is_cppi_enabled() || tusb_dma_omap())
+   musb_h_tx_dma_start(hw_ep);
return;

  

   It will have been already started by this moment -- from
musb_start_urb() which is enough . Otherwise it wouldn't work, and I've
made sure it *does* work.



This part is being done at musb_host_rx()


  You're doing it in musb_host_tx() actually. Although musb_host_rx() 
is also broken WRT the isochronous transfers.



 doing next packet programming within same urb and *not* starting next urb. 
Thus musb_start_urb() doesn't come into this path.


  What? Read the code, please -- musb_start_urb() call should always 
precede musb_host_tx() which handles the DMA interrupt. Unless something 
clears DMAReqEnab after musb_start_urb() call, setting it only once 
should work.



So it wouldn't start the DMAs.
  


  How musb_host_tx() can be called without musb_start_urb()?


In case of PIO, it does load the FIFO and sets the TXPKTREADY.
  


  Only is URB_ISO_ASAP is not set.

WBR, Sergei


-Ajay


WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Subbrathnam, Swaminathan]

Sergei,
Pl. do the required testing with and without the patch on the current 
tree for ISO transfers in Tx direction.  As Ajay indicated we have done the 
same and found it not working and hence the fix.

ISO Rx is also broken and the patch for fixing the same is on the way.  
Since that fix involves some bit of re-structuring it is delayed a bit.

We can discuss further if need be.

Regards
swami

-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] 
Sent: Friday, August 28, 2009 3:33 PM
To: Gupta, Ajay Kumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; 
felipe.ba...@nokia.com; davi...@pacbell.net; Subbrathnam, Swaminathan; B, Ravi
Subject: Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

Hello.

Gupta, Ajay Kumar wrote:
 -Original Message-
 From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
 Sent: Friday, August 28, 2009 2:53 PM
 To: Gupta, Ajay Kumar
 Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
 felipe.ba...@nokia.com; davi...@pacbell.net; Subbrathnam, Swaminathan; B,
 Ravi
 Subject: Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

 Hello.

 Ajay Kumar Gupta wrote:

 
 Isochronous Tx DMA is getting programmed but never getting started
 for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.

   
That's not true.
 

 We have tested and it doesn't work with current driver. Have you tested it 
 and was it working for you ?
   

   Not with the current driver, I must admit. I'll try it today...

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index cf94511..e3ab40a 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
 return;
 } else  if (usb_pipeisoc(pipe)  dma) {
 if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
 -   offset, length))
 +   offset, length)) {
 +   if (is_cppi_enabled() || tusb_dma_omap())
 +   musb_h_tx_dma_start(hw_ep);
 return;

   
It will have been already started by this moment -- from
 musb_start_urb() which is enough . Otherwise it wouldn't work, and I've
 made sure it *does* work.
 

 This part is being done at musb_host_rx()

   You're doing it in musb_host_tx() actually. Although musb_host_rx() 
is also broken WRT the isochronous transfers.

  doing next packet programming within same urb and *not* starting next urb. 
 Thus musb_start_urb() doesn't come into this path.

   What? Read the code, please -- musb_start_urb() call should always 
precede musb_host_tx() which handles the DMA interrupt. Unless something 
clears DMAReqEnab after musb_start_urb() call, setting it only once 
should work.

 So it wouldn't start the DMAs.
   

   How musb_host_tx() can be called without musb_start_urb()?

 In case of PIO, it does load the FIFO and sets the TXPKTREADY.
   

   Only is URB_ISO_ASAP is not set.

WBR, Sergei

 -Ajay

WBR, Sergei



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello, I wrote:


In case of PIO, it does load the FIFO and sets the TXPKTREADY.
  


  Only is URB_ISO_ASAP is not set.


  This should read only if URB_ISO_ASAP is set. :-/

WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Gupta, Ajay Kumar]

   This part is being done at musb_host_rx()
 
 You're doing it in musb_host_tx() actually. Although musb_host_rx()
  is also broken WRT the isochronous transfers.
 
doing next packet programming within same urb and *not* starting next
  urb. Thus musb_start_urb() doesn't come into this path.
 
 What? Read the code, please -- musb_start_urb() call should always
  precede musb_host_tx() which handles the DMA interrupt. Unless something
  clears DMAReqEnab after musb_start_urb() call, setting it only once
  should work.
 
 musb_start_urb() call does precede musb_host_tx() but when urb is
 *completed*.

I think you are aware that there are multiple packets within same isochronous 
urb and musb_start_urb() programs only for first packet.


case USB_ENDPOINT_XFER_ISOC:
qh-iso_idx = 0;
qh-frame = 0;
offset = urb-iso_frame_desc[0].offset;
len = urb-iso_frame_desc[0].length;



-Ajay

 
 check the 'done' flag and musb_advance_schedule getting called in the
 path.
 
 if (done) {
 /* set status */
 urb-status = status;
 urb-actual_length = qh-offset;
 musb_advance_schedule(musb, urb, hw_ep, USB_DIR_OUT);
 return;
 } else  if (usb_pipeisoc(pipe)  dma) {
  if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
 offset, length)) {
 if (is_cppi_enabled() || tusb_dma_omap()
 || is_cppi41_enabled())
 musb_h_tx_dma_start(hw_ep);
return;
 }
 
 
 
   So it wouldn't start the DMAs.
  
 
 How musb_host_tx() can be called without musb_start_urb()?
 
   In case of PIO, it does load the FIFO and sets the TXPKTREADY.
  
 
 Only is URB_ISO_ASAP is not set.
 
  WBR, Sergei
 
   -Ajay
 
  WBR, Sergei
 
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb 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] OMAP SRAM: flush the right address after memcpy in omap_sram_push

[Paul Walmsley]

On Fri, 28 Aug 2009, ye janboe wrote:

 the original flush operation is to flush the function address which is
 copied from.
 But we do not change the function code and it is not necessary to flush it.
 
 Signed-off-by: janboe janboe...@gmail.com

Acked-by: Paul Walmsley p...@pwsan.com

thanks Janboe.

Tony, you want to take this one, or do you want me to?

- Paul


 ---
  arch/arm/plat-omap/sram.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
 index f2b0fa6..f549d8a 100644
 --- a/arch/arm/plat-omap/sram.c
 +++ b/arch/arm/plat-omap/sram.c
 @@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size)
 omap_sram_ceil -= size;
 omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 memcpy((void *)omap_sram_ceil, start, size);
 -   flush_icache_range((unsigned long)start, (unsigned long)(start + 
 size));
 +   flush_icache_range((unsigned long)omap_sram_ceil,
 +   (unsigned long)(omap_sram_ceil + size));
 
 return (void *)omap_sram_ceil;
  }
 


--
To unsubscribe from this list: send the line unsubscribe 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] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello.

Gupta, Ajay Kumar wrote:


diff --git a/drivers/usb/musb/musb_host.c
  

b/drivers/usb/musb/musb_host.c


index cf94511..e3ab40a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
} else  if (usb_pipeisoc(pipe)  dma) {
if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
-   offset, length))
+   offset, length)) {
+   if (is_cppi_enabled() || tusb_dma_omap())
+   musb_h_tx_dma_start(hw_ep);
return;


  

   It will have been already started by this moment -- from
musb_start_urb() which is enough . Otherwise it wouldn't work, and I've
made sure it *does* work.



This part is being done at musb_host_rx()
  

   You're doing it in musb_host_tx() actually. Although musb_host_rx()
is also broken WRT the isochronous transfers.



 doing next packet programming within same urb and *not* starting next
  

urb. Thus musb_start_urb() doesn't come into this path.

   What? Read the code, please -- musb_start_urb() call should always
precede musb_host_tx() which handles the DMA interrupt. Unless something
clears DMAReqEnab after musb_start_urb() call, setting it only once
should work.



musb_start_urb() call does precede musb_host_tx() but when urb is *completed*.

check the 'done' flag and musb_advance_schedule getting called in the path.

if (done) {
/* set status */
urb-status = status;
urb-actual_length = qh-offset;
musb_advance_schedule(musb, urb, hw_ep, USB_DIR_OUT);
return;
} else  if (usb_pipeisoc(pipe)  dma) {
 if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
offset, length)) {
if (is_cppi_enabled() || tusb_dma_omap()
|| is_cppi41_enabled())
musb_h_tx_dma_start(hw_ep);
   return;
}
  


  Sigh, that will be musb_start_urb() for the *next* URB after a 
completed one... Someone must have called it for the *current* URB when 
starting an ISO transfer.
This call to musb_tx_dma_program() is only done for the 2nd and 
subsequent data fragments of an URB -- the call for the 1st fragment 
happens elsewhere, from musb_ep_program().

There are basically two Tx URB starting paths within the driver:

1) musb_urb_enqueue() - musb_schedule() - musb_start_urb() - 
musb_h_tx_dma_start();
2) musb_host_tx() - musb_advance_schedule() - musb_start_urb() - 
musb_h_tx_dma_start().


  Transfer of the 1st fragment is started on either of these patch, 
depending on whether there was URBs already queued at the time of 
submitting the new URB; after that DMAReqMode/DMAReqEnab bits should 
remain set after the first musb_h_tx_dma_start() call, so that calling 
musb_tx_dma_program() should be enough for the subsequent fragments. So 
your statement that Isochronous Tx DMA is getting programmed but never 
getting started for CPPI and TUSB DMAs is an overstatement in any case 
-- first fragment must be properly started.


WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517

[Jarkko Nikula]

On Fri, 28 Aug 2009 09:55:01 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:

  Can you, Peter or who has access to 2420 and 2430 TRMs to verify is the
  DEVCONF0 bits 3 and 4 selecting there also the McBSP1 CLKR and FSR
  sources like my patch is now assuming for all OMAP2-3.
 
 On OMAP2:
 DEVCONF:3 MCBSP1_CLKR
 DEVCONF:4 MCBSP1_FSR
 
 So it is correct for  both OMAP2 and OMAP3.
 
Good :-)

Are you Mark fine with the patch [] where the snd_soc_dai_set_sysclk
is used to specify source pin for CLKR and FSR?


-- 
Jarkko

1.
http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020771.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 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space

[Shilimkar, Santosh]

Tony, Kevin,

Did you happen to go through this series?

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
 Sent: Sunday, August 23, 2009 7:00 PM
 To: Tony Lindgren; Kevin Hilman
 Cc: linux-omap@vger.kernel.org
 Subject: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space
 
 All,
 
 This patch series is intended to free up the kernel IO address space for
 OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's
 omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and
 OMAP4430 platform.
 
 Some more combinations are possible but to make it uniform across
 OMAP2, OMAP3 and OMAP4, these io combinations are chosen.
 
 If needed documentation entry can be created to ease up reading and
 debugging information.
   Like Documentation/arm/omap/io_map.txt
 
 Summary of changes:
 
 The following changes since commit
 95e32bc5b2d95370fb67a108a0e3678381fc42df:
   Tony Lindgren (1):
 OMAP: Remove ifdefs for io.h
 
 Santosh Shilimkar (5):
   ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4
   ARM: OMAP2/3/4: Remap L3, L4 to get more kernel io address space
   ARM: OMAP2/3/4: Move SRAM map to claim more io space
   ARM: OMAP2/3/4: Fix DEBUG_LL UART io address
   ARM: OMAP2/3/4: Add OMAP4 L3 and L4 peripherals.
 
  arch/arm/mach-omap2/board-2430sdp.c   |2 +-
  arch/arm/mach-omap2/board-3430sdp.c   |2 +-
  arch/arm/mach-omap2/board-4430sdp.c   |6 +-
  arch/arm/mach-omap2/board-apollon.c   |2 +-
  arch/arm/mach-omap2/board-generic.c   |2 +-
  arch/arm/mach-omap2/board-h4.c|2 +-
  arch/arm/mach-omap2/board-ldp.c   |2 +-
  arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
  arch/arm/mach-omap2/board-omap3evm.c  |2 +-
  arch/arm/mach-omap2/board-omap3pandora.c  |2 +-
  arch/arm/mach-omap2/board-overo.c |2 +-
  arch/arm/mach-omap2/board-rx51.c  |2 +-
  arch/arm/mach-omap2/board-zoom2.c |2 +-
  arch/arm/mach-omap2/cm.h  |6 +-
  arch/arm/mach-omap2/io.c  |   18 
  arch/arm/mach-omap2/irq.c |4 +-
  arch/arm/mach-omap2/omap-smp.c|2 +-
  arch/arm/mach-omap2/pm-debug.c|3 +-
  arch/arm/mach-omap2/prm.h |6 +-
  arch/arm/mach-omap2/sdrc.h|9 +-
  arch/arm/mach-omap2/serial.c  |6 +-
  arch/arm/mach-omap2/sram242x.S|4 +-
  arch/arm/mach-omap2/sram243x.S|4 +-
  arch/arm/mach-omap2/timer-gp.c|2 +-
  arch/arm/plat-omap/common.c   |   44 +-
  arch/arm/plat-omap/dma.c  |6 +-
  arch/arm/plat-omap/dmtimer.c  |2 +-
  arch/arm/plat-omap/gpio.c |   42 
  arch/arm/plat-omap/include/mach/control.h |   15 ++-
  arch/arm/plat-omap/include/mach/debug-macro.S |4 +-
  arch/arm/plat-omap/include/mach/entry-macro.S |4 +-
  arch/arm/plat-omap/include/mach/io.h  |  124 +---
 -
  arch/arm/plat-omap/include/mach/omap44xx.h|   14 ++-
  arch/arm/plat-omap/include/mach/sdrc.h|6 +-
  arch/arm/plat-omap/include/mach/vmalloc.h |2 +-
  arch/arm/plat-omap/io.c   |   20 +++-
  arch/arm/plat-omap/sram.c |   24 +++---
  drivers/video/omap/dispc.c|6 +-
  38 files changed, 246 insertions(+), 161 deletions(-)
 
 
 Regards,
 Santosh
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe 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 2/2] ARM: OMAP4: PM: Refine API's for Power domain Framework Support.

[Paul Walmsley]

Hello Abhijit,

some comments.

On Wed, 19 Aug 2009, abhijitpag...@ti.com wrote:

 From: Abhijit Pagare abhijitpag...@ti.com
 
 This Patch Adds Silicon Specific initialisations for the API support.
 
 Signed-off-by: Abhijit Pagare abhijitpag...@ti.com
 ---
  arch/arm/mach-omap2/powerdomain.c |   96 
 +++--
  1 files changed, 81 insertions(+), 15 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/powerdomain.c 
 b/arch/arm/mach-omap2/powerdomain.c
 index 8f19c38..5ea7afa 100644
 --- a/arch/arm/mach-omap2/powerdomain.c
 +++ b/arch/arm/mach-omap2/powerdomain.c
 @@ -38,6 +38,63 @@
  #include mach/powerdomain.h
  #include mach/clockdomain.h
  
 +/* OMAP3 Or OMAP4 specific register bit initialisations
 + * Notice that the names here are not according to each power
 + * domain but the bit mapping used applies to all of them
 + */
 +#ifdef CONFIG_ARCH_OMAP34XX

This will break multi-OMAP builds.  And should not be necessary, given 
that the OMAP3 defines appear to be identical to the OMAP4 defines 
(with the exception of the additional bank).

 +/* OMAP4 Logic Retention control and status bits*/
 +#define OMAP_LOGICRET_STATE OMAP4430_LOGICRETSTATE_MASK
 +#define OMAP_LOGICSTATEST OMAP4430_LOGICSTATEST

Please drop the above and 
 +
 +/* OMAP4 Memory Onstate Masks (common across all power domains) */
 +#define OMAP_MEM0_ONSTATE_MASK OMAP4430_CORE_OTHER_BANK_ONSTATE_MASK
 +#define OMAP_MEM1_ONSTATE_MASK OMAP4430_CORE_OCMRAM_ONSTATE_MASK
 +#define OMAP_MEM2_ONSTATE_MASK OMAP4430_DUCATI_L2RAM_ONSTATE_MASK
 +#define OMAP_MEM3_ONSTATE_MASK OMAP4430_DUCATI_UNICACHE_ONSTATE_MASK
 +#define OMAP_MEM4_ONSTATE_MASK OMAP4430_OCP_NRET_BANK_ONSTATE_MASK
 +
 +/* OMAP4 Memory Retstate Masks (common across all power domains) */
 +#define OMAP_MEM0_RETSTATE_MASK OMAP4430_CORE_OTHER_BANK_RETSTATE_MASK
 +#define OMAP_MEM1_RETSTATE_MASK OMAP4430_CORE_OCMRAM_RETSTATE_MASK
 +#define OMAP_MEM2_RETSTATE_MASK OMAP4430_DUCATI_L2RAM_RETSTATE_MASK
 +#define OMAP_MEM3_RETSTATE_MASK OMAP4430_DUCATI_UNICACHE_RETSTATE_MASK
 +#define OMAP_MEM4_RETSTATE_MASK OMAP4430_OCP_NRET_BANK_RETSTATE_MASK
 +
 +/* OMAP4 Memory Status bits */
 +#define OMAP_MEM0_STATEST_MASK OMAP4430_CORE_OTHER_BANK_STATEST_MASK
 +#define OMAP_MEM1_STATEST_MASK OMAP4430_CORE_OCMRAM_STATEST_MASK
 +#define OMAP_MEM2_STATEST_MASK OMAP4430_DUCATI_L2RAM_STATEST_MASK
 +#define OMAP_MEM3_STATEST_MASK OMAP4430_DUCATI_UNICACHE_STATEST_MASK
 +#define OMAP_MEM4_STATEST_MASK OMAP4430_OCP_NRET_BANK_STATEST_MASK

I like the idea that you propose above - to use macro aliases for the bank 
masks.  But let's make some changes.  Banks 0 - 3 should use the OMAP3430 
macros, since that's where they were first introduced.  Bank 4 should keep 
the OMAP4430 macro.

 @@ -714,8 +771,8 @@ int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 
 pwrst)
* but the type of value returned is the same for each
* powerdomain.
*/
 - prm_rmw_mod_reg_bits(OMAP3430_LOGICL1CACHERETSTATE,
 -  (pwrst  __ffs(OMAP3430_LOGICL1CACHERETSTATE)),
 + prm_rmw_mod_reg_bits(OMAP_LOGICRET_STATE,
 +  (pwrst  __ffs(OMAP_LOGICRET_STATE)),
pwrdm-prcm_offs, PM_PWSTCTRL);
  
   return 0;
 @@ -759,16 +816,19 @@ int pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8 
 bank, u8 pwrst)
*/
   switch (bank) {
   case 0:
 - m = OMAP3430_SHAREDL1CACHEFLATONSTATE_MASK;
 + m = OMAP_MEM0_ONSTATE_MASK;
   break;
   case 1:
 - m = OMAP3430_L1FLATMEMONSTATE_MASK;
 + m = OMAP_MEM1_ONSTATE_MASK;
   break;
   case 2:
 - m = OMAP3430_SHAREDL2CACHEFLATONSTATE_MASK;
 + m = OMAP_MEM2_ONSTATE_MASK;
   break;
   case 3:
 - m = OMAP3430_L2FLATMEMONSTATE_MASK;
 + m = OMAP_MEM3_ONSTATE_MASK;
 + break;
 + case 4:
 + m = OMAP_MEM4_ONSTATE_MASK;
   break;
   default:
   WARN_ON(1); /* should never happen */
 @@ -820,16 +880,19 @@ int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8 
 bank, u8 pwrst)
*/
   switch (bank) {
   case 0:
 - m = OMAP3430_SHAREDL1CACHEFLATRETSTATE;
 + m = OMAP_MEM0_RETSTATE_MASK;
   break;
   case 1:
 - m = OMAP3430_L1FLATMEMRETSTATE;
 + m = OMAP_MEM1_RETSTATE_MASK;
   break;
   case 2:
 - m = OMAP3430_SHAREDL2CACHEFLATRETSTATE;
 + m = OMAP_MEM2_RETSTATE_MASK;
   break;
   case 3:
 - m = OMAP3430_L2FLATMEMRETSTATE;
 + m = OMAP_MEM3_RETSTATE_MASK;
 + break;
 + case 4:
 + m = OMAP_MEM4_RETSTATE_MASK;
   break;
   default:
   WARN_ON(1); /* should never happen */
 @@ -857,7 +920,7 @@ int pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
   return -EINVAL;
  
   

Re: [PATCH 1/2] ARM: OMAP4: PM: Add power domain framework.

[Paul Walmsley]

Hello Abhijit,

a few more comments.

On Wed, 19 Aug 2009, abhijitpag...@ti.com wrote:

 From: Abhijit Pagare abhijitpag...@ti.com
 
 This Patch Adds the new power domain framework for OMAP4 and introduces \
 some MACROS for OMAP4 Support. It also takes care of the initialisations \
 of the power domains based on the silicon.
 
 Signed-off-by: Abhijit Pagare abhijitpag...@ti.com
 diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
 index bacfc97..5bab417 100644
 --- a/arch/arm/mach-omap2/prm.h
 +++ b/arch/arm/mach-omap2/prm.h
 @@ -473,11 +473,17 @@
   *
   */
  
 -/* Registers appearing on both 24xx and 34xx */
 -
 -#define RM_RSTCTRL   0x0050
 -#define RM_RSTTIME   0x0054
 -#define RM_RSTST 0x0058
 +/* Registers appearing on 24xx and 34xx and 44xx */
 +
 +#ifdef CONFIG_ARCH_OMAP4

This will break multi-OMAP kernels.  If those offsets differ, please define
two sets, e.g.,

#define OMAP2_RM_RSTCTRL0x0050
...

#define OMAP4_RM_RSTCTRL0x
...

You'll need to patch some of other code with the appropriate offsets.

 +#define RM_RSTCTRL   0x /* OMAP4 */
 +#define RM_RSTTIME   0x0004 /* OMAP4 */
 +#define RM_RSTST 0x0008 /* OMAP4 */
 +#else
 +#define RM_RSTCTRL   0x0050 /* OMAP2  3 */
 +#define RM_RSTTIME   0x0054 /* OMAP2  3 */
 +#define RM_RSTST 0x0058 /* OMAP2  3 */
 +#endif
  
  #define PM_WKEN  0x00a0
  #define PM_WKEN1 PM_WKEN
 @@ -487,8 +493,14 @@
  #define PM_EVGENCTRL 0x00d4
  #define PM_EVGENONTIM0x00d8
  #define PM_EVGENOFFTIM   0x00dc
 -#define PM_PWSTCTRL  0x00e0
 -#define PM_PWSTST0x00e4
 +
 +#ifdef CONFIG_ARCH_OMAP4

Same here.

 +#define PM_PWSTCTRL  0x /* OMAP4 */
 +#define PM_PWSTST0x0004 /* OMAP4 */
 +#else
 +#define PM_PWSTCTRL  0x00e0 /* OMAP2  3 */
 +#define PM_PWSTST0x00e4 /* OMAP2  3 */
 +#endif
  
  /* Omap2 specific registers */
  #define OMAP24XX_PM_WKEN20x00a4
 diff --git a/arch/arm/plat-omap/include/mach/cpu.h 
 b/arch/arm/plat-omap/include/mach/cpu.h
 index fc60c4e..4647f9a 100644
 --- a/arch/arm/plat-omap/include/mach/cpu.h
 +++ b/arch/arm/plat-omap/include/mach/cpu.h
 @@ -253,6 +253,7 @@ IS_OMAP_SUBCLASS(343x, 0x343)
   * cpu_is_omap2423():True for OMAP2423
   * cpu_is_omap2430():True for OMAP2430
   * cpu_is_omap3430():True for OMAP3430
 + * cpu_is_omap4430():True for OMAP4430
   */
  #define GET_OMAP_TYPE((omap_rev()  16)  0x)
  
 @@ -385,7 +386,7 @@ IS_OMAP_TYPE(3430, 0x3430)
  #define OMAP3430_REV_ES3_0   0x34303034
  #define OMAP3430_REV_ES3_1   0x34304034
  
 -#define OMAP443X_CLASS   0x44300034
 +#define OMAP443X_CLASS   0x44300044
  
  /*
   * omap_chip bits
 @@ -408,6 +409,7 @@ IS_OMAP_TYPE(3430, 0x3430)
  #define CHIP_IS_OMAP3430ES2  (1  4)
  #define CHIP_IS_OMAP3430ES3_0(1  5)
  #define CHIP_IS_OMAP3430ES3_1(1  6)
 +#define CHIP_IS_OMAP4430 (1  7)
  
  #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
  

The above changes to cpu.h don't belong as part of a
powerdomains-related patch and should be placed in a separate OMAP4
base patch.

 diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h 
 b/arch/arm/plat-omap/include/mach/powerdomain.h
 index 69c9e67..2742106 100644
 --- a/arch/arm/plat-omap/include/mach/powerdomain.h
 +++ b/arch/arm/plat-omap/include/mach/powerdomain.h
 @@ -46,13 +46,13 @@
   * Number of memory banks that are power-controllable.   On OMAP3430, the
   * maximum is 4.
   */
 -#define PWRDM_MAX_MEM_BANKS  4
 +#define PWRDM_MAX_MEM_BANKS  5
  
  /*
   * Maximum number of clockdomains that can be associated with a powerdomain.
   * CORE powerdomain on OMAP3 is the worst case

Please update this comment.

   */
 -#define PWRDM_MAX_CLKDMS 4
 +#define PWRDM_MAX_CLKDMS 9
  
  /* XXX A completely arbitrary number. What is reasonable here? */
  #define PWRDM_TRANSITION_BAILOUT 10

I also have another comment, which, by request of others at TI India, I 
will send you via private E-mail for now.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache

[Janusz Krzysztofik]

Hi,

No single comment on this idea?

Thanks,
Janusz

--
On 2009-08-12 12:39, Janusz Krzysztofik wrote:

Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.

With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta (buggy?)
hardware. Before that, I could suspect that values read back from McBSP
registers before updating them happened to be errornous.

I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.

Created against linux-2.6.31-rc5

Tested on Amstrad Delta

Signed-off-by: Janusz Krzysztofik

---
--- linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h.orig   
2009-08-11 23:43:25.0 +0200
+++ linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h2009-08-11 
23:45:46.0 +0200
@@ -377,6 +377,8 @@ struct omap_mcbsp {
struct omap_mcbsp_platform_data *pdata;
struct clk *iclk;
struct clk *fclk;
+
+   struct omap_mcbsp_reg_cfg reg_cache;
 };
 extern struct omap_mcbsp **mcbsp_ptr;
 extern int omap_mcbsp_count;
--- linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c.orig2009-08-11 
23:43:25.0 +0200
+++ linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c 2009-08-11 23:45:35.0 
+0200
@@ -91,6 +91,7 @@ static void omap_mcbsp_dump_reg(u8 id)
 static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void *dev_id)
 {
struct omap_mcbsp *mcbsp_tx = dev_id;
+   struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_tx-reg_cache;
u16 irqst_spcr2;
 
 	irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2);

@@ -101,7 +102,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_tx-io_base, SPCR2,
-   irqst_spcr2  ~(XSYNC_ERR));
+   reg_cache-spcr2 = ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -112,6 +113,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
 static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void *dev_id)
 {
struct omap_mcbsp *mcbsp_rx = dev_id;
+   struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_rx-reg_cache;
u16 irqst_spcr1;
 
 	irqst_spcr1 = OMAP_MCBSP_READ(mcbsp_rx-io_base, SPCR1);

@@ -122,7 +124,7 @@ static irqreturn_t omap_mcbsp_rx_irq_han
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_rx-io_base, SPCR1,
-   irqst_spcr1  ~(RSYNC_ERR));
+   reg_cache-spcr1 = ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -167,6 +169,7 @@ static void omap_mcbsp_rx_dma_callback(i
 void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg 
*config)
 {
struct omap_mcbsp *mcbsp;
+   struct omap_mcbsp_reg_cfg *reg_cache;
void __iomem *io_base;
 
 	if (!omap_mcbsp_check_valid_id(id)) {
@@ -174,26 +177,27 @@ void omap_mcbsp_config(unsigned int id, 
 		return;

}
mcbsp = id_to_mcbsp_ptr(id);
+   reg_cache = mcbsp-reg_cache;
 
 	io_base = mcbsp-io_base;

dev_dbg(mcbsp-dev, Configuring McBSP%d  phys_base: 0x%08lx\n,
mcbsp-id, mcbsp-phys_base);
 
 	/* We write the given config */

-   OMAP_MCBSP_WRITE(io_base, SPCR2, config-spcr2);
-   OMAP_MCBSP_WRITE(io_base, SPCR1, config-spcr1);
-   OMAP_MCBSP_WRITE(io_base, RCR2, config-rcr2);
-   OMAP_MCBSP_WRITE(io_base, RCR1, config-rcr1);
-   OMAP_MCBSP_WRITE(io_base, XCR2, config-xcr2);
-   OMAP_MCBSP_WRITE(io_base, XCR1, config-xcr1);
-   OMAP_MCBSP_WRITE(io_base, SRGR2, config-srgr2);
-   OMAP_MCBSP_WRITE(io_base, SRGR1, config-srgr1);
-   OMAP_MCBSP_WRITE(io_base, MCR2, config-mcr2);
-   OMAP_MCBSP_WRITE(io_base, MCR1, config-mcr1);
-   OMAP_MCBSP_WRITE(io_base, PCR0, config-pcr0);
+   OMAP_MCBSP_WRITE(io_base, SPCR2, reg_cache-spcr2 = config-spcr2);
+   OMAP_MCBSP_WRITE(io_base, SPCR1, reg_cache-spcr1 = config-spcr1);
+   OMAP_MCBSP_WRITE(io_base, RCR2, reg_cache-rcr2 = config-rcr2);
+   OMAP_MCBSP_WRITE(io_base, RCR1, reg_cache-rcr1 = config-rcr1);
+   OMAP_MCBSP_WRITE(io_base, XCR2, reg_cache-xcr2 = config-xcr2);
+   OMAP_MCBSP_WRITE(io_base, XCR1, reg_cache-xcr1 = config-xcr1);
+   OMAP_MCBSP_WRITE(io_base, SRGR2, reg_cache-srgr2 = config-srgr2);
+   OMAP_MCBSP_WRITE(io_base, SRGR1, reg_cache-srgr1 = config-srgr1);
+   

Re: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space

[Kevin Hilman]

Shilimkar, Santosh santosh.shilim...@ti.com writes:

 This patch series is intended to free up the kernel IO address space for 
 OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's 
 omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and 
 OMAP4430 platform. 

 Some more combinations are possible but to make it uniform across
 OMAP2, OMAP3 and OMAP4, these io combinations are chosen.

 If needed documentation entry can be created to ease up reading and debugging 
 information.
   Like Documentation/arm/omap/io_map.txt

Yes, this would be very helpful.

Otherwise, this series looks OK with me.

Acked-by: Kevin Hilman khil...@deeprootsystems.com


 Summary of changes:

 The following changes since commit 95e32bc5b2d95370fb67a108a0e3678381fc42df:
   Tony Lindgren (1):
 OMAP: Remove ifdefs for io.h

 Santosh Shilimkar (5):
   ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4
   ARM: OMAP2/3/4: Remap L3, L4 to get more kernel io address space
   ARM: OMAP2/3/4: Move SRAM map to claim more io space
   ARM: OMAP2/3/4: Fix DEBUG_LL UART io address
   ARM: OMAP2/3/4: Add OMAP4 L3 and L4 peripherals.

  arch/arm/mach-omap2/board-2430sdp.c   |2 +-
  arch/arm/mach-omap2/board-3430sdp.c   |2 +-
  arch/arm/mach-omap2/board-4430sdp.c   |6 +-
  arch/arm/mach-omap2/board-apollon.c   |2 +-
  arch/arm/mach-omap2/board-generic.c   |2 +-
  arch/arm/mach-omap2/board-h4.c|2 +-
  arch/arm/mach-omap2/board-ldp.c   |2 +-
  arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
  arch/arm/mach-omap2/board-omap3evm.c  |2 +-
  arch/arm/mach-omap2/board-omap3pandora.c  |2 +-
  arch/arm/mach-omap2/board-overo.c |2 +-
  arch/arm/mach-omap2/board-rx51.c  |2 +-
  arch/arm/mach-omap2/board-zoom2.c |2 +-
  arch/arm/mach-omap2/cm.h  |6 +-
  arch/arm/mach-omap2/io.c  |   18 
  arch/arm/mach-omap2/irq.c |4 +-
  arch/arm/mach-omap2/omap-smp.c|2 +-
  arch/arm/mach-omap2/pm-debug.c|3 +-
  arch/arm/mach-omap2/prm.h |6 +-
  arch/arm/mach-omap2/sdrc.h|9 +-
  arch/arm/mach-omap2/serial.c  |6 +-
  arch/arm/mach-omap2/sram242x.S|4 +-
  arch/arm/mach-omap2/sram243x.S|4 +-
  arch/arm/mach-omap2/timer-gp.c|2 +-
  arch/arm/plat-omap/common.c   |   44 +-
  arch/arm/plat-omap/dma.c  |6 +-
  arch/arm/plat-omap/dmtimer.c  |2 +-
  arch/arm/plat-omap/gpio.c |   42 
  arch/arm/plat-omap/include/mach/control.h |   15 ++-
  arch/arm/plat-omap/include/mach/debug-macro.S |4 +-
  arch/arm/plat-omap/include/mach/entry-macro.S |4 +-
  arch/arm/plat-omap/include/mach/io.h  |  124 
 +
  arch/arm/plat-omap/include/mach/omap44xx.h|   14 ++-
  arch/arm/plat-omap/include/mach/sdrc.h|6 +-
  arch/arm/plat-omap/include/mach/vmalloc.h |2 +-
  arch/arm/plat-omap/io.c   |   20 +++-
  arch/arm/plat-omap/sram.c |   24 +++---
  drivers/video/omap/dispc.c|6 +-
  38 files changed, 246 insertions(+), 161 deletions(-)


 Regards,
 Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP3:PM: fix lockdep warning caused by omap3_pm_init

[Kevin Hilman]

tom.leim...@gmail.com writes:

 From: Ming Lei tom.leim...@gmail.com

 This patch uses kmalloc(size,GFP_ATOMIC) instead of kmalloc(size,GFP_KERNEL)
 to allocate memory for instance of struct power_state in pwrdms_setup(),
 since it may be called by pwrdm_for_each() with irq disabled.

 It is a easy fix for the following lockdep warning caused by
 kmalloc(size,GFP_KERNEL) in pwrdms_setup():

 Power Management for TI OMAP3.
 [ cut here ]
 WARNING: at kernel/lockdep.c:2282 lockdep_trace_alloc+0xe8/0xfc()
 Modules linked in:
 [c0032ccc] (unwind_backtrace+0x0/0xec) from [c0056934] 
 (warn_slowpath_common+0x48/0x60)
 [c0056934] (warn_slowpath_common+0x48/0x60) from [c007da10] 
 (lockdep_trace_alloc+0xe8/0xfc)
 [c007da10] (lockdep_trace_alloc+0xe8/0xfc) from [c00cd9bc] 
 (kmem_cache_alloc+0x28/0x178)
 [c00cd9bc] (kmem_cache_alloc+0x28/0x178) from [c000f184] 
 (pwrdms_setup+0x30/0xf8)
 [c000f184] (pwrdms_setup+0x30/0xf8) from [c00381c4] 
 (pwrdm_for_each+0x64/0x84)
 [c00381c4] (pwrdm_for_each+0x64/0x84) from [c000ef60] 
 (omap3_pm_init+0x3f4/0x5ac)
 [c000ef60] (omap3_pm_init+0x3f4/0x5ac) from [c002c2c0] 
 (do_one_initcall+0x30/0x1d4)
 [c002c2c0] (do_one_initcall+0x30/0x1d4) from [c00088d8] 
 (kernel_init+0xa4/0x118)
 [c00088d8] (kernel_init+0xa4/0x118) from [c002ddf8] 
 (kernel_thread_exit+0x0/0x8)
 ---[ end trace 1e06f8d97dc5a19b ]---

 ---
 This patch is against linux-2.6.31-rc7.

 Signed-off-by: Ming Lei tom.leim...@gmail.com

Looks good, I'll queue in my fixes for 2.6.32 queue.

Kevin

 ---
  arch/arm/mach-omap2/pm34xx.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 488d595..d67b781 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -665,7 +665,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm)
   if (!pwrdm-pwrsts)
   return 0;
  
 - pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL);
 + pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
   if (!pwrst)
   return -ENOMEM;
   pwrst-pwrdm = pwrdm;
 -- 
 1.6.0.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517

[Mark Brown]

On Fri, Aug 28, 2009 at 01:51:03PM +0300, Jarkko Nikula wrote:

 Are you Mark fine with the patch [] where the snd_soc_dai_set_sysclk
 is used to specify source pin for CLKR and FSR?

Yes, that's OK.  Could you re-send the patch, I don't think I've got a
local copy any more?
--
To unsubscribe from this list: send the line unsubscribe 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: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support

[Hemanth V]

 Original Message - 
From: David Brownell davi...@pacbell.net




On Sunday 05 July 2009, Hemanth V wrote:

Do you see any major changes required to support
slave mode in the SPI core driver.


There *is* no such thing as a SPI core driver...


I was referring to

spi.c - SPI init/core code



We are able to 
use the existing interface for slave mode also, but

some APIs/ Structures could be made generic.


Three things are obvious:

- A spi_master is not a slave side driver!


Yes a more generic or new structure would be good,
but the current one does work for slave mode also.



- Control model would need to be inverted
   * Chip select would be one input,
 not N outputs
   * No clock rate controls at all


Conditional checks for slave/master mode have been added in
the driver where required.


   * latency issues ... driver can't necessarily
 respond quickly enough to guarantee no data
 loss (FIFOs help)


We currently support both FIFO and DMA for
slave mode


   * Can't re-use /dev/spidev*
   * Request queue would have a very different role

- Some primitives are likely missing, for flow
  control (when hardware has a READY handshake)

I think a few proposals for how to handle slave
side have been circulated.


So would it be possible to merge the slave support also for
now, and could be modified to support the new slave interface
as and when available.

--
To unsubscribe from this list: send the line unsubscribe 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] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Gupta, Ajay Kumar wrote:


This part is being done at musb_host_rx()



  You're doing it in musb_host_tx() actually. Although musb_host_rx()
is also broken WRT the isochronous transfers.



doing next packet programming within same urb and *not* starting next



urb. Thus musb_start_urb() doesn't come into this path.



  What? Read the code, please -- musb_start_urb() call should always
precede musb_host_tx() which handles the DMA interrupt. Unless something
clears DMAReqEnab after musb_start_urb() call, setting it only once
should work.



musb_start_urb() call does precede musb_host_tx() but when urb is
*completed*.



I think you are aware that there are multiple packets within same isochronous 
urb and musb_start_urb() programs only for first packet.


case USB_ENDPOINT_XFER_ISOC:
qh-iso_idx = 0;
qh-frame = 0;
offset = urb-iso_frame_desc[0].offset;
len = urb-iso_frame_desc[0].length;



   Sure. What I'm still not aware of is where and how the TXCSR DMA bits 
are cleared after the first fragment. Hopefully, testing will reveal this...


WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Hello.

Subbrathnam, Swaminathan wrote:


Sergei,
Pl. do the required testing with and without the patch on the current 
tree for ISO transfers in Tx direction.  As Ajay indicated we have done the 
same and found it not working and hence the fix.


   Sigh, I'm now seeing it even witout testing... So, I'm sorry for all the 
noise. It was a result of my 2 patches clashing.



ISO Rx is also broken and the patch for fixing the same is on the way.


   That's good to hear... musb_host_rx() was further broken WRT ISO 
trabnsers while the Mentor DMA case was being fixed.


WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH]: Adding support for omap-serail driver

[vimal singh]

From: Govindraj R govindraj.r...@ti.com

This patch adds support for OMAP3430-HIGH SPEED UART Controller.

It currently adds support for the following features.

1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
5. Debug Console support on all UARTs on SDP/ZOOM2.
6. Support for quad uart on ZOOM2 board.

The reason for adding this new driver alternative to 8250 is to avoid
polluting 8250 driver with too many omap specific data as 8250 already
supports more than 16 different uart controllers and may need too
many omap-platform checks to implement feature like DMA support.

Signed-off-by: Govindraj R govindraj.r...@ti.com
---
 arch/arm/plat-omap/include/mach/omap-serial.h |   84 +
 drivers/serial/Kconfig|   92 +
 drivers/serial/Makefile   |1
 drivers/serial/omap-serial.c  | 1431 ++
 4 files changed, 1608 insertions(+)

diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
b/arch/arm/plat-omap/include/mach/omap-serial.h
new file mode 100644
index 000..d1b0bf2
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-serial.h
@@ -0,0 +1,84 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-serial.h
+ *
+ * Driver for OMAP3430 UART controller.
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * Authors:
+ * Thara Gopinath  th...@ti.com
+ * Govindraj R govindraj.r...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+/* TI OMAP CONSOLE */
+#define PORT_OMAP   86
+
+#define DRIVER_NAMEomap-hsuart
+
+/*
+ * We default to IRQ0 for the no irq hack.   Some
+ * machine types want  others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq)  ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE)  defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#define OMAP_MDR1_DISABLE  0x07
+#define OMAP_MDR1_MODE13X  0x03
+#define OMAP_MDR1_MODE16X  0x00
+#define OMAP_MODE13X_SPEED 230400
+#endif
+
+#define CONSOLE_NAME   console=
+
+#define UART_CLK   (4800)
+#define QUART_CLK  (1843200)
+
+/* UART NUMBERS */
+#define UART1  (0x0)
+#define UART2  (0x1)
+#define UART3  (0x2)
+#define QUART  (0x3)
+
+#ifdef CONFIG_MACH_OMAP_ZOOM2
+#define MAX_UARTS  QUART
+#else
+#define MAX_UARTS  UART3
+#endif
+
+#define UART_BASE(uart_no) (uart_no == UART1) ? OMAP_UART1_BASE :\
+   (uart_no == UART2) ? OMAP_UART2_BASE :\
+OMAP_UART3_BASE
+
+#define UART_MODULE_BASE(uart_no)  (UART1 == uart_no ? \
+   IO_ADDRESS(OMAP_UART1_BASE) :\
+   (UART2 == uart_no ? \
+   IO_ADDRESS(OMAP_UART2_BASE) :\
+   IO_ADDRESS(OMAP_UART3_BASE)))
+extern unsigned int fcr[MAX_UARTS];
+extern char *saved_command_line;
+
+struct plat_serialomap_port {
+   void __iomem*membase;   /* ioremap cookie or NULL */
+resource_size_t mapbase;   /* resource base */
+   unsigned intirq;/* interrupt number */
+   unsigned char   regshift;   /* register shift */
+   upf_t   flags;  /* UPF_* flags */
+   void*private_data;
+};
+
+#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 037c1e0..906fb61 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1359,6 +1359,98 @@ config SERIAL_OF_PLATFORM
  Currently, only 8250 compatible ports are supported, but
  others can easily be added.

+config SERIAL_OMAP
+   bool OMAP serial port support
+   depends on ARM  ARCH_OMAP
+   select SERIAL_CORE
+   help
+   If you have a machine based on an Texas Instruments OMAP CPU you
+   can enable its onboard serial ports by enabling this option.
+
+config SERIAL_OMAP_CONSOLE
+   bool Console on OMAP serial port
+   depends on SERIAL_OMAP
+   select SERIAL_CORE_CONSOLE
+   help
+   If you have enabled the serial port on the Texas Instruments OMAP
+   CPU you can make it the console by answering Y to this option.
+
+   Even if you say Y here, the currently visible virtual console
+   (/dev/tty0) will still be used as the system console by default, but
+   you can alter that 

Re: [PATCH] musb: fix ISOC Tx programming for CPPI DMAs

[Sergei Shtylyov]

Ajay Kumar Gupta wrote:


Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.



Fixing it by starting DMAs using musb_h_tx_dma_start().



Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Babu Ravi ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com


Acked-by: Sergei Shtylyov sshtyl...@ru.mvista.com


diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index cf94511..e3ab40a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1301,8 +1301,11 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
} else  if (usb_pipeisoc(pipe)  dma) {
if (musb_tx_dma_program(musb-dma_controller, hw_ep, qh, urb,
-   offset, length))
+   offset, length)) {
+   if (is_cppi_enabled() || tusb_dma_omap())


   The latter check shouldn't really be needed, as in the TUSB DMA mode 
only DMA mode 0 is used, in which case the DMA interrupt filtering code 
above in this function shouldn't clear the TXCSR.DMAReEnab bit.



+   musb_h_tx_dma_start(hw_ep);
return;
+   }
} else  if (tx_csr  MUSB_TXCSR_DMAENAB) {
DBG(1, not complete, but DMA enabled?\n);
return;


WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH]: Adding support for omap-serail driver

[Tony Lindgren]

Hi,

Some comments below.

* vimal singh vimal.neww...@gmail.com [090828 06:52]:
 From: Govindraj R govindraj.r...@ti.com
 
 This patch adds support for OMAP3430-HIGH SPEED UART Controller.
 
 It currently adds support for the following features.
 
 1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
 2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
 3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
 4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
 5. Debug Console support on all UARTs on SDP/ZOOM2.
 6. Support for quad uart on ZOOM2 board.
 
 The reason for adding this new driver alternative to 8250 is to avoid
 polluting 8250 driver with too many omap specific data as 8250 already
 supports more than 16 different uart controllers and may need too
 many omap-platform checks to implement feature like DMA support.

Just the DMA and PM features should be enough to justify having a
custom driver for sure.

 diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
 b/arch/arm/plat-omap/include/mach/omap-serial.h
 new file mode 100644
 index 000..d1b0bf2
 --- /dev/null
 +++ b/arch/arm/plat-omap/include/mach/omap-serial.h
 @@ -0,0 +1,84 @@
 +/*
 + * arch/arm/plat-omap/include/mach/omap-serial.h
 + *
 + * Driver for OMAP3430 UART controller.
 + *
 + * Copyright (C) 2009 Texas Instruments.
 + *
 + * Authors:
 + *   Thara Gopinath  th...@ti.com
 + *   Govindraj R govindraj.r...@ti.com
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2. This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +#ifndef __OMAP_SERIAL_H__
 +#define __OMAP_SERIAL_H__
 +
 +#include linux/serial_core.h
 +#include linux/platform_device.h
 +
 +/* TI OMAP CONSOLE */
 +#define PORT_OMAP   86
 +
 +#define DRIVER_NAME  omap-hsuart
 +
 +/*
 + * We default to IRQ0 for the no irq hack.   Some
 + * machine types want  others as well - they're free
 + * to redefine this in their header file.
 + */
 +#define is_real_interrupt(irq)  ((irq) != 0)
 +
 +#if defined(CONFIG_SERIAL_OMAP_CONSOLE)  defined(CONFIG_MAGIC_SYSRQ)
 +#define SUPPORT_SYSRQ
 +#endif
 +
 +#ifdef CONFIG_ARCH_OMAP34XX
 +#define OMAP_MDR1_DISABLE0x07
 +#define OMAP_MDR1_MODE13X0x03
 +#define OMAP_MDR1_MODE16X0x00
 +#define OMAP_MODE13X_SPEED   230400
 +#endif

Omap34xx specific things should be set dynamically during init rather
than using ifdefs. Maybe do the low level init in mach-omap2/serial.c?
That way the driver stays clean of any processor specific hacks.


 +
 +#define CONSOLE_NAME console=
 +
 +#define UART_CLK (4800)
 +#define QUART_CLK(1843200)
 +
 +/* UART NUMBERS */
 +#define UART1(0x0)
 +#define UART2(0x1)
 +#define UART3(0x2)
 +#define QUART(0x3)
 +
 +#ifdef CONFIG_MACH_OMAP_ZOOM2
 +#define MAX_UARTSQUART
 +#else
 +#define MAX_UARTSUART3
 +#endif

This should be passed via platform_data.


 +
 +#define UART_BASE(uart_no)   (uart_no == UART1) ? OMAP_UART1_BASE :\
 + (uart_no == UART2) ? OMAP_UART2_BASE :\
 +  OMAP_UART3_BASE
 +
 +#define UART_MODULE_BASE(uart_no)(UART1 == uart_no ? \
 + IO_ADDRESS(OMAP_UART1_BASE) :\
 + (UART2 == uart_no ? \
 + IO_ADDRESS(OMAP_UART2_BASE) :\
 + IO_ADDRESS(OMAP_UART3_BASE)))

These too you can easily set in mach-omap2/serial.c so similar.


 +extern unsigned int fcr[MAX_UARTS];
 +extern char *saved_command_line;
 +
 +struct plat_serialomap_port {
 + void __iomem*membase;   /* ioremap cookie or NULL */
 +  resource_size_t mapbase;   /* resource base */

Extra space after tab. Please run through checkpatch.pl --strict.


 + unsigned intirq;/* interrupt number */
 + unsigned char   regshift;   /* register shift */
 + upf_t   flags;  /* UPF_* flags */
 + void*private_data;
 +};
 +
 +#endif /* __OMAP_SERIAL_H__ */
 diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
 index 037c1e0..906fb61 100644
 --- a/drivers/serial/Kconfig
 +++ b/drivers/serial/Kconfig
 @@ -1359,6 +1359,98 @@ config SERIAL_OF_PLATFORM
 Currently, only 8250 compatible ports are supported, but
 others can easily be added.
 
 +config SERIAL_OMAP
 + bool OMAP serial port support
 + depends on ARM  ARCH_OMAP
 + select SERIAL_CORE
 + help
 + If you have a machine based on an Texas Instruments OMAP CPU you
 + can enable its onboard serial ports by enabling this option.
 +
 +config SERIAL_OMAP_CONSOLE
 + bool Console on OMAP serial port
 + depends on SERIAL_OMAP
 + select SERIAL_CORE_CONSOLE
 + help
 + If you have 

Re: [PATCH 0/2] OMAP: misc. fixes for 2.6.32

[Tony Lindgren]

* Kevin Hilman khil...@deeprootsystems.com [090828 01:28]:
 Tony,
 
 I pushed a couple more fixes to my pm-upstream/fixes-32 branch.  You've
 already pulled this branch into your for-next, so a re-pull will get
 you just these two additional patches.

OK, I need to rebuild the omap for-next as there are few compilation
issues in at least the omap3-upstream series.

Regards,

Tony
 
 Thanks,
 
 Kevin
 
 
 Reddy, Teerth (1):
   OMAP3: PM: add T2 interrupt line mux setting, and enable on 3430SDP
 
 Vikram Pandita (1):
   OMAP: Zoom2: release debug board detect gpio line
 
  arch/arm/mach-omap2/board-3430sdp.c |6 ++
  arch/arm/mach-omap2/board-zoom-debugboard.c |7 ---
  arch/arm/mach-omap2/mux.c   |5 +
  arch/arm/plat-omap/include/mach/mux.h   |3 +++
  4 files changed, 18 insertions(+), 3 deletions(-)
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP SRAM: flush the right address after memcpy in omap_sram_push

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [090828 03:43]:
 On Fri, 28 Aug 2009, ye janboe wrote:
 
  the original flush operation is to flush the function address which is
  copied from.
  But we do not change the function code and it is not necessary to flush it.
  
  Signed-off-by: janboe janboe...@gmail.com
 
 Acked-by: Paul Walmsley p...@pwsan.com
 
 thanks Janboe.
 
 Tony, you want to take this one, or do you want me to?

I can add it to my omap-fixes unless you have a fixes series of your
own coming up.

Tony
 
 - Paul
 
 
  ---
   arch/arm/plat-omap/sram.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
  
  diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
  index f2b0fa6..f549d8a 100644
  --- a/arch/arm/plat-omap/sram.c
  +++ b/arch/arm/plat-omap/sram.c
  @@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size)
  omap_sram_ceil -= size;
  omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
  memcpy((void *)omap_sram_ceil, start, size);
  -   flush_icache_range((unsigned long)start, (unsigned long)(start + 
  size));
  +   flush_icache_range((unsigned long)omap_sram_ceil,
  +   (unsigned long)(omap_sram_ceil + size));
  
  return (void *)omap_sram_ceil;
   }
  
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RFC] OMAP3: PM: Adding OSWR support

[Tony Lindgren]

* Thara Gopinath th...@ti.com [090827 09:54]:
 This patch adds OSWR support for MPU/CORE domains in CPUidle.
 Two new C states are being added to the existing C states
 which makes the new states look like below.

Please explain what OSWR means, the patch description should be clear
to everybody. I guess you mean Open SWitch Retention?

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support

[Tony Lindgren]

* Hemanth V heman...@ti.com [090828 05:05]:
  Original Message - From: David Brownell davi...@pacbell.net


 On Sunday 05 July 2009, Hemanth V wrote:
 Do you see any major changes required to support
 slave mode in the SPI core driver.

 There *is* no such thing as a SPI core driver...

 I was referring to

 spi.c - SPI init/core code


 We are able to use the existing interface for slave mode also, but
 some APIs/ Structures could be made generic.

 Three things are obvious:

 - A spi_master is not a slave side driver!

 Yes a more generic or new structure would be good,
 but the current one does work for slave mode also.


 - Control model would need to be inverted
* Chip select would be one input,
  not N outputs
* No clock rate controls at all

 Conditional checks for slave/master mode have been added in
 the driver where required.

* latency issues ... driver can't necessarily
  respond quickly enough to guarantee no data
  loss (FIFOs help)

 We currently support both FIFO and DMA for
 slave mode

* Can't re-use /dev/spidev*
* Request queue would have a very different role

 - Some primitives are likely missing, for flow
   control (when hardware has a READY handshake)

 I think a few proposals for how to handle slave
 side have been circulated.

 So would it be possible to merge the slave support also for
 now, and could be modified to support the new slave interface
 as and when available.

In general it's not good to merge half implemented patches.

That's because it usually means that the work on getting
things cleaned up stops right there.

And then the community is left to deal with the mess.

So I recommend doing it clean from the start rather than
merging in hacks.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] OMAP3: Zoom2: provide default MTD partitions

[Rix, Tom]

The bootloader perspective..

The minimum set needed are for xloader, u-boot and the environment. 
xloader is very static.
u-boot at 1.25m should be big enough
environment is very static and should be big enough..
This is consistent with the bootloader.

The rest can be done with mtdparts and the differences between ldp and zoom2
flash layout can be separated in their respective environment files. 

The bootloader flashing utility 'fastboot' depends on the kernel layout.
There is a change pending to decouple using an mtdparts-like mechanism. 
See 'Runtime Partitions' toward the bottom of..

https://omapzoom.org/gf/project/omapzoom/wiki/?pagename=FAQ-8%3A+Zoom-II+Android%C2%A0fastboot

Tom


From: Maxime Petazzoni [mpetazz...@mvista.com]
Sent: Thursday, August 27, 2009 9:06 AM
To: Pandita, Vikram
Cc: Singh, Vimal; linux-omap@vger.kernel.org; Rix, Tom
Subject: Re: [PATCH] OMAP3: Zoom2: provide default MTD partitions

Hi,

* Pandita, Vikram vikram.pand...@ti.com [2009-08-27 19:16:27]:

 Why?

 I know of an implementation by Vimal Singh that introduces a common
 flash file for Zoom1 and Zoom2.
 There is reuse of code there.

Thanks for your comments.

There are indeed other implentations around using a common flash file
for Zoom1 and Zoom2 boards. I didn't know of this specific
implementation by Vimal Singh, but we use something very similar
internally.

Since linux-omap didn't had any MTD partitions definitions for either
boards, I decided to go for the smallest change: only partitions for
Zoom2.

 Please discuss and get a converged approach on handling NAND
 partitions on Zoom1 and Zoom2.

Agreed. We should use a common file for Zoom1 and Zoom2 flash, with
Zoom2 specific partition sizes. But I'm not sure I deserve the right to
propose Vimal Singh's patch (by the way, why hasn't it been merged in
the linux-omap tree?). How should we proceed then?

 Also the Systerm/User/Cache partition definitions are more from Android 
 perspective.

 Given that each system may have a different NAND partition requirement,
 have you looked at bootargs passing the MTD partition info: Eg:

 mtdparts=omap2-nand.0:5...@0(xloader),\
 15...@512k(bootloader),\
 2...@2m(kernel),\
 1...@32m(system),\
 3...@192m(userdata),\
 3...@224m(cache)

Yes, I am aware of the mtdparts command line arguments, which works
great. I think a default, sensible partition layout for the Zoom2
would be nice though.

- Maxime

--
Maxime Petazzoni
Linux kernel  software dev
MontaVista Software, 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: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space

[Shilimkar, Santosh]

Thanks Kevin for review!!

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Friday, August 28, 2009 5:32 PM
 To: Shilimkar, Santosh
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address
 space
 
 Shilimkar, Santosh santosh.shilim...@ti.com writes:
 
  This patch series is intended to free up the kernel IO address space for
 OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's
  omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and
 OMAP4430 platform.
 
  Some more combinations are possible but to make it uniform across
  OMAP2, OMAP3 and OMAP4, these io combinations are chosen.
 
  If needed documentation entry can be created to ease up reading and
 debugging information.
  Like Documentation/arm/omap/io_map.txt
 
 Yes, this would be very helpful.
 
 Otherwise, this series looks OK with me.
 
 Acked-by: Kevin Hilman khil...@deeprootsystems.com

Will create the doc entry.

Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support

[David Brownell]

On Friday 28 August 2009, Hemanth V wrote:
 So would it be possible to merge the slave support also for
 now, and could be modified to support the new slave interface
 as and when available.

Not really.  You still haven't split the non-slave stuff into
a patch, note ..

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching

[Samuel Ortiz]

Hi Amit,

On Mon, Aug 17, 2009 at 05:01:46PM +0300, Amit Kucheria wrote:
 +
 +#include asm/mach-types.h
You'll have to make your Kconfig entry depend on ARM if you want to include
this file. Too bad you need it just for the special sdp and ldp cases, but I
guess there's no other solution.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/10] OMAP3: update OMAP3 Beagle defconfig, v3

[Tony Lindgren]

Hi Eric  Felipe,

* Eric Witcher ewitc...@mindspring.com [090825 20:20]:
 
 -Original Message-
 From: Felipe Balbi felipe.ba...@nokia.com
 Sent: Aug 19, 2009 9:40 AM
 To: ext Tony Lindgren t...@atomide.com
 Cc: Eric Witcher ewitc...@mindspring.com, linux-omap@vger.kernel.org 
 linux-omap@vger.kernel.org
 Subject: Re: [PATCH 10/10] OMAP3: update OMAP3 Beagle defconfig, v3
 
 Hi,
 
 On Sun, Aug 16, 2009 at 05:42:00PM +0200, ext Tony Lindgren wrote:
  From f9356c9b5ca663feb3a985b42d0409da5625d537 Mon Sep 17 00:00:00 2001
  From: Paul Walmsley p...@pwsan.com
  Date: Sun, 16 Aug 2009 18:29:49 +0300
  Subject: [PATCH] OMAP3: update OMAP3 Beagle defconfig
  
  Update the OMAP3 Beagle defconfig to add EHCI, MMC, TWL4030 GPIO support.
  Beagle can again use MMC rootfs after this patch.  Tested on BeagleBoard
  rev C2.
  
  Patch updated to enable PM and OTG options as suggested by
  Eric Witcher ewitc...@mindspring.com.
  
  Signed-off-by: Paul Walmsley p...@pwsan.com
  Cc: Jason Kridner jkrid...@beagleboard.org
  Signed-off-by: Tony Lindgren t...@atomide.com
 
 Acked-by: Felipe Balbi felipe.ba...@nokia.com
 
 now that we have REGULATOR and TWL4030_USB it will work.

Updated the patch with Felipe's Ack. Then see below on how
we should deal with the remaining parts.

 
 Hi everyone,
 
 I just tested this again at the top of for-next at
  6e083649e19ba4aa3b8a65d75f394ab8a06feb78
 and we are still short 2 changes in order to get a working
 boot using omap3_beagle_defconfig.
 
 The changes are shown below.
 
 The code deltas were discussed before
 but I didn't follow how the twl4030-usb.c change was going to make
 it into the tree.
 
 With respect to the .config change, it was shown in my earlier post
 but it didn't get put into the commit at
 OMAP3: update OMAP3 Beagle defconfig
 af9d536a65251a547864e3be87f53a22a6966b7a
 
 In that check-in configuration CONFIG_USB_M66592 overrides
 CONFIG_USB_GADGET_MUSB_HDRC and we fail during compile.
 
 Eric
 
 ---
  arch/arm/configs/omap3_beagle_defconfig |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/configs/omap3_beagle_defconfig 
 b/arch/arm/configs/omap3_beagle_defconfig
 index b213e3b..51c0fa8 100644
 --- a/arch/arm/configs/omap3_beagle_defconfig
 +++ b/arch/arm/configs/omap3_beagle_defconfig
 @@ -899,8 +899,8 @@ CONFIG_USB_GADGET_SELECTED=y
  # CONFIG_USB_GADGET_FSL_USB2 is not set
  # CONFIG_USB_GADGET_NET2280 is not set
  # CONFIG_USB_GADGET_PXA25X is not set
 -CONFIG_USB_GADGET_M66592=y
 -CONFIG_USB_M66592=y
 +# CONFIG_USB_GADGET_M66592 is not set
 +# CONFIG_USB_M66592 is not set
  # CONFIG_USB_GADGET_PXA27X is not set
  # CONFIG_USB_GADGET_GOKU is not set
  # CONFIG_USB_GADGET_LH7A40X is not set

Thanks, merged this part into the patch.


 -- 
 1.6.2.2
 
 ---
  arch/arm/mach-omap2/serial.c  |1 -
  drivers/usb/otg/twl4030-usb.c |2 +-
  2 files changed, 1 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
 index 021130d..1cf8078 100644
 --- a/arch/arm/mach-omap2/serial.c
 +++ b/arch/arm/mach-omap2/serial.c
 @@ -475,7 +475,6 @@ static void omap_uart_idle_init(struct omap_uart_state 
 *uart)
   uart-padconf = 0;
   }
  
 - p-irqflags |= IRQF_SHARED;
   ret = request_irq(p-irq, omap_uart_interrupt, IRQF_SHARED,
 serial idle, (void *)uart);
   WARN_ON(ret);

The related serial irqflags changes are already queued up in for-next,
so this we can ignore until the omap for-next is merged.


 diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
 index 9e3e7a5..d1852d4 100644
 --- a/drivers/usb/otg/twl4030-usb.c
 +++ b/drivers/usb/otg/twl4030-usb.c
 @@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
  {
   return platform_driver_register(twl4030_usb_driver);
  }
 -subsys_initcall(twl4030_usb_init);
 +subsys_initcall_sync(twl4030_usb_init);
  
  static void __exit twl4030_usb_exit(void)
  {

But this should be a separate patch and Felipe should take a look at it.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] OMAP: iommu: add initial debugfs support

[Tony Lindgren]

* Hiroshi DOYU hiroshi.d...@nokia.com [090827 00:26]:
 Hi Tony,
 
 I fixed the error exit path as below and attached the updated verion
 of the patch. Please replace the old one in for-next with the attached
 one.

OK will update.

Tony

   Modified arch/arm/plat-omap/iommu-debug.c
 diff --git a/arch/arm/plat-omap/iommu-debug.c 
 b/arch/arm/plat-omap/iommu-debug.c
 index 5a7e409..c799b3b 100644
 --- a/arch/arm/plat-omap/iommu-debug.c
 +++ b/arch/arm/plat-omap/iommu-debug.c
 @@ -268,14 +268,14 @@ static ssize_t debug_read_mem(struct file *file, char 
 __user *userbuf,
  
   area = find_iovm_area(obj, (u32)ppos);
   if (IS_ERR(area)) {
 - mutex_unlock(iommu_debug_lock);
 - return -EINVAL;
 + bytes = -EINVAL;
 + goto err_out;
   }
   memcpy(p, area-va, count);
   p += count;
  
   bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
 -
 +err_out:
   mutex_unlock(iommu_debug_lock);
   free_page((unsigned long)buf);
  
 @@ -299,17 +299,17 @@ static ssize_t debug_write_mem(struct file *file, const 
 char __user *userbuf,
   mutex_lock(iommu_debug_lock);
  
   if (copy_from_user(p, userbuf, count)) {
 - mutex_unlock(iommu_debug_lock);
 - return -EFAULT;
 + count =  -EFAULT;
 + goto err_out;
   }
  
   area = find_iovm_area(obj, (u32)ppos);
   if (IS_ERR(area)) {
 - mutex_unlock(iommu_debug_lock);
 - return -EINVAL;
 + count = -EINVAL;
 + goto err_out;
   }
   memcpy(area-va, p, count);
 -
 +err_out:
   mutex_unlock(iommu_debug_lock);
   free_page((unsigned long)buf);
  


--
To unsubscribe from this list: send the line unsubscribe 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: [DSPBRIGDE PATCH 5/6] dsp: brigde: remove unnecessary memset()

[Guzman Lugo, Fernando]

Acked-by: Fernando Guzman Lugo x0095...@ti.com

Regards
-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Friday, August 21, 2009 5:30 AM
To: Balbi Felipe (Nokia-D/Helsinki)
Cc: Doyu Hiroshi (Nokia-D/Helsinki); Palande Ameya (Nokia-D/Helsinki); Guzman 
Lugo, Fernando; Linux OMAP Mailing List
Subject: Re: [DSPBRIGDE PATCH 5/6] dsp: brigde: remove unnecessary memset()

Hi,

On Fri, Aug 21, 2009 at 12:23:38PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
 bridge_device is static and thus doesn't need
 to be zero-initialized.
 
 Signed-off-by: Felipe Balbi felipe.ba...@nokia.com

I changed this patch to the following:

 cut here =


From 1a5699476007fdff6beb5a895c74bc15f0bdd223 Mon Sep 17 00:00:00 2001
From: Felipe Balbi felipe.ba...@nokia.com
Date: Fri, 21 Aug 2009 12:10:00 +0300
Subject: [DSPBRIGDE PATCH 5/6] dsp: brigde: convert kmalloc() memset() to 
kzalloc()

use kzalloc() instead of manually kmalloc() + memset() later.

Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
 drivers/dsp/bridge/rmgr/drv_interface.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c 
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 7763346..27e293b 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -329,13 +329,12 @@ static int __init bridge_init(void)
 
driver_major = MAJOR(dev);
 
-   bridge_device = kmalloc(sizeof(struct bridge_dev), GFP_KERNEL);
+   bridge_device = kzalloc(sizeof(struct bridge_dev), GFP_KERNEL);
if (!bridge_device) {
result = -ENOMEM;
unregister_chrdev_region(dev, 1);
return result;
}
-   memset(bridge_device, 0, sizeof(struct bridge_dev));
cdev_init(bridge_device-cdev, bridge_fops);
bridge_device-cdev.owner = THIS_MODULE;
bridge_device-cdev.ops = bridge_fops;
-- 
1.6.3.3.385.g60647



-- 
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

--
To unsubscribe from this list: send the line unsubscribe 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: [DSPBRIGDE PATCH 2/6] dsp: bridge: wcd: else is unnecessary

[Guzman Lugo, Fernando]

Acked-by: Fernando Guzman Lugo x0095...@ti.com

-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com] 
Sent: Friday, August 21, 2009 5:24 AM
To: Hiroshi DOYU
Cc: Ameya Palande; Guzman Lugo, Fernando; Linux OMAP Mailing List; Felipe Balbi
Subject: [DSPBRIGDE PATCH 2/6] dsp: bridge: wcd: else is unnecessary

The return makes the use of else unnecessary, remove it

Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
 drivers/dsp/bridge/pmgr/wcd.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 7434f43..01c9572 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -260,9 +260,9 @@ inline DSP_STATUS WCD_CallDevIOCtl(u32 cmd, union 
Trapped_Args *args,
/* make the fxn call via the cmd table */
*pResult = (*WCD_cmdTable[cmd].fxn) (args);
return DSP_SOK;
-   } else {
-   return DSP_EINVALIDARG;
}
+
+   return DSP_EINVALIDARG;
 }
 
 /*
-- 
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

RE: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path

[Guzman Lugo, Fernando]

Acked-by: Fernando Guzman Lugo x0095...@ti.com


-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com] 
Sent: Friday, August 21, 2009 5:24 AM
To: Hiroshi DOYU
Cc: Ameya Palande; Guzman Lugo, Fernando; Linux OMAP Mailing List; Felipe Balbi
Subject: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path

... and get rid of a possible memory leak.

in case of error while adding the chardev, probe()
would not kfree() bridge_device.

Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
 drivers/dsp/bridge/rmgr/drv_interface.c |   20 ++--
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c 
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 559d14a..c37c5a0 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -324,7 +324,7 @@ static int __init bridge_init(void)
if (result  0) {
GT_1trace(driverTrace, GT_7CLASS, bridge_init: 
Can't get Major %d \n, driver_major);
-   return result;
+   goto err1;
}
 
driver_major = MAJOR(dev);
@@ -332,19 +332,17 @@ static int __init bridge_init(void)
bridge_device = kmalloc(sizeof(struct bridge_dev), GFP_KERNEL);
if (!bridge_device) {
result = -ENOMEM;
-   unregister_chrdev_region(dev, 1);
-   return result;
+   goto err2;
}
cdev_init(bridge_device-cdev, bridge_fops);
bridge_device-cdev.owner = THIS_MODULE;
bridge_device-cdev.ops = bridge_fops;
 
status = cdev_add(bridge_device-cdev, dev, 1);
-
if (status) {
GT_0trace(driverTrace, GT_7CLASS,
Failed to add the bridge device \n);
-   return status;
+   goto err3;
}
 
/* udev support */
@@ -474,7 +472,17 @@ static int __init bridge_init(void)
DBC_Assert(status == 0);
DBC_Assert(DSP_SUCCEEDED(initStatus));
GT_0trace(driverTrace, GT_ENTER,  - driver_init\n);
-   return status;
+
+   return 0;
+
+err3:
+   kfree(bridge_device);
+
+err2:
+   unregister_chrdev_region(dev, 1);
+
+err1:
+   return result;
 }
 
 /*  This function is invoked during unlinking of the bridge module from the
-- 
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

RE: [DSPBRIGDE PATCH 4/6] dsp: bridge: always use dynamic major/minor numbers

[Guzman Lugo, Fernando]

Acked-by: Fernando Guzman Lugo x0095...@ti.com


-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com] 
Sent: Friday, August 21, 2009 5:24 AM
To: Hiroshi DOYU
Cc: Ameya Palande; Guzman Lugo, Fernando; Linux OMAP Mailing List; Felipe Balbi
Subject: [DSPBRIGDE PATCH 4/6] dsp: bridge: always use dynamic major/minor 
numbers

there's no reason to initialize that to 0 or use module parameters
if kernel will always get us dynamic numbers.

Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
 drivers/dsp/bridge/rmgr/drv_interface.c |   25 ++---
 1 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c 
b/drivers/dsp/bridge/rmgr/drv_interface.c
index a283cd7..7763346 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -105,8 +105,6 @@
 #define BRIDGE_NAME C6410
 /*  --- Globals */
 #define DRIVER_NAME  DspBridge
-#define DRIVER_MAJOR 0 /* Linux assigns our Major device number */
-#define DRIVER_MINOR 0 /* Linux assigns our Major device number */
 s32 dsp_debug;
 
 /* This is a test variable used by Bridge to test different sleep states */
@@ -123,8 +121,8 @@ static u32 driverContext;
 #ifdef CONFIG_BRIDGE_DEBUG
 static char *GT_str;
 #endif /* CONFIG_BRIDGE_DEBUG */
-static s32 driver_major = DRIVER_MAJOR;
-static s32 driver_minor = DRIVER_MINOR;
+static s32 driver_major;
+static s32 driver_minor;
 static char *base_img;
 char *iva_img;
 static char *num_procs = C55=1;
@@ -162,12 +160,6 @@ module_param(dsp_debug, int, 0);
 MODULE_PARM_DESC(dsp_debug, Wait after loading DSP image. default = false);
 #endif
 
-module_param(driver_major, int, 0);/* Driver's major number */
-MODULE_PARM_DESC(driver_major, Major device number, default = 0 (auto));
-
-module_param(driver_minor, int, 0);/* Driver's major number */
-MODULE_PARM_DESC(driver_minor, Minor device number, default = 0 (auto));
-
 module_param(dsp_test_sleepstate, int, 0);
 MODULE_PARM_DESC(dsp_test_sleepstate, DSP Sleep state = 0);
 
@@ -327,21 +319,16 @@ static int __init bridge_init(void)
 #endif
 
/* use 2.6 device model */
-   if (driver_major) {
-   dev = MKDEV(driver_major, driver_minor);
-   result = register_chrdev_region(dev, 1, driver_name);
-   } else {
-   result = alloc_chrdev_region(dev, driver_minor, 1,
-   driver_name);
-   driver_major = MAJOR(dev);
-   }
-
+   result = alloc_chrdev_region(dev, driver_minor, 1,
+   driver_name);
if (result  0) {
GT_1trace(driverTrace, GT_7CLASS, bridge_init: 
Can't get Major %d \n, driver_major);
return result;
}
 
+   driver_major = MAJOR(dev);
+
bridge_device = kmalloc(sizeof(struct bridge_dev), GFP_KERNEL);
if (!bridge_device) {
result = -ENOMEM;
-- 
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

Re: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path

[Andy Shevchenko]

On Fri, Aug 28, 2009 at 11:58 PM, Guzman Lugo,


 @@ -324,7 +324,7 @@ static int __init bridge_init(void)
        if (result  0) {
                GT_1trace(driverTrace, GT_7CLASS, bridge_init: 
                                Can't get Major %d \n, driver_major);
 -               return result;
 +               goto err1;
        }

        driver_major = MAJOR(dev);
 @@ -332,19 +332,17 @@ static int __init bridge_init(void)
        bridge_device = kmalloc(sizeof(struct bridge_dev), GFP_KERNEL);
        if (!bridge_device) {
                result = -ENOMEM;
 -               unregister_chrdev_region(dev, 1);
 -               return result;
 +               goto err2;
        }
        cdev_init(bridge_device-cdev, bridge_fops);
        bridge_device-cdev.owner = THIS_MODULE;
        bridge_device-cdev.ops = bridge_fops;

        status = cdev_add(bridge_device-cdev, dev, 1);
 -
        if (status) {
                GT_0trace(driverTrace, GT_7CLASS,
                                Failed to add the bridge device \n);
 -               return status;
result = status, isn't is?
or change status to result on previous lines.


 +               goto err3;
        }

        /* udev support */
 @@ -474,7 +472,17 @@ static int __init bridge_init(void)
        DBC_Assert(status == 0);
        DBC_Assert(DSP_SUCCEEDED(initStatus));
        GT_0trace(driverTrace, GT_ENTER,  - driver_init\n);
 -       return status;
 +
 +       return 0;
 +
 +err3:
 +       kfree(bridge_device);
 +
 +err2:
 +       unregister_chrdev_region(dev, 1);
 +
 +err1:
 +       return result;
  }

  /*  This function is invoked during unlinking of the bridge module from the


-- 
With Best Regards,
Andy Shevchenko

RE: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path

[Guzman Lugo, Fernando]

Hi,

-Original Message-
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
Sent: Friday, August 28, 2009 4:13 PM
To: Guzman Lugo, Fernando
Cc: Felipe Balbi; Hiroshi DOYU; Ameya Palande; Linux OMAP Mailing List
Subject: Re: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path

On Fri, Aug 28, 2009 at 11:58 PM, Guzman Lugo,


 @@ -324,7 +324,7 @@ static int __init bridge_init(void)
        if (result  0) {
                GT_1trace(driverTrace, GT_7CLASS, bridge_init: 
                                Can't get Major %d \n, driver_major);
 -               return result;
 +               goto err1;
        }

        driver_major = MAJOR(dev);
 @@ -332,19 +332,17 @@ static int __init bridge_init(void)
        bridge_device = kmalloc(sizeof(struct bridge_dev), GFP_KERNEL);
        if (!bridge_device) {
                result = -ENOMEM;
 -               unregister_chrdev_region(dev, 1);
 -               return result;
 +               goto err2;
        }
        cdev_init(bridge_device-cdev, bridge_fops);
        bridge_device-cdev.owner = THIS_MODULE;
        bridge_device-cdev.ops = bridge_fops;

        status = cdev_add(bridge_device-cdev, dev, 1);
 -
        if (status) {
                GT_0trace(driverTrace, GT_7CLASS,
                                Failed to add the bridge device \n);
 -               return status;
result = status, isn't is?
or change status to result on previous lines.


Yes, we need to assigned status to result, in order to report the error, 
however I think we can get rid of result and use status instead, what do you 
think?


 +               goto err3;
        }

        /* udev support */
 @@ -474,7 +472,17 @@ static int __init bridge_init(void)
        DBC_Assert(status == 0);
        DBC_Assert(DSP_SUCCEEDED(initStatus));
        GT_0trace(driverTrace, GT_ENTER,  - driver_init\n);
 -       return status;
 +
 +       return 0;
 +
 +err3:
 +       kfree(bridge_device);
 +
 +err2:
 +       unregister_chrdev_region(dev, 1);
 +
 +err1:
 +       return result;
  }

  /*  This function is invoked during unlinking of the bridge module from
the


--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html