date:20091126

RE: [PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c

2009-11-26 Thread kalle.jokiniemi

Hi Ben,

Could you take this patch to i2c tree? The patch has been discussed in 
linux-omap list, and this version was the one that was agreed to pushed forward.

http://marc.info/?l=linux-omapm=125907598412786w=2


I tried it on top of linus' tree and it applied fine. 

- Kalle


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Jokiniemi Kalle (Nokia-D/Tampere)
 Sent: 25. marraskuuta 2009 20:04
 To: ben-li...@fluff.org; linux-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org; Ujfalusi Peter 
 (Nokia-D/Tampere); Hogander Jouni (Nokia-D/Tampere); 
 khil...@deeprootsystems.com; ext Kalle Jokiniemi; Moiz 
 Sonasath; Jarkko Nikula; Paul Walmsley; Nishanth Menon
 Subject: [PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c
 
 From: ext Kalle Jokiniemi kalle.jokini...@digia.com
 
 While waiting for completion of the i2c transfer, the MPU 
 could hit OFF mode and cause several msecs of delay that made 
 i2c transfers fail more often. The extra delays and 
 subsequent re-trys cause i2c clocks to be active more often. 
 This has also an negative effect on power consumption.
 
 Created a mechanism for passing and using the constraint 
 setting function in driver code. The used mpu wake up latency 
 constraints are now set individually per bus, and they are 
 calculated based on clock rate and fifo size.
 
 Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley, and 
 Nishanth Menon for tuning out the details of this patch.
 
 Cc: Moiz Sonasath m-sonas...@ti.com
 Cc: Jarkko Nikula jhnik...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Nishanth Menon n...@ti.com
 Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
 ---
  arch/arm/plat-omap/i2c.c  |   54 
 +++-
  drivers/i2c/busses/i2c-omap.c |   25 ---
  include/linux/i2c-omap.h  |9 +++
  3 files changed, 72 insertions(+), 16 deletions(-)  create 
 mode 100644 include/linux/i2c-omap.h
 
 diff --git a/arch/arm/plat-omap/i2c.c 
 b/arch/arm/plat-omap/i2c.c index 8b84839..3c122cd 100644
 --- a/arch/arm/plat-omap/i2c.c
 +++ b/arch/arm/plat-omap/i2c.c
 @@ -26,8 +26,10 @@
  #include linux/kernel.h
  #include linux/platform_device.h
  #include linux/i2c.h
 +#include linux/i2c-omap.h
  #include mach/irqs.h
  #include mach/mux.h
 +#include mach/omap-pm.h
  
  #define OMAP_I2C_SIZE0x3f
  #define OMAP1_I2C_BASE   0xfffb3800
 @@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
   },  \
   }
  
 -static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
 +static struct omap_i2c_bus_platform_data 
 +i2c_pdata[ARRAY_SIZE(i2c_resources)];
  static struct platform_device omap_i2c_devices[] = {
 - I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
 + I2C_DEV_BUILDER(1, i2c_resources[0], i2c_pdata[0]),
  #if  defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
 - I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
 + I2C_DEV_BUILDER(2, i2c_resources[1], i2c_pdata[1]),
  #endif
  #if  defined(CONFIG_ARCH_OMAP34XX)
 - I2C_DEV_BUILDER(3, i2c_resources[2], i2c_rate[2]),
 + I2C_DEV_BUILDER(3, i2c_resources[2], i2c_pdata[2]),
  #endif
  };
  
 @@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
  
  #define OMAP_I2C_CMDLINE_SETUP   (BIT(31))
  
 +#ifdef CONFIG_ARCH_OMAP34XX
 +/*
 + * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
 + * @dev: i2c bus device pointer
 + * @val: latency constraint to set, -1 to disable constraint
 + *
 + * When waiting for completion of a i2c transfer, we need to 
 set a wake 
 +up
 + * latency constraint for the MPU. This is to ensure quick enough 
 +wakeup from
 + * idle, when transfer completes.
 + */
 +static void omap_i2c_set_wfc_mpu_wkup_lat(struct device 
 *dev, int val) 
 +{
 + omap_pm_set_max_mpu_wakeup_lat(dev, val); } #endif
 +
 +static void __init omap_set_i2c_constraint_func(
 + struct omap_i2c_bus_platform_data *pd) {
 + if (cpu_is_omap34xx())
 + pd-set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
 + else
 + pd-set_mpu_wkup_lat = NULL;
 +}
 +
  static void __init omap_i2c_mux_pins(int bus)  {
   int scl, sda;
 @@ -180,8 +207,8 @@ static int __init omap_i2c_bus_setup(char *str)
   get_options(str, 3, ints);
   if (ints[0]  2 || ints[1]  1 || ints[1]  ports)
   return 0;
 - i2c_rate[ints[1] - 1] = ints[2];
 - i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
 + i2c_pdata[ints[1] - 1].clkrate = ints[2];
 + i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
  
   return 1;
  }
 @@ -195,9 +222,10 @@ static int __init 
 omap_register_i2c_bus_cmdline(void)
  {
   int i, err = 0;
  
 - for (i = 0; i  ARRAY_SIZE(i2c_rate); i++)
 - if (i2c_rate[i]  OMAP_I2C_CMDLINE_SETUP) {
 - i2c_rate[i] =

Re: [PATCH 0/8] Series short description

2009-11-26 Thread Tony Lindgren

* Hemanth V heman...@ti.com [091125 22:44]:
 - Original Message - From: Tony Lindgren
 t...@atomide.com
 To: linux-arm-ker...@lists.infradead.org
 Cc: linux-omap@vger.kernel.org
 Sent: Thursday, November 26, 2009 5:48 AM
 Subject: [PATCH 0/8] Series short description

 Hi all,

 Here are some omap mux updates for review. These
 are intended for the v2.6.33 merge window.

 Initially this series changes the omap34xx mux
 code, I'm planning on adding 3630, 2420, and 2430
 code later on.

 There are several reasons why we need better mux
 code:

 - We want to make the mux code more generic and this
  will allow us to use the internal signal names and
  gpio numbers instead of mux register offsets. The
  internal signal names stay the same across omap
  generations for some devices.

 - We need to map mux registers to GPIO registers for
  dynamic muxing of the GPIO pins during off-idle.

 - We want to be able to override the bootloader mux
  values for the modded boards, such as the Beagle.

 - We want to have the mux signals and balls available
  under debugfs for debugging new drivers.

 Does it also detect conflicts when two drivers try
 to step on each other and overwrite the mux settings of
 other. SPI and EHCI was one of the problems I faced.

It does not, but that could be added by adding a
usecount to struct omap_mux.

In fact it's already a problem with the cmdline mux
options as that does not prevent other init code from
muxing over the cmdline options.

But then again, just being able to override the
bootloader settings might do the trick for most people
customizing their Beagle boards.

Currently we're not checking the return values for
muxing, so adding a usecount sounds like a follow-up
patch after these changes.

Regards,

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

Re: [PATCH 1/2 v2] musb: Add context save and restore support

2009-11-26 Thread Romit Dasgupta

 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2167,21 +2167,163 @@ static int __devexit musb_remove(struct 
 platform_device *pdev)
 
  #ifdef CONFIG_PM
 
 +static struct musb_context_registers musb_context;
 +
 +void musb_save_context(void __iomem *musb_base)
 +{
 +   int i;
 +
 +   musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
 +   musb_context.power = musb_readb(musb_base, MUSB_POWER);
 +   musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
 +   musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
 +   musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
 +   musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
Not necessary for gadget
 +   musb_context.index = musb_readb(musb_base, MUSB_INDEX);

 +   musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
Not sure if it is necessary for gadget.

 +   musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
 +
 +   for (i = 0; i  MUSB_C_NUM_EPS; ++i) {
 +   musb_writeb(musb_base, MUSB_INDEX, i);
 +   musb_context.index_regs[i].txmaxp =
 +   musb_readw(musb_base, 0x10 + MUSB_TXMAXP);
 +   musb_context.index_regs[i].txcsr =
 +   musb_readw(musb_base, 0x10 + MUSB_TXCSR);
 +   musb_context.index_regs[i].rxmaxp =
 +   musb_readw(musb_base, 0x10 + MUSB_RXMAXP);
 +   musb_context.index_regs[i].rxcsr =
 +   musb_readw(musb_base, 0x10 + MUSB_RXCSR);
 +   musb_context.index_regs[i].rxcount =
 +   musb_readw(musb_base, 0x10 + MUSB_RXCOUNT);
 +   musb_context.index_regs[i].txtype =
 +   musb_readb(musb_base, 0x10 + MUSB_TXTYPE);
 +   musb_context.index_regs[i].txinterval =
 +   musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL);
 +   musb_context.index_regs[i].rxtype =
 +   musb_readb(musb_base, 0x10 + MUSB_RXTYPE);
 +   musb_context.index_regs[i].rxinterval =
 +   musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL);
 +
 +   musb_context.index_regs[i].txfifoadd =
 +   musb_read_txfifoadd(musb_base);
 +   musb_context.index_regs[i].rxfifoadd =
 +   musb_read_rxfifoadd(musb_base);
 +   musb_context.index_regs[i].txfifosz =
 +   musb_read_txfifosz(musb_base);
 +   musb_context.index_regs[i].rxfifosz =
 +   musb_read_rxfifosz(musb_base);

If MUSB_CONFIGDATA_DYNFIFO is not set then saving FIFO address and sizes are
probably not necessary. Not sure if they are detrimental as well.
 +
 +   musb_context.index_regs[i].txfunaddr =
 +   musb_read_txfunaddr(musb_base, i);
 +   musb_context.index_regs[i].txhubaddr =
 +   musb_read_txhubaddr(musb_base, i);
 +   musb_context.index_regs[i].txhubport =
 +   musb_read_txhubport(musb_base, i);
 +
 +   musb_context.index_regs[i].rxfunaddr =
 +   musb_read_rxfunaddr(musb_base, i);
 +   musb_context.index_regs[i].rxhubaddr =
 +   musb_read_rxhubaddr(musb_base, i);
 +   musb_context.index_regs[i].rxhubport =
 +   musb_read_rxhubport(musb_base, i);
 +   }
If we are in gadget mode, do we have to save this?
 +
 +   musb_writeb(musb_base, MUSB_INDEX, musb_context.index);
 +
 +   musb_platform_save_context(musb_context);
 +}
