Re: [PATCH v4 18/20] gpio/omap: use pm-runtime framework

[Todd Poynor]

On Wed, Jul 13, 2011 at 07:24:17PM +0530, Tarun Kanti DebBarma wrote:
 From: Charulatha V ch...@ti.com
 
 Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
 for enabling/disabling clocks appropriately. Remove syscore_ops and
 instead use dev_pm_ops now.
 
...
 + /*
 +  * If this is the first gpio_request for the bank,
 +  * enable the bank module.
 +  */
 + if (!bank-mod_usage) {
 + if (IS_ERR_VALUE(pm_runtime_get_sync(bank-dev)  0)) {
 + dev_err(bank-dev, %s: GPIO bank %d 
 + pm_runtime_get_sync failed\n,
 + __func__, bank-id);
 + return -EINVAL;
 + }
 +
 + /* Initialize the gpio bank registers to init time value */
 + omap_gpio_mod_init(bank);
 + }
 +
   spin_lock_irqsave(bank-lock, flags);

Does the check for first gpio_request and omap_gpio_mod_init() call
need concurrency protection, possibly moved under the spinlock?

  
   /* Set trigger to none. You need to enable the desired trigger with
 @@ -536,6 +554,18 @@ static void omap_gpio_free(struct gpio_chip *chip, 
 unsigned offset)
  
   _reset_gpio(bank, bank-chip.base + offset);
   spin_unlock_irqrestore(bank-lock, flags);
 +
 + /*
 +  * If this is the last gpio to be freed in the bank,
 +  * disable the bank module.
 +  */
 + if (!bank-mod_usage) {
 + if (IS_ERR_VALUE(pm_runtime_put_sync(bank-dev)  0)) {
 + dev_err(bank-dev, %s: GPIO bank %d 
 + pm_runtime_put_sync failed\n,
 + __func__, bank-id);
 + }
 + }

And need mutual exclusion here?


Todd

--
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 2/5] regulator: omap smps regulator driver

[Todd Poynor]

On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
 OMAP SMPS regulator driver provides access to OMAP voltage processor
 controlled regulators. These include VDD1 and VDD2 for OMAP3 and additionally
 VDD3 for OMAP4. SMPS regulators use the OMAP voltage layer for the actual
 voltage regulation operations.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 ---
...
 + for (i = 0; i  pdata-num_regulators; i++) {
 + initdata = pdata-regulators[i];
 +
 + c = initdata-constraints;
 + c-valid_modes_mask = REGULATOR_MODE_NORMAL;
 + c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE;
 + c-always_on = true;
 +
 + voltdm = omap_voltage_domain_lookup(
 + initdata-consumer_supplies[0].dev_name);
 +
 + if (IS_ERR(voltdm)) {
 + dev_err(pdev-dev, can't find voltdm %s, %ld\n,
 + initdata-consumer_supplies[0].dev_name,
 + PTR_ERR(voltdm));
 + return PTR_ERR(voltdm);


Or maybe continue to next loop iteration.

 + }
 + info = kzalloc(sizeof(struct omap_smps_reg_info), GFP_KERNEL);
 +
 + info-voltdm = voltdm;


Check kzalloc NULL return.

 + info-desc.ops = omap_smps_ops;
 + info-desc.name = c-name;
 + info-desc.type = REGULATOR_VOLTAGE;
 + info-desc.n_voltages = 0;
 + rdev = regulator_register(info-desc, pdev-dev, initdata,
 + info);
 + if (IS_ERR(rdev)) {
 + dev_err(pdev-dev, can't register %s, %ld\n,
 + info-desc.name, PTR_ERR(rdev));
 + return PTR_ERR(rdev);

Or suggest continue to next loop iteration.

 + }
 + platform_set_drvdata(pdev, rdev);

Performed in a loop, but only last iteration's rdev is set as the
driver data for pdev.  Platform driver data should be pdata?

 + }
 +
 + return 0;
 +}
 +
 +static int omap_smps_reg_remove(struct platform_device *pdev)
 +{
 + regulator_unregister(platform_get_drvdata(pdev));


Should kfree() the struct omap_smps_reg_info data structure(s) and
platform_set_drvdata(pdev, NULL) ?


Todd
--
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 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6

[Tero Kristo]

On Wed, 2011-07-13 at 19:49 +0200, Premi, Sanjeev wrote:
  
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 
-Original Message-

  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo, Tero
  Sent: Wednesday, July 13, 2011 7:31 PM
  To: linux-omap@vger.kernel.org
  Cc: broo...@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
  Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
  
  Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can 
  run at 720MHz.
  
  Signed-off-by: Tero Kristo t-kri...@ti.com
  ---
   arch/arm/mach-omap2/board-omap3beagle.c |   32 
  +++
   arch/arm/mach-omap2/opp3xxx_data.c  |4 +++
   2 files changed, 36 insertions(+), 0 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
  b/arch/arm/mach-omap2/board-omap3beagle.c
  index d7ae648..5ab507d 100644
  --- a/arch/arm/mach-omap2/board-omap3beagle.c
  +++ b/arch/arm/mach-omap2/board-omap3beagle.c
  @@ -592,6 +592,38 @@ static void __init beagle_opp_init(void)
  return;
  }
   
  +   /* Custom OPP enabled for C4 */
  +   if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
  +   struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
  +   struct omap_hwmod *dh = omap_hwmod_lookup(iva);
  +   struct device *dev;
  +
  +   if (!mh || !dh) {
  +   pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
  +   __func__, mh, dh);
  +   }
  +   /* Enable MPU 720MHz opp */
  +   dev = mh-od-pdev.dev;
  +   r = opp_enable(dev, 72000);
  +
  +   /* Enable IVA 520MHz opp */
  +   dev = dh-od-pdev.dev;
  +   r |= opp_enable(dev, 52000);
  +
  +   if (r) {
  +   pr_err(%s: failed to enable higher opp %d\n,
  +   __func__, r);
  +   /*
  +* Cleanup - disable the higher freqs - 
  we dont care
  +* about the results
  +*/
  +   dev = mh-od-pdev.dev;
  +   opp_disable(dev, 72000);
  +   dev = dh-od-pdev.dev;
  +   opp_disable(dev, 52000);
  +   }
  +   }
  +
  /* Custom OPP enabled for all xM versions */
  if (cpu_is_omap3630()) {
  struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
  diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
  b/arch/arm/mach-omap2/opp3xxx_data.c
  index d95f3f9..a0f5fe1 100644
  --- a/arch/arm/mach-omap2/opp3xxx_data.c
  +++ b/arch/arm/mach-omap2/opp3xxx_data.c
  @@ -98,6 +98,8 @@ static struct omap_opp_def __initdata 
  omap34xx_opp_def_list[] = {
  OPP_INITIALIZER(mpu, true, 55000, 
  OMAP3430_VDD_MPU_OPP4_UV),
  /* MPU OPP5 */
  OPP_INITIALIZER(mpu, true, 6, 
  OMAP3430_VDD_MPU_OPP5_UV),
  +   /* MPU OPP6 : omap3530 high speed grade only */
  +   OPP_INITIALIZER(mpu, false, 72000, 
  OMAP3430_VDD_MPU_OPP5_UV),
   
  /*
   * L3 OPP1 - 41.5 MHz is disabled because: The voltage 
  for that OPP is
  @@ -123,6 +125,8 @@ static struct omap_opp_def __initdata 
  omap34xx_opp_def_list[] = {
  OPP_INITIALIZER(iva, true, 4, 
  OMAP3430_VDD_MPU_OPP4_UV),
  /* DSP OPP5 */
  OPP_INITIALIZER(iva, true, 43000, 
  OMAP3430_VDD_MPU_OPP5_UV),
  +   /* DSP OPP6 : omap3530 high speed grade only */
  +   OPP_INITIALIZER(iva, false, 52000, 
  OMAP3430_VDD_MPU_OPP5_UV),
   };
   
   static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
 
 [sp] Basic support for 720MHz was already closed early this year.
  See: http://marc.info/?l=linux-omapm=129735630928696w=2
 
  I cannot check the current tree status right now; but I assume
  the patch should already be in.
 

Yea, I heard this was agreed upon, however it is not in the tree yet.
Thus I just added this patch in the set for testing purposes... and
tagged as TEMP.

 ~sanjeev
 
  -- 
  1.7.4.1
  
  
  Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 
  0115040-6. Kotipaikka: Helsinki
   
  
  --
  To unsubscribe from this list: send the line unsubscribe 
  linux-omap in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  


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

RE: [PATCH v4 18/20] gpio/omap: use pm-runtime framework

[DebBarma, Tarun Kanti]

 -Original Message-
 From: Todd Poynor [mailto:toddpoy...@google.com]
 Sent: Thursday, July 14, 2011 11:40 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org; Hilman, Kevin; Shilimkar, Santosh;
 t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan,
 Charulatha
 Subject: Re: [PATCH v4 18/20] gpio/omap: use pm-runtime framework
 
 On Wed, Jul 13, 2011 at 07:24:17PM +0530, Tarun Kanti DebBarma wrote:
  From: Charulatha V ch...@ti.com
 
  Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
  for enabling/disabling clocks appropriately. Remove syscore_ops and
  instead use dev_pm_ops now.
 
 ...
  +   /*
  +* If this is the first gpio_request for the bank,
  +* enable the bank module.
  +*/
  +   if (!bank-mod_usage) {
  +   if (IS_ERR_VALUE(pm_runtime_get_sync(bank-dev)  0)) {
  +   dev_err(bank-dev, %s: GPIO bank %d 
  +   pm_runtime_get_sync failed\n,
  +   __func__, bank-id);
  +   return -EINVAL;
  +   }
  +
  +   /* Initialize the gpio bank registers to init time value */
  +   omap_gpio_mod_init(bank);
  +   }
  +
  spin_lock_irqsave(bank-lock, flags);
 
 Does the check for first gpio_request and omap_gpio_mod_init() call
 need concurrency protection, possibly moved under the spinlock?
I believe, with pm_runtime_irq_safe() already in place, we could move
them including *_get_sync() under spinlock.

 
 
  /* Set trigger to none. You need to enable the desired trigger with
  @@ -536,6 +554,18 @@ static void omap_gpio_free(struct gpio_chip *chip,
 unsigned offset)
 
  _reset_gpio(bank, bank-chip.base + offset);
  spin_unlock_irqrestore(bank-lock, flags);
  +
  +   /*
  +* If this is the last gpio to be freed in the bank,
  +* disable the bank module.
  +*/
  +   if (!bank-mod_usage) {
  +   if (IS_ERR_VALUE(pm_runtime_put_sync(bank-dev)  0)) {
  +   dev_err(bank-dev, %s: GPIO bank %d 
  +   pm_runtime_put_sync failed\n,
  +   __func__, bank-id);
  +   }
  +   }
 
 And need mutual exclusion here?
Yes.
I will verify and take action. Thanks.
--
Tarun
 
 
 Todd

--
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 2/5] regulator: omap smps regulator driver

[Tero Kristo]

