Re: [PATCH 2/2] OMAP: remove OMAP_TAG_UART

[Kalle Valo]

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

Omap tags are deprecrated and convert all OMAP_TAG_UART cases to use
omap_uart_platform_data instead.

Tested on rx51 and n8x0. Compile tested on omap_osk_5912.

Signed-off-by: Kalle Valo kalle.v...@iki.fi

 Any plans to remove OMAP_TAG_LCD

I don't have any plans, but I don't know about others.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Kalle Jokiniemi]

On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:
 Roger Quadros ext-roger.quad...@nokia.com writes:
 
  As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
  for automatic self-refresh before transition to OFF mode.
  In the current implementation this is done in omap3_scratchpad_contents()
  which is wrong, since this is the value that will be restored while
  resuming from OFF mode and not while transitioning to it.
 
  This patch implements the workaround in the correct way as per errata.
 
  Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
 
 This looks right to me.
 
 Rajendra, Kalle, any comments? since you were the originators of
 the original patch.
 
 Kevin
 
  ---
   arch/arm/mach-omap2/control.c |   16 ++--
   arch/arm/mach-omap2/pm34xx.c  |   20 ++--
   2 files changed, 16 insertions(+), 20 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
  index a7159a9..0a563c8 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
  (sdrc_read_reg(SDRC_ERR_TYPE)  0x);
  sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
  sdrc_block_contents.dll_b_ctrl = 0x0;
  -   /*
  -* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  -* be programed to issue automatic self refresh on timeout
  -* of AUTO_CNT = 1 prior to any transition to OFF mode.
  -*/
  -   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
  -(omap_rev() = OMAP3430_REV_ES3_0))
  -   sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
  -   ~(SDRC_POWER_AUTOCOUNT_MASK|
  -   SDRC_POWER_CLKCTRL_MASK)) |
  -   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  -   SDRC_SELF_REFRESH_ON_AUTOCOUNT;
  -   else
  -   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  +
  +   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);

Why do you want to remove the workaround from scratchpad?

When we wake up from off mode, the boot ROM code writes these settings
as the first sdrc_power settings after wakeup. If that setting does not
include the workaround, we'll have a period of time where sdram is not
being refreshed. This hits especially HS devices that do long secure
context restore in ROM code as well.


   
  sdrc_block_contents.cs_0 = 0x0;
  sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
  diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
  index 14f10bc..eb3c9e5 100644
  --- a/arch/arm/mach-omap2/pm34xx.c
  +++ b/arch/arm/mach-omap2/pm34xx.c
  @@ -405,15 +405,23 @@ void omap_sram_idle(void)
  }
   
  /*
  -   * On EMU/HS devices ROM code restores a SRDC value
  -   * from scratchpad which has automatic self refresh on timeout
  -   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
  -   * Hence store/restore the SDRC_POWER register here.
  -   */
  +* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  +* be programed to issue automatic self refresh on timeout
  +* of AUTO_CNT = 1 prior to any transition to OFF mode.
  +*/
  +
  if (omap_rev() = OMAP3430_REV_ES3_0 
  omap_type() != OMAP2_DEVICE_TYPE_GP 
  -   core_next_state == PWRDM_POWER_OFF)
  +   core_next_state == PWRDM_POWER_OFF) {
  +
  sdrc_pwr = sdrc_read_reg(SDRC_POWER);
  +   sdrc_write_reg((sdrc_pwr 
  +   ~(SDRC_POWER_AUTOCOUNT_MASK|
  +   SDRC_POWER_CLKCTRL_MASK)) |
  +   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  +   SDRC_SELF_REFRESH_ON_AUTOCOUNT,
  +   SDRC_POWER);
  +   }

This part seems ok to me.

- Kalle


   
  if (regset_save_on_suspend)
  pm_dbg_regset_save(1);
  -- 
  1.6.0.4

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

[PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Jarkko Nikula]

Simultaneous audio playback and capture on OMAP1510 can cause that second
stream is stalled if there is enough delay between startup of the audio
streams.

Current implementation of the omap_mcbsp_start is starting both transmitter
and receiver at the same time and it is called only for firstly started
audio stream from the OMAP McBSP based ASoC DAI driver.

Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is
missed if there is no DMA transfer set up at that time when the first word
after McBSP startup is transmitted. The problem hasn't noted before since
later OMAPs are using level sensitive DMA request lines.

Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by
allowing to start and stop individually McBSP transmitter and receiver
logics. Then call those functions individually for both audio playback
and capture streams. This ensures that DMA transfer is setup before
transmitter or receiver is started.

Thanks to Janusz Krzysztofik jkrzy...@tis.icnet.pl for detailed problem
analysis and Peter Ujfalusi peter.ujfal...@nokia.com for info about DMA
request line behavior differences between the OMAP generations.

Reported-and-tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
 arch/arm/plat-omap/mcbsp.c  |   50 +++---
 sound/soc/omap/omap-mcbsp.c |   10 +++---
 3 files changed, 39 insertions(+), 25 deletions(-)

diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h 
b/arch/arm/plat-omap/include/mach/mcbsp.h
index bb154ea..57249bb 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -387,8 +387,8 @@ void omap_mcbsp_register_board_cfg(struct 
omap_mcbsp_platform_data *config,
 void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg * 
config);
 int omap_mcbsp_request(unsigned int id);
 void omap_mcbsp_free(unsigned int id);
-void omap_mcbsp_start(unsigned int id);
-void omap_mcbsp_stop(unsigned int id);
+void omap_mcbsp_start(unsigned int id, int tx, int rx);
+void omap_mcbsp_stop(unsigned int id, int tx, int rx);
 void omap_mcbsp_xmit_word(unsigned int id, u32 word);
 u32 omap_mcbsp_recv_word(unsigned int id);
 
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index efa0e01..a3d2313 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -328,14 +328,15 @@ void omap_mcbsp_free(unsigned int id)
 EXPORT_SYMBOL(omap_mcbsp_free);
 
 /*
- * Here we start the McBSP, by enabling the sample
- * generator, both transmitter and receivers,
- * and the frame sync.
+ * Here we start the McBSP, by enabling transmitter, receiver or both.
+ * If no transmitter or receiver is active prior calling, then sample-rate
+ * generator and frame sync are started.
  */
-void omap_mcbsp_start(unsigned int id)
+void omap_mcbsp_start(unsigned int id, int tx, int rx)
 {
struct omap_mcbsp *mcbsp;
void __iomem *io_base;
+   int idle;
u16 w;
 
if (!omap_mcbsp_check_valid_id(id)) {
@@ -348,32 +349,40 @@ void omap_mcbsp_start(unsigned int id)
mcbsp-rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1)  5)  0x7;
mcbsp-tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1)  5)  0x7;
 
-   /* Start the sample generator */
-   w = OMAP_MCBSP_READ(io_base, SPCR2);
-   OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  6));
+   idle = !((OMAP_MCBSP_READ(io_base, SPCR2) |
+ OMAP_MCBSP_READ(io_base, SPCR1))  1);
+
+   if (idle) {
+   /* Start the sample generator */
+   w = OMAP_MCBSP_READ(io_base, SPCR2);
+   OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  6));
+   }
 
/* Enable transmitter and receiver */
w = OMAP_MCBSP_READ(io_base, SPCR2);
-   OMAP_MCBSP_WRITE(io_base, SPCR2, w | 1);
+   OMAP_MCBSP_WRITE(io_base, SPCR2, w | (tx  1));
 
w = OMAP_MCBSP_READ(io_base, SPCR1);
-   OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
+   OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx  1));
 
udelay(100);
 
-   /* Start frame sync */
-   w = OMAP_MCBSP_READ(io_base, SPCR2);
-   OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  7));
+   if (idle) {
+   /* Start frame sync */
+   w = OMAP_MCBSP_READ(io_base, SPCR2);
+   OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  7));
+   }
 
/* Dump McBSP Regs */
omap_mcbsp_dump_reg(id);
 }
 EXPORT_SYMBOL(omap_mcbsp_start);
 
-void omap_mcbsp_stop(unsigned int id)
+void omap_mcbsp_stop(unsigned int id, int tx, int rx)
 {
struct omap_mcbsp *mcbsp;
void __iomem *io_base;
+   int idle;
u16 w;
 
if (!omap_mcbsp_check_valid_id(id)) {
@@ -386,15 +395,20 @@ void omap_mcbsp_stop(unsigned int id)
 
/* Reset transmitter 

Re: N8x0 to mainline patches

[Tony Lindgren]

* Kalle Valo kalle.v...@iki.fi [090806 19:29]:
 On Thu, Aug 6, 2009 at 7:21 PM, Kalle Valokalle.v...@iki.fi wrote:
  My plan is this:
 
  1. first finish OMAP_TAG_UART removal patch and send it for review

This would be great.

  2. finins and send tusb6010 patch
 
  + omap2-add-usb-tusb6010-c

The tusb6010 could be added later on as a fix too if you want to cut
down dependencies.

  2. fold these n8x0 board file patches into one and send it for review:
 
  + n8x0-add-board-file
  + n8x0-onenand-support
  + n8x0-add-spi-support
  + n8x0-add-usb-support

Yeh one patch for the board file.
 
 This was item 3, of course. And I forget n8x0_defconfig, I'll send
 that as a separate patch.

Yeah it's easier to read the series that way.
 
 Tony, does this look ok to you?

Looks good to me!

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: N8x0 to mainline patches

[Tony Lindgren]

* Kalle Valo kalle.v...@iki.fi [090806 19:23]:
 Tony Lindgren t...@atomide.com writes:
 
  Hey, nice job cleaning up the n8x0 board support! Let's get those into
  l-o master and queued up for the next merge window. (Except for the
  hacks that is).
 
 What did you think of the file layout? I decided to go with one file
 approach (against your advice, sorry) because I didn't see any benefit
 from having separate files.

Your one file approach looks good to me.

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: N8x0 to mainline patches

[Kalle Valo]

Tony Lindgren t...@atomide.com writes:

  2. finins and send tusb6010 patch
 
  + omap2-add-usb-tusb6010-c

 The tusb6010 could be added later on as a fix too if you want to cut
 down dependencies.

Good point, I'll send that separately.

Current n8x0 patches are here:

http://www.valot.fi/kalle/n8x0/patches/n8x0-add/2009-08-06-19:21/

They are just pending final testing and I'll send them after I have done
that, hopefully tonight.

Tony, on which tree should I base the patches? They are now against
linus's tree.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe 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: N8x0 to mainline patches

[Tony Lindgren]

* Kalle Valo kalle.v...@iki.fi [090807 10:44]:
 Tony Lindgren t...@atomide.com writes:
 
   2. finins and send tusb6010 patch
  
   + omap2-add-usb-tusb6010-c
 
  The tusb6010 could be added later on as a fix too if you want to cut
  down dependencies.
 
 Good point, I'll send that separately.
 
 Current n8x0 patches are here:
 
 http://www.valot.fi/kalle/n8x0/patches/n8x0-add/2009-08-06-19:21/
 
 They are just pending final testing and I'll send them after I have done
 that, hopefully tonight.
 
 Tony, on which tree should I base the patches? They are now against
 linus's tree.

Great, yeah it's best to base all the patches against Linus' tree where
possible.

I'll start piling up the omap-upstream queue for the merge window and
will add your serial patch there. So we still have few more days to
deal with the board file patch.

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] MAINTAINERS: Add list entries linux-...@vger.kernel.org and linux-arm-kernel@ to OMAP sections

[Tony Lindgren]

Hi,

* Joe Perches j...@perches.com [090806 19:35]:
 Perhaps it's useful for OMAP patches and bug reports
 to CC entries to the primary and secondary ARM lists.
 
 Added a pattern entry for OMAP USB as well.

Good idea, except maybe let's leave out all the driver parts
because that will cause tons of extra noise on the lists,
see below.

 
 Signed-off-by: Joe Perches
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index b1114cf..f237765 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -3662,6 +3662,8 @@ F:  drivers/video/nvidia/
  OMAP SUPPORT
  M:   Tony Lindgren t...@atomide.com t...@atomide.com
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  W:   http://www.muru.com/linux/omap/
  W:   http://linux.omap.com/
  T:   git 
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
 @@ -3671,12 +3673,16 @@ F:arch/arm/*omap*
  OMAP CLOCK FRAMEWORK SUPPORT
  M:   Paul Walmsley p...@pwsan.com
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   arch/arm/*omap*/*clock*
  
  OMAP POWER MANAGEMENT SUPPORT
  M:   Kevin Hilman khil...@deeprootsystems.com
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   arch/arm/*omap*/*pm*
  
All the above look good to me, but..

 @@ -3684,6 +3690,8 @@ OMAP AUDIO SUPPORT
  M:   Jarkko Nikula jhnik...@gmail.com
  L:   alsa-de...@alsa-project.org (subscribers-only)
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   sound/soc/omap/
  
 @@ -3691,17 +3699,24 @@ OMAP FRAMEBUFFER SUPPORT
  M:   Imre Deak imre.d...@nokia.com
  L:   linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers)
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   drivers/video/omap/
  
  OMAP MMC SUPPORT
  M:   Jarkko Lavinen jarkko.lavi...@nokia.com
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   drivers/mmc/host/*omap*
  
  OMAP RANDOM NUMBER GENERATOR SUPPORT
  M:   Deepak Saxena dsax...@plexity.net
 +L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
  F:   drivers/char/hw_random/omap-rng.c
  
 @@ -3710,7 +3725,10 @@ M: Felipe Balbi felipe.ba...@nokia.com
  M:   David Brownell dbrown...@users.sourceforge.net
  L:   linux-...@vger.kernel.org
  L:   linux-omap@vger.kernel.org
 +L:   linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
 +L:   linux-...@vger.kernel.org
  S:   Maintained
 +F:   drivers/usb/*/*omap*
  
  OMFS FILESYSTEM
  M:   Bob Copeland m...@bobcopeland.com

... I think let's not add the drivers. The related driver list
and linux-omap list should be enough for these.

Regards,

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

Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Roger Quadros]

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:

Roger Quadros ext-roger.quad...@nokia.com writes:


As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
for automatic self-refresh before transition to OFF mode.
In the current implementation this is done in omap3_scratchpad_contents()
which is wrong, since this is the value that will be restored while
resuming from OFF mode and not while transitioning to it.

This patch implements the workaround in the correct way as per errata.

Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com

This looks right to me.

Rajendra, Kalle, any comments? since you were the originators of
the original patch.

Kevin


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

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index a7159a9..0a563c8 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE)  0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
-   /*
-* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
-* be programed to issue automatic self refresh on timeout
-* of AUTO_CNT = 1 prior to any transition to OFF mode.
-*/
-   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
-(omap_rev() = OMAP3430_REV_ES3_0))
-   sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
-   ~(SDRC_POWER_AUTOCOUNT_MASK|
-   SDRC_POWER_CLKCTRL_MASK)) |
-   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
-   SDRC_SELF_REFRESH_ON_AUTOCOUNT;
-   else
-   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
+
+   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);


Why do you want to remove the workaround from scratchpad?

When we wake up from off mode, the boot ROM code writes these settings
as the first sdrc_power settings after wakeup. If that setting does not
include the workaround, we'll have a period of time where sdram is not
being refreshed. This hits especially HS devices that do long secure
context restore in ROM code as well.


I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However when we 
enter OFF mode it should be _self_ refreshed. That is done by the below code 
before we switch to OFF mode.


When we wake up from OFF mode (the scratchpad contents are used), we should 
restore the original register setting that was there before we went to OFF mode 
and not the self refresh mode setting. Hence the removal of above code.


-roger
 
 	sdrc_block_contents.cs_0 = 0x0;

sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 14f10bc..eb3c9e5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -405,15 +405,23 @@ void omap_sram_idle(void)
}
 
 	/*

-   * On EMU/HS devices ROM code restores a SRDC value
-   * from scratchpad which has automatic self refresh on timeout
-   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
-   * Hence store/restore the SDRC_POWER register here.
-   */
+* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
+* be programed to issue automatic self refresh on timeout
+* of AUTO_CNT = 1 prior to any transition to OFF mode.
+*/
+
if (omap_rev() = OMAP3430_REV_ES3_0 
omap_type() != OMAP2_DEVICE_TYPE_GP 
-   core_next_state == PWRDM_POWER_OFF)
+   core_next_state == PWRDM_POWER_OFF) {
+
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
+   sdrc_write_reg((sdrc_pwr 
+   ~(SDRC_POWER_AUTOCOUNT_MASK|
+   SDRC_POWER_CLKCTRL_MASK)) |
+   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
+   SDRC_SELF_REFRESH_ON_AUTOCOUNT,
+   SDRC_POWER);
+   }


This part seems ok to me.

- Kalle


 
 	if (regset_save_on_suspend)

pm_dbg_regset_save(1);
--
1.6.0.4




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

Re: [PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Tony Lindgren]

* Jarkko Nikula jhnik...@gmail.com [090807 09:59]:
 Simultaneous audio playback and capture on OMAP1510 can cause that second
 stream is stalled if there is enough delay between startup of the audio
 streams.
 
 Current implementation of the omap_mcbsp_start is starting both transmitter
 and receiver at the same time and it is called only for firstly started
 audio stream from the OMAP McBSP based ASoC DAI driver.
 
 Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is
 missed if there is no DMA transfer set up at that time when the first word
 after McBSP startup is transmitted. The problem hasn't noted before since
 later OMAPs are using level sensitive DMA request lines.
 
 Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by
 allowing to start and stop individually McBSP transmitter and receiver
 logics. Then call those functions individually for both audio playback
 and capture streams. This ensures that DMA transfer is setup before
 transmitter or receiver is started.
 
 Thanks to Janusz Krzysztofik jkrzy...@tis.icnet.pl for detailed problem
 analysis and Peter Ujfalusi peter.ujfal...@nokia.com for info about DMA
 request line behavior differences between the OMAP generations.
 
 Reported-and-tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 Cc: Mark Brown broo...@opensource.wolfsonmicro.com
 Cc: Tony Lindgren t...@atomide.com

This seems OK to me queue via the alsa list as it's mostly audio related.

Acked-by: Tony Lindgren t...@atomide.com




 ---
  arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
  arch/arm/plat-omap/mcbsp.c  |   50 +++---
  sound/soc/omap/omap-mcbsp.c |   10 +++---
  3 files changed, 39 insertions(+), 25 deletions(-)
 
 diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h 
 b/arch/arm/plat-omap/include/mach/mcbsp.h
 index bb154ea..57249bb 100644
 --- a/arch/arm/plat-omap/include/mach/mcbsp.h
 +++ b/arch/arm/plat-omap/include/mach/mcbsp.h
 @@ -387,8 +387,8 @@ void omap_mcbsp_register_board_cfg(struct 
 omap_mcbsp_platform_data *config,
  void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg * 
 config);
  int omap_mcbsp_request(unsigned int id);
  void omap_mcbsp_free(unsigned int id);
 -void omap_mcbsp_start(unsigned int id);
 -void omap_mcbsp_stop(unsigned int id);
 +void omap_mcbsp_start(unsigned int id, int tx, int rx);
 +void omap_mcbsp_stop(unsigned int id, int tx, int rx);
  void omap_mcbsp_xmit_word(unsigned int id, u32 word);
  u32 omap_mcbsp_recv_word(unsigned int id);
  
 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
 index efa0e01..a3d2313 100644
 --- a/arch/arm/plat-omap/mcbsp.c
 +++ b/arch/arm/plat-omap/mcbsp.c
 @@ -328,14 +328,15 @@ void omap_mcbsp_free(unsigned int id)
  EXPORT_SYMBOL(omap_mcbsp_free);
  
  /*
 - * Here we start the McBSP, by enabling the sample
 - * generator, both transmitter and receivers,
 - * and the frame sync.
 + * Here we start the McBSP, by enabling transmitter, receiver or both.
 + * If no transmitter or receiver is active prior calling, then sample-rate
 + * generator and frame sync are started.
   */
 -void omap_mcbsp_start(unsigned int id)
 +void omap_mcbsp_start(unsigned int id, int tx, int rx)
  {
   struct omap_mcbsp *mcbsp;
   void __iomem *io_base;
 + int idle;
   u16 w;
  
   if (!omap_mcbsp_check_valid_id(id)) {
 @@ -348,32 +349,40 @@ void omap_mcbsp_start(unsigned int id)
   mcbsp-rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1)  5)  0x7;
   mcbsp-tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1)  5)  0x7;
  
 - /* Start the sample generator */
 - w = OMAP_MCBSP_READ(io_base, SPCR2);
 - OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  6));
 + idle = !((OMAP_MCBSP_READ(io_base, SPCR2) |
 +   OMAP_MCBSP_READ(io_base, SPCR1))  1);
 +
 + if (idle) {
 + /* Start the sample generator */
 + w = OMAP_MCBSP_READ(io_base, SPCR2);
 + OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  6));
 + }
  
   /* Enable transmitter and receiver */
   w = OMAP_MCBSP_READ(io_base, SPCR2);
 - OMAP_MCBSP_WRITE(io_base, SPCR2, w | 1);
 + OMAP_MCBSP_WRITE(io_base, SPCR2, w | (tx  1));
  
   w = OMAP_MCBSP_READ(io_base, SPCR1);
 - OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
 + OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx  1));
  
   udelay(100);
  
 - /* Start frame sync */
 - w = OMAP_MCBSP_READ(io_base, SPCR2);
 - OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  7));
 + if (idle) {
 + /* Start frame sync */
 + w = OMAP_MCBSP_READ(io_base, SPCR2);
 + OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1  7));
 + }
  
   /* Dump McBSP Regs */
   omap_mcbsp_dump_reg(id);
  }
  EXPORT_SYMBOL(omap_mcbsp_start);
  
 -void omap_mcbsp_stop(unsigned int id)
 +void omap_mcbsp_stop(unsigned int id, int tx, int rx)
  {
   struct 

Re: MMC3 Overo

[Tony Lindgren]

* Peter Barada pet...@logicpd.com [090806 19:31]:
 On Thu, 2009-08-06 at 11:09 -0400, Philip Balister wrote:
  Kevin Hilman wrote:
   John Sarman johnsar...@gmail.com writes:
   
   On Wed, Aug 5, 2009 at 2:35 PM, Kevin 
   Hilmankhil...@deeprootsystems.com wrote:
   Steve Sakoman wrote:
   On Wed, Aug 5, 2009 at 10:58 AM, Kevin
   Hilmankhil...@deeprootsystems.com wrote:
   Steve Sakoman wrote:
   And up to now in each case I shrug and say no time to do that now,
   I'll just leave kernel pinmuxing turned off and do it in u-boot
   I agree there are lots of shortcomings in the current mux code and 
   we've
   been hitting them regularily lately.
  
   That being said, for mux settings that done one-time only at boot, 
   what
   are
   the problems you're running into?
   It's been a few months since I last encountered this, so the exact
   details are a bit fuzzy.
  
   I seem to recall that there were some basic issues with enabling
   kernel pinmuxing in that some of the setup that was done for all
   machines was just wrong for my particular machine.  IIRC, it was due
   to assumptions about which pad was used for a particular function (for
   those functions which can be steered to multiple GPIO pads).
  
   So I faced having to undo that change in my board file as well as any
   issues that may have arisen from glitches on the GPIO pins during the
   process.  And since there were several of these I gave up and turned
   off kernel pinmuxing.
  
   I'd be happy if we cleaned up the one size fits all pinmuxing to
   just that subset that truly does fit all boards, and leave the rest to
   the board files.  I'd also be content to have it all done in the board
   file for each machine.
   Indeed, any assumptions about common muxing that are not indeed common 
   are
   bugs and should be fixed.
  
   The right solution is to have everything in the kernel, and split 
   across
   SoC common init and board specific init.  Of course u-boot
   will still have to do some early muxing, but it should be redone in
   the kernel so it's trivial to change bootloaders.
  
   So the real missing piece is someone to step up and rework the mux code.
   The bigger problem is that the vast majority of folks don't care about 
   the
   common case and only care about getting thing working for a specific
   platform.
  
   Kevin
  
   I  like the idea of having the board file configure the mux.  First of
   all lets address the shortcomings of mux.h.  The Pin values are
   labeled as so:
   snip from mux.h
   * NOTE: Please use the following naming style for new pin entries.
*   For example, W8_1610_MMC2_DAT0, where:
*   - W8= ball
*   - 1610  = 1510 or 1610, none if common for both 1510 and 
   1610
*   - MMC2_DAT0 = function
  
   But lets take the 3530 as an example.
The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
   look at MMC3_clk (the root of my original problem that started this
   thread)
  CBB  CBCCUS
   mmc3_clk AB1 / AF10R9 / AB2 AC1
  
   So to properly add these to mux.h we need to add 5 entries for mmc3_clk
 AB1_35XXCBB_MMC3_CLK
 AF10_35XXCBB_MMC3_CLK
 R9_35XXCBC_MMC3_CLK
 AB2_35XXCBC_MMC3_CLK
 AC1_35XXCUS_MMC3_CLK
   We would then have to update mux.c making sure the position matches
   and add the proper settings.
  
   So this is obviously a maintenance nightmare.
   
   So why don't we drop the ball (pun intended.) ;)
   
   This is what I proposed to Phillip Ballister for his SPI changes for 
   Beagle.
   
   Though I haven't looked at the details for each package, I have a hard
   time imagining that the reg offsets and functionality for each package
   is different.  In fact, I'm pretty sure they're even the same between
   34xx and 35xx.  
   
   IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
   
   Then each board file that cares simply has to call omap_cfg_reg() on
   that name and not care about the package.
  
  They first problem I see is the MMC3_CLK is available on multiple balls, 
  so the mux files need to list them all.
  
  Unless you are proposing custom mux files for each board? Is this is 
  good idea (just had this thought). In other words, instead of trying to 
  come up with one set of mux files, make them board specific.
 
 Here's an idea:
 
 1) Replace index with enum search in pin table - this breaks the
 requirement that the enum list and table align - a good thing as
 misalingment has bitten me multiple times when adding pins to the
 current mux table.  Also, pinmux setup is done infrequently, so the
 search doesn't add much overall execution time.

Yeh something like that sounds good. We should just move the omap1
specific code to live in mach-omap1 and keep it as it is for now.

You might also want to take a look at what the sh people have done:

$ find arch/sh -name \*mux*
 
 2) 

Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

[Tony Lindgren]

* Kevin Hilman khil...@deeprootsystems.com [090806 17:56]:
 Premi, Sanjeev pr...@ti.com writes:
 
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com] 
  Sent: Thursday, August 06, 2009 5:20 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
  
  * Premi, Sanjeev pr...@ti.com [090806 14:34]:

-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com] 
Sent: Thursday, August 06, 2009 4:34 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

Hi,

* Sanjeev Premi pr...@ti.com [090806 13:36]:
 Added runtime check via omap2_set_globals_35xx().
 
 Parts of this patch have been derived from an earlier
 earlier patch submitted by Tony Lindgren t...@atomide.com
 
  [1] http://marc.info/?l=linux-omapm=123301852702797w=2
  [2] http://marc.info/?l=linux-omapm=123334055822212w=2
 
 Signed-off-by: Sanjeev Premi pr...@ti.com
 ---
  arch/arm/mach-omap2/id.c |  115 
--
  arch/arm/plat-omap/common.c  |   18 +-
  arch/arm/plat-omap/include/mach/common.h |1 +
  arch/arm/plat-omap/include/mach/cpu.h|   64 
  -
  4 files changed, 173 insertions(+), 25 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index a98201c..06770aa 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -28,6 +28,14 @@
  static struct omap_chip_id omap_chip;
  static unsigned int omap_revision;
  
 +/* The new OMAP35x devices have assymetric names - 
OMAP3505 and OMAP3517.
 + * It is not possible to define a common macro to 
  identify them.
 + *
 + * A quick way is to separate them across 
  'generations' as below.
 + */
 +#define OMAP35XX_G1 0x1 /* Applies to 3503, 
