Re: [PATCH 2/4] cpuidle: define the enter function in the driver structure

2012-07-10 Thread Rajendra Nayak 

Hi Daniel,

On Friday 06 July 2012 04:28 PM, Daniel Lezcano wrote:

The main purpose of all these cleanup patches are to move out all
non-data information from the cpuidle_state structure in order to add a
new api which could be 'cpuidle_register_cpu_latency(int cpu, struct
cpuidle_latencies latencies)'.


So are there any technical difficulties in adding such an api with the
non-data information being part of cpuidle_state? Or its just that you
think the already duplicated non-data information (per state) is going
to be duplicated much more (per state per cpu) in most cases.

regards,
Rajendra


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

Re: [PATCH 2/4] cpuidle: define the enter function in the driver structure

2012-07-10 Thread Daniel Lezcano 
On 07/10/2012 10:29 AM, Rajendra Nayak wrote:
> Hi Daniel,
> 
> On Friday 06 July 2012 04:28 PM, Daniel Lezcano wrote:
>> The main purpose of all these cleanup patches are to move out all
>> non-data information from the cpuidle_state structure in order to add a
>> new api which could be 'cpuidle_register_cpu_latency(int cpu, struct
>> cpuidle_latencies latencies)'.
> 
> So are there any technical difficulties in adding such an api with the
> non-data information being part of cpuidle_state? Or its just that you
> think the already duplicated non-data information (per state) is going
> to be duplicated much more (per state per cpu) in most cases.

Yes, it is possible. I am already working on an alternate patchset I
will post soon, but I don't like to add more things in a subsystem
before cleaning up the code when it makes sense.

When I looked at the cpuidle code, I noticed this 'enter' field was used
for the same function. With per cpu latency and using the cpuidle_state
structure, that means duplication of this field. For an x86_64
architecture with 16 cores and 4 C-states, that is 512 bytes of memory
instead of 8 bytes.

That is the same for example the 'disable' field which could be stored
in the 'flags' field as a bit instead of the moving it to the 'stats'
structure with "unsigned long long".

As the architectures tend to add more cores [1][2], that means more
memory consumption. In a very near future, we will have 100 cores in a
cpu. Assuming we have 4 C-states, that is 100 * 4 * 8 = 3200 bytes of
memory used for a single function. IMHO, the kernel shouldn't assume the
user must add more memory on the system.

Anyway, I will post a patchset to use the cpuidle_state per cpu.

Thanks
  -- Daniel

[1] http://www.engadget.com/2007/02/11/intel-demonstrates-80-core-processor/
[2] http://www.tilera.com/products/processors/TILE-Gx_Family

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

Follow Linaro:   Facebook |
 Twitter |
 Blog


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

Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE

2012-07-10 Thread Vincent Guittot 
On 10 July 2012 13:27, Peter Zijlstra  wrote:
> On Mon, 2012-07-09 at 11:27 +0200, Vincent Guittot wrote:
>> This patchset creates an arch_scale_freq_power function for ARM, which is 
>> used
>> to set the relative capacity of each core of a big.LITTLE system. It also 
>> removes
>> the broken power estimation of x86.
>>
>> Modification since v3:
>>  - Add comments
>>  - Add optimization for SMP system
>>  - Ensure that capacity of a CPU will be at most 1
>>
>> Modification since v2:
>>  - set_power_scale function becomes static
>>  - Rework loop in update_siblings_masks
>>  - Remove useless code in parse_dt_topology
>>
>> Modification since v1:
>>  - Add and update explanation about the use of the table and the range of 
>> the value
>>  - Remove the use of NR_CPUS and use nr_cpu_ids instead
>>  - Remove broken power estimation of x86
>>
>> Peter Zijlstra (1):
>>   sched, x86: Remove broken power estimation
>
> Note that this patch already made its way into tip as commit
> bcae21d6e793a7047d38abc9ac0946c53733c1dd so it might be best to base
> whatever tree this is supposed to fo into on something that includes
> that.
>

yes

>> Vincent Guittot (4):
>>   ARM: topology: Add arch_scale_freq_power function
>>   ARM: topology: factorize the update of sibling masks
>>   ARM: topology: Update cpu_power according to DT information
>>   sched: cpu_power: enable ARCH_POWER
>
> How would you like to proceed with these patches, I'm fine with them
> going through the ARM tree..

May be the last one which enable ARCH_POWER should also go into tip ?

>
> In which case:
>
> Acked-by: Peter Zijlstra 
>
> Ingo, Russell, any other preferences?

I'm going to push the patches related to ARM into Russell's patch system

Vincent

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

Re: [PATCH 2/4] cpuidle: define the enter function in the driver structure

2012-07-10 Thread Rajendra Nayak 

As the architectures tend to add more cores [1][2], that means more
memory consumption. In a very near future, we will have 100 cores in a
cpu. Assuming we have 4 C-states, that is 100 * 4 * 8 = 3200 bytes of
memory used for a single function. IMHO, the kernel shouldn't assume the
user must add more memory on the system.


I completely agree.


Anyway, I will post a patchset to use the cpuidle_state per cpu.


Maybe what you were doing wasn't clearly evident with the existing
cpuidle core, but once its scaled to add a per cpu state, it might
look more meaningful. So if you post your patches to add cpuidle
state per cpu, it should certainly give more insight into why this
cleanup makes sense.



Thanks
   -- Daniel

[1] http://www.engadget.com/2007/02/11/intel-demonstrates-80-core-processor/
[2] http://www.tilera.com/products/processors/TILE-Gx_Family




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

Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE

2012-07-10 Thread Peter Zijlstra 
On Mon, 2012-07-09 at 11:27 +0200, Vincent Guittot wrote:
> This patchset creates an arch_scale_freq_power function for ARM, which is 
> used 
> to set the relative capacity of each core of a big.LITTLE system. It also 
> removes
> the broken power estimation of x86.
> 
> Modification since v3:
>  - Add comments
>  - Add optimization for SMP system
>  - Ensure that capacity of a CPU will be at most 1
> 
> Modification since v2:
>  - set_power_scale function becomes static
>  - Rework loop in update_siblings_masks
>  - Remove useless code in parse_dt_topology
> 
> Modification since v1:
>  - Add and update explanation about the use of the table and the range of the 
> value 
>  - Remove the use of NR_CPUS and use nr_cpu_ids instead
>  - Remove broken power estimation of x86
> 
> Peter Zijlstra (1):
>   sched, x86: Remove broken power estimation

Note that this patch already made its way into tip as commit
bcae21d6e793a7047d38abc9ac0946c53733c1dd so it might be best to base
whatever tree this is supposed to fo into on something that includes
that.

> Vincent Guittot (4):
>   ARM: topology: Add arch_scale_freq_power function
>   ARM: topology: factorize the update of sibling masks
>   ARM: topology: Update cpu_power according to DT information
>   sched: cpu_power: enable ARCH_POWER

How would you like to proceed with these patches, I'm fine with them
going through the ARM tree..

In which case:

Acked-by: Peter Zijlstra 

Ingo, Russell, any other preferences?

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

[PATCH] mfd: Implement devicetree support for AB8500 Btemp

2012-07-10 Thread Rajanikanth H . V 
From: "Rajanikanth H.V" 

This patch adds device tree support for
battery temperature monitor driver

Signed-off-by: Rajanikanth H.V 
---
 .../bindings/power_supply/ab8500/btemp.txt |   54 ++
 arch/arm/boot/dts/db8500.dtsi  |   17 +
 arch/arm/mach-ux500/Makefile   |4 +-
 arch/arm/mach-ux500/board-mop500-bm.c  |  532 
 arch/arm/mach-ux500/include/mach/board-mop500-bm.h |   24 +
 drivers/mfd/ab8500-core.c  |1 +
 drivers/power/Kconfig  |8 +-
 drivers/power/ab8500_btemp.c   |   79 ++-
 include/linux/mfd/ab8500/pwmleds.h |   20 +
 9 files changed, 722 insertions(+), 17 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
 create mode 100644 arch/arm/mach-ux500/board-mop500-bm.c
 create mode 100644 arch/arm/mach-ux500/include/mach/board-mop500-bm.h
 create mode 100644 include/linux/mfd/ab8500/pwmleds.h

diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt 
b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
new file mode 100644
index 000..8543ed1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
@@ -0,0 +1,54 @@
+AB8500 Battery Termperature Monitor Driver
+
+AB8500 is a mixed signal multimedia and power management
+device comprising: power and energy management module,
+WalliCharger and USB charger interface, audio, general
+purpose ADC TVOut, clock management and SIM card Interface.
+
+Battery temperature monitoring support is part of 'energy
+management module', the other components of this module
+are: 'main and USB Combo charger' and fuel guage.
+
+The properties below describes the node for battery
+temperature monitor driver.
+
+Required Properties:
+- compatible = "stericsson,ab8500-btemp"
+
+interrupts:
+   Four battery temperature ranges are be defined
+   which results in interrupt events as:
+   - Btemp
+   - BtempLow
+   - BtempMedium
+   - BtempHigh
+
+
+Supplied-to:
+   This shall be power supply class dependency where in the runtime battery
+   properties will be shared across fuel guage and charging algorithm 
driver.
+
+Thermister-interface:
+   'btemp' and 'batctrl' are the pins interfaced for battery temperature
+   measurement, btemp is used when NTC(Negative Termperature coefficient)
+   resister is interfaced external to battery and batctrl is used when
+   NTC resister is internal to battery.
+
+example:
+ab8500-btemp {
+   compatible = "stericsson,ab8500-btemp";
+
+   interrupt-names =
+   "BAT_CTRL_INDB",/* battery removal indicator */
+   "BTEMP_LOW",/* Btemp < BtempLow, if battery 
temperature is lower than -10°C */
+   "BTEMP_HIGH",   /* BtempLow < Btemp < BtempMedium,
+   if battery 
temperature is between -10 and 0°C */
+   "BTEMP_LOW_MEDIUM", /* BtempMedium < Btemp < BtempHigh,
+   if battery 
temperature is between 0°C and “MaxTemp”.*/
+   "BTEMP_MEDIUM_HIGH";/* Btemp > BtempHigh,
+   if battery 
temperature is higher than “MaxTemp”. */
+
+   supplied-to = "ab8500_chargalg", "ab8500_fg";
+
+   thermister-internal-to-battery = <1>;
+};
diff --git a/arch/arm/boot/dts/db8500.dtsi b/arch/arm/boot/dts/db8500.dtsi
index 7279165..527fdc3 100644
--- a/arch/arm/boot/dts/db8500.dtsi
+++ b/arch/arm/boot/dts/db8500.dtsi
@@ -330,6 +330,23 @@
vddadc-supply = <&ab8500_ldo_tvout_reg>;
};
 
+   ab8500-btemp {
+   compatible = "stericsson,ab8500-btemp";
+   interrupts = <20 0x04
+   80 0x04
+   81 0x04
+   82 0x04
+   83 0x04>;
+   interrupt-names = "BAT_CTRL_INDB",
+   
"BTEMP_LOW",
+   
"BTEMP_HIGH",
+   
"BTEMP_LOW_MEDIUM",
+   
"BTEMP_MEDIUM_HIGH";
+   supplied_to = "ab8500_chargalg", 
"ab8500_fg";
+   num_supplicants = <2>;
+   battery_term_on_batctrl =

Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE

2012-07-10 Thread Peter Zijlstra 
On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
> 
> May be the last one which enable ARCH_POWER should also go into tip ?
> 
OK, I can take it.

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

Re: [PATCH] mfd: Implement devicetree support for AB8500 Btemp

2012-07-10 Thread Arnd Bergmann 
On Tuesday 10 July 2012, Rajanikanth H.V wrote:

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
> @@ -0,0 +1,54 @@
> +AB8500 Battery Termperature Monitor Driver
> +
> +AB8500 is a mixed signal multimedia and power management
> +device comprising: power and energy management module,
> +WalliCharger and USB charger interface, audio, general
> +purpose ADC TVOut, clock management and SIM card Interface.
> +
> +Battery temperature monitoring support is part of 'energy
> +management module', the other components of this module
> +are: 'main and USB Combo charger' and fuel guage.
> +
> +The properties below describes the node for battery
> +temperature monitor driver.
> +
> +Required Properties:
> +- compatible = "stericsson,ab8500-btemp"
> +
> +interrupts:
> + Four battery temperature ranges are be defined
> + which results in interrupt events as:
> + - Btemp
> + - BtempLow
> + - BtempMedium
> + - BtempHigh
> +

These names do not match the five interrupts in the example or in the
code. When you provide an "interrupt-names" property you have to define
the exact strings that are permissible for them in the binding.

> +Supplied-to:
> + This shall be power supply class dependency where in the runtime battery
> + properties will be shared across fuel guage and charging algorithm 
> driver.

I probably don't understand enough of this, but shouldn't the other devices
that are supplied by this have a reference to this node rather than doing
it this way around? Why use strings here instead of phandles?

You are also not listing some of the properties that are in the device
tree here, like the "interrupts" property itself.

> diff --git a/arch/arm/mach-ux500/board-mop500-bm.c 
> b/arch/arm/mach-ux500/board-mop500-bm.c
> new file mode 100644
> index 000..3349ceb
> --- /dev/null
> +++ b/arch/arm/mach-ux500/board-mop500-bm.c

Didn't we conclude that this file has no board-specific information in it?
Either explain why it's still here, or move it into the driver itself.

> +/*
> + * Note that the batres_vs_temp table must be strictly sorted by falling
> + * temperature values to work.
> + */
> +#ifdef CONFIG_AB8500_9100_LI_ION_BATTERY
> +#define BATRES   180
> +#else
> +#define BATRES   300
> +#endif

I think I mentioned before that you need to get rid of the
CONFIG_AB8500_9100_LI_ION_BATTERY symbol. If you have exclusive
compile-time options, it is impossible to build a kernel that
runs on all system, so this has to be a run-time option.

Arnd

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

Re: What is the purpose of the kernel_build subdirectory in the Linaro kernel source?

2012-07-10 Thread David Cullen 
Hello, John,

On 7/9/2012 9:20 PM, John Rigby wrote:
> This is probably a bug in the new kernel packaging scripts.  I will
> check into it.


Can I just remove the "kernel_build" subdirectory for now?  Or
should I build the kernel out of the "kernel_build" subdirectory?


> On Mon, Jul 9, 2012 at 2:30 PM, David Cullen
>  wrote:
>> Hello, linaro-dev,
>>
>> I just created a TAGS file for the Linaro kernel source and I
>> noticed that there is a "kernel_build" subdirectory:
>>
>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/kernel_build
>>
>> What is the purpose of this directory?
>>
>> When I run "make ARCH=arm TAGS", it includes the source in this
>> directory, so it appears that all files are tagged twice.


-- 
Thank you,
David Cullen
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: What is the purpose of the kernel_build subdirectory in the Linaro kernel source?

2012-07-10 Thread John Rigby 
just remove it

On Tue, Jul 10, 2012 at 8:15 AM, David Cullen
 wrote:
> Hello, John,
>
> On 7/9/2012 9:20 PM, John Rigby wrote:
>> This is probably a bug in the new kernel packaging scripts.  I will
>> check into it.
>
>
> Can I just remove the "kernel_build" subdirectory for now?  Or
> should I build the kernel out of the "kernel_build" subdirectory?
>
>
>> On Mon, Jul 9, 2012 at 2:30 PM, David Cullen
>>  wrote:
>>> Hello, linaro-dev,
>>>
>>> I just created a TAGS file for the Linaro kernel source and I
>>> noticed that there is a "kernel_build" subdirectory:
>>>
>>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/kernel_build
>>>
>>> What is the purpose of this directory?
>>>
>>> When I run "make ARCH=arm TAGS", it includes the source in this
>>> directory, so it appears that all files are tagged twice.
>
>
> --
> Thank you,
> David Cullen

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

Config check fails for linux-linaro-lt-omap-3.4-3.4.0

2012-07-10 Thread David Cullen 
Hello, linaro-dev,

I am using the instructions in the "adjust kernel config" section at
this link:

> https://wiki.linaro.org/KenWerner/Sandbox/CreateCustomKernelDeb

When I run

# fakeroot debian/rules editconfigs

I get the the following errors:

> Running config-check for all configurations ...
> 
> check-config: 
> /tmp/tmp.Sv8FblIPLa/CONFIGS/armel-config.flavour.linaro-lt-omap: loading 
> config
> check-config: 
> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
> loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
> check-config: 
> /tmp/tmp.Sv8FblIPLa/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading 
> config
> check-config: 
> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
> loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
> 
> *** ERROR: 2 config-check failures detected

I am using config-3.4.0-1-linaro-lt-omap as my initial .config.  A
search for INIT_PASS_ALL_PARAMS in the Kconfig files produces no
results:

find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'

When I extract the source to a temporary directory and search the
"kernel_build" subdirectory (that John Rigby told me to delete), I
find it in

./init/Kconfig:config INIT_PASS_ALL_PARAMS

So, now I am really confused.  Is the real source in the
"kernel_build" subdirectory?

-- 
Thank you,
David Cullen

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

Re: [PATCH] mfd: Implement devicetree support for AB8500 Btemp

2012-07-10 Thread Lee Jones 
Some of my comments are picky, but if it's going into Mainline, it 
should at least look professional.


You didn't CC the ST-Ericsson internal mailing list.

Address is stericsson_nomadik_li...@list.st.com

I'll do it for now, but please do so on your next submission.

On 10/07/12 15:23, Rajanikanth H.V wrote:

From: "Rajanikanth H.V" 

 This patch adds device tree support for
 battery temperature monitor driver

Signed-off-by: Rajanikanth H.V 
---
  .../bindings/power_supply/ab8500/btemp.txt |   54 ++
  arch/arm/boot/dts/db8500.dtsi  |   17 +
  arch/arm/mach-ux500/Makefile   |4 +-
  arch/arm/mach-ux500/board-mop500-bm.c  |  532 
  arch/arm/mach-ux500/include/mach/board-mop500-bm.h |   24 +
  drivers/mfd/ab8500-core.c  |1 +
  drivers/power/Kconfig  |8 +-
  drivers/power/ab8500_btemp.c   |   79 ++-
  include/linux/mfd/ab8500/pwmleds.h |   20 +
  9 files changed, 722 insertions(+), 17 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
  create mode 100644 arch/arm/mach-ux500/board-mop500-bm.c
  create mode 100644 arch/arm/mach-ux500/include/mach/board-mop500-bm.h
  create mode 100644 include/linux/mfd/ab8500/pwmleds.h

diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt 
b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
new file mode 100644
index 000..8543ed1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
@@ -0,0 +1,54 @@
+AB8500 Battery Termperature Monitor Driver


Spelling.


+
+AB8500 is a mixed signal multimedia and power management
+device comprising: power and energy management module,
+WalliCharger and USB charger interface, audio, general
+purpose ADC TVOut, clock management and SIM card Interface.


Mixture of capitalised and otherwise device names.


+
+Battery temperature monitoring support is part of 'energy
+management module', the other components of this module
+are: 'main and USB Combo charger' and fuel guage.


Spelling. Mixed use of ''.


+The properties below describes the node for battery
+temperature monitor driver.
+
+Required Properties:
+- compatible = "stericsson,ab8500-btemp"
+
+interrupts:
+   Four battery temperature ranges are be defined
+   which results in interrupt events as:
+   - Btemp
+   - BtempLow
+   - BtempMedium
+   - BtempHigh
+
+
+Supplied-to:
+   This shall be power supply class dependency where in the runtime battery
+   properties will be shared across fuel guage and charging algorithm 
driver.


Spelling.


+
+Thermister-interface:
+   'btemp' and 'batctrl' are the pins interfaced for battery temperature
+   measurement, btemp is used when NTC(Negative Termperature coefficient)


Spelling.


+   resister is interfaced external to battery and batctrl is used when
+   NTC resister is internal to battery.
+
+example:
+ab8500-btemp {
+   compatible = "stericsson,ab8500-btemp";
+
+   interrupt-names =
+   "BAT_CTRL_INDB",  /* battery removal indicator */
+   "BTEMP_LOW",  /* Btemp < BtempLow, if battery 
temperature is lower than -10°C */
+   "BTEMP_HIGH", /* BtempLow < Btemp < BtempMedium,
+   if battery 
temperature is between -10 and 0°C */
+   "BTEMP_LOW_MEDIUM", /* BtempMedium < Btemp < BtempHigh,
+   if battery 
temperature is between 0°C and “MaxTemp”.*/
+   "BTEMP_MEDIUM_HIGH";/* Btemp > BtempHigh,
+   if battery 
temperature is higher than “MaxTemp”. */
+
+   supplied-to = "ab8500_chargalg", "ab8500_fg";
+
+   thermister-internal-to-battery = <1>;
+};
diff --git a/arch/arm/boot/dts/db8500.dtsi b/arch/arm/boot/dts/db8500.dtsi
index 7279165..527fdc3 100644
--- a/arch/arm/boot/dts/db8500.dtsi
+++ b/arch/arm/boot/dts/db8500.dtsi
@@ -330,6 +330,23 @@
vddadc-supply = <&ab8500_ldo_tvout_reg>;
};

+   ab8500-btemp {
+   compatible = "stericsson,ab8500-btemp";
+   interrupts = <20 0x04
+   80 0x04
+   81 0x04
+   82 0x04
+   83 0x04>;


Odd tabbing.


+   interrupt-names = "BAT_CTRL_INDB",
+   
"BTEMP_LOW",
+

Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0

2012-07-10 Thread John Rigby 
David,

I thnk we need to start at the beginning.  Where did you get the
source you are working with.  In your original post I assumed that
this was source extracted with dpkg-source from a linaro kernel source
pkg.

--john

On Tue, Jul 10, 2012 at 10:19 AM, David Cullen
 wrote:
> Hello, linaro-dev,
>
> I am using the instructions in the "adjust kernel config" section at
> this link:
>
>> https://wiki.linaro.org/KenWerner/Sandbox/CreateCustomKernelDeb
>
> When I run
>
> # fakeroot debian/rules editconfigs
>
> I get the the following errors:
>
>> Running config-check for all configurations ...
>>
>> check-config: 
>> /tmp/tmp.Sv8FblIPLa/CONFIGS/armel-config.flavour.linaro-lt-omap: loading 
>> config
>> check-config: 
>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
>> loading checks
>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>> check-config: 43/44 checks passed -- exit 1
>> check-config: 
>> /tmp/tmp.Sv8FblIPLa/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading 
>> config
>> check-config: 
>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
>> loading checks
>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>> check-config: 43/44 checks passed -- exit 1
>>
>> *** ERROR: 2 config-check failures detected
>
> I am using config-3.4.0-1-linaro-lt-omap as my initial .config.  A
> search for INIT_PASS_ALL_PARAMS in the Kconfig files produces no
> results:
>
> find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
>
> When I extract the source to a temporary directory and search the
> "kernel_build" subdirectory (that John Rigby told me to delete), I
> find it in
>
> ./init/Kconfig:config INIT_PASS_ALL_PARAMS
>
> So, now I am really confused.  Is the real source in the
> "kernel_build" subdirectory?
>
> --
> Thank you,
> David Cullen

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

Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0

2012-07-10 Thread David Cullen 
Hello, John,

On 7/10/2012 12:52 PM, John Rigby wrote:
> I thnk we need to start at the beginning.  Where did you get the
> source you are working with.  In your original post I assumed that
> this was source extracted with dpkg-source from a linaro kernel source
> pkg.


I used

apt-get source linux-image-3.4.0-1-linaro-lt-omap

Then I extracted the tarball.  The tarball comes from the Linaro
repository:


> Get:1 http://ppa.launchpad.net/linaro-maintainers/kernel/ubuntu/ precise/main 
> linux-linaro-lt-omap-3.4 3.4.0-1.1~120627131801 (tar) [204 MB]


So Linaro appears to have a defect in the kernel source package in
their repository.  This goes along with a defect I found in the
linux-headers package for the same kernel.


> On Tue, Jul 10, 2012 at 10:19 AM, David Cullen
>  wrote:
>> Hello, linaro-dev,
>>
>> I am using the instructions in the "adjust kernel config" section at
>> this link:
>>
>>> https://wiki.linaro.org/KenWerner/Sandbox/CreateCustomKernelDeb
>>
>> When I run
>>
>> # fakeroot debian/rules editconfigs
>>
>> I get the the following errors:
>>
>>> Running config-check for all configurations ...
>>>
>>> check-config: 
>>> /tmp/tmp.Sv8FblIPLa/CONFIGS/armel-config.flavour.linaro-lt-omap: loading 
>>> config
>>> check-config: 
>>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
>>> loading checks
>>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>>> check-config: 43/44 checks passed -- exit 1
>>> check-config: 
>>> /tmp/tmp.Sv8FblIPLa/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading 
>>> config
>>> check-config: 
>>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
>>> loading checks
>>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>>> check-config: 43/44 checks passed -- exit 1
>>>
>>> *** ERROR: 2 config-check failures detected
>>
>> I am using config-3.4.0-1-linaro-lt-omap as my initial .config.  A
>> search for INIT_PASS_ALL_PARAMS in the Kconfig files produces no
>> results:
>>
>> find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
>>
>> When I extract the source to a temporary directory and search the
>> "kernel_build" subdirectory (that John Rigby told me to delete), I
>> find it in
>>
>> ./init/Kconfig:config INIT_PASS_ALL_PARAMS
>>
>> So, now I am really confused.  Is the real source in the
>> "kernel_build" subdirectory?
>>
>> --
>> Thank you,
>> David Cullen


-- 
Thank you,
David Cullen


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

Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0

2012-07-10 Thread John Rigby 
There will shortly be a new kernel
linux-linaro-lt-omap-3.4_3.4.0-1.1~120710203036 in the kernel ppa:
https://code.launchpad.net/~linaro-maintainers/+archive/kernel
with the kernel_build issue fixed.

Now we can get back to the original issue.

--john

On Tue, Jul 10, 2012 at 11:47 AM, David Cullen
 wrote:
> Hello, John,
>
> On 7/10/2012 12:52 PM, John Rigby wrote:
>> I thnk we need to start at the beginning.  Where did you get the
>> source you are working with.  In your original post I assumed that
>> this was source extracted with dpkg-source from a linaro kernel source
>> pkg.
>
>
> I used
>
> apt-get source linux-image-3.4.0-1-linaro-lt-omap
>
> Then I extracted the tarball.  The tarball comes from the Linaro
> repository:
>
>
>> Get:1 http://ppa.launchpad.net/linaro-maintainers/kernel/ubuntu/ 
>> precise/main linux-linaro-lt-omap-3.4 3.4.0-1.1~120627131801 (tar) [204 MB]
>
>
> So Linaro appears to have a defect in the kernel source package in
> their repository.  This goes along with a defect I found in the
> linux-headers package for the same kernel.
>
>
>> On Tue, Jul 10, 2012 at 10:19 AM, David Cullen
>>  wrote:
>>> Hello, linaro-dev,
>>>
>>> I am using the instructions in the "adjust kernel config" section at
>>> this link:
>>>
 https://wiki.linaro.org/KenWerner/Sandbox/CreateCustomKernelDeb
>>>
>>> When I run
>>>
>>> # fakeroot debian/rules editconfigs
>>>
>>> I get the the following errors:
>>>
 Running config-check for all configurations ...

 check-config: 
 /tmp/tmp.Sv8FblIPLa/CONFIGS/armel-config.flavour.linaro-lt-omap: loading 
 config
 check-config: 
 /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
 loading checks
 check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
 check-config: 43/44 checks passed -- exit 1
 check-config: 
 /tmp/tmp.Sv8FblIPLa/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading 
 config
 check-config: 
 /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: 
 loading checks
 check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
 check-config: 43/44 checks passed -- exit 1

 *** ERROR: 2 config-check failures detected
>>>
>>> I am using config-3.4.0-1-linaro-lt-omap as my initial .config.  A
>>> search for INIT_PASS_ALL_PARAMS in the Kconfig files produces no
>>> results:
>>>
>>> find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
>>>
>>> When I extract the source to a temporary directory and search the
>>> "kernel_build" subdirectory (that John Rigby told me to delete), I
>>> find it in
>>>
>>> ./init/Kconfig:config INIT_PASS_ALL_PARAMS
>>>
>>> So, now I am really confused.  Is the real source in the
>>> "kernel_build" subdirectory?
>>>
>>> --
>>> Thank you,
>>> David Cullen
>
>
> --
> Thank you,
> David Cullen
>

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

Agenda for the 2012/7/11 Linaro Android Platform Team Meeting Posted

2012-07-10 Thread Zach Pfeffer 
Take a look:

https://wiki.linaro.org/Platform/Android/Meetings/2012-07-11

See everyone tomorrow morning on irc.freenode.net in #linaro-meeting
at 8 AM Texas time, 14:00 UTC.

-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Power Meter

2012-07-10 Thread Zach Pfeffer 
Check out our new NI power meter:

http://www.youtube.com/watch?v=JYRogshDyVo&feature=plcp

We're gonna hook this thing up to LAVA. Its a pretty nice piece of equipment.

Specs:
NI PXIe-1073 with a NI PXIE-4154 Battery Simulator.

-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Fwd: No space left on device at linaro-android-media-create

2012-07-10 Thread Chunsang Jeong 
I've resolved the problem below by partitioning sdcard manually, i.e.
increased system partition and used --no-part option with
linaro-android-media-create, but I believe linaro-android-media-create
seems to change default system partition size as the Linaro android image
comes bigger.

-- Forwarded message --
From: Chunsang Jeong 
Date: Wed, Jul 4, 2012 at 8:17 PM
Subject: No space left on device at linaro-android-media-create
To: Linaro Dev 


Hello all,

I've found that linaro android images are getting bigger and I got error
messages when I tried to put images to sdcard. i.e. "No space left on
device" by using linaro-android-media-create. I've been using 4GB sdcard
onto Origen and linaro-android-media-create by "apt-get install
linaro-image-tools" (Ubuntu 11.10).

Is there any configurable re-partitioning option for sdcard on
linaro-android-media-create, or do I need bigger one?

Cheers.

-- 
Chunsang Jeong
(Paul Jeong)
*
"Whether you believe you can, or you can't, you are right" - Henry Ford*
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Ubuntu config fragment

2012-07-10 Thread Ricardo Salveti 
On Wed, Jul 4, 2012 at 7:01 AM, Jon Medhurst (Tixy)  wrote:
> Adding in Linaro Dev list for more visibility...
>
> On Tue, 2012-07-03 at 14:08 -0300, Ricardo Salveti wrote:
>> On Tue, Jul 3, 2012 at 10:22 AM, Jon Medhurst (Tixy)  wrote:
>> > Hi Ricardo
>> >
>> > I notice the new ubuntu.conf seems to contain everything including the
>> > kitchen sink. It has things which (as people found out at release time)
>> > breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it
>> > contains drivers and other support for loads of hardware which isn't
>> > present on any Linaro supported device; and if it was, should go in the
>> > board specific config fragments, not the Ubuntu one.
>>
>> This config is basically provided by the official ubuntu kernel
>> packages. We just removed a few specific devices, and some which would
>> not make much sense, but other then that it's basically the same one
>> you can find at your desktop.
>>
>> It's useful to enable all these additional configs for a bunch of
>> reasons, like sharing with Ubuntu, enabling additional usb-based
>> devices and such. We have tons of bugs requesting us to add stuff to
>> the kernel config, and having this config fragment solves them all.
>>
>> If there's any hardware specific thing that could be disabled, we
>> could just move to the board config. Regarding CONFIG_REGULATORS, I
>> just decided to disable it at the vexpress.conf, as it only breaks
>> stuff at vexpress (and makes sense to track it there).
>
> Well, the other boards which need regulators already enable it, so
> there's not really any need for Ubuntu to have this config. This
> particular issue isn't worth worrying about - we'll be adding regulators
> to vexpress to enable the single kernel image initiative - but it does
> seem to show up a general issue of the blurring of the purpose of config
> fragments; if Ubuntu enables a bunch of hardware support, what is the
> roll of the board config fragments?

As we're currently using, the board config fragments would be the
basic input for any hardware specific config set for that flavour. I
agree here that we'd need to move the most we can from the ubuntu.conf
to the boards config, so we could try to remove any hw specific config
from there.

This is currently done at this way as it was basically a copy from the
current Ubuntu packages + a few removals. Unfortunately the list of
configs are just huge to look at each and then update all the
fragments later, as it'd require at least a kernel build for all
flavours. Hopefully this will improve once we start building it daily,
and cleaning it up even more.

> I noticed that the Ubuntu config was patched to remove ATH6KL with the
> commit title "should be platform dependent". What was the reasoning for
> singling that driver out?

That's a bug at the driver, which breaks the kernel build in case
you're selecting something that you don't have available at your
system. I don't remember the details, but we were forced to remove the
module for now and just enable it at origen.

>> > I think that for vexpress at least, you have used ubuntu-minimal.conf
>> > for the 12.06 release and the current CI jobs. What is the plan going
>> > forward? To me, it would seem to make more sense to start with the
>> > minimal config and add things as they are found to be missing.
>>
>> We tried in the past, but that's just too painful. This time we
>> decided to give the Ubuntu config a try, and then just disable what we
>> know will not be used.
>>
>> If possible, we'd like to continue using it, and change as needed to
>> disable whatever you think it shouldn't be there.
>
> OK, lets see how it goes.
>
> I would like to keep the ubuntu-minimal.conf around and supported, if
> for no other that selfish reasons as it produces a much smaller (quicker
> to load) kernel and quicker builds, which is useful for anyone wanting
> to basic kernel development and testing. (In an ideal world it could be
> used on nano and developer images but that isn't worth the complexity of
> a second kernel package and hwpack.)

Yup, this config will still be maintained as well, basically for the
same reasons you described :-)

Let's see how it goes, but the goal is to clean the ubuntu.conf a bit,
and update ubuntu-minimal.conf in case we're missing something there.

Cheers,
-- 
Ricardo Salveti de Araujo

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

Re: Ubuntu config fragment

2012-07-10 Thread Ricardo Salveti 
On Wed, Jul 4, 2012 at 11:45 AM, Christian Robottom Reis
 wrote:
> On Wed, Jul 04, 2012 at 11:01:20AM +0100, Jon Medhurst (Tixy) wrote:
>> > > I notice the new ubuntu.conf seems to contain everything including the
>> > > kitchen sink. It has things which (as people found out at release time)
>> > > breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it
>> > > contains drivers and other support for loads of hardware which isn't
>> > > present on any Linaro supported device; and if it was, should go in the
>> > > board specific config fragments, not the Ubuntu one.
>> >
>> > This config is basically provided by the official ubuntu kernel
>> > packages. We just removed a few specific devices, and some which would
>> > not make much sense, but other then that it's basically the same one
>> > you can find at your desktop.
>> >
>> > It's useful to enable all these additional configs for a bunch of
>> > reasons, like sharing with Ubuntu, enabling additional usb-based
>> > devices and such. We have tons of bugs requesting us to add stuff to
>> > the kernel config, and having this config fragment solves them all.
>> >
>> > If there's any hardware specific thing that could be disabled, we
>> > could just move to the board config. Regarding CONFIG_REGULATORS, I
>> > just decided to disable it at the vexpress.conf, as it only breaks
>> > stuff at vexpress (and makes sense to track it there).
>>
>> Well, the other boards which need regulators already enable it, so
>> there's not really any need for Ubuntu to have this config. This
>> particular issue isn't worth worrying about - we'll be adding regulators
>> to vexpress to enable the single kernel image initiative - but it does
>> seem to show up a general issue of the blurring of the purpose of config
>> fragments; if Ubuntu enables a bunch of hardware support, what is the
>> roll of the board config fragments?
>
> Generally, I'd like it that the distribution flavor avoided specifying
> hardware support config, as Tixy says. I realize this clashes with the
> goal to stay as close as possible to the stock distro configuration, but
> that's also not a end-goal in itself -- ideally, Ubuntu adopts config
> fragments themselves and leaves the hardware-specific configs to be
> enabled by board frags.

That's our goal. Currently it's yet perfect because it's actually a
pain to update all those config sets, as it'd require at least a
kernel build (which could cause failures and other extra bugs). From
my personal experience, working on updating configs is a PITA, as once
you enable a few other configs, things can break heavily (as the
config combinations are not properly tested still).

> Is there a way we can achieve this without causing more problems than we
> are solving?

We're getting there. If you see the amount of bugs we were able to
close but just using the current config sets you'd be surprised how
useful it was for the previous cycle :-) This was the first time we
used it, so not getting it perfect at first is expected ;-)

Cheers,
-- 
Ricardo Salveti de Araujo

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