pm-qa integration in LAVA

2011-08-02 Thread Daniel Lezcano
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Paul,

I commited the different tests for pm-qa [1]

Can you integrate it with LAVA ?

In order to invoke the tests, just do 'sudo make check' on the topmost
directory of pm-qa, that will compile the different utilities and run
the tests.

The results [2] will be 'PASS', 'FAIL', or 'SKIP'.

At present, only the cpufreq tests are available and most of them will
fail because cpufreq is still work in progress on ARM. But I think it is
worth to have them running, so when the kernel is updated we should see
more tests to PASS.

The test suite will be continuously updated with new tests, you just
have to take care of updating the git tree. The invocation of the tests
won't change, I will take care of writing the correct Makefile for the
dependencies.

Thanks in advance

  -- Daniel


[1] http://git.linaro.org/git/tools/pm-qa.git

[2]
cpufreq:test_01/cpu0 checking scaling_available_frequencies exists ...
   PASS
cpufreq:test_01/cpu0 checking scaling_cur_freq exists ...
   PASS
cpufreq:test_01/cpu0 checking scaling_setspeed exists ...
   PASS
cpufreq:test_01/cpu1 checking scaling_available_frequencies exists ...
   PASS
cpufreq:test_01/cpu1 checking scaling_cur_freq exists ...
   PASS
cpufreq:test_01/cpu1 checking scaling_setspeed exists ...
   PASS
cpufreq:test_02/cpu0 checking scaling_available_governors exists ...
   PASS
cpufreq:test_02/cpu0 checking scaling_governor exists ...
   PASS
cpufreq:test_02/cpu1 checking scaling_available_governors exists ...
   PASS
cpufreq:test_02/cpu1 checking scaling_governor exists ...
   PASS
cpufreq:test_03/cpu0 checking governor change to 'conservative' ...
   PASS
cpufreq:test_03/cpu0 checking governor change to 'ondemand' ...
   PASS
cpufreq:test_03/cpu0 checking governor change to 'userspace' ...
   PASS
cpufreq:test_03/cpu0 checking governor change to 'powersave' ...
   PASS
cpufreq:test_03/cpu0 checking governor change to 'performance' ...
   PASS
cpufreq:test_03/cpu1 checking governor change to 'conservative' ...
   PASS
cpufreq:test_03/cpu1 checking governor change to 'ondemand' ...
   PASS
cpufreq:test_03/cpu1 checking governor change to 'userspace' ...
   PASS
cpufreq:test_03/cpu1 checking governor change to 'powersave' ...
   PASS
cpufreq:test_03/cpu1 checking governor change to 'performance' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '2.6 GHz' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '2.6 GHz' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '2.0 GHz' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '1.6 GHz' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '1.2 GHz' ...
   PASS
cpufreq:test_04/cpu0 checking setting frequency '800.0 MHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '2.6 GHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '2.6 GHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '2.0 GHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '1.6 GHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '1.2 GHz' ...
   PASS
cpufreq:test_04/cpu1 checking setting frequency '800.0 MHz' ...
   PASS
cpufreq:test_05/cpu1 checking 'ondemand' directory exists ...
   PASS
cpufreq:test_05/cpu1 checking 'conservative' directory exists ...
   PASS
cpufreq:test_05/cpu1 checking 'ondemand' directory is not there ...
   PASS
cpufreq:test_05/cpu1 checking 'conservative' directory is not there ...
   PASS
cpufreq:test_05/cpu1 checking 'ondemand' directory exists ...
   PASS
cpufreq:test_05/cpu1 checking 'conservative' directory exists ...
   PASS

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

iQEcBAEBAgAGBQJOOAmIAAoJEAKBbMCpUGYAe84H/3daucqFQKC9ZRwmqy1xFeIc
Oql0jREhfMuQWVunl2T2UXbAmR1ApyVlPTwRdmpoOmS4y4JRMxnM/PzRV9CU85gt
AE5NIUie4uERYRCPllMXNQ8S6KDWgHqX+usbGjsqLcrzeymMVvdsvF+705E24P5b
nDyaUnr9dMddftcV6i5fTGaPYUdXBFSCcsV4sDf0icqQULg+xRnbmtwQaaFGV4om
9B04q3s1PeQ1wUBoAzwiLEx6S5XryPKarh2QyedxZFaHIde8p07hutD3jI/0Wx3P
freFm42NcoRzmgIZp/FpbIPRy+bSum8cw6LpKpAR9LDqCbbX+6hJuQCiSvwimJc=
=0eTT
-END PGP SIGNATURE-

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


[PATCH] usb: musb: ux500: set dma config for both src and dst

2011-08-02 Thread Per Forlin
From: Per Forlin 

The dma driver requires both src and dst to be set.
This fix is needed in order to run gadget mass storage.
Patch is verified on snowball.

Signed-off-by: Per Forlin 
---
 drivers/usb/musb/ux500_dma.c |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index cecace4..2313475 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -133,15 +133,13 @@ static bool ux500_configure_channel(struct dma_channel 
*channel,
DMA_SLAVE_BUSWIDTH_4_BYTES;
 
slave_conf.direction = direction;
-   if (direction == DMA_FROM_DEVICE) {
-   slave_conf.src_addr = usb_fifo_addr;
-   slave_conf.src_addr_width = addr_width;
-   slave_conf.src_maxburst = 16;
-   } else {
-   slave_conf.dst_addr = usb_fifo_addr;
-   slave_conf.dst_addr_width = addr_width;
-   slave_conf.dst_maxburst = 16;
-   }
+   slave_conf.src_addr = usb_fifo_addr;
+   slave_conf.src_addr_width = addr_width;
+   slave_conf.src_maxburst = 16;
+   slave_conf.dst_addr = usb_fifo_addr;
+   slave_conf.dst_addr_width = addr_width;
+   slave_conf.dst_maxburst = 16;
+
dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG,
 (unsigned long) &slave_conf);
 
-- 
1.6.3.3


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


thumb compiler flags

2011-08-02 Thread Bernhard Rosenkranzer
Hi,
I just spotted this bit in Android's Makefiles (inherited that way from AOSP):

TARGET_arm_CFLAGS := [...] -fstrict-aliasing [...]
[...]
TARGET_thumb_CFLAGS := [...] -fno-strict-aliasing [...]

This general assumption that arm code can handle strict aliasing, but
thumb code can't, seems odd.

My guess is that they started out using -fno-strict-aliasing
everywhere, then fixed aliasing violations and "fixed" the compiler
flags for arm, and didn't notice they're still turning it off for
thumb -- either that, or they've run into toolchain bugs (that might
be fixed in the Linaro toolchain), or it's a matter of "something
we're building in thumb mode has aliasing violations and we're too
lazy to figure out which part it is".

Unless someone knows of a valid reason for doing things the way they
did, simply taking it out (preferrably replacing it with
-Werror=strict-aliasing, so we're likely to notice any aliasing
violations if it comes down to "too lazy to figure out which part")
should get us some free extra speed. (Not sure just how much we're
actually building in thumb mode - may or may not be relevant.)

ttyl
bero

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


Re: [PATCH v4 1/2] ARMV7: Add support for Samsung ORIGEN board

2011-08-02 Thread Chander Kashyap
Dear Wolfgang Denk,

On 31 July 2011 15:30, Wolfgang Denk  wrote:

> Dear Chander Kashyap,
>
> In message <1311914519-10531-2-git-send-email-chander.kash...@linaro.org>
> you wrote:
> > Origen board is based upon S5PV310 SoC which is similiar to
> > S5PC210 SoC.
> >
> > Signed-off-by: Chander Kashyap 
> ...
> > + /* APLL(1), MPLL(1), CORE(0), HPM(0) */
> > + ldr r1, =0x0101
> > + ldr r2, =0x14200@CLK_SRC_CPU
> ...
> > + mov r1, #0x1
> ...
> > + ldr r1, =0x00
> > + ldr r2, =0x0C210@CLK_SRC_TOP0
> ...
> > + ldr r1, =0x00
> > + ldr r2, =0x0C214@CLK_SRC_TOP1_OFFSET
> ...
> > + ldr r1, =0x1
> > + ldr r2, =0x10200@CLK_SRC_DMC_OFFSET
> ...
>
> ..
> > + /*
> > +  * CLK_DIV_DMC0:
> > +  *
> > +  * CORE_TIMERS_RATIO[28]0x1
> > +  * COPY2_RATIO[24]  0x3
> > +  * DMCP_RATIO[20]   0x1
> > +  * DMCD_RATIO[16]   0x1
> > +  * DMC_RATIO[12]0x1
> > +  * DPHY_RATIO[8]0x1
> > +  * ACP_PCLK_RATIO[4]0x1
> > +  * ACP_RATIO[0] 0x3
> > +  */
> > + ldr r1, =0x1313
> > + ldr r2, =0x010500   @CLK_DIV_DMC0_OFFSET
> > + str r1, [r0, r2]
>
>
> lease get rid of all these magic hard coded constants.  Use symbolic
> names instead. If needed, auto-generate these from the respective C
> structs.  If needed, create the C structs.
>

I will change hard coded values to  symbolic names.

>
> ...
> > --- /dev/null
> > +++ b/board/samsung/origen/mem_setup.S
> > @@ -0,0 +1,359 @@
>
> What exactly is the reeason for not coding this in C ?
>
> ...
> > +#ifdef CONFIG_MIU_1BIT_12_INTERLEAVED
> > + ldr r1, =0x000c
> > + str r1, [r0, #0x400]
> > + ldr r1, =0x0001
> > + str r1, [r0, #0xc00]
> > +#elif defined(CONFIG_MIU_1BIT_7_INTERLEAVED)
> > + ldr r1, =0x0007
> > + str r1, [r0, #0x400]
> > + ldr r1, =0x0001
> > + str r1, [r0, #0xc00]
> > +#elif defined(CONFIG_MIU_2BIT_21_12_INTERLEAVED)
> > + ldr r1, =0x2000150c
> > + str r1, [r0, #0x400]
> > + ldr r1, =0x0001
> > + str r1, [r0, #0xc00]
> > +#elif defined(CONFIG_MIU_2BIT_21_7_INTERLEAVED)
> > + ldr r1, =0x20001507
> > + str r1, [r0, #0x400]
> > + ldr r1, =0x0001
> > + str r1, [r0, #0xc00]
> > +#elif defined(CONFIG_MIU_2BIT_31_INTERLEAVED)
> > + ldr r1, =0x001d
> > + str r1, [r0, #0x400]
> > + ldr r1, =0x0001
> > + str r1, [r0, #0xc00]
>
> See above.  Please get rid of all these hard-ciooded magic numbers.
> [Eventually this happens automativcally when you rewrite this in C.]

I will use symbolic names.

>
> > +int dram_init(void)
> > +{
> > + gd->ram_size= get_ram_size((long *)PHYS_SDRAM_1,
> PHYS_SDRAM_1_SIZE)
> > + + get_ram_size((long *)PHYS_SDRAM_2,
> PHYS_SDRAM_2_SIZE)
> > + + get_ram_size((long *)PHYS_SDRAM_3,
> PHYS_SDRAM_3_SIZE)
> > + + get_ram_size((long *)PHYS_SDRAM_4,
> PHYS_SDRAM_4_SIZE);
> > +
> > + return 0;
> > +}
> > +
> > +void dram_init_banksize(void)
> > +{
> > + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> > + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> > + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> > + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
> > + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> > + gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
> > + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> > + gd->bd->bi_dram[3].size = PHYS_SDRAM_4_SIZE;
> > +}
>
> How do you detect memory issues in one of the memory banks, say, a
> memory error in bank 3?
>
 get_ram_size will take care for it.


> > diff --git a/include/configs/origen.h b/include/configs/origen.h
> > new file mode 100644
> > index 000..3cd9bfe
> > --- /dev/null
> > +++ b/include/configs/origen.h
> ...
> > +#define COPY_BL2_SIZE0x8
> > +#define BL2_START_OFFSET ((CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)/512)
> > +#define BL2_SIZE_BLOC_COUNT  (COPY_BL2_SIZE/512)
>
> Some of the defines in this file are not used anywhere in the code
> (for example, COPY_BL2_SIZE, COPY_BL2_SIZEBL2_START_OFFSET or
> BL2_SIZE_BLOC_COUNT.  Please remove unused defines from this patch.
>
> These are used in spl code. I will move them to spl patch.


> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Don't hit a man when he's down - kick him; it's easier.
>



-- 
with warm regards,
Chander Kashyap
___
linaro-dev mailing list
linaro-dev@li

Re: [PATCH v4 2/2] ORIGEN: Add MMC SPL support

2011-08-02 Thread Chander Kashyap
Dear Wolfgang Denk,

On 31 July 2011 15:33, Wolfgang Denk  wrote:

> Dear Chander Kashyap,
>
> In message <1311914519-10531-3-git-send-email-chander.kash...@linaro.org>
> you wrote:
> > Adds mmc boot support.
> >
> > Signed-off-by: Chander Kashyap 
> > ---
> >  mmc_spl/board/samsung/origen/Makefile |  106
> 
> >  mmc_spl/board/samsung/origen/mmc_boot.c   |   57 +
> >  mmc_spl/board/samsung/origen/tools/mkv310_image.c |  140
> +
> >  mmc_spl/board/samsung/origen/u-boot.lds   |   88 +
> >  4 files changed, 391 insertions(+), 0 deletions(-)
> >  create mode 100644 mmc_spl/board/samsung/origen/Makefile
> >  create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c
> >  create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c
> >  create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds
>
> PLease adapt this code to the new SPL infrastructure that has recently
> been introduced.
>
Yes i will use the new SPL Infrastructure.

>
>
> > +typedef u32(*copy_sd_mmc_to_mem) \
> > + (u32 start_block, u32 block_count, u32 *dest_addr);
>
> Quote CodingStyle:
>
>Lots of people think that typedefs "help readability". Not so.
>
> > +void copy_uboot_to_ram(void)
> > +{
> > + copy_sd_mmc_to_mem copy_bl2 = (copy_sd_mmc_to_mem)*(u32
> *)(0x02020030);
> > + copy_bl2(BL2_START_OFFSET,\
> > + BL2_SIZE_BLOC_COUNT, (u32 *)CONFIG_SYS_TEXT_BASE);
> > +}
>
> This code is, in addition to the magic 0x02020030 constant, basicly
> unreadable.
>
> The typedef is especially useless as it is used only in this single
> case.  Please clean this up.
>
> > diff --git a/mmc_spl/board/samsung/origen/u-boot.lds
> b/mmc_spl/board/samsung/origen/u-boot.lds
> > new file mode 100644
> > index 000..4a231d9
> > --- /dev/null
> > +++ b/mmc_spl/board/samsung/origen/u-boot.lds
>
> What exactly is the reason for needing your own, custom linker script?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Defaults are wonderful, just like fire.
>  - Larry Wall in <1996mar6.004121.27...@netlabs.com>
>



-- 
with warm regards,
Chander Kashyap
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH v4 1/2] ARMV7: Add support for Samsung ORIGEN board

2011-08-02 Thread Wolfgang Denk
Dear Chander Kashyap,

In message  
you wrote:
> 
> > > +void dram_init_banksize(void)
> > > +{
> > > + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> > > + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> > > + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> > > + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
> > > + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> > > + gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
> > > + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> > > + gd->bd->bi_dram[3].size = PHYS_SDRAM_4_SIZE;
> > > +}
> >
> > How do you detect memory issues in one of the memory banks, say, a
> > memory error in bank 3?
> >
>  get_ram_size will take care for it.

How so?  You are setting these to fixed, predefined values.

If get_ram_size() for bank 3 returns a size of 0, you will still set
the size to PHYS_SDRAM_3_SIZE here.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
1000 pains  = 1 Megahertz

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