Hi all,
Git Location: http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=summary
Branch: big-LITTLE-MP-v1
We're announcing a kernel tree to track the various topics of the
big.LITTLE MP project. The aim of this tree is to help consolidate the
various topic patchsets that improve the behaviour of Linux on
asymmetric cores (e.g. big.LITTLE) and make smarter scheduling
decisions possible in order to save power. I'd like to think of it as
a linux-next tree focused on asymmetric support enablement.
Viresh will recreate this tree when new versions of the topic
patchsets are available. IOW, as the patches are reviewed on the lists
and go through iterations, we'll pull each topic patchset into a topic
branch (e.g. per-task-load-average-v2, arm-asymmetric-support-v3).
Then a merge tree will be created (e.g. big-LITTLE-MP-v1) as needed
based on the latest versions of these topics. This should allow users
to track individual topics or leave out some topics if they so desire.
More topics will be added to this tree as the work becomes available.
Linaro platform team will take the merge branch (big-LITTLE-MP-v1,
-v2, etc.) and use it for platform enablement work and testing on real
hardware and models.
Problems should be reported on LKML/LAKML as usual if they are related
to the individual topic trees. If they're related to a bad merge or
config enablement please report on linaro-dev(a)lists.linaro.org.
Regards,
Amit
p.s. People who've shown an interest in this tree have been bcc'ed so
they don't miss the announcement. They are requested to join either
linaro-dev or linaro-sched-sig for future announcements.
Dear all,
A few weeks ago, Peter De Schrijver proposed a patch [1] to allow per
cpu latencies. We had a discussion about this patchset because it
reverse the modifications Deepthi did some months ago [2] and we may
want to provide a different implementation.
The Linaro Connect [3] event bring us the opportunity to meet people
involved in the power management and the cpuidle area for different SoC.
With the Tegra3 and big.LITTLE architecture, making per cpu latencies
for cpuidle is vital.
Also, the SoC vendors would like to have the ability to tune their cpu
latencies through the device tree.
We agreed in the following steps:
1. factor out / cleanup the cpuidle code as much as possible
2. better sharing of code amongst SoC idle drivers by moving common bits
to core code
3. make the cpuidle_state structure contain only data
4. add a API to register latencies per cpu
These four steps impacts all the architecture. I began the factor out
code / cleanup [4] and that has been accepted upstream and I proposed
some modifications [5] but I had a very few answers.
The patch review are very slow and done at the last minute at the merge
window and that makes code upstreaming very difficult. It is not a
reproach, it is just how it is and I would like to propose a solution
for that.
I propose to host a cpuidle-next tree where all these modifications will
be and where people can send patches against, preventing last minutes
conflicts and perhaps Lenb will agree to pull from this tree. In the
meantime, the tree will be part of the linux-next, the patches will be
more widely tested and could be fixed earlier.
Thanks
-- Daniel
[1] http://lwn.net/Articles/491257/
[2] http://lwn.net/Articles/464808/
[3] http://summit.linaro.org/
[4]
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67033.html,
http://www.spinics.net/lists/linux-pm/msg27330.html,
http://comments.gmane.org/gmane.linux.ports.arm.omap/76311,
http://www.digipedia.pl/usenet/thread/18885/11795/
[5] https://lkml.org/lkml/2012/6/8/375
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Adding in Linaro Dev list for more visibility...
On Tue, 2012-07-03 at 14:08 -0300, Ricardo Salveti wrote:
> On Tue, Jul 3, 2012 at 10:22 AM, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:
> > Hi Ricardo
> >
> > I notice the new ubuntu.conf seems to contain everything including the
> > kitchen sink. It has things which (as people found out at release time)
> > breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it
> > contains drivers and other support for loads of hardware which isn't
> > present on any Linaro supported device; and if it was, should go in the
> > board specific config fragments, not the Ubuntu one.
>
> This config is basically provided by the official ubuntu kernel
> packages. We just removed a few specific devices, and some which would
> not make much sense, but other then that it's basically the same one
> you can find at your desktop.
>
> It's useful to enable all these additional configs for a bunch of
> reasons, like sharing with Ubuntu, enabling additional usb-based
> devices and such. We have tons of bugs requesting us to add stuff to
> the kernel config, and having this config fragment solves them all.
>
> If there's any hardware specific thing that could be disabled, we
> could just move to the board config. Regarding CONFIG_REGULATORS, I
> just decided to disable it at the vexpress.conf, as it only breaks
> stuff at vexpress (and makes sense to track it there).
Well, the other boards which need regulators already enable it, so
there's not really any need for Ubuntu to have this config. This
particular issue isn't worth worrying about - we'll be adding regulators
to vexpress to enable the single kernel image initiative - but it does
seem to show up a general issue of the blurring of the purpose of config
fragments; if Ubuntu enables a bunch of hardware support, what is the
roll of the board config fragments?
I noticed that the Ubuntu config was patched to remove ATH6KL with the
commit title "should be platform dependent". What was the reasoning for
singling that driver out?
> > I think that for vexpress at least, you have used ubuntu-minimal.conf
> > for the 12.06 release and the current CI jobs. What is the plan going
> > forward? To me, it would seem to make more sense to start with the
> > minimal config and add things as they are found to be missing.
>
> We tried in the past, but that's just too painful. This time we
> decided to give the Ubuntu config a try, and then just disable what we
> know will not be used.
>
> If possible, we'd like to continue using it, and change as needed to
> disable whatever you think it shouldn't be there.
OK, lets see how it goes.
I would like to keep the ubuntu-minimal.conf around and supported, if
for no other that selfish reasons as it produces a much smaller (quicker
to load) kernel and quicker builds, which is useful for anyone wanting
to basic kernel development and testing. (In an ideal world it could be
used on nano and developer images but that isn't worth the complexity of
a second kernel package and hwpack.)
--
Tixy
Hello all,
I've found that linaro android images are getting bigger and I got error
messages when I tried to put images to sdcard. i.e. "No space left on
device" by using linaro-android-media-create. I've been using 4GB sdcard
onto Origen and linaro-android-media-create by "apt-get install
linaro-image-tools" (Ubuntu 11.10).
Is there any configurable re-partitioning option for sdcard on
linaro-android-media-create, or do I need bigger one?
Cheers.
--
Chunsang Jeong
(Paul Jeong)
*
"Whether you believe you can, or you can't, you are right" - Henry Ford*
Hello, linaro-dev,
I just created a TAGS file for the Linaro kernel source and I
noticed that there is a "kernel_build" subdirectory:
/home/work/linux-linaro-lt-omap-3.4-3.4.0/kernel_build
What is the purpose of this directory?
When I run "make ARCH=arm TAGS", it includes the source in this
directory, so it appears that all files are tagged twice.
--
Thank you,
David Cullen
Hello, linaro-dev,
I am trying to follow the instructions at
https://wiki.linaro.org/Source/ImageBuilding
However, when I run "sudo lh build", I get the following output
> P: Setting up cleanup function
> P: Begin caching bootstrap stage...
> P: Begin bootstrapping system...
> P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy.
> P: Running debootstrap (download-only)...
> I: Retrieving Release
> E: Failed getting release file http://ftp.de.debian.org/debian/dists/lenny/Release
> P: Begin unmounting filesystems...
Why is it trying to download files for lenny?
--
Thank you,
David Cullen