RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB

2010-09-06 Thread Hiremath, Vaibhav 
 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 06, 2010 9:31 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org
 Subject: RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build
 without VRFB
 
 Hi,
 
 Hiremath, Vaibhav wrote:
  -Original Message-
  From: Taneja, Archit
  Sent: Saturday, September 04, 2010 2:12 PM
  To: Hiremath, Vaibhav
  Cc: linux-omap@vger.kernel.org;
  linux-me...@vger.kernel.org; Taneja,
  Archit
  Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build
 without
  VRFB
 
  This lets omap_vout driver build and run without VRFB. It works along
  the lines of the following patch series:
  OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
  https://patchwork.kernel.org/patch/105371/
 
  A variable rotation_type is introduced in omapvideo_info like the way
  in omapfb_info to make both vrfb and non vrfb rotation possible.
 
  [Hiremath, Vaibhav] Archit,
 
  Currently omap_vout driver only supports VRFB based rotation,
  it doesn't support SDMA based rotation (unlike OMAPFB) and neither you
 patch
  adds it.
 
 [Archit]The above description in the git commit is a mistake from my end.
 The main purpose
 of the patch is to get omap_vout running without VRFB.
 
 I am not sure if we need to enable SDMA rotation for V4L2 though, we would
 always have
 vrfb and tiler on omap3 and omap4 respectively.
[Hiremath, Vaibhav] No, for me SDMA based rotation doesn't make sense, since 
SDMA rotation suffers from bandwidth issue. On OMAPFB it has been observed 
that, DSS throws FIFO underflow error very frequently in SDMA based rotation.


 
 How do you think things should be handled in the non vrfb case? Should we
 try to get
 rotation running or should the driver return an error if userspace tries
 to enable
 rotation in a non-vrfb mode?
[Hiremath, Vaibhav] We can handle this in 2 ways,

- Driver can return -ERANGE error, in case of OMAP4 (or non-vrfb platform)

- Driver can choose/fall-down 0 degree rotation gracefully

As per V4L2 spec both options are acceptable.

Thanks,
Vaibhav

 
 Thanks,
 
 Archit
 
  Since VRFB is tightly coupled with the omap_vout driver, a handful of
  vrfb-specific functions have been defined and placed in
 omap_vout_vrfb.c
 
  This series applies along with the previously submitted patch:
  https://patchwork.kernel.org/patch/146401/
 
  Archit Taneja (2):
V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library
V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and
 sdram
  rotation
 
   drivers/media/video/omap/Kconfig  |1 -
   drivers/media/video/omap/Makefile |1 +
   drivers/media/video/omap/omap_vout.c  |  502 ++---
 ---
   - drivers/media/video/omap/omap_vout_vrfb.c |  417
    drivers/media/video/omap/omap_vout_vrfb.h |
 40
   +++ drivers/media/video/omap/omap_voutdef.h   |   26 ++
   6 files changed, 582 insertions(+), 405 deletions(-)  create mode
  100644 drivers/media/video/omap/omap_vout_vrfb.c
   create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB

2010-09-06 Thread Taneja, Archit 
Hi,

Hiremath, Vaibhav wrote:
 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 06, 2010 9:31 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org
 Subject: RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build
 without VRFB 
 
 Hi,
 
 Hiremath, Vaibhav wrote:
 -Original Message-
 From: Taneja, Archit
 Sent: Saturday, September 04, 2010 2:12 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org;
 linux-me...@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without
 VRFB 
 
 This lets omap_vout driver build and run without VRFB. It works
 along the lines of the following patch series:
 OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
 https://patchwork.kernel.org/patch/105371/
 
 A variable rotation_type is introduced in omapvideo_info like the
 way in omapfb_info to make both vrfb and non vrfb rotation possible.
 
 [Hiremath, Vaibhav] Archit,
 
 Currently omap_vout driver only supports VRFB based rotation, it
 doesn't support SDMA based rotation (unlike OMAPFB) and neither you patch
 adds it.
 
 [Archit]The above description in the git commit is a mistake from my end.
 The main purpose of the patch is to get omap_vout running without VRFB.
 
 I am not sure if we need to enable SDMA rotation for V4L2 though, we
 would always have vrfb and tiler on omap3 and omap4 respectively.
 [Hiremath, Vaibhav] No, for me SDMA based rotation doesn't
 make sense, since SDMA rotation suffers from bandwidth issue.
 On OMAPFB it has been observed that, DSS throws FIFO
 underflow error very frequently in SDMA based rotation.
 
 
 
 How do you think things should be handled in the non vrfb case? Should we
 try to get rotation running or should the driver return an error if
 userspace tries to enable rotation in a non-vrfb mode?
 [Hiremath, Vaibhav] We can handle this in 2 ways,
 
 - Driver can return -ERANGE error, in case of OMAP4 (or non-vrfb platform)
 
 - Driver can choose/fall-down 0 degree rotation gracefully
 
 As per V4L2 spec both options are acceptable.

Thanks for the clarification. I will work on this change.

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

Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Catalin Marinas 
On Thu, 2010-09-02 at 17:16 +0100, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [100902 06:29]:
  On Mon, Aug 30, 2010 at 03:55:27PM -0700, Tony Lindgren wrote:
   * Tony Lindgren t...@atomide.com [100820 04:59]:
* Russell King - ARM Linux li...@arm.linux.org.uk [100819 13:13]:
 On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote:
  Looks like something is not quite right with smp_on_up part of 
  __fixup_smp,
  returning early before smp_on_up does not produce that.

 It's probably overwriting some register it shouldn't be.  I might be
 able to look at this sometime during the coming week... assuming that
 the weather is as bad as they forecast and I have 'net connectivity.
  
   This seems to fix it.
 
  Thanks, merged that into my original patch - so here it is again with
  everything updated.
 
 Your patch sure makes things simpler! The problem still is the
 V6 vs V7 SMP code though.

I haven't followed your patches closely but can we restrict the ARMv6
SMP/UP support to only those cores that have TEX remapping (most of them
probably)?

-- 
Catalin

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

Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Russell King - ARM Linux 
On Mon, Sep 06, 2010 at 10:28:53AM +0100, Catalin Marinas wrote:
 I haven't followed your patches closely but can we restrict the ARMv6
 SMP/UP support to only those cores that have TEX remapping (most of them
 probably)?

We don't support TEX remapping on ARMv6.
--
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/4] ARM: l2x0: Fix coding-style in the cache-l2x0.h

2010-09-06 Thread Catalin Marinas 
On Sat, 2010-07-31 at 23:14 +0530, Santosh Shilimkar wrote:
 Replace tab with space after #define to be consisten with other
 define in the file. Also move the bit mask below the register offsets.
 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Catalin Marinas catalin.mari...@arm.com

Acked-by: Catalin Marinas catalin.mari...@arm.com

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

Re: [PATCH 3/4] ARM: l2x0: Determine the cache size

2010-09-06 Thread Catalin Marinas 
On Sat, 2010-07-31 at 23:16 +0530, Santosh Shilimkar wrote:
 The cache size is needed for to optimise range based
 maintainance operations
 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Catalin Marinas catalin.mari...@arm.com

Acked-by: Catalin Marinas catalin.mari...@arm.com

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

Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Russell King - ARM Linux 
On Mon, Sep 06, 2010 at 10:38:30AM +0100, Catalin Marinas wrote:
 On Mon, 2010-09-06 at 10:34 +0100, Russell King - ARM Linux wrote:
  On Mon, Sep 06, 2010 at 10:28:53AM +0100, Catalin Marinas wrote:
   I haven't followed your patches closely but can we restrict the ARMv6
   SMP/UP support to only those cores that have TEX remapping (most of them
   probably)?
  
  We don't support TEX remapping on ARMv6.
 
 I know but it's easy to enable if useful for the SMP/UP v6/v7
 combination (with some restrictions).

It'll make proc-v6.S much more complicated than it already is, requiring
it to carry both the non-remap and remapping code selected via an ifdef.

Is it worth it?  For the sake of one conditional in mmu.c, I don't think
so - and the view is that using TEX remapping to get rid of the shared
bit is a horrible hack anyway.

In any case, it's unnecessary.  We can use my word-replacement to modify
a variable to indicate whether we're running on SMP or not, and so have
the test for SMP-on-UP in just one place.  Like this:

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index e621530..7de5aa5 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -18,4 +18,19 @@ static inline int cache_ops_need_broadcast(void)
return ((read_cpuid_ext(CPUID_EXT_MMFR3)  12)  0xf)  1;
 }
 
+/*
+ * Return true if we are running on a SMP platform
+ */
+static inline bool is_smp(void)
+{
+#ifndef CONFIG_SMP
+   return false;
+#elif defined(CONFIG_SMP_ON_UP)
+   extern unsigned int smp_on_up;
+   return !!smp_on_up;
+#else
+   return true;
+#endif
+}
+
 #endif
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 26ec521..360bf06 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -343,7 +343,7 @@ __fixup_smp:
orr r7, r7, #0x4100 @ val 0x4107
and r0, r9, r6
teq r0, r7  @ ARM CPU and ARMv6/v7?
-   bne smp_on_up   @ no, assume UP
+   bne fixup_smp_on_up @ no, assume UP
 
orr r6, r6, #0xff00
orr r6, r6, #0x00f0 @ mask 0xff07fff0
@@ -357,7 +357,7 @@ __fixup_smp:
tst r0, #1  31
movne   pc, lr  @ bit 31 = SMP
 
-smp_on_up:
+fixup_smp_on_up:
adr r0, 1f
ldmia   r0, {r3, r6, r7}
sub r3, r0, r3
@@ -373,6 +373,14 @@ ENDPROC(__fixup_smp)
 1: .word   .
.word   __smpalt_begin
.word   __smpalt_end
+
+   .pushsection .data
+   .globl  smp_on_up
+smp_on_up:
+   SMP(.long   1)
+   UP(.long0)
+   .popsection
+
 #endif
 
 #include head-common.S
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d5231ae..fe94467 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include asm/procinfo.h
 #include asm/sections.h
 #include asm/setup.h
+#include asm/smp_plat.h
 #include asm/mach-types.h
 #include asm/cacheflush.h
 #include asm/cachetype.h
@@ -824,9 +825,8 @@ void __init setup_arch(char **cmdline_p)
paging_init(mdesc);
request_standard_resources(meminfo, mdesc);
 
-#ifdef CONFIG_SMP
-   smp_init_cpus();
-#endif
+   if (is_smp())
+   smp_init_cpus();
reserve_crashkernel();
 
cpu_init();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..a789320 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -303,9 +303,8 @@ static void __init build_mem_type_table(void)
cachepolicy = CPOLICY_WRITEBACK;
ecc_mask = 0;
}
-#ifdef CONFIG_SMP
-   cachepolicy = CPOLICY_WRITEALLOC;
-#endif
+   if (is_smp())
+   cachepolicy = CPOLICY_WRITEALLOC;
 
/*
 * Strip out features not present on earlier architectures.
@@ -399,13 +398,11 @@ static void __init build_mem_type_table(void)
cp = cache_policies[cachepolicy];
vecs_pgprot = kern_pgprot = user_pgprot = cp-pte;
 
-#ifndef CONFIG_SMP
/*
 * Only use write-through for non-SMP systems
 */
-   if (cpu_arch = CPU_ARCH_ARMv5  cachepolicy  CPOLICY_WRITETHROUGH)
+   if (!is_smp()  cpu_arch = CPU_ARCH_ARMv5  cachepolicy  
CPOLICY_WRITETHROUGH)
vecs_pgprot = cache_policies[CPOLICY_WRITETHROUGH].pte;
-#endif
 
/*
 * Enable CPU-specific coherency if supported.
@@ -426,20 +423,21 @@ static void __init build_mem_type_table(void)
mem_types[MT_MINICLEAN].prot_sect |= 
PMD_SECT_APX|PMD_SECT_AP_WRITE;
mem_types[MT_CACHECLEAN].prot_sect |= 
PMD_SECT_APX|PMD_SECT_AP_WRITE;
 
-#ifdef CONFIG_SMP
-   /*
-* Mark memory with the shared attribute for SMP systems
-*/
-   user_pgprot |= L_PTE_SHARED;
-   kern_pgprot |= L_PTE_SHARED;
-   vecs_pgprot |= L_PTE_SHARED;
-

Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing

2010-09-06 Thread Bryan Wu 
Tony,

I tried your latest branch: devel-smp-on-unicore, kernel boots up but
got lots of WARN_ON fired:

---
[ cut here ]
[1.149719] WARNING: at mm/percpu-vm.c:320 pcpu_alloc+0x2fc/0x888()
[1.149780] Modules linked in:
[1.149841] [c01b34c8] (unwind_backtrace+0x0/0xe4) from
[c01e939c] (warn_slowpath_common+0x4c/0x64)
[1.149902] [c01e939c] (warn_slowpath_common+0x4c/0x64) from
[c01e93cc] (warn_slowpath_null+0x18/0x1c)
[1.149993] [c01e93cc] (warn_slowpath_null+0x18/0x1c) from
[c0274730] (pcpu_alloc+0x2fc/0x888)
[1.150085] [c0274730] (pcpu_alloc+0x2fc/0x888) from [c0279578]
(sget+0x198/0x43c)
[1.150146] [c0279578] (sget+0x198/0x43c) from [c0279adc]
(get_sb_ns+0x20/0x90)
[1.150238] [c0279adc] (get_sb_ns+0x20/0x90) from [c02791a4]
(vfs_kern_mount+0x9c/0x18c)
[1.150299] [c02791a4] (vfs_kern_mount+0x9c/0x18c) from
[c0022280] (init_mqueue_fs+0x68/0xc8)
[1.150390] [c0022280] (init_mqueue_fs+0x68/0xc8) from
[c01ac5d0] (do_one_initcall+0xcc/0x1a4)
[1.150451] [c01ac5d0] (do_one_initcall+0xcc/0x1a4) from
[c0008760] (kernel_init+0x148/0x210)
[1.150543] [c0008760] (kernel_init+0x148/0x210) from
[c01adcf8] (kernel_thread_exit+0x0/0x8)
[1.150604] ---[ end trace 1b75b31a2719ed74 ]---
---

It looks like we still missed to set some flag for chuck.

-Bryan

On Fri, Sep 3, 2010 at 8:09 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Thursday, September 02, 2010 11:13 PM
 To: Russell King - ARM Linux
 Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
 Bryan Wu; Will Deacon
 Subject: Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early
 init testing

 * Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:00]:
  On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
 
   --- a/arch/arm/include/asm/smp_plat.h
   +++ b/arch/arm/include/asm/smp_plat.h
   @@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
    #define UP(instr...)     _str(instr)
    #endif
  
   +static inline int smp_on_up(void)
   +{
   +#ifdef CONFIG_SMP_ON_UP
   + int smp_on_up;
   +
   + asm(                                                    \
   +         SMP(mov %0, #0)                                 \
   +         UP(mov  %0, #1)                                 \
   +         : =r (smp_on_up));
   +
   + return smp_on_up;
   +#else
   + return 0;
   +#endif
 
  I think this is the wrong approach - rather than a function which tells
 us
  just if we are a SMP kernel running on UP, why not something which
 returns
  whether we're running on SMP and use that to eliminate some of these
 ifdefs?

 Sure. Will has something like this in his patches:

 static inline int cpu_is_part_of_mp_system(void)
 {
       u32 mpidr;
       asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
       return (mpidr  31) ? !(mpidr  30) : 0;
 }

 I guess this register is only available on MP Core extensions.

 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 4/4] ARM: l2x0: Optmise the range based operations

2010-09-06 Thread Catalin Marinas 
On Sat, 2010-07-31 at 23:16 +0530, Santosh Shilimkar wrote:
 For the big buffers which are in excess of cache size, the maintaince
 operations by PA are very slow. For such buffers the maintainace
 operations can be speeded up by using the WAY based method.
 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Catalin Marinas catalin.mari...@arm.com
 ---
  arch/arm/mm/cache-l2x0.c |   95 
 --
  1 files changed, 58 insertions(+), 37 deletions(-)
 
 diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
 index b2938d4..c0d6108 100644
 --- a/arch/arm/mm/cache-l2x0.c
 +++ b/arch/arm/mm/cache-l2x0.c
 @@ -116,6 +116,18 @@ static void l2x0_flush_all(void)
   spin_unlock_irqrestore(l2x0_lock, flags);
  }
  
 +static void l2x0_clean_all(void)
 +{
 + unsigned long flags;
 +
 + /* clean all ways */
 + spin_lock_irqsave(l2x0_lock, flags);
 + writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_WAY);
 + cache_wait(l2x0_base + L2X0_CLEAN_WAY, l2x0_way_mask);

In case you'll base this on top of my PL310 optimisation, you should use
cache_wait_way() as the cache_wait() becomes a no-op.

  static void l2x0_clean_range(unsigned long start, unsigned long end)
  {
 - void __iomem *base = l2x0_base;
 - unsigned long flags;
  
 - spin_lock_irqsave(l2x0_lock, flags);
 - start = ~(CACHE_LINE_SIZE - 1);
 - while (start  end) {
 - unsigned long blk_end = start + min(end - start, 4096UL);
 + if ((end - start) = l2x0_size) {
 + l2x0_clean_all();
 + } else {
 + void __iomem *base = l2x0_base;
 + unsigned long flags, blk_end;

Minor thing - the patch may be cleaner if we use a 'return' instead of
'else' to avoid further indentation (same for the other functions):

if ((end - start) = l2x0_size) {
l2x0_clean_all();
return;
}

Otherwise the patch looks fine to me.

-- 
Catalin

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

Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Russell King - ARM Linux 
Here's my latest patch (which is combined from two patches.)

Tony, could you follow up with patches for anything which is still
required - I think there's two things you've addressed which this
currently misses:

1. not initializing twd_base (I'm not convinced this is safe - rather
   making smp_prepare_cpus() return early is probably a better idea.)
2. __flush_icache_all()

Note that (2) seems to be complicated by the instruction only being
available on ARMv7 and later.

Also note that this should only be used for comparing SMP vs UP versions
of the same architecture - in other words, not ARMv6 vs ARMv6K.

Lastly, what's happening about ARMv6 and ARMv7 processor setup functions?
Are we going to split them into those which need SMP bits twiddled and
those which don't?  If we are going to split them, someone needs to follow
up on this email with patches to do it (preferably to be slotted in
before these changes.)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 836a3e5..11daea0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1166,6 +1166,19 @@ config SMP
 
  If you don't know what to do here, say N.
 
+config SMP_ON_UP
+   bool Allow booting SMP kernel on uniprocessor systems (EXPERIMENTAL)
+   depends on EXPERIMENTAL
+   depends on SMP  !XIP
+   default y
+   help
+ SMP kernels contain instructions which fail on non-SMP processors.
+ Enabling this option allows the kernel to modify itself to make
+ these instructions safe.  Disabling it allows about 1K of space
+ savings.
+
+ If you don't know what to do here, say Y.
+
 config HAVE_ARM_SCU
bool
depends on SMP
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6e8f05c..e2bd8c6 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -154,16 +154,39 @@
.long   b,9001f;\
.popsection
 
+#ifdef CONFIG_SMP
+#define SMP(instr...)  \
+9998:  instr
+#define UP(instr...)   \
+   .pushsection .smpalt.init, a;\
+   .long   9998b   ;\
+   instr   ;\
+   .popsection
+#define UP_B(label)\
+   .equup_b_offset, label - 9998b  ;\
+   .pushsection .smpalt.init, a;\
+   .long   9998b   ;\
+   b   . + up_b_offset ;\
+   .popsection
+#else
+#define SMP(instr...)
+#define UP(instr...) instr
+#define UP_B(label) b label
+#endif
+
 /*
  * SMP data memory barrier
  */
.macro  smp_dmb
 #ifdef CONFIG_SMP
 #if __LINUX_ARM_ARCH__ = 7
-   dmb
+   SMP(dmb)
 #elif __LINUX_ARM_ARCH__ == 6
-   mcr p15, 0, r0, c7, c10, 5  @ dmb
+   SMP(mcr p15, 0, r0, c7, c10, 5) @ dmb
+#else
+#error Incompatible SMP platform
 #endif
+   UP(nop)
 #endif
.endm
 
diff --git a/arch/arm/include/asm/smp_mpidr.h b/arch/arm/include/asm/smp_mpidr.h
new file mode 100644
index 000..18f2117
--- /dev/null
+++ b/arch/arm/include/asm/smp_mpidr.h
@@ -0,0 +1,17 @@
+#ifndef ASMARM_SMP_MIDR_H
+#define ASMARM_SMP_MIDR_H
+
+#define hard_smp_processor_id()
\
+   ({  \
+   unsigned int cpunum;\
+   __asm__(\n\
+   1: mrc p15, 0, %0, c0, c0, 5\n\
+  .pushsection \.smpalt.init\, \a\\n \
+  .long   1b\n   \
+  mov %0, #0\n   \
+  .popsection\
+   : =r (cpunum));   \
+   cpunum = 0x0F; \
+   })
+
+#endif
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index e621530..7de5aa5 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -18,4 +18,19 @@ static inline int cache_ops_need_broadcast(void)
return ((read_cpuid_ext(CPUID_EXT_MMFR3)  12)  0xf)  1;
 }
 
+/*
+ * Return true if we are running on a SMP platform
+ */
+static inline bool is_smp(void)
+{
+#ifndef CONFIG_SMP
+   return false;
+#elif defined(CONFIG_SMP_ON_UP)
+   extern unsigned int smp_on_up;
+   return !!smp_on_up;
+#else
+   return true;
+#endif
+}
+
 #endif
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 33b546a..cf2f018 100644
--- a/arch/arm/include/asm/tlbflush.h
+++

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

2010-09-06 Thread Mark Brown 
On Fri, Sep 03, 2010 at 11:27:50AM -0700, Kevin Hilman wrote:

 In the background Thomas and I will continue to research the changes
 needed in the regulator framework.

These really are fairly straightforward, the algorithm I outlined in my
last mail will do the trick.
--
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 CPUIDLE: CPU Idle latency measurement

2010-09-06 Thread Sripathy, Vishwanath 
Jean,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Jean Pihet
 Sent: Thursday, September 02, 2010 2:39 PM
 To: Shilimkar, Santosh
 Cc: Amit Kucheria; Kevin Hilman; linaro-...@lists.linaro.org; linux-
 o...@vger.kernel.org
 Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
 
 Hi Amit, Santosh,
 
 On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
 ...
   The point is to keep the minimum possible in the kernel: just the
   tracepoints we're interested in.   The rest (calculations, averages,
   analysis, etc.) does not need to be in the kernel and can be done easier
   and with more powerful tools outside the kernel.
 
  Kevin,
 
  I agree. We discussed this a little in our weekly meeting. Vishwa's main
  concern was the lack of ability to instrument the last bit of SRAM code.
 
  I have a feeling that even with caches on when we enter this code, we
  won't
  see too much variance in the latency to execute this bit of code. Vishwa
  is
  going to confirm that now. If that hypothesis is true, we can indeed move
  to
  using tracepoints in the idle path and use external tools to track latency.
 I agree. Can you confirm this asap?

I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst case 
it takes around 3.28ms and best case around 2.93ms for mpu off mode. For MPU 
INACTIVE/RET, it is less than 30us. 
However as Kevin mentioned in other email, it would be better to find out a way 
to trace inside assembly code as well.

Regards
Vishwa
 I am looking at the instrumentation tracepoints now. I think it would
 be ideal to provide multiple tracepoints in both sleep and wake-up
 paths.
 
  There will be difference with and without caches but the delta latency will 
  be
 constant with caches and without caches. Another important point is
  he lowest level code should be just profiled once and for worst CPU/BUS 
  clock
 speed.
 Ok.
 
  Even if it isn't true, the rest of the idle path could still contain
  tracepoints.
 I am looking at the best way to introduce tracepoints in the low level
 code, in case it is needed.
 
  I also think this would be better approach considering a generic solution.
 Good!
 
 
  Regards,
  Santosh
 
 
 Jean
 --
 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 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP

2010-09-06 Thread Catalin Marinas 
Russell,

I can see you posted another version while writing this e-mail. But I
think most comments still apply. 

On Fri, 2010-09-03 at 10:10 +0100, Russell King - ARM Linux wrote:
 diff --git a/arch/arm/include/asm/assembler.h 
 b/arch/arm/include/asm/assembler.h
 index 6e8f05c..55974d2 100644
 --- a/arch/arm/include/asm/assembler.h
 +++ b/arch/arm/include/asm/assembler.h
 @@ -154,16 +154,32 @@
 .long   b,9001f;\
 .popsection
 
 +#ifdef CONFIG_SMP
 +#define SMP(instr...)  \
 +9998:  instr
 +#define UP(instr...)   \
 +   .pushsection .smpalt.init, a;\
 +   .word   9998b   ;\
 +   instr   ;\
 +   .popsection
 +#else
 +#define SMP(instr...)
 +#define UP(instr...) instr
 +#endif

Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr)
in the SMP/UP macros to make sure that the instruction is always 32-bit
wide.

 diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
 index bb8e93a..bb2ef60 100644
 --- a/arch/arm/kernel/entry-armv.S
 +++ b/arch/arm/kernel/entry-armv.S
 @@ -965,11 +965,8 @@ kuser_cmpxchg_fixup:
 beq 1b
 rsbsr0, r3, #0
 /* beware -- each __kuser slot must be 8 instructions max */
 -#ifdef CONFIG_SMP
 -   b   __kuser_memory_barrier
 -#else
 -   usr_ret lr
 -#endif
 +   SMP(b   __kuser_memory_barrier)
 +   UP(usr_ret  lr)

Ah, the automatic W() I mentioned above wouldn't work for macros.

 @@ -333,4 +336,35 @@ __create_page_tables:
  ENDPROC(__create_page_tables)
 .ltorg
 
 +#ifdef CONFIG_SMP_ON_UP
 +__fixup_smp:
 +   and r0, r9, #0xff00
 +   teq r0, #0x4100 @ ARM CPU?
 +   bne smp_on_up   @ no, assume UP

That's a bit restricting but I'm not sure we have a better way. If we
have the new CPUID format (MIDR[19:16] = 0xf), we can check MMFR0[31:28]
for 1 which means implemented with hardware coherency support.

 +   and r0, r9, #0x0007
 +   teq r0, #0x0007 @ ARMv6/v7?
 +   bne smp_on_up   @ no, assume UP
 +   mrc p15, 0, r0, c0, c0, 5   @ read MIDR

Typo in comment - MPIDR.

I think this applies to the smp_midr.h file. Should we call it
smp_mpidr.h or just mpidr.h?

 +   movsr0, r0, lsr #30
 +   teqne   r0, #3  @ check top two bits 00 or 11
 +   movne   pc, lr
 +
 +smp_on_up:
 +   adr r0, 1f
 +   ldmia   r0, {r3, r6, r7}
 +   sub r3, r0, r3
 +   add r6, r6, r3
 +   add r7, r7, r3
 +2: cmp r6, r7
 +   ldmia   r6!, {r0, r4}
 +   movhs   pc, lr
 +   str r4, [r0, r3]
 +   b   2b
 +ENDPROC(__fixup_smp)
 +
 +1: .word   .
 +   .word   __smpalt_begin
 +   .word   __smpalt_end

I think a '.align 2' would be useful as Thumb-2 code may break the
alignment of 1f.

-- 
Catalin

--
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 v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-06 Thread Russell King - ARM Linux 
On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
 2010/9/1 Ohad Ben-Cohen o...@wizery.com:
  Add a simple mechanism to pass platform data to the
  SDIO instances of wl12xx.
 
  This way there is no confusion over who owns the 'embedded data',
  typechecking is preserved, and no possibility for the wrong driver to
  pick up the data.
 
  Originally proposed by Russell King.
 
  Signed-off-by: Ohad Ben-Cohen o...@wizery.com
  ---
   drivers/net/wireless/Makefile                      |    2 +
   drivers/net/wireless/wl12xx/Kconfig                |    5 ++-
   drivers/net/wireless/wl12xx/wl12xx_platform_data.c |   31 
  
   include/linux/wl12xx.h                             |    3 ++
   4 files changed, 40 insertions(+), 1 deletions(-)
   create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
 
  diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
  index 5d4ce4d..85af697 100644
  --- a/drivers/net/wireless/Makefile
  +++ b/drivers/net/wireless/Makefile
  @@ -50,5 +50,7 @@ obj-$(CONFIG_ATH_COMMON)      += ath/
   obj-$(CONFIG_MAC80211_HWSIM)   += mac80211_hwsim.o
 
   obj-$(CONFIG_WL12XX)   += wl12xx/
  +# small builtin driver bit
  +obj-$(CONFIG_WL12XX_PLATFORM_DATA)     += wl12xx/wl12xx_platform_data.o
 
   obj-$(CONFIG_IWM)      += iwmc3200wifi/
  diff --git a/drivers/net/wireless/wl12xx/Kconfig 
  b/drivers/net/wireless/wl12xx/Kconfig
  index 2f98058..4a8bb25 100644
  --- a/drivers/net/wireless/wl12xx/Kconfig
  +++ b/drivers/net/wireless/wl12xx/Kconfig
  @@ -74,4 +74,7 @@ config WL1271_SDIO
           If you choose to build a module, it'll be called
           wl1271_sdio. Say N if unsure.
 
  -
  +config WL12XX_PLATFORM_DATA
  +       bool
  +       depends on WL1271_SDIO != n
  +       default y
  diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c 
  b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
  new file mode 100644
  index 000..e00973b
  --- /dev/null
  +++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
  @@ -0,0 +1,31 @@
  +#include linux/module.h
  +#include linux/wl12xx.h
  +
  +static struct wl12xx_platform_data *platform_data;
  +
  +int __init wl12xx_set_platform_data(const struct wl12xx_platform_data 
  *data)
  +{
  +       if (platform_data)
  +               return -EBUSY;
  +       if (!data)
  +               return -EINVAL;
  +
  +       platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
  +       if (!platform_data)
  +               return -ENOMEM;
  +
  +       return 0;
  +}
  +
  +int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
  +{
  +       if (!platform_data)
  +               return -ENODEV;
  +       if (!data)
  +               return -EINVAL;
  +
  +       memcpy(data, platform_data, sizeof(*data));
  +
  +       return 0;
  +}
  +EXPORT_SYMBOL(wl12xx_get_platform_data);
  diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
  index 137ac89..3e33ae1 100644
  --- a/include/linux/wl12xx.h
  +++ b/include/linux/wl12xx.h
  @@ -31,4 +31,7 @@ struct wl12xx_platform_data {
         bool use_eeprom;
   };
 
  +int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
  +int wl12xx_get_platform_data(struct wl12xx_platform_data *data);
  +
   #endif
 
 Why do you need all that copying? Isn't the data constant?

The first copy is to allow platforms to have their data marked with
__initdata.  The second copy probably isn't necessary, but avoids
problems where the driver may decide to modify the platform data.

We could instead make wl12xx_get_platform_data() return a const pointer
to its own internal storage instead, or ERR pointers for the various
failure cases.
--
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] OMAP: DSS2: Framework to handle omap version specific DSS features

2010-09-06 Thread Taneja, Archit 
Hi,

Could you comment on the dss_feature patches? I can start reworking the 
floating omap4
patches with this finalized :)

Thanks,

Archit

Taneja, Archit wrote:
 This is a simple approach to prevent scattered
 cpu_is_omap checks in DSS2 by bringing all omap version
 specific DSS features/values to one single place, initialize
 them and expose a set of functions to DSS2 driver files which
 return the value/existance of a feature.
 
 This method provides the following:
   -A set of functions which give the value of a feature.
   -Functions which add and return the start and end bits of a register field
which varies across omaps.
   -A function which checks if a DSS2 feature exists or not on the present
omap (omap_dss_has_feature)
 
 Whenever a new DSS feature is introduced, its value/existance
 is specified for all omaps in omap_dss_feature_init().
 
 This patch also fills up a minimal list of features in
 omap_dss_features_init(). The second patch in the series makes use of
 dss_features to remove some of the existing omap checks.
 
 Archit Taneja (2):
   OMAP: DSS2: Introduce dss_features files
   OMAP: DSS2: Use dss_features framework on DSS2 code
 
  arch/arm/plat-omap/include/plat/display.h |   31 -
  drivers/video/omap2/dss/Makefile  |2 +-
  drivers/video/omap2/dss/core.c|5 +
  drivers/video/omap2/dss/dispc.c   |   56 +
  drivers/video/omap2/dss/dss_features.c|  197
 +
  drivers/video/omap2/dss/dss_features.h|   48 +++
  drivers/video/omap2/dss/manager.c |   33 +++---
  drivers/video/omap2/dss/overlay.c |   24 ++--
  8 files changed, 308 insertions(+), 88 deletions(-)  create
 mode 100644 drivers/video/omap2/dss/dss_features.c
  create mode 100644 drivers/video/omap2/dss/dss_features.h--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1

2010-09-06 Thread Gadiyar, Anand 
tom.leim...@gmail.com wrote:
 
 From: Ming Lei tom.leim...@gmail.com
 
 This patch fixes one bugs of OUT transfer in double buffer case:
 
 -the current code only enable autoclear for dma mode 1, and not
 for dma mode 0
 
 Without this patch, test #5 of usbtest can't be passed if we
 configure musb as g_zero and use fifo mode 3 to enable double
 buffer mode.
 
 With this patch and the following patch(fix dma length),
 on my beagle B5, test#5(queued bulk out) may go beyond
 18Mbyte/s(seems dma mode 0 is quicker in double buffer case)
 if musb is configured as g_zero and fifo mode 3 is taken, follows
 the test command:
 
 #./testusb -D DEV_NAME -c 1024 -t 5 -s 32768 -g 8   [1]
 
 Also I have tested this patch can't make g_ether broken.
 
 [1],
 -source of testusb : tools/usb/testusb.c under linux kernel;
 
 Signed-off-by: Ming Lei tom.leim...@gmail.com
 Cc: Anand Gadiyar gadi...@ti.com
 Cc: Mike Frysinger vap...@gentoo.org
 Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
 ---
  drivers/usb/musb/musb_gadget.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
 index e0bd1c1..c0dfec4 100644
 --- a/drivers/usb/musb/musb_gadget.c
 +++ b/drivers/usb/musb/musb_gadget.c
 @@ -645,9 +645,9 @@ static void rxstate(struct musb *musb, struct 
 musb_request *req)
*/
  
   csr |= MUSB_RXCSR_DMAENAB;
 -#ifdef USE_MODE1
   if (!musb_ep-hb_mult)
   csr |= MUSB_RXCSR_AUTOCLEAR;

Hi Tom,

Which codebase is this patch meant for?
I don't see the hb_mult in current mainline code?

Are there any patches which this one depends on?

Thanks,
Anand

 +#ifdef USE_MODE1
   /* csr |= MUSB_RXCSR_DMAMODE; */
  
   /* this special sequence (enabling and then
--
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] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1

2010-09-06 Thread Ming Lei 
2010/9/6 Gadiyar, Anand gadi...@ti.com:
 Hi Tom,

 Which codebase is this patch meant for?
 I don't see the hb_mult in current mainline code?

 Are there any patches which this one depends on?

This depends on the two iso for device mode patches:
 http://marc.info/?l=linux-usbm=128076716001885w=2
 http://marc.info/?l=linux-usbm=128076716901924w=2

I plan to resend the two patches above and the double buffer patches
later.

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: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Catalin Marinas 
Russell,

On Mon, 2010-09-06 at 11:44 +0100, Russell King - ARM Linux wrote:
 +#ifdef CONFIG_SMP_ON_UP
 +__fixup_smp:
 +   mov r7, #0x0007
 +   orr r6, r7, #0xff00 @ mask 0xff07
 +   orr r7, r7, #0x4100 @ val 0x4107
 +   and r0, r9, r6
 +   teq r0, r7  @ ARM CPU and ARMv6/v7?
 +   bne __fixup_smp_on_up   @ no, assume UP
 +
 +   orr r6, r6, #0xff00
 +   orr r6, r6, #0x00f0 @ mask 0xff07fff0
 +   orr r7, r7, #0xb000
 +   orr r7, r7, #0x0020 @ val 0x4107b020
 +   and r0, r9, r6
 +   teq r0, r7  @ ARM 11MPCore?
 +   moveq   pc, lr  @ yes, assume SMP
 +
 +   mrc p15, 0, r0, c0, c0, 5   @ read MIDR
 +   tst r0, #1  31
 +   movne   pc, lr  @ bit 31 = SMP

An alternative would be to check for hardware coherency support in the
shareability domain using the MMFR0 register. If we have the new CPUID
format (all MP systems):

if (ID_MMFR015:12 == 0) 
HWCoherency = (ID_MMFR011:8 == 1)
else 
HWCoherency = (ID_MMFR031:28 == 1)

The hw coherency is built for MP systems and this register should be
valid for both ARMv6 and ARMv7 configurations.

Something like below, untested:

mov r6, #0x000f @ mask/val new CPUID
and r0, r9, r6
teq r0, r6  @ ARMv6/v7 new CPUID
bne __fixup_smp_on_up   @ no, assume UP

mrc p15, 0, r0, c0, c1, 4   @ MMFR0
mov r6, #0xf000 @ mask shareability levels
tst r0, r6
moveq   r0, r0, lsr #8  @ outermost shareability
movne   r0, r0, lsr #28 @ innermost shareability
and r0, r0, #15
cmp r0, #1  @ check hw coherency support
bne __fixup_smp_on_up   @ no, assume UP

We still cannot optimise the case where you have an MP capable processor
but in a UP-only configuration (maxcpus=1).

For the availability of the Inner Shareable cache and TLB operations, we
would need to check for the MMFR315:12 bits.

-- 
Catalin

--
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] USB: otg: twl4030: fix phy initialization(v1)

2010-09-06 Thread tom . leiming 
From: Ming Lei tom.leim...@gmail.com

Commit 461c317705eca5cac09a360f488715927fd0a927(into 2.6.36-v3)
is put forward to power down phy if no usb cable is connected,
but does introduce the two issues below:

1), phy is not into work state if usb cable is connected
with PC during poweron, so musb device mode is not usable
in such case, follows the reasons:
-twl4030_phy_resume is not called, so
regulators are not enabled
i2c access are not enabled
usb mode not configurated

2), The kernel warings[1] of regulators 'unbalanced disables'
is caused if poweron without usb cable connected
with PC or b-device.

This patch fixes the two issues above:
-power down phy only if no usb cable is connected with PC
and b-device
-do phy initialization(via __twl4030_phy_resume) if usb cable
is connected with PC(vbus event) or another b-device(ID event) in
twl4030_usb_probe.

This patch also doesn't put VUSB3V1 LDO into active mode in
twl4030_usb_ldo_init until VBUS/ID change detected, so we can
save more power consumption than before.

This patch is verified OK on Beagle board either connected with
usb cable or not when poweron.

[1]. warnings of 'unbalanced disables' of regulators.
[r...@omap3evm /]# dmesg
[ cut here ]
WARNING: at drivers/regulator/core.c:1357 _regulator_disable+0x38/0x128()
unbalanced disables for VUSB1V8
Modules linked in:
Backtrace:
[c0030c48] (dump_backtrace+0x0/0x110) from [c034f5a8] (dump_stack+0x18/0x1c)
 r7:c78179d8 r6:c01ed6b8 r5:c0410822 r4:054d
[c034f590] (dump_stack+0x0/0x1c) from [c0057da8] 
(warn_slowpath_common+0x54/0x6c)
[c0057d54] (warn_slowpath_common+0x0/0x6c) from [c0057e64] 
(warn_slowpath_fmt+0x38/0x40)
 r9: r8: r7:c78e6608 r6: r5:fffb
r4:c78e6c00
[c0057e2c] (warn_slowpath_fmt+0x0/0x40) from [c01ed6b8] 
(_regulator_disable+0x38/0x128)
 r3:c0410e53 r2:c0410ad5
[c01ed680] (_regulator_disable+0x0/0x128) from [c01ed87c] 
(regulator_disable+0x24/0x38)
 r7:c78e6608 r6: r5:c78e6c40 r4:c78e6c00
[c01ed858] (regulator_disable+0x0/0x38) from [c02382dc] 
(twl4030_phy_power+0x15c/0x17c)
 r5:c78595c0 r4:
[c0238180] (twl4030_phy_power+0x0/0x17c) from [c023831c] 
(twl4030_phy_suspend+0x20/0x2c)
 r6: r5:c78595c0 r4:c78595c0
[c02382fc] (twl4030_phy_suspend+0x0/0x2c) from [c0238638] 
(twl4030_usb_irq+0x11c/0x16c)
 r5:c78595c0 r4:0040
[c023851c] (twl4030_usb_irq+0x0/0x16c) from [c034ec18] 
(twl4030_usb_probe+0x2c4/0x32c)
 r6: r5: r4:c78595c0
[c034e954] (twl4030_usb_probe+0x0/0x32c) from [c02152a0] 
(platform_drv_probe+0x20/0x24)
 r7: r6:c047d49c r5:c78e6608 r4:c047d49c
[c0215280] (platform_drv_probe+0x0/0x24) from [c0214244] 
(driver_probe_device+0xd0/0x190)
[c0214174] (driver_probe_device+0x0/0x190) from [c02143d4] 
(__device_attach+0x44/0x48)
 r7: r6:c78e6608 r5:c78e6608 r4:c047d49c
[c0214390] (__device_attach+0x0/0x48) from [c0213694] 
(bus_for_each_drv+0x50/0x90)
 r5:c0214390 r4:
[c0213644] (bus_for_each_drv+0x0/0x90) from [c0214474] 
(device_attach+0x70/0x94)
 r6:c78e663c r5:c78e6608 r4:c78e6608
[c0214404] (device_attach+0x0/0x94) from [c02134fc] 
(bus_probe_device+0x2c/0x48)
 r7: r6:0002 r5:c78e6608 r4:c78e6600
[c02134d0] (bus_probe_device+0x0/0x48) from [c0211e48] 
(device_add+0x340/0x4b4)
[c0211b08] (device_add+0x0/0x4b4) from [c021597c] 
(platform_device_add+0x110/0x16c)
[c021586c] (platform_device_add+0x0/0x16c) from [c0220cb0] 
(add_numbered_child+0xd8/0x118)
 r7: r6:c045f15c r5:c78e6600 r4:
[c0220bd8] (add_numbered_child+0x0/0x118) from [c001c618] 
(twl_probe+0x3a4/0x72c)
[c001c274] (twl_probe+0x0/0x72c) from [c02601ac] 
(i2c_device_probe+0x7c/0xa4)
[c0260130] (i2c_device_probe+0x0/0xa4) from [c0214244] 
(driver_probe_device+0xd0/0x190)
 r5:c7856e20 r4:c047c860
[c0214174] (driver_probe_device+0x0/0x190) from [c02143d4] 
(__device_attach+0x44/0x48)
 r7:c7856e04 r6:c7856e20 r5:c7856e20 r4:c047c860
[c0214390] (__device_attach+0x0/0x48) from [c0213694] 
(bus_for_each_drv+0x50/0x90)
 r5:c0214390 r4:
[c0213644] (bus_for_each_drv+0x0/0x90) from [c0214474] 
(device_attach+0x70/0x94)
 r6:c7856e54 r5:c7856e20 r4:c7856e20
[c0214404] (device_attach+0x0/0x94) from [c02134fc] 
(bus_probe_device+0x2c/0x48)
 r7:c7856e04 r6:c78fd048 r5:c7856e20 r4:c7856e20
[c02134d0] (bus_probe_device+0x0/0x48) from [c0211e48] 
(device_add+0x340/0x4b4)
[c0211b08] (device_add+0x0/0x4b4) from [c0211fd8] 
(device_register+0x1c/0x20)
[c0211fbc] (device_register+0x0/0x20) from [c0260aa8] 
(i2c_new_device+0xec/0x150)
 r5:c7856e00 r4:c7856e20
[c02609bc] (i2c_new_device+0x0/0x150) from [c0260dc0] 
(i2c_register_adapter+0xa0/0x1c4)
 r7: r6:c78fd078 r5:c78fd048 r4:c781d5c0
[c0260d20] (i2c_register_adapter+0x0/0x1c4) from [c0260f80] 
(i2c_add_numbered_adapter+0x9c/0xb4)
 r7:0a28 r6:c04600a8 r5:c78fd048 r4:
[c0260ee4] (i2c_add_numbered_adapter+0x0/0xb4) from [c034efa4]

Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling

2010-09-06 Thread kishore kadiyala 
Hi Benoit,

On Fri, Sep 3, 2010 at 1:51 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
 Hi Benoit

 snip

 +               while (!(omap_readl(base + reg_off)
                          MMCHS_SYSSTATUS_RESETDONE))
                         cpu_relax();

 Why does that series not seems to be based on your hwmod migration? The
 reset is fully handle by the hwmod framework now.

 Agree. But Kevin has  suggested to post this patch  independent of hwmod.
 Does this patch has to go in hwmod series ?


 BTW, when do you have to apply a reset in your case? Do you have the need
 for an API accessible by the driver?
 I'm asking because for the moment the framework does not expose the reset
 API and use it only at init time.

 Correct , I don't need reset API access in the driver.

One correction here , in case of context restore , driver does
software reset apart from
the initial reset. So reset is required and so both the tables needs
registers SYSCONFIG and
SYSSTATUS. In which case  offset deviation of 0x100 can't be maintained.

Regards,
Kishore

 snip


 +enum {
 +       OMAP_HSMMC_SYSCONFIG = 0,
 +       OMAP_HSMMC_SYSSTATUS,
 +       OMAP_HSMMC_CON,
 +       OMAP_HSMMC_BLK,
 +       OMAP_HSMMC_ARG,
 +       OMAP_HSMMC_CMD,
 +       OMAP_HSMMC_RSP10,
 +       OMAP_HSMMC_RSP32,
 +       OMAP_HSMMC_RSP54,
 +       OMAP_HSMMC_RSP76,
 +       OMAP_HSMMC_DATA,
 +       OMAP_HSMMC_PSTATE,
 +       OMAP_HSMMC_HCTL,
 +       OMAP_HSMMC_SYSCTL,
 +       OMAP_HSMMC_STAT,
 +       OMAP_HSMMC_IE,
 +       OMAP_HSMMC_ISE,
 +       OMAP_HSMMC_CAPA,
 +       OMAP_HSMMC_REV,
 +       OMAP_HSMMC_CUR_CAPA,
 +       OMAP_HSMMC_FE,
 +       OMAP_HSMMC_ADMA_ES,
 +       OMAP_HSMMC_ADMA_SAL,
 +};
 +
 +static const u16 omap3_mmc_reg_map[] = {
 +       [OMAP_HSMMC_SYSCONFIG] = 0x0010,
 +       [OMAP_HSMMC_SYSSTATUS] = 0x0014,
 +       [OMAP_HSMMC_CON] = 0x002C,
 +       [OMAP_HSMMC_BLK] = 0x0104,
 +       [OMAP_HSMMC_ARG] = 0x0108,
 +       [OMAP_HSMMC_CMD] = 0x010C,
 +       [OMAP_HSMMC_RSP10] = 0x0110,
 +       [OMAP_HSMMC_RSP32] = 0x0114,
 +       [OMAP_HSMMC_RSP54] = 0x0118,
 +       [OMAP_HSMMC_RSP76] = 0x011C,
 +       [OMAP_HSMMC_DATA] = 0x0120,
 +       [OMAP_HSMMC_PSTATE] = 0x0124,
 +       [OMAP_HSMMC_HCTL] = 0x0128,
 +       [OMAP_HSMMC_SYSCTL] = 0x012C,
 +       [OMAP_HSMMC_STAT] = 0x0130,
 +       [OMAP_HSMMC_IE] = 0x0134,
 +       [OMAP_HSMMC_ISE] = 0x0138,
 +       [OMAP_HSMMC_CAPA] = 0x0140,
 +       [OMAP_HSMMC_REV] = 0x01FC,
 +};
 +
 +static const u16 omap4_mmc_reg_map[] = {
 +       [OMAP_HSMMC_SYSCONFIG] = 0x0010,        /* Use Highlander Version
 */
 +       [OMAP_HSMMC_SYSSTATUS] = 0x0114,

 In fact that sysstatus is a legacy register that is not needed anymore in
 the highlander version. The resetdone is in the sysconfig now.
 So you can ignore it in OMAP4.

 Just verified and thanks for pointing this.
 ok will avoid checking resetdone in sysstatus for OMAP4


 +       [OMAP_HSMMC_CON] = 0x012C,
 +       [OMAP_HSMMC_BLK] = 0x0204,
 +       [OMAP_HSMMC_ARG] = 0x0208,
 +       [OMAP_HSMMC_CMD] = 0x020C,
 +       [OMAP_HSMMC_RSP10] = 0x0210,
 +       [OMAP_HSMMC_RSP32] = 0x0214,
 +       [OMAP_HSMMC_RSP54] = 0x0218,
 +       [OMAP_HSMMC_RSP76] = 0x021C,
 +       [OMAP_HSMMC_DATA] = 0x0220,
 +       [OMAP_HSMMC_PSTATE] = 0x0224,
 +       [OMAP_HSMMC_HCTL] = 0x0228,
 +       [OMAP_HSMMC_SYSCTL] = 0x022C,
 +       [OMAP_HSMMC_STAT] = 0x0230,
 +       [OMAP_HSMMC_IE] = 0x0234,
 +       [OMAP_HSMMC_ISE] = 0x0238,
 +       [OMAP_HSMMC_CAPA] = 0x0240,
 +       [OMAP_HSMMC_REV] = 0x,      /* Use Highlander Version */
 +       [OMAP_HSMMC_CUR_CAPA] = 0x0248,
 +       [OMAP_HSMMC_FE] = 0x0250,
 +       [OMAP_HSMMC_ADMA_ES] = 0x0254,
 +       [OMAP_HSMMC_ADMA_SAL] = 0x0258,

 I didn't check all the registers, but it seems that there is a constant
 0x100 offset for most of these registers. Cannot you simplify this table?

 Sure will simplify and post.


 Regards,
 Benoit


 snip

 Regards,
 Kishore

--
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 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP

2010-09-06 Thread Catalin Marinas 
On Mon, 2010-09-06 at 16:34 +0100, Russell King - ARM Linux wrote:
 On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote:
  Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr)
  in the SMP/UP macros to make sure that the instruction is always 32-bit
  wide.
 
 Probably not, and it's not obvious how to make it work for T2 kernel
 builds.  For the time being, I'm going to make this available only for
 native ARM builds.  We can think about how to make this work for T2
 sometime later.
[...]
 Indeed, that's only half of the problem.  On T2, some of these may be
 16-bit values, others may be 32-bit values, and this mechanism has no
 way to know the size of the areas.

We can add the W() macro and they are guaranteed to be 32-bit wide or
get a compilation error. Something like using UP(W(nop)), though it's
doesn't look as nice.

The usr_ret macro is always compiled to ARM mode anyway.

It may be easier to do it in this patch patch rather than at a later
time trying to grep for SMP/UP macros.

-- 
Catalin

--
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] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1

2010-09-06 Thread Sergei Shtylyov 

Hello.

Ming Lei wrote:


Which codebase is this patch meant for?
I don't see the hb_mult in current mainline code?



Are there any patches which this one depends on?



This depends on the two iso for device mode patches:
 http://marc.info/?l=linux-usbm=128076716001885w=2
 http://marc.info/?l=linux-usbm=128076716901924w=2



I plan to resend the two patches above and the double buffer patches
later.


   I recommend that you change the ordering of patches so that fixes come 
first, and new features last. I.e. this patch should precede the second one of 
those two above.



thanks,


WBR, Sergei
--
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 CPUIDLE: CPU Idle latency measurement

2010-09-06 Thread Jean Pihet 
Hi Vishwa,

On Mon, Sep 6, 2010 at 1:15 PM, Sripathy, Vishwanath
vishwanath...@ti.com wrote:
 I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst 
 case it takes around 3.28ms and best case around 2.93ms for mpu off mode.
Can you give a bit more details? Which measurement has been taken (ASM
only, sleep, wake-up ...?) and what are the significant figures?

For MPU INACTIVE/RET, it is less than 30us.
Mmh that is the resolution of the 32kHz timer, so I guess you get
either 0 or 1 timer cycle depending when you start the measurement.
IMO the 32kHz timer is too slow to measure those fast events.

 However as Kevin mentioned in other email, it would be better to find out a 
 way to trace inside assembly code as well.
OK that could be done but first I would like to make sure such a
complication is  needed.


 Regards
 Vishwa

Jean
--
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 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP

2010-09-06 Thread Russell King - ARM Linux 
On Mon, Sep 06, 2010 at 04:53:47PM +0100, Catalin Marinas wrote:
 On Mon, 2010-09-06 at 16:34 +0100, Russell King - ARM Linux wrote:
  On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote:
   Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr)
   in the SMP/UP macros to make sure that the instruction is always 32-bit
   wide.
  
  Probably not, and it's not obvious how to make it work for T2 kernel
  builds.  For the time being, I'm going to make this available only for
  native ARM builds.  We can think about how to make this work for T2
  sometime later.
 [...]
  Indeed, that's only half of the problem.  On T2, some of these may be
  16-bit values, others may be 32-bit values, and this mechanism has no
  way to know the size of the areas.
 
 We can add the W() macro and they are guaranteed to be 32-bit wide or
 get a compilation error. Something like using UP(W(nop)), though it's
 doesn't look as nice.
 
 The usr_ret macro is always compiled to ARM mode anyway.

That's not the only place - here's another:

+   ALT_SMP(test_for_ipi r0, r6, r5, lr)
+   ALT_UP_B(9997f)

test_for_ipi may be thumb code, which could be 16-bit aligned.
--
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 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP

2010-09-06 Thread Catalin Marinas 
On Mon, 2010-09-06 at 17:36 +0100, Russell King - ARM Linux wrote:
 On Mon, Sep 06, 2010 at 04:53:47PM +0100, Catalin Marinas wrote:
  On Mon, 2010-09-06 at 16:34 +0100, Russell King - ARM Linux wrote:
   On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote:
Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr)
in the SMP/UP macros to make sure that the instruction is always 32-bit
wide.
  
   Probably not, and it's not obvious how to make it work for T2 kernel
   builds.  For the time being, I'm going to make this available only for
   native ARM builds.  We can think about how to make this work for T2
   sometime later.
  [...]
   Indeed, that's only half of the problem.  On T2, some of these may be
   16-bit values, others may be 32-bit values, and this mechanism has no
   way to know the size of the areas.
 
  We can add the W() macro and they are guaranteed to be 32-bit wide or
  get a compilation error. Something like using UP(W(nop)), though it's
  doesn't look as nice.
 
  The usr_ret macro is always compiled to ARM mode anyway.
 
 That's not the only place - here's another:
 
 +   ALT_SMP(test_for_ipi r0, r6, r5, lr)
 +   ALT_UP_B(9997f)
 
 test_for_ipi may be thumb code, which could be 16-bit aligned.

The branch can be 16-bit aligned as well but we would have to change the
fixup loop for Thumb-2 to load/store 2 half-words and avoid an alignment
fault.

Anyway, I agree that for now we should get the ARM builds working and we
can change the Thumb-2 afterwards, as time allows. It doesn't look like
something fundamental would prevent this.

-- 
Catalin

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

Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7

2010-09-06 Thread Tony Lindgren 
* Russell King - ARM Linux li...@arm.linux.org.uk [100906 03:36]:
 Here's my latest patch (which is combined from two patches.)
 
 Tony, could you follow up with patches for anything which is still
 required - I think there's two things you've addressed which this
 currently misses:
 
 1. not initializing twd_base (I'm not convinced this is safe - rather
making smp_prepare_cpus() return early is probably a better idea.)
 2. __flush_icache_all()
 
 Note that (2) seems to be complicated by the instruction only being
 available on ARMv7 and later.

Yeah will check probably on Tuesday, heading to a BBQ as it's a holiday
here. Also my laptop cooling fan broke a few days ago, got it patched up
temporarily though: An external fan duct taped to the side of the machine
until the replacement arrives :)
 
 Also note that this should only be used for comparing SMP vs UP versions
 of the same architecture - in other words, not ARMv6 vs ARMv6K.

Right, ARMv6 vs ARMv6K can be dealt with in another patch once this
is done.
 
 Lastly, what's happening about ARMv6 and ARMv7 processor setup functions?
 Are we going to split them into those which need SMP bits twiddled and
 those which don't?  If we are going to split them, someone needs to follow
 up on this email with patches to do it (preferably to be slotted in
 before these changes.)

No need to split them any longer AFAIK. Or do you have some case in mind
that's not being handled now, maybe I don't follow you?

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

[PATCH] USB: otg: twl4030: fix phy initialization(v1)

2010-09-06 Thread venki kaps 
Dear USB experts,

  Is the same fix valid for omap3430 + 2.6.32 Kernel?

  I have been facing mp3 playback idle current consumption 20mA more
after booting without USB cable connected
  but If USB cable detach and attach happen, then able to hit proper
values otherwise irrespective of cold/warm reset
  the current values increases to 20mA.

  with cable,
  OTG_SYSCONFIG standby mode of operation - SMART idle
  HSOTGUSB_STANDBY - SMART standby

  without cable,
OTG_SYSCONFIG standby mode of operation - SMART idle
HSOTGUSB_STANDBY - Active

  Even i have applied  patch but still the same issue.

  If i use __twl4030_phy_power(twl, 0) at the end of USB LDO initialization,
  then able to hit proper values but USB ADC values are getting in correct
  with Travel adapter (Charger power supply) which means temperature
  shows 84 instead of 26~30 degrees.

  Queries,
  ---
   - Is Errata 1.164 fix : OTG idle will work on 3430?
   - USBOTG_SUSPEND is enabled in Kernel 32, will it give any impact?
   - Is there anything missed from Power management idle path (or)
USB OTG controller/Transreceiver driver part?

  Could you please provide the best approach to solve my issue?

  Best Regards,
  Venkappa
--
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 v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-06 Thread Michał Mirosław 
W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
li...@arm.linux.org.uk napisał:
 On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
 2010/9/1 Ohad Ben-Cohen o...@wizery.com:
  Add a simple mechanism to pass platform data to the
  SDIO instances of wl12xx.
[cut patch]
 Why do you need all that copying? Isn't the data constant?

 The first copy is to allow platforms to have their data marked with
 __initdata.  The second copy probably isn't necessary, but avoids
 problems where the driver may decide to modify the platform data.

Sorry for pushing at this, but why would you mark data that's meant to
be used after init phase as __initdata?

Best Regards,
Michał Mirosław
--
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/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-09-06 Thread Eduardo Valentin 
Hello,

On Fri, Sep 03, 2010 at 08:20:52PM +0200, Mark Brown wrote:
 On Fri, Sep 03, 2010 at 11:00:31AM -0700, Kevin Hilman wrote:
  Mark Brown broo...@opensource.wolfsonmicro.com writes:
 
   The only thing I can think you might need to do if this is just straight
   voltage setting is re-add support for multiple consumers setting
   voltages simultaneously 
 
  Yeah, that sounds like what we need.
 
  re-add? was it there at one point and removed?  Any pointers to the old
  code?
 
 It was present in the pre-merge regulator API which you can find in the
 bowels of:
 
git://opensource.wolfsonmicro.com/linux-2.6-audioplus
 
 but was removed to simplify review during the merge.  It's fairly simple
 to do, it's just that there's been no demand.
 
 Essentially all that needs doing is that when regulator_set_voltage() is
 called instead of merging with the machine constraints and applying the
 setting immediately we store the constraints that are specified in the
 consumer then iterate over all enabled consumers applying all the
 constraints that they've set in addition to those from the machine.
 This results in a configuration which is the lowest possible voltage
 which satisfies all the constraints that have been supplied and for
 supplies with only one consumer it gives the same behaviour as we have
 currently.

How about taking Thara's proposal of using priority lists?

I mean, it could make more sense to keep the constraints into a priority list,
instead of iterate over all enabled consumers?

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

---
Eduardo Valentin
--
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/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-09-06 Thread Liam Girdwood 
On Mon, 2010-09-06 at 22:59 +0300, Eduardo Valentin wrote:
 Hello,
 
 On Fri, Sep 03, 2010 at 08:20:52PM +0200, Mark Brown wrote:
  On Fri, Sep 03, 2010 at 11:00:31AM -0700, Kevin Hilman wrote:
   Mark Brown broo...@opensource.wolfsonmicro.com writes:
  
The only thing I can think you might need to do if this is just straight
voltage setting is re-add support for multiple consumers setting
voltages simultaneously 
  
   Yeah, that sounds like what we need.
  
   re-add? was it there at one point and removed?  Any pointers to the old
   code?
  
  It was present in the pre-merge regulator API which you can find in the
  bowels of:
  
 git://opensource.wolfsonmicro.com/linux-2.6-audioplus
  
  but was removed to simplify review during the merge.  It's fairly simple
  to do, it's just that there's been no demand.
  
  Essentially all that needs doing is that when regulator_set_voltage() is
  called instead of merging with the machine constraints and applying the
  setting immediately we store the constraints that are specified in the
  consumer then iterate over all enabled consumers applying all the
  constraints that they've set in addition to those from the machine.
  This results in a configuration which is the lowest possible voltage
  which satisfies all the constraints that have been supplied and for
  supplies with only one consumer it gives the same behaviour as we have
  currently.
 
 How about taking Thara's proposal of using priority lists?
 
 I mean, it could make more sense to keep the constraints into a priority list,
 instead of iterate over all enabled consumers?
 

You've not really explained why you think a priority list makes more
sense in this case ?

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

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

Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)

2010-09-06 Thread Felipe Balbi 
Hi,

On Tue, 7 Sep 2010 03:10:30 +0900, venki kaps venkiece2...@gmail.com
wrote:
 Dear USB experts,
 
   Is the same fix valid for omap3430 + 2.6.32 Kernel?

3.6.32 ?? difficult to say. Why such an old kernel ? Although
I doubt musb or twl4030-usb driver has changed that much, it's
difficult to say.

   I have been facing mp3 playback idle current consumption 20mA more
 after booting without USB cable connected

let me see if I understand you right. The consumption is higher
when the cable is kept plugged or the consumption is higher if
you boot with usb cable pugged and remove it afterwards ?

-- 
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 v2 00/10] split out emac cpdma and mdio for reuse

2010-09-06 Thread David Miller 
From: Cyril Chemparathy cy...@ti.com
Date: Fri, 03 Sep 2010 14:20:47 -0400

 Hi Kevin,
 
 [...]
 Although am3517 (omap) board support code has been updated as needed,
 emac does not work on this platform.
 
 Just to clarify... did EMAC work on AM3517 before this series?
 
 No.  It didn't work before this series.  To get AM3517 EMAC working, the
 driver needs another patch to enable the interface clock in addition to
 the functional clock.

Since this has dependencies on davinci board files and whatnot, why don't
you merge this via the davinci tree and add my:

Acked-by: David S. Miller da...@davemloft.net

Ok?
--
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/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-09-06 Thread Mark Brown 
On Mon, Sep 06, 2010 at 10:59:05PM +0300, Eduardo Valentin wrote:
 On Fri, Sep 03, 2010 at 08:20:52PM +0200, Mark Brown wrote:

  Essentially all that needs doing is that when regulator_set_voltage() is
  called instead of merging with the machine constraints and applying the
  setting immediately we store the constraints that are specified in the
  consumer then iterate over all enabled consumers applying all the
  constraints that they've set in addition to those from the machine.

 How about taking Thara's proposal of using priority lists?

 I mean, it could make more sense to keep the constraints into a priority list,
 instead of iterate over all enabled consumers?

Partly just that the lists tend to be short enough that it's hardly
worth bothering with the more complex algorithm, partly because the fact
that you have both a minimum constraint and a maximum constraint makes
it into two priority lists you need to maintain.
--
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] omap4: board-omap4panda: adding leds status1 and status2

2010-09-06 Thread Ricardo Salveti de Araujo 
At Pandaboard we have 2 status leds, so adding them with similar usage as
we have for Beagleboard (heartbeat and mmc0). The patch basically adds the
platform data required by leds-gpio driver.

Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@canonical.com
---
 arch/arm/mach-omap2/board-omap4panda.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 96f5bbb..e67bd2c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -20,6 +20,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/io.h
+#include linux/leds.h
 #include linux/gpio.h
 #include linux/usb/otg.h
 #include linux/i2c/twl.h
@@ -40,6 +41,36 @@
 #include hsmmc.h
 
 
+static struct gpio_led gpio_leds[] = {
+   {
+   .name   = pandaboard::status1,
+   .default_trigger= heartbeat,
+   .gpio   = 7,
+   },
+   {
+   .name   = pandaboard::status2,
+   .default_trigger= mmc0,
+   .gpio   = 8,
+   },
+};
+
+static struct gpio_led_platform_data gpio_led_info = {
+   .leds   = gpio_leds,
+   .num_leds   = ARRAY_SIZE(gpio_leds),
+};
+
+static struct platform_device leds_gpio = {
+   .name   = leds-gpio,
+   .id = -1,
+   .dev= {
+   .platform_data  = gpio_led_info,
+   },
+};
+
+static struct platform_device *panda_devices[] __initdata = {
+   leds_gpio,
+};
+
 static void __init omap4_panda_init_irq(void)
 {
omap2_init_common_hw(NULL, NULL);
@@ -275,6 +306,7 @@ static int __init omap4_panda_i2c_init(void)
 static void __init omap4_panda_init(void)
 {
omap4_panda_i2c_init();
+   platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
-- 
1.7.1

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

Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)

2010-09-06 Thread venki kaps 
Venkii.

On Tue, Sep 7, 2010 at 5:22 AM, Felipe Balbi m...@felipebalbi.com wrote:
 Hi,

 On Tue, 7 Sep 2010 03:10:30 +0900, venki kaps venkiece2...@gmail.com
 wrote:
 Dear USB experts,

   Is the same fix valid for omap3430 + 2.6.32 Kernel?

 3.6.32 ?? difficult to say. Why such an old kernel ? Although
 I doubt musb or twl4030-usb driver has changed that much, it's
 difficult to say.

   I have been facing mp3 playback idle current consumption 20mA more
 after booting without USB cable connected

 let me see if I understand you right. The consumption is higher
 when the cable is kept plugged or the consumption is higher if
 you boot with usb cable pugged and remove it afterwards ?
   The consumption is higher if boot without usb cable.If boot when
the cable is kept plugged
   and remove it afterwards, then normal.

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