On Thu, 2011-07-14 at 08:29 +0200, Todd Poynor wrote:
 On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
  OMAP SMPS regulator driver provides access to OMAP voltage processor
  controlled regulators. These include VDD1 and VDD2 for OMAP3 and 
  additionally
  VDD3 for OMAP4. SMPS regulators use the OMAP voltage layer for the actual
  voltage regulation operations.
  
  Signed-off-by: Tero Kristo t-kri...@ti.com
  ---
 ...
  +   for (i = 0; i  pdata-num_regulators; i++) {
  +   initdata = pdata-regulators[i];
  +
  +   c = initdata-constraints;
  +   c-valid_modes_mask = REGULATOR_MODE_NORMAL;
  +   c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE;
  +   c-always_on = true;
  +
  +   voltdm = omap_voltage_domain_lookup(
  +   initdata-consumer_supplies[0].dev_name);
  +
  +   if (IS_ERR(voltdm)) {
  +   dev_err(pdev-dev, can't find voltdm %s, %ld\n,
  +   initdata-consumer_supplies[0].dev_name,
  +   PTR_ERR(voltdm));
  +   return PTR_ERR(voltdm);
 
 
 Or maybe continue to next loop iteration.

Not sure about this. If one of the regulators fails, it is probably
better to fail/disable them all, otherwise we end up in partly
functioning situation. I think I'll just change this into a setup where
all the SMPS regulators are disabled if init of any of them fails.

 
  +   }
  +   info = kzalloc(sizeof(struct omap_smps_reg_info), GFP_KERNEL);
  +
  +   info-voltdm = voltdm;
 
 
 Check kzalloc NULL return.

True.

 
  +   info-desc.ops = omap_smps_ops;
  +   info-desc.name = c-name;
  +   info-desc.type = REGULATOR_VOLTAGE;
  +   info-desc.n_voltages = 0;
  +   rdev = regulator_register(info-desc, pdev-dev, initdata,
  +   info);
  +   if (IS_ERR(rdev)) {
  +   dev_err(pdev-dev, can't register %s, %ld\n,
  +   info-desc.name, PTR_ERR(rdev));
  +   return PTR_ERR(rdev);
 
 Or suggest continue to next loop iteration.

Same as above continue comment.

 
  +   }
  +   platform_set_drvdata(pdev, rdev);
 
 Performed in a loop, but only last iteration's rdev is set as the
 driver data for pdev.  Platform driver data should be pdata?

I'll check what the cleanup part needs and fix it.

 
  +   }
  +
  +   return 0;
  +}
  +
  +static int omap_smps_reg_remove(struct platform_device *pdev)
  +{
  +   regulator_unregister(platform_get_drvdata(pdev));
 
 
 Should kfree() the struct omap_smps_reg_info data structure(s) and
 platform_set_drvdata(pdev, NULL) ?

Same as above.

 
 
 Todd



Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

--
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 0/5] OMAP SMPS regulator driver

[Tero Kristo]

On Thu, 2011-07-14 at 02:22 +0200, Hilman, Kevin wrote:
 Hi Tero,
 
 Tero Kristo t-kri...@ti.com writes:
 
  Based on the comments for the previous version of this set, I implemented
  a regulator driver for the OMAP SMPS now. 
 
 Could you rebase this on my pm-wip/voltdm branch where I've started the
 work to separate out the VC/VP layers into their own files.
 

I'll do this for next version.

 I've just rebased that branch on top of current l-o master, so it also
 includes all the PRCM core code changes queued for v3.1.
 
 Thanks,
 
 Kevin



Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

Re: [PATCH 1/3] ARM: OMAP4: Add pcm049 to Kconfig/Makefile

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [110708 04:53]:
 
 Are you or are you not taking now board files ? We have one which was
 left out due to a comment from Russell stating that no new board-files
 would be accepted until the move to device tree was completed [1]

Well looking at the cumulative diffstats, adding these board files
with about total of 1000 lines of addition would push our diffstat to
positive side. And that's not a good sign of code coalescing.

So I'll carry the board files in testing-board until we have device tree
working and won't need those.

Alternatively if somebody combines beagle variants to use board-beagle-common.c
and board-panda-common.c then adding new boards would have minimal impact
and would probably make device tree conversion of these boards easier
too.

Regards,

Tony

 
 [1] http://marc.info/?t=13019960756r=1w=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] ARM: OMAP4: PCM049: remove vusim regulator

[Tony Lindgren]

* Jan Weitzel j.weit...@phytec.de [110713 05:51]:
 Am Mittwoch, den 13.07.2011, 16:13 +0400 schrieb Sergei Shtylyov:
 
  
  Have you added that 'i' at the end intentionally?
  
 Thank you. It was a tribute to vim.

:i)

I'll fold the fixed patch into your original patch. Will also
keep the new board files in testing-board because of the code
coalescing and device tree conversion effort.

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: OMAP: PM: BUG: 3.0-rc6 does not compile, tusb6010_omap.c fails to compile musb undeclared

[Felipe Balbi]

On Tue, Jul 12, 2011 at 02:39:45PM -0300, Victhor wrote:
 | drivers/usb/musb/tusb6010_omap.c: In function 'tusb_omap_use_shared_dmareq':
 | drivers/usb/musb/tusb6010_omap.c:92: error: 'musb' undeclared (first use in 
 this function)
 | drivers/usb/musb/tusb6010_omap.c:92: error: (Each undeclared identifier is 
 reported only once
 | drivers/usb/musb/tusb6010_omap.c:92: error: for each function it appears 
 in.)

hmm... how about this ?

diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index c784e6c..07c8a73 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -89,7 +89,7 @@ static inline int tusb_omap_use_shared_dmareq(struct 
tusb_omap_dma_ch *chdat)
u32 reg = musb_readl(chdat-tbase, TUSB_DMA_EP_MAP);
 
if (reg != 0) {
-   dev_dbg(musb-controller, ep%i dmareq0 is busy for ep%i\n,
+   dev_dbg(chdat-musb-controller, ep%i dmareq0 is busy for 
ep%i\n,
chdat-epnum, reg  0xf);
return -EAGAIN;
}

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] ARM: OMAP4: Add pcm049 to Kconfig/Makefile

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [110714 00:22]:
 * Felipe Balbi ba...@ti.com [110708 04:53]:
  
  Are you or are you not taking now board files ? We have one which was
  left out due to a comment from Russell stating that no new board-files
  would be accepted until the move to device tree was completed [1]

For the mcop changes, that should be updated against current devel-board
for the irq/timer/init_early changes. Then I can add that to testing-board
too.

Tony
 
  [1] http://marc.info/?t=13019960756r=1w=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: [PATCHv2 2/5] regulator: omap smps regulator driver

[Tero Kristo]

On Thu, 2011-07-14 at 00:55 +0200, Mark Brown wrote:
 On Wed, Jul 13, 2011 at 06:53:45PM +0300, Tero Kristo wrote:
  On Wed, 2011-07-13 at 16:40 +0200, Mark Brown wrote:
 
   I do strongly prefer the idiom of just registering all the regulators
   even if they're read only.
 
  Number of available SMPS regulators is kind of board specific issue.
  OMAP3 has 2 available, OMAP4 has 3. If we are using some custom powering
  solution, we might have even different amounts for these.
 
 Right, but the interface to them is always there?

The library used in this driver will attempt to lookup for the
voltagedomains, and this will fail for 'iva' on omap3, as it does not
exist. I could change the driver to always try to look for all of the
possible known domains, and just register the ones it finds, and apply
user settings for the ones that board file provides. This contradicts
now a bit on the comment I just said to Todd, but you believe this to be
a better way?

 
   No, this is bad.  We *always* pay attention to the constraints the user
   set even if they're nuts or won't work, the machine driver has the final
   say on what is or isn't allowed on a given board.  The mode setting is
   especially suspect as there's no mode support in the driver.
 
  Just a clarification on this one that I have understood your comment
  right... Do you mean that I should be checking the constraints user sets
  more thoroughly to see if there is something bogus? I was looking at
  some of the other regulator drivers and they seem to be fiddling with
  the constraints in similar manner.
 
 No!  You should *always* use the constraints the user has set, don't
 randomly add new permissions without them doing so.

Ah ok, so no fiddling with the constraints at all, core should take care
of proper functioning regarding this part.

-Tero


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

--
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] ARM: OMAP4: PCM049: remove vusim regulator

[Jan Weitzel]

Am Donnerstag, den 14.07.2011, 00:34 -0700 schrieb Tony Lindgren:
 * Jan Weitzel j.weit...@phytec.de [110713 05:51]:
  Am Mittwoch, den 13.07.2011, 16:13 +0400 schrieb Sergei Shtylyov:
  
   
   Have you added that 'i' at the end intentionally?
   
  Thank you. It was a tribute to vim.
 
 :i)
 
 I'll fold the fixed patch into your original patch. Will also
 keep the new board files in testing-board because of the code
 coalescing and device tree conversion effort.

So there is no way to get the board mainline yet?

Jan

 Tony
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


--
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 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6

[Premi, Sanjeev]

 -Original Message-
 From: Kristo, Tero 
 Sent: Thursday, July 14, 2011 12:41 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org; 
 broo...@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
 Subject: RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
 
 On Wed, 2011-07-13 at 19:49 +0200, Premi, Sanjeev wrote:
   
 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 
 0115040-6. Kotipaikka: Helsinki
  
 -Original Message-
 
   From: linux-omap-ow...@vger.kernel.org 
   [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Kristo, Tero
   Sent: Wednesday, July 13, 2011 7:31 PM
   To: linux-omap@vger.kernel.org
   Cc: broo...@opensource.wolfsonmicro.com; Girdwood, Liam; 
 Hilman, Kevin
   Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
   
   Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can 
   run at 720MHz.
   
   Signed-off-by: Tero Kristo t-kri...@ti.com
   ---

[snip]...[snip]

  
  [sp] Basic support for 720MHz was already closed early this year.
   See: http://marc.info/?l=linux-omapm=129735630928696w=2
  
   I cannot check the current tree status right now; but I assume
   the patch should already be in.
  
 
 Yea, I heard this was agreed upon, however it is not in the tree yet.
 Thus I just added this patch in the set for testing purposes... and
 tagged as TEMP.

I noticed this today morning. Will be reposting it today after rebase.

~sanjeev

 
  ~sanjeev
  
   -- 
   1.7.4.1
   
   
   Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 
   0115040-6. Kotipaikka: Helsinki

   
   --
   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] omap2+: Use Kconfig symbol in Makefile instead of obj-y

[Tony Lindgren]

As noted by Grant Likely grant.lik...@secretlab.ca, omap2+ Makefile 
unnecessarily
repeats entries for common device init code instead of using Kconfig symbol.

Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o
references can be removed once it has some Kconfig symbol to use.

Signed-off-by: Tony Lindgren t...@atomide.com
---
* Grant Likely grant.lik...@secretlab.ca [110713 16:10]:
 
 This is an odd construct.  Tony, why does each board add hsmmc to the
 oby-y variable instead of it having its own kconfig symbol?

Heh that's true. Something that got added for one board got cloned
all over the Makefile. Here's a patch to simplify that.

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ff1466f..9c49a86 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -175,78 +175,66 @@ endif
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
-obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \
-  hsmmc.o
+obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_DEVKIT8000)  += board-devkit8000.o \
-   hsmmc.o
-obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
-  board-flash.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OMAP3530_LV_SOM)  += board-omap3logic.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OVERO)   += board-overo.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
-  hsmmc.o \
-  board-flash.o
+obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
+obj-$(CONFIG_MACH_DEVKIT8000)  += board-devkit8000.o
+obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
+obj-$(CONFIG_MACH_OMAP3530_LV_SOM)  += board-omap3logic.o
+obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
+obj-$(CONFIG_MACH_ENCORE)  += board-omap3encore.o
+obj-$(CONFIG_MACH_OVERO)   += board-overo.o
+obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o
+obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
-  sdram-nokia.o \
-  hsmmc.o
+  sdram-nokia.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o \
   sdram-nokia.o \
   board-rx51-peripherals.o \
-  board-rx51-video.o \
-  hsmmc.o
+  board-rx51-video.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom.o \
   board-zoom-peripherals.o \
   board-zoom-display.o \
-  board-flash.o \
-  hsmmc.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_ZOOM3)  += board-zoom.o \
   board-zoom-peripherals.o \
   board-zoom-display.o \
-  board-flash.o \
-  hsmmc.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
   board-zoom-peripherals.o \
-  board-zoom-display.o \
-  board-flash.o \
-  hsmmc.o
-obj-$(CONFIG_MACH_CM_T35)  += board-cm-t35.o \
-  hsmmc.o
+  board-zoom-display.o
+obj-$(CONFIG_MACH_CM_T35)  += board-cm-t35.o
 

Re: [PATCH][RFC] OMAP4: I2C : I2C context save

[Shubhrajyoti]

On Thursday 14 July 2011 02:57 AM, Hilman, Kevin wrote:

On Wed, Jul 13, 2011 at 2:15 PM, Kevin Hilmankhil...@ti.com  wrote:

Ben Dooksben-...@fluff.org  writes:


On Tue, Jul 05, 2011 at 02:50:46PM +0530, Shubhrajyoti D wrote:

Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.

Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com

I guess since the previous set has been taken by Kevin
then these will be too.

Sure, I'll pick these up, but it's probably to late for v3.1.

We've already submitted the bulk of the OMAP stuff for v3.1.

Kevin in the folowing I tried taking the comments do do have any
further comments or suggestions.

http://www.spinics.net/lists/linux-i2c/msg05823.html


I should've also said I'll pick these up when they are ready.  There
are still some comments that need addressing.

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

USB Ethernet gadget doesn't work with DM3730

[Enric Balletbò i Serra]

Hi all,

Playing with USB ethernet gadget on IGEP boards with mainline kernel
(Linux 3.0.0-rc7) I observed one strange behavior. The ethernet gadget
works with one board with OMAP3530 but it doesn't with another one
with DM3730. The log looks like this:

root@igep00x0:~# modprobe g_ether

[   51.420257] g_ether gadget: using random host ethernet address
[   51.427886] usb0: MAC da:93:4b:2d:55:e9
[   51.431915] usb0: HOST MAC 42:47:83:70:46:b6
[   51.436706] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[   51.443725] g_ether gadget: g_ether ready
[   51.447906] musb-hdrc musb-hdrc: MUSB HDRC host driver
[   51.455871] musb-hdrc musb-hdrc: new USB bus registered, assigned
bus number 1
[   51.464141] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   51.471313] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[   51.478912] usb usb1: Product: MUSB HDRC host driver
[   51.484161] usb usb1: Manufacturer: Linux 3.0.0-rc7-00027-g8d86e5f musb-hcd
[   51.491485] usb usb1: SerialNumber: musb-hdrc
[   51.498321] hub 1-0:1.0: USB hub found
[   51.502410] hub 1-0:1.0: 1 port detected

root@igep00x0:~# ifconfig usb0 192.168.7.2

usb0  Link encap:Ethernet  HWaddr DA:93:4B:2D:55:E9
  inet addr:192.168.7.2  Bcast:192.168.7.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@igep00x0:~# ping 192.168.7.1
PING 192.168.7.1 (192.168.7.1): 56 data bytes

With DM3730 I can't ping the other side (the same configuration with
OMAP3530 works without problems). Any clue on this ?

Cheers,
   Enric
--
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

Realistic bandwidth to get through ehci controller on a dm3730?

[Jonathan Cameron]

Hi All,

Just wondering if anyone had any figures for how much data one can expect
the omap3's usb controller to handle?

I'm trying to get a playstation eye (ov534) camera to run as at 60fps,
but gspca is giving me payload errors at 50fps or 60fps. (50*640*480 bytes
per sec, or about 122Mbits / sec (15MB / sec)

Quick and dirty tests of the beagle xm's network adapter suggest about
4MB/s so even at 40 fps when the camera is fine, I'm way above that.

Anyhow. Basically I'm trying to work out if I've run into a brick wall
or if it is worth more time to get this to work?

Thanks,

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

Re: [PATCH][RFC] OMAP4: I2C : I2C context save

[Kevin Hilman]

Shubhrajyoti shubhrajy...@ti.com writes:

 On Thursday 14 July 2011 02:57 AM, Hilman, Kevin wrote:
 On Wed, Jul 13, 2011 at 2:15 PM, Kevin Hilmankhil...@ti.com  wrote:
 Ben Dooksben-...@fluff.org  writes:

 On Tue, Jul 05, 2011 at 02:50:46PM +0530, Shubhrajyoti D wrote:
 Currently the OMAP4 doesnot hit device off still the
 driver may have support for it.Adding support for the
 same.

 Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
 I guess since the previous set has been taken by Kevin
 then these will be too.
 Sure, I'll pick these up, but it's probably to late for v3.1.

 We've already submitted the bulk of the OMAP stuff for v3.1.
 Kevin in the folowing I tried taking the comments do do have any
 further comments or suggestions.

 http://www.spinics.net/lists/linux-i2c/msg05823.html

Sorry, my ti.com email got unsubscribed from vger lists for a couple
days around July 5  6, so I missed that one.

It's always best to directly Cc people you are expecting to get review
comments from.

I'll reply to your updated one shortly.

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] OMAP4: I2C : I2C context save

[Kevin Hilman]

Shubhrajyoti D shubhrajy...@ti.com writes:

 Restore of context is not done for OMAP4. This patch 

Subject says context *save*, here says context *restore.*

 adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
 hwmod which activates the restore for OMAP4.

s/hwmod/hwmod data/

 Currently the OMAP4 doesnot hit device off still the

s/doesnot/does not/

 driver may have support for it.

Also, since this is a patch to the hwmod data, the subject
prefix should be something like:

OMAP4: hwmod_data: I2C: set flag to restore context

or something similar.

Also, this is the 2nd (or maybe 3rd) version of this patch posted.
Please version the patch using [PATCH vN].

Kevin

 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
 Applies on top of patches from Andy Green
 http://www.spinics.net/lists/linux-i2c/msg05632.html
 Tested on OMAP4430

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

 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 index 0fe9556..5e2c748 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class 
 = {
  };
  
  static struct omap_i2c_dev_attr i2c_dev_attr = {
 - .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
 + .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
 + OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
  };
  
  /* i2c1 */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] OMAP4:hwmod: I2C : I2C context save

[Shubhrajyoti D]

Restore of context is not done for OMAP4. This patch 
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = 
{
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
-   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+   OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
 };
 
 /* i2c1 */
-- 
1.7.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 v3] OMAP4:hwmod: I2C : I2C context restore

[Shubhrajyoti D]

Restore of context is not done for OMAP4. This patch 
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = 
{
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
-   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+   OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
 };
 
 /* i2c1 */
-- 
1.7.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

Re: [PATCH v3] OMAP4:hwmod: I2C : I2C context save

[Shubhrajyoti]

Please ignore the patch sent another one with correct sub line
On Thursday 14 July 2011 10:03 PM, Shubhrajyoti D wrote:


Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = 
{
  };

  static struct omap_i2c_dev_attr i2c_dev_attr = {
-   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+   .flags  = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+   OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
  };

  /* i2c1 */


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

Re: [PATCH v3] OMAP4:hwmod: I2C : I2C context restore

[Kevin Hilman]

Shubhrajyoti D shubhrajy...@ti.com writes:

 Restore of context is not done for OMAP4. This patch 
 adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
 hwmod data which activates the restore for OMAP4.
 Currently the OMAP4 does not hit device off still the
 driver may have support for it.

 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com

Subject should include 'hwmod data', and fix up the spacing:

OMAP4: hwmod data: I2C: add flag for context restore

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] omap-serial: Allow IXON and IXOFF to be disabled.

[Nick Pelly]

Fixes logic bug that software flow control cannot be disabled, because
serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits
are cleared.

Signed-off-by: Nick Pelly npe...@google.com
---
 drivers/tty/serial/omap-serial.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..6d3ec14 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -806,8 +806,7 @@ serial_omap_set_termios(struct uart_port *port, struct 
ktermios *termios,
 
serial_omap_set_mctrl(up-port, up-port.mctrl);
/* Software Flow Control Configuration */
-   if (termios-c_iflag  (IXON | IXOFF))
-   serial_omap_configure_xonxoff(up, termios);
+   serial_omap_configure_xonxoff(up, termios);
 
spin_unlock_irqrestore(up-port.lock, flags);
dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-pdev-id);
-- 
1.7.5.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/2] TI816X: Add minimal hwmod data

[Kevin Hilman]

Hi Hemant,

On Wed, 2011-07-13 at 05:07 +0530, Pedanekar, Hemant wrote:

 Any comments on the hwmod and clock patch sets?

I just discovered that other devices in this family are coming along
which will require changing the names/macros/etc. from 816x to 81xx[1].

Merging this series, followed shortly by another series that renames
everything is the type of churn we are trying to avoid.

To avoid this kind of churn, I recommend starting from the broader
family name first.

Kevin

http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=ce17fa2f527ed614399e577fc2fd5cd3624ee501

--
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/6] OMAP3+ Clock Fixes

[Jon Hunter]

From: Jon Hunter jon-hun...@ti.com

Various clock fixes for OMAP3 and OMAP4 devices.
Plus one debug patch (if anyone is interested).

Jon Hunter (4):
  OMAP4: Add missing clock divider for OCP_ABE_ICLK
  OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate
  OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
  OMAP: Add debugfs node to show the summary of all clocks

Mike Turquette (2):
  OMAP4: Clock: round_rate and recalc functions for DPLL_ABE
  OMAP3+: use DPLL's round_rate when setting rate

 arch/arm/mach-omap2/clkt_dpll.c  |   51 +++--
 arch/arm/mach-omap2/clock.h  |2 +
 arch/arm/mach-omap2/clock44xx.h  |1 +
 arch/arm/mach-omap2/clock44xx_data.c |   20 +++--
 arch/arm/mach-omap2/dpll3xxx.c   |6 ++--
 arch/arm/mach-omap2/dpll44xx.c   |   45 ++
 arch/arm/plat-omap/clock.c   |   39 ++
 7 files changed, 142 insertions(+), 22 deletions(-)

-- 
1.7.4.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 1/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK

[Jon Hunter]

From: Jon Hunter jon-hun...@ti.com

The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...

ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK

The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However, the dividers for
the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
and the OCP_ABE_ICLK is 1.

The above relationship between the AESS_FCLK and OCP_ABE_ICLK
dividers ensure that the OCP_ABE_ICLK clock is always half the
frequency of the ABE_CLK...

OCP_ABE_ICLK = ABE_FCLK/2

The divider for the OCP_ABE_ICLK is currently missing so add a
divider that will ensure the OCP_ABE_ICLK frequency is always half
the ABE_FCLK frequency.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 8c96567..6e158ce 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1301,11 +1301,25 @@ static struct clk mcasp3_fclk = {
.recalc = followparent_recalc,
 };
 
+static const struct clksel_rate div2_2to1_rates[] = {
+   { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+   { .div = 2, .val = 0, .flags = RATE_IN_4430 },
+   { .div = 0 },
+};
+
+static const struct clksel ocp_abe_iclk_div[] = {
+   { .parent = aess_fclk, .rates = div2_2to1_rates },
+   { .parent = NULL },
+};
+
 static struct clk ocp_abe_iclk = {
.name   = ocp_abe_iclk,
.parent = aess_fclk,
+   .clksel = ocp_abe_iclk_div,
+   .clksel_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
+   .clksel_mask= OMAP4430_CLKSEL_AESS_FCLK_MASK,
.ops= clkops_null,
-   .recalc = followparent_recalc,
+   .recalc = omap2_clksel_recalc,
 };
 
 static struct clk per_abe_24m_fclk = {
-- 
1.7.4.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/6] OMAP4: Clock: round_rate and recalc functions for DPLL_ABE

[Jon Hunter]

From: Mike Turquette mturque...@ti.com

OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:

Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
applicable to DPLL_ABE).

Add new round_rate() and recalc() functions for OMAP4, that check the
setting of REGM4XEN bit and handle this appropriately. The new functions
are a simple wrapper on top of the existing omap2_dpll_round_rate() and
omap2_dpll_get_rate() functions to handle the REGM4XEN bit.

The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.

Signed-off-by: Mike Turquette mturque...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clock.h  |2 +
 arch/arm/mach-omap2/clock44xx.h  |1 +
 arch/arm/mach-omap2/clock44xx_data.c |4 +-
 arch/arm/mach-omap2/dpll44xx.c   |   45 ++
 4 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index e10ff2b..1e505fe 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -64,6 +64,8 @@ void omap3_noncore_dpll_disable(struct clk *clk);
 int omap4_dpllmx_gatectrl_read(struct clk *clk);
 void omap4_dpllmx_allow_gatectrl(struct clk *clk);
 void omap4_dpllmx_deny_gatectrl(struct clk *clk);
+long omap4_dpll_regm4xen_round_rate(struct clk *clk, unsigned long 
target_rate);
+unsigned long omap4_dpll_regm4xen_recalc(struct clk *clk);
 
 #ifdef CONFIG_OMAP_RESET_CLOCKS
 void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 6be1095..a1cdaa9 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -14,6 +14,7 @@
  */
 #define OMAP4430_MAX_DPLL_MULT 2047
 #define OMAP4430_MAX_DPLL_DIV  128
