linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[RFC PATCH] PM / devfreq: Add runtime-pm support

by Rajagopal Venkat

Instead of devfreq device driver explicitly calling devfreq suspend and resume apis perhaps from runtime-pm suspend and resume callbacks, let devfreq core handle it automatically. Attach devfreq core to runtime-pm framework so that, devfreq device driver pm_runtime_suspend() will automatically suspend the devfreq and pm_runtime_resume() will resume the devfreq. Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org> --- drivers/devfreq/devfreq.c | 89 ++++++++++++++++++++++++++++++++++++++------- include/linux/devfreq.h | 12 ------ 2 files changed, 76 insertions(+), 25 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 4c50235..781ea47 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -25,10 +25,9 @@ #include <linux/list.h> #include <linux/printk.h> #include <linux/hrtimer.h> +#include <linux/pm_runtime.h> #include "governor.h" -static struct class *devfreq_class; - /* * devfreq core provides delayed work based load monitoring helper * functions. Governors can use these or can implement their own @@ -42,6 +41,9 @@ static LIST_HEAD(devfreq_governor_list); static LIST_HEAD(devfreq_list); static DEFINE_MUTEX(devfreq_list_lock); +static int devfreq_suspend_device(struct devfreq *devfreq); +static int devfreq_resume_device(struct devfreq *devfreq); + /** * find_device_devfreq() - find devfreq struct using device pointer * @dev: device pointer used to lookup device devfreq. @@ -453,6 +455,61 @@ static void devfreq_dev_release(struct device *dev) _remove_devfreq(devfreq, true); } +static int devfreq_runtime_suspend(struct device *dev) +{ + int ret; + struct devfreq *devfreq; + + mutex_lock(&devfreq_list_lock); + devfreq = find_device_devfreq(dev); + mutex_unlock(&devfreq_list_lock); + + ret = devfreq_suspend_device(devfreq); + if (ret < 0) + goto out; + + ret = pm_generic_runtime_suspend(dev); +out: + return ret; +} + +static int devfreq_runtime_resume(struct device *dev) +{ + int ret; + struct devfreq *devfreq; + + mutex_lock(&devfreq_list_lock); + devfreq = find_device_devfreq(dev); + mutex_unlock(&devfreq_list_lock); + + ret = devfreq_resume_device(devfreq); + if (ret < 0) + goto out; + + ret = pm_generic_runtime_resume(dev); +out: + return ret; +} + +static int devfreq_runtime_idle(struct device *dev) +{ + return pm_generic_runtime_idle(dev); +} + +static const struct dev_pm_ops devfreq_pm_ops = { + SET_RUNTIME_PM_OPS( + devfreq_runtime_suspend, + devfreq_runtime_resume, + devfreq_runtime_idle + ) +}; + +static struct class devfreq_class = { + .name = "devfreq", + .owner = THIS_MODULE, + .pm = &devfreq_pm_ops, +}; + /** * devfreq_add_device() - Add devfreq feature to the device * @dev: the device to add devfreq feature. @@ -494,8 +551,9 @@ struct devfreq *devfreq_add_device(struct device *dev, mutex_init(&devfreq->lock); mutex_lock(&devfreq->lock); + dev->class = &devfreq_class; devfreq->dev.parent = dev; - devfreq->dev.class = devfreq_class; + devfreq->dev.class = &devfreq_class; devfreq->dev.release = devfreq_dev_release; devfreq->profile = profile; strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN); @@ -538,6 +596,9 @@ struct devfreq *devfreq_add_device(struct device *dev, goto err_init; } + pm_runtime_get_noresume(dev); + pm_runtime_set_active(dev); + return devfreq; err_init: @@ -569,7 +630,7 @@ EXPORT_SYMBOL(devfreq_remove_device); * devfreq_suspend_device() - Suspend devfreq of a device. * @devfreq: the devfreq instance to be suspended */ -int devfreq_suspend_device(struct devfreq *devfreq) +static int devfreq_suspend_device(struct devfreq *devfreq) { if (!devfreq) return -EINVAL; @@ -580,13 +641,12 @@ int devfreq_suspend_device(struct devfreq *devfreq) return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_SUSPEND, NULL); } -EXPORT_SYMBOL(devfreq_suspend_device); /** * devfreq_resume_device() - Resume devfreq of a device. * @devfreq: the devfreq instance to be resumed */ -int devfreq_resume_device(struct devfreq *devfreq) +static int devfreq_resume_device(struct devfreq *devfreq) { if (!devfreq) return -EINVAL; @@ -597,12 +657,12 @@ int devfreq_resume_device(struct devfreq *devfreq) return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_RESUME, NULL); } -EXPORT_SYMBOL(devfreq_resume_device); /** * devfreq_add_governor() - Add devfreq governor * @governor: the devfreq governor to be added */ + int devfreq_add_governor(struct devfreq_governor *governor) { struct devfreq_governor *g; @@ -770,6 +830,7 @@ out: ret = count; return ret; } + static ssize_t show_available_governors(struct device *d, struct device_attribute *attr, char *buf) @@ -992,19 +1053,21 @@ static struct device_attribute devfreq_attrs[] = { static int __init devfreq_init(void) { - devfreq_class = class_create(THIS_MODULE, "devfreq"); - if (IS_ERR(devfreq_class)) { + int err; + + err = class_register(&devfreq_class); + if (err < 0) { pr_err("%s: couldn't create class\n", __FILE__); - return PTR_ERR(devfreq_class); + return err; } devfreq_wq = create_freezable_workqueue("devfreq_wq"); if (IS_ERR(devfreq_wq)) { - class_destroy(devfreq_class); + class_unregister(&devfreq_class); pr_err("%s: couldn't create workqueue\n", __FILE__); return PTR_ERR(devfreq_wq); } - devfreq_class->dev_attrs = devfreq_attrs; + devfreq_class.dev_attrs = devfreq_attrs; return 0; } @@ -1012,7 +1075,7 @@ subsys_initcall(devfreq_init); static void __exit devfreq_exit(void) { - class_destroy(devfreq_class); + class_unregister(&devfreq_class); destroy_workqueue(devfreq_wq); } module_exit(devfreq_exit); diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h index e83ef39..b84840c 100644 --- a/include/linux/devfreq.h +++ b/include/linux/devfreq.h @@ -181,8 +181,6 @@ extern struct devfreq *devfreq_add_device(struct device *dev, const char *governor_name, void *data); extern int devfreq_remove_device(struct devfreq *devfreq); -extern int devfreq_suspend_device(struct devfreq *devfreq); -extern int devfreq_resume_device(struct devfreq *devfreq); /* Helper functions for devfreq user device driver with OPP. */ extern struct opp *devfreq_recommended_opp(struct device *dev, @@ -226,16 +224,6 @@ static int devfreq_remove_device(struct devfreq *devfreq) return 0; } -static int devfreq_suspend_device(struct devfreq *devfreq) -{ - return 0; -} - -static int devfreq_resume_device(struct devfreq *devfreq) -{ - return 0; -} - static struct opp *devfreq_recommended_opp(struct device *dev, unsigned long *freq, u32 flags) { -- 1.7.10.4

