date:20101004

On Monday 04 October 2010 10:36:16 ext G, Manjunath Kondaiah wrote:
  are going to have:
  DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to
 
 For OMAP2, you should use DMA_ERRATA_IFRAME_BUFFERING since it is
 different type of issue.

Thanks!
I'll do that.

 
 -Manjunath

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

RE: NOTE: hwmod changes merged to linux-omap master for testing

Hi Tony,
With latest merges on master branch with commit ID:
0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after 
merging in hwmod support for testing

Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. 

Looks like multiple warning dumps and finally it crashes after Freeing init 
memory with both NFS and ramdisk file systems.

The complete bootlogs are available at:
NFS bootlog:
http://pastebin.com/nrWQ5FGG

Ramdisk bootlog:
http://pastebin.com/1F75d2Ew

-Manjunath 

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Saturday, October 02, 2010 6:18 AM
 To: linux-omap@vger.kernel.org
 Subject: NOTE: hwmod changes merged to linux-omap master for testing
 
 Hi all,
 
 So I've finally merged Kevin's hwmod branch into the 
 linux-omap master so we can give it some testing to see if we 
 can merge it to the mainline. Might take few minutes to hit 
 the mirrors.
 
 Please note that for omap2plus machines you need to change:
 
 - u-boot bootargs for kernel cmdline needs to change with setenv
 - if you use hardcoded CONFIG_CMDLINE, change it in your .config
 - /etc/inittab in your omap root file system if using serial console
 
 This is because otherwise the serial-omap would be 
 conflicting with the 8250 driver. This should not affect 
 omap1 machines.
 
 Please give it a try and report any issues on this list! Now 
 all the machines except ams_delta_defconfig should build.
 That one is still missing some camera driver changes to build.
 
 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
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] OMAP3 PM: sleep code clean up

2010-10-04 Thread Amit Kucheria

On 10 Oct 04, Sripathy, Vishwanath wrote:
 Kevin,
 
[snip]

 
  But this also makes me wonder, if we're going to clean this up, the bulk
  of it could be re-written in C, with some inline asm helpers as needed.
 Probably yes. But as this code is specific to OMAP3, do you think it's
 worth spending time on rewriting the entire code in C? It might be a
 significant effort and it will not be reusable for other ARM SOCs.

The C code will be more maintainable and offer more opportunities to
refactor across OMAP flavours - perhaps OMAP4 as well.

I'm also interested in code reuse across other SoCs. We've got to be able to
shut down the ARM core using common code instead of each SoC copying buggy
code from each other. Could you list reasons why you don't think the code is
re-usable?

Regards,
Amit
--
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: Fix compilation warnings

2010-10-04 Thread Pramod


On Friday 01 October 2010 09:30 PM, Kevin Hilman wrote:

pramod.gu...@ti.com writes:


From: Pramod Guravpramod.gu...@ti.com


patch is missing
- more descriptive subject
- more descriptive changelog (preferably incluing compilation error)
- signoff (should've been noticed when running checkpatch)

And after the '---', which tree this applies to since it does not apply
to current l-o master.  In fact, it appears that all these issues have
already been fixed in l-o master.



I was working out of l-o pm branch. Sorry for the confusion!


Kevin


---
  arch/arm/mach-omap2/board-omap4panda.c |2 --
  arch/arm/mach-omap2/mux.c  |2 +-
  arch/arm/plat-omap/gpio.c  |4 ++--
  3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
  }
  static void __init omap4_panda_init(void)
  {
-   int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
  int __init omap_mux_init_gpio(int gpio, int val)
  {
struct omap_mux_entry *e;
-   struct omap_mux *gpio_mux;
+   struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f6c03a7..22f175f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2223,7 +2223,7 @@ void omap2_gpio_prepare_for_idle(int power_state)

for (i = min; i  gpio_bank_count; i++) {
struct gpio_bank *bank =gpio_bank[i];
-   u32 l1, l2;
+   u32 l1 = 0, l2 = 0;
int j;

for (j = 0; j  hweight_long(bank-dbck_enable_mask); j++)
@@ -2291,7 +2291,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i  gpio_bank_count; i++) {
struct gpio_bank *bank =gpio_bank[i];
-   u32 l, gen, gen0, gen1;
+   u32 l = 0, gen, gen0, gen1;
int j;

for (j = 0; j  hweight_long(bank-dbck_enable_mask); j++)


--
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: multiple linux-next OMAP3 build errors

2010-10-04 Thread Tomi Valkeinen

Hi,

On Fri, 2010-10-01 at 17:57 +0200, ext Grazvydas Ignotas wrote:
 hi,
 
 I've been building linux-next for a while now and keep getting these
 build errors, just posting them here in case not all are known. Not
 familiar enough with that code to send patches unfortunately.

   CC  drivers/video/omap2/vram.o
 drivers/video/omap2/vram.c: In function 'omap_vram_reserve_sdram_memblock':
 drivers/video/omap2/vram.c:568: error: implicit declaration of
 function 'memblock_region_is_memory'

Benjamin, your patch memblock/arm: Use memblock_region_is_memory() for
omap fb in linux-next seems to be broken. I believe the called function
should be memblock_is_region_memory, not memblock_region_is_memory?

 Tomi


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

Re: [PATCH] usb: musb: fix build break due to partial rename


On Fri, Oct 01, 2010 at 03:34:24PM -0500, Gadiyar, Anand wrote:

Patch usb gadget: don't save bind callback in struct usb_gadget_driver
in Greg's USB queue missed one conversion of
usb_gadget_register_driver to usb_gadget_probe_driver,
causing a build break when MUSB is built in gadget mode.

Fix this.

Reported-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Uwe Kleine-Koenigu.kleine-koe...@pengutronix.de
Cc: Michal Nazarewicz m.nazarew...@samsung.com
Cc: Felipe Balbi ba...@ti.com


wow, good catch :-)

Acked-by: Felipe Balbi ba...@ti.com


Cc: Greg Kroah-Hartman gre...@suse.de
---
Greg,

Since Uwe's original patch isn't yet in mainline, maybe you could
fold this patch into the original.


Fine by me to fold on original patch.

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

RE: [PATCH 08/10] OMAP: split plat-omap/common.c

2010-10-04 Thread DebBarma, Tarun Kanti


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
 Sent: Monday, October 04, 2010 2:39 PM
 To: Paul Walmsley
 Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c

 Hi Paul,

 On 10/1/2010 11:35 PM, Paul Walmsley wrote:
  Split plat-omap/common.c into three pieces:
 
  1. the 32KiHz sync timer and clocksource code, which now lives in
  plat-omap/32ksynctimer.c;
 
  2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;
 
  3. and the remainder of the OMAP-wide common code, which includes the
  deprecated ATAGs code and a deprecated video RAM reservation
 function.
 
  The primary motivation for doing this is to move the OMAP2+-specific
 parts
  into an OMAP2+-specific file, so that build breakage related to the
  System Control Module code can be resolved.
 
  Signed-off-by: Paul Walmsleyp...@pwsan.com
  ---

 ...

  diff --git a/arch/arm/plat-omap/32ksynctimer.c b/arch/arm/plat-
 omap/32ksynctimer.c
  new file mode 100644
  index 000..b7f458c
  --- /dev/null
  +++ b/arch/arm/plat-omap/32ksynctimer.c
  @@ -0,0 +1,184 @@
  +/*
  + * linux/arch/arm/plat-omap/clocksource.c

 What name do you want to use? 32ksynctimer.c or clocksource.c?

 If this file is dedicated for the 32k sync timer, maybe we should now
 use the new OMAP4 name: counter_32k.

 Noboby knows what the sync stand for, and at the end this is just a 32k
 counter. Hence the new name :-)
One of the points to be kept in mind while naming is that we are able to relate 
our driver easily to the hardware device. In this regard the TRM terms this 
module as 32-kHz Synchronized Timer. Therefore we should be careful in our 
naming. With regard to the meaning of the word here is the extract from the TRM.

OMAP4430 ES2.0 TRM
...
The sync logic ensures the read transaction correctness by synchronizing the 
counter register read access on 32KSYNCNT_ICLK because the 32KSYNCNT_ICLK clock 
signal is completely asynchronous with S32KSYNCNT_FCLK.
...


 Benoit

  + *
  + * OMAP clocksource-related code
  + *
  + * Copyright (C) 2009 Texas Instruments
  + * Copyright (C) 2010 Nokia Corporation
  + * Tony Lindgrent...@atomide.com
  + * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com
  + * Paul Walmsley
  + *
  + * 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.
  + */
  +#includelinux/kernel.h
  +#includelinux/init.h
  +#includelinux/clk.h
  +#includelinux/io.h
  +
  +#includeplat/common.h
  +#includeplat/board.h
  +
  +#includeplat/clock.h
  +
  +
  +/*
  + * 32KHz clocksource ... always available, on pretty most chips except
  + * OMAP 730 and 1510.  Other timers could be used as clocksources, with
  + * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
  + * but systems won't necessarily want to spend resources that way.
  + */
  +
  +#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
  +
  +#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
  +
  +#includelinux/clocksource.h
  +
  +/*
  + * offset_32k holds the init time counter value. It is then subtracted
  + * from every counter read to achieve a counter that counts time from
 the
  + * kernel boot (needed for sched_clock()).
  + */
  +static u32 offset_32k __read_mostly;
  +
  +#ifdef CONFIG_ARCH_OMAP16XX
  +static cycle_t omap16xx_32k_read(struct clocksource *cs)
  +{
  +   return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k;
  +}
  +#else
  +#define omap16xx_32k_read  NULL
  +#endif
  +
  +#ifdef CONFIG_ARCH_OMAP2420
  +static cycle_t omap2420_32k_read(struct clocksource *cs)
  +{
  +   return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k;
  +}
  +#else
  +#define omap2420_32k_read  NULL
  +#endif
  +
  +#ifdef CONFIG_ARCH_OMAP2430
  +static cycle_t omap2430_32k_read(struct clocksource *cs)
  +{
  +   return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k;
  +}
  +#else
  +#define omap2430_32k_read  NULL
  +#endif
  +
  +#ifdef CONFIG_ARCH_OMAP3
  +static cycle_t omap34xx_32k_read(struct clocksource *cs)
  +{
  +   return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k;
  +}
  +#else
  +#define omap34xx_32k_read  NULL
  +#endif
  +
  +#ifdef CONFIG_ARCH_OMAP4
  +static cycle_t omap44xx_32k_read(struct clocksource *cs)
  +{
  +   return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k;
  +}
  +#else
  +#define omap44xx_32k_read  NULL
  +#endif
  +
  +/*
  + * Kernel assumes that sched_clock can be called early but may not have
  + * things ready yet.
  + */
  +static cycle_t omap_32k_read_dummy(struct clocksource *cs)
  +{
  +   return 0;
  +}
  +
  +static struct clocksource clocksource_32k = {
  +   .name   =

[PATCH v4 3/4] OMAP2: DMA: Use errata flag for disabling buffering

Convert the errata handling of buffering disable on
OMAP2 platforms.

Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
 arch/arm/plat-omap/dma.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ae0ff64..c116c41 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -147,6 +147,7 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = 
{
 };
 
 /* Errata handling */
+#define DMA_ERRATA_IFRAME_BUFFERING(1  0)
 static u16 dma_errata;
 #define IS_DMA_ERRATA(id)  (dma_errata  (id))
 
@@ -1003,8 +1004,7 @@ void omap_start_dma(int lch)
 * Errata: On ES2.0 BUFFERING disable must be set.
 * This will always fail on ES1.0
 */
-   if (cpu_is_omap2420() ||
-   (cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
+   if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
l |= OMAP_DMA_CCR_EN;
@@ -2048,6 +2048,9 @@ void omap_dma_global_context_restore(void)
 
 static void dma_errata_configure(void)
 {
+   if (cpu_is_omap2420() ||
+   (cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
+   dma_errata |= DMA_ERRATA_IFRAME_BUFFERING;
 }
 
 static int __init omap_init_dma(void)
-- 
1.7.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: [PATCH 08/10] OMAP: split plat-omap/common.c

2010-10-04 Thread Varadarajan, Charulatha

Paul,

snip

 
   +static int __init omap_init_clocksource_32k(void)
   +{
   + static char err[] __initdata = KERN_ERR
   + %s: can't register clocksource!\n;
   +
   + if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
   + struct clk *sync_32k_ick;
   +
   + if (cpu_is_omap16xx())
 
  Avoid cpu_is* checks in plat-omap.
 
 OK, I'll bite.  Why?

I think this is being looked for all the new code introduced
in plat-omap layer for the following reasons:
Adding cpu-is-* checks makes code unmaintainable going fwd.
plat-omap layer needs to handle common code for all omap platforms.

This was raised for GPIO driver because of which, there was a
requirement to clean-up the gpio driver.

Is this stand changed? Are cpu_is* checks allowed in plat-omap?

   + clocksource_32k.read = omap16xx_32k_read;
   + else if (cpu_is_omap2420())
   + clocksource_32k.read = omap2420_32k_read;
   + else if (cpu_is_omap2430())
   + clocksource_32k.read = omap2430_32k_read;
   + else if (cpu_is_omap34xx())
   + clocksource_32k.read = omap34xx_32k_read;
   + else if (cpu_is_omap44xx())
   + clocksource_32k.read = omap44xx_32k_read;
   + else
   + return -ENODEV;
   +
   + sync_32k_ick = clk_get(NULL, omap_32ksync_ick);
   + if (sync_32k_ick)
   + clk_enable(sync_32k_ick);
   +
   + clocksource_32k.mult = clocksource_hz2mult(32768,
   + clocksource_32k.shift);
   +
   + offset_32k = clocksource_32k.read(clocksource_32k);
   +
   + if (clocksource_register(clocksource_32k))
   + printk(err, clocksource_32k.name);
   + }
   + return 0;
   +}
   +arch_initcall(omap_init_clocksource_32k);
   +


-V Charulatha
--
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 v4 0/4] OMAP2/3: DMA: FIFO drain errata fixes

Hello,

Changes since v3:
- use flags for errata handling
 - OMAP2 buffering disable converted to use flags
 - OMAP3 i541 is using the dma_errata flag
- Spelling fix in OMAP3 drain timeout message
Changes since v2:
- remove multiple assignment
Changes since v1:
- Errata ID added to the comment (i541)

Intro mail from v1:

The following series fixes the sDMA FIFO drain issue present for OMAP2 and
OMAP3, and covered by an errata.
For OMAP2 the omap_start_dma had a comment about this errata, but the workaround
configured wrong bit (CCR_EN instead of the correct BUFFERING_DISABLE bit).
The first patch from Jarkko Nikula jhnik...@gmail.com fixes this.
For OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again. The second patch implements this workaround for OMAP3.

The FIFO drain problem can be reproduced on both OMAP2 and OMAP3 while using
audio (capture case):
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat  /dev/null  \
dd if=/dev/urandom of=/dev/null

or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 1 -F 5000 -f dat  /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...

On OMAP2 we can not recover from this problem. The board has to be rebooted,
while OMAP3 can be recovered by reseting the sDMA channel, or introducing
unrelated sDMA activity (which takes sDMA out from Standby - but this is not
working all the time).

---
Peter Ujfalusi (3):
  OMAP: DMA: Introduce errata handling variable, and macro
  OMAP2: DMA: Use errata flag for disabling buffering
  OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

ext Jarkko Nikula (1):
  omap: dma: Fix buffering disable bit setting for omap24xx

 arch/arm/plat-omap/dma.c  |   60 ++--
 arch/arm/plat-omap/include/plat/dma.h |4 ++
 2 files changed, 60 insertions(+), 4 deletions(-)

--
1.7.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: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

Peter, 

 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] 
 Sent: Monday, October 04, 2010 12:46 PM
 To: G, Manjunath Kondaiah
 Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; 
 Liam Girdwood
 Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
 bit setting for omap24xx

 On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote:
  No errata numbers numbers used with TI errata documents 
 till omap2430.
  Errata numbers avaialable from omap3430 onwards.

   For OMAP3 the errata number is i541, but I do not know the iXYZ 
   number for OMAP2 class.

  Being said that no errata numbers for omap2 class, it's ok to use
  omap3 errata numbers for common errata(like your patch 2/2)

 Thanks,
 we are going to use the same errata ID for OMAP2, and OMAP3, 
 but going to use different workaround for them:
 OMAP2: disable buffering

This issue seems to be completly different from omap3 i541.
This is required to flush out fifo contents properly where as with i541, 
it requires DMA controller to be put in no mstandby mode before stoping 
DMA transfer.

 OMAP3: implement the workaround as it is in the errata

 So, as Tony suggested, I'll add the errata handling, and we

If you are introducing errata handling, are you taking care of existing 
errata in DMA driver also? If not, it is better to go ahead current
implementation. DMA hwmod patches will introduce errata handling and these
changes can be rebased once it is available in mainline.

 are going to have:
 DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to

For OMAP2, you should use DMA_ERRATA_IFRAME_BUFFERING since it is different
type of issue.

-Manjunath 
--
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 0/4] OMAP2/3: DMA: FIFO drain errata fixes

On Monday 04 October 2010 11:29:16 ext Peter Ujfalusi wrote:
 Hello,
 
 Will resend, since

I'll wait for comments on v4 series, and I'll send the v5 later today after the 
comments to reduce the noise.

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

Re: [PATCH 02/14] omap: Map only available sram memory

2010-10-04 Thread Grazvydas Ignotas

 
  This hangs OMAP3 pandora:
 
  [    0.00] Linux version
  2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc
  version 4.3.3 (Sourcery G++ Lite 2009q1-20
  [    0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7),
 cr=10c53c7f
  [    0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing
  instruction cache
  [    0.00] Machine: Pandora Handheld Console
  [    0.00] Ignoring unrecognised tag 0x54410008
  [    0.00] bootconsole [earlycon0] enabled
  [    0.00] Reserving 6422528 bytes SDRAM for VRAM
  [    0.00] Memory policy: ECC disabled, Data cache writeback
  [    0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
  [    0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1
  (stuck here)
 
  reverting this fixes the problem.

 Hmm, boots fine here with overo. Any idea what in this patch breaks
 pandora?

 The change in this patch is not board dependent really. Have tested this
 on 3430SDP. Pandora is OMAP3 based, right ?

OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and
it has the same problem. Maybe it's because of older Cortex A8 used
there, or I'm missing some errata workaround in defconfig.

BTW, hacking the size to 1M on top of your patch fixes the problem too:

base = omap_sram_start;
base = ROUND_DOWN(base, PAGE_SIZE);
omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
-   omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
+   omap_sram_io_desc[0].length = 0x10;
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
--
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: NOTE: hwmod changes merged to linux-omap master for testing

2010-10-04 Thread Ohad Ben-Cohen

On Mon, Oct 4, 2010 at 2:20 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
 Can you post complete boot log? so far, it failed on one blaze and
 one 3430sdp both of them are having es2.0

Sure:

wizery.com/ohad/blaze-linux-omap.txt.gz

Summary of my setup:
- Blaze ES2.0
- linux-omap-2.6 master branch (commit
0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix
build after merging in hwmod support for testing)
- omap2plus_defconfig
- kernel boots (with 2-3 warnings)
--
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: Dropping omap3430 ES1.0 support in mainline


On 10/2/2010 12:28 AM, Anand Gadiyar wrote:

Paul Walmsley wrote:

On Sat, 2 Oct 2010, Anand Gadiyar wrote:


Okay, so we're aligned that you guys don't have an ES1 board to test,
and TI doesn't have any either. :)

I'd still like to know if anyone in the wild still cares about the

board.


(I see Tony already said No thanks, but I'd like to know anyway).


Why would we want to remove support for a board that should work fine

with

linux-omap and isn't causing any problems with existing code?


I'm not sure it works fine, and if there are no users that care about
the board, then it would be nice to drop the support. If the board
works fine today, that's good, but has anyone tested the current
kernel on that board?

(we're struggling to keep linux-omap working on boards available now,
why support something that nobody cares about. It's not like I'm asking
3430 support to be dropped)

- the ES1 chip has never been available to the outside world beyond
sampling quantities
- no new developments are likely to happen on that board
- nobody's likely to have one of these around and care to boot it up
- there are plenty of replacements like the beagles which are lower
   cost, easier to obtain, and can beat an ES1 in speed

I'm okay having support for the board if someone's actually using it.
It's not such a big deal. It was just a thought - it came up because
Manju was looking at old errata docs, and came across something that
was specific to an ES1, but we realized there was no way to test it.


If this is the SDMA bug we are talking about, it was unfortunately 
already there in OMAP2420. For some reason I didn't find it in 2430 
errata, but since it was still there in 3430 ES1, we can assume that 
2430 also has the issue.



That being said, ES1 devices for both OMAP3 and OMAP4 were supposed to 
be engineering samples.
There is no product out there with OMAP3 ES1, and same thing is 
happening with 4430 ES1.


So, it makes sense to keep supporting them during the transition, but as 
soon as everybody is upgraded to the next production version, what the 
point to keep maintaining these buggy devices?

Hopefully the auto-destroy mode after 2 years seems to work fine :-)

Regards,
Benoit


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

RE: [PATCH 2/2] OMAP3 PM: sleep code clean up

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Amit Kucheria
 Sent: Monday, October 04, 2010 2:27 PM
 To: Sripathy, Vishwanath
 Cc: Kevin Hilman; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
 Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up

 On 10 Oct 04, Sripathy, Vishwanath wrote:
  Kevin,

 [snip]

   But this also makes me wonder, if we're going to clean this up, the
 bulk
   of it could be re-written in C, with some inline asm helpers as needed.
  Probably yes. But as this code is specific to OMAP3, do you think it's
  worth spending time on rewriting the entire code in C? It might be a
  significant effort and it will not be reusable for other ARM SOCs.

 The C code will be more maintainable and offer more opportunities to
 refactor across OMAP flavours - perhaps OMAP4 as well.

 I'm also interested in code reuse across other SoCs. We've got to be able
 to
 shut down the ARM core using common code instead of each SoC copying buggy
 code from each other. Could you list reasons why you don't think the code
 is
 re-usable?
Trust zone implementation and it's varients
--
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] nand: omap2: Missing arg to gpmc_prefetch_reset()

2010-10-04 Thread Artem Bityutskiy

On Mon, 2010-10-04 at 10:52 +0200, Loïc Minier wrote:
 On Mon, Oct 04, 2010, Artem Bityutskiy wrote:
  FYI, a similar patch is already in Linus' tree, so I'm dropping it from
  my tree
 
  Ok, thanks; is there something I should have done to get this patch
  into Linus tree?

No, you did everything right. I guess that guy was just faster than you.

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

[PATCH v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx

From: ext Jarkko Nikula jhnik...@gmail.com

An errata workaround for omap24xx is not setting the buffering disable bit
25 what is the purpose but channel enable bit 7 instead.

Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
driver. Peter Ujfalusi peter.ujfal...@nokia.com has found an issue in
recording that the DMA stall could happen if there were a buffer overrun
detected by ALSA and the DMA was stopped and restarted due that. This
problem is known to occur on both OMAP2420 and OMAP3. It can recover on
OMAP3 after dma free, dma request and reconfiguration cycle. However, on
OMAP2420 it seems that only way to recover is a reset.

Problem was not visible before the commit c12abc0. That commit changed that
the McBSP transmitter/receiver is released from reset only when needed. That
is, only enabled McBSP transmitter without transmission was able to prevent
this DMA stall problem in receiving side and underlying problem did not show
up until now. McBSP transmitter itself seems to no be reason since DMA
stall does not recover by enabling the transmission after stall.

Debugging showed that there were a DMA write active during DMA stop time and
it never completed even when restarting the DMA. Experimenting showed that
the DMA buffering disable bit could be used to avoid stalling when using
source synchronized transfers. However that could have performance hit and
OMAP3 TRM states that buffering disable is not allowed for destination
synchronized transfers so subsequent patch will implement a method to
complete DMA writes when stopping.

This patch is based on assumtion that complete lock-up on OMAP2420 is
different but related problem. I don't have access to OMAP2420 errata but
I believe this old workaround here is put for a reason but unfortunately
a wrong bit was typed and problem showed up only now.

v2: Issue is applicaple only to OMAP2420 and ES1.0 of OMAP2430. Thanks to
G, Manjunath Kondaiah manj...@ti.com for noticing.

Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
 arch/arm/plat-omap/dma.c  |5 +++--
 arch/arm/plat-omap/include/plat/dma.h |1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ec7eddf..6914ccf 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -999,8 +999,9 @@ void omap_start_dma(int lch)
 * Errata: On ES2.0 BUFFERING disable must be set.
 * This will always fail on ES1.0
 */
-   if (cpu_is_omap24xx())
-   l |= OMAP_DMA_CCR_EN;
+   if (cpu_is_omap2420() ||
+   (cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
+   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
l |= OMAP_DMA_CCR_EN;
dma_write(l, CCR(lch));
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index af3a039..776ba44 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -335,6 +335,7 @@
 #define OMAP2_DMA_MISALIGNED_ERR_IRQ   (1  11)
 
 #define OMAP_DMA_CCR_EN(1  7)
+#define OMAP_DMA_CCR_BUFFERING_DISABLE (1  25)
 
 #define OMAP_DMA_DATA_TYPE_S8  0x00
 #define OMAP_DMA_DATA_TYPE_S16 0x01
-- 
1.7.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

[PATCH v4 2/4] OMAP: DMA: Introduce errata handling variable, and macro

Use flags for errata handling.

Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
 arch/arm/plat-omap/dma.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 6914ccf..ae0ff64 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -146,6 +146,10 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] 
= {
INT_1610_DMA_CH14, INT_1610_DMA_CH15, INT_DMA_LCD
 };
 
+/* Errata handling */
+static u16 dma_errata;
+#define IS_DMA_ERRATA(id)  (dma_errata  (id))
+
 static inline void disable_lnk(int lch);
 static void omap_disable_channel_irq(int lch);
 static inline void omap_enable_channel_irq(int lch);
@@ -2042,6 +2046,10 @@ void omap_dma_global_context_restore(void)
 
 
/**/
 
+static void dma_errata_configure(void)
+{
+}
+
 static int __init omap_init_dma(void)
 {
unsigned long base;
@@ -2064,6 +2072,8 @@ static int __init omap_init_dma(void)
return -ENODEV;
}
 
+   dma_errata_configure();
+
omap_dma_base = ioremap(base, SZ_4K);
BUG_ON(!omap_dma_base);
 
-- 
1.7.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: [PATCH 2/2] OMAP3 PM: sleep code clean up

2010-10-04 Thread Sripathy, Vishwanath

Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Saturday, September 25, 2010 1:35 AM
 To: Sripathy, Vishwanath
 Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
 Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up

 Vishwanath BS vishwanath...@ti.com writes:

  This patch has done some clean up of omap3 sleep code.
  Basically all possible hardcodings are removed and code is Reorganized
  into more logical buckets for better readability and instrumentation.
 
  Tested on ZOOM3.

 Again, please describe more about how it was tested.  idle?  suspend?
 retention? off?
This has been tested for both RET and OFF mode in Idle and suspend path. Will 
update the change log for the same.

 Also please fix long-line checkpatch warnings.
OK.

 While breaking this up in to subroutines, why not just call them all
 from the C-code instead of assembly?
I thought about that. But unfortunately, while saving CPU registers (in 
save_context_wfi), LR also gets saved. So if I call wfi routine 
(omap34xx_do_wfi ) from C code itself, then LR would have pointed to 
omap34xx_do_wfi while saving
the registers which is not correct.

 But this also makes me wonder, if we're going to clean this up, the bulk
 of it could be re-written in C, with some inline asm helpers as needed.
Probably yes. But as this code is specific to OMAP3, do you think it's worth 
spending time on rewriting the entire code in C? It might be a significant 
effort and it will not be reusable for other ARM SOCs.

Vishwa

 Kevin

  Signed-off-by: Vishwanath BS vishwanath...@ti.com
  Cc: Kevin Hillman khil...@deeprootsystems.com
  Cc: Linaro linaro-...@lists.linaro.org
  ---
   arch/arm/mach-omap2/sleep34xx.S   |  377 ++---
 
   arch/arm/plat-omap/include/plat/control.h |2 +
   2 files changed, 189 insertions(+), 190 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
  index ba53191..734f82a
  --- a/arch/arm/mach-omap2/sleep34xx.S
  +++ b/arch/arm/mach-omap2/sleep34xx.S
  @@ -33,17 +33,20 @@
   #include prm.h
   #include sdrc.h
 
  -#define SDRC_SCRATCHPAD_SEM_V  0xfa00291c
  +#define SDRC_SCRATCHPAD_SEM_OFFS   0xc
  +#define SDRC_SCRATCHPAD_SEM_V  OMAP343X_SCRATCHPAD_REGADDR \
  +   
  (SDRC_SCRATCHPAD_SEM_OFFS)
 
   #define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
  -   OMAP3430_PM_PREPWSTST)
  -#define PM_PREPWSTST_CORE_P0x48306AE8
  +   OMAP3430_PM_PREPWSTST)
  +#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD + \
  +   
  OMAP3430_PM_PREPWSTST
   #define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
  OMAP3430_PM_PREPWSTST)
   #define PM_PWSTCTRL_MPU_P  OMAP3430_PRM_BASE + MPU_MOD +
 OMAP2_PM_PWSTCTRL
   #define CM_IDLEST1_CORE_V  OMAP34XX_CM_REGADDR(CORE_MOD,
 CM_IDLEST1)
  -#define SRAM_BASE_P0x4020
  -#define CONTROL_STAT   0x480022F0
  +#define SRAM_BASE_P0x4020
  +#define CONTROL_STAT   OMAP343X_CTRL_BASE +
 OMAP343X_CONTROL_STATUS
   #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is
 * available */
   #define SCRATCHPAD_BASE_P  (OMAP343X_CTRL_BASE +
 OMAP343X_CONTROL_MEM_WKUP\
  @@ -184,29 +187,16 @@ api_params:
   ENTRY(save_secure_ram_context_sz)
  .word   . - save_secure_ram_context
 
  -/*
  - * Forces OMAP into idle state
  - *
  - * omap34xx_suspend() - This bit of code just executes the WFI
  - * for normal idles.
  - *
  - * Note: This code get's copied to internal SRAM at boot. When the OMAP
  - *  wakes up it continues execution at the point it went to sleep.
  - */
  -ENTRY(omap34xx_cpu_suspend)
  +/* Function to execute WFI. When the MPU wakes up from retention
  + * or inactive mode, it continues execution just after wfi */

 fix multi-line comment style

  +ENTRY(omap34xx_do_wfi)
  stmfd   sp!, {r0-r12, lr}   @ save registers on stack
  -loop:
  -   /*b loop*/  @Enable to debug by stepping through code
  -   /* r0 contains restore pointer in sdram */
  -   /* r1 contains information about saving context */
  +
  ldr r4, sdrc_power  @ read the SDRC_POWER register
  ldr r5, [r4]@ read the contents of SDRC_POWER
  orr r5, r5, #0x40   @ enable self refresh on idle req
  str r5, [r4]@ write back to SDRC_POWER register
 
  -   cmp r1, #0x0
  -   /* If context save is required, do that and execute wfi */
  -   bne save_context_wfi
  /* Data memory barrier and Data sync barrier */
  mov r1, #0
  mcr p15, 0, r1, c7, c10, 4
  @@ -225,8 +215,182 @@ loop:
  nop
  nop
  bl

Re: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset()

2010-10-04 Thread Loïc Minier

On Mon, Oct 04, 2010, Artem Bityutskiy wrote:
 FYI, a similar patch is already in Linus' tree, so I'm dropping it from
 my tree

 Ok, thanks; is there something I should have done to get this patch
 into Linus tree?

-- 
Loïc Minier
--
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: NOTE: hwmod changes merged to linux-omap master for testing

2010-10-04 Thread Ohad Ben-Cohen

On Mon, Oct 4, 2010 at 9:49 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
 Booting with zoom3 seems to be fine but observed issues with omap4 blaze 
 board.

FWIW, for me it worked just fine with blaze
--
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: beagle hangs in uart3 disabling clocks

2010-10-04 Thread Pramod


Hi Sanjeev,

I just tested pm branch of tony's linux-omap-2.6 tree, and found my
beagle will hang in uart3 disabling clocks, follows the log info:



[snip]..[snip]



Texas Instruments X-Loader 1.41
Starting OS Bootloader...


U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
DRAM:  128 MB
NAND:


Lei,

Couldn't help noticing the version information for x-loader and
u-boot. Both seem to be quite old...

Could you try update both? May be, there is a dependency...

I am seeing the same issue with console on UART3 on zoom3 board. The 
bootloaders are older. Can you please share a link to latest bootloader 
which will have zoom3 support.


I am using L25_INC3.x android kernel. The board hangs as soon as it 
boots the kernel. Enabling the logs shows us that the hang occurs when 
UART3 clocks are being disabled in omap_hwmod.c as mentioned by Lei 
Ming. Has anyone observed this issue on any of omap boards?



~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: NOTE: hwmod changes merged to linux-omap master for testing



 -Original Message-
 From: Ohad Ben-Cohen [mailto:o...@wizery.com] 
 Sent: Monday, October 04, 2010 6:03 PM
 To: G, Manjunath Kondaiah
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: NOTE: hwmod changes merged to linux-omap master 
 for testing
 
 On Mon, Oct 4, 2010 at 2:20 PM, G, Manjunath Kondaiah 
 manj...@ti.com wrote:
  Can you post complete boot log? so far, it failed on one 
 blaze and one 
  3430sdp both of them are having es2.0
 
 Sure:
 
 wizery.com/ohad/blaze-linux-omap.txt.gz

Here is difference: you are booting with nosmp..

console=ttyO2,115200n8 root=/dev/nfs rw rootdelay=1 mem=4...@0x8000 
mem=5...@0xa000 noinitrd vram=12M omapfb.vram=0:5M,1:5M nosmp 
nfsroot=192.168.1.4:/home/ohad/embedded/myfs_blaze,nolock,devfs=mount 
ip=192.168.1.160

Remove nosmp from your bootargs and try.

-Manjunath


--
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/4] iovmm: fix roundup for next area and end check for the last area

2010-10-04 Thread David Cohen

Hi,

I have no access to my @nokia.com e-mail at this moment, so I'm
replying using my personal one.

On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:

 On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, Fernando wrote:
 
   On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo,
   Fernando wrote:
   
  
   [snip]
  
   arch/arm/plat-omap/iovmm.c |    6 +++---
   1 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/arch/arm/plat-omap/iovmm.c
 b/arch/arm/plat-omap/iovmm.c
  index 24ca9c4..fc6b109 100644
  --- a/arch/arm/plat-omap/iovmm.c
  +++ b/arch/arm/plat-omap/iovmm.c
  @@ -289,19 +289,19 @@ static struct iovm_struct
 *alloc_iovm_area(struct iommu *obj, u32 da,
        prev_end = 0;
        list_for_each_entry(tmp, obj-mmap, list) {
 
  -             if (prev_end = start)
  +             if (prev_end  start)
                        break;
 
                if (start + bytes = tmp-da_start)
                        goto found;
 
                if (flags  IOVMF_DA_ANON)
  -                     start = roundup(tmp-da_end +
   1, alignement);
  +                     start = roundup(tmp-da_end,
   alignement);

 There's a lack of comment here, but the purpose of
 tmp-da_end + 1 is to create a gap between iovm areas to
 force to trigger iommu faults when some access exceeds a
   valid area.
 Without this gap, such situation may produce data
   corruption which
 is much more difficult to track.
   
That only works when you are accessing sequencially beyond
   the End of
the vm_area. However if you are accessing a random address
   Which is in
the mmu tables you still can corrupt memory which does Not
   belong to
you. That looks not very effective then why waste Memory?
  
   The main intention is to detect sequential access beyond the
   end of the vm area and it is effective for that purpose.
   i.e., OMAP3 ISP has a hw issue which makes its H3A submodule,
   responsible to produce statistics data for the captured
   image, to write more data than it should. The workaround
   described in the errata wasn't enough to avoid error
   conditions, so a different approach was implemented. This gap
   did help me to make sure the new workaround is valid and no
   data corruption was occurring anymore.
   Anyway, I can't see why memory is being wasted.
  
 
  I was taking about vitual memory waste (maybe not so important).
  Is ok for me then keep the gap. Do other changes look good to
  You?

 Do you mean in this patch?
 All changes make sense only if you're removing the gap, except for the
 fix below.

 The thing is, the dspbridge needs to map some register in order to DSP
 can read and configure some of them. We need to map some pages
 with fix addresses and to do that I use iommu_kmap. So when some
 of that pages are contiguous I get his error:

 %s: no space to fit %08x(%x) flags: %08x\n

 Which is not true. The page to page perfectly fix, but the check with 1 byte
 more avoid that it could be mapped and I am getting the error.

 I am not agree with the gap, but I am ok when it is not fixed address as
 below code

 if (flags  IOVMF_DA_ANON)
        start = roundup(tmp-da_end + 1, alignement);

 But it is breaking the tidspbridge when the gap is used for fixed addresses.

 It should not fail when we want to map a page what is freed just because of 
 the gap.
 Please let me know what you thing.

I got your point. I agree the gap shouldn't be forced for fixed da.
IMO you can apply this change when !(flags  IOVMF_DA_ANON).

Regards,

David


 Thanks,
 Fernando.


 [snip]

 
                prev_end = tmp-da_end;
        }
 
  -     if ((start  prev_end)  (ULONG_MAX - start = bytes))
  +     if ((start = prev_end)  (ULONG_MAX - start +
   1 = bytes))

 This fix is partially valid. The correct change must be only:
 -       if ((start  prev_end)  (ULONG_MAX - start = bytes))
 +       if ((start  prev_end)  (ULONG_MAX - start + 1 = bytes))

 Otherwise you wouldn't guarantee the gap for fixed da.

 Br,

 David
 --
 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 02/14] omap: Map only available sram memory



 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
 Sent: Monday, October 04, 2010 3:08 PM
 To: Grazvydas Ignotas
 Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; Russell King - ARM Linux
 Subject: RE: [PATCH 02/14] omap: Map only available sram memory
 
  -Original Message-
  From: Grazvydas Ignotas [mailto:nota...@gmail.com]
  Sent: Monday, October 04, 2010 2:34 PM
  To: Shilimkar, Santosh
  Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
  ker...@lists.infradead.org; Russell King - ARM Linux
  Subject: Re: [PATCH 02/14] omap: Map only available sram memory
 
   
This hangs OMAP3 pandora:
   
[    0.00] Linux version
2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis)
 (gcc
version 4.3.3 (Sourcery G++ Lite 2009q1-20
[    0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7),
   cr=10c53c7f
[    0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[    0.00] Machine: Pandora Handheld Console
[    0.00] Ignoring unrecognised tag 0x54410008
[    0.00] bootconsole [earlycon0] enabled
[    0.00] Reserving 6422528 bytes SDRAM for VRAM
[    0.00] Memory policy: ECC disabled, Data cache writeback
[    0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
[    0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size:
  0x1
(stuck here)
   
reverting this fixes the problem.
  
   Hmm, boots fine here with overo. Any idea what in this patch breaks
   pandora?
  
   The change in this patch is not board dependent really. Have tested
 this
   on 3430SDP. Pandora is OMAP3 based, right ?
 
  OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and
  it has the same problem. Maybe it's because of older Cortex A8 used
  there, or I'm missing some errata workaround in defconfig.
 
  BTW, hacking the size to 1M on top of your patch fixes the problem too:
 
  base = omap_sram_start;
  base = ROUND_DOWN(base, PAGE_SIZE);
  omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
  -   omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size,
  PAGE_SIZE);
  +   omap_sram_io_desc[0].length = 0x10;
 This is the exact reason this patch is created :)
 So that you map only available memory instead of 1 MB
  iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));

Just booted latest mainline where this patch is already merged and 
my OMAP3630 boots fine

## Booting image at 8030 ...
   Image Name:   Linux-2.6.36-rc6-00086-gd4e8aa3
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3242124 Bytes =  3.1 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.36-rc6-00086-gd4e8aa3 
(a0393...@a0393909-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) 
#1 Mon Oct 4 18:27:30 IST 2010
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction 
cache
[0.00] Machine: OMAP Zoom3 board
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
[0.00] SRAM: Mapped pa 0x40208000 to va 0xfe408000 size: 0x8000
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32512
[0.00] Kernel command line: root=/dev/ram0 rw mem=128M 
console=ttyS0,115200n8 noinitrd root=/dev/nfs rw 
nfsroot=172.24.190.46:/ubuntu/nfs-share/omap3_next/,nolock,tcp,rsize=4096,wsize=4096
 ip=dhcp earlyprintk
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 128MB = 128MB total
[0.00] Memory: 116148k/116148k available, 14924k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0   (   2 MB)
[0.00] vmalloc : 0xc880 - 0xf800   ( 760 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .init : 0xc0008000 - 0xc0047000   ( 252 kB)
[0.00]   .text : 0xc0047000 - 0xc05e9000   (5768 kB)
[0.00]   .data : 0xc0612000 - 0xc07e2900   (1859 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU-based detection of stalled CPUs is disabled.
[0.00]  Verbose stalled-CPUs detection is disabled.
[

RE: NOTE: hwmod changes merged to linux-omap master for testing



 -Original Message-
 From: Ohad Ben-Cohen [mailto:o...@wizery.com] 
 Sent: Monday, October 04, 2010 5:44 PM
 To: G, Manjunath Kondaiah
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: NOTE: hwmod changes merged to linux-omap master 
 for testing
 
 On Mon, Oct 4, 2010 at 2:13 PM, G, Manjunath Kondaiah 
 manj...@ti.com wrote:
  ES2.0 or ES1.0?
 
 2.0

Can you post complete boot log? so far, it failed on one blaze and
one 3430sdp both of them are having es2.0

-Manjunath

--
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: NOTE: hwmod changes merged to linux-omap master for testing

 -Original Message-
 From: Govindraj [mailto:govindraj...@gmail.com] 
 Sent: Monday, October 04, 2010 2:50 PM
 To: G, Manjunath Kondaiah
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: NOTE: hwmod changes merged to linux-omap master 
 for testing

 On Mon, Oct 4, 2010 at 1:19 PM, G, Manjunath Kondaiah 
 manj...@ti.com wrote:
  Hi Tony,
  With latest merges on master branch with commit ID:
  0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix 
  build after merging in hwmod support for testing

  Booting with zoom3 seems to be fine but observed issues 
 with omap4 blaze board.

  Looks like multiple warning dumps and finally it crashes 
 after Freeing init memory with both NFS and ramdisk file systems.

 This issue though seems to exist much before hwmod merge, I 
 tried below commit on master

Mainline line kernel(2.6.36-rc6) merged only with 'omap_for_2.6.37' 
of git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base 
will work fine on omap4.

-Manjunath
--
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 1/4] omap: dma: Fix buffering disable bit setting for omap24xx

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi
 Sent: Monday, October 04, 2010 1:48 PM
 To: Tony Lindgren
 Cc: linux-omap@vger.kernel.org; Jarkko Nikula; 
 linux-arm-ker...@lists.infradead.org
 Subject: [PATCH v4 1/4] omap: dma: Fix buffering disable bit 
 setting for omap24xx

 From: ext Jarkko Nikula jhnik...@gmail.com

 An errata workaround for omap24xx is not setting the 
 buffering disable bit
 25 what is the purpose but channel enable bit 7 instead.

...

 diff --git a/arch/arm/plat-omap/dma.c 
 b/arch/arm/plat-omap/dma.c index ec7eddf..6914ccf 100644
 --- a/arch/arm/plat-omap/dma.c
 +++ b/arch/arm/plat-omap/dma.c
 @@ -999,8 +999,9 @@ void omap_start_dma(int lch)
* Errata: On ES2.0 BUFFERING disable must be set.
* This will always fail on ES1.0
*/

Sorry, I didn't catch this with earlier patch.

Looks like wrong comment. only on 2430ES1.0 and for all omap2420, 
buffer disable should be set. 
I feel below description will be useful to the reader:
Errata: Inter Frame DMA buffering issue(All OMAP2420 and OMAP2430ES1.0):
DMA will wrongly buffer elements if packing and bursting is enabled.
This might result in data gets stalled in FIFO at the end of the block.
Workaround: DMA channels must have BUFFERING_DISABLED bit set to guarantee
no data will stay in the DMA FIFO in case inter frame buffering occurs.

-Manjunath--
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 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] 
 Sent: Monday, October 04, 2010 4:13 PM
 To: G, Manjunath Kondaiah
 Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jarkko Nikula; 
 linux-arm-ker...@lists.infradead.org
 Subject: Re: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA 
 FIFO draining does not finish

 On Monday 04 October 2010 12:17:41 ext G, Manjunath Kondaiah wrote:

  ...

   + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */

  This logic is required for multiple erratas.

 As Tony requested, I have added a variable for flags to 
 handle the different erratas. I even added a macro to check 
 that the errata applies, so one can use:
 if (IS_DMA_ERRATA(DMA_ERRATA_X))

  Can we have seperate
  function for handling this logic. More details at:
  https://patchwork.kernel.org/patch/126271/

 I see. That patch is for hwmod converted dma code, right?
 We need this fix without the hwmod to applied, and than 
 backport it to earlier kernel releases.

  As I mentioned in other mail, if you are introducing this 
 feature, it 
  is better to convert existing erratas also to use this feature.

 The upcoming hwmod conversion will take care of the cleanup.

If this is the case, not sure about intention of having dma_errata only
for these two erratas since all the erratas are not handled.

All the erratas will get cleaned up and errata handling feature
will be introduced along with dma hwmod changes.

If feel v3 version is better so that I can use these changes along 
dma hwmod.

It is upto Tony to decide.

 We _need_ these two small fixes ASAP, since it is fixing 
 serious problem in audio (and the same issue might bite other 
 areas as well).
 It is not the intention of this series to clean up the 
 arc/arm/plat-omap/dma.c.

Tony, 
How about having v3 series + review comments fixed(except comments
related errata handling). Errata handling will be done as part dma
hwmod. I am waiting for these patches so that I can rebase these
patches in DMA hwmod.

-Manjunath--
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: devices: Avoid merge conflict between ASoC and OMAP hwmod changes

2010-10-04 Thread Jarkko Nikula

Upcoming ASoC multi-component and OMAP hwmod changes will conflict
in arch/arm/mach-omap2/devices.c. Avoid this by moving a little bit
include statement introduced by ASoC Multi-Component Support patch.

Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
This is intended to be merged with ASoC: multi-component -
ASoC Multi-Component Support patch via ASoC tree.
---
 arch/arm/mach-omap2/devices.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 08e1ad5..512ae46 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -25,10 +25,10 @@
 #include plat/control.h
 #include plat/tc.h
 #include plat/board.h
+#include plat/mcbsp.h
 #include mach/gpio.h
 #include plat/mmc.h
 #include plat/dma.h
-#include plat/mcbsp.h
 
 #include mux.h
 
-- 
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: multiple linux-next OMAP3 build errors

2010-10-04 Thread Gadiyar, Anand

On Mon, Oct 4, 2010 at 11:59 AM, Tomi Valkeinen
tomi.valkei...@nokia.com wrote:
 Hi,

 On Fri, 2010-10-01 at 17:57 +0200, ext Grazvydas Ignotas wrote:
 hi,

 I've been building linux-next for a while now and keep getting these
 build errors, just posting them here in case not all are known. Not
 familiar enough with that code to send patches unfortunately.

   CC      drivers/video/omap2/vram.o
 drivers/video/omap2/vram.c: In function 'omap_vram_reserve_sdram_memblock':
 drivers/video/omap2/vram.c:568: error: implicit declaration of
 function 'memblock_region_is_memory'

 Benjamin, your patch memblock/arm: Use memblock_region_is_memory() for
 omap fb in linux-next seems to be broken. I believe the called function
 should be memblock_is_region_memory, not memblock_region_is_memory?


I've posted this patch [1] for this. Could one of you please pick up,
or fold into
the original patch if it hasn't yet reached mainline?

- Anand

[1] https://patchwork.kernel.org/patch/224902/
--
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 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

On Monday 04 October 2010 12:17:41 ext G, Manjunath Kondaiah wrote:
 
 ...
 
  +   /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
 
 This logic is required for multiple erratas.

As Tony requested, I have added a variable for flags to handle the different 
erratas. I even added a macro to check that the errata applies, so one can use:
if (IS_DMA_ERRATA(DMA_ERRATA_X))

 Can we have seperate
 function for handling this logic. More details at:
 https://patchwork.kernel.org/patch/126271/

I see. That patch is for hwmod converted dma code, right?
We need this fix without the hwmod to applied, and than backport it to earlier 
kernel releases.

 As I mentioned in other mail, if you are introducing this feature,
 it is better to convert existing erratas also to use this feature.

The upcoming hwmod conversion will take care of the cleanup.
We _need_ these two small fixes ASAP, since it is fixing serious problem in 
audio (and the same issue might bite other areas as well).
It is not the intention of this series to clean up the arc/arm/plat-omap/dma.c.

I have added the dma_errata variable, since Tony asked for it, but even that 
addition is a bigger change than what I was planning to do here.

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

[PATCH 4/5] arm/omap: remove duplicated include

2010-10-04 Thread Nicolas Kaiser

Remove duplicated include.

Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
 arch/arm/mach-omap2/board-cm-t35.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index e10bc10..3308119 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -237,8 +237,6 @@ static inline void cm_t35_init_nand(void) {}
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
 #include linux/spi/ads7846.h
 
-#include plat/mcspi.h
-
 static struct omap2_mcspi_device_config ads7846_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,/* 0: slave, 1: master */
-- 
1.7.2.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: NOTE: hwmod changes merged to linux-omap master for testing

2010-10-04 Thread Ohad Ben-Cohen

On Mon, Oct 4, 2010 at 2:13 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
 ES2.0 or ES1.0?

2.0


 -Manjunath
--
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: beagle hangs in uart3 disabling clocks

2010-10-04 Thread Ming Lei

2010/10/4 Premi, Sanjeev pr...@ti.com:

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ming Lei
 Sent: Sunday, October 03, 2010 2:34 PM
 To: Kevin Hilman; linux-omap@vger.kernel.org
 Subject: beagle hangs in uart3 disabling clocks

 Hi,

 I just tested pm branch of tony's linux-omap-2.6 tree, and found my
 beagle will hang in uart3 disabling clocks, follows the log info:


 [snip]..[snip]


 Texas Instruments X-Loader 1.41
 Starting OS Bootloader...


 U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)

 OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
 OMAP3 Beagle Board + LPDDR/NAND
 DRAM:  128 MB
 NAND:

 Lei,

 Couldn't help noticing the version information for x-loader and
 u-boot. Both seem to be quite old...

 Could you try update both? May be, there is a dependency...

No difference even update x-load and u-boot with those in the link below:

http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation


thanks,
-- 
Lei Ming
--
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: Dropping omap3430 ES1.0 support in mainline


On Fri, Oct 01, 2010 at 04:58:32PM -0500, Tony Lindgren wrote:

* Anand Gadiyar gadi...@ti.com [101001 14:38]:

Tony, all,

The OMAP3430 ES1.0 was pretty much a test chip, with the only known board
being the 3430ES1.0 SDP. There are only a small number of these boards
outside TI and within TI, they've likely never been used in over 2 years.
It's unlikely that these boards still work on mainline, and likely have
been broken in linux-omap since the very beginning.

Between ES1.0 and ES2.0 we've had several major changes in the clock
nodes,
and IPs. However we're still keeping code/data on these in the kernel
today.

Since all later OMAP3 chips have been very similar to ES2.0, it probably
makes sense to drop support for the ES1.0. This would result in a small
but probably significant reduction in the current code. If you're okay
with dropping this support, we can slowly start working on this.

What do you think?


No thanks!


yeah, I don't like the idea of simply dropping support either and would
be very happy if I had an old h2 board to fix up the omap_udc.c code
which is horrible :-p

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

RE: [PATCH v4 3/4] OMAP2: DMA: Use errata flag for disabling buffering

 

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi
 Sent: Monday, October 04, 2010 1:48 PM
 To: Tony Lindgren
 Cc: linux-omap@vger.kernel.org; Jarkko Nikula; 
 linux-arm-ker...@lists.infradead.org
 Subject: [PATCH v4 3/4] OMAP2: DMA: Use errata flag for 
 disabling buffering

...

  
  /* Errata handling */
 +#define DMA_ERRATA_IFRAME_BUFFERING  (1  0)
  static u16 dma_errata;
  #define IS_DMA_ERRATA(id)(dma_errata  (id))
  

These macros should move to header file since these
macros will be used in mach-omap2/dma.c and plat-omap/dma.c
with upcoming dma hwmod series.

-Manjunath--
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 08/10] OMAP: split plat-omap/common.c

 -Original Message-
 From: Balbi, Felipe
 Sent: Monday, October 04, 2010 12:31 PM
 To: Balbi, Felipe
 Cc: Shilimkar, Santosh; Paul Walmsley; linux-omap@vger.kernel.org; linux-
 arm-ker...@lists.infradead.org
 Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c

 On Mon, Oct 04, 2010 at 01:56:24AM -0500, Balbi, Felipe wrote:
 On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote:
 Felipe,

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Paul Walmsley
  Sent: Saturday, October 02, 2010 3:06 AM
  To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
  Subject: [PATCH 08/10] OMAP: split plat-omap/common.c

  Split plat-omap/common.c into three pieces:

  1. the 32KiHz sync timer and clocksource code, which now lives in
 plat-omap/32ksynctimer.c;

 I remember you have converted the 32k sync time code to a platform
 driver.
 That was also addressing the multi-omap build and was removing all
 the compile time switches.
 Do you plan to rebase it and post it again ?

 I still have that sitting on my gitorious tree. The patch is attached
 to this mail. I compile tested (only) for omap3_defconfig, it probably
 needs to start using pm_runtime functions at some point and probably
 move to drivers/clocksource instead of arch/arm/plat-omap.

 patch is also available at [1]

 [1] git://gitorious.org/usb/usb.git clksource

 I made a few changes to make checkpatch.pl --strict happy. Attached

Good !!
This patch addresses splitting as well as multi-omap builds and probably
also a better candidate in case we need to convert sync timer to hwmod
driver.

Paul, what's your take?

Regards,
Santosh

--
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 08/10] OMAP: split plat-omap/common.c

2010-10-04 Thread Paul Walmsley

On Mon, 4 Oct 2010, Varadarajan, Charulatha wrote:

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley
  Sent: Saturday, October 02, 2010 3:06 AM
  To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
  Subject: [PATCH 08/10] OMAP: split plat-omap/common.c
  
  Split plat-omap/common.c into three pieces:

...

  +#if defined(CONFIG_ARCH_OMAP2430)
  +
  +static struct omap_globals omap243x_globals = {
  +   .class  = OMAP243X_CLASS,
  +   .tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
  +   .sdrc   = OMAP243X_SDRC_BASE,
  +   .sms= OMAP243X_SMS_BASE,
  +   .ctrl   = OMAP243X_CTRL_BASE,
  +   .prm= OMAP2430_PRM_BASE,
  +   .cm = OMAP2430_CM_BASE,
  +   .uart1_phys = OMAP2_UART1_BASE,
  +   .uart2_phys = OMAP2_UART2_BASE,
  +   .uart3_phys = OMAP2_UART3_BASE,
  +};
  +
  +void __init omap2_set_globals_243x(void)
  +{
  +   __omap2_set_globals(omap243x_globals);
  +}
  +#endif
  +
  +#if defined(CONFIG_ARCH_OMAP3)
 
 Do you really need these #ifdefs?
 It would be better to avoid these #ifdefs and use cpu_is* checks.
 Same comment holds good across this patch.

If you think you can do it better, please create a patch for the 2.6.38 
time frame.  I personally am not interested in changing any of this code 
(which was not added by this patch; the patch just splits the existing 
code) for the .37 merge window.

  +static int __init omap_init_clocksource_32k(void)
  +{
  +   static char err[] __initdata = KERN_ERR
  +   %s: can't register clocksource!\n;
  +
  +   if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
  +   struct clk *sync_32k_ick;
  +
  +   if (cpu_is_omap16xx())
 
 Avoid cpu_is* checks in plat-omap.

OK, I'll bite.  Why?


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

Re: [PATCH 08/10] OMAP: split plat-omap/common.c


On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote:

Felipe,


-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Saturday, October 02, 2010 3:06 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 08/10] OMAP: split plat-omap/common.c

Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
   plat-omap/32ksynctimer.c;


I remember you have converted the 32k sync time code to a platform driver.
That was also addressing the multi-omap build and was removing all
the compile time switches.
Do you plan to rebase it and post it again ?


I still have that sitting on my gitorious tree. The patch is attached
to this mail. I compile tested (only) for omap3_defconfig, it probably
needs to start using pm_runtime functions at some point and probably
move to drivers/clocksource instead of arch/arm/plat-omap.

patch is also available at [1]

[1] git://gitorious.org/usb/usb.git clksource

8--- cut here -

From 9aad17796072a2ee88aa11c0431fa99e8e9609f0 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Tue, 23 Mar 2010 12:54:14 +0200
Subject: [PATCH] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver
Organization: Texas Instruments\n

Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap1/devices.c|   24 
 arch/arm/mach-omap2/clock2420_data.c |2 +-
 arch/arm/mach-omap2/clock2430_data.c |2 +-
 arch/arm/mach-omap2/clock3xxx_data.c |2 +-
 arch/arm/mach-omap2/devices.c|   35 +
 arch/arm/plat-omap/Makefile  |4 +-
 arch/arm/plat-omap/common.c  |  158 -
 arch/arm/plat-omap/counter-32k.c |  251 ++
 8 files changed, 315 insertions(+), 163 deletions(-)
 create mode 100644 arch/arm/plat-omap/counter-32k.c

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index aa07256..b276b4b 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -28,6 +28,29 @@
 
 /*-*/
 
+#define OMAP16XX_TIMER_32K_BASE		0xfffbc400

+
+static struct resource omap_32k_resources[] = {
+   {
+   .start  = OMAP16XX_TIMER_32K_BASE,
+   .end= SZ_4K,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device omap_32k_device = {
+   .name   = omap-counter-32k,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(omap_32k_resources),
+   .resource   = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+   if (cpu_is_omap16xx())
+  (void) platform_device_register(omap_32k_device);
+};
+
 #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
 
 #define	OMAP_RTC_BASE		0xfffb4800

@@ -223,6 +246,7 @@ static int __init omap1_init_devices(void)
 * in alphabetical order so they're easier to sort through.
 */
 
+	omap_init_32k();

omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index 37d65d6..781bfeb 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL,   gpios_fck,  gpios_fck, CK_242X),
CLK(omap_wdt,   ick,mpu_wdt_ick,   
CK_242X),
CLK(omap_wdt,   fck,mpu_wdt_fck,   
CK_242X),
-   CLK(NULL,   sync_32k_ick,   sync_32k_ick,  CK_242X),
+   CLK(omap-counter-32k,   ick,sync_32k_ick,  
CK_242X),
CLK(NULL,   wdt1_ick,   wdt1_ick,  CK_242X),
CLK(NULL,   omapctrl_ick,   omapctrl_ick,  CK_242X),
CLK(omap24xxcam, fck,   cam_fck,   CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index b33118f..e997692 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL,   gpios_fck,  gpios_fck, CK_243X),
CLK(omap_wdt,   ick,mpu_wdt_ick,   
CK_243X),
CLK(omap_wdt,   fck,mpu_wdt_fck,   
CK_243X),
-   CLK(NULL,   sync_32k_ick,   sync_32k_ick,  CK_243X),
+   CLK(omap-counter-32k,   ick,sync_32k_ick,  
CK_243X),
CLK(NULL,   wdt1_ick,   wdt1_ick,  CK_243X),
CLK(NULL,

Re: [PATCH] usb: musb: fix build break due to partial rename

2010-10-04 Thread Uwe Kleine-König

On Sat, Oct 02, 2010 at 02:04:24AM +0530, Anand Gadiyar wrote:
 Patch usb gadget: don't save bind callback in struct usb_gadget_driver
 in Greg's USB queue missed one conversion of
 usb_gadget_register_driver to usb_gadget_probe_driver,
 causing a build break when MUSB is built in gadget mode.
 
 Fix this.
 
 Reported-by: Grazvydas Ignotas nota...@gmail.com
 Signed-off-by: Anand Gadiyar gadi...@ti.com
 Cc: Uwe Kleine-Koenigu.kleine-koe...@pengutronix.de
 Cc: Michal Nazarewicz m.nazarew...@samsung.com
 Cc: Felipe Balbi ba...@ti.com
 Cc: Greg Kroah-Hartman gre...@suse.de
Acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de

 ---
 Greg,
 
 Since Uwe's original patch isn't yet in mainline, maybe you could
 fold this patch into the original.
 
  drivers/usb/musb/musb_gadget.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_gadget.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_gadget.c
 +++ linux-2.6/drivers/usb/musb/musb_gadget.c
 @@ -1786,7 +1786,7 @@ int usb_gadget_probe_driver(struct usb_g
  
   return retval;
  }
 -EXPORT_SYMBOL(usb_gadget_register_driver);
 +EXPORT_SYMBOL(usb_gadget_probe_driver);
  
  static void stop_activity(struct musb *musb, struct usb_gadget_driver 
 *driver)
  {
 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe

Dmitry,
As agreed, can you push this patch?
https://patchwork.kernel.org/patch/197442/

-Manjunath

 -Original Message-
 From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] 
 Sent: Tuesday, September 21, 2010 9:57 PM
 To: G, Manjunath Kondaiah
 Cc: Ameya Palande; linux-omap@vger.kernel.org; 
 linux-in...@vger.kernel.org; 
 linux-arm-ker...@lists.infradead.org; Tony Lindgren
 Subject: Re: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe
 
 Hi,
 
 On Tue, Sep 21, 2010 at 07:11:01PM +0530, G, Manjunath Kondaiah wrote:
  
  Hi,
  
   -Original Message-
   From: Ameya Palande [mailto:ameya.pala...@nokia.com]
   Sent: Tuesday, September 21, 2010 7:04 PM
   To: G, Manjunath Kondaiah
   Cc: linux-omap@vger.kernel.org; 
 linux-in...@vger.kernel.org; Dmitry 
   Torokhov; linux-arm-ker...@lists.infradead.org; Tony Lindgren
   Subject: Re: [PATCH v2] OMAP3: Keypad: Fix failure exit path in 
   probe
   
   Hi Manjunath,
   
   On Tue, 2010-09-21 at 13:49 +0200, ext G, Manjunath 
 Kondaiah wrote:
The failure exit paths seems to be wrong in probe function.
This patch corrects exit failure paths for error handling cases.
   
 
 And also adds memory leak...
 
 
   https://patchwork.kernel.org/patch/160551/
   Any comments on this?
  
  Looks fine. Sorry, I didn't look at the change. This 
 version seems to 
  be better.
  
 
 I do not understand why we need to separate memory 
 allocations. It looks
 like the minimal patch should be like one below.
 
 Thanks.
 
 -- 
 Dmitry
 
 
 Input: twl4030_keypad - fix error handling path
 
 From: Dmitry Torokhov dmitry.torok...@gmail.com
 
 We should not try to call free_irq() when request_irq() failed.
 
 Reported-by: G, Manjunath Kondaiah manj...@ti.com
 Signed-off-by: Dmitry Torokhov d...@mail.ru
 ---
 
  drivers/input/keyboard/twl4030_keypad.c |7 +++
  1 files changed, 3 insertions(+), 4 deletions(-)
 
 
 diff --git a/drivers/input/keyboard/twl4030_keypad.c 
 b/drivers/input/keyboard/twl4030_keypad.c
 index fb16b5e..09bef79 100644
 --- a/drivers/input/keyboard/twl4030_keypad.c
 +++ b/drivers/input/keyboard/twl4030_keypad.c
 @@ -406,23 +406,22 @@ static int __devinit 
 twl4030_kp_probe(struct platform_device *pdev)
   if (error) {
   dev_info(kp-dbg_dev, request_irq failed for 
 irq no=%d\n,
   kp-irq);
 - goto err3;
 + goto err2;
   }
  
   /* Enable KP and TO interrupts now. */
   reg = (u8) ~(KEYP_IMR1_KP | KEYP_IMR1_TO);
   if (twl4030_kpwrite_u8(kp, reg, KEYP_IMR1)) {
   error = -EIO;
 - goto err4;
 + goto err3;
   }
  
   platform_set_drvdata(pdev, kp);
   return 0;
  
 -err4:
 +err3:
   /* mask all events - we don't care about the result */
   (void) twl4030_kpwrite_u8(kp, 0xff, KEYP_IMR1);
 -err3:
   free_irq(kp-irq, NULL);
  err2:
   input_unregister_device(input);
 --
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: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database


Hi Paul,

On 10/2/2010 12:25 AM, Paul Walmsley wrote:

On Thu, 30 Sep 2010, Cousson, Benoit wrote:


On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote:


   #include omap_hwmod_common_data.h

   #include prm-regbits-24xx.h
@@ -121,6 +123,614 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
  .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
  .flags  = HWMOD_NO_IDLEST,
   };
+/* Timer Common */
+static char *timer_clk_src_names[] = {
+   sys_ck,
+   func_32k_ck,
+   alt_ck,
+   NULL,
+};


I have an issue with that, because this is a pure duplication of the clock_sel
information already contained in the clock data:

static const struct clksel omap24xx_gpt_clksel[] = {
 { .parent =func_32k_ck, .rates = gpt_32k_rates },
{ .parent =sys_ck,  .rates = gpt_sys_rates },
{ .parent =alt_ck,  .rates = gpt_alt_rates },
{ .parent = NULL },
};

And duplicating the same information somewhere else is most of the time a bad
idea.


Yep, there's no way that info should be in the hwmod data, in the current
setup.  It belongs in the clkdev tables.  Example below.


That being said... I don't really know how to handle that properly :-)

We have to find a better way to select the proper source clock in a soc
independent way.

Maybe Paul will have some idea?


Here's how it's done:

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

and

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


The famous clock alias... I don't know why but I always forgot that 
solution each time I have such concern:-(

This is indeed the very clean and cool way to do that clock selection.
We can even remove this #define to identified them and use the clock 
string name directly.


Thanks Paul,
Benoit

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

Re: NOTE: hwmod changes merged to linux-omap master for testing

2010-10-04 Thread Govindraj

On Mon, Oct 4, 2010 at 1:19 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
 Hi Tony,
 With latest merges on master branch with commit ID:
 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build 
 after merging in hwmod support for testing

 Booting with zoom3 seems to be fine but observed issues with omap4 blaze 
 board.

 Looks like multiple warning dumps and finally it crashes after Freeing init 
 memory with both NFS and ramdisk file systems.

This issue though seems to exist much before hwmod merge, I tried
below commit on master

commit 2365f1f7e5544b531ccd3e07fd06bb12bf7a62a7
Merge: acc012f 391bcdd
Author: Tony Lindgren t...@atomide.com
Date:   Wed Sep 29 11:19:10 2010 -0700

Issue still reproducible.
I used 4430SDP with es2.0

Not sure what is happening though.

http://pastebin.com/LZKaAztT

---
Regards,
Govindraj.R



 The complete bootlogs are available at:
 NFS bootlog:
 http://pastebin.com/nrWQ5FGG

 Ramdisk bootlog:
 http://pastebin.com/1F75d2Ew

 -Manjunath

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Saturday, October 02, 2010 6:18 AM
 To: linux-omap@vger.kernel.org
 Subject: NOTE: hwmod changes merged to linux-omap master for testing

 Hi all,

 So I've finally merged Kevin's hwmod branch into the
 linux-omap master so we can give it some testing to see if we
 can merge it to the mainline. Might take few minutes to hit
 the mirrors.

 Please note that for omap2plus machines you need to change:

 - u-boot bootargs for kernel cmdline needs to change with setenv
 - if you use hardcoded CONFIG_CMDLINE, change it in your .config
 - /etc/inittab in your omap root file system if using serial console

 This is because otherwise the serial-omap would be
 conflicting with the 8250 driver. This should not affect
 omap1 machines.

 Please give it a try and report any issues on this list! Now
 all the machines except ams_delta_defconfig should build.
 That one is still missing some camera driver changes to build.

 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
 --
 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 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish



 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi
 Sent: Monday, October 04, 2010 1:48 PM
 To: Tony Lindgren
 Cc: linux-omap@vger.kernel.org; Jarkko Nikula; 
 linux-arm-ker...@lists.infradead.org
 Subject: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO 
 draining does not finish

...
 + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */

This logic is required for multiple erratas. Can we have seperate
function for handling this logic. More details at:
https://patchwork.kernel.org/patch/126271/

...

 --- a/arch/arm/plat-omap/include/plat/dma.h
 +++ b/arch/arm/plat-omap/include/plat/dma.h
 @@ -335,6 +335,9 @@
  #define OMAP2_DMA_MISALIGNED_ERR_IRQ (1  11)
  
  #define OMAP_DMA_CCR_EN  (1  7)
 +#define OMAP_DMA_CCR_RD_ACTIVE   (1  9)
 +#define OMAP_DMA_CCR_WR_ACTIVE   (1  10)
 +#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC(1  24)
  #define OMAP_DMA_CCR_BUFFERING_DISABLE   (1  25)

As I mentioned in other mail, if you are introducing this feature,
it is better to convert existing erratas also to use this feature.

-Manjunath--
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 08/10] OMAP: split plat-omap/common.c


On Mon, Oct 04, 2010 at 01:56:24AM -0500, Balbi, Felipe wrote:

On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote:

Felipe,


-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Saturday, October 02, 2010 3:06 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 08/10] OMAP: split plat-omap/common.c

Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
   plat-omap/32ksynctimer.c;


I remember you have converted the 32k sync time code to a platform driver.
That was also addressing the multi-omap build and was removing all
the compile time switches.
Do you plan to rebase it and post it again ?


I still have that sitting on my gitorious tree. The patch is attached
to this mail. I compile tested (only) for omap3_defconfig, it probably
needs to start using pm_runtime functions at some point and probably
move to drivers/clocksource instead of arch/arm/plat-omap.

patch is also available at [1]

[1] git://gitorious.org/usb/usb.git clksource


I made a few changes to make checkpatch.pl --strict happy. Attached

--
balbi
From 42dddbbd0738b36106e8aa9851ab16851642bdd0 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Tue, 23 Mar 2010 12:54:14 +0200
Subject: [PATCH] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver
Organization: Texas Instruments\n

Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap1/devices.c|   24 
 arch/arm/mach-omap2/clock2420_data.c |2 +-
 arch/arm/mach-omap2/clock2430_data.c |2 +-
 arch/arm/mach-omap2/clock3xxx_data.c |2 +-
 arch/arm/mach-omap2/devices.c|   35 +
 arch/arm/plat-omap/Makefile  |4 +-
 arch/arm/plat-omap/common.c  |  158 -
 arch/arm/plat-omap/counter-32k.c |  253 ++
 8 files changed, 317 insertions(+), 163 deletions(-)
 create mode 100644 arch/arm/plat-omap/counter-32k.c

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index aa07256..62170fd 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -28,6 +28,29 @@
 
 /*-*/
 
+#define OMAP16XX_TIMER_32K_BASE		0xfffbc400
+
+static struct resource omap_32k_resources[] = {
+	{
+		.start		= OMAP16XX_TIMER_32K_BASE,
+		.end		= SZ_4K,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device omap_32k_device = {
+	.name			= omap-counter-32k,
+	.id			= -1,
+	.num_resources		= ARRAY_SIZE(omap_32k_resources),
+	.resource		= omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+	if (cpu_is_omap16xx())
+		(void) platform_device_register(omap_32k_device);
+};
+
 #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
 
 #define	OMAP_RTC_BASE		0xfffb4800
@@ -223,6 +246,7 @@ static int __init omap1_init_devices(void)
 	 * in alphabetical order so they're easier to sort through.
 	 */
 
+	omap_init_32k();
 	omap_init_mbox();
 	omap_init_rtc();
 	omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index 37d65d6..781bfeb 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = {
 	CLK(NULL,	gpios_fck,	gpios_fck,	CK_242X),
 	CLK(omap_wdt,	ick,		mpu_wdt_ick,	CK_242X),
 	CLK(omap_wdt,	fck,		mpu_wdt_fck,	CK_242X),
-	CLK(NULL,	sync_32k_ick,	sync_32k_ick,	CK_242X),
+	CLK(omap-counter-32k,	ick,	sync_32k_ick,	CK_242X),
 	CLK(NULL,	wdt1_ick,	wdt1_ick,	CK_242X),
 	CLK(NULL,	omapctrl_ick,	omapctrl_ick,	CK_242X),
 	CLK(omap24xxcam, fck,	cam_fck,	CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index b33118f..e997692 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = {
 	CLK(NULL,	gpios_fck,	gpios_fck,	CK_243X),
 	CLK(omap_wdt,	ick,		mpu_wdt_ick,	CK_243X),
 	CLK(omap_wdt,	fck,		mpu_wdt_fck,	CK_243X),
-	CLK(NULL,	sync_32k_ick,	sync_32k_ick,	CK_243X),
+	CLK(omap-counter-32k,	ick,	sync_32k_ick,	CK_243X),
 	CLK(NULL,	wdt1_ick,	wdt1_ick,	CK_243X),
 	CLK(NULL,	omapctrl_ick,	omapctrl_ick,	CK_243X),
 	CLK(NULL,	icr_ick,	icr_ick,	CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index dfdce2d..257a8fe 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3343,7 +3343,7 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(omap_wdt,	ick,		wdt2_ick,	CK_3XXX),
 	CLK(NULL,	wdt1_ick,	wdt1_ick,	CK_3XXX),
 	CLK(NULL,	gpio1_ick,	gpio1_ick,	CK_3XXX),
-

Re: [PATCH v4 0/4] OMAP2/3: DMA: FIFO drain errata fixes

Hello,

Will resend, since

On Monday 04 October 2010 11:18:10 ext Peter Ujfalusi wrote:

...

 ext Jarkko Nikula (1):
   omap: dma: Fix buffering disable bit setting for omap24xx

Our mail server changed Jarkko's name.
Sorry.

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

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote:
 No errata numbers numbers used with TI errata documents till omap2430.
 Errata numbers avaialable from omap3430 onwards.
 
  For OMAP3 the errata number is i541, but I do not know the
  iXYZ number for OMAP2 class.
 
 Being said that no errata numbers for omap2 class, it's ok to use
 omap3 errata numbers for common errata(like your patch 2/2)

Thanks,
we are going to use the same errata ID for OMAP2, and OMAP3, but going to use 
different workaround for them:
OMAP2: disable buffering
OMAP3: implement the workaround as it is in the errata

So, as Tony suggested, I'll add the errata handling, and
we are going to have:
DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to differentiate the different 
workarounds. We can than experiment, and we might use the OMAP3 workaround for 
OMAP2 as well.

I'll send the v4 series shortly (after testing).

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

Re: beagle hangs in uart3 disabling clocks

2010-10-04 Thread Govindraj

I tried now on zoom3 with uart3[ttyO2] as console

It boots up fine for me

Logs:

http://pastebin.com/sXR5nYcD

I am using omap2plus_defconfig and lo-master

commit 0882b1455797b0a104978000a622c3f2412e7cf5
Author: Tony Lindgren t...@atomide.com
Date:   Fri Oct 1 17:23:48 2010 -0700

omap: READ CAREFULLY: Fix build after merging in hwmod support for testing


---
Regards,
Govindraj.R



On Mon, Oct 4, 2010 at 5:47 PM, Pramod pramod.gu...@ti.com wrote:
 Hi Sanjeev,

 I just tested pm branch of tony's linux-omap-2.6 tree, and found my
 beagle will hang in uart3 disabling clocks, follows the log info:


 [snip]..[snip]


 Texas Instruments X-Loader 1.41
 Starting OS Bootloader...


 U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)

 OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
 OMAP3 Beagle Board + LPDDR/NAND
 DRAM:  128 MB
 NAND:

 Lei,

 Couldn't help noticing the version information for x-loader and
 u-boot. Both seem to be quite old...

 Could you try update both? May be, there is a dependency...

 I am seeing the same issue with console on UART3 on zoom3 board. The
 bootloaders are older. Can you please share a link to latest bootloader
 which will have zoom3 support.

 I am using L25_INC3.x android kernel. The board hangs as soon as it boots
 the kernel. Enabling the logs shows us that the hang occurs when UART3
 clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has
 anyone observed this issue on any of omap boards?

 ~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: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr

2010-10-04 Thread Sripathy, Vishwanath

Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Saturday, September 25, 2010 1:28 AM
 To: Sripathy, Vishwanath
 Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
 Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
 
 Vishwanath BS vishwanath...@ti.com writes:
 
  There is no need to keep omap3 sleep code in SRAM.
  This code can be run very well on DDR.
 
 /me remains skeptical
 
  This would help us to instrument CPUIdle latencies.
 
 Indeed, but...
 
 I'm afraid we will need a much more descriptive changelog here,
 describing in detail why this will still work, and what about the
 previous motiviations for running SRAM has changed such that this will
 work out of SRAM.
Running the code from SRAM for CPUIdle was more of legacy from OMAP2 and there 
was no technical reason why it cannot be run from DDR. Also note that, once MPU 
enters off mode, wake up code used to run from DDR earlier (w/o these changes) 
as well. I will put more details in the change log.
 
  Tested on ZOOM3.
 
 Tested in what way?  This path is used for both idle and suspend, and
 needs to be validated for retention and off mode.
I have tested for both retention and off mode in both CPU idle and suspend 
path. I will update the changelog in next version. 

Vishwa
 
 Kevin
 
  Signed-off-by: Vishwanath BS vishwanath...@ti.com
  Cc: Kevin Hillman khil...@deeprootsystems.com
  Cc: Linaro linaro-...@lists.linaro.org
  ---
   arch/arm/mach-omap2/pm34xx.c |9 +
   1 files changed, 1 insertions(+), 8 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
  index 85ef245..ed9d12c 100644
  --- a/arch/arm/mach-omap2/pm34xx.c
  +++ b/arch/arm/mach-omap2/pm34xx.c
  @@ -79,8 +79,6 @@ struct power_state {
 
   static LIST_HEAD(pwrst_list);
 
  -static void (*_omap_sram_idle)(u32 *addr, int save_state);
  -
   static int (*_omap_save_secure_sram)(u32 *addr);
 
   static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
  @@ -360,9 +358,6 @@ void omap_sram_idle(void)
  int core_prev_state, per_prev_state;
  u32 sdrc_pwr = 0;
 
  -   if (!_omap_sram_idle)
  -   return;
  -
  pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
  pwrdm_clear_all_prev_pwrst(neon_pwrdm);
  pwrdm_clear_all_prev_pwrst(core_pwrdm);
  @@ -438,7 +433,7 @@ void omap_sram_idle(void)
   * get saved. The restore path then reads from this
   * location and restores them back.
   */
  -   _omap_sram_idle(omap3_arm_context, save_state);
  +   omap34xx_cpu_suspend(omap3_arm_context, save_state);
  cpu_init();
 
  if (is_suspending())
  @@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain 
  *clkdm,
 void *unused)
 
   void omap_push_sram_idle(void)
   {
  -   _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
  -   omap34xx_cpu_suspend_sz);
  if (omap_type() != OMAP2_DEVICE_TYPE_GP)
  _omap_save_secure_sram =
 omap_sram_push(save_secure_ram_context,
  save_secure_ram_context_sz);
--
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 02/14] omap: Map only available sram memory

 -Original Message-
 From: Grazvydas Ignotas [mailto:nota...@gmail.com]
 Sent: Monday, October 04, 2010 2:34 PM
 To: Shilimkar, Santosh
 Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; Russell King - ARM Linux
 Subject: Re: [PATCH 02/14] omap: Map only available sram memory
 
  
   This hangs OMAP3 pandora:
  
   [    0.00] Linux version
   2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc
   version 4.3.3 (Sourcery G++ Lite 2009q1-20
   [    0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7),
  cr=10c53c7f
   [    0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing
   instruction cache
   [    0.00] Machine: Pandora Handheld Console
   [    0.00] Ignoring unrecognised tag 0x54410008
   [    0.00] bootconsole [earlycon0] enabled
   [    0.00] Reserving 6422528 bytes SDRAM for VRAM
   [    0.00] Memory policy: ECC disabled, Data cache writeback
   [    0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
   [    0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size:
 0x1
   (stuck here)
  
   reverting this fixes the problem.
 
  Hmm, boots fine here with overo. Any idea what in this patch breaks
  pandora?
 
  The change in this patch is not board dependent really. Have tested this
  on 3430SDP. Pandora is OMAP3 based, right ?
 
 OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and
 it has the same problem. Maybe it's because of older Cortex A8 used
 there, or I'm missing some errata workaround in defconfig.
 
 BTW, hacking the size to 1M on top of your patch fixes the problem too:
 
 base = omap_sram_start;
 base = ROUND_DOWN(base, PAGE_SIZE);
 omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
 -   omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size,
 PAGE_SIZE);
 +   omap_sram_io_desc[0].length = 0x10;
This is the exact reason this patch is created :)
So that you map only available memory instead of 1 MB
 iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
--
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 08/10] OMAP: split plat-omap/common.c


Hi Paul,

On 10/1/2010 11:35 PM, Paul Walmsley wrote:

Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
plat-omap/32ksynctimer.c;

2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;

3. and the remainder of the OMAP-wide common code, which includes the
deprecated ATAGs code and a deprecated video RAM reservation function.

The primary motivation for doing this is to move the OMAP2+-specific parts
into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.

Signed-off-by: Paul Walmsleyp...@pwsan.com
---


...


diff --git a/arch/arm/plat-omap/32ksynctimer.c 
b/arch/arm/plat-omap/32ksynctimer.c
new file mode 100644
index 000..b7f458c
--- /dev/null
+++ b/arch/arm/plat-omap/32ksynctimer.c
@@ -0,0 +1,184 @@
+/*
+ * linux/arch/arm/plat-omap/clocksource.c


What name do you want to use? 32ksynctimer.c or clocksource.c?

If this file is dedicated for the 32k sync timer, maybe we should now 
use the new OMAP4 name: counter_32k.


Noboby knows what the sync stand for, and at the end this is just a 32k 
counter. Hence the new name :-)


Benoit


+ *
+ * OMAP clocksource-related code
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Copyright (C) 2010 Nokia Corporation
+ * Tony Lindgrent...@atomide.com
+ * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com
+ * Paul Walmsley
+ *
+ * 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.
+ */
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/clk.h
+#includelinux/io.h
+
+#includeplat/common.h
+#includeplat/board.h
+
+#includeplat/clock.h
+
+
+/*
+ * 32KHz clocksource ... always available, on pretty most chips except
+ * OMAP 730 and 1510.  Other timers could be used as clocksources, with
+ * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
+ * but systems won't necessarily want to spend resources that way.
+ */
+
+#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
+
+#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
+
+#includelinux/clocksource.h
+
+/*
+ * offset_32k holds the init time counter value. It is then subtracted
+ * from every counter read to achieve a counter that counts time from the
+ * kernel boot (needed for sched_clock()).
+ */
+static u32 offset_32k __read_mostly;
+
+#ifdef CONFIG_ARCH_OMAP16XX
+static cycle_t omap16xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k;
+}
+#else
+#define omap16xx_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2420
+static cycle_t omap2420_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap2420_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static cycle_t omap2430_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap2430_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+static cycle_t omap34xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap34xx_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+static cycle_t omap44xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap44xx_32k_read  NULL
+#endif
+
+/*
+ * Kernel assumes that sched_clock can be called early but may not have
+ * things ready yet.
+ */
+static cycle_t omap_32k_read_dummy(struct clocksource *cs)
+{
+   return 0;
+}
+
+static struct clocksource clocksource_32k = {
+   .name   = 32k_counter,
+   .rating = 250,
+   .read   = omap_32k_read_dummy,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .shift  = 10,
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+/*
+ * Returns current time from boot in nsecs. It's OK for this to wrap
+ * around for now, as it's just a relative time stamp.
+ */
+unsigned long long sched_clock(void)
+{
+   return clocksource_cyc2ns(clocksource_32k.read(clocksource_32k),
+ clocksource_32k.mult, clocksource_32k.shift);
+}
+
+/**
+ * read_persistent_clock -  Return time from a persistent clock.
+ *
+ * Reads the time from a source which isn't disabled during PM, the
+ * 32k sync timer.  Convert the cycles elapsed since last read into
+ * nsecs and adds to a monotonically increasing timespec.
+ */
+static struct timespec persistent_ts;
+static cycles_t cycles, last_cycles;
+void read_persistent_clock(struct timespec *ts)
+{
+   unsigned long long nsecs;
+   cycles_t delta;
+   struct timespec *tsp =persistent_ts;
+
+   last_cycles = cycles;
+   cycles =

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote:
 
 2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is
 not used with TI internal trees.
 
  We experimented that also on 2420 and it seemed to help but since the
  lockup was unrecovable I went thinking if 2420 has also another issue
  what original
  workaround was trying to fix and buffering disable was needed there.
 
 I don't have any data for 2420. Based on your observation, it is better
 to disable buffering for 2420.

Does the same errata number applies to OMAP2 and OMAP3 as well?
For OMAP3 the errata number is i541, but I do not know the iXYZ number for 
OMAP2 
class.

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

RE: [PATCH 01/10] OMAP2+: Kconfig: disallow builds for boards that don't use the currently-selected SoC

2010-10-04 Thread Paul Walmsley

On Mon, 4 Oct 2010, Varadarajan, Charulatha wrote:

  
 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley
  Sent: Saturday, October 02, 2010 3:05 AM
  To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
  Cc: Tony Lindgren
  Subject: [PATCH 01/10] OMAP2+: Kconfig: disallow builds for 
  boards that don't use the currently-selected SoC

...

  +++ b/arch/arm/mach-omap2/board-generic.c
  @@ -48,10 +48,22 @@ static void __init omap_generic_init(void)
   
   static void __init omap_generic_map_io(void)
   {
  -   omap2_set_globals_242x(); /* should be 242x, 243x, or 343x */
  -   omap242x_map_common_io();
  +   if (cpu_is_omap242x()) {
  +   omap2_set_globals_242x();
  +   omap242x_map_common_io();
  +   } else if (cpu_is_omap242x()) {
 
 Is this intended for 242x() or 243x()?
 
  +   omap2_set_globals_243x();
  +   omap243x_map_common_io();

That's for 243x().  Thanks, updated that in the branch that's posted on 
git.pwsan.com.


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

RE: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

 -Original Message-
 From: Jarkko Nikula [mailto:jhnik...@gmail.com] 
 Sent: Monday, October 04, 2010 11:13 AM
 To: G, Manjunath Kondaiah
 Cc: Peter Ujfalusi; Tony Lindgren; 
 linux-omap@vger.kernel.org; Liam Girdwood
 Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
 bit setting for omap24xx

 On Sat, 2 Oct 2010 10:12:50 +0530
 G, Manjunath Kondaiah manj...@ti.com wrote:

   --- a/arch/arm/plat-omap/dma.c
   +++ b/arch/arm/plat-omap/dma.c
   @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
  * This will always fail on ES1.0
  */
 if (cpu_is_omap24xx())
   - l |= OMAP_DMA_CCR_EN;
   + l |= OMAP_DMA_CCR_BUFFERING_DISABLE;

  This issue is applicable only for 2430ES1.0(not sure about 
 2420) and 
  it got fixed with later ES versions.
  cpu check should be replaced with:

  if (cpu_is_omap2420() || (cpu_is_omap2430()  (omap_type() == 
  OMAP2430_REV_ES1_0)))

 Ok, thanks for your info, I'll change this.

 How about later versions of 2430?
Fixed in later versions ES2.0 and ES2.1

 Should they use the workaround in Patch 2/2? 
2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is not 
used with TI internal trees.

 We experimented that also on 2420 and it seemed to help but since the lockup 
 was unrecovable I 
 went thinking if 2420 has also another issue what original 
 workaround was trying to fix and buffering disable was needed there.
I don't have any data for 2420. Based on your observation, it is better
to disable buffering for 2420.

-Manjunath--
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 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] 
 Sent: Monday, October 04, 2010 11:45 AM
 To: G, Manjunath Kondaiah
 Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; 
 Liam Girdwood
 Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
 bit setting for omap24xx

 On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote:

  2/2 is applicable for all omap2plus except omap4. So far 2/2 
  workaround is not used with TI internal trees.

   We experimented that also on 2420 and it seemed to help but since 
   the lockup was unrecovable I went thinking if 2420 has 
 also another 
   issue what original workaround was trying to fix and buffering 
   disable was needed there.

  I don't have any data for 2420. Based on your observation, it is 
  better to disable buffering for 2420.

 Does the same errata number applies to OMAP2 and OMAP3 as well?
No errata numbers numbers used with TI errata documents till omap2430.
Errata numbers avaialable from omap3430 onwards.

 For OMAP3 the errata number is i541, but I do not know the 
 iXYZ number for OMAP2 class.

Being said that no errata numbers for omap2 class, it's ok to use
omap3 errata numbers for common errata(like your patch 2/2)

-Manjunath

--
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 08/10] OMAP: split plat-omap/common.c


Hi Tarun,

On 10/4/2010 11:35 AM, DebBarma, Tarun Kanti wrote:



-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Monday, October 04, 2010 2:39 PM
To: Paul Walmsley
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c

Hi Paul,

On 10/1/2010 11:35 PM, Paul Walmsley wrote:

Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
 plat-omap/32ksynctimer.c;

2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;

3. and the remainder of the OMAP-wide common code, which includes the
 deprecated ATAGs code and a deprecated video RAM reservation

function.


The primary motivation for doing this is to move the OMAP2+-specific

parts

into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.

Signed-off-by: Paul Walmsleyp...@pwsan.com
---


...


diff --git a/arch/arm/plat-omap/32ksynctimer.c b/arch/arm/plat-

omap/32ksynctimer.c

new file mode 100644
index 000..b7f458c
--- /dev/null
+++ b/arch/arm/plat-omap/32ksynctimer.c
@@ -0,0 +1,184 @@
+/*
+ * linux/arch/arm/plat-omap/clocksource.c


What name do you want to use? 32ksynctimer.c or clocksource.c?

If this file is dedicated for the 32k sync timer, maybe we should now
use the new OMAP4 name: counter_32k.

Noboby knows what the sync stand for, and at the end this is just a 32k
counter. Hence the new name :-)

One of the points to be kept in mind while naming is that we are able to relate 
our driver easily to the hardware device. In this regard the TRM terms this 
module as 32-kHz Synchronized Timer. Therefore we should be careful in our 
naming. With regard to the meaning of the word here is the extract from the TRM.


The TRM will have to be fixed anyway to stick to the new convention.
We are just anticipating in order to avoid changing that again for the 
next revision.




OMAP4430 ES2.0 TRM
...
The sync logic ensures the read transaction correctness by synchronizing the 
counter register read access on 32KSYNCNT_ICLK because the 32KSYNCNT_ICLK clock 
signal is completely asynchronous with S32KSYNCNT_FCLK.


Thanks, but if this is where the sync came from, then this is the case 
for all modules with a very slow functional clock or even as soon as the 
fclk is not derived from its iclk.

This is not a functionality, it is just how it should be implemented.

Regards,
Benoit


...



Benoit


+ *
+ * OMAP clocksource-related code
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Copyright (C) 2010 Nokia Corporation
+ * Tony Lindgrent...@atomide.com
+ * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com
+ * Paul Walmsley
+ *
+ * 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.
+ */
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/clk.h
+#includelinux/io.h
+
+#includeplat/common.h
+#includeplat/board.h
+
+#includeplat/clock.h
+
+
+/*
+ * 32KHz clocksource ... always available, on pretty most chips except
+ * OMAP 730 and 1510.  Other timers could be used as clocksources, with
+ * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
+ * but systems won't necessarily want to spend resources that way.
+ */
+
+#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
+
+#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
+
+#includelinux/clocksource.h
+
+/*
+ * offset_32k holds the init time counter value. It is then subtracted
+ * from every counter read to achieve a counter that counts time from

the

+ * kernel boot (needed for sched_clock()).
+ */
+static u32 offset_32k __read_mostly;
+
+#ifdef CONFIG_ARCH_OMAP16XX
+static cycle_t omap16xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k;
+}
+#else
+#define omap16xx_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2420
+static cycle_t omap2420_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap2420_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static cycle_t omap2430_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap2430_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+static cycle_t omap34xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap34xx_32k_read  NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+static cycle_t omap44xx_32k_read(struct clocksource *cs)
+{
+   return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k;
+}
+#else
+#define omap44xx_32k_read  NULL
+#endif
+
+/*
+ *

[PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.

The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat  /dev/null  \
dd if=/dev/urandom of=/dev/null

or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 1 -F 5000 -f dat  /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...

In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).

The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.

Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by : Santosh Shilimkar santosh.shilim...@ti.com
Acked-by : G, Manjunath Kondaiah manj...@ti.com
---
 arch/arm/plat-omap/dma.c  |   42 +++-
 arch/arm/plat-omap/include/plat/dma.h |3 ++
 2 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c116c41..a102cf5 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -30,6 +30,7 @@
 #include linux/irq.h
 #include linux/io.h
 #include linux/slab.h
+#include linux/delay.h
 
 #include asm/system.h
 #include mach/hardware.h
@@ -148,6 +149,8 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = 
{
 
 /* Errata handling */
 #define DMA_ERRATA_IFRAME_BUFFERING(1  0)
+/* OMAP3 Errata i541: sDMA FIFO draining does not finish */
+#define DMA_ERRATA_i541(1  1)
 static u16 dma_errata;
 #define IS_DMA_ERRATA(id)  (dma_errata  (id))
 
@@ -1023,8 +1026,40 @@ void omap_stop_dma(int lch)
dma_write(0, CICR(lch));
 
l = dma_read(CCR(lch));
-   l = ~OMAP_DMA_CCR_EN;
-   dma_write(l, CCR(lch));
+   /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
+   if (IS_DMA_ERRATA(DMA_ERRATA_i541) 
+   (l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+   int i = 0;
+   u32 sys_cf;
+
+   /* Configure No-Standby */
+   l = dma_read(OCP_SYSCONFIG);
+   sys_cf = l;
+   l = ~DMA_SYSCONFIG_MIDLEMODE_MASK;
+   l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
+   dma_write(l , OCP_SYSCONFIG);
+
+   l = dma_read(CCR(lch));
+   l = ~OMAP_DMA_CCR_EN;
+   dma_write(l, CCR(lch));
+
+   /* Wait for sDMA FIFO drain */
+   l = dma_read(CCR(lch));
+   while (i  100  (l  (OMAP_DMA_CCR_RD_ACTIVE |
+   OMAP_DMA_CCR_WR_ACTIVE))) {
+   udelay(5);
+   i++;
+   l = dma_read(CCR(lch));
+   }
+   if (i = 100)
+   printk(KERN_ERR DMA drain did not complete on 
+   lch %d\n, lch);
+   /* Restore OCP_SYSCONFIG */
+   dma_write(sys_cf, OCP_SYSCONFIG);
+   } else {
+   l = ~OMAP_DMA_CCR_EN;
+   dma_write(l, CCR(lch));
+   }
 
if (!omap_dma_in_1510_mode()  dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
@@ -2051,6 +2086,9 @@ static void dma_errata_configure(void)
if (cpu_is_omap2420() ||
(cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
dma_errata |= DMA_ERRATA_IFRAME_BUFFERING;
+
+   if (cpu_is_omap34xx())
+   dma_errata |= DMA_ERRATA_i541;
 }
 
 static int __init omap_init_dma(void)
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index 776ba44..cf66f85 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -335,6 +335,9 @@
 #define OMAP2_DMA_MISALIGNED_ERR_IRQ   (1  11)
 
 #define OMAP_DMA_CCR_EN(1  7)
+#define OMAP_DMA_CCR_RD_ACTIVE (1  9)
+#define OMAP_DMA_CCR_WR_ACTIVE (1  10)
+#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC  (1  24)
 #define OMAP_DMA_CCR_BUFFERING_DISABLE (1  25)
 
 #define OMAP_DMA_DATA_TYPE_S8  0x00
-- 
1.7.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in

RE: [PATCH 08/10] OMAP: split plat-omap/common.c

Felipe,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Paul Walmsley
 Sent: Saturday, October 02, 2010 3:06 AM
 To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: [PATCH 08/10] OMAP: split plat-omap/common.c

 Split plat-omap/common.c into three pieces:

 1. the 32KiHz sync timer and clocksource code, which now lives in
plat-omap/32ksynctimer.c;

I remember you have converted the 32k sync time code to a platform driver.
That was also addressing the multi-omap build and was removing all
the compile time switches.
Do you plan to rebase it and post it again ?

 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;

 3. and the remainder of the OMAP-wide common code, which includes the
deprecated ATAGs code and a deprecated video RAM reservation function.

 The primary motivation for doing this is to move the OMAP2+-specific parts
 into an OMAP2+-specific file, so that build breakage related to the
 System Control Module code can be resolved.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/mach-omap2/Makefile  |3
  arch/arm/mach-omap2/common.c  |  138 ++
  arch/arm/plat-omap/32ksynctimer.c |  184 +++
  arch/arm/plat-omap/Makefile   |2
  arch/arm/plat-omap/common.c   |  291 
 -
  arch/arm/plat-omap/devices.c  |1
  arch/arm/plat-omap/sram.c |3
  7 files changed, 325 insertions(+), 297 deletions(-)
  create mode 100644 arch/arm/mach-omap2/common.c
  create mode 100644 arch/arm/plat-omap/32ksynctimer.c

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 9edacb0..d543533 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -3,7 +3,8 @@
  #

  # Common support
 -obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
 pm.o
 +obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
 pm.o \
 +  common.o

  omap-2-3-common  = irq.o sdrc.o prm2xxx_3xxx.o
  hwmod-common = omap_hwmod.o \
 diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
 new file mode 100644
 index 000..4e0469d
 --- /dev/null
 +++ b/arch/arm/mach-omap2/common.c
 @@ -0,0 +1,138 @@
 +/*
 + * linux/arch/arm/mach-omap2/common.c
 + *
 + * Code common to all OMAP2+ machines.
 + *
 + * Copyright (C) 2009 Texas Instruments
 + * Copyright (C) 2010 Nokia Corporation
 + * Tony Lindgren t...@atomide.com
 + * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
 + * Paul Walmsley
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +#include linux/kernel.h
 +#include linux/init.h
 +#include linux/clk.h
 +#include linux/io.h
 +
 +#include plat/common.h
 +#include plat/board.h
 +#include plat/control.h
 +#include plat/mux.h
 +
 +#include plat/clock.h
 +
 +#include sdrc.h
 +
 +/* Global address base setup code */
 +
 +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
 +
 +static void __init __omap2_set_globals(struct omap_globals
 *omap2_globals)
 +{
 + omap2_set_globals_tap(omap2_globals);
 + omap2_set_globals_sdrc(omap2_globals);
 + omap2_set_globals_control(omap2_globals);
 + omap2_set_globals_prcm(omap2_globals);
 + omap2_set_globals_uart(omap2_globals);
 +}
 +
 +#endif
 +
 +#if defined(CONFIG_ARCH_OMAP2420)
 +
 +static struct omap_globals omap242x_globals = {
 + .class  = OMAP242X_CLASS,
 + .tap= OMAP2_L4_IO_ADDRESS(0x48014000),
 + .sdrc   = OMAP2420_SDRC_BASE,
 + .sms= OMAP2420_SMS_BASE,
 + .ctrl   = OMAP242X_CTRL_BASE,
 + .prm= OMAP2420_PRM_BASE,
 + .cm = OMAP2420_CM_BASE,
 + .uart1_phys = OMAP2_UART1_BASE,
 + .uart2_phys = OMAP2_UART2_BASE,
 + .uart3_phys = OMAP2_UART3_BASE,
 +};
 +
 +void __init omap2_set_globals_242x(void)
 +{
 + __omap2_set_globals(omap242x_globals);
 +}
 +#endif
 +
 +#if defined(CONFIG_ARCH_OMAP2430)
 +
 +static struct omap_globals omap243x_globals = {
 + .class  = OMAP243X_CLASS,
 + .tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
 + .sdrc   = OMAP243X_SDRC_BASE,
 + .sms= OMAP243X_SMS_BASE,
 + .ctrl   = OMAP243X_CTRL_BASE,
 + .prm= OMAP2430_PRM_BASE,
 + .cm = OMAP2430_CM_BASE,
 + .uart1_phys = OMAP2_UART1_BASE,
 + .uart2_phys = OMAP2_UART2_BASE,
 + .uart3_phys = OMAP2_UART3_BASE,
 +};
 +
 +void __init omap2_set_globals_243x(void)
 +{
 + __omap2_set_globals(omap243x_globals);
 +}
 +#endif
 +
 +#if defined(CONFIG_ARCH_OMAP3)
 +
 +static struct omap_globals omap3_globals = {
 + .class  = OMAP343X_CLASS,
 + .tap= OMAP2_L4_IO_ADDRESS(0x4830A000),
 + .sdrc   =

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

2010-10-04 Thread Jarkko Nikula

On Sat, 2 Oct 2010 10:12:50 +0530
G, Manjunath Kondaiah manj...@ti.com wrote:

  --- a/arch/arm/plat-omap/dma.c
  +++ b/arch/arm/plat-omap/dma.c
  @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
   * This will always fail on ES1.0
   */
  if (cpu_is_omap24xx())
  -   l |= OMAP_DMA_CCR_EN;
  +   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
 This issue is applicable only for 2430ES1.0(not sure about 2420)
 and it got fixed with later ES versions. 
 cpu check should be replaced with:
 
 if (cpu_is_omap2420() || (cpu_is_omap2430()  (omap_type() == 
 OMAP2430_REV_ES1_0)))
 
Ok, thanks for your info, I'll change this.

How about later versions of 2430? Should they use the workaround in
Patch 2/2? We experimented that also on 2420 and it seemed to help but
since the lockup was unrecovable I went thinking if 2420 has also
another issue what original workaround was trying to fix and buffering
disable was needed there.


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

Re: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-omap


On 9/21/2010 10:56 AM, DebBarma, Tarun Kanti wrote:

This patch removes the ocp config code from omap-plat
because they are supposed to be taken care of by the
hwmod framework. Specifically, following changes are
incorporated:
(1) setting of smart-idle and wakeup-enable is already
taken care in existing code and so they are simply removed
from plat-omap
(2) clockactivity configuration is not present in the present
hwmod database. Therefore this filed is initialized to '1' in


Typo.


respective database.


Could you explain why, the default setting is not working for the timers?



Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
Signed-off-by: Partha Basakp-bas...@ti.com
Cc: Cousson, Benoitb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Tony Lindgrent...@atomide.com
---
  arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
  arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
  arch/arm/plat-omap/dmtimer.c   |   11 ---
  5 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index fc761a5..25111bf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -168,6 +168,7 @@ static struct omap_hwmod_class_sysconfig 
omap2420_timer_sysc = {
   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
   SYSC_HAS_AUTOIDLE),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .clockact   = 1, /* preserve fclk on idle */


In theory, this field is useless unless you add a flag: 
SYSC_HAS_CLOCKACTIVITY.


So how is it working in your case?



.sysc_fields=omap_hwmod_sysc_type1,
  };

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 2ac463f..93d5c3d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -174,6 +174,7 @@ static struct omap_hwmod_class_sysconfig 
omap2430_timer_sysc = {
   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
   SYSC_HAS_AUTOIDLE),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .clockact   = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
  };

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1ce40e0..c64c95b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -147,6 +147,7 @@ static struct omap_hwmod_class_sysconfig 
omap3xxx_timer_1ms_sysc = {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .clockact   = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
  };

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9edc518..a816d30 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -538,6 +538,7 @@ static struct omap_hwmod_class_sysconfig 
omap44xx_timer_1ms_sysc = {
   SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
   SYSS_MISSING),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .clockact   = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
  };

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7d57605..6211501 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -157,17 +157,6 @@ static void omap_dm_timer_reset(struct omap_dm_timer 
*timer)
}
omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);

-   l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
-   l |= 0x02  3;  /* Set to smart-idle mode */
-   l |= 0x2  8;   /* Set clock activity to perserve f-clock on idle */


It used to be 0x2 and now you put 1:
.clockact   = 1, /* preserve fclk on idle */

I do not understand how that patch can work???

Benoit


-
-   /*
-* Enable wake-up on OMAP2 CPUs.
-*/
-   if (cpu_class_is_omap2())
-   l |= 1  2;
-   omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
-
/* Match hardware reset default of posted mode */
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG,
OMAP_TIMER_CTRL_POSTED);


--
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/3 v5] musb: add musb support for AM35x


On Fri, Oct 01, 2010 at 01:48:57AM -0500, Balbi, Felipe wrote:

On Fri, Oct 01, 2010 at 01:33:49AM -0500, Gupta, Ajay Kumar wrote:

Hi,
[...]

I couldn't fetch your gitorious tree so I just applied 14 patch set
Manually on my branch.

Anyways I will look into it and send the refreshed patch shortly.

gitorious must be trying to make me look bad :-p

Works like a charm here. Will try on a different laptop

fine on another laptop too. Maybe you need to check your .git/config

the correct address is git://gitorious.org/usb/usb.git


I am using same address (http one) but fetch always fails while getting
Index pack,
484a70e99b430800a9d93198bae32df155aecfc9


try to get it via git instead of http.


seems like our servers converted TABs into spaces. Would you send
(privately, even) a tarball with all the patches ??

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

Re: [PATCH v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx

2010-10-04 Thread Jarkko Nikula

On Mon, 4 Oct 2010 14:44:28 +0530
G, Manjunath Kondaiah manj...@ti.com wrote:

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi
  Sent: Monday, October 04, 2010 1:48 PM
  To: Tony Lindgren
  Cc: linux-omap@vger.kernel.org; Jarkko Nikula; 
  linux-arm-ker...@lists.infradead.org
  Subject: [PATCH v4 1/4] omap: dma: Fix buffering disable bit 
  setting for omap24xx

  From: ext Jarkko Nikula jhnik...@gmail.com

  An errata workaround for omap24xx is not setting the 
  buffering disable bit
  25 what is the purpose but channel enable bit 7 instead.

 ...

  diff --git a/arch/arm/plat-omap/dma.c 
  b/arch/arm/plat-omap/dma.c index ec7eddf..6914ccf 100644
  --- a/arch/arm/plat-omap/dma.c
  +++ b/arch/arm/plat-omap/dma.c
  @@ -999,8 +999,9 @@ void omap_start_dma(int lch)
   * Errata: On ES2.0 BUFFERING disable must be set.
   * This will always fail on ES1.0
   */

 Sorry, I didn't catch this with earlier patch.

 Looks like wrong comment. only on 2430ES1.0 and for all omap2420, 
 buffer disable should be set. 
 I feel below description will be useful to the reader:
 Errata: Inter Frame DMA buffering issue(All OMAP2420 and OMAP2430ES1.0):
 DMA will wrongly buffer elements if packing and bursting is enabled.
 This might result in data gets stalled in FIFO at the end of the block.
 Workaround: DMA channels must have BUFFERING_DISABLED bit set to guarantee
 no data will stay in the DMA FIFO in case inter frame buffering occurs.

Ok, no problem. I'll add this to the next version. This is good to get
documented.

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

[PATCH] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset

2010-10-04 Thread Vishwanath BS

This patch adds comments on precatution to be taken if Global SW reset is
used as the means to trigger sysem reset.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/prcm.c |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index c201374..fdc860e
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -157,6 +157,32 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
else
WARN_ON(1);
 
+   /* As per Errata i520, In some cases, user
+* will not be able to access DDR memory after warm-reset.
+* This situation occurs while the warm-reset happens during a read
+* access to DDR memory. In that particular condition, DDR memory
+* does not respond to a corrupted read command due to the warm
+* reset occurence but SDRC is waiting for read completion.
+* SDRC is not sensitive to the warm reset, but the interconect is
+* reset on the fly, thus causing a misalignment between SDRC logic,
+* interconect logic and DDR memory state.
+* WORKAROUND:
+* Steps to perform before a Warm reset is trigged:
+* 1. enable self-refresh on idle request
+* 2. put SDRC in idle
+* 3. wait until SDRC goes to idle
+* 4. generate SW reset (Global SW reset)
+
+* Steps to be performed after warm reset occurs (in bootloader):
+* if HW warm reset is the source, apply below steps before any
+* accesses to SDRAM:
+* 1. Reset SMS and SDRC and wait till reset is complete
+* 2. Re-initialize SMS, SDRC and memory
+
+* NOTE: Above work around is required only if arch reset is implemented
+* using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need
+* the WA since it resets SDRC as well as part of cold reset. */
+
if (cpu_is_omap24xx() || cpu_is_omap34xx())
prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
 OMAP2_RM_RSTCTRL);
-- 
1.7.0.4

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

Re: [PATCH] omap: devices: Avoid merge conflict between ASoC and OMAP hwmod changes

2010-10-04 Thread Mark Brown

On Mon, Oct 04, 2010 at 03:04:53PM +0300, Jarkko Nikula wrote:
 Upcoming ASoC multi-component and OMAP hwmod changes will conflict
 in arch/arm/mach-omap2/devices.c. Avoid this by moving a little bit
 include statement introduced by ASoC Multi-Component Support patch.

 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Tony Lindgren t...@atomide.com

Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOTE: hwmod changes merged to linux-omap master for testing

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

 Hi Tony,
 With latest merges on master branch with commit ID:
 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build 
 after merging in hwmod support for testing

 Booting with zoom3 seems to be fine but observed issues with omap4 blaze 
 board. 

 Looks like multiple warning dumps and finally it crashes after Freeing init 
 memory with both NFS and ramdisk file systems.

 The complete bootlogs are available at:
 NFS bootlog:
 http://pastebin.com/nrWQ5FGG

In the future, it helps greatly if you state what defconfig you're
using, and specifically what you've changed from the default defconfig.

Looking at this log, you've enabled CPUidle in your config, which is not
(yet) supported for OMAP4 in mainline.

Kevin

 Ramdisk bootlog:
 http://pastebin.com/1F75d2Ew

 -Manjunath 

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Saturday, October 02, 2010 6:18 AM
 To: linux-omap@vger.kernel.org
 Subject: NOTE: hwmod changes merged to linux-omap master for testing
 
 Hi all,
 
 So I've finally merged Kevin's hwmod branch into the 
 linux-omap master so we can give it some testing to see if we 
 can merge it to the mainline. Might take few minutes to hit 
 the mirrors.
 
 Please note that for omap2plus machines you need to change:
 
 - u-boot bootargs for kernel cmdline needs to change with setenv
 - if you use hardcoded CONFIG_CMDLINE, change it in your .config
 - /etc/inittab in your omap root file system if using serial console
 
 This is because otherwise the serial-omap would be 
 conflicting with the 8250 driver. This should not affect 
 omap1 machines.
 
 Please give it a try and report any issues on this list! Now 
 all the machines except ams_delta_defconfig should build.
 That one is still missing some camera driver changes to build.
 
 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
 --
 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: beagle hangs in uart3 disabling clocks

2010-10-04 Thread Ming Lei

2010/10/4 Govindraj govindraj...@gmail.com:
 I tried now on zoom3 with uart3[ttyO2] as console

 It boots up fine for me

 Logs:

 http://pastebin.com/sXR5nYcD

 I am using omap2plus_defconfig and lo-master

 commit 0882b1455797b0a104978000a622c3f2412e7cf5
 Author: Tony Lindgren t...@atomide.com
 Date:   Fri Oct 1 17:23:48 2010 -0700

    omap: READ CAREFULLY: Fix build after merging in hwmod support for testing

Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could you
try the pm branch of the tree?


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

PATCH [0/4] perf: clean-up of power events API

Here is a re-spin of the patches after discussion.
It includes:
- clean-up of the API,
- a deprecation process for backward compatibility,
- support for x86 and OMAP processors,
- support for the following tracepoints: cpuidle, cpufreq,
   system suspend, clocks  power domains

ToDO:
- documentation of the new API (once the code is agreed on),
- cpu idle latency tracing not included


  [PATCH 1/4] perf: cleanup power events API
  [PATCH 2/4] perf: add OMAP support for the new power events
  [PATCH 3/4] perf: add calls to suspend trace point
  [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] perf: cleanup power events API

From: Thomas Renninger tr...@suse.de

New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend

C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:processor_idle

and
  power:power_frequency
is replaced with:
  power:processor_frequency

power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.

Signed-off-by: Thomas Renninger tr...@suse.de
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Peter Zijlstra pet...@infradead.org
CC: Ingo Molnar mi...@elte.hu
CC: linux-perf-us...@vger.kernel.org
CC: linux-trace-us...@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Steven Rostedt rost...@goodmis.org
CC: Frank Eigler f...@redhat.com
CC: Rafael Wysocki r...@sisk.pl
---
 arch/x86/kernel/process.c|8 ++---
 arch/x86/kernel/process_32.c |2 +-
 arch/x86/kernel/process_64.c |2 +-
 drivers/cpufreq/cpufreq.c|2 +-
 drivers/cpuidle/cpuidle.c|2 +-
 drivers/idle/intel_idle.c|6 ++--
 include/trace/events/power.h |   69 ++
 kernel/trace/power-traces.c  |3 +-
 8 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e8a5ad1..284df73 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -372,7 +372,7 @@ static inline int hlt_use_halt(void)
 void default_idle(void)
 {
if (hlt_use_halt()) {
-   trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
current_thread_info()-status = ~TS_POLLING;
/*
 * TS_POLLING-cleared state must be visible before we
@@ -442,7 +442,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
  */
 void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
 {
-   trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id());
+   trace_processor_idle((ax4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -458,7 +458,7 @@ void mwait_idle_with_hints(unsigned long ax, unsigned long 
cx)
 static void mwait_idle(void)
 {
if (!need_resched()) {
-   trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
 
@@ -479,11 +479,9 @@ static void mwait_idle(void)
  */
 static void poll_idle(void)
 {
-   trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
 }
 
 /*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 96586c3..8dee35c 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -114,7 +114,7 @@ void cpu_idle(void)
pm_idle();
start_critical_timings();
 
-   trace_power_end(smp_processor_id());
+   trace_processor_idle(0, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index b3d7a3a..d30069a 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -141,7 +141,7 @@ void cpu_idle(void)
pm_idle();
start_critical_timings();
 
-   trace_power_end(smp_processor_id());
+   trace_processor_idle(0, smp_processor_id());
 
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..8c0dbe6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -354,7 +354,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, 
unsigned int state)
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
dprintk(FREQ: %lu - CPU: %lu, (unsigned long)freqs-new,
(unsigned long)freqs-cpu);
-   trace_power_frequency(POWER_PSTATE, freqs-new, freqs-cpu);
+   trace_processor_frequency(freqs-new, freqs-cpu);

[PATCH 2/4] perf: add OMAP support for the new power events

The patch adds the new power management trace points for
the OMAP architecture.

The trace points are for cpuidle, cpufreq (DVFS), the clocks
changes (enable, disable, set_rate) and the power domains
transitions.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/cpuidle34xx.c |3 +++
 arch/arm/mach-omap2/pm34xx.c  |5 +
 arch/arm/mach-omap2/powerdomain.c |3 +++
 arch/arm/plat-omap/clock.c|   13 ++---
 arch/arm/plat-omap/cpu-omap.c |2 ++
 5 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..96a6f38 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -24,6 +24,7 @@
 
 #include linux/sched.h
 #include linux/cpuidle.h
+#include trace/events/power.h
 
 #include plat/prcm.h
 #include plat/irqs.h
@@ -130,6 +131,8 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
 
+   trace_processor_idle(cx-type, smp_processor_id());
+
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
 
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7b03426..4b5383f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
 #include linux/clk.h
 #include linux/delay.h
 #include linux/slab.h
+#include trace/events/power.h
 
 #include plat/sram.h
 #include plat/clockdomain.h
@@ -557,6 +558,8 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
 
+   trace_processor_idle(1, smp_processor_id());
+
omap_sram_idle();
 
 out:
@@ -623,6 +626,8 @@ restore:
printk(KERN_INFO Powerdomain (%s) didn't enter 
   target state %d\n,
   pwrst-pwrdm-name, pwrst-next_state);
+   trace_power_domain_missed(pwrst-pwrdm-name,
+ state, smp_processor_id());
ret = -1;
}
set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 6527ec3..73cbe9a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -23,6 +23,7 @@
 #include linux/errno.h
 #include linux/err.h
 #include linux/io.h
+#include trace/events/power.h
 
 #include asm/atomic.h
 
@@ -440,6 +441,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
 pwrdm-name, pwrst);
 
+   trace_power_domain_target(pwrdm-name, pwrst, smp_processor_id());
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
 (pwrst  OMAP_POWERSTATE_SHIFT),
 pwrdm-prcm_offs, pwrstctrl_reg_offs);
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 7190cbd..d6518f5 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -21,6 +21,7 @@
 #include linux/cpufreq.h
 #include linux/debugfs.h
 #include linux/io.h
+#include trace/events/power.h
 
 #include plat/clock.h
 
@@ -43,8 +44,10 @@ int clk_enable(struct clk *clk)
return -EINVAL;
 
spin_lock_irqsave(clockfw_lock, flags);
-   if (arch_clock-clk_enable)
+   if (arch_clock-clk_enable) {
+   trace_clock_enable(clk-name, 1, smp_processor_id());
ret = arch_clock-clk_enable(clk);
+   }
spin_unlock_irqrestore(clockfw_lock, flags);
 
return ret;
@@ -66,8 +69,10 @@ void clk_disable(struct clk *clk)
goto out;
}
 
-   if (arch_clock-clk_disable)
+   if (arch_clock-clk_disable) {
+   trace_clock_disable(clk-name, 0, smp_processor_id());
arch_clock-clk_disable(clk);
+   }
 
 out:
spin_unlock_irqrestore(clockfw_lock, flags);
@@ -120,8 +125,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
return ret;
 
spin_lock_irqsave(clockfw_lock, flags);
-   if (arch_clock-clk_set_rate)
+   if (arch_clock-clk_set_rate) {
+   trace_clock_set_rate(clk-name, rate, smp_processor_id());
ret = arch_clock-clk_set_rate(clk, rate);
+   }
if (ret == 0) {
if (clk-recalc)
clk-rate = clk-recalc(clk);
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 6d3d333..19d5a6c 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -21,6 +21,7 @@
 #include linux/err.h
 #include linux/clk.h
 #include linux/io.h
+#include trace/events/power.h
 
 #include mach/hardware.h
 #include plat/clock.h
@@ -95,6 +96,7 @@ static int omap_target(struct cpufreq_policy *policy,

[PATCH 3/4] perf: add calls to suspend trace point

Uses the machine_suspend trace point, from the
generic kernel suspend_enter function.

Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
 kernel/power/suspend.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7335952..10cad5c 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
 #include linux/mm.h
 #include linux/slab.h
 #include linux/suspend.h
+#include trace/events/power.h
 
 #include power.h
 
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE)  pm_check_wakeup_events()) {
+   trace_machine_suspend(state);
error = suspend_ops-enter(state);
+   trace_machine_suspend(0);
events_check_enabled = false;
}
sysdev_resume();
-- 
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 4/4] perf: provide a DEPRECTAED power trace API to user space

Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING  option in order
to provide backward compatibility with the user space tracing tools.

To be removed as soon as the tools are in sync with the new API.
Note: only the old events are mapped to.

Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
 include/trace/events/power.h |   98 ++
 kernel/trace/Kconfig |4 ++
 kernel/trace/power-traces.c  |4 ++
 3 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 00bf175..dd00512 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -7,6 +7,103 @@
 #include linux/ktime.h
 #include linux/tracepoint.h
 
+
+#ifdef CONFIG_DEPRECATED_POWER_EVENT_TRACING
+/*
+ * Keep the old power API for user space tools backward compatibility.
+ * To be removed as soon as the tools are in sync with the new API.
+ *
+ * Note: only the old events are mapped to.
+ *
+ * The mapping is as follows:
+ *  - trace_processor_idle(state != 0, cpu_id) =
+ * trace_power_start(POWER_CSTATE, state, cpu_id)
+ *  - trace_processor_idle(state == 0, cpu_id) =
+ * trace_power_end(cpu_id)
+ *  - trace_processor_frequency(frequency, cpu_id) =
+ * trace_power_frequency(POWER_PSTATE, frequency, cpu_id)
+ *
+ */
+
+/* Define old API events */
+#ifndef _TRACE_POWER_OLD_API_
+#define _TRACE_POWER_OLD_API_
+enum {
+   POWER_NONE = 0,
+   POWER_CSTATE = 1,
+   POWER_PSTATE = 2,
+};
+#endif /* _TRACE_POWER_OLD_API_ */
+
+DECLARE_EVENT_CLASS(power,
+
+   TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id),
+
+   TP_ARGS(type, state, cpu_id),
+
+   TP_STRUCT__entry(
+   __field(u64,type)
+   __field(u64,state   )
+   __field(u64,cpu_id  )
+   ),
+
+   TP_fast_assign(
+   __entry-type = type;
+   __entry-state = state;
+   __entry-cpu_id = cpu_id;
+   ),
+
+   TP_printk(type=%lu state=%lu cpu_id=%lu, (unsigned long)__entry-type,
+   (unsigned long)__entry-state, (unsigned long)__entry-cpu_id)
+);
+
+DEFINE_EVENT(power, power_start,
+
+   TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id),
+
+   TP_ARGS(type, state, cpu_id)
+);
+
+DEFINE_EVENT(power, power_frequency,
+
+   TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id),
+
+   TP_ARGS(type, state, cpu_id)
+);
+
+TRACE_EVENT(power_end,
+
+   TP_PROTO(unsigned int cpu_id),
+
+   TP_ARGS(cpu_id),
+
+   TP_STRUCT__entry(
+   __field(u64,cpu_id  )
+   ),
+
+   TP_fast_assign(
+   __entry-cpu_id = cpu_id;
+   ),
+
+   TP_printk(cpu_id=%lu, (unsigned long)__entry-cpu_id)
+);
+
+/* Map new events trace points calls to old ones */
+#define trace_processor_idle(state, cpu_id)\
+   do {\
+   if (state != 0) \
+   trace_power_start(POWER_CSTATE, state, cpu_id); \
+   else\
+   trace_power_end(cpu_id);\
+   } while (0)
+
+#define trace_processor_frequency(frequency, cpu_id)   \
+   do {\
+   trace_power_frequency(POWER_PSTATE, frequency, cpu_id); \
+   } while (0)
+
+#else /* CONFIG_DEPRECATED_POWER_EVENT_TRACING */
+
 /*
  * The processor events class is used for cpuidle (processor_idle) and
  *  for cpufreq (processor_frequency)
@@ -44,6 +141,7 @@ DEFINE_EVENT(processor, processor_frequency,
 
TP_ARGS(frequency, cpu_id)
 );
+#endif /* CONFIG_DEPRECATED_POWER_EVENT_TRACING */
 
 /*
  * The machine_suspend event is used for system suspend (machine_suspend)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 538501c..dab2bc1 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -64,6 +64,10 @@ config EVENT_TRACING
select CONTEXT_SWITCH_TRACER
bool
 
+config DEPRECATED_POWER_EVENT_TRACING
+   bool Use the deprecated power trace API
+   default n
+
 config CONTEXT_SWITCH_TRACER
bool
 
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index abe..3a95670 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -13,4 +13,8 @@
 #define CREATE_TRACE_POINTS
 #include trace/events/power.h
 
+#ifdef CONFIG_DEPRECATED_POWER_EVENT_TRACING
+EXPORT_TRACEPOINT_SYMBOL_GPL(power_start);
+#else
 EXPORT_TRACEPOINT_SYMBOL_GPL(processor_idle);
+#endif
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in

Re: beagle hangs in uart3 disabling clocks

Ming Lei tom.leim...@gmail.com writes:

 I just tested pm branch of tony's linux-omap-2.6 tree, and found my
 beagle will hang in uart3 disabling clocks, follows the log info:

It greatly helps when you also state what defconfig you're using, and
what you've changed from the default defconfig.

... more below...

 Starting kernel ...

 Uncompressing Linux... done, booting the kernel.
 Linux version 2.6.36-rc6+ (t...@tom-lei) (gcc version 4.3.3 (Sourcery
 G++ Lite 2009q1-203) ) #320 PREEM
 PT Sun Oct 3 16:46:04 CST 2010
 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
 CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
 Machine: OMAP3 Beagle Board
 bootconsole [earlycon0] enabled
 Memory policy: ECC disabled, Data cache writeback
 OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
 SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1
 On node 0 totalpages: 32768
 free_area_init_node: node 0, pgdat c04a1a00, node_mem_map c06b8000
   Normal zone: 256 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 32512 pages, LIFO batch:7
 Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
 Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw
 rootdelay=1 earlyprintk initcall_de
 bug=1 loglevel=8
 PID hash table entries: 512 (order: -1, 2048 bytes)
 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
 Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
 Memory: 128MB = 128MB total
 Memory: 123068k/123068k available, 8004k reserved, 0K highmem
 Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
 DMA : 0xffc0 - 0xffe0   (   2 MB)
 vmalloc : 0xc880 - 0xf800   ( 760 MB)
 lowmem  : 0xc000 - 0xc800   ( 128 MB)
 modules : 0xbf00 - 0xc000   (  16 MB)
   .init : 0xc0008000 - 0xc0034000   ( 176 kB)
   .text : 0xc0034000 - 0xc046c000   (4320 kB)
   .data : 0xc046c000 - 0xc04a2000   ( 216 kB)
 Preemptable hierarchical RCU implementation.
 RCU-based detection of stalled CPUs is disabled.
 Verbose stalled-CPUs detection is disabled.
 NR_IRQS:402
 omap_hwmod: l3_main: registering

You've manually done a '#define DEBUG' in omap_hwmod.c.  This does not
work well with UART hwmods, especially when using a UART console and
using DEBUG_LL + earlyprintk.

[...]

 omap_hwmod: uart2: idling
 omap_hwmod: uart2: disabling clocks
 omap_device: omap-hsuart: activating
 omap_hwmod: uart2: enabling
 omap_hwmod: uart2: enabling clocks
 omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec
 omap_device: omap-hsuart: deactivating
 omap_hwmod: uart2: idling
 omap_hwmod: uart2: disabling clocks
 omap_device: omap-hsuart: pm_lat 0: deactivate: elapsed time 0 nsec
 omap_device: omap-hsuart: activating
 omap_hwmod: uart2: enabling
 omap_hwmod: uart2: enabling clocks
 omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec
 omap_device: omap-hsuart: building with 1 hwmods
 omap_device: omap-hsuart: counted 4 total resources across 1 hwmods
 omap_device: omap-hsuart: registering
 Registering platform device 'omap-hsuart.2'. Parent at omap
 device: 'omap-hsuart.2': device_add
 bus: 'platform': add device omap-hsuart.2
 PM: Adding info for platform:omap-hsuart.2
 omap_hwmod: uart3: idling
 omap_hwmod: uart3: disabling clocks

Remember UART3 is your serial console.  

Basically, what is happening is that the hwmod is trying to print debug
messages for all hwmod changes.  As soon as UART3 is disabled, the
printing will fail since that is your console, so as soon as uart3
clocks are disabled, there is a fault when the polling-mode serial
driver (used for earlyprintk) tries to access the UART, and you hang.

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

tidspbridge broken?

Hi,

I was trying the iommu patches but I noticed the tidspbridge driver
doesn't work at all, I found two critical issues:

First, the platform device is missing, so there's no way the driver
can work. It seems to have been dropped from the migration to staging
which happened some time ago... I would have expected somebody to
notice a thing like this. I already have patches that fix this.

And second, since 2.6.35, ioremap() doesn't work on RAM, so this
driver cannot work anymore unless 309caa9 is reverted. I am reserving
the memory with memblock, but it still fails the ioremap(), and __va()
doesn't seem to work (don't know why).

Has anyone tried the driver on 2.6.36-rcX?

-- 
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: [PATCHv2 00/11] staging tidspbridge: iommu migration

Hi,

On Fri, Oct 1, 2010 at 5:12 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
 This set of patches remove the dspbridge custom mmu
 implementation and use iommu module instead.

I suppose the driver wouldn't work in the middle of this patch series.
I wanted to try this patches and experiment to see if I could come
with a version that doesn't break in the middle, but it turns out the
driver doesn't work at all on 2.6.36, I just sent an email with the
details.

Have you tried with the mainline? Or am I missing something?

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

Re: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface

2010-10-04 Thread Janusz Krzysztofik

Sunday 03 October 2010 04:42:53 Guennadi Liakhovetski napisał(a):
 On Sat, 2 Oct 2010, Janusz Krzysztofik wrote:
  Saturday 02 October 2010 08:07:28 Guennadi Liakhovetski napisał(a):
   Same with this one - let's take it as is and address a couple of
   clean-ups later.
 
  Guennadi,
  Thanks for taking them both.
 
  BTW, what are your intentions about the last patch from my series still
  left not commented, SoC Camera: add support for g_parm / s_parm
  operations, http://www.spinics.net/lists/linux-media/msg22887.html ?

 Yes, taking that one too, thanks. I see it right, that I have to apply 3
 of your patches: omap1 camera driver, ov6650 and default .[gs]_fmt for
 soc_camera, the rest will go via the OMAP / ARM tree, right?

Right.
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: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area

2010-10-04 Thread Guzman Lugo, Fernando

 -Original Message-
 From: David Cohen [mailto:daco...@gmail.com] 
 Sent: Monday, October 04, 2010 7:11 AM
 To: Guzman Lugo, Fernando
 Cc: David Cohen; Doyu Hiroshi (Nokia-MS/Espoo); Contreras 
 Felipe (Nokia-MS/Helsinki); Palande Ameya 
 (Nokia-MS/Helsinki); linux-ker...@vger.kernel.org; 
 andy.shevche...@gmail.com; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 2/4] iovmm: fix roundup for next area and 
 end check for the last area

 Hi,

 I have no access to my @nokia.com e-mail at this moment, so 
 I'm replying using my personal one.

 On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando 
 fernando.l...@ti.com wrote:

  On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, 
 Fernando wrote:

On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo, 
Fernando wrote:

[snip]

    arch/arm/plat-omap/iovmm.c |    6 +++---
    1 files changed, 3 insertions(+), 3 deletions(-)

   diff --git a/arch/arm/plat-omap/iovmm.c
  b/arch/arm/plat-omap/iovmm.c
   index 24ca9c4..fc6b109 100644
   --- a/arch/arm/plat-omap/iovmm.c
   +++ b/arch/arm/plat-omap/iovmm.c
   @@ -289,19 +289,19 @@ static struct iovm_struct
  *alloc_iovm_area(struct iommu *obj, u32 da,
         prev_end = 0;
         list_for_each_entry(tmp, obj-mmap, list) {

   -             if (prev_end = start)
   +             if (prev_end  start)
                         break;

                 if (start + bytes = tmp-da_start)
                         goto found;

                 if (flags  IOVMF_DA_ANON)
   -                     start = roundup(tmp-da_end +
1, alignement);
   +                     start = roundup(tmp-da_end,
alignement);

  There's a lack of comment here, but the purpose of
  tmp-da_end + 1 is to create a gap between iovm areas to
  force to trigger iommu faults when some access exceeds a
valid area.
  Without this gap, such situation may produce data
corruption which
  is much more difficult to track.

 That only works when you are accessing sequencially beyond
the End of
 the vm_area. However if you are accessing a random address
Which is in
 the mmu tables you still can corrupt memory which does Not
belong to
 you. That looks not very effective then why waste Memory?

The main intention is to detect sequential access 
 beyond the end 
of the vm area and it is effective for that purpose.
i.e., OMAP3 ISP has a hw issue which makes its H3A submodule, 
responsible to produce statistics data for the 
 captured image, to 
write more data than it should. The workaround 
 described in the 
errata wasn't enough to avoid error conditions, so a different 
approach was implemented. This gap did help me to make 
 sure the 
new workaround is valid and no data corruption was occurring 
anymore.
Anyway, I can't see why memory is being wasted.

   I was taking about vitual memory waste (maybe not so important).
   Is ok for me then keep the gap. Do other changes look 
 good to You?

  Do you mean in this patch?
  All changes make sense only if you're removing the gap, except for 
  the fix below.

  The thing is, the dspbridge needs to map some register in 
 order to DSP 
  can read and configure some of them. We need to map some pages with 
  fix addresses and to do that I use iommu_kmap. So when some of that 
  pages are contiguous I get his error:

  %s: no space to fit %08x(%x) flags: %08x\n

  Which is not true. The page to page perfectly fix, but the 
 check with 
  1 byte more avoid that it could be mapped and I am getting 
 the error.

  I am not agree with the gap, but I am ok when it is not 
 fixed address 
  as below code

  if (flags  IOVMF_DA_ANON)
         start = roundup(tmp-da_end + 1, alignement);

  But it is breaking the tidspbridge when the gap is used for 
 fixed addresses.

  It should not fail when we want to map a page what is freed 
 just because of the gap.
  Please let me know what you thing.

 I got your point. I agree the gap shouldn't be forced for fixed da.
 IMO you can apply this change when !(flags  IOVMF_DA_ANON).

As for not fixed address it always travers the list from the
Beginning. The only change need to revert in my patch is when
We roundup. That means keeping:

if (flags  IOVMF_DA_ANON)
        start = roundup(tmp-da_end + 1, alignement);

Is enough to create the gap for not fixed address. I will
Update the patch and send them again.

Thanks,
Fernando.

 Regards,

 David

  Thanks,
  Fernando.

  [snip]

                 prev_end = tmp-da_end;
         }

   -     if ((start  prev_end)  (ULONG_MAX - start = 
   bytes))
   +     if ((start = prev_end)  (ULONG_MAX - start +
1 = bytes))

  This fix is partially valid. The correct change must be only:
  -       if ((start  prev_end)

Re: [PATCH] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset

Vishwanath BS vishwanath...@ti.com writes:

 This patch adds comments on precatution to be taken if Global SW reset is
 used as the means to trigger sysem reset.

 Signed-off-by: Vishwanath BS vishwanath...@ti.com
 Cc: Paul Walmsley p...@pwsan.com

Please fix multi-line comment style.  

Search for 'multi-line' in Documentation/CodingStyle

Kevin


 ---
  arch/arm/mach-omap2/prcm.c |   26 ++
  1 files changed, 26 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
 index c201374..fdc860e
 --- a/arch/arm/mach-omap2/prcm.c
 +++ b/arch/arm/mach-omap2/prcm.c
 @@ -157,6 +157,32 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
   else
   WARN_ON(1);
  
 + /* As per Errata i520, In some cases, user
 +  * will not be able to access DDR memory after warm-reset.
 +  * This situation occurs while the warm-reset happens during a read
 +  * access to DDR memory. In that particular condition, DDR memory
 +  * does not respond to a corrupted read command due to the warm
 +  * reset occurence but SDRC is waiting for read completion.
 +  * SDRC is not sensitive to the warm reset, but the interconect is
 +  * reset on the fly, thus causing a misalignment between SDRC logic,
 +  * interconect logic and DDR memory state.
 +  * WORKAROUND:
 +  * Steps to perform before a Warm reset is trigged:
 +  * 1. enable self-refresh on idle request
 +  * 2. put SDRC in idle
 +  * 3. wait until SDRC goes to idle
 +  * 4. generate SW reset (Global SW reset)
 +
 +  * Steps to be performed after warm reset occurs (in bootloader):
 +  * if HW warm reset is the source, apply below steps before any
 +  * accesses to SDRAM:
 +  * 1. Reset SMS and SDRC and wait till reset is complete
 +  * 2. Re-initialize SMS, SDRC and memory
 +
 +  * NOTE: Above work around is required only if arch reset is implemented
 +  * using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need
 +  * the WA since it resets SDRC as well as part of cold reset. */
 +
   if (cpu_is_omap24xx() || cpu_is_omap34xx())
   prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
OMAP2_RM_RSTCTRL);
--
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] video/omap: remove duplicated include

2010-10-04 Thread Nicolas Kaiser

Remove duplicated include.

Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
 drivers/video/omap/lcd_omap3beagle.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap/lcd_omap3beagle.c 
b/drivers/video/omap/lcd_omap3beagle.c
index ca75cc2..ac715f9 100644
--- a/drivers/video/omap/lcd_omap3beagle.c
+++ b/drivers/video/omap/lcd_omap3beagle.c
@@ -26,7 +26,6 @@
 #include linux/i2c/twl.h
 
 #include plat/mux.h
-#include plat/mux.h
 #include asm/mach-types.h
 
 #include omapfb.h
-- 
1.7.2.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: beagle hangs in uart3 disabling clocks

Ming Lei tom.leim...@gmail.com writes:

 2010/10/4 Govindraj govindraj...@gmail.com:
 I tried now on zoom3 with uart3[ttyO2] as console

 It boots up fine for me

 Logs:

 http://pastebin.com/sXR5nYcD

 I am using omap2plus_defconfig and lo-master

 commit 0882b1455797b0a104978000a622c3f2412e7cf5
 Author: Tony Lindgren t...@atomide.com
 Date:   Fri Oct 1 17:23:48 2010 -0700

    omap: READ CAREFULLY: Fix build after merging in hwmod support for testing

 Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could 
 you
 try the pm branch of the tree?

Why?  What do you need from the PM branch that is not in l-o master?

The PM branch is *experimental*, and is under significant change while
parts that are not yet ready for mainline are being reworked and in some
cases completely re-written.

IOW, the PM branch is unstable and should not be trusted.  (I can say
that, I am the maintainer.)  ;)

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 2/4] iovmm: fix roundup for next area and end check for the last area

2010-10-04 Thread David Cohen

On Mon, Oct 04, 2010 at 05:37:04PM +0200, ext Guzman Lugo, Fernando wrote:

  -Original Message-
  From: David Cohen [mailto:daco...@gmail.com] 
  Sent: Monday, October 04, 2010 7:11 AM
  To: Guzman Lugo, Fernando
  Cc: David Cohen; Doyu Hiroshi (Nokia-MS/Espoo); Contreras 
  Felipe (Nokia-MS/Helsinki); Palande Ameya 
  (Nokia-MS/Helsinki); linux-ker...@vger.kernel.org; 
  andy.shevche...@gmail.com; linux-omap@vger.kernel.org
  Subject: Re: [PATCH 2/4] iovmm: fix roundup for next area and 
  end check for the last area

  Hi,

  I have no access to my @nokia.com e-mail at this moment, so 
  I'm replying using my personal one.

  On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando 
  fernando.l...@ti.com wrote:

   On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, 
  Fernando wrote:

 On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo, 
 Fernando wrote:

 [snip]

 arch/arm/plat-omap/iovmm.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c
   b/arch/arm/plat-omap/iovmm.c
index 24ca9c4..fc6b109 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,19 +289,19 @@ static struct iovm_struct
   *alloc_iovm_area(struct iommu *obj, u32 da,
      prev_end = 0;
      list_for_each_entry(tmp, obj-mmap, list) {

-             if (prev_end = start)
+             if (prev_end  start)
                      break;

              if (start + bytes = tmp-da_start)
                      goto found;

              if (flags  IOVMF_DA_ANON)
-                     start = roundup(tmp-da_end +
 1, alignement);
+                     start = roundup(tmp-da_end,
 alignement);

   There's a lack of comment here, but the purpose of
   tmp-da_end + 1 is to create a gap between iovm areas to
   force to trigger iommu faults when some access exceeds a
 valid area.
   Without this gap, such situation may produce data
 corruption which
   is much more difficult to track.

  That only works when you are accessing sequencially beyond
 the End of
  the vm_area. However if you are accessing a random address
 Which is in
  the mmu tables you still can corrupt memory which does Not
 belong to
  you. That looks not very effective then why waste Memory?

 The main intention is to detect sequential access 
  beyond the end 
 of the vm area and it is effective for that purpose.
 i.e., OMAP3 ISP has a hw issue which makes its H3A submodule, 
 responsible to produce statistics data for the 
  captured image, to 
 write more data than it should. The workaround 
  described in the 
 errata wasn't enough to avoid error conditions, so a different 
 approach was implemented. This gap did help me to make 
  sure the 
 new workaround is valid and no data corruption was occurring 
 anymore.
 Anyway, I can't see why memory is being wasted.

I was taking about vitual memory waste (maybe not so important).
Is ok for me then keep the gap. Do other changes look 
  good to You?

   Do you mean in this patch?
   All changes make sense only if you're removing the gap, except for 
   the fix below.

   The thing is, the dspbridge needs to map some register in 
  order to DSP 
   can read and configure some of them. We need to map some pages with 
   fix addresses and to do that I use iommu_kmap. So when some of that 
   pages are contiguous I get his error:

   %s: no space to fit %08x(%x) flags: %08x\n

   Which is not true. The page to page perfectly fix, but the 
  check with 
   1 byte more avoid that it could be mapped and I am getting 
  the error.

   I am not agree with the gap, but I am ok when it is not 
  fixed address 
   as below code

   if (flags  IOVMF_DA_ANON)
          start = roundup(tmp-da_end + 1, alignement);

   But it is breaking the tidspbridge when the gap is used for 
  fixed addresses.

   It should not fail when we want to map a page what is freed 
  just because of the gap.
   Please let me know what you thing.

  I got your point. I agree the gap shouldn't be forced for fixed da.
  IMO you can apply this change when !(flags  IOVMF_DA_ANON).

 As for not fixed address it always travers the list from the
 Beginning. The only change need to revert in my patch is when
 We roundup. That means keeping:

 if (flags  IOVMF_DA_ANON)
         start = roundup(tmp-da_end + 1, alignement);

 Is enough to create the gap for not fixed address. I will
 Update the patch and send them again.

Sounds fine for me. Please, update the patch and I'll ack it.

Br,

David

 Thanks,
 Fernando.

  Regards,

  David

   Thanks,
   Fernando.

   [snip]

RE: tidspbridge broken?

2010-10-04 Thread Ramirez Luna, Omar

Hi,

Felipe Contreras wrote:
Hi,

I was trying the iommu patches but I noticed the tidspbridge driver
doesn't work at all, I found two critical issues:

First, the platform device is missing, so there's no way the driver
can work. It seems to have been dropped from the migration to staging
which happened some time ago... I would have expected somebody to
notice a thing like this. I already have patches that fix this.

Yes this is missing from beginning, I seeked advice on whether to send a patch
for this or not, and since it would be touching mach dependent files it would
be out of the scope of staging tree, however if needed:

http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c

This was meant to placed under dspbridge wiki, I still have to do that one.

And second, since 2.6.35, ioremap() doesn't work on RAM, so this
driver cannot work anymore unless 309caa9 is reverted. I am reserving
the memory with memblock, but it still fails the ioremap(), and
__va() doesn't seem to work (don't know why).

Yes that's true, so far the only solution I have seen is to move the allocation
on memory outside kernel control, I believe framebuffer has the same problem,
but I haven't contacted them to see if we can align on a common solution.

Has anyone tried the driver on 2.6.36-rcX?

Yes I have, I was rebasing your mailbox hwmod patches but seems something has
changed since they don't work, I was trying to write my own version.

After that, I was planning the migration from bridge tasklet to a process
context, and see how it works, since the spin_lock method used in the mailbox
driver also causes an invalid locking condition.

Regards,

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

[PATCHv2] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset

2010-10-04 Thread Vishwanath BS

This patch adds comments on precatution to be taken if Global Warm reset is
used as the means to trigger sysem reset.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/prcm.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index c201374..6494a88
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -157,6 +157,34 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
else
WARN_ON(1);
 
+   /*
+* As per Errata i520, In some cases, user will not be able to
+* access DDR memory after warm-reset.
+* This situation occurs while the warm-reset happens during a read
+* access to DDR memory. In that particular condition, DDR memory
+* does not respond to a corrupted read command due to the warm
+* reset occurence but SDRC is waiting for read completion.
+* SDRC is not sensitive to the warm reset, but the interconect is
+* reset on the fly, thus causing a misalignment between SDRC logic,
+* interconect logic and DDR memory state.
+* WORKAROUND:
+* Steps to perform before a Warm reset is trigged:
+* 1. enable self-refresh on idle request
+* 2. put SDRC in idle
+* 3. wait until SDRC goes to idle
+* 4. generate SW reset (Global SW reset)
+
+* Steps to be performed after warm reset occurs (in bootloader):
+* if HW warm reset is the source, apply below steps before any
+* accesses to SDRAM:
+* 1. Reset SMS and SDRC and wait till reset is complete
+* 2. Re-initialize SMS, SDRC and memory
+
+* NOTE: Above work around is required only if arch reset is implemented
+* using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need
+* the WA since it resets SDRC as well as part of cold reset.
+*/
+
if (cpu_is_omap24xx() || cpu_is_omap34xx())
prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
 OMAP2_RM_RSTCTRL);
-- 
1.7.0.4

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

[PATCH 0/2] omap: dsp: make the driver actually work

Hi,

It seems the platform device was dropped from the migration of tidspbridge into
staging, plus the sdram meblock (previously bootmem) required for it work are
gone.

Withouth these patches the driver loads, but doesn't do anything.

A second issue with ioremap() still remains, but that can be solved by
reverting 309caa9.

I think these might be worth to get into 2.6.36, if not, I have versions with
more changes; cleanups and so on.

Tested on a Nokia N900.

Felipe Contreras (2):
  omap: add dsp platform device
  staging: tidspbridge: use omap_dsp_platform_data

 arch/arm/mach-omap2/Makefile   |4 +
 arch/arm/mach-omap2/dsp.c  |   85 
 arch/arm/plat-omap/common.c|2 +
 arch/arm/plat-omap/devices.c   |   30 +++
 arch/arm/plat-omap/include/plat/dsp.h  |   31 +++
 drivers/staging/tidspbridge/core/tiomap3430.c  |   14 ++--
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c  |   14 ++--
 drivers/staging/tidspbridge/core/tiomap_io.c   |4 +-
 .../tidspbridge/include/dspbridge/host_os.h|   19 -
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |   10 ++-
 10 files changed, 177 insertions(+), 36 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dsp.c
 create mode 100644 arch/arm/plat-omap/include/plat/dsp.h

-- 
1.7.3.1.2.g7fe2b

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

[PATCH 1/2] omap: add dsp platform device

Otherwise tidspbridge cannot work.

It looks like this was dropped in the conversion to staging. I took the
liberty of doing some cleaning up.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap2/Makefile  |4 ++
 arch/arm/mach-omap2/dsp.c |   85 +
 arch/arm/plat-omap/common.c   |2 +
 arch/arm/plat-omap/devices.c  |   30 
 arch/arm/plat-omap/include/plat/dsp.h |   31 
 5 files changed, 152 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dsp.c
 create mode 100644 arch/arm/plat-omap/include/plat/dsp.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..58288a4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,6 +102,10 @@ obj-y  += $(iommu-m) 
$(iommu-y)
 i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o
 obj-y  += $(i2c-omap-m) $(i2c-omap-y)
 
+ifneq ($(CONFIG_TIDSPBRIDGE),)
+obj-y  += dsp.o
+endif
+
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
new file mode 100644
index 000..6feeeae
--- /dev/null
+++ b/arch/arm/mach-omap2/dsp.c
@@ -0,0 +1,85 @@
+/*
+ * TI's OMAP DSP platform device registration
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+#include prm.h
+#include cm.h
+#ifdef CONFIG_BRIDGE_DVFS
+#include plat/omap-pm.h
+#endif
+
+#include plat/dsp.h
+
+extern phys_addr_t omap_dsp_get_mempool_base(void);
+
+static struct platform_device *omap_dsp_pdev;
+
+static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
+#ifdef CONFIG_BRIDGE_DVFS
+   .dsp_set_min_opp = omap_pm_dsp_set_min_opp,
+   .dsp_get_opp = omap_pm_dsp_get_opp,
+   .cpu_set_freq = omap_pm_cpu_set_freq,
+   .cpu_get_freq = omap_pm_cpu_get_freq,
+#endif
+   .dsp_prm_read = prm_read_mod_reg,
+   .dsp_prm_write = prm_write_mod_reg,
+   .dsp_prm_rmw_bits = prm_rmw_mod_reg_bits,
+   .dsp_cm_read = cm_read_mod_reg,
+   .dsp_cm_write = cm_write_mod_reg,
+   .dsp_cm_rmw_bits = cm_rmw_mod_reg_bits,
+};
+
+static int __init omap_dsp_init(void)
+{
+   struct platform_device *pdev;
+   int err = -ENOMEM;
+   struct omap_dsp_platform_data *pdata = omap_dsp_pdata;
+
+   pdata-phys_mempool_base = omap_dsp_get_mempool_base();
+
+   if (pdata-phys_mempool_base) {
+   pdata-phys_mempool_size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+   pr_info(%s: %x bytes @ %x\n, __func__,
+   pdata-phys_mempool_size, pdata-phys_mempool_base);
+   }
+
+   pdev = platform_device_alloc(omap-dsp, -1);
+   if (!pdev)
+   goto err_out;
+
+   err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+   if (err)
+   goto err_out;
+
+   err = platform_device_add(pdev);
+   if (err)
+   goto err_out;
+
+   omap_dsp_pdev = pdev;
+   return 0;
+
+err_out:
+   platform_device_put(pdev);
+   return err;
+}
+module_init(omap_dsp_init);
+
+static void __exit omap_dsp_exit(void)
+{
+   platform_device_unregister(omap_dsp_pdev);
+}
+module_exit(omap_dsp_exit);
+
+MODULE_AUTHOR(Hiroshi DOYU);
+MODULE_DESCRIPTION(TI's OMAP DSP platform device registration);
+MODULE_LICENSE(GPL);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3008e71..57205a4 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -37,6 +37,7 @@
 #include plat/fpga.h
 #include plat/serial.h
 #include plat/vram.h
+#include plat/dsp.h
 
 #include plat/clock.h
 
@@ -87,6 +88,7 @@ void __init omap_reserve(void)
 {
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
+   omap_dsp_reserve_sdram_memblock();
 }
 
 /*
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index d1920be..4c8f9b9 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -15,6 +15,7 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/slab.h
+#include linux/memblock.h
 
 #include mach/hardware.h
 #include asm/mach-types.h
@@ -272,6 +273,35 @@ static void omap_init_wdt(void)
 static inline void omap_init_wdt(void) {}
 #endif
 
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+static phys_addr_t omap_dsp_phys_mempool_base;
+
+void __init omap_dsp_reserve_sdram_memblock(void)

[PATCH 2/2] staging: tidspbridge: use omap_dsp_platform_data

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 drivers/staging/tidspbridge/core/tiomap3430.c  |   14 --
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c  |   14 --
 drivers/staging/tidspbridge/core/tiomap_io.c   |4 +++-
 .../tidspbridge/include/dspbridge/host_os.h|   19 ---
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |   10 ++
 5 files changed, 25 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f914829..5aefc95 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -16,6 +16,8 @@
  * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  */
 
+#include plat/dsp.h
+
 #include linux/types.h
 /*  --- Host OS */
 #include dspbridge/host_os.h
@@ -264,8 +266,8 @@ static int bridge_brd_monitor(struct bridge_dev_context 
*dev_ctxt)
 {
struct bridge_dev_context *dev_context = dev_ctxt;
u32 temp;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
temp = (*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) 
OMAP_POWERSTATEST_MASK;
@@ -374,8 +376,8 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
/* The device context contains all the mmu setup info from when the
 * last dsp base image was loaded. The first entry is always
@@ -627,8 +629,8 @@ static int bridge_brd_stop(struct bridge_dev_context 
*dev_ctxt)
struct pg_table_attrs *pt_attrs;
u32 dsp_pwr_state;
int clk_status;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
if (dev_context-dw_brd_state == BRD_STOPPED)
return status;
diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c 
b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
index b789f8f..1bea23f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
@@ -16,6 +16,8 @@
  * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  */
 
+#include plat/dsp.h
+
 /*  --- DSP/BIOS Bridge */
 #include dspbridge/dbdefs.h
 #include dspbridge/cfg.h
@@ -54,8 +56,8 @@ int handle_constraints_set(struct bridge_dev_context 
*dev_context,
 {
 #ifdef CONFIG_TIDSPBRIDGE_DVFS
u32 *constraint_val;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
constraint_val = (u32 *) (pargs);
/* Read the target value requested by DSP */
@@ -83,8 +85,8 @@ int handle_hibernation_from_dsp(struct bridge_dev_context 
*dev_context)
u32 opplevel;
struct io_mgr *hio_mgr;
 #endif
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
pwr_state = (*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) 
OMAP_POWERSTATEST_MASK;
@@ -152,8 +154,8 @@ int sleep_dsp(struct bridge_dev_context *dev_context, u32 
dw_cmd,
 #endif /* CONFIG_TIDSPBRIDGE_NTFY_PWRERR */
u16 timeout = PWRSTST_TIMEOUT / 10;
u32 pwr_state, target_pwr_state;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
+   struct omap_dsp_platform_data *pdata =
+   omap_dspbridge_dev-dev.platform_data;
 
/* Check if sleep code is valid */
if ((dw_cmd != PWR_DEEPSLEEP)  (dw_cmd != PWR_EMERGENCYDEEPSLEEP))
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c 
b/drivers/staging/tidspbridge/core/tiomap_io.c
index 190c028..2a3cd45 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -16,6 +16,8 @@
  * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  */
 
+#include plat/dsp.h
+
 /*  --- DSP/BIOS Bridge */
 #include dspbridge/dbdefs.h
 
@@ -388,7 +390,7 @@ int sm_interrupt_dsp(struct

Re: [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space

2010-10-04 Thread Frank Ch. Eigler

Hi -

 Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING  option in order
 to provide backward compatibility with the user space tracing tools.

This is clever:

 +/* Map new events trace points calls to old ones */
 +#define trace_processor_idle(state, cpu_id)  \
 + do {\
 + if (state != 0) \
 + trace_power_start(POWER_CSTATE, state, cpu_id); \
 + else\
 + trace_power_end(cpu_id);\
 + } while (0)

but with this code, are the new tracepoints firing at all?  In other
words, does this backward-compatibility config option effectively
disable the newer ones?  If so, this is probably avoidable.

Instead of redirecting the new tracepoint calls to these macros, an
alternative may intercept (un)registration for the old tracepoint
names, and map them to (un)registration of the real tracepoints.  See
how syscall tracepoints map to a special (un)registration callback in
include/trace/events/syscalls.h (syscall_*regfunc).  Instead of
setting a TIF flag, the new functions can call
register_processor_idle() et al., and their respective callbacks can
call the backward-compatibility tracepoints.

The starting point would be to recast the power_start, power_end,
power_frequency tracepoints via TRACE_EVENT_FN() instead of
TRACE_EVENT().

- FChE
--
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] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset

2010-10-04 Thread Paul Walmsley

Hi Vishwa,

On Mon, 4 Oct 2010, Vishwanath BS wrote:

 This patch adds comments on precatution to be taken if Global Warm reset is
 used as the means to trigger sysem reset.

thanks for this but the comment style still needs at least one more fix 
per Documentation/CodingStyle:



The preferred style for long (multi-line) comments is:

/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

-

Please make sure that every line in the comment block has an asterisk on 
the left side.

Once you fix that and repost, I'll queue for 2.6.38.

- Paul

 
 Signed-off-by: Vishwanath BS vishwanath...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/mach-omap2/prcm.c |   28 
  1 files changed, 28 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
 index c201374..6494a88
 --- a/arch/arm/mach-omap2/prcm.c
 +++ b/arch/arm/mach-omap2/prcm.c
 @@ -157,6 +157,34 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
   else
   WARN_ON(1);
  
 + /*
 +  * As per Errata i520, In some cases, user will not be able to
 +  * access DDR memory after warm-reset.
 +  * This situation occurs while the warm-reset happens during a read
 +  * access to DDR memory. In that particular condition, DDR memory
 +  * does not respond to a corrupted read command due to the warm
 +  * reset occurence but SDRC is waiting for read completion.
 +  * SDRC is not sensitive to the warm reset, but the interconect is
 +  * reset on the fly, thus causing a misalignment between SDRC logic,
 +  * interconect logic and DDR memory state.
 +  * WORKAROUND:
 +  * Steps to perform before a Warm reset is trigged:
 +  * 1. enable self-refresh on idle request
 +  * 2. put SDRC in idle
 +  * 3. wait until SDRC goes to idle
 +  * 4. generate SW reset (Global SW reset)
 +
 +  * Steps to be performed after warm reset occurs (in bootloader):
 +  * if HW warm reset is the source, apply below steps before any
 +  * accesses to SDRAM:
 +  * 1. Reset SMS and SDRC and wait till reset is complete
 +  * 2. Re-initialize SMS, SDRC and memory
 +
 +  * NOTE: Above work around is required only if arch reset is implemented
 +  * using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need
 +  * the WA since it resets SDRC as well as part of cold reset.
 +  */
 +
   if (cpu_is_omap24xx() || cpu_is_omap34xx())
   prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
OMAP2_RM_RSTCTRL);
 -- 
 1.7.0.4
 


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

Re: beagle hangs in uart3 disabling clocks

2010-10-04 Thread Ming Lei

2010/10/4 Kevin Hilman khil...@deeprootsystems.com:

 Why?  What do you need from the PM branch that is not in l-o master?

Seems master branch works fine for me, my beagle board doesn't hang
uart3 disabling clocks.

I only want to have a try of the runtime pm feature of omap3, so use
PM branch to do the test.


 The PM branch is *experimental*, and is under significant change while
 parts that are not yet ready for mainline are being reworked and in some
 cases completely re-written.

 IOW, the PM branch is unstable and should not be trusted.  (I can say
 that, I am the maintainer.)  ;)

I see now, :-)

-- 
Lei Ming
--
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: tidspbridge broken?

Hi,

On Mon, Oct 4, 2010 at 6:59 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
Felipe Contreras wrote:
I was trying the iommu patches but I noticed the tidspbridge driver
doesn't work at all, I found two critical issues:

Yes this is missing from beginning, I seeked advice on whether to send a
patch for this or not, and since it would be touching mach dependent files it
would be out of the scope of staging tree, however if needed:

http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c

This was meant to placed under dspbridge wiki, I still have to do that one.

This seems to be worth mentioning in the TODO file:
* Make it actually work

Anyway, first, I think I tried a version similar to that one, and
doesn't apply on mainline any more, also, bootmem doesn't seem to be
working on ARM either, so I had to move to memblock, and third, I
don't think that platform device is correct since it depends on the
headers of a driver.

My version is basically the same, but using memblock, and stands on
it's own. Even if tidspbridge wasn't in staging I think this could go
to mainline, plus, perhaps other implementations like dsp-link could
make use of it (who knows):
http://article.gmane.org/gmane.linux.kernel/1044209

Yes that's true, so far the only solution I have seen is to move the
allocation on memory outside kernel control, I believe framebuffer has the
same problem, but I haven't contacted them to see if we can align on a common
solution.

At least on my N900 the framebuffer is not working either, and I've
heard the same on beagleboard.

Maybe something like this:
http://article.gmane.org/gmane.linux.kernel.mm/52757

Has anyone tried the driver on 2.6.36-rcX?

Yes I have,

I guess by applying your patches on top and reverting 309caa9.

I was rebasing your mailbox hwmod patches but seems something has changed
since they don't work, I was trying to write my own version.

You should have said so, I'll try to rebase myself.

Cheers.

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

Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-04 Thread Steve Sakoman

On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote:
 David Vrabel wrote:

 On 27/08/2010 20:22, Chris Ball wrote:

 Hi David,

 On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote:

 These patches add support for SDIO cards to the omap_hsmmc driver.
 Power management changes to prevent SDIO cards from being turned off
 and losing all state, and card interrupts.

 I've been unable to test these exact patches as I only have an N900 for
 testing and the N900 support in mainline is incomplete.

 Changes since v1:
 - (hopefully) get all cards working again by removing a second call to
  read MMCi_STAT in the interrupt handler.
 - flush posted writes after enabling/disabling SDIO interrupts.
 - tweak the FIXME commit on disabling FCLK to better match what really
  going on (at least I think so anyway).

 David Vrabel (2):
  mmc: omap_hsmmc: don't turn SDIO cards off when idle
  mmc: omap_hsmmc: enable SDIO card interrupts

 Looks like this patchset wasn't merged.  Mike Rapoport replied with a fix
 for libertas.  Would you like to resubmit it?

 I thought Madhu had picked this up and was going to submit it.

 Regardless of whether that is the case, I think it needs to be submitted
 by someone who can run mainline kernels (I can't) and ideally someone
 who can test it with SDIO cards.

 I'll try to update the patches in the next few days.

Any update on the status of these patches?  I'm happy to help test!

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

RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-04 Thread Madhusudhan

 -Original Message-
 From: Steve Sakoman [mailto:sako...@gmail.com]
 Sent: Monday, October 04, 2010 11:32 AM
 To: Mike Rapoport
 Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; madhu...@ti.com
 Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

 On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il
 wrote:
  David Vrabel wrote:

  On 27/08/2010 20:22, Chris Ball wrote:

  Hi David,

  On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote:

  These patches add support for SDIO cards to the omap_hsmmc driver.
  Power management changes to prevent SDIO cards from being turned off
  and losing all state, and card interrupts.

  I've been unable to test these exact patches as I only have an N900
 for
  testing and the N900 support in mainline is incomplete.

  Changes since v1:
  - (hopefully) get all cards working again by removing a second call
 to
   read MMCi_STAT in the interrupt handler.
  - flush posted writes after enabling/disabling SDIO interrupts.
  - tweak the FIXME commit on disabling FCLK to better match what
 really
   going on (at least I think so anyway).

  David Vrabel (2):
   mmc: omap_hsmmc: don't turn SDIO cards off when idle
   mmc: omap_hsmmc: enable SDIO card interrupts

  Looks like this patchset wasn't merged.  Mike Rapoport replied with a
 fix
  for libertas.  Would you like to resubmit it?

  I thought Madhu had picked this up and was going to submit it.

  Regardless of whether that is the case, I think it needs to be
 submitted
  by someone who can run mainline kernels (I can't) and ideally someone
  who can test it with SDIO cards.

  I'll try to update the patches in the next few days.

 Any update on the status of these patches?  I'm happy to help test!

Steve,

I have not been able to test SDIO card interrupts. If you could help test
that it's great.

Regards,
Madhu

 Steve

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

RE: NOTE: hwmod changes merged to linux-omap master for testing

 

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com] 
 Sent: Monday, October 04, 2010 8:36 PM
 To: G, Manjunath Kondaiah
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: NOTE: hwmod changes merged to linux-omap master 
 for testing
 
 G, Manjunath Kondaiah manj...@ti.com writes:
 
  Hi Tony,
  With latest merges on master branch with commit ID:
  0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix 
  build after merging in hwmod support for testing
 
  Booting with zoom3 seems to be fine but observed issues 
 with omap4 blaze board. 
 
  Looks like multiple warning dumps and finally it crashes 
 after Freeing init memory with both NFS and ramdisk file systems.
 
  The complete bootlogs are available at:
  NFS bootlog:
  http://pastebin.com/nrWQ5FGG
 
 In the future, it helps greatly if you state what defconfig 
 you're using, 

ok. I have used omap2plus_defconfig

 and specifically what you've changed from the 
 default defconfig.
No changes to defconfig

 
 Looking at this log, you've enabled CPUidle in your config, 
 which is not
 (yet) supported for OMAP4 in mainline.

As I mentioned no changes to defconfig and it looks like cpu idle
is disabled and cpu idle wait is enabled in .config after running
make omap2plus_defconfig

$ cat arch/arm/configs/omap2plus_defconfig | grep CPU_IDLE
$
$ make omap2plus_defconfig
#
# configuration written to .config
#
$ cat .config | grep CPU_IDLE
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
# CONFIG_CPU_IDLE is not set
$

Even if I disable CPU_IDLE_WAIT manually, behaviour is same

-Manjunath
--
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 4/4] perf: provide a DEPRECTAED power trace API to user space