+#define OMAP4430_REGM4XEN_MULT 4
 
 int omap4xxx_clk_init(void);
 
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 6e158ce..9b58d93 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -270,8 +270,8 @@ static struct clk dpll_abe_ck = {
.dpll_data  = dpll_abe_dd,
.init   = omap2_init_dpll_parent,
.ops= clkops_omap3_noncore_dpll_ops,
-   .recalc = omap3_dpll_recalc,
-   .round_rate = omap2_dpll_round_rate,
+   .recalc = omap4_dpll_regm4xen_recalc,
+   .round_rate = omap4_dpll_regm4xen_round_rate,
.set_rate   = omap3_noncore_dpll_set_rate,
 };
 
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 4e4da61..4f31530 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -19,6 +19,7 @@
 #include plat/clock.h
 
 #include clock.h
+#include clock44xx.h
 #include cm-regbits-44xx.h
 
 /* Supported only on OMAP4 */
@@ -82,3 +83,47 @@ const struct clkops clkops_omap4_dpllmx_ops = {
.deny_idle  = omap4_dpllmx_deny_gatectrl,
 };
 
+unsigned long omap4_dpll_regm4xen_recalc(struct clk *clk)
+{
+   u32 v;
+   unsigned long rate;
+   struct dpll_data *dd;
+
+   if (!clk || !clk-dpll_data)
+   return -EINVAL;
+
+   dd = clk-dpll_data;
+
+   rate = omap2_get_dpll_rate(clk);
+
+   /* regm4xen adds a multiplier of 4 to DPLL calculations */
+   v = __raw_readl(dd-control_reg);
+   if (v  OMAP4430_DPLL_REGM4XEN_MASK)
+   rate *= OMAP4430_REGM4XEN_MULT;
+
+   return rate;
+}
+
+long omap4_dpll_regm4xen_round_rate(struct clk *clk, unsigned long target_rate)
+{
+   u32 v;
+   struct dpll_data *dd;
+
+   if (!clk || !clk-dpll_data)
+   return -EINVAL;
+
+   dd = clk-dpll_data;
+
+   /* regm4xen adds a multiplier of 4 to DPLL calculations */
+   v = __raw_readl(dd-control_reg)  OMAP4430_DPLL_REGM4XEN_MASK;
+
+   if (v)
+   target_rate = target_rate / OMAP4430_REGM4XEN_MULT;
+
+   omap2_dpll_round_rate(clk, target_rate);
+
+   if (v)
+   clk-dpll_data-last_rounded_rate *= OMAP4430_REGM4XEN_MULT;
+
+   return clk-dpll_data-last_rounded_rate;
+}
-- 
1.7.4.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/6] OMAP3+: use DPLL's round_rate when setting rate

[Jon Hunter]

From: Mike Turquette mturque...@ti.com

omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.

Also the rounded rate can differ from target rate, so to better reflect
reality set clk-rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.

An example of both of these needs is DPLL_ABE on OMAP4 which can have a 4x
multiplier on top of the usual MN dividers depending on register settings.
This requires a special round_rate function that might yield a rate
different from the initial target.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/dpll3xxx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..73a1595 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -455,7 +455,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned 
long rate)
new_parent = dd-clk_bypass;
} else {
if (dd-last_rounded_rate != rate)
-   omap2_dpll_round_rate(clk, rate);
+   rate = clk-round_rate(clk, rate);
 
if (dd-last_rounded_rate == 0)
return -EINVAL;
-- 
1.7.4.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 4/6] OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate

[Jon Hunter]

From: Jon Hunter jon-hun...@ti.com

This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.

omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.

An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/dpll3xxx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 73a1595..7916f66 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -390,7 +390,7 @@ int omap3_noncore_dpll_enable(struct clk *clk)
 * propagating?
 */
if (!r)
-   clk-rate = omap2_get_dpll_rate(clk);
+   clk-rate = clk-recalc(clk);
 
return r;
 }
@@ -435,7 +435,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned 
long rate)
if (!dd)
return -EINVAL;
 
-   if (rate == omap2_get_dpll_rate(clk))
+   if (rate == clk-recalc(clk))
return 0;
 
/*
-- 
1.7.4.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 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices

[Jon Hunter]

From: Jon Hunter jon-hun...@ti.com

The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.

For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
other DPLLs.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clkt_dpll.c |   51 ++
 1 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index bcffee0..e069a9b 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -46,10 +46,19 @@
 (DPLL_SCALE_FACTOR / DPLL_SCALE_BASE))
 
 /* DPLL valid Fint frequency band limits - from 34xx TRM Section 4.7.6.2 */
-#define DPLL_FINT_BAND1_MIN75
-#define DPLL_FINT_BAND1_MAX210
-#define DPLL_FINT_BAND2_MIN750
-#define DPLL_FINT_BAND2_MAX2100
+#define OMAP3430_DPLL_FINT_BAND1_MIN   75
+#define OMAP3430_DPLL_FINT_BAND1_MAX   210
+#define OMAP3430_DPLL_FINT_BAND2_MIN   750
+#define OMAP3430_DPLL_FINT_BAND2_MAX   2100
+
+/*
+ * DPLL valid Fint frequency range for OMAP36xx and OMAP4xxx.
+ * From device data manual section 4.3 DPLL and DLL Specifications.
+ */
+#define OMAP3PLUS_DPLL_FINT_JTYPE_MIN  50
+#define OMAP3PLUS_DPLL_FINT_JTYPE_MAX  250
+#define OMAP3PLUS_DPLL_FINT_MIN32000
+#define OMAP3PLUS_DPLL_FINT_MAX5200
 
 /* _dpll_test_fint() return codes */
 #define DPLL_FINT_UNDERFLOW-1
@@ -71,33 +80,43 @@
 static int _dpll_test_fint(struct clk *clk, u8 n)
 {
struct dpll_data *dd;
-   long fint;
+   long fint, fint_min, fint_max;
int ret = 0;
 
dd = clk-dpll_data;
 
/* DPLL divider must result in a valid jitter correction val */
fint = clk-parent-rate / n;
-   if (fint  DPLL_FINT_BAND1_MIN) {
 
+   if (cpu_is_omap24xx()) {
+   /* Should not be called for OMAP2, so warn if it is called */
+   WARN(1, No fint limits available for OMAP2!\n);
+   return DPLL_FINT_INVALID;
+   } else if (cpu_is_omap3430()) {
+   fint_min = OMAP3430_DPLL_FINT_BAND1_MIN;
+   fint_max = OMAP3430_DPLL_FINT_BAND2_MAX;
+   } else if (dd-flags  DPLL_J_TYPE) {
+   fint_min = OMAP3PLUS_DPLL_FINT_JTYPE_MIN;
+   fint_max = OMAP3PLUS_DPLL_FINT_JTYPE_MAX;
+   } else {
+   fint_min = OMAP3PLUS_DPLL_FINT_MIN;
+   fint_max = OMAP3PLUS_DPLL_FINT_MAX;
+   }
+
+   if (fint  fint_min) {
pr_debug(rejecting n=%d due to Fint failure, 
 lowering max_divider\n, n);
dd-max_divider = n;
ret = DPLL_FINT_UNDERFLOW;
-
-   } else if (fint  DPLL_FINT_BAND1_MAX 
-  fint  DPLL_FINT_BAND2_MIN) {
-
-   pr_debug(rejecting n=%d due to Fint failure\n, n);
-   ret = DPLL_FINT_INVALID;
-
-   } else if (fint  DPLL_FINT_BAND2_MAX) {
-
+   } else if (fint  fint_max) {
pr_debug(rejecting n=%d due to Fint failure, 
 boosting min_divider\n, n);
dd-min_divider = n;
ret = DPLL_FINT_INVALID;
-
+   } else if (cpu_is_omap3430()  fint  OMAP3430_DPLL_FINT_BAND1_MAX 
+  fint  OMAP3430_DPLL_FINT_BAND2_MIN) {
+   pr_debug(rejecting n=%d due to Fint failure\n, n);
+   ret = DPLL_FINT_INVALID;
}
 
return ret;
-- 
1.7.4.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 6/6] OMAP: Add debugfs node to show the summary of all clocks

[Jon Hunter]

From: Jon Hunter jon-hun...@ti.com

Add a debugfs node called summary to /sys/kernel/debug/clock/
that displays a quick summary of all clocks registered in the
clocks structure. The format of the output from this node is:

clock-name parent-name rate usecount

This debugfs node was very helpful for taking a quick snapshot of
the linux clock tree for OMAP and ensuring clock frequencies
calculated by the kernel were indeed correct. This patch helped
uncover some bugs in the linux clock tree for OMAP4.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/plat-omap/clock.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..156b27d 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -475,8 +475,41 @@ int __init clk_init(struct clk_functions * custom_clocks)
 /*
  * debugfs support to trace clock tree hierarchy and attributes
  */
+
+#include linux/debugfs.h
+#include linux/seq_file.h
+
 static struct dentry *clk_debugfs_root;
 
+static int clk_dbg_show_summary(struct seq_file *s, void *unused)
+{
+   struct clk *c;
+   struct clk *pa;
+
+   seq_printf(s, %-30s %-30s %-10s %s\n,
+   clock-name, parent-name, rate, use-count);
+
+   list_for_each_entry(c, clocks, node) {
+   pa = c-parent;
+   seq_printf(s, %-30s %-30s %-10lu %d\n,
+   c-name, pa ? pa-name : none, c-rate, c-usecount);
+   }
+
+   return 0;
+}
+
+static int clk_dbg_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, clk_dbg_show_summary, inode-i_private);
+}
+
+static const struct file_operations debug_clock_fops = {
+   .open   = clk_dbg_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
 static int clk_debugfs_register_one(struct clk *c)
 {
int err;
@@ -551,6 +584,12 @@ static int __init clk_debugfs_init(void)
if (err)
goto err_out;
}
+
+   d = debugfs_create_file(summary, S_IRUGO,
+   d, NULL, debug_clock_fops);
+   if (!d)
+   return -ENOMEM;
+
return 0;
 err_out:
debugfs_remove_recursive(clk_debugfs_root);
-- 
1.7.4.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

RE: [PATCH 1/2] TI816X: Add minimal hwmod data

[Pedanekar, Hemant]

Hi Kevin,

Hilman, Kevin wrote on Friday, July 15, 2011 3:28 AM:

 Hi Hemant,
 
 On Wed, 2011-07-13 at 05:07 +0530, Pedanekar, Hemant wrote:
 
 Any comments on the hwmod and clock patch sets?
 
 I just discovered that other devices in this family are coming along
 which will require changing the names/macros/etc. from 816x
 to 81xx[1].
 
 Merging this series, followed shortly by another series that renames
 everything is the type of churn we are trying to avoid.
 
 To avoid this kind of churn, I recommend starting from the broader family
 name first. 
 
 Kevin
 
 http://arago-project.org/git/projects/?p=linux-omap3.git;a=com
 mit;h=ce17fa2f527ed614399e577fc2fd5cd3624ee501

Sure, I will send in TI814X patches then.

Thanks.

   Hemant

Re: [PATCH] omap-serial: Allow IXON and IXOFF to be disabled.

[Govindraj]

On Fri, Jul 15, 2011 at 12:19 AM, Nick Pelly npe...@google.com wrote:
 Fixes logic bug that software flow control cannot be disabled, because
 serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits
 are cleared.


Thanks, Good Point.

need to send to this patch to linux-ser...@vger.kernel.org,
CC'ing Greg Kroah-Hartman gre...@suse.de

will be merged through tty tree.

feel free to add

Acked-by: Govindraj.R govindraj.r...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com

--
Thanks,
Govindraj.R

 Signed-off-by: Nick Pelly npe...@google.com
 ---
  drivers/tty/serial/omap-serial.c |    3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/omap-serial.c 
 b/drivers/tty/serial/omap-serial.c
 index 47cadf4..6d3ec14 100644
 --- a/drivers/tty/serial/omap-serial.c
 +++ b/drivers/tty/serial/omap-serial.c
 @@ -806,8 +806,7 @@ serial_omap_set_termios(struct uart_port *port, struct 
 ktermios *termios,

        serial_omap_set_mctrl(up-port, up-port.mctrl);
        /* Software Flow Control Configuration */
 -       if (termios-c_iflag  (IXON | IXOFF))
 -               serial_omap_configure_xonxoff(up, termios);
 +       serial_omap_configure_xonxoff(up, termios);

        spin_unlock_irqrestore(up-port.lock, flags);
        dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-pdev-id);
 --
 1.7.5.2

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

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