3515, 3525 and 3530 */
 +#define OMAP35XX_G2 0x2 /* Applies to 3505 and 3517 */
 +
  
  unsigned int omap_rev(void)
  {
 @@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
  pr_info(\n);
  }
  
 +static void __init omap34xx_set_revision(u8 rev, char 
  *rev_name)
 +{
 +switch (rev) {
 +case 0:
 +omap_revision = OMAP3430_REV_ES2_0;
 +strcat(rev_name, ES2.0);
 +break;
 +case 2:
 +omap_revision = OMAP3430_REV_ES2_1;
 +strcat(rev_name, ES2.1);
 +break;
 +case 3:
 +omap_revision = OMAP3430_REV_ES3_0;
 +strcat(rev_name, ES3.0);
 +break;
 +case 4:
 +omap_revision = OMAP3430_REV_ES3_1;
 +strcat(rev_name, ES3.1);
 +break;
 +default:
 +/* Use the latest known revision as default */
 +omap_revision = OMAP3430_REV_ES3_1;
 +strcat(rev_name, Unknown revision);
 +}
 +}
 +
 +static void __init omap35xx_set_revision(u8 rev, u8 gen, 
char *rev_name)
 +{
 +omap_revision = OMAP35XX_CLASS ;
 +
 +if (gen == OMAP35XX_G1) {
 +switch (rev) {
 +case 0: /* Take care of some older boards */
 +case 1:
 +omap_revision |= OMAP35XX_MASK_ES2_0;
 +strcat(rev_name, ES2.0);
 +break;
 +case 2:
 +omap_revision |= OMAP35XX_MASK_ES2_1;
 +strcat(rev_name, ES2.1);
 +break;
 +case 3:
 +omap_revision |= OMAP35XX_MASK_ES3_0;
 +strcat(rev_name, ES3.0);
 +break;
 +case 4:
 +omap_revision |= OMAP35XX_MASK_ES3_1;
 +strcat(rev_name, ES3.1);
 +break;
 +default:
 +/* Use the latest known 
  revision as default */
 +omap_revision |= OMAP35XX_MASK_ES3_0;
 +strcat(rev_name, Unknown revision);
 +}
 +} else {
 +strcat(rev_name, ES1.0);
 +}
 +}
 +

To me it looks like you're checking the exact same cores as 
we already do
for 34xx. That is, (idcode  28)  0xff for both 34xx and 
35xx. So basically
they have the same omap cores.
   
   No, the cores in OMAP3505 and OMAP3517 are very different.
   I have listed major differences in PATCH 2/6.
   
   These devices differ in following areas:
- Power management capabilities
  (Only 1 power domain, 1 OPP, etc.)
- EMIF4 instead of SDRC
- Support for DDR2
- EMAC
- USB
  

Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Kalle Jokiniemi]

On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote:
 ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:
  Roger Quadros ext-roger.quad...@nokia.com writes:
 
  As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
  for automatic self-refresh before transition to OFF mode.
  In the current implementation this is done in omap3_scratchpad_contents()
  which is wrong, since this is the value that will be restored while
  resuming from OFF mode and not while transitioning to it.
 
  This patch implements the workaround in the correct way as per errata.
 
  Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
  This looks right to me.
 
  Rajendra, Kalle, any comments? since you were the originators of
  the original patch.
 
  Kevin
 
  ---
   arch/arm/mach-omap2/control.c |   16 ++--
   arch/arm/mach-omap2/pm34xx.c  |   20 ++--
   2 files changed, 16 insertions(+), 20 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
  index a7159a9..0a563c8 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE)  0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
  - /*
  -  * Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  -  * be programed to issue automatic self refresh on timeout
  -  * of AUTO_CNT = 1 prior to any transition to OFF mode.
  -  */
  - if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
  -  (omap_rev() = OMAP3430_REV_ES3_0))
  - sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
  - ~(SDRC_POWER_AUTOCOUNT_MASK|
  - SDRC_POWER_CLKCTRL_MASK)) |
  - (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  - SDRC_SELF_REFRESH_ON_AUTOCOUNT;
  - else
  - sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  +
  + sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  
  Why do you want to remove the workaround from scratchpad?
  
  When we wake up from off mode, the boot ROM code writes these settings
  as the first sdrc_power settings after wakeup. If that setting does not
  include the workaround, we'll have a period of time where sdram is not
  being refreshed. This hits especially HS devices that do long secure
  context restore in ROM code as well.
  
  
 I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However when 
 we 
 enter OFF mode it should be _self_ refreshed. That is done by the below code 
 before we switch to OFF mode.

The erratum speaks of auto-refresh failing after waking up from CORE off
mode. I think there is the described workaround in place in sleep34xx.S
code to kick up the auto refresh, but this still leaves a short gap
between boot ROM and the sleep code.

Unless the self-refresh mode does not get changed by the scratchpad
settings?

- Kalle

 
 When we wake up from OFF mode (the scratchpad contents are used), we should 
 restore the original register setting that was there before we went to OFF 
 mode 
 and not the self refresh mode setting. Hence the removal of above code.
 
 -roger
   
sdrc_block_contents.cs_0 = 0x0;
sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
  diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
  index 14f10bc..eb3c9e5 100644
  --- a/arch/arm/mach-omap2/pm34xx.c
  +++ b/arch/arm/mach-omap2/pm34xx.c
  @@ -405,15 +405,23 @@ void omap_sram_idle(void)
}
   
/*
  - * On EMU/HS devices ROM code restores a SRDC value
  - * from scratchpad which has automatic self refresh on timeout
  - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
  - * Hence store/restore the SDRC_POWER register here.
  - */
  +  * Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  +  * be programed to issue automatic self refresh on timeout
  +  * of AUTO_CNT = 1 prior to any transition to OFF mode.
  +  */
  +
if (omap_rev() = OMAP3430_REV_ES3_0 
omap_type() != OMAP2_DEVICE_TYPE_GP 
  - core_next_state == PWRDM_POWER_OFF)
  + core_next_state == PWRDM_POWER_OFF) {
  +
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
  + sdrc_write_reg((sdrc_pwr 
  + ~(SDRC_POWER_AUTOCOUNT_MASK|
  + SDRC_POWER_CLKCTRL_MASK)) |
  + (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  + SDRC_SELF_REFRESH_ON_AUTOCOUNT,
  + SDRC_POWER);
  + }
  
  This part seems ok to me.
  
  - Kalle
  
  
   
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
  -- 
  1.6.0.4
  
 

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

Re: [alsa-devel] [PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Jarkko Nikula]

On Fri, 7 Aug 2009 11:30:54 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:

 Looks nice, but I would have done it a bit differently...
 
...
  -void omap_mcbsp_start(unsigned int id);
  -void omap_mcbsp_stop(unsigned int id);
  +void omap_mcbsp_start(unsigned int id, int tx, int rx);
  +void omap_mcbsp_stop(unsigned int id, int tx, int rx);
 
 void omap_mcbsp_start(unsigned int id, int dir);
 void omap_mcbsp_stop(unsigned int id, int dir);
 
Valid point and cleans up a bit the ALSA SoC part of the patch.
However I didn't want to limit this generic arch/arm/plat-omap/mcbsp.c
into audio use case only. My change still allows to start transmitter
and receiver exactly at the same time. Might be worth if the
generic McBSP driver is used for something else than audio.


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

Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Roger Quadros]

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote:

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:

Roger Quadros ext-roger.quad...@nokia.com writes:


As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
for automatic self-refresh before transition to OFF mode.
In the current implementation this is done in omap3_scratchpad_contents()
which is wrong, since this is the value that will be restored while
resuming from OFF mode and not while transitioning to it.

This patch implements the workaround in the correct way as per errata.

Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com

This looks right to me.

Rajendra, Kalle, any comments? since you were the originators of
the original patch.

Kevin


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

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index a7159a9..0a563c8 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE)  0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
-   /*
-* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
-* be programed to issue automatic self refresh on timeout
-* of AUTO_CNT = 1 prior to any transition to OFF mode.
-*/
-   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
-(omap_rev() = OMAP3430_REV_ES3_0))
-   sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
-   ~(SDRC_POWER_AUTOCOUNT_MASK|
-   SDRC_POWER_CLKCTRL_MASK)) |
-   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
-   SDRC_SELF_REFRESH_ON_AUTOCOUNT;
-   else
-   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
+
+   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);

Why do you want to remove the workaround from scratchpad?

When we wake up from off mode, the boot ROM code writes these settings
as the first sdrc_power settings after wakeup. If that setting does not
include the workaround, we'll have a period of time where sdram is not
being refreshed. This hits especially HS devices that do long secure
context restore in ROM code as well.


I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However when we 
enter OFF mode it should be _self_ refreshed. That is done by the below code 
before we switch to OFF mode.


The erratum speaks of auto-refresh failing after waking up from CORE off
mode. I think there is the described workaround in place in sleep34xx.S
code to kick up the auto refresh, but this still leaves a short gap
between boot ROM and the sleep code.

Unless the self-refresh mode does not get changed by the scratchpad
settings?

- Kalle


There are 2 parts in the errata 1.142.

The 1st part is what you are talking about. And it needs to be applied only on 
ES3.0 devices.


The 2nd part is valid only for HS devices.
..it is mandatory on HS device to have the SDRC issuing automatic self-refresh
entries on inactivity periods..

My patch is only fixing the implementation of the 2nd part without changing the 
work around for the 1st part. no?


-roger



When we wake up from OFF mode (the scratchpad contents are used), we should 
restore the original register setting that was there before we went to OFF mode 
and not the self refresh mode setting. Hence the removal of above code.


-roger
 
 	sdrc_block_contents.cs_0 = 0x0;

sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 14f10bc..eb3c9e5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -405,15 +405,23 @@ void omap_sram_idle(void)
}
 
 	/*

-   * On EMU/HS devices ROM code restores a SRDC value
-   * from scratchpad which has automatic self refresh on timeout
-   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
-   * Hence store/restore the SDRC_POWER register here.
-   */
+* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
+* be programed to issue automatic self refresh on timeout
+* of AUTO_CNT = 1 prior to any transition to OFF mode.
+*/
+
if (omap_rev() = OMAP3430_REV_ES3_0 
omap_type() != OMAP2_DEVICE_TYPE_GP 
-   core_next_state == PWRDM_POWER_OFF)
+   core_next_state == PWRDM_POWER_OFF) {
+
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
+   sdrc_write_reg((sdrc_pwr 
+   ~(SDRC_POWER_AUTOCOUNT_MASK|
+   

Re: [alsa-devel] [PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Peter Ujfalusi]

On Friday 07 August 2009 11:47:57 ext Jarkko Nikula wrote:
 On Fri, 7 Aug 2009 11:30:54 +0300

 Peter Ujfalusi peter.ujfal...@nokia.com wrote:
  Looks nice, but I would have done it a bit differently...

 ...

   -void omap_mcbsp_start(unsigned int id);
   -void omap_mcbsp_stop(unsigned int id);
   +void omap_mcbsp_start(unsigned int id, int tx, int rx);
   +void omap_mcbsp_stop(unsigned int id, int tx, int rx);
 
  void omap_mcbsp_start(unsigned int id, int dir);
  void omap_mcbsp_stop(unsigned int id, int dir);

 Valid point and cleans up a bit the ALSA SoC part of the patch.
 However I didn't want to limit this generic arch/arm/plat-omap/mcbsp.c
 into audio use case only. My change still allows to start transmitter
 and receiver exactly at the same time. Might be worth if the
 generic McBSP driver is used for something else than audio.

Good point.

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

Re: [alsa-devel] [PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Peter Ujfalusi]

On Friday 07 August 2009 09:59:47 ext Jarkko Nikula wrote:
 Simultaneous audio playback and capture on OMAP1510 can cause that second
 stream is stalled if there is enough delay between startup of the audio
 streams.

 Current implementation of the omap_mcbsp_start is starting both transmitter
 and receiver at the same time and it is called only for firstly started
 audio stream from the OMAP McBSP based ASoC DAI driver.

 Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is
 missed if there is no DMA transfer set up at that time when the first word
 after McBSP startup is transmitted. The problem hasn't noted before since
 later OMAPs are using level sensitive DMA request lines.

 Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by
 allowing to start and stop individually McBSP transmitter and receiver
 logics. Then call those functions individually for both audio playback
 and capture streams. This ensures that DMA transfer is setup before
 transmitter or receiver is started.

 Thanks to Janusz Krzysztofik jkrzy...@tis.icnet.pl for detailed problem
 analysis and Peter Ujfalusi peter.ujfal...@nokia.com for info about DMA
 request line behavior differences between the OMAP generations.

 Reported-and-tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 Cc: Mark Brown broo...@opensource.wolfsonmicro.com
 Cc: Tony Lindgren t...@atomide.com
 ---
  arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
  arch/arm/plat-omap/mcbsp.c  |   50
 +++--- sound/soc/omap/omap-mcbsp.c |  
 10 +++---
  3 files changed, 39 insertions(+), 25 deletions(-)

Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com

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

PM: UART not resuming from OFF mode

[Roger Quadros]

Hi,

 I'm facing this strange problem since some days. I have 3 identical boards 
using OMAP3430 ES3.1 and I'm using Kevin's PM tree. 
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm


The problem is that UART3 fails to operate correctly after OFF mode on _two_ of 
the boards but works on one. It seems to receive characters but 0 only. So 
characters do not show up on terminal.


Is anybody experiencing similar problems with UART and off mode on your boards?

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

Git pull request for omap fixes for 2.6.31

[Tony Lindgren]

Hi Russell,

Here's the pull request for you.

Tony
The following changes since commit ed680c4ad478d0fee9740f7d029087f181346564:
  Linus Torvalds (1):
Linux 2.6.31-rc5

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-fixes

Janboe Ye (1):
  OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after 
increasing vmalloc size

Roger Quadros (4):
  OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs
  OMAP3: RX51: Define TWL4030 USB transceiver in board file
  OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up
  OMAP3: RX51: Updated rx51_defconfig

Sergio Aguirre (1):
  OMAP3: Overo: Fix smsc911x platform device resource value

Vikram Pandita (1):
  OMAP2/3: DMA errata correction

 arch/arm/configs/rx51_defconfig  |7 ++-
 arch/arm/mach-omap2/board-overo.c|2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |5 ++
 arch/arm/mach-omap2/mmc-twl4030.c|6 ++
 arch/arm/plat-omap/dma.c |4 +-
 arch/arm/plat-omap/gpio.c|   68 --
 arch/arm/plat-omap/sram.c|4 +-
 7 files changed, 85 insertions(+), 11 deletions(-)

Re: [PATCH 1/2] OMAP2: Add funcs for writing SMS_ROT_* registers

[Tomi Valkeinen]

Hmm sorry, this was meant to be [PATCH 1/1].

 Tomi


Valkeinen Tomi (Nokia-D/Helsinki) wrote:

SMS_ROT_* registers are used by VRFB rotation engine.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/mach-omap2/sdrc.c |   16 
 arch/arm/plat-omap/include/mach/sdrc.h |8 +++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 2045441..56f6dab 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -111,3 +111,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
(1  SDRC_POWER_PAGEPOLICY_SHIFT);
sdrc_write_reg(l, SDRC_POWER);
 }
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_CONTROL(ctx));
+}
+
+void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_SIZE(ctx));
+}
+
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
+}
+
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h 
b/arch/arm/plat-omap/include/mach/sdrc.h
index adc7352..4199c19 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -75,7 +75,10 @@
 
 /* SMS register offsets - read/write with sms_{read,write}_reg() */
 
-#define SMS_SYSCONFIG		0x010

+#define SMS_SYSCONFIG  0x010
+#define SMS_ROT_CONTROL(context)   (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context)  (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context)   (0x188 + 0x10 * context)
 /* REVISIT: fill in other SMS registers here */
 
 
@@ -104,6 +107,9 @@ struct omap_sdrc_params {
 
 void __init omap2_sdrc_init(struct omap_sdrc_params *sp);

 struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
 
 #ifdef CONFIG_ARCH_OMAP2
 


--
To unsubscribe from this list: send the line unsubscribe 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] [PATCH][2.6.31-rc5] ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop

[Peter Ujfalusi]

On Friday 07 August 2009 09:59:47 ext Jarkko Nikula wrote:
 Simultaneous audio playback and capture on OMAP1510 can cause that second
 stream is stalled if there is enough delay between startup of the audio
 streams.

 Current implementation of the omap_mcbsp_start is starting both transmitter
 and receiver at the same time and it is called only for firstly started
 audio stream from the OMAP McBSP based ASoC DAI driver.

 Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is
 missed if there is no DMA transfer set up at that time when the first word
 after McBSP startup is transmitted. The problem hasn't noted before since
 later OMAPs are using level sensitive DMA request lines.

 Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by
 allowing to start and stop individually McBSP transmitter and receiver
 logics. Then call those functions individually for both audio playback
 and capture streams. This ensures that DMA transfer is setup before
 transmitter or receiver is started.

Looks nice, but I would have done it a bit differently...


 Thanks to Janusz Krzysztofik jkrzy...@tis.icnet.pl for detailed problem
 analysis and Peter Ujfalusi peter.ujfal...@nokia.com for info about DMA
 request line behavior differences between the OMAP generations.

 Reported-and-tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 Cc: Mark Brown broo...@opensource.wolfsonmicro.com
 Cc: Tony Lindgren t...@atomide.com
 ---
  arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
  arch/arm/plat-omap/mcbsp.c  |   50
 +++--- sound/soc/omap/omap-mcbsp.c |  
 10 +++---
  3 files changed, 39 insertions(+), 25 deletions(-)

 diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
 b/arch/arm/plat-omap/include/mach/mcbsp.h index bb154ea..57249bb 100644
 --- a/arch/arm/plat-omap/include/mach/mcbsp.h
 +++ b/arch/arm/plat-omap/include/mach/mcbsp.h
 @@ -387,8 +387,8 @@ void omap_mcbsp_register_board_cfg(struct
 omap_mcbsp_platform_data *config, void omap_mcbsp_config(unsigned int id,
 const struct omap_mcbsp_reg_cfg * config); int omap_mcbsp_request(unsigned
 int id);
  void omap_mcbsp_free(unsigned int id);
 -void omap_mcbsp_start(unsigned int id);
 -void omap_mcbsp_stop(unsigned int id);
 +void omap_mcbsp_start(unsigned int id, int tx, int rx);
 +void omap_mcbsp_stop(unsigned int id, int tx, int rx);

void omap_mcbsp_start(unsigned int id, int dir);
void omap_mcbsp_stop(unsigned int id, int dir);

  void omap_mcbsp_xmit_word(unsigned int id, u32 word);
  u32 omap_mcbsp_recv_word(unsigned int id);

 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
 index efa0e01..a3d2313 100644
 --- a/arch/arm/plat-omap/mcbsp.c
 +++ b/arch/arm/plat-omap/mcbsp.c
 @@ -328,14 +328,15 @@ void omap_mcbsp_free(unsigned int id)
  EXPORT_SYMBOL(omap_mcbsp_free);

  /*
 - * Here we start the McBSP, by enabling the sample
 - * generator, both transmitter and receivers,
 - * and the frame sync.
 + * Here we start the McBSP, by enabling transmitter, receiver or both.
 + * If no transmitter or receiver is active prior calling, then sample-rate
 + * generator and frame sync are started.

 * dir == 0: tx
 * dir == 1: rx

   */
 -void omap_mcbsp_start(unsigned int id)
 +void omap_mcbsp_start(unsigned int id, int tx, int rx)

void omap_mcbsp_start(unsigned int id, int dir)

  {
   struct omap_mcbsp *mcbsp;
   void __iomem *io_base;
 + int idle;
   u16 w;

...

   /* Enable transmitter and receiver */
   w = OMAP_MCBSP_READ(io_base, SPCR2);
 - OMAP_MCBSP_WRITE(io_base, SPCR2, w | 1);
 + OMAP_MCBSP_WRITE(io_base, SPCR2, w | (tx  1));

   w = OMAP_MCBSP_READ(io_base, SPCR1);
 - OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
 + OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx  1));

if (dir) {
/* RX: Enable receiver */
w = OMAP_MCBSP_READ(io_base, SPCR1);
OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
} else {
/* TX: Enable transmitter */
w = OMAP_MCBSP_READ(io_base, SPCR2);
OMAP_MCBSP_WRITE(io_base, SPCR2, w | 1);
}

   udelay(100);

...

 -void omap_mcbsp_stop(unsigned int id)
 +void omap_mcbsp_stop(unsigned int id, int tx, int rx)

void omap_mcbsp_stop(unsigned int id, int dir)

  {
   struct omap_mcbsp *mcbsp;
   void __iomem *io_base;
 + int idle;
   u16 w;

   if (!omap_mcbsp_check_valid_id(id)) {
 @@ -386,15 +395,20 @@ void omap_mcbsp_stop(unsigned int id)

   /* Reset transmitter */
   w = OMAP_MCBSP_READ(io_base, SPCR2);
 - OMAP_MCBSP_WRITE(io_base, SPCR2, w  ~(1));
 + OMAP_MCBSP_WRITE(io_base, SPCR2, w  ~(tx  1));

   /* Reset receiver */
   w = OMAP_MCBSP_READ(io_base, SPCR1);
 - OMAP_MCBSP_WRITE(io_base, SPCR1, w  ~(1));
 + OMAP_MCBSP_WRITE(io_base, SPCR1, w  ~(rx  1));

if (dir) {
/* RX: 

Re: [PATCH 04/15] OMAP: Add support for VRFB rotation engine

[Tomi Valkeinen]

ext Tony Lindgren wrote:

* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:

VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.

Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/plat-omap/Kconfig |3 +
 arch/arm/plat-omap/Makefile|1 +
 arch/arm/plat-omap/include/mach/vrfb.h |   46 +
 arch/arm/plat-omap/vrfb.c  |  281 
 4 files changed, 331 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
 create mode 100644 arch/arm/plat-omap/vrfb.c

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ca06037..2d6ae55 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -186,6 +186,9 @@ config OMAP_SERIAL_WAKE
 config OMAP2_VRAM
  bool

+config OMAP2_VRFB
+ bool
+
 endmenu

 endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 0472bbe..462edf3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -26,3 +26,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
 obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o

 obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o


Can you please place this file under drivers/video?


Ok. I still feel a common place, like plat-omap is better place for vrfb 
and vram, but I don't feel too strongly about it =). drivers/video works 
fine also.






diff --git a/arch/arm/plat-omap/include/mach/vrfb.h 
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644


snip


+
+static inline void restore_hw_context(int ctx)
+{
+ omap_writel(vrfb_hw_context[ctx].control, SMS_ROT_CONTROL(ctx));
+ omap_writel(vrfb_hw_context[ctx].size, SMS_ROT_SIZE(ctx));
+ omap_writel(vrfb_hw_context[ctx].physical_ba, SMS_ROT_PHYSICAL_BA(ctx));
+}


Please use ioremap + and readl/writel instead of omap_read/write for all new 
code.

Otherwise we'll have harder time to reclaim more address space for kernel
as discussed earlier on linux-omap list.


True. But I noticed that SMS registers are already mapped by sdrc.c. I 
sent a patch adding functions for manipulating SMS_ROT_* registers. I 
think that's a cleaner way than remapping them again in VRFB.


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

[PATCH 1/2] OMAP2: Add funcs for writing SMS_ROT_* registers

[Tomi Valkeinen]

SMS_ROT_* registers are used by VRFB rotation engine.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/mach-omap2/sdrc.c |   16 
 arch/arm/plat-omap/include/mach/sdrc.h |8 +++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 2045441..56f6dab 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -111,3 +111,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
(1  SDRC_POWER_PAGEPOLICY_SHIFT);
sdrc_write_reg(l, SDRC_POWER);
 }
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_CONTROL(ctx));
+}
+
+void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_SIZE(ctx));
+}
+
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
+}
+
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h 
b/arch/arm/plat-omap/include/mach/sdrc.h
index adc7352..4199c19 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -75,7 +75,10 @@
 
 /* SMS register offsets - read/write with sms_{read,write}_reg() */
 
-#define SMS_SYSCONFIG  0x010
+#define SMS_SYSCONFIG  0x010
+#define SMS_ROT_CONTROL(context)   (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context)  (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context)   (0x188 + 0x10 * context)
 /* REVISIT: fill in other SMS registers here */
 
 
@@ -104,6 +107,9 @@ struct omap_sdrc_params {
 
 void __init omap2_sdrc_init(struct omap_sdrc_params *sp);
 struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
 
 #ifdef CONFIG_ARCH_OMAP2
 
-- 
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 3/9] ehci: correct EHCI init parameters on OMAP3EVM

[Gupta, Ajay Kumar]

  diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
 omap2/board-omap3evm.c
  index 595beac..b497979 100644
  --- a/arch/arm/mach-omap2/board-omap3evm.c
  +++ b/arch/arm/mach-omap2/board-omap3evm.c
  @@ -308,7 +308,9 @@ static void __init omap3_evm_init(void)
 
  omap_serial_init();
  usb_musb_init();
  -   usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
  +   /* Setup EHCI phy reset padconfig */
  +   omap_cfg_reg(AF4_34XX_GPIO135_OUT);
  +   usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, false, true, -EINVAL, 135);
  ads7846_dev_init();
   }
 
 Is this safe to do if you don't have the daughter card? If so, maybe
 add a comment for it.

Yes, it is safe for OMAP3EVM even if there is no DC but we can add comment as 
you suggested.

 
 I guess the nicest thing would be to wait until the daughter card
 is probed based on some I2C chip id and only then mux the pins.

I agree that this would be the best but this requires OMAP3EVM DC related patch 
from Vaibhav which is still under review.

I feel we can add this logic once other dependent patches are accepted.

-Ajay
 
 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: Git pull request for omap fixes for 2.6.31

[Russell King - ARM Linux]

On Fri, Aug 07, 2009 at 12:01:48PM +0300, Tony Lindgren wrote:
 Here's the pull request for you.

I'll hold off merging this for a bit - I've sent Linus two pull requests
over the last couple of weeks, both of which so far haven't produced a
reaction. It would be unfair for me to merge more stuff onto that branch
until Linus has pulled.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git pull request for omap fixes for 2.6.31

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [090807 12:06]:
 On Fri, Aug 07, 2009 at 12:01:48PM +0300, Tony Lindgren wrote:
  Here's the pull request for you.
 
 I'll hold off merging this for a bit - I've sent Linus two pull requests
 over the last couple of weeks, both of which so far haven't produced a
 reaction. It would be unfair for me to merge more stuff onto that branch
 until Linus has pulled.

OK thanks.

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: MMC3 Overo

[Vladimir Pantelic]

Tony Lindgren wrote:

snip

 Here's an idea:

 1) Replace index with enum search in pin table - this breaks the
 requirement that the enum list and table align - a good thing as
 misalingment has bitten me multiple times when adding pins to the
 current mux table.  Also, pinmux setup is done infrequently, so the
 search doesn't add much overall execution time.


Yeh something like that sounds good. We should just move the omap1
specific code to live in mach-omap1 and keep it as it is for now.

You might also want to take a look at what the sh people have done:

$ find arch/sh -name \*mux*


 2) Break up mux table into two parts, the common mux list, and a
 custom mux list - the latter in the board file, and add a function to
 add the custom mux list to mux lists searched by omap_cfg_reg().

 3) Search the custom mux list first (if specified - allows replacing an
 entry in the common table if hardware required differences in
 termination, custom pins for GPIO, etc).

 For example, on the OMAP3530, balls H18-H21 can be associated with
 either UART3, or GPIOs 163-166. In the common mux list (where multiple
 boards use those pins for UART3, the common mux file can have the
 entries:

 H18_35XX_UART3_CTS
 H19_35XX_UART3_RTS
 H20_35XX_UART3_RX
 H21_35XX_UART_TX

 that sets up the mux for those pines as a UART.  If a board wants to use
 those pins instead for GPIO, then in the board file it can have a custom
 mux list with:

 H18_35XX_GPIO_163
 H19_35XX_GPIO_164
 H20_35XX_GPIO_165
 H21_35XX_GPIO_166

 and call into the mux code to add the custom mux list to be searched
 first.

 Thoughts?


Sounds pretty good to me!


but does not solve yet the package issue, where different omap3 packages have
different balls connected, no? It would be ok for board files, assuming that a
board has only one package, but what about the common code?

Or are the package differences only for a few pins, in this case they could be
banned from common and must live in board files..




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

[Grazvydas Ignotas]

On Fri, Aug 7, 2009 at 9:03 AM, Kalle Valokalle.v...@iki.fi wrote:
 Pandita, Vikram vikram.pand...@ti.com writes:

Omap tags are deprecrated and convert all OMAP_TAG_UART cases to use
omap_uart_platform_data instead.

Tested on rx51 and n8x0. Compile tested on omap_osk_5912.

Signed-off-by: Kalle Valo kalle.v...@iki.fi

 Any plans to remove OMAP_TAG_LCD

 I don't have any plans, but I don't know about others.

Already started by Tomi:
http://marc.info/?l=linux-omapm=124948326314839w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MMC3 Overo

[Tony Lindgren]

* Vladimir Pantelic p...@nt.tu-darmstadt.de [090807 12:24]:
 Tony Lindgren wrote:

 snip
  Here's an idea:

  1) Replace index with enum search in pin table - this breaks the
  requirement that the enum list and table align - a good thing as
  misalingment has bitten me multiple times when adding pins to the
  current mux table.  Also, pinmux setup is done infrequently, so the
  search doesn't add much overall execution time.

 Yeh something like that sounds good. We should just move the omap1
 specific code to live in mach-omap1 and keep it as it is for now.

 You might also want to take a look at what the sh people have done:

 $ find arch/sh -name \*mux*

  2) Break up mux table into two parts, the common mux list, and a
  custom mux list - the latter in the board file, and add a function to
  add the custom mux list to mux lists searched by omap_cfg_reg().

  3) Search the custom mux list first (if specified - allows replacing an
  entry in the common table if hardware required differences in
  termination, custom pins for GPIO, etc).

  For example, on the OMAP3530, balls H18-H21 can be associated with
  either UART3, or GPIOs 163-166. In the common mux list (where multiple
  boards use those pins for UART3, the common mux file can have the
  entries:

  H18_35XX_UART3_CTS
  H19_35XX_UART3_RTS
  H20_35XX_UART3_RX
  H21_35XX_UART_TX

  that sets up the mux for those pines as a UART.  If a board wants to use
  those pins instead for GPIO, then in the board file it can have a custom
  mux list with:

  H18_35XX_GPIO_163
  H19_35XX_GPIO_164
  H20_35XX_GPIO_165
  H21_35XX_GPIO_166

  and call into the mux code to add the custom mux list to be searched
  first.

  Thoughts?

 Sounds pretty good to me!

 but does not solve yet the package issue, where different omap3 packages 
 have
 different balls connected, no? It would be ok for board files, assuming that a
 board has only one package, but what about the common code?

 Or are the package differences only for a few pins, in this case they could be
 banned from common and must live in board files..

Well we need to mux all the pins that can potentially conflict only in the
board-*.c files.

For naming, I think we should use the default mode0 name in the mux register as 
the
key, and then link package specific pin names to that key. The pin names are
very handy to see for debugging at least.

Another thing to consider is if we want to support dynamic muxing. That means
we need to keep the mux tables in the memory.

Or do init time muxing in board-*.c files, then re-register the pins needed for
dynamic muxing in board-*.c files. That way most of the mux data can be 
__initdata,
and only the pins that have been registered for dynamic muxing need to be kept
in the memory.

Regard,

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: Pull request: SDRC clock-related OMAP fixes for 2.6.31

[Paul Walmsley]

Hi Russell,

On Tue, 4 Aug 2009, Paul Walmsley wrote:

 The following changes since commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465:
   Linus Torvalds (1):
 Linux 2.6.31-rc4
 
 are available in the git repository at:
 
   git://git.pwsan.com/linux-2.6 omap_fixes_31

Just checking to see if you are planning to pull these?


- 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] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Kalle Jokiniemi]

On Fri, 2009-08-07 at 11:48 +0300, Roger Quadros wrote:
 ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote:
  ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:
  Roger Quadros ext-roger.quad...@nokia.com writes:
 
  As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
  for automatic self-refresh before transition to OFF mode.
  In the current implementation this is done in 
  omap3_scratchpad_contents()
  which is wrong, since this is the value that will be restored while
  resuming from OFF mode and not while transitioning to it.
 
  This patch implements the workaround in the correct way as per errata.
 
  Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
  This looks right to me.
 
  Rajendra, Kalle, any comments? since you were the originators of
  the original patch.
 
  Kevin
 
  ---
   arch/arm/mach-omap2/control.c |   16 ++--
   arch/arm/mach-omap2/pm34xx.c  |   20 ++--
   2 files changed, 16 insertions(+), 20 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/control.c 
  b/arch/arm/mach-omap2/control.c
  index a7159a9..0a563c8 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
  (sdrc_read_reg(SDRC_ERR_TYPE)  0x);
  sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
  sdrc_block_contents.dll_b_ctrl = 0x0;
  -   /*
  -* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  -* be programed to issue automatic self refresh on timeout
  -* of AUTO_CNT = 1 prior to any transition to OFF mode.
  -*/
  -   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
  -(omap_rev() = OMAP3430_REV_ES3_0))
  -   sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
  -   ~(SDRC_POWER_AUTOCOUNT_MASK|
  -   SDRC_POWER_CLKCTRL_MASK)) |
  -   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  -   SDRC_SELF_REFRESH_ON_AUTOCOUNT;
  -   else
  -   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  +
  +   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  Why do you want to remove the workaround from scratchpad?
 
  When we wake up from off mode, the boot ROM code writes these settings
  as the first sdrc_power settings after wakeup. If that setting does not
  include the workaround, we'll have a period of time where sdram is not
  being refreshed. This hits especially HS devices that do long secure
  context restore in ROM code as well.
 
 
  I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However 
  when we 
  enter OFF mode it should be _self_ refreshed. That is done by the below 
  code 
  before we switch to OFF mode.
  
  The erratum speaks of auto-refresh failing after waking up from CORE off
  mode. I think there is the described workaround in place in sleep34xx.S
  code to kick up the auto refresh, but this still leaves a short gap
  between boot ROM and the sleep code.
  
  Unless the self-refresh mode does not get changed by the scratchpad
  settings?
  
  - Kalle
 
 There are 2 parts in the errata 1.142.
 
 The 1st part is what you are talking about. And it needs to be applied only 
 on 
 ES3.0 devices.
 
 The 2nd part is valid only for HS devices.
 ..it is mandatory on HS device to have the SDRC issuing automatic 
 self-refresh
 entries on inactivity periods..
 
 My patch is only fixing the implementation of the 2nd part without changing 
 the 
 work around for the 1st part. no?

The fix for second part is ok. But I have understood that the scratchpad
change was an additional safeguard against the 1st part. Rajendra, any
comments? 

I don't know how fast SDRAM corrupts when not refreshed, but on low OPP
it takes several msecs to reach public code from boot ROM. So keeping
SDRAM in self-refresh also in this period, seems sensible to me (even
though the erratum does not mention a requirement for this).

- Kalle

 
 -roger
 
  
  When we wake up from OFF mode (the scratchpad contents are used), we 
  should 
  restore the original register setting that was there before we went to OFF 
  mode 
  and not the self refresh mode setting. Hence the removal of above code.
 
  -roger
   
  sdrc_block_contents.cs_0 = 0x0;
  sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
  diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
  index 14f10bc..eb3c9e5 100644
  --- a/arch/arm/mach-omap2/pm34xx.c
  +++ b/arch/arm/mach-omap2/pm34xx.c
  @@ -405,15 +405,23 @@ void omap_sram_idle(void)
  }
   
  /*
  -   * On EMU/HS devices ROM code restores a SRDC value
  -   * from scratchpad which has automatic self refresh on timeout
  -   * of AUTO_CNT = 1 enabled. This takes 

Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Roger Quadros]

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 11:48 +0300, Roger Quadros wrote:

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote:

ext Kalle Jokiniemi wrote:

On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:

Roger Quadros ext-roger.quad...@nokia.com writes:


As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed
for automatic self-refresh before transition to OFF mode.
In the current implementation this is done in omap3_scratchpad_contents()
which is wrong, since this is the value that will be restored while
resuming from OFF mode and not while transitioning to it.

This patch implements the workaround in the correct way as per errata.

Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com

This looks right to me.

Rajendra, Kalle, any comments? since you were the originators of
the original patch.

Kevin


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

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index a7159a9..0a563c8 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE)  0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
-   /*
-* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
-* be programed to issue automatic self refresh on timeout
-* of AUTO_CNT = 1 prior to any transition to OFF mode.
-*/
-   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
-(omap_rev() = OMAP3430_REV_ES3_0))
-   sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
-   ~(SDRC_POWER_AUTOCOUNT_MASK|
-   SDRC_POWER_CLKCTRL_MASK)) |
-   (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
-   SDRC_SELF_REFRESH_ON_AUTOCOUNT;
-   else
-   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
+
+   sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);

Why do you want to remove the workaround from scratchpad?

When we wake up from off mode, the boot ROM code writes these settings
as the first sdrc_power settings after wakeup. If that setting does not
include the workaround, we'll have a period of time where sdram is not
being refreshed. This hits especially HS devices that do long secure
context restore in ROM code as well.


I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However when we 
enter OFF mode it should be _self_ refreshed. That is done by the below code 
before we switch to OFF mode.

The erratum speaks of auto-refresh failing after waking up from CORE off
mode. I think there is the described workaround in place in sleep34xx.S
code to kick up the auto refresh, but this still leaves a short gap
between boot ROM and the sleep code.

Unless the self-refresh mode does not get changed by the scratchpad
settings?

- Kalle

There are 2 parts in the errata 1.142.

The 1st part is what you are talking about. And it needs to be applied only on 
ES3.0 devices.


The 2nd part is valid only for HS devices.
..it is mandatory on HS device to have the SDRC issuing automatic self-refresh
entries on inactivity periods..

My patch is only fixing the implementation of the 2nd part without changing the 
work around for the 1st part. no?


The fix for second part is ok. But I have understood that the scratchpad
change was an additional safeguard against the 1st part. Rajendra, any
comments? 


I don't know how fast SDRAM corrupts when not refreshed, but on low OPP
it takes several msecs to reach public code from boot ROM. So keeping
SDRAM in self-refresh also in this period, seems sensible to me (even
though the erratum does not mention a requirement for this).

- Kalle


If what you are saying is right then this should be done for all OMAPs and not 
only non GP right?


-roger




-roger

When we wake up from OFF mode (the scratchpad contents are used), we should 
restore the original register setting that was there before we went to OFF mode 
and not the self refresh mode setting. Hence the removal of above code.


-roger
 
 	sdrc_block_contents.cs_0 = 0x0;

sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 14f10bc..eb3c9e5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -405,15 +405,23 @@ void omap_sram_idle(void)
}
 
 	/*

-   * On EMU/HS devices ROM code restores a SRDC value
-   * from scratchpad which has automatic self refresh on timeout
-   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
-   * Hence store/restore the SDRC_POWER 

Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)

[Kalle Jokiniemi]

On Fri, 2009-08-07 at 13:54 +0300, Roger Quadros wrote:
 ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 11:48 +0300, Roger Quadros wrote:
  ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote:
  ext Kalle Jokiniemi wrote:
  On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote:
  Roger Quadros ext-roger.quad...@nokia.com writes:
 
  As per errata 1.142, on EMU/HS devices, SDRC_POWER should be 
  programmed
  for automatic self-refresh before transition to OFF mode.
  In the current implementation this is done in 
  omap3_scratchpad_contents()
  which is wrong, since this is the value that will be restored while
  resuming from OFF mode and not while transitioning to it.
 
  This patch implements the workaround in the correct way as per errata.
 
  Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
  This looks right to me.
 
  Rajendra, Kalle, any comments? since you were the originators of
  the original patch.
 
  Kevin
 
  ---
   arch/arm/mach-omap2/control.c |   16 ++--
   arch/arm/mach-omap2/pm34xx.c  |   20 ++--
   2 files changed, 16 insertions(+), 20 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/control.c 
  b/arch/arm/mach-omap2/control.c
  index a7159a9..0a563c8 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE)  0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
  - /*
  -  * Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
  -  * be programed to issue automatic self refresh on timeout
  -  * of AUTO_CNT = 1 prior to any transition to OFF mode.
  -  */
  - if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
  -  (omap_rev() = OMAP3430_REV_ES3_0))
  - sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) 
  - ~(SDRC_POWER_AUTOCOUNT_MASK|
  - SDRC_POWER_CLKCTRL_MASK)) |
  - (1  SDRC_POWER_AUTOCOUNT_SHIFT) |
  - SDRC_SELF_REFRESH_ON_AUTOCOUNT;
  - else
  - sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  +
  + sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
  Why do you want to remove the workaround from scratchpad?
 
  When we wake up from off mode, the boot ROM code writes these settings
  as the first sdrc_power settings after wakeup. If that setting does not
  include the workaround, we'll have a period of time where sdram is not
  being refreshed. This hits especially HS devices that do long secure
  context restore in ROM code as well.
 
 
  I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However 
  when we 
  enter OFF mode it should be _self_ refreshed. That is done by the below 
  code 
  before we switch to OFF mode.
  The erratum speaks of auto-refresh failing after waking up from CORE off
  mode. I think there is the described workaround in place in sleep34xx.S
  code to kick up the auto refresh, but this still leaves a short gap
  between boot ROM and the sleep code.
 
  Unless the self-refresh mode does not get changed by the scratchpad
  settings?
 
  - Kalle
  There are 2 parts in the errata 1.142.
 
  The 1st part is what you are talking about. And it needs to be applied 
  only on 
  ES3.0 devices.
 
  The 2nd part is valid only for HS devices.
  ..it is mandatory on HS device to have the SDRC issuing automatic 
  self-refresh
  entries on inactivity periods..
 
  My patch is only fixing the implementation of the 2nd part without 
  changing the 
  work around for the 1st part. no?
  
  The fix for second part is ok. But I have understood that the scratchpad
  change was an additional safeguard against the 1st part. Rajendra, any
  comments? 
  
  I don't know how fast SDRAM corrupts when not refreshed, but on low OPP
  it takes several msecs to reach public code from boot ROM. So keeping
  SDRAM in self-refresh also in this period, seems sensible to me (even
  though the erratum does not mention a requirement for this).
  
  - Kalle
 
 If what you are saying is right then this should be done for all OMAPs and 
 not 
 only non GP right?

GP devices skip secure context restore, which decreases the wakeup time
considerably. But I assume the gap to exist nevertheless, however
smaller it may be.

The question that I don't know the answer to in this scratchpad part, is
that:

If we use the normal sdrc_power setting in scratchpad, will it stop the
self-refresh mode when boot ROM writes the normal scratchpad setting
into sdrc_power register?

If it does not, then we can remove the workaround from scratchpad
settings.

Rajendra, any comments.

- Kalle

 
 -roger
 
  
  -roger
 
  When we wake up from OFF mode (the scratchpad contents are used), we 
  should 
  restore the 

Re: [PATCH 00/15] OMAP: DSS intro

[Tomi Valkeinen]

Quadros Roger (EXT-Teleca/Helsinki) wrote:

ext Tomi Valkeinen wrote:

This patch set implement new display subsystem driver (DSS2) and omapfb driver
for OMAP2/3. The patches can also be found from
http://gitorious.org/linux-omap-dss2/linux

The patches include DSS documentation patch that includes more instructions for
module parameters, sysfs files etc.

The patches enable DSS2 for SDP, Beagle and Overo boards.

I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2
and the possible fixes needed should be minimal.

OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards.

DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also
contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling
and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav
Hiremath, and perhaps some others that I have forgotten =).

---

[PATCH 01/15] OMAP: OMAPFB: split omapfb.h
[PATCH 02/15] OMAP: OMAPFB: add omapdss device
[PATCH 03/15] OMAP: Add VRAM manager
[PATCH 04/15] OMAP: Add support for VRFB rotation engine
[PATCH 05/15] OMAP: DSS2: Documentation for DSS2
[PATCH 06/15] OMAP: DSS2: Display Subsystem Driver core
[PATCH 07/15] OMAP: DSS2: VENC driver
[PATCH 08/15] OMAP: DSS2: RFBI driver
[PATCH 09/15] OMAP: DSS2: SDI driver
[PATCH 10/15] OMAP: DSS2: DSI driver
[PATCH 11/15] OMAP: DSS2: omapfb driver
[PATCH 12/15] OMAP: DSS2: Add panel drivers
[PATCH 13/15] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
[PATCH 14/15] OMAP: Beagle: Enable DSS2 for Beagle board
[PATCH 15/15] OMAP: Overo: Enable DSS2 for Overo



Tomi,

I didn't receive PATCH 06 from the series.


It was too big. It seems to have gone through to linux-fbdev-devel:

http://marc.info/?l=linux-fbdev-develr=1b=200908w=2

I have split it up more for next posting.

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

Re: [PATCH 00/15] OMAP: DSS intro

[Roger Quadros]

Tomi,

I didn't receive PATCH 06 from the series.


It was too big. It seems to have gone through to linux-fbdev-devel:

http://marc.info/?l=linux-fbdev-develr=1b=200908w=2

I have split it up more for next posting.

 Tomi


Thanks :), i'll pick it up from there.

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

Re: [PATCH 1/2] OMAP2: Add funcs for writing SMS_ROT_* registers

[Tony Lindgren]

Hi,

* Tomi Valkeinen tomi.valkei...@nokia.com [090807 11:36]:
 Hmm sorry, this was meant to be [PATCH 1/1].

  Tomi


 Valkeinen Tomi (Nokia-D/Helsinki) wrote:
 SMS_ROT_* registers are used by VRFB rotation engine.

Assuming Paul acks it too, I suggest you merge this via the fbdev queue
to avoid dependencies of having to wait for all the arm patches to get
merged.

Acked-by: Tony Lindgren t...@atomide.com



 Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
 ---
  arch/arm/mach-omap2/sdrc.c |   16 
  arch/arm/plat-omap/include/mach/sdrc.h |8 +++-
  2 files changed, 23 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
 index 2045441..56f6dab 100644
 --- a/arch/arm/mach-omap2/sdrc.c
 +++ b/arch/arm/mach-omap2/sdrc.c
 @@ -111,3 +111,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
  (1  SDRC_POWER_PAGEPOLICY_SHIFT);
  sdrc_write_reg(l, SDRC_POWER);
  }
 +
 +void omap2_sms_write_rot_control(u32 val, unsigned ctx)
 +{
 +sms_write_reg(val, SMS_ROT_CONTROL(ctx));
 +}
 +
 +void omap2_sms_write_rot_size(u32 val, unsigned ctx)
 +{
 +sms_write_reg(val, SMS_ROT_SIZE(ctx));
 +}
 +
 +void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
 +{
 +sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
 +}
 +
 diff --git a/arch/arm/plat-omap/include/mach/sdrc.h 
 b/arch/arm/plat-omap/include/mach/sdrc.h
 index adc7352..4199c19 100644
 --- a/arch/arm/plat-omap/include/mach/sdrc.h
 +++ b/arch/arm/plat-omap/include/mach/sdrc.h
 @@ -75,7 +75,10 @@
   /* SMS register offsets - read/write with sms_{read,write}_reg() */
  -#define SMS_SYSCONFIG  0x010
 +#define SMS_SYSCONFIG   0x010
 +#define SMS_ROT_CONTROL(context)(0x180 + 0x10 * context)
 +#define SMS_ROT_SIZE(context)   (0x184 + 0x10 * context)
 +#define SMS_ROT_PHYSICAL_BA(context)(0x188 + 0x10 * context)
  /* REVISIT: fill in other SMS registers here */
   @@ -104,6 +107,9 @@ struct omap_sdrc_params {
   void __init omap2_sdrc_init(struct omap_sdrc_params *sp);
  struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
 +void omap2_sms_write_rot_control(u32 val, unsigned ctx);
 +void omap2_sms_write_rot_size(u32 val, unsigned ctx);
 +void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
   #ifdef CONFIG_ARCH_OMAP2
  

 --
 To unsubscribe from this list: send the line unsubscribe 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 00/15] OMAP: DSS intro

[Roger Quadros]

ext Tomi Valkeinen wrote:

This patch set implement new display subsystem driver (DSS2) and omapfb driver
for OMAP2/3. The patches can also be found from
http://gitorious.org/linux-omap-dss2/linux

The patches include DSS documentation patch that includes more instructions for
module parameters, sysfs files etc.

The patches enable DSS2 for SDP, Beagle and Overo boards.

I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2
and the possible fixes needed should be minimal.

OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards.

DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also
contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling
and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav
Hiremath, and perhaps some others that I have forgotten =).

---

[PATCH 01/15] OMAP: OMAPFB: split omapfb.h
[PATCH 02/15] OMAP: OMAPFB: add omapdss device
[PATCH 03/15] OMAP: Add VRAM manager
[PATCH 04/15] OMAP: Add support for VRFB rotation engine
[PATCH 05/15] OMAP: DSS2: Documentation for DSS2
[PATCH 06/15] OMAP: DSS2: Display Subsystem Driver core
[PATCH 07/15] OMAP: DSS2: VENC driver
[PATCH 08/15] OMAP: DSS2: RFBI driver
[PATCH 09/15] OMAP: DSS2: SDI driver
[PATCH 10/15] OMAP: DSS2: DSI driver
[PATCH 11/15] OMAP: DSS2: omapfb driver
[PATCH 12/15] OMAP: DSS2: Add panel drivers
[PATCH 13/15] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
[PATCH 14/15] OMAP: Beagle: Enable DSS2 for Beagle board
[PATCH 15/15] OMAP: Overo: Enable DSS2 for Overo



Tomi,

I didn't receive PATCH 06 from the series.

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

Re: [PATCH 1/2] OMAP2: Add funcs for writing SMS_ROT_* registers

[Paul Walmsley]

On Fri, 7 Aug 2009, Tony Lindgren wrote:

 * Tomi Valkeinen tomi.valkei...@nokia.com [090807 11:36]:
  Hmm sorry, this was meant to be [PATCH 1/1].
 
   Tomi
 
 
  Valkeinen Tomi (Nokia-D/Helsinki) wrote:
  SMS_ROT_* registers are used by VRFB rotation engine.
 
 Assuming Paul acks it too, I suggest you merge this via the fbdev queue
 to avoid dependencies of having to wait for all the arm patches to get
 merged.
 
 Acked-by: Tony Lindgren t...@atomide.com

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

 
 
 
  Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
  ---
   arch/arm/mach-omap2/sdrc.c |   16 
   arch/arm/plat-omap/include/mach/sdrc.h |8 +++-
   2 files changed, 23 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
  index 2045441..56f6dab 100644
  --- a/arch/arm/mach-omap2/sdrc.c
  +++ b/arch/arm/mach-omap2/sdrc.c
  @@ -111,3 +111,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params 
  *sp)
 (1  SDRC_POWER_PAGEPOLICY_SHIFT);
 sdrc_write_reg(l, SDRC_POWER);
   }
  +
  +void omap2_sms_write_rot_control(u32 val, unsigned ctx)
  +{
  +  sms_write_reg(val, SMS_ROT_CONTROL(ctx));
  +}
  +
  +void omap2_sms_write_rot_size(u32 val, unsigned ctx)
  +{
  +  sms_write_reg(val, SMS_ROT_SIZE(ctx));
  +}
  +
  +void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
  +{
  +  sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
  +}
  +
  diff --git a/arch/arm/plat-omap/include/mach/sdrc.h 
  b/arch/arm/plat-omap/include/mach/sdrc.h
  index adc7352..4199c19 100644
  --- a/arch/arm/plat-omap/include/mach/sdrc.h
  +++ b/arch/arm/plat-omap/include/mach/sdrc.h
  @@ -75,7 +75,10 @@
/* SMS register offsets - read/write with sms_{read,write}_reg() */
   -#define SMS_SYSCONFIG0x010
  +#define SMS_SYSCONFIG 0x010
  +#define SMS_ROT_CONTROL(context)  (0x180 + 0x10 * context)
  +#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
  +#define SMS_ROT_PHYSICAL_BA(context)  (0x188 + 0x10 * context)
   /* REVISIT: fill in other SMS registers here */
@@ -104,6 +107,9 @@ struct omap_sdrc_params {
void __init omap2_sdrc_init(struct omap_sdrc_params *sp);
   struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
  +void omap2_sms_write_rot_control(u32 val, unsigned ctx);
  +void omap2_sms_write_rot_size(u32 val, unsigned ctx);
  +void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
#ifdef CONFIG_ARCH_OMAP2
   
 
  --
  To unsubscribe from this list: send the line unsubscribe 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
 


- 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: [PATCH 11/15] OMAP: DSS2: omapfb driver

[Roger Quadros]

diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 244b80d..89bf210 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig


This file does not exist in linus' tree or linux-omap so it fails to apply as it 
does not have 'new file node' attribute



@@ -1,2 +1,3 @@
 source drivers/video/omap2/dss/Kconfig
 source drivers/video/omap2/displays/Kconfig
+source drivers/video/omap2/omapfb/Kconfig
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 2d2c83e..0c0414f 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile


ditto


@@ -1,2 +1,3 @@
 obj-y += dss/
 obj-y += displays/
+obj-y += omapfb/


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

[Paul Walmsley]

On Wed, 5 Aug 2009, Roger Quadros wrote:

 SDRC addresses are offset from OMAP3430_SDRC_RT_BASE and not
 OMAP3430_SMS_RT_BASE.
 This fixes OFF mode on EMU/HS devices.
 
 Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com

Signed-off-by: Paul Walmsley p...@pwsan.com

 ---
  arch/arm/mach-omap2/sleep34xx.S |   14 +++---
  1 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
 index 807b23e..53b6da9 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -49,13 +49,13 @@
  #define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\
   + SCRATCHPAD_MEM_OFFS)
  #define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER)
 -#define SDRC_SYSCONFIG_P (OMAP3430_SMS_RT_BASE + SDRC_SYSCONFIG)
 -#define SDRC_MR_0_P  (OMAP3430_SMS_RT_BASE + SDRC_MR_0)
 -#define SDRC_EMR2_0_P(OMAP3430_SMS_RT_BASE + SDRC_EMR2_0)
 -#define SDRC_MANUAL_0_P  (OMAP3430_SMS_RT_BASE + SDRC_MANUAL_0)
 -#define SDRC_MR_1_P  (OMAP3430_SMS_RT_BASE + SDRC_MR_1)
 -#define SDRC_EMR2_1_P(OMAP3430_SMS_RT_BASE + SDRC_EMR2_1)
 -#define SDRC_MANUAL_1_P  (OMAP3430_SMS_RT_BASE + SDRC_MANUAL_1)
 +#define SDRC_SYSCONFIG_P (OMAP3430_SDRC_RT_BASE + SDRC_SYSCONFIG)
 +#define SDRC_MR_0_P  (OMAP3430_SDRC_RT_BASE + SDRC_MR_0)
 +#define SDRC_EMR2_0_P(OMAP3430_SDRC_RT_BASE + SDRC_EMR2_0)
 +#define SDRC_MANUAL_0_P  (OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_0)
 +#define SDRC_MR_1_P  (OMAP3430_SDRC_RT_BASE + SDRC_MR_1)
 +#define SDRC_EMR2_1_P(OMAP3430_SDRC_RT_BASE + SDRC_EMR2_1)
 +#define SDRC_MANUAL_1_P  (OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_1)
  #define SDRC_DLLA_STATUS_V   OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
  #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
  
 -- 
 1.6.0.4
 


- 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: [PATCH 12/15] OMAP: DSS2: Add panel drivers

[Roger Quadros]

ext Tomi Valkeinen wrote:

- Generic panel
- Samsung LTE430WQ-F0C LCD Panel
- Sharp LS037V7DW01 LCD Panel

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/displays/Kconfig   |   18 +++
 drivers/video/omap2/displays/Makefile  |3 +
 drivers/video/omap2/displays/panel-generic.c   |  104 +
 .../omap2/displays/panel-samsung-lte430wq-f0c.c|  113 +++
 .../video/omap2/displays/panel-sharp-ls037v7dw01.c |  153 
 5 files changed, 391 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-generic.c
 create mode 100644 drivers/video/omap2/displays/panel-samsung-lte430wq-f0c.c
 create mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c


This does not apply on linux-omap tree.

I get,

Applying: OMAP: DSS2: Add panel drivers
error: drivers/video/omap2/displays/Kconfig: does not exist in index
error: drivers/video/omap2/displays/Makefile: does not exist in index
Patch failed at 0011.

probably missing the 'new file node' attribute here too.

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

Re: [PATCH 11/15] OMAP: DSS2: omapfb driver

[Tomi Valkeinen]

Hi,

Quadros Roger (EXT-Teleca/Helsinki) wrote:

diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 244b80d..89bf210 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig


This file does not exist in linus' tree or linux-omap so it fails to apply as it 
does not have 'new file node' attribute



@@ -1,2 +1,3 @@
 source drivers/video/omap2/dss/Kconfig
 source drivers/video/omap2/displays/Kconfig
+source drivers/video/omap2/omapfb/Kconfig
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 2d2c83e..0c0414f 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile


ditto


@@ -1,2 +1,3 @@
 obj-y += dss/
 obj-y += displays/
+obj-y += omapfb/




You need to apply the patches in order. Those files, and the files 
needed by panel drivers patch, are created in


[PATCH 06/15] OMAP: DSS2: Display Subsystem

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

Re: [PATCH 11/15] OMAP: DSS2: omapfb driver

[Roger Quadros]

Tomi Valkeinen wrote:

Hi,

Quadros Roger (EXT-Teleca/Helsinki) wrote:

diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 244b80d..89bf210 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig


This file does not exist in linus' tree or linux-omap so it fails to 
apply as it does not have 'new file node' attribute



@@ -1,2 +1,3 @@
 source drivers/video/omap2/dss/Kconfig
 source drivers/video/omap2/displays/Kconfig
+source drivers/video/omap2/omapfb/Kconfig
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 2d2c83e..0c0414f 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile


ditto


@@ -1,2 +1,3 @@
 obj-y += dss/
 obj-y += displays/
+obj-y += omapfb/




You need to apply the patches in order. Those files, and the files 
needed by panel drivers patch, are created in


[PATCH 06/15] OMAP: DSS2: Display Subsystem

 Tomi


oh ya. i downloaded it but forgot to apply. Thanks :)
--
To unsubscribe from this list: send the line unsubscribe 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] Clear the SDRC_POWER.PWRENA bit before putting the SDRAM into self-refresh before suspend

[Paul Walmsley]

Hello Janboe,

On Tue, 7 Jul 2009, ye janboe wrote:

 I saw you clear clear the SDRC PWRENA bit during SDRC frequency change
 but not during suspend.
 
 Please review if it is necessary to clear PWRENA bit during suspend.

I hope we don't need this after:

http://patchwork.kernel.org/patch/37284/

Of course, the bootloader might still set it :-(

- Paul

 
 Thanks
 
 Janboe Ye
 
 rom 287db2e188391be0ac95128131724e0e035e945a Mon Sep 17 00:00:00 2001
 From: janboe janboe...@gmail.com
 Date: Tue, 7 Jul 2009 16:30:26 -0500
 Subject: [PATCH] Clear the SDRC_POWER.PWRENA bit before putting the
 SDRAM into self-refresh and then suspend
 
 Signed-off-by: janboe janboe...@gmail.com
 ---
  arch/arm/mach-omap2/sleep34xx.S |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
 index e5e2553..2bc0c3b 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -70,6 +70,7 @@ loop:
 ldr r4, sdrc_power  @ read the SDRC_POWER register
 ldr r5, [r4]@ read the contents of SDRC_POWER
 orr r5, r5, #0x40   @ enable self refresh on idle req
 +   bic r5, r5, #0x4@ clear PWDENA
 str r5, [r4]@ write back to SDRC_POWER register
 
 cmp r1, #0x0
 -- 
 1.6.3.1
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


- 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

[PATCHv2 00/20] OMAP: DSS intro v2

[Tomi Valkeinen]

This patch set implement new display subsystem driver (DSS2) and omapfb driver
for OMAP2/3. The patches can also be found from
http://gitorious.org/linux-omap-dss2/linux

The patches include DSS documentation patch that includes more instructions for
module parameters, sysfs files etc.

The patches enable DSS2 for SDP, Beagle and Overo boards.

I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2
and the possible fixes needed should be minimal.

OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards.

DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also
contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling
and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav
Hiremath, and perhaps some others that I have forgotten =).

---

Changes to the previous posted version:

- Split the commits more to make them smaller
- Print error if fclk is too low for scaling
- Indent SDP, Beagle, Overo board files
- DSI: return -EIO instead of -1
- VRFB: Move to drivers/video/omap2/
- VRAM: Move to drivers/video/omap2/
- VRFB: use omap2_sms_write_*() functions instead of omap_writel
- SDI: Remove custom pinmuxing. Will be added later properly.
- VENC: indentation changes
- Add Taal DSI panel driver

---

[PATCH 01/20] OMAP2: Add funcs for writing SMS_ROT_* registers
[PATCH 02/20] OMAP: OMAPFB: split omapfb.h
[PATCH 03/20] OMAP: OMAPFB: add omapdss device
[PATCH 04/20] OMAP: Add VRAM manager
[PATCH 05/20] OMAP: Add support for VRFB rotation engine
[PATCH 06/20] OMAP: DSS2: Documentation for DSS2
[PATCH 07/20] OMAP: DSS2: Display Subsystem Driver core
[PATCH 08/20] OMAP: DSS2: Add more core files
[PATCH 09/20] OMAP: DSS2: DISPC
[PATCH 10/20] OMAP: DSS2: DPI driver
[PATCH 11/20] OMAP: DSS2: Video encoder driver
[PATCH 12/20] OMAP: DSS2: RFBI driver
[PATCH 13/20] OMAP: DSS2: SDI driver
[PATCH 14/20] OMAP: DSS2: DSI driver
[PATCH 15/20] OMAP: DSS2: omapfb driver
[PATCH 16/20] OMAP: DSS2: Add DPI panel drivers
[PATCH 17/20] OMAP: DSS2: Taal DSI command mode panel driver
[PATCH 18/20] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
[PATCH 19/20] OMAP: Beagle: Enable DSS2 for Beagle board
[PATCH 20/20] OMAP: Overo: Enable DSS2 for Overo

---

 Documentation/arm/OMAP/DSS |  317 ++
 arch/arm/configs/omap3_beagle_defconfig|   26 +-
 arch/arm/configs/omap_3430sdp_defconfig|   31 +-
 arch/arm/configs/overo_defconfig   |  265 +--
 arch/arm/mach-omap1/board-nokia770.c   |2 +-
 arch/arm/mach-omap2/board-3430sdp.c|  171 +-
 arch/arm/mach-omap2/board-n800.c   |2 +-
 arch/arm/mach-omap2/board-omap3beagle.c|  119 +-
 arch/arm/mach-omap2/board-overo.c  |  149 +-
 arch/arm/mach-omap2/clock24xx.c|8 +-
 arch/arm/mach-omap2/clock34xx.c|   10 +-
 arch/arm/mach-omap2/io.c   |4 +-
 arch/arm/mach-omap2/sdrc.c |   16 +
 arch/arm/plat-omap/fb.c|   41 +-
 arch/arm/plat-omap/include/mach/display.h  |  540 +++
 arch/arm/plat-omap/include/mach/omapfb.h   |  398 ---
 arch/arm/plat-omap/include/mach/sdrc.h |8 +-
 arch/arm/plat-omap/include/mach/vram.h |   63 +
 arch/arm/plat-omap/include/mach/vrfb.h |   46 +
 arch/arm/plat-omap/sram.c  |8 +
 drivers/video/Kconfig  |1 +
 drivers/video/Makefile |1 +
 drivers/video/omap/Kconfig |5 +-
 drivers/video/omap/blizzard.c  |2 +-
 drivers/video/omap/dispc.c |   21 +-
 drivers/video/omap/hwa742.c|2 +-
 drivers/video/omap/lcd_2430sdp.c   |2 +-
 drivers/video/omap/lcd_ams_delta.c |2 +-
 drivers/video/omap/lcd_apollon.c   |2 +-
 drivers/video/omap/lcd_h3.c|2 +-
 drivers/video/omap/lcd_h4.c|2 +-
 drivers/video/omap/lcd_inn1510.c   |2 +-
 drivers/video/omap/lcd_inn1610.c   |2 +-
 drivers/video/omap/lcd_ldp.c   |2 +-
 drivers/video/omap/lcd_mipid.c |3 +-
 drivers/video/omap/lcd_omap2evm.c  |2 +-
 drivers/video/omap/lcd_omap3beagle.c   |2 +-
 drivers/video/omap/lcd_omap3evm.c  |2 +-
 drivers/video/omap/lcd_osk.c   |2 +-
 drivers/video/omap/lcd_overo.c |3 +-
 drivers/video/omap/lcd_palmte.c|2 +-
 drivers/video/omap/lcd_palmtt.c|2 +-
 drivers/video/omap/lcd_palmz71.c   |2 +-
 drivers/video/omap/lcdc.c  |3 +-
 

[PATCH 01/20] OMAP2: Add funcs for writing SMS_ROT_* registers

[Tomi Valkeinen]

SMS_ROT_* registers are used by VRFB rotation engine.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/sdrc.c |   16 
 arch/arm/plat-omap/include/mach/sdrc.h |8 +++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 2045441..56f6dab 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -111,3 +111,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
(1  SDRC_POWER_PAGEPOLICY_SHIFT);
sdrc_write_reg(l, SDRC_POWER);
 }
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_CONTROL(ctx));
+}
+
+void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_SIZE(ctx));
+}
+
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+   sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
+}
+
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h 
b/arch/arm/plat-omap/include/mach/sdrc.h
index adc7352..4199c19 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -75,7 +75,10 @@
 
 /* SMS register offsets - read/write with sms_{read,write}_reg() */
 
-#define SMS_SYSCONFIG  0x010
+#define SMS_SYSCONFIG  0x010
+#define SMS_ROT_CONTROL(context)   (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context)  (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context)   (0x188 + 0x10 * context)
 /* REVISIT: fill in other SMS registers here */
 
 
@@ -104,6 +107,9 @@ struct omap_sdrc_params {
 
 void __init omap2_sdrc_init(struct omap_sdrc_params *sp);
 struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
 
 #ifdef CONFIG_ARCH_OMAP2
 
-- 
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 02/20] OMAP: OMAPFB: split omapfb.h

[Tomi Valkeinen]

Split arch/arm/plat-omap/include/mach/omapfb.h into two files:

include/linux/omapfb.h - ioctls etc for userspace and some kernel
 stuff for board files
drivers/video/omap/omapfb.h - for omapfb internal use

This cleans up omapfb.h and also makes it easier for the upcoming new
DSS driver to co-exist with the old driver.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap1/board-nokia770.c |2 +-
 arch/arm/mach-omap2/board-n800.c |2 +-
 arch/arm/mach-omap2/io.c |2 +-
 arch/arm/plat-omap/fb.c  |2 +-
 arch/arm/plat-omap/include/mach/omapfb.h |  398 --
 drivers/video/omap/blizzard.c|2 +-
 drivers/video/omap/dispc.c   |2 +-
 drivers/video/omap/hwa742.c  |2 +-
 drivers/video/omap/lcd_2430sdp.c |2 +-
 drivers/video/omap/lcd_ams_delta.c   |2 +-
 drivers/video/omap/lcd_apollon.c |2 +-
 drivers/video/omap/lcd_h3.c  |2 +-
 drivers/video/omap/lcd_h4.c  |2 +-
 drivers/video/omap/lcd_inn1510.c |2 +-
 drivers/video/omap/lcd_inn1610.c |2 +-
 drivers/video/omap/lcd_ldp.c |2 +-
 drivers/video/omap/lcd_mipid.c   |3 +-
 drivers/video/omap/lcd_omap2evm.c|2 +-
 drivers/video/omap/lcd_omap3beagle.c |2 +-
 drivers/video/omap/lcd_omap3evm.c|2 +-
 drivers/video/omap/lcd_osk.c |2 +-
 drivers/video/omap/lcd_overo.c   |3 +-
 drivers/video/omap/lcd_palmte.c  |2 +-
 drivers/video/omap/lcd_palmtt.c  |2 +-
 drivers/video/omap/lcd_palmz71.c |2 +-
 drivers/video/omap/lcdc.c|3 +-
 drivers/video/omap/omapfb.h  |  227 +
 drivers/video/omap/omapfb_main.c |2 +-
 drivers/video/omap/rfbi.c|3 +-
 drivers/video/omap/sossi.c   |2 +-
 include/linux/omapfb.h   |  197 +++
 31 files changed, 455 insertions(+), 427 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h
 create mode 100644 drivers/video/omap/omapfb.h
 create mode 100644 include/linux/omapfb.h

diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index ed2a48a..6fbde33 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -14,6 +14,7 @@
 #include linux/platform_device.h
 #include linux/input.h
 #include linux/clk.h
+#include linux/omapfb.h
 
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
@@ -32,7 +33,6 @@
 #include mach/keypad.h
 #include mach/common.h
 #include mach/dsp_common.h
-#include mach/omapfb.h
 #include mach/hwa742.h
 #include mach/lcd_mipid.h
 #include mach/mmc.h
diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index 23296e9..e2907ac 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -22,6 +22,7 @@
 #include linux/interrupt.h
 #include linux/irq.h
 #include linux/i2c.h
+#include linux/omapfb.h
 #include mach/hardware.h
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -34,7 +35,6 @@
 #include mach/lcd_mipid.h
 #include mach/clock.h
 #include mach/menelaus.h
-#include mach/omapfb.h
 #include mach/blizzard.h
 #include mach/onenand.h
 #include mach/board-nokia.h
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3a86b0f..7a54e12 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -22,13 +22,13 @@
 #include linux/init.h
 #include linux/io.h
 #include linux/clk.h
+#include linux/omapfb.h
 
 #include asm/tlb.h
 
 #include asm/mach/map.h
 
 #include mach/mux.h
-#include mach/omapfb.h
 #include mach/sram.h
 #include mach/sdrc.h
 #include mach/gpmc.h
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 3746222..40615a6 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -28,13 +28,13 @@
 #include linux/platform_device.h
 #include linux/bootmem.h
 #include linux/io.h
+#include linux/omapfb.h
 
 #include mach/hardware.h
 #include asm/mach/map.h
 
 #include mach/board.h
 #include mach/sram.h
-#include mach/omapfb.h
 
 #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
 
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h 
b/arch/arm/plat-omap/include/mach/omapfb.h
deleted file mode 100644
index b226bdf..000
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ /dev/null
@@ -1,398 +0,0 @@
-/*
- * File: arch/arm/plat-omap/include/mach/omapfb.h
- *
- * Framebuffer driver for TI OMAP boards
- *
- * Copyright (C) 2004 Nokia Corporation
- * Author: Imre Deak imre.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of 

[PATCH 03/20] OMAP: OMAPFB: add omapdss device

[Tomi Valkeinen]

The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.

This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/clock24xx.c |8 
 arch/arm/mach-omap2/clock34xx.c |   10 +-
 drivers/video/omap/dispc.c  |   19 ---
 3 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..402a3d4 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL,   mdm_ick,  mdm_ick,   CK_243X),
CLK(NULL,   mdm_osc_ck,   mdm_osc_ck,CK_243X),
/* DSS domain clocks */
-   CLK(omapfb,   ick,  dss_ick,   CK_243X | CK_242X),
-   CLK(omapfb,   dss1_fck, dss1_fck,  CK_243X | CK_242X),
-   CLK(omapfb,   dss2_fck, dss2_fck,  CK_243X | CK_242X),
-   CLK(omapfb,   tv_fck,   dss_54m_fck,   CK_243X | CK_242X),
+   CLK(omapdss,  ick,  dss_ick,   CK_243X | CK_242X),
+   CLK(omapdss,  dss1_fck, dss1_fck,  CK_243X | CK_242X),
+   CLK(omapdss,  dss2_fck, dss2_fck,  CK_243X | CK_242X),
+   CLK(omapdss,  tv_fck,   dss_54m_fck,   CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL,   core_l3_ck,   core_l3_ck,CK_243X | CK_242X),
CLK(NULL,   ssi_fck,  ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..dd7bba2 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -200,11 +200,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick,  rng_ick,   CK_343X),
CLK(NULL,   sha11_ick,sha11_ick, CK_343X),
CLK(NULL,   des1_ick, des1_ick,  CK_343X),
-   CLK(omapfb,   dss1_fck, dss1_alwon_fck, CK_343X),
-   CLK(omapfb,   tv_fck,   dss_tv_fck,CK_343X),
-   CLK(omapfb,   video_fck,dss_96m_fck,   CK_343X),
-   CLK(omapfb,   dss2_fck, dss2_alwon_fck, CK_343X),
-   CLK(omapfb,   ick,  dss_ick,   CK_343X),
+   CLK(omapdss,  dss1_fck, dss1_alwon_fck, CK_343X),
+   CLK(omapdss,  tv_fck,   dss_tv_fck,CK_343X),
+   CLK(omapdss,  video_fck,dss_96m_fck,   CK_343X),
+   CLK(omapdss,  dss2_fck, dss2_alwon_fck, CK_343X),
+   CLK(omapdss,  ick,  dss_ick,   CK_343X),
CLK(NULL,   cam_mclk, cam_mclk,  CK_343X),
CLK(NULL,   cam_ick,  cam_ick,   CK_343X),
CLK(NULL,   csi2_96m_fck, csi2_96m_fck,  CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 06438d0..cde3d18 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
 #include linux/vmalloc.h
 #include linux/clk.h
 #include linux/io.h
+#include linux/platform_device.h
 
 #include mach/sram.h
 #include mach/board.h
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
 } dispc;
 
+static struct platform_device omapdss_device = {
+   .name   = omapdss,
+   .id = -1,
+};
+
 static void enable_lcd_clocks(int enable);
 
 static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void 
*dev)
 
 static int get_dss_clocks(void)
 {
-   dispc.dss_ick = clk_get(dispc.fbdev-dev, ick);
+   dispc.dss_ick = clk_get(omapdss_device.dev, ick);
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
 
-   dispc.dss1_fck = clk_get(dispc.fbdev-dev, dss1_fck);
+   dispc.dss1_fck = clk_get(omapdss_device.dev, dss1_fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
 
-   dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck);
+   dispc.dss_54m_fck = clk_get(omapdss_device.dev, tv_fck);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
@@ -1371,6 +1377,12 @@ static int omap_dispc_init(struct omapfb_device *fbdev, 
int ext_mode,
int skip_init = 0;
int i;
 
+   r = platform_device_register(omapdss_device);
+   if (r) {
+   dev_err(fbdev-dev, can't register omapdss device\n);
+   return r;
+   }
+
   

[PATCH 04/20] OMAP: Add VRAM manager

[Tomi Valkeinen]

Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:

- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations

The upcoming DSS2 uses VRAM manager.

VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/mach-omap2/io.c   |2 +
 arch/arm/plat-omap/include/mach/vram.h |   63 +++
 arch/arm/plat-omap/sram.c  |8 +
 drivers/video/Kconfig  |1 +
 drivers/video/Makefile |1 +
 drivers/video/omap2/Kconfig|2 +
 drivers/video/omap2/Makefile   |1 +
 drivers/video/omap2/vram.c |  655 
 8 files changed, 733 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/mach/vram.h
 create mode 100644 drivers/video/omap2/Kconfig
 create mode 100644 drivers/video/omap2/Makefile
 create mode 100644 drivers/video/omap2/vram.c

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7a54e12..e37f736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -32,6 +32,7 @@
 #include mach/sram.h
 #include mach/sdrc.h
 #include mach/gpmc.h
+#include mach/vram.h
 
 #ifndef CONFIG_ARCH_OMAP4  /* FIXME: Remove this once clkdev is ready */
 #include clock.h
@@ -240,6 +241,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+   omap_vram_reserve_sdram();
 }
 
 /*
diff --git a/arch/arm/plat-omap/include/mach/vram.h 
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..fe72f81
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include linux/autoconf.h
+#include linux/types.h
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX  1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+   unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+   unsigned long sram_vstart,
+   unsigned long sram_size,
+   unsigned long pstart_avail,
+   unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+   unsigned long sram_vstart,
+   unsigned long sram_size,
+   unsigned long pstart_avail,
+   unsigned long size_avail)
+{
+   return 0;
+}
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 4ea7380..944bf69 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -28,6 +28,7 @@
 #include mach/sram.h
 #include mach/board.h
 #include mach/cpu.h
+#include mach/vram.h
 
 #include mach/control.h
 
@@ 

[PATCH 05/20] OMAP: Add support for VRFB rotation engine

[Tomi Valkeinen]

VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.

Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/plat-omap/include/mach/vrfb.h |   46 ++
 drivers/video/omap2/Kconfig|3 +
 drivers/video/omap2/Makefile   |1 +
 drivers/video/omap2/vrfb.c |  277 
 4 files changed, 327 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
 create mode 100644 drivers/video/omap2/vrfb.c

diff --git a/arch/arm/plat-omap/include/mach/vrfb.h 
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644
index 000..8790612
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vrfb.h
@@ -0,0 +1,46 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+   u8 context;
+   void __iomem *vaddr[4];
+   unsigned long paddr[4];
+   u16 xoffset;
+   u16 yoffset;
+   u8 bytespp;
+};
+
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_suspend_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_resume_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+   u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+   u16 width, u16 height,
+   unsigned bytespp, bool yuv_mode);
+extern void omap_vrfb_restore_context(void);
+
+#endif /* __VRFB_H */
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 7a6c4c9..ac8b650 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -1,2 +1,5 @@
 config OMAP2_VRAM
bool
+
+config OMAP2_VRFB
+   bool
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 7fdf7bd..aa3751b 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
new file mode 100644
index 000..8726689
--- /dev/null
+++ b/drivers/video/omap2/vrfb.c
@@ -0,0 +1,277 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/mutex.h
+
+#include mach/io.h
+#include mach/vrfb.h
+#include mach/sdrc.h
+/*#define DEBUG*/
+
+#ifdef DEBUG
+#define DBG(format, ...) pr_debug(VRFB:  format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define SMS_ROT_VIRT_BASE(context, rot) \
+   (((context = 4) ? 0xD000 : 0x7000) \
++ (0x400 * (context)) \
++ (0x100 * (rot)))
+
+#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
+
+#define VRFB_PAGE_WIDTH_EXP5 /* Assuming SDRAM pagesize= 1024 */
+#define VRFB_PAGE_HEIGHT_EXP   5 /* 1024 = 2^5 * 2^5 */
+#define VRFB_PAGE_WIDTH(1  VRFB_PAGE_WIDTH_EXP)
+#define VRFB_PAGE_HEIGHT   (1  VRFB_PAGE_HEIGHT_EXP)
+#define SMS_IMAGEHEIGHT_OFFSET 16
+#define 

[PATCH 06/20] OMAP: DSS2: Documentation for DSS2

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 Documentation/arm/OMAP/DSS |  317 
 1 files changed, 317 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/arm/OMAP/DSS

diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
new file mode 100644
index 000..0af0e9e
--- /dev/null
+++ b/Documentation/arm/OMAP/DSS
@@ -0,0 +1,317 @@
+OMAP2/3 Display Subsystem
+-
+
+This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
+(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
+TV-out and multiple display support, but there are lots of small improvements
+also.
+
+The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
+panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
+currently side by side, you can choose which one to use.
+
+Features
+
+
+Working and tested features include:
+
+- MIPI DPI (parallel) output
+- MIPI DSI output in command mode
+- MIPI DBI (RFBI) output
+- SDI output
+- TV output
+- All pieces can be compiled as a module or inside kernel
+- Use DISPC to update any of the outputs
+- Use CPU to update RFBI or DSI output
+- OMAP DISPC planes
+- RGB16, RGB24 packed, RGB24 unpacked
+- YUV2, UYVY
+- Scaling
+- Adjusting DSS FCK to find a good pixel clock
+- Use DSI DPLL to create DSS FCK
+
+Tested boards include:
+- OMAP3 SDP board
+- Beagle board
+- N810
+
+omapdss driver
+--
+
+The DSS driver does not itself have any support for Linux framebuffer, V4L or
+such like the current ones, but it has an internal kernel API that upper level
+drivers can use.
+
+The DSS driver models OMAP's overlays, overlay managers and displays in a
+flexible way to enable non-common multi-display configuration. In addition to
+modelling the hardware overlays, omapdss supports virtual overlays and overlay
+managers. These can be used when updating a display with CPU or system DMA.
+
+Panel and controller drivers
+
+
+The drivers implement panel or controller specific functionality and are not
+usually visible to users except through omapfb driver.  They register
+themselves to the DSS driver.
+
+omapfb driver
+-
+
+The omapfb driver implements arbitrary number of standard linux framebuffers.
+These framebuffers can be routed flexibly to any overlays, thus allowing very
+dynamic display architecture.
+
+The driver exports some omapfb specific ioctls, which are compatible with the
+ioctls in the old driver.
+
+The rest of the non standard features are exported via sysfs. Whether the final
+implementation will use sysfs, or ioctls, is still open.
+
+V4L2 drivers
+
+
+V4L2 is being implemented in TI.
+
+From omapdss point of view the V4L2 drivers should be similar to framebuffer
+driver.
+
+Architecture
+
+
+Some clarification what the different components do:
+
+- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
+  pixel data for the image. Framebuffer has width and height and color
+  depth.
+- Overlay defines where the pixels are read from and where they go on the
+  screen. The overlay may be smaller than framebuffer, thus displaying only
+  part of the framebuffer. The position of the overlay may be changed if
+  the overlay is smaller than the display.
+- Overlay manager combines the overlays in to one image and feeds them to
+  display.
+- Display is the actual physical display device.
+
+A framebuffer can be connected to multiple overlays to show the same pixel data
+on all of the overlays. Note that in this case the overlay input sizes must be
+the same, but, in case of video overlays, the output size can be different. Any
+framebuffer can be connected to any overlay.
+
+An overlay can be connected to one overlay manager. Also DISPC overlays can be
+connected only to DISPC overlay managers, and virtual overlays can be only
+connected to virtual overlays.
+
+An overlay manager can be connected to one display. There are certain
+restrictions which kinds of displays an overlay manager can be connected:
+
+- DISPC TV overlay manager can be only connected to TV display.
+- Virtual overlay managers can only be connected to DBI or DSI displays.
+- DISPC LCD overlay manager can be connected to all displays, except TV
+  display.
+
+Sysfs
+-
+The sysfs interface is mainly used for testing. I don't think sysfs
+interface is the best for this in the final version, but I don't quite know
+what would be the best interfaces for these things.
+
+The sysfs interface is divided to two parts: DSS and FB.
+
+/sys/class/graphics/fb? directory:
+mirror 0=off, 1=on
+rotate Rotation 0-3 for 0, 90, 180, 270 degrees
+rotate_type0 = DMA rotation, 1 = VRFB rotation
+overlays   List of overlay numbers to which framebuffer pixels go
+phys_addr  Physical 

[PATCH 13/20] OMAP: DSS2: SDI driver

[Tomi Valkeinen]

SDI (Serial Display Interface) implements TI Flatlink 3G display
interface.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/dss/sdi.c |  261 +
 1 files changed, 261 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/dss/sdi.c

diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
new file mode 100644
index 000..a9c727e
--- /dev/null
+++ b/drivers/video/omap2/dss/sdi.c
@@ -0,0 +1,261 @@
+/*
+ * linux/drivers/video/omap2/dss/sdi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME SDI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+static struct {
+   bool skip_init;
+   bool update_enabled;
+} sdi;
+
+static void sdi_basic_init(void)
+{
+   dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+
+   dispc_set_lcd_display_type(OMAP_DSS_LCD_DISPLAY_TFT);
+   dispc_set_tft_data_lines(24);
+   dispc_lcd_enable_signal_polarity(1);
+}
+
+static int sdi_display_enable(struct omap_dss_device *dssdev)
+{
+   struct omap_video_timings *t = dssdev-panel.timings;
+   struct dispc_clock_info cinfo;
+   u16 lck_div, pck_div;
+   unsigned long fck;
+   unsigned long pck;
+   int r;
+
+   r = omap_dss_start_device(dssdev);
+   if (r) {
+   DSSERR(failed to start device\n);
+   goto err0;
+   }
+
+   if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+   DSSERR(dssdev already enabled\n);
+   r = -EINVAL;
+   goto err1;
+   }
+
+   /* In case of skip_init sdi_init has already enabled the clocks */
+   if (!sdi.skip_init)
+   dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+   sdi_basic_init();
+
+   /* 15.5.9.1.2 */
+   dssdev-panel.config |= OMAP_DSS_LCD_RF | OMAP_DSS_LCD_ONOFF;
+
+   dispc_set_pol_freq(dssdev-panel.config, dssdev-panel.acbi,
+   dssdev-panel.acb);
+
+   if (!sdi.skip_init)
+   r = dispc_calc_clock_div(1, t-pixel_clock * 1000,
+   cinfo);
+   else
+   r = dispc_get_clock_div(cinfo);
+
+   if (r)
+   goto err2;
+
+   fck = cinfo.fck;
+   lck_div = cinfo.lck_div;
+   pck_div = cinfo.pck_div;
+
+   pck = fck / lck_div / pck_div / 1000;
+
+   if (pck != t-pixel_clock) {
+   DSSWARN(Could not find exact pixel clock. Requested %d kHz, 
+   got %lu kHz\n,
+   t-pixel_clock, pck);
+
+   t-pixel_clock = pck;
+   }
+
+
+   dispc_set_lcd_timings(t);
+
+   r = dispc_set_clock_div(cinfo);
+   if (r)
+   goto err2;
+
+   if (!sdi.skip_init) {
+   dss_sdi_init(dssdev-phy.sdi.datapairs);
+   dss_sdi_enable();
+   mdelay(2);
+   }
+
+   dispc_enable_lcd_out(1);
+
+   if (dssdev-driver-enable) {
+   r = dssdev-driver-enable(dssdev);
+   if (r)
+   goto err3;
+   }
+
+   dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+   sdi.skip_init = 0;
+
+   return 0;
+err3:
+   dispc_enable_lcd_out(0);
+err2:
+   dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+err1:
+   omap_dss_stop_device(dssdev);
+err0:
+   return r;
+}
+
+static int sdi_display_resume(struct omap_dss_device *dssdev);
+
+static void sdi_display_disable(struct omap_dss_device *dssdev)
+{
+   if (dssdev-state == OMAP_DSS_DISPLAY_DISABLED)
+   return;
+
+   if (dssdev-state == OMAP_DSS_DISPLAY_SUSPENDED)
+   sdi_display_resume(dssdev);
+
+   if (dssdev-driver-disable)
+   dssdev-driver-disable(dssdev);
+
+   dispc_enable_lcd_out(0);
+
+   dss_sdi_disable();
+
+   dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+   dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
+   omap_dss_stop_device(dssdev);
+}
+
+static int sdi_display_suspend(struct omap_dss_device *dssdev)
+{
+   if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+   return -EINVAL;
+
+   if (dssdev-driver-suspend)
+   

[PATCH 12/20] OMAP: DSS2: RFBI driver

[Tomi Valkeinen]

RFBI (Remote FrameBuffer Interface) implements MIPI DBI interface.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/dss/rfbi.c | 1310 
 1 files changed, 1310 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/dss/rfbi.c

diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
new file mode 100644
index 000..9dd2349
--- /dev/null
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -0,0 +1,1310 @@
+/*
+ * linux/drivers/video/omap2/dss/rfbi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME RFBI
+
+#include linux/kernel.h
+#include linux/dma-mapping.h
+#include linux/vmalloc.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/kfifo.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/seq_file.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+/*#define MEASURE_PERF*/
+
+#define RFBI_BASE   0x48050800
+
+struct rfbi_reg { u16 idx; };
+
+#define RFBI_REG(idx)  ((const struct rfbi_reg) { idx })
+
+#define RFBI_REVISION  RFBI_REG(0x)
+#define RFBI_SYSCONFIG RFBI_REG(0x0010)
+#define RFBI_SYSSTATUS RFBI_REG(0x0014)
+#define RFBI_CONTROL   RFBI_REG(0x0040)
+#define RFBI_PIXEL_CNT RFBI_REG(0x0044)
+#define RFBI_LINE_NUMBER   RFBI_REG(0x0048)
+#define RFBI_CMD   RFBI_REG(0x004c)
+#define RFBI_PARAM RFBI_REG(0x0050)
+#define RFBI_DATA  RFBI_REG(0x0054)
+#define RFBI_READ  RFBI_REG(0x0058)
+#define RFBI_STATUSRFBI_REG(0x005c)
+
+#define RFBI_CONFIG(n) RFBI_REG(0x0060 + (n)*0x18)
+#define RFBI_ONOFF_TIME(n) RFBI_REG(0x0064 + (n)*0x18)
+#define RFBI_CYCLE_TIME(n) RFBI_REG(0x0068 + (n)*0x18)
+#define RFBI_DATA_CYCLE1(n)RFBI_REG(0x006c + (n)*0x18)
+#define RFBI_DATA_CYCLE2(n)RFBI_REG(0x0070 + (n)*0x18)
+#define RFBI_DATA_CYCLE3(n)RFBI_REG(0x0074 + (n)*0x18)
+
+#define RFBI_VSYNC_WIDTH   RFBI_REG(0x0090)
+#define RFBI_HSYNC_WIDTH   RFBI_REG(0x0094)
+
+#define RFBI_CMD_FIFO_LEN_BYTES (16 * sizeof(struct update_param))
+
+#define REG_FLD_MOD(idx, val, start, end) \
+   rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
+
+/* To work around an RFBI transfer rate limitation */
+#define OMAP_RFBI_RATE_LIMIT1
+
+enum omap_rfbi_cycleformat {
+   OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
+   OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
+   OMAP_DSS_RFBI_CYCLEFORMAT_3_1 = 2,
+   OMAP_DSS_RFBI_CYCLEFORMAT_3_2 = 3,
+};
+
+enum omap_rfbi_datatype {
+   OMAP_DSS_RFBI_DATATYPE_12 = 0,
+   OMAP_DSS_RFBI_DATATYPE_16 = 1,
+   OMAP_DSS_RFBI_DATATYPE_18 = 2,
+   OMAP_DSS_RFBI_DATATYPE_24 = 3,
+};
+
+enum omap_rfbi_parallelmode {
+   OMAP_DSS_RFBI_PARALLELMODE_8 = 0,
+   OMAP_DSS_RFBI_PARALLELMODE_9 = 1,
+   OMAP_DSS_RFBI_PARALLELMODE_12 = 2,
+   OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
+};
+
+enum update_cmd {
+   RFBI_CMD_UPDATE = 0,
+   RFBI_CMD_SYNC   = 1,
+};
+
+static int rfbi_convert_timings(struct rfbi_timings *t);
+static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
+static void process_cmd_fifo(void);
+
+static struct {
+   void __iomem*base;
+
+   unsigned long   l4_khz;
+
+   enum omap_rfbi_datatype datatype;
+   enum omap_rfbi_parallelmode parallelmode;
+
+   enum omap_rfbi_te_mode te_mode;
+   int te_enabled;
+
+   void (*framedone_callback)(void *data);
+   void *framedone_callback_data;
+
+   struct omap_dss_device *dssdev[2];
+
+   struct kfifo  *cmd_fifo;
+   spinlock_tcmd_lock;
+   struct completion cmd_done;
+   atomic_t  cmd_fifo_full;
+   atomic_t  cmd_pending;
+#ifdef MEASURE_PERF
+   unsigned perf_bytes;
+   ktime_t perf_setup_time;
+   ktime_t perf_start_time;
+#endif
+} rfbi;
+
+struct update_region {
+   u16 x;
+   u16 y;
+   u16 w;
+   u16 h;
+};
+
+struct update_param {
+   u8 rfbi_module;
+   u8 cmd;
+
+   union {
+   struct update_region r;
+   struct completion *sync;
+   } par;
+};
+
+static inline 

[PATCH 11/20] OMAP: DSS2: Video encoder driver

[Tomi Valkeinen]

VENC (video encoder) driver implements OMAP's analog S-Video/Composite
TV-out.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
 drivers/video/omap2/dss/venc.c |  797 
 1 files changed, 797 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/dss/venc.c

diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
new file mode 100644
index 000..cf7827e
--- /dev/null
+++ b/drivers/video/omap2/dss/venc.c
@@ -0,0 +1,797 @@
+/*
+ * linux/drivers/video/omap2/dss/venc.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * VENC settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME VENC
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/seq_file.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+
+#include mach/display.h
+#include mach/cpu.h
+
+#include dss.h
+
+#define VENC_BASE  0x48050C00
+
+/* Venc registers */
+#define VENC_REV_ID0x00
+#define VENC_STATUS0x04
+#define VENC_F_CONTROL 0x08
+#define VENC_VIDOUT_CTRL   0x10
+#define VENC_SYNC_CTRL 0x14
+#define VENC_LLEN  0x1C
+#define VENC_FLENS 0x20
+#define VENC_HFLTR_CTRL0x24
+#define VENC_CC_CARR_WSS_CARR  0x28
+#define VENC_C_PHASE   0x2C
+#define VENC_GAIN_U0x30
+#define VENC_GAIN_V0x34
+#define VENC_GAIN_Y0x38
+#define VENC_BLACK_LEVEL   0x3C
+#define VENC_BLANK_LEVEL   0x40
+#define VENC_X_COLOR   0x44
+#define VENC_M_CONTROL 0x48
+#define VENC_BSTAMP_WSS_DATA   0x4C
+#define VENC_S_CARR0x50
+#define VENC_LINE210x54
+#define VENC_LN_SEL0x58
+#define VENC_L21__WC_CTL   0x5C
+#define VENC_HTRIGGER_VTRIGGER 0x60
+#define VENC_SAVID__EAVID  0x64
+#define VENC_FLEN__FAL 0x68
+#define VENC_LAL__PHASE_RESET  0x6C
+#define VENC_HS_INT_START_STOP_X   0x70
+#define VENC_HS_EXT_START_STOP_X   0x74
+#define VENC_VS_INT_START_X0x78
+#define VENC_VS_INT_STOP_X__VS_INT_START_Y 0x7C
+#define VENC_VS_INT_STOP_Y__VS_EXT_START_X 0x80
+#define VENC_VS_EXT_STOP_X__VS_EXT_START_Y 0x84
+#define VENC_VS_EXT_STOP_Y 0x88
+#define VENC_AVID_START_STOP_X 0x90
+#define VENC_AVID_START_STOP_Y 0x94
+#define VENC_FID_INT_START_X__FID_INT_START_Y  0xA0
+#define VENC_FID_INT_OFFSET_Y__FID_EXT_START_X 0xA4
+#define VENC_FID_EXT_START_Y__FID_EXT_OFFSET_Y 0xA8
+#define VENC_TVDETGP_INT_START_STOP_X  0xB0
+#define VENC_TVDETGP_INT_START_STOP_Y  0xB4
+#define VENC_GEN_CTRL  0xB8
+#define VENC_OUTPUT_CONTROL0xC4
+#define VENC_OUTPUT_TEST   0xC8
+#define VENC_DAC_B__DAC_C  0xC8
+
+struct venc_config {
+   u32 f_control;
+   u32 vidout_ctrl;
+   u32 sync_ctrl;
+   u32 llen;
+   u32 flens;
+   u32 hfltr_ctrl;
+   u32 cc_carr_wss_carr;
+   u32 c_phase;
+   u32 gain_u;
+   u32 gain_v;
+   u32 gain_y;
+   u32 black_level;
+   u32 blank_level;
+   u32 x_color;
+   u32 m_control;
+   u32 bstamp_wss_data;
+   u32 s_carr;
+   u32 line21;
+   u32 ln_sel;
+   u32 l21__wc_ctl;
+   u32 htrigger_vtrigger;
+   u32 savid__eavid;
+   u32 flen__fal;
+   u32 lal__phase_reset;
+   u32 hs_int_start_stop_x;
+   u32 hs_ext_start_stop_x;
+   u32 vs_int_start_x;
+   u32 vs_int_stop_x__vs_int_start_y;
+   u32 vs_int_stop_y__vs_ext_start_x;
+   u32 vs_ext_stop_x__vs_ext_start_y;
+   u32 vs_ext_stop_y;
+   

[PATCH 16/20] OMAP: DSS2: Add DPI panel drivers

[Tomi Valkeinen]

- Generic panel
- Samsung LTE430WQ-F0C LCD Panel
- Sharp LS037V7DW01 LCD Panel

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/Kconfig|1 +
 drivers/video/omap2/Makefile   |1 +
 drivers/video/omap2/displays/Kconfig   |   22 +++
 drivers/video/omap2/displays/Makefile  |3 +
 drivers/video/omap2/displays/panel-generic.c   |  104 +
 .../omap2/displays/panel-samsung-lte430wq-f0c.c|  113 +++
 .../video/omap2/displays/panel-sharp-ls037v7dw01.c |  153 
 7 files changed, 397 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/Kconfig
 create mode 100644 drivers/video/omap2/displays/Makefile
 create mode 100644 drivers/video/omap2/displays/panel-generic.c
 create mode 100644 drivers/video/omap2/displays/panel-samsung-lte430wq-f0c.c
 create mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c

diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 3e60d7e..d877c36 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -6,3 +6,4 @@ config OMAP2_VRFB
 
 source drivers/video/omap2/dss/Kconfig
 source drivers/video/omap2/omapfb/Kconfig
+source drivers/video/omap2/displays/Kconfig
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 3ba6ef5..d853d05 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
 
 obj-y += dss/
 obj-y += omapfb/
+obj-y += displays/
diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
new file mode 100644
index 000..396905d
--- /dev/null
+++ b/drivers/video/omap2/displays/Kconfig
@@ -0,0 +1,22 @@
+menu OMAP2/3 Display Device Drivers
+depends on OMAP2_DSS
+
+config PANEL_GENERIC
+tristate Generic Panel
+help
+ Generic panel driver.
+ Used for DVI output for Beagle and OMAP3 SDP.
+
+config PANEL_SAMSUNG_LTE430WQ_F0C
+tristate Samsung LTE430WQ-F0C LCD Panel
+depends on OMAP2_DSS
+help
+  LCD Panel used on Overo Palo43
+
+config PANEL_SHARP_LS037V7DW01
+tristate Sharp LS037V7DW01 LCD Panel
+depends on OMAP2_DSS
+help
+  LCD Panel used in TI's SDP3430 and EVM boards
+
+endmenu
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
new file mode 100644
index 000..a26bbd2
--- /dev/null
+++ b/drivers/video/omap2/displays/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
+obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
+obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
diff --git a/drivers/video/omap2/displays/panel-generic.c 
b/drivers/video/omap2/displays/panel-generic.c
new file mode 100644
index 000..738147e
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -0,0 +1,104 @@
+/*
+ * Generic panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include mach/display.h
+
+static struct omap_video_timings generic_panel_timings = {
+   /* 640 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
+   .x_res  = 640,
+   .y_res  = 480,
+   .pixel_clock= 23500,
+   .hfp= 48,
+   .hsw= 32,
+   .hbp= 80,
+   .vfp= 3,
+   .vsw= 4,
+   .vbp= 7,
+};
+
+static int generic_panel_probe(struct omap_dss_device *dssdev)
+{
+   dssdev-panel.config = OMAP_DSS_LCD_TFT;
+   dssdev-panel.timings = generic_panel_timings;
+
+   return 0;
+}
+
+static void generic_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int generic_panel_enable(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   if (dssdev-platform_enable)
+   r = dssdev-platform_enable(dssdev);
+
+   return r;
+}
+
+static void generic_panel_disable(struct omap_dss_device *dssdev)
+{
+   if (dssdev-platform_disable)
+   dssdev-platform_disable(dssdev);
+}
+
+static int generic_panel_suspend(struct omap_dss_device *dssdev)
+{
+   generic_panel_disable(dssdev);
+  

[PATCH 17/20] OMAP: DSS2: Taal DSI command mode panel driver

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/displays/Kconfig  |6 +
 drivers/video/omap2/displays/Makefile |2 +
 drivers/video/omap2/displays/panel-taal.c |  900 +
 3 files changed, 908 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-taal.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index 396905d..79d2861 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,4 +19,10 @@ config PANEL_SHARP_LS037V7DW01
 help
   LCD Panel used in TI's SDP3430 and EVM boards
 
+config PANEL_TAAL
+tristate Taal DSI Panel
+depends on OMAP2_DSS_DSI
+help
+  Taal DSI command mode panel from TPO.
+
 endmenu
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index a26bbd2..d44e765 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
 obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+
+obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
new file mode 100644
index 000..84f0d47
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -0,0 +1,900 @@
+/*
+ * Taal DSI command mode panel
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+/*#define DEBUG*/
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/jiffies.h
+#include linux/sched.h
+#include linux/backlight.h
+#include linux/fb.h
+#include linux/interrupt.h
+#include linux/gpio.h
+#include linux/completion.h
+
+#include mach/display.h
+
+/* DSI Virtual channel. Hardcoded for now. */
+#define TCH 0
+
+#define DCS_READ_NUM_ERRORS0x05
+#define DCS_READ_POWER_MODE0x0a
+#define DCS_READ_MADCTL0x0b
+#define DCS_READ_PIXEL_FORMAT  0x0c
+#define DCS_SLEEP_IN   0x10
+#define DCS_SLEEP_OUT  0x11
+#define DCS_DISPLAY_OFF0x28
+#define DCS_DISPLAY_ON 0x29
+#define DCS_COLUMN_ADDR0x2a
+#define DCS_PAGE_ADDR  0x2b
+#define DCS_MEMORY_WRITE   0x2c
+#define DCS_TEAR_OFF   0x34
+#define DCS_TEAR_ON0x35
+#define DCS_MEM_ACC_CTRL   0x36
+#define DCS_PIXEL_FORMAT   0x3a
+#define DCS_BRIGHTNESS 0x51
+#define DCS_CTRL_DISPLAY   0x53
+#define DCS_WRITE_CABC 0x55
+#define DCS_READ_CABC  0x56
+#define DCS_GET_ID10xda
+#define DCS_GET_ID20xdb
+#define DCS_GET_ID30xdc
+
+struct taal_data {
+   struct backlight_device *bldev;
+
+   unsigned long   hw_guard_end;   /* next value of jiffies when we can
+* issue the next sleep in/out command
+*/
+   unsigned long   hw_guard_wait;  /* max guard time in jiffies */
+
+   struct omap_dss_device *dssdev;
+
+   bool enabled;
+   u8 rotate;
+   bool mirror;
+
+   bool te_enabled;
+   bool use_ext_te;
+   struct completion te_completion;
+
+   bool use_dsi_bl;
+
+   bool cabc_broken;
+   unsigned cabc_mode;
+
+   bool intro_printed;
+};
+
+static void hw_guard_start(struct taal_data *td, int guard_msec)
+{
+   td-hw_guard_wait = msecs_to_jiffies(guard_msec);
+   td-hw_guard_end = jiffies + td-hw_guard_wait;
+}
+
+static void hw_guard_wait(struct taal_data *td)
+{
+   unsigned long wait = td-hw_guard_end - jiffies;
+
+   if ((long)wait  0  wait = td-hw_guard_wait) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(wait);
+   }
+}
+
+static int taal_dcs_read_1(u8 dcs_cmd, u8 *data)
+{
+   int r;
+   u8 buf[1];
+
+   r = dsi_vc_dcs_read(TCH, dcs_cmd, buf, 1);
+
+   if (r  0)
+   return r;
+
+   *data = buf[0];
+
+   return 0;
+}
+
+static int taal_dcs_write_0(u8 dcs_cmd)
+{
+   return dsi_vc_dcs_write(TCH, dcs_cmd, 1);
+}
+
+static int taal_dcs_write_1(u8 dcs_cmd, u8 param)
+{
+   u8 buf[2];
+   

[PATCH 20/20] OMAP: Overo: Enable DSS2 for Overo

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/overo_defconfig  |  265 -
 arch/arm/mach-omap2/board-overo.c |  149 +++--
 2 files changed, 196 insertions(+), 218 deletions(-)

diff --git a/arch/arm/configs/overo_defconfig b/arch/arm/configs/overo_defconfig
index a57f9e4..93d911c 100644
--- a/arch/arm/configs/overo_defconfig
+++ b/arch/arm/configs/overo_defconfig
@@ -994,225 +994,76 @@ CONFIG_SSB_POSSIBLE=y
 #
 # CONFIG_MFD_CORE is not set
 # CONFIG_MFD_SM501 is not set
+# CONFIG_MFD_ASIC3 is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
-# CONFIG_UCB1400_CORE is not set
+# CONFIG_TPS65010 is not set
+# CONFIG_TWL4030_CORE is not set
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set
 # CONFIG_MFD_TC6393XB is not set
-
-#
-# Multimedia devices
-#
-
-#
-# Multimedia core support
-#
-CONFIG_VIDEO_DEV=m
-CONFIG_VIDEO_V4L2_COMMON=m
-CONFIG_VIDEO_ALLOW_V4L1=y
-CONFIG_VIDEO_V4L1_COMPAT=y
-CONFIG_DVB_CORE=m
-CONFIG_VIDEO_MEDIA=m
-
-#
-# Multimedia drivers
-#
-CONFIG_MEDIA_ATTACH=y
-CONFIG_MEDIA_TUNER=m
-# CONFIG_MEDIA_TUNER_CUSTOMIZE is not set
-CONFIG_MEDIA_TUNER_SIMPLE=m
-CONFIG_MEDIA_TUNER_TDA8290=m
-CONFIG_MEDIA_TUNER_TDA827X=m
-CONFIG_MEDIA_TUNER_TDA18271=m
-CONFIG_MEDIA_TUNER_TDA9887=m
-CONFIG_MEDIA_TUNER_TEA5761=m
-CONFIG_MEDIA_TUNER_TEA5767=m
-CONFIG_MEDIA_TUNER_MT20XX=m
-CONFIG_MEDIA_TUNER_MT2060=m
-CONFIG_MEDIA_TUNER_MT2266=m
-CONFIG_MEDIA_TUNER_QT1010=m
-CONFIG_MEDIA_TUNER_XC2028=m
-CONFIG_MEDIA_TUNER_XC5000=m
-CONFIG_MEDIA_TUNER_MXL5005S=m
-CONFIG_VIDEO_V4L2=m
-CONFIG_VIDEO_V4L1=m
-CONFIG_VIDEO_TVEEPROM=m
-CONFIG_VIDEO_TUNER=m
-CONFIG_VIDEO_CAPTURE_DRIVERS=y
-# CONFIG_VIDEO_ADV_DEBUG is not set
-CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
-CONFIG_VIDEO_MSP3400=m
-CONFIG_VIDEO_CS53L32A=m
-CONFIG_VIDEO_WM8775=m
-CONFIG_VIDEO_SAA711X=m
-CONFIG_VIDEO_CX25840=m
-CONFIG_VIDEO_CX2341X=m
-# CONFIG_VIDEO_VIVI is not set
-# CONFIG_VIDEO_CPIA is not set
-# CONFIG_VIDEO_CPIA2 is not set
-# CONFIG_VIDEO_SAA5246A is not set
-# CONFIG_VIDEO_SAA5249 is not set
-# CONFIG_TUNER_3036 is not set
-# CONFIG_VIDEO_AU0828 is not set
-CONFIG_V4L_USB_DRIVERS=y
-CONFIG_USB_VIDEO_CLASS=m
-CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
-# CONFIG_USB_GSPCA is not set
-CONFIG_VIDEO_PVRUSB2=m
-CONFIG_VIDEO_PVRUSB2_SYSFS=y
-CONFIG_VIDEO_PVRUSB2_DVB=y
-# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
-# CONFIG_VIDEO_EM28XX is not set
-CONFIG_VIDEO_USBVISION=m
-CONFIG_VIDEO_USBVIDEO=m
-CONFIG_USB_VICAM=m
-CONFIG_USB_IBMCAM=m
-CONFIG_USB_KONICAWC=m
-CONFIG_USB_QUICKCAM_MESSENGER=m
-# CONFIG_USB_ET61X251 is not set
-CONFIG_VIDEO_OVCAMCHIP=m
-CONFIG_USB_W9968CF=m
-CONFIG_USB_OV511=m
-CONFIG_USB_SE401=m
-CONFIG_USB_SN9C102=m
-CONFIG_USB_STV680=m
-# CONFIG_USB_ZC0301 is not set
-CONFIG_USB_PWC=m
-# CONFIG_USB_PWC_DEBUG is not set
-CONFIG_USB_ZR364XX=m
-# CONFIG_USB_STKWEBCAM is not set
-# CONFIG_USB_S2255 is not set
-# CONFIG_SOC_CAMERA is not set
-# CONFIG_VIDEO_SH_MOBILE_CEU is not set
-CONFIG_RADIO_ADAPTERS=y
-# CONFIG_USB_DSBR is not set
-# CONFIG_USB_SI470X is not set
-CONFIG_DVB_CAPTURE_DRIVERS=y
-# CONFIG_TTPCI_EEPROM is not set
-
-#
-# Supported USB Adapters
-#
-CONFIG_DVB_USB=m
-# CONFIG_DVB_USB_DEBUG is not set
-CONFIG_DVB_USB_A800=m
-CONFIG_DVB_USB_DIBUSB_MB=m
-# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
-CONFIG_DVB_USB_DIBUSB_MC=m
-CONFIG_DVB_USB_DIB0700=m
-CONFIG_DVB_USB_UMT_010=m
-CONFIG_DVB_USB_CXUSB=m
-CONFIG_DVB_USB_M920X=m
-CONFIG_DVB_USB_GL861=m
-CONFIG_DVB_USB_AU6610=m
-CONFIG_DVB_USB_DIGITV=m
-CONFIG_DVB_USB_VP7045=m
-CONFIG_DVB_USB_VP702X=m
-CONFIG_DVB_USB_GP8PSK=m
-CONFIG_DVB_USB_NOVA_T_USB2=m
-CONFIG_DVB_USB_TTUSB2=m
-CONFIG_DVB_USB_DTT200U=m
-CONFIG_DVB_USB_OPERA1=m
-CONFIG_DVB_USB_AF9005=m
-CONFIG_DVB_USB_AF9005_REMOTE=m
-# CONFIG_DVB_USB_DW2102 is not set
-# CONFIG_DVB_USB_ANYSEE is not set
-CONFIG_DVB_TTUSB_BUDGET=m
-CONFIG_DVB_TTUSB_DEC=m
-CONFIG_DVB_CINERGYT2=m
-# CONFIG_DVB_CINERGYT2_TUNING is not set
-# CONFIG_DVB_SIANO_SMS1XXX is not set
-
-#
-# Supported FlexCopII (B2C2) Adapters
-#
-# CONFIG_DVB_B2C2_FLEXCOP is not set
-
-#
-# Supported DVB Frontends
-#
-
-#
-# Customise DVB Frontends
-#
-# CONFIG_DVB_FE_CUSTOMISE is not set
-
-#
-# DVB-S (satellite) frontends
-#
-CONFIG_DVB_CX24110=m
-CONFIG_DVB_CX24123=m
-CONFIG_DVB_MT312=m
-CONFIG_DVB_S5H1420=m
-CONFIG_DVB_STV0299=m
-CONFIG_DVB_TDA8083=m
-CONFIG_DVB_TDA10086=m
-CONFIG_DVB_VES1X93=m
-CONFIG_DVB_TUNER_ITD1000=m
-CONFIG_DVB_TDA826X=m
-CONFIG_DVB_TUA6100=m
-
-#
-# DVB-T (terrestrial) frontends
-#
-CONFIG_DVB_SP8870=m
-CONFIG_DVB_SP887X=m
-CONFIG_DVB_CX22700=m
-CONFIG_DVB_CX22702=m
-# CONFIG_DVB_DRX397XD is not set
-CONFIG_DVB_L64781=m
-CONFIG_DVB_TDA1004X=m
-CONFIG_DVB_NXT6000=m
-CONFIG_DVB_MT352=m
-CONFIG_DVB_ZL10353=m
-CONFIG_DVB_DIB3000MB=m
-CONFIG_DVB_DIB3000MC=m
-CONFIG_DVB_DIB7000M=m
-CONFIG_DVB_DIB7000P=m
-CONFIG_DVB_TDA10048=m
-
-#
-# DVB-C (cable) frontends
-#
-CONFIG_DVB_VES1820=m

[PATCH 10/20] OMAP: DSS2: DPI driver

[Tomi Valkeinen]

This implements MIPI DPI interface.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/dss/dpi.c |  388 +
 1 files changed, 388 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/dss/dpi.c

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
new file mode 100644
index 000..b6543c8
--- /dev/null
+++ b/drivers/video/omap2/dss/dpi.c
@@ -0,0 +1,388 @@
+/*
+ * linux/drivers/video/omap2/dss/dpi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME DPI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/errno.h
+
+#include mach/board.h
+#include mach/display.h
+#include mach/cpu.h
+
+#include dss.h
+
+static struct {
+   int update_enabled;
+} dpi;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
+   unsigned long *fck, int *lck_div, int *pck_div)
+{
+   struct dsi_clock_info cinfo;
+   int r;
+
+   r = dsi_pll_calc_pck(is_tft, pck_req, cinfo);
+   if (r)
+   return r;
+
+   r = dsi_pll_program(cinfo);
+   if (r)
+   return r;
+
+   dss_select_clk_source(0, 1);
+
+   dispc_set_lcd_divisor(cinfo.lck_div, cinfo.pck_div);
+
+   *fck = cinfo.dsi1_pll_fclk;
+   *lck_div = cinfo.lck_div;
+   *pck_div = cinfo.pck_div;
+
+   return 0;
+}
+#else
+static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,
+   unsigned long *fck, int *lck_div, int *pck_div)
+{
+   struct dispc_clock_info cinfo;
+   int r;
+
+   r = dispc_calc_clock_div(is_tft, pck_req, cinfo);
+   if (r)
+   return r;
+
+   r = dispc_set_clock_div(cinfo);
+   if (r)
+   return r;
+
+   *fck = cinfo.fck;
+   *lck_div = cinfo.lck_div;
+   *pck_div = cinfo.pck_div;
+
+   return 0;
+}
+#endif
+
+static int dpi_set_mode(struct omap_dss_device *dssdev)
+{
+   struct omap_video_timings *t = dssdev-panel.timings;
+   int lck_div, pck_div;
+   unsigned long fck;
+   unsigned long pck;
+   bool is_tft;
+   int r = 0;
+
+   dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+   dispc_set_pol_freq(dssdev-panel.config, dssdev-panel.acbi,
+   dssdev-panel.acb);
+
+   is_tft = (dssdev-panel.config  OMAP_DSS_LCD_TFT) != 0;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+   r = dpi_set_dsi_clk(is_tft, t-pixel_clock * 1000,
+   fck, lck_div, pck_div);
+#else
+   r = dpi_set_dispc_clk(is_tft, t-pixel_clock * 1000,
+   fck, lck_div, pck_div);
+#endif
+   if (r)
+   goto err0;
+
+   pck = fck / lck_div / pck_div / 1000;
+
+   if (pck != t-pixel_clock) {
+   DSSWARN(Could not find exact pixel clock. 
+   Requested %d kHz, got %lu kHz\n,
+   t-pixel_clock, pck);
+
+   t-pixel_clock = pck;
+   }
+
+   dispc_set_lcd_timings(t);
+
+err0:
+   dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+   return r;
+}
+
+static int dpi_basic_init(struct omap_dss_device *dssdev)
+{
+   bool is_tft;
+
+   is_tft = (dssdev-panel.config  OMAP_DSS_LCD_TFT) != 0;
+
+   dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+   dispc_set_lcd_display_type(is_tft ? OMAP_DSS_LCD_DISPLAY_TFT :
+   OMAP_DSS_LCD_DISPLAY_STN);
+   dispc_set_tft_data_lines(dssdev-phy.dpi.data_lines);
+
+   return 0;
+}
+
+static int dpi_display_enable(struct omap_dss_device *dssdev)
+{
+   int r;
+
+   r = omap_dss_start_device(dssdev);
+   if (r) {
+   DSSERR(failed to start device\n);
+   goto err0;
+   }
+
+   if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+   DSSERR(display already enabled\n);
+   r = -EINVAL;
+   goto err1;
+   }
+
+   dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+   r = dpi_basic_init(dssdev);
+   if (r)
+   goto err2;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+   dss_clk_enable(DSS_CLK_FCK2);
+   r = dsi_pll_init(0, 1);
+ 

[PATCH 18/20] OMAP: SDP: Enable DSS2 for OMAP3 SDP board

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap_3430sdp_defconfig |   31 +-
 arch/arm/mach-omap2/board-3430sdp.c |  171 +++
 2 files changed, 181 insertions(+), 21 deletions(-)

diff --git a/arch/arm/configs/omap_3430sdp_defconfig 
b/arch/arm/configs/omap_3430sdp_defconfig
index 73e0128..a0dce8f 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1336,10 +1336,35 @@ CONFIG_FB_CFB_IMAGEBLIT=y
 #
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_LCD_VGA is not set
+# CONFIG_FB_OMAP_031M3R is not set
+# CONFIG_FB_OMAP_048M3R is not set
+# CONFIG_FB_OMAP_079M3R is not set
+# CONFIG_FB_OMAP_092M9R is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
-CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=6
+CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+CONFIG_PANEL_SHARP_LS037V7DW01=y
+CONFIG_FB_OMAP2=y
+CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=3
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 21b4a52..0bb83f5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -36,6 +36,7 @@
 #include mach/common.h
 #include mach/dma.h
 #include mach/gpmc.h
+#include mach/display.h
 
 #include mach/control.h
 #include mach/keypad.h
@@ -148,23 +149,149 @@ static struct spi_board_info sdp3430_spi_board_info[] 
__initdata = {
},
 };
 
-static struct platform_device sdp3430_lcd_device = {
-   .name   = sdp2430_lcd,
-   .id = -1,
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO   8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO  5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+   int r;
+
+   enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+   backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+   r = gpio_request(enable_gpio, LCD reset);
+   if (r) {
+   printk(KERN_ERR failed to get LCD reset GPIO\n);
+   goto err0;
+   }
+
+   r = gpio_request(backlight_gpio, LCD Backlight);
+   if (r) {
+   printk(KERN_ERR failed to get LCD backlight GPIO\n);
+   goto err1;
+   }
+
+   gpio_direction_output(enable_gpio, 0);
+   gpio_direction_output(backlight_gpio, 0);
+
+   return;
+err1:
+   gpio_free(enable_gpio);
+err0:
+   return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   if (dvi_enabled) {
+   printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
+   return -EINVAL;
+   }
+
+   gpio_direction_output(enable_gpio, 1);
+   gpio_direction_output(backlight_gpio, 1);
+
+   lcd_enabled = 1;
+
+   return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   lcd_enabled = 0;
+
+   gpio_direction_output(enable_gpio, 0);
+   gpio_direction_output(backlight_gpio, 0);
+}
+
+static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+   if (lcd_enabled) {
+   printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+   return -EINVAL;
+   }
+
+   dvi_enabled = 1;
+
+   return 0;
+}
+
+static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+   dvi_enabled = 0;
+}
+
+static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+   return 0;
+}
+
+static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+
+static struct omap_dss_device sdp3430_lcd_device = {
+   .name   = lcd,
+   .driver_name= sharp_ls_panel,
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .platform_enable= sdp3430_panel_enable_lcd,
+   .platform_disable   = sdp3430_panel_disable_lcd,
 };
 
-static struct regulator_consumer_supply sdp3430_vdac_supply = {
-   .supply = vdac,
-   .dev= sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_dvi_device = {
+   .name   = dvi,
+   .driver_name= generic_panel,
+   .type   = 

[PATCH] omap2: compile usb-tusb6010.c

[Kalle Valo]

For some reason usb-tusb6010.c was't compiled, add it to Makefile and
Kconfig. This is prepraration for upcoming n8x0 support.

Signed-off-by: Kalle Valo kalle.v...@iki.fi
---

 arch/arm/mach-omap2/Kconfig  |5 +
 arch/arm/mach-omap2/Makefile |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a755eb5..bf54686 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -31,6 +31,11 @@ config MACH_OMAP_GENERIC
bool Generic OMAP board
depends on ARCH_OMAP2  ARCH_OMAP24XX
 
+config MACH_OMAP2_TUSB6010
+   bool
+   depends on ARCH_OMAP2  ARCH_OMAP2420
+   default y if MACH_NOKIA_N8X0
+
 config MACH_OMAP_H4
bool OMAP 2420 H4 board
depends on ARCH_OMAP2  ARCH_OMAP24XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 735bae5..757c84b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_MACH_OMAP_4430SDP)   += 
board-4430sdp.o
 
 # Platform specific device init code
 obj-y  += usb-musb.o
+obj-$(CONFIG_MACH_OMAP2_TUSB6010)  += usb-tusb6010.o
 
 onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
 obj-y  += $(onenand-m) $(onenand-y)

--
To unsubscribe from this list: send the line unsubscribe 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] Nokia n8x0 support for mainline

[Kalle Valo]

Here are patches for mainline to support Nokia N800 and N810. Tested on 
Nokia N800. Lots of stuff still missing, but we have to start from
somewhere.

---

Kalle Valo (2):
  n8x0: add n8x0_defconfig
  Add support for Nokia N800


 arch/arm/configs/n8x0_defconfig  | 1104 ++
 arch/arm/mach-omap2/Kconfig  |4 
 arch/arm/mach-omap2/Makefile |2 
 arch/arm/mach-omap2/board-n8x0.c |  307 +++
 4 files changed, 1416 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/configs/n8x0_defconfig
 create mode 100644 arch/arm/mach-omap2/board-n8x0.c

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

[PATCH 1/2] Add support for Nokia N800

[Kalle Valo]

Signed-off-by: Kalle Valo kalle.v...@iki.fi
---

 arch/arm/mach-omap2/Kconfig  |4 
 arch/arm/mach-omap2/Makefile |2 
 arch/arm/mach-omap2/board-n8x0.c |  307 ++
 3 files changed, 312 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-n8x0.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bf54686..75b1c7e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,10 @@ config MACH_OMAP_3430SDP
bool OMAP 3430 SDP board
depends on ARCH_OMAP3  ARCH_OMAP34XX
 
+config MACH_NOKIA_N8X0
+   bool Nokia N800/N810
+   depends on ARCH_OMAP2420
+
 config MACH_NOKIA_RX51
bool Nokia RX-51 board
depends on ARCH_OMAP3  ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 757c84b..8850a24 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -62,7 +62,7 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)  += board-omap3pandora.o 
\
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
   mmc-twl4030.o
-
+obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o \
   board-rx51-peripherals.o \
   mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
new file mode 100644
index 000..08d1c11
--- /dev/null
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -0,0 +1,307 @@
+/*
+ * linux/arch/arm/mach-omap2/board-n8x0.c
+ *
+ * Copyright (C) 2005-2007 Nokia Corporation
+ * Author: Juha Yrjola juha.yrj...@nokia.com
+ *
+ * Modified from mach-omap2/board-generic.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/stddef.h
+#include linux/spi/spi.h
+#include linux/usb/musb.h
+
+#include asm/mach/arch.h
+#include asm/mach-types.h
+
+#include mach/board.h
+#include mach/common.h
+#include mach/gpio.h
+#include mach/io.h
+#include mach/irqs.h
+#include mach/mcspi.h
+#include mach/onenand.h
+#include mach/serial.h
+
+#define TUSB_ASYNC_CS  1
+#define TUSB_SYNC_CS   4
+#define GPIO_TUSB_INT  58
+#define GPIO_TUSB_ENABLE   0
+
+#if defined(CONFIG_USB_MUSB_OTG)
+#define BOARD_MODE MUSB_OTG
+#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
+#define BOARD_MODE MUSB_PERIPHERAL
+#else /* defined(CONFIG_USB_MUSB_HOST) */
+#define BOARD_MODE MUSB_HOST
+#endif
+
+/*
+ * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
+ * 1.5 V voltage regulators of PM companion chip. Companion chip will then
+ * provide then PGOOD signal to TUSB6010 which will release it from reset.
+ */
+static int tusb_set_power(int state)
+{
+   int i, retval = 0;
+
+   if (state) {
+   gpio_set_value(GPIO_TUSB_ENABLE, 1);
+   msleep(1);
+
+   /* Wait until TUSB6010 pulls INT pin down */
+   i = 100;
+   while (i  gpio_get_value(GPIO_TUSB_INT)) {
+   msleep(1);
+   i--;
+   }
+
+   if (!i) {
+   printk(KERN_ERR tusb: powerup failed\n);
+   retval = -ENODEV;
+   }
+   } else {
+   gpio_set_value(GPIO_TUSB_ENABLE, 0);
+   msleep(10);
+   }
+
+   return retval;
+}
+
+static int osc_ck_on;
+
+static int tusb_set_clock(struct clk *osc_ck, int state)
+{
+   if (state) {
+   if (osc_ck_on  0)
+   return -ENODEV;
+
+   clk_enable(osc_ck);
+   osc_ck_on = 1;
+   } else {
+   if (osc_ck_on == 0)
+   return -ENODEV;
+
+   clk_disable(osc_ck);
+   osc_ck_on = 0;
+   }
+
+   return 0;
+}
+
+static struct musb_hdrc_eps_bits musb_eps[] = {
+   {   ep1_tx, 5,},
+   {   ep1_rx, 5,},
+   {   ep2_tx, 5,},
+   {   ep2_rx, 5,},
+   {   ep3_tx, 3,},
+   {   ep3_rx, 3,},
+   {   ep4_tx, 3,},
+   {   ep4_rx, 3,},
+   {   ep5_tx, 2,},
+   {   ep5_rx, 2,},
+   {   ep6_tx, 2,},
+   {   ep6_rx, 2,},
+   {   ep7_tx, 2,},
+   {   ep7_rx, 2,},
+   {   ep8_tx, 2,},
+   {   ep8_rx, 2,},
+   {   ep9_tx, 2,},
+   {   ep9_rx, 2,},
+   {   ep10_tx, 2,   },
+   {   ep10_rx, 2,   },
+   {   ep11_tx, 2,   },
+   {   ep11_rx, 2,   },
+   { 

[PATCH 2/2] n8x0: add n8x0_defconfig

[Kalle Valo]

Signed-off-by: Kalle Valo kalle.v...@iki.fi
---

 arch/arm/configs/n8x0_defconfig | 1104 +++
 1 files changed, 1104 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/n8x0_defconfig

diff --git a/arch/arm/configs/n8x0_defconfig b/arch/arm/configs/n8x0_defconfig
new file mode 100644
index 000..8da75de
--- /dev/null
+++ b/arch/arm/configs/n8x0_defconfig
@@ -0,0 +1,1104 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.31-rc5
+# Thu Aug  6 22:17:23 2009
+#
+CONFIG_ARM=y
+CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+CONFIG_GENERIC_GPIO=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_HARDIRQS_SW_RESEND=y
+CONFIG_GENERIC_IRQ_PROBE=y
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
+CONFIG_VECTORS_BASE=0x
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+CONFIG_CONSTRUCTORS=y
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+# CONFIG_CLASSIC_RCU is not set
+CONFIG_TREE_RCU=y
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_RCU_TRACE is not set
+CONFIG_RCU_FANOUT=32
+# CONFIG_RCU_FANOUT_EXACT is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_GROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
+# CONFIG_SYSFS_DEPRECATED_V2 is not set
+# CONFIG_RELAY is not set
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_RD_GZIP=y
+CONFIG_RD_BZIP2=y
+CONFIG_RD_LZMA=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
+# CONFIG_EMBEDDED is not set
+CONFIG_UID16=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+
+#
+# Performance Counters
+#
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_STRIP_ASM_SYMS is not set
+CONFIG_COMPAT_BRK=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+# CONFIG_MARKERS is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_SLOW_WORK is not set
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_BLOCK=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+# CONFIG_IOSCHED_AS is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_IOSCHED_CFQ=y
+# CONFIG_DEFAULT_AS is not set
+# CONFIG_DEFAULT_DEADLINE is not set
+CONFIG_DEFAULT_CFQ=y
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=cfq
+# CONFIG_FREEZER is not set
+
+#
+# System Type
+#
+# CONFIG_ARCH_AAEC2000 is not set
+# CONFIG_ARCH_INTEGRATOR is not set
+# CONFIG_ARCH_REALVIEW is not set
+# CONFIG_ARCH_VERSATILE is not set
+# CONFIG_ARCH_AT91 is not set
+# CONFIG_ARCH_CLPS711X is not set
+# CONFIG_ARCH_GEMINI is not set
+# CONFIG_ARCH_EBSA110 is not set
+# CONFIG_ARCH_EP93XX is not set
+# CONFIG_ARCH_FOOTBRIDGE is not set
+# CONFIG_ARCH_MXC is not set
+# CONFIG_ARCH_STMP3XXX is not set
+# CONFIG_ARCH_NETX is not set
+# CONFIG_ARCH_H720X is not set
+# CONFIG_ARCH_IOP13XX is not set
+# CONFIG_ARCH_IOP32X is not set
+# CONFIG_ARCH_IOP33X is not set
+# CONFIG_ARCH_IXP23XX is not set
+# CONFIG_ARCH_IXP2000 is not set
+# CONFIG_ARCH_IXP4XX is not set
+# CONFIG_ARCH_L7200 is not set
+# CONFIG_ARCH_KIRKWOOD is not set
+# CONFIG_ARCH_LOKI is not set
+# CONFIG_ARCH_MV78XX0 is not set
+# CONFIG_ARCH_ORION5X is not set
+# CONFIG_ARCH_MMP is not set
+# CONFIG_ARCH_KS8695 is not set
+# CONFIG_ARCH_NS9XXX is not set
+# CONFIG_ARCH_W90X900 is not set
+# CONFIG_ARCH_PNX4008 is not set
+# CONFIG_ARCH_PXA is not set
+# CONFIG_ARCH_MSM is not set
+# CONFIG_ARCH_RPC is not set
+# CONFIG_ARCH_SA1100 is not set
+# 

Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eduardo Valentin]

Hello guys,

On Thu, Aug 06, 2009 at 08:15:40PM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu) 
wrote:
 
 
  I would say the default mode for the omap34xx should be also element as
  it keeps the omap_pcm_pointer behavior the same than currently and
  avoids possible regression.
  
  Yes, the default mode should be the element mode in my opinion as well.
  
  --
  Péter
 
 
 Well, the element mode is fine for !McBSP2. One doesn't really loose the
 buffer pointer accuracy, because you can get the last DMA irq timestamp
 with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time).
 The accuracy is not far off from the element mode? (If you read the DMA
 portion of TRM, I think there were some issues as well)
 
 Don't want to be piccy, but McBSP2 with element mode is more or less like
 a joke? As there's a large HW bugger, why not take advantage of it..why 
 bypass  it as default?
 
 For !McBSP2, it doesn't even pay to have the threshold mode at all, because
 the effect on PM is actually adverse - too frequent wakeups will cause more
 adverse net effect on PM (IIRC) @ VBAT.

I agree with Eero in this point. We can set mcbsp2 default op mode to threshold.

I think we are even here :) two believe that must be element mode by default,
while two want default threshold (at least for mcbsp2). We need another opinion.

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

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

Re: MMC3 Overo

[Steve Sakoman]

On Fri, Aug 7, 2009 at 2:55 AM, Tony Lindgrent...@atomide.com wrote:

 Well we need to mux all the pins that can potentially conflict only in the
 board-*.c files.

 For naming, I think we should use the default mode0 name in the mux register 
 as the
 key, and then link package specific pin names to that key. The pin names are
 very handy to see for debugging at least.

I like that approach - it matches the method in the documentation
tables (i.e. unique pin name is the mode 0 function).

 Another thing to consider is if we want to support dynamic muxing. That means
 we need to keep the mux tables in the memory.

Dynamic muxing would be very nice.  It is required if we ever want to
do card detect with microSD cards.

 Or do init time muxing in board-*.c files, then re-register the pins needed 
 for
 dynamic muxing in board-*.c files. That way most of the mux data can be 
 __initdata,
 and only the pins that have been registered for dynamic muxing need to be kept
 in the memory.

This sounds good too.

Reagrds,

Steve
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP: remove OMAP_TAG_UART

[Roger Quadros]

ext Kalle Valo wrote:

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


Omap tags are deprecrated and convert all OMAP_TAG_UART cases to use
omap_uart_platform_data instead.

Tested on rx51 and n8x0. Compile tested on omap_osk_5912.

Signed-off-by: Kalle Valo kalle.v...@iki.fi

Any plans to remove OMAP_TAG_LCD


I don't have any plans, but I don't know about others.



I'm working on getting rid off OMAP_TAG_LCD. Will post a patch soon.

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

RE: [PATCH 2/2] OMAP: remove OMAP_TAG_UART

[Pandita, Vikram]

From: Roger Quadros [mailto:ext-roger.quad...@nokia.com]
 Signed-off-by: Kalle Valo kalle.v...@iki.fi
 Any plans to remove OMAP_TAG_LCD

 I don't have any plans, but I don't know about others.


I'm working on getting rid off OMAP_TAG_LCD. Will post a patch soon.

Sounds great. Looking forward.


-roger

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

Re: [PATCH 1/2] Add support for Nokia N800

[Felipe Balbi]

Hi,

On Fri, Aug 07, 2009 at 03:06:11PM +0200, ext Kalle Valo wrote:
 Signed-off-by: Kalle Valo kalle.v...@iki.fi
 ---
 
  arch/arm/mach-omap2/Kconfig  |4 
  arch/arm/mach-omap2/Makefile |2 
  arch/arm/mach-omap2/board-n8x0.c |  307 
 ++
  3 files changed, 312 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/board-n8x0.c
 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index bf54686..75b1c7e 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -73,6 +73,10 @@ config MACH_OMAP_3430SDP
   bool OMAP 3430 SDP board
   depends on ARCH_OMAP3  ARCH_OMAP34XX
  
 +config MACH_NOKIA_N8X0
 + bool Nokia N800/N810
 + depends on ARCH_OMAP2420
 +
  config MACH_NOKIA_RX51
   bool Nokia RX-51 board
   depends on ARCH_OMAP3  ARCH_OMAP34XX
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 757c84b..8850a24 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -62,7 +62,7 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o 
 \
  mmc-twl4030.o
  obj-$(CONFIG_MACH_OMAP_3430SDP)  += board-3430sdp.o \
  mmc-twl4030.o
 -
 +obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
  obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \
  board-rx51-peripherals.o \
  mmc-twl4030.o
 diff --git a/arch/arm/mach-omap2/board-n8x0.c 
 b/arch/arm/mach-omap2/board-n8x0.c
 new file mode 100644
 index 000..08d1c11
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-n8x0.c
 @@ -0,0 +1,307 @@
 +/*
 + * linux/arch/arm/mach-omap2/board-n8x0.c
 + *
 + * Copyright (C) 2005-2007 Nokia Corporation

2005-2009

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

Re: [PATCH] MAINTAINERS: Add list entries linux-...@vger.kernel.org and linux-arm-kernel@ to OMAP sections

[Joe Perches]

On Fri, 2009-08-07 at 11:01 +0300, Tony Lindgren wrote:
 * Joe Perches j...@perches.com [090806 19:35]:
  Perhaps it's useful for OMAP patches and bug reports
  to CC entries to the primary and secondary ARM lists.
  Added a pattern entry for OMAP USB as well.
 ... I think let's not add the drivers. The related driver list
 and linux-omap list should be enough for these.

Fine by me.  I fixed up your M: entry as well.

Signed-off-by: Joe Perches j...@perches.com

diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..6a82733 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3660,8 +3660,10 @@ F:   drivers/video/riva/
 F: drivers/video/nvidia/
 
 OMAP SUPPORT
-M: Tony Lindgren t...@atomide.com t...@atomide.com
+M: Tony Lindgren t...@atomide.com
 L: linux-omap@vger.kernel.org
+L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
+L: linux-...@vger.kernel.org
 W: http://www.muru.com/linux/omap/
 W: http://linux.omap.com/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
@@ -3671,12 +3673,16 @@ F:  arch/arm/*omap*
 OMAP CLOCK FRAMEWORK SUPPORT
 M: Paul Walmsley p...@pwsan.com
 L: linux-omap@vger.kernel.org
+L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
+L: linux-...@vger.kernel.org
 S: Maintained
 F: arch/arm/*omap*/*clock*
 
 OMAP POWER MANAGEMENT SUPPORT
 M: Kevin Hilman khil...@deeprootsystems.com
 L: linux-omap@vger.kernel.org
+L: linux-arm-ker...@lists.arm.linux.org.uk (subscribers-only)
+L: linux-...@vger.kernel.org
 S: Maintained
 F: arch/arm/*omap*/*pm*
 


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

[Resend][PATCH] Maintainers update for hsmmc driver

[Madhusudhan Chikkature]

Hi,

Resending the patch after changing omap_hs* to omap_hsmmc.c.

Regards,
Madhu



Update maintainers entry for TI OMAP HS MMC support.

Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
 MAINTAINERS |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: linux-omap-2.6/MAINTAINERS
===
--- linux-omap-2.6.orig/MAINTAINERS
+++ linux-omap-2.6/MAINTAINERS
@@ -3698,7 +3698,13 @@ OMAP MMC SUPPORT
 M: Jarkko Lavinen jarkko.lavi...@nokia.com
 L: linux-omap@vger.kernel.org
 S: Maintained
-F: drivers/mmc/host/*omap*
+F: drivers/mmc/host/omap.c
+
+OMAP HS MMC SUPPORT
+M: Madhusudhan Chikkature madhu...@ti.com
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: drivers/mmc/host/omap_hsmmc.c

 OMAP RANDOM NUMBER GENERATOR SUPPORT
 M: Deepak Saxena dsax...@plexity.net


--
To unsubscribe from this list: send the line unsubscribe 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/8] Adding TI TPS PMICs support in the regulator framework

[Anuj Aggarwal]

This patch set adds support for TI TPS65023 and TPS6507x PMICs in the voltage
regulator framework. It also creates a common board-omap35x-pmic.c file which
has the board related information for the TPS devices for the OMAP35x platforms.

The patches also take care of the comments received earlier when only TPS65023
regulator driver was submitted.

The earlier discussions can be found at:

 [1] Add pmic.c file to regulator framework
 http://marc.info/?l=linux-omapm=124265188617999w=2

 [2] Add TPS65023 Regulator Driver
 http://marc.info/?l=linux-omapm=124181108318242w=2

 [3] Added board-dependent code for TPS65023
 http://marc.info/?l=linux-omapm=124264951114318w=2

Anuj Aggarwal (8):
  Regulator: Add TPS65023 regulator driver
  Regulator: Adding header file for TPS65023
  Regulator: Add TPS6507x regulator driver
  Regulator: Adding header file for TI TPS6507x regulator driver
  Regulator: Adding TPS65023 and TPS6507x in Kconfig and Makefile
  Regulator: Add board-omap35x-pmic.c to arch/arm/mach-omap2/
  Regulator: Added board-dependent code for TPS65023
  Regulator: Added board-dependent code for TPS65073

 arch/arm/mach-omap2/board-omap35x-pmic.c |  305 
 drivers/regulator/Kconfig|   16 +
 drivers/regulator/Makefile   |2 +
 drivers/regulator/tps65023-regulator.c   |  496 ++
 drivers/regulator/tps6507x-regulator.c   |  563 ++
 include/linux/mfd/tps6507x.h |   93 +
 include/linux/regulator/tps65023.h   |   74 
 7 files changed, 1549 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap35x-pmic.c
 create mode 100644 drivers/regulator/tps65023-regulator.c
 create mode 100644 drivers/regulator/tps6507x-regulator.c
 create mode 100644 include/linux/mfd/tps6507x.h
 create mode 100644 include/linux/regulator/tps65023.h

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

[PATCH 1/8] Regulator: Add TPS65023 regulator driver

[Anuj Aggarwal]

Adding support for TI TPS65023 regulator driver

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 drivers/regulator/tps65023-regulator.c |  496 
 1 files changed, 496 insertions(+), 0 deletions(-)
 create mode 100644 drivers/regulator/tps65023-regulator.c

diff --git a/drivers/regulator/tps65023-regulator.c 
b/drivers/regulator/tps65023-regulator.c
new file mode 100644
index 000..d112cbc
--- /dev/null
+++ b/drivers/regulator/tps65023-regulator.c
@@ -0,0 +1,496 @@
+/*
+ * tps65023-regulator.c
+ *
+ * Supports TPS65023 Regulator
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/regulator/tps65023.h
+
+struct tps_info {
+   const char *name;
+   unsigned min_uV;
+   unsigned max_uV;
+   bool fixed;
+   u8 table_len;
+   const u16 *table;
+};
+
+struct tps_pmic {
+   struct regulator_desc desc[TPS65023_NUM_REGULATOR];
+   struct i2c_client *client;
+   struct regulator_dev *rdev[TPS65023_NUM_REGULATOR];
+   const struct tps_info *info[TPS65023_NUM_REGULATOR];
+};
+
+static inline int tps_65023_read_reg(struct tps_pmic *tps, u8 reg, u8 *val)
+{
+   int status;
+
+   status = i2c_smbus_read_byte_data(tps-client, reg);
+   *val = status;
+   if (status  0)
+   return status;
+   return 0;
+}
+
+static inline int tps_65023_write_reg(struct tps_pmic *tps, u8 reg, u8 val)
+{
+   return i2c_smbus_write_byte_data(tps-client, reg, val);
+}
+
+static int tps_65023_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+{
+   u8 data;
+   int err;
+
+   err = tps_65023_read_reg(tps, reg, data);
+   if (err) {
+   pr_err(Read from reg 0x%x failed\n, reg);
+   return err;
+   }
+
+   data |= mask;
+
+   return tps_65023_write_reg(tps, reg, data);
+}
+
+static int tps_65023_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+{
+   u8 data;
+   int err;
+
+   err = tps_65023_read_reg(tps, reg, data);
+   if (err) {
+   pr_err(Read from reg 0x%x failed\n, reg);
+   return err;
+   }
+
+   data = ~mask;
+
+   return tps_65023_write_reg(tps, reg, data);
+}
+
+static int tps65023_dcdc_is_enabled(struct regulator_dev *dev)
+{
+   unsigned char reg_ctrl;
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   int ret;
+   u8 shift;
+
+   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS65023_NUM_REGULATOR - dcdc;
+   ret = tps_65023_read_reg(tps, TPS65023_REG_REG_CTRL, reg_ctrl);
+
+   if (ret == 0) {
+   reg_ctrl = (1  shift);
+   return reg_ctrl ? 1 : 0;
+   } else
+   return ret;
+}
+
+static int tps65023_ldo_is_enabled(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int ldo = rdev_get_id(dev);
+   int ret;
+   u8 shift;
+   unsigned char reg_ctrl;
+
+   if (ldo  TPS65023_LDO_1 || ldo  TPS65023_LDO_2)
+   return -EINVAL;
+
+   shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
+   ret = tps_65023_read_reg(tps, TPS65023_REG_REG_CTRL, reg_ctrl);
+
+   if (ret == 0) {
+   reg_ctrl = (1  shift);
+   return reg_ctrl ? 1 : 0;
+   } else
+   return ret;
+}
+
+static int tps65023_dcdc_enable(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   u8 shift;
+
+   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS65023_NUM_REGULATOR - dcdc;
+   return tps_65023_set_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
+}
+
+static int tps65023_dcdc_disable(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   u8 shift;
+
+   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS65023_NUM_REGULATOR - dcdc;
+   return tps_65023_clear_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
+}
+
+static int tps65023_ldo_enable(struct regulator_dev *dev)
+{
+   struct tps_pmic 

[PATCH 2/8] Regulator: Adding header file for TPS65023

[Anuj Aggarwal]

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 include/linux/regulator/tps65023.h |   74 
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/regulator/tps65023.h

diff --git a/include/linux/regulator/tps65023.h 
b/include/linux/regulator/tps65023.h
new file mode 100644
index 000..6afba6c
--- /dev/null
+++ b/include/linux/regulator/tps65023.h
@@ -0,0 +1,74 @@
+/*
+ * tps65023.h
+ *
+ * Header file for TI TPS65023 Regulator
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+/* Register definitions */
+#defineTPS65023_REG_VERSION0
+#defineTPS65023_REG_PGOODZ 1
+#defineTPS65023_REG_MASK   2
+#defineTPS65023_REG_REG_CTRL   3
+#defineTPS65023_REG_CON_CTRL   4
+#defineTPS65023_REG_CON_CTRL2  5
+#defineTPS65023_REG_DEF_CORE   6
+#defineTPS65023_REG_DEFSLEW7
+#defineTPS65023_REG_LDO_CTRL   8
+
+/* PGOODZ bitfields */
+#defineTPS65023_PGOODZ_PWRFAILZBIT(7)
+#defineTPS65023_PGOODZ_LOWBATTZBIT(6)
+#defineTPS65023_PGOODZ_VDCDC1  BIT(5)
+#defineTPS65023_PGOODZ_VDCDC2  BIT(4)
+#defineTPS65023_PGOODZ_VDCDC3  BIT(3)
+#defineTPS65023_PGOODZ_LDO2BIT(2)
+#defineTPS65023_PGOODZ_LDO1BIT(1)
+
+/* MASK bitfields */
+#defineTPS65023_MASK_PWRFAILZ  BIT(7)
+#defineTPS65023_MASK_LOWBATTZ  BIT(6)
+#defineTPS65023_MASK_VDCDC1BIT(5)
+#defineTPS65023_MASK_VDCDC2BIT(4)
+#defineTPS65023_MASK_VDCDC3BIT(3)
+#defineTPS65023_MASK_LDO2  BIT(2)
+#defineTPS65023_MASK_LDO1  BIT(1)
+
+/* REG_CTRL bitfields */
+#define TPS65023_REG_CTRL_VDCDC1_ENBIT(5)
+#define TPS65023_REG_CTRL_VDCDC2_ENBIT(4)
+#define TPS65023_REG_CTRL_VDCDC3_ENBIT(3)
+#define TPS65023_REG_CTRL_LDO2_EN  BIT(2)
+#define TPS65023_REG_CTRL_LDO1_EN  BIT(1)
+
+/* LDO_CTRL bitfields */
+#define TPS65023_LDO_CTRL_LDOx_SHIFT(ldo_id)   ((ldo_id)*4)
+#define TPS65023_LDO_CTRL_LDOx_MASK(ldo_id)(0xF0  ((ldo_id)*4))
+
+/* Number of step-down converters available */
+#define TPS65023_NUM_DCDC  3
+/* Number of LDO voltage regulators  available */
+#define TPS65023_NUM_LDO   2
+/* Number of total regulators available */
+#define TPS65023_NUM_REGULATOR (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
+
+/* DCDC's */
+#define TPS65023_DCDC_10
+#define TPS65023_DCDC_21
+#define TPS65023_DCDC_32
+/* LDOs */
+#define TPS65023_LDO_1 3
+#define TPS65023_LDO_2 4
+
+#define TPS65023_MAX_REG_IDTPS65023_LDO_2
+
-- 
1.6.2.4

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

[PATCH 3/8] Regulator: Add TPS6507x regulator driver

[Anuj Aggarwal]

Adding support for TI TPS6507x regulator driver

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 drivers/regulator/tps6507x-regulator.c |  563 
 1 files changed, 563 insertions(+), 0 deletions(-)
 create mode 100644 drivers/regulator/tps6507x-regulator.c

diff --git a/drivers/regulator/tps6507x-regulator.c 
b/drivers/regulator/tps6507x-regulator.c
new file mode 100644
index 000..c5e319c
--- /dev/null
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -0,0 +1,563 @@
+/*
+ * tps6507x-regulator.c
+ *
+ * Regulator driver for TPS65073 PMIC
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/mfd/tps6507x.h
+#include linux/i2c.h
+#include linux/delay.h
+
+struct tps_info {
+   const char *name;
+   unsigned min_uV;
+   unsigned max_uV;
+   bool fixed;
+   u8 table_len;
+   const u16 *table;
+};
+
+struct tps_pmic {
+   struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
+   struct i2c_client *client;
+   struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
+   struct tps_info *info[TPS6507X_NUM_REGULATOR];
+};
+
+static inline int tps_6507x_read_reg(struct tps_pmic *tps, u8 reg, u8 *val)
+{
+   int status;
+
+   status = i2c_smbus_read_byte_data(tps-client, reg);
+   *val = status;
+   if (status  0)
+   return status;
+   return 0;
+}
+
+static inline int tps_6507x_write_reg(struct tps_pmic *tps, u8 reg, u8 val)
+{
+   return i2c_smbus_write_byte_data(tps-client, reg, val);
+}
+
+static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+{
+   u8 data;
+   int err;
+
+   err = tps_6507x_read_reg(tps, reg, data);
+   if (err) {
+   pr_err(Read from reg 0x%x failed\n, reg);
+   return err;
+   }
+
+   data |= mask;
+
+   return tps_6507x_write_reg(tps, reg, data);
+}
+
+static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+{
+   u8 data;
+   int err;
+
+   err = tps_6507x_read_reg(tps, reg, data);
+   if (err) {
+   pr_err(Read from reg 0x%x failed\n, reg);
+   return err;
+   }
+
+   data = ~mask;
+
+   return tps_6507x_write_reg(tps, reg, data);
+}
+
+static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   int ret;
+   u8 shift;
+   unsigned char reg_ctrl;
+
+   if (dcdc  TPS6507X_DCDC_1 || dcdc  TPS6507X_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS6507X_MAX_REG_ID - dcdc;
+   ret = tps_6507x_read_reg(tps, TPS6507X_REG_CON_CTRL1, reg_ctrl);
+
+   if (ret == 0) {
+   reg_ctrl = (1  shift);
+   return reg_ctrl ? 1 : 0;
+   } else
+   return ret;
+}
+
+static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int ldo = rdev_get_id(dev);
+   int ret;
+   u8 shift;
+   unsigned char reg_ctrl;
+
+   if (ldo  TPS6507X_LDO_1 || ldo  TPS6507X_LDO_2)
+   return -EINVAL;
+
+   shift = TPS6507X_MAX_REG_ID - ldo;
+   ret = tps_6507x_read_reg(tps, TPS6507X_REG_CON_CTRL1, reg_ctrl);
+
+   if (ret == 0) {
+   reg_ctrl = (1  shift);
+   return reg_ctrl ? 1 : 0;
+   } else
+   return ret;
+}
+
+static int tps6507x_dcdc_enable(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   u8 shift;
+
+   if (dcdc  TPS6507X_DCDC_1 || dcdc  TPS6507X_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS6507X_MAX_REG_ID - dcdc;
+   return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1  shift);
+}
+
+static int tps6507x_dcdc_disable(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = rdev_get_drvdata(dev);
+   int dcdc = rdev_get_id(dev);
+   u8 shift;
+
+   if (dcdc  TPS6507X_DCDC_1 || dcdc  TPS6507X_DCDC_3)
+   return -EINVAL;
+
+   shift = TPS6507X_MAX_REG_ID - dcdc;
+   return tps_6507x_clear_bits(tps, TPS6507X_REG_CON_CTRL1, 1  shift);
+}
+
+static int tps6507x_ldo_enable(struct regulator_dev *dev)
+{
+   struct tps_pmic *tps = 

[PATCH 4/8] Regulator: Adding header file for TI TPS6507x regulator driver

[Anuj Aggarwal]

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 include/linux/mfd/tps6507x.h |   93 ++
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/mfd/tps6507x.h

diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
new file mode 100644
index 000..069b02a
--- /dev/null
+++ b/include/linux/mfd/tps6507x.h
@@ -0,0 +1,93 @@
+/*
+ * tps6507x.h
+ *
+ * Header file for TI TPS6507x Regulators
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+/* Register definitions */
+#defineTPS6507X_REG_PPATH1 0X01
+#defineTPS6507X_REG_INT0X02
+#defineTPS6507X_REG_CHGCONFIG0 0X03
+#defineTPS6507X_REG_CHGCONFIG1 0X04
+#defineTPS6507X_REG_CHGCONFIG2 0X05
+#defineTPS6507X_REG_CHGCONFIG3 0X06
+#defineTPS6507X_REG_REG_ADCONFIG   0X07
+#defineTPS6507X_REG_TSCMODE0X08
+#defineTPS6507X_REG_ADRESULT_1 0X09
+#defineTPS6507X_REG_ADRESULT_2 0X0A
+#defineTPS6507X_REG_PGOOD  0X0B
+#defineTPS6507X_REG_PGOODMASK  0X0C
+#defineTPS6507X_REG_CON_CTRL1  0X0D
+#defineTPS6507X_REG_CON_CTRL2  0X0E
+#defineTPS6507X_REG_CON_CTRL3  0X0F
+#defineTPS6507X_REG_DEFDCDC1   0X10
+#defineTPS6507X_REG_DEFDCDC2_LOW   0X11
+#defineTPS6507X_REG_DEFDCDC2_HIGH  0X12
+#defineTPS6507X_REG_DEFDCDC3_LOW   0X13
+#defineTPS6507X_REG_DEFDCDC3_HIGH  0X14
+#defineTPS6507X_REG_DEFSLEW0X15
+#defineTPS6507X_REG_LDO_CTRL1  0X16
+#defineTPS6507X_REG_DEFLDO20X17
+#defineTPS6507X_REG_WLED_CTRL1 0X18
+#defineTPS6507X_REG_WLED_CTRL2 0X19
+
+/* CON_CTRL1 bitfields */
+#defineTPS6507X_CON_CTRL1_DCDC1_ENABLE BIT(4)
+#defineTPS6507X_CON_CTRL1_DCDC2_ENABLE BIT(3)
+#defineTPS6507X_CON_CTRL1_DCDC3_ENABLE BIT(2)
+#defineTPS6507X_CON_CTRL1_LDO1_ENABLE  BIT(1)
+#defineTPS6507X_CON_CTRL1_LDO2_ENABLE  BIT(0)
+
+/* DEFDCDC1 bitfields */
+#define TPS6507X_DEFDCDC1_DCDC1_EXT_ADJ_EN BIT(7)
+#define TPS6507X_DEFDCDC1_DCDC1_MASK   0X3F
+
+/* DEFDCDC2_LOW bitfields */
+#define TPS6507X_DEFDCDC2_LOW_DCDC2_MASK   0X3F
+
+/* DEFDCDC2_HIGH bitfields */
+#define TPS6507X_DEFDCDC2_HIGH_DCDC2_MASK  0X3F
+
+/* DEFDCDC3_LOW bitfields */
+#define TPS6507X_DEFDCDC3_LOW_DCDC3_MASK   0X3F
+
+/* DEFDCDC3_HIGH bitfields */
+#define TPS6507X_DEFDCDC3_HIGH_DCDC3_MASK  0X3F
+
+/* TPS6507X_REG_LDO_CTRL1 bitfields */
+#define TPS6507X_REG_LDO_CTRL1_LDO1_MASK   0X0F
+
+/* TPS6507X_REG_DEFLDO2 bitfields */
+#define TPS6507X_REG_DEFLDO2_LDO2_MASK 0X3F
+
+/* VDCDC MASK */
+#define TPS6507X_DEFDCDCX_DCDC_MASK0X3F
+
+/* DCDC's */
+#define TPS6507X_DCDC_10
+#define TPS6507X_DCDC_21
+#define TPS6507X_DCDC_32
+/* LDOs */
+#define TPS6507X_LDO_1 3
+#define TPS6507X_LDO_2 4
+
+#define TPS6507X_MAX_REG_IDTPS6507X_LDO_2
+
+/* Number of step-down converters available */
+#define TPS6507X_NUM_DCDC  3
+/* Number of LDO voltage regulators  available */
+#define TPS6507X_NUM_LDO   2
+/* Number of total regulators available */
+#define TPS6507X_NUM_REGULATOR (TPS6507X_NUM_DCDC + TPS6507X_NUM_LDO)
+
-- 
1.6.2.4

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

[PATCH 5/8] Regulator: Adding TPS65023 and TPS6507x in Kconfig and Makefile

[Anuj Aggarwal]

Adding TPS65023 and TPS6507x regulator driver support in
drivers/regulator/Makefile and drivers/regulator/Kconfig

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 drivers/regulator/Kconfig  |   16 
 drivers/regulator/Makefile |2 ++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f431779..5f5b587 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -117,4 +117,20 @@ config REGULATOR_LP3971
 Say Y here to support the voltage regulators and convertors
 on National Semiconductors LP3971 PMIC
 
+config REGULATOR_TPS65023
+   tristate TI TPS65023 Power regulators
+   depends on OMAP3EVM_TPS65023
+   help
+ This driver supports TPS65023 voltage regulator chips. TPS65023 
provides
+ three step-down converters and two general-purpose LDO voltage 
regulators.
+ It supports TI's software based Class-2 SmartReflex implementation.
+
+config REGULATOR_TPS65073
+   tristate TI TPS65073 Power regulators
+   depends on OMAP3EVM_TPS65073
+   help
+ This driver supports TPS65073 voltage regulator chips. TPS65073 
provides
+ three step-down converters and two general-purpose LDO voltage 
regulators.
+ It supports TI's software based Class-2 SmartReflex implementation.
+
 endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 4d762c4..3863e3d 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -16,5 +16,7 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
 obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65073) += tps6507x-regulator.o
 
 ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
-- 
1.6.2.4

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

[PATCH 7/8] Regulator: Added board-dependent code for TPS65023

[Anuj Aggarwal]

Added OMAP35x specific code for TPS65023 in board-omap35x-pmic.c

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 arch/arm/mach-omap2/board-omap35x-pmic.c |   93 +-
 1 files changed, 92 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap35x-pmic.c 
b/arch/arm/mach-omap2/board-omap35x-pmic.c
index 11db66f..0bf47fd 100644
--- a/arch/arm/mach-omap2/board-omap35x-pmic.c
+++ b/arch/arm/mach-omap2/board-omap35x-pmic.c
@@ -30,6 +30,96 @@
 /*
  * Definitions specific to TPS65023
  */
+#if defined(CONFIG_OMAP3EVM_TPS65023)
+/* MPU voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_mpu_consumers = {
+   .supply = vdd1,
+};
+
+/* CORE voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_core_consumers = {
+   .supply = vdd2,
+};
+
+/* SRAM/MEM/WKUP_BG voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_vdds_consumers = {
+   .supply = vdds,
+};
+
+/* DPLL voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_dpll_consumers = {
+   .supply = dpll,
+};
+
+/* MMC voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_mmc_consumers = {
+   .supply = mmc,
+};
+
+struct regulator_init_data tps65023_regulator_data[] = {
+   {
+   .constraints = {
+   .min_uV = 80,
+   .max_uV = 160,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65023_mpu_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 330,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65023_core_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 330,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65023_vdds_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 100,
+   .max_uV = 315,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65023_dpll_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 105,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65023_mmc_consumers,
+   },
+};
+
+static struct i2c_board_info __initdata board_tps65023_instances[] = {
+   {
+   I2C_BOARD_INFO(tps65023, 0x48),
+   .flags = I2C_CLIENT_WAKE,
+   .platform_data = tps65023_regulator_data[0],
+   },
+};
+#endif
 
 /*
  * Definitions specific to TPS65073
@@ -109,7 +199,8 @@ int oma35x_pmic_init(void)
 #endif
 
 #if defined(CONFIG_OMAP3EVM_TPS65023)
-   /* do stuff specific to TPS65023 */
+   omap_register_i2c_bus(1, 400, board_tps65023_instances,
+   ARRAY_SIZE(board_tps65023_instances));
 #endif
 
 #if defined(CONFIG_OMAP3EVM_TPS65073)
-- 
1.6.2.4

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

[PATCH 8/8] Regulator: Added board-dependent code for TPS65073

[Anuj Aggarwal]

Added OMAP35x specific code for TPS65073 in board-omap35x-pmic.c

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 arch/arm/mach-omap2/board-omap35x-pmic.c |   95 +-
 1 files changed, 94 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap35x-pmic.c 
b/arch/arm/mach-omap2/board-omap35x-pmic.c
index 0bf47fd..2c33965 100644
--- a/arch/arm/mach-omap2/board-omap35x-pmic.c
+++ b/arch/arm/mach-omap2/board-omap35x-pmic.c
@@ -124,6 +124,98 @@ static struct i2c_board_info __initdata 
board_tps65023_instances[] = {
 /*
  * Definitions specific to TPS65073
  */
+#if defined(CONFIG_OMAP3EVM_TPS65073)
+/* MPU voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65073_mpu_consumers = {
+   .supply = vdd1,
+};
+
+/* CORE voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65073_core_consumers = {
+   .supply = vdd2,
+};
+
+/* SRAM/MEM/WKUP_BG/VDDS voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65073_vdds_consumers = {
+   .supply = vdds,
+};
+
+/* DPLL voltage regulator of LDO type */
+struct regulator_consumer_supply tps65073_dpll_consumers = {
+   .supply = dpll,
+};
+
+/* MMC voltage regulator of LDO type */
+struct regulator_consumer_supply tps65073_mmc_consumers = {
+   .supply = mmc,
+};
+
+struct regulator_init_data tps65073_regulator_data[] = {
+   {
+   .constraints = {
+   .min_uV = 725000,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65073_vdds_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 725000,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65073_core_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 725000,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65073_mpu_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 100,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65073_dpll_consumers,
+   },
+   {
+   .constraints = {
+   .min_uV = 725000,
+   .max_uV = 330,
+   .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+   REGULATOR_CHANGE_STATUS),
+   .boot_on = 1,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = tps65073_mmc_consumers,
+   },
+};
+
+static struct i2c_board_info __initdata board_tps65073_instances[] = {
+   {
+   I2C_BOARD_INFO(tps6507x, 0x48),
+   .flags = I2C_CLIENT_WAKE,
+   .platform_data = tps65073_regulator_data[0],
+   },
+};
+#endif
 
 static int flag_pmic_twl4030;
 static int flag_pmic_tps6235x;
@@ -204,7 +296,8 @@ int oma35x_pmic_init(void)
 #endif
 
 #if defined(CONFIG_OMAP3EVM_TPS65073)
-   /* do stuff specific to TPS65073 */
+   omap_register_i2c_bus(1, 400, board_tps65073_instances,
+   ARRAY_SIZE(board_tps65073_instances));
 #endif
 
return 0;
-- 
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: [PATCH 1/8] Regulator: Add TPS65023 regulator driver

[Mark Brown]

On Fri, Aug 07, 2009 at 08:55:26PM +0530, Anuj Aggarwal wrote:

 +static int tps_65023_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 +{
 + u8 data;
 + int err;
 +
 + err = tps_65023_read_reg(tps, reg, data);
 + if (err) {
 + pr_err(Read from reg 0x%x failed\n, reg);
 + return err;
 + }
 +
 + data |= mask;
 +
 + return tps_65023_write_reg(tps, reg, data);
 +}

This and the clear_bits() function should use a lock to stop data
corruption if two simultaneous read/modify/write operations occur.  The
regulator framework doesn't stop two different regulators being updated
simultaneously.

 + if (min_uV  tps-info[dcdc]-min_uV 
 + || min_uV  tps-info[dcdc]-max_uV)
 + return -EINVAL;

Odd indentation for the or clause here and elsewhere.

 + for (vsel = 0; vsel  tps-info[dcdc]-table_len; vsel++) {
 + int mV = tps-info[dcdc]-table[vsel];
 + int uV = mV * 1000;
 +
 + /* Break at the first in-range value */
 + if (min_uV = uV  uV = max_uV)
 + break;
 + }
 +
 + /* write to the register */
 + return tps_65023_write_reg(tps, TPS65023_REG_DEF_CORE, vsel);

There should be a check after the for loop to make sure we actually
found a voltage - the min/max check earlier isn't enough since a
consumer could ask for a very narrow voltage range that the chip is
unable to generate.  For example, if 1.1V and 1.2V are supported a
request for exactly 1.15V would fail to match.

The same issue applies to the LDO.

 + ret = tps_65023_read_reg(tps, TPS65023_REG_LDO_CTRL, reg_ctrl);
 +
 + if (ret  0)
 + return ret;
 +
 + reg_ctrl = TPS65023_LDO_CTRL_LDOx_MASK(ldo - TPS65023_LDO_1);
 + reg_ctrl |= 
 + (vsel  (TPS65023_LDO_CTRL_LDOx_SHIFT(ldo - TPS65023_LDO_1)));
 + return tps_65023_write_reg(tps, TPS65023_REG_LDO_CTRL, reg_ctrl);

This will also have the locking issue I mentioned earlier with the set
bits operation.

 +/* Operations permitted on VDCDCx */
 +static struct regulator_ops tps65023_dcdc_ops = {
 + .is_enabled = tps65023_dcdc_is_enabled,
 + .enable = tps65023_dcdc_enable,
 + .disable = tps65023_dcdc_disable,
 + .get_voltage = tps65023_dcdc_get_voltage,
 + .set_voltage = tps65023_dcdc_set_voltage,

It'd be good to also implement list_voltage().

 + init_data, tps);
 + if (IS_ERR(rdev)) {
 + dev_err(client-dev, failed to register %s\n,
 + id-name);
 + kfree(tps);
 + return PTR_ERR(rdev);
 + }

This should go through and deallocate any regulators that were
succesfully allocated if it hits an error.

 +/* Supported voltage values for regulators */
 +static const u16 VDCDC1_VSEL_table[] = {

It'd feel more natural when reading the source if these tables were at
the top of the driver (so the reader knows they're there when going from
the top of the driver to the bottom) but that's just a personal
preference.

 +static const struct tps_info tps65023_regs[] = {
 + {
 + .name = VDCDC1,
 + .min_uV =  80,
 + .max_uV = 160,
 + .fixed = 0,
 + .table_len = ARRAY_SIZE(VDCDC1_VSEL_table),
 + .table = VDCDC1_VSEL_table,
 + },

Indentation here is a bit non-standard - I'd expect either the {} around
the elements to be in column 0 or another level of indentation for the
fields.

 + {
 + .name = VDCDC2,
 + .min_uV =  330,
 + .max_uV = 330,
 + .fixed = 1,
 + .table_len = 0,
 + },

You could drop the fixed flag and just have fixed be inferred from
min_uV == max_uV?

 +static struct i2c_driver tps_65023_i2c_driver = {
 + .driver = {
 + .name = tps_65023_pwr,
 + .owner = THIS_MODULE,
 + },

It'd be more natural to drop the _pwr from the name of the driver - most
I2C devices have a name which is just the chip name (and normally with
no _s too so tps65023).
--
To unsubscribe from this list: send the line unsubscribe 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/8] Regulator: Adding header file for TPS65023

[Mark Brown]

On Fri, Aug 07, 2009 at 08:55:36PM +0530, Anuj Aggarwal wrote:

This is OK but since you'll need to resubmit anyway it might be nice to
consider moving the register  bitfield definitions into the driver file
since they can't be used by any other code.

 +/* DCDC's */

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

Re: [PATCH 3/8] Regulator: Add TPS6507x regulator driver

[Mark Brown]

On Fri, Aug 07, 2009 at 08:56:06PM +0530, Anuj Aggarwal wrote:
 Adding support for TI TPS6507x regulator driver

Exactly which chips does this driver support?  Google tells me that at
least some of the parts in the TPS6507x range have functionality other
than regulator support on them like power path management and touch
which would mean that the drivers should be using the MFD framework to
hook in to the various subsystems unless the device presents as multiple
devices on the I2C bus.

Otherwise my comments here are essentially the same as for the previous
driver - it looks good but the same relatively minor issues apply.
--
To unsubscribe from this list: send the line unsubscribe 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/8] Regulator: Adding TPS65023 and TPS6507x in Kconfig and Makefile

[Mark Brown]

On Fri, Aug 07, 2009 at 08:59:20PM +0530, Anuj Aggarwal wrote:

 +config REGULATOR_TPS65023
 + tristate TI TPS65023 Power regulators
 + depends on OMAP3EVM_TPS65023
 + help

...

 +config REGULATOR_TPS65073
 + tristate TI TPS65073 Power regulators
 + depends on OMAP3EVM_TPS65073

These dependencies on the OMAP3EVM seem very wrong - the only dependency
I'd expect would be on I2C (or a MFD core for the .

Also, the Kconfig stuff says TPS65073 but the driver said it supported
the entire TPS6507x line.  I'd expect these to be consistent with each
other.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM: UART not resuming from OFF mode

[Kevin Hilman]

Roger Quadros ext-roger.quad...@nokia.com writes:

  I'm facing this strange problem since some days. I have 3 identical
 boards using OMAP3430 ES3.1 and I'm using Kevin's PM
 tree. 
 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm

 The problem is that UART3 fails to operate correctly after OFF mode on
 _two_ of the boards but works on one. It seems to receive characters
 but 0 only. So characters do not show up on terminal.

 Is anybody experiencing similar problems with UART and off mode on your 
 boards?

Is this after suspend-to-OFF or OFF-while-idle?

I've experienced this with UART1 on SDP ES3.0, but according to
Rajendra it didn't happen on SDP ES3.1 (I don't currently have any
ES3.1 hardware) :(

Are all of yours ES3.1 ?

I haven't tracked it further since I only saw it on my SDP with UART1
and not on any other board.

Kevin



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

RE: PM: UART not resuming from OFF mode

[Aguirre Rodriguez, Sergio Alberto]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Kevin Hilman
 Sent: Friday, August 07, 2009 11:21 AM
 To: Roger Quadros
 Cc: linux-omap@vger.kernel.org
 Subject: Re: PM: UART not resuming from OFF mode
 
 Roger Quadros ext-roger.quad...@nokia.com writes:
 
   I'm facing this strange problem since some days. I have 3 identical
  boards using OMAP3430 ES3.1 and I'm using Kevin's PM
  tree. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-
 pm.git;a=shortlog;h=pm
 
  The problem is that UART3 fails to operate correctly after OFF mode on
  _two_ of the boards but works on one. It seems to receive characters
  but 0 only. So characters do not show up on terminal.
 
  Is anybody experiencing similar problems with UART and off mode on your
 boards?
 
 Is this after suspend-to-OFF or OFF-while-idle?
 
 I've experienced this with UART1 on SDP ES3.0, but according to
 Rajendra it didn't happen on SDP ES3.1 (I don't currently have any
 ES3.1 hardware) :(
 
 Are all of yours ES3.1 ?

Could it be related to board encryption type (GP, EMU, HS)?

I'm not an expert on the topic, but I'm just throwing possible variants...

Regards,
Sergio
 
 I haven't tracked it further since I only saw it on my SDP with UART1
 and not on any other board.
 
 Kevin
 
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)

[Wang Limei-E12499]

Kevin,
 
I am using linux-omap pm-2.6.29
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=s
hortlog;h=pm-2.6.29  branch,found a dead lock condition in:
arch/arm/plat-omap/resource.c-resource_release().   
 
The dead lock happens when using resource_request(vdd1_opp,dev,...)
and resource_release(vdd1_opp, dev) to set and release vdd1 opp
constraint. The  scenario is:  
 
plat-omap/resource.c/resource_release(vdd1_opp,
dev)==resource.c/update_resource_level()=mach-omap2/resource34xx.c/se
t_opp().  In set_opp(),  if the target_level of vdd1 is less than
OPP3,will release the constraint set on VDD2 by calling
resource_release(), but it will never return because can not get the
mutex which is holding  by the previous caller. 
 
int resource_release(const char *name, struct device *dev)
{   ...
down(res_mutex);

/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
up(res_mutex);
return ret;
}

int set_opp(struct shared_resource *resp, u32 target_level)
{
.
 if (resp == vdd1_resp) {
  if (target_level  3)
   resource_release(vdd2_opp, vdd2_dev);
}
 
The patch to fix this issue is below, will you pls review it and let me
know your feedback?
 
From: Limei Wang e12...@motorola.com
Date: Fri, 7 Aug 2009 11:40:35 -0500
Subject: [PATCH] OMAP PM: Fix dead lock bug in
resourc_release(vdd1_opp).
 

Signed-off-by: Limei Wang e12...@motorola.com
---
 arch/arm/plat-omap/resource.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)
 
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..876fd12 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -418,10 +418,12 @@ int resource_release(const char *name, struct
device *dev)
list_del(user-node);
free_user(user);
 
-   /* Recompute and set the current level for the resource */
-   ret = update_resource_level(resp);
 res_unlock:
up(res_mutex);
+
+   /* Recompute and set the current level for the resource */
+   if (!ret)
+   ret = update_resource_level(resp);
return ret;
 }
 EXPORT_SYMBOL(resource_release);
--
1.5.6.3

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

Re: PM branch updated

[Kevin Hilman]

Jean Pihet jpi...@mvista.com writes:

 On Thursday 06 August 2009 19:13:06 Kevin Hilman wrote:
 Kevin Hilman wrote:
  I just pushed an updated PM branch which was rebased to current
  omap/master (which is based on v2.6.31-rc5)

 Also, please check out

http://elinux.org/OMAP_Power_Management

 This page includes the stuff I normally put in the announcment of a new
 PM branch, but also tries to describe how to use the various features of
 the PM branch (which has been sorely missing for a while.)

 I think this page had been long-awaited. Thanks a lot for putting it
 together.

 One question about it:

 What about the cpufreq interface for doing DVFS? Is it preferred way
 to change OPPs or is it using /sys/power/vddx_opp? I think cpufreq
 utils are more standard, easier to use and to understand.

CPUfreq is much preferred.  The /sys/power/vdd* are just for manual
testing and more fore PM developers than PM users.

Hey, sounds like a perfect opportunity for you to update the wiki. ;)

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

RE: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
 Peter Barada wrote:
  I'm running into a problem where the MUSB controller stops talking with
  the hardwired device on the other end, and I wasn to unload the musb as
  a module and reload it to the connection working again.
  
  I can compile MSUB as a module, but when I load it the 2nd time it
  complains with:
  
  OMAP-35x# modprobe musb_hdrc
  musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0
  musb_core_init 1421: reconfigure software for static FIFOs
  musb_hdrc musb_hdrc: musb_init_controller failed with status -19
  
  This is due to the platform device wanting dynamic fifo sizing but the
  CONFIGDATA register has DYNFIFO bit cleared.  Looking through the TRM, I
  can't find informaiton on how the MUSB controller changes the state of
  DYNFIFO - I'm guessing once any of the dynamic registers are written to
  that the controller switches to Dynamic Fifo sizing.
 
 This patch from Ajay (already in mainline) should fix it for you.
 
 http://marc.info/?l=linux-usbm=124881724122257w=2
 
 The problem is not that the CONFIGDATA changes, but that we attempt
 to read from CONFIGDATA without having set the INDEX register to 0.
 
 CONFIGDATA is a read-only register.

Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but
shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc
driver I don't see any USB devices downstream of the MUSB:

I have the following setup plugged in at boot(and left plugged in):

MUSB - OTG cable - Hub - thumbdrive

When I modprobe the driver the first time I get:

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=0
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty
musb-hcd
usb usb1: SerialNumber: musb_hdrc
usb 1-1: new high speed USB device using musb_hdrc and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc.
Bus 001 Device 001: ID 1d6b:0002
OMAP-35x#

Rmmod'ng the driver shows:

OMAP-35x# rmmod musb_hdrc
musb_hdrc musb_hdrc: remove, state 1
usb usb1: USB disconnect, address 1
usb 1-1: USB disconnect, address 2
musb_hdrc musb_hdrc: USB bus 1 deregistered

But modprobing the musb_hdrc driver a 2nd time shows:

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=0
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty
musb-hcd
usb usb1: SerialNumber: musb_hdrc
OMAP-35x#
OMAP-35x# lsusb
Bus 001 Device 001: ID 1d6b:0002

And it fails to find the hub or thumbdrive.

1) Any idea why I'd see -ETIMEDOUT from musb_hdrc on the first modprobe?

2) Any ideas why musb_hdrc finds the hub/thumbdrive on the first
modprobe, but not the 2nd?

3) I don't see any twl4030_usb interrupts from kernel boot - should I
see them?

Thanks in advance!

-- 
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question regarding MUSB and dynamic fifo sizing

[Pandita, Vikram]

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter
Barada
Sent: Friday, August 07, 2009 12:24 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: RE: Question regarding MUSB and dynamic fifo sizing

On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
 Peter Barada wrote:
  I'm running into a problem where the MUSB controller stops talking with
  the hardwired device on the other end, and I wasn to unload the musb as
  a module and reload it to the connection working again.
 
  I can compile MSUB as a module, but when I load it the 2nd time it
  complains with:
 
  OMAP-35x# modprobe musb_hdrc
  musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0
  musb_core_init 1421: reconfigure software for static FIFOs
  musb_hdrc musb_hdrc: musb_init_controller failed with status -19
 
  This is due to the platform device wanting dynamic fifo sizing but the
  CONFIGDATA register has DYNFIFO bit cleared.  Looking through the TRM, I
  can't find informaiton on how the MUSB controller changes the state of
  DYNFIFO - I'm guessing once any of the dynamic registers are written to
  that the controller switches to Dynamic Fifo sizing.

 This patch from Ajay (already in mainline) should fix it for you.

 http://marc.info/?l=linux-usbm=124881724122257w=2

 The problem is not that the CONFIGDATA changes, but that we attempt
 to read from CONFIGDATA without having set the INDEX register to 0.

 CONFIGDATA is a read-only register.

Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but
shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc
driver I don't see any USB devices downstream of the MUSB:

I have the following setup plugged in at boot(and left plugged in):

MUSB - OTG cable - Hub - thumbdrive

When I modprobe the driver the first time I get:

hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc.
Bus 001 Device 001: ID 1d6b:0002


Do things work fine without the hub for multiple insmod/rmmod?
Case = MUSB - OTG cable - thumbdrive

Is hub introducing some issue here looking at above logs?


--
To unsubscribe from this list: send the line unsubscribe 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/2] Add support for Nokia N800

[Kalle Valo]

Felipe Balbi felipe.ba...@nokia.com writes:

 +/*
 + * linux/arch/arm/mach-omap2/board-n8x0.c
 + *
 + * Copyright (C) 2005-2007 Nokia Corporation

 2005-2009

Thanks, I'll fix that in v2. I also noticed that patch description was
missing in both n8x0 patches, I'll write something.

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

RE: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Fri, 2009-08-07 at 22:55 +0530, Pandita, Vikram wrote:
 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter
 Barada
 Sent: Friday, August 07, 2009 12:24 PM
 To: Gadiyar, Anand
 Cc: linux-omap
 Subject: RE: Question regarding MUSB and dynamic fifo sizing
 
 On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
  Peter Barada wrote:
   I'm running into a problem where the MUSB controller stops talking with
   the hardwired device on the other end, and I wasn to unload the musb as
   a module and reload it to the connection working again.
  
   I can compile MSUB as a module, but when I load it the 2nd time it
   complains with:
  
   OMAP-35x# modprobe musb_hdrc
   musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0
   musb_core_init 1421: reconfigure software for static FIFOs
   musb_hdrc musb_hdrc: musb_init_controller failed with status -19
  
   This is due to the platform device wanting dynamic fifo sizing but the
   CONFIGDATA register has DYNFIFO bit cleared.  Looking through the TRM, I
   can't find informaiton on how the MUSB controller changes the state of
   DYNFIFO - I'm guessing once any of the dynamic registers are written to
   that the controller switches to Dynamic Fifo sizing.
 
  This patch from Ajay (already in mainline) should fix it for you.
 
  http://marc.info/?l=linux-usbm=124881724122257w=2
 
  The problem is not that the CONFIGDATA changes, but that we attempt
  to read from CONFIGDATA without having set the INDEX register to 0.
 
  CONFIGDATA is a read-only register.
 
 Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but
 shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc
 driver I don't see any USB devices downstream of the MUSB:
 
 I have the following setup plugged in at boot(and left plugged in):
 
 MUSB - OTG cable - Hub - thumbdrive
 
 When I modprobe the driver the first time I get:
 
 hub 1-1:1.0: hub_port_status failed (err = -110)
 hub 1-1:1.0: hub_port_status failed (err = -110)
 hub 1-1:1.0: hub_port_status failed (err = -110)
 hub 1-1:1.0: hub_port_status failed (err = -110)
 OMAP-35x# lsusb
 Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc.
 Bus 001 Device 001: ID 1d6b:0002
 
 
 Do things work fine without the hub for multiple insmod/rmmod?
 Case = MUSB - OTG cable - thumbdrive
 
 Is hub introducing some issue here looking at above logs?

Someting strange is going on.  If I boot with the MUSB-OTG adapter -
thumbdrive plugged in, and then modprobe the driver, it finds the
thumbdrive.  I can then remove/reinsert the OTG adapter - thumbdrive
multiple times, and each time it is enumerated.

If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the
musb driver, and then plug in the OTG adaptor -thumbdrive, it is not
enumerated.

Any idea why I need the OTG adapter - thumbdrive plugged in at kernel
boot for it to enumerate the thumbdrive?


-- 
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
 Someting strange is going on.  If I boot with the MUSB-OTG adapter -
 thumbdrive plugged in, and then modprobe the driver, it finds the
 thumbdrive.  I can then remove/reinsert the OTG adapter - thumbdrive
 multiple times, and each time it is enumerated.
 
 If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the
 musb driver, and then plug in the OTG adaptor -thumbdrive, it is not
 enumerated.
 
 Any idea why I need the OTG adapter - thumbdrive plugged in at kernel
 boot for it to enumerate the thumbdrive?

which board are you using ?

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

Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi all,

On OMAP3 we are creating a space for DSP components to have shared buffers 
using the boot arguments.

mem=...@0x8000 mem=1...@0x8800

This creates a 40M hole for DSP components, the drivers dynamically do a 
request mem region and ioremap of pre-defined address space with in the 40M 
region.

With the above setup, we see the system running for a while but then ends up 
with exception. 

Unable to handle kernel paging request at virtual address c7381000

The address reported here is not in kernel space, and this doesn't result in a 
kernel panic.

Other observation:
- The same setup works fine with no hole or space created. The 40M space for 
DSP components will be allocated at the end (216M).
- If we increase the mem hole region we can make the system fail with in less 
time.
- Free returns expected memory map

While I am still debugging the issue, I thought of posting this message to know 
if there are any known issues with ARM architecture in handling such non 
contiguous space / mem hole.

I see some special boot parameters for other architectures like exactmap, we 
don't see similar stuff on ARM. Do we need to port any such support for ARM ?

Kindly advice,

Thanks.

Regards,
Khasim

--
To unsubscribe from this list: send the line unsubscribe 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/8] Regulator: Add TPS65023 regulator driver

[Felipe Balbi]

Hi,

Adding linux-i2c to the loop.

On Fri, Aug 07, 2009 at 05:25:26PM +0200, ext Anuj Aggarwal wrote:
 +static inline int tps_65023_read_reg(struct tps_pmic *tps, u8 reg, u8 *val)
 +{
 +   int status;
 +
 +   status = i2c_smbus_read_byte_data(tps-client, reg);
 +   *val = status;
 +   if (status  0)
 +   return status;
 +   return 0;
 +}

make this:

static inline int tps_65023_read_reg(struct tps_pmic *tps, u8 reg)
{
   return i2c_smbus_read_byte_data(tps-client, reg);
}

ad change the users likewise.

 +static inline int tps_65023_write_reg(struct tps_pmic *tps, u8 reg, u8 val)
 +{
 +   return i2c_smbus_write_byte_data(tps-client, reg, val);
 +}
 +
 +static int tps_65023_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 +{
 +   u8 data;
 +   int err;
 +
 +   err = tps_65023_read_reg(tps, reg, data);

then this would become:

data = tps_65023_read_reg(tps, reg);
if (data  0) {
 +   if (err) {
 +   pr_err(Read from reg 0x%x failed\n, reg);

this should use dev_dbg(); you have a device struct inside the
i2c_client, use it.

 +   return err;
 +   }
 +
 +   data |= mask;
 +
 +   return tps_65023_write_reg(tps, reg, data);
 +}
 +
 +static int tps_65023_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 +{
 +   u8 data;
 +   int err;
 +
 +   err = tps_65023_read_reg(tps, reg, data);
 +   if (err) {

ditto

 +   pr_err(Read from reg 0x%x failed\n, reg);

ditto

 +   return err;
 +   }
 +
 +   data = ~mask;
 +
 +   return tps_65023_write_reg(tps, reg, data);
 +}
 +
 +static int tps65023_dcdc_is_enabled(struct regulator_dev *dev)
 +{
 +   unsigned char reg_ctrl;
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   int ret;
 +   u8 shift;
 +
 +   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
 +   return -EINVAL;
 +
 +   shift = TPS65023_NUM_REGULATOR - dcdc;
 +   ret = tps_65023_read_reg(tps, TPS65023_REG_REG_CTRL, reg_ctrl);
 +
 +   if (ret == 0) {
 +   reg_ctrl = (1  shift);
 +   return reg_ctrl ? 1 : 0;
 +   } else
 +   return ret;
 +}
 +
 +static int tps65023_ldo_is_enabled(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int ldo = rdev_get_id(dev);
 +   int ret;
 +   u8 shift;
 +   unsigned char reg_ctrl;
 +
 +   if (ldo  TPS65023_LDO_1 || ldo  TPS65023_LDO_2)
 +   return -EINVAL;
 +
 +   shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
 +   ret = tps_65023_read_reg(tps, TPS65023_REG_REG_CTRL, reg_ctrl);
 +
 +   if (ret == 0) {
 +   reg_ctrl = (1  shift);
 +   return reg_ctrl ? 1 : 0;
 +   } else
 +   return ret;
 +}
 +
 +static int tps65023_dcdc_enable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
 +   return -EINVAL;
 +
 +   shift = TPS65023_NUM_REGULATOR - dcdc;
 +   return tps_65023_set_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
 +}
 +
 +static int tps65023_dcdc_disable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
 +   return -EINVAL;
 +
 +   shift = TPS65023_NUM_REGULATOR - dcdc;
 +   return tps_65023_clear_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
 +}
 +
 +static int tps65023_ldo_enable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int ldo = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (ldo  TPS65023_LDO_1 || ldo  TPS65023_LDO_2)
 +   return -EINVAL;
 +
 +   shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
 +   return tps_65023_set_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
 +}
 +
 +static int tps65023_ldo_disable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int ldo = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (ldo  TPS65023_LDO_1 || ldo  TPS65023_LDO_2)
 +   return -EINVAL;
 +
 +   shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
 +   return tps_65023_clear_bits(tps, TPS65023_REG_REG_CTRL, 1  shift);
 +}
 +
 +static int tps65023_dcdc_get_voltage(struct regulator_dev *dev)
 +{
 +   unsigned char reg_ctrl;
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   int ret;
 +
 +   if (dcdc  TPS65023_DCDC_1 || dcdc  TPS65023_DCDC_3)
 +   return -EINVAL;
 +
 +   if (dcdc == TPS65023_DCDC_1) {
 +   ret = tps_65023_read_reg(tps, TPS65023_REG_DEF_CORE, 
 reg_ctrl);
 +   if (ret  0)
 +   return ret;
 +   

Re: [PATCH 2/8] Regulator: Adding header file for TPS65023

[Felipe Balbi]

On Fri, Aug 07, 2009 at 05:55:58PM +0200, ext Mark Brown wrote:
 On Fri, Aug 07, 2009 at 08:55:36PM +0530, Anuj Aggarwal wrote:
 
 This is OK but since you'll need to resubmit anyway it might be nice to
 consider moving the register  bitfield definitions into the driver file
 since they can't be used by any other code.
 
  +/* DCDC's */
 
 Extra ' here :)

I agree, there shouldn't be need for this file.

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

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

Re: [PATCH 3/8] Regulator: Add TPS6507x regulator driver

[Felipe Balbi]

On Fri, Aug 07, 2009 at 05:26:06PM +0200, ext Anuj Aggarwal wrote:
 Adding support for TI TPS6507x regulator driver
 
 Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
 ---
  drivers/regulator/tps6507x-regulator.c |  563 
 
  1 files changed, 563 insertions(+), 0 deletions(-)
  create mode 100644 drivers/regulator/tps6507x-regulator.c
 
 diff --git a/drivers/regulator/tps6507x-regulator.c 
 b/drivers/regulator/tps6507x-regulator.c
 new file mode 100644
 index 000..c5e319c
 --- /dev/null
 +++ b/drivers/regulator/tps6507x-regulator.c
 @@ -0,0 +1,563 @@
 +/*
 + * tps6507x-regulator.c
 + *
 + * Regulator driver for TPS65073 PMIC
 + *
 + * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
 + * whether express or implied; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + */
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/init.h
 +#include linux/err.h
 +#include linux/platform_device.h
 +#include linux/regulator/driver.h
 +#include linux/regulator/machine.h
 +#include linux/mfd/tps6507x.h
 +#include linux/i2c.h
 +#include linux/delay.h
 +
 +struct tps_info {
 +   const char *name;
 +   unsigned min_uV;
 +   unsigned max_uV;
 +   bool fixed;
 +   u8 table_len;
 +   const u16 *table;
 +};
 +
 +struct tps_pmic {
 +   struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
 +   struct i2c_client *client;
 +   struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
 +   struct tps_info *info[TPS6507X_NUM_REGULATOR];
 +};
 +
 +static inline int tps_6507x_read_reg(struct tps_pmic *tps, u8 reg, u8 *val)
 +{
 +   int status;
 +
 +   status = i2c_smbus_read_byte_data(tps-client, reg);
 +   *val = status;
 +   if (status  0)
 +   return status;
 +   return 0;

same comments as previous patch.

 +}
 +
 +static inline int tps_6507x_write_reg(struct tps_pmic *tps, u8 reg, u8 val)
 +{
 +   return i2c_smbus_write_byte_data(tps-client, reg, val);
 +}
 +
 +static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 +{
 +   u8 data;
 +   int err;
 +
 +   err = tps_6507x_read_reg(tps, reg, data);
 +   if (err) {
 +   pr_err(Read from reg 0x%x failed\n, reg);
 +   return err;
 +   }
 +
 +   data |= mask;
 +
 +   return tps_6507x_write_reg(tps, reg, data);
 +}
 +
 +static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 +{
 +   u8 data;
 +   int err;
 +
 +   err = tps_6507x_read_reg(tps, reg, data);
 +   if (err) {
 +   pr_err(Read from reg 0x%x failed\n, reg);
 +   return err;
 +   }
 +
 +   data = ~mask;
 +
 +   return tps_6507x_write_reg(tps, reg, data);
 +}
 +
 +static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   int ret;
 +   u8 shift;
 +   unsigned char reg_ctrl;
 +
 +   if (dcdc  TPS6507X_DCDC_1 || dcdc  TPS6507X_DCDC_3)
 +   return -EINVAL;
 +
 +   shift = TPS6507X_MAX_REG_ID - dcdc;
 +   ret = tps_6507x_read_reg(tps, TPS6507X_REG_CON_CTRL1, reg_ctrl);
 +
 +   if (ret == 0) {
 +   reg_ctrl = (1  shift);
 +   return reg_ctrl ? 1 : 0;
 +   } else
 +   return ret;
 +}
 +
 +static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int ldo = rdev_get_id(dev);
 +   int ret;
 +   u8 shift;
 +   unsigned char reg_ctrl;
 +
 +   if (ldo  TPS6507X_LDO_1 || ldo  TPS6507X_LDO_2)
 +   return -EINVAL;
 +
 +   shift = TPS6507X_MAX_REG_ID - ldo;
 +   ret = tps_6507x_read_reg(tps, TPS6507X_REG_CON_CTRL1, reg_ctrl);
 +
 +   if (ret == 0) {
 +   reg_ctrl = (1  shift);
 +   return reg_ctrl ? 1 : 0;
 +   } else
 +   return ret;
 +}
 +
 +static int tps6507x_dcdc_enable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (dcdc  TPS6507X_DCDC_1 || dcdc  TPS6507X_DCDC_3)
 +   return -EINVAL;
 +
 +   shift = TPS6507X_MAX_REG_ID - dcdc;
 +   return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1  shift);
 +}
 +
 +static int tps6507x_dcdc_disable(struct regulator_dev *dev)
 +{
 +   struct tps_pmic *tps = rdev_get_drvdata(dev);
 +   int dcdc = rdev_get_id(dev);
 +   u8 shift;
 +
 +   if (dcdc  TPS6507X_DCDC_1 || dcdc  

RE: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)

[Wang Limei-E12499]

 
Re-sent to linux-omap-ow...@vger.kernel.org. 

-Original Message-
From: Wang Limei-E12499 
Sent: Friday, August 07, 2009 12:05 PM
To: linux-omap@vger.kernel.org; Kevin Hilman
Cc: Wang Limei-E12499
Subject: Linux-omap PM: Fix dead lock condition in
resource_release(vdd1_opp)

Kevin,
 
I am using linux-omap pm-2.6.29
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=s
hortlog;h=pm-2.6.29  branch,found a dead lock condition in:
arch/arm/plat-omap/resource.c-resource_release().   
 
The dead lock happens when using resource_request(vdd1_opp,dev,...)
and resource_release(vdd1_opp, dev) to set and release vdd1 opp
constraint. The  scenario is:  
 
plat-omap/resource.c/resource_release(vdd1_opp,
dev)==resource.c/update_resource_level()=mach-omap2/resource34xx.c/se
t_opp().  In set_opp(),  if the target_level of vdd1 is less than
OPP3,will release the constraint set on VDD2 by calling
resource_release(), but it will never return because can not get the
mutex which is holding  by the previous caller. 
 
int resource_release(const char *name, struct device *dev)
{   ...
down(res_mutex);

/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
up(res_mutex);
return ret;
}

int set_opp(struct shared_resource *resp, u32 target_level) {
.
 if (resp == vdd1_resp) {
  if (target_level  3)
   resource_release(vdd2_opp, vdd2_dev); }
 
The patch to fix this issue is below, will you pls review it and let me
know your feedback?
 
From: Limei Wang e12...@motorola.com
Date: Fri, 7 Aug 2009 11:40:35 -0500
Subject: [PATCH] OMAP PM: Fix dead lock bug in
resourc_release(vdd1_opp).
 

Signed-off-by: Limei Wang e12...@motorola.com
---
 arch/arm/plat-omap/resource.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)
 
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c index ec31727..876fd12 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -418,10 +418,12 @@ int resource_release(const char *name, struct
device *dev)
list_del(user-node);
free_user(user);
 
-   /* Recompute and set the current level for the resource */
-   ret = update_resource_level(resp);
 res_unlock:
up(res_mutex);
+
+   /* Recompute and set the current level for the resource */
+   if (!ret)
+   ret = update_resource_level(resp);
return ret;
 }
 EXPORT_SYMBOL(resource_release);
--
1.5.6.3

 
Thanks,
Limei
--
To unsubscribe from this list: send the line unsubscribe 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Woodruff, Richard]

Used to be you needed to build with CONFIG_ARCH_DISCONTIGMEM_ENABLE did you do 
this?

Regards,
Richard W.

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim
 Sent: Friday, August 07, 2009 3:17 PM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
 Subject: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

 Hi all,

 On OMAP3 we are creating a space for DSP components to have shared buffers
 using the boot arguments.

 mem=...@0x8000 mem=1...@0x8800

 This creates a 40M hole for DSP components, the drivers dynamically do a
 request mem region and ioremap of pre-defined address space with in the 40M
 region.

 With the above setup, we see the system running for a while but then ends up
 with exception.

 Unable to handle kernel paging request at virtual address c7381000

 The address reported here is not in kernel space, and this doesn't result in a
 kernel panic.

 Other observation:
 - The same setup works fine with no hole or space created. The 40M space for
 DSP components will be allocated at the end (216M).
 - If we increase the mem hole region we can make the system fail with in less
 time.
 - Free returns expected memory map

 While I am still debugging the issue, I thought of posting this message to
 know if there are any known issues with ARM architecture in handling such non
 contiguous space / mem hole.

 I see some special boot parameters for other architectures like exactmap, we
 don't see similar stuff on ARM. Do we need to port any such support for ARM ?

 Kindly advice,

 Thanks.

 Regards,
 Khasim

 --
 To unsubscribe from this list: send the line unsubscribe 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

On Sat, Aug 08, 2009 at 01:46:35AM +0530, Syed Mohammed, Khasim wrote:
 On OMAP3 we are creating a space for DSP components to have shared
 buffers using the boot arguments.
 
 mem=...@0x8000 mem=1...@0x8800

Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the
configuration - you need OMAP3 to select this symbol.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][pm-2.6.29] OMAP: PM: Fix MUSB power domain association

[Vikram Pandita]

MUSB lies in CORE power domain.
Current code wrongly associates MUSB with USBHOST domain.
USBHOST domain is for EHCI/OHCI controller.

Correct the association of MUSB to CORE power domain.

Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
 arch/arm/mach-omap2/omapdev3xxx.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omapdev3xxx.h 
b/arch/arm/mach-omap2/omapdev3xxx.h
index d2772c4..fd29129 100644
--- a/arch/arm/mach-omap2/omapdev3xxx.h
+++ b/arch/arm/mach-omap2/omapdev3xxx.h
@@ -663,7 +663,7 @@ static struct omapdev usbhost_3xxx_omapdev = {
 
 static struct omapdev usbotg_3xxx_omapdev = {
.name   = usbotg_omapdev,
-   .pwrdm  = { .name = usbhost_pwrdm },
+   .pwrdm  = { .name = core_pwrdm },
.pdev_name  = musb_hdrc,
.pdev_id= -1,
.omap_chip  = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
-- 
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

Re: [PATCH][pm-2.6.29] OMAP: PM: Fix MUSB power domain association

[Kevin Hilman]

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

 MUSB lies in CORE power domain.
 Current code wrongly associates MUSB with USBHOST domain.
 USBHOST domain is for EHCI/OHCI controller.

 Correct the association of MUSB to CORE power domain.

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

Thanks, pushed to pm-2.6.29 branch.
(Not relevant to current PM branch due to new omap_hwmod/omap_device 
infrastructure.)

Kevin

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

 diff --git a/arch/arm/mach-omap2/omapdev3xxx.h 
 b/arch/arm/mach-omap2/omapdev3xxx.h
 index d2772c4..fd29129 100644
 --- a/arch/arm/mach-omap2/omapdev3xxx.h
 +++ b/arch/arm/mach-omap2/omapdev3xxx.h
 @@ -663,7 +663,7 @@ static struct omapdev usbhost_3xxx_omapdev = {
  
  static struct omapdev usbotg_3xxx_omapdev = {
   .name   = usbotg_omapdev,
 - .pwrdm  = { .name = usbhost_pwrdm },
 + .pwrdm  = { .name = core_pwrdm },
   .pdev_name  = musb_hdrc,
   .pdev_id= -1,
   .omap_chip  = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
 -- 
 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