Re: [PATCH v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

[Gregory CLEMENT]

 Hi Gregory,
 
Hi Grant,

 Patch does not apply, but I cannot immediately isolate the damage.
 Please see if you can figure out the issue on your end.  Is it your
 mailer?  I could fudge it, but in the long run it is better if this
 issue can get sorted out now.
 

I found the problem: see below in the patch itself.

 Also, a few other minor nitpicks (I won't reject a patch over these,
 but it helps to have them right):
 
 Please prefix spi patch names with spi[/driver]:.  It is the format
 for all spi patches I take through my tree, and if it already follows
 that convention, then I don't need to edit it manually.
 
 Second, please keep the line length in the patch description short; in
 general I find that a textwidth limit of 70 characters is about right
 for the purpose of reading/replying in email.  A lot of maintainers
 use text email clients like mutt in 80 column terminal windows.
 Keeping a reasonable right hand margin in the text body is simply
 friendly.
 
 Finally, in changelogs it is easier to read if there is some kind of
 itemization ticks.  For example:
 
 * Change from v5 to v6:
   - Rebase on linus/master (after 2.6.37-rc7)
   - Use CONFIG_SUSPEND instead of CONFIG_PM
   - Didn't use legacy PM methods anymore. Instead, add a struct
 dev_pm_ops and add the resume method there.
   - Fix multi-line comment style
  

I will fix these (patch prefix, wrapping and itemization ticks) and send the 
patch again today.

 g.
 
 ---
  drivers/spi/omap2_mcspi.c |   40 
  1 files changed, 40 insertions(+), 0 deletions(-)

 diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
 index 2a651e6..a17ea97 100644
 --- a/drivers/spi/omap2_mcspi.c
 +++ b/drivers/spi/omap2_mcspi.c
 @@ -1305,10 +1305,50 @@ static int __exit omap2_mcspi_remove(struct 
 platform_device *pdev)
  /* work with hotplug and coldplug */
  MODULE_ALIAS(platform:omap2_mcspi);
  +#ifdef CONFIG_SUSPEND
   ^
   |
Problem was here, I deleted a carrier in error :(

 +/*
 + * When SPI wake up from off-mode, CS is in activate state. If it was in
 + * unactive state when driver was suspend, then force it to unactive state 
 at
 + * wake up.
 + */
 +static int omap2_mcspi_resume(struct device *dev)
 +{
 +struct spi_master   *master = dev_get_drvdata(dev);
 +struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
 +struct omap2_mcspi_cs *cs;
 +
 +omap2_mcspi_enable_clocks(mcspi);
 +list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
 +node) {
 +if ((cs-chconf0  OMAP2_MCSPI_CHCONF_FORCE) == 0) {
 +
 +/*
 + * We need to toggle CS state for OMAP take this
 + * change in account.
 + */
 +MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
 +__raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 +MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
 +__raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 +}
 +}
 +omap2_mcspi_disable_clocks(mcspi);
 +return 0;
 +}
 +#else
 +#define omap2_mcspi_resume  NULL
 +#endif
 +
 +static const struct dev_pm_ops omap2_mcspi_pm_ops = {
 +.resume = omap2_mcspi_resume,
 +};
 +
  static struct platform_driver omap2_mcspi_driver = {
  .driver = {
  .name = omap2_mcspi,
  .owner =THIS_MODULE,
 +.pm =   omap2_mcspi_pm_ops
 +
 
 Drop the extra line.
 
  },
  .remove =   __exit_p(omap2_mcspi_remove),
  };
 -- 
 1.7.0.4



-- 
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: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 user-space crashed, not kernel-space; the code would continue to run
 and eventually release the lock.

 So you'll have to be more specific about the scenario you are describing.

 If there's a user thread that is still running the proc_*_dma()
 function, and we agree that this thread keeps running until completion
 and then returns to user space, what's the problem ?

The problem is if the user-space process crashes exactly in the middle
of it, *before* completing. With locks there's no problem, as
proc_un_map() would wait for the lock in my patch. In your patch it
would not wait, just return -EBUSY.

 If that user thread will crash, drv_remove_all_resources() will clean
 up all map_obj's.

Not if a proc_*_dma() is still running.

There's a very narrow timing window where this could happen, but it is there.

-- 
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: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Tue, Dec 28, 2010 at 4:48 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 I still don't know how exactly you triggered the bug: is gst-dsp
 multithreaded ? and one of its threads invoked proc_un_map() while
 another thread called proc_begin_dma() ?

 I haven't investigated why that happens

 Btw, I still think you should look into this.

 The kernel panic will be solved, but you may still have a race there
 that can lead to data corruption: if proc_un_map will be fast enough,
 it will acquire the proc_lock mutex before proc_begin_dma(), and then
 you will miss a cache operation.

Aquiring the lock is the first thing done; if proc_un_map() aquires
the lock first, it's because it was run first, and thus a problem for
user-space. If user-space wants the cache operation, it must run
proc_begin_dma() first, there's nothing kernel-space can do to fix
that.

-- 
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: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Ohad Ben-Cohen]

On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 user-space crashed, not kernel-space; the code would continue to run
 and eventually release the lock.

 So you'll have to be more specific about the scenario you are describing.

 If there's a user thread that is still running the proc_*_dma()
 function, and we agree that this thread keeps running until completion
 and then returns to user space, what's the problem ?

 The problem is if the user-space process crashes exactly in the middle
 of it, *before* completing. With locks there's no problem, as
 proc_un_map() would wait for the lock in my patch. In your patch it
 would not wait, just return -EBUSY.

We have two threads.

One called proc_un_map(), and one called proc_begin_dma().

The first crashed, but the second didn't. it still holds the bridge
device open. When it will exit, and release the device, then
drv_remove_all_resources() will be called, and all the map_obj's will
be cleaned.


 If that user thread will crash, drv_remove_all_resources() will clean
 up all map_obj's.

 Not if a proc_*_dma() is still running.

It will be called after it will return, and its thread will exit (or crash).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Tue, Dec 28, 2010 at 07:13:58PM -0600, Lambert, David wrote:

one blank line only. BTW, are these used anywwhere outside the dmic.c
driver ? If not, it's better to move the definitions there.



They were originally in the omap-dmic.h header, but it was suggested
that we move
them to a platform header so that the driver could be more
architecture independent
and we could put the platform specific details here.  I'm OK putting
them just about
anywhere, as long as we have consensus.


The thing I don't like about putting register definitions under
plat/*.h is that it creates the need for making the driver depends on
ARCH_OMAP because it's the only architecture which has that file. If
you put under linux/* or directly on the .c source file, you can have
a much needed compile test with several architectures.

Even though the driver will never work with those other archs, compile
testing with several of them isn't bad at all.


+#ifdef DEBUG
+static void omap_dmic_reg_dump(struct omap_dmic *dmic)
+{
+       dev_dbg(dmic-dev, ***\n);
+       dev_dbg(dmic-dev, OMAP_DMIC_IRQSTATUS_RAW:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_IRQSTATUS_RAW));
+       dev_dbg(dmic-dev, OMAP_DMIC_IRQSTATUS:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_IRQSTATUS));
+       dev_dbg(dmic-dev, OMAP_DMIC_IRQENABLE_SET:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_IRQENABLE_SET));
+       dev_dbg(dmic-dev, OMAP_DMIC_IRQENABLE_CLR:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_IRQENABLE_CLR));
+       dev_dbg(dmic-dev, OMAP_DMIC_IRQWAKE_EN:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_IRQWAKE_EN));
+       dev_dbg(dmic-dev, OMAP_DMIC_DMAENABLE_SET:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_DMAENABLE_SET));
+       dev_dbg(dmic-dev, OMAP_DMIC_DMAENABLE_CLR:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_DMAENABLE_CLR));
+       dev_dbg(dmic-dev, OMAP_DMIC_DMAWAKEEN:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_DMAWAKEEN));
+       dev_dbg(dmic-dev, OMAP_DMIC_CTRL:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_CTRL));
+       dev_dbg(dmic-dev, OMAP_DMIC_DATA:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_CTRL:  0x%04x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_CTRL));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC1R_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC1R_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC1L_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC1L_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC2R_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC2R_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC2L_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC2L_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC3R_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC3R_DATA));
+       dev_dbg(dmic-dev, OMAP_DMIC_FIFO_DMIC3L_DATA:  0x%08x\n,
+               omap_dmic_read(dmic, OMAP_DMIC_FIFO_DMIC3L_DATA));
+       dev_dbg(dmic-dev, ***\n);
+}
+#else
+static void omap_dmic_reg_dump(struct omap_dmic *dmic) {}
+#endif


Would be better to make a debugfs layer ??


I'll look in to what it would take to do this.  Could this be a
feature to add later?


It could, but this omap_dmic_reg_dump() really doesn't look nice. And
you even have a #undef DEBUG on the top of the file, which will require
code change to actually make this one work.


+static irqreturn_t omap_dmic_irq_handler(int irq, void *dev_id)
+{
+       struct omap_dmic *dmic = dev_id;
+       u32 irq_status;
+
+       irq_status = omap_dmic_read(dmic, OMAP_DMIC_IRQSTATUS);
+
+       /* Acknowledge irq event */
+       omap_dmic_write(dmic, OMAP_DMIC_IRQSTATUS, irq_status);
+       if (irq_status  OMAP_DMIC_IRQ_FULL)
+               dev_dbg(dmic-dev, DMIC FIFO error %x\n, irq_status);
+
+       if (irq_status  OMAP_DMIC_IRQ_EMPTY)
+               dev_dbg(dmic-dev, DMIC FIFO error %x\n, irq_status);
+
+       if (irq_status  OMAP_DMIC_IRQ)
+               dev_dbg(dmic-dev, DMIC write request\n);


no locking needed ??


+static int omap_dmic_dai_startup(struct snd_pcm_substream *substream,
+                                 struct snd_soc_dai *dai)
+{
+       struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+
+       if (!dmic-active++)
+               pm_runtime_get_sync(dmic-dev);
+
+       return 0;
+}
+
+static void omap_dmic_dai_shutdown(struct snd_pcm_substream *substream,
+                                   struct snd_soc_dai *dai)
+{
+       struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+
+       if (!--dmic-active)
+               pm_runtime_put_sync(dmic-dev);


I could be wrong but I believe pm_runtime implementation on OMAP has
its own refcounting, so you could drop the need for 

Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Wed, Dec 29, 2010 at 11:46 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 user-space crashed, not kernel-space; the code would continue to run
 and eventually release the lock.

 So you'll have to be more specific about the scenario you are describing.

 If there's a user thread that is still running the proc_*_dma()
 function, and we agree that this thread keeps running until completion
 and then returns to user space, what's the problem ?

 The problem is if the user-space process crashes exactly in the middle
 of it, *before* completing. With locks there's no problem, as
 proc_un_map() would wait for the lock in my patch. In your patch it
 would not wait, just return -EBUSY.

 We have two threads.

 One called proc_un_map(), and one called proc_begin_dma().

 The first crashed, but the second didn't. it still holds the bridge
 device open. When it will exit, and release the device, then
 drv_remove_all_resources() will be called, and all the map_obj's will
 be cleaned.

I'm not familiar how crashes are handled; if you say as long as one
task is still running the device release is not called, then I guess
there's no issue.

-- 
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: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Liam Girdwood]

On Wed, 2010-12-29 at 11:47 +0200, Felipe Balbi wrote:
 Hi,
 
 On Tue, Dec 28, 2010 at 07:13:58PM -0600, Lambert, David wrote:
  one blank line only. BTW, are these used anywwhere outside the dmic.c
  driver ? If not, it's better to move the definitions there.
 
 
 They were originally in the omap-dmic.h header, but it was suggested
 that we move
 them to a platform header so that the driver could be more
 architecture independent
 and we could put the platform specific details here.  I'm OK putting
 them just about
 anywhere, as long as we have consensus.
 
 The thing I don't like about putting register definitions under
 plat/*.h is that it creates the need for making the driver depends on
 ARCH_OMAP because it's the only architecture which has that file. If
 you put under linux/* or directly on the .c source file, you can have
 a much needed compile test with several architectures.
 
 Even though the driver will never work with those other archs, compile
 testing with several of them isn't bad at all.

This seems unnecessary since this driver is for the OMAP platform only
and also means maintainers will have to waste time fixing any build
issues for this driver on irrelevant architectures. The costs here
outweigh any benefits

It also seems inconsistent with the other OMAP system headers in
plat-omap too.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

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

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Wed, Dec 29, 2010 at 10:35:31AM +, Liam Girdwood wrote:

Even though the driver will never work with those other archs, compile
testing with several of them isn't bad at all.


This seems unnecessary since this driver is for the OMAP platform only
and also means maintainers will have to waste time fixing any build
issues for this driver on irrelevant architectures. The costs here
outweigh any benefits


If that's the case, what's the use for linux-next, then ? Drivers should
be arch independent as much as possible, no ? Isn't that why we don't
want drivers using branches to things such as machine_is_omap4_panda()
or similar ?

But the whole audio part on OMAP is still in a bad shape anyway, e.g.
mcbsp exports omap-only functions for drivers to use, so this will only
be yet another driver to the pile :-p


It also seems inconsistent with the other OMAP system headers in
plat-omap too.


Other than a few drivers which still need converting (and are on their
way) I can only see really arch-specific bits and pieces under plat/.

Not sure what's your point here.

--
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 1/1] omap-sham: backlog handling fix

[Herbert Xu]

On Wed, Dec 29, 2010 at 11:58:28AM +0200, Dmitry Kasatkin wrote:
 Previous commit removed redundant locking introduced
 a bug in handling backlog.
 In certain cases, when async request complete callback will
 call complete() on -EINPROGRESS code, it will cause uncompleted requests.
 It does not happen in implementation similar to crypto test manager,
 but it will happen in implementation similar to dm-crypt.
 Backlog needs to be checked before dequeuing next request.
 
 Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com

Patch applied.  Thanks Dmitry.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe 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 v7 1/1] spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition

[Gregory CLEMENT]

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

Changelog:
* Change from v1 to v2:
  - Rebase on linus/master (after 2.6.37-rc1)
  - Do some clean-up and fix indentation on both patches
  - Add more explanations for patch 2

* Change from v2 to v3:
  - Use directly resume function of spi_master instead of using function
  - from spi_device as Grant Likely pointed it out.
  - Force this transition explicitly for each CS used by a device.

* Change from v3 to v4:
  - Patch clean-up according to Kevin Hilman and checkpatch.
  - Now force CS to be in inactive state only if it was inactive when it was
suspended.

* Change from v4 to v5:
  - Rebase on linus/master (after 2.6.37-rc3)
  - Collapse some lines as pointed by Grant Likely
  - Fix a spelling

* Change from v5 to v6:
  - Rebase on linus/master (after 2.6.37-rc7)
  - Use CONFIG_SUSPEND instead of CONFIG_PM
  - Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and
add the resume method there.
  - Fix multi-line comment style

* Change from v6 to v7:
  - Rebase on linus/master (after 2.6.37-rc8)
  - Drop an extra line

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com

---
 drivers/spi/omap2_mcspi.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..951a160 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,10 +1305,49 @@ static int __exit omap2_mcspi_remove(struct 
platform_device *pdev)
 /* work with hotplug and coldplug */
 MODULE_ALIAS(platform:omap2_mcspi);

+#ifdef CONFIG_SUSPEND
+/*
+ * When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct device *dev)
+{
+   struct spi_master   *master = dev_get_drvdata(dev);
+   struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
+   struct omap2_mcspi_cs *cs;
+
+   omap2_mcspi_enable_clocks(mcspi);
+   list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+   node) {
+   if ((cs-chconf0  OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+   /*
+* We need to toggle CS state for OMAP take this
+* change in account.
+*/
+   MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+   __raw_writel(cs-chconf0, cs-base + 
OMAP2_MCSPI_CHCONF0);
+   MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+   __raw_writel(cs-chconf0, cs-base + 
OMAP2_MCSPI_CHCONF0);
+   }
+   }
+   omap2_mcspi_disable_clocks(mcspi);
+   return 0;
+}
+#else
+#defineomap2_mcspi_resume  NULL
+#endif
+
+static const struct dev_pm_ops omap2_mcspi_pm_ops = {
+   .resume = omap2_mcspi_resume,
+};
+
 static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
+   .pm =   omap2_mcspi_pm_ops
},
.remove =   __exit_p(omap2_mcspi_remove),
 };
-- 
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 v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

[Gregory CLEMENT]

On 12/29/2010 10:01 AM, Gregory CLEMENT wrote:
 Hi Gregory,

 Hi Grant,
 
 Patch does not apply, but I cannot immediately isolate the damage.
 Please see if you can figure out the issue on your end.  Is it your
 mailer?  I could fudge it, but in the long run it is better if this
 issue can get sorted out now.

 
 I found the problem: see below in the patch itself.
 
Indeed it was may mailer which had broken the patch. I use
git-format-patch and git imap send to create the mail. But when I
open it from the draft folder to add the email address, it decides
by itself to remove an end of line!
It is not the first time that I have some problems with Thunderbird.
I consider changing my mailer to a more hacker friendly one.

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

[PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+

[Mika Westerberg]

In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
updating reg and l values. However, at the end of the function we
perform a write:

__raw_writel(l, reg);

So on OMAP2+ we end up writing 0 to the bank-base which is not
correct (typically this points to GPIO_REVISION register).

Fix this by returning immediately after call to
set_24xx_gpio_triggering().

Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com
---
 arch/arm/plat-omap/gpio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..4dcb66f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -867,7 +867,7 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int 
gpio, int trigger)
case METHOD_GPIO_24XX:
case METHOD_GPIO_44XX:
set_24xx_gpio_triggering(bank, gpio, trigger);
-   break;
+   return 0;
 #endif
default:
goto bad;
-- 
1.7.3.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: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Liam Girdwood]

On Wed, 2010-12-29 at 12:44 +0200, Felipe Balbi wrote:
 Hi,
 
 On Wed, Dec 29, 2010 at 10:35:31AM +, Liam Girdwood wrote:
  Even though the driver will never work with those other archs, compile
  testing with several of them isn't bad at all.
 
 This seems unnecessary since this driver is for the OMAP platform only
 and also means maintainers will have to waste time fixing any build
 issues for this driver on irrelevant architectures. The costs here
 outweigh any benefits
 
 If that's the case, what's the use for linux-next, then ? Drivers should
 be arch independent as much as possible, no ? Isn't that why we don't
 want drivers using branches to things such as machine_is_omap4_panda()
 or similar ?
 

I agree that drivers should be arch independent when possible, but in
this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found
on OMAP silicon.

I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but
what happens when the driver builds fine for OMAP but breaks the PXA,
MIPS, SuperH build ? Who will spend time to fix and test it ?

My main problem here is cost benefit. No one benefits directly by having
this driver available for the above platforms but it costs me time
fixing it when it breaks. 

 But the whole audio part on OMAP is still in a bad shape anyway, e.g.
 mcbsp exports omap-only functions for drivers to use, so this will only
 be yet another driver to the pile :-p
 

In this case though the other McBSP user afaik is DaVinci, so in this
case it does make sense to make this driver support both.

 It also seems inconsistent with the other OMAP system headers in
 plat-omap too.
 
 Other than a few drivers which still need converting (and are on their
 way) I can only see really arch-specific bits and pieces under plat/.
 
 Not sure what's your point here.
 

The point is that David had split the DMIC headers into two files, one
for plat specific registers and bit definitions and the other for audio
definitions (for the machine drivers) and is/was consistent with the
current OMAP platform headers. 

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

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

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Mark Brown]

On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:

 In this case though the other McBSP user afaik is DaVinci, so in this
 case it does make sense to make this driver support both.

The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to audio use (though as I understand it
other uses are very rare).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Wed, Dec 29, 2010 at 11:56:28AM +, Mark Brown wrote:

In this case though the other McBSP user afaik is DaVinci, so in this
case it does make sense to make this driver support both.


The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to audio use (though as I understand it
other uses are very rare).


So why is it still tied to OMAP-only ? There's no abstraction layer
around McBSP so OMAP McBSP driver has to export a whole bunch of symbols
for its users:

$ git grep -e EXPORT_SYMBOL arch/arm/*omap*/*mcbsp*.c
arch/arm/mach-omap2/mcbsp.c:EXPORT_SYMBOL(omap2_mcbsp1_mux_clkr_src);
arch/arm/mach-omap2/mcbsp.c:EXPORT_SYMBOL(omap2_mcbsp1_mux_fsr_src);
arch/arm/mach-omap2/mcbsp.c:EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_config);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_st_set_chgain);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_st_get_chgain);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_st_enable);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_st_disable);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_st_is_enabled);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_max_tx_threshold);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_fifo_size);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_tx_delay);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_rx_delay);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_set_io_type);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_request);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_free);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_start);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_stop);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_pollwrite);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_pollread);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_xmit_word);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_recv_word);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_spi_master_xmit_word_poll);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_spi_master_recv_word_poll);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_xmit_buffer);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_recv_buffer);
arch/arm/plat-omap/mcbsp.c:EXPORT_SYMBOL(omap_mcbsp_set_spi_mode);

--
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 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:

I agree that drivers should be arch independent when possible, but in
this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found
on OMAP silicon.


Let's imagine this IP is sourced from someone else and not created by
TI, what prevents company XYZ from sourcing the same IP and end up
re-using the driver ?


I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but
what happens when the driver builds fine for OMAP but breaks the PXA,
MIPS, SuperH build ? Who will spend time to fix and test it ?


You forgetting about other ARMs. This won't compile on DaVinci either.


My main problem here is cost benefit. No one benefits directly by having
this driver available for the above platforms but it costs me time
fixing it when it breaks.


Of course there's people benefitting: OMAP audio driver writers would
know their driver is well written and doesn't break build for anybody.

Ok, let me put it this way:

What happens when you want have one kernel image for OMAP and DaVinci ?
Granted, that's not possible today anyway but e.g. Linaro is pushing for
it and IMO should be the way to go for us to be able to have a
distro-like kernel for ARM-based systems too.


It also seems inconsistent with the other OMAP system headers in
plat-omap too.

Other than a few drivers which still need converting (and are on their
way) I can only see really arch-specific bits and pieces under plat/.

Not sure what's your point here.



The point is that David had split the DMIC headers into two files, one
for plat specific registers and bit definitions and the other for audio
definitions (for the machine drivers) and is/was consistent with the
current OMAP platform headers.


You forgot to mention that plat/ headers are supposed to be used by
plat-* and mach-* code only to setup the correct state for the driver.
Just recently one of the musb glue layers got broken because it was
mistakenly using plat/control.h and that got moved.

That's actually my point and why I think drivers should not touch plat/*
and mach/* headers.

--
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 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Mark Brown]

On Wed, Dec 29, 2010 at 01:59:24PM +0200, Felipe Balbi wrote:
 On Wed, Dec 29, 2010 at 11:56:28AM +, Mark Brown wrote:

 The other thing with McBSP is that it's a generic programmable serial
 port and so need not be tied to audio use (though as I understand it
 other uses are very rare).

 So why is it still tied to OMAP-only ? There's no abstraction layer
 around McBSP so OMAP McBSP driver has to export a whole bunch of symbols
 for its users:

As far as I know the hardware has not been used on other platforms - all
the people who care specifically about the driver are using OMAP and
don't see any reason to do the work.  There's really no pressure to do
this.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Liam Girdwood]

On Wed, 2010-12-29 at 14:04 +0200, Felipe Balbi wrote:
 Hi,
 
 On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:
 I agree that drivers should be arch independent when possible, but in
 this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
 i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found
 on OMAP silicon.
 
 Let's imagine this IP is sourced from someone else and not created by
 TI, what prevents company XYZ from sourcing the same IP and end up
 re-using the driver ?

That's fine, but this is not the case atm for this particular DMIC IP
and we can only justify effort for OMAP atm.

 
 I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but
 what happens when the driver builds fine for OMAP but breaks the PXA,
 MIPS, SuperH build ? Who will spend time to fix and test it ?
 
 You forgetting about other ARMs. This won't compile on DaVinci either.
 
 My main problem here is cost benefit. No one benefits directly by having
 this driver available for the above platforms but it costs me time
 fixing it when it breaks.
 
 Of course there's people benefitting: OMAP audio driver writers would
 know their driver is well written and doesn't break build for anybody.
 
 Ok, let me put it this way:
 
 What happens when you want have one kernel image for OMAP and DaVinci ?
 Granted, that's not possible today anyway but e.g. Linaro is pushing for
 it and IMO should be the way to go for us to be able to have a
 distro-like kernel for ARM-based systems too.
 

Ok, I now think you meant other ARM architectures here than other
Linux architectures in general. It does make a more sense for ARM
distribution deployment, but I still think guaranteeing successful build
for this driver on all non ARM architectures atm just to give us
satisfaction that the driver is well written is unnecessary effort.

  It also seems inconsistent with the other OMAP system headers in
  plat-omap too.
 
  Other than a few drivers which still need converting (and are on their
  way) I can only see really arch-specific bits and pieces under plat/.
 
  Not sure what's your point here.
 
 
 The point is that David had split the DMIC headers into two files, one
 for plat specific registers and bit definitions and the other for audio
 definitions (for the machine drivers) and is/was consistent with the
 current OMAP platform headers.
 
 You forgot to mention that plat/ headers are supposed to be used by
 plat-* and mach-* code only to setup the correct state for the driver.
 Just recently one of the musb glue layers got broken because it was
 mistakenly using plat/control.h and that got moved.
 
 That's actually my point and why I think drivers should not touch plat/*
 and mach/* headers.
 

In a lot of cases drivers under drivers/* and sound/* must touch plat/*
and mach/* headers for runtime access to hardware IP. I've just grepped
and the list is quite long for drivers/*

Liam


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

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Wed, Dec 29, 2010 at 01:00:00PM +, Liam Girdwood wrote:

Ok, I now think you meant other ARM architectures here than other
Linux architectures in general. It does make a more sense for ARM
distribution deployment, but I still think guaranteeing successful build
for this driver on all non ARM architectures atm just to give us
satisfaction that the driver is well written is unnecessary effort.


Ok.


In a lot of cases drivers under drivers/* and sound/* must touch plat/*
and mach/* headers for runtime access to hardware IP. I've just grepped
and the list is quite long for drivers/*


IMHO that's wrong :-p But that's only my opinion. Anyway, I'm ok with
your decision FWIW.

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

[PATCH v7 0/7] nand prefetch-irq support and ecc layout chanage

[Sukumar Ghorai]

The following set of patches applies on linux-2.6.

The main motivations behind this patch series are -
1. support NAND I/O in irq mode.
2. support of different ECC schema.
3. also add support ecc layout as like in romcode ecc layout, but not 
enabled

v7: NAND type (x16 or x8) is board specific and not omap specific; this passed 
form board file.

v6: configurable transfer type from board file; 
#define irq number used for nand-irq
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39397.html

v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html
This address the input as to support the irq_chained in GPMC.
And resend of
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html

v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html
and resend of
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html

v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html
Rebase on latest codebase and previous patch(posted).
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html

v2: Rebase on latest codebase and previous patch(posted).
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html

v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html

Sukumar Ghorai (7):
  omap3630: nand: fix device size to work in polled mode
  omap3: nand: configurable transfer type per board
  omap: gpmc: enable irq mode in gpmc
  omap3: nand: prefetch in irq mode support
  omap3: nand: configurable fifo threshold to gain the throughput
  omap3: nand: ecc layout select from board file
  omap3: nand: making ecc layout as compatible with romcode ecc

 arch/arm/mach-omap2/board-2430sdp.c|1 +
 arch/arm/mach-omap2/board-3430sdp.c|3 +-
 arch/arm/mach-omap2/board-3630sdp.c|4 +-
 arch/arm/mach-omap2/board-4430sdp.c|2 +
 arch/arm/mach-omap2/board-am3517evm.c  |2 +
 arch/arm/mach-omap2/board-apollon.c|1 +
 arch/arm/mach-omap2/board-cm-t35.c |1 +
 arch/arm/mach-omap2/board-devkit8000.c |1 +
 arch/arm/mach-omap2/board-flash.c  |   13 +-
 arch/arm/mach-omap2/board-flash.h  |4 +-
 arch/arm/mach-omap2/board-generic.c|2 +
 arch/arm/mach-omap2/board-h4.c |1 +
 arch/arm/mach-omap2/board-igep0020.c   |1 +
 arch/arm/mach-omap2/board-ldp.c|3 +-
 arch/arm/mach-omap2/board-n8x0.c   |2 +
 arch/arm/mach-omap2/board-omap3beagle.c|1 +
 arch/arm/mach-omap2/board-omap3evm.c   |2 +
 arch/arm/mach-omap2/board-omap3pandora.c   |2 +
 arch/arm/mach-omap2/board-omap3stalker.c   |1 +
 arch/arm/mach-omap2/board-omap3touchbook.c |1 +
 arch/arm/mach-omap2/board-omap4panda.c |2 +
 arch/arm/mach-omap2/board-overo.c  |1 +
 arch/arm/mach-omap2/board-rx51.c   |1 +
 arch/arm/mach-omap2/board-zoom2.c  |7 +-
 arch/arm/mach-omap2/board-zoom3.c  |7 +-
 arch/arm/mach-omap2/gpmc-nand.c|7 +-
 arch/arm/mach-omap2/gpmc.c |   50 -
 arch/arm/mach-omap2/io.c   |2 -
 arch/arm/plat-omap/include/plat/gpmc.h |   17 ++-
 arch/arm/plat-omap/include/plat/irqs.h |9 +-
 arch/arm/plat-omap/include/plat/nand.h |   11 +
 drivers/mtd/nand/Kconfig   |   17 --
 drivers/mtd/nand/omap2.c   |  336 +---
 33 files changed, 396 insertions(+), 119 deletions(-)

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

[PATCH v7 1/7] omap3630: nand: fix device size to work in polled mode

[Sukumar Ghorai]

zoom3 and 3630-sdp having the x16 nand device.
This patch configure gpmc as x16 and select the currect function in driver
for polled mode (without prefetch enable) transfer.

Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c |2 +-
 arch/arm/mach-omap2/board-3630sdp.c |3 ++-
 arch/arm/mach-omap2/board-flash.c   |   10 ++
 arch/arm/mach-omap2/board-flash.h   |4 ++--
 arch/arm/mach-omap2/board-ldp.c |2 +-
 arch/arm/mach-omap2/board-zoom2.c   |5 +++--
 arch/arm/mach-omap2/board-zoom3.c   |5 +++--
 arch/arm/mach-omap2/gpmc-nand.c |7 +--
 drivers/mtd/nand/omap2.c|2 +-
 9 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..470872e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -809,7 +809,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_smc91x_init();
-   board_flash_init(sdp_flash_partitions, chip_sel_3430);
+   board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..0a74141 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -11,6 +11,7 @@
 #include linux/platform_device.h
 #include linux/input.h
 #include linux/gpio.h
+#include linux/mtd/nand.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -210,7 +211,7 @@ static void __init omap_sdp_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
board_smc91x_init();
-   board_flash_init(sdp_flash_partitions, chip_sel_sdp);
+   board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
 }
diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index fd38c05..f6b7253 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -139,11 +139,13 @@ static struct omap_nand_platform_data board_nand_data = {
 };
 
 void
-__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs)
+__init board_nand_init(struct mtd_partition *nand_parts,
+   u8 nr_parts, u8 cs, int nand_type)
 {
board_nand_data.cs  = cs;
board_nand_data.parts   = nand_parts;
-   board_nand_data.nr_parts= nr_parts;
+   board_nand_data.nr_parts= nr_parts;
+   board_nand_data.devsize = nand_type;
 
gpmc_nand_init(board_nand_data);
 }
@@ -194,7 +196,7 @@ unmap:
  * @return - void.
  */
 void board_flash_init(struct flash_partitions partition_info[],
-   char chip_sel_board[][GPMC_CS_NUM])
+   char chip_sel_board[][GPMC_CS_NUM], int nand_type)
 {
u8  cs = 0;
u8  norcs = GPMC_CS_NUM + 1;
@@ -250,5 +252,5 @@ void board_flash_init(struct flash_partitions 
partition_info[],
in GPMC\n);
else
board_nand_init(partition_info[2].parts,
-   partition_info[2].nr_parts, nandcs);
+   partition_info[2].nr_parts, nandcs, nand_type);
 }
diff --git a/arch/arm/mach-omap2/board-flash.h 
b/arch/arm/mach-omap2/board-flash.h
index 69befe0..c240a3f 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -25,6 +25,6 @@ struct flash_partitions {
 };
 
 extern void board_flash_init(struct flash_partitions [],
-   char chip_sel[][GPMC_CS_NUM]);
+   char chip_sel[][GPMC_CS_NUM], int nand_type);
 extern void board_nand_init(struct mtd_partition *nand_parts,
-   u8 nr_parts, u8 cs);
+   u8 nr_parts, u8 cs, int nand_type);
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 001fd97..b088b1d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -436,7 +436,7 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_nand_init(ldp_nand_partitions,
-   ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS);
+   ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS, 0);
 
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
diff --git a/arch/arm/mach-omap2/board-zoom2.c 
b/arch/arm/mach-omap2/board-zoom2.c
index 2992a9f..994d286 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -15,6 

[PATCH v7 5/7] omap3: nand: configurable fifo threshold to gain the throughput

[Sukumar Ghorai]

Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.

Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   11 +++
 arch/arm/plat-omap/include/plat/gpmc.h |5 -
 drivers/mtd/nand/omap2.c   |   22 ++
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index cfaf357..b26b1a5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
 #define GPMC_CHUNK_SHIFT   24  /* 16 MB */
 #define GPMC_SECTION_SHIFT 28  /* 128 MB */
 
-#define PREFETCH_FIFOTHRESHOLD (0x40  8)
 #define CS_NUM_SHIFT   24
 #define ENABLE_PREFETCH(0x1  7)
 #define DMA_MPU_MODE   2
@@ -595,15 +594,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
 /**
  * gpmc_prefetch_enable - configures and starts prefetch transfer
  * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
  * @dma_mode: dma mode enable (1) or disable (0)
  * @u32_count: number of bytes to be transferred
  * @is_write: prefetch read(0) or write post(1) mode
  */
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
 {
 
-   if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+   if (fifo_th  PREFETCH_FIFOTHRESHOLD_MAX) {
+   printk(KERN_ERR PREFETCH Fifo Threshold is not supported\n);
+   return -1;
+   } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
 
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
 * enable the engine. Set which cs is has requested for.
 */
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs  CS_NUM_SHIFT) |
-   PREFETCH_FIFOTHRESHOLD |
+   PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode  DMA_MPU_MODE) |
(0x1  is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
 #define GPMC_IRQ_FIFOEVENTENABLE   0x01
 #define GPMC_IRQ_COUNT_EVENT   0x02
 
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val  8)
+
 /*
  * Note that all values in this struct are in nanoseconds, while
  * the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size, 
unsigned long *base);
 extern void gpmc_cs_free(int cs);
 extern int gpmc_cs_set_reserved(int cs, int reserved);
 extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
 extern int gpmc_prefetch_reset(int cs);
 extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 007862e..384d89b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -243,7 +243,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char 
*buf, int len)
}
 
/* configure and start prefetch transfer */
-   ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+   ret = gpmc_prefetch_enable(info-gpmc_cs,
+   PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options  NAND_BUSWIDTH_16)
@@ -287,7 +288,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
 
/*  configure and start prefetch transfer */
-   ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+   ret = gpmc_prefetch_enable(info-gpmc_cs,
+   PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options  NAND_BUSWIDTH_16)
@@ -340,8 +342,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
 
-   /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+   /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+* and 

[PATCH v7 7/7] omap3: nand: making ecc layout as compatible with romcode ecc

[Sukumar Ghorai]

This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.

This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.

This patch does not enables this feature by default and need to pass from
board file to enable for any board.

Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/plat-omap/include/plat/gpmc.h |2 +
 drivers/mtd/nand/omap2.c   |   37 +++-
 2 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 28a5607..fcc0530 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -90,6 +90,8 @@ enum omap_ecc {
/* 1-bit ecc: stored at end of spare area */
OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+   /* 1-bit ecc: stored at begining of spare area as romcode */
+   OMAP_ECC_HAMMING_CODE_HW_ROMCODE, /* gpmc method  romcode layout */
 };
 
 /*
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c6f3ea9..72af2d9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -97,6 +97,20 @@
 static const char *part_probes[] = { cmdlinepart, NULL };
 #endif
 
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+   .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+   .offs = 0,
+   .len = 1,
+   .pattern = scan_ff_pattern,
+};
+
+
 struct omap_nand_info {
struct nand_hw_control  controller;
struct omap_nand_platform_data  *pdata;
@@ -906,6 +920,7 @@ static int __devinit omap_nand_probe(struct platform_device 
*pdev)
struct omap_nand_info   *info;
struct omap_nand_platform_data  *pdata;
int err;
+   int i, offset;
 
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1029,7 +1044,8 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
/* selsect the ecc type */
if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
info-nand.ecc.mode = NAND_ECC_SOFT;
-   else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+   else if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
+   (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
info-nand.ecc.bytes= 3;
info-nand.ecc.size = 512;
info-nand.ecc.calculate= omap_calculate_ecc;
@@ -1049,6 +1065,25 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
}
}
 
+   /* rom code layout */
+   if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+
+   if (info-nand.options  NAND_BUSWIDTH_16)
+   offset = 2;
+   else {
+   offset = 1;
+   info-nand.badblock_pattern = bb_descrip_flashbased;
+   }
+   omap_oobinfo.eccbytes = 3 * (info-mtd.oobsize/16);
+   for (i = 0; i  omap_oobinfo.eccbytes; i++)
+   omap_oobinfo.eccpos[i] = i+offset;
+
+   omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+   omap_oobinfo.oobfree-length = info-mtd.oobsize -
+   (offset + omap_oobinfo.eccbytes);
+
+   info-nand.ecc.layout = omap_oobinfo;
+   }
 
 #ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 4/7] omap3: nand: prefetch in irq mode support

[Sukumar Ghorai]

This patch enable prefetch-irq mode for nand transfer(read, write)

Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/board-flash.c  |2 +
 arch/arm/plat-omap/include/plat/nand.h |4 +-
 drivers/mtd/nand/omap2.c   |  169 
 3 files changed, 174 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index f6b7253..1964509 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,6 +16,7 @@
 #include linux/platform_device.h
 #include linux/mtd/physmap.h
 #include linux/io.h
+#include plat/irqs.h
 
 #include plat/gpmc.h
 #include plat/nand.h
@@ -147,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
 
+   board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
 }
 #else
diff --git a/arch/arm/plat-omap/include/plat/nand.h 
b/arch/arm/plat-omap/include/plat/nand.h
index 78c0bdb..ae5e053 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -13,7 +13,8 @@
 enum nand_io {
NAND_OMAP_PREFETCH_POLLED = 0,  /* prefetch polled mode, default */
NAND_OMAP_POLLED,   /* polled mode, without prefetch */
-   NAND_OMAP_PREFETCH_DMA  /* prefetch enabled sDMA mode */
+   NAND_OMAP_PREFETCH_DMA, /* prefetch enabled sDMA mode */
+   NAND_OMAP_PREFETCH_IRQ  /* prefetch enabled irq mode */
 };
 
 struct omap_nand_platform_data {
@@ -26,6 +27,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+   int gpmc_irq;
enum nand_ioxfer_type;
unsigned long   phys_base;
int devsize;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 66b7428..007862e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -11,6 +11,7 @@
 #include linux/platform_device.h
 #include linux/dma-mapping.h
 #include linux/delay.h
+#include linux/interrupt.h
 #include linux/jiffies.h
 #include linux/sched.h
 #include linux/mtd/mtd.h
@@ -108,6 +109,13 @@ struct omap_nand_info {
unsigned long   phys_base;
struct completion   comp;
int dma_ch;
+   int gpmc_irq;
+   enum {
+   OMAP_NAND_IO_READ = 0,  /* read */
+   OMAP_NAND_IO_WRITE, /* write */
+   } iomode;
+   u_char  *buf;
+   int buf_len;
 };
 
 /**
@@ -436,6 +444,153 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
 }
 
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+   struct omap_nand_info *info = (struct omap_nand_info *) dev;
+   u32 bytes;
+   u32 irq_stat;
+
+   irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+   bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+   bytes = bytes   0xFFFC; /* io in multiple of 4 bytes */
+   if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
+   if (irq_stat  0x2)
+   goto done;
+
+   if (info-buf_len  (info-buf_len  bytes))
+   bytes = info-buf_len;
+   else if (!info-buf_len)
+   bytes = 0;
+   iowrite32_rep(info-nand.IO_ADDR_W,
+   (u32 *)info-buf, bytes  2);
+   info-buf = info-buf + bytes;
+   info-buf_len -= bytes;
+
+   } else {
+   ioread32_rep(info-nand.IO_ADDR_R,
+   (u32 *)info-buf, bytes  2);
+   info-buf = info-buf + bytes;
+
+   if (irq_stat  0x2)
+   goto done;
+   }
+   gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+   irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+   return IRQ_HANDLED;
+
+done:
+   complete(info-comp);
+   /* disable irq */
+   gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+   /* clear status */
+   gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+   irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * omap_read_buf_irq_pref - read data from NAND controller into buffer
+ * @mtd: MTD device 

[PATCH v7 6/7] omap3: nand: ecc layout select from board file

[Sukumar Ghorai]

This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver.  And hw ecc layout selected for
sdp and zoom boards, by default.

Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/board-flash.c  |1 +
 arch/arm/plat-omap/include/plat/gpmc.h |6 ++
 arch/arm/plat-omap/include/plat/nand.h |2 ++
 drivers/mtd/nand/omap2.c   |   26 +++---
 4 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index 1964509..a768198 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -148,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
 
+   board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
 }
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index fb82335..28a5607 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,12 @@
 #define PREFETCH_FIFOTHRESHOLD_MAX 0x40
 #define PREFETCH_FIFOTHRESHOLD(val)(val  8)
 
+enum omap_ecc {
+   /* 1-bit ecc: stored at end of spare area */
+   OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
+   OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+};
+
 /*
  * Note that all values in this struct are in nanoseconds, while
  * the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h 
b/arch/arm/plat-omap/include/plat/nand.h
index ae5e053..d86d1ec 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
  * published by the Free Software Foundation.
  */
 
+#include plat/gpmc.h
 #include linux/mtd/partitions.h
 
 enum nand_io {
@@ -31,6 +32,7 @@ struct omap_nand_platform_data {
enum nand_ioxfer_type;
unsigned long   phys_base;
int devsize;
+   enum omap_ecc   ecc_opt;
 };
 
 /* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 384d89b..c6f3ea9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -618,8 +618,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const 
u_char * buf, int len)
return 0;
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
 /**
  * gen_true_ecc - This function will generate true ECC value
  * @ecc_buf: buffer to store ecc code
@@ -839,8 +837,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int 
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
 }
 
-#endif
-
 /**
  * omap_wait - wait until the command is done
  * @mtd: MTD device structure
@@ -1030,17 +1026,17 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
 
info-nand.verify_buf = omap_verify_buf;
 
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-   info-nand.ecc.bytes= 3;
-   info-nand.ecc.size = 512;
-   info-nand.ecc.calculate= omap_calculate_ecc;
-   info-nand.ecc.hwctl= omap_enable_hwecc;
-   info-nand.ecc.correct  = omap_correct_data;
-   info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
-   info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+   /* selsect the ecc type */
+   if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
+   info-nand.ecc.mode = NAND_ECC_SOFT;
+   else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+   info-nand.ecc.bytes= 3;
+   info-nand.ecc.size = 512;
+   info-nand.ecc.calculate= omap_calculate_ecc;
+   info-nand.ecc.hwctl= omap_enable_hwecc;
+   info-nand.ecc.correct  = omap_correct_data;
+   info-nand.ecc.mode = NAND_ECC_HW;
+   }
 
/* DIP switches on some boards change between 8 and 16 bit
 * bus widths for flash.  Try the other width if the first try fails.
-- 
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 v7 2/7] omap3: nand: configurable transfer type per board

[Sukumar Ghorai]

nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.

this helps in multi-omap build and to select different transfer type for
different board.

Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/plat-omap/include/plat/nand.h |7 +++
 drivers/mtd/nand/Kconfig   |   17 --
 drivers/mtd/nand/omap2.c   |   92 +++
 3 files changed, 40 insertions(+), 76 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/nand.h 
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
 
 #include linux/mtd/partitions.h
 
+enum nand_io {
+   NAND_OMAP_PREFETCH_POLLED = 0,  /* prefetch polled mode, default */
+   NAND_OMAP_POLLED,   /* polled mode, without prefetch */
+   NAND_OMAP_PREFETCH_DMA  /* prefetch enabled sDMA mode */
+};
+
 struct omap_nand_platform_data {
unsigned intoptions;
int cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+   enum nand_ioxfer_type;
unsigned long   phys_base;
int devsize;
 };
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8229802..89bb297 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -105,23 +105,6 @@ config MTD_NAND_OMAP2
help
   Support for NAND flash on Texas Instruments OMAP2 and OMAP3 
platforms.
 
-config MTD_NAND_OMAP_PREFETCH
-   bool GPMC prefetch support for NAND Flash device
-   depends on MTD_NAND_OMAP2
-   default y
-   help
-The NAND device can be accessed for Read/Write using GPMC PREFETCH 
engine
-to improve the performance.
-
-config MTD_NAND_OMAP_PREFETCH_DMA
-   depends on MTD_NAND_OMAP_PREFETCH
-   bool DMA mode
-   default n
-   help
-The GPMC PREFETCH engine can be configured eigther in MPU interrupt 
mode
-or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
-
 config MTD_NAND_IDS
tristate
 
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7c04cd6..66b7428 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -96,27 +96,6 @@
 static const char *part_probes[] = { cmdlinepart, NULL };
 #endif
 
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
-static int use_prefetch = 1;
-
-/* modprobe ... use_prefetch=0 etc */
-module_param(use_prefetch, bool, 0);
-MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
-
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
-static int use_dma = 1;
-
-/* modprobe ... use_dma=0 etc */
-module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
-#else
-static const int use_dma;
-#endif
-#else
-const int use_prefetch;
-static const int use_dma;
-#endif
-
 struct omap_nand_info {
struct nand_hw_control  controller;
struct omap_nand_platform_data  *pdata;
@@ -324,7 +303,6 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
 /*
  * omap_nand_dma_cb: callback on the completion of dma transfer
  * @lch: logical channel
@@ -426,14 +404,6 @@ out_copy:
: omap_write_buf8(mtd, (u_char *) addr, len);
return 0;
 }
-#else
-static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
-static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
-   unsigned int len, int is_write)
-{
-   return 0;
-}
-#endif
 
 /**
  * omap_read_buf_dma_pref - read data from NAND controller into buffer
@@ -842,28 +812,13 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
info-nand.chip_delay = 50;
}
 
-   if (use_prefetch) {
-
+   switch (pdata-xfer_type) {
+   case NAND_OMAP_PREFETCH_POLLED:
info-nand.read_buf   = omap_read_buf_pref;
info-nand.write_buf  = omap_write_buf_pref;
-   if (use_dma) {
-   err = omap_request_dma(OMAP24XX_DMA_GPMC, NAND,
-   omap_nand_dma_cb, info-comp, info-dma_ch);
-   if (err  0) {
-   info-dma_ch = -1;
-   printk(KERN_WARNING DMA request failed.
-Non-dma data transfer mode\n);
-   } else {
-   omap_set_dma_dest_burst_mode(info-dma_ch,
-   OMAP_DMA_DATA_BURST_16);
-   

[PATCH v7 3/7] omap: gpmc: enable irq mode in gpmc

[Sukumar Ghorai]

add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on irq.

Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/board-2430sdp.c|1 +
 arch/arm/mach-omap2/board-3430sdp.c|1 +
 arch/arm/mach-omap2/board-3630sdp.c|1 +
 arch/arm/mach-omap2/board-4430sdp.c|2 +
 arch/arm/mach-omap2/board-am3517evm.c  |2 +
 arch/arm/mach-omap2/board-apollon.c|1 +
 arch/arm/mach-omap2/board-cm-t35.c |1 +
 arch/arm/mach-omap2/board-devkit8000.c |1 +
 arch/arm/mach-omap2/board-generic.c|2 +
 arch/arm/mach-omap2/board-h4.c |1 +
 arch/arm/mach-omap2/board-igep0020.c   |1 +
 arch/arm/mach-omap2/board-ldp.c|1 +
 arch/arm/mach-omap2/board-n8x0.c   |2 +
 arch/arm/mach-omap2/board-omap3beagle.c|1 +
 arch/arm/mach-omap2/board-omap3evm.c   |2 +
 arch/arm/mach-omap2/board-omap3pandora.c   |2 +
 arch/arm/mach-omap2/board-omap3stalker.c   |1 +
 arch/arm/mach-omap2/board-omap3touchbook.c |1 +
 arch/arm/mach-omap2/board-omap4panda.c |2 +
 arch/arm/mach-omap2/board-overo.c  |1 +
 arch/arm/mach-omap2/board-rx51.c   |1 +
 arch/arm/mach-omap2/board-zoom2.c  |2 +
 arch/arm/mach-omap2/board-zoom3.c  |2 +
 arch/arm/mach-omap2/gpmc.c |   39 ++-
 arch/arm/mach-omap2/io.c   |2 -
 arch/arm/plat-omap/include/plat/gpmc.h |4 +++
 arch/arm/plat-omap/include/plat/irqs.h |9 +-
 27 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index b527f8d..11c89dc 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void)
omap_board_config_size = ARRAY_SIZE(sdp2430_config);
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
+   gpmc_init();
omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 470872e..690fecd 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
+   gpmc_init();
omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
index 0a74141..46c1755 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -77,6 +77,7 @@ static void __init omap_sdp_init_irq(void)
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params);
omap_init_irq();
+   gpmc_init();
omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..8d15604 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -34,6 +34,7 @@
 #include plat/common.h
 #include plat/usb.h
 #include plat/mmc.h
+#include plat/gpmc.h
 
 #include hsmmc.h
 #include timer-gp.h
@@ -222,6 +223,7 @@ static void __init omap_4430sdp_init_irq(void)
omap2_gp_clockevent_set_gptimer(1);
 #endif
gic_init_irq();
+   gpmc_init();
omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..460e3d1 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
 #include plat/common.h
 #include plat/usb.h
 #include plat/display.h
+#include plat/gpmc.h
 
 #include mux.h
 #include control.h
@@ -392,6 +393,7 @@ static void __init am3517_evm_init_irq(void)
 
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
+   gpmc_init();
omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-apollon.c 
b/arch/arm/mach-omap2/board-apollon.c
index 2c6db1a..8264e7a 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void)
omap_board_config_size = ARRAY_SIZE(apollon_config);
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
+   gpmc_init();
omap_gpio_init();
apollon_init_smc91x();
 }
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..7c9a834 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -686,6 +686,7 @@ static void __init cm_t35_init_irq(void)
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 mt46h32m32lf6_sdrc_params);

RE: OMAP NAND redux

[Ghorai, Sukumar]

 -Original Message-
 From: Charles Manning [mailto:mannin...@actrix.gen.nz]
 Sent: Friday, December 17, 2010 3:31 AM
 To: linux-omap@vger.kernel.org
 Cc: Ghorai, Sukumar; Grazvydas Ignotas
 Subject: OMAP NAND redux
 
 Hello All
 
 Over the last while I have been working on getting ubifs working on
 omap3530
 using 16-bit NAND with the latest 2.6.37 prefetch code. This is basically
 a
 tweaked Overo kernel.
 
  Here is what I found:
 
 After initial exploration I found that there were three problem:
 
 * ECC bytes not being read correctly during sub-page reads.
 * Disabling prefetch meant that the flash was not being read at all.
 * NAND access seems to have slowed down significantly.
 
 Both these boiled down to one root cause. After the prefetch changes,
 nand-IO_ADDR_R is set to an address that only works within the context of
 the prefetch code. It no longer works if prefetch is disabled. Execution
 of:
  static void omap_read_buf16(struct mtd_info *mtd, u_char *buf, int len)
 {
   struct nand_chip *nand = mtd-priv;
 
 ioread16_rep(nand-IO_ADDR_R, buf, len / 2);
 }
 
 
 Even if prefetch is enabled, subpage reads that are not 32-bit aligned
 call
 the above function which means the ECC does not read correctly - resulting
 in
 ECC errors.
[Ghorai] please give a try with CONFIG_MTD_NAND_OMAP_HWECC enable; 
i.e. NAND_ECC_HW; by this I did not see this issue

 
 I managed to work around this by applying the following patch to force all
 buffer reads to u32 alignment:
 --- a/drivers/mtd/nand/omap2.c
 +++ b/drivers/mtd/nand/omap2.c
 @@ -245,6 +245,18 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
 u_char *buf, int len)
 int ret = 0;
 u32 *p = (u32 *)buf;
 
 +   /* u32 align the buffer and read */
 +   /* NB: This assumes the buf ptr can be aligned *down* which is a
 valid.
 +* Assumption when dealing with ecc buffers etc.
 +*/
 +   u32 addr = (u32)p;
 +
 +   int diff = addr  3;
 +   addr -= diff;
 +   len += diff;
 +   len = (len + 3)  ~3;
 +   p = (u32 *)addr;
 +
 /* take care of subpage reads */
 if (len % 4) {
 if (info-nand.options  NAND_BUSWIDTH_16)
 
 Yeah I know that is ugly, but it works!
 
 Prefetch is enabled, dma is disabled. ECC is done in software.
[Ghorai] please give a try with CONFIG_MTD_NAND_OMAP_HWECC enable


 OK, that gives me a working UBIFS, but I found something else...
 
 NAND access has got way, way slower since 2.6.34.
 
 I created a 2MB file foo then do the following:
 
 sync; date; cp foo bar; sync; date
 
 In 2.6.34 the time between the two dates was 3 seconds.
 In 2.6.37 this now takes 14 seconds!
 
 
 Now question time:
 
 1) How well has the prefetch code been tested?
[Ghorai] yes, its enable by default even in 2.6.34 onwards
And many omap products using this.

 2) Does it work with prefetch disabled?
