2012-09-19 Android Platform Team Meeting Agenda Posted

2012-09-18 Thread Zach Pfeffer 
Take a look at:

https://wiki.linaro.org/Platform/Android/Meetings/2012-09-19

Feel free to add to the agenda and join us in #linaro-meeting on
irc.freenode.net at 13:00 UTC on 2012/9/19.

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

Re: fastmodel run over ubuntu 64bit machine

2012-09-18 Thread Andy Doan 

On 09/17/2012 04:01 AM, Dave Pigott wrote:

Hi Lei,

I'm copying Andy Doan directly on this, since he's had more experience
of getting FM working in LAVA and can probably point you in the right
direction.

Thanks

Dave

On 14 Sep 2012, at 14:35, Lei Wen wrote:


Hi Dave,

On Fri, Sep 14, 2012 at 3:58 PM, Dave Pigott mailto:dave.pig...@linaro.org>> wrote:

Hi Lei,

We run Fast Models on 64 bit all the time. How are you creating
the model, and how are you trying to launch it?


I launch the fast model by below command:
model_shell cadi_system_Linux64-Release-GCC-4.4.so

boot-wrapper/linux-system-semi.axf -f params


Looks like you do things different than we do. The way we launch things 
is with:


/opt/arm/RTSM_A15-A7x14_VE/Linux64_RTSM_VE_Cortex-A15x4-A7x4/RTSM_VE_Cortex-A15x4-A7x4 


  -a coretile.cluster0.*=img.axf
  -C motherboard.mmc.p_mmc_file=sd.img
  -C coretile.cluster0.cpu0.semihosting-enable=1
  -C motherboard.hostbridge.userNetworking=1
  -C coretile.cache_state_modelled=0
  -C motherboard.smsc_91c111.enabled=1

I also follow pages like:

 https://wiki.linaro.org/Platform/Android/AndroidOnFastModels


And it is interested that while I just run the "./isim_system", there
is no such error report out.
But I don't know to use isim_system to launch this simulation...


Dave

On 14 Sep 2012, at 08:40, Lei Wen wrote:

> Hi,
>
> Does anyone try to run the fastmodel over ubuntu 64bit machine?
> I try to run the simulation over Cortex-A15 model, but get below
error message when start:
> "Fatal Error: No CreateCADIBroker entry point found. Not a CADI
2.0 model ?"
>
> Anyone knows what this message means? Do I need any additional
configuration to bring up
> the fastmodel over 64bit ubuntu?
>
> Thanks,
> Lei
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org 
> http://lists.linaro.org/mailman/listinfo/linaro-dev


Thanks,
Lei





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

Re: [PATCH 0/6] cpuidle : per cpu latencies

2012-09-18 Thread Rafael J. Wysocki 
On Tuesday, September 18, 2012, Lorenzo Pieralisi wrote:
> On Mon, Sep 17, 2012 at 10:35:00PM +0100, Daniel Lezcano wrote:
> > On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote:
> > > On Monday, September 17, 2012, Daniel Lezcano wrote:
> > >> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> > >>> On Friday, September 07, 2012, Daniel Lezcano wrote:
> 
> [...]
> 
> > >>> Unfortunately, I also don't agree with the approach used by the 
> > >>> remaining
> > >>> patches, which is to try to use a separate array of states for each
> > >>> individual CPU core.  This way we end up with quite some duplicated data
> > >>> if the CPU cores in question actually happen to be identical.
> > >>
> > >> Actually, there is a single array of states which is defined with the
> > >> cpuidle_driver. A pointer to this array from the cpuidle_device
> > >> structure is added and used from the cpuidle core.
> > >>
> > >> If the cpu cores are identical, this pointer will refer to the same 
> > >> array.
> > > 
> > > OK, but what if there are two (or more) sets of cores, where all cores in 
> > > one
> > > set are identical, but two cores from different sets differ?
> > 
> > A second array is defined and registered for these cores with the
> > cpuidle_register_states function.
> > 
> > Let's pick an example with the big.LITTLE architecture.
> > 
> > There are two A7 and two A15, resulting in the code on 4 cpuidle_device
> > structure (eg. dev_A7_1, dev_A7_2, dev_A15_1, dev_A15_2). Then the
> > driver registers a different cpu states array for the A7s and the A15s
> > 
> > At the end,
> > 
> > dev_A7_1->states points to the array states 1
> > dev_A7_2->states points to the array states 1
> > 
> > dev_A15_1->states points to the array states 2
> > dev_A15_2->states points to the array states 2
> > 
> > It is similar with Tegra3.
> > 
> > I think Peter and Lorenzo already wrote a driver based on this approach.
> > Peter, Lorenzo any comments ?
> 
> Well, I guess the question is about *where* the array of states should
> belong. With the current approach we end up having an array of states
> in the cpuidle_driver, but also array(s) of states in platform code and we
> override the newly added pointer in cpuidle_device to point to those
> array(s) for CPUs whose idle states differ from the ones registered (and
> copied) in the driver.
> 
> Data is NOT duplicated but now I understand Rafael's remark.
> 
> If we have a driver per-[set of cpus] (that is impossible with the
> current framework as you higlighted) code would be cleaner since
> all idle states data would live in cpuidle_driver(s), not possibly in
> platform code. Then the problem becomes: what cpuidle_driver should be
> used and how to choose that at run-time within the governors.

