Hi Geert,
On Fri, Nov 02, 2012, Geert Schuring wrote:
> Could you tell me if you have any plans to enable Ubuntu on the Raspberry Pi
> (ARMv6) ?
Short answer: an Ubuntu ARMv6 port for the Raspberry Pi isn't a Linaro
target, but we're taking patches and we're interested in some bugs! :-)
There are two main reasons for that:
- Linaro doesn't have the capacity to do large scale distro ports, this
is usually mainly the job of distros, and we're sometimes giving a
hand
- Linaro is all about the future of ARM, so the focus is mainly on ARMv7
and ARMv8 at this point
That said, there is hope! First, a bunch of Linaro folks have a
Raspberry Pi and play with it; second, I believe Ubuntu's armel port is
being re-targeted to ARMv5, so Ubuntu armel binaries should eventually
run on the Pi.
Linaro does directly care about toolchain regressions you might
encounter on ARMv5/ARMv6 (or even on x86), so please do report us any
toolchain regressions caused by Linaro patches.
Cheers,
--
Loïc Minier
From: "hongbo.zhang" <hongbo.zhang(a)linaro.com>
Hi all,
This patch set is to upstream ST-Ericsson thermal driver and fix some bugs
of thermal layer at the same time.
All of these patches are based on v3.7-rc1.
[PATCH 1/5] Thermal: do bind operation after thermal zone or cooling
device register returns.
In the previous bind function, cdev->get_max_state(cdev, &max_state) is called
before the registration function finishes, but at this moment, the parameter
cdev at thermal driver layer isn't ready--it will get ready only after its
registration, so the the get_max_state callback cannot tell the max_state
according to the cdev input.
This problem can be fixed by separating the bind operation out of registration
and doing it when registration completely finished.
There is no such problem with the current exynos thermal driver because it
regsters cooling device before thermal zone device. As a generic thermal layer
any sequence should be supported, thermal zone first or cooling device first,
this will be also helpful to add/remove cooling device dynamically.
[PATCH 2/5] Thermal: add indent for code alignment.
[PATCH 3/5] Thermal: fix empty list checking method.
[PATCH 4/5] Thermal: make sure cpufreq cooling register after
cpufreq driver
Bug fix for generic cpufreq cooling layer as described in the commit logs.
[PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver.
This patch is to add ST-Ericsson into the latest kervel version.
hongbo.zhang (5):
Thermal: do bind operation after thermal zone or cooling device
register returns.
Thermal: add indent for code alignment.
Thermal: fix empty list checking method.
Thermal: make sure cpufreq cooling register after cpufreq driver
Thermal: Add ST-Ericsson db8500 thermal dirver.
arch/arm/boot/dts/dbx5x0.dtsi | 11 +
arch/arm/configs/u8500_defconfig | 4 +
arch/arm/mach-ux500/board-mop500.c | 73 ++++
drivers/thermal/Kconfig | 20 ++
drivers/thermal/Makefile | 2 +
drivers/thermal/cpu_cooling.c | 19 +-
drivers/thermal/db8500_cpufreq_cooling.c | 118 +++++++
drivers/thermal/db8500_thermal.c | 507 +++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 86 +++--
include/linux/platform_data/db8500_thermal.h | 39 +++
10 files changed, 847 insertions(+), 32 deletions(-)
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
--
1.7.11.3
On Thu, Nov 8, 2012 at 2:07 PM, Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> Hi guys,
>
> Sorry if i am on the wrong list :(
Probably a linaro-dev question.
> I found it hard to log on to ask.linaro.org to see if i can answer some queries.
> Or even to ask some queries.
You should be able to use your launchpad id. e.g. for me the openid
url is launchpad.net/~amitk
> I would love to have a mail + mailing-list interface for it. Please point me to
> one if available.
ask.linaro.org is a stackoverflow Q&A interface. There is no mailing
list interface to stackoverflow.
The discussion about having different cpus on the system with
different latencies bring us to a first attemp by adding a
pointer in the cpuidle_device to the states array.
But as Rafael suggested, it would make more sense to create a
driver per cpu [1].
This patch adds support for multiple cpuidle drivers.
It creates a per cpu cpuidle driver pointer.
In order to not break the different drivers, the function cpuidle_register_driver
assign for each cpu, the driver.
The multiple driver support is optional and if it is not set, the cpuide driver
core code remains the same (except some code reorganisation).
I did the following tests compiled, booted, tested without/with CONFIG_CPU_IDLE,
with/without CONFIG_CPU_IDLE_MULTIPLE_DRIVERS.
Tested on Core2 Duo T9500 with acpi_idle [and intel_idle]
Tested on ARM Dual Cortex-A9 U8500 (aka Snowball)
V1 tested on Tegra3 and Vexpress TC2
[1] http://www.spinics.net/lists/linux-acpi/msg37921.html
Changelog:
V2:
* fixed sysfs output : /sys/devices/system/cpu/cpu[0-9]/driver/name
* fixed ifdefs in driver.c
* fixed register_driver function loop when unregistering
* removed WARN under spinlock
* fixed changelog for patch [2/4]
* changed cpuidle_get_cpu_driver function parameter
* removed cpuidle_for_each_driver function
* replaced smp_processor_id() by get_cpu/put_cpu
V3:
* refreshed patchset
Daniel Lezcano (4):
cpuidle: move driver's refcount to cpuidle
cpuidle: move driver checking within the lock section
cpuidle: prepare the driver core to be multi drivers aware
cpuidle: support multiple drivers
drivers/cpuidle/Kconfig | 9 ++
drivers/cpuidle/cpuidle.c | 36 +++++---
drivers/cpuidle/cpuidle.h | 4 +-
drivers/cpuidle/driver.c | 209 ++++++++++++++++++++++++++++++++++++++------
drivers/cpuidle/sysfs.c | 174 ++++++++++++++++++++++++++++++++++++--
include/linux/cpuidle.h | 8 ++-
6 files changed, 388 insertions(+), 52 deletions(-)
--
1.7.5.4
From: "hongbo.zhang" <hongbo.zhang(a)linaro.com>
V3->V4 Changes:
1. In previous patch set V3 "Fix thermal bugs and Upstream ST-Ericsson thermal
driver", there were 5 patches in total, since the first 3 for fixing thermal
layer bugs have been accepted by the maintainer, I'd like to send out the
updated last 2 only this time, for upstreaming ST-Ericsson thermal driver.
2. In patch "Thermal: Add ST-Ericsson DB8500 thermal driver"
- typo in commit message: diver -> driver;
- add more explanation of device tree properties are optional or required.
- in function db8500_thermal_match_cdev: remove cdev_name, use
trip_points->cdev_name[i] directly instead;
- in function db8500_cdev_bind: move cdev->ops->get_max_state(cdev,
&max_state) out of for loop to call it only once;
- in function db8500_thermal_parse_dt: update checking strlen(tmp_str) >=
THERMAL_NAME_LENGTH
- add Reviewed-by: Viresh Kumar <viresh.kumar(a)linaro.org>
- add Reviewed-by: Francesco Lavra <francescolavra.fl(a)gmail.com>
3. In patch "Thermal: Add ST-Ericsson DB8500 thermal properties and platform
data"
- add Reviewed-by: Viresh Kumar <viresh.kumar(a)linaro.org>
hongbo.zhang (2):
Thermal: Add ST-Ericsson DB8500 thermal driver.
Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
.../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++
arch/arm/boot/dts/dbx5x0.dtsi | 14 +
arch/arm/boot/dts/snowball.dts | 31 ++
arch/arm/configs/u8500_defconfig | 2 +
arch/arm/mach-ux500/board-mop500.c | 64 +++
drivers/thermal/Kconfig | 20 +
drivers/thermal/Makefile | 2 +
drivers/thermal/db8500_cpufreq_cooling.c | 108 +++++
drivers/thermal/db8500_thermal.c | 530 +++++++++++++++++++++
include/linux/platform_data/db8500_thermal.h | 38 ++
10 files changed, 853 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
--
1.7.11.3
Hi Ingo/Peter,
I am trying to understand the complex scheduler code and just found
something incorrect (maybe i am not reading it well):
File: kernel/sched/fair.c
static void
prio_changed_fair(struct rq *rq, struct task_struct *p, int oldprio)
{
if (!p->se.on_rq)
return;
/*
* Reschedule if we are currently running on this runqueue and
* our priority decreased, or if we are not currently running on
* this runqueue and our priority is higher than the current's
*/
if (rq->curr == p) {
if (p->prio > oldprio)
resched_task(rq->curr);
} else
check_preempt_curr(rq, p, 0);
}
Comment says that we must mark the task to be rescheduled, if we
are currently running and our priority has decreased. But in code we
are checking (p->prio > oldprio). i.e. reschedule if we were currently
running and our priority increased.
Sorry if i am wrong :(
--
viresh
Currently when none of CONFIG_NET_DSA_TAG_DSA, CONFIG_NET_DSA_TAG_EDSA and
CONFIG_NET_DSA_TAG_TRAILER is defined, we get following compilation warnings:
net/dsa/slave.c:51:12: warning: 'dsa_slave_init' defined but not used [-Wunused-function]
net/dsa/slave.c:60:12: warning: 'dsa_slave_open' defined but not used [-Wunused-function]
net/dsa/slave.c:98:12: warning: 'dsa_slave_close' defined but not used [-Wunused-function]
net/dsa/slave.c:116:13: warning: 'dsa_slave_change_rx_flags' defined but not used [-Wunused-function]
net/dsa/slave.c:127:13: warning: 'dsa_slave_set_rx_mode' defined but not used [-Wunused-function]
net/dsa/slave.c:136:12: warning: 'dsa_slave_set_mac_address' defined but not used [-Wunused-function]
net/dsa/slave.c:164:12: warning: 'dsa_slave_ioctl' defined but not used [-Wunused-function]
Fix them by enclosing these routines under #ifdef,endif.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
net/dsa/slave.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index e32083d..5606fae 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -48,6 +48,8 @@ void dsa_slave_mii_bus_init(struct dsa_switch *ds)
/* slave device handling ****************************************************/
+#if defined(CONFIG_NET_DSA_TAG_DSA) || defined(CONFIG_NET_DSA_TAG_EDSA) || \
+ defined(CONFIG_NET_DSA_TAG_TRAILER)
static int dsa_slave_init(struct net_device *dev)
{
struct dsa_slave_priv *p = netdev_priv(dev);
@@ -170,6 +172,8 @@ static int dsa_slave_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
return -EOPNOTSUPP;
}
+#endif /* defined(CONFIG_NET_DSA_TAG_DSA) || defined(CONFIG_NET_DSA_TAG_EDSA ||
+ defined(CONFIG_NET_DSA_TAG_TRAILER) */
/* ethtool operations *******************************************************/
--
1.7.12.rc2.18.g61b472e
Hi Andrey
Two weeks ago ARM released a new version of Developer Studio 5 (v5.12)
which as usual included a new version of the Streamline plugin and the
corresponding new versions of the Gator daemon and module which run on
the target device.
I have updated my tracking branch which is pulled into
linux-linaro-core-tracking so Linaro's Linux 3.7 kernels will get this
new Gator version. However, I suspect that some builds will be staying
with Linux 3.6 for a while so I have a separate topic branch suitable
for pulling into this. I'm not completely sure how such branches will be
managed but, if it is possible, can the Gator version in 3.6 be replaced
by the new one from the branch '3.6-armlt-gator-5.12' in ARM LT tree
(git://git.linaro.org/landing-teams/working/arm/kernel) ?
Thanks
--
Tixy
Postmortem and lessons learned for Linaro's release 2012.10
https://wiki.linaro.org/Cycles/1210/Release/Review
Highlights and Key Successes
============================
http://www.linaro.org/downloads/1210
Linaro is now making early ARMv8 images available to interested
developers. For a primer on the ARMv8 architecture, the AArch64
execution state and the A64 instruction set, please visit the ARM
portal. While there is currently no ARMv8 hardware available, ARM and
Linaro have developed support for AArch64/A64 against virtual
platforms and started sending the resulting patches to various open
source projects. For more information on these ARMv8 images please
take a look at the Linaro Engineer pages on the Linaro website.
Work on big.LITTLE continues as the Linaro Kernel Working Group
highlights its completion of TC2 support; noting that TC2 now boots
with the latest IKS tree. Five new test cases have been added to
handle simultaneous thread switching, important bugs such as Switcher
Thumb-2 bug and Switcher deadlock issue when working on the
memblock_steal(), vlock remaining locked under certain conditions were
fixed along with and updated focus to run benchmarks with the latest
IKS on TC2 to find optimization opportunities.
Postmortem and Lessons Learned
==============================
As a better way for the integration groups to prioritize their
planning for each cycle, the platform group has begun to implement a
short planning sign-off session for each team. After the team plans
the milestone, plans will be reviewed and signed off.
The general question that is to be answered is that "for this cycle is
the roadmap story complete?"
The format incorporates
* Roadmap Card Review
* General Planning
* blueprints
* bugs
* maintenance
* Resources
* vacations
* vacancies
* action items
One item that continues to irritate is the TC2 board that is stuck in
customs in India. A major effort was expended to try and free it, but
it is still in stasis.
Blueprints
=========
The number of high or essential priority blueprints that missed the cycle:
Android 4 out of 13
Developer Platform 3 out of 7
Infrastructure 3 out of 6
Lava 3 out of 7
QA 2 out of 5
Total 15 out of 38
39% of high or essential priority blueprints scheduled for this cycle
were not delivered.
Total blueprints: 27 out of 54 missed the cycle.
High priority missed blueprints recap:
12.05: 19 out of 48, 39%
12.06: 13 out of 31, 42%
12.07: 14 out of 31, 45%
12.08: 6 out of 26, 23%
12.09: 9 out of 28, 32%
12.010: 15 out of 38, 39%
* Not included is data from working groups and landing teams
Source:
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AjEaTwrvj1bidHBfe…
--
David Zinman, Project Manager
Linaro.org | Open source software for ARM SoCs