Similar for restore.
  static int musb_suspend(struct device *dev)
  {
 struct platform_device *pdev = to_platform_device(dev);
 unsigned long   flags;
 struct musb *musb = dev_to_musb(pdev-dev);
 +   u8 reg;
 
 if (!musb-clock)
 return 0;
 
 spin_lock_irqsave(musb-lock, flags);
 
 +   musb_save_context(musb-mregs);
 +
 if (is_peripheral_active(musb)) {
 -   /* FIXME force disconnect unless we know USB will wake
 -* the system up quickly enough to respond ...
 +   /* System is entering into suspend where gadget would not be
 +* able to respond to host and thus it will be in an unknown
 +* state for host.Re-enumemation of gadget is required after
 +* resume to make the gadget functional thus doing a force
 +* disconnect.
  */
 +   reg = musb_readb(musb-mregs, MUSB_POWER);
 +   reg = ~MUSB_POWER_SOFTCONN;
 +   musb_writeb(musb-mregs, MUSB_POWER, reg);
After this softdisconnect when we subsequently get reconnected followed by a
reset we could have changed our speed (LS,FS, HS). In your resume routine we are
writing back our previous

RE: [PATCH 1/2 v2] musb: Add context save and restore support

2009-11-26 Thread Gupta, Ajay Kumar

Hi,
 -Original Message-
 From: Dasgupta, Romit
 Sent: Thursday, November 26, 2009 2:33 PM
 To: Gupta, Ajay Kumar
 Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
 felipe.ba...@nokia.com; Gadiyar, Anand
 Subject: Re: [PATCH 1/2 v2] musb: Add context save and restore support
 
  --- a/drivers/usb/musb/musb_core.c
  +++ b/drivers/usb/musb/musb_core.c
  @@ -2167,21 +2167,163 @@ static int __devexit musb_remove(struct
 platform_device *pdev)
 
   #ifdef CONFIG_PM
 
  +static struct musb_context_registers musb_context;
  +
  +void musb_save_context(void __iomem *musb_base)
  +{
  +   int i;
  +
  +   musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
  +   musb_context.power = musb_readb(musb_base, MUSB_POWER);
  +   musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
  +   musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
  +   musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);

  +   musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
 Not necessary for gadget
  +   musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
 Not sure if it is necessary for gadget.

Right!

..so we can all #ifdefs to save/restore gadget or host only registers.
 

  +   musb_context.index = musb_readb(musb_base, MUSB_INDEX);
 
 
snip
  +   musb_read_txfifosz(musb_base);
  +   musb_context.index_regs[i].rxfifosz =
  +   musb_read_rxfifosz(musb_base);
 
 If MUSB_CONFIGDATA_DYNFIFO is not set then saving FIFO address and sizes
 are probably not necessary. Not sure if they are detrimental as well.

We can add it within DYNFIFO check.

  +
  +   musb_context.index_regs[i].txfunaddr =
  +   musb_read_txfunaddr(musb_base, i);
  +   musb_context.index_regs[i].txhubaddr =

snip.

   */
  +   reg = musb_readb(musb-mregs, MUSB_POWER);
  +   reg = ~MUSB_POWER_SOFTCONN;
  +   musb_writeb(musb-mregs, MUSB_POWER, reg);
 After this softdisconnect when we subsequently get reconnected followed by
 a reset we could have changed our speed (LS,FS, HS).

I didn't get it completely. I think as a peripheral USB speed will remain
same after resume for the gadget driver it was before suspend?

If we intend to change the gadget driver then we may have support for a
different speed but it would anyways happen after resume is completed.

Regards,
Ajay
 In your resume 
 routine we are writing back our previous speed. I am not sure here but is 
 it not possible that we have reset the controller and then restored back 
 the old speed overwriting the new speed?




--
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: DSS2 panel question

2009-11-26 Thread Tomi Valkeinen

On Wed, 2009-11-25 at 11:53 +0100, ext Grazvydas Ignotas wrote:
 On Mon, Nov 23, 2009 at 7:41 PM, TAO HU tgh...@motorola.com wrote:
  Hi,
 
  One idea as below
 
  struct spi_dss_device {
   struct omap_dss_device dss_dev;
   struct spi_dss_dev_priv  * spi_data;
  } spi_dss_dev;
 
 Hm, omap_dss_register_device() takes omap_dss_driver, not
 omap_dss_device. Anyway that wouldn't work if there were 2 instances
 of same panel in one system I guess, as 2 different spi_data instances
 would probe, when there is only one omap_dss_driver.
 
 Instead I'm thinking to link omap_dss_device with spi in board file
 itself by (ab)using platform_data:
 
 static struct omap_dss_device pandora_lcd_device = {
 ...
 };
 
 struct spi_board_info pandora_spi_board_info = {
   .bus_num = 1,
   ...
   .platform_data = pandora_lcd_device,
 };
 
 Then in panel driver:
 
 int spi_probe(struct spi_device *spi)
 {
   struct omap_dss_device *dssdev = spi-dev.platform_data;
   dev_set_drvdata(dssdev-dev, spi);
 }
 
 static int lcd_probe(struct omap_dss_device *dssdev)
 {
   struct spi_device *spi = dev_get_drvdata(dssdev-dev);
 }
 
 Tomi, does that look reasonable to you?

Yes, the linking has to be done inside the board file somehow. I need to
try this at some point with N900's panel driver, but I think it looks
good.

I think you could also link it other way around, store the
spi_board_info inside the dss_device, but I don't immediately see that
this way is better than the other.

 Tomi


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

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Mark Brown

On Thu, Nov 26, 2009 at 08:31:11AM +0530, Aggarwal, Anuj wrote:

 I have already tried that but it doesn't fix the problem entirely.
 Still, I was not able to playback properly because the bias settings
 were not handled correctly and as you can see, it writes to some 
 invalid registers too (all registers don't exist between 0 and ARRAY_SIZE).

Please also note the following patch which is queued for 2.6.32:

commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date:   Mon Nov 23 13:11:53 2009 +

ASoC: Fix suspend with active audio streams

When we get a stream suspend event force the power down since otherwise
the stream would remain marked as active.  In future we'll probably want
to make this stream-specific and add an interface to make the power down
of other widgets optional in order to support leaving bypass paths
active while suspending the processor.

Cc: sta...@kernel.org
Reported-by: Joonyoung Shim jy0922.s...@samsung.com
Tested-by: Joonyoung Shim jy0922.s...@samsung.com
Acked-by: Liam Girdwood l...@slimlogic.co.uk
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index d89f6dc..66d4c16 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -973,9 +973,19 @@ static int dapm_power_widgets(struct snd_soc_codec *codec, 
int event)
if (!w-power_check)
continue;
 
-   power = w-power_check(w);
-   if (power)
-   sys_power = 1;
+   /* If we're suspending then pull down all the 
+* power. */
+   switch (event) {
+   case SND_SOC_DAPM_STREAM_SUSPEND:
+   power = 0;
+   break;
+
+   default:
+   power = w-power_check(w);
+   if (power)
+   sys_power = 1;
+   break;
+   }
 
if (w-power == power)
continue;
@@ -999,8 +1009,12 @@ static int dapm_power_widgets(struct snd_soc_codec 
*codec, int event)
case SND_SOC_DAPM_STREAM_RESUME:
sys_power = 1;
break;
+   case SND_SOC_DAPM_STREAM_SUSPEND:
+   sys_power = 0;
+   break;
case SND_SOC_DAPM_STREAM_NOP:
sys_power = codec-bias_level != SND_SOC_BIAS_STANDBY;
+   break;
default:
break;
}
--
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 v2] musb: Add context save and restore support

2009-11-26 Thread Gadiyar, Anand

 snip.
 
*/
   +   reg = musb_readb(musb-mregs, MUSB_POWER);
   +   reg = ~MUSB_POWER_SOFTCONN;
   +   musb_writeb(musb-mregs, MUSB_POWER, reg);
  After this softdisconnect when we subsequently get reconnected followed by
  a reset we could have changed our speed (LS,FS, HS).
 
 I didn't get it completely. I think as a peripheral USB speed will remain
 same after resume for the gadget driver it was before suspend?
 
 If we intend to change the gadget driver then we may have support for a
 different speed but it would anyways happen after resume is completed.
 

The host side might change, but that shouldn't affect us. This bit is
used to tell MUSB (acting as a peripheral) if it should attempt
to enumerate at HS or not - it will always fall back to FS if the host
does not support it.

So Ajay is correct in restoring this register.

- Anand
--
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: Enabling HSUSB1 port on OMAP3430 labrador

2009-11-26 Thread Kovacs Peter Tamas


Dear Anand,

thank you very much for your exhaustive answer and help. Unfortunately 
it seems there is no clock signal coming out of the HSUSB1_CLK line.



We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).


I have all these USB related kernel config options enabled:
USB_EHCI_HCD
USB_OHCI_HCD
USB_MUSB_HDRC
TWL4030_USB

My guess was that either EHCI or the Inventra should be the one enabling 
that USB port on the OMAP, but no luck.

The external USB port on the MDK works fine with this configuration.

The pin multiplexing configuration in the board file omap3430-labrador.c 
in u-boot also seems to be correct (although the config of USB1_STP 
seems to be strange, but changing that didn't work either).



HSUSB1 is not supposed to be used with the labrador (do you have a link
to the board schematics with the mods?). HSUSB1 is the EHCI port.
  
What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
wired out on the Logic MDK baseboard so we cannot use that. Thus only 
one possibility remains if we need an extra USB port inside the casing, 
which is HSUSB1.

Not sure why the pad conf is done in u-boot for this board, but maybe
it was a copy-paste thing. That being said, if you've got the part
installed correctly, it ought to work.
  
Yes, I can also see these pin multiplexing configs in 
arch/arm/mach-omap2/usb-ehci.c.
I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
(couldn't find it in menuconfig, but this macro seems to be used in this 
single file).
Still, the clock goes high when powering the board on, and it remains 
there forever.


I recall seeing a TI-specific kernel source in another git repository, 
which had menuconfig options for setting PHY/TLL, maybe the USB code is 
different too?



Note, the ISP1507A is connected to the following pins of the BGA:
HSUSB1_STP (AF10)
HSUSB1_CLK (AE10)
HSUSB1_DIR (AF9)
HSUSB1_NXP (AG9)
HSUSB1_D0 (AF11)
HSUSB1_D1 (AG12)
HSUSB1_D2 (AH12)
HSUSB1_D3 (AH14)
HSUSB1_D4 (AE11)
HSUSB1_D5 (AH9)
HSUSB1_D6 (AF13)
HSUSB1_D7 (AE13)



These are the pads for EHCI. So I suppose that's what you're trying to use.
  

We suspect there might be a confusion here.
According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
also ETK_CLK, MMC3_CMD, GPIO_13).
According to the OMAP3430 Multimedia Processor Data Manual version N 
(OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 
GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
Then, in mach_omap2/usb-ehci.c, I can see  
omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
or GPIO_151, but not USB at all.


So far we have used the pins as seen in the Logic schematic for creating 
an extension board with a number of SPI and GPIO signals, and everything 
worked perfectly. Why are the pins described differently?



Note that EHCI on the OMAP3 supports only the input clocking mode. This
might mean you need to check if you've configured the PHY correctly for
this mode. (No XTAL required, OMAP provides the clock to the PHY).
NXP seems to have removed all mention of this mode from their
data sheets, so you might want to check with them.
  
Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
so it seems not to be compatible with the OMAP3430.
The clock pin of the ISP1504 can be configured for I/O, however this 
component is quite difficult to get, but it seems it's necessary.

Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line?
  
Unfortunately not. There is a constant high in the CLK line during the 
whole poweron and boot process, no matter if I configure the USB to PHY 
or TLL. We've also tried another Logic OMAP MDK unit and the effect is 
the same.


Could you please suggest what can be the cause of no clock signal (and 
other ULPI signals) appearing at all?


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

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

2009-11-26 Thread Thara Gopinath

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

Signed-off-by: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/powerdomain.c |6 ++
 arch/arm/mach-omap2/powerdomains34xx.h|1 +
 arch/arm/plat-omap/include/plat/powerdomain.h |5 -
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index b6990e3..1af447e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -985,6 +985,9 @@ int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
if (pwrdm-banks  (bank + 1))
return -EEXIST;
 
+   if (pwrdm-flags  PWRDM_HAS_MPU_QUIRK)
+   bank = 1;
+
/*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
@@ -1032,6 +1035,9 @@ int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, 
u8 bank)
if (pwrdm-banks  (bank + 1))
return -EEXIST;
 
+   if (pwrdm-flags  PWRDM_HAS_MPU_QUIRK)
+   bank = 1;
+
/*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h 
b/arch/arm/mach-omap2/powerdomains34xx.h
index fd09b08..588f7e0 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -190,6 +190,7 @@ static struct powerdomain mpu_34xx_pwrdm = {
.wkdep_srcs   = mpu_34xx_wkdeps,
.pwrsts   = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
+   .flags= PWRDM_HAS_MPU_QUIRK,
.banks= 1,
.pwrsts_mem_ret   = {
[0] = PWRSTS_OFF_RET,
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h 
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 3d45ee1..ad070a6 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -40,7 +40,10 @@
 
 /* Powerdomain flags */
 #define PWRDM_HAS_HDWR_SAR (1  0) /* hardware save-and-restore support */
-
+#define PWRDM_HAS_MPU_QUIRK(1  1) /* MPU pwr domain has MEM bank 0 bits
+ * in MEM bank 1 position. This is
+ * true for OMAP3430
+ */
 
 /*
  * Number of memory banks that are power-controllable. On OMAP3430, the
-- 
1.5.4.7

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

RE: [PATCH 1/5] OMAP3: Fixed ARM aux ctrl register save/restore

2009-11-26 Thread Gopinath, Thara



-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
Kristo
Sent: Thursday, November 12, 2009 3:37 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 1/5] OMAP3: Fixed ARM aux ctrl register save/restore

From: Tero Kristo tero.kri...@nokia.com

Current value is stored on SDRAM and it is written back during wakeup.
Previously a static value of 0x72 was written there.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/sleep34xx.S |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 4707ba8..8bd5fc5 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -278,7 +278,8 @@ restore:
  mov r1, #0  @ set task id for ROM code in r1
  mov r2, #4  @ set some flags in r2, r6
  mov r6, #0xff
- adr r3, write_aux_control_params@ r3 points to parameters
+ ldr r4, scratchpad_base
+ ldr r3, [r4, #0xBC] @ r3 points to parameters
  mcr p15, 0, r0, c7, c10, 4  @ data write barrier
  mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
  .word   0xE1600071  @ call SMI monitor (smi #1)
@@ -286,14 +287,14 @@ restore:
  b   logic_l1_restore
 l2_inv_api_params:
  .word   0x1, 0x00
-write_aux_control_params:
- .word   0x1, 0x72
 l2_inv_gp:
  /* Execute smi to invalidate L2 cache */
  mov r12, #0x1 @ set up to invalide L2
 smi:.word 0xE1600070 @ Call SMI monitor (smieq)
  /* Write to Aux control register to set some bits */
- mov r0, #0x72
+ ldr r4, scratchpad_base
+ ldr r3, [r4,#0xBC]
+ ldr r0, [r3,#4]
  mov r12, #0x3
  .word 0xE1600070@ Call SMI monitor (smieq)
 logic_l1_restore:
@@ -304,6 +305,7 @@ logic_l1_restore:

  ldr r4, scratchpad_base
  ldr r3, [r4,#0xBC]
+ addsr3, r3, #8
  ldmia   r3!, {r4-r6}
  mov sp, r4
  msr spsr_cxsf, r5
@@ -420,6 +422,9 @@ usettbr0:
 save_context_wfi:
  /*b save_context_wfi*/  @ enable to debug save code
  mov r8, r0 /* Store SDRAM address in r8 */
+ mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
+ mov r4, #0x1@ Number of parameters for restore call
+ stmia   r8!, {r4-r5}
 /* Check what that target sleep state is:stored in r1*/
 /* 1 - Only L1 and logic lost */
 /* 2 - Only L2 lost */

Looks Ok to me. Acked.
--
1.5.4.3

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

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

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

2009-11-26 Thread Mike Rapoport

Tony,

Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [091125 16:17]:
 Hi all,

 Here are some omap mux updates for review. These
 are intended for the v2.6.33 merge window.
 
 Forgot to edit the subject :)
 
 Also, these patches are available in the mux branch
 of the linux-omap tree for easy testing.

After all the discussions we had, what would be preferable way to define the
board mux configuration? The omap_board_mux array or a calls for
omap_mux_init_signal?

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

-- 
Sincerely yours,
Mike.

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

RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display

2009-11-26 Thread Y, Kishore

 -Original Message-
 From: G, Manjunath Kondaiah
 Sent: Tuesday, November 24, 2009 9:44 PM
 To: Y, Kishore; linux-omap@vger.kernel.org
 Subject: RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
 
 
 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
  Sent: Friday, November 20, 2009 7:58 PM
  To: linux-omap@vger.kernel.org
  Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
 
  From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
  From: Mukund Mittal mmit...@ti.com
  Date: Fri, 20 Nov 2009 18:35:26 +0530
  Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
 
  Nec panel has been added which is used on both
  zoom2 and zoom3 boards
 
  Signed-off-by: Kishore Y kishor...@ti.com
  ---
   drivers/video/omap2/displays/panel-nec.c |  291
  ++
   1 files changed, 291 insertions(+), 0 deletions(-)
   create mode 100644 drivers/video/omap2/displays/panel-nec.c
 
  diff --git a/drivers/video/omap2/displays/panel-nec.c
  b/drivers/video/omap2/displays/panel-nec.c
  new file mode 100644
  index 000..c18f3ba
  --- /dev/null
  +++ b/drivers/video/omap2/displays/panel-nec.c
  @@ -0,0 +1,291 @@
  +/*
  + * NEC panel support
  + *
  + * Copyright (C) 2008 Nokia Corporation
  + * Author: Tomi Valkeinen tomi.valkei...@nokia.com
  + *
  + * This program is free software; you can redistribute it
  and/or modify it
  + * under the terms of the GNU General Public License version
  2 as published by
  + * the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be
  useful, but WITHOUT
  + * ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or
  + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
  Public License for
  + * more details.
  + *
  + * You should have received a copy of the GNU General Public
  License along with
  + * this program.  If not, see http://www.gnu.org/licenses/.
  + */
  +
  +#include linux/module.h
  +#include linux/delay.h
  +#include linux/platform_device.h
  +#include linux/i2c/twl4030.h
  +#include linux/spi/spi.h
  +
  +#include mach/gpio.h
 
 This will break the build since header files are moved to plat-omap.
 
Comments taken. I will release v2 soon with all comments incorporated
  +#include mach/gpio.h
 
 Remove this.
 
  +#include plat/mux.h
  +#include asm/mach-types.h
  +#include plat/control.h
  +
 
 Remove extra line.
 
Comments taken
  +#include plat/display.h
  +
  +#define LCD_XRES   800
  +#define LCD_YRES   480
  +
 
 Remove extra line.
 
  +#define LCD_PIXCLOCK_MIN   21800 /* NEC MIN PIX
  Clock is 21.8MHz */
  +#define LCD_PIXCLOCK_TYP   23800 /* Typical PIX
  clock is 23.8MHz */
  +#define LCD_PIXCLOCK_MAX   25700 /* Maximum is 25.7MHz */
  +
 
 -Ditto-
 
  +/* Current Pixel clock */
  +#define LCD_PIXEL_CLOCKLCD_PIXCLOCK_MIN
  +
  +
 
 -Ditto-
 
  +/*NEC NL8048HL11-01B  Manual
  + * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
  + */
  +
  +static struct omap_video_timings nec_panel_timings = {
  +   /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
  +   .x_res  = LCD_XRES,
  +   .y_res  = LCD_YRES,
  +   .pixel_clock= LCD_PIXEL_CLOCK,
  +   .hfp= 6,
  +   .hsw= 1,
  +   .hbp= 4,
  +   .vfp= 3,
  +   .vsw= 1,
  +   .vbp= 4,
  +};
  +
  +static int nec_panel_probe(struct omap_dss_device *dssdev)
  +{
  +   dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
  +OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
  +OMAP_DSS_LCD_ONOFF;
 
 Checkpatch error - ERROR: code indent should use tabs where possible
 
  +   dssdev-panel.timings = nec_panel_timings;
  +   dssdev-panel.recommended_bpp = 16;
  +
  +   return 0;
  +}
 
 This function will always return zero. Either check for sanity of function
 Parameters or change return value of the API to void.
 
  +
  +static void nec_panel_remove(struct omap_dss_device *dssdev)
  +{
  +}
  +
  +static int nec_panel_enable(struct omap_dss_device *dssdev)
  +{
  +   int r = 0;
  +
  +   mdelay(4);
 
 Add comment to justify the delay values used.
 
  +   if (dssdev-platform_enable)
  +   r = dssdev-platform_enable(dssdev);
  +
  +   return r;
 
 dssdev parameter is never used inside platform_enable.
 
 I guess platform_enable will always return zero. Please take care
 of error checking conditions.
 
  +}
  +
  +static void nec_panel_disable(struct omap_dss_device *dssdev)
  +{
  +   if (dssdev-platform_disable)
  +   dssdev-platform_disable(dssdev);
 dssdev parameter is never used inside platform_disable
 
  +   mdelay(4);
 Add comment to justify the delay values used.
 
  +}
  +
  +static int nec_panel_suspend(struct omap_dss_device *dssdev)
  +{
  +

[PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules

2009-11-26 Thread Peter Ujfalusi

Wake-up from McBSP ports are needed, especially when the THRESHOLD
dma mode is in use for audio playback.

Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 81ed252..6b17647 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -878,12 +878,16 @@ static void __init prcm_setup_regs(void)
/* Enable wakeups in PER */
prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 |
  OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
  OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 |
  OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
 
/* Don't attach IVA interrupts */
-- 
1.6.5.3

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

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

2009-11-26 Thread Janusz Krzysztofik

Thursday 26 November 2009 09:00:00 Jarkko Nikula napisał(a):
 Hi

 On Tue, 24 Nov 2009 12:31:16 +0100

 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
  -#define OMAP_MCBSP_READ(base, reg) \
  -   omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
  -#define OMAP_MCBSP_WRITE(base, reg, val) \
  -   omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
  +#define OMAP_MCBSP_READ(mcbsp, reg) \
  +   omap_mcbsp_read(mcbsp-io_base, OMAP_MCBSP_REG_##reg)
  +#define OMAP_MCBSP_WRITE(mcbsp, reg, val) \
  +   omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, val)
  +
  +#define OMAP_MCBSP_CREAD(mcbsp, reg) \
  +   (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1])
  +#define OMAP_MCBSP_CWRITE(mcbsp, reg, val) \
  +   omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, \
  +   mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
  +   = val)
  +

 Have rather single write writing both the cache and actual register.
 I.e. keep the OMAP_MCBSP_WRITE since writes should always go to hw and
 makes the patch smaller.

Jarkko,
Not that I am against making things simpler, but please reconsider:

1. Is there any point for caching data written to DXR registers?

2. There is at least one register, WAKEUPEN, never updated bit by bit, but 
always rewritten from scratch with a few different values that can be 
computed easily from other msbsp structure member values. For these rare 
cases, is it any worth to bypass the cache while writing them, saving a few 
instructions maybe?

3. Sometimes a register is written several times in succession with different 
values, like SYSCON inside omap34xx_mcbsp_free(), for example. Could all 
writes but the last one bypass the cache for the same reason?

Another axample is omap_mcbsp_start() fiddling with SPCR2 several times. 
However, there is a udelay(500) inbetween that I am not sure if can ever 
happen to be interleaved with a concurrent suspend or idle or something like 
that requiring the cache being up-to-date.

That said, please confirm if a single write macro with caching still seems 
sufficient, or a separate one without caching would provide enough benefits 
to keep it as well.

 I also found the OMAP_MCBSP_CREAD a little 
 unclear so I suggest to name is as OMAP_MCBSP_READ_CACHE.

I just tried to minimize line wrapping :/. If we agree on a single caching 
version of OMAP_MCBSP_WRITE(), what about OMAP_CACHE_READ()? If no better 
ideas, I'll use what you suggest.

  +#define OMAP_MCBSP_BREAD(mcbsp, reg) \
  +   (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
  +   = OMAP_MCBSP_READ(mcbsp-io_base, reg))

 Why is this? There is nothing eating this :-)

It's a part of a possible solution I am considering for SYSCON register 
handling. See below.

  dev_dbg(mcbsp-dev, DRR2:  0x%04x\n,
  -   OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
  +   OMAP_MCBSP_READ(mcbsp, DRR2));

 These changes are worth to send as a separate cleanup patch. Will make
 the actual cache patch smaller and easier to follow.

OK, but let me recap that first. We have two options:

1. All macros accept very same arguments, as long as applicable.
   This is what I have put in my patch.

2. Every macro is optimized in respect of its argumnets, ie.
OMAP_MCBSP_READ(io_base, ...)
OMAP_MCBSP_READ_CACHE(reg_cache, ...)
OMAP_MCBSP_WRITE(mcbsp, ...)

Which one do you think is better?

  @@ -93,15 +104,15 @@ static irqreturn_t omap_mcbsp_tx_irq_han
  struct omap_mcbsp *mcbsp_tx = dev_id;
  u16 irqst_spcr2;
 
  -   irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2);
  +   irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx, SPCR2);
  dev_dbg(mcbsp_tx-dev, TX IRQ callback : 0x%x\n, irqst_spcr2);
 
  if (irqst_spcr2  XSYNC_ERR) {
  dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
  irqst_spcr2);
  /* Writing zero to XSYNC_ERR clears the IRQ */
  -   OMAP_MCBSP_WRITE(mcbsp_tx-io_base, SPCR2,
  -   irqst_spcr2  ~(XSYNC_ERR));
  +   OMAP_MCBSP_CWRITE(mcbsp_tx, SPCR2,
  +   OMAP_MCBSP_CREAD(mcbsp_tx, SPCR2)  ~(XSYNC_ERR));

 I was thinking that should these read+read_cache changes be a separate
 patch for fixing the 1510 issues since no other OMAPs are known to
 corrupt registers and plain hw read is enough for them.

