[PATCH 2/3] ARM: EXYNOS: Removed code for setting clock rate of xusbxti

[Pankaj Dubey]

Since now xusbxti clock's default rate is set in clock.c file,
there is no need to set it again in the machine file.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-exynos/mach-nuri.c |1 -
 arch/arm/mach-exynos/mach-origen.c   |1 -
 arch/arm/mach-exynos/mach-smdk4x12.c |2 --
 arch/arm/mach-exynos/mach-smdkv310.c |1 -
 4 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 236bbe1..d9196b8 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1314,7 +1314,6 @@ static void __init nuri_machine_init(void)
nuri_camera_init();
 
nuri_ehci_init();
-   clk_xusbxti.rate = 2400;
 
/* Last */
platform_add_devices(nuri_devices, ARRAY_SIZE(nuri_devices));
diff --git a/arch/arm/mach-exynos/mach-origen.c 
b/arch/arm/mach-exynos/mach-origen.c
index f56d027..4700456 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -702,7 +702,6 @@ static void __init origen_machine_init(void)
s3c_sdhci0_set_platdata(&origen_hsmmc0_pdata);
 
origen_ehci_init();
-   clk_xusbxti.rate = 2400;
 
s5p_tv_setup();
s5p_i2c_hdmiphy_set_platdata(NULL);
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c 
b/arch/arm/mach-exynos/mach-smdk4x12.c
index fcf2e0e..35b86ea 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -247,8 +247,6 @@ static struct platform_device *smdk4x12_devices[] 
__initdata = {
 
 static void __init smdk4x12_map_io(void)
 {
-   clk_xusbxti.rate = 2400;
-
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
s3c24xx_init_clocks(clk_xusbxti.rate);
s3c24xx_init_uarts(smdk4x12_uartcfgs, ARRAY_SIZE(smdk4x12_uartcfgs));
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c 
b/arch/arm/mach-exynos/mach-smdkv310.c
index cec2afa..c7fb82f 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -363,7 +363,6 @@ static void __init smdkv310_machine_init(void)
s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
 
smdkv310_ehci_init();
-   clk_xusbxti.rate = 2400;
 
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
-- 
1.7.4.1


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

[PATCH 0/3] Moving xusbxti clock setting in clock.c file.

[Pankaj Dubey]

Since there is code duplication in different mach-board.c file it is better
to set default clock rate of xusbxti clock in plat-s5p/clock.c file.

The patches are based on following commit on Kukjin's for-next branch.

Pankaj (1):
  ARM: S5P: Set default rate of xusbxti clock

Pankaj Dubey (2):
  ARM: EXYNOS: Removed code for setting clock rate of xusbxti
  ARM: S5PV210: Removed code for setting clock rate of xusbxti

 arch/arm/mach-exynos/mach-nuri.c |1 -
 arch/arm/mach-exynos/mach-origen.c   |1 -
 arch/arm/mach-exynos/mach-smdk4x12.c |2 --
 arch/arm/mach-exynos/mach-smdkv310.c |1 -
 arch/arm/mach-s5pv210/mach-goni.c|1 -
 arch/arm/plat-s5p/clock.c|1 +
 6 files changed, 1 insertions(+), 6 deletions(-)

-- 
1.7.4.1


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

[PATCH 1/3] ARM: S5P: Set default rate of xusbxti clock

[Pankaj Dubey]

From: Pankaj 

Initialize xusbxti clock's default value here.
So that code duplication in all other mach-board.c can be avoided.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/plat-s5p/clock.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-s5p/clock.c b/arch/arm/plat-s5p/clock.c
index 5f84a3f..6fb9049 100644
--- a/arch/arm/plat-s5p/clock.c
+++ b/arch/arm/plat-s5p/clock.c
@@ -38,6 +38,7 @@ struct clk clk_ext_xtal_mux = {
 struct clk clk_xusbxti = {
.name   = "xusbxti",
.id = -1,
+   .rate   = 2400,
 };
 
 struct clk s5p_clk_27m = {
-- 
1.7.4.1


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

[PATCH 3/3] ARM: S5PV210: Removed code for setting clock rate of xusbxti

[Pankaj Dubey]

Since now xusbxti clock's default rate is set in clock.c file,
there is no need to set it again in the machine file.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-s5pv210/mach-goni.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
b/arch/arm/mach-s5pv210/mach-goni.c
index 15edcae..02d31f4 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -947,7 +947,6 @@ static void __init goni_machine_init(void)
/* KEYPAD */
samsung_keypad_set_platdata(&keypad_data);
 
-   clk_xusbxti.rate = 2400;
 
platform_add_devices(goni_devices, ARRAY_SIZE(goni_devices));
 }
-- 
1.7.4.1


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

Re: linux-next not booting on snowball

[Nicolas Pitre]

On Fri, 2 Dec 2011, Daniel Lezcano wrote:

> On 12/01/2011 08:03 PM, Nicolas Pitre wrote:
> > Please have a look at this email:
> > 
> > http://article.gmane.org/gmane.linux.ports.arm.kernel/141386
> > 
> > There are two patches in there which should help you get some debugging 
> > info out.
> 
> 
> Thanks Nicolas,
> 
> I have applied the patches and I get:
> 
> -
> 
> <6>Booting Linux on physical CPU 0
> <6>Initializing cgroup subsys cpuset
> <6>Initializing cgroup subsys cpu
> <5>Linux version 3.2.0-rc2+ (dlezcano@monster) (gcc version 4.3.2
> (Debian 4.3.2-1.1) ) #7 SMP PREEMPT Thu Dec 1 2
> 3:58:34 CET 2011
> CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387f
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: Calao Systems Snowball platform
> <4>Ignoring unrecognised tag 0x41000403
> Memory policy: ECC disabled, Data cache writealloc
> 
> -
> 
> I am not able to understand these informations, I hope they can help to
> understand the problem.
> 
> Is there something else I can do to help ?

Yes.  Either you have access to a fancy debugger and then you could 
trace what happens from the moment devicemaps_init() is entered.

Or, using the good old way, just insert a couple of

printk("%s:%s line %d\n", __FILE__, __func__, __LINE__);

in a couple places (still with the 2 earlier patches applied).  Good 
locations for those traces would be:

 - Upon entering devicemaps_init() to confirm it makes that far.

 - Just before and right after the call to mdesc->map_io(), still in 
   devicemaps_init().

 - If you don't see the trace after mdesc->map_io(), then the problem is
   most likely in u8500_map_io(), in which case you should add more 
   traces in there to narrow the problem area down to the problematic
   call.


Nicolas

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

Re: Proposal : New Linaro Desktop Wallpaper

[Jesse Barker]

Works for me.  Nice job, Tom!

cheers,
Jesse

On Thu, Dec 1, 2011 at 2:56 PM, Tom Gall  wrote:
> Hi All,
>
> one of the blueprints we have for 11.12 is to modify the LEB/ALIP
> images so they include more linaro branding. A linaro wallpaper, maybe
> a linaro image as the system is booting, that kind of thing.
>
> Towards that end (and given that time is short if this is to make
> 11.12)  I'd like to propose the following graphic be our new wallpaper
> image. This would be the image displayed in the background on a
> graphical desktop by default.
>
> I created it in gimp.
>
> http://people.linaro.org/~tgall/LinaroDesktop-1920x1080-1.png
>
> Thoughts? Concerns? Feedback?
>
> --
> Regards,
> Tom
>
> "Where's the kaboom!? There was supposed to be an earth-shattering
> kaboom!" Marvin Martian
> Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
> w) tom.gall att linaro.org
> w) tom_gall att vnet.ibm.com
> h) tom_gall att mac.com
>
> ___
> 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 v3 3/5] clk: introduce the common clock framework

[Paul Walmsley]

Hi Mark,

On Thu, 1 Dec 2011, Mark Brown wrote:

> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
> 
> > Clock rate/parent-change notifiers are requirements for DVFS use-cases, 
> > and they must be paired with something like the 
> > clk_{allow,block}_rate_change() functions to work efficiently.  I intend 
> > to comment on this later; it's not a simple problem.  It might be worth 
> > noting that Tero and I implemented a simplified version of this for the 
> > N900.
> 
> I'm thinking that if we're going to have clk_{allow,block}_rate_change()
> we may as well make that the main interface to enable rate changes - if
> a device wants to change the clock rate it allows rate changes using
> that interface rather than by disabling the clocks.  I've got devices
> which can do glitch free updates of active clocks so having to disable
> would be a real restriction, and cpufreq would have issues with actually
> disabling the clock too I expect.

The intention behind the clk_{allow,block}_rate_change() proposal was to 
allow the current user of the clock to change its rate without having to 
call clk_{allow,block}_rate_change(), if that driver was the sole user of 
the clock.

So for example, if you had a driver that did:

c = clk_get(dev, clk_name);
clk_enable(c);
clk_set_rate(c, clk_rate);

and c was currently not enabled by any other driver on the system, and 
nothing else had called clk_block_rate_change(c), then the rate change 
would be allowed to proceed.  (modulo any notifier activity, etc.)  

So clk_{allow,block}_rate_change() was simply intended to allow or 
restrict other users of the same clock, not the current user.


- Paul

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

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Ian Campbell]

On Thu, 2011-12-01 at 15:10 +, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 10:26:37AM +, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 18:32 +, Stefano Stabellini wrote:
> > > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > > KVM and Xen at least both fall into the single-return-value category,
> > > > so we should be able to agree on a calling conventions. KVM does not
> > > > have an hcall API on ARM yet, and I see no reason not to use the
> > > > same implementation that you have in the Xen guest.
> > > > 
> > > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > > file into a common asm/hypercall.h and submit it for review to the
> > > > arm kernel list?
> > > 
> > > Sure, I can do that.
> > > Usually the hypercall calling convention is very hypervisor specific,
> > > but if it turns out that we have the same requirements I happy to design
> > > a common interface.
> > 
> > I expect the only real decision to be made is hypercall page vs. raw hvc
> > instruction.
> > 
> > The page was useful on x86 where there is a variety of instructions
> > which could be used (at least for PV there was systenter/syscall/int, I
> > think vmcall instruction differs between AMD and Intel also) and gives
> > some additional flexibility. It's hard to predict but I don't think I'd
> > expect that to be necessary on ARM.
> > 
> > Another reason for having a hypercall page instead of a raw instruction
> > might be wanting to support 32 bit guests (from ~today) on a 64 bit
> > hypervisor in the future and perhaps needing to do some shimming/arg
> > translation. It would be better to aim for having the interface just be
> > 32/64 agnostic but mistakes do happen.
> 
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor.

The issue I was thinking about was struct packing for arguments passed
as pointers etc rather than the argument registers themselves. Since the
preference appears to be for raw hvc we should just be careful that they
are agnostic in these.

Ian.

>  We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.
> 
> I'm not closely involved with any of the Xen or KVM work but I would
> vote for using HVC than a hypercall page.
> 



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

Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Ian Campbell]

On Wed, 2011-11-30 at 18:15 +, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> > 
> > That's along the lines of what I was thinking as well.
> > 
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
> 
> Yes.
> 
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
> 
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
> 
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.

Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.

Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.

> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.

We were absolutely banking on targeting the results of this work, so
that's good ;-)

Ian.



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

Re: [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Ian Campbell]

On Wed, 2011-11-30 at 18:32 +, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:

> 
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> > 
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
> 
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.

I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.

The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.

Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.

Ian.


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

Re: linux-next not booting on snowball

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2011 08:03 PM, Nicolas Pitre wrote:
> On Thu, 1 Dec 2011, Daniel Lezcano wrote:
> 
>> On 12/01/2011 03:58 PM, Mark Brown wrote:
>>> On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
>>>
 commit 549158d2ab01e8370d2773044fe09738a26f7086
 Author: Nicolas Pitre 
 Date:   Thu Aug 25 00:35:59 2011 -0400
>>>
 ARM: move iotable mappings within the vmalloc region

>>>
>>> I recently reported an issue with this patch on s3c64xx which I'm
>>> avoiding with the below change, I believe Nicolas folded this in to his
>>> code but it's not propagated into -next yet.
>>>
> [...]
>>
>> Thanks for the patch Mark. I applied it and tried to boot but the kernel
>> is still stuck on the same place :(
> 
> Please have a look at this email:
> 
> http://article.gmane.org/gmane.linux.ports.arm.kernel/141386
> 
> There are two patches in there which should help you get some debugging 
> info out.


Thanks Nicolas,

I have applied the patches and I get:

- -

<6>Booting Linux on physical CPU 0
<6>Initializing cgroup subsys cpuset
<6>Initializing cgroup subsys cpu
<5>Linux version 3.2.0-rc2+ (dlezcano@monster) (gcc version 4.3.2
(Debian 4.3.2-1.1) ) #7 SMP PREEMPT Thu Dec 1 2
3:58:34 CET 2011
CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387f
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Calao Systems Snowball platform
<4>Ignoring unrecognised tag 0x41000403
Memory policy: ECC disabled, Data cache writealloc

- -

I am not able to understand these informations, I hope they can help to
understand the problem.

Is there something else I can do to help ?

Thanks
  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

iQEcBAEBAgAGBQJO2Ah/AAoJEAKBbMCpUGYAef0H/2eV0xJKDtt1sQDOEDqKx3HS
dOK4p//Q7niWVWXl2JXC3x39qBRHg4SDf/jc5nFmUBjbOZQDsiwGujQ9B0bI3yMR
Ozm5Uirv8L1jMdfhzDJQAG5OqFzOoNCX2RE9bYrrKssUb6z1QCPYi0HgGo8Wf4KL
N2T+naSZb1Pe/tIj9A7FK7HC/hjoMwBpdKXfM2IG6QT2sTo3BmTTrkuY8OD6avJ9
V1sWV2pX4oxp4RNOZVqkr6A8Lpcjy/x3GYe3vLVFuXkBTbFhhDRnaXSezCKNrx0X
bMlNXBt8lrqB37ifW61ISww9ec9b6jViXYs1ksByIdeIJPQ0dJPgGbRPrJORp40=
=d9/Y
-END PGP SIGNATURE-

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

Proposal : New Linaro Desktop Wallpaper

[Tom Gall]

Hi All,

one of the blueprints we have for 11.12 is to modify the LEB/ALIP
images so they include more linaro branding. A linaro wallpaper, maybe
a linaro image as the system is booting, that kind of thing.

Towards that end (and given that time is short if this is to make
11.12)  I'd like to propose the following graphic be our new wallpaper
image. This would be the image displayed in the background on a
graphical desktop by default.

I created it in gimp.

http://people.linaro.org/~tgall/LinaroDesktop-1920x1080-1.png

Thoughts? Concerns? Feedback?

-- 
Regards,
Tom

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Russell King - ARM Linux]

On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> The intention behind the clk_{allow,block}_rate_change() proposal was to 
> allow the current user of the clock to change its rate without having to 
> call clk_{allow,block}_rate_change(), if that driver was the sole user of 
> the clock.

And how does a driver know that?

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

Re: [EOL] Request for End Of Life - Beagleboard and Beagleboard-xM

[Peter Maydell]

On 1 December 2011 19:14, David Zinman  wrote:
> A request has been received to discontinue Linaro's support for the
> Beagleboard and Beagleboard-xM hardware.

This raises the question of what effect this should have on what
we do with the Beagleboard models in Linaro QEMU, since we don't
have a Panda model that we would move over to as our supported
model. Since this is the first EOL for a board we model, I don't
think we've thought about this before.

Here's my initial suggestion:
 * we will continue to hold the omap3/beagle qemu patches in
   qemu-linaro. We may try to get bits of them upstream in our
   copious free time but not as a priority.
 * users are welcome to report beagle related model bugs in
   launchpad but we won't spend any official effort on fixing them
 * beagle model will no longer be an obligatory part of qemu-linaro
   release testing

Does that seem reasonable or would another approach be better?

(OMAP3/Beagle model maintenance is at a very low priority anyway
so it wouldn't be a major change to go to "officially not working
on it". Actually dropping the OMAP3 patchset from qemu-linaro
would be a more abrupt change of direction.)

-- Peter Maydell

___
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 2011-12-02

[Mounir Bsaibes]

Enclosed  please find the link to the  Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2011-12-02


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

== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-11-1


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

 * Roadmap cards reviewed and made ready, the ones that will be delivered
this quarter are:
   *
https://linaro-public.papyrs.com/public/4136/PMWG2011-THERMAL-MANAGEMENT/
   * https://linaro-public.papyrs.com/public/4111/PMWG2011-COMMON-CLK

 To see  Linaro Roadmap
http://linaro.kanbantool.com/public_view-9487de29a82f2.html

 * Thermal Management:
   * Integrated the hwmon based mainline tmu sensor in the generic thermal
interface. Added necessary function to export the temp data. Added the
functionality to tie trip information to a cooling
level. Will upstream it shortly.
   * Updated the thermal wiki page with shortcomings of existing
framework
https://wiki.linaro.org/WorkingGroups/PowerManagement/Specs/ThermalArchitecture

 * Cpuidle:
*  Did a simple driver for the snowball on top of linux-next with WIFI
* Investigating a problem with tickless (NO_HZ) happening on linux-next
* Submitted V3 of the exynos4 cpuidle patches and following it up in
mainline.

 * Common Clock Struct
* Submitted  Common clock patches V3.  The  common code was ported to
the Freescale IMX  platform


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

[EOL] Request for End Of Life - Beagleboard and Beagleboard-xM

[David Zinman]

A request has been received to discontinue Linaro's support for the
Beagleboard and Beagleboard-xM hardware.

The following conditions will be applied for the 2012.01 release cycle:
 * There will be no more LEB or Linaro Developer builds.
 * No more testing will be applied by Linaro to the boards at all,
   and no quality assurance will be performed.
 * No more bugs will be filed against these boards assigned to
   Linaro resources.
 * All currently filed bugs will be re-targeted to the appropriate
   community resource.
 * Landing team support is no longer needed or expected.
 * Linaro Release notes will no longer refer to Beagleboard.

-- 
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs

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

Re: linux-next not booting on snowball

[Nicolas Pitre]

On Thu, 1 Dec 2011, Daniel Lezcano wrote:

> On 12/01/2011 03:58 PM, Mark Brown wrote:
> > On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
> > 
> >> commit 549158d2ab01e8370d2773044fe09738a26f7086
> >> Author: Nicolas Pitre 
> >> Date:   Thu Aug 25 00:35:59 2011 -0400
> > 
> >> ARM: move iotable mappings within the vmalloc region
> >>
> > 
> > I recently reported an issue with this patch on s3c64xx which I'm
> > avoiding with the below change, I believe Nicolas folded this in to his
> > code but it's not propagated into -next yet.
> > 
[...]
> 
> Thanks for the patch Mark. I applied it and tried to boot but the kernel
> is still stuck on the same place :(

Please have a look at this email:

http://article.gmane.org/gmane.linux.ports.arm.kernel/141386

There are two patches in there which should help you get some debugging 
info out.


Nicolas

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

Weird, weird Linux on ARM, a LinuxCon presentation

[Christian Robottom Reis]

I did a presentation this November at LinuxCon Brazil called "The
Wierd World of Linux on ARM (featuring Android)":

https://events.linuxfoundation.org/events/linuxcon-brasil/programacao

I thought the slides might be interesting, so I posted them here:

https://wiki.linaro.org/ChristianReis

Linus didn't ask me any questions, so your comments are even more
welcome than usual. Thanks!
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Mark Brown]

On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:

> So for example, if you had a driver that did:

> c = clk_get(dev, clk_name);
> clk_enable(c);
> clk_set_rate(c, clk_rate);

> and c was currently not enabled by any other driver on the system, and 
> nothing else had called clk_block_rate_change(c), then the rate change 
> would be allowed to proceed.  (modulo any notifier activity, etc.)  

> So clk_{allow,block}_rate_change() was simply intended to allow or 
> restrict other users of the same clock, not the current user.

Ah, sorry!  I'd totally misunderstood what you were proposing.

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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Turquette, Mike]

On Thu, Dec 1, 2011 at 6:42 AM, Mark Brown
 wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
>> Clock rate/parent-change notifiers are requirements for DVFS use-cases,
>> and they must be paired with something like the
>> clk_{allow,block}_rate_change() functions to work efficiently.  I intend
>> to comment on this later; it's not a simple problem.  It might be worth
>> noting that Tero and I implemented a simplified version of this for the
>> N900.
>
> I'm thinking that if we're going to have clk_{allow,block}_rate_change()
> we may as well make that the main interface to enable rate changes - if
> a device wants to change the clock rate it allows rate changes using
> that interface rather than by disabling the clocks.  I've got devices
> which can do glitch free updates of active clocks so having to disable
> would be a real restriction, and cpufreq would have issues with actually
> disabling the clock too I expect.
>

I agree that imposing a "disable clk before changing rate" policy in
the framework core is a bad idea.  During discussion on the
CLK_GATE_SET_RATE flag in the patch #2 Shawn commented that he has
some clks that must be enabled to change their rates (I assume he
means PLLs but that detail doesn't really matter).

Regards,
Mike

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

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Catalin Marinas]

On Thu, Dec 01, 2011 at 04:44:40PM +, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > On Thu, Dec 01, 2011 at 03:42:19PM +, Arnd Bergmann wrote:
> > > On Thursday 01 December 2011, Catalin Marinas wrote:
> > > How do you deal with signed integer arguments passed into SVC or HVC from
> > > a caller? If I understand the architecture correctly, the upper
> > > halves of the argument register end up zero-padded, while the callee
> > > expects sign-extension.
> > 
> > If you treat it as an "int" (32-bit) and function prototype defined
> > accordingly, then the generated code only accesses it as a W (rather
> > than X) register and the top 32-bit part is ignored (no need for
> > sign-extension). If it is defined as a "long" in the 32-bit world, then
> > it indeed needs explicit conversion given the different sizes for long
> > (for example sys_lseek, the second argument is a 'long' and we do
> > explicit sign extension in the wrapper).
...
> What about unsigned long and pointer? Can we always rely on the upper
> half of the register to be zero-filled when we get an exception from 32
> bit into 64 bit state, or do we also have to zero-extend those?

They are also fine, no need for zero-extension.

-- 
Catalin

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

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Arnd Bergmann]

On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +, Arnd Bergmann wrote:
> > On Thursday 01 December 2011, Catalin Marinas wrote:
> > How do you deal with signed integer arguments passed into SVC or HVC from
> > a caller? If I understand the architecture correctly, the upper
> > halves of the argument register end up zero-padded, while the callee
> > expects sign-extension.
> 
> If you treat it as an "int" (32-bit) and function prototype defined
> accordingly, then the generated code only accesses it as a W (rather
> than X) register and the top 32-bit part is ignored (no need for
> sign-extension). If it is defined as a "long" in the 32-bit world, then
> it indeed needs explicit conversion given the different sizes for long
> (for example sys_lseek, the second argument is a 'long' and we do
> explicit sign extension in the wrapper).

Ok, so it's actually different from most other 64 bit architectures, which
normally operate on 64-bit registers and expect the caller to do the
correct sign-extension.

Doing the sign-extension for long arguments then falls into the same
category as long long and unsigned long long arguments, which also need
a wrapper, as you mentioned. Strictly speaking, we only need to do it
for those where the long argument has a meaning outside of the 0..2^31
range, e.g. io_submit can only take small positive numbers although
the type is 'long'.

What about unsigned long and pointer? Can we always rely on the upper
half of the register to be zero-filled when we get an exception from 32
bit into 64 bit state, or do we also have to zero-extend those?

Arnd

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

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Catalin Marinas]

On Thu, Dec 01, 2011 at 03:42:19PM +, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > Given the way register banking is done on AArch64, issuing an HVC on a
> > 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> > have a similar implementation at the SVC level (for 32-bit user apps on
> > a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> > 64-bit parameter in two separate 32-bit registers, so packing needs to
> > be done in a syscall wrapper.
> 
> How do you deal with signed integer arguments passed into SVC or HVC from
> a caller? If I understand the architecture correctly, the upper
> halves of the argument register end up zero-padded, while the callee
> expects sign-extension.

If you treat it as an "int" (32-bit) and function prototype defined
accordingly, then the generated code only accesses it as a W (rather
than X) register and the top 32-bit part is ignored (no need for
sign-extension). If it is defined as a "long" in the 32-bit world, then
it indeed needs explicit conversion given the different sizes for long
(for example sys_lseek, the second argument is a 'long' and we do
explicit sign extension in the wrapper).

-- 
Catalin

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

Android Build seeded builds report

[Paul Sokolovsky]

Hello,

We launched "seeded" builds on Linaro Android Build System
(https://android-build.linaro.org) more than a week ago with the aim to
improve build performance and stability, following Android ICS import
which overloaded our previous build infrastructure, and looking forward
into making Android RC preparation to be comfortable instead of
stressful it became due to infra overload.

>From the very first builds it was clear that it is huge relief
for problems we have, but it took entire Android team involvement to
prove that they're working as expected. And now, almost 2 weeks later,
we even enough stats materials to assess how much improvement they
actually did. So, I wrote a blog article about that, which includes
nice build time chart which vividly shows it all:
http://www.linaro.org/linaro-blog/2011/12/01/improving-performance-of-linaro-android-build-service/

The seeded builds launch effort was a big success in cooperation
between Infrastructure and Android team, led by Platform Director, and
I would like to thank everyone for you discussion, involvement, peer
review!

One last thing I would like to add though is that we essentially just
*started* deployment of the seeded builds, they will require more time
to uncover their full potential and made be well maintainable, so work
on that continues thru 11.12


Thanks,
Paul

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: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Arnd Bergmann]

On Thursday 01 December 2011, Catalin Marinas wrote:
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.

How do you deal with signed integer arguments passed into SVC or HVC from
a caller? If I understand the architecture correctly, the upper
halves of the argument register end up zero-padded, while the callee
expects sign-extension.

Arnd

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

Re: linux-next not booting on snowball

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2011 03:58 PM, Mark Brown wrote:
> On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
> 
>> commit 549158d2ab01e8370d2773044fe09738a26f7086
>> Author: Nicolas Pitre 
>> Date:   Thu Aug 25 00:35:59 2011 -0400
> 
>> ARM: move iotable mappings within the vmalloc region
>>
>> In order to remove the build time variation between different SOCs
>> with
>> regards to VMALLOC_END, the iotable mappings are now allocated inside
>> the vmalloc region.  This allows for VMALLOC_END to be identical
>> across
>> all machines.
> 
> I recently reported an issue with this patch on s3c64xx which I'm
> avoiding with the below change, I believe Nicolas folded this in to his
> code but it's not propagated into -next yet.
> 
> From d53e2ce3fb18e097678b324932591044eb80c0f1 Mon Sep 17 00:00:00 2001
> From: Mark Brown 
> Date: Thu, 24 Nov 2011 12:46:04 +
> Subject: [PATCH] ARM: Handle empty maps in iotable_init()
> 
> Some CPUs (such as the S3C6410) have been relying on being able to call
> iotable_init() with no io_descs in order to simplify passing through
> machine-specific io_descs. The changes in "ARM: move iotable mappings
> within the vmalloc region" broke this by adding an early_alloc_aligned()
> for an array of vm_structs. Fix this by returning early if no descriptors
> have been passed.
> 
> I'm not sure if this is the most tasteful fix but it preserves existing
> behaviour and allows boot to proceed on my system.
> 
> Signed-off-by: Mark Brown 
> ---
>  arch/arm/mm/mmu.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 06e2aef..94c5a0c 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -763,6 +763,9 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
>   struct map_desc *md;
>   struct vm_struct *vm;
>  
> + if (!nr)
> + return;
> +
>   vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
>  
>   for (md = io_desc; nr; md++, nr--) {

Thanks for the patch Mark. I applied it and tried to boot but the kernel
is still stuck on the same place :(


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

iQEcBAEBAgAGBQJO156fAAoJEAKBbMCpUGYAZK4H/iCGIqc7pYPllJbO4b4JU6FB
iTIXCeNrLZIxoqgugTQTru/6ISX/Rc3jjXIXrmu7NRjN5V+C0IzpJzRj5x4X/ysJ
xOU+65pKZ2z9D+BnkXADKYZCM6Zlqnf4qtMFLGHC1Ki1QK6HwMmReYUDEJc/7V3z
b1jXlql88Lgex9iFo73VKHn+ww8E/8OWyeutyTUIw9kvrlVaXQy6mF87rOPtS3gP
HCENMMwtEKUlHPrVBDA/MRQDF0iWKQl0aDKlmJBL3HivoAVlmhr1H6m260dkWo1w
dQUfTG7XbBWN3xg2JQ9Bp2KpTl4VvCyEJl9k0ymlcim00+l+dQySpaeC+LCKkG0=
=x1Qh
-END PGP SIGNATURE-

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

Re: [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Stefano Stabellini]

On Thu, 1 Dec 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
>
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

I always like to keep things as simple as possible, so I am in favor of
using the raw hvc instruction.
Besides with the bulk of mmu hypercalls gone, it should not be difficult
to design a 32/64 bit agnostic interface.

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

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

[Catalin Marinas]

On Thu, Dec 01, 2011 at 10:26:37AM +, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

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

Re: linux-next not booting on snowball

[Mark Brown]

On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:

> commit 549158d2ab01e8370d2773044fe09738a26f7086
> Author: Nicolas Pitre 
> Date:   Thu Aug 25 00:35:59 2011 -0400

> ARM: move iotable mappings within the vmalloc region
>
> In order to remove the build time variation between different SOCs
> with
> regards to VMALLOC_END, the iotable mappings are now allocated inside
> the vmalloc region.  This allows for VMALLOC_END to be identical
> across
> all machines.

I recently reported an issue with this patch on s3c64xx which I'm
avoiding with the below change, I believe Nicolas folded this in to his
code but it's not propagated into -next yet.

>From d53e2ce3fb18e097678b324932591044eb80c0f1 Mon Sep 17 00:00:00 2001
From: Mark Brown 
Date: Thu, 24 Nov 2011 12:46:04 +
Subject: [PATCH] ARM: Handle empty maps in iotable_init()

Some CPUs (such as the S3C6410) have been relying on being able to call
iotable_init() with no io_descs in order to simplify passing through
machine-specific io_descs. The changes in "ARM: move iotable mappings
within the vmalloc region" broke this by adding an early_alloc_aligned()
for an array of vm_structs. Fix this by returning early if no descriptors
have been passed.

I'm not sure if this is the most tasteful fix but it preserves existing
behaviour and allows boot to proceed on my system.

Signed-off-by: Mark Brown 
---
 arch/arm/mm/mmu.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 06e2aef..94c5a0c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -763,6 +763,9 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
struct map_desc *md;
struct vm_struct *vm;
 
+   if (!nr)
+   return;
+
vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
 
for (md = io_desc; nr; md++, nr--) {
-- 
1.7.7.3


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

linux-next not booting on snowball

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all,

I am using the linux-next head git tree on a snowball V5.

The kernel hangs at "Uncompressing kernel... done".

After bisecting, the patch where the kernel does no longer boot is:

commit 549158d2ab01e8370d2773044fe09738a26f7086
Author: Nicolas Pitre 
Date:   Thu Aug 25 00:35:59 2011 -0400

ARM: move iotable mappings within the vmalloc region
   
In order to remove the build time variation between different SOCs
with
regards to VMALLOC_END, the iotable mappings are now allocated inside
the vmalloc region.  This allows for VMALLOC_END to be identical
across
all machines.
   
The value for VMALLOC_END is now set to 0xff00 which is right
where
the consistent DMA area starts.
   
To accommodate all static mappings on machines with possible
highmem usage,
the default vmalloc area size is changed to 240 MB so that
VMALLOC_START
is no higher than 0xf000 by default.
   
Signed-off-by: Nicolas Pitre 
Tested-by: Stephen Warren 
Tested-by: Kevin Hilman 
Tested-by: Jamie Iles 

Is it a known issue ?

kernel config file : http://pastebin.com/E6HngT58

Thanks
  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

iQEcBAEBAgAGBQJO15RUAAoJEAKBbMCpUGYA+JkIALr9uQl2EgpCuvjo9udAs6LI
dqM1w0BvMpr2WxcMO0pUvqsCKMKBcuWz6sC/BZjCJmpcxT5H8Am6YJTFq4l4y+tO
09Ggt2fK3AUWH6CBlja8HD0MEQkkjv45tiFWS0s6qFdd4MhhII+P9M04kSwaQ24u
PWwCiPofwx2RfYGM7an7VBpTAgqOuIaL5CUJdjDL5wgHsZW/qE5hQVN+V/V47TPq
1M1A9xaBs+3BhU0yTe8JMstaXoGqTgehkE5puFXZ+6f+qhLRJZTRXwu2lHbXCdyf
rcByM65gB3cSfb555DKnXgK7qB4T2n0t/nilkkT1PaO7sM0I9E4O2wdQk5KvtbE=
=RaPn
-END PGP SIGNATURE-


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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Mark Brown]

On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:

> Clock rate/parent-change notifiers are requirements for DVFS use-cases, 
> and they must be paired with something like the 
> clk_{allow,block}_rate_change() functions to work efficiently.  I intend 
> to comment on this later; it's not a simple problem.  It might be worth 
> noting that Tero and I implemented a simplified version of this for the 
> N900.

I'm thinking that if we're going to have clk_{allow,block}_rate_change()
we may as well make that the main interface to enable rate changes - if
a device wants to change the clock rate it allows rate changes using
that interface rather than by disabling the clocks.  I've got devices
which can do glitch free updates of active clocks so having to disable
would be a real restriction, and cpufreq would have issues with actually
disabling the clock too I expect.

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

[PATCH] thermal: Add a new trip type to use cooling device instance number

[Amit Daniel Kachhap]

This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.

Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.

Signed-off-by: Amit Daniel Kachhap 
---
 Documentation/thermal/sysfs-api.txt |4 ++--
 drivers/thermal/thermal_sys.c   |   27 ++-
 include/linux/thermal.h |1 +
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
 
 trip_point_[0-*]_type
Strings which indicate the type of the trip point.
-   E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
-   thermal zone.
+   E.g. it can be one of critical, hot, passive, active[0-1],
+   state-active[0-*] for ACPI thermal zone.
RO, Optional
 
 cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "passive\n");
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, "active\n");
+   case THERMAL_TRIP_STATE_ACTIVE:
+   return sprintf(buf, "state-active\n");
default:
return sprintf(buf, "unknown\n");
}
@@ -1035,7 +1037,7 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
 void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
int count, ret = 0;
-   long temp, trip_temp;
+   long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
struct thermal_cooling_device_instance *instance;
struct thermal_cooling_device *cdev;
@@ -1086,6 +1088,29 @@ void thermal_zone_device_update(struct 
thermal_zone_device *tz)
cdev->ops->set_cur_state(cdev, 0);
}
break;
+   case THERMAL_TRIP_STATE_ACTIVE:
+   list_for_each_entry(instance, &tz->cooling_devices,
+   node) {
+   if (instance->trip != count)
+   continue;
+
+   if (temp <= last_trip_change)
+   continue;
+
+   cdev = instance->cdev;
+   cdev->ops->get_max_state(cdev, &max_state);
+
+   if ((temp >= trip_temp) &&
+   ((count + 1) <= max_state))
+   cdev->ops->set_cur_state(cdev,
+   count + 1);
+   else if ((temp < trip_temp) &&
+   (count <= max_state))
+   cdev->ops->set_cur_state(cdev, count);
+
+   last_trip_change = trip_temp;
+   }
+   break;
case THERMAL_TRIP_PASSIVE:
if (temp >= trip_temp || tz->passive)
thermal_zone_device_passive(tz, temp,
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 47b4a27..d7d0a27 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -42,6 +42,7 @@ enum thermal_trip_type {
THERMAL_TRIP_PASSIVE,
THERMAL_TRIP_HOT,
THERMAL_TRIP_CRITICAL,
+   THERMAL_TRIP_STATE_ACTIVE,
 };
 
 struct thermal_zone_device_ops {
-- 
1.7.1


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

Re: cpu_idle?

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2011 03:07 PM, Zach Pfeffer wrote:
> On 30 November 2011 13:34, Daniel Lezcano  wrote:
> On 11/30/2011 08:56 PM, Zach Pfeffer wrote:
 On 30 November 2011 11:41, Amit Kucheria  wrote:
> Wow - quite a cc-list :)
>
> On Tue, Nov 29, 2011 at 7:47 PM, Zach Pfeffer  
> wrote:
>> Amit/Mounir,
>>
>> What's your guys plan with cpu_idle for each board? Are you going to
>> try and upstream a solution that will work across all boards? Would
>> you or Mounir be open to filing a BP per board so we can track when
>> cpu_idle will hit each board? Does it make sense to prototype
>> something across each board that we could land in Ubuntu and Android?
>>
>> Adding other people, leads, etc...
>
> I'll add four more.
>
> The people I've added to cc are the ones looking at upstreaming
> cpuidle for the various member platforms (the first 3 are Linaro
> assignees):
>
> Samsung - Amit Kachhap
> ST-E - Daniel Lezcano
> Freescale - Rob Lee
> TI - Kevin Hilman and Santosh Shilimkar
>
> Rob tried to upstream a driver for the imx5 platform. Russell
> suggested that it is time to have a common cpuidle stub driver for
> ARM[1].
>
> Daniel Lezcano and Rob are currently working on such a common stub
> driver. The imx5 cpuidle will get rebased on top of that. Daniel has
> actively started work on a u8500 cpuidle driver in the meanwhile but
> is awaiting documentation.
>
> For OMAP4, I was told that there was now a cpuidle driver on its way
> into mainline. But I didn't find one after a cursory glance at the
> lists. Perhaps Kevin/Santosh can shed some light there. The last known
> tree I was aware of for an OMAP4 cpuidle driver was TI maintained
> one[2].
>
> For exynos, there is a basic cpuidle driver in mainline. Amit Kachhap
> has been working on enhancing it[3] (adding more states and using more
> of the common code that was recently added).
>
> In summary, we should have cpuidle working on the member platforms in
> the coming month. If you want something today, you should look at
> enabling OMAP4 and Exynos cpuidle configs.
>
> Regards,
> Amit

 Cool, thanks for the overview Amit.

 Is there a test that a QA guy can run to verify that cpu_idle is
 working? A set of commands and a proc node to cat out with some stats
 perhaps?
> 
> This is something we are working on [1]. The test suite [2] has a few
> trivial tests but we want to add more tests, so it is is in the radar.
> 
>> Would you share a pointer to the source?

Do you mean the source of the pm-qa code ?


> The test suite is integrated in LAVA and is run daily. The LAVA script
> checkout the head git tree and run automatically the tests. Each time we
> commit a new tests, it is take into account and run in LAVA.
> 
> For the moment, all the PM features are not available for all the
> boards, so most of the tests fail and the results are not very
> significant but the more we will merge the different PM blocks upstream,
> the greener the test suite will be :)
> 
> [1] https://blueprints.launchpad.net/linaro-power-qa/+spec/qa-cpuidle
> [2] http://git.linaro.org/gitweb?p=people/dlezcano/pm-qa.git;a=summary
> 
> 
> p.s Andy, was the breakage you reported in cpuidle related to the
> missing export.h patch?
>
> [1] 
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/132859/focus=133279
> [2] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
> for_3_2/omap4_mpuss_pm-integrated_2
> [3] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/7877



> 
> 

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

iQEcBAEBAgAGBQJO14r0AAoJEAKBbMCpUGYA7dUIAK8ghea5S1BKIX3d6eMdSJqw
fFBjzMFUSosDJTS2Chy19PPRGx80MDlXRZ1qHdQlcgU0IVJNlkoDm01/j2vha6H3
v8470SSTvqRSDHQuYC26S8/8mREdspgwDCQxpKCcAernX5Tqpqql069cK/tDb24W
vpeWncwAuIWcU3N/f2/WisYVFjr5gKReXw/1slP4Mjmq4Gl2u1KrdhXF941mORTA
by5ipmPEUfwL+NPRK35s0qnd5Kf/s+IRK6riSv904hDe0xrOpWdSF9f9aRok+iTo
UdfUJfN1E/ivIm08XM2/QubdB//iR7i6Wym76ttwysQ1QsLcSKDXFcvVva/iJ3U=
=g3SN
-END PGP SIGNATURE-

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

Re: cpu_idle?

[Zach Pfeffer]

On 30 November 2011 13:34, Daniel Lezcano  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/30/2011 08:56 PM, Zach Pfeffer wrote:
>> On 30 November 2011 11:41, Amit Kucheria  wrote:
>>> Wow - quite a cc-list :)
>>>
>>> On Tue, Nov 29, 2011 at 7:47 PM, Zach Pfeffer  
>>> wrote:
 Amit/Mounir,

 What's your guys plan with cpu_idle for each board? Are you going to
 try and upstream a solution that will work across all boards? Would
 you or Mounir be open to filing a BP per board so we can track when
 cpu_idle will hit each board? Does it make sense to prototype
 something across each board that we could land in Ubuntu and Android?

 Adding other people, leads, etc...
>>>
>>> I'll add four more.
>>>
>>> The people I've added to cc are the ones looking at upstreaming
>>> cpuidle for the various member platforms (the first 3 are Linaro
>>> assignees):
>>>
>>> Samsung - Amit Kachhap
>>> ST-E - Daniel Lezcano
>>> Freescale - Rob Lee
>>> TI - Kevin Hilman and Santosh Shilimkar
>>>
>>> Rob tried to upstream a driver for the imx5 platform. Russell
>>> suggested that it is time to have a common cpuidle stub driver for
>>> ARM[1].
>>>
>>> Daniel Lezcano and Rob are currently working on such a common stub
>>> driver. The imx5 cpuidle will get rebased on top of that. Daniel has
>>> actively started work on a u8500 cpuidle driver in the meanwhile but
>>> is awaiting documentation.
>>>
>>> For OMAP4, I was told that there was now a cpuidle driver on its way
>>> into mainline. But I didn't find one after a cursory glance at the
>>> lists. Perhaps Kevin/Santosh can shed some light there. The last known
>>> tree I was aware of for an OMAP4 cpuidle driver was TI maintained
>>> one[2].
>>>
>>> For exynos, there is a basic cpuidle driver in mainline. Amit Kachhap
>>> has been working on enhancing it[3] (adding more states and using more
>>> of the common code that was recently added).
>>>
>>> In summary, we should have cpuidle working on the member platforms in
>>> the coming month. If you want something today, you should look at
>>> enabling OMAP4 and Exynos cpuidle configs.
>>>
>>> Regards,
>>> Amit
>>
>> Cool, thanks for the overview Amit.
>>
>> Is there a test that a QA guy can run to verify that cpu_idle is
>> working? A set of commands and a proc node to cat out with some stats
>> perhaps?
>
> This is something we are working on [1]. The test suite [2] has a few
> trivial tests but we want to add more tests, so it is is in the radar.

Would you share a pointer to the source?

> The test suite is integrated in LAVA and is run daily. The LAVA script
> checkout the head git tree and run automatically the tests. Each time we
> commit a new tests, it is take into account and run in LAVA.
>
> For the moment, all the PM features are not available for all the
> boards, so most of the tests fail and the results are not very
> significant but the more we will merge the different PM blocks upstream,
> the greener the test suite will be :)
>
> [1] https://blueprints.launchpad.net/linaro-power-qa/+spec/qa-cpuidle
> [2] http://git.linaro.org/gitweb?p=people/dlezcano/pm-qa.git;a=summary
>
>
>>> p.s Andy, was the breakage you reported in cpuidle related to the
>>> missing export.h patch?
>>>
>>> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/132859/focus=133279
>>> [2] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
>>> for_3_2/omap4_mpuss_pm-integrated_2
>>> [3] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/7877
>>
>>
>>
>
>
> - --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJO1qFZAAoJEAKBbMCpUGYA+lEIAIIYZaVDpwnwKOVshB/+tkQ/
> jiRE9Ncq4iY7WyW5Acs0ev1bKfbEohX0pIJb9eA8lj9xbdRWUv/EoBLGC5b7mceH
> 5Ga2RRjU2x8BeeeXcwf3joS6bW3zt5JGd2i688bb4XHNRcJv1vG23/6Uu3NIYZJ9
> J0NW7sYkhl0ByrYqmaRwBjl42NjRx1MmHmvsxAQXUArCY1iyr7/3pVIa+NhrHatK
> 0PGFhjpeUmUWZGNAdOLYzN5/sL0uoVLiOxulZsoSWru8UUpqcOfZqPCMgyKCl9im
> 7zfVT7w3B9KTUkjlnw9mB0raq8B7X+Ro/Gpc2/H182+Rvm6F+rbiU5hrCj7V+E8=
> =5t4S
> -END PGP SIGNATURE-



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

[ACTIVITY] OCTO weekly status report - wk47.2011 (20111121-20111125)

[Ilias Biris]

Status report in detail in
https://wiki.linaro.org/OfficeofCTO/WeeklyReport

Last weekly meeting:
https://wiki.linaro.org/OfficeofCTO/2011-11-29

Highlights:

- ARMHF (also tracked via https://launchpad.net/linaro-octo-armhf
Launchpad project)
  + Debian builds are now churning
  + Ubuntu ARMHF now happening - there were some problems unearthed (eg
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/898172) but
moving on. Bugs which will appear will be tackled
  + Bug https://bugs.launchpad.net/offspring/+bug/892240 - offspring
does not currently support armhf. This will impede efforts to get armhf
benchmarks running on LAVA. The issue is being now tackled by infra, a
machine will be set to handle putting together *unsupported*
experimental armhf Debian images as a precursor to getting eventually
Ubuntu armhf builds supported by offspring.

- ARM Server: Preparation work is ongoing, for the roadmap and
requirements as well as initial planning for the first steps. A server
LEB will also be discussed from next week onwards.

- A number of patches sent already to deal with reducing ticks as a way
to reduce power consumption. Check patches from
http://patches.linaro.org/team/linaro-octo/

- Finally a short account of memory management:
  + CMA has seen a new version of the patches as result of the
discussion on Kernel Summit
  + there is ongoing work to enable testing of CMA via LAVA
  + getting dma-buf sharing improved based on the review comments, and
also pushing implementation of v4l2 as a user of dmabuf
  + we have a first implementation of dri2video for nouveau driver, and
also coming soon for omap

All questions, comments,  are welcome,

-- 
Ilias Biris ilias.bi...@linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs

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

-Werror issues in cm-kernel [was: gcc4.6,how to remove werror]

[Dave Martin]

On Thu, Dec 01, 2011 at 03:31:38PM +0700, tknv wrote:
> I could not find that WERROR override code at my kernels...
> 
> Sorry delay it, I did make V=1.
> There are three kinds test.
> All targets are ARM.
> All Makefiles(top of kernel tree)-KBUILD_CFLAGS are same.
> KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>-fno-strict-aliasing -fno-common \
>-Wno-format-security \
>-fno-delete-null-pointer-checks
> 
> I think linaro Werror behaviour is different or I need to add FLAGS more.
> 
> Compile CM-kernel with android SDK
> make -f scripts/Makefile.build obj=drivers/net/wireless/bcm4329
>  rm -f drivers/net/wireless/bcm4329/built-in.o;
>  /home/tknv/android/Oxygen/prebuil
>  t/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ar rcs
>  drivers/net/wireless/bcm43  29/built-in.o
>  
> /home/tknv/android/Oxygen/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eab
>i-gcc -Wp,-MD,drivers/net/wireless/bcm4329/.dhd_linux.o.d
>-nostdinc -isystem /home
>
> /tknv/android/Oxygen/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm
>-eabi/4.4.3/include
>-I/home/tknv/android/SuperSonic/kernels/CM-kernel/arch/arm/incl
>ude -Iinclude  -include include/generated/autoconf.h
>-D__KERNEL__ -mlittle-endian -  Iarch/arm/mach-msm/include
>-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-st
>rict-aliasing -fno-common -Wno-format-security
>-fno-delete-null-pointer-checks -Os   -marm -mabi=aapcs-linux
>-mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=7
>-march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024
>-fno-stack-protector -f  omit-frame-pointer
>-Wdeclaration-after-statement -Wno-pointer-sign
>-fno-strict-over  flow -fno-dwarf2-cfi-asm -fconserve-stack
>-DLINUX -DBCMDRIVER -DBCMDONGLEHOST -DDHD  THREAD -DBCMWPA2
>-DUNRELEASEDCHIP -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64
>-DDHD_  FIRSTREAD=64 -DDHD_GPL -DDHD_SCHED -DBDC -DTOE
>-DDHD_BCMEVENTS -DSHOW_EVENTS -DBCMS  DIO -DDHD_GPL
>-DBCMLXSDMMC -DBCMPLATFORM_BUS -Wall -Wstrict-prototypes
>-Werror -DOO  B_INTR_ONLY -DCUSTOMER_HW2 -DDHD_USE_STATIC_BUF
>-DMMC_SDIO_ABORT -DDHD_DEBUG_TRAP -  DSOFTAP
>-DEMBEDDED_PLATFORM -DARP_OFFLOAD_SUPPORT -DPKT_FILTER_SUPPORT
>-DGET_CUSTOM  _MAC_ENABLE -DSET_RANDOM_MAC_SOFTAP -DHW_OOB
>-Idrivers/net/wireless/bcm4329 -Idrive
>rs/net/wireless/bcm4329/include  -DMODULE -D"KBUILD_STR(s)=#s"
>-D"KBUILD_BASENAME=K  BUILD_STR(dhd_linux)"
>-D"KBUILD_MODNAME=KBUILD_STR(bcm4329)"  -c -o drivers/net/wi
>reless/bcm4329/dhd_linux.o
>drivers/net/wireless/bcm4329/dhd_linux.
>...
> [1]+  Donemake V=1 > build.log 2>&1
> 
> Compile CM-kernel with linaro.
> make -f scripts/Makefile.build obj=drivers/net/wireless/bcm4329
>rm -f drivers/net/wireless/bcm4329/built-in.o;
>/usr/bin/arm-linux-gnueabi-ar rcs
>drivers/net/wireless/bcm4329/built-in.o
>  /usr/bin/arm-linux-gnueabi-gcc
>  -Wp,-MD,drivers/net/wireless/bcm4329/.dhd_linux.o.d  -nostdinc
>  -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6.1/include
>  -I/home/tknv/android/SuperSonic/kernels/CM-kernel/arch/arm/include
>  -Iinclude  -include include/generated/autoconf.h -D__KERNEL__
>  -mlittle-endian -Iarch/arm/mach-msm/include -Wall -Wundef
>  -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
>  -Wno-format-security -fno-delete-null-pointer-checks -Os -marm
>  -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables
>  -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm
>  -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer
>  -Wdeclaration-after-statement -Wno-pointer-sign
>  -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -DLINUX
>  -DBCMDRIVER -DBCMDONGLEHOST -DDHDTHREAD -DBCMWPA2 -DUNRELEASEDCHIP
>  -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64 -DDHD_FIRSTREAD=64
>  -DDHD_GPL -DDHD_SCHED -DBDC -DTOE -DDHD_BCMEVENTS -DSHOW_EVENTS
>  -DBCMSDIO -DDHD_GPL -DBCMLXSDMMC -DBCMPLATFORM_BUS -Wall
>  -Wstrict-prototypes -Werror -DOOB_INTR_ONLY -DCUSTOMER_HW2
>  -DDHD_USE_STATIC_BUF -DMMC_SDIO_ABORT -DDHD_DEBUG_TRAP -DSOFTAP
>  -DEMBEDDED_PLATFORM -DARP_OFFLOAD_SUPPORT -DPKT_FILTER_SUPPORT
>  -DGET_CUSTOM_MAC_ENABLE -DSET_RANDOM_MAC_SOFTAP -DHW_OOB
>  -Idrivers/net/wireless/bcm4329
>  -Idrivers/net/wireless/bcm4329/include  -DMODULE
>  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(dhd_linux)"
>  -D"KBUILD_MODNAME=KBUILD_STR(bcm4329)"  -c -o
>  drivers/net/wireless/bcm4329/dhd_linux.o
>  drivers/net/wireless/bcm4329/dhd_linux.c
>  drivers/net/wireless/bcm4329/dhd_linux.c: In function ‘
>  dhd_rx_frame’:
>  drivers/net/wireless/bcm4329/dhd_linux.c:1282:

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Paul Walmsley]

Hi Mike

a few brief comments.

On Wed, 30 Nov 2011, Turquette, Mike wrote:

> Likewise when a clk is requested to transition to a new frequency it
> will have to clear it with all of the clks below it, so there is still
> a need to propagate a request throughout the clk tree whenever
> clk_set_rate is called and take a decision.
> 
> One way to solve this is for driver owners to sprinkle their code with
> clk_block_rate_change and clk_allow_rate_change as you propose.
> There is a problem with this method if it is not supplemented with 
> rate-change notifications that drivers are allowed to handle 
> asynchronously.  

I don't think notifiers have a bearing on clk_get_rate().

> In this case it would be nice to have asynchronous notifiers that can
> interrupt the MMC driver with a pre-change notifier and say "please
> finish your current transaction, stall your next transaction, and then
> return so I can change your clk rate".  Then after the clk rate change
> occurs a post-change notification would also go out to the MMC driver
> saying "ok I'm done changing rates.  here is your new clk rate and
> please continue working".  The notification is very polite.

I haven't made any comments about clock notifiers yet, because my 
comments so far have only concerned clk_get_rate() and 
clk_get_parent().

Clock rate/parent-change notifiers are requirements for DVFS use-cases, 
and they must be paired with something like the 
clk_{allow,block}_rate_change() functions to work efficiently.  I intend 
to comment on this later; it's not a simple problem.  It might be worth 
noting that Tero and I implemented a simplified version of this for the 
N900.

> It is worth nothing that the MMC driver can return NOTIFY_STOP in it's
> pre-change notification handler and this effectively does the same
> thing as traversing the clk subtree and checking to make sure that
> nobody is holding clk_block_rate_change against any of the children
> clocks.
> 
> The point of all of that text above is to say: if we have to walk the
> whole clk subtree below the point where we want to change rates AND we
> want to make a dynamic case-by-case call on whether to allow the rate
> change to happen (as opposed to contending with the allow/block
> semantics) then I think that only having notifications will suffice.

That would not be good.  A notifier implementation without something like 
clk_{allow,block}_rate_change() is going to waste a lot of CPU time making 
pointless calls into the notifier chains by whatever is attempting to do 
top-down DVFS.

With clk_{allow,block}_rate_change(), only a single comparison is needed 
to determine whether or not the rate change can succeed.  A 
blocking clk_set_rate() variant could also be efficiently implemented with 
that information, if so desired.

In general, a clock rate change notifier should almost never return 
NOTIFY_STOP.  That should only happen if some event occurred that took 
place after the notifier chain started.

> > 3. For the above changes to work, the clock framework will need to
> > discriminate between different clock users' calls to clock functions like
> > clk_{get,set}_rate(), etc.  Luckily this should be possible within the
> > current clock interface.  clk_get() can allocate and return a new struct
> > clk that clk_put() can later free.  One useful side effect of doing this
> > is that the clock framework could catch unbalanced clk_{enable,disable}()
> > calls.
> 
> This is definitely worth thinking about.  Another way to accomplish
> this is stop treating prepare_count and enable_count as scalars and
> instead vectorize them by tracking a list of struct device *'s.

To return to my original comments on clk_get_rate(): how would this allow 
the clock framework to discriminate between callers of clk_get_rate()?  
(Or indeed any clock framework function?)  Or is your comment simply 
addressing the unbalanced clk_{enable,disable}() case?

> > 4. clk_get_rate() must return an error when it's called in situations
> > where the caller hasn't ensured that the clock's rate won't be changed by
> > other entities.  For non-fixed rate clocks, these forbidden sections would
> > include code between a clk_get() and a clk_enable(), or between a
> > clk_disable() and a clk_put() or clk_enable(), or between a
> > clk_allow_rate_changes() and clk_block_rate_changes().  The first and
> > second of those three cases will require some code auditing of
> > clk_get_rate() users to ensure that they are only calling it after they've
> > enabled the clock.  And presumably most of them are not checking for
> > error.  include/linux/clk.h doesn't define an error return value, so this
> > needs to be explicitly defined in clk.h.
> 
> This adds a lot of burden to a driver that just wants to know a rate.
> Especially if that purpose is for something as simple/transient as a
> pr_debug message or something.

Could you clarify what burden are you referring to?

The above protocol requires few (if any) chang

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Paul Walmsley]

Hello,

Here are some initial comments on clk_get_rate().

On Mon, 21 Nov 2011, Mike Turquette wrote:

> +/**
> + * clk_get_rate - return the rate of clk
> + * @clk: the clk whose rate is being returned
> + *
> + * Simply returns the cached rate of the clk.  Does not query the hardware.  
> If
> + * clk is NULL then returns 0.
> + */
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (!clk)
> + return 0;
> +
> + return clk->rate;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_rate);

This implementation of clk_get_rate() is racy, and is, in general, unsafe. 
The problem is that, in many cases, the clock's rate may change between 
the time that clk_get_rate() is called and the time that the returned 
rate is used.  This is the case for many clocks which are part of a 
larger DVFS domain, for example.

Several changes are needed to fix this:

1. When a clock user calls clk_enable() on a clock, the clock framework 
should prevent other users of the clock from changing the clock's rate.  
This should persist until the clock user calls clk_disable() (but see also 
#2 below).  This will ensure that clock users can rely on the rate 
returned by clk_get_rate(), as long as it's called between clk_enable() 
and clk_disable().  And since the clock's rate is guaranteed to remain the 
same during this time, code that cannot tolerate clock rate changes 
without special handling (such as driver code for external I/O devices) 
will work safely without further modification.

2. Since the protocol described in #1 above will prevent DVFS from working 
when the clock is part of a larger DVFS clock group, functions need to be 
added to allow and prevent other clock users from changing the clock's 
rate.  I'll use the function names "clk_allow_rate_changes(struct clk *)" 
and "clk_block_rate_changes(struct clk *)" for this discussion.  These 
functions can be used by clock users to define critical sections during 
which other entities on the system are allowed to change a clock's rate - 
even if the clock is currently enabled.  (Note that when a clock is 
prevented from changing its rate, all of the clocks from it up to the root 
of the tree should also be prevented from changing rates, since parent 
rate changes generally cause disruptions in downstream clocks.)

3. For the above changes to work, the clock framework will need to 
discriminate between different clock users' calls to clock functions like 
clk_{get,set}_rate(), etc.  Luckily this should be possible within the 
current clock interface.  clk_get() can allocate and return a new struct 
clk that clk_put() can later free.  One useful side effect of doing this 
is that the clock framework could catch unbalanced clk_{enable,disable}() 
calls.

4. clk_get_rate() must return an error when it's called in situations 
where the caller hasn't ensured that the clock's rate won't be changed by 
other entities.  For non-fixed rate clocks, these forbidden sections would 
include code between a clk_get() and a clk_enable(), or between a 
clk_disable() and a clk_put() or clk_enable(), or between a 
clk_allow_rate_changes() and clk_block_rate_changes().  The first and 
second of those three cases will require some code auditing of 
clk_get_rate() users to ensure that they are only calling it after they've 
enabled the clock.  And presumably most of them are not checking for 
error.  include/linux/clk.h doesn't define an error return value, so this 
needs to be explicitly defined in clk.h.


- Paul

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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Paul Walmsley]

Hi

a few initial comments on clk_get_parent().

On Mon, 21 Nov 2011, Mike Turquette wrote:

> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent.  It is up to the caller to hold the
> + * prepare_lock, if desired.  Returns NULL if clk is NULL.
> + */
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + if (!clk)
> + return NULL;
> +
> + return clk->parent;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_parent);

This implementation of clk_get_parent() has similar problems to the 
clk_get_rate() implementation:

http://lkml.org/lkml/2011/11/30/403

clk_get_parent() should return an error if some other entity can change 
the clock's parent between the time that clk_get_parent() returns, and the 
time that the returned struct clk * is used.

For this to work, we need to define when clk_get_parent() should succeed. 
If we follow the protocol outlined in the above URL about clk_get_rate(), 
and we stipulate that when we block rate changes, we also block parent 
changes, then this should be fairly straightforward.  clk_get_parent() can 
succeed:

1. between a clk_enable() and a clk_disable() or clk_allow_rate_changes(),

2. between a clk_block_rate_changes() and a clk_enable(), clk_disable(), 
   or clk_allow_rate_changes()

As with clk_get_rate(), include/linux/clk.h is missing documentation of 
what the error return value should be.  This should be a little easier to 
define than with clk_get_rate(), but I don't think the error value should 
be NULL.  This is because NULL is a valid return value when 
clk_get_parent() is called on root clocks.  Better to use 
ERR_PTR(-EINVAL/-EBUSY/etc.).


- Paul

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

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Russell King - ARM Linux]

On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> 1. When a clock user calls clk_enable() on a clock, the clock framework 
> should prevent other users of the clock from changing the clock's rate.  
> This should persist until the clock user calls clk_disable() (but see also 
> #2 below).  This will ensure that clock users can rely on the rate 
> returned by clk_get_rate(), as long as it's called between clk_enable() 
> and clk_disable().  And since the clock's rate is guaranteed to remain the 
> same during this time, code that cannot tolerate clock rate changes 
> without special handling (such as driver code for external I/O devices) 
> will work safely without further modification.

So, if you have a PLL whose parent clock is not used by anything else.
You want to program it to a certain rate.

You call clk_disable() on the PLL clock.  This walks up the tree and
disables the parent.  You then try to set the rate using clk_set_rate().
clk_set_rate() in this circumstance can't wait for the PLL to lock
because it can't - there's no reference clock for it.

You then call clk_enable().  The PLL now takes its time to lock.  You
can't sleep in clk_enable() because it might be called from atomic
contexts, so you have to spin waiting for this.

Overloading clk_disable/clk_enable in this way is a bad solution to
this problem.

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