12 years, 10 months

Re: [PATCH] cpuidle: fix number of initialized/destroyed states

by Daniel Lezcano

On 01/07/2013 10:58 PM, Rafael J. Wysocki wrote: > Hi, > > Thanks for the patch! > > I'd like Daniel to have a look at it still. I agree with this patch. I was about to send exactly the same. Thanks Krzysztof for fixing this. > On Monday, January 07, 2013 08:12:01 PM Krzysztof Mazur wrote: >> Commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 (cpuidle: support >> multiple drivers) changed the number of initialized state kobjects >> in cpuidle_add_state_sysfs() from device->state_count to drv->state_count, >> but leaved device->state_count in cpuidle_remove_state_sysfs(). >> Those two values might have different values, causing for instance >> NULL pointer dereference in cpuidle_remove_state_sysfs(). >> >> Signed-off-by: Krzysztof Mazur <krzysiek(a)podlesie.net> Acked-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> -- <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

12 years, 10 months

[PATCH 0/2] hw_breakpoint debug over powerdown

by Dietmar Eggemann

This patchset updates OS Save and Restore mechanism for v7 and v7.1 debug for self-hosted debug powerdown support to Linux 3.8-rc2. v7 debug for self-hosted debug tested on Pandaboard (A9) which unfortunately does not support OS Save and Restore. v7.1 debug for self-hosted debug tested on TC2 big.LITTLE testchip (cpuidle, on both A7 and A15 clusters). Gdb (version 7.5.50.20121105-cvs) was used as the self-hosted debugger. This patchset is against commit e01b52e 'Merge branch 'next-armlt-arm64' into integration-next' on linaro_landing_team/integration-next . It replaces the patch 'ARM: hw_breakpoint: v7.1 self-hosted debug powerdown support'. Dietmar Eggemann (2): ARM: hw_breakpoint: Check function for OS Save and Restore mechanism ARM: hw_breakpoint: Debug powerdown support for self-hosted debug arch/arm/include/asm/hw_breakpoint.h | 3 ++ arch/arm/kernel/hw_breakpoint.c | 56 +++++++++++++++++++++++++++++++--- 2 files changed, 54 insertions(+), 5 deletions(-) -- 1.7.9.5

12 years, 10 months

[PATCH v4 00/24] Introduce Xen support on ARM (based on 3.6-rc5)

by Stefano Stabellini

Hi all, this patch series implements Xen support for ARMv7 with virtualization extensions. It allows a Linux guest to boot as dom0 and as domU on Xen on ARM. PV console, disk and network frontends and backends are all working correctly. It has been tested on a Versatile Express Cortex A15 emulator, using the latest Xen ARM developement branch (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus the "ARM hypercall ABI: 64 bit ready" patch series (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546). The patch marked with [HACK] has been dropped from this series, however you can find it here: http://marc.info/?l=linux-kernel&m=134513277823527&w=2. I am also attaching to this email the dts'es that I am currently using for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to Linux by Xen, while vexpress-virt.dts is the dts used for other domUs and it is appended in binary form to the guest kernel image. I am not sure where they are supposed to live yet, so I am just attaching them here so that people can actually try out this series if they want to. Comments are very welcome! Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not present" touches generic ARM code and still needs to be acked/reviewed. Arnd, Russell, what do you think about this series? If you are OK with it, to whom should I submit it? Changes in v4: - rebase on 3.6-rc5; - devicetree: "xen,xen" should be last as it is less specific; - devicetree: use 2 address-cells and 2 size-cells in the reg property; - do not xs_reset_watches on dom0; - compile drivers/xen/pcpu.c only on x86; - use "+=" instead of ":=" for dom0- targets; - add a patch to update the MAINTAINERS file. Changes in v3: - move patches that have been picked up by Konrad at the end of the series; - improve comments; - add a doc to describe the Xen Device Tree format; - do not use xen_ulong_t for multicalls and apic_physbase; - add a patch at the end of the series to use the new __HVC macro; - add missing pvclock-abi.h include to ia64 header files; - do not use an anonymous union in struct xen_add_to_physmap. Changes in v2: - fix up many comments and commit messages; - remove the early_printk patches: rely on the emulated serial for now; - remove the xen_guest_init patch: without any PV early_printk, we don't need any early call to xen_guest_init, we can rely on core_initcall alone; - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if at the moment is unused; - use ldm instead of pop in the hypercall wrappers; - return -ENOSYS rather than -1 from the unimplemented grant_table functions; - remove the pvclock ifdef in the Xen headers; - remove include linux/types.h from xen/interface/xen.h; - replace pr_info with pr_debug in xen_guest_init; - add a new patch to introduce xen_ulong_t and use it top replace all the occurences of unsigned long in the public Xen interface; - explicitely size all the pointers to 64 bit on ARM, so that the hypercall ABI is "64 bit ready"; - clean up xenbus_init; - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI; - mark Xen guest support on ARM as EXPERIMENTAL; - introduce GRANT_TABLE_PHYSADDR; - remove unneeded initialization of boot_max_nr_grant_frames; - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c; - return -EINVAL from xen_remap_domain_mfn_range if auto_translated_physmap; - retain binary compatibility in xen_add_to_physmap: use a union to introduce foreign_domid. Shortlog and diffstat: Stefano Stabellini (24): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions docs: Xen ARM DT bindings xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_pfn_t for pfn and mfn types xen/arm: Introduce xen_ulong_t for unsigned long xen/arm: compile and run xenbus xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen: allow privcmd for HVM guests xen/arm: compile blkfront and blkback xen/arm: compile netback arm/v2m: initialize arch_timers even if v2m_timer is not present xen: missing includes xen: update xen_add_to_physmap interface MAINTAINERS: add myself as Xen ARM maintainer Documentation/devicetree/bindings/arm/xen.txt | 22 ++++ MAINTAINERS | 7 + arch/arm/Kconfig | 10 ++ arch/arm/Makefile | 1 + arch/arm/include/asm/hypervisor.h | 6 + arch/arm/include/asm/sync_bitops.h | 27 ++++ arch/arm/include/asm/xen/events.h | 18 +++ arch/arm/include/asm/xen/hypercall.h | 69 ++++++++++ arch/arm/include/asm/xen/hypervisor.h | 19 +++ arch/arm/include/asm/xen/interface.h | 73 +++++++++++ arch/arm/include/asm/xen/page.h | 82 ++++++++++++ arch/arm/mach-vexpress/v2m.c | 11 +- arch/arm/xen/Makefile | 1 + arch/arm/xen/enlighten.c | 168 +++++++++++++++++++++++++ arch/arm/xen/grant-table.c | 53 ++++++++ arch/arm/xen/hypercall.S | 106 ++++++++++++++++ arch/ia64/include/asm/xen/interface.h | 8 +- arch/x86/include/asm/xen/interface.h | 8 ++ arch/x86/xen/enlighten.c | 1 + arch/x86/xen/irq.c | 1 + arch/x86/xen/mmu.c | 3 + arch/x86/xen/xen-ops.h | 1 - drivers/block/xen-blkback/blkback.c | 1 + drivers/net/xen-netback/netback.c | 1 + drivers/net/xen-netfront.c | 1 + drivers/tty/hvc/hvc_xen.c | 2 + drivers/xen/Makefile | 13 ++- drivers/xen/events.c | 18 +++- drivers/xen/grant-table.c | 1 + drivers/xen/privcmd.c | 4 - drivers/xen/xenbus/xenbus_comms.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 62 +++++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 +- include/xen/events.h | 2 + include/xen/interface/features.h | 3 + include/xen/interface/grant_table.h | 4 +- include/xen/interface/io/protocols.h | 3 + include/xen/interface/memory.h | 21 ++-- include/xen/interface/physdev.h | 2 +- include/xen/interface/platform.h | 4 +- include/xen/interface/version.h | 2 +- include/xen/interface/xen.h | 7 +- include/xen/privcmd.h | 3 +- include/xen/xen.h | 2 +- 45 files changed, 796 insertions(+), 61 deletions(-) A branch based on 3.6-rc5 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4 Cheers, Stefano

12 years, 10 months

When do we plan to move to Linux 3.8?

by Jon Medhurst (Tixy)

Hi All I assume we'll be moving to Linux 3.8 for the January release cycle? For my part I have prepared a 3.8 branch for vexpress [1] which doesn't yet contain Android patches or bit.LITTLE MP as their respective branches aren't on 3.8 yet. [1] http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=short… -- Tixy

12 years, 10 months

[PATCH] bootwrapper: CPU hotplug aware boot protocol

by Jon Medhurst (Tixy)

To enable CPU hotplug the need to provide some boot code at the reset vector and which survives after the kernel has booted without being overwritten. We achieve this by the getting the linker script to place the code in boot.S at address zero. This now means we can delete the code that relocates the secondary CPU pen code to "a location less likely to be overridden". We then modify the boot protocol slightly to allow hot-plugging of any CPU, including CPU #0, when the system is already booted. This is done by checking if SYS_FLAGS is already set before the normal check for CPU0 and the boot-or-wait decision made. This patch is based on work by Nicolas Pitre. Signed-off-by: Nicolas Pitre <nico(a)linaro.org> Signed-off-by: Jon Medhurst <tixy(a)linaro.org> --- boot.S | 41 ++++++++++++++++++++++++----------------- model.lds.S | 3 ++- 2 files changed, 26 insertions(+), 18 deletions(-) diff --git a/boot.S b/boot.S index dd453e3..fb56693 100644 --- a/boot.S +++ b/boot.S @@ -12,6 +12,8 @@ .arch_extension virt .text + b start @ Must be first instruction for power on reset vector + .macro enter_hyp @ We assume we're entered in Secure Supervisor mode. To @ get to Hyp mode we have to pass through Monitor mode @@ -119,27 +121,32 @@ start: orr r0, r0, r1 mcr p15, 0, r0, c1, c1, 2 - @ Check CPU nr again - mrc p15, 0, r0, c0, c0, 5 @ MPIDR (ARMv7 only) - bfc r0, #24, #8 @ CPU number, taking multicluster into account - cmp r0, #0 @ primary CPU? - beq 2f - - @ - @ Secondary CPUs (following the RealView SMP booting protocol) - @ - enter_hyp - - ldr r1, =fs_start - 0x100 - adr r2, 1f - ldmia r2, {r3 - r7} @ move the code to a location - stmia r1, {r3 - r7} @ less likely to be overridden + /* + * If SYS_FLAGS is already set, this is a warm boot and we blindly + * branch to the indicated address right away, irrespective of the + * CPU we are. + */ #ifdef VEXPRESS ldr r0, =0x1c010030 @ VE SYS_FLAGS register #else ldr r0, =0x10000030 @ RealView SYS_FLAGS register #endif - mov pc, r1 @ branch to the relocated code + ldr r1, [r0] + cmp r1, #0 + beq 1f + enter_hyp + bx r1 +1: + /* + * Otherwise this is a cold boot. In this case it depends if + * we are the primary CPU or not. The primary CPU boots the system + * while the secondaries wait for the primary to set SYS_FLAGS. + */ + mrc p15, 0, r1, c0, c0, 5 + bics r1, #0xff000000 + beq 2f + + enter_hyp 1: #ifdef VEXPRESS wfe @@ -147,7 +154,7 @@ start: ldr r1, [r0] cmp r1, #0 beq 1b - mov pc, r1 @ branch to the given address + bx r1 @ branch to the given address #endif 2: diff --git a/model.lds.S b/model.lds.S index 793df89..f37824e 100644 --- a/model.lds.S +++ b/model.lds.S @@ -27,7 +27,8 @@ STACKTOP = 0xff000000; SECTIONS { - . = PHYS_OFFSET; + . = 0; + .boot : { boot.o } . = PHYS_OFFSET + 0x8000 - 0x40; -- 1.7.10.4

12 years, 10 months

[PATCH 1/2] ab8500: remove explicit handling of battery type

by Rajanikanth H.V

From: "Rajanikanth H.V" <rajanikanth.hv(a)stericsson.com> dt property, 'battery-type' shall be one of supported technology type instead blank. refer:Documentation/devicetree/bindings/power_supply/ab8500/fg.txt for the list of supported types thanks to Francesco Lavra for highlighting missing of_node_put(...) for '3.7-rc5': of git://git.infradead.org/battery-2.6.git Acked-by: Lee Jones <lee.jones(a)linaro.org> Signed-off-by: Rajanikanth H.V <rajanikanth.hv(a)stericsson.com> --- drivers/power/ab8500_bmdata.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c index 03cc528..2230b2c 100644 --- a/drivers/power/ab8500_bmdata.c +++ b/drivers/power/ab8500_bmdata.c @@ -461,7 +461,6 @@ bmdevs_of_probe(struct device *dev, struct device_node *np_bat_supply; struct abx500_bm_data *bat; const char *btech; - char bat_tech[8]; int i, thermistor; *battery = &ab8500_bm_data; @@ -488,12 +487,10 @@ bmdevs_of_probe(struct device *dev, "stericsson,battery-type", NULL); if (!btech) { dev_warn(dev, "missing property battery-name/type\n"); - strcpy(bat_tech, "UNKNOWN"); - } else { - strcpy(bat_tech, btech); + of_node_put(np_bat_supply); + return -EINVAL; } - - if (strncmp(bat_tech, "LION", 4) == 0) { + if (strncmp(btech, "LION", 4) == 0) { bat->no_maintenance = true; bat->chg_unknown_bat = true; bat->bat_type[BATTERY_UNKNOWN].charge_full_design = 2600; @@ -508,7 +505,7 @@ bmdevs_of_probe(struct device *dev, if (thermistor == NTC_EXTERNAL) { btype->batres_tbl = temp_to_batres_tbl_ext_thermistor; - } else if (strncmp(bat_tech, "LION", 4) == 0) { + } else if (strncmp(btech, "LION", 4) == 0) { btype->batres_tbl = temp_to_batres_tbl_9100; } else { -- 1.7.10.4

12 years, 10 months

[RFC] KVM on arm64

by Anup Patel

Hi Marc, We tried kvm-arm64/soc-armv8-kvm branch from your git tree on v8 Foundation Model but we dont get any prints on serial terminal. We followed the step mentioned in https://wiki.linaro.org/HowTo/BuildArm64Kernel except: 1. We used kernel compiled from kvm-arm64/soc-armv8-kvm branche from your git tree. 2. We used vexpress-foundation-v8.dts from git:// git.linaro.org/kernel/linaro-aarch64.git What are we missing here ? Regards, Anup ---------- Forwarded message ---------- From: marc.zyngier at arm.com (Marc Zyngier) To: Cc: Date: Wed, 19 Dec 2012 11:59:39 +0000 Subject: [kvmarm] [RFC] KVM on arm64 As I'm about to go in turkey mode for a few days, I thought it would be good to let people have a taste of KVM on arm64. At least for those who are not following the same path... So this is the first public drop of KVM/arm64. It supports: - arm and arm64 guests - SMP host and guest - 4kB and 64kB pages (both as a host and as a guest) - Virtual GIC - Architected timers It has been tested on ARMv8 VE model as well as the Foundation Model (after reworking the DTS), using Will Deacon's excellent port of kvmtool to arm64 for the platform emulation side (with virtio for console, block device, networking...). We happily booted guests using the Linaro OE filesystem (64bit) as well Debian and Ubuntu (32bit). It reuses a fair amount of the KVM/arm port source code and general architecture, though there still some work to be done in order to share more code. It currently relies on so much out of tree code that I'm not even trying to post the patches, hence merely signaling the existence of the port. The code sits in a number of (non-stable) branches at git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git - kvm-arm64/pre-arm64-cleanup: Christoffer Dall's kvm-arm-master branch plus a number of patches reorganizing some parts of the KVM/arm code in order to reuse them on arm64. - kvm-arm64/psci: the above, plus the implementation of the Power State Coordination Interface - kvm-arm64/soc-armv8-kvm: a merge of Catalin Marinas' soc-armv8-model branch and the above. - kvm-arm64/soc-armv8-kvm- prereq: the above, plus a bunch of patches adding the KVM prerequisites (including an architected timer rework courtesy of Mark Rutland). - kvm-arm64/soc-armv8-kvm-arm64: The turkey itself. - kvm-arm64/kvmtool: The above, with stuffing, vegs and gravy. Enjoy. The soc-armv8-kvm-arm64 branch contains patches that are roughly split by theme (world switch, MMU, exit handling...), but does not yet reflect the way I intend to split them before review. The code is currently based on v3.7 + kvm-next. Don't try it if you're not prepared to tinker with what is essentially experimental, fast changing and probably broken code (though my tests seem to show that it is solid enough. YMMV). What is missing: - FP access from userspace - COMPAT layer for 32bit userspace As always, comments are welcome, though I may be a bit slow to reply... M. -- Jazz is not dead. It just smells funny...

12 years, 10 months

booting an exynos

by Daniel Lezcano

Hi All, happy new year ! I am trying to boot my exynos board for the first time but I have no console output (the line shows "offline"). I used a serial-usb with minicom and screen. The web site origenboard.org is down, so I have no information available. Is there a trick I missed ? Did anyone face this problem ? Thanks -- Daniel -- <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

12 years, 10 months

HMP patches v2

by Liviu Dudau

Hi Viresh, Here are the latest patches for HMP tunables to be included in the MP branch for the 12.11 release. They depend on Vincent Guittot's patches that you have on -exp-v12 branch which we need included in the PULL request. Testing shows that they improve power consumption for HMP. Thanks, Liviu

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev