* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-12-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962480933.163666.1481741832090@email.1und1.de>
Hi Stefan,
On Wed, 2016-12-14 at 19:57 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
[snip]
> > >
> > > did you try cyclictest [1]?
> >
> > Not yet. Not sure what to measure and which values to compare here.
>
> i tought you have the vendor kernel and the mainline kernel available
> for your platform.
>
> So you could compare the both kernels.
Yes, that's right. I will have a look at this tool.
> >
> > >
> > > Beside the time for a request the amount of requests for the
> > > complete
> > > iperf test
> > > would we interesting. Maybe there are retries.
> > >
> > > I'm still interested in your PIO mode patches for mxs-mmc even
> > > without clean up.
> >
> > Actually, the patch does not implement a PIO mode, but drops DMA
> > and
> > uses polling instead. I've attached the patch.
>
> Thanks. I applied it, but unfortunately this breaks SD card support
> for my Duckbill and the kernel isn't able to mount the rootfs:
>
> [????2.267073] mxs-mmc 80010000.ssp: initialized
> [????2.272624] mxs-mmc 80010000.ssp: AC command error 0xffffff92
Sorry, I messed up the branches. I attached the correct patch which is
working for me on Linux v4.9.
J?rg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0200-mmc-mxs-mmc-use-PIO-mode.patch
Type: text/x-patch
Size: 15450 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/b5c33807/attachment-0001.bin>
^ permalink raw reply
* [PATCH 33/37] ARM: dts: vf610m4-cosmic: Correct license text
From: Afzal Mohammed @ 2016-12-15 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235746.7108-34-alexandre.belloni@free-electrons.com>
Hi,
On Thu, Dec 15, 2016 at 12:57:42AM +0100, Alexandre Belloni wrote:
> The license test has been mangled at some point then copy pasted across
The patch text has been mangled at this point ... ;)
> multiple files. Restore it to what it should be.
> Note that this is not intended as a license change.
Acked-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Regards
afzal
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-15 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212104243.GA21248@arm.com>
On 12/12/2016 04:12 PM, Will Deacon wrote:
> On Mon, Dec 12, 2016 at 10:31:52AM +0530, Srinivas Ramana wrote:
>> On 12/06/2016 05:43 PM, Will Deacon wrote:
>>> On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
>>>> On 12/02/2016 04:38 PM, Will Deacon wrote:
>>>>> On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
>>>>>> Extend the trace_clock to support the arch timer cycle
>>>>>> counter so that we can get the monotonic cycle count
>>>>>> in the traces. This will help in correlating the traces with the
>>>>>> timestamps/events in other subsystems in the soc which share
>>>>>> this common counter for driving their timers.
>>>>>
>>>>> I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
>>>>> particular, the "perf" trace_clock hangs off sched_clock, which should
>>>>> be backed by the architected counter anyway. What does the cycle counter in
>>>>> isolation tell you, given that the frequency isn't architected?
>>>>>
>>>>> I think I'm missing something here.
>>>>>
>>>>
>>>> Having cycle counter would help in the cases where we want to correlate the
>>>> time with other subsystems which are outside cpu subsystem.
>>>
>>> Do you have an example of these subsystems? Can they be used to generate
>>> trace data with mainline?
>>
>> Some of the subsystems i can list are Modem(on a mobilephone), GPU or video
>> subsystem, or a DSP among others.
>
> Oh, you're talking about hardware subsystems. That makes this slightly more
> compelling, but I don't think you want the virtual counter here, since
> I assume those other subsystems don't take into account CNTVOFF (and I
> don't really see how they could, it being a per-cpu thing). So, if you
> want to expose the *physical* counter as a trace clock, I think that's
> justifiable.
>
Yes, I meant HW subsystems. Sorry if I was not clear.
In ARM64, it seems the access to physical counter is removed with commit
"clocksource: arch_timer: Fix code to use physical timers when
requested". Only ARM (32) is allowed to used physical counter in the
current timer API. It seems only EL2 is supposed to access this. But
yes, if there is an offset, it seems it would be difficult to get the
exact value at EL0. However for systems where CNTVOFF is '0', this will
work seamless. This clock would not be the default anyways and is
optional. Local clock would continue to be the default for traces.
>>>> local_clock or even the perf track_clock uses sched_clock which gets
>>>> suspended during system suspend. Yes, they are backed up by the
>>>> architected counter but they ignore the cycles spent in suspend.i
>>>
>>> Does mono_raw solve this (also hangs off the architected counter and is
>>> supported in the vdso)?
>>
>> Doesn't seem like. Any of the existing clock sources are designed not show
>> the jump, when there is a suspend and resume. Even though they run out of
>> architected counter they just cane give exact correlation with the counter.
>> Furthermore, during the initial kernel boot, these just run out of jiffies
>> clock source. They also not account for the time spent in boot loaders.
>
> Hmm, there's a thing called CLOCK_BOOTTIME, but I don't think that helps
> you when CNTVOFF comes into play.
>
CLOCK_BOOTTIME includes the time spent in suspend. But this also doesn't
give exact counter value since power ON. So for the purpose of comparing
with global counter, this would not help.
>>>> so, when comparing with monotonically increasing cycle counter, other
>>>> clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
>>>
>>> Does this mean we need a way to expose the frequency to userspace, too?
>>
>> Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency of
>> system timer and is available to EL0.
>
> Experience shows that CNTFRQ_EL0 is often unreliable, and the frequency
> can be overridden by the device-tree. There are also systems where the
> counter stops ticking across suspend. Whilst both of these can be considered
> "broken", I suspect we want runtime buy-in from the arch-timer driver
> before registering this trace_clock.
Agree. It doesnt seem like architecture mandates initializing this.
For those systems where tick would stop, if not arch counter, i assume
there is some counter which falls in 'always ON' domain without which
they cant keep track of time.
Adding Mark Rutland and Marc Zyngier for help with this.
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
Project.
^ permalink raw reply
* [PATCH v2] i2c: designware: add reset interface
From: Andy Shevchenko @ 2016-12-15 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481792388-13781-1-git-send-email-zhangfei.gao@linaro.org>
On Thu, 2016-12-15 at 16:59 +0800, Zhangfei Gao wrote:
> Some platforms like hi3660 need do reset first to allow accessing
> registers
Patch itself looks good, but would be nice to have it tested.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> ?drivers/i2c/busses/i2c-designware-core.h????|??1 +
> ?drivers/i2c/busses/i2c-designware-platdrv.c | 28
> ++++++++++++++++++++++++----
> ?2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.h
> b/drivers/i2c/busses/i2c-designware-core.h
> index 0d44d2a..94b14fa 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -80,6 +80,7 @@ struct dw_i2c_dev {
> ? void __iomem *base;
> ? struct completion cmd_complete;
> ? struct clk *clk;
> + struct reset_control *rst;
> ? u32 (*get_clk_rate_khz) (struct
> dw_i2c_dev *dev);
> ? struct dw_pci_controller *controller;
> ? int cmd_err;
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 0b42a12..e9016ae 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -38,6 +38,7 @@
> ?#include <linux/pm_runtime.h>
> ?#include <linux/property.h>
> ?#include <linux/io.h>
> +#include <linux/reset.h>
> ?#include <linux/slab.h>
> ?#include <linux/acpi.h>
> ?#include <linux/platform_data/i2c-designware.h>
> @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? dev->irq = irq;
> ? platform_set_drvdata(pdev, dev);
> ?
> + dev->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
> + if (IS_ERR(dev->rst)) {
> + if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + } else {
> + reset_control_deassert(dev->rst);
> + }
> +
> ? /* fast mode by default because of legacy reasons */
> ? dev->clk_freq = 400000;
> ?
> @@ -207,12 +216,13 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? ????&& dev->clk_freq != 1000000 && dev->clk_freq != 3400000)
> {
> ? dev_err(&pdev->dev,
> ? "Only 100kHz, 400kHz, 1MHz and 3.4MHz
> supported");
> - return -EINVAL;
> + r = -EINVAL;
> + goto exit_reset;
> ? }
> ?
> ? r = i2c_dw_eval_lock_support(dev);
> ? if (r)
> - return r;
> + goto exit_reset;
> ?
> ? dev->functionality =
> ? I2C_FUNC_I2C |
> @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? }
> ?
> ? r = i2c_dw_probe(dev);
> - if (r && !dev->pm_runtime_disabled)
> - pm_runtime_disable(&pdev->dev);
> + if (r)
> + goto exit_probe;
> ?
> ? return r;
> +
> +exit_probe:
> + if (!dev->pm_runtime_disabled)
> + pm_runtime_disable(&pdev->dev);
> +exit_reset:
> + if (!IS_ERR_OR_NULL(dev->rst))
> + reset_control_assert(dev->rst);
> + return r;
> ?}
> ?
> ?static int dw_i2c_plat_remove(struct platform_device *pdev)
> @@ -290,6 +308,8 @@ static int dw_i2c_plat_remove(struct
> platform_device *pdev)
> ? pm_runtime_put_sync(&pdev->dev);
> ? if (!dev->pm_runtime_disabled)
> ? pm_runtime_disable(&pdev->dev);
> + if (!IS_ERR_OR_NULL(dev->rst))
> + reset_control_assert(dev->rst);
> ?
> ? return 0;
> ?}
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v3 5/5] Explicitly clean linux-system.axf and xen-system.axf
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
When doing a make clean, only the output image currently configured to
build is being removed. However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older build than
intended. Simply hardcode the axf image file names.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index db97f9c..506a1d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
all: $(IMAGE)
-CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
+CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
--
2.9.0
^ permalink raw reply related
* [PATCH v3 4/5] Xen: Select correct dom0 console
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Ian Campbell <ian.campbell@citrix.com>
If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ea02dca..d23cced 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,7 +105,8 @@ AC_ARG_WITH([initrd],
AC_SUBST([FILESYSTEM], [$USE_INITRD])
AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
AC_ARG_WITH([cmdline],
AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
[C_CMDLINE=$withval])
--
2.9.0
^ permalink raw reply related
* [PATCH v3 3/5] Xen: Support adding DT nodes
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
Support adding xen,xen-bootargs node via --with-xen-cmdline to the
configure script and automatically add the Dom0 node to the DT as well.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
Makefile.am | 23 +++++++++++++++--------
configure.ac | 9 +++++++++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f8b9ec9..db97f9c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,21 +96,28 @@ FDT_OFFSET := 0x08000000
if XEN
XEN := -DXEN=$(XEN_IMAGE)
XEN_OFFSET := 0x08200000
+KERNEL_SIZE := $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
+DOM0_OFFSET := $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
+XEN_BOOTARGS := xen,xen-bootargs = \"$(XEN_CMDLINE)\"; \
+ \#address-cells = <2>; \
+ \#size-cells = <2>; \
+ module at 1 { \
+ compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
+ reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>; \
+ };
endif
if INITRD
INITRD_FLAGS := -DUSE_INITRD
+INITRD_CHOSEN := linux,initrd-start = <$(FILESYSTEM_START)>; \
+ linux,initrd-end = <$(FILESYSTEM_END)>;
+endif
+
CHOSEN_NODE := chosen { \
bootargs = \"$(CMDLINE)\"; \
- linux,initrd-start = <$(FILESYSTEM_START)>; \
- linux,initrd-end = <$(FILESYSTEM_END)>; \
- };
-else
-INITRD_FLAGS :=
-CHOSEN_NODE := chosen { \
- bootargs = \"$(CMDLINE)\"; \
+ $(INITRD_CHOSEN) \
+ $(XEN_BOOTARGS) \
};
-endif
CPPFLAGS += $(INITRD_FLAGS)
CFLAGS += -Iinclude/ -I$(ARCH_SRC)/include/
diff --git a/configure.ac b/configure.ac
index 1d7cf3d..ea02dca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -111,6 +111,12 @@ AC_ARG_WITH([cmdline],
[C_CMDLINE=$withval])
AC_SUBST([CMDLINE], [$C_CMDLINE])
+X_CMDLINE="console=dtuart dtuart=serial0 no-bootscrub"
+AC_ARG_WITH([xen-cmdline],
+ AS_HELP_STRING([--with-xen-cmdline], [set Xen command line]),
+ [X_CMDLINE=$withval])
+AC_SUBST([XEN_CMDLINE], [$X_CMDLINE])
+
# Allow a user to pass --enable-gicv3
AC_ARG_ENABLE([gicv3],
AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
@@ -149,4 +155,7 @@ echo " Use GICv3? ${USE_GICV3}"
echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
echo " Kernel execution state: AArch${KERNEL_ES}"
echo " Xen image ${XEN_IMAGE:-NONE}"
+if test "x${XEN_IMAGE}" != "x"; then
+echo " Xen command line: ${XEN_CMDLINE}"
+fi
echo ""
--
2.9.0
^ permalink raw reply related
* [PATCH v3 2/5] Support for building in a Xen binary
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
Add support for building a Xen binary which includes a Dom0 image and
the Dom0 command-line.
If the user specifies --with-xen=<Xen>, where Xen is an appropriate
AArch64 Xen binary, the build system will generate a xen-system.axf
instead of a linux-system.axf.
Original patch from Ian Campbell, but I modified most of it so all bugs
are probably mine.
[Andre: adapt to newest boot-wrapper branch, increase load address,
fixup Xen image file test]
Cc: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
.gitignore | 1 +
Makefile.am | 10 +++++++---
boot_common.c | 4 ++--
configure.ac | 17 +++++++++++++++++
model.lds.S | 14 ++++++++++++++
5 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/.gitignore b/.gitignore
index 8653852..80770c0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ configure
dtc
fdt.dtb
Image
+Xen
install-sh
Makefile
Makefile.in
diff --git a/Makefile.am b/Makefile.am
index 692d2cc..f8b9ec9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -85,7 +85,6 @@ TEXT_LIMIT := 0x80080000
endif
LD_SCRIPT := model.lds.S
-IMAGE := linux-system.axf
FS_OFFSET := 0x10000000
FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET))))
@@ -94,6 +93,11 @@ FILESYSTEM_END := $(shell echo $$(($(FILESYSTEM_START) + $(FILESYSTEM_SIZE))))
FDT_OFFSET := 0x08000000
+if XEN
+XEN := -DXEN=$(XEN_IMAGE)
+XEN_OFFSET := 0x08200000
+endif
+
if INITRD
INITRD_FLAGS := -DUSE_INITRD
CHOSEN_NODE := chosen { \
@@ -121,7 +125,7 @@ all: $(IMAGE)
CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
-$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
+$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
%.o: %.S Makefile
@@ -131,7 +135,7 @@ $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
$(CC) $(CPPFLAGS) $(CFLAGS) $(DEFINES) -c -o $@ $<
model.lds: $(LD_SCRIPT) Makefile
- $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
+ $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) -DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) $(CPUS_NODE) };" ) | $(DTC) -O dtb -o $@ -
diff --git a/boot_common.c b/boot_common.c
index 4947fe3..e7b8e1d 100644
--- a/boot_common.c
+++ b/boot_common.c
@@ -9,7 +9,7 @@
#include <cpu.h>
#include <spin.h>
-extern unsigned long kernel;
+extern unsigned long entrypoint;
extern unsigned long dtb;
void init_platform(void);
@@ -67,7 +67,7 @@ void __noreturn first_spin(unsigned int cpu, unsigned long *mbox,
if (cpu == 0) {
init_platform();
- *mbox = (unsigned long)&kernel;
+ *mbox = (unsigned long)&entrypoint;
sevl();
spin(mbox, invalid, 1);
} else {
diff --git a/configure.ac b/configure.ac
index e0daec4..1d7cf3d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
[KERN_DTB="$withval"])
+AC_ARG_WITH([xen],
+ AS_HELP_STRING([--with-xen], [Compile for Xen, and specify a particular Xen to use]),
+ X_IMAGE=$withval)
+
+AS_IF([test "x$X_IMAGE" == "x"], [],
+ [AS_IF([test ! -f "$X_IMAGE"],
+ [AC_MSG_ERROR([Could not find Xen hypervisor binary: $X_IMAGE])]
+ )]
+)
+AC_SUBST([XEN_IMAGE], [$X_IMAGE])
+AM_CONDITIONAL([XEN], [test "x$X_IMAGE" != "x"])
+
# Ensure that the user has provided us with a sane kernel dir.
if ! test -d $KERN_DIR; then
AC_MSG_ERROR([Could not find Linux kernel dir $KERN_DIR.])
@@ -63,6 +75,10 @@ fi
AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
AC_SUBST([KERNEL_DTB], [$KERN_DTB])
+AS_IF([test "x$X_IMAGE" != "x"],
+ [AC_SUBST([IMAGE], ["xen-system.axf"])],
+ [AC_SUBST([IMAGE], ["linux-system.axf"])]
+)
# Allow a user to pass --enable-psci
AC_ARG_ENABLE([psci],
@@ -132,4 +148,5 @@ echo " CPU IDs: ${CPU_IDS}"
echo " Use GICv3? ${USE_GICV3}"
echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
echo " Kernel execution state: AArch${KERNEL_ES}"
+echo " Xen image ${XEN_IMAGE:-NONE}"
echo ""
diff --git a/model.lds.S b/model.lds.S
index 51c5684..511f552 100644
--- a/model.lds.S
+++ b/model.lds.S
@@ -16,6 +16,9 @@ OUTPUT_ARCH(aarch64)
#endif
TARGET(binary)
+#ifdef XEN
+INPUT(XEN)
+#endif
INPUT(KERNEL)
INPUT(./fdt.dtb)
@@ -36,6 +39,17 @@ SECTIONS
KERNEL
}
+#ifdef XEN
+ .xen (PHYS_OFFSET + XEN_OFFSET): {
+ xen = .;
+ XEN
+ }
+
+ entrypoint = xen;
+#else
+ entrypoint = kernel;
+#endif
+
.dtb (PHYS_OFFSET + FDT_OFFSET): {
dtb = .;
./fdt.dtb
--
2.9.0
^ permalink raw reply related
* [PATCH v3 1/5] configure: fix file detection when cross-compiling
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
The autotools documentation states that AC_CHECK_FILE cannot be used when
cross-compiling [1], because it's meant to check files in the target
system, not on the build host. When just giving --host on the configure
command line, the script detects cross compilation rather late; and as the
file test just happens to execute earlier, this works anyway.
However if one gives both --host and --build, cross compilation is
detected very early and ./configure complains:
checking for /src/linux-arm64... configure: error: cannot check for file existence when cross compiling
So replace the checkfile macro usage with a simple "test -f" call (which
is the recommended way of checking for files on the build host) and output
proper error messages.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Files
---
configure.ac | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index ab8f5b3..e0daec4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,12 +41,25 @@ AC_ARG_WITH([dtb],
[KERN_DTB="$withval"])
# Ensure that the user has provided us with a sane kernel dir.
-m4_define([CHECKFILES], [KERN_DIR,
- KERN_DTB,
- KERN_IMAGE])
+if ! test -d $KERN_DIR; then
+ AC_MSG_ERROR([Could not find Linux kernel dir $KERN_DIR.])
+fi
+
+AC_MSG_CHECKING([whether DTB file exists])
+if ! test -f $KERN_DTB; then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([You need to specify a valid DTB file, could not find: $KERN_DTB])
+else
+ AC_MSG_RESULT([yes])
+fi
-m4_foreach([checkfile], [CHECKFILES],
- [AC_CHECK_FILE([$checkfile], [], AC_MSG_ERROR([No such file or directory: $checkfile]))])
+AC_MSG_CHECKING([whether kernel image exists])
+if ! test -f $KERN_IMAGE; then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([You need to compile a kernel first, could not find: $KERN_IMAGE])
+else
+ AC_MSG_RESULT([yes])
+fi
AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
AC_SUBST([KERNEL_DTB], [$KERN_DTB])
--
2.9.0
^ permalink raw reply related
* [PATCH v3 0/5] boot-wrapper: arm64: Xen support
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
The original patches have been around for a while, so this series is
merely an update to apply on the latest boot-wrapper HEAD. Also I fixed
minor things here and there (like increasing Xen's load address to
accomodate for Dom0 kernels bigger than 16 MB) and addressed Julien's
review comments.
For testing this just add: "--with-xen=/path/to/src/xen/xen" to the
./configure command line and feed the resulting xen-system.axf file to
the model.
Also this release folds in a cross-compilation fix to avoid pointless
merge conflicts.
Cheers,
Andre.
Changelog v1 .. v2:
- use "xen-cmdline" instead of bootargs as parameter and variable name
- move hunk in patch 1/4 to make patch 2/4 smaller
- replace AC_FILE_CHECK macro usage to fix cross compilation
Changelog v2 .. v3:
- fix spelling typos as pointed out by Julien
- include cross-compilation fix
- add Tested-by: and Reviewed-by: tags
Andre Przywara (1):
configure: fix file detection when cross-compiling
Christoffer Dall (3):
Support for building in a Xen binary
Xen: Support adding DT nodes
Explicitly clean linux-system.axf and xen-system.axf
Ian Campbell (1):
Xen: Select correct dom0 console
.gitignore | 1 +
Makefile.am | 35 +++++++++++++++++++++++------------
boot_common.c | 4 ++--
configure.ac | 52 ++++++++++++++++++++++++++++++++++++++++++++++------
model.lds.S | 14 ++++++++++++++
5 files changed, 86 insertions(+), 20 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH 0/3] clkdev: add devm_get_clk_from_child()
From: Mark Brown @ 2016-12-15 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737hyymo9.wl%kuninori.morimoto.gx@renesas.com>
On Fri, Dec 09, 2016 at 12:25:48AM +0000, Kuninori Morimoto wrote:
> Mark, I think I should re-post 2nd patch (3rd will be dropped) after
> merge window ? There will be no branch dependency
Should be fine without but obviously if it looks like it's gone AWOL
then reposting would be good.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/d9c5690a/attachment.sig>
^ permalink raw reply
* Applied "ASoC: samsung: Remove tests of member address" to the asoc tree
From: Mark Brown @ 2016-12-15 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481363471-21364-1-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Remove tests of member address
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 409c69be433b819c924a8d1c457a835bc6d51700 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sat, 10 Dec 2016 11:51:11 +0200
Subject: [PATCH] ASoC: samsung: Remove tests of member address
The driver was checking for non-NULL address of struct's members:
- s3c_audio_pdata->type (union),
- s3c_audio_pdata->type.i2s (embedded struct).
This is pointless as these will be always non-NULL. The 's3c_audio_pdata'
is always initialized in static memory so it will be zeroed.
Additionally the 'type' member was an union with only one member.
It is safe to reorganize the structures to get rid of useless union and
checks for addresses to fix the coccinelle warning:
>> sound/soc/samsung/i2s.c:1270:2-4: ERROR: test of a variable/field address
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm/mach-s3c64xx/dev-audio.c | 4 +---
include/linux/platform_data/asoc-s3c.h | 6 ++----
sound/soc/samsung/i2s.c | 10 ++--------
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b57783371d52..247dcc0b691e 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -106,9 +106,7 @@ static struct s3c_audio_pdata i2sv4_pdata = {
.dma_playback = DMACH_HSI_I2SV40_TX,
.dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
- .i2s = {
- .quirks = QUIRK_PRI_6CHAN,
- },
+ .quirks = QUIRK_PRI_6CHAN,
},
};
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 15bf56ee8af7..90641a5daaf0 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -18,7 +18,7 @@
extern void s3c64xx_ac97_setup_gpio(int);
-struct samsung_i2s {
+struct samsung_i2s_type {
/* If the Primary DAI has 5.1 Channels */
#define QUIRK_PRI_6CHAN (1 << 0)
/* If the I2S block has a Stereo Overlay Channel */
@@ -47,7 +47,5 @@ struct s3c_audio_pdata {
void *dma_capture;
void *dma_play_sec;
void *dma_capture_mic;
- union {
- struct samsung_i2s i2s;
- } type;
+ struct samsung_i2s_type type;
};
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index e00974bc5616..d55326289a4a 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1218,7 +1218,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
{
struct i2s_dai *pri_dai, *sec_dai = NULL;
struct s3c_audio_pdata *i2s_pdata = pdev->dev.platform_data;
- struct samsung_i2s *i2s_cfg = NULL;
struct resource *res;
u32 regs_base, quirks = 0, idma_addr = 0;
struct device_node *np = pdev->dev.of_node;
@@ -1267,13 +1266,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
pri_dai->filter = i2s_pdata->dma_filter;
- if (&i2s_pdata->type)
- i2s_cfg = &i2s_pdata->type.i2s;
-
- if (i2s_cfg) {
- quirks = i2s_cfg->quirks;
- idma_addr = i2s_cfg->idma_addr;
- }
+ quirks = i2s_pdata->type.quirks;
+ idma_addr = i2s_pdata->type.idma_addr;
} else {
quirks = i2s_dai_data->quirks;
if (of_property_read_u32(np, "samsung,idma-addr",
--
2.11.0
^ permalink raw reply related
* Applied "misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present" to the asoc tree
From: Mark Brown @ 2016-12-15 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-2-git-send-email-peda@axentia.se>
The patch
misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e8314d7d53c8b050aac2828a5de5f28a997b468b Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda@axentia.se>
Date: Tue, 6 Dec 2016 20:22:36 +0100
Subject: [PATCH] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is
present
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.11.0
^ permalink raw reply related
* Applied "ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself" to the asoc tree
From: Mark Brown @ 2016-12-15 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481052157-23400-3-git-send-email-peda@axentia.se>
The patch
ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ca8c7f233fa2c40e2a23f982dc33d947f28ad207 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda@axentia.se>
Date: Tue, 6 Dec 2016 20:22:37 +0100
Subject: [PATCH] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai
by itself
This breaks devicetree compatibility, but in this case that is ok. All
affected units are either on my desk, or running an even older version
of the driver that is not compatible with the upstreamed version anyway
(and when these other units are eventually updated, they will get a
fresh dtb as well, so that is not a significant problem either).
All of that is of course assuming that noone else has managed to build
something that can use this driver, but that seems extremely improbable.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 ++++++++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fdb25b492514 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -43,6 +42,12 @@ the PCM5142 codec.
Example:
+ &ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+ };
+
&i2c {
codec: pcm5142 at 4c {
compatible = "ti,pcm5142";
@@ -77,7 +82,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-15 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215123533.f7e2373d2a9eb113ee7b0600@bidouilliste.com>
On Thu, Dec 15, 2016 at 12:35:33PM +0100, Emmanuel Vadot wrote:
>
> Hi Maxime,
>
> On Wed, 14 Dec 2016 16:30:13 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> > > The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> > > This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> > > result in a unusable eMMC if U-Boot didn't configured the pins to the
> > > correct functions.
> > >
> > > Changes since v1:
> > > * Rename the node mmc2-rst-pin
> >
> > That changelog should be after the ---. Removed it and applied.
> >
> > Thanks!
> > Maxime
>
> Sorry, still kinda new at doing patches for Linux, will be more
> carefull next time.
> Quick question, when you say applied, applied where exactly ? I had a
> quick look at your branches on git.kernel.org didn't find anything.
In general, my tree on kernel.org.
In this case, my local tree for now. We're right in the middle of the
merge window for 4.10, so in order not to pollute next and not to
confuse everyone (or rebasing a branch at some point), I just gather
the patches here. I'll publish a branch based on 4.10 as soon as
4.10-rc1 is released.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/74075136/attachment.sig>
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mark Rutland @ 2016-12-15 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1147ef90-7877-e4d2-bb2b-5c4fa8d3144b@free.fr>
On Thu, Dec 15, 2016 at 11:35:12AM +0100, Mason wrote:
> On 14/12/2016 18:47, Mason wrote:
> > On 14/12/2016 18:08, Thomas Gleixner wrote:
> >> Does the patch below fix the issue?
> >> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> >> index 22acee76cf4c..2594c287b078 100644
> >> --- a/include/linux/cpuhotplug.h
> >> +++ b/include/linux/cpuhotplug.h
> >> @@ -101,7 +101,6 @@ enum cpuhp_state {
> >> CPUHP_AP_ARM_L2X0_STARTING,
> >> CPUHP_AP_ARM_ARCH_TIMER_STARTING,
> >> CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
> >> - CPUHP_AP_DUMMY_TIMER_STARTING,
> >> CPUHP_AP_JCORE_TIMER_STARTING,
> >> CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> >> CPUHP_AP_ARM_TWD_STARTING,
> >> @@ -111,6 +110,7 @@ enum cpuhp_state {
> >> CPUHP_AP_MARCO_TIMER_STARTING,
> >> CPUHP_AP_MIPS_GIC_TIMER_STARTING,
> >> CPUHP_AP_ARC_TIMER_STARTING,
> >> + CPUHP_AP_DUMMY_TIMER_STARTING,
> >> CPUHP_AP_KVM_STARTING,
> >> CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
> >> CPUHP_AP_KVM_ARM_VGIC_STARTING,
> > It does seem to fix the problem:
> > I reverted your patch, and the kernel blows up again.
> >
> > So what's the problem, and how does your patch solve it?
>
> Link to the original report:
> https://marc.info/?l=linux-arm-kernel&m=148173152524746&w=2
>
> Forgot to CC Robin Murphy, who had provided valuable input
> in similar circumstances a few months back.
>
> Also add LKML, since this doesn't appear to be ARM-specific.
>
> Do I need to specify which device tree I was using?
This is already fixed in the linux-tip tree, with commit messages
describing the fix.
It's specific to a few clocksources, due to their hotplug callbacks
occuring later than the dummy timer. That triggers the bug fixed in:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgent&id=c1a9eeb938b5433947e5ea22f89baff3182e7075
The relevant timers were fixed in:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=smp/urgent&id=9bf11ecce5a2758e5a097c2f3a13d08552d0d6f9
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-15 11:55 UTC (permalink / raw)
To: linux-arm-kernel
Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
(for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
cooling maps to account for new OPPs.
Since new OPPs are not available on all Exynos5422/5800 boards modify
dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
Tested on Odroid-XU3 and XU3 Lite.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Ben Gamari <ben@smart-cactus.org>
Cc: Arjun K V <arjun.kv@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
v2:
- added comments about limitations of SoC revisions used by Odroid-XU3 Lite and
Peach Pi boards (suggested by Javier)
- removed redundant opp_a7_14 label
- added Arjun to Cc:
Javier, could you test it on Peach Pi board?
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 ++++++-------
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 22 +++++++++++++++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 9 ++++++++
arch/arm/boot/dts/exynos5800.dtsi | 15 ++++++++++++++
4 files changed, 53 insertions(+), 7 deletions(-)
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.361955949 +0100
@@ -118,7 +118,7 @@
/*
* When reaching cpu_alert3, reduce CPU
* by 2 steps. On Exynos5422/5800 that would
- * be: 1600 MHz and 1100 MHz.
+ * (usually) be: 1800 MHz and 1200 MHz.
*/
map3 {
trip = <&cpu_alert3>;
@@ -131,16 +131,16 @@
/*
* When reaching cpu_alert4, reduce CPU
- * further, down to 600 MHz (11 steps for big,
- * 7 steps for LITTLE).
+ * further, down to 600 MHz (13 steps for big,
+ * 8 steps for LITTLE).
*/
- map5 {
+ cooling_map5: map5 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu0 3 7>;
+ cooling-device = <&cpu0 3 8>;
};
- map6 {
+ cooling_map6: map6 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu4 3 11>;
+ cooling-device = <&cpu4 3 13>;
};
};
};
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.361955949 +0100
@@ -21,6 +21,28 @@
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
};
+/*
+ * Odroid XU3-Lite board uses SoC revision with lower maximum frequencies
+ * than Odroid XU3/XU4 boards: 1.8 GHz for A15 cores & 1.3 GHz for A7 cores.
+ * Therefore we need to update OPPs tables and thermal maps accordingly.
+ */
+&cluster_a15_opp_table {
+ /delete-node/opp at 2000000000;
+ /delete-node/opp at 1900000000;
+};
+
+&cluster_a7_opp_table {
+ /delete-node/opp at 1400000000;
+};
+
+&cooling_map5 {
+ cooling-device = <&cpu0 3 7>;
+};
+
+&cooling_map6 {
+ cooling-device = <&cpu4 3 11>;
+};
+
&pwm {
/*
* PWM 0 -- fan
Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.361955949 +0100
@@ -146,6 +146,15 @@
vdd-supply = <&ldo9_reg>;
};
+/*
+ * Peach Pi board uses SoC revision with lower maximum frequency for A7 cores
+ * (1.3 GHz instead of 1.4 GHz) than Odroid XU3/XU4 boards. Thus we need to
+ * update A7 OPPs table accordingly.
+ */
+&cluster_a7_opp_table {
+ /delete-property/opp at 1400000000;
+};
+
&cpu0 {
cpu-supply = <&buck2_reg>;
};
Index: b/arch/arm/boot/dts/exynos5800.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
@@ -24,6 +24,16 @@
};
&cluster_a15_opp_table {
+ opp at 2000000000 {
+ opp-hz = /bits/ 64 <2000000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
+ opp at 1900000000 {
+ opp-hz = /bits/ 64 <1900000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1700000000 {
opp-microvolt = <1250000>;
};
@@ -85,6 +95,11 @@
};
&cluster_a7_opp_table {
+ opp at 1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1300000000 {
opp-microvolt = <1250000>;
};
^ permalink raw reply
* [PATCH] boot-wrapper: configure: fix file detection when cross-compiling
From: Mark Rutland @ 2016-12-15 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122151501.16643-1-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:15:01PM +0000, Andre Przywara wrote:
> The autotools documentation states that CHECKFILES cannot be used when
> cross-compiling[1], because it's meant to check files in the target
> system, not on the build host. When just giving --host on the configure
> command line, the script detects cross compilation rather late; and as the
> file test just happens to execute earlier, this works anyway.
> However if one gives both --host and --build, cross compilation is
> detected very early and ./configure complains:
>
> checking for /src/linux-arm64... configure: error: cannot check for file existence when cross compiling
>
> So replace the checkfile macro usage with a simple "test -f" call (which
> is the recommended way of checking for files on the build host) and output
> proper error messages.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Files
This looks fine to me. Does this conflict with the Xen patches at all?
To make it easier to pick these all up, could you please fold this into
the Xen series as a preparatory patch?
Thanks,
Mark.
> ---
> configure.ac | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index ab8f5b3..e0daec4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -41,12 +41,25 @@ AC_ARG_WITH([dtb],
> [KERN_DTB="$withval"])
>
> # Ensure that the user has provided us with a sane kernel dir.
> -m4_define([CHECKFILES], [KERN_DIR,
> - KERN_DTB,
> - KERN_IMAGE])
> +if ! test -d $KERN_DIR; then
> + AC_MSG_ERROR([Could not find Linux kernel dir $KERN_DIR.])
> +fi
> +
> +AC_MSG_CHECKING([whether DTB file exists])
> +if ! test -f $KERN_DTB; then
> + AC_MSG_RESULT([no])
> + AC_MSG_ERROR([You need to specify a valid DTB file, could not find: $KERN_DTB])
> +else
> + AC_MSG_RESULT([yes])
> +fi
>
> -m4_foreach([checkfile], [CHECKFILES],
> - [AC_CHECK_FILE([$checkfile], [], AC_MSG_ERROR([No such file or directory: $checkfile]))])
> +AC_MSG_CHECKING([whether kernel image exists])
> +if ! test -f $KERN_IMAGE; then
> + AC_MSG_RESULT([no])
> + AC_MSG_ERROR([You need to compile a kernel first, could not find: $KERN_IMAGE])
> +else
> + AC_MSG_RESULT([yes])
> +fi
>
> AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
> AC_SUBST([KERNEL_DTB], [$KERN_DTB])
> --
> 2.9.0
>
^ permalink raw reply
* [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Greg Kroah-Hartman @ 2016-12-15 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
for include/linux/serial_core.h:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Greg Kroah-Hartman @ 2016-12-15 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481778865-27667-9-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:30AM +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
> drivers/net/wireless/intersil/orinoco/Makefile | 3 ---
> drivers/net/wireless/mediatek/mt7601u/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile | 2 --
> drivers/net/wireless/ti/wl1251/Makefile | 2 --
> drivers/net/wireless/ti/wlcore/Makefile | 2 --
> drivers/staging/rtl8188eu/Makefile | 2 +-
> drivers/staging/rtl8192e/Makefile | 2 --
> drivers/staging/rtl8192e/rtl8192e/Makefile | 2 --
> net/bluetooth/Makefile | 2 --
> net/ieee802154/Makefile | 2 --
> net/mac80211/Makefile | 2 +-
> net/mac802154/Makefile | 2 --
> net/wireless/Makefile | 2 --
> 38 files changed, 5 insertions(+), 68 deletions(-)
For drivers/staging:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf
From: Mark Rutland @ 2016-12-15 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb5e65ca-65a2-6e0c-47f5-1773d6173739@arm.com>
On Mon, Dec 12, 2016 at 02:50:20PM +0000, Andre Przywara wrote:
> Hi Konrad,
>
> On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 22, 2016 at 03:09:17PM +0000, Andre Przywara wrote:
> >> From: Christoffer Dall <christoffer.dall@linaro.org>
> >>
> >> When doing a make clean, only the output image currently configured to
> >> build is being removed. However, one would expect all build artifacts
> >> to be removed when doing a 'make clean' and when switching between Xen
> >> and Linux builds, it is easy to accidentally run an older build than
> >> intended. Simply hardcode the axf image file names.
> >>
> >> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >> Reviewed-by: Julien Grall <julien.grall@arm.com>
> >
> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Thanks a lot!
>
> I will try to poke Mark to see if we can get this merged eventually.
I'm happy to take these so long as this doesn't adversely affect non-Xen
usage. I assume they don't. :)
Could you fix this up as per Julien's comments, and fold in the tags?
I'm happy to take that from a v3 or a git repo.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Marc Zyngier @ 2016-12-15 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215113539.GK14217@n2100.armlinux.org.uk>
On 15/12/16 11:35, Russell King - ARM Linux wrote:
> On Thu, Dec 15, 2016 at 11:18:48AM +0000, Marc Zyngier wrote:
>> On 14/12/16 10:46, Russell King wrote:
>>> @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
>>> * initialisation entry point.
>>> */
>>> ENTRY(__hyp_get_vectors)
>>> - mov r0, #-1
>>> + mov r0, #HVC_GET_VECTORS
>>
>> This breaks the KVM implementation of __hyp_get_vectors, easily fixed
>> with the following patchlet:
>
> Right, so what Mark said is wrong:
>
> "The hyp-stub is part of the kernel image, and the API is private to
> that particular image, so we can change things -- there's no ABI to
> worry about."
I think Mark is right. The API *is* private to the kernel, and KVM being
the only in-kernel hypervisor on ARM, this is not an ABI.
It is an unfortunate bug that no symbolic constant was used to highlight
the two implementations of the same functionality, but I don't think
that makes anything wrong in what Mark said here.
> So no, I'm going with my original patch (which TI has tested) which is
> the minimal change, and if we _then_ want to rework the HYP mode
> interfaces, that's the time to do the other changes when more people
> (such as KVM folk) are paying attention and we can come to a cross-
> hypervisor agreement on what the interface should be.
Given that there is a single in-kernel hypervisor, I can't really see
who we're going to agree anything with...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/4] Xen: Support adding DT nodes
From: Julien Grall @ 2016-12-15 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-3-andre.przywara@arm.com>
Hi Andre,
On 22/11/16 15:09, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Support adding xen,xen-bootargs node via --with-xen-bootargs to the
Based the code, the configure option is --with-xen-cmdline.
> configure script and automatically add the Dom0 node to the DT as well.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
With the above request:
Reviewed-by: Julien Grall <julien.grall@arm.com>
Regards,
--
Julien Grall
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Russell King - ARM Linux @ 2016-12-15 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72f93940-cf87-fd91-90f2-760b7ff050fb@arm.com>
On Thu, Dec 15, 2016 at 11:18:48AM +0000, Marc Zyngier wrote:
> On 14/12/16 10:46, Russell King wrote:
> > @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
> > * initialisation entry point.
> > */
> > ENTRY(__hyp_get_vectors)
> > - mov r0, #-1
> > + mov r0, #HVC_GET_VECTORS
>
> This breaks the KVM implementation of __hyp_get_vectors, easily fixed
> with the following patchlet:
Right, so what Mark said is wrong:
"The hyp-stub is part of the kernel image, and the API is private to
that particular image, so we can change things -- there's no ABI to
worry about."
So no, I'm going with my original patch (which TI has tested) which is
the minimal change, and if we _then_ want to rework the HYP mode
interfaces, that's the time to do the other changes when more people
(such as KVM folk) are paying attention and we can come to a cross-
hypervisor agreement on what the interface should be.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Emmanuel Vadot @ 2016-12-15 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214153013.bkdm3pu3osepfnn2@lukather>
Hi Maxime,
On Wed, 14 Dec 2016 16:30:13 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> > The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> > This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> > result in a unusable eMMC if U-Boot didn't configured the pins to the
> > correct functions.
> >
> > Changes since v1:
> > * Rename the node mmc2-rst-pin
>
> That changelog should be after the ---. Removed it and applied.
>
> Thanks!
> Maxime
Sorry, still kinda new at doing patches for Linux, will be more
carefull next time.
Quick question, when you say applied, applied where exactly ? I had a
quick look at your branches on git.kernel.org didn't find anything.
Thanks.
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox