Re: [RFC pm-qa 0/2] tests for cpufreq

[Amit Kucheria]

On 11 Jul 01, Paul Larson wrote:
> On Thu, Jun 30, 2011 at 11:24 PM, Daniel Lezcano
> wrote:
> 
> > When all tests will be finished I wish to switch the new way test suite
> > execution in lava, if it is possible.
> >
> Given that the old tests are broken at the moment and disabled, any reason
> we shouldn't switchover now?

I think we should switchover now. There is no real dependency on the old
tests.
 
> > Will the following format be ok ?
> >
> > test_01/cpu0 : checking scaling_available_frequencies file ... PASS
> > ...
> 
> That would probably translate internally to something like:
> {test_id="test_01_cpu0", message="checking scaling_available_frequencies
> file", result="PASS"}
> Is that ok?  Seems like something we should have no trouble making sense out
> of later I think.  Also, the exact output is saved as an attachment as well.

Does LAVA send email in case of a FAIL result?

> > The result for a test case is PASS or FAIL.
> >
> > We support "unknown" as a result as well, if that helps you at all.
>  Sometimes results can be indeterminate, or unimportant (odd as that may
> sound, sometimes the message is really what you're after, as illustrated by
> some of the previous pm qa tests)
> 
> But under some circumstances, we need to do some extra work where a
> > failure does not mean the test case failed but the pre-requisite for the
> > test case is not met.
> >
> ...and we also support "skip" as a result.  That seems like a correct use
> for it.
>  You don't have to report it literally as "skip", you can call it "oink" for
> all we care, and just provide a translation table that converts whatever
> your result strings are to {pass, fail, skip, unknown}.  For example, see
> the test definition for ltp.
> 
> 
> > deviation 0 % for 2333000 is ...  VERY
> > >> GOOD
> > >
> > > Same comments as above about having an easier to interpret format, but
> > the
> > > result here: "VERY GOOD" - what does that mean?  What are the other
> > possible
> > > values?  Is this simply another way of saying "PASS"?  Or should it
> > actually
> > > be a measurement reported here?
> >
> > Yep, I agree it is an informational message and should go to a logging
> > file. I will stick to a simple result 'PASS' or 'FAIL' and I will let
> > the user to read the documentation of the test in the wiki page to
> > understand the meaning of these messages (GOOD, VERY GOOD...).
> >
> keeping to the template you mentioned earlier, I wonder if we could do
> something like this:
> deviation_0_for_2333000: VERY GOOD ... PASS
> (are the numbers there consistent and useful as a test case name?  I'm
> assuming so here)
> That would allow you to capture "VERY GOOD" as details in the message (one
> of the fields we keep).  Also, your test could be smart enough to know that
> good, or verygood = pass, while bad, verybad = fail.  Possibly I'm making a
> lot of assumptions here, but I think you see what I mean.

Yes, it makes sense to make GOOD, VERY GOOD, etc. informational (as part of
the messages) and map them to PASS.

> Keeping to a consistent results format in your output is a good practice,
> and makes this *much* easier for capturing the data important to you.  Of
> course, anything is possible.  We have some tests with rather elaborate
> results and for those, the test definition just inherits from a base class
> and defines it's own parser.  If you're not feeling very pythonic, you could
> provide your own parser as part of the test download written in shell, c,
> ruby, go, whatever, that just acts as a filter, then have it just read it
> all in directly.  There are lots of options, but I'm of the opinion that a
> consistent format makes it easier on humans looking at it as much as machine
> parsers.  And since you have control over that, easiest to do it now. :)
> 
> Thanks,
> Paul Larson

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v4] Add ARM cpu topology definition

[Vincent Guittot]

The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency. We can define the
cpu topology of ARM platform, that is then used by sched_mc and sched_smt.

The default state of sched_mc and sched_smt config is disable.
When enabled, the behavior of the scheduler can be modified with
sched_mc_power_savings and sched_smt_power_savings sysfs interfaces.

Changes since v3 :
* Update the format of printk message
* Remove blank line

Changes since v2 :
* Update the commit message and some comments

Changes since v1 :
* Update the commit message
* Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h
* Modify header of arch/arm/kernel/topology.c
* Modify tests and manipulation of MPIDR's bitfields
* Modify the place and dependancy of the config
* Modify Noop functions

Signed-off-by: Vincent Guittot 
Reviewed-by: Amit Kucheria 
---
 arch/arm/Kconfig|   25 +++
 arch/arm/include/asm/cputype.h  |6 ++
 arch/arm/include/asm/topology.h |   33 +
 arch/arm/kernel/Makefile|1 +
 arch/arm/kernel/smp.c   |6 ++
 arch/arm/kernel/topology.c  |  149 +++
 6 files changed, 220 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/kernel/topology.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..f327e55 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1344,6 +1344,31 @@ config SMP_ON_UP
 
  If you don't know what to do here, say Y.
 
+config ARM_CPU_TOPOLOGY
+   bool "Support cpu topology definition"
+   depends on SMP && CPU_V7
+   default y
+   help
+ Support ARM cpu topology definition. The MPIDR register defines
+ affinity between processors which is then used to describe the cpu
+ topology of an ARM System.
+
+config SCHED_MC
+   bool "Multi-core scheduler support"
+   depends on ARM_CPU_TOPOLOGY
+   help
+ Multi-core scheduler support improves the CPU scheduler's decision
+ making when dealing with multi-core CPU chips at a cost of slightly
+ increased overhead in some places. If unsure say N here.
+
+config SCHED_SMT
+   bool "SMT scheduler support"
+   depends on ARM_CPU_TOPOLOGY
+   help
+ Improves the CPU scheduler's decision making when dealing with
+ MultiThreading at a cost of slightly increased overhead in some
+ places. If unsure say N here.
+
 config HAVE_ARM_SCU
bool
depends on SMP
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cd4458f..cb47d28 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -8,6 +8,7 @@
 #define CPUID_CACHETYPE1
 #define CPUID_TCM  2
 #define CPUID_TLBTYPE  3
+#define CPUID_MPIDR5
 
 #define CPUID_EXT_PFR0 "c1, 0"
 #define CPUID_EXT_PFR1 "c1, 1"
@@ -70,6 +71,11 @@ static inline unsigned int __attribute_const__ 
read_cpuid_tcmstatus(void)
return read_cpuid(CPUID_TCM);
 }
 
+static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
+{
+   return read_cpuid(CPUID_MPIDR);
+}
+
 /*
  * Intel's XScale3 core supports some v6 features (supersections, L2)
  * but advertises itself as v5 as it does not support the v6 ISA.  For
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index accbd7c..63a7454 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -1,6 +1,39 @@
 #ifndef _ASM_ARM_TOPOLOGY_H
 #define _ASM_ARM_TOPOLOGY_H
 
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+
+#include 
+
+struct cputopo_arm {
+   int thread_id;
+   int core_id;
+   int socket_id;
+   cpumask_t thread_sibling;
+   cpumask_t core_sibling;
+};
+
+extern struct cputopo_arm cpu_topology[NR_CPUS];
+
+#define topology_physical_package_id(cpu)  (cpu_topology[cpu].socket_id)
+#define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
+#define topology_core_cpumask(cpu) (&(cpu_topology[cpu].core_sibling))
+#define topology_thread_cpumask(cpu)   (&(cpu_topology[cpu].thread_sibling))
+
+#define mc_capable()   (cpu_topology[0].socket_id != -1)
+#define smt_capable()  (cpu_topology[0].thread_id != -1)
+
+void init_cpu_topology(void);
+void store_cpu_topology(unsigned int cpuid);
+const struct cpumask *cpu_coregroup_mask(unsigned int cpu);
+
+#else
+
+static inline void init_cpu_topology(void) { };
+static inline void store_cpu_topology(unsigned int cpuid) { };
+
+#endif
+
 #include 
 
 #endif /* _ASM_ARM_TOPOLOGY_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index a5b31af..816a481 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_IWMMXT)  += iwmmxt.o
 obj-$(CONFIG_CPU_HAS_PMU)  += pmu.o
 obj-$(CONFIG_HW_PERF_EVENTS)   += perf_event.o
 AFLAGS_iwmmxt.o:= -Wa,-mcpu=iwmmxt
+o

Re: Pandaboard broken in Linus' git tree

[john stultz]

On Thu, 2011-06-30 at 20:32 -0500, Robert Nelson wrote:
> On Thu, Jun 30, 2011 at 8:16 PM, john stultz  wrote:
> >> So is there a fix in the works or should I request Linus just revert
> > that?
> 
> Other then the discussion on linux-usb that found it and mentioned it
> should be reverted, i haven't seen a direct revert request yet to
> linus

Yea, I just sent mail to the patch author to clarify if there is a fix
pending or if it should be reverted.  Hopefully we can get this sorted
quickly, apparently the issue has been around since -rc1.

Thanks for the pointer to the fix as well!
-john



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard broken in Linus' git tree

[Robert Nelson]

On Thu, Jun 30, 2011 at 8:16 PM, john stultz  wrote:
> On Thu, 2011-06-30 at 18:00 -0700, john stultz wrote:
>> Booting Panda with Linus' current git tree (3.0-rc5-130) and got the
>> following:
>>
>> [    2.066558] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> [    2.073730] Unhandled fault: imprecise external abort (0x1406) at 
>> 0x
>> [    2.081146] Internal error: : 1406 [#1] SMP
>> [    2.085540] Modules linked in:
>> [    2.088775] CPU: 0    Not tainted  (3.0.0-rc5-00130-g0e90ed0 #27)
>> [    2.095184] PC is at omap_usbhs_enable+0x174/0x43c
>> [    2.100250] LR is at __pm_runtime_resume+0x58/0x60
>
> Oh. This is the same issue Andy mentioned in a thread a week ago.
>
> And even more humorously is the fact that I'm forgetful enough that I
> had *also* hit this and found that the fix is reverting
> 7e6502d577106fb5b202bbaac64c5f1b065e6daa
>
> So is there a fix in the works or should I request Linus just revert
> that?

Other then the discussion on linux-usb that found it and mentioned it
should be reverted, i haven't seen a direct revert request yet to
linus

> Or maybe I'll just go ahead and put a reminder in my calendar for next
> week when I hit it again and have forgotten I already know the fix?
>

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard broken in Linus' git tree

[john stultz]

On Thu, 2011-06-30 at 18:00 -0700, john stultz wrote:
> Booting Panda with Linus' current git tree (3.0-rc5-130) and got the
> following:
> 
> [2.066558] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [2.073730] Unhandled fault: imprecise external abort (0x1406) at 
> 0x
> [2.081146] Internal error: : 1406 [#1] SMP
> [2.085540] Modules linked in:
> [2.088775] CPU: 0Not tainted  (3.0.0-rc5-00130-g0e90ed0 #27)
> [2.095184] PC is at omap_usbhs_enable+0x174/0x43c
> [2.100250] LR is at __pm_runtime_resume+0x58/0x60

Oh. This is the same issue Andy mentioned in a thread a week ago.

And even more humorously is the fact that I'm forgetful enough that I
had *also* hit this and found that the fix is reverting
7e6502d577106fb5b202bbaac64c5f1b065e6daa

So is there a fix in the works or should I request Linus just revert
that?

Or maybe I'll just go ahead and put a reminder in my calendar for next
week when I hit it again and have forgotten I already know the fix?

thanks
-john



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard broken in Linus' git tree

[Robert Nelson]

On Thu, Jun 30, 2011 at 8:00 PM, john stultz  wrote:
> Booting Panda with Linus' current git tree (3.0-rc5-130) and got the
> following:
>
> [    2.066558] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    2.073730] Unhandled fault: imprecise external abort (0x1406) at 
> 0x
> [    2.081146] Internal error: : 1406 [#1] SMP
> [    2.085540] Modules linked in:
> [    2.088775] CPU: 0    Not tainted  (3.0.0-rc5-00130-g0e90ed0 #27)
> [    2.095184] PC is at omap_usbhs_enable+0x174/0x43c
> [    2.100250] LR is at __pm_runtime_resume+0x58/0x60
> [    2.105285] pc : []    lr : []    psr: 8093
> [    2.105316] sp : ef833e50  ip : ef833e10  fp : ef833ed8
> [    2.117401] r10: 801c  r9 : efb04f20  r8 : 8013
> [    2.122894] r7 : efa6b724  r6 : c0718928  r5 : efb02808  r4 : efa6b6e0
> [    2.129760] r3 :   r2 : 801c  r1 : 0001  r0 : 
> [    2.136627] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kel
> [    2.144439] Control: 10c5387d  Table: 8000404a  DAC: 0015
> [    2.150482] Process swapper (pid: 1, stack limit = 0xef8322f0)
> [    2.156616] Stack: (0xef833e50 to 0xef834000)
> [    2.161193] 3e40:                                     eef3e000 efb02808 
> efb0c
> [    2.169830] 3e60: 0003 efb04f20 efb04f60 c03c9d48 c0722ccc ef832000 
> c0724
> [    2.178436] 3e80: 0002  eee43208 ef833ed8 eee43208 c0176c64 
> fc06d
> [    2.187042] 3ea0: eee43208 eee43208  eee43288 efb05e88 0001 
> 0
> [    2.195678] 3ec0:  c0177eb0 ef8313c0 c05262d0 ef8556b8 0003 
> 73752
> [    2.204284] 3ee0: c0738ca4 efb02808 efb0283c c0738ca4 c0738ca4  
> 0
> [    2.212890] 3f00:  c0337dcc efb02808 c0336bf8 efb02808 efb0283c 
> c0730
> [    2.221527] 3f20:  c0336d1c c0738ca4 ef833f38 c0336cb4 c0336424 
> ef850
> [    2.230133] 3f40: c0738ca4 c0738ca4 eee44d40 c072fba8  c0335d54 
> c0670
> [    2.238739] 3f60:  c0738ca4 c0c9a8e8 c0055894   
> c
> [    2.247344] 3f80: c0c9a33c c0c9a8e8 c0055894   c0029478 
> 0
> [    2.255981] 3fa0:  c0033438 c00293d8 c004a570  c017 
> c065a
> [    2.264587] 3fc0: c071de0c c0033438 c0033570 c0055894 0013  
> 0
> [    2.273193] 3fe0:  c00083ac  c0008324 c0055894 c0055894 
> 0
> [    2.281829] [] (omap_usbhs_enable+0x174/0x43c) from [] 
> ()
> [    2.290252] Code: e3530001 03caaa01 138aaa01 ea5c (e59f22b0)
> [    2.296691] [ cut here ]
> [    2.301574] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:106 
> l3_interrupt_h)
> [    2.310729] CUSTOM SRESP error with SOURCE:L4CFG
> [    2.315582] Modules linked in:
> [    2.318817] ---[ end trace 90068a0c409412d0 ]---
> [    2.323699] ---[ end trace 90068a0c409412d1 ]---
> [    2.328582] Kernel panic - not syncing: Attempted to kill init!
> [    2.334838] CPU1: stopping
>
>
> Since we're likely to be moving to 3.0 for the next release, it might be
> good to try to get this fixed upstream.

Reverting

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7e6502d577106fb5b202bbaac64c5f1b065e6daa

works for me with the pandaboard on mainline..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Pandaboard broken in Linus' git tree

[john stultz]

Booting Panda with Linus' current git tree (3.0-rc5-130) and got the
following:

[2.066558] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[2.073730] Unhandled fault: imprecise external abort (0x1406) at 0x
[2.081146] Internal error: : 1406 [#1] SMP
[2.085540] Modules linked in:
[2.088775] CPU: 0Not tainted  (3.0.0-rc5-00130-g0e90ed0 #27)
[2.095184] PC is at omap_usbhs_enable+0x174/0x43c
[2.100250] LR is at __pm_runtime_resume+0x58/0x60
[2.105285] pc : []lr : []psr: 8093
[2.105316] sp : ef833e50  ip : ef833e10  fp : ef833ed8
[2.117401] r10: 801c  r9 : efb04f20  r8 : 8013
[2.122894] r7 : efa6b724  r6 : c0718928  r5 : efb02808  r4 : efa6b6e0
[2.129760] r3 :   r2 : 801c  r1 : 0001  r0 : 
[2.136627] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kel
[2.144439] Control: 10c5387d  Table: 8000404a  DAC: 0015
[2.150482] Process swapper (pid: 1, stack limit = 0xef8322f0)
[2.156616] Stack: (0xef833e50 to 0xef834000)
[2.161193] 3e40: eef3e000 efb02808 efb0c
[2.169830] 3e60: 0003 efb04f20 efb04f60 c03c9d48 c0722ccc ef832000 c0724
[2.178436] 3e80: 0002  eee43208 ef833ed8 eee43208 c0176c64 fc06d
[2.187042] 3ea0: eee43208 eee43208  eee43288 efb05e88 0001 0
[2.195678] 3ec0:  c0177eb0 ef8313c0 c05262d0 ef8556b8 0003 73752
[2.204284] 3ee0: c0738ca4 efb02808 efb0283c c0738ca4 c0738ca4  0
[2.212890] 3f00:  c0337dcc efb02808 c0336bf8 efb02808 efb0283c c0730
[2.221527] 3f20:  c0336d1c c0738ca4 ef833f38 c0336cb4 c0336424 ef850
[2.230133] 3f40: c0738ca4 c0738ca4 eee44d40 c072fba8  c0335d54 c0670
[2.238739] 3f60:  c0738ca4 c0c9a8e8 c0055894   c
[2.247344] 3f80: c0c9a33c c0c9a8e8 c0055894   c0029478 0
[2.255981] 3fa0:  c0033438 c00293d8 c004a570  c017 c065a
[2.264587] 3fc0: c071de0c c0033438 c0033570 c0055894 0013  0
[2.273193] 3fe0:  c00083ac  c0008324 c0055894 c0055894 0
[2.281829] [] (omap_usbhs_enable+0x174/0x43c) from [] ()
[2.290252] Code: e3530001 03caaa01 138aaa01 ea5c (e59f22b0) 
[2.296691] [ cut here ]
[2.301574] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:106 l3_interrupt_h)
[2.310729] CUSTOM SRESP error with SOURCE:L4CFG
[2.315582] Modules linked in:
[2.318817] ---[ end trace 90068a0c409412d0 ]---
[2.323699] ---[ end trace 90068a0c409412d1 ]---
[2.328582] Kernel panic - not syncing: Attempted to kill init!
[2.334838] CPU1: stopping


Since we're likely to be moving to 3.0 for the next release, it might be
good to try to get this fixed upstream. 

thanks
-john



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC pm-qa 0/2] tests for cpufreq

[Paul Larson]

On Thu, Jun 30, 2011 at 11:24 PM, Daniel Lezcano
wrote:

> When all tests will be finished I wish to switch the new way test suite
> execution in lava, if it is possible.
>
Given that the old tests are broken at the moment and disabled, any reason
we shouldn't switchover now?


> Will the following format be ok ?
>
> test_01/cpu0 : checking scaling_available_frequencies file ... PASS
> ...

That would probably translate internally to something like:
{test_id="test_01_cpu0", message="checking scaling_available_frequencies
file", result="PASS"}
Is that ok?  Seems like something we should have no trouble making sense out
of later I think.  Also, the exact output is saved as an attachment as well.


> The result for a test case is PASS or FAIL.
>
> We support "unknown" as a result as well, if that helps you at all.
 Sometimes results can be indeterminate, or unimportant (odd as that may
sound, sometimes the message is really what you're after, as illustrated by
some of the previous pm qa tests)

But under some circumstances, we need to do some extra work where a
> failure does not mean the test case failed but the pre-requisite for the
> test case is not met.
>
...and we also support "skip" as a result.  That seems like a correct use
for it.
 You don't have to report it literally as "skip", you can call it "oink" for
all we care, and just provide a translation table that converts whatever
your result strings are to {pass, fail, skip, unknown}.  For example, see
the test definition for ltp.


> deviation 0 % for 2333000 is ...  VERY
> >> GOOD
> >
> > Same comments as above about having an easier to interpret format, but
> the
> > result here: "VERY GOOD" - what does that mean?  What are the other
> possible
> > values?  Is this simply another way of saying "PASS"?  Or should it
> actually
> > be a measurement reported here?
>
> Yep, I agree it is an informational message and should go to a logging
> file. I will stick to a simple result 'PASS' or 'FAIL' and I will let
> the user to read the documentation of the test in the wiki page to
> understand the meaning of these messages (GOOD, VERY GOOD...).
>
keeping to the template you mentioned earlier, I wonder if we could do
something like this:
deviation_0_for_2333000: VERY GOOD ... PASS
(are the numbers there consistent and useful as a test case name?  I'm
assuming so here)
That would allow you to capture "VERY GOOD" as details in the message (one
of the fields we keep).  Also, your test could be smart enough to know that
good, or verygood = pass, while bad, verybad = fail.  Possibly I'm making a
lot of assumptions here, but I think you see what I mean.

Keeping to a consistent results format in your output is a good practice,
and makes this *much* easier for capturing the data important to you.  Of
course, anything is possible.  We have some tests with rather elaborate
results and for those, the test definition just inherits from a base class
and defines it's own parser.  If you're not feeling very pythonic, you could
provide your own parser as part of the test download written in shell, c,
ruby, go, whatever, that just acts as a filter, then have it just read it
all in directly.  There are lots of options, but I'm of the opinion that a
consistent format makes it easier on humans looking at it as much as machine
parsers.  And since you have control over that, easiest to do it now. :)

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Customization of Gerrit for Android

[James Westby]

On Tue, 14 Jun 2011 17:32:59 -0400, James Westby  
wrote:
> I'll write up a spec on doing the tested merge involves.

I've got the first draft of this at

  https://wiki.linaro.org/Platform/Android/Specs/BuildTestedMerge

Please take a look at let me know any comments that you have and I'll
incorporate them in to a second draft.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Please test Android RC builds

[Paul Larson]

http://validation.linaro.org/launch-control/dashboard/attachments/2755/

Tested on the released panda-leb version, here's the serial log showing the
same errors I mentioned in the previous results?  Is this a known problem?
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC pm-qa 0/2] tests for cpufreq

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/30/2011 01:04 PM, Paul Larson wrote:
> On Thu, Jun 30, 2011 at 10:44 AM, Daniel Lezcano
> wrote:
> 
>> I added in attachment the result of these scripts on a fully working
>> cpufreq framework on my intel box. That will show the ouput of the tests.
>>
>> But the cpufreq is not complete on a pandaboard, so results won't be
>> really nice.
>>
>> Looking at your results answered some of my questions at least, it seems to
> have a very different format for the output than the previous tests.  Are
> the older ones replaced by this, extended by it, or is this just a
> completely separate testsuite?  If it's to be considered a different
> testsuite, that makes some sense, as the type of tests here seem to be
> consistent pass/fail sorts of tests.  However I have a few concerns for
> having it be easily parsed into results that can be stored automatically:

It is the same test suite but I want the new tests to replace the old
ones in a near future.

At present, new and old tests are co-existing.

The test suite is launched in two different manners:

  * running the old tests -> no modification
  * the new way, invoked by 'make check'

Today, you should not have to modify anything as lava should invoke the
old way pm-qa tests.

When all tests will be finished I wish to switch the new way test suite
execution in lava, if it is possible.

So in the meantime, lava can continue to run the old tests while the
developers can easily invoke the new tests with 'make check' and check
their kernel code each time new tests are committed.

Does it make sense ?

> for 'cpu0':
>> checking scaling_available_governors file presence ...PASS
>> checking scaling_governor file presence ...   PASS
>> for 'cpu1':
>> checking scaling_available_governors file presence ...PASS
>> checking scaling_governor file presence ...   PASS
> 
>  ...
> Heading1
>  test_id1
>  test_id2
> Heading2
>  test_id1
>  test_id2
> This is notoriously a bit tricky to deal with.  It can be done, but the
> parsing has to track which heading it's under, and modify the test_id (or
> some attribute of it) to designate how it differs from other testcases with
> the exact same name.  It can be done, but since you have complete control
> over how you output results, it can easily be changed in such a way that is
> easy to parse, and easy for a human to look at.
> What might be easier is:
> cpu0_scaling_available_governors_file_exists: PASS
> cpu0_scaling_governor_file_exists: PASS
> cpu1_scaling_available_governors_file_exists: PASS
> cpu1_scaling_governor_file_exists: PASS

Ok I can get rid of the nested format. No problem.

Each scripts are doing several tests, IMO, that would be better to show
the description of what is doing the script and finish them by PASS or FAIL.

Will the following format be ok ?

test_01/cpu0 : checking scaling_available_frequencies file ... PASS
test_01/cpu0 : checking scaling_cur_freq file ...  PASS
test_01/cpu0 : checking scaling_setspeed file ...  PASS
test_01/cpu1 : checking scaling_available_frequencies file ... PASS
test_01/cpu1 : checking scaling_cur_freq file ...  PASS
test_01/cpu1 : checking scaling_setspeed file ...  PASS

All the tests are described at :

https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts

> Another thing that I'm curious about here is...
> 
>> saving governor for cpu0 ...  DONE
> 
> Is that a result? Or just an informational message?  That's not clear, even
> as a human reader.

The result for a test case is PASS or FAIL.

But under some circumstances, we need to do some extra work where a
failure does not mean the test case failed but the pre-requisite for the
test case is not met.

For example, the test case is to change the governor to 'userspace'. We
have to be 'root' to do such operation. If the test script is run
without 'root' privileges then the prerequisite is not met and the test
script fails, not the test case.

But anyway, I can log to a file the operations not related to the test
case and just display PASS or FAIL as a result. It will be up to the
user to look at the log file to understand the problem.

> deviation 0 % for 2333000 is ...  VERY
>> GOOD
> 
> Same comments as above about having an easier to interpret format, but the
> result here: "VERY GOOD" - what does that mean?  What are the other possible
> values?  Is this simply another way of saying "PASS"?  Or should it actually
> be a measurement reported here?

Yep, I agree it is an informational message and should go to a logging
file. I will stick to a simple result 'PASS' or 'FAIL' and I will let
the user to read the documentation of the test in the wiki page to
understand the meaning of these messages (GOOD, VERY GOOD...).

eg. for this one:

https://wiki.linaro.org/Wo

Re: lava-dev-tool + lava-server installation/development and local data

[Michael Hudson-Doyle]

On Thu, 30 Jun 2011 14:45:28 +0100, Paul Larson  wrote:
> On Thu, Jun 30, 2011 at 3:01 AM, Michael Hudson-Doyle <
> michael.hud...@linaro.org> wrote:
> 
> > It's one of these things I've been vaguely meaning to look into for ages
> > -- can you run postgres as an unprivileged user like this for testing?
> > I assume it's possible in some sense, but if e.g. it involves
> > recompiling postgres or any thing like that it's not really practical.
> > But I would be happy to only support postgres.
>
> If we're just talking about doing this testing periodically, and not every
> time you run the unit tests, could we just do it in a chroot?

I'm talking about trying to get to the situation where we can use a
self-contained postgres for our unit tests, so that we can move to only
supporting postgres.  If we can't do that, then yes, some kind of chroot
solution makes sense.

Cheers,
mwh

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro 11.06 released

[Joey Stanford]

Excellent work everyone. This is a superb release!

On Thu, Jun 30, 2011 at 2:16 PM, Fathi Boudra  wrote:
> Hi,
>
> The Linaro Team is pleased to announce the release of Linaro 11.06.
>
> 11.06 is the Linaro’s first release delivered on the new monthly cadence.
> Since we started focusing on monthly component releases, activity in the
> engineering teams has been channeled into producing a coherent set of 
> packages;
> This allows anyone to witness development of new features and fixes as the 
> team
> progresses towards its goals. This month’s release highlights the results:
> a host of new components are now available, including LAVA packages from the
> Platform Validation Team, a collection of SoC-specific kernels provided by the
> Landing Teams, and preview releases of Graphics and Multimedia Working Groups
> work ranging from Unity 3D to a NEON-optimized libjpeg-turbo. In addition,
> another solid set of toolchain components, topped by a Linaro GCC 4.6 release
> that should start making a very good impressions on benchmarks near you.
>
> We encourage everybody to use the 11.06 release. The download links for all
> images and components are available on our release page:
>
>  http://wiki.linaro.org/Cycles/1106/Release
>
> Highlights of this release:
>
>  * Linaro Evaluation Builds (LEBs) for Ubuntu comes with the full 3D Unity
>   desktop experience enabled on PandaBoard. It's powered by Compiz and relies
>   on the Nux toolkit for its rendering.
>  * Linaro Evaluation Build (LEBs) for Android on Pandaboard comes with latest
>   stable 2.6.38 kernel from Linaro's TI Landing Team and is built using
>   Linaro's GCC 4.5 2011.06 release; Also, latest Linaro toolchain have been
>   packaged for Android and benchmark results showing noticeable performance
>   gains compared to the Google AOSP gingerbread toolchain have been included
>   as part of the release documentation: http://bit.ly/jTAhWa
>  * Initial preview releases of Ubuntu Hardware Packs for Snowball, Origen and
>   Quickstart boards featuring the latest Linaro Landing Team components are
>   available as part of this release.
>  * Linaro GCC 4.6 2011.06 and GCC 4.5 2011.06 come with bugfixes and various
>   performance optimizations with focus on vectoriser improvements. With this
>   release Linaro GCC 4.5 series enters maintenance mode and will ensure that
>   development can be focused on making the "future" better.
>  * Linaro QEMU 2011.06, based on upstream (trunk) QEMU. This version includes 
> a
>   number of ARM-focused bug fixes and enhancements like the support of a model
>   of the Gumstix Overo board and the USB keyboard/mouse support on
>   BeagleBoard.
>  * Linaro Kernel 2.6.39 2011.06, based on the 2.6.39.1 stable kernel with a
>   number of changes developed by Linaro and integrated from the 3.0-rc. It
>   includes the ability to append Device Tree to zImage at build time, support
>   for parallel async MMC requests and more...
>  * Linaro U-Boot 2011.06.1, based on upstream version 2011.06-rc3 features 
> USB,
>   Network and TFTP boot for PandaBoard as well as initial PXE support.
>  * First full release of LAVA components, Linaro's automated validation
>   solution, has been made available as part of our monthly releases.
>  * QEMU with OpenGL ES acceleration - technology preview. For more details,
>   please visit https://wiki.linaro.org/Platform/DevPlatform/QemuOpenGLES
>  * The Unity, NUX and Compiz port for EGL/OpenGL ES v2 that are part of
>   our Ubuntu LEB for this month are also made available as components
>   maintained by Linaro's Graphics Working Group.
>  * Linaro Image Tools 2011.06-1 features the support for the --image_file
>   option in linaro-android-media-create and support the new upstream name of
>   the smdkv310 SPL.
>  * Powerdebug 0.5-2011.06 is a major rewrite of the code to put in place a
>   generic framework to integrate more easily new components like the thermal
>   sensors. It's more modular and decrease the dependency between the display
>   and the power management blocks.
>  * And much more... The release details are linked from the "Details" column
>   for each release artifact on the 11.06 release page.
>
> Using the Android-based images
> ==
>
> The Android-based images come in three parts: system, userdata and boot.
> These need to be combined to form a complete Android install. For an
> explanation of how to do this please see:
>
>  http://wiki.linaro.org/Platform/Android/ImageInstallation
>
> If you are interested in getting the source and building these images
> yourself please see the following pages:
>
>  http://wiki.linaro.org/Platform/Android/GetSource
>  http://wiki.linaro.org/Platform/Android/BuildSource
>
> Using the Ubuntu-based images
> =
>
> The Ubuntu-based images consist of two parts. The first part is a hardware
> pack, which can be found under the hwpacks directory and contains hardware
> specific packages (such as t

LAVA 2011.06 Release

[Paul Larson]

The Linaro Validation team is pleased to announce the first full release of
LAVA, for the 2011.06 milestone.

LAVA is the Linaro Automated Validation Architecture that Linaro is
deploying to automate the testing of Linaro images and components on
supported development boards.

The release pages with release notes, highlights, changelogs, and downloads
can be found at:

 * lava-dashboard -
https://launchpad.net/lava-dashboard/linaro-11.11/2011.06
 * lava-dashboard-tool -
https://launchpad.net/lava-dashboard-tool/linaro-11.11/2011.06
 * lava-dispatcher -
https://launchpad.net/lava-dispatcher/linaro-11.11/2011.06
 * lava-scheduler -
https://launchpad.net/lava-scheduler/linaro-11.11/2011.06
 * lava-scheduler-tool -
https://launchpad.net/lava-scheduler-tool/linaro-11.11/2011.06
 * lava-server - https://launchpad.net/lava-server/linaro-11.11/2011.06
 * lava-test - https://launchpad.net/lava-test/linaro-11.11/2011.06
 * lava-tool - https://launchpad.net/lava-tool/linaro-11.11/2011.06
 * linaro-python-dashboard-bundle -
https://launchpad.net/linaro-python-dashboard-bundle/linaro-11.11/2011.06
 * linaro-django-xmlrpc -
https://launchpad.net/linaro-django-xmlrpc/+milestone/2011.06

For more information about installing, running, and developing on LAVA, see:
https://wiki.linaro.org/Platform/Validation/LAVA/Documentation

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

initrd and dtb locations (for panda)

[David Long]

Can someone explain why uboot copies the initrd and device tree data to
higher memory when we boot panda with a dtb?   I'm assuming there's a
reason, but it seems a problematic thing to do (potentially even without
>3/4GB SDRAM present).

-dl

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: lava-dev-tool + lava-server installation/development and local data

[Paul Larson]

On Thu, Jun 30, 2011 at 3:01 AM, Michael Hudson-Doyle <
michael.hud...@linaro.org> wrote:

> It's one of these things I've been vaguely meaning to look into for ages
> -- can you run postgres as an unprivileged user like this for testing?
> I assume it's possible in some sense, but if e.g. it involves
> recompiling postgres or any thing like that it's not really practical.
> But I would be happy to only support postgres.
>
> If we're just talking about doing this testing periodically, and not every
time you run the unit tests, could we just do it in a chroot?

-Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 6/11] HWMON: DA9052 hwmon driver v2

[ashishj3]

The DA9052 PMIC provides an Analogue to Digital Converter with 10 bits
resolution and 10 channels.

This patch montiors the DA9052 PMIC's ADC channels mostly for battery parameters
like battery temperature, junction temperature, battery current etc.

Signed-off-by: David Dajun Chen 
Signed-off-by: Ashish Jangam 
---
Changes since v1:
- Corrected error handling in the function da9052_read_vddout()
---
 Documentation/hwmon/da9052   |   58 
 drivers/hwmon/Kconfig|   10 ++
 drivers/hwmon/Makefile   |1 +
 drivers/hwmon/da9052-hwmon.c |  332 ++
 4 files changed, 401 insertions(+), 0 deletions(-)
 create mode 100755 Documentation/hwmon/da9052
 create mode 100755 drivers/hwmon/da9052-hwmon.c
diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052
new file mode 100755
index 000..0b7930f
--- /dev/null
+++ b/Documentation/hwmon/da9052
@@ -0,0 +1,58 @@
+Kernel driver da9052-hwmon
+==
+
+Supported chips:
+  * Dialog Semiconductors DA9052 PMICs
+Prefix: 'da9052'
+Datasheet: Kindly visit www.dialog-semiconductor.com and request for the
+   official datasheet.
+
+Authors: David Dajun Chen 
+
+Description
+---
+
+The DA9052 provides an Analogue to Digital Converter (ADC) with 10 bits
+resolution and track and hold circuitry combined with an analogue input
+multiplexer. The analogue input multiplexer will allow conversion of up to 10
+different inputs. The track and hold circuit ensures stable input voltages at
+the input of the ADC during the conversion.
+
+The ADC is used to measure the following inputs:
+Channel 0: VDDOUT - measurement of the system voltage
+Channel 1: ICH - internal battery charger current measurement
+Channel 2: TBAT - output from the battery NTC
+Channel 3: VBAT - measurement of the battery voltage
+Channel 4: ADC_IN4 - high impedance input (0 - 2.5V)
+Channel 5: ADC_IN5 - high impedance input (0 - 2.5V)
+Channel 6: ADC_IN6 - high impedance input (0 - 2.5V)
+Channel 7: XY - TSI interface to measure the X and Y voltage of the touch
+screen resistive potentiometers
+Channel 8: Internal Tjunc. - sense (internal temp. sensor)
+Channel 9: VBBAT - measurement of the backup battery voltage
+
+By using sysfs attributes we can measure the system voltage VDDOUT, the battery
+charging current ICH, battery temperature TBAT, battery junction temperature
+TJUNC, battery voltage VBAT and the back up battery voltage VBBAT.
+
+Voltage Monitoring
+--
+
+Voltages are sampled by a 10 bit ADC.  Voltages in millivolts are 1.465
+times the ADC value.
+
+Temperature Monitoring
+--
+
+Temperatures are sampled by a 10 bit ADC.  Junction and battery temperatures
+are monitored by the ADC channels.
+
+The junction temperature is calculated:
+   Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8
+The junction temperature attribute is supported by the driver.
+
+The battery temperature is calculated:
+   Degree Celcius = 1 / (t1 + 1/298)- 273
+where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255))
+Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively.
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 3236a45..da5ff6d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -303,6 +303,16 @@ config SENSORS_DS1621
  This driver can also be built as a module.  If so, the module
  will be called ds1621.
 
+config SENSORS_DA9052_ADC
+tristate "Dialog DA9052 HWMON"
+depends on PMIC_DA9052
+help
+  Say y here to support the ADC found on
+  Dialog Semiconductor DA9052 PMIC.
+
+  This driver can also be built as module. If so, the module
+  will be called da9052-hwmon.
+
 config SENSORS_I5K_AMB
tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
depends on PCI && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f7c0c28..88b81ca 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
 obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
 obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
 obj-$(CONFIG_SENSORS_PKGTEMP)  += pkgtemp.o
+obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
 obj-$(CONFIG_SENSORS_DME1737)  += dme1737.o
 obj-$(CONFIG_SENSORS_DS620)+= ds620.o
 obj-$(CONFIG_SENSORS_DS1621)   += ds1621.o
diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c
new file mode 100755
index 000..ed25ba9
--- /dev/null
+++ b/drivers/hwmon/da9052-hwmon.c
@@ -0,0 +1,332 @@
+/*
+ * HWMON Driver for Dialog DA9052
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+ *
+ * Author: David Dajun Chen 
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  Lice

Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency

[Russell King - ARM Linux]

On Thu, Jun 30, 2011 at 03:12:46PM +0200, Arnd Bergmann wrote:
> I think this looks good enough to merge into the linux-mmc tree, the code is
> clean and the benefits are clear.
> 
> Acked-by: Arnd Bergmann 
> 
> One logical follow-up as both a cleanup and performance optimization would be
> to get rid of the mmc_queue_thread completely. When mmc_blk_issue_rq() is
> non-blocking always, you can call it directly from the mmc_request()
> function, instead of waking up another thread to do it for you.

It isn't anywhere near that - because you need to wait for the
request to complete, then analyze the results and if there has been
an error, send more commands and wait for their response.

To do all that in an asynchronous fashion will just create a mess of
small little functions with hard to understand code.  It's far better
to do all that in a clear procedural way in a thread.

We've been here before - with PCMCIA's card insertion code, where you
have to go through a sequence of events (insert, power up, reset, etc).
The PCMCIA code used to have a collection of small functions to do
each step, one chained after the other in a state machine fashion.
The result was horrid.  That's exactly what you'll end up with here.

Threads have their place, and this is one of them.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency

[Arnd Bergmann]

On Tuesday 28 June 2011, Per Forlin wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost more due to
> multiple cache levels and speculative cache pre-fetch. In relation the
> cost for handling the caches have increased and is now a bottle neck
> dealing with fast eMMC together with DMA.
> 
> The intention for introducing non-blocking mmc requests is to minimize the
> time between a mmc request ends and another mmc request starts. In the
> current implementation the MMC controller is idle when dma_map_sg and
> dma_unmap_sg is processing. Introducing non-blocking mmc request makes it
> possible to prepare the caches for next job in parallel to an active
> mmc request.
> 
> This is done by making the issue_rw_rq() non-blocking.
> The increase in throughput is proportional to the time it takes to
> prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
> a request and how fast the memory is. The faster the MMC/SD is
> the more significant the prepare request time becomes. Measurements on U5500
> and Panda on eMMC and SD shows significant performance gain for large
> reads when running DMA mode. In the PIO case the performance is unchanged.
> 
> There are two optional hooks pre_req() and post_req() that the host driver
> may implement in order to move work to before and after the actual mmc_request
> function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
> the dma descriptor and post_req runs the dma_unmap_sg.

I think this looks good enough to merge into the linux-mmc tree, the code is
clean and the benefits are clear.

Acked-by: Arnd Bergmann 

One logical follow-up as both a cleanup and performance optimization would be
to get rid of the mmc_queue_thread completely. When mmc_blk_issue_rq() is
non-blocking always, you can call it directly from the mmc_request()
function, instead of waking up another thread to do it for you.

Arnd

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency

[S, Venkatraman]

On Thu, Jun 30, 2011 at 6:06 PM, Poddar, Sourav  wrote:
> On Tue, Jun 28, 2011 at 1:41 PM, Per Forlin  wrote:
>> How significant is the cache maintenance over head?
>> It depends, the eMMC are much faster now
>> compared to a few years ago and cache maintenance cost more due to
>> multiple cache levels and speculative cache pre-fetch. In relation the
>> cost for handling the caches have increased and is now a bottle neck
>> dealing with fast eMMC together with DMA.
>>
>> The intention for introducing non-blocking mmc requests is to minimize the
>> time between a mmc request ends and another mmc request starts. In the
>> current implementation the MMC controller is idle when dma_map_sg and
>> dma_unmap_sg is processing. Introducing non-blocking mmc request makes it
>> possible to prepare the caches for next job in parallel to an active
>> mmc request.
>>
>> This is done by making the issue_rw_rq() non-blocking.
>> The increase in throughput is proportional to the time it takes to
>> prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
>> a request and how fast the memory is. The faster the MMC/SD is
>> the more significant the prepare request time becomes. Measurements on U5500
>> and Panda on eMMC and SD shows significant performance gain for large
>> reads when running DMA mode. In the PIO case the performance is unchanged.
>>
>> There are two optional hooks pre_req() and post_req() that the host driver
>> may implement in order to move work to before and after the actual 
>> mmc_request
>> function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
>> the dma descriptor and post_req runs the dma_unmap_sg.
>>
>> Details on measurements from IOZone and mmc_test:
>> https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
>>
>> Changes since v7:
>>  * rebase on mmc-next, on top of Russell's updated error handling.
>>  * Clarify description of mmc_start_req()
>>  * Resolve compile without CONFIG_DMA_ENIGNE issue for mmci
>>  * Add mmc test to measure how performance is affected by sg length
>>  * Add missing wait_for_busy in mmc_test non-blocking test. This call got 
>> lost
>>   in v4 of this patchset when refactoring mmc_start_req.
>>  * Add sub-prefix (core block queue) to relevant patches.
>>
>> Per Forlin (12):
>>  mmc: core: add non-blocking mmc request function
>>  omap_hsmmc: add support for pre_req and post_req
>>  mmci: implement pre_req() and post_req()
>>  mmc: mmc_test: add debugfs file to list all tests
>>  mmc: mmc_test: add test for non-blocking transfers
>>  mmc: mmc_test: test to measure how sg_len affect performance
>>  mmc: block: add member in mmc queue struct to hold request data
>>  mmc: block: add a block request prepare function
>>  mmc: block: move error code in issue_rw_rq to a separate function.
>>  mmc: queue: add a second mmc queue request member
>>  mmc: core: add random fault injection
>>  mmc: block: add handling for two parallel block requests in
>>    issue_rw_rq
>>
>>  drivers/mmc/card/block.c      |  505 
>> -
>>  drivers/mmc/card/mmc_test.c   |  491 
>> ++--
>>  drivers/mmc/card/queue.c      |  184 ++--
>>  drivers/mmc/card/queue.h      |   33 ++-
>>  drivers/mmc/core/core.c       |  167 +-
>>  drivers/mmc/core/debugfs.c    |    5 +
>>  drivers/mmc/host/mmci.c       |  147 +++-
>>  drivers/mmc/host/mmci.h       |    8 +
>>  drivers/mmc/host/omap_hsmmc.c |   87 +++-
>>  include/linux/mmc/core.h      |    6 +-
>>  include/linux/mmc/host.h      |   24 ++
>>  lib/Kconfig.debug             |   11 +
>>  12 files changed, 1345 insertions(+), 323 deletions(-)
>
>
>
> Boot tested on Omap4430 Blaze board.
>
> Tested-by: Sourav Poddar
>
Reviewed for OMAP along with Sourav's tests..
Reviewed-by: Venkatraman S 

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3] Add ARM cpu topology definition

[Vincent Guittot]

On 30 June 2011 12:34, Russell King - ARM Linux  wrote:
> On Fri, Jun 24, 2011 at 08:38:44PM +0200, Vincent Guittot wrote:
>> +     printk(KERN_INFO "cpu %u : thread %d cpu %d, socket %d, mpidr %x\n",
>> +             cpuid, cpu_topology[cpuid].thread_id,
>> +             cpu_topology[cpuid].core_id,
>> +             cpu_topology[cpuid].socket_id, mpidr);
>> +
>> +}
>
> Please remove that empty blank line before the closing brace.
>

ok

> Also...
>
> cpu 0 : thread -1 cpu 0, socket 0, mpidr 8000
> Calibrating local timer... 199.99MHz.
> hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
> CPU1: Booted secondary processor
> cpu 1 : thread -1 cpu 1, socket 0, mpidr 8001
> CPU2: Booted secondary processor
> cpu 2 : thread -1 cpu 2, socket 0, mpidr 8002
> CPU3: Booted secondary processor
> cpu 3 : thread -1 cpu 3, socket 0, mpidr 8003
> Brought up 4 CPUs
>
> It'd be better to have some consistency there - please change from
> "cpu %u :" to "CPU%u:".
>

ok

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency

[Poddar, Sourav]

On Tue, Jun 28, 2011 at 1:41 PM, Per Forlin  wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost more due to
> multiple cache levels and speculative cache pre-fetch. In relation the
> cost for handling the caches have increased and is now a bottle neck
> dealing with fast eMMC together with DMA.
>
> The intention for introducing non-blocking mmc requests is to minimize the
> time between a mmc request ends and another mmc request starts. In the
> current implementation the MMC controller is idle when dma_map_sg and
> dma_unmap_sg is processing. Introducing non-blocking mmc request makes it
> possible to prepare the caches for next job in parallel to an active
> mmc request.
>
> This is done by making the issue_rw_rq() non-blocking.
> The increase in throughput is proportional to the time it takes to
> prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
> a request and how fast the memory is. The faster the MMC/SD is
> the more significant the prepare request time becomes. Measurements on U5500
> and Panda on eMMC and SD shows significant performance gain for large
> reads when running DMA mode. In the PIO case the performance is unchanged.
>
> There are two optional hooks pre_req() and post_req() that the host driver
> may implement in order to move work to before and after the actual mmc_request
> function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
> the dma descriptor and post_req runs the dma_unmap_sg.
>
> Details on measurements from IOZone and mmc_test:
> https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
>
> Changes since v7:
>  * rebase on mmc-next, on top of Russell's updated error handling.
>  * Clarify description of mmc_start_req()
>  * Resolve compile without CONFIG_DMA_ENIGNE issue for mmci
>  * Add mmc test to measure how performance is affected by sg length
>  * Add missing wait_for_busy in mmc_test non-blocking test. This call got lost
>   in v4 of this patchset when refactoring mmc_start_req.
>  * Add sub-prefix (core block queue) to relevant patches.
>
> Per Forlin (12):
>  mmc: core: add non-blocking mmc request function
>  omap_hsmmc: add support for pre_req and post_req
>  mmci: implement pre_req() and post_req()
>  mmc: mmc_test: add debugfs file to list all tests
>  mmc: mmc_test: add test for non-blocking transfers
>  mmc: mmc_test: test to measure how sg_len affect performance
>  mmc: block: add member in mmc queue struct to hold request data
>  mmc: block: add a block request prepare function
>  mmc: block: move error code in issue_rw_rq to a separate function.
>  mmc: queue: add a second mmc queue request member
>  mmc: core: add random fault injection
>  mmc: block: add handling for two parallel block requests in
>    issue_rw_rq
>
>  drivers/mmc/card/block.c      |  505 
> -
>  drivers/mmc/card/mmc_test.c   |  491 ++--
>  drivers/mmc/card/queue.c      |  184 ++--
>  drivers/mmc/card/queue.h      |   33 ++-
>  drivers/mmc/core/core.c       |  167 +-
>  drivers/mmc/core/debugfs.c    |    5 +
>  drivers/mmc/host/mmci.c       |  147 +++-
>  drivers/mmc/host/mmci.h       |    8 +
>  drivers/mmc/host/omap_hsmmc.c |   87 +++-
>  include/linux/mmc/core.h      |    6 +-
>  include/linux/mmc/host.h      |   24 ++
>  lib/Kconfig.debug             |   11 +
>  12 files changed, 1345 insertions(+), 323 deletions(-)



Boot tested on Omap4430 Blaze board.

Tested-by: Sourav Poddar

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC pm-qa 0/2] tests for cpufreq

[Paul Larson]

On Thu, Jun 30, 2011 at 10:44 AM, Daniel Lezcano
wrote:

> I added in attachment the result of these scripts on a fully working
> cpufreq framework on my intel box. That will show the ouput of the tests.
>
> But the cpufreq is not complete on a pandaboard, so results won't be
> really nice.
>
> Looking at your results answered some of my questions at least, it seems to
have a very different format for the output than the previous tests.  Are
the older ones replaced by this, extended by it, or is this just a
completely separate testsuite?  If it's to be considered a different
testsuite, that makes some sense, as the type of tests here seem to be
consistent pass/fail sorts of tests.  However I have a few concerns for
having it be easily parsed into results that can be stored automatically:

for 'cpu0':
> checking scaling_available_governors file presence ...PASS
> checking scaling_governor file presence ...   PASS
> for 'cpu1':
> checking scaling_available_governors file presence ...PASS
> checking scaling_governor file presence ...   PASS

 ...
Heading1
 test_id1
 test_id2
Heading2
 test_id1
 test_id2
This is notoriously a bit tricky to deal with.  It can be done, but the
parsing has to track which heading it's under, and modify the test_id (or
some attribute of it) to designate how it differs from other testcases with
the exact same name.  It can be done, but since you have complete control
over how you output results, it can easily be changed in such a way that is
easy to parse, and easy for a human to look at.
What might be easier is:
cpu0_scaling_available_governors_file_exists: PASS
cpu0_scaling_governor_file_exists: PASS
cpu1_scaling_available_governors_file_exists: PASS
cpu1_scaling_governor_file_exists: PASS
...

Another thing that I'm curious about here is...

> saving governor for cpu0 ...  DONE

Is that a result? Or just an informational message?  That's not clear, even
as a human reader.

deviation 0 % for 2333000 is ...  VERY
> GOOD

Same comments as above about having an easier to interpret format, but the
result here: "VERY GOOD" - what does that mean?  What are the other possible
values?  Is this simply another way of saying "PASS"?  Or should it actually
be a measurement reported here?

Thanks,
Paul Larson

>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3] Add ARM cpu topology definition

[Russell King - ARM Linux]

On Fri, Jun 24, 2011 at 08:38:44PM +0200, Vincent Guittot wrote:
> + printk(KERN_INFO "cpu %u : thread %d cpu %d, socket %d, mpidr %x\n",
> + cpuid, cpu_topology[cpuid].thread_id,
> + cpu_topology[cpuid].core_id,
> + cpu_topology[cpuid].socket_id, mpidr);
> +
> +}

Please remove that empty blank line before the closing brace.

Also...

cpu 0 : thread -1 cpu 0, socket 0, mpidr 8000
Calibrating local timer... 199.99MHz.
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
CPU1: Booted secondary processor
cpu 1 : thread -1 cpu 1, socket 0, mpidr 8001
CPU2: Booted secondary processor
cpu 2 : thread -1 cpu 2, socket 0, mpidr 8002
CPU3: Booted secondary processor
cpu 3 : thread -1 cpu 3, socket 0, mpidr 8003
Brought up 4 CPUs

It'd be better to have some consistency there - please change from
"cpu %u :" to "CPU%u:".

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Android libjpeg

[DRC]

I still posit that it's possible to avoid many of those inefficiencies by using 
a sufficiently large buffer in libjpeg-turbo and using an in-memory 
source/destination manager. Much of the inefficiency in the code relates to the 
buffering that it does to avoid reading the entire image into memory.

I also hasten to point out that not all of the compute-intensive parts of the 
code are NEON-accelerated. The general speedup we're seeing in NEON vs non-NEON 
is about 1.5-2x rather than the 3-4x we see with x86-64. Not sure whether ARM 
is 64-bit, but using 64-bit code will improve Huffman en/decoding performance 
significantly. It may also be the case that the hand-tuned code I wrote in the 
Huffman codec is making performance assumptions based on x86 that aren't true 
for ARM. It would be interesting to see what the speedup is with the 
unoptimized Huffman code out of libjpeg. At least on x86, Huffman can account 
for 40% of the compute time, so optimizing it further has a potentially big 
pay-off. However, I've personally spent hundreds of hours getting it where it 
is, and I have a gut feeling that further optimization of it would require 
dropping down to assembly.

On Jun 29, 2011, at 3:03 PM, Måns Rullgård  wrote:

> Vladimir Pantelic  writes:
> 
>> Mandeep Kumar wrote:
>>> Hi All,
>>> 
>>> I have done some benchmarking on OMAP4  running Ubuntu for various versions 
>>> of libjpegs. Benchmarks were collected with
>>> modified version of djpeg that prints out ms time taken for decoding. 
>>> Sample used for benchmarking is a 12MP image
>>> downloaded from a photography website. Here are the results:
>> 
>> ...
>> 
>>> libjpeg-turbo trunk version that has NEON patches (5 runs). 
>>> *http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/*
>>> * Decoding Time for Run 1: 1068 ms
>>>  Decoding Time for Run 2: 1065 ms
>>>  Decoding Time for Run 3: 1093 ms
>>>  Decoding Time for Run 4: 1066 ms
>>>  Decoding Time for Run 5: 1067 ms
>>> *Median Decoding Time: 1067 ms*
>> 
>> One remark:
>> 
>> a 12MP image decoded in 1076ms equals ~12MP/s decoding speed.
>> 
>> decoding a 640x480 MJPEG file on a 1GHz OMAP4 using libavcodec
>> gives me an average decoding time per frame of ~10ms which yields:
>> 
>> 640x480/10ms = ~30MP/s
>> 
>> so roughly 2.5 times faster.
>> 
>> Either I am doing something wrong or this libjpeg-turbo is not so turbo.
> 
> Libjpeg (turbo or regular) is full of inefficiencies.  I guess they all
> add up.
> 
> -- 
> Måns Rullgård
> m...@mansr.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[Patch 5/11] Regulator: DA9052 regulator support v2

[ashishj3]

The DA9052 PMIC has below featured regulators:-
4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
10 Programmable LDO's High PSSR, 1% accuracy.

This patch support all the DA9052 regulators. The output voltages are fully
programmable via I2C or SPI interface. The platform data with regulation
constraints is passed down from the board to the regulator.

Signed-off-by: David Dajun Chen 
Signed-off-by: Ashish Jangam 
CC: Mark Brown 
---
Changes since v2
- Check for current min_uA < 70
- Corrected current conversions from mA to uA
---
 drivers/regulator/Kconfig|7 +
 drivers/regulator/Makefile   |1 +
 drivers/regulator/da9052-regulator.c |  544 ++
 3 files changed, 552 insertions(+), 0 deletions(-)
 create mode 100755 drivers/regulator/da9052-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index fa61fe2..ae80461 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -167,6 +167,13 @@ config REGULATOR_DA903X
  Say y here to support the BUCKs and LDOs regulators found on
  Dialog Semiconductor DA9030/DA9034 PMIC.
 
+config REGULATOR_DA9052
+tristate "Dialog DA9052 regulators"
+depends on PMIC_DA9052
+help
+  Say y here to support the BUCKs and LDOs regulators found on
+  Dialog Semiconductor DA9052 PMIC.
+
 config REGULATOR_PCF50633
tristate "PCF50633 regulator driver"
 depends on MFD_PCF50633
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 8cb6d0d..3738361 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
 obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
diff --git a/drivers/regulator/da9052-regulator.c 
b/drivers/regulator/da9052-regulator.c
new file mode 100755
index 000..e7126d7
--- /dev/null
+++ b/drivers/regulator/da9052-regulator.c
@@ -0,0 +1,544 @@
+/*
+* da9052-regulator.c: Regulator driver for DA9052
+*
+* Copyright(c) 2011 Dialog Semiconductor Ltd.
+*
+*Author: David Dajun Chen 
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or
+* (at your option) any later version.
+*
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Buck step size */
+#define DA9052_BUCK_PERI_3uV_STEP  10
+#define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV  24
+#define DA9052_CONST_3uV   300
+
+/* Buck current limits */
+#define DA9052_BUCK_CURRENT_LIMIT_700mA 0
+#define DA9052_BUCK_CURRENT_LIMIT_800mA 1
+#define DA9052_BUCK_CURRENT_LIMIT_1000mA2
+#define DA9052_BUCK_CURRENT_LIMIT_1200mA3
+
+/* Bit masks */
+#define DA9052_BUCK_ILIM_MASK_EVEN 0x3F
+#define DA9052_BUCK_ILIM_MASK_ODD  0xF3
+
+struct da9052_regulator_info {
+   struct regulator_desc reg_desc;
+   int step_uV;
+   int min_uV;
+   int max_uV;
+   unsigned char volt_shift;
+   unsigned char en_bit;
+   unsigned char activate_bit;
+};
+
+struct da9052_regulator {
+   struct da9052 *da9052;
+   struct da9052_regulator_info *info;
+   struct regulator_dev *rdev;
+};
+
+static int verify_range(struct da9052_regulator_info *info,
+int min_uV, int max_uV)
+{
+   if (min_uV < info->min_uV || min_uV > info->max_uV)
+   return -EINVAL;
+   if (max_uV < info->min_uV || max_uV > info->max_uV)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int da9052_regulator_enable(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+   struct da9052_regulator_info *info = regulator->info;
+   int offset = rdev_get_id(rdev);
+
+   return da9052_reg_update(regulator->da9052,
+DA9052_BUCKCORE_REG + offset,
+1 << info->en_bit, 1);
+}
+
+static int da9052_regulator_disable(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+   struct da9052_regulator_info *info = regulator->info;
+   int offset = rdev_get_id(rdev);
+
+   return da9052_reg_update(regulator->da9052,
+DA9052_BUCKCORE_REG + offset,
+1 << info->en_bit, 0);
+}
+
+static int da9052_regulator_is_enabled(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulat

[Patch 5/11] Regulator: DA9052 regulator support v2

[ashishj3]

The DA9052 PMIC has below featured regulators:-
4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
10 Programmable LDO's High PSSR, 1% accuracy.

This patch support all the DA9052 regulators. The output voltages are fully
programmable via I2C or SPI interface. The platform data with regulation
constraints is passed down from the board to the regulator.

Signed-off-by: David Dajun Chen 
Signed-off-by: Ashish Jangam 
CC: Mark Brown 
---
Changes since v2
- Check for current min_uA < 70
- Corrected current conversions from mA to uA
---
 drivers/regulator/Kconfig|7 +
 drivers/regulator/Makefile   |1 +
 drivers/regulator/da9052-regulator.c |  544 ++
 3 files changed, 552 insertions(+), 0 deletions(-)
 create mode 100755 drivers/regulator/da9052-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index fa61fe2..ae80461 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -167,6 +167,13 @@ config REGULATOR_DA903X
  Say y here to support the BUCKs and LDOs regulators found on
  Dialog Semiconductor DA9030/DA9034 PMIC.
 
+config REGULATOR_DA9052
+tristate "Dialog DA9052 regulators"
+depends on PMIC_DA9052
+help
+  Say y here to support the BUCKs and LDOs regulators found on
+  Dialog Semiconductor DA9052 PMIC.
+
 config REGULATOR_PCF50633
tristate "PCF50633 regulator driver"
 depends on MFD_PCF50633
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 8cb6d0d..3738361 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
 obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
diff --git a/drivers/regulator/da9052-regulator.c 
b/drivers/regulator/da9052-regulator.c
new file mode 100755
index 000..e7126d7
--- /dev/null
+++ b/drivers/regulator/da9052-regulator.c
@@ -0,0 +1,544 @@
+/*
+* da9052-regulator.c: Regulator driver for DA9052
+*
+* Copyright(c) 2011 Dialog Semiconductor Ltd.
+*
+*Author: David Dajun Chen 
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or
+* (at your option) any later version.
+*
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Buck step size */
+#define DA9052_BUCK_PERI_3uV_STEP  10
+#define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV  24
+#define DA9052_CONST_3uV   300
+
+/* Buck current limits */
+#define DA9052_BUCK_CURRENT_LIMIT_700mA 0
+#define DA9052_BUCK_CURRENT_LIMIT_800mA 1
+#define DA9052_BUCK_CURRENT_LIMIT_1000mA2
+#define DA9052_BUCK_CURRENT_LIMIT_1200mA3
+
+/* Bit masks */
+#define DA9052_BUCK_ILIM_MASK_EVEN 0x3F
+#define DA9052_BUCK_ILIM_MASK_ODD  0xF3
+
+struct da9052_regulator_info {
+   struct regulator_desc reg_desc;
+   int step_uV;
+   int min_uV;
+   int max_uV;
+   unsigned char volt_shift;
+   unsigned char en_bit;
+   unsigned char activate_bit;
+};
+
+struct da9052_regulator {
+   struct da9052 *da9052;
+   struct da9052_regulator_info *info;
+   struct regulator_dev *rdev;
+};
+
+static int verify_range(struct da9052_regulator_info *info,
+int min_uV, int max_uV)
+{
+   if (min_uV < info->min_uV || min_uV > info->max_uV)
+   return -EINVAL;
+   if (max_uV < info->min_uV || max_uV > info->max_uV)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int da9052_regulator_enable(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+   struct da9052_regulator_info *info = regulator->info;
+   int offset = rdev_get_id(rdev);
+
+   return da9052_reg_update(regulator->da9052,
+DA9052_BUCKCORE_REG + offset,
+1 << info->en_bit, 1);
+}
+
+static int da9052_regulator_disable(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+   struct da9052_regulator_info *info = regulator->info;
+   int offset = rdev_get_id(rdev);
+
+   return da9052_reg_update(regulator->da9052,
+DA9052_BUCKCORE_REG + offset,
+1 << info->en_bit, 0);
+}
+
+static int da9052_regulator_is_enabled(struct regulator_dev *rdev)
+{
+   struct da9052_regulator *regulat

Re: Android libjpeg

[Måns Rullgård]

Mandeep Kumar  writes:

>> Vladimir Pantelic  writes:
>>
>> > Mandeep Kumar wrote:
>> >> Hi All,
>> >>
>> >> I have done some benchmarking on OMAP4  running Ubuntu for various
>> >> versions of libjpegs. Benchmarks were collected with
>> >> modified version of djpeg that prints out ms time taken for decoding.
>> >> Sample used for benchmarking is a 12MP image
>> >> downloaded from a photography website. Here are the results:
>> >
>> > ...
>> >
>> >> libjpeg-turbo trunk version that has NEON patches (5 runs). *
>> >> http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/*
>> >> * Decoding Time for Run 1: 1068 ms
>> >>   Decoding Time for Run 2: 1065 ms
>> >>   Decoding Time for Run 3: 1093 ms
>> >>   Decoding Time for Run 4: 1066 ms
>> >>   Decoding Time for Run 5: 1067 ms
>> >> *Median Decoding Time: 1067 ms*
>> >
>> > One remark:
>> >
>> > a 12MP image decoded in 1076ms equals ~12MP/s decoding speed.
>> >
>> > decoding a 640x480 MJPEG file on a 1GHz OMAP4 using libavcodec
>> > gives me an average decoding time per frame of ~10ms which yields:
>> >
>> > 640x480/10ms = ~30MP/s
>> >
>> > so roughly 2.5 times faster.
>> >
>> > Either I am doing something wrong or this libjpeg-turbo is not so turbo.
>>
>> Libjpeg (turbo or regular) is full of inefficiencies.  I guess they all
>> add up.
>>
> My numbers should only be used for relative comparison purpose as djpeg
> decoding time that I sent also include time to read input file from
> filessystem. Actual decoding speed may be  higher when special modification
> are done in djpeg application to read input from memory.

I doubt reading from a cached file can account for that much time.
Besides, I presume Vladimir was reading his file from somewhere too.

However, no matter how slow libjpeg is, that's what lots of apps use,
and thus improving it should be beneficial to them insofar jpeg decoding
is a bottleneck.

-- 
Måns Rullgård
m...@mansr.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 6/11] HWMON: DA9052 hwmon driver v1

[Guenter Roeck]

On Wed, Jun 29, 2011 at 07:44:08AM -0400, Ashish Jangam wrote:
> On Tue, 2011-06-28 at 23:05 +0530, Guenter Roeck wrote:
> > On Tue, 2011-06-28 at 10:24 -0400, ashish jangam wrote:
> > > +static ssize_t da9052_read_vddout(struct device *dev,
> > > +  struct device_attribute *devattr, char 
> > > *buf)
> > > +{
> > > +   struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> > > +   int ret, vdd = -1;
> > > +
> > > +   mutex_lock(&hwmon->hwmon_lock);
> > > +
> > > +   ret = da9052_enable_vddout_channel(hwmon->da9052);
> > > +   if (ret < 0)
> > > +   goto hwmon_err;
> > > +
> > > +   ret = da9052_reg_read(hwmon->da9052, DA9052_VDD_RES_REG);
> > > +   if (ret < 0)
> > > +   pr_err("failed to read VDD_RES_REG\n");
> > > +   else
> > > +   vdd = ret;
> > > +
> > > +   ret = da9052_disable_vddout_channel(hwmon->da9052);
> > > +   if (ret < 0)
> > > +   goto hwmon_err;
> > > +
> > > +   if (vdd >= 0) {
> > > +   mutex_unlock(&hwmon->hwmon_lock);
> > > +   return sprintf(buf, "%d\n", vdd);
> > > +   }
> > > +
> > > +hwmon_err:
> > > +   mutex_unlock(&hwmon->hwmon_lock);
> > > +   return ret;
> > > +}
> > 
> > This function still produces a bad result if the call to
> > da9052_reg_read() fails and the call to da9052_disable_vddout_channel()
> > doesn't. 
> Thanks much for comments and patience. When vddout channel is enabled
> and then read from this channel fails then, in this case should vddout
> channel get disabled? Is this correct understanding.

Hmm, yes, you are right there. You should try to disable it. But you would have 
to do that such that you don't override the original error. One possibility 
would
be to add an unconditional call to da9052_disable_vddout_channel() into the 
error 
path.

ret = da9052_reg_read(hwmon->da9052, DA9052_VDD_RES_REG);
if (ret < 0)
goto hwmon_err_release;

...
hwmon_err_release:
da9052_disable_vddout_channel(hwmon->da9052);
hwmon_err:
...

Guenter

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Android libjpeg

[Måns Rullgård]

Vladimir Pantelic  writes:

> Mandeep Kumar wrote:
>> Hi All,
>>
>> I have done some benchmarking on OMAP4  running Ubuntu for various versions 
>> of libjpegs. Benchmarks were collected with
>> modified version of djpeg that prints out ms time taken for decoding. Sample 
>> used for benchmarking is a 12MP image
>> downloaded from a photography website. Here are the results:
>
> ...
>
>> libjpeg-turbo trunk version that has NEON patches (5 runs). 
>> *http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/*
>> * Decoding Time for Run 1: 1068 ms
>>   Decoding Time for Run 2: 1065 ms
>>   Decoding Time for Run 3: 1093 ms
>>   Decoding Time for Run 4: 1066 ms
>>   Decoding Time for Run 5: 1067 ms
>> *Median Decoding Time: 1067 ms*
>
> One remark:
>
> a 12MP image decoded in 1076ms equals ~12MP/s decoding speed.
>
> decoding a 640x480 MJPEG file on a 1GHz OMAP4 using libavcodec
> gives me an average decoding time per frame of ~10ms which yields:
>
> 640x480/10ms = ~30MP/s
>
> so roughly 2.5 times faster.
>
> Either I am doing something wrong or this libjpeg-turbo is not so turbo.

Libjpeg (turbo or regular) is full of inefficiencies.  I guess they all
add up.

-- 
Måns Rullgård
m...@mansr.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC pm-qa 0/2] tests for cpufreq

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/30/2011 11:09 AM, Amit Kucheria wrote:
> On 11 Jun 30, Daniel Lezcano wrote:
>> These tests are used to test the cpufreq driver on ARM architecture.
>> As the cpufreq is not yet complete, the test suite is based on the cpufreq
>> sysfs API exported on intel architecture, assuming it is consistent across
>> architecture.
>>
>> The different tests are described at:
>>
>> https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts
>>
>> Each test's header contains an URL to the anchor related item of this web 
>> page
>> describing the script.
>>
>> Daniel Lezcano (2):
>>   cpufreq: add a test set for cpufreq
>>   cpufreq: check the frequency affect the performances
>>
>>  Makefile   |6 ++
>>  cpufreq/test_01.sh |   43 ++
>>  cpufreq/test_02.sh |   43 ++
>>  cpufreq/test_03.sh |   64 ++
>>  cpufreq/test_04.sh |   85 +++
>>  cpufreq/test_05.sh |  145 
>>  cpufreq/test_06.sh |  236 
>> 
>>  utils/Makefile |   11 +++
>>  utils/cpucycle.c   |  102 ++
>>  utils/nanosleep.c  |   45 ++
>>  10 files changed, 780 insertions(+), 0 deletions(-)
>>  create mode 100644 cpufreq/test_01.sh
>>  create mode 100644 cpufreq/test_02.sh
>>  create mode 100644 cpufreq/test_03.sh
>>  create mode 100644 cpufreq/test_04.sh
>>  create mode 100644 cpufreq/test_05.sh
>>  create mode 100644 cpufreq/test_06.sh
>>  create mode 100644 utils/Makefile
>>  create mode 100644 utils/cpucycle.c
>>  create mode 100644 utils/nanosleep.c
>>
> 
> Daniel,
> 
> The scripts themselves look ok and the documentation is excellent. 

Thanks

But I'm in
> two minds regarding the location of the documentation though.
> 
> While having it on a wiki in the current form allows people w/o access to the
> code to browse through the docs, it means that the 'comments' are at a
> different place from the code.

I though, once commited, the patches to add a link for each test
description in the wiki page to the corresponding file in the git pm-qa
repo.

> But as long as you're confident this works for you, I'm ok with it.
> 
> Once youv've published the tree, please get in touch with Paul Larson to
> start pulling these scripts into LAVA.

Sure.

> I'd like to see what the reports would
> look like.

I added in attachment the result of these scripts on a fully working
cpufreq framework on my intel box. That will show the ouput of the tests.

But the cpufreq is not complete on a pandaboard, so results won't be
really nice.


- -- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJODEV7AAoJEAKBbMCpUGYA60YH+QGBcRseV68zwcMcaF7HLnBm
AQVJti3VqIlq535wJj/tk2wymosWtZJSSjRI06G1twXZ2Mzw6K65aEj4KM6dJuji
rdtkIF3+T+FHxPuhBkYuv5rIa2DRGiKxoUgIf8GZhFSJB5z1+SjU3muQFe292DL/
U/hLmtam1vzBDs/+Q3iA/DdX3N/ZYu21xAfmyDhT6vZgTXenaK++fFi04dmX8oxQ
fz/yrfUkEPfKqiwnn7L+VQnnKi8s39unbKmaD9bUk9UgWzqB1nWe4EW1T1OpWUUb
S5G5ebjt72B4tfTKeFkOciyQzYcYShfCCoRV0DZFEIin7QLtBeTPZv5V2Lf8BfE=
=9KXc
-END PGP SIGNATURE-
make[1]: Entering directory `/home/dlezcano/work/src/pm-qa/utils'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/dlezcano/work/src/pm-qa/utils'
make[1]: Entering directory `/home/dlezcano/work/src/pm-qa/cpufreq'

--- Running test_01.sh ---
for 'cpu0':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file presence ...   PASS
checking scaling_setspeed file presence ...   PASS
for 'cpu1':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file presence ...   PASS
checking scaling_setspeed file presence ...   PASS
for 'cpu2':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file presence ...   PASS
checking scaling_setspeed file presence ...   PASS
for 'cpu3':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file presence ...   PASS
checking scaling_setspeed file presence ...   PASS
for 'cpu4':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file presence ...   PASS
checking scaling_setspeed file presence ...   PASS
for 'cpu5':
checking scaling_available_frequencies file presence ...  PASS
checking scaling_cur_freq file pr

Re: [RFC pm-qa 0/2] tests for cpufreq

[Paul Larson]

On Wed, Jun 29, 2011 at 11:35 PM, Daniel Lezcano
wrote:

> These tests are used to test the cpufreq driver on ARM architecture.
> As the cpufreq is not yet complete, the test suite is based on the cpufreq
> sysfs API exported on intel architecture, assuming it is consistent across
> architecture.
>
> Hi Daniel, are these built on top of the previous pmqa testsuite so that
they will work automatically?  Or do we need to make updates to the test
definition in lava-test?  As long as they are going into the same git tree,
and don't do anything that changes the way the results were parsed, they
should be fine, but I wanted to make sure.

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC pm-qa 0/2] tests for cpufreq

[Amit Kucheria]

On 11 Jun 30, Daniel Lezcano wrote:
> These tests are used to test the cpufreq driver on ARM architecture.
> As the cpufreq is not yet complete, the test suite is based on the cpufreq
> sysfs API exported on intel architecture, assuming it is consistent across
> architecture.
> 
> The different tests are described at:
> 
> https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts
> 
> Each test's header contains an URL to the anchor related item of this web page
> describing the script.
> 
> Daniel Lezcano (2):
>   cpufreq: add a test set for cpufreq
>   cpufreq: check the frequency affect the performances
> 
>  Makefile   |6 ++
>  cpufreq/test_01.sh |   43 ++
>  cpufreq/test_02.sh |   43 ++
>  cpufreq/test_03.sh |   64 ++
>  cpufreq/test_04.sh |   85 +++
>  cpufreq/test_05.sh |  145 
>  cpufreq/test_06.sh |  236 
> 
>  utils/Makefile |   11 +++
>  utils/cpucycle.c   |  102 ++
>  utils/nanosleep.c  |   45 ++
>  10 files changed, 780 insertions(+), 0 deletions(-)
>  create mode 100644 cpufreq/test_01.sh
>  create mode 100644 cpufreq/test_02.sh
>  create mode 100644 cpufreq/test_03.sh
>  create mode 100644 cpufreq/test_04.sh
>  create mode 100644 cpufreq/test_05.sh
>  create mode 100644 cpufreq/test_06.sh
>  create mode 100644 utils/Makefile
>  create mode 100644 utils/cpucycle.c
>  create mode 100644 utils/nanosleep.c
>

Daniel,

The scripts themselves look ok and the documentation is excellent. But I'm in
two minds regarding the location of the documentation though.

While having it on a wiki in the current form allows people w/o access to the
code to browse through the docs, it means that the 'comments' are at a
different place from the code.

But as long as you're confident this works for you, I'm ok with it.

Once youv've published the tree, please get in touch with Paul Larson to
start pulling these scripts into LAVA. I'd like to see what the reports would
look like.

Cheers,
Amit

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: trouble with should-be-bootable SD cards and kernel versions

[David Gilbert]

On 29 June 2011 23:40, AJ ONeal  wrote:
> The cards are from the same manufacturer, and exactly the same size.

Is the ID of the card as reported by
/sys/class/mmc_host/mmc0/mmc0:0001/manfid and oemid
(adjust path to your SD card interface) the same for the cards that
work and the cards that don't?

(If you haven't seen it you might also look at the table on:

https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey

)

Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Vladimir Pantelic]

Dechesne, Nicolas wrote:



On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic mailto:vlado...@gmail.com>> wrote:

would you be able to come up with a short list of "fixes" that have been 
done?

the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the ROM 
code will read the FAT table. in OMAP3
if you keep replacing the MLO/uboot/uimage (whether you cp or mv to it) after a 
while (~10 iterations, iirc) the ROM
code will not be able to locate MLO anymore, and you need to reformat the card. 
this problem is fixed on OMAP4. there
might be other things, but this one was really the biggest issue i think.


thanks!


also, note that the SD can be used as RAW instead of FAT, in which case you 
aren't going through the embedded FAT
implementation and avoid such issues.


sure, that's how we boot from emmc :)


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Dechesne, Nicolas]

On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic wrote:

> would you be able to come up with a short list of "fixes" that have been
> done?
>

the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the
ROM code will read the FAT table. in OMAP3 if you keep replacing the
MLO/uboot/uimage (whether you cp or mv to it) after a while (~10 iterations,
iirc) the ROM code will not be able to locate MLO anymore, and you need to
reformat the card. this problem is fixed on OMAP4. there might be other
things, but this one was really the biggest issue i think.

also, note that the SD can be used as RAW instead of FAT, in which case you
aren't going through the embedded FAT implementation and avoid such issues.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Andy Green]

On 06/30/2011 08:11 AM, Somebody in the thread at some point said:

Hi -


yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the
feedback from linux/SD card users.


I think it pretty much reached perfection on OMAP4 for SD boot case 
anyway.  In fact a VFAT and partition parser in ROM was more than I 
expected to see, it's very good.



Of course, it'll pull anything called MLO.  I believe folks are
working on adding stuff to be able to call U-Boot "MLO" directly
eliminating x-loader and Matt Hsu and I already did that for Qi.


one clarification: the u-boot MLO project is just about the capabilities
of rebuilding MLO from u-boot sources. in fact MLO is a 'tiny uboot'. so
instead of duplicating the source tree for x-loader as it stands today,
the idea is to have a mlo config in uboot and rebuild this tiny uboot
from uboot sources so that there is no need to maintain 2 MMC driver for
example. you will still get a 2-stage bootloader.


FWIW panda-dev branch of Qi does it in one stage, and it's not that much 
bigger than x-loader alone.  It just loads and boots linux plus or minus 
initrd though so it's not the same as U-Boot.



Yeah confusing ain't it.  There are two camps in x-loader
development one on omapzoom and one on gitorious.  TI engineers like
omapzoom but the official repo is gitorious.


i don't think it's a TI vs others issue. TI has been pushing for a


Right, I meant, as you can see from the two commit logs, that TI 
engineers "like" to push to omapzoom repo and the official one less so.



mailing xloader because there is a lot of confusion on this topic. the
clean mainline tree started after the android xloader and is still
lacking behind. if community/TI is able to bring mainline x-loader to
the same level of features has the omapzoom one, I am pretty sure that
the migration can happen.


I did create a unification branch a while ago which merged all omapzoom 
content on to the gitorious one.  The result worked fine on Panda, but I 
didn't test it on anything else.


http://gitorious.org/x-loader/x-loader/commits/unified

-Andy


--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Vladimir Pantelic]

Dechesne, Nicolas wrote:


ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in 
OMAP4 stuff seems pretty much perfect for
SD Card boot case, it doesn't care about any arcane stuff like geometry for 
example.  It only needs to success to
pull MLO reliably and anything further can be done there in an upgradeable 
way.


yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback 
from linux/SD card users.


would you be able to come up with a short list of "fixes" that have been done?


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Vladimir Pantelic]

Andy Green wrote:


I think we can count that as arcarna... but I think we're talking about
different problems, and that the ROM fragility to partitioning on OMAP3
is real enough.

On an IGEP0020 I was unable to create a bootable image -- one that would
boot x-loader so it would talk on the serial console -- even after a
couple of days struggling.  It was only 'solved' in the end when Loic
imaged the start of his magic working card and I dd'd it on to mine.
Then it was happy even when I put my MLO on there.


It would have been interesting to compare the 2 cards. In fact I did that
once for a friend that had similar issues and in the end came up with:

http://groups.google.com/group/beagleboard/browse_thread/thread/ae8e64e6be02baae?pli=1

the fact that partition size in MBR and FAT have to match came as a little
surprise :)



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Dechesne, Nicolas]

andy, paul,

On Thu, Jun 30, 2011 at 6:26 AM, Andy Green  wrote:

> Nicolas already gave a rundown but the short answer is the ROM can drive
> the MMC hardware of the OMAP4, talk SD-HC protocol, parse your partition
> table and FAT filesystem on your SD Card, and will load and execute a file
> of the magic name "MLO" on partition 1.
>
> That is "x-loader", which sets stuff up and loads and executes a magic file
> "u-boot.bin" off partition 1.  And "u-boot" does its usual thing from then
> on.
>

unlike MLO filename which is hardcoded in the ROM code (hence cannot change)
the 'u-boot.bin' is coded in x-loader and is manageable. as it turns out ROM
code needs to be able to read FAT/SD, x-loader needs that too (to load
u-boot), and u-boot as well ;-) how funny...


>
> ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in
> OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care
> about any arcane stuff like geometry for example.  It only needs to success
> to pull MLO reliably and anything further can be done there in an
> upgradeable way.
>

yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the
feedback from linux/SD card users.


>
> Of course, it'll pull anything called MLO.  I believe folks are working on
> adding stuff to be able to call U-Boot "MLO" directly eliminating x-loader
> and Matt Hsu and I already did that for Qi.
>

one clarification: the u-boot MLO project is just about the capabilities of
rebuilding MLO from u-boot sources. in fact MLO is a 'tiny uboot'. so
instead of duplicating the source tree for x-loader as it stands today, the
idea is to have a mlo config in uboot and rebuild this tiny uboot from uboot
sources so that there is no need to maintain 2 MMC driver for example. you
will still get a 2-stage bootloader.


>
>  So, it would be nice if you could suggest Android team which
>> repo/branch/tag/revision can be safely used to produce releases.
>>
>
> Yeah confusing ain't it.  There are two camps in x-loader development one
> on omapzoom and one on gitorious.  TI engineers like omapzoom but the
> official repo is gitorious.
>

i don't think it's a TI vs others issue. TI has been pushing for a mailing
xloader because there is a lot of confusion on this topic. the clean
mainline tree started after the android xloader and is still lacking behind.
if community/TI is able to bring mainline x-loader to the same level of
features has the omapzoom one, I am pretty sure that the migration can
happen.


> The magic branch I (and I believe Ubuntu) use is:
>
> git://gitorious.org/x-loader/**x-loader.gitmaster
>
> ... and BTW, 3.0 android kernel from us requires MLO update from what you
> supply at the moment to this in order for 3D unit to start up.  So this is a
> good idea anyway.
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Andy Green]

On 06/30/2011 08:00 AM, Somebody in the thread at some point said:

Andy Green wrote:


ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in
OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't
care about any arcane stuff like geometry for example. It only needs to
success to pull MLO reliably and anything further can be done there in
an upgradeable way.


neither does the OMAP3 ROM code. All the cargo cult around geometry stems
from the fact that initially x-loader aka MLO hardcoded sector 63 for the
start of the boot partition and this is fixed since long. Unfortunately,
there is a large number of ancient unfixed MLO files out there...


I think we can count that as arcarna... but I think we're talking about 
different problems, and that the ROM fragility to partitioning on OMAP3 
is real enough.


On an IGEP0020 I was unable to create a bootable image -- one that would 
boot x-loader so it would talk on the serial console -- even after a 
couple of days struggling.  It was only 'solved' in the end when Loic 
imaged the start of his magic working card and I dd'd it on to mine. 
Then it was happy even when I put my MLO on there.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Pandaboard is / x-loader flow and official branch

[Vladimir Pantelic]

Andy Green wrote:


ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in
OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't
care about any arcane stuff like geometry for example.  It only needs to
success to pull MLO reliably and anything further can be done there in
an upgradeable way.


neither does the OMAP3 ROM code. All the cargo cult around geometry stems
from the fact that initially x-loader aka MLO hardcoded sector 63 for the
start of the boot partition and this is fixed since long. Unfortunately,
there is a large number of ancient unfixed MLO files out there...


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev