RE: Linaro rootfs / kernel version combination

[Suresh Kumar SHUKLA]

Thanks Michael, these steps worked fine.

My kernel is built with statically linked modules, so I skipped initrd.

I am able to boot and reach a console (with pty logging errors, and delay in 
prompt).
I am getting some CPU stall errors occasionally.

Regards,
Suresh

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

Re: 12.05 linux-linaro kernel tree

[Andy Green]

On 15/05/12 07:03, Somebody in the thread at some point said:


While migrating the Android solution to use linux-linaro-core-tracking, I
get kernel panic with umm-patchset (haven't dug deep into it though, it
might be because the multimedia drivers are not yet migrated for using UMM).
Would it be ok if we only include CMA patchset, but not the dma-buf and
dma-mapping patches?



are you asking whether we would consider to drop dma-mapping from
linux-linaro tree or if it would be a bad idea to do that in your
samsung LT tree?


We will need latest dmabuf and associated stuff.


For linux-linaro, we probably would prefer to try to fix it before
talking about the option to drop such a core topic. Do you have more
info about the kernel panic you see?


Yes approach of dropping -core topics to manage problems isn't really 
workable.  Even if you did it Tushar's older stuff will conflict when 
you try to unify the kernels.


If it's the case that stuff in linaro tree is more upstream-converged 
than what Tushar's tree works with, then we can put it another way: the 
current implementation in Samsung tree (no ding intended since it can 
just as easily be any of us and no doubt soon will be) needs to be fixed 
to work with current upstream-headed pieces it needs.


When you put it like that, it's clearer that there's value for Samsung 
in fixing this in Samsung LT tree to work with latest upstream-headed 
series, because they're going to have to deal with same breakage shortly 
from upstream path anyway.


I dunno if it helps, but Rob Clark has a few patches on top of current 
stuff that might also be something to do with something for Tushar


http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-omapdrm-dmabuf

-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: thermal issue on panda

[Andy Green]

On 15/05/12 07:17, Somebody in the thread at some point said:

Andy Green  writes:


On 14/05/12 20:45, Somebody in the thread at some point said:

Hi Aneesh,

Adding linaro-dev in the loop as someone else could be also interested

I have reproduced my thermal error with a lava test so you can have a
complete log available here:
http://validation.linaro.org/lava-server/scheduler/job/18564/log_file

As a summary of the problem, the panda board turns off during some
sysbench tests because the SDRAM has exceeded its temperature limit


Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is
interacting badly with smartreflex and the wrong Vcore can be selected
for 4460.


I may be lacking context here, but: we don't have any 4460s in the lab
currently, so any problems seen there cannot be 4460 specific (it _is_
possible that the lab pandas are less than perfectly ventilated of
course).


I don't think the cpu_idle vs smartreflex problems were specific to 
4460.  Since it's PoP if the cpu die is running hot it will directly 
impact the sdram.


-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: thermal issue on panda

[Michael Hudson-Doyle]

Andy Green  writes:

> On 14/05/12 20:45, Somebody in the thread at some point said:
>> Hi Aneesh,
>>
>> Adding linaro-dev in the loop as someone else could be also interested
>>
>> I have reproduced my thermal error with a lava test so you can have a
>> complete log available here:
>> http://validation.linaro.org/lava-server/scheduler/job/18564/log_file
>>
>> As a summary of the problem, the panda board turns off during some
>> sysbench tests because the SDRAM has exceeded its temperature limit
>
> Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is 
> interacting badly with smartreflex and the wrong Vcore can be selected 
> for 4460.

I may be lacking context here, but: we don't have any 4460s in the lab
currently, so any problems seen there cannot be 4460 specific (it _is_
possible that the lab pandas are less than perfectly ventilated of
course).

Cheers,
mwh

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

Re: 12.05 linux-linaro kernel tree

[Alexander Sack]

Hi Tushar,

On Mon, May 14, 2012 at 8:04 PM, Tushar Behera  wrote:
> On 14 May 2012 13:40, Tushar Behera  wrote:
>> On 05/12/2012 11:09 PM, Andrey Konovalov wrote:
>>> Tushar,
>>>
>>> On 05/11/2012 09:04 AM, Tushar Behera wrote:
 On 05/11/2012 01:04 AM, Andrey Konovalov wrote:
> Greetings,
>
> So far I wasn't updating the linux-linaro tree since the 12.04 release.
> (The generic topic updates were being done to the
> linux-linaro-core-tracking tree)
>
> Now it is time to move the focus to the linux-linaro tree. For one week
> it will use the mainline tip as the base. Then, on next Thursday the
> most recent -rc will be selected as the base, and won't be changed until
> 12.05 is released. Most probably it will be v3.4-rc7.
>
> The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
> the 7 generic topics currently included into the
> linux-linaro-core-tracking tree:
>     ufs (ufs-for-linux-linaro)
>     emmc (emmc-for-linux-linaro)
>     thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
>     linaro-android-3.4
>     armlt-gator (tracking-armlt-gator)
>     umm-wip (umm-3.4rc4-wip)
>     linaro-configs-3.4
> If you don't see your generic topic in this list, but you think it
> should be there, please let me know ASAP. If you have a new topic to
> add, please send me the request before the next Thursday, May 17; the
> sooner, the better. The requirements for a topic can be found here:
> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it
>
>
>
> The landing teams - please update your topic branches if needed:
> ARM:
>     tracking-armlt-hdlcd tracking-armlt-mmc
>     tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
>     tracking-armlt-ubuntu-config tracking-armlt-android-config
> Samsung:
>     topic/base topic/core topic/bl topic/dt topic/fb topic/pd
>     topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
>     topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
>     topic/mali topic/cma_v24 topic/android_config
>
 Is any other LT using CMA patchset? If so, this topic branch can be
 moved into linux-linaro-core-tracking.
>>>
>>> That's a good idea, thanks!
>>>
>>> The only problem is that your topic/cma_v24 is based on the topic/base,
>>> and thus includes "CONFIG: ORIGEN:" commits and an older version of
>>> linaro-configs-3.4 topic. In particular, the latter recreates
>>> configs/panda.conf file which has been deleted from the current
>>> linaro-configs-3.4. Could you please make topic/cma_v24 mainline based
>>> (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the
>>> "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is
>>> generic, it should go into a separate file, e.g. configs/cma.conf.
>>>
>> I didn't mean to include topic/cma_v24 with the patches from topic/base,
>> rather the clean patchset from Marek. But now that we have the umm topic
>> branch in linux-linaro-core-tracking, we don't need topic/cma_v24
>> anymore. If any fixes with respect to Origen are required, I will queue
>> them up in another topic branch.
>>
>> I will shortly send you the list of topic branches for 2012.05 release,
>> now that 3.4-rc7 is already released.
>>
>
> While migrating the Android solution to use linux-linaro-core-tracking, I
> get kernel panic with umm-patchset (haven't dug deep into it though, it
> might be because the multimedia drivers are not yet migrated for using UMM).
> Would it be ok if we only include CMA patchset, but not the dma-buf and
> dma-mapping patches?
>

are you asking whether we would consider to drop dma-mapping from
linux-linaro tree or if it would be a bad idea to do that in your
samsung LT tree?

For linux-linaro, we probably would prefer to try to fix it before
talking about the option to drop such a core topic. Do you have more
info about the kernel panic you see?

-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
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: Linaro rootfs / kernel version combination

[Michael Hope]

On 14 May 2012 17:48, Suresh Kumar SHUKLA  wrote:
> Hi all,
>
> I need some help in choosing right version of rootfs for my environment.
>
> I have a development board with ST SoC with Cortex-A9 dual core and 
> VFPv3-D16. Kernel version available to me is 2.6.37.
> I am using Debian 6 arm-hf port, but would like to try Linaro rootfs.
>
> 1. What is the version of linaro filesytem I should pick (optimum for 
> -mfpu=vfp and -mfloat-abi=hard) ?
> 2. I don't have a hwpack, is it possible to use vexpress or similar rootfs.

Hi Suresh.  I'd start with the Linaro Precise Nano rootfs and work
your way up from there.  Nano is a minimal hard float system that has
a serial console, networking, apt-get for new packages, and that's
about it.

I'm not sure what your SoC needs to boot.  You could try using
linaro-media-create to create a Versatile Express image, grab the
finished rootfs out of that, and then use it on your device.
Something like:

 * Grab 
http://releases.linaro.org/12.04/ubuntu/precise-images/nano/linaro-precise-nano-20120426-108.tar.gz
 * Grab 
http://releases.linaro.org/12.04/ubuntu/precise-images/nano/hwpack_linaro-vexpress_20120424-1_armhf_supported.tar.gz
 * linaro-media-create --dev vexpress --image-file vexpress.img
--hwpack hwpack*vexpress* --binary *nano* --hwpack-force-yes
 * sudo kpartx -a vexpress.img
 * sudo mount /dev/mapper/loop0p1 /mnt
 * Grab the initrd from /mnt
 * sudo mount /dev/mapper/loop0p2 /mnt
 * Grab the rootfs from /mnt

I believe you need the initrd to boot.

-- Michael

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

Standardized kernel interface for 2D blitters

[Ilyes Gouta]

Hi,

I've previously read (probably on Phoronix) that Linaro is working out
a 'standard' kernel interface for 2D blitters IPs as commonly found on
SoCs.

Has it ever been the case? If yes, are there any
documentation/references online?

Thanks,

-Ilyes

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

[ANNOUNCE] New boot loader on Snowball

[Mathieu Poirier]

All,

In our ongoing effort to move to an upstream-supported code base and
booting the snowball with a device tree (DT) I have change the boot
loader in the following android builds [1][2][3] to u-boot-linaro-stable
[4].

Once the linaro-uboot is installed in a system it won't be able to boot
images that were created at an earlier time.

Say that build #500 has the new linaro-uboot and the image has been
installed on the emmc.  Once powered this uboot will not be able to
boot build #499 that is installed on the mmc.  To fix the problem,
simply install build #500 on the mmc.  This is because the mmc commands
in the IK-uboot and the linaro-uboot differ.

To install the linaro-uboot you *must* use the latest
android-linaro-media-create found here [5] until the changes get merged
in the official repository [6].

Something like:

$ bzr branch lp:~mathieu.poirier/linaro-image-tools/linaro-image-tools

Last but not least, the linaro-uboot is currently not able to save the
environment variable block to the emmc card.  That work is ongoing and
the functionality expected to be part of 12.05.

Find me on IRC if you have any questions.

Regards,
Mathieu.

[1].
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-igloo-tracking-blob
[2].
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-igloo-stable-blob
[3].
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob
[4]. http://git.linaro.org/git/boot/u-boot-linaro-stable.git
[5].
https://code.launchpad.net/~mathieu.poirier/linaro-image-tools/linaro-image-tools
[6]. https://code.launchpad.net/linaro-image-tools

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

Golly, is that the dual SD card you and David from tincantools have been working on?

[Zach Pfeffer]

Yuppers...


Pictures here:

https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK

Its working!

-- 
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: 12.05 linux-linaro kernel tree

[Tushar Behera]

On 14 May 2012 13:40, Tushar Behera  wrote:
> On 05/12/2012 11:09 PM, Andrey Konovalov wrote:
>> Tushar,
>>
>> On 05/11/2012 09:04 AM, Tushar Behera wrote:
>>> On 05/11/2012 01:04 AM, Andrey Konovalov wrote:
 Greetings,

 So far I wasn't updating the linux-linaro tree since the 12.04 release.
 (The generic topic updates were being done to the
 linux-linaro-core-tracking tree)

 Now it is time to move the focus to the linux-linaro tree. For one week
 it will use the mainline tip as the base. Then, on next Thursday the
 most recent -rc will be selected as the base, and won't be changed until
 12.05 is released. Most probably it will be v3.4-rc7.

 The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
 the 7 generic topics currently included into the
 linux-linaro-core-tracking tree:
     ufs (ufs-for-linux-linaro)
     emmc (emmc-for-linux-linaro)
     thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
     linaro-android-3.4
     armlt-gator (tracking-armlt-gator)
     umm-wip (umm-3.4rc4-wip)
     linaro-configs-3.4
 If you don't see your generic topic in this list, but you think it
 should be there, please let me know ASAP. If you have a new topic to
 add, please send me the request before the next Thursday, May 17; the
 sooner, the better. The requirements for a topic can be found here:
 https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it



 The landing teams - please update your topic branches if needed:
 ARM:
     tracking-armlt-hdlcd tracking-armlt-mmc
     tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
     tracking-armlt-ubuntu-config tracking-armlt-android-config
 Samsung:
     topic/base topic/core topic/bl topic/dt topic/fb topic/pd
     topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
     topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
     topic/mali topic/cma_v24 topic/android_config

>>> Is any other LT using CMA patchset? If so, this topic branch can be
>>> moved into linux-linaro-core-tracking.
>>
>> That's a good idea, thanks!
>>
>> The only problem is that your topic/cma_v24 is based on the topic/base,
>> and thus includes "CONFIG: ORIGEN:" commits and an older version of
>> linaro-configs-3.4 topic. In particular, the latter recreates
>> configs/panda.conf file which has been deleted from the current
>> linaro-configs-3.4. Could you please make topic/cma_v24 mainline based
>> (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the
>> "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is
>> generic, it should go into a separate file, e.g. configs/cma.conf.
>>
> I didn't mean to include topic/cma_v24 with the patches from topic/base,
> rather the clean patchset from Marek. But now that we have the umm topic
> branch in linux-linaro-core-tracking, we don't need topic/cma_v24
> anymore. If any fixes with respect to Origen are required, I will queue
> them up in another topic branch.
>
> I will shortly send you the list of topic branches for 2012.05 release,
> now that 3.4-rc7 is already released.
>

While migrating the Android solution to use linux-linaro-core-tracking, I
get kernel panic with umm-patchset (haven't dug deep into it though, it
might be because the multimedia drivers are not yet migrated for using UMM).
Would it be ok if we only include CMA patchset, but not the dma-buf and
dma-mapping patches?

I would like to know the opinion of others regarding this.

>> Thanks,
>> Andrey
>
>
> --
> Tushar Behera



-- 
Tushar Behera

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

LAVA tests in fast models have started!

[Zygmunt Krynicki]

Hey folks.

Initial batch of LAVA tests in fast models are now running in the Linaro 
validation lab. This initial run is designed to see how behaves in 
practice and to check for omissions occurring away from my computer.


The branch that I've deployed is lp:~zkrynicki/lava-core/demo-3 (it 
depends on unreleased json-document tree from github if you want to try 
it out, there are instructions in the tree).


We've got the licensing server setup for production usage and started a 
(arguably dummy) stream lava-test test based on 
hwpack_linaro-vexpressdt-rtsm_20120511-22_armhf_supported.tar.gz and
linaro-precise-developer-20120426-86.tar.gz which is the combination I 
was using locally.


Over the next few days we'll be working on improving the process so that 
we can start accepting more realistic tests. Initially do expect high 
failure rate due to imperfections in the technology, configuration 
issues, etc.


The plan is to quickly move to practical use cases. So far I'm aware of 
the switcher tests that the QA team is using, and the kvm tests but I 
have not checked either, in practice, on a fast model yet.


My question to you, is to give me pointers (ideally as simple, practical 
instructions that show it works) for things that you want to run. I'm 
pretty ignorant about Android side of the story so any message from our 
android team would be appreciated.


Please note that iteraction cycle is very slow. It takes 10+ hours to do 
trivial things (doing apt-get update, installing a few packages, 
compiling trivial program and getting it to run for a short moment). 
Please don't ask us to run monkey for you as we'll be wasting time at 
this point.


My goal is to understand what's missing and to estimate how long given 
tests typically takes so that we can compare how our infrastructure 
compares to your needs.


Many thanks
Zygmunt Krynicki

--
Zygmunt Krynicki
Linaro Validation Team


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

Re: thermal issue on panda

[Andy Green]

On 14/05/12 22:23, Somebody in the thread at some point said:

On Mon, May 14, 2012 at 5:12 PM, Andy Green  wrote:

On 14/05/12 20:53, Somebody in the thread at some point said:


On 14/05/12 20:45, Somebody in the thread at some point said:


Hi Aneesh,

Adding linaro-dev in the loop as someone else could be also interested

I have reproduced my thermal error with a lava test so you can have a
complete log available here:
http://validation.linaro.org/lava-server/scheduler/job/18564/log_file

As a summary of the problem, the panda board turns off during some
sysbench tests because the SDRAM has exceeded its temperature limit



Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is
interacting badly with smartreflex and the wrong Vcore can be selected
for 4460.

At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix +
workaround and I'll update with it tomorrow.



tilt-3.3 is updated with the fixes and workaround of disabling CPU_IDLE,
please give that a try.



Andy,

Disabling cpuidle is a bit of extreme workaround if one works on power
management. :)

Can you point to any discussions about the problem?


They're on a private list and being dug into atm.

Actually it's not so extreme as a workaround under the circumstances, 
the issue is cpuidle disrupts Vcore set by smartreflex leading to 
crashes or excess power consumption and heat.  It's better to have 
voltage part of dvfs working well (and not crashing) than cpuidle until 
we figure out what broke.


-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: thermal issue on panda

[Amit Kucheria]

On Mon, May 14, 2012 at 5:12 PM, Andy Green  wrote:
> On 14/05/12 20:53, Somebody in the thread at some point said:
>>
>> On 14/05/12 20:45, Somebody in the thread at some point said:
>>>
>>> Hi Aneesh,
>>>
>>> Adding linaro-dev in the loop as someone else could be also interested
>>>
>>> I have reproduced my thermal error with a lava test so you can have a
>>> complete log available here:
>>> http://validation.linaro.org/lava-server/scheduler/job/18564/log_file
>>>
>>> As a summary of the problem, the panda board turns off during some
>>> sysbench tests because the SDRAM has exceeded its temperature limit
>>
>>
>> Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is
>> interacting badly with smartreflex and the wrong Vcore can be selected
>> for 4460.
>>
>> At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix +
>> workaround and I'll update with it tomorrow.
>
>
> tilt-3.3 is updated with the fixes and workaround of disabling CPU_IDLE,
> please give that a try.
>

Andy,

Disabling cpuidle is a bit of extreme workaround if one works on power
management. :)

Can you point to any discussions about the problem?

/Amit

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

Re: thermal issue on panda

[Andy Green]

On 14/05/12 20:53, Somebody in the thread at some point said:

On 14/05/12 20:45, Somebody in the thread at some point said:

Hi Aneesh,

Adding linaro-dev in the loop as someone else could be also interested

I have reproduced my thermal error with a lava test so you can have a
complete log available here:
http://validation.linaro.org/lava-server/scheduler/job/18564/log_file

As a summary of the problem, the panda board turns off during some
sysbench tests because the SDRAM has exceeded its temperature limit


Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is
interacting badly with smartreflex and the wrong Vcore can be selected
for 4460.

At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix +
workaround and I'll update with it tomorrow.


tilt-3.3 is updated with the fixes and workaround of disabling CPU_IDLE, 
please give that a try.


-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

[PATCH 1/2] ARM: s3c64xx: cpuidle - declare the states with the new api

[Daniel Lezcano]

The states are now part of the cpuidle_driver structure, so we can
declare the states in this structure directly. That saves us an extra
variable declaration and a memcpy.

Signed-off-by: Daniel Lezcano 
---
 arch/arm/mach-s3c64xx/cpuidle.c |   33 ++---
 1 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 179460f..2750e54 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -51,33 +51,28 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
return index;
 }
 
-static struct cpuidle_state s3c64xx_cpuidle_set[] = {
-   [0] = {
-   .enter  = s3c64xx_enter_idle,
-   .exit_latency   = 1,
-   .target_residency   = 1,
-   .flags  = CPUIDLE_FLAG_TIME_VALID,
-   .name   = "IDLE",
-   .desc   = "System active, ARM gated",
-   },
-};
+static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
 
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
-   .name   = "s3c64xx_cpuidle",
-   .owner  = THIS_MODULE,
-   .state_count= ARRAY_SIZE(s3c64xx_cpuidle_set),
-};
-
-static struct cpuidle_device s3c64xx_cpuidle_device = {
-   .state_count= ARRAY_SIZE(s3c64xx_cpuidle_set),
+   .name   = "s3c64xx_cpuidle",
+   .owner  = THIS_MODULE,
+   .states = {
+   {
+   .enter= s3c64xx_enter_idle,
+   .exit_latency = 1,
+   .target_residency = 1,
+   .flags= CPUIDLE_FLAG_TIME_VALID,
+   .name = "IDLE",
+   .desc = "System active, ARM gated",
+   },
+   },
+   .state_count = 1,
 };
 
 static int __init s3c64xx_init_cpuidle(void)
 {
int ret;
 
-   memcpy(s3c64xx_cpuidle_driver.states, s3c64xx_cpuidle_set,
-  sizeof(s3c64xx_cpuidle_set));
cpuidle_register_driver(&s3c64xx_cpuidle_driver);
 
ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
-- 
1.7.5.4


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

[PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Daniel Lezcano]

These couple of patches use the new cpuidle core api to refactor
some part of the code. The first one declares the states directly
in the driver declaration and the second one use the timekeeping
flag to let the cpuidle core to compute the idle time.

I don't have this board, I was not able to test these patches.

Daniel Lezcano (2):
  ARM: s3c64xx: cpuidle - declare the states with the new api
  ARM: s3c64xx: cpuidle - use timekeeping wrapper

 arch/arm/mach-s3c64xx/cpuidle.c |   45 +--
 1 files changed, 15 insertions(+), 30 deletions(-)

-- 
1.7.5.4


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

[PATCH 2/2] ARM: s3c64xx: cpuidle - use timekeeping wrapper

[Daniel Lezcano]

The timekeeping is computed from the cpuidle core if we set
the .en_core_tk_irqen flag. Let's use it and remove the duplicated
code.

Signed-off-by: Daniel Lezcano 
---
 arch/arm/mach-s3c64xx/cpuidle.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 2750e54..acb197c 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -27,12 +27,7 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
  struct cpuidle_driver *drv,
  int index)
 {
-   struct timeval before, after;
unsigned long tmp;
-   int idle_time;
-
-   local_irq_disable();
-   do_gettimeofday(&before);
 
/* Setup PWRCFG to enter idle mode */
tmp = __raw_readl(S3C64XX_PWR_CFG);
@@ -42,12 +37,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
 
cpu_do_idle();
 
-   do_gettimeofday(&after);
-   local_irq_enable();
-   idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
-   (after.tv_usec - before.tv_usec);
-
-   dev->last_residency = idle_time;
return index;
 }
 
@@ -56,6 +45,7 @@ static DEFINE_PER_CPU(struct cpuidle_device, 
s3c64xx_cpuidle_device);
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
.name   = "s3c64xx_cpuidle",
.owner  = THIS_MODULE,
+   .en_core_tk_irqen = 1,
.states = {
{
.enter= s3c64xx_enter_idle,
-- 
1.7.5.4


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

RE: FW: STM Drviers update patch

[Deao, Douglas]

Ryan,

No worries. I have not updated yet to pick up your patches, so I had no idea 
what Andy was referencing.

Regards,
Doug

From: Ryan Harkin [mailto:ryan.har...@linaro.org]
Sent: Monday, May 14, 2012 8:58 AM
To: Deao, Douglas
Cc: Andy Green; linaro-dev@lists.linaro.org; Arnd Bergmann
Subject: Re: FW: STM Drviers update patch

(CC'd "inaro-dev" as opposed to "linaro-dev" as I guess that was a previous 
typo)

On 14 May 2012 14:41, Deao, Douglas mailto:d-d...@ti.com>> wrote:
Andy,

The commit to my clone was right after "config tilt stm and omap driver"
on tracking-topic-stm.  I used "git format-patch -1" to generate the
patch.

I sent my patch before Ryan's showed up on the landing team site.

My patches are only a new "driver" (stm_arm.c) and the Kconfig/makefile changes 
needed.

This new driver doesn't do anything yet, BTW, it's just a load of debug code.  
But it shouldn't effect your patch merging over the top of your existing 
stm_fw.c as I haven't touched that file.



The Framework driver is not using /sys in any way, just /debugfs, so
anything with /sys was added by Ryan.

Not guilty :-)  I think Andy was simply referring to the /debugfs stuff, but 
called it /sys.


The Framework driver has always had a debugfs fops API. The first
release supported only character based messages, but the new patch
supports binary transfers using the same fops API. Trying to keep
it easy to use for both cases.

Regards,
Doug

> -Original Message-
> From: Andy Green [mailto:andy.gr...@linaro.org]
> Sent: Sunday, May 13, 2012 10:29 PM
> To: Deao, Douglas
> Cc: inaro-...@lists.linaro.org; Ryan 
> Harkin; Arnd Bergmann
> Subject: Re: FW: STM Drviers update patch
>
> On 11/05/12 01:29, Somebody in the thread at some point said:
>
> (looping Ryan and Arnd)
>
> > This time without the copy/paste error.
> >
> > -Original Message-
> > From: Deao, Douglas
> > Sent: Thursday, May 10, 2012 12:26 PM
> > To: 'Andy Green'
> > Cc: 'mailto:patc...@linaro.org'; 
> > 'mailto:linaro-dev@lists.linaro.org'
> > Subject: STM Drviers update patch
> >
> > Andy,
> >
> > Just found the Linaro "Process/UpstreamPatches" page.
> >
> > Anything else that's not obvious to a newbie I need to be aware of?
>
> Hi Doug -
>
> I'm not sure I'm the integration point for these patches or it should
> be
> Ryan... he has sent some refactor patches for omap support recently for
> OMAP5 testing.
>
> Either way patc...@linaro.org only cares about 
> patches when they're
> sent
> upstream, and we're not there yet.
>
> I wasn't able to get this patch to apply to tracking-topic-stm with or
> without Ryan's changes... is it intended to replace what's there?
> That's fine if so, otherwise what should it apply to?  Is it aware of
> Ryan's changes?
>
> http://git.linaro.org/gitweb?p=landing-
> teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-stm
>
> Something I noticed when testing for Ryan was there's a kind of shell
> command type interface via /sys nodes, with commandlines like
>
> echo "rm xyz" > /sys/blah
>
> In the past, I believe there has been some resistance to this kind of
> thing upstream, with a hardline one-token-one-sys-node approach
> demanded.  In other /sys based subsystems, they seem to use the idea of
> elaborating the possible commands as /sys nodes themselves, so you
> would
> echo > /sys/.../rm to delete.  Maybe Arnd can guide us if that's still
> a
> problem.
>
> Also while we're bothering Arnd, IIRC at one point there was a char
> device, but I can't see it any more with a quick look through the
> framework code.  Did you replace it?  If so what's the way to transfer
> the bulk data now?
>
> -Andy
>
> > -Original Message-
> > From: Deao, Douglas
> > Sent: Tuesday, May 08, 2012 4:40 PM
> > To: Andy Green
> > Cc: Loic Pallardy; 
> > scott.bambro...@linaro.org; Ryan Harkin; 
> > Lee
> Jones; Philippe Langlais
> > Subject: STM Drviers update patch
> >
> > Andy,
> >
> > I have attached a patch for tracking-topic-stm that contains both my
> latest updates and feedback/patches I merged from Loic Pallardy.
> >
> > This patch includes:
> > - Binary data transport
> > - mmap support for mapping channels to user space
> > - PID change notification
> > - Added patched/feedback provided by Loic Pallardy for:
> >echo support improvement
> >API improvements
> >
> > Let me know if there is any additional process for adding patches
> beyond simply sending you the patch.
> >
> > P.S Just noticed you have a change to stm_omap_ti1.0.c that I did not
> manage to update. Let me know if applying the patch causes you any
> grief.
> >
> > Thanks,
> > Doug
>
>
> --
> Andy Green | TI Landing Team Leader
> Linaro.org │ Open source software for ARM SoCs | Follow Linaro
> http://facebook.com/pages/Linaro/155974581091106  -
> http://t

Fwd: Re: FW: STM Drviers update patch

[Andy Green]

 Original Message 
Subject: Re: FW: STM Drviers update patch
Date: Mon, 14 May 2012 21:46:40 +0800
From: Andy Green 
To: Deao, Douglas 
CC: inaro-...@lists.linaro.org ,  Ryan 
Harkin , Arnd Bergmann 


On 14/05/12 21:41, Somebody in the thread at some point said:

Hi -


The commit to my clone was right after "config tilt stm and omap driver"
on tracking-topic-stm.  I used "git format-patch -1" to generate the
patch.

I sent my patch before Ryan's showed up on the landing team site.


OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to
deal with it.  I had Ryan's patches locally for a couple of weeks but
was unable to push tracking for several days due to crash bugs I fixed
late last week.


The Framework driver is not using /sys in any way, just /debugfs, so
anything with /sys was added by Ryan.


You're quite right, if I looked a little further along I would have seen
it's /sys/kernel/debugfs.  Sorry for the noise.


The Framework driver has always had a debugfs fops API. The first
release supported only character based messages, but the new patch
supports binary transfers using the same fops API. Trying to keep
it easy to use for both cases.


-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: FW: STM Drviers update patch

[Ryan Harkin]

On 14 May 2012 14:46, Andy Green  wrote:

> On 14/05/12 21:41, Somebody in the thread at some point said:
>
> Hi -
>
>
>  The commit to my clone was right after "config tilt stm and omap driver"
>> on tracking-topic-stm.  I used "git format-patch -1" to generate the
>> patch.
>>
>> I sent my patch before Ryan's showed up on the landing team site.
>>
>
> OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to
> deal with it.  I had Ryan's patches locally for a couple of weeks but was
> unable to push tracking for several days due to crash bugs I fixed late
> last week.


Andy, you can just remove my patches from the tree if you like.  I can send
you a fresh set of patches that apply cleanly over the STM topic when I
have something else for you to test.

As mentioned in the previous mail, my current set of patches just do some
debugging stuff and don't really constitute a "driver" for ARM's STM.

>
>
>  The Framework driver is not using /sys in any way, just /debugfs, so
>> anything with /sys was added by Ryan.
>>
>
> You're quite right, if I looked a little further along I would have seen
> it's /sys/kernel/debugfs.  Sorry for the noise.
>
>
>  The Framework driver has always had a debugfs fops API. The first
>> release supported only character based messages, but the new patch
>> supports binary transfers using the same fops API. Trying to keep
>> it easy to use for both cases.
>>
>
> -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: FW: STM Drviers update patch

[Ryan Harkin]

(CC'd "inaro-dev" as opposed to "linaro-dev" as I guess that was a previous
typo)


On 14 May 2012 14:41, Deao, Douglas  wrote:

> Andy,
>
> The commit to my clone was right after "config tilt stm and omap driver"
> on tracking-topic-stm.  I used "git format-patch -1" to generate the
> patch.
>
> I sent my patch before Ryan's showed up on the landing team site.
>

My patches are only a new "driver" (stm_arm.c) and the Kconfig/makefile
changes needed.

This new driver doesn't do anything yet, BTW, it's just a load of debug
code.  But it shouldn't effect your patch merging over the top of your
existing stm_fw.c as I haven't touched that file.



>
> The Framework driver is not using /sys in any way, just /debugfs, so
> anything with /sys was added by Ryan.
>

Not guilty :-)  I think Andy was simply referring to the /debugfs stuff,
but called it /sys.


>
> The Framework driver has always had a debugfs fops API. The first
> release supported only character based messages, but the new patch
> supports binary transfers using the same fops API. Trying to keep
> it easy to use for both cases.
>
> Regards,
> Doug
>
> > -Original Message-
> > From: Andy Green [mailto:andy.gr...@linaro.org]
> > Sent: Sunday, May 13, 2012 10:29 PM
> > To: Deao, Douglas
> > Cc: inaro-...@lists.linaro.org; Ryan Harkin; Arnd Bergmann
> > Subject: Re: FW: STM Drviers update patch
> >
> > On 11/05/12 01:29, Somebody in the thread at some point said:
> >
> > (looping Ryan and Arnd)
> >
> > > This time without the copy/paste error.
> > >
> > > -Original Message-
> > > From: Deao, Douglas
> > > Sent: Thursday, May 10, 2012 12:26 PM
> > > To: 'Andy Green'
> > > Cc: 'mailto:patc...@linaro.org'; 'mailto:linaro-dev@lists.linaro.org'
> > > Subject: STM Drviers update patch
> > >
> > > Andy,
> > >
> > > Just found the Linaro "Process/UpstreamPatches" page.
> > >
> > > Anything else that's not obvious to a newbie I need to be aware of?
> >
> > Hi Doug -
> >
> > I'm not sure I'm the integration point for these patches or it should
> > be
> > Ryan... he has sent some refactor patches for omap support recently for
> > OMAP5 testing.
> >
> > Either way patc...@linaro.org only cares about patches when they're
> > sent
> > upstream, and we're not there yet.
> >
> > I wasn't able to get this patch to apply to tracking-topic-stm with or
> > without Ryan's changes... is it intended to replace what's there?
> > That's fine if so, otherwise what should it apply to?  Is it aware of
> > Ryan's changes?
> >
> > http://git.linaro.org/gitweb?p=landing-
> > teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-stm
> >
> > Something I noticed when testing for Ryan was there's a kind of shell
> > command type interface via /sys nodes, with commandlines like
> >
> > echo "rm xyz" > /sys/blah
> >
> > In the past, I believe there has been some resistance to this kind of
> > thing upstream, with a hardline one-token-one-sys-node approach
> > demanded.  In other /sys based subsystems, they seem to use the idea of
> > elaborating the possible commands as /sys nodes themselves, so you
> > would
> > echo > /sys/.../rm to delete.  Maybe Arnd can guide us if that's still
> > a
> > problem.
> >
> > Also while we're bothering Arnd, IIRC at one point there was a char
> > device, but I can't see it any more with a quick look through the
> > framework code.  Did you replace it?  If so what's the way to transfer
> > the bulk data now?
> >
> > -Andy
> >
> > > -Original Message-
> > > From: Deao, Douglas
> > > Sent: Tuesday, May 08, 2012 4:40 PM
> > > To: Andy Green
> > > Cc: Loic Pallardy; scott.bambro...@linaro.org; Ryan Harkin; Lee
> > Jones; Philippe Langlais
> > > Subject: STM Drviers update patch
> > >
> > > Andy,
> > >
> > > I have attached a patch for tracking-topic-stm that contains both my
> > latest updates and feedback/patches I merged from Loic Pallardy.
> > >
> > > This patch includes:
> > > - Binary data transport
> > > - mmap support for mapping channels to user space
> > > - PID change notification
> > > - Added patched/feedback provided by Loic Pallardy for:
> > >echo support improvement
> > >API improvements
> > >
> > > Let me know if there is any additional process for adding patches
> > beyond simply sending you the patch.
> > >
> > > P.S Just noticed you have a change to stm_omap_ti1.0.c that I did not
> > manage to update. Let me know if applying the patch causes you any
> > grief.
> > >
> > > Thanks,
> > > Doug
> >
> >
> > --
> > 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: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Daniel Lezcano]

On 05/14/2012 03:51 PM, Kukjin Kim wrote:

On 05/14/12 18:22, Daniel Lezcano wrote:

On 05/14/2012 10:57 AM, Mark Brown wrote:

On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:

Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:

On 05/09/2012 04:08 PM, Daniel Lezcano wrote:



Are these patches ok for inclusion ?



you might want to include the maintainer



Kukjin Kim



and the samsung list



linux-samsung-...@vger.kernel.org



into your recipients


Also the original author (me).


Oh, ok. I thought I did it, sorry.


Heiko, thanks :-)

Daniel, could you please re-submit this series with adding me and Mark
Brown in Cc. I couldn't find your patches in my mailbox...


Sure.

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

Follow Linaro:   Facebook |
 Twitter |
 Blog


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

Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Kukjin Kim]

On 05/14/12 18:22, Daniel Lezcano wrote:

On 05/14/2012 10:57 AM, Mark Brown wrote:

On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:

Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:

On 05/09/2012 04:08 PM, Daniel Lezcano wrote:



Are these patches ok for inclusion ?



you might want to include the maintainer



Kukjin Kim



and the samsung list



linux-samsung-...@vger.kernel.org



into your recipients


Also the original author (me).


Oh, ok. I thought I did it, sorry.


Heiko, thanks :-)

Daniel, could you please re-submit this series with adding me and Mark 
Brown in Cc. I couldn't find your patches in my mailbox...


Thanks.

Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

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

Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Daniel Lezcano]

On 05/14/2012 10:57 AM, Mark Brown wrote:

On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:

Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:

On 05/09/2012 04:08 PM, Daniel Lezcano wrote:
Are these patches ok for inclusion ?

you might want to include the maintainer
Kukjin Kim
and the samsung list
linux-samsung-...@vger.kernel.org
into your recipients

Also the original author (me).


Mark,

I noticed you are not in the cpuidle.c header file neither in the 
MAINTAINERS entry for the s3c64xx.

Just FYI.

Thanks
-- Daniel


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

Follow Linaro:  Facebook |
  Twitter |
  Blog



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

Re: thermal issue on panda

[Andy Green]

On 14/05/12 20:45, Somebody in the thread at some point said:

Hi Aneesh,

Adding linaro-dev in the loop as someone else could be also interested

I have reproduced my thermal error with a lava test so you can have a
complete log available here:
http://validation.linaro.org/lava-server/scheduler/job/18564/log_file

As a summary of the problem, the panda board turns off during some
sysbench tests because the SDRAM has exceeded its temperature limit


Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is 
interacting badly with smartreflex and the wrong Vcore can be selected 
for 4460.


At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix + 
workaround and I'll update with it tomorrow.


-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: thermal issue on panda

[Vincent Guittot]

Hi Aneesh,

Adding linaro-dev in the loop as someone else could be also interested

I have reproduced my thermal error with a lava test so you can have a
complete log available here:
http://validation.linaro.org/lava-server/scheduler/job/18564/log_file

As a summary of the problem, the panda board turns off during some
sysbench tests because the SDRAM has exceeded its temperature limit

Regards,
Vincent


On 9 May 2012 14:43, Vincent Guittot  wrote:
> Hi Aneesh,
>
> Sorry for this late replay.
>
> I'm working with the Linaro 12.04 developer image which is quite close
> to the Linaro ubuntu one but without IHM.
> Te manifest gives me the following information about the kernel
> linux-image-3.3.1-38-linaro-lt-omap=3.3.1-38.38~lt~ci~01+1336186099~4fa4ad78
> which should be available here
> :git://git.linaro.org/landing-teams/leb/ti/kernel.git
>
> This issue occurs each time I run some sysbench tests on my panda
> board (revA1). I run several tests which  are 20 seconds long and the
> issue occurs after few minutes
>
> I've check with my finger and the package is quite hot when the issue occurs
>
> Regards,
> Vincent
>
> On 7 May 2012 19:43, Aneesh V  wrote:
>> On 05/07/2012 10:38 AM, Mike Turquette wrote:
>>>
>>> On Thu, May 3, 2012 at 7:47 AM, Vincent Guittot
>>>   wrote:

 Hi Amit and Mike,

 While stressing the dual cortex-A9 of my panda board ( omap4430 ) with
 the latest Linaro ubuntu developer environment, I reach the following
 message

 [  824.996978] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  837.243957] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  839.045318] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  845.168518] emif emif.1: temperature alert before registers are
 calculated, not de-rating timings
 [  901.361663] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  902.082672] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  914.329620] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  925.496124] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  930.537292] emif emif.2: temperature alert before registers are
 calculated, not de-rating timings
 [  938.82] emif emif.1: temperature alert before registers are
 calculated, not de-rating timings
 [  947.828857] emif emif.1: temperature alert before registers are
 calculated, not de-rating timings
 [  954.312072] emif emif.1: temperature alert before registers are
 calculated, not de-rating timings
 [  982.047271] emif emif.2: SDRAM temperature exceeds operating
 limit.. Needs shut down!!!
 [  982.072784] Power down.

 It is something you have already faced ? could something miss in the
 kernel ?
>>
>>
>> That should not happen normally. If all is well, it should happen only
>> if the temperature alert comes during a small window at bootup. Is that
>> the case with you. Which tree and branch are you using. Please send me
>> the details and I will take a look.
>>
>> br,
>> Aneesh

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

Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Heiko Stübner]

Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:
> On 05/09/2012 04:08 PM, Daniel Lezcano wrote:
> > These couple of patches use the new cpuidle core api to refactor
> > some part of the code. The first one declares the states directly
> > in the driver declaration and the second one use the timekeeping
> > flag to let the cpuidle core to compute the idle time.
> > 
> > I don't have this board, I was not able to test these patches.
> > 
> > Daniel Lezcano (2):
> >ARM: s3c64xx: cpuidle - declare the states with the new api
> >ARM: s3c64xx: cpuidle - use timekeeping wrapper
> 
> Are these patches ok for inclusion ?

you might want to include the maintainer

Kukjin Kim 

and the samsung list

linux-samsung-...@vger.kernel.org

into your recipients


Heiko

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

Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Daniel Lezcano]

On 05/14/2012 10:57 AM, Mark Brown wrote:

On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:

Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:

On 05/09/2012 04:08 PM, Daniel Lezcano wrote:



Are these patches ok for inclusion ?



you might want to include the maintainer



Kukjin Kim



and the samsung list



linux-samsung-...@vger.kernel.org



into your recipients


Also the original author (me).


Oh, ok. I thought I did it, sorry.

  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog


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

Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

[Mark Brown]

On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:
> Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:
> > On 05/09/2012 04:08 PM, Daniel Lezcano wrote:

> > Are these patches ok for inclusion ?

> you might want to include the maintainer

>   Kukjin Kim 

> and the samsung list

>   linux-samsung-...@vger.kernel.org

> into your recipients

Also the original author (me).

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

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Saturday 05 May 2012, Arnd Bergmann wrote:

> From the statements made so far, I can see no clear policy that we can
> apply to everyone. My take on this is that for any work I spend on
> multiplatform kernel, I concentrate on the DT-based board files and
> get them to work together first, but leave it up to the individual
> subarch maintainers whether they want to add other board files into
> the mix.

A small update that I already posted as a comment in the lwn article
covering this discussion:

| Over the last week, I've actually tried out building kernels for
| multiple platforms combined to get a better feeling for the remaining
| problems. The result is in the testing/multiplatform branch of
| git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git and it
| can build arbitrary combinations of four of the five subarchitectures
| that the Linaro organization is most interested in (imx, omap, ux500 and
| vexpress, but not exynos for now). Most other platforms should actually
| be simpler to convert.
| 
| However, this kernel is not yet going to be useful on real hardware
| because I had to disable or add hacks for a number of features (SMP,
| sparseirq, clocks) that are still being worked on, but as soon as one
| oatform has all that work done, we can actually build a kernel with
| everything enabled and run on that particular platform and see what
| else breaks.
|
| Unlike I suggested earlier, this kernel at the moment actually allows
| enabling all the board files including non-DT ones because that was
| easier to do with the Kconfig dependencies, but I found two real technical
| issues that would be solved by making the combined kernel DT-only:
|
| 1. The exynos platform defines static platform devices from files
| shared with five other Samsung platforms that are mutually exclusive
| because the device definitions depend on platform specific compile-time
| constants. Using DT probing we can just drop those static platform device
| definitions and make the conflict go away.
|
| 2. With sparse IRQs, a lot of the hardcoded interrupt numbers in static
| platform device definitions are broken, while the definitions from DT
| still work. Sparse IRQs are currently needed to build multiplatform
| kernels and I expect that requirement to stay.

Arnd

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

Re: 12.05 linux-linaro kernel tree

[Tushar Behera]

On 05/12/2012 11:09 PM, Andrey Konovalov wrote:
> Tushar,
> 
> On 05/11/2012 09:04 AM, Tushar Behera wrote:
>> On 05/11/2012 01:04 AM, Andrey Konovalov wrote:
>>> Greetings,
>>>
>>> So far I wasn't updating the linux-linaro tree since the 12.04 release.
>>> (The generic topic updates were being done to the
>>> linux-linaro-core-tracking tree)
>>>
>>> Now it is time to move the focus to the linux-linaro tree. For one week
>>> it will use the mainline tip as the base. Then, on next Thursday the
>>> most recent -rc will be selected as the base, and won't be changed until
>>> 12.05 is released. Most probably it will be v3.4-rc7.
>>>
>>> The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
>>> the 7 generic topics currently included into the
>>> linux-linaro-core-tracking tree:
>>> ufs (ufs-for-linux-linaro)
>>> emmc (emmc-for-linux-linaro)
>>> thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
>>> linaro-android-3.4
>>> armlt-gator (tracking-armlt-gator)
>>> umm-wip (umm-3.4rc4-wip)
>>> linaro-configs-3.4
>>> If you don't see your generic topic in this list, but you think it
>>> should be there, please let me know ASAP. If you have a new topic to
>>> add, please send me the request before the next Thursday, May 17; the
>>> sooner, the better. The requirements for a topic can be found here:
>>> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it
>>>
>>>
>>>
>>> The landing teams - please update your topic branches if needed:
>>> ARM:
>>> tracking-armlt-hdlcd tracking-armlt-mmc
>>> tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
>>> tracking-armlt-ubuntu-config tracking-armlt-android-config
>>> Samsung:
>>> topic/base topic/core topic/bl topic/dt topic/fb topic/pd
>>> topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
>>> topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
>>> topic/mali topic/cma_v24 topic/android_config
>>>
>> Is any other LT using CMA patchset? If so, this topic branch can be
>> moved into linux-linaro-core-tracking.
> 
> That's a good idea, thanks!
> 
> The only problem is that your topic/cma_v24 is based on the topic/base,
> and thus includes "CONFIG: ORIGEN:" commits and an older version of
> linaro-configs-3.4 topic. In particular, the latter recreates
> configs/panda.conf file which has been deleted from the current
> linaro-configs-3.4. Could you please make topic/cma_v24 mainline based
> (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the
> "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is
> generic, it should go into a separate file, e.g. configs/cma.conf.
> 
I didn't mean to include topic/cma_v24 with the patches from topic/base,
rather the clean patchset from Marek. But now that we have the umm topic
branch in linux-linaro-core-tracking, we don't need topic/cma_v24
anymore. If any fixes with respect to Origen are required, I will queue
them up in another topic branch.

I will shortly send you the list of topic branches for 2012.05 release,
now that 3.4-rc7 is already released.

> Thanks,
> Andrey


-- 
Tushar Behera

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