Dear ARM fans,
Linaro Developer Platform team organises every week (Wednesday 14:00 -
18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to
fix userspace portability issues across the board. The list of bugs
being worked on
is at launchpad:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby…
Interested in making the software in Ubuntu run better on ARM? Join us on
the #linaro channel on irc.linaro.org (aka freenode) today!
Cheers,
Riku
Hi All,
These two patches are a proposal of memory mapped virtio device.
The main goal was to provide an equivalent of the virtio PCI device,
happily used by KVM an qemu on x86, which could be used by PCI-less
platforms (common in ARM world). The interface exposed by my device
is very similar to the original virtio_pci one, maybe just a little
bit simplified (no sophisticated IRQ infrastructure here). Of course
all the control registers live in memory space, instead of PCI IO
space (writel vs iowrite32).
This raises an obvious question whether these two implementation
could share some common code. Probably some constant values could
be shared (like VIRTIO_*_HOST_FEATURES or VIRTIO_*_VRING_ALIGN),
maybe struct virtio_*_vq_info as well. On the other hand the vring
interface itself is an abstraction layer already... I really don't
know, all comments and ideas appreciated.
The second thing is AMBAness of the driver... I've decided to
make it an AMBA device rather than simple platform device to add
at least a touch of "dicoverability". The idea was simple - one
can add "permanent" virtio AMBA device in the kernel placing it
somewhere in reserved area of real hardware, so the kernel running
on hardware will not get correct amba_id value and ignore the
device. With the eve of Ultimate DeviceTreenes this argument is
slightly out of date, as qemu could add the virtio device even in
runtime. So maybe I should convert it into platform_device then?
This brings additional problem though. Magnus Damm already proposed
a platform virtio device here:
http://thread.gmane.org/gmane.linux.ports.sh.devel/11554
however it's something completely different, as his use case is a
heterogeneous system and the virtio is used mainly as a transport
between nodes. It also uses lguest-based interface, which is much
less applicable to the qemu reality.
Let me just add that Peter Maydell kindly agreed to work on the
qemu side of the problem, once there is some consensus about the
kernel part. He also suggested to send this to linaro-dev first,
before throwing it into LKML fire. So here I am :-)
All comments welcome!
Paweł
Pawel Moll (2):
arm: Add VIRTUALIZATION configuration menu and virtio options
arm: Add AMBA bus driver for virtio device
arch/arm/Kconfig | 16 ++
drivers/virtio/Kconfig | 11 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_amba.c | 443 ++++++++++++++++++++++++++++++++++++++++++
include/linux/virtio_amba.h | 62 ++++++
5 files changed, 533 insertions(+), 0 deletions(-)
create mode 100644 drivers/virtio/virtio_amba.c
create mode 100644 include/linux/virtio_amba.h
The same clock is used for all cpus so we must notify the frequency change
for each one in order to update the configuration of all twd clockevents.
Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org>
---
drivers/cpufreq/db8500-cpufreq.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
index 0d8dd1c..4cb5785 100644
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ b/drivers/cpufreq/db8500-cpufreq.c
@@ -76,13 +76,13 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
freqs.old = policy->cur;
freqs.new = freq_table[idx].frequency;
- freqs.cpu = policy->cpu;
if (freqs.old == freqs.new)
return 0;
/* pre-change notification */
- cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ for_each_online_cpu(freqs.cpu)
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
/* request the PRCM unit for opp change */
if (prcmu_set_arm_opp(idx2opp[idx])) {
@@ -91,7 +91,8 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
}
/* post change notification */
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ for_each_online_cpu(freqs.cpu)
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
return 0;
}
--
1.7.4.1
I've decided to take a look at this moderately quiet l.k.embedded list
and noticed this question:
Is it possible to debug multi-threaded applications using gdb on ARM
these days?
http://thread.gmane.org/gmane.linux.kernel.embedded/3631
This is completely supported now, right?
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs