Re: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition

[Hemanth V]

- Original Message - 
From: Gregory CLEMENT gregory.clem...@free-electrons.com
To: spi-devel-general spi-devel-gene...@lists.sourceforge.net; 
linux-omap linux-omap@vger.kernel.org
Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely 
grant.lik...@secretlab.ca; Kevin Hilman khil...@deeprootsystems.com

Sent: Wednesday, November 10, 2010 4:02 PM
Subject: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode 
transition



When SPI wake up from OFF mode, CS is in the wrong state: force it to the 
inactive state.


During the system life, I monitored the CS behavior using a oscilloscope. 
I also activated debug in omap2_mcspi, so I saw when driver disable the 
clocks and restore context when device is not used.

Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated 
that on resume the CS was in wrong state( ie activated).




Just to confirm the understanding. Are saying  CHCONF[6]  EPOL bit
setting and CS state did not match and is actually a hardware bug. If so
could u let us know which platform u are testing this on.

Thanks
Hemanth


Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/spi/omap2_mcspi.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
 };
 #endif
 +/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
 static int __init omap2_mcspi_probe(struct platform_device *pdev)
 {
 struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct 
platform_device *pdev)

 master-transfer = omap2_mcspi_transfer;
 master-cleanup = omap2_mcspi_cleanup;
 master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
  dev_set_drvdata(pdev-dev, master);
 -- 1.7.0.4

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



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

[PATCH] OMAP: Serial: Define OMAP uart MDR1 register definitions

[Emeltchenko Andrei]

From: Andrei Emeltchenko andrei.emeltche...@nokia.com

Define MDR1 register serial definitions used in serial and
bluetooth drivers. Remove magic numbers there.

Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
 include/linux/serial_reg.h |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index c7a0ce1..b62968c 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -341,5 +341,17 @@
 #define UART_OMAP_SYSS 0x16/* System status register */
 #define UART_OMAP_WER  0x17/* Wake-up enable register */
 
+/*
+ * These are the definitions for the MDR1 register
+ */
+#define UART_MDR1_16X_MODE 0x00/* UART 16x mode */
+#define UART_MDR1_SIR_MODE 0x01/* SIR mode */
+#define UART_MDR1_16X_AUTOBAUD_MODE0x02/* UART 16x auto-baud */
+#define UART_MDR1_13X_MODE 0x03/* UART 13x mode */
+#define UART_MDR1_MIR_MODE 0x04/* MIR mode */
+#define UART_MDR1_FIR_MODE 0x05/* FIR mode */
+#define UART_MDR1_CIR_MODE 0x06/* CIR mode */
+#define UART_MDR1_DISABLE  0x07/* Disable (default state) */
+
 #endif /* _LINUX_SERIAL_REG_H */
 
-- 
1.7.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/5] omap: control: add functions for DSP boot

[Felipe Contreras]

On Thu, Nov 11, 2010 at 2:00 AM, Paul Walmsley p...@pwsan.com wrote:
 Hello Felipe,

 On Sun, 7 Nov 2010, Felipe Contreras wrote:

 From: Paul Walmsley p...@pwsan.com

 Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control.  These
 registers wound up in the System Control Module.  Other kernel code that
 wishes to control the DSP's boot process should now use these functions
 to do so; subsequent patches implement this in the two in-tree users of
 these functions.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com

 I see that you modified my original patch, but it seems that you also
 dropped my Signed-off-by:.

Yes, because you didn't s-o-b my changes. I got that complaint from Catalin.

 This is a tricky situation, to be sure.
 Probably the best thing to do in these cases if you don't wish to ask me
 to review the modified patch,  is to keep my original Signed-off-by: --
 since I wrote the patch, originally -- and then, immediately before your
 Signed-off-by:, to add a bracketed note saying what you changed, e.g.,

 [felipe.contre...@gmail.com: dropped some changes, etc.]

 That way the provenance of the patch is clear.

Ok. I was hoping you would review the patch and put your s-o-b.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe 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: BeagleBoard not resuming from uart with latest pm-core ?

[Peter 'p2' De Schrijver]

On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote:
 Jean Pihet jean.pi...@newoldbits.com writes:
 
  l-o is currently broken wrt to suspend and idle.
  Solutions are being worked on for the moment.
 
  Kevin, are there solutions available yet?
 
 The solution to your previous problem (ensuring runtime PM transitions
 work during system PM) is included in my pm-core branch, but is not yet
 the final solution.  I've been disussing this issue with the runtime PM
 maintainers for a final solution.  Until then, I will carry this in
 pm-core.
 
 The other problem that I'm aware of so far I've only seen on boards with
 UART2 console (beagle, Overo, n900.)  The printk messages that warn of

N900 uses UART3 as its console... UART2 is bluetooth iirc.

CHeers,

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

Re: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition

[Gregory CLEMENT]

On 11/11/2010 10:34 AM, Hemanth V wrote:

- Original Message - From: Gregory CLEMENT
gregory.clem...@free-electrons.com
To: spi-devel-general spi-devel-gene...@lists.sourceforge.net;
linux-omap linux-omap@vger.kernel.org
Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely
grant.lik...@secretlab.ca; Kevin Hilman khil...@deeprootsystems.com
Sent: Wednesday, November 10, 2010 4:02 PM
Subject: [PATCH v2 2/2] spi: Force CS to be in inactive state after
off-mode transition



When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.

During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).



Just to confirm the understanding. Are saying CHCONF[6] EPOL bit
setting and CS state did not match and is actually a hardware bug. If so
could u let us know which platform u are testing this on.



Well I am not sure it is related to CHCONF[6] EPOL bit. During exchange 
on SPI, CS is in the good state. But when system wake up from an 
off-mode, CS is in its active state (high state for our configuration). 
I thought it was more a problem with CHCONF[20] FORCE bit, indeed this 
bit is at 0, so CS should be in low state. It is only when we first set 
this bit to 1 and then to 0, that CS go to low state.
It sounds like an hardware bug on this bit, or let's say an undocumented 
feature ;)
CS stay in high state until the next transaction on the SPI bus, indeed 
as the driver use CHCONF[20] FORCE bit during exchange, it will do the 
transition on this bit. That's why nobody noticed it until now, because 
from the software point of view it works.


I didn't test it with CHCONF[6] EPOL bit set to 1.

Our silicon revision was OMAP3530-GP ES3.1.


Thanks
Hemanth


Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
};
#endif
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
-- 1.7.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






--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 4/7] OMAP4: mux: Add CBL package data for OMAP4430 ES1

[Cousson, Benoit]

Hi Tony,

On 11/11/2010 2:56 AM, Tony Lindgren wrote:

* Benoit Coussonb-cous...@ti.com  [101019 15:14]:

Add data for OMAP4430 generated from HW pinout  register database.
The data set is split in two partitions for both core and wkup.


We should drop patch 3/7 and merge the following patch to your
4/7 patch.


OK



Basically let's keep the omap_mux_read/write around for now,
by adding omap_mux_get for dealing with the partition
information.


Thanks for that.

I'll send the update today.

Regards,
Benoit



Regards,

Tony


From: Tony Lindgrent...@atomide.com
Date: Wed, 10 Nov 2010 09:55:47 -0800
Subject: [PATCH] omap: mux: Fix support for partitions for dynamic muxing

Revert some parts of Benoit's patch to not make
omap_mux_read/write static at this point.

We may need to do remuxing for system wide idle states,
and also for driver specific idle states.

So we still need to have omap_mux_read/write around for
the platform level driver code.

Also add omap_mux_get for getting the partition data so
platform level device code can use it.

Signed-off-by: Tony Lindgrent...@atomide.com

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3fec4d6..3fda20d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -293,6 +293,8 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
  };

+static struct omap_mux_partition *partition;
+
  /*
   * Current flows to eMMC when eMMC is off and the data lines are pulled up,
   * so pull them down. N.B. we pull 8 lines because we are using 8 lines.
@@ -300,9 +302,9 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
  static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
  {
if (power_on)
-   omap_mux_write_array(rx51_mmc2_on_mux);
+   omap_mux_write_array(partition, rx51_mmc2_on_mux);
else
-   omap_mux_write_array(rx51_mmc2_off_mux);
+   omap_mux_write_array(partition, rx51_mmc2_off_mux);
  }

  static struct omap2_hsmmc_info mmc[] __initdata = {
@@ -922,7 +924,11 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
-   omap2_hsmmc_init(mmc);
+
+   partition = omap_mux_get(core);
+   if (partition)
+   omap2_hsmmc_init(mmc);
+
platform_device_register(rx51_charger_device);
  }

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9b9128e..6d91bb8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -49,7 +49,19 @@ struct omap_mux_entry {
  static LIST_HEAD(mux_partitions);
  static DEFINE_MUTEX(muxmode_mutex);

-static u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
+struct omap_mux_partition * omap_mux_get(const char *name)
+{
+   struct omap_mux_partition *partition;
+
+   list_for_each_entry(partition,mux_partitions, node) {
+   if (!strcmp(name, partition-name))
+   return partition;
+   }
+
+   return NULL;
+}
+
+u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
  {
if (partition-flags  OMAP_MUX_REG_8BIT)
return __raw_readb(partition-base + reg);
@@ -57,7 +69,7 @@ static u16 omap_mux_read(struct omap_mux_partition 
*partition, u16 reg)
return __raw_readw(partition-base + reg);
  }

-static void omap_mux_write(struct omap_mux_partition *partition, u16 val,
+void omap_mux_write(struct omap_mux_partition *partition, u16 val,
   u16 reg)
  {
if (partition-flags  OMAP_MUX_REG_8BIT)
@@ -66,7 +78,7 @@ static void omap_mux_write(struct omap_mux_partition 
*partition, u16 val,
__raw_writew(val, partition-base + reg);
  }

-static void omap_mux_write_array(struct omap_mux_partition *partition,
+void omap_mux_write_array(struct omap_mux_partition *partition,
 struct omap_board_mux *board_mux)
  {
while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index dad32f6..6656043 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -186,6 +186,40 @@ u16 omap_mux_get_gpio(int gpio);
  void omap_mux_set_gpio(u16 val, int gpio);

  /**
+ * omap_mux_get() - get a mux partition by name
+ * @name:  Name of the mux partition
+ *
+ */
+struct omap_mux_partition * omap_mux_get(const char *name);
+
+/**
+ * omap_mux_read() - read mux register
+ * @partition: Mux partition
+ * @mux_offset:Offset of the mux register
+ *
+ */
+u16 omap_mux_read(struct omap_mux_partition *p, u16 mux_offset);
+
+/**
+ * omap_mux_write() - write mux register
+ * @partition: Mux partition
+ * @val: 

Re: [PATCH 00/02] staging: tidspbridge: 2.6.37-rcX fixes

[Greg KH]

On Wed, Nov 10, 2010 at 07:50:23PM -0600, Omar Ramirez Luna wrote:
 Hi Greg,
 
 Please consider the following patch set for tidspbridge driver in
 staging tree, the following has been tested on an omap3430 based board
 + gst-dsp environment. Many thanks to Felipe Contreras for piling this up,
 as I'm just propagating his patches.
 
 First two patches:
 1. omap: dsp: remove shm from normal memory
 2. staging: tidspbridge: hardcode SCM macros while fix is upstreamed
 
 Resolve a couple of build breaks due to adaptations for memblock
 and SCM layer.
 
 (2) Is meant as a temporary fix, until the patches to fix this
 (currently in review) are upstreamed. [1]
 
 The rest of the series, is the revert of iommu migration changes. These
 are needed because, without modifications made to iommu module, they do not
 work; these modifications (on iommu code) didn't make it for the previous
 merge window either.
 
 I will avoid posting the reverts (unless required), they can be found
 (along with the two patches of this series) at:
 
 git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git 
   tidspbridge-2.6.37-rc1

I've pulled from this tree and pushed it out to the staging-linus branch
to get sent to Linus before .37 is released.

thanks,

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

[PATCHv2] OMAP: Serial: Define OMAP uart MDR1 register definitions

[Emeltchenko Andrei]

From: Andrei Emeltchenko andrei.emeltche...@nokia.com

Define MDR1 register serial definitions used in serial and
bluetooth drivers. Remove magic numbers there.
*v2 added OMAP keyword

Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
 include/linux/serial_reg.h |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index c7a0ce1..6f38234 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -341,5 +341,17 @@
 #define UART_OMAP_SYSS 0x16/* System status register */
 #define UART_OMAP_WER  0x17/* Wake-up enable register */
 
+/*
+ * These are the definitions for the MDR1 register
+ */
+#define UART_OMAP_MDR1_16X_MODE0x00/* UART 16x mode */
+#define UART_OMAP_MDR1_SIR_MODE0x01/* SIR mode */
+#define UART_OMAP_MDR1_16X_ABAUD_MODE  0x02/* UART 16x auto-baud */
+#define UART_OMAP_MDR1_13X_MODE0x03/* UART 13x mode */
+#define UART_OMAP_MDR1_MIR_MODE0x04/* MIR mode */
+#define UART_OMAP_MDR1_FIR_MODE0x05/* FIR mode */
+#define UART_OMAP_MDR1_CIR_MODE0x06/* CIR mode */
+#define UART_OMAP_MDR1_DISABLE 0x07/* Disable (default state) */
+
 #endif /* _LINUX_SERIAL_REG_H */
 
-- 
1.7.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/5] omap: control: add functions for DSP boot

[Paul Walmsley]

Hello Felipe,

On Thu, 11 Nov 2010, Felipe Contreras wrote:

 On Thu, Nov 11, 2010 at 2:00 AM, Paul Walmsley p...@pwsan.com wrote:
 
  I see that you modified my original patch, but it seems that you also
  dropped my Signed-off-by:.
 
 Yes, because you didn't s-o-b my changes. I got that complaint from Catalin.

I have reviewed my p...@pwsan.com inbox. I didn't see any request from you 
to review the changes.  But perhaps it was inadvertently dropped at some 
point in the mail path between you and I.

  This is a tricky situation, to be sure.
  Probably the best thing to do in these cases if you don't wish to ask me
  to review the modified patch,  is to keep my original Signed-off-by: --
  since I wrote the patch, originally -- and then, immediately before your
  Signed-off-by:, to add a bracketed note saying what you changed, e.g.,
 
  [felipe.contre...@gmail.com: dropped some changes, etc.]
 
  That way the provenance of the patch is clear.
 
 Ok. I was hoping you would review the patch and put your s-o-b.

I have reviewed your updated patch; you are welcome to re-add my 
Signed-off-by:.


- Paul

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Kevin Hilman]

Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:

 On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote:
 Jean Pihet jean.pi...@newoldbits.com writes:
 
  l-o is currently broken wrt to suspend and idle.
  Solutions are being worked on for the moment.
 
  Kevin, are there solutions available yet?
 
 The solution to your previous problem (ensuring runtime PM transitions
 work during system PM) is included in my pm-core branch, but is not yet
 the final solution.  I've been disussing this issue with the runtime PM
 maintainers for a final solution.  Until then, I will carry this in
 pm-core.
 
 The other problem that I'm aware of so far I've only seen on boards with
 UART2 console (beagle, Overo, n900.)  The printk messages that warn of

 N900 uses UART3 as its console... UART2 is bluetooth iirc.

You're right, beagle and Overo are also UART3, so s/UART2/UART3/ in my
above comment.

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: [PATCHv2] OMAP: Serial: Define OMAP uart MDR1 register definitions

[Kevin Hilman]

Emeltchenko Andrei andrei.emeltchenko.n...@gmail.com writes:

 From: Andrei Emeltchenko andrei.emeltche...@nokia.com

 Define MDR1 register serial definitions used in serial and
 bluetooth drivers. Remove magic numbers there.

Remove magic numbers where?  This patch doesn't remove anything.

 *v2   added OMAP keyword

This info should go after the '---' as it is not needed in the final
git history.

Kevin

 Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
 ---
  include/linux/serial_reg.h |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
 index c7a0ce1..6f38234 100644
 --- a/include/linux/serial_reg.h
 +++ b/include/linux/serial_reg.h
 @@ -341,5 +341,17 @@
  #define UART_OMAP_SYSS   0x16/* System status register */
  #define UART_OMAP_WER0x17/* Wake-up enable register */
  
 +/*
 + * These are the definitions for the MDR1 register
 + */
 +#define UART_OMAP_MDR1_16X_MODE  0x00/* UART 16x mode */
 +#define UART_OMAP_MDR1_SIR_MODE  0x01/* SIR mode */
 +#define UART_OMAP_MDR1_16X_ABAUD_MODE0x02/* UART 16x auto-baud */
 +#define UART_OMAP_MDR1_13X_MODE  0x03/* UART 13x mode */
 +#define UART_OMAP_MDR1_MIR_MODE  0x04/* MIR mode */
 +#define UART_OMAP_MDR1_FIR_MODE  0x05/* FIR mode */
 +#define UART_OMAP_MDR1_CIR_MODE  0x06/* CIR mode */
 +#define UART_OMAP_MDR1_DISABLE   0x07/* Disable (default 
 state) */
 +
  #endif /* _LINUX_SERIAL_REG_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

Re: [RFC v2 3/7] OMAP: mux: Add support for control module split in several partitions

[Tony Lindgren]

* Benoit Cousson b-cous...@ti.com [101019 15:14]:
 --- a/arch/arm/mach-omap2/mux.h
 +++ b/arch/arm/mach-omap2/mux.h
 +
 +/**
 + * struct mux_partition - contain partition related information
 + * @name: name of the current partition
 + * @flags: flags specific to this partition
 + * @phys: physical address
 + * @size: partition size
 + * @base: virtual address after ioremap
 + * @muxmodes: list of nodes that belong to a partition
 + * @node: list node for the partitions linked list
 + */
 +struct omap_mux_partition {
 + const char  *name;
 + u32 flags;
 + u32 phys;
 + u32 size;
 + void __iomem*base;
 + struct list_headmuxmodes;
 + struct list_headnode;
 +};

With the omap_mux_parition..
  
  /**
   * struct omap_mux - data for omap mux register offset and it's value
   * @reg_offset:  mux register offset from the mux base
   * @gpio:GPIO number
 + * @id:  Partition identifier
   * @muxnames:available signal modes for a ball
   */
  struct omap_mux {
 @@ -82,6 +114,7 @@ struct omap_mux {
   char*muxnames[OMAP_MUX_NR_MODES];
  #ifdef CONFIG_DEBUG_FS
   char*balls[OMAP_MUX_NR_SIDES];
 + struct omap_mux_partition *partition;
  #endif
  #endif
  };
 @@ -89,6 +122,7 @@ struct omap_mux {
  /**
   * struct omap_ball - data for balls on omap package
   * @reg_offset:  mux register offset from the mux base
 + * @id:  Partition identifier
   * @balls:   available balls on the package
   */
  struct omap_ball {
 @@ -100,6 +134,7 @@ struct omap_ball {
   * struct omap_board_mux - data for initializing mux registers
   * @reg_offset:  mux register offset from the mux base
   * @mux_value:   desired mux value to set
 + * @id:  Partition identifier
   */
  struct omap_board_mux {
   u16 reg_offset;

..I think the above changes are no longer needed.

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 v2 4/7] OMAP4: mux: Add CBL package data for OMAP4430 ES1

[Tony Lindgren]

* Cousson, Benoit b-cous...@ti.com [10 04:24]:
 Hi Tony,
 
 On 11/11/2010 2:56 AM, Tony Lindgren wrote:
 * Benoit Coussonb-cous...@ti.com  [101019 15:14]:
 Add data for OMAP4430 generated from HW pinout  register database.
 The data set is split in two partitions for both core and wkup.
 
 We should drop patch 3/7 and merge the following patch to your
 4/7 patch.
 
 OK

Oops, sorry got the patch numbers wrong, the patch numbers
should be 2/7 and 3/7. Well you probably figured that out
already :)

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 v2 3/7] OMAP: mux: Add support for control module split in several partitions

[Cousson, Benoit]

On 11/11/2010 5:35 PM, Tony Lindgren wrote:

* Benoit Coussonb-cous...@ti.com  [101019 15:14]:

--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
+
+/**
+ * struct mux_partition - contain partition related information
+ * @name: name of the current partition
+ * @flags: flags specific to this partition
+ * @phys: physical address
+ * @size: partition size
+ * @base: virtual address after ioremap
+ * @muxmodes: list of nodes that belong to a partition
+ * @node: list node for the partitions linked list
+ */
+struct omap_mux_partition {
+   const char  *name;
+   u32 flags;
+   u32 phys;
+   u32 size;
+   void __iomem*base;
+   struct list_headmuxmodes;
+   struct list_headnode;
+};


With the omap_mux_parition..


  /**
   * struct omap_mux - data for omap mux register offset and it's value
   * @reg_offset:   mux register offset from the mux base
   * @gpio: GPIO number
+ * @id:Partition identifier
   * @muxnames: available signal modes for a ball
   */
  struct omap_mux {
@@ -82,6 +114,7 @@ struct omap_mux {
char*muxnames[OMAP_MUX_NR_MODES];
  #ifdef CONFIG_DEBUG_FS
char*balls[OMAP_MUX_NR_SIDES];
+   struct omap_mux_partition *partition;
  #endif
  #endif
  };
@@ -89,6 +122,7 @@ struct omap_mux {
  /**
   * struct omap_ball - data for balls on omap package
   * @reg_offset:   mux register offset from the mux base
+ * @id:Partition identifier
   * @balls:available balls on the package
   */
  struct omap_ball {
@@ -100,6 +134,7 @@ struct omap_ball {
   * struct omap_board_mux - data for initializing mux registers
   * @reg_offset:   mux register offset from the mux base
   * @mux_value:desired mux value to set
+ * @id:Partition identifier
   */
  struct omap_board_mux {
u16 reg_offset;


..I think the above changes are no longer needed.


Oops yep, I forgot to remove the @id in the kerneldoc.
I was about to send the next revision, maybe I should wait a little bit 
more.


Thanks,
Benoit

--
To unsubscribe from this list: send the line unsubscribe 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 v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 ES2 support

[Tony Lindgren]

* Cousson, Benoit b-cous...@ti.com [101020 13:43]:
 
 On 10/20/2010 1:06 AM, Tony Lindgren wrote:
 * Benoit Coussonb-cous...@ti.com  [101019 15:14]:
 
 It takes into account your proposal to store partition
 information in a partition structure instead of inside every pad entries.
 The mechanism relies on the uniqueness of the pad name in each partition to
 find the correct partition during iteration.
 
 OK, using the offset defines won't be unique necessarily..
 
 They should. The defines are all based on pad names that are all
 unique. Assuming HW folks didn't messed up the spec...

Just for the record to avoid confusion.. What I meant is the
offset values from the partition base are not unique even
if the define names are unique:

/* ctrl_module_pad_core registers offset */
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD0_OFFSET   0x0040
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD1_OFFSET   0x0042
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD2_OFFSET   0x0044
...

/* ctrl_module_pad_wkup registers offset */
#define OMAP4_CTRL_MODULE_PAD_SIM_IO_OFFSET 0x0040
#define OMAP4_CTRL_MODULE_PAD_SIM_CLK_OFFSET0x0042
#define OMAP4_CTRL_MODULE_PAD_SIM_RESET_OFFSET  0x0044
...

So now we have to use either a unique pad name, or a combination of
partition + offset.

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 v2 3/7] OMAP: mux: Add support for control module split in several partitions

[Tony Lindgren]

* Cousson, Benoit b-cous...@ti.com [10 08:40]:
 On 11/11/2010 5:35 PM, Tony Lindgren wrote:
 
 Oops yep, I forgot to remove the @id in the kerneldoc.
 I was about to send the next revision, maybe I should wait a little
 bit more.

Well I think that's all I had to comment on these. Just please update
the patch description in 3/7 too.

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 v2 4/7] OMAP4: mux: Add CBL package data for OMAP4430 ES1

[Cousson, Benoit]

On 11/11/2010 5:38 PM, Tony Lindgren wrote:

* Cousson, Benoitb-cous...@ti.com  [10 04:24]:

Hi Tony,

On 11/11/2010 2:56 AM, Tony Lindgren wrote:

* Benoit Coussonb-cous...@ti.com   [101019 15:14]:

Add data for OMAP4430 generated from HW pinout   register database.
The data set is split in two partitions for both core and wkup.


We should drop patch 3/7 and merge the following patch to your
4/7 patch.


OK


Oops, sorry got the patch numbers wrong, the patch numbers
should be 2/7 and 3/7. Well you probably figured that out
already :)


Well, yes, it took me some time, but I figured it out :-)

Benoit
--
To unsubscribe from this list: send the line unsubscribe 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 v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 ES2 support

[Cousson, Benoit]

On 11/11/2010 5:53 PM, Tony Lindgren wrote:

* Cousson, Benoitb-cous...@ti.com  [101020 13:43]:


On 10/20/2010 1:06 AM, Tony Lindgren wrote:

* Benoit Coussonb-cous...@ti.com   [101019 15:14]:


It takes into account your proposal to store partition
information in a partition structure instead of inside every pad entries.
The mechanism relies on the uniqueness of the pad name in each partition to
find the correct partition during iteration.


OK, using the offset defines won't be unique necessarily..


They should. The defines are all based on pad names that are all
unique. Assuming HW folks didn't messed up the spec...


Just for the record to avoid confusion.. What I meant is the
offset values from the partition base are not unique even
if the define names are unique:

/* ctrl_module_pad_core registers offset */
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD0_OFFSET   0x0040
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD1_OFFSET   0x0042
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD2_OFFSET   0x0044
...

/* ctrl_module_pad_wkup registers offset */
#define OMAP4_CTRL_MODULE_PAD_SIM_IO_OFFSET 0x0040
#define OMAP4_CTRL_MODULE_PAD_SIM_CLK_OFFSET0x0042
#define OMAP4_CTRL_MODULE_PAD_SIM_RESET_OFFSET  0x0044
...

So now we have to use either a unique pad name, or a combination of
partition + offset.


Yes. Hence the need for the omap_mux_get you've just done in order to 
access the low level API.


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

Re: [PATCH v2 07/14] OMAP: Introduce dependent voltage domain support.

[Kevin Hilman]

Thara Gopinath th...@ti.com writes:

 There could be dependencies between various voltage domains for
 maintaining system performance or hardware limitation reasons
 like VDDX should be at voltage v1 when VDDY is at voltage v2.
 This patch introduce dependent vdd information structures in the
 voltage layer which can be used to populate these dependencies
 for a voltage domain. This patch also adds support to scale
 the dependent vdd and the scalable devices belonging to it
 during the scaling of a main vdd through omap_voltage_scale.

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

This patch introduces recursive locking (found by lockdep)

[...]

  /**
   * omap_voltage_get_nom_volt() - Gets the current non-auto-compensated 
 voltage
 @@ -1697,6 +1803,8 @@ int omap_voltage_scale(struct voltagedomain *voltdm, 
 unsigned long volt)
   int is_volt_scaled = 0;
   struct omap_vdd_info *vdd;
   struct omap_vdd_dev_list *temp_dev;
 + struct plist_node *node;
 + struct omap_vdd_user_list *user;
  
   if (!voltdm || IS_ERR(voltdm)) {
   pr_warning(%s: VDD specified does not exist!\n, __func__);
 @@ -1709,6 +1817,17 @@ int omap_voltage_scale(struct voltagedomain *voltdm, 
 unsigned long volt)
  
   curr_volt = omap_voltage_get_nom_volt(voltdm);

Just above here, there is an existing mutex_lock()

 + /* Find the device requesting the voltage scaling */
 + node = plist_first(vdd-user_list);
 + user = container_of(node, struct omap_vdd_user_list, node);

 + /* calculate the voltages for dependent vdd's */
 + if (calc_dep_vdd_volt(user-dev, vdd, volt)) {

This function can call omap_voltage_add_request() which will also try to
take the same mutex.

 + pr_warning(%s: Error in calculating dependent vdd voltages
 + for vdd_%s\n, __func__, voltdm-name);
 + return -EINVAL;
 + }
 +

   if (curr_volt == volt) {
   is_volt_scaled = 1;
   } else if (curr_volt  volt) {
 @@ -1746,6 +1865,9 @@ int omap_voltage_scale(struct voltagedomain *voltdm, 
 unsigned long volt)
  
   mutex_unlock(vdd-scaling_mutex);
  
 + /* Scale dependent vdds */
 + scale_dep_vdd(vdd);
 +
   return 0;
  }

Here is the details reported by lockdep.

Kevin

[2.314270] SmartReflex Class3 initialized
[2.318634] omap_device: smartreflex.1: new worst case activate latency 0: 
30517
[2.363861] clock: disabling unused clocks to save power
[2.372070] 
[2.372070] =
[2.379272] [ INFO: possible recursive locking detected ]
[2.384918] 2.6.36-pm-default-09076-g6ad1eb9 #2
[2.389648] -
[2.395294] swapper/1 is trying to acquire lock:
[2.400115]  (vdd-scaling_mutex){+.+.+.}, at: [c025b138] 
omap_voltage_add_request+0x48/0x1a0
[2.409362] 
[2.409362] but task is already holding lock:
[2.415466]  (vdd-scaling_mutex){+.+.+.}, at: [c025b2d0] 
omap_voltage_scale+0x40/0x26c
[2.424133] 
[2.424133] other info that might help us debug this:
[2.430938] 3 locks held by swapper/1:
[2.434875]  #0:  (sysdev_drivers_lock){+.+.+.}, at: [c047d87c] 
sysdev_driver_register+0x60/0x114
[2.444366]  #1:  (per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: 
[c0512bb0] lock_policy_rwsem_write+0x40/0x94
[2.454956]  #2:  (vdd-scaling_mutex){+.+.+.}, at: [c025b2d0] 
omap_voltage_scale+0x40/0x26c
[2.464080] 
[2.464111] stack backtrace:
[2.468688] [c024d4a0] (unwind_backtrace+0x0/0xe4) from [c02b670c] 
(__lock_acquire+0xdc8/0x1758)
[2.478271] [c02b670c] (__lock_acquire+0xdc8/0x1758) from [c02b7170] 
(lock_acquire+0xd4/0xf8)
[2.487548] [c02b7170] (lock_acquire+0xd4/0xf8) from [c05e4de8] 
(mutex_lock_nested+0x54/0x320)
[2.496948] [c05e4de8] (mutex_lock_nested+0x54/0x320) from [c025b138] 
(omap_voltage_add_request+0x48/0x1a0)
[2.507476] [c025b138] (omap_voltage_add_request+0x48/0x1a0) from 
[c025b388] (omap_voltage_scale+0xf8/0x26c)
[2.518127] [c025b388] (omap_voltage_scale+0xf8/0x26c) from [c0267918] 
(omap_device_scale+0x108/0x12c)
[2.528228] [c0267918] (omap_device_scale+0x108/0x12c) from [c026a754] 
(omap_target+0x58/0x60)
[2.537628] [c026a754] (omap_target+0x58/0x60) from [c0512b5c] 
(__cpufreq_driver_target+0x4c/0x60)
[2.547363] [c0512b5c] (__cpufreq_driver_target+0x4c/0x60) from 
[c05151c8] (cpufreq_governor_performance+0x20/0x28)
[2.558654] [c05151c8] (cpufreq_governor_performance+0x20/0x28) from 
[c0512d28] (__cpufreq_governor+0xd8/0x12c)
[2.569549] [c0512d28] (__cpufreq_governor+0xd8/0x12c) from [c0512eb4] 
(__cpufreq_set_policy+0x114/0x15c)
[2.579925] [c0512eb4] (__cpufreq_set_policy+0x114/0x15c) from 
[c0514288] (cpufreq_add_dev_interface+0x268/0x2b4)
[2.591033] [c0514288] (cpufreq_add_dev_interface+0x268/0x2b4) from 
[c0514790] (cpufreq_add_dev+0x4bc/0x528)
[2.601684] [c0514790] (cpufreq_add_dev+0x4bc/0x528) from [c047d8c8] 

RE: Mistral AM37x (with AM3715) devel board networking broken

[Rick Bronson]

Hi,

  I've found the problem and below is the fix.  It appears your
SMSC9200 is faster than mine ;-)  Once in a while mine gets through the
smsc911x_soft_reset() in 100 us but most of the time it takes a full
250 ms.

  Rick

--- linux/drivers/net/smsc911x.c.~1~2010-11-08 19:53:03.0 -0800
+++ linux/drivers/net/smsc911x.c2010-11-11 12:00:18.0 -0800
@@ -791,8 +791,8 @@
return -ENODEV;
}
 
-   SMSC_TRACE(PROBE, PHY %d: addr %d, phy_id 0x%08X,
-   phy_addr, phydev-addr, phydev-phy_id);
+   SMSC_TRACE(PROBE, PHY %s: addr %d, phy_id 0x%08X,
+   dev_name(phydev-dev), phydev-addr, phydev-phy_id);
 
ret = phy_connect_direct(dev, phydev,
smsc911x_phy_adjust_link, 0,
@@ -1124,11 +1124,11 @@
 
/* Reset the LAN911x */
smsc911x_reg_write(pdata, HW_CFG, HW_CFG_SRST_);
-   timeout = 10;
-   do {
-   udelay(10);
-   temp = smsc911x_reg_read(pdata, HW_CFG);
-   } while ((--timeout)  (temp  HW_CFG_SRST_));
+   timeout = 1;  /* this can take up to 1/4 sec */
+   while ((smsc911x_reg_read(pdata, HW_CFG)  HW_CFG_SRST_)  timeout) {
+   udelay(100);
+   timeout--;
+   }
 
if (unlikely(temp  HW_CFG_SRST_)) {
SMSC_WARNING(DRV, Failed to complete reset);
--
To unsubscribe from this list: send the line unsubscribe 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/7] OMAP4: mux: Add the OMAP4430 ES1.0 ES2.x support

[Benoit Cousson]

Hi Tony,

Here is the version updated with your fixes.
This is the first non RFC version to make Nishant M. happy;-)

Thanks to you, the RX-51 is now handled properly and the low level API
is still public like before for dynamic mux use.

The pandaboard is now supported thanks to Sricharan, and a couple of bugs
are fixed, thanks to Dan who reported them.

The series is based on mainline (2.6.37-rc1) and is available here:
git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3

Tested on SDP4430 ES1.0, ES2.0 and ES2.1 with omap2plus_defconfig.
Still require some test on OMAP3 and OMAP2.

Thanks,
Benoit


RFC v2:
http://www.spinics.net/lists/linux-omap/msg38995.html

- Take into account Tony's proposal to store partition information
in a partition structure instead of inside every pad entries.
- Remove some cpu_is_xxx calls from the core code by adding a
couple of flags during partition init.

RFC v1:
http://www.spinics.net/lists/linux-omap/msg37158.html


Benoit Cousson (6):
  OMAP: mux: Replace printk with pr_xxx macros
  OMAP: mux: Add support for control module split in several partitions
  OMAP4: mux: Add CBL package data for OMAP4430 ES1
  OMAP4: sdp4430: Select CBL package for ES1 and initialize mux
  OMAP4: mux: Add CBS package data for OMAP4430 ES2
  OMAP4: sdp4430: Select CBS package for ES2

sricharan (1):
  OMAP4: pandaboard: Select CBL  CBS package and initialize mux

 arch/arm/mach-omap2/Kconfig  |   10 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-4430sdp.c  |   14 +
 arch/arm/mach-omap2/board-omap4panda.c   |   16 +
 arch/arm/mach-omap2/board-rx51-peripherals.c |   12 +-
 arch/arm/mach-omap2/mux.c|  342 --
 arch/arm/mach-omap2/mux.h|   84 ++-
 arch/arm/mach-omap2/mux2420.c|7 +-
 arch/arm/mach-omap2/mux2430.c|7 +-
 arch/arm/mach-omap2/mux34xx.c|7 +-
 arch/arm/mach-omap2/mux44xx.c| 1625 ++
 arch/arm/mach-omap2/mux44xx.h|  298 +
 12 files changed, 2279 insertions(+), 144 deletions(-)
 create mode 100644 arch/arm/mach-omap2/mux44xx.c
 create mode 100644 arch/arm/mach-omap2/mux44xx.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/7] OMAP: mux: Replace printk with pr_xxx macros

[Benoit Cousson]

Replace all the printk(KERN_XXX... with pr_xxx macros.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/mux.c |   38 +++---
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 074536a..979e9d1 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -102,13 +102,13 @@ int __init omap_mux_init_gpio(int gpio, int val)
}
 
if (found == 0) {
-   printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+   pr_err(mux: Could not set gpio%i\n, gpio);
return -ENODEV;
}
 
if (found  1) {
-   printk(KERN_INFO mux: Multiple gpio paths (%d) for gpio%i\n,
-   found, gpio);
+   pr_info(mux: Multiple gpio paths (%d) for gpio%i\n,
+   found, gpio);
return -EINVAL;
}
 
@@ -118,8 +118,8 @@ int __init omap_mux_init_gpio(int gpio, int val)
mux_mode |= OMAP_MUX_MODE3;
else
mux_mode |= OMAP_MUX_MODE4;
-   printk(KERN_DEBUG mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
-   gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
+   pr_debug(mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
+gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(mux_mode, gpio_mux-reg_offset);
 
return 0;
@@ -161,9 +161,9 @@ int __init omap_mux_init_signal(const char *muxname, int 
val)
 
old_mode = omap_mux_read(m-reg_offset);
mux_mode = val | i;
-   printk(KERN_DEBUG mux: Setting signal 
-   %s.%s 0x%04x - 0x%04x\n,
-   m0_entry, muxname, old_mode, mux_mode);
+   pr_debug(mux: Setting signal 
+%s.%s 0x%04x - 0x%04x\n,
+m0_entry, muxname, old_mode, mux_mode);
omap_mux_write(mux_mode, m-reg_offset);
found++;
}
@@ -174,12 +174,12 @@ int __init omap_mux_init_signal(const char *muxname, int 
val)
return 0;
 
if (found  1) {
-   printk(KERN_ERR mux: Multiple signal paths (%i) for %s\n,
-   found, muxname);
+   pr_err(mux: Multiple signal paths (%i) for %s\n,
+  found, muxname);
return -EINVAL;
}
 
-   printk(KERN_ERR mux: Could not set signal %s\n, muxname);
+   pr_err(mux: Could not set signal %s\n, muxname);
 
return -ENODEV;
 }
@@ -462,8 +462,8 @@ static void __init omap_mux_package_fixup(struct omap_mux 
*p,
s++;
}
if (!found)
-   printk(KERN_ERR mux: Unknown entry offset 0x%x\n,
-   p-reg_offset);
+   pr_err(mux: Unknown entry offset 0x%x\n,
+  p-reg_offset);
p++;
}
 }
@@ -487,8 +487,8 @@ static void __init omap_mux_package_init_balls(struct 
omap_ball *b,
s++;
}
if (!found)
-   printk(KERN_ERR mux: Unknown ball offset 0x%x\n,
-   b-reg_offset);
+   pr_err(mux: Unknown ball offset 0x%x\n,
+  b-reg_offset);
b++;
}
 }
@@ -615,7 +615,7 @@ u16 omap_mux_get_gpio(int gpio)
 
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
-   printk(KERN_ERR mux: Could not get gpio%i\n, gpio);
+   pr_err(mux: Could not get gpio%i\n, gpio);
return offset;
}
 
@@ -629,7 +629,7 @@ void omap_mux_set_gpio(u16 val, int gpio)
 
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
-   printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+   pr_err(mux: Could not set gpio%i\n, gpio);
return;
}
 
@@ -687,7 +687,7 @@ static void __init omap_mux_init_list(struct omap_mux 
*superset)
 
entry = omap_mux_list_add(superset);
if (!entry) {
-   printk(KERN_ERR mux: Could not add entry\n);
+   pr_err(mux: Could not add entry\n);
return;
}
superset++;
@@ -738,7 +738,7 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
mux_phys = mux_pbase;
mux_base = ioremap(mux_pbase, mux_size);
if (!mux_base) {

[PATCH 2/7] OMAP: mux: Add support for control module split in several partitions

[Benoit Cousson]

Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/partition
if the current mux mode is not the default one.

Thanks to Tony Lindgren t...@atomide.com for the following improvements:
- Add omap_mux_get for getting the partition data so platform level
device code can use it.
- Fix the rx51 board code to use the new API.

Thanks to Dan Murphy dmur...@ti.com for testing on OMAP4 and reporting
a couple of bugs.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Tested-by: Murphy Dan dmur...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   12 +-
 arch/arm/mach-omap2/mux.c|  310 +-
 arch/arm/mach-omap2/mux.h|   71 +-
 arch/arm/mach-omap2/mux2420.c|7 +-
 arch/arm/mach-omap2/mux2430.c|7 +-
 arch/arm/mach-omap2/mux34xx.c|7 +-
 6 files changed, 286 insertions(+), 128 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3fec4d6..3fda20d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -293,6 +293,8 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
+static struct omap_mux_partition *partition;
+
 /*
  * Current flows to eMMC when eMMC is off and the data lines are pulled up,
  * so pull them down. N.B. we pull 8 lines because we are using 8 lines.
@@ -300,9 +302,9 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
 static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
 {
if (power_on)
-   omap_mux_write_array(rx51_mmc2_on_mux);
+   omap_mux_write_array(partition, rx51_mmc2_on_mux);
else
-   omap_mux_write_array(rx51_mmc2_off_mux);
+   omap_mux_write_array(partition, rx51_mmc2_off_mux);
 }
 
 static struct omap2_hsmmc_info mmc[] __initdata = {
@@ -922,7 +924,11 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
-   omap2_hsmmc_init(mmc);
+
+   partition = omap_mux_get(core);
+   if (partition)
+   omap2_hsmmc_init(mmc);
+
platform_device_register(rx51_charger_device);
 }
 
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 979e9d1..fa139ff 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1,9 +1,9 @@
 /*
  * linux/arch/arm/mach-omap2/mux.c
  *
- * OMAP2 and OMAP3 pin multiplexing configurations
+ * OMAP2, OMAP3 and OMAP4 pin multiplexing configurations
  *
- * Copyright (C) 2004 - 2008 Texas Instruments Inc.
+ * Copyright (C) 2004 - 2010 Texas Instruments Inc.
  * Copyright (C) 2003 - 2008 Nokia Corporation
  *
  * Written by Tony Lindgren
@@ -40,60 +40,72 @@
 
 #define OMAP_MUX_BASE_OFFSET   0x30/* Offset from CTRL_BASE */
 #define OMAP_MUX_BASE_SZ   0x5ca
-#define MUXABLE_GPIO_MODE3 BIT(0)
 
 struct omap_mux_entry {
struct omap_mux mux;
struct list_headnode;
 };
 
-static unsigned long mux_phys;
-static void __iomem *mux_base;
-static u8 omap_mux_flags;
+static LIST_HEAD(mux_partitions);
+static DEFINE_MUTEX(muxmode_mutex);
+
+struct omap_mux_partition *omap_mux_get(const char *name)
+{
+   struct omap_mux_partition *partition;
+
+   list_for_each_entry(partition, mux_partitions, node) {
+   if (!strcmp(name, partition-name))
+   return partition;
+   }
+
+   return NULL;
+}
 
-u16 omap_mux_read(u16 reg)
+u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
 {
-   if (cpu_is_omap24xx())
-   return __raw_readb(mux_base + reg);
+   if (partition-flags  OMAP_MUX_REG_8BIT)
+   return __raw_readb(partition-base + reg);
else
-   return __raw_readw(mux_base + reg);
+   return __raw_readw(partition-base + reg);
 }
 
-void omap_mux_write(u16 val, u16 reg)
+void omap_mux_write(struct omap_mux_partition *partition, u16 val,
+  u16 reg)
 {
-   if (cpu_is_omap24xx())
-   __raw_writeb(val, mux_base + reg);
+   if (partition-flags  OMAP_MUX_REG_8BIT)
+   

[PATCH 4/7] OMAP4: sdp4430: Select CBL package for ES1 and initialize mux

[Benoit Cousson]

Select the CBL package if SDP4430 is enabled during config.
Initialize the mux framework during the board init.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/Kconfig |1 +
 arch/arm/mach-omap2/board-4430sdp.c |   10 ++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e14c73d..7efb256 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -280,6 +280,7 @@ config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
depends on ARCH_OMAP4
+   select OMAP_PACKAGE_CBL
 
 config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..e4f1726 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,6 +35,7 @@
 #include plat/usb.h
 #include plat/mmc.h
 
+#include mux.h
 #include hsmmc.h
 #include timer-gp.h
 #include control.h
@@ -505,10 +506,19 @@ static void __init omap_sfh7741prox_init(void)
}
 }
 
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux  NULL
+#endif
+
 static void __init omap_4430sdp_init(void)
 {
int status;
 
+   omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
-- 
1.7.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 6/7] OMAP4: sdp4430: Select CBS package for ES2

[Benoit Cousson]

Select the CBS package if SDP4430 is enabled during config.
Use the proper package (CBL or CBS) based on chip revision.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/Kconfig |1 +
 arch/arm/mach-omap2/board-4430sdp.c |6 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 92fea63..39229cf 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -284,6 +284,7 @@ config MACH_OMAP_4430SDP
default y
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
+   select OMAP_PACKAGE_CBS
 
 config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index e4f1726..94d989b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -517,8 +517,12 @@ static struct omap_board_mux board_mux[] __initdata = {
 static void __init omap_4430sdp_init(void)
 {
int status;
+   int package = OMAP_PACKAGE_CBS;
+
+   if (omap_rev() == OMAP4430_REV_ES1_0)
+   package = OMAP_PACKAGE_CBL;
+   omap4_mux_init(board_mux, package);
 
-   omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
-- 
1.7.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 5/7] OMAP4: mux: Add CBS package data for OMAP4430 ES2

[Benoit Cousson]

Please note that the full muxmodes are re-defined for ES2 instead
of using the subset. There are 81 differences among 204 pins.
The subset fixup will have to iterate over the whole list for each
subset entry, which can lead to an important number of iteration.
On the other hand, it will take much more memory at boot time.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/Kconfig   |3 +
 arch/arm/mach-omap2/mux.h |1 +
 arch/arm/mach-omap2/mux44xx.c |  741 -
 arch/arm/mach-omap2/mux44xx.h |   21 ++
 4 files changed, 758 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7efb256..92fea63 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,6 +88,9 @@ config OMAP_PACKAGE_CBP
 config OMAP_PACKAGE_CBL
bool
 
+config OMAP_PACKAGE_CBS
+   bool
+
 comment OMAP Board Type
depends on ARCH_OMAP2PLUS
 
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 58e4913..e2b7dbc 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -62,6 +62,7 @@
 
 /* Flags for omapX_mux_init */
 #define OMAP_PACKAGE_MASK  0x
+#define OMAP_PACKAGE_CBS   8   /* 547-pin 0.40 0.40 */
 #define OMAP_PACKAGE_CBL   7   /* 547-pin 0.40 0.40 */
 #define OMAP_PACKAGE_CBP   6   /* 515-pin 0.40 0.50 */
 #define OMAP_PACKAGE_CUS   5   /* 423-pin 0.65 */
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index 5e9d60a..80335f3 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -48,7 +48,7 @@
 }
 
 /*
- * Superset of all mux modes for omap4
+ * Superset of all mux modes for omap4 ES1.0
  */
 static struct omap_mux __initdata omap4_core_muxmodes[] = {
_OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
@@ -755,6 +755,724 @@ struct omap_ball __initdata omap4_core_cbl_ball[] = {
 #endif
 
 /*
+ * Superset of all mux modes for omap4 ES2.0
+ */
+static struct omap_mux __initdata omap4_es2_core_muxmodes[] = {
+   _OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
+   NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD1, 0, gpmc_ad1, sdmmc2_dat1, NULL, NULL,
+   NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD2, 0, gpmc_ad2, sdmmc2_dat2, NULL, NULL,
+   NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD3, 0, gpmc_ad3, sdmmc2_dat3, NULL, NULL,
+   NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD4, 0, gpmc_ad4, sdmmc2_dat4,
+   sdmmc2_dir_dat0, NULL, NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD5, 0, gpmc_ad5, sdmmc2_dat5,
+   sdmmc2_dir_dat1, NULL, NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD6, 0, gpmc_ad6, sdmmc2_dat6,
+   sdmmc2_dir_cmd, NULL, NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD7, 0, gpmc_ad7, sdmmc2_dat7,
+   sdmmc2_clk_fdbk, NULL, NULL, NULL, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD8, 32, gpmc_ad8, kpd_row0, c2c_data15,
+   gpio_32, NULL, sdmmc1_dat0, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD9, 33, gpmc_ad9, kpd_row1, c2c_data14,
+   gpio_33, NULL, sdmmc1_dat1, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD10, 34, gpmc_ad10, kpd_row2, c2c_data13,
+   gpio_34, NULL, sdmmc1_dat2, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD11, 35, gpmc_ad11, kpd_row3, c2c_data12,
+   gpio_35, NULL, sdmmc1_dat3, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD12, 36, gpmc_ad12, kpd_col0, c2c_data11,
+   gpio_36, NULL, sdmmc1_dat4, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD13, 37, gpmc_ad13, kpd_col1, c2c_data10,
+   gpio_37, NULL, sdmmc1_dat5, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD14, 38, gpmc_ad14, kpd_col2, c2c_data9,
+   gpio_38, NULL, sdmmc1_dat6, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_AD15, 39, gpmc_ad15, kpd_col3, c2c_data8,
+   gpio_39, NULL, sdmmc1_dat7, NULL, NULL),
+   _OMAP4_MUXENTRY(GPMC_A16, 40, gpmc_a16, kpd_row4, c2c_datain0,
+   gpio_40, venc_656_data0, NULL, NULL, safe_mode),
+   _OMAP4_MUXENTRY(GPMC_A17, 41, gpmc_a17, kpd_row5, c2c_datain1,
+   gpio_41, venc_656_data1, NULL, NULL, safe_mode),
+   _OMAP4_MUXENTRY(GPMC_A18, 42, gpmc_a18, kpd_row6, c2c_datain2,
+   gpio_42, venc_656_data2, NULL, NULL, safe_mode),
+   _OMAP4_MUXENTRY(GPMC_A19, 43, gpmc_a19, kpd_row7, c2c_datain3,
+   gpio_43, venc_656_data3, NULL, 

[PATCH 7/7] OMAP4: pandaboard: Select CBL CBS package and initialize mux

[Benoit Cousson]

From: sricharan r.sricha...@ti.com

The mux framework allows the change of pad configuration by drivers
when needed. Prior to this the mux framework has to be initialised
with all the mux parameters specific to the board. The mux init is
already present in the board file for SDP. Adding the mux init
for panda boards.

Signed-off-by: sricharan r.sricha...@ti.com
Acked-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/Kconfig|2 ++
 arch/arm/mach-omap2/board-omap4panda.c |   16 
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 39229cf..186d270 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -290,6 +290,8 @@ config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
depends on ARCH_OMAP4
+   select OMAP_PACKAGE_CBL
+   select OMAP_PACKAGE_CBS
 
 config OMAP3_EMU
bool OMAP3 debugging peripherals
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 1ecd0a6..801f814 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -40,6 +40,7 @@
 
 #include hsmmc.h
 #include control.h
+#include mux.h
 
 #define GPIO_HUB_POWER 1
 #define GPIO_HUB_NRESET62
@@ -368,8 +369,23 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
 }
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux  NULL
+#endif
+
 static void __init omap4_panda_init(void)
 {
+   int package = OMAP_PACKAGE_CBS;
+
+   if (omap_rev() == OMAP4430_REV_ES1_0)
+   package = OMAP_PACKAGE_CBL;
+   omap4_mux_init(board_mux, package);
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
omap_serial_init();
-- 
1.7.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 v2 05/14] OMAP: Introduce device specific set rate and get rate in omap_device structure

[Kevin Hilman]

Thara Gopinath th...@ti.com writes:

 This patch extends the omap_device structure to contain
 pointers to scale the operating rate of the
 device and to retrieve the operating rate of the device.
 This patch also adds the three new APIs in the omap device layer
 namely omap_device_set_rate that can be called to set a new operating
 rate for a device, omap_device_get_rate that can be called to retrieve
 the operating frequency for a device and omap_device_populate_rate_fns
 to populte the device specific set_rate and get_rate API's.
 The omap_device_set_rate and omap_device_get_rate does some routine error
 checks and finally calls into the device specific set_rate
 and get_rate APIs populated through omap_device_populate_rate_fns.

 Signed-off-by: Thara Gopinath th...@ti.com
 ---
  arch/arm/plat-omap/include/plat/omap_device.h |9 +
  arch/arm/plat-omap/omap_device.c  |   49 
 +
  2 files changed, 58 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
 b/arch/arm/plat-omap/include/plat/omap_device.h
 index 28e2d1a..2a37345 100644
 --- a/arch/arm/plat-omap/include/plat/omap_device.h
 +++ b/arch/arm/plat-omap/include/plat/omap_device.h
 @@ -50,6 +50,8 @@ extern struct device omap_device_parent;
   * @hwmods: (one .. many per omap_device)
   * @hwmods_cnt: ARRAY_SIZE() of @hwmods
   * @pm_lats: ptr to an omap_device_pm_latency table
 + * @set_rate: fn ptr to change the operating rate.
 + * @get_rate: fn ptr to retrieve the current operating rate.
   * @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
   * @pm_lat_level: array index of the last odpl entry executed - -1 if never
   * @dev_wakeup_lat: dev wakeup latency in nanoseconds
 @@ -67,6 +69,8 @@ struct omap_device {
   struct platform_device  pdev;
   struct omap_hwmod   **hwmods;
   struct omap_device_pm_latency   *pm_lats;
 + int (*set_rate)(struct device *dev, unsigned long rate);
 + unsigned long (*get_rate) (struct device *dev);

minor nit, but I prefer the function pointers at the end.

   u32 dev_wakeup_lat;
   u32 _dev_wakeup_lat_limit;
   u8  pm_lats_cnt;
 @@ -107,6 +111,11 @@ void __iomem *omap_device_get_rt_va(struct omap_device 
 *od);
  int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
  struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
 +int omap_device_set_rate(struct device *dev, unsigned long freq);
 +unsigned long omap_device_get_rate(struct device *dev);
 +void omap_device_populate_rate_fns(struct device *dev,
 + int (*set_rate)(struct device *dev, unsigned long rate),
 + unsigned long (*get_rate) (struct device *dev));

how about omap_device_register_callbacks()

  /* Other */
  
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index 7c902a6..ffe06eb 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -785,6 +785,55 @@ int omap_device_enable_clocks(struct omap_device *od)
   return 0;
  }
  
 +int omap_device_set_rate(struct device *dev, unsigned long freq)
 +{
 + struct platform_device *pdev;
 + struct omap_device *od;
 +
 + pdev = container_of(dev, struct platform_device, dev);

pdev = to_platform_device(dev)

This helper is already defined in platform_device.h.

 + od = _find_by_pdev(pdev);
 +
 + if (!od-set_rate) {
 + dev_err(dev, %s: No set_rate API for scaling device\n,
 + __func__);
 + return -ENODATA;
 + }
 +
 + return od-set_rate(dev, freq);
 +}
 +
 +unsigned long omap_device_get_rate(struct device *dev)
 +{
 + struct platform_device *pdev;
 + struct omap_device *od;
 +
 + pdev = container_of(dev, struct platform_device, dev);

pdev = to_platform_device(dev)

 + od = _find_by_pdev(pdev);
 +
 +
 + if (!od-get_rate) {
 + dev_err(dev, %s: No get rate API for the device\n,
 + __func__);
 + return 0;
 + }
 +
 + return od-get_rate(dev);
 +}
 +
 +void omap_device_populate_rate_fns(struct device *dev,
 + int (*set_rate)(struct device *dev, unsigned long rate),
 + unsigned long (*get_rate) (struct device *dev))
 +{
 + struct platform_device *pdev;
 + struct omap_device *od;
 +
 + pdev = container_of(dev, struct platform_device, dev);

pdev = to_platform_device(dev)

 + od = _find_by_pdev(pdev);
 +
 + od-set_rate = set_rate;
 + od-get_rate = get_rate;
 +}
 +
  struct device omap_device_parent = {
   .init_name  = omap,
   .parent = platform_bus,

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  

Re: [PATCH v3 04/13] OMAP2420: DMA: hwmod: add system DMA

[Kevin Hilman]

Kevin Hilman khil...@deeprootsystems.com writes:

 G, Manjunath Kondaiah manj...@ti.com writes:

 Add OMAP2420 DMA hwmod structures.

 s/structures/data/

 Also, as pointed out in many other hwmod reviews, when adding hwmod
 data, subject should be something like: 

   OMAP2420: hwmod_data: add system DMA


Oops... no underscore here please.  IOW:

OMAP2420: hwmod data: add system DMA

Sorry for the confusion,

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

Re: [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS.

[Kevin Hilman]

Thara Gopinath th...@ti.com writes:

 This patch introduces an API to take in the voltage domain and the
 new voltage as parameter and to scale all the scalable devices
 associated with the the voltage domain to the rate corresponding to the
 new voltage and scale the voltage domain to the new voltage.

 Signed-off-by: Thara Gopinath th...@ti.com
 ---
  arch/arm/mach-omap2/voltage.c |   72 
 +
  arch/arm/plat-omap/include/plat/voltage.h |7 +++
  2 files changed, 79 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index 6c2e4ef..458f8c1 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -27,9 +27,11 @@
  #include linux/spinlock.h
  #include linux/plist.h
  #include linux/slab.h
 +#include linux/opp.h
  
  #include plat/common.h
  #include plat/voltage.h
 +#include plat/omap_device.h
  
  #include prm-regbits-34xx.h
  #include prm44xx.h
 @@ -1678,6 +1680,76 @@ struct voltagedomain *omap_voltage_domain_lookup(char 
 *name)
  }
  
  /**
 + * omap_voltage_scale : API to scale the devices associated with a
 + *   voltage domain vdd voltage.
 + * @volt_domain : the voltage domain to be scaled
 + * @volt : the new voltage for the voltage domain
 + *
 + * This API runs through the list of devices associated with the
 + * voltage domain and scales the device rates to those corresponding
 + * to the new voltage of the voltage domain. This API also scales
 + * the voltage domain voltage to the new value. Returns 0 on success
 + * else the error value.
 + */
 +int omap_voltage_scale(struct voltagedomain *voltdm, unsigned long volt)
 +{
 + unsigned long curr_volt;
 + int is_volt_scaled = 0;
 + struct omap_vdd_info *vdd;
 + struct omap_vdd_dev_list *temp_dev;
 +
 + if (!voltdm || IS_ERR(voltdm)) {
 + pr_warning(%s: VDD specified does not exist!\n, __func__);
 + return -EINVAL;
 + }
 +
 + vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
 +
 + mutex_lock(vdd-scaling_mutex);
 +
 + curr_volt = omap_voltage_get_nom_volt(voltdm);
 +
 + if (curr_volt == volt) {
 + is_volt_scaled = 1;
 + } else if (curr_volt  volt) {
 + omap_voltage_scale_vdd(voltdm, volt);
 + is_volt_scaled = 1;
 + }
 +
 + list_for_each_entry(temp_dev, vdd-dev_list, node) {
 + struct device *dev;
 + struct opp *opp;
 + unsigned long freq;
 +
 + dev = temp_dev-dev;
 +
 + opp = opp_find_voltage(dev, volt);
 + if (IS_ERR(opp)) {
 + dev_err(dev, %s: Unable to find OPP for
 + volt%ld\n, __func__, volt);
 + continue;
 + }
 +
 + freq = opp_get_freq(opp);
 +
 + if (freq == omap_device_get_rate(dev)) {
 + dev_warn(dev, %s: Already at the requested
 + rate %ld\n, __func__, freq);

Does this need to be a warning?  This happens relatively often and is normal.
This should probably just be removed in favor of

if (freq != omap_device_get_rate(dev)) 
omap_device_set_rate(dev, freq);

Kevin

 + continue;
 + }
 +
 + omap_device_set_rate(dev, freq);
 + }
 +
 + if (!is_volt_scaled)
 + omap_voltage_scale_vdd(voltdm, volt);
 +
 + mutex_unlock(vdd-scaling_mutex);
 +
 + return 0;
 +}
 +
 +/**
   * omap_voltage_init : Volatage init API which does VP and VC init.
   */
  static int __init omap_voltage_init(void)
 diff --git a/arch/arm/plat-omap/include/plat/voltage.h 
 b/arch/arm/plat-omap/include/plat/voltage.h
 index dc64a9a..54d50e2 100644
 --- a/arch/arm/plat-omap/include/plat/voltage.h
 +++ b/arch/arm/plat-omap/include/plat/voltage.h
 @@ -153,6 +153,7 @@ void omap_change_voltscale_method(int voltscale_method);
  int omap_voltage_add_request(struct voltagedomain *voltdm, struct device 
 *dev,
   unsigned long *volt);
  int omap_voltage_add_dev(struct voltagedomain *voltdm, struct device *dev);
 +int omap_voltage_scale(struct voltagedomain *voltdm, unsigned long volt);
  #else
  static inline void omap_voltage_register_pmic
   (struct omap_volt_pmic_info *pmic_info) {}
 @@ -169,6 +170,12 @@ static inline int omap_voltage_add_dev(struct 
 voltagedomain *voltdm,
  {
   return -EINVAL;
  }
 +
 +static inline int omap_voltage_scale(struct voltagedomain *voltdm,
 + unsigned long volt)
 +{
 + return -EINVAL;
 +}
  #endif
  
  #endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/14] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

[Kevin Hilman]

Thara Gopinath th...@ti.com writes:

 This patch introduces a user list of devices associated with each
 voltage domain instance. The user list is implemented using plist
 structure with priority node populated with the voltage values.
 This patch also adds an API which will take in a device and
 requested voltage as parameters, adds the info to the user list
 and returns back the maximum voltage requested by all the user
 devices. This can be used anytime to get the voltage that the
 voltage domain instance can be transitioned into.

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

[...]

 +/**
 + * omap_voltage_add_request() - API to keep track of various requests to
 + *   scale the VDD and returns the best possible
 + *   voltage the VDD can be put to.
 + * @volt_domain: pointer to the voltage domain.
 + * @dev: the device pointer.
 + * @volt:the voltage which is requested by the device.
 + *
 + * This API is to be called before the actual voltage scaling is
 + * done to determine what is the best possible voltage the VDD can
 + * be put to. This API adds the device dev in the user list of the
 + * vdd volt_domain with volt as the requested voltage. The user list
 + * is a plist with the priority element absolute voltage values.
 + * The API then finds the maximum of all the requested voltages for
 + * the VDD and returns it back through volt pointer itself.
 + * Returns error value in case of any errors.
 + */
 +int omap_voltage_add_request(struct voltagedomain *voltdm, struct device 
 *dev,
 + unsigned long *volt)
 +{
 + struct omap_vdd_info *vdd;
 + struct omap_vdd_user_list *user;
 + struct plist_node *node;
 + int found = 0;
 +
 + if (!voltdm || IS_ERR(voltdm)) {
 + pr_warning(%s: VDD specified does not exist!\n, __func__);
 + return -EINVAL;
 + }
 +
 + vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
 +
 + mutex_lock(vdd-scaling_mutex);
 +
 + plist_for_each_entry(user, vdd-user_list, node) {
 + if (user-dev == dev) {
 + found = 1;

please drop the use of 'found' here.  This can be solved using
a tmp iterator instead:

struct omap_vdd_user_list *tmp_user, *user = NULL;

plist_for_each_entry(tmp_user, vdd-user_list, node)
if (tmp_user-dev == dev) {
user = tmp_user;
break;
}

 + break;
 + }
 + }
 +
 + if (!found) {

if (!user) {

 + user = kzalloc(sizeof(struct omap_vdd_user_list), GFP_KERNEL);
 + if (!user) {
 + pr_err(%s: Unable to creat a new user for vdd_%s\n,
 + __func__, voltdm-name);
 + mutex_unlock(vdd-scaling_mutex);
 + return -ENOMEM;
 + }
 + user-dev = dev;
 + } else {
 + plist_del(user-node, vdd-user_list);
 + }
 +
 + plist_node_init(user-node, *volt);
 + plist_add(user-node, vdd-user_list);
 + node = plist_last(vdd-user_list);

The use of plist_last() doesn't seem right here. Won't plist_last()
return the node with the lowest voltage?, but this function is meant to
return the highest requested voltage.

I guess it currently works because it's only been tested with a single
requested voltage, so first and last are the same thing, but if I
understand the intent of the code correctly, I think it is broken if
ever there is more than one requester.

In [PATCH v2 07/14] OMAP: Introduce dependent voltage domain support, 
plist_first() is used to get the currently requesting node, so that is
what caused the confusion.   One side is using plist_first(), the other
plist_last() so one of them must be wrong.

 + *volt = user-volt = node-prio;
 +
 + mutex_unlock(vdd-scaling_mutex);
 +
 + return 0;
 +}

The above problems make me think that the 'request' and the 'get' part
of the above function should actually be separated out into two separate
functions.  One to add the request voltage, and another to query the
current max request.

The query function could then be used in patch 07/14 instead of using
plist directly.  That would clear up some of the confusion.

Kevin

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

Re: [PATCH v2 01/14] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

[Kevin Hilman]

Thara Gopinath th...@ti.com writes:

[...]

 +/**
   * omap_vdd_info - Per Voltage Domain info
   *
   * @volt_data: voltage table having the distinct voltages 
 supported
 @@ -95,9 +112,13 @@ struct vp_reg_val {
   * vp registers
   * @voltdm   : pointer to the voltage domain structure
   * @debug_dir: debug directory for this voltage domain.
 + * @user_lock: the lock to be used by the plist user_list
 + * @user_list: the list head maintaining the various users.
 + * @scaling_mutex: the dvfs muutex.
   ^^

h...  muutex,  that must be a Finnish mutex. ;)

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

[PATCH 0/4] omap fixes for v2.6.37-rc1

[Tony Lindgren]

Hi all,

Here are few fixes for review.

Regards,

Tony

---

Felipe Balbi (1):
  arm: omap1: devices: need to return with a value

Janusz Krzysztofik (1):
  OMAP1: camera.h: add missing include

Mathias Nyman (1):
  omap: dma: Add read-back to DMA interrupt handler to avoid 
spuriousinterrupts

Thomas Weber (1):
  OMAP2: Devkit8000: Fix mmc regulator failure


 arch/arm/mach-omap1/devices.c |5 ++---
 arch/arm/mach-omap1/include/mach/camera.h |2 ++
 arch/arm/mach-omap2/board-devkit8000.c|3 ---
 arch/arm/plat-omap/dma.c  |2 ++
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
Signature
--
To unsubscribe from this list: send the line unsubscribe 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/4] OMAP2: Devkit8000: Fix mmc regulator failure

[Tony Lindgren]

From: Thomas Weber we...@corscience.de

This patch fixes the following error:

regulator: VMMC1: 1850 -- 3150 mV at 3000 mV normal standby
twl_reg twl_reg.6: can't register VMMC1, -22
twl_reg: probe of twl_reg.6 failed with error -22

Signed-off-by: Thomas Weber we...@corscience.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-devkit8000.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 067f437..53ac762 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -242,9 +242,6 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
 
-   /* link regulators to MMC adapters */
-   devkit8000_vmmc1_supply.dev = mmc[0].dev;
-
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
 

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

[PATCH 2/4] omap: dma: Add read-back to DMA interrupt handler to avoid spuriousinterrupts

[Tony Lindgren]

From: Mathias Nyman mathias.ny...@nokia.com

Flush the writes to IRQSTATUS_L0 register in the DMA interrupt handler by 
reading the register
directly after write. This prevents the spurious DMA interrupts noted when 
using VDD_OPP 1

Signed-off-by: Mathias Nyman mathias.ny...@nokia.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/dma.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..2c28265 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1983,6 +1983,8 @@ static int omap2_dma_handle_ch(int ch)
 
dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR(ch));
dma_write(1  ch, IRQSTATUS_L0);
+   /* read back the register to flush the write */
+   dma_read(IRQSTATUS_L0);
 
/* If the ch is not chained then chain_id will be -1 */
if (dma_chan[ch].chain_id != -1) {

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

[PATCH 3/4] OMAP1: camera.h: add missing include

[Tony Lindgren]

From: Janusz Krzysztofik jkrzy...@tis.icnet.pl

#include media/omap1_camera.h directive is required to
compile the dependant boards (board-ams-delta for now).

Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
[t...@atomide.com: updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap1/include/mach/camera.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap1/include/mach/camera.h 
b/arch/arm/mach-omap1/include/mach/camera.h
index fd54b45..847d00f 100644
--- a/arch/arm/mach-omap1/include/mach/camera.h
+++ b/arch/arm/mach-omap1/include/mach/camera.h
@@ -1,6 +1,8 @@
 #ifndef __ASM_ARCH_CAMERA_H_
 #define __ASM_ARCH_CAMERA_H_
 
+#include media/omap1_camera.h
+
 void omap1_camera_init(void *);
 
 static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)

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

[PATCH 4/4] arm: omap1: devices: need to return with a value

[Tony Lindgren]

From: Felipe Balbi ba...@ti.com

Get rid of the following warning:

arch/arm/mach-omap1/devices.c: In function 'omap_init_wdt':
arch/arm/mach-omap1/devices.c:298: warning: 'return' with
no value, in function returning non-void

while at that, also change:

platform_device_register();
return 0;

into:

return platform_device_register();

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap1/devices.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index ea0d80a..e7f9ee6 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -321,10 +321,9 @@ static struct platform_device omap_wdt_device = {
 static int __init omap_init_wdt(void)
 {
if (!cpu_is_omap16xx())
-   return;
+   return -ENODEV;
 
-   platform_device_register(omap_wdt_device);
-   return 0;
+   return platform_device_register(omap_wdt_device);
 }
 subsys_initcall(omap_init_wdt);
 #endif

--
To unsubscribe from this list: send the line unsubscribe 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: [PATCHv2] OMAP: Serial: Define OMAP uart MDR1 register definitions

[Andrei Emeltchenko]

Hi,

On Thu, Nov 11, 2010 at 6:02 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Emeltchenko Andrei andrei.emeltchenko.n...@gmail.com writes:

 From: Andrei Emeltchenko andrei.emeltche...@nokia.com

 Define MDR1 register serial definitions used in serial and
 bluetooth drivers. Remove magic numbers there.

 Remove magic numbers where?  This patch doesn't remove anything.

We have code which is not yet upstream, it will come through Bluetooth
subtree at some point, I am also going to remove magic in
omapX/serial.c drivers in the next patches.

Do you think I need to add those patches?


 *v2   added OMAP keyword

 This info should go after the '---' as it is not needed in the final
 git history.

OK, will remove it.


 Kevin

 Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
 ---
  include/linux/serial_reg.h |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
 index c7a0ce1..6f38234 100644
 --- a/include/linux/serial_reg.h
 +++ b/include/linux/serial_reg.h
 @@ -341,5 +341,17 @@
  #define UART_OMAP_SYSS               0x16    /* System status register */
  #define UART_OMAP_WER                0x17    /* Wake-up enable register */

 +/*
 + * These are the definitions for the MDR1 register
 + */
 +#define UART_OMAP_MDR1_16X_MODE              0x00    /* UART 16x mode */
 +#define UART_OMAP_MDR1_SIR_MODE              0x01    /* SIR mode */
 +#define UART_OMAP_MDR1_16X_ABAUD_MODE        0x02    /* UART 16x auto-baud 
 */
 +#define UART_OMAP_MDR1_13X_MODE              0x03    /* UART 13x mode */
 +#define UART_OMAP_MDR1_MIR_MODE              0x04    /* MIR mode */
 +#define UART_OMAP_MDR1_FIR_MODE              0x05    /* FIR mode */
 +#define UART_OMAP_MDR1_CIR_MODE              0x06    /* CIR mode */
 +#define UART_OMAP_MDR1_DISABLE               0x07    /* Disable (default 
 state) */
 +
  #endif /* _LINUX_SERIAL_REG_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