Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Saravana Kannan]

On 01/12/2012 04:48 PM, Rob Herring wrote:

On 01/12/2012 06:04 PM, Saravana Kannan wrote:

On 01/04/2012 08:07 PM, Turquette, Mike wrote:

On Wed, Jan 4, 2012 at 6:11 PM, Rob Herring
wrote:

On 01/04/2012 07:01 PM, Turquette, Mike wrote:

On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring
wrote:

On 01/03/2012 08:15 PM, Richard Zhao wrote:

On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:

On Wed, Dec 14, 2011 at 5:18 AM, Thomas
Gleixner   wrote:

On Tue, 13 Dec 2011, Mike Turquette wrote:


snip


+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware
for the
+ * parent and rate and sets them both.  Adds the clk to the
sysfs tree
+ * topology.
+ *
+ * Caller must populate clk->name and clk->flags before calling


I'm not too happy about this construct. That leaves struct clk
and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will
lead to
random fiddling in that data structure in drivers and arch code
just
because the core code has a shortcoming.

Why can't we make struct clk a real cookie and confine the data
structure to the core code ?

That would change the init call to something like:

struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
  struct clk *parent)

And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char*name;
unsigned long flags;
};

Implementers can do:
struct my_clk_hw {
struct clk_hwhw;
mydata;
};

And then change the clk ops callbacks to take struct clk_hw * as an
argument.

We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.


DT is not a prerequisite for having dynamically created clocks. You
can
make clock init dynamic without DT.


Agreed.


What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move
it to
struct clk later. Even if almost everything ends up in clk_hw
initially,
at least the structure is in place to have common, core-only data
separate from platform data.


What is the point of this?


To have a way forward. It would be nice to have a clk infrastructure
before I retire...


Haha, agreed.




The original clk_hw was defined simply as:

struct clk_hw {
  struct clk *clk;
};

It's only purpose in life was as a handle for navigation between the
opaque struct clk and the hardware-specific struct my_clk_hw.  struct
clk_hw is defined in clk.h and everyone can see it.  If we're suddenly
OK putting clk data in this structure then why bother with an opaque
struct clk at all?


What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.


To answer your question on what data we're trying to expose: platform
code commonly needs the parent pointer and the clk rate (and by
extension, the rate of the parent).  For debug/error prints it is also
nice to have the clk name.  Generic clk flags are also conceivably
something that platform code might want.


I agree with the need to have the parent and flags from a static init
perspective. There's not really a good reason the others can't be
accessed thru accessors though.


I'd like to spin the question around: if we're OK exposing some stuff
(in your example above, the parent pointer), then what clk data are
you trying to hide?


Well, everything from drivers which the current clk implementations do
hide. Catching abuse in with drivers coming in from all different trees
and lists will be impossible.

For platform code it is more fuzzy. I don't think platform code should
be allowed to muck with prepare/enable counts for example.


So there is a clear dichotomy: drivers shouldn't be exposed to any of
it and platform code should be exposed to some of it.

How about a drivers/clk/clk-private.h which will define struct clk and
must only be included by clk drivers in drivers/clk/*?

This establishes a bright line between those things which are allowed
to know the details of struct clk and those that are not: namely that
clk drivers in drivers/clk/ may use '#include "clk-private.h"'.
Obviously struct clk is opaque to the rest of the kernel (in the same
way it has been prior to the common clk patches) and there is no need
for struct clk_hw anymore.  Also helper functions are no longer needed
for clock driver code, which I think *is* a manageable set of code to
review.  Also clk drivers must live in drivers/clk/ for this to work
(without a big ugly path in someone's #include directive somewhere).

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Saravana Kannan]

On 01/04/2012 08:07 PM, Turquette, Mike wrote:

On Wed, Jan 4, 2012 at 6:11 PM, Rob Herring  wrote:

On 01/04/2012 07:01 PM, Turquette, Mike wrote:

On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring  wrote:

On 01/03/2012 08:15 PM, Richard Zhao wrote:

On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:

On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner  wrote:

On Tue, 13 Dec 2011, Mike Turquette wrote:


snip


+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both.  Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk->name and clk->flags before calling


I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.

Why can't we make struct clk a real cookie and confine the data
structure to the core code ?

That would change the init call to something like:

struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
 struct clk *parent)

And have:
struct clk_hw {
   struct clk_hw_ops *ops;
   const char*name;
   unsigned long flags;
};

Implementers can do:
struct my_clk_hw {
   struct clk_hwhw;
   mydata;
};

And then change the clk ops callbacks to take struct clk_hw * as an
argument.

We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.


DT is not a prerequisite for having dynamically created clocks. You can
make clock init dynamic without DT.


Agreed.


What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move it to
struct clk later. Even if almost everything ends up in clk_hw initially,
at least the structure is in place to have common, core-only data
separate from platform data.


What is the point of this?


To have a way forward. It would be nice to have a clk infrastructure
before I retire...


Haha, agreed.




The original clk_hw was defined simply as:

struct clk_hw {
 struct clk *clk;
};

It's only purpose in life was as a handle for navigation between the
opaque struct clk and the hardware-specific struct my_clk_hw.  struct
clk_hw is defined in clk.h and everyone can see it.  If we're suddenly
OK putting clk data in this structure then why bother with an opaque
struct clk at all?


What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.


To answer your question on what data we're trying to expose: platform
code commonly needs the parent pointer and the clk rate (and by
extension, the rate of the parent).  For debug/error prints it is also
nice to have the clk name.  Generic clk flags are also conceivably
something that platform code might want.


I agree with the need to have the parent and flags from a static init
perspective. There's not really a good reason the others can't be
accessed thru accessors though.


I'd like to spin the question around: if we're OK exposing some stuff
(in your example above, the parent pointer), then what clk data are
you trying to hide?


Well, everything from drivers which the current clk implementations do
hide. Catching abuse in with drivers coming in from all different trees
and lists will be impossible.

For platform code it is more fuzzy. I don't think platform code should
be allowed to muck with prepare/enable counts for example.


So there is a clear dichotomy: drivers shouldn't be exposed to any of
it and platform code should be exposed to some of it.

How about a drivers/clk/clk-private.h which will define struct clk and
must only be included by clk drivers in drivers/clk/*?

This establishes a bright line between those things which are allowed
to know the details of struct clk and those that are not: namely that
clk drivers in drivers/clk/ may use '#include "clk-private.h"'.
Obviously struct clk is opaque to the rest of the kernel (in the same
way it has been prior to the common clk patches) and there is no need
for struct clk_hw anymore.  Also helper functions are no longer needed
for clock driver code, which I think *is* a manageable set of code to
review.  Also clk drivers must live in drivers/clk/ for this to work
(without a big ugly path in someone's #include directive somewhere).


While the original clk_hw suggestion was well intentioned, it just 
forces too many unnecessary 

Re: l-m-c hacking for UEFI

[Jon Medhurst (Tixy)]

On Thu, 2012-01-12 at 17:35 -0300, Guilherme Salgado wrote:
> I wonder if it wouldn't be better to make hwpacks include just one
> bootloader (whichever is chosen by the hwpack author)?

This could make the transition difficult. Some users (like LAVA) require
U-Boot, whereas others might want to use the new UEFI.

Also, I think we should support placing multiple versions of the
bootloader in the boot partition, together with multiple device-tree
blobs. Otherwise, for Versatile Express, we will soon end up having to
produce 6 images each month. (6 is the permutation of {A5, A9, A15 CPUs}
x {real hardware, fast models} and there are other combinations likely
in the future.)

-- 
Tixy


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

Re: l-m-c hacking for UEFI

[Zygmunt Krynicki]

On 01/13/2012 10:38 AM, Jon Medhurst (Tixy) wrote:

On Thu, 2012-01-12 at 17:35 -0300, Guilherme Salgado wrote:

I wonder if it wouldn't be better to make hwpacks include just one
bootloader (whichever is chosen by the hwpack author)?


This could make the transition difficult. Some users (like LAVA) require
U-Boot, whereas others might want to use the new UEFI.


We don't require U-Boot. If we can somehow script UEFI (remotely tell it 
to boot from something) then we'll gladly support UEFI as well.


--
Zygmunt Krynicki
Linaro Validation Team

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

using cpuidle on panda board

[Vincent Guittot]

Hi,

I'd like to do some tests with cpuidle on my panda board but i'm
facing some issues:

Originally, i'd like to use the Linaro developer image which uses the
landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver
only works when cpu1 is off whereas i'd like to do some test with both
cpus.
The android kernel has got a cpuidle driver which can enter C-states
when both cpus are running and I was wondering if there is a plan to
merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2
?

Then, when I'm testing the landing-panda-11.12-release android image
on my panda board revA1, the cpuidle is using only C0 state (WFI)
according to cpuidle stats.

My test sequence:
prevent suspend with: echo qwerty > /sys/power/wake_lock
let android enter the early_suspend mode
get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only
state0 time is different from 0

Is it a normal behavior ?

Regards,
Vincent

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

Re: l-m-c hacking for UEFI

[Danilo Šegan]

Hi Ryan, Guilherme, all,

У чет, 12. 01 2012. у 17:35 -0300, Guilherme Salgado пише:
> 
> I'm wondering... do you have any use cases for the none and all
> options?

At least the 'all' option should make sense: I remember reading that
UEFI can happily live alongside a different boot loader as well, thus
allowing one single image to be used for systems supporting either uboot
or UEFI.

Ryan, my overall take on this so far is:

 - there is still a lot of work done to be able to make this fully
usable
 - we would need sufficient tests (automated, unit and integration
tests) to ensure whatever we implemented is not easily broken with
future modifications
 - it would be hard to get all this in a suitable state by the end of
January cycle
 - it would be better if you used a branch and pushed it to
lp:~ryanharkin/linaro-image-tools/uefi-support or something (name it
whatever you like, it doesn't have to be "uefi-support")

The core question is how urgent this really is?

Cheers,
Danilo



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

Re: using cpuidle on panda board

[Andy Green]

On 01/13/2012 05:59 PM, Somebody in the thread at some point said:

Hi,

I'd like to do some tests with cpuidle on my panda board but i'm
facing some issues:

Originally, i'd like to use the Linaro developer image which uses the
landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver
only works when cpu1 is off whereas i'd like to do some test with both
cpus.
The android kernel has got a cpuidle driver which can enter C-states
when both cpus are running and I was wondering if there is a plan to
merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2
?

Then, when I'm testing the landing-panda-11.12-release android image
on my panda board revA1, the cpuidle is using only C0 state (WFI)
according to cpuidle stats.

My test sequence:
prevent suspend with: echo qwerty>  /sys/power/wake_lock
let android enter the early_suspend mode
get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only
state0 time is different from 0

Is it a normal behavior ?


No I think cpuidle is broken with what we have in tilt-3.1.

It's worth trying tilt-tracking which, last time Jassi looked at it was 
working and visiting all the C states.


-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: using cpuidle on panda board

[Jassi Brar]

On 13 January 2012 16:13, Andy Green  wrote:
> On 01/13/2012 05:59 PM, Somebody in the thread at some point said:
>>
>> Hi,
>>
>> I'd like to do some tests with cpuidle on my panda board but i'm
>> facing some issues:
>>
>> Originally, i'd like to use the Linaro developer image which uses the
>> landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver
>> only works when cpu1 is off whereas i'd like to do some test with both
>> cpus.
>> The android kernel has got a cpuidle driver which can enter C-states
>> when both cpus are running and I was wondering if there is a plan to
>> merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2
>> ?
>>
>> Then, when I'm testing the landing-panda-11.12-release android image
>> on my panda board revA1, the cpuidle is using only C0 state (WFI)
>> according to cpuidle stats.
>>
>> My test sequence:
>> prevent suspend with: echo qwerty>  /sys/power/wake_lock
>> let android enter the early_suspend mode
>> get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only
>> state0 time is different from 0
>>
>> Is it a normal behavior ?
>
>
> No I think cpuidle is broken with what we have in tilt-3.1.
>
> It's worth trying tilt-tracking which, last time Jassi looked at it was
> working and visiting all the C states.
>
IIRC, CPU_0 entered C1, C2 states only when the CPU_1 is offline, when I tested.

Vincent, would you remember exactly which android branch has it working with
both cpus online?

Cheers,
Jassi

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

Re: using cpuidle on panda board

[Vincent Guittot]

On 13 January 2012 12:12, Jassi Brar  wrote:
> On 13 January 2012 16:13, Andy Green  wrote:
>> On 01/13/2012 05:59 PM, Somebody in the thread at some point said:
>>>
>>> Hi,
>>>
>>> I'd like to do some tests with cpuidle on my panda board but i'm
>>> facing some issues:
>>>
>>> Originally, i'd like to use the Linaro developer image which uses the
>>> landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver
>>> only works when cpu1 is off whereas i'd like to do some test with both
>>> cpus.
>>> The android kernel has got a cpuidle driver which can enter C-states
>>> when both cpus are running and I was wondering if there is a plan to
>>> merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2
>>> ?
>>>
>>> Then, when I'm testing the landing-panda-11.12-release android image
>>> on my panda board revA1, the cpuidle is using only C0 state (WFI)
>>> according to cpuidle stats.
>>>
>>> My test sequence:
>>> prevent suspend with: echo qwerty>  /sys/power/wake_lock
>>> let android enter the early_suspend mode
>>> get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only
>>> state0 time is different from 0
>>>
>>> Is it a normal behavior ?
>>
>>
>> No I think cpuidle is broken with what we have in tilt-3.1.
>>
>> It's worth trying tilt-tracking which, last time Jassi looked at it was
>> working and visiting all the C states.
>>
> IIRC, CPU_0 entered C1, C2 states only when the CPU_1 is offline, when I 
> tested.
>
yes, but I need to keep both cpu online for my tests with sched_mc

> Vincent, would you remember exactly which android branch has it working with
> both cpus online?
>

I'm using the the compiled baseline :
https://android-build.linaro.org/builds/~linaro-android/landing-panda-11.12-release/#build=3
For this baseline, a cpuidle device is registered for each CPU (0,1)
unlike the tilt tracking which register a device only for cpu0.
This baseline uses an other cpuidle driver for omap4 which manages both CPU

Vincent

> Cheers,
> Jassi

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

[PATCH] ARM: pl330: fix null pointer dereference in pl330_chan_ctrl()

[Mans Rullgard]

This fixes the thrd->req_running field being accessed before thrd
is checked for null.  The error was introduced in abb959f.

Signed-off-by: Mans Rullgard 
---
 arch/arm/common/pl330.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
index 8d8df74..67abef5 100644
--- a/arch/arm/common/pl330.c
+++ b/arch/arm/common/pl330.c
@@ -1496,12 +1496,13 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op)
struct pl330_thread *thrd = ch_id;
struct pl330_dmac *pl330;
unsigned long flags;
-   int ret = 0, active = thrd->req_running;
+   int ret = 0, active;
 
if (!thrd || thrd->free || thrd->dmac->state == DYING)
return -EINVAL;
 
pl330 = thrd->dmac;
+   active = thrd->req_running;
 
spin_lock_irqsave(&pl330->lock, flags);
 
-- 
1.7.8.3


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

Re: [PATCH] ARM: pl330: fix null pointer dereference in pl330_chan_ctrl()

[Russell King - ARM Linux]

On Fri, Jan 13, 2012 at 12:36:31PM +, Mans Rullgard wrote:
> This fixes the thrd->req_running field being accessed before thrd
> is checked for null.  The error was introduced in abb959f.
> 
> Signed-off-by: Mans Rullgard 

I don't know what's happening with the PL330 driver, but there's patches
around to remove this file and merge it with the DMA engine driver.

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

Finding source code for Linaro kernels

[Dave Martin]

For everyone who packages kernel trees:


I've had some questions about getting the source for linaro kernel
packaged, and it seems that this is still not straightforward:

Getting the debian package source (i.e., flat tarball) for a binary
kernel is possible, but only if it is a non-superseded version.

Working out which source package you need is non-obvious (You have to
check for installed kernel packages, and guess which source package
you need, based on that.  Non-linaro folks may not understand the
difference between the various meta- and real kernel packages and may
get pretty confused along the way.)

Finding the git tree and the relevant commit to reproduce the source
(including that for superseded kernels) is hard or impossible.  It
requires guesswork and/or specific knowledge about the way the
relevant team manages their trees.  For some platforms, it looks like
there may be no single tree containing the packaged kernel at all, in
which case you would also need more guesswork and/or scripts or help
from the relevant landing team in order actually to reproduce a
release.

Am I correct in these conclusions?


If so, here's a proposal -- I welcome people's comments (and please do
say if any of these problems are actually solved already!):


For every binary kernel package (.deb) publicly released by any linaro
team, including those produced by the platform team and the landing
teams:


1) The source package's control file must contain a Vcs-Git entry


2) The Vcs-Git entry must reference a git tree which contains the
_exact_ source code which appears in the source package.

 * Such a tree must exist and must be publicly readable.  It does not
have to be on git.linaro.org (though this is the recommended place).

 * Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not
acceptable, unless that repo is populated with the real source for
that specific kernel as well as the packaging.

 * Manufacturing the source package from the contents of multiple
repositories or branches at source package upload time is not
acceptable, unless the result is also recorded as a tagged commit in
the repository referenced by the Vcs-Git entry in the debian/control
file contained in that same commit.  The commit must have full
history: importing tarballs directly into a repository for the purpose
of release tagging is not acceptable.

 * Referring to a tree which does not contain the whole contents of
the debian source package (for example, debian/ and other packaging
files/dirs are missing) is not acceptable.


3) Tagging of packaged kernels must be done in a standard way.

 * I recommend _, matching the
Source field of debian/control and the version number of the most
recent debian/changelog entry respectively (which must both be present
in the repository as a consequence of (2)).  If we want to avoid
namespace pollution, we probably want to add a prefix such as debian/
or ubuntu/ to the tag name to indicate that the tag describes the
source for a published .deb package.  If so, we must standardise that
prefix so that it is identical in all out trees.

 * Tree maintainers are of course free to add any other additional
tags for their own use if they want to.

All teams already do release tagging of some sort, but the lack of
consistency creates difficulties when anyone from outside the team
tries to understand that team's trees.

 * We _could_ standardise the following, but it is not essential:

* ubuntu/: The tagged source for the _original_ kernel
which was distributed in  (where  is a linaro
monthly release such as 11.12 or 12.01)


4) No specific branch naming requirements exist.

 * Release tags do not necessarily need to appear on any branch.

 * We _could_ standardise the following, but it is not essential:

* ubuntu/latest - the tagged packaged source for the most recent
kernel release made from this tree


(In the above, we could choose a diferent prefix instead of ubuntu/,
but as described in (3) ,this should be chosen globally and _not_ on a
per-tree basis).

Cheers
---Dave

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

Re: l-m-c hacking for UEFI

[Ryan Harkin]

On 13 January 2012 10:09, Danilo Šegan  wrote:
> Hi Ryan, Guilherme, all,
>
> У чет, 12. 01 2012. у 17:35 -0300, Guilherme Salgado пише:
>>
>> I'm wondering... do you have any use cases for the none and all
>> options?

I don't have a use case for none, but it was easy to add and I
considered it might be useful to some.


> At least the 'all' option should make sense: I remember reading that
> UEFI can happily live alongside a different boot loader as well, thus
> allowing one single image to be used for systems supporting either
uboot
> or UEFI.

Indeed.  Also, the ALL case is useful for Versatile Express, which
doesn't actually use the bootloader off the card at all.  However, some
people may prefer to use u-boot or vice-versa, so having both is a nice
extra and saves having multiple hwpacks.

Also:

On Thu, 2012-01-12 at 17:35 -0300, Guilherme Salgado wrote:
> Is it implemented for any of our supported platforms already?  If not,
> do you have any idea when that might happen?

It is implemented on Versatile Express A9.  As I mentioned, VE has no
way to boot from the MMC card.  The image must be programmed into NOR
flash on the motherboard.  We do this at the moment by copying the image
from the disk image.  As mentioned, this is a manual step.

There is a BeagleBoard version and Samsung has also released a version
of UEFI for their boards, but I don't believe Linaro have been involved
so far.


>
> Ryan, my overall take on this so far is:
>
>  - there is still a lot of work done to be able to make this fully
> usable
>  - we would need sufficient tests (automated, unit and integration
> tests) to ensure whatever we implemented is not easily broken with
> future modifications
>  - it would be hard to get all this in a suitable state by the end of
> January cycle
>  - it would be better if you used a branch and pushed it to
> lp:~ryanharkin/linaro-image-tools/uefi-support or something (name it
> whatever you like, it doesn't have to be "uefi-support")
>
> The core question is how urgent this really is?

To follow up on this, Danilo and I have a chat earlier and we agreed
that a January release is not really possible.  There is too much to
consider and decide, plus the implementation on top.

We agreed that I would set up a Connect session for general issues about
hwpacks and l-m-c, including this issue; with a follow-up session a day
or so later where we concentrate on UEFI requirements.

Regards,
Ryan.


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

Re: [PATCH] ARM: pl330: fix null pointer dereference in pl330_chan_ctrl()

[Javi Merino]

On 13/01/12 12:36, Mans Rullgard wrote:
> This fixes the thrd->req_running field being accessed before thrd
> is checked for null.  The error was introduced in abb959f.
> 
> Signed-off-by: Mans Rullgard 
> ---
>  arch/arm/common/pl330.c |3 ++-

As Russell points out, the s5p tree has merged this file with
drivers/dma/pl330.c so this bug is now in that file.  Please rebase the
patch on top of linux-next.

Other than that, yes, that's my fault.

Acked-by: Javi Merino 

>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
> index 8d8df74..67abef5 100644
> --- a/arch/arm/common/pl330.c
> +++ b/arch/arm/common/pl330.c
> @@ -1496,12 +1496,13 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op 
> op)
>   struct pl330_thread *thrd = ch_id;
>   struct pl330_dmac *pl330;
>   unsigned long flags;
> - int ret = 0, active = thrd->req_running;
> + int ret = 0, active;
>  
>   if (!thrd || thrd->free || thrd->dmac->state == DYING)
>   return -EINVAL;
>  
>   pl330 = thrd->dmac;
> + active = thrd->req_running;
>  
>   spin_lock_irqsave(&pl330->lock, flags);
>  



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

Re: [PATCH] mmc: use usleep_range() in mmc_delay()

[Dmitry Antipov]

On 01/13/2012 05:22 PM, Aaro Koskinen wrote:


Anyway, I think the change is good. On systems with multiple MMC devices
the boot/probe can spend 100-200 ms alone just doing busylooping delays. I
think e.g. in mmc_rescan() the code uses frequently mmc_delay(10).


I'm worrying about this:

mmc_delay(DIV_ROUND_UP(card->ext_csd.sa_timeout, 1))

since I have no ideas about typical values for this timeout.
If it may be too small (<=10 us), using usleep_range() makes no sense.

Dmitry

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

Re: linaro powertop doesn't work during initialization of ncurse

[Tony Mansson]

Hi,

FYI: We just merged powertop into our Android 4.0.3. builds again, it was
lost when we went from Gingerbread before Christmas.

I tested it on Snowball and it ran well. There are some funny numbers that
need to be investigated but I saw no problems related to ncurses.

http://android.git.linaro.org/gitweb?p=platform/external/ncurses.git;a=summary
http://android.git.linaro.org/gitweb?p=platform/external/powertop.git;a=summary

branch linaro.

BR,
Tony

On 13 January 2012 04:38, Amit Kachhap  wrote:

> Hi Chanwoo Choi,
>
> I remember I found some of those issues when making cross-compiled
> static powertop binaries due to incompatible ncurses database files.
> Then I moved to native compilation of powertop binaries for ARM
> boards. May be this will give you some pointers.
> Anyway I will test with new libcurses library and let you know.
>
> Thanks,
> Amit Daniel
>
>
> On 12 January 2012 17:37, Chanwoo Choi  wrote:
> >
> > Hi Amit,
> >
> > I used linaro powertop to check idle state on embedded board
> > with EXYNOS4 series. I modified Makefile to use -lncurse
> > instead of -lncursew and it was well operated on my board.
> > - kernel : 2.6.36
> > - libncurse : libncurses5-dev
> >
> > But, same powertop binary doesn't work on  new embedded board.
> > When execute powertop, I faced one problem which stop powertop
> > during initialization of ncurse in display.cpp. (init_display function)
> > - kernel : 3.0
> > - libncurse : libncurses5-dev
> > Does anyone have experience about it?
> >
> > Regards,
> > Chanwoo Choi
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Shawn Guo]

On Thu, Jan 12, 2012 at 04:04:23PM -0800, Saravana Kannan wrote:
> While the original clk_hw suggestion was well intentioned, it just
> forces too many unnecessary dereferences and indirection. It also
> prevents static init of some fields as others have mentioned.
> Overall, it made the MSM clock code a mess when I tried to convert
> it to the common clock framework during Linaro Connect Q4 2011.
> 
> The current off-tree MSM clock code uses a very similar approach to
> what the original patches that Jeremy sent out did. When Mike sent
> out the patches that removed clk_hw, the MSM code was much clearer
> and easier to convert to the common clock framework.
> 
I share the same feeling with migrating imx6 clock support to v2 and
v3 of this series.  (v2 uses clk_hw, and v3 removes clk_hw.)

-- 
Regards,
Shawn

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

Re: [PATCH] mmc: use usleep_range() in mmc_delay()

[Aaro Koskinen]

Hi,

On Wed, 21 Dec 2011, Dmitry Antipov wrote:

From f447d78db65c6675e69466e8ed08364ff065ac08 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov 
Date: Wed, 21 Dec 2011 10:51:03 +0400
Subject: [PATCH] mmc: use usleep_range() in mmc_delay()

---


Shouldn't you add a proper patch description and a signed-off-by line?


drivers/mmc/core/core.h |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 14664f1..a77851e 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -47,12 +47,8 @@ void mmc_power_off(struct mmc_host *host);

static inline void mmc_delay(unsigned int ms)
{
-   if (ms < 1000 / HZ) {
-   cond_resched();
-   mdelay(ms);
-   } else {
-   msleep(ms);
-   }
+   unsigned long us = ms * USEC_PER_MSEC;
+   usleep_range(us, us + 1000);
}


Anyway, I think the change is good. On systems with multiple MMC devices
the boot/probe can spend 100-200 ms alone just doing busylooping delays. I
think e.g. in mmc_rescan() the code uses frequently mmc_delay(10).


void mmc_rescan(struct work_struct *work);
--
1.7.7.4


A.

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

Re: [PATCH] mmc: use usleep_range() in mmc_delay()

[Aaro Koskinen]

Hi,

On Fri, 13 Jan 2012, Dmitry Antipov wrote:

On 01/13/2012 05:22 PM, Aaro Koskinen wrote:


Anyway, I think the change is good. On systems with multiple MMC devices
the boot/probe can spend 100-200 ms alone just doing busylooping delays. I
think e.g. in mmc_rescan() the code uses frequently mmc_delay(10).


I'm worrying about this:

mmc_delay(DIV_ROUND_UP(card->ext_csd.sa_timeout, 1))

since I have no ideas about typical values for this timeout.
If it may be too small (<=10 us), using usleep_range() makes no sense.


Hmm, but the code above is rounding it up to at least 1 ms?

A.

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

Re: Finding source code for Linaro kernels

[John Rigby]

On Fri, Jan 13, 2012 at 6:32 AM, Dave Martin  wrote:
> For everyone who packages kernel trees:
>
>
> I've had some questions about getting the source for linaro kernel
> packaged, and it seems that this is still not straightforward:
>
...

This seems reasonable to me.  This month we are adding CI auto
packaging/building for LT kernels so I will add the Vcs-Git setting to
these CI scripts.

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

Re: Finding source code for Linaro kernels

[Dave Martin]

On Fri, Jan 13, 2012 at 3:52 PM, John Rigby  wrote:
> On Fri, Jan 13, 2012 at 6:32 AM, Dave Martin  wrote:
>> For everyone who packages kernel trees:
>>
>>
>> I've had some questions about getting the source for linaro kernel
>> packaged, and it seems that this is still not straightforward:
>>
> ...
>
> This seems reasonable to me.  This month we are adding CI auto
> packaging/building for LT kernels so I will add the Vcs-Git setting to
> these CI scripts.


I think at the moment, we're just pasting it from the vanilla kernel
packaging, which is why we end up with a pointer to the wrong tree
(but that's partly guesswork on my part)

Do you know if the TI packaged kernels already in a tree somewhere?  I
had someone trying to find that specifically.

Cheers
---Dave

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

Re: using cpuidle on panda board

[Andy Green]

On 01/13/2012 08:34 PM, Somebody in the thread at some point said:

(adding AmitK)

Amit, do you know of a good place to raid for better cpuidle, closer to 
upstream than OZ?


-Andy


On 13 January 2012 12:12, Jassi Brar  wrote:

On 13 January 2012 16:13, Andy Green  wrote:

On 01/13/2012 05:59 PM, Somebody in the thread at some point said:


Hi,

I'd like to do some tests with cpuidle on my panda board but i'm
facing some issues:

Originally, i'd like to use the Linaro developer image which uses the
landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver
only works when cpu1 is off whereas i'd like to do some test with both
cpus.
The android kernel has got a cpuidle driver which can enter C-states
when both cpus are running and I was wondering if there is a plan to
merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2
?

Then, when I'm testing the landing-panda-11.12-release android image
on my panda board revA1, the cpuidle is using only C0 state (WFI)
according to cpuidle stats.

My test sequence:
prevent suspend with: echo qwerty>/sys/power/wake_lock
let android enter the early_suspend mode
get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only
state0 time is different from 0

Is it a normal behavior ?



No I think cpuidle is broken with what we have in tilt-3.1.

It's worth trying tilt-tracking which, last time Jassi looked at it was
working and visiting all the C states.


IIRC, CPU_0 entered C1, C2 states only when the CPU_1 is offline, when I tested.


yes, but I need to keep both cpu online for my tests with sched_mc


Vincent, would you remember exactly which android branch has it working with
both cpus online?



I'm using the the compiled baseline :
https://android-build.linaro.org/builds/~linaro-android/landing-panda-11.12-release/#build=3
For this baseline, a cpuidle device is registered for each CPU (0,1)
unlike the tilt tracking which register a device only for cpu0.
This baseline uses an other cpuidle driver for omap4 which manages both CPU

Vincent


Cheers,
Jassi



--
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: Finding source code for Linaro kernels

[John Rigby]

The CI autopackaged TI 3.1 kernels all land here:
https://github.com/jcrigby/packaged-linux-linaro-3.1-ci/commits/lt-omap/

All 3.1 LT and non LT kernel land there in different branches but each
branch gets overwritten with each new merge so you need the tag to
find a particular release.

On Fri, Jan 13, 2012 at 9:50 AM, Dave Martin  wrote:
> On Fri, Jan 13, 2012 at 3:52 PM, John Rigby  wrote:
>> On Fri, Jan 13, 2012 at 6:32 AM, Dave Martin  wrote:
>>> For everyone who packages kernel trees:
>>>
>>>
>>> I've had some questions about getting the source for linaro kernel
>>> packaged, and it seems that this is still not straightforward:
>>>
>> ...
>>
>> This seems reasonable to me.  This month we are adding CI auto
>> packaging/building for LT kernels so I will add the Vcs-Git setting to
>> these CI scripts.
>
>
> I think at the moment, we're just pasting it from the vanilla kernel
> packaging, which is why we end up with a pointer to the wrong tree
> (but that's partly guesswork on my part)
>
> Do you know if the TI packaged kernels already in a tree somewhere?  I
> had someone trying to find that specifically.
>
> Cheers
> ---Dave

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

Re: Finding source code for Linaro kernels

[Zach Pfeffer]

Linaro Android kernels are very easy to find

Browse to:

https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=142

Click on Downloads

You'll see:

http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/source-manifest.xml

and

http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/pinned-manifest.xml

The source-manifest contains:




For the specific commit that got built in our CI loop use the
pinned-manifest.xml:



Just

git clone git://git.linaro.org/landing-teams/working/samsung/kernel

Get the toolchain

wget 
http://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-bzr/141/android-toolchain-eabi-4.6-daily-linux-x86.tar.bz2

tar -jxvf android-toolchain-eabi-4.6-*

Get the config

wget --no-check-certificate
https://android-build.linaro.org/jenkins/job/linaro-android_staging-origen/142/consoleText
or click on Raw

Get the build commands:

cat consoleText | grep ARCH=arm

Fix up the toolchain and bingo!

Amit is putting this all into a per build script, which you'll just
download and run.

Enjoy!

On 13 January 2012 07:32, Dave Martin  wrote:
> For everyone who packages kernel trees:
>
>
> I've had some questions about getting the source for linaro kernel
> packaged, and it seems that this is still not straightforward:
>
> Getting the debian package source (i.e., flat tarball) for a binary
> kernel is possible, but only if it is a non-superseded version.
>
> Working out which source package you need is non-obvious (You have to
> check for installed kernel packages, and guess which source package
> you need, based on that.  Non-linaro folks may not understand the
> difference between the various meta- and real kernel packages and may
> get pretty confused along the way.)
>
> Finding the git tree and the relevant commit to reproduce the source
> (including that for superseded kernels) is hard or impossible.  It
> requires guesswork and/or specific knowledge about the way the
> relevant team manages their trees.  For some platforms, it looks like
> there may be no single tree containing the packaged kernel at all, in
> which case you would also need more guesswork and/or scripts or help
> from the relevant landing team in order actually to reproduce a
> release.
>
> Am I correct in these conclusions?
>
>
> If so, here's a proposal -- I welcome people's comments (and please do
> say if any of these problems are actually solved already!):
>
>
> For every binary kernel package (.deb) publicly released by any linaro
> team, including those produced by the platform team and the landing
> teams:
>
>
> 1) The source package's control file must contain a Vcs-Git entry
>
>
> 2) The Vcs-Git entry must reference a git tree which contains the
> _exact_ source code which appears in the source package.
>
>  * Such a tree must exist and must be publicly readable.  It does not
> have to be on git.linaro.org (though this is the recommended place).
>
>  * Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not
> acceptable, unless that repo is populated with the real source for
> that specific kernel as well as the packaging.
>
>  * Manufacturing the source package from the contents of multiple
> repositories or branches at source package upload time is not
> acceptable, unless the result is also recorded as a tagged commit in
> the repository referenced by the Vcs-Git entry in the debian/control
> file contained in that same commit.  The commit must have full
> history: importing tarballs directly into a repository for the purpose
> of release tagging is not acceptable.
>
>  * Referring to a tree which does not contain the whole contents of
> the debian source package (for example, debian/ and other packaging
> files/dirs are missing) is not acceptable.
>
>
> 3) Tagging of packaged kernels must be done in a standard way.
>
>  * I recommend _, matching the
> Source field of debian/control and the version number of the most
> recent debian/changelog entry respectively (which must both be present
> in the repository as a consequence of (2)).  If we want to avoid
> namespace pollution, we probably want to add a prefix such as debian/
> or ubuntu/ to the tag name to indicate that the tag describes the
> source for a published .deb package.  If so, we must standardise that
> prefix so that it is identical in all out trees.
>
>  * Tree maintainers are of course free to add any other additional
> tags for their own use if they want to.
>
> All teams already do release tagging of some sort, but the lack of
> consistency creates difficulties when anyone from outside the team
> tries to understand that team's trees.
>
>  * We _could_ standardise the following, but it is not essential:
>
>    * ubuntu/: The tagged source for the _original_ kernel
> which was distributed in  (where  is a linaro
> monthly release such as 11.12 or 12.01)
>
>
> 4) No specific branch naming requirements exist.
>
>  * Release tags do not necessarily need to appear on any bran

Re: using cpuidle on panda board

[Dechesne, Nicolas]

On Fri, Jan 13, 2012 at 5:59 PM, Andy Green  wrote:

> Amit, do you know of a good place to raid for better cpuidle, closer to
> upstream than OZ?


wasn't that merged in 3.2? are you looking for that :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V6 4/7] cpufreq: add clk-reg cpufreq driver

[Cousson, Benoit]

On 1/12/2012 11:52 PM, Kevin Hilman wrote:

Richard Zhao  writes:


[...]


Do you have real case to need different voltage/clk?


Sure, any system with independently scalable CPUs/clusters.


AFAIK, in the ARM SoC world there is a least the MSM8660 that does 
support that today.


Regards,
Benoit

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

Re: Finding source code for Linaro kernels

[Dave Martin]

I was specifically after solving the problem for the debianised
kernels.  Android is an analogous but completely separate problem --
if you already have a solution there then great.

> https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=142

I assume people can tell from their deliverables which build to go to?
 Is the URL obvious / guessable?

Otherwise, it looks like all the needed info is there, though you're
right that scripting could make it more convenient to access.

Cheers
---Dave

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

Re: Finding source code for Linaro kernels

[Zach Pfeffer]

On 13 January 2012 11:36, Dave Martin  wrote:
> I was specifically after solving the problem for the debianised
> kernels.  Android is an analogous but completely separate problem --
> if you already have a solution there then great.
>
>> https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=142
>
> I assume people can tell from their deliverables which build to go to?
>  Is the URL obvious / guessable?

Its not obvious, but we're going to change that. Right now people have to ask.

> Otherwise, it looks like all the needed info is there, though you're
> right that scripting could make it more convenient to access.
>
> Cheers
> ---Dave



-- 
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: Finding source code for Linaro kernels

[Dave Martin]

On Fri, Jan 13, 2012 at 5:42 PM, Zach Pfeffer  wrote:
> On 13 January 2012 11:36, Dave Martin  wrote:
>> I was specifically after solving the problem for the debianised
>> kernels.  Android is an analogous but completely separate problem --
>> if you already have a solution there then great.
>>
>>> https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=142
>>
>> I assume people can tell from their deliverables which build to go to?
>>  Is the URL obvious / guessable?
>
> Its not obvious, but we're going to change that. Right now people have to ask.

Cool; I guess once that's sorted it should work.

---Dave

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

Re: using cpuidle on panda board

[Jassi Brar]

On 13 January 2012 22:44, Dechesne, Nicolas  wrote:
>
>
> On Fri, Jan 13, 2012 at 5:59 PM, Andy Green  wrote:
>>
>> Amit, do you know of a good place to raid for better cpuidle, closer to
>> upstream than OZ?
>
> wasn't that merged in 3.2? are you looking for that :
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266
>
We have this already.
AIUI, Vincent wants CPU0 to switch between C1-2-3 even when CPU1 is online
and apparently he has seen it possible (with the android link he provided).

-j

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

[Activity] Kernel WG Weekly Status report for week ending 2012-01-13

[Mounir Bsaibes]

Enclosed  please find the link to the Weekly Status & Individual Activity
reports
for the kernel  working group for the week ending 2012-01-13

== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2012-01-12

== Individual Activity Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2012-01-06

== Summary ==
(For more details, please see the Status report or the  Individual Activity
report above)

* Sub-teams
   The KWG has re-organized into sub-teams, links to the teams' pages
(which are still under construction)
   can be reached from https://wiki.linaro.org/WorkingGroups/Kernel.

* Kernel Release
   Andrey Konvalov is handling the Linaro baseline kernel release from now
on.
   He has a tracking branch setup
(http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git)
   that is currently on 3.2 and has a number of 3.3 patches he will be
merging for the 12.01 release
   including updates to DT, sched_mc, and pinmux. Expect a kernel release
on Jan 19th.

* Pinctrl
 * Linusw sent a pull request for the top of the pinctrl branch that has
matured in linux-next to Torvalds
 * PXA is very mature and was merged on top of LinusW devel branch, but did
not make it into this merge window.
 * Work on pinctrl binding  to DT  is progressing, extensive discussions on
how to add DT binding for pinctrl drivers.

* Device Tree
 * Submitted patch for a new lcd power control driver with device tree
support.
 * Submitted device tree support patch for generic power domains.
 * Submitted device tree support patch for Samsung display controller.
 * Reviewed imx pinctrl patch series from Aisheng, and had some extensive
discussion on
   how we should add DT binding for pinctrl drivers.

* Android
 * Planning to submit patch queue that adds an android alarmtimer driver,
which is
   mended to use the upstreamed alarmtimer code, to staging,
 * Submitted talk on Android kernel patch status for ELC
 * Sent a few iterations of the patches to evdev to allow monotonic
timestamps to be used (required for ICS).

* imx  maintenance
  * Collected a number of imx tty/serial patches and sent them to Greg for
3.3 merge window.
  * Collected a couple of imx6 PM fixup patches from Eric Miao
  * Reviewed a number of imx6  related patches
  * Sent the clk-prepare series to fix mutex locking issue while moving,
one step towards common-clk frame work
  * Sent a patch to use CHIPID register to detect soc between imx23 andimx28
  * Tested the patch from Fabio Estevam adding audio support intomxs_defconfig

Best regards,
Mounir

-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
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

[PATCH] ARM: pl330: fix null pointer dereference in pl330_chan_ctrl()

[Mans Rullgard]

This fixes the thrd->req_running field being accessed before thrd
is checked for null.  The error was introduced in abb959f.

Signed-off-by: Mans Rullgard 
---
 drivers/dma/pl330.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 3a6e042..cb3e597 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1568,12 +1568,13 @@ static int pl330_chan_ctrl(void *ch_id, enum 
pl330_chan_op op)
struct pl330_thread *thrd = ch_id;
struct pl330_dmac *pl330;
unsigned long flags;
-   int ret = 0, active = thrd->req_running;
+   int ret = 0, active;
 
if (!thrd || thrd->free || thrd->dmac->state == DYING)
return -EINVAL;
 
pl330 = thrd->dmac;
+   active = thrd->req_running;
 
spin_lock_irqsave(&pl330->lock, flags);
 
-- 
1.7.8.3


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

[Activity] Power Management WG Weekly Status report for week ending 2012-01-13

[Mounir Bsaibes]

Enclosed  please find the link to the  Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2012-01-13


== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2012-01-12

== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2012-01-11


== Summary ==
(For details, see the Weekly Status Report and Meeting Minutes )


 * Scheduler mini-summit
   * Setting for a scheduler mini-summit at Connet,  Paul McKenney and
Vincent Guittot will moderate.

 * Thermal Driver
   * Rob submitted the thermal driver patch for i.MX6 Freescale. Based on
feedback, he will fix and make more extensive tests on the next submission.
   * Amit Daniel working on use the temperature information in thermal
layer to generate some useful  information like temperature drop per
cooling state. Amit has submitted proposal for thermal framework discussion
in ELC.

 * Cpuidle
   * Daniel is moving cpuilde drivers to drivers directory, he discussed
this with Russel and Arnd and agreed on how to do it.
   * Current major area of work on cpuidle
 * Moving all cpuidle drivers from sub-arch directory to driver
directory
 * Cleaning up Arm cpuidle and make a generic common cpuidle driver
framework, so all platforms can use it.
 * Rob/Daniel working on moving i.mx and st-e cpuidle drivers to use
the new common cpuidle.



Best regards,
Mounir

-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
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: using cpuidle on panda board

[Amit Kucheria]

On Fri, Jan 13, 2012 at 7:14 PM, Dechesne, Nicolas  wrote:
>
>
> On Fri, Jan 13, 2012 at 5:59 PM, Andy Green  wrote:
>>
>> Amit, do you know of a good place to raid for better cpuidle, closer to
>> upstream than OZ?
>
>
> wasn't that merged in 3.2? are you looking for that :
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266

What was merged depends on hotplug, it isn't SMP cpuidle. At this
point, I'm quite confused about the history on what happened to the
SMP cpuidle driver and why it wasn't merged. Mike or Kevin should
know.

/Amit

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

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Turquette, Mike]

On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan  wrote:
> On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
>>
>> On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
>>>
>>> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner
>>>  wrote:

 On Tue, 13 Dec 2011, Mike Turquette wrote:
>
> +void __clk_unprepare(struct clk *clk)
> +{
> +     if (!clk)
> +             return;
> +
> +     if (WARN_ON(clk->prepare_count == 0))
> +             return;
> +
> +     if (--clk->prepare_count>  0)
> +             return;
> +
> +     WARN_ON(clk->enable_count>  0);


 So this leaves the clock enable count set. I'm a bit wary about
 that. Shouldn't it either return (including bumping the prepare_count
 again) or call clk_disable() ?
>>
>>
>> No it should not.
>>
>>> I've hit this in my port of OMAP.  It comes from this simple situation:
>>>
>>> driver 1 (adapted for clk_prepare/clk_unprepare):
>>> clk_prepare(clk);
>>> clk_enable(clk);
>>>
>>> ...
>>>
>>> driver2 (not adapted for clk_prepare/clk_unprepare):
>>> clk_enable(clk);
>>
>>
>> So this is basically buggy.  Look, it's quite simple.  Convert _all_
>> your drivers to clk_prepare/clk_unprepare _before_ you start switching
>> your platform to use these new functions.  You can do that _today_
>> without exception.
>>
>> We must refuse to merge _any_ user which does this the old way - and
>> we should have been doing this since my commit was merged into mainline
>> to allow drivers to be converted.
>>
>> And stop trying to think of ways around this inside clk_prepare/
>> clk_unprepare/clk_enable/clk_disable.  You can't do it.  Just fix _all_
>> the drivers.  Now.  Before you start implementing
>> clk_prepare/clk_unprepare.
>
>
> I agree with Russell's suggestion. This is what I'm trying to do with the
> MSM platform. Not sure if I'm too optimistic, but as of today, I'm still
> optimistic I can push the MSM driver devs to get this done before we enable
> real prepare/unprepare support.

Just to reach closure on this topic: I don't plan to change
__clk_unprepare in the next version of the patches.  The warnings are
doing a fine job of catching code which has yet to be properly
converted to use clk_(un)prepare.

Mike

>
>
> Thanks,
> Saravana
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

Re: using cpuidle on panda board

[Mike Turquette]

On Fri, Jan 13, 2012 at 2:41 PM, Amit Kucheria  wrote:
> On Fri, Jan 13, 2012 at 7:14 PM, Dechesne, Nicolas  wrote:
>>
>>
>> On Fri, Jan 13, 2012 at 5:59 PM, Andy Green  wrote:
>>>
>>> Amit, do you know of a good place to raid for better cpuidle, closer to
>>> upstream than OZ?
>>
>>
>> wasn't that merged in 3.2? are you looking for that :
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266
>
> What was merged depends on hotplug, it isn't SMP cpuidle. At this
> point, I'm quite confused about the history on what happened to the
> SMP cpuidle driver and why it wasn't merged. Mike or Kevin should
> know.

Amit is correct.  The hotplug-dependent cpuidle got merged.

The SMP CPUidle patches have been put on the list and should work
patch into a recent kernel:
http://article.gmane.org/gmane.linux.ports.tegra/2649

However the OMAP4 support seems to be missing:
http://article.gmane.org/gmane.linux.ports.arm.omap/69186

So this isn't straightforward, but at least it's headed in the right direction.

Regards,
Mike

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

Re: using cpuidle on panda board

[Andy Green]

On 01/14/2012 12:52 PM, Somebody in the thread at some point said:

On Fri, Jan 13, 2012 at 2:41 PM, Amit Kucheria  wrote:

On Fri, Jan 13, 2012 at 7:14 PM, Dechesne, Nicolas  wrote:



On Fri, Jan 13, 2012 at 5:59 PM, Andy Green  wrote:


Amit, do you know of a good place to raid for better cpuidle, closer to
upstream than OZ?



wasn't that merged in 3.2? are you looking for that :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266


What was merged depends on hotplug, it isn't SMP cpuidle. At this
point, I'm quite confused about the history on what happened to the
SMP cpuidle driver and why it wasn't merged. Mike or Kevin should
know.


Amit is correct.  The hotplug-dependent cpuidle got merged.

The SMP CPUidle patches have been put on the list and should work
patch into a recent kernel:
http://article.gmane.org/gmane.linux.ports.tegra/2649

However the OMAP4 support seems to be missing:
http://article.gmane.org/gmane.linux.ports.arm.omap/69186

So this isn't straightforward, but at least it's headed in the right direction.


Thanks for the info... it sounds like we should try to add the SMP 
CPUidle from upstream and ask Santosh for his patches and see what happens.


Unfortunately we've been trying to use Andrey's new 
linux-linaro-tracking as a basis and despite fixing some of the problems 
the resulting tree still blows chunks midway through boot.  So I think 
we'll have to give up on that for now and retry later.


-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