For that to work, the cpuidle core would have to be modified so that it didn't
make the "there may be only on driver in the system" assumption and there would
have to be a way to associate the given CPU core with the matching driver.

Thanks,
Rafael

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

Re: [PATCH 0/6] cpuidle : per cpu latencies

2012-09-18 Thread Rafael J. Wysocki 
On Monday, September 17, 2012, Daniel Lezcano wrote:
> On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote:
> > On Monday, September 17, 2012, Daniel Lezcano wrote:
> >> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> >>> On Friday, September 07, 2012, Daniel Lezcano wrote:
>  Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab,
>  cpuidle: Single/Global registration of idle states
> 
>  we have a single registration for the cpuidle states which makes
>  sense. But now two new architectures are coming: tegra3 and big.LITTLE.
> 
>  These architectures have different cpus with different caracteristics
>  for power saving. High load => powerfull processors, idle => small 
>  processors.
> 
>  That implies different cpu latencies.
> 
>  This patchset keeps the current behavior as introduced by Deepthi without
>  breaking the drivers and add the possibility to specify a per cpu states.
> 
>   * Tested on intel core 2 duo T9500
>   * Tested on vexpress by Lorenzo Pieralsi
>   * Tested on tegra3 by Peter De Schrijver
> 
>  Daniel Lezcano (6):
>    acpi : move the acpi_idle_driver variable declaration
>    acpi : move cpuidle_device field out of the acpi_processor_power
>  structure
>    acpi : remove pointless cpuidle device state_count init
> >>>
> >>> I've posted comments about patches [1-3/6] already.  In short, I don't 
> >>> like
> >>> [1/6], [2/6] would require some more work IMO and I'm not sure about the
> >>> validity of the observation that [3/6] is based on.
> >>>
> >>> Yes, I agree that the ACPI processor driver as a whole might be cleaner
> >>> and it probably would be good to spend some time on cleaning it up, but
> >>> not necessarily in a hurry.
> >>>
> >>> Unfortunately, I also don't agree with the approach used by the remaining
> >>> patches, which is to try to use a separate array of states for each
> >>> individual CPU core.  This way we end up with quite some duplicated data
> >>> if the CPU cores in question actually happen to be identical.
> >>
> >> Actually, there is a single array of states which is defined with the
> >> cpuidle_driver. A pointer to this array from the cpuidle_device
> >> structure is added and used from the cpuidle core.
> >>
> >> If the cpu cores are identical, this pointer will refer to the same array.
> > 
> > OK, but what if there are two (or more) sets of cores, where all cores in 
> > one
> > set are identical, but two cores from different sets differ?
> 
> A second array is defined and registered for these cores with the
> cpuidle_register_states function.
> 
> Let's pick an example with the big.LITTLE architecture.
> 
> There are two A7 and two A15, resulting in the code on 4 cpuidle_device
> structure (eg. dev_A7_1, dev_A7_2, dev_A15_1, dev_A15_2). Then the
> driver registers a different cpu states array for the A7s and the A15s
> 
> At the end,
> 
> dev_A7_1->states points to the array states 1
> dev_A7_2->states points to the array states 1
> 
> dev_A15_1->states points to the array states 2
> dev_A15_2->states points to the array states 2
> 
> It is similar with Tegra3.
> 
> I think Peter and Lorenzo already wrote a driver based on this approach.
> Peter, Lorenzo any comments ?
> 
> The single registration mechanism introduced by Deepthi is kept and we
> have a way to specify different idle states for different cpus.
> 
> > In that case it would be good to have one array of states per set, but the
> > patch doesn't seem to do that, does it?
> 
> Yes, this is what does the patch.

OK

Now, if you look at struct cpuidle_driver, it is not much more than the
array of struct cpuidle_state objects.  Yes, there are more fields in there,
but they are all secondary.

This means that by adding a new array of states you effectively add a different
cpuidle driver for those CPU cores.

> >> Maybe I misunderstood you remark but there is no data duplication, that
> >> was the purpose of this approach to just add a pointer to point to a
> >> single array when the core are identical and to a different array when
> >> the cores are different (set by the driver). Furthermore, this patch
> >> allows to support multiple cpu latencies without impacting the existing
> >> drivers.
> > 
> > Well that's required. :-)
> 
> Yes :)
> 
> >>> What about using a separate cpuidle driver for every kind of different 
> >>> CPUs in
> >>> the system (e.g. one driver for "big" CPUs and the other for "little" 
> >>> ones)?
> >>>
> >>> Have you considered this approach already?
> >>
> >> No, what would be the benefit of this approach ?
> > 
> > Uniform handling of all the CPUs of the same kind without data duplication
> > and less code complexity, I think.
> > 
> >> We will need to switch
> >> the driver each time we switch the cluster (assuming all it is the bL
> >> switcher in place and not the scheduler). IMHO, that could be suboptimal
> >> because we will have to (un)register the driver,

Re: [PATCH v4 06/24] docs: Xen ARM DT bindings

2012-09-18 Thread Dave Martin 
On Mon, Sep 17, 2012 at 03:12:11PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Rob Herring wrote:
> > On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > >>> Add a doc to describe the Xen ARM device tree bindings
> > >>>
> > >>>
> > >>> Changes in v4:
> > >>>
> > >>> - "xen,xen" should be last as it is less specific;
> > >>> - update reg property using 2 address-cells and 2 size-cells.
> > >>>
> > >>>
> > >>> Signed-off-by: Stefano Stabellini 
> > >>> CC: devicetree-disc...@lists.ozlabs.org
> > >>> CC: David Vrabel 
> > >>> CC: Rob Herring 
> > >>> CC: Dave Martin 
> > >>> ---
> > >>>  Documentation/devicetree/bindings/arm/xen.txt |   22 
> > >>> ++
> > >>>  1 files changed, 22 insertions(+), 0 deletions(-)
> > >>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> > >>> b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> new file mode 100644
> > >>> index 000..1f8f7d4
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> @@ -0,0 +1,22 @@
> > >>> +* Xen hypervisor device tree bindings
> > >>> +
> > >>> +Xen ARM virtual platforms shall have the following properties:
> > >>> +
> > 
> > State that they are part of top-level "hypervisor" node.
> 
> OK
> 
> 
> > >>> +- compatible:
> > >>> +   compatible = "xen,xen-", "xen,xen";
> > >>> +  where  is the version of the Xen ABI of the platform.
> > >>> +
> > >>> +- reg: specifies the base physical address and size of a region in
> > >>> +  memory where the grant table should be mapped to, using an
> > >>> +  HYPERVISOR_memory_op hypercall. 
> > >>> +
> > >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> > >>
> > >> Its singular here.. but in the example its plurar. What if you use
> > >> multiple of the same number ("16 0xf")?
> > > 
> > > The "interrupts" property in the example below is a standard property to
> > > describe interrupts. We just happen to declare only one interrupt.
> > > 
> > > From the device tree point of view it would be possible to declare more
> > > than one interrupt here, but Xen only supports one really.
> > > 
> > > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > > a specific meaning in the GIC context:
> > > 
> > > """
> > >   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > >   interrupts.
> > > 
> > >   The 2nd cell contains the interrupt number for the interrupt type.
> > >   SPI interrupts are in the range [0-987].  PPI interrupts are in the
> > >   range [0-15].
> > > 
> > >   The 3rd cell is the flags, encoded as follows:
> > >   bits[3:0] trigger type and level flags.
> > >   1 = low-to-high edge triggered
> > >   2 = high-to-low edge triggered
> > >   4 = active high level-sensitive
> > >   8 = active low level-sensitive
> > >   bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> > >   the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> > >   the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> > > """
> > > 
> > > So <1 15 0xf08> means the last PPI.
> > 
> > Since it is a PPI, it is handled differently than a normal interrupt.
> > That is fine, but you should somehow state that a GIC node is also required.
> 
> Yes, good idea
> 
> 
> > >>> +
> > >>> +
> > >>> +Example:
> > >>> +
> > >>> +hypervisor {
> > >>> +   compatible = "xen,xen-4.3", "xen,xen";
> > >>> +   reg = <0 0xb000 0 0x2>;
> > >>
> > >> So two grant tables?
> > >>
> > >> Hm, physical address is zero, and the size is 0xbignumber?
> > >> Or is the '0' denotating a seperator of arguments, so it is
> > >> 0xb000.. for physical address and 0x2 for size?
> > > 
> > > from http://devicetree.org/Device_Tree_Usage:
> > > 
> > > "Each addressable device gets a reg which is a list of tuples in the
> > > form reg =  > > Each tuple represents an address range used by the device. Each address
> > > value is a list of one or more 32 bit integers called cells. Similarly,
> > > the length value can either be a list of cells, or empty."
> > > 
> > > In this case the address is: [0 0xb000], that means
> > > 0xb000, and the length is [0 0x2], that means
> > > 0x0002.
> > 
> > But the size depends on #size-cells and #address-cells. I would expect
> > those to be 1 for a 32-bit guest.
>  
> I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
> that on Linux v3.6-rc5 has:
> 
> #address-cells = <2>;
> #size-cells = <2>;

Some core tiles on vexpress use physical addresses beyond 4G.  But many
32-bit platforms (including some supporting the virtualization extensions)
may not.  There's no reason for such platforms to set these properties to
<2>.

> What should

Re: [PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)

2012-09-18 Thread Konrad Rzeszutek Wilk 
On Tue, Sep 18, 2012 at 02:57:05PM +0100, Stefano Stabellini wrote:
> On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> > On Monday 17 September 2012, Stefano Stabellini wrote:
> > 
> > > I am also attaching to this email the dts'es that I am currently using
> > > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > > and it is appended in binary form to the guest kernel image. I am not
> > > sure where they are supposed to live yet, so I am just attaching them
> > > here so that people can actually try out this series if they want to.
> > 
> > You can submit the dts files separately so we can include them in
> > the arm-soc tree. Pawel Moll is handling vexpress related changes these
> > days, so it would be reasonable if he included them in a pull request.
> 
> OK, I'll submit them as a patch series separately.
> 
> 
> > > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > > branch.
> > > 
> > > Arnd, Russell, what do you think about this series? If you are OK with
> > > it, to whom should I submit it?
> > 
> > I have no objections to your patches from this series. IMHO they should
> > be submitted through the Xen tree,
> 
> Konrad, are you happy to carry this series in your tree?

Yes.
> 
> 
> >but it would be good to have an Ack from Russell.
> 
> Indeed

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

Re: [PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)

2012-09-18 Thread Konrad Rzeszutek Wilk 
On Tue, Sep 18, 2012 at 12:34:29PM +, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.
>  
> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree, but it would be good to have an Ack
> from Russell.

OK, I can do that.

How do we get Russell to look at these patches? Bribes? Ship him some
beer/wine to be delievered to his office?

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

Re: [PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)

2012-09-18 Thread Stefano Stabellini 
On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.

OK, I'll submit them as a patch series separately.


> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree,

Konrad, are you happy to carry this series in your tree?


>but it would be good to have an Ack from Russell.

Indeed

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

Re: [PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)

2012-09-18 Thread Arnd Bergmann 
On Monday 17 September 2012, Stefano Stabellini wrote:

> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.

You can submit the dts files separately so we can include them in
the arm-soc tree. Pawel Moll is handling vexpress related changes these
days, so it would be reasonable if he included them in a pull request.
 
> The patch series has been rebased on Konrad's stable/for-linus-3.7
> branch.
> 
> Arnd, Russell, what do you think about this series? If you are OK with
> it, to whom should I submit it?

I have no objections to your patches from this series. IMHO they should
be submitted through the Xen tree, but it would be good to have an Ack
from Russell.

Arnd

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

Re: [PATCH 0/6] cpuidle : per cpu latencies

2012-09-18 Thread Peter De Schrijver 
> 
> It is similar with Tegra3.
> 

In our case CPU0 has different latencies for 1 C state compared to the other
CPUs

> I think Peter and Lorenzo already wrote a driver based on this approach.
> Peter, Lorenzo any comments ?
> 

Yes. My implementation doesn't provide a state table in the cpuidle device 
at all. I always use cpuidle_register_states() to register the state tables.

Cheers,

Peter.

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

Re: [PATCH 0/6] cpuidle : per cpu latencies

2012-09-18 Thread Lorenzo Pieralisi 
On Mon, Sep 17, 2012 at 10:35:00PM +0100, Daniel Lezcano wrote:
> On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote:
> > On Monday, September 17, 2012, Daniel Lezcano wrote:
> >> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> >>> On Friday, September 07, 2012, Daniel Lezcano wrote:

[...]

> >>> Unfortunately, I also don't agree with the approach used by the remaining
> >>> patches, which is to try to use a separate array of states for each
> >>> individual CPU core.  This way we end up with quite some duplicated data
> >>> if the CPU cores in question actually happen to be identical.
> >>
> >> Actually, there is a single array of states which is defined with the
> >> cpuidle_driver. A pointer to this array from the cpuidle_device
> >> structure is added and used from the cpuidle core.
> >>
> >> If the cpu cores are identical, this pointer will refer to the same array.
> > 
> > OK, but what if there are two (or more) sets of cores, where all cores in 
> > one
> > set are identical, but two cores from different sets differ?
> 
> A second array is defined and registered for these cores with the
> cpuidle_register_states function.
> 
> Let's pick an example with the big.LITTLE architecture.
> 
> There are two A7 and two A15, resulting in the code on 4 cpuidle_device
> structure (eg. dev_A7_1, dev_A7_2, dev_A15_1, dev_A15_2). Then the
> driver registers a different cpu states array for the A7s and the A15s
> 
> At the end,
> 
> dev_A7_1->states points to the array states 1
> dev_A7_2->states points to the array states 1
> 
> dev_A15_1->states points to the array states 2
> dev_A15_2->states points to the array states 2
> 
> It is similar with Tegra3.
> 
> I think Peter and Lorenzo already wrote a driver based on this approach.
> Peter, Lorenzo any comments ?

Well, I guess the question is about *where* the array of states should
belong. With the current approach we end up having an array of states
in the cpuidle_driver, but also array(s) of states in platform code and we
override the newly added pointer in cpuidle_device to point to those
array(s) for CPUs whose idle states differ from the ones registered (and
copied) in the driver.

Data is NOT duplicated but now I understand Rafael's remark.

If we have a driver per-[set of cpus] (that is impossible with the
current framework as you higlighted) code would be cleaner since
all idle states data would live in cpuidle_driver(s), not possibly in
platform code. Then the problem becomes: what cpuidle_driver should be
used and how to choose that at run-time within the governors.

> 
> The single registration mechanism introduced by Deepthi is kept and we
> have a way to specify different idle states for different cpus.
> 
> > In that case it would be good to have one array of states per set, but the
> > patch doesn't seem to do that, does it?
> 
> Yes, this is what does the patch.

The patch adds a pointer to idle states in cpuidle_device, the platform driver
defines the array(s).

> >> Maybe I misunderstood you remark but there is no data duplication, that
> >> was the purpose of this approach to just add a pointer to point to a
> >> single array when the core are identical and to a different array when
> >> the cores are different (set by the driver). Furthermore, this patch
> >> allows to support multiple cpu latencies without impacting the existing
> >> drivers.
> > 
> > Well that's required. :-)
> 
> Yes :)
> 
> >>> What about using a separate cpuidle driver for every kind of different 
> >>> CPUs in
> >>> the system (e.g. one driver for "big" CPUs and the other for "little" 
> >>> ones)?
> >>>
> >>> Have you considered this approach already?
> >>
> >> No, what would be the benefit of this approach ?
> > 
> > Uniform handling of all the CPUs of the same kind without data duplication
> > and less code complexity, I think.
> > 
> >> We will need to switch
> >> the driver each time we switch the cluster (assuming all it is the bL
> >> switcher in place and not the scheduler). IMHO, that could be suboptimal
> >> because we will have to (un)register the driver, register the devices,
> >> pull all the sysfs and notifications mechanisms. The cpuidle core is not
> >> designed for that.
> > 
> > I don't seem to understand how things are supposed to work, then.
> 
> Sorry, I did not suggest that. I am wondering how several cpuidle
> drivers can co-exist together in the state of the code. Maybe I
> misunderstood your idea.
> 
> The patchset I sent is pretty simple and do not duplicate the array states.
> 
> That would be nice if Len could react to this patchset (4/6,5/6, and
> 6/6). Cc'ing him to its intel address.

As the idle infrastructure stands I do not see how multiple cpuidle drivers
can co-exist, that's the problem, and Daniel already mentioned that.

Lorenzo


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

[PATCH 3/3] init: Add additional print for detailed kernel version

2012-09-18 Thread Tushar Behera 
When CONFIG_LOCALVERSION_AUTO is not defined, kernel boot log prints
only short version. This doesn't have any information regarding the
commit at which the kernel was compiled.

Adding an additional print statement to explicitly tell the current
HEAD.

Signed-off-by: Tushar Behera 
---
 include/linux/printk.h |1 +
 init/main.c|3 +++
 init/version.c |3 +++
 3 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..a2560f6 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -6,6 +6,7 @@
 
 extern const char linux_banner[];
 extern const char linux_proc_banner[];
+extern const char linux_scm_version_banner[];
 
 static inline int printk_get_level(const char *buffer)
 {
diff --git a/init/main.c b/init/main.c
index b286730..bad6b9b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -494,6 +494,9 @@ asmlinkage void __init start_kernel(void)
boot_cpu_init();
page_address_init();
printk(KERN_NOTICE "%s", linux_banner);
+#if !IS_ENABLED(CONFIG_LOCALVERSION_AUTO)
+   printk(KERN_NOTICE "%s", linux_scm_version_banner);
+#endif
setup_arch(&command_line);
mm_init_owner(&init_mm, &init_task);
mm_init_cpumask(&init_mm);
diff --git a/init/version.c b/init/version.c
index 86fe0cc..e86cce9 100644
--- a/init/version.c
+++ b/init/version.c
@@ -46,3 +46,6 @@ const char linux_proc_banner[] =
"%s version %s"
" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
" (" LINUX_COMPILER ") %s\n";
+
+const char linux_scm_version_banner [] =
+   "Detailed version Linux "UTS_RELEASE "" KERNEL_VERSION_LOCAL "\n";
-- 
1.7.4.1


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

[PATCH 2/3] kbuild: Add support to extract information about current git commit HEAD

2012-09-18 Thread Tushar Behera 
Signed-off-by: Tushar Behera 
---
 Makefile |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 0f66f14..7e83768 100644
--- a/Makefile
+++ b/Makefile
@@ -374,6 +374,7 @@ KBUILD_LDFLAGS_MODULE := -T 
$(srctree)/scripts/module-common.lds
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
+KERNELVERSIONLOCAL= $(shell cat .scmversion 2> /dev/null)
 
 export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
 export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
@@ -778,7 +779,8 @@ $(vmlinux-dirs): prepare scripts
 include/config/kernel.release: include/config/auto.conf FORCE
$(Q)rm -f $@
$(Q)echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))" > $@
-
+   $(Q)rm -f .scmversion
+   $(Q)($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion 
--save-scmversion $(srctree))
 
 # Things we need to do before we recursively start building the kernel
 # or the modules are listed in "prepare".
@@ -829,7 +831,8 @@ define filechk_utsrelease.h
  echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >&2;\
  exit 1; \
fi;   \
-   (echo \#define UTS_RELEASE \"$(KERNELRELEASE)\";)
+   (echo \#define UTS_RELEASE \"$(KERNELRELEASE)\"; \
+   echo \#define KERNEL_VERSION_LOCAL \"$(KERNELVERSIONLOCAL)\";)
 endef
 
 define filechk_version.h
-- 
1.7.4.1


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

[PATCH 0/3] kbuild modifications to print git commit ID

2012-09-18 Thread Tushar Behera 
The bootlog in Ubuntu/Android images provide minimal information about
the current HEAD from which the kernel was built. This patchset enables
us to get detailed version info of the kernel.

Tested both on Ubuntu and Android images.

Patch 1 is already submitted to kernel-build ML and has been rejected.
Hence review of this patchset is required w.r.t. Android/Ubuntu LEB and
linux-linaro in mind.

Tushar Behera (3):
  kbuild: setlocalversion: ignore private tags while reporting local
version
  kbuild: Add support to extract information about current git commit
HEAD
  init: Add additional print for detailed kernel version

 Makefile|7 +--
 include/linux/printk.h  |1 +
 init/main.c |3 +++
 init/version.c  |3 +++
 scripts/setlocalversion |5 +++--
 5 files changed, 15 insertions(+), 4 deletions(-)

-- 
1.7.4.1


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