[Ghorai] yes. 

 3) Has it been performance tested?
[Ghorai] yes. I did not remember the numbers.

 4) What should the value in nand-IO_ADDR_R be?
[Ghorai] this could be the same as IO_ADDR_W
And you can refer Section in TRM: Global Memory Space Mapping

 
 
 Thanks
 
 Charles

--
To unsubscribe from this list: send the line unsubscribe 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] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling

[Aaro Koskinen]

Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
eliminate some ifdefs.

Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
 arch/arm/mach-omap2/pm.h |4 
 arch/arm/mach-omap2/pm24xx.c |   16 
 arch/arm/mach-omap2/pm34xx.c |   16 
 arch/arm/mach-omap2/pm44xx.c |   17 +
 4 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 1c1b0ab..704766b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -138,4 +138,8 @@ static inline int omap4_twl_init(void)
 }
 #endif
 
+#ifndef CONFIG_SUSPEND
+#define omap_pm_ops NULL
+#endif
+
 #endif
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index dac2d1d..e65b329 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -350,14 +350,14 @@ static void omap2_pm_end(void)
enable_hlt();
 }
 
-static struct platform_suspend_ops omap_pm_ops = {
-   .begin  = omap2_pm_begin,
-   .enter  = omap2_pm_enter,
-   .end= omap2_pm_end,
-   .valid  = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+   {
+   .begin  = omap2_pm_begin,
+   .enter  = omap2_pm_enter,
+   .end= omap2_pm_end,
+   .valid  = suspend_valid_only_mem,
+   }
 };
-#else
-static const struct platform_suspend_ops __initdata omap_pm_ops;
 #endif /* CONFIG_SUSPEND */
 
 /* XXX This function should be shareable between OMAP2xxx and OMAP3 */
@@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
omap24xx_cpu_suspend_sz);
}
 
-   suspend_set_ops(omap_pm_ops);
+   suspend_set_ops(omap_pm_ops);
pm_idle = omap2_pm_idle;
 
return 0;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5b323f2..a4c9283 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -605,11 +605,13 @@ static void omap3_pm_end(void)
return;
 }
 
-static struct platform_suspend_ops omap_pm_ops = {
-   .begin  = omap3_pm_begin,
-   .end= omap3_pm_end,
-   .enter  = omap3_pm_enter,
-   .valid  = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+   {
+   .begin  = omap3_pm_begin,
+   .end= omap3_pm_end,
+   .enter  = omap3_pm_enter,
+   .valid  = suspend_valid_only_mem,
+   }
 };
 #endif /* CONFIG_SUSPEND */
 
@@ -1067,9 +1069,7 @@ static int __init omap3_pm_init(void)
core_clkdm = clkdm_lookup(core_clkdm);
 
omap_push_sram_idle();
-#ifdef CONFIG_SUSPEND
-   suspend_set_ops(omap_pm_ops);
-#endif /* CONFIG_SUSPEND */
+   suspend_set_ops(omap_pm_ops);
 
pm_idle = omap3_pm_idle;
omap3_idle_init();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index e9f4862..6022c0a 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -16,6 +16,7 @@
 #include linux/err.h
 #include linux/slab.h
 
+#include pm.h
 #include powerdomain.h
 #include mach/omap4-common.h
 
@@ -65,11 +66,13 @@ static void omap4_pm_end(void)
return;
 }
 
-static struct platform_suspend_ops omap_pm_ops = {
-   .begin  = omap4_pm_begin,
-   .end= omap4_pm_end,
-   .enter  = omap4_pm_enter,
-   .valid  = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+   {
+   .begin  = omap4_pm_begin,
+   .end= omap4_pm_end,
+   .enter  = omap4_pm_enter,
+   .valid  = suspend_valid_only_mem,
+   }
 };
 #endif /* CONFIG_SUSPEND */
 
@@ -113,9 +116,7 @@ static int __init omap4_pm_init(void)
}
 #endif
 
-#ifdef CONFIG_SUSPEND
-   suspend_set_ops(omap_pm_ops);
-#endif /* CONFIG_SUSPEND */
+   suspend_set_ops(omap_pm_ops);
 
 err2:
return ret;
-- 
1.5.6.5

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

Re: [PATCH v7 1/1] spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition

[Grant Likely]

On Wed, Dec 29, 2010 at 11:52:53AM +0100, Gregory CLEMENT wrote:
 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).
 

merged, thanks.

g.

 Changelog:
 * Change from v1 to v2:
   - Rebase on linus/master (after 2.6.37-rc1)
   - Do some clean-up and fix indentation on both patches
   - Add more explanations for patch 2
 
 * Change from v2 to v3:
   - Use directly resume function of spi_master instead of using function
   - from spi_device as Grant Likely pointed it out.
   - Force this transition explicitly for each CS used by a device.
 
 * Change from v3 to v4:
   - Patch clean-up according to Kevin Hilman and checkpatch.
   - Now force CS to be in inactive state only if it was inactive when it was
 suspended.
 
 * Change from v4 to v5:
   - Rebase on linus/master (after 2.6.37-rc3)
   - Collapse some lines as pointed by Grant Likely
   - Fix a spelling
 
 * Change from v5 to v6:
   - Rebase on linus/master (after 2.6.37-rc7)
   - Use CONFIG_SUSPEND instead of CONFIG_PM
   - Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and
 add the resume method there.
   - Fix multi-line comment style
 
 * Change from v6 to v7:
   - Rebase on linus/master (after 2.6.37-rc8)
   - Drop an extra line
 
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Acked-by: David Brownell dbrown...@users.sourceforge.net
 Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
 
 ---
  drivers/spi/omap2_mcspi.c |   39 +++
  1 files changed, 39 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
 index 2a651e6..951a160 100644
 --- a/drivers/spi/omap2_mcspi.c
 +++ b/drivers/spi/omap2_mcspi.c
 @@ -1305,10 +1305,49 @@ static int __exit omap2_mcspi_remove(struct 
 platform_device *pdev)
  /* work with hotplug and coldplug */
  MODULE_ALIAS(platform:omap2_mcspi);
 
 +#ifdef   CONFIG_SUSPEND
 +/*
 + * When SPI wake up from off-mode, CS is in activate state. If it was in
 + * unactive state when driver was suspend, then force it to unactive state at
 + * wake up.
 + */
 +static int omap2_mcspi_resume(struct device *dev)
 +{
 + struct spi_master   *master = dev_get_drvdata(dev);
 + struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
 + struct omap2_mcspi_cs *cs;
 +
 + omap2_mcspi_enable_clocks(mcspi);
 + list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
 + node) {
 + if ((cs-chconf0  OMAP2_MCSPI_CHCONF_FORCE) == 0) {
 +
 + /*
 +  * We need to toggle CS state for OMAP take this
 +  * change in account.
 +  */
 + MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
 + __raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 + MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
 + __raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 + }
 + }
 + omap2_mcspi_disable_clocks(mcspi);
 + return 0;
 +}
 +#else
 +#define  omap2_mcspi_resume  NULL
 +#endif
 +
 +static const struct dev_pm_ops omap2_mcspi_pm_ops = {
 + .resume = omap2_mcspi_resume,
 +};
 +
  static struct platform_driver omap2_mcspi_driver = {
   .driver = {
   .name = omap2_mcspi,
   .owner =THIS_MODULE,
 + .pm =   omap2_mcspi_pm_ops
   },
   .remove =   __exit_p(omap2_mcspi_remove),
  };
 -- 
 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: OMAP Color Rotation

[Elvis Dowson]

Hi David,

On Dec 28, 2010, at 9:44 PM, David Lynch Jr. wrote:

   I am looking for an example of programing the color rotation
 registers. 
   I need to swap red and blue in software. 
   This should be fairly easy, but some code usi_ng the color rotation
 registers would help. 
   DISPC_CPR_COEF_R  
 

There's a color matrix transform mentioned in this document:

http://bunnitude.com/misc/files/omap/pdf/sprufa4.pdf

page 180, 181.

Best regards,

Elvis Dowson
--
To unsubscribe from this list: send the line unsubscribe 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 03/12] OMAP4: clock data: Add missing DPLL x2 clock nodes

[Gopinath, Thara]

-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, December 22, 2010 7:17 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Gopinath, Thara; Nayak, Rajendra; Cousson, Benoit
Subject: Re: [PATCH 03/12] OMAP4: clock data: Add missing DPLL x2 clock
nodes

On Mon, 13 Dec 2010, Paul Walmsley wrote:

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

 This patch extends the OMAP4 clock data to include
 various x2 clock nodes between DPLL and HS dividers as the
 clock framework skips a x2 while calculating the dpll locked
 frequency.

 The clock database extensions are autogenerated using
 the scripts maintained by Benoit Cousson.

 Signed-off-by: Benoit Cousson b-cous...@ti.com
 Signed-off-by: Thara Gopinath th...@ti.com
 [p...@pwsan.com: fixed merge conflicts against v2.6.37-rc5]
 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Rajendra Nayak rna...@ti.com

This patch has been updated to drop dpll_mpu_x2_ck.  According to Benoît
there is no need for this clock because there are no users of it, and the
script has been updated accordingly.

dpll_mpu_x2_ck was added to maintain the compatibility with other dpll
nodes. You can drop it if there is no use for it and you perceive no use
for it in OMAP4.

Regards
Thara


- Paul

From: Thara Gopinath th...@ti.com
Date: Tue, 21 Dec 2010 18:11:05 -0700
Subject: [PATCH] OMAP4: clock data: Add missing DPLL x2 clock nodes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch extends the OMAP4 clock data to include
various x2 clock nodes between DPLL and HS dividers as the
clock framework skips a x2 while calculating the dpll locked
frequency.

The clock database extensions are autogenerated using
the scripts maintained by Benoit Cousson.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
[p...@pwsan.com: fixed merge conflicts against v2.6.37-rc5; dropped
 dpll_mpu_x2_ck on advice from Benoît]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |  415 -
-
 1 files changed, 240 insertions(+), 175 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index 305019c4..7c8d7f4 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -275,11 +275,63 @@ static struct clk dpll_abe_ck = {
  .set_rate   = omap3_noncore_dpll_set_rate,
 };

+static struct clk dpll_abe_x2_ck = {
+ .name   = dpll_abe_x2_ck,
+ .parent = dpll_abe_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
+static const struct clksel_rate div31_1to31_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 3, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 4, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 5, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 6, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 7, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 8, .val = 8, .flags = RATE_IN_4430 },
+ { .div = 9, .val = 9, .flags = RATE_IN_4430 },
+ { .div = 10, .val = 10, .flags = RATE_IN_4430 },
+ { .div = 11, .val = 11, .flags = RATE_IN_4430 },
+ { .div = 12, .val = 12, .flags = RATE_IN_4430 },
+ { .div = 13, .val = 13, .flags = RATE_IN_4430 },
+ { .div = 14, .val = 14, .flags = RATE_IN_4430 },
+ { .div = 15, .val = 15, .flags = RATE_IN_4430 },
+ { .div = 16, .val = 16, .flags = RATE_IN_4430 },
+ { .div = 17, .val = 17, .flags = RATE_IN_4430 },
+ { .div = 18, .val = 18, .flags = RATE_IN_4430 },
+ { .div = 19, .val = 19, .flags = RATE_IN_4430 },
+ { .div = 20, .val = 20, .flags = RATE_IN_4430 },
+ { .div = 21, .val = 21, .flags = RATE_IN_4430 },
+ { .div = 22, .val = 22, .flags = RATE_IN_4430 },
+ { .div = 23, .val = 23, .flags = RATE_IN_4430 },
+ { .div = 24, .val = 24, .flags = RATE_IN_4430 },
+ { .div = 25, .val = 25, .flags = RATE_IN_4430 },
+ { .div = 26, .val = 26, .flags = RATE_IN_4430 },
+ { .div = 27, .val = 27, .flags = RATE_IN_4430 },
+ { .div = 28, .val = 28, .flags = RATE_IN_4430 },
+ { .div = 29, .val = 29, .flags = RATE_IN_4430 },
+ { .div = 30, .val = 30, .flags = RATE_IN_4430 },
+ { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel dpll_abe_m2x2_div[] = {
+ { .parent = dpll_abe_x2_ck, .rates = div31_1to31_rates },
+ { .parent = NULL },
+};
+
 static struct clk dpll_abe_m2x2_ck = {
  .name   = dpll_abe_m2x2_ck,
- .parent = dpll_abe_ck,
+ .parent = dpll_abe_x2_ck,
+ .clksel = dpll_abe_m2x2_div,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
+ .clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
  .ops= 

Re: [PATCH] musb: am35x: fix compile error due to control apis

[Ben Gamari]

On Mon, 27 Dec 2010 11:20:38 +0200, Felipe Balbi ba...@ti.com wrote:
 On Thu, Dec 23, 2010 at 12:16:22PM -0500, Ben Gamari wrote:
 Is this change slated to go into 2.6.37? As it stands it looks like
 2.6.37 will be released with completely broken musb support on many boards
 (including the BeagleBoard).
 
 yes, it is.
 
Are you sure? We are currently at -rc8 and yet this patch has yet to
make it into my tree.

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