I see. Do you want the change limited to cpu_is_omap1510() case only?

  @@ -612,7 +612,6 @@ EXPORT_SYMBOL(omap_mcbsp_stop);
   int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
   {
  struct omap_mcbsp *mcbsp;
  -   void __iomem *base;
 
  if (!omap_mcbsp_check_valid_id(id)) {
  printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
  @@ -620,28 +619,27 @@ int omap_mcbsp_pollwrite(unsigned int id
  }
 
  mcbsp = id_to_mcbsp_ptr(id);
  -   base = mcbsp-io_base;
 
  -   writew(buf, base +

Re: [PATCH 0/9] dspbridge cleanup patches

2009-11-26 Thread Felipe Contreras

On Tue, Nov 24, 2009 at 2:50 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
 Following patches are cleanups, removing history of files,
 tab spacing and also remove DPC layer.

Any plans for the first release?

MODULE_VERSION(0.1);

-- 
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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

2009-11-26 Thread Tomi Valkeinen

Hi,

On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote:
 Hi,
 
 I'm trying to get Xorg running on an Angstrom distro image on the OMAP3
 EVM, with a rotated framebuffer.  The default screen orientation on the
 EVM is portrait, and I'm trying to change this to landscape.  Without
 any tweaking, using a kernel with your latest v5 DSS patches added on
 top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom
 happily displays both its initial bootup screen, and then the X server
 starts successfully.
 
 Using the omapfb.rotate=1 kernel command-line option, the initial bootup
 screen still works, but as soon as the X server tries to start up, I get
 the following error on the console:
 
 Starting GPE display manager: gpe-dm
 omapdss MANAGER error: dispc_setup_plane failed for ovl 0
 omapdss MANAGER error: configure_overlay 0 failed

It sounds to me that gpe-dm (or something running after that) is trying
to configure the overlay to 480x640 mode, and failing. If the initial
bootup screen (I believe this is drawn from the linux side, not boot
loader?) is fine, it hints that the problem is in the X server or some
other user space component.

 My kernel bootargs are:
 mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2
 rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y
 omapfb.debug=y omapdss.debug=y
 
 Without vrfb=y, the initial boot screen won't show up, with a console
 message of 'omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX', and
 the same error for Xorg.

In practice you always have to use VRFB rotation on OMAP3, so no point
in trying without.

 I'd appreciate any advice you could give me - doing this (in theory
 simple) screen orientation change is really stumping me.

It sounds to me that the DSS and omapfb is working fine. I also tried
booting SDP board with similar boot arguments, and it's working fine
(although I'm not running X).

Perhaps there's some application that checks the display dimensions,
which are 480x640, and tries to use those regardless of the rotation.

 Tomi


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

Re: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

2009-11-26 Thread Janusz Krzysztofik

Thursday 26 November 2009 03:08:30 Paul Walmsley napisał(a):
 On Wed, 25 Nov 2009, Janusz Krzysztofik wrote:
  It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c
  exports several functions that are called unconditionaly from
  drivers/video/omap/lcdc.c AND the latter is linked into the omapfb
  driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be
  limited to selected OMAP1 subarchs unless at least
  drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c
  itself either, are modified for that as well. Am I missing something?
 
  If not, I can see two options:
  1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch
  unless CONFIG_FB_OMAP is not set. That can be cleaned up further after
  the drivers/video/omap/* stuff is ever modified.
  2. Include drivers/video/omap/* modifications into this series.
 
  What do you suggest?

 Let's take option 1 for right now.  Maybe one of the htcwizard people
 might take that project up after the LCD DMA split is merged.

Paul,

I probably missed a third option: conditionally replacing declarations of 
those functions required by lcdc.c with coresponding fake static inline 
definitions inside an #ifdef block in lcd_dma.h. What do you think?

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

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Aggarwal, Anuj

 -Original Message-
 From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
 Sent: Thursday, November 26, 2009 3:53 PM
 To: Aggarwal, Anuj
 Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
 Arun KS
 Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
 hang

 On Thu, Nov 26, 2009 at 08:31:11AM +0530, Aggarwal, Anuj wrote:

  I have already tried that but it doesn't fix the problem entirely.
  Still, I was not able to playback properly because the bias settings
  were not handled correctly and as you can see, it writes to some
  invalid registers too (all registers don't exist between 0 and
 ARRAY_SIZE).

 Please also note the following patch which is queued for 2.6.32:

 commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829
 Author: Mark Brown broo...@opensource.wolfsonmicro.com
 Date:   Mon Nov 23 13:11:53 2009 +

 ASoC: Fix suspend with active audio streams

[Aggarwal, Anuj] I am also seeing one more problem with the original 
driver, although I am not sure if the problem is in the audio driver. 
When tried to capture, using NFS as storage, it gives overrun error and comes 
out with:
arecord: pcm_read:1617: read error: Input/output error

It happen always after ~20 sec, file size ~5MB. Tried with multiple
configurations in arecord but no use.
When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't 
come too when I try to store the captured audio file on a MMC card.

Any idea what could be the problem? Why arecord goes for a toss after a 
single overrun error and why it is happening always after ~20 sec? Is
there something which can be tried to narrow down the problem?

--
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: Enabling HSUSB1 port on OMAP3430 labrador

2009-11-26 Thread Kovacs Peter Tamas


Dear Anand, All,

We are trying to make the HSUSB1 port on the OMAP3430 work as an USB 
host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected 
to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).


I have all these USB related kernel config options enabled:
USB_EHCI_HCD
USB_OHCI_HCD
USB_MUSB_HDRC
TWL4030_USB

My guess was that either EHCI or the Inventra should be the one 
enabling that USB port on the OMAP, but no luck.

The external USB port on the MDK works fine with this configuration.

The pin multiplexing configuration in the board file 
omap3430-labrador.c in u-boot also seems to be correct (although the 
config of USB1_STP seems to be strange, but changing that didn't 
work either).  

Not sure why the pad conf is done in u-boot for this board, but maybe
it was a copy-paste thing. That being said, if you've got the part
installed correctly, it ought to work.
  
Yes, I can also see these pin multiplexing configs in 
arch/arm/mach-omap2/usb-ehci.c.
I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are 
PHY (couldn't find it in menuconfig, but this macro seems to be used 
in this single file).
Still, the clock goes high when powering the board on, and it remains 
there forever.


I recall seeing a TI-specific kernel source in another git repository, 
which had menuconfig options for setting PHY/TLL, maybe the USB code 
is different too?
After having no clock signal on the HSUSB1_CLK with the kernel pulled 
from from git.kernel.org/linux/kernel/linux-omap-2.6.git, I've tried 
some older ti-2.6.xx kernel branches from 
git.omapzoom.org/repo/omapkernel.git


branch ti-2.6.27-omap3 didn't compile.
branch ti-2.6.26-omap3 kind of works, but the HSUSB1_CLK is still dead.
branch ti-2.6.24-omap3 works, and during booting I can see a clock 
signal on HSUSB1_CLK, and also the STP signal seems to go high and back 
low as expected!


Is it possible that this feature is broken some months ago? I'll go and 
compare the relevant files, but your suggestions on how to make this 
work again in newer kernels are welcome.


Thanks,
Peter

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

RE: [PATCH 0/4] AM3517: MMC: Add support for HSMMC

2009-11-26 Thread Aggarwal, Anuj

 -Original Message-
 From: Aggarwal, Anuj
 Sent: Monday, November 23, 2009 11:55 PM
 To: linux-omap@vger.kernel.org
 Cc: Aggarwal, Anuj
 Subject: [PATCH 0/4] AM3517: MMC: Add support for HSMMC
 
 This patch series adds support for HSMMC for AM3517 platform.
 It also enables the HSMMC driver in the AM3517 defconfig.
 
 Anuj Aggarwal (4):
   AM3517: MMC: Add low-level init code for HSMMC controller
   AM3517: MMC: Modifying board-evm file to add mmc_init
   AM3517: MMC: Modifying Makefile to enable MMC init
   AM3517: MMC: Make HSMMC driver built-in
 
  arch/arm/configs/am3517_evm_defconfig |   21 +++-
  arch/arm/mach-omap2/Makefile  |3 +-
  arch/arm/mach-omap2/board-am3517evm.c |   22 +++
  arch/arm/mach-omap2/mmc-am3517evm.c   |  267
 +
  arch/arm/mach-omap2/mmc-am3517evm.h   |   22 +++
  5 files changed, 333 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.c
  create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.h

[Aggarwal, Anuj] Any comments on the patch series?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Mark Brown

On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:

 driver, although I am not sure if the problem is in the audio driver. 
 When tried to capture, using NFS as storage, it gives overrun error and comes 
 out with:
 arecord: pcm_read:1617: read error: Input/output error

 It happen always after ~20 sec, file size ~5MB. Tried with multiple
 configurations in arecord but no use.
 When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't 
 come too when I try to store the captured audio file on a MMC card.

 Any idea what could be the problem? Why arecord goes for a toss after a 
 single overrun error and why it is happening always after ~20 sec? Is
 there something which can be tried to narrow down the problem?

Sounds like you've narrowed the problem down to a performance issue with
NFS writeout - it's probably having trouble keeping up with your I/O
rate.  This isn't 100% surprising with smaller systems, sometimes tuning
the NFS configuration can resolve the issue but sometimes the hardware
is just underspecified.

arecord is a pretty basic program and doesn't try terribly hard to
recover from errors.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Aggarwal, Anuj

 -Original Message-
 From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
 Sent: Thursday, November 26, 2009 8:41 PM
 To: Aggarwal, Anuj
 Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
 Arun KS
 Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
 hang

 On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:

  driver, although I am not sure if the problem is in the audio driver.
  When tried to capture, using NFS as storage, it gives overrun error and
 comes out with:
  arecord: pcm_read:1617: read error: Input/output error

  It happen always after ~20 sec, file size ~5MB. Tried with multiple
  configurations in arecord but no use.
  When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
  come too when I try to store the captured audio file on a MMC card.

  Any idea what could be the problem? Why arecord goes for a toss after a
  single overrun error and why it is happening always after ~20 sec? Is
  there something which can be tried to narrow down the problem?

 Sounds like you've narrowed the problem down to a performance issue with
 NFS writeout - it's probably having trouble keeping up with your I/O
 rate.  This isn't 100% surprising with smaller systems, sometimes tuning
 the NFS configuration can resolve the issue but sometimes the hardware
 is just underspecified.
[Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
command is used for read/write to further check NFS performance, 2Mbps for 
write and 4Mbps for read is observed.
Does that still mean nfs is the culprit? What could be tweaked in audio/network 
driver to avoid this problem, any suggestions?

 arecord is a pretty basic program and doesn't try terribly hard to
 recover from errors.
[Aggarwal, Anuj] Any other utility to try capture which does error 
recovering too?
--
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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

2009-11-26 Thread Koen Kooi


Op 26 nov 2009, om 15:20 heeft Tomi Valkeinen het volgende geschreven:

 My kernel bootargs are:
 mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2
 rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y
 omapfb.debug=y omapdss.debug=y

Try allocating some more VRAM for fb0 and fb1 and change 'rootdelay=1' to 
'rootwait' and remove 'nohz=off'

regards,

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

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Aggarwal, Anuj

The performance numbers are in Mbytes/sec. Sorry for the typo :(

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj
 Sent: Thursday, November 26, 2009 8:52 PM
 To: Mark Brown
 Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
 Arun KS
 Subject: RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
 hang

  -Original Message-
  From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
  Sent: Thursday, November 26, 2009 8:41 PM
  To: Aggarwal, Anuj
  Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-
 o...@vger.kernel.org;
  Arun KS
  Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
  hang

  On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:

   driver, although I am not sure if the problem is in the audio driver.
   When tried to capture, using NFS as storage, it gives overrun error
 and
  comes out with:
   arecord: pcm_read:1617: read error: Input/output error

   It happen always after ~20 sec, file size ~5MB. Tried with multiple
   configurations in arecord but no use.
   When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
   come too when I try to store the captured audio file on a MMC card.

   Any idea what could be the problem? Why arecord goes for a toss after
 a
   single overrun error and why it is happening always after ~20 sec? Is
   there something which can be tried to narrow down the problem?

  Sounds like you've narrowed the problem down to a performance issue with
  NFS writeout - it's probably having trouble keeping up with your I/O
  rate.  This isn't 100% surprising with smaller systems, sometimes tuning
  the NFS configuration can resolve the issue but sometimes the hardware
  is just underspecified.
 [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout
 issue
 as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
 command is used for read/write to further check NFS performance, 2Mbps for
 write and 4Mbps for read is observed.
 Does that still mean nfs is the culprit? What could be tweaked in
 audio/network driver to avoid this problem, any suggestions?

  arecord is a pretty basic program and doesn't try terribly hard to
  recover from errors.
 [Aggarwal, Anuj] Any other utility to try capture which does error
 recovering too?
 --
 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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Mark Brown

On Thu, Nov 26, 2009 at 08:52:08PM +0530, Aggarwal, Anuj wrote:

 [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
 as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
 command is used for read/write to further check NFS performance, 2Mbps for 
 write and 4Mbps for read is observed.
 Does that still mean nfs is the culprit? What could be tweaked in 
 audio/network driver to avoid this problem, any suggestions?

There can also be issues with the way the data gets pushed into NFS
interacting poorly - it's not just the raw data rate that's in play
here, it's also things like how often the writes are done and how big
they are.  Possibly also overhead from interacting with the ethernet
chip but that's not normally an issue for anything modern.

The fact that this only happens when NFS is in use seems a fairly clear
pointer to an interacton there.

 [Aggarwal, Anuj] Any other utility to try capture which does error
 recovering too?

Not for the console off the top of my head, and TBH I don't really know
how good the error handling is in the various apps.  You could also try
playing with the buffer size options in arecord.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

2009-11-26 Thread Philby John

On Thu, 2009-11-26 at 20:52 +0530, Aggarwal, Anuj wrote:
  -Original Message-
  From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
  Sent: Thursday, November 26, 2009 8:41 PM
  To: Aggarwal, Anuj
  Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
  Arun KS
  Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
  hang

  On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:

   driver, although I am not sure if the problem is in the audio driver.
   When tried to capture, using NFS as storage, it gives overrun error and
  comes out with:
   arecord: pcm_read:1617: read error: Input/output error

   It happen always after ~20 sec, file size ~5MB. Tried with multiple
   configurations in arecord but no use.
   When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
   come too when I try to store the captured audio file on a MMC card.

   Any idea what could be the problem? Why arecord goes for a toss after a
   single overrun error and why it is happening always after ~20 sec? Is
   there something which can be tried to narrow down the problem?

  Sounds like you've narrowed the problem down to a performance issue with
  NFS writeout - it's probably having trouble keeping up with your I/O
  rate.  This isn't 100% surprising with smaller systems, sometimes tuning
  the NFS configuration can resolve the issue but sometimes the hardware
  is just underspecified.
 [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
 as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
 command is used for read/write to further check NFS performance, 2Mbps for 
 write and 4Mbps for read is observed.
 Does that still mean nfs is the culprit? What could be tweaked in 
 audio/network driver to avoid this problem, any suggestions?

My two cents... could also try connecting the target directly to your
host machine (using nfs), through a cross-cable (one with the Tx and Rx
crossed). If no errors are seen, then it surely must be an attribution
of network congestion.

Regards,
Philby

--
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: Enabling HSUSB1 port on OMAP3430 labrador

2009-11-26 Thread Gadiyar, Anand

Kovacs Peter Tamas wrote:
 
 Dear Anand,
 
 thank you very much for your exhaustive answer and help. Unfortunately 
 it seems there is no clock signal coming out of the HSUSB1_CLK line.
 
  We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
  To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
  the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
 
  I have all these USB related kernel config options enabled:
  USB_EHCI_HCD
  USB_OHCI_HCD
  USB_MUSB_HDRC
  TWL4030_USB
 
  My guess was that either EHCI or the Inventra should be the one enabling 
  that USB port on the OMAP, but no luck.
  The external USB port on the MDK works fine with this configuration.
 
  The pin multiplexing configuration in the board file omap3430-labrador.c 
  in u-boot also seems to be correct (although the config of USB1_STP 
  seems to be strange, but changing that didn't work either).
  
 
  HSUSB1 is not supposed to be used with the labrador (do you have a link
  to the board schematics with the mods?). HSUSB1 is the EHCI port.

 What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
 then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
 wired out on the Logic MDK baseboard so we cannot use that. Thus only 
 one possibility remains if we need an extra USB port inside the casing, 
 which is HSUSB1.


I meant there was nothing connected to it on the default board.
The pads are possibly brought out to the expansion connector, but
I haven't checked the schematic - so I'm not sure. I don't think
anyone's tried hooking up a transceiver to that port.


  Not sure why the pad conf is done in u-boot for this board, but maybe
  it was a copy-paste thing. That being said, if you've got the part
  installed correctly, it ought to work.

 Yes, I can also see these pin multiplexing configs in 
 arch/arm/mach-omap2/usb-ehci.c.
 I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
 (couldn't find it in menuconfig, but this macro seems to be used in this 
 single file).
 Still, the clock goes high when powering the board on, and it remains 
 there forever.
 
 I recall seeing a TI-specific kernel source in another git repository, 
 which had menuconfig options for setting PHY/TLL, maybe the USB code is 
 different too?
 
  Note, the ISP1507A is connected to the following pins of the BGA:
  HSUSB1_STP (AF10)
  HSUSB1_CLK (AE10)
  HSUSB1_DIR (AF9)
  HSUSB1_NXP (AG9)
  HSUSB1_D0 (AF11)
  HSUSB1_D1 (AG12)
  HSUSB1_D2 (AH12)
  HSUSB1_D3 (AH14)
  HSUSB1_D4 (AE11)
  HSUSB1_D5 (AH9)
  HSUSB1_D6 (AF13)
  HSUSB1_D7 (AE13)
  
 
  These are the pads for EHCI. So I suppose that's what you're trying to use.

 We suspect there might be a confusion here.
 According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
 also ETK_CLK, MMC3_CMD, GPIO_13).
 According to the OMAP3430 Multimedia Processor Data Manual version N 
 (OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 

Not sure about this - if it says ES1.0, that's a really old silicon
version. The HSUSB block was not present in that chip and there are
very very few of these chips floating around.

ES2.0 and greater all have this block and all boards in the wild (including
the labrador) should have an ES2 or greater chip.

 GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
 Then, in mach_omap2/usb-ehci.c, I can see  
 omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
 configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
 or GPIO_151, but not USB at all.

No, this is incorrect. Go with the setting in mach-omap2/mux.c.
All packages have the same pads for HSUSB1 lines, so there should be
no issue with this.

 
 So far we have used the pins as seen in the Logic schematic for creating 
 an extension board with a number of SPI and GPIO signals, and everything 
 worked perfectly. Why are the pins described differently?
 
  Note that EHCI on the OMAP3 supports only the input clocking mode. This
  might mean you need to check if you've configured the PHY correctly for
  this mode. (No XTAL required, OMAP provides the clock to the PHY).
  NXP seems to have removed all mention of this mode from their
  data sheets, so you might want to check with them.

 Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
 so it seems not to be compatible with the OMAP3430.
 The clock pin of the ISP1504 can be configured for I/O, however this 
 component is quite difficult to get, but it seems it's necessary.

You might want to take a look at the NXP ISP1703. I believe it's
available now and does officially support the input-clocking mode.
(Disclaimer: I haven't personally used with my OMAP3 SDP , but I was
informed that it works)

Beagleboard and others use the SMSC 332x, but we have issues with
suspend-resume with this PHY. If you're designing fresh, you might
want to try the NXP PHY.


  Also,

omap3evm: touchscreen delays on pm branch

2009-11-26 Thread Premi, Sanjeev

Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 cat /proc/interrupts
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with cat /dev/zero  /dev/null 
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?

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

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

2009-11-26 Thread Tony Lindgren

* Mike Rapoport m...@compulab.co.il [091126 03:19]:
 Tony,
 
 Tony Lindgren wrote:
  * Tony Lindgren t...@atomide.com [091125 16:17]:
  Hi all,
 
  Here are some omap mux updates for review. These
  are intended for the v2.6.33 merge window.
  
  Forgot to edit the subject :)
  
  Also, these patches are available in the mux branch
  of the linux-omap tree for easy testing.
 
 After all the discussions we had, what would be preferable way to define the
 board mux configuration? The omap_board_mux array or a calls for
 omap_mux_init_signal?

You should be able to just boot with CONFIG_DEBUG_FS,
check how the pins are set, and adjust as needed via sysfs.
Then when happy with the settings, just do:

# cat /sys/kernel/debug/omap_mux/board
OMAP3_MUX(CAM_D0, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D10, OMAP_PIN_OUTPUT | OMAP_MUX_MODE7), 
OMAP3_MUX(CAM_D11, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D1, OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE | 
OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D2, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4), 
OMAP3_MUX(CAM_D3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE7),
OMAP3_MUX(CAM_D5, OMAP_PIN_OUTPUT | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D6, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D7, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D8, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D9, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
...

And then use the output for the struct omap_board_mux board_mux[]
in your board-*.c files.

For the common device init functions and omap_hwmod, we probably
want to use the signal names. That allows more generic initialization
of the internal devices, but some pins for sure still need to
be muxed in a board specific way.

Regards,

Tony

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

RE: [PATCH] DSPBRIDGE: Interface tightening to check for invalid

2009-11-26 Thread Ramos Falcon, Ernesto

Hi,

-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Tuesday, November 24, 2009 2:51 AM
To: Ramos Falcon, Ernesto
Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; imre.d...@nokia.com;
Shah, Bhavin
Subject: Re: [PATCH] DSPBRIDGE: Interface tightening to check for invalid

Hi Ernesto,

From: ext Ramos Falcon, Ernesto erne...@ti.com
Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
Date: Mon, 23 Nov 2009 21:12:08 +0100

 From f28ec22e48a9b61ac00b7711e035e117bdc71aeb Mon Sep 17 00:00:00 2001
 From: Ernesto Ramos erne...@ti.com
 Date: Mon, 23 Nov 2009 12:16:45 -0600
 Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
inputs.

 Move the error checking to kernel to address usecases
 accessing kernel API directly.

memory_check_vma() wasn't implemented for normal ioctl parameter
checking, but one for bridge cache operations with kernel crash risk,
especially with the following patch:

  http://marc.info/?l=linux-omapm=125810716419520w=2

This is because these memory area is expected that:

  - its pages have been already populated.
  - its pages shouldn't be swapped out.

Otherwise there's risk of kernel crash at these cache operation,
although find_vma() and follow_page() may be a bit heavier
operation.

The intention with this patch is to further strengthen the dsp bridge driver.
I already executed some test cases to measure performance and the impact seems 
to be ~ 0.3% for a big amount of memory maps and flush memory commands, the 
latency impact is not even noticeable.

For most of the normal cases, which just checks ioctl parameters,
normal access_ok() would be enough. If it tries to access kernel
address, just it returns error to userland. If it tries to access
invalid address in user address space, the process dies with
SIGSEGV. I think that normally it's ok that a process dies because of
invalid address access rather than performance degrade.

I intended to use access_ok() for the purpose to check ioctl parameters, 
however, access_ok() seems not to work, I was able to send any invalid address 
to the bridge driver and no errors where reported. It seems that access_ok is 
rejecting only addresses that belong to the kernel space but the user would be 
able to send invalid address anyway.

So I think that memory_check_vma() doesn't fit for normal ioctl
parameter checking(copy_from_user/copy_to_user), but access_ok()
would work in most of normal cases.

In macros, __cp_fm_usr()/__cp_to_usr(), adding access_ok() checking
for pointers may work fine, I guess.

access_ok() is already called within copy_to_user() but the verification is 
being done after most of the processing is done, the intentions is to add these 
checks before any processing happens, and as I mentioned before access_ok does 
not work for all cases.

 Signed-off-by: Ernesto Ramos erne...@ti.com
 ---
  arch/arm/plat-omap/include/dspbridge/dbdefs.h |3 +-
  drivers/dsp/bridge/pmgr/wcd.c |  263
+++--
  drivers/dsp/bridge/rmgr/proc.c|   42 
  3 files changed, 249 insertions(+), 59 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

Re: omap3evm: touchscreen delays on pm branch

2009-11-26 Thread Hemanth V

- Original Message - 
From: Premi, Sanjeev pr...@ti.com

To: linux-omap@vger.kernel.org
Sent: Thursday, November 26, 2009 10:32 PM
Subject: omap3evm: touchscreen delays on pm branch

Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 cat /proc/interrupts
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with cat /dev/zero  /dev/null 
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?

I dont see this problem on Zoom2/Zoom3, I am able to see interrupts being
incremented for every touch.

Best regards,
Sanjeev
--
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: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

2009-11-26 Thread Paul Walmsley

On Thu, 26 Nov 2009, Janusz Krzysztofik wrote:

 Thursday 26 November 2009 03:08:30 Paul Walmsley napisał(a):
  On Wed, 25 Nov 2009, Janusz Krzysztofik wrote:
   It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c
   exports several functions that are called unconditionaly from
   drivers/video/omap/lcdc.c AND the latter is linked into the omapfb
   driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be
   limited to selected OMAP1 subarchs unless at least
   drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c
   itself either, are modified for that as well. Am I missing something?
  
   If not, I can see two options:
   1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch
   unless CONFIG_FB_OMAP is not set. That can be cleaned up further after
   the drivers/video/omap/* stuff is ever modified.
   2. Include drivers/video/omap/* modifications into this series.
  
   What do you suggest?
 
  Let's take option 1 for right now.  Maybe one of the htcwizard people
  might take that project up after the LCD DMA split is merged.
 
 I probably missed a third option: conditionally replacing declarations of 
 those functions required by lcdc.c with coresponding fake static inline 
 definitions inside an #ifdef block in lcd_dma.h. What do you think?

Just took a quick look at that lcdc.c file; I think we'd better leave 
those functions in, since they are so tightly integrated to the code. 
Hopefully one of the OMAP730/750/850 people can tease them out, since 
they've got a platform to test on.  Sound reasonable?  Less work for us, 
anyway :-)

- Paul

Re: [PATCH-v6 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards

2009-11-26 Thread Artem Bityutskiy

On Tue, 2009-11-24 at 20:55 +0530, Vimal Singh wrote:
 On Tue, Nov 24, 2009 at 8:36 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
  On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote:
  Here is the v6 of this patch series. I am cc'ing mtd list too this time.

  From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
  From: Vimal Singh vimalsi...@ti.com
  Date: Thu, 19 Nov 2009 19:28:11 +0530

  This patch series adds flash support for NAND (in sdp, zoom and ldp),
  OneNAND and NOR (in sdp)

  Tested on Zoom2 and 3430SDP

  Vimal Singh (4):
  [PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards
  [PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards
  [PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig
  [PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig

  Is it possible to separate the MTD and OMAP parts?

 1st patch does migration of gpmc low level calls from omap2.c to gpmc-nand.c.
 I am not sure how we can have separate patches for this.

Ok. It looks like you intend to merge this stuff via linux-omap, which
seems right.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

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

RE: [PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c

Re: [PATCH 0/8] Series short description

Re: [PATCH 1/2 v2] musb: Add context save and restore support

RE: [PATCH 1/2 v2] musb: Add context save and restore support

Re: DSS2 panel question

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

RE: [PATCH 1/2 v2] musb: Add context save and restore support

Re: Enabling HSUSB1 port on OMAP3430 labrador

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

RE: [PATCH 1/5] OMAP3: Fixed ARM aux ctrl register save/restore

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display

[PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules

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

Re: [PATCH 0/9] dspbridge cleanup patches

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

Re: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

Re: Enabling HSUSB1 port on OMAP3430 labrador

RE: [PATCH 0/4] AM3517: MMC: Add support for HSMMC

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

RE: Enabling HSUSB1 port on OMAP3430 labrador

omap3evm: touchscreen delays on pm branch

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

RE: [PATCH] DSPBRIDGE: Interface tightening to check for invalid

Re: omap3evm: touchscreen delays on pm branch

Re: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

Re: [PATCH-v6 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards

33 matches

Site Navigation

Mail list logo

Footer information