* [PATCH 0/2] ARM: OMAP2+: CM: make some structures, function arguments and pointers as const
From: Tony Lindgren @ 2017-12-11 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1509974140-10860-1-git-send-email-bhumirks@gmail.com>
* Bhumika Goyal <bhumirks@gmail.com> [171106 05:17]:
> Make some pointers and function arguments as const. After this change,
> make the structures of type cm_ll_data as const.
Thanks applying both in to omap-for-v4.16/soc.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 07/12] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings
From: Laurent Pinchart @ 2017-12-11 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111939.1153-8-jacob-chen@iotwrt.com>
Hello Jacob,
Thank you for the patch.
On Wednesday, 6 December 2017 13:19:34 EET Jacob Chen wrote:
> From: Jacob Chen <jacob2.chen@rock-chips.com>
>
> Add DT bindings documentation for Rockchip MIPI D-PHY RX
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
> .../bindings/media/rockchip-mipi-dphy.txt | 71 +++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt new file
> mode 100644
> index 000000000000..cef9450db051
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> @@ -0,0 +1,71 @@
> +Rockchip SoC MIPI RX D-PHY
> +-------------------------------------------------------------
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "rockchip,rk3288-mipi-dphy";
> + "rockchip,rk3399-mipi-dphy";
> +- rockchip,grf: GRF regs.
> +- bus-width : maximum number of data lanes supported (SoC specific);
Bus width isn't a standard property, should this be rockchip,data-lanes or
rockchip,#data-lanes ?
> +- clocks : list of clock specifiers, corresponding to entries in
> + clock-names property;
> +- clock-names: required clock name.
> +
> +The device node should contain two 'port' child node, according to the
s/child node/child nodes/
> bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The first port should be connected to sensor nodes, and the second port
> should be
> +connected to isp node. The following are properties specific to those
> nodes.
> +
> +endpoint node
> +-------------
> +
> +- data-lanes : (required) an array specifying active physical MIPI-CSI2
> + data input lanes and their mapping to logical lanes; the
> + array's content is unused, only its length is meaningful;
I assume this means that the D-PHY can't reroute lanes. I would mention that
explicitly, and require that the data-lanes values start at one at are
consecutive instead of ignoring them.
> +Device node example
> +-------------------
> +
> + mipi_dphy_rx0: mipi-dphy-rx0 {
> + compatible = "rockchip,rk3399-mipi-dphy";
> + clocks = <&cru SCLK_MIPIDPHY_REF>,
> + <&cru SCLK_DPHY_RX0_CFG>,
> + <&cru PCLK_VIO_GRF>;
> + clock-names = "dphy-ref", "dphy-cfg", "grf";
> + power-domains = <&power RK3399_PD_VIO>;
> + bus-width = <4>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mipi_in_wcam: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&wcam_out>;
> + data-lanes = <1 2>;
> + };
> + mipi_in_ucam: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&ucam_out>;
> + data-lanes = <1>;
> + };
What do those two camera correspond to ? Can they be active at the same time,
or do they use the same data lanes ? If they use the same data lanes, how does
this work, is there a multiplexer on the board ?
> + };
> +
> + port at 1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dphy_rx0_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&isp0_mipi_in>;
> + };
> + };
> + };
> + };
> \ No newline at end of file
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] rcutorture: Add basic ARM64 support to run scripts
From: Paul E. McKenney @ 2017-12-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512728023-37977-1-git-send-email-lianglihao@huawei.com>
On Fri, Dec 08, 2017 at 06:13:43PM +0800, lianglihao at huawei.com wrote:
> From: Lihao Liang <lianglihao@huawei.com>
>
> This commit adds support of the qemu command qemu-system-aarch64
> to rcutorture. Use the following command to run:
>
> ./kvm.sh --qemu-cmd qemu-system-aarch64
>
> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
Nice!!! Getting ARM support for rcutorture has been on my todo list
for some time!
A few questions and comments below.
Feedback from ARM experts also welcome!
Thanx, Paul
> ---
>
> The max CPUs supported by qemu machine 'virt' is 8 so the value of
> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>
> tools/testing/selftests/rcutorture/bin/functions.sh | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
> index 07a1377..5ffe4fe 100644
> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> @@ -136,6 +136,9 @@ identify_boot_image () {
> qemu-system-x86_64|qemu-system-i386)
> echo arch/x86/boot/bzImage
> ;;
> + qemu-system-aarch64)
> + echo arch/arm64/boot/Image
> + ;;
> *)
> echo vmlinux
> ;;
Is it possible to automatically select ARM based on the kernel binary?
See the identify_qemu function for how this is done for i386, x86_64,
and PowerPC. Can an "elif" be added for ARM?
> @@ -185,7 +188,14 @@ identify_qemu_append () {
> then
> echo root=/dev/sda
> else
> - echo console=ttyS0
> + case "$1" in
> + qemu-system-aarch64)
> + echo console=ttyAMA0
> + ;;
> + *)
> + echo console=ttyS0
> + ;;
> + esac
> fi
> }
This approach is going to result in very ugly nesting if support is
added for additional CPU families. How about something like this?
identify_qemu_append () {
local console=ttyS0
case "$1" in
qemu-system-x86_64|qemu-system-i386)
echo noapic selinux=0 initcall_debug debug
;;
qemu-system-aarch64)
console=ttyAMA0
;;
esac
if test -n "$TORTURE_QEMU_INTERACTIVE"
then
echo root=/dev/sda
else
echo console=$console
fi
}
> @@ -197,6 +207,9 @@ identify_qemu_args () {
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> ;;
> + qemu-system-aarch64)
> + echo -M virt -cpu host
> + ;;
> qemu-system-ppc64)
> echo -enable-kvm -M pseries -nodefaults
> echo -device spapr-vscsi
> @@ -257,6 +270,9 @@ specify_qemu_cpus () {
> qemu-system-x86_64|qemu-system-i386)
How about the following instead, eliminating the need for an additional
case?
qemu-system-x86_64|qemu-system-i386!qemu-system-aarch64)
> echo $2 -smp $3
> ;;
> + qemu-system-aarch64)
> + echo $2 -smp $3
> + ;;
> qemu-system-ppc64)
> nt="`lscpu | grep '^NUMA node0' | sed -e 's/^[^,]*,\([0-9]*\),.*$/\1/'`"
> echo $2 -smp cores=`expr \( $3 + $nt - 1 \) / $nt`,threads=$nt
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 00/36] Optimize KVM/ARM for VHE systems
From: Yury Norov @ 2017-12-11 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211153458.GK910@cbox>
On Mon, Dec 11, 2017 at 04:34:58PM +0100, Christoffer Dall wrote:
> Hi Yury,
>
> On Mon, Dec 11, 2017 at 05:43:23PM +0300, Yury Norov wrote:
> >
> > On Thu, Dec 07, 2017 at 06:05:54PM +0100, Christoffer Dall wrote:
> > > This series redesigns parts of KVM/ARM to optimize the performance on
> > > VHE systems. The general approach is to try to do as little work as
> > > possible when transitioning between the VM and the hypervisor. This has
> > > the benefit of lower latency when waiting for interrupts and delivering
> > > virtual interrupts, and reduces the overhead of emulating behavior and
> > > I/O in the host kernel.
> > >
> > > Patches 01 through 04 are not VHE specific, but rework parts of KVM/ARM
> > > that can be generally improved. We then add infrastructure to move more
> > > logic into vcpu_load and vcpu_put, we improve handling of VFP and debug
> > > registers.
> > >
> > > We then introduce a new world-switch function for VHE systems, which we
> > > can tweak and optimize for VHE systems. To do that, we rework a lot of
> > > the system register save/restore handling and emulation code that may
> > > need access to system registers, so that we can defer as many system
> > > register save/restore operations to vcpu_load and vcpu_put, and move
> > > this logic out of the VHE world switch function.
> > >
> > > We then optimize the configuration of traps. On non-VHE systems, both
> > > the host and VM kernels run in EL1, but because the host kernel should
> > > have full access to the underlying hardware, but the VM kernel should
> > > not, we essentially make the host kernel more privileged than the VM
> > > kernel despite them both running at the same privilege level by enabling
> > > VE traps when entering the VM and disabling those traps when exiting the
> > > VM. On VHE systems, the host kernel runs in EL2 and has full access to
> > > the hardware (as much as allowed by secure side software), and is
> > > unaffected by the trap configuration. That means we can configure the
> > > traps for VMs running in EL1 once, and don't have to switch them on and
> > > off for every entry/exit to/from the VM.
> > >
> > > Finally, we improve our VGIC handling by moving all save/restore logic
> > > out of the VHE world-switch, and we make it possible to truly only
> > > evaluate if the AP list is empty and not do *any* VGIC work if that is
> > > the case, and only do the minimal amount of work required in the course
> > > of the VGIC processing when we have virtual interrupts in flight.
> > >
> > > The patches are based on v4.15-rc1 plus the fixes sent for v4.15-rc3
> > > [1], the level-triggered mapped interrupts support series [2], and the
> > > first five patches of James' SDEI series [3], a single SVE patch that
> > > moves the CPU ID reg trap setup out of the world-switch path, and v3 of
> > > my vcpu load/put series [4].
> > >
> > > I've given the patches a fair amount of testing on Thunder-X, Mustang,
> > > Seattle, and TC2 (32-bit) for non-VHE testing, and tested VHE
> > > functionality on the Foundation model, running both 64-bit VMs and
> > > 32-bit VMs side-by-side and using both GICv3-on-GICv3 and
> > > GICv2-on-GICv3.
> > >
> > > The patches are also available in the vhe-optimize-v2 branch on my
> > > kernel.org repository [5].
> > >
> > > Changes since v1:
> > > - Rebased on v4.15-rc1 and newer versions of other dependencies,
> > > including the vcpu load/put approach taken for KVM.
> > > - Addressed review comments from v1 (detailed changelogs are in the
> > > individual patches).
> > >
> > > Thanks,
> > > -Christoffer
> > >
> > > [1]: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm kvm-arm-fixes-for-v4.15-1
> > > [2]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v6
> > > [3]: git://linux-arm.org/linux-jm.git sdei/v5/base
> > > [4]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vcpu-load-put-v3
> > > [5]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vhe-optimize-v2
> >
> > I just submitted the benchmark I used to test your v1 and v2 series':
> > https://lkml.org/lkml/2017/12/11/364
> >
> > On ThunderX2, 112 online CPUs test results for v1 are like this:
> >
> > Host, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 81 110
> > Broadcast IPI: 0 2106
> >
> > Guest, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 10 18
> > Normal IPI: 305 525
> > Broadcast IPI: 0 9729
> >
> > Guest, v4.14 + VHE:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 176 343
> > Broadcast IPI: 0 9885
> >
> > And for v2.
> >
> > Host, v4.15:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 79 108
> > Broadcast IPI: 0 2102
> >
> > Guest, v4.15-rc:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 291 526
> > Broadcast IPI: 0 10439
> >
> > Guest, v4.15-rc + VHE:
> > Dry-run: 0 2
> > Self-IPI: 14 28
> > Normal IPI: 370 569
> > Broadcast IPI: 0 11688
> >
> > All times are normalized to v1 host dry-run time. Smaller - better.
> >
>
> Thanks for running this.
>
> > Results for v1 and v2 may vary because kernel version is changed.
> > What makes us worry is slowing down the "Normal IPI" test observed in
> > v2 series.
>
> I'm wondering if this is not simply variability in your measurements.
> How many times have you run this? The 100,000 iterations for each run
> is not a lot if you consider the cost of migrating threads.
I ran it more than 100 times, maybe more than 200. Variablity exists,
but ~5% at max, much less than observed changes. I can run 1M iterations
version to handle this concern.
> Is this workload pinned to a single CPU?
No. We are interested in test close to real usecases, so I didn't pin
the test. Inside, sending IPI and waiting for acknowledge is pinned
using {get,put}_cpu(). Tomorrow I'll run test pinned to some CPU. Are
you OK with 'taskset -c 111 insmod ipi_benchmark.ko'?
> Is the system otherwise idle (both host and guest)?
Yes, this machine is in my exclusive usage, and I don't run something
heavy in background. And this is newly installed Ubuntu.
> If you run this during boot or during kernel module load, the results
> may be skewed by that.
Hmm... I do it at module load, but there are many tests that measure
performance like this... Anyway, I'll check that.
> Power management can greatly influence results as well.
That's true. I'll check this also. But as you see, all host numbers,
and guest dry-run and self-ipi numbers are stable, except v2 test...
> Just so I'm sure we're reading these reults the same way, your "+ VHE"
> notation means the VHE optimization series, but both the before and
> after picture runs with VHE enabled, right?
Yes.
> Are you using the same guest kernel version and config for both your v1
> and v2 results, and for both the before and after versions?
I rebased v1 on 4.14. For v2 I ran make olddefconfig, the rest is same
as on your branches. I used same kernel image for host and guest, ie
4.14 host + 4.14 guest for v1, and 4.15-rc host and guest for v2. I
also tested host with and without this series - no difference for both
versions.
> I can't easily come up with a scneario that explains the slowdown on the
> normal IPI test, beyond some unfortunate bug introduced in v2.
>
> >
> > Nevertheless, if you find test relevant, for v1 and v2,
> > Tested-by: Yury Norov <ynorov@caviumnetworks.com>
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH] IPI performance benchmark
From: Christian Borntraeger @ 2017-12-11 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211145557.mooeknrcdfw53qpz@yury-thinkpad>
On 12/11/2017 03:55 PM, Yury Norov wrote:
> On Mon, Dec 11, 2017 at 03:35:02PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 12/11/2017 03:16 PM, Yury Norov wrote:
>>> This benchmark sends many IPIs in different modes and measures
>>> time for IPI delivery (first column), and total time, ie including
>>> time to acknowledge the receive by sender (second column).
>>>
>>> The scenarios are:
>>> Dry-run: do everything except actually sending IPI. Useful
>>> to estimate system overhead.
>>> Self-IPI: Send IPI to self CPU.
>>> Normal IPI: Send IPI to some other CPU.
>>> Broadcast IPI: Send broadcast IPI to all online CPUs.
>>>
>>> For virtualized guests, sending and reveiving IPIs causes guest exit.
>>> I used this test to measure performance impact on KVM subsystem of
>>> Christoffer Dall's series "Optimize KVM/ARM for VHE systems".
>>>
>>> https://www.spinics.net/lists/kvm/msg156755.html
>>>
>>> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
>>> to host dry-run time. Smaller - better.
>>>
>>> Host, v4.14:
>>> Dry-run: 0 1
>>> Self-IPI: 9 18
>>> Normal IPI: 81 110
>>> Broadcast IPI: 0 2106
>>>
>>> Guest, v4.14:
>>> Dry-run: 0 1
>>> Self-IPI: 10 18
>>> Normal IPI: 305 525
>>> Broadcast IPI: 0 9729
>>>
>>> Guest, v4.14 + VHE:
>>> Dry-run: 0 1
>>> Self-IPI: 9 18
>>> Normal IPI: 176 343
>>> Broadcast IPI: 0 9885
[...]
>>> +static int __init init_bench_ipi(void)
>>> +{
>>> + ktime_t ipi, total;
>>> + int ret;
>>> +
>>> + ret = bench_ipi(NTIMES, DRY_RUN, &ipi, &total);
>>> + if (ret)
>>> + pr_err("Dry-run FAILED: %d\n", ret);
>>> + else
>>> + pr_err("Dry-run: %18llu, %18llu ns\n", ipi, total);
>>
>> you do not use NTIMES here to calculate the average value. Is that intended?
>
> I think, it's more visually to represent all results in number of dry-run
> times, like I did in patch description. So on kernel side I expose raw data
> and calculate final values after finishing tests.
I think it is highly confusing that the output from the patch description does not
match the output from the real module. So can you make that match at least?
>
> If you think that average values are preferable, I can do that in v2.
The raw numbers a propably fine, but then you might want to print the number of
loop iterations in the output.
If we want to do something fancy, we could do a combination of a smaller inner
loop doing the test, then an outer loops redoing the inner loop and then you
can do some min/max/average calculation. Not s
^ permalink raw reply
* [PATCH 13/13] arc: do not use __print_symbol()
From: Vineet Gupta @ 2017-12-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-14-sergey.senozhatsky@gmail.com>
On 12/11/2017 04:53 AM, Sergey Senozhatsky wrote:
> __print_symbol() uses extra stack space to sprintf() symbol
> information and then to feed that buffer to printk()
>
> char buffer[KSYM_SYMBOL_LEN];
>
> sprint_symbol(buffer, address);
> printk(fmt, buffer);
>
> Replace __print_symbol() with a direct printk("%pS") call.
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
Applied to arc for-curr
Thx,
-Vineet
> ---
> arch/arc/kernel/stacktrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
> index 74315f302971..bf40e06f3fb8 100644
> --- a/arch/arc/kernel/stacktrace.c
> +++ b/arch/arc/kernel/stacktrace.c
> @@ -163,7 +163,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
> */
> static int __print_sym(unsigned int address, void *unused)
> {
> - __print_symbol(" %s\n", address);
> + printk(" %pS\n", (void *)address);
> return 0;
> }
>
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Joe Perches @ 2017-12-11 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
On Mon, 2017-12-11 at 21:50 +0900, Sergey Senozhatsky wrote:
> print_symbol
Yay.
Just about exactly 5 years earlier...
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137121.html
^ permalink raw reply
* [PATCH net v3] net: phy: meson-gxl: detect LPA corruption
From: David Miller @ 2017-12-11 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208110811.30789-1-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Fri, 8 Dec 2017 12:08:11 +0100
> I suppose this patch probably seems a bit hacky, especially the part
> about the link partner acknowledge. I'm trying to figure out if the
> value in MII_LPA makes sense but I don't have such a deep knowledge
> of the ethernet spec.
Yeah it's not the prettiest thing in the world, but if this is what you
need to check to detect this situation then there isn't much else you
can do.
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_EFUSE
From: Masahiro Yamada @ 2017-12-11 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512005215-6323-1-git-send-email-hayashibara.keiji@socionext.com>
FW: Arnd and Olof,
This patch looks trivial enough.
The reason for not-apply is
probably because this patch was sent to Catalin and Will
without Arnd and Olof even CC'ed.
Arnd, Olof,
Please consider to apply it.
This one:
https://patchwork.kernel.org/patch/10084055/
Thanks.
2017-11-30 10:26 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> Enable the efuse driver for UniPhier SoC
>
> Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 6356c6d..41e1b56 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -558,6 +558,7 @@ CONFIG_PHY_XGENE=y
> CONFIG_PHY_TEGRA_XUSB=y
> CONFIG_QCOM_L2_PMU=y
> CONFIG_QCOM_L3_PMU=y
> +CONFIG_UNIPHIER_EFUSE=y
> CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_ARM_SCPI_PROTOCOL=y
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] arm: dts: uniphier: add efuse node for UniPhier 32bit SoC
From: Masahiro Yamada @ 2017-12-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512375130-16860-1-git-send-email-hayashibara.keiji@socionext.com>
2017-12-04 17:12 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> Add efuse node for UniPhier LD4, Pro4, sLD8, Pro5 and PXs2.
> This efuse node is included in soc-glue.
>
> Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> ---
> arch/arm/boot/dts/uniphier-ld4.dtsi | 18 ++++++++++++++++++
> arch/arm/boot/dts/uniphier-pro4.dtsi | 23 +++++++++++++++++++++++
> arch/arm/boot/dts/uniphier-pro5.dtsi | 33 +++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 18 ++++++++++++++++++
> arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++++++++++++++++++
> 5 files changed, 110 insertions(+)
Applied to linux-uniphier,
but please reconsider To: list next time.
This patch was addressed to Rob and Mark,
but they do not pick up platform DT patches.
You do not need to get Rob's Ack for a patch like this.
Binding is a contract between operation system and DT.
The binding for this
(Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt)
was approved by Rob and merged in the mainline.
Given that this patch follows the binding correctly,
it should be safe.
Thanks.
> diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi b/arch/arm/boot/dts/uniphier-ld4.dtsi
> index 01fc3e1..6883f3b 100644
> --- a/arch/arm/boot/dts/uniphier-ld4.dtsi
> +++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
> @@ -273,6 +273,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-ld4-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> + };
> +
> timer at 60000200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x60000200 0x20>;
> diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi b/arch/arm/boot/dts/uniphier-pro4.dtsi
> index 7955c3a..150726b 100644
> --- a/arch/arm/boot/dts/uniphier-pro4.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
> @@ -294,6 +294,29 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pro4-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x14>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pro4-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
> index 6589b8a..f291dd6 100644
> --- a/arch/arm/boot/dts/uniphier-pro5.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
> @@ -355,6 +355,39 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pro5-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x28>;
> + };
> +
> + efuse at 300 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x300 0x14>;
> + };
> +
> + efuse at 400 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x400 0x8>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pro5-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index d82d6d8..8e54e87 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -375,6 +375,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pxs2-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x58>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pxs2-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi b/arch/arm/boot/dts/uniphier-sld8.dtsi
> index 7188536..afafe7c 100644
> --- a/arch/arm/boot/dts/uniphier-sld8.dtsi
> +++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
> @@ -277,6 +277,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-sld8-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x14>;
> + };
> + };
> +
> timer at 60000200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x60000200 0x20>;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: Dongjiu Geng @ 2017-12-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
do_sea() calls arm64_notify_die() which will always signal
user-space. It also returns whether APEI claimed the external
abort as a RAS notification. If it returns failure do_mem_abort()
will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always
call arm64_notify_die() so can always return success.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
1. Address James's comments to update the commit messages
2. Address James's comments to not change the si_code for SIGBUS
---
arch/arm64/mm/fault.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index b64958b..38b9f3e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -610,7 +610,6 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
{
struct siginfo info;
const struct fault_info *inf;
- int ret = 0;
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -625,7 +624,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
- ret = ghes_notify_sea();
+ ghes_notify_sea();
if (interrupts_enabled(regs))
nmi_exit();
@@ -640,7 +639,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
info.si_addr = (void __user *)addr;
arm64_notify_die("", regs, &info, esr);
- return ret;
+ return 0;
}
static const struct fault_info fault_info[] = {
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/2] acpi, x86: Use SPCR table for earlycon on x86
From: Prarit Bhargava @ 2017-12-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211155059.17062-1-prarit@redhat.com>
The ACPI SPCR code has been used to define an earlycon console for ARM64
and can be used for x86.
Modify the ACPI SPCR parsing code to account for console behaviour
differences between ARM64 and x86. Initialize the SPCR code from
x86 ACPI initialization code.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-acpi at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Lv Zheng <lv.zheng@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Timur Tabi <timur@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/arm64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 4 ++++
drivers/acpi/Kconfig | 2 +-
drivers/acpi/spcr.c | 7 +++++--
include/linux/acpi.h | 7 +++++--
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0d173289c67e..c7cc890a0e81 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -918,6 +918,9 @@
stdout-path property in device tree's chosen node,
or determined by the ACPI SPCR table.
+ [X86] When used with no options the early console is
+ determined by the ACPI SPCR table.
+
cdns,<addr>[,options]
Start an early, polled-mode console on a Cadence
(xuartps) serial port at the specified address. Only
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3e33bbdf3b7..aaee4864b63e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -355,7 +355,7 @@ void __init acpi_boot_table_init(void)
early_init_dt_scan_chosen_stdout();
} else {
/* Always enable the ACPI SPCR console */
- acpi_parse_spcr(console_acpi_spcr_enable);
+ acpi_parse_spcr(console_acpi_spcr_enable, true);
if (IS_ENABLED(CONFIG_ACPI_BGRT))
acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
}
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index f4c463df8b08..f01a03643cff 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -36,6 +36,7 @@
#include <linux/ioport.h>
#include <linux/pci.h>
#include <linux/efi-bgrt.h>
+#include <linux/serial_core.h>
#include <asm/e820/api.h>
#include <asm/irqdomain.h>
@@ -1626,6 +1627,9 @@ int __init acpi_boot_init(void)
if (!acpi_noirq)
x86_init.pci.init = pci_acpi_init;
+ /* Do not enable ACPI SPCR console by default */
+ acpi_parse_spcr(console_acpi_spcr_enable, console_acpi_spcr_enable);
+
return 0;
}
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9ae98eeada76..2d4e841e0682 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -80,7 +80,7 @@ endif
config ACPI_SPCR_TABLE
bool "ACPI Serial Port Console Redirection Support"
- default y if ARM64
+ default y if (X86 || ARM64)
help
Enable support for Serial Port Console Redirection (SPCR) Table.
This table provides information about the configuration of the
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index f4bb8110e404..c9469b488527 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -39,7 +39,7 @@ bool console_acpi_spcr_enable __initdata;
* from arch initialization code as soon as the DT/ACPI decision is made.
*
*/
-int __init acpi_parse_spcr(bool earlycon)
+int __init acpi_parse_spcr(bool earlycon, bool enable_console)
{
static char opts[ACPI_SPCR_OPTS_SIZE];
static char uart[ACPI_SPCR_BUF_SIZE];
@@ -112,7 +112,10 @@ int __init acpi_parse_spcr(bool earlycon)
if (earlycon)
setup_earlycon(opts);
- err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
+ if (enable_console)
+ err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
+ else
+ err = 0;
done:
acpi_put_table((struct acpi_table_header *)table);
return err;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 875d7327d91c..4c2d449bab9b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1248,10 +1248,13 @@ extern bool console_acpi_spcr_enable __initdata;
extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
char *opts, char *uart, char *iotype,
int baud_rate, bool earlycon);
-int acpi_parse_spcr(bool earlycon);
+int acpi_parse_spcr(bool earlycon, bool enable_console);
#else
static const bool console_acpi_spcr_enable;
-static inline int acpi_parse_spcr(bool earlycon) { return 0; }
+static inline int acpi_parse_spcr(bool earlycon, bool enable_console)
+{
+ return 0;
+}
#endif
#if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
--
2.15.0.rc0.39.g2f0e14e64
^ permalink raw reply related
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Prarit Bhargava @ 2017-12-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211155059.17062-1-prarit@redhat.com>
Other architectures can use SPCR to setup an early console or console
but the current code is ARM64 specific.
Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
function acpi_arch_setup_console() that can be used for arch-specific
setup. Move flags into ACPI code. Update the Documention on the use of
the SPCR.
[v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
mmio value. Move baud rate check earlier.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-acpi at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Lv Zheng <lv.zheng@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Timur Tabi <timur@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 6 +-
arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
drivers/acpi/Kconfig | 7 +-
drivers/acpi/spcr.c | 175 ++++++------------------
drivers/tty/serial/earlycon.c | 15 +-
include/linux/acpi.h | 11 +-
include/linux/serial_core.h | 2 -
7 files changed, 184 insertions(+), 160 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..0d173289c67e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -914,9 +914,9 @@
earlycon= [KNL] Output early console device and options.
- When used with no options, the early console is
- determined by the stdout-path property in device
- tree's chosen node.
+ [ARM64] The early console is determined by the
+ stdout-path property in device tree's chosen node,
+ or determined by the ACPI SPCR table.
cdns,<addr>[,options]
Start an early, polled-mode console on a Cadence
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3162715ed78..b3e33bbdf3b7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -25,7 +25,6 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/smp.h>
-#include <linux/serial_core.h>
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
@@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
return ret;
}
+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * acpi_parse_spcr().
+ */
+bool qdf2400_e44_present;
+EXPORT_SYMBOL(qdf2400_e44_present);
+
+/*
+ * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
+ * Detect them by examining the OEM fields in the SPCR header, similar to PCI
+ * quirk detection in pci_mcfg.c.
+ */
+static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
+{
+ if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
+ return false;
+
+ if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
+ return true;
+
+ if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
+ h->oem_revision == 1)
+ return true;
+
+ return false;
+}
+
+/*
+ * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
+ * register aligned to 32-bit. In addition, the BIOS also encoded the
+ * access width to be 8 bits. This function detects this errata condition.
+ */
+static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+{
+ bool xgene_8250 = false;
+
+ if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
+ return false;
+
+ if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+ memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
+ return false;
+
+ if (!memcmp(tb->header.oem_table_id, "XGENESPC",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
+ xgene_8250 = true;
+
+ if (!memcmp(tb->header.oem_table_id, "ProLiant",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
+ xgene_8250 = true;
+
+ return xgene_8250;
+}
+
+int acpi_arch_setup_console(struct acpi_table_spcr *table,
+ char *opts, char *uart, char *iotype,
+ int baud_rate, bool earlycon)
+{
+ if (table->header.revision < 2) {
+ pr_err("wrong table version\n");
+ return -ENOENT;
+ }
+
+ switch (table->interface_type) {
+ case ACPI_DBG2_ARM_SBSA_32BIT:
+ snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
+ /* fall through */
+ case ACPI_DBG2_ARM_PL011:
+ case ACPI_DBG2_ARM_SBSA_GENERIC:
+ case ACPI_DBG2_BCM2835:
+ snprintf(uart, ACPI_SPCR_BUF_SIZE, "pl011");
+ break;
+ default:
+ if (strlen(uart) == 0)
+ return -ENOENT;
+ }
+
+ /*
+ * If the E44 erratum is required, then we need to tell the pl011
+ * driver to implement the work-around.
+ *
+ * The global variable is used by the probe function when it
+ * creates the UARTs, whether or not they're used as a console.
+ *
+ * If the user specifies "traditional" earlycon, the qdf2400_e44
+ * console name matches the EARLYCON_DECLARE() statement, and
+ * SPCR is not used. Parameter "earlycon" is false.
+ *
+ * If the user specifies "SPCR" earlycon, then we need to update
+ * the console name so that it also says "qdf2400_e44". Parameter
+ * "earlycon" is true.
+ *
+ * For consistency, if we change the console name, then we do it
+ * for everyone, not just earlycon.
+ */
+ if (qdf2400_erratum_44_present(&table->header)) {
+ qdf2400_e44_present = true;
+ if (earlycon)
+ snprintf(uart, ACPI_SPCR_BUF_SIZE, "qdf2400_e44");
+ }
+
+ if (xgene_8250_erratum_present(table)) {
+ snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
+
+ /* for xgene v1 and v2 we don't know the clock rate of the
+ * UART so don't attempt to change to the baud rate state
+ * in the table because driver cannot calculate the dividers
+ */
+ snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx", uart,
+ iotype, table->serial_port.address);
+ } else {
+ snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart,
+ iotype, table->serial_port.address, baud_rate);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(acpi_arch_setup_console);
+
/*
* acpi_boot_table_init() called from setup_arch(), always.
* 1. find RSDP and get its address, and then find XSDT
@@ -230,10 +351,11 @@ void __init acpi_boot_table_init(void)
done:
if (acpi_disabled) {
- if (earlycon_init_is_deferred)
+ if (console_acpi_spcr_enable)
early_init_dt_scan_chosen_stdout();
} else {
- parse_spcr(earlycon_init_is_deferred);
+ /* Always enable the ACPI SPCR console */
+ acpi_parse_spcr(console_acpi_spcr_enable);
if (IS_ENABLED(CONFIG_ACPI_BGRT))
acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
}
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 46505396869e..9ae98eeada76 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
endif
config ACPI_SPCR_TABLE
- bool
+ bool "ACPI Serial Port Console Redirection Support"
+ default y if ARM64
+ help
+ Enable support for Serial Port Console Redirection (SPCR) Table.
+ This table provides information about the configuration of the
+ earlycon console.
config ACPI_LPIT
bool
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 324b35bfe781..f4bb8110e404 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -16,65 +16,18 @@
#include <linux/kernel.h>
#include <linux/serial_core.h>
-/*
- * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
- * occasionally getting stuck as 1. To avoid the potential for a hang, check
- * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
- * implementations, so only do so if an affected platform is detected in
- * parse_spcr().
- */
-bool qdf2400_e44_present;
-EXPORT_SYMBOL(qdf2400_e44_present);
-
-/*
- * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
- * Detect them by examining the OEM fields in the SPCR header, similiar to PCI
- * quirk detection in pci_mcfg.c.
- */
-static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
-{
- if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
- return false;
-
- if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
- return true;
-
- if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
- h->oem_revision == 1)
- return true;
-
- return false;
-}
-
-/*
- * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
- * register aligned to 32-bit. In addition, the BIOS also encoded the
- * access width to be 8 bits. This function detects this errata condition.
- */
-static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+int __weak acpi_arch_setup_console(struct acpi_table_spcr *table,
+ char *opts, char *uart, char *iotype,
+ int baud_rate, bool earlycon)
{
- bool xgene_8250 = false;
-
- if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
- return false;
-
- if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
- memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
- return false;
-
- if (!memcmp(tb->header.oem_table_id, "XGENESPC",
- ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
- xgene_8250 = true;
-
- if (!memcmp(tb->header.oem_table_id, "ProLiant",
- ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
- xgene_8250 = true;
-
- return xgene_8250;
+ snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart, iotype,
+ table->serial_port.address, baud_rate);
+ return 0;
}
+bool console_acpi_spcr_enable __initdata;
/**
- * parse_spcr() - parse ACPI SPCR table and add preferred console
+ * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
*
* @earlycon: set up earlycon for the console specified by the table
*
@@ -86,13 +39,13 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
* from arch initialization code as soon as the DT/ACPI decision is made.
*
*/
-int __init parse_spcr(bool earlycon)
+int __init acpi_parse_spcr(bool earlycon)
{
- static char opts[64];
+ static char opts[ACPI_SPCR_OPTS_SIZE];
+ static char uart[ACPI_SPCR_BUF_SIZE];
+ static char iotype[ACPI_SPCR_BUF_SIZE];
struct acpi_table_spcr *table;
acpi_status status;
- char *uart;
- char *iotype;
int baud_rate;
int err;
@@ -105,48 +58,6 @@ int __init parse_spcr(bool earlycon)
if (ACPI_FAILURE(status))
return -ENOENT;
- if (table->header.revision < 2) {
- err = -ENOENT;
- pr_err("wrong table version\n");
- goto done;
- }
-
- if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
- switch (ACPI_ACCESS_BIT_WIDTH((
- table->serial_port.access_width))) {
- default:
- pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
- case 8:
- iotype = "mmio";
- break;
- case 16:
- iotype = "mmio16";
- break;
- case 32:
- iotype = "mmio32";
- break;
- }
- } else
- iotype = "io";
-
- switch (table->interface_type) {
- case ACPI_DBG2_ARM_SBSA_32BIT:
- iotype = "mmio32";
- /* fall through */
- case ACPI_DBG2_ARM_PL011:
- case ACPI_DBG2_ARM_SBSA_GENERIC:
- case ACPI_DBG2_BCM2835:
- uart = "pl011";
- break;
- case ACPI_DBG2_16550_COMPATIBLE:
- case ACPI_DBG2_16550_SUBSET:
- uart = "uart";
- break;
- default:
- err = -ENOENT;
- goto done;
- }
-
switch (table->baud_rate) {
case 3:
baud_rate = 9600;
@@ -165,43 +76,36 @@ int __init parse_spcr(bool earlycon)
goto done;
}
- /*
- * If the E44 erratum is required, then we need to tell the pl011
- * driver to implement the work-around.
- *
- * The global variable is used by the probe function when it
- * creates the UARTs, whether or not they're used as a console.
- *
- * If the user specifies "traditional" earlycon, the qdf2400_e44
- * console name matches the EARLYCON_DECLARE() statement, and
- * SPCR is not used. Parameter "earlycon" is false.
- *
- * If the user specifies "SPCR" earlycon, then we need to update
- * the console name so that it also says "qdf2400_e44". Parameter
- * "earlycon" is true.
- *
- * For consistency, if we change the console name, then we do it
- * for everyone, not just earlycon.
- */
- if (qdf2400_erratum_44_present(&table->header)) {
- qdf2400_e44_present = true;
- if (earlycon)
- uart = "qdf2400_e44";
+ switch (table->interface_type) {
+ case ACPI_DBG2_16550_COMPATIBLE:
+ case ACPI_DBG2_16550_SUBSET:
+ snprintf(uart, ACPI_SPCR_BUF_SIZE, "uart");
+ break;
+ default:
+ break;
}
- if (xgene_8250_erratum_present(table)) {
- iotype = "mmio32";
+ if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+ u8 width = ACPI_ACCESS_BIT_WIDTH((
+ table->serial_port.access_width));
+ switch (width) {
+ default:
+ pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
+ case 8:
+ snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio");
+ break;
+ case 16:
+ case 32:
+ snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio%d", width);
+ break;
+ }
+ } else
+ snprintf(iotype, ACPI_SPCR_BUF_SIZE, "io");
- /* for xgene v1 and v2 we don't know the clock rate of the
- * UART so don't attempt to change to the baud rate state
- * in the table because driver cannot calculate the dividers
- */
- snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
- table->serial_port.address);
- } else {
- snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
- table->serial_port.address, baud_rate);
- }
+ err = acpi_arch_setup_console(table, opts, uart, iotype, baud_rate,
+ earlycon);
+ if (err)
+ goto done;
pr_info("console: %s\n", opts);
@@ -209,7 +113,6 @@ int __init parse_spcr(bool earlycon)
setup_earlycon(opts);
err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
-
done:
acpi_put_table((struct acpi_table_header *)table);
return err;
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 4c8b80f1c688..b22afb62c7a3 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -196,26 +196,15 @@ int __init setup_earlycon(char *buf)
return -ENOENT;
}
-/*
- * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
- * command line does not start DT earlycon immediately, instead it defers
- * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
- * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
- */
-bool earlycon_init_is_deferred __initdata;
-
/* early_param wrapper for setup_earlycon() */
static int __init param_setup_earlycon(char *buf)
{
int err;
- /*
- * Just 'earlycon' is a valid param for devicetree earlycons;
- * don't generate a warning from parse_early_params() in that case
- */
+ /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
if (!buf || !buf[0]) {
if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
- earlycon_init_is_deferred = true;
+ console_acpi_spcr_enable = true;
return 0;
} else if (!buf) {
return early_init_dt_scan_chosen_stdout();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfeeb5ec..875d7327d91c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1241,10 +1241,17 @@ static inline bool acpi_has_watchdog(void) { return false; }
#endif
#ifdef CONFIG_ACPI_SPCR_TABLE
+#define ACPI_SPCR_OPTS_SIZE 64
+#define ACPI_SPCR_BUF_SIZE 32
extern bool qdf2400_e44_present;
-int parse_spcr(bool earlycon);
+extern bool console_acpi_spcr_enable __initdata;
+extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
+ char *opts, char *uart, char *iotype,
+ int baud_rate, bool earlycon);
+int acpi_parse_spcr(bool earlycon);
#else
-static inline int parse_spcr(bool earlycon) { return 0; }
+static const bool console_acpi_spcr_enable;
+static inline int acpi_parse_spcr(bool earlycon) { return 0; }
#endif
#if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 37b044e78333..abfffb4b1c37 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -376,10 +376,8 @@ extern int of_setup_earlycon(const struct earlycon_id *match,
const char *options);
#ifdef CONFIG_SERIAL_EARLYCON
-extern bool earlycon_init_is_deferred __initdata;
int setup_earlycon(char *buf);
#else
-static const bool earlycon_init_is_deferred;
static inline int setup_earlycon(char *buf) { return 0; }
#endif
--
2.15.0.rc0.39.g2f0e14e64
^ permalink raw reply related
* [PATCH v2 0/2] acpi, x86: Add SPCR table support
From: Prarit Bhargava @ 2017-12-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
The SPCR (Serial Port Console Redirection) Table provides information
about the configuration of the serial port. This information can be used to
configure the early console.
SPCR support was added for ARM64 and is made available across all arches
in this patchset. The first patch adds a weak per-arch configuration function
and moves the SPCR code into ACPI. The second patch adds support to x86.
The existing behaviour on ARM64 is maintained. If the SPCR exists the
earlycon and console are automatically configured.
The existing default behaviour on x86 is also maintained. If no console or
earlycon parameter is defined and the SPCR exists, the serial port is not
configured. If the earlycon parameter is used both the early console
and the console are configured using the data from the SPCR.
Additional testing (requested by Timur): On Gigabyte (no quirks), Qualcomm
Amberwing systems to test Qualcomm quirks, HPE Mantis system to test xgene
quirks. Tested several x86 systems with and without a SPCR to confirm
no changes in default behaviour.
[v2]: See 1/2 for code changes.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-acpi at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Lv Zheng <lv.zheng@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Timur Tabi <timur@codeaurora.org>
Prarit Bhargava (2):
acpi, spcr: Make SPCR avialable to other architectures
acpi, x86: Use SPCR table for earlycon on x86
Documentation/admin-guide/kernel-parameters.txt | 9 +-
arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
arch/x86/kernel/acpi/boot.c | 4 +
drivers/acpi/Kconfig | 7 +-
drivers/acpi/spcr.c | 180 ++++++------------------
drivers/tty/serial/earlycon.c | 15 +-
include/linux/acpi.h | 14 +-
include/linux/serial_core.h | 2 -
8 files changed, 198 insertions(+), 161 deletions(-)
--
2.15.0.rc0.39.g2f0e14e64
^ permalink raw reply
* 答复: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times
From: gengdongjiu @ 2017-12-11 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A2E8DAC.1010400@arm.com>
Hi James,
Thanks for your review and suggestion.
> Hi gengdongjiu,
>
> On 08/12/17 04:43, gengdongjiu wrote:
> > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is better, as shown [1].
> > BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a error; action required".
>
> Today its also used as the last-resort. This signal tells user-space the page can't be re-read from disk/swap, and its been unmapped from all
> affected processes.
>
> I think using it like this (tempting as it is) changes the meaning.
Consider again, I think what is your said is reasonable, when the ghes_notify_sea() return failure, it means the meory_failure() does not handler the error and even not
unmapped the affected processes.
So setting the si_code to BUS_MCEERR_AR may not better, I will set the si_code to 0.
Thanks for your suggestion and reminder.
>
>
> > so it is better than "0". In the X86 platform, it also use the "BUS_MCEERR_AR" for si_code[2] in "arch/x86/mm/fault.c".
> > what do you think about it?
>
> This is heading into kernel-first territory, I'd prefer we do that all at once so we know everything is covered.
Yes, it is.
>
>
> > [2]:
> > arch/x86/mm/fault.c:
> >
> > static void
> > do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
> > u32 *pkey, unsigned int fault)
> > {
> > ......
> > #ifdef CONFIG_MEMORY_FAILURE
> > if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
>
> These VM_FAULT flags indicate memory_failure() has run, tried to re-read the memory from disk/swap, failed, and unmapped the page
> from all affected processes.
Understand, These VM_FAULT flags is different with the do_sea() handling. In the do_sea(), the memory_failure() may not run.
>
>
> > printk(KERN_ERR
> > "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
> > tsk->comm, tsk->pid, address);
> > code = BUS_MCEERR_AR;
> > }
> > #endif
> > force_sig_info_fault(SIGBUS, code, address, tsk, pkey, fault); }
>
> This is x86's page fault handler, not its Machine-Check-Exception handler.
>
> arm64's page fault handler does this too, from do_page_fault():
Yes, indeed.
just now I check the code, you are right.
> > } else if (fault & (VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE)) {
> > sig = SIGBUS;
> > code = BUS_MCEERR_AR;
>
>
> If you're seeing this, its likely due to the race Xie XiuQi spotted where the recovery action has been queued, then we return to user-space
> before its done.
>
> I had a go at tackling this, adding helpers to kick the assorted queues, which we can do if we took the exception from user-space. Where I
> got stuck is whether we should still force a signal, and how signals get merged. I'll try and spend some more time on that this week.
Understand, thanks for tacking and effort.
>
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v2 00/36] Optimize KVM/ARM for VHE systems
From: Christoffer Dall @ 2017-12-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211144323.firshrsx4dbumgou@yury-thinkpad>
Hi Yury,
On Mon, Dec 11, 2017 at 05:43:23PM +0300, Yury Norov wrote:
>
> On Thu, Dec 07, 2017 at 06:05:54PM +0100, Christoffer Dall wrote:
> > This series redesigns parts of KVM/ARM to optimize the performance on
> > VHE systems. The general approach is to try to do as little work as
> > possible when transitioning between the VM and the hypervisor. This has
> > the benefit of lower latency when waiting for interrupts and delivering
> > virtual interrupts, and reduces the overhead of emulating behavior and
> > I/O in the host kernel.
> >
> > Patches 01 through 04 are not VHE specific, but rework parts of KVM/ARM
> > that can be generally improved. We then add infrastructure to move more
> > logic into vcpu_load and vcpu_put, we improve handling of VFP and debug
> > registers.
> >
> > We then introduce a new world-switch function for VHE systems, which we
> > can tweak and optimize for VHE systems. To do that, we rework a lot of
> > the system register save/restore handling and emulation code that may
> > need access to system registers, so that we can defer as many system
> > register save/restore operations to vcpu_load and vcpu_put, and move
> > this logic out of the VHE world switch function.
> >
> > We then optimize the configuration of traps. On non-VHE systems, both
> > the host and VM kernels run in EL1, but because the host kernel should
> > have full access to the underlying hardware, but the VM kernel should
> > not, we essentially make the host kernel more privileged than the VM
> > kernel despite them both running at the same privilege level by enabling
> > VE traps when entering the VM and disabling those traps when exiting the
> > VM. On VHE systems, the host kernel runs in EL2 and has full access to
> > the hardware (as much as allowed by secure side software), and is
> > unaffected by the trap configuration. That means we can configure the
> > traps for VMs running in EL1 once, and don't have to switch them on and
> > off for every entry/exit to/from the VM.
> >
> > Finally, we improve our VGIC handling by moving all save/restore logic
> > out of the VHE world-switch, and we make it possible to truly only
> > evaluate if the AP list is empty and not do *any* VGIC work if that is
> > the case, and only do the minimal amount of work required in the course
> > of the VGIC processing when we have virtual interrupts in flight.
> >
> > The patches are based on v4.15-rc1 plus the fixes sent for v4.15-rc3
> > [1], the level-triggered mapped interrupts support series [2], and the
> > first five patches of James' SDEI series [3], a single SVE patch that
> > moves the CPU ID reg trap setup out of the world-switch path, and v3 of
> > my vcpu load/put series [4].
> >
> > I've given the patches a fair amount of testing on Thunder-X, Mustang,
> > Seattle, and TC2 (32-bit) for non-VHE testing, and tested VHE
> > functionality on the Foundation model, running both 64-bit VMs and
> > 32-bit VMs side-by-side and using both GICv3-on-GICv3 and
> > GICv2-on-GICv3.
> >
> > The patches are also available in the vhe-optimize-v2 branch on my
> > kernel.org repository [5].
> >
> > Changes since v1:
> > - Rebased on v4.15-rc1 and newer versions of other dependencies,
> > including the vcpu load/put approach taken for KVM.
> > - Addressed review comments from v1 (detailed changelogs are in the
> > individual patches).
> >
> > Thanks,
> > -Christoffer
> >
> > [1]: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm kvm-arm-fixes-for-v4.15-1
> > [2]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v6
> > [3]: git://linux-arm.org/linux-jm.git sdei/v5/base
> > [4]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vcpu-load-put-v3
> > [5]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vhe-optimize-v2
>
> I just submitted the benchmark I used to test your v1 and v2 series':
> https://lkml.org/lkml/2017/12/11/364
>
> On ThunderX2, 112 online CPUs test results for v1 are like this:
>
> Host, v4.14:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 81 110
> Broadcast IPI: 0 2106
>
> Guest, v4.14:
> Dry-run: 0 1
> Self-IPI: 10 18
> Normal IPI: 305 525
> Broadcast IPI: 0 9729
>
> Guest, v4.14 + VHE:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 176 343
> Broadcast IPI: 0 9885
>
> And for v2.
>
> Host, v4.15:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 79 108
> Broadcast IPI: 0 2102
>
> Guest, v4.15-rc:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 291 526
> Broadcast IPI: 0 10439
>
> Guest, v4.15-rc + VHE:
> Dry-run: 0 2
> Self-IPI: 14 28
> Normal IPI: 370 569
> Broadcast IPI: 0 11688
>
> All times are normalized to v1 host dry-run time. Smaller - better.
>
Thanks for running this.
> Results for v1 and v2 may vary because kernel version is changed.
> What makes us worry is slowing down the "Normal IPI" test observed in
> v2 series.
I'm wondering if this is not simply variability in your measurements.
How many times have you run this? The 100,000 iterations for each run
is not a lot if you consider the cost of migrating threads.
Is this workload pinned to a single CPU? Is the system otherwise idle
(both host and guest)? If you run this during boot or during kernel
module load, the results may be skewed by that.
Power management can greatly influence results as well.
Just so I'm sure we're reading these reults the same way, your "+ VHE"
notation means the VHE optimization series, but both the before and
after picture runs with VHE enabled, right?
Are you using the same guest kernel version and config for both your v1
and v2 results, and for both the before and after versions?
I can't easily come up with a scneario that explains the slowdown on the
normal IPI test, beyond some unfortunate bug introduced in v2.
>
> Nevertheless, if you find test relevant, for v1 and v2,
> Tested-by: Yury Norov <ynorov@caviumnetworks.com>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] IPI performance benchmark
From: Konrad Rzeszutek Wilk @ 2017-12-11 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141600.24401-1-ynorov@caviumnetworks.com>
On Mon, Dec 11, 2017 at 05:16:00PM +0300, Yury Norov wrote:
> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
>
> The scenarios are:
> Dry-run: do everything except actually sending IPI. Useful
> to estimate system overhead.
> Self-IPI: Send IPI to self CPU.
> Normal IPI: Send IPI to some other CPU.
> Broadcast IPI: Send broadcast IPI to all online CPUs.
>
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems".
>
> https://www.spinics.net/lists/kvm/msg156755.html
>
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time. Smaller - better.
Would it make sense to also add spinlock contention tests? Meaning make
this framework a bit more generic so you could do IPI and you could
also do spinlock contention?
Like:
http://xenbits.xen.org/gitweb/?p=xentesttools/bootstrap.git;a=blob;f=root_image/drivers/spinlock_hog/spinlock_hog.c;h=040a154808452576b1aa5720a6282981319a5360;hb=HEAD
And then also this could be used for an CPU intensive
test to see how well virtualization schedulers work:
http://xenbits.xen.org/gitweb/?p=xentesttools/bootstrap.git;a=blob;f=root_image/drivers/ipi_hog/ipi_hog.c;h=6dcc4f3382c29c42fec077791cc53bc52e6d8868;hb=HEAD
(asking as it never occurred to me upstream those test-cases
but if folks are OK with Yury little module, then other things
could be done as well with it).
>
> Host, v4.14:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 81 110
> Broadcast IPI: 0 2106
>
> Guest, v4.14:
> Dry-run: 0 1
> Self-IPI: 10 18
> Normal IPI: 305 525
> Broadcast IPI: 0 9729
>
> Guest, v4.14 + VHE:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 176 343
> Broadcast IPI: 0 9885
>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Ashish Kalra <Ashish.Kalra@cavium.com>
> CC: Christoffer Dall <christoffer.dall@linaro.org>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> CC: Linu Cherian <Linu.Cherian@cavium.com>
> CC: Sunil Goutham <Sunil.Goutham@cavium.com>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> ---
> arch/Kconfig | 10 ++++
> kernel/Makefile | 1 +
> kernel/ipi_benchmark.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 145 insertions(+)
> create mode 100644 kernel/ipi_benchmark.c
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 057370a0ac4e..80d6ef439199 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -82,6 +82,16 @@ config JUMP_LABEL
> ( On 32-bit x86, the necessary options added to the compiler
> flags may increase the size of the kernel slightly. )
>
> +config IPI_BENCHMARK
> + tristate "Test IPI performance on SMP systems"
> + depends on SMP
> + help
> + Test IPI performance on SMP systems. If system has only one online
> + CPU, sending IPI to other CPU is obviously not possible, and ENOENT
> + is returned for corresponding test.
> +
> + If unsure, say N.
> +
> config STATIC_KEYS_SELFTEST
> bool "Static key selftest"
> depends on JUMP_LABEL
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 172d151d429c..04e550e1990c 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -101,6 +101,7 @@ obj-$(CONFIG_TRACEPOINTS) += trace/
> obj-$(CONFIG_IRQ_WORK) += irq_work.o
> obj-$(CONFIG_CPU_PM) += cpu_pm.o
> obj-$(CONFIG_BPF) += bpf/
> +obj-$(CONFIG_IPI_BENCHMARK) += ipi_benchmark.o
>
> obj-$(CONFIG_PERF_EVENTS) += events/
>
> diff --git a/kernel/ipi_benchmark.c b/kernel/ipi_benchmark.c
> new file mode 100644
> index 000000000000..35f1f7598c36
> --- /dev/null
> +++ b/kernel/ipi_benchmark.c
> @@ -0,0 +1,134 @@
> +/*
> + * Performance test for IPI on SMP machines.
> + *
> + * Copyright (c) 2017 Cavium Networks.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of version 2 of the GNU General Public
> + * License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/ktime.h>
> +
> +#define NTIMES 100000
> +
> +#define POKE_ANY 0
> +#define DRY_RUN 1
> +#define POKE_SELF 2
> +#define POKE_ALL 3
> +
> +static void __init handle_ipi(void *t)
> +{
> + ktime_t *time = (ktime_t *) t;
> +
> + if (time)
> + *time = ktime_get() - *time;
> +}
> +
> +static ktime_t __init send_ipi(int flags)
> +{
> + ktime_t time;
> + unsigned int cpu = get_cpu();
> +
> + switch (flags) {
> + case POKE_ALL:
> + /* If broadcasting, don't force all CPUs to update time. */
> + smp_call_function_many(cpu_online_mask, handle_ipi, NULL, 1);
> + /* Fall thru */
> + case DRY_RUN:
> + /* Do everything except actually sending IPI. */
> + time = 0;
> + break;
> + case POKE_ANY:
> + cpu = cpumask_any_but(cpu_online_mask, cpu);
> + if (cpu >= nr_cpu_ids) {
> + time = -ENOENT;
> + break;
> + }
> + /* Fall thru */
> + case POKE_SELF:
> + time = ktime_get();
> + smp_call_function_single(cpu, handle_ipi, &time, 1);
> + break;
> + default:
> + time = -EINVAL;
> + }
> +
> + put_cpu();
> + return time;
> +}
> +
> +static int __init __bench_ipi(unsigned long i, ktime_t *time, int flags)
> +{
> + ktime_t t;
> +
> + *time = 0;
> + while (i--) {
> + t = send_ipi(flags);
> + if ((int) t < 0)
> + return (int) t;
> +
> + *time += t;
> + }
> +
> + return 0;
> +}
> +
> +static int __init bench_ipi(unsigned long times, int flags,
> + ktime_t *ipi, ktime_t *total)
> +{
> + int ret;
> +
> + *total = ktime_get();
> + ret = __bench_ipi(times, ipi, flags);
> + if (unlikely(ret))
> + return ret;
> +
> + *total = ktime_get() - *total;
> +
> + return 0;
> +}
> +
> +static int __init init_bench_ipi(void)
> +{
> + ktime_t ipi, total;
> + int ret;
> +
> + ret = bench_ipi(NTIMES, DRY_RUN, &ipi, &total);
> + if (ret)
> + pr_err("Dry-run FAILED: %d\n", ret);
> + else
> + pr_err("Dry-run: %18llu, %18llu ns\n", ipi, total);
> +
> + ret = bench_ipi(NTIMES, POKE_SELF, &ipi, &total);
> + if (ret)
> + pr_err("Self-IPI FAILED: %d\n", ret);
> + else
> + pr_err("Self-IPI: %18llu, %18llu ns\n", ipi, total);
> +
> + ret = bench_ipi(NTIMES, POKE_ANY, &ipi, &total);
> + if (ret)
> + pr_err("Normal IPI FAILED: %d\n", ret);
> + else
> + pr_err("Normal IPI: %18llu, %18llu ns\n", ipi, total);
> +
> + ret = bench_ipi(NTIMES, POKE_ALL, &ipi, &total);
> + if (ret)
> + pr_err("Broadcast IPI FAILED: %d\n", ret);
> + else
> + pr_err("Broadcast IPI: %18llu, %18llu ns\n", ipi, total);
> +
> + /* Return error to avoid annoying rmmod. */
> + return -EINVAL;
> +}
> +module_init(init_bench_ipi);
> +
> +MODULE_LICENSE("GPL");
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2 3/4] thermal: armada: add support for CP110
From: Baruch Siach @ 2017-12-11 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211160932.692ba8be@xps13>
Hi Miquel,
On Mon, Dec 11, 2017 at 04:09:32PM +0100, Miquel RAYNAL wrote:
> On Sun, 3 Dec 2017 13:11:23 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
>
> > The CP110 component is integrated in the Armada 8k and 7k lines of
> > processors.
> >
> > This patch also adds an option of offset to the MSB of the control
> > register. The existing DT binding for Armada 38x refers to a single
> > 32 bit control register. It turns out that this is actually only the
> > MSB of the control area. Changing the binding to fix that would break
> > existing DT files, so the Armada 38x binding is left as is.
> >
> > The new CP110 binding increases the size of the control area to 64
> > bits, thus moving the MSB to offset 4.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > v2: No change
> > ---
> > drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
> > 1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 0eb82097571f..59b75f63945d
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -73,6 +73,7 @@ struct armada_thermal_data {
> > unsigned int temp_shift;
> > unsigned int temp_mask;
> > unsigned int is_valid_shift;
> > + unsigned int control_msb_offset;
> > };
> >
> > static void armadaxp_init_sensor(struct platform_device *pdev,
> > @@ -142,12 +143,14 @@ static void armada375_init_sensor(struct
> > platform_device *pdev, static void armada380_init_sensor(struct
> > platform_device *pdev, struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg = readl_relaxed(priv->control);
> > + void __iomem *control_msb =
> > + priv->control + priv->data->control_msb_offset;
> > + unsigned long reg = readl_relaxed(control_msb);
> >
> > /* Reset hardware once */
> > if (!(reg & A380_HW_RESET)) {
> > reg |= A380_HW_RESET;
> > - writel(reg, priv->control);
> > + writel(reg, control_msb);
> > mdelay(10);
> > }
> > }
> > @@ -266,6 +269,19 @@ static const struct armada_thermal_data
> > armada_ap806_data = { .signed_sample = true,
> > };
> >
> > +static const struct armada_thermal_data armada_cp110_data = {
> > + .is_valid = armada_is_valid,
> > + .init_sensor = armada380_init_sensor,
>
> I see the initialization for CP110 thermal IP is close to
> Armada-380's, but, as you point it in the commit log it is still
> different.
>
> I don't know what is the best way to handle this but until now each
> new compatible had his own ->init_sensor function, shouldn't we do
> the same here as changes are requested? This would naturally avoid the
> situation with Armada-380 bindings.
I'm not sure I understand your suggestion.
There is no difference between the CP110 and the Armada 38x, as far as I can
see. The only quirk is that the existing Armada 38x DT binding is wrong I that
the 'reg' property references the control MSB, while leaving the LSB out. We
can't change the Armada 38x binding without breaking existing DTs. The
'control_msb_offset' field that this patch adds allows correct binding for
CP110, while keeping compatibility with the existing Armada 38x binding.
How would a separate init_sensor routine improve things?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 01/19] arm64: asm-offsets: Avoid clashing DMA definitions
From: Marc Zyngier @ 2017-12-11 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211150307.GV10595@n2100.armlinux.org.uk>
On 11/12/17 15:03, Russell King - ARM Linux wrote:
> On Mon, Dec 11, 2017 at 02:49:19PM +0000, Marc Zyngier wrote:
>> asm-offsets.h contains a few DMA related definitions that have
>> the exact same name than the enum members they are derived from.
>>
>> While this is not a problem so far, it will become an issue if
>> both asm-offsets.h and include/linux/dma-direction.h: are pulled
>> by the same file.
>
> Umm. asm-offsets.h is only supposed to be included by assembly files.
> Assembly files would not be able to include linux/dma-direction.h
> So this shouldn't be a problem.
>
> The same could be true of things like CLOCK_REALTIME etc.
>
> Just don't do it. Keep asm-offsets.h as something that gets included
> by assembly and only assembly.
That'd be true if C code never used anything that is exposed by
asm-offsets.h. Unfortunately, things like our alternative patching
relies on generating assembly (or rather, using assembly generated data
structures). For more details, please see patch 4 in the same series.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 14/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl
From: Christoffer Dall @ 2017-12-11 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141241.2129a84c.cohuck@redhat.com>
On Mon, Dec 11, 2017 at 02:12:41PM +0100, Cornelia Huck wrote:
> On Mon, 4 Dec 2017 21:35:36 +0100
> Christoffer Dall <cdall@kernel.org> wrote:
>
> > From: Christoffer Dall <christoffer.dall@linaro.org>
> >
> > Move the calls to vcpu_load() and vcpu_put() in to the architecture
> > specific implementations of kvm_arch_vcpu_ioctl() which dispatches
> > further architecture-specific ioctls on to other functions.
> >
> > Some architectures support asynchronous vcpu ioctls which cannot call
> > vcpu_load() or take the vcpu->mutex, because that would prevent
> > concurrent execution with a running VCPU, which is the intended purpose
> > of these ioctls, for example because they inject interrupts.
> >
> > We repeat the separate checks for these specifics in the architecture
> > code for MIPS, S390 and PPC, and avoid taking the vcpu->mutex and
> > calling vcpu_load for these ioctls.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/mips/kvm/mips.c | 49 +++++++++++++++++++++++----------------
> > arch/powerpc/kvm/powerpc.c | 13 ++++++-----
> > arch/s390/kvm/kvm-s390.c | 19 ++++++++-------
> > arch/x86/kvm/x86.c | 22 +++++++++++++-----
> > virt/kvm/arm/arm.c | 58 ++++++++++++++++++++++++++++++++--------------
> > virt/kvm/kvm_main.c | 2 --
> > 6 files changed, 103 insertions(+), 60 deletions(-)
> >
> > diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> > index 3a898712d6cd..4a039341dc29 100644
> > --- a/arch/mips/kvm/mips.c
> > +++ b/arch/mips/kvm/mips.c
> > @@ -913,56 +913,65 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned int ioctl,
> > void __user *argp = (void __user *)arg;
> > long r;
> >
> > + if (ioctl == KVM_INTERRUPT) {
>
> I would add a comment here that this ioctl is async to vcpu execution,
> so it is understandable why you skip the vcpu_load().
Yes, that would be appropriate.
>
> [As an aside, it is nice that this is now more obvious when looking at
> the architectures' handlers.]
>
Agreed.
> > + struct kvm_mips_interrupt irq;
> > +
> > + if (copy_from_user(&irq, argp, sizeof(irq)))
> > + return -EFAULT;
> > + kvm_debug("[%d] %s: irq: %d\n", vcpu->vcpu_id, __func__,
> > + irq.irq);
> > +
> > + return kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> > + }
> > +
> > + vcpu_load(vcpu);
> > +
> > switch (ioctl) {
>
> (...)
>
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index c06bc9552438..6b5dd3a25fe8 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -1617,16 +1617,16 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> > void __user *argp = (void __user *)arg;
> > long r;
> >
> > - switch (ioctl) {
> > - case KVM_INTERRUPT: {
> > + if (ioctl == KVM_INTERRUPT) {
>
> Same here.
>
> > struct kvm_interrupt irq;
> > - r = -EFAULT;
> > if (copy_from_user(&irq, argp, sizeof(irq)))
> > - goto out;
> > - r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> > - goto out;
> > + return -EFAULT;
> > + return kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> > }
> >
> > + vcpu_load(vcpu);
> > +
> > + switch (ioctl) {
> > case KVM_ENABLE_CAP:
> > {
> > struct kvm_enable_cap cap;
> > @@ -1666,6 +1666,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> > }
> >
> > out:
> > + vcpu_put(vcpu);
> > return r;
> > }
> >
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index 43278f334ce3..cd067b63d77f 100644
> > --- a/arch/s390/kvm/kvm-s390.c
> > +++ b/arch/s390/kvm/kvm-s390.c
> > @@ -3743,24 +3743,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> > case KVM_S390_IRQ: {
> > struct kvm_s390_irq s390irq;
> >
> > - r = -EFAULT;
> > if (copy_from_user(&s390irq, argp, sizeof(s390irq)))
> > - break;
> > - r = kvm_s390_inject_vcpu(vcpu, &s390irq);
> > - break;
> > + return -EFAULT;
> > + return kvm_s390_inject_vcpu(vcpu, &s390irq);
> > }
> > case KVM_S390_INTERRUPT: {
> > struct kvm_s390_interrupt s390int;
> > struct kvm_s390_irq s390irq;
> >
> > - r = -EFAULT;
> > if (copy_from_user(&s390int, argp, sizeof(s390int)))
> > - break;
> > + return -EFAULT;
> > if (s390int_to_s390irq(&s390int, &s390irq))
> > return -EINVAL;
> > - r = kvm_s390_inject_vcpu(vcpu, &s390irq);
> > - break;
> > + return kvm_s390_inject_vcpu(vcpu, &s390irq);
> > }
> > + }
>
> I find the special casing with the immediate return a bit ugly. Maybe
> introduce a helper async_vcpu_ioctl() or so that sets -ENOIOCTLCMD in
> its default case and return here if ret != -ENOIOCTLCMD? Christian,
> what do you think?
>
> > +
> > + vcpu_load(vcpu);
> > +
> > + switch (ioctl) {
> > case KVM_S390_STORE_STATUS:
> > idx = srcu_read_lock(&vcpu->kvm->srcu);
> > r = kvm_s390_vcpu_store_status(vcpu, arg);
> > @@ -3883,6 +3884,8 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> > default:
> > r = -ENOTTY;
> > }
> > +
> > + vcpu_put(vcpu);
> > return r;
> > }
> >
>
> (...)
>
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 06751bbecd58..ad5f83159a15 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2693,9 +2693,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> > break;
> > }
> > default:
> > - vcpu_load(vcpu);
> > r = kvm_arch_vcpu_ioctl(filp, ioctl, arg);
> > - vcpu_put(vcpu);
> > }
> > out:
> > mutex_unlock(&vcpu->mutex);
>
> It would be nice if we could get rid of the special casing at the
> beginning of this function, but as it would involve not taking the
> mutex for special cases (and not releasing it for those special cases),
> I don't see an elegant way to do that.
I would also have liked that, and that's essentially what I had in the
first version, but Paolo thought the result was too high an increase in
complexity in the architecture-specfic functions throughout. I don't
have any better suggestions either.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string
From: Tony Lindgren @ 2017-12-11 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <280160905017f67c91b96bf38ea9b6094ec277c3.1512114082.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [171201 07:44]:
> Official vendor string is now "tpo" and not "toppoly".
>
> Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
> so that the driver understands both.
Tomi, so what's the plan with the dependency patch, is that for v4.16
or for the v4.15-rc cycle?
Regards,
Tony
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>
> /* lcd panel */
> lcd: td028ttec1 at 0 {
> - compatible = "toppoly,td028ttec1";
> + compatible = "tpo,td028ttec1";
> reg = <0>;
> spi-max-frequency = <100000>;
> spi-cpol;
> --
> 2.12.2
>
^ permalink raw reply
* [PATCH v3 11/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_guest_debug
From: Christoffer Dall @ 2017-12-11 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211133943.236f18be.cohuck@redhat.com>
On Mon, Dec 11, 2017 at 01:39:43PM +0100, Cornelia Huck wrote:
> On Mon, 4 Dec 2017 21:35:33 +0100
> Christoffer Dall <cdall@kernel.org> wrote:
>
> > From: Christoffer Dall <christoffer.dall@linaro.org>
> >
> > Move vcpu_load() and vcpu_put() into the architecture specific
> > implementations of kvm_arch_vcpu_ioctl_set_guest_debug().
> >
> > Reviewed-by: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/guest.c | 15 ++++++++++++---
> > arch/powerpc/kvm/book3s.c | 2 ++
> > arch/powerpc/kvm/booke.c | 19 +++++++++++++------
> > arch/s390/kvm/kvm-s390.c | 16 ++++++++++++----
> > arch/x86/kvm/x86.c | 4 +++-
> > virt/kvm/kvm_main.c | 2 --
> > 6 files changed, 42 insertions(+), 16 deletions(-)
> >
>
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index 1b491b89cd43..7cb0e2677e60 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -2018,12 +2018,15 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> > {
> > struct debug_reg *dbg_reg;
> > int n, b = 0, w = 0;
> > + int ret = 0;
> > +
> > + vcpu_load(vcpu);
> >
> > if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
> > vcpu->arch.dbg_reg.dbcr0 = 0;
> > vcpu->guest_debug = 0;
> > kvm_guest_protect_msr(vcpu, MSR_DE, false);
> > - return 0;
> > + goto out;
> > }
> >
> > kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > @@ -2055,8 +2058,9 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> > #endif
> >
> > if (!(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP))
> > - return 0;
> > + goto out;
> >
> > + ret = -EINVAL;
> > for (n = 0; n < (KVMPPC_BOOKE_IAC_NUM + KVMPPC_BOOKE_DAC_NUM); n++) {
> > uint64_t addr = dbg->arch.bp[n].addr;
> > uint32_t type = dbg->arch.bp[n].type;
> > @@ -2067,21 +2071,24 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> > if (type & ~(KVMPPC_DEBUG_WATCH_READ |
> > KVMPPC_DEBUG_WATCH_WRITE |
> > KVMPPC_DEBUG_BREAKPOINT))
> > - return -EINVAL;
> > + goto out;
> >
> > if (type & KVMPPC_DEBUG_BREAKPOINT) {
> > /* Setting H/W breakpoint */
> > if (kvmppc_booke_add_breakpoint(dbg_reg, addr, b++))
> > - return -EINVAL;
> > + goto out;
> > } else {
> > /* Setting H/W watchpoint */
> > if (kvmppc_booke_add_watchpoint(dbg_reg, addr,
> > type, w++))
> > - return -EINVAL;
> > + goto out;
> > }
> > }
> >
> > - return 0;
> > + ret = 0;
>
> I would probably set the -EINVAL in the individual branches (so it is
> clear that something is wrong, and it is not just a benign exit as in
> the cases above), but your code is correct as well.
I think that's better as well actually. I got probably got a little
used to that pattern after looking the main dispatcher function for a
while. I'm happy to change it.
> > +out:
> > + vcpu_put(vcpu);
> > + return ret;
> > }
> >
> > void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>
> In any case,
>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Thanks!
-Christoffer
^ permalink raw reply
* [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: Tony Lindgren @ 2017-12-11 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a27001ba-5ffd-365d-93e3-06fd1a2e01c2@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [171201 02:03]:
> On 01/12/17 11:48, H. Nikolaus Schaller wrote:
>
> > Just a note: there is no toppoly->tpo change for *this* panel and
> > Pandora board. Just omapdss removal.
> >
> > The GTA04 needs a toppoly->tpo change but no omapdss, removal.
> >
> > So they solve different problems and are independent of each other.
> >
> > GTA04: change vendor string
> > Pandora: remove omapdss, prefix
>
> Oh, right, I totally missed that. I thought they were changes to the
> same file...
>
> In that case, Tony, can you pick this one as a fix? I'll pick the
> toppoly->tpo patch and merge via drm tree, if you give the ack.
>
> For this:
>
> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Sorry I've lost track of this thread and what if anything is really
needed as a fix for v4.16. And now there's newer version of the two
dts patches in thread "[PATCH v4 0/2] Fixes for omapdrm on
OpenPandora and GTA04" so let's move the discussion there.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 00/36] Optimize KVM/ARM for VHE systems
From: Yury Norov @ 2017-12-11 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e238af17-d63c-52cd-c411-c2d3f3d86994@arm.com>
On Mon, Dec 11, 2017 at 02:56:01PM +0000, Marc Zyngier wrote:
> On 11/12/17 14:43, Yury Norov wrote:
> > Hi Christoffer,
> >
> > On Thu, Dec 07, 2017 at 06:05:54PM +0100, Christoffer Dall wrote:
> >> This series redesigns parts of KVM/ARM to optimize the performance on
> >> VHE systems. The general approach is to try to do as little work as
> >> possible when transitioning between the VM and the hypervisor. This has
> >> the benefit of lower latency when waiting for interrupts and delivering
> >> virtual interrupts, and reduces the overhead of emulating behavior and
> >> I/O in the host kernel.
> >>
> >> Patches 01 through 04 are not VHE specific, but rework parts of KVM/ARM
> >> that can be generally improved. We then add infrastructure to move more
> >> logic into vcpu_load and vcpu_put, we improve handling of VFP and debug
> >> registers.
> >>
> >> We then introduce a new world-switch function for VHE systems, which we
> >> can tweak and optimize for VHE systems. To do that, we rework a lot of
> >> the system register save/restore handling and emulation code that may
> >> need access to system registers, so that we can defer as many system
> >> register save/restore operations to vcpu_load and vcpu_put, and move
> >> this logic out of the VHE world switch function.
> >>
> >> We then optimize the configuration of traps. On non-VHE systems, both
> >> the host and VM kernels run in EL1, but because the host kernel should
> >> have full access to the underlying hardware, but the VM kernel should
> >> not, we essentially make the host kernel more privileged than the VM
> >> kernel despite them both running at the same privilege level by enabling
> >> VE traps when entering the VM and disabling those traps when exiting the
> >> VM. On VHE systems, the host kernel runs in EL2 and has full access to
> >> the hardware (as much as allowed by secure side software), and is
> >> unaffected by the trap configuration. That means we can configure the
> >> traps for VMs running in EL1 once, and don't have to switch them on and
> >> off for every entry/exit to/from the VM.
> >>
> >> Finally, we improve our VGIC handling by moving all save/restore logic
> >> out of the VHE world-switch, and we make it possible to truly only
> >> evaluate if the AP list is empty and not do *any* VGIC work if that is
> >> the case, and only do the minimal amount of work required in the course
> >> of the VGIC processing when we have virtual interrupts in flight.
> >>
> >> The patches are based on v4.15-rc1 plus the fixes sent for v4.15-rc3
> >> [1], the level-triggered mapped interrupts support series [2], and the
> >> first five patches of James' SDEI series [3], a single SVE patch that
> >> moves the CPU ID reg trap setup out of the world-switch path, and v3 of
> >> my vcpu load/put series [4].
> >>
> >> I've given the patches a fair amount of testing on Thunder-X, Mustang,
> >> Seattle, and TC2 (32-bit) for non-VHE testing, and tested VHE
> >> functionality on the Foundation model, running both 64-bit VMs and
> >> 32-bit VMs side-by-side and using both GICv3-on-GICv3 and
> >> GICv2-on-GICv3.
> >>
> >> The patches are also available in the vhe-optimize-v2 branch on my
> >> kernel.org repository [5].
> >>
> >> Changes since v1:
> >> - Rebased on v4.15-rc1 and newer versions of other dependencies,
> >> including the vcpu load/put approach taken for KVM.
> >> - Addressed review comments from v1 (detailed changelogs are in the
> >> individual patches).
> >>
> >> Thanks,
> >> -Christoffer
> >>
> >> [1]: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm kvm-arm-fixes-for-v4.15-1
> >> [2]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v6
> >> [3]: git://linux-arm.org/linux-jm.git sdei/v5/base
> >> [4]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vcpu-load-put-v3
> >> [5]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vhe-optimize-v2
> >
> > I just submitted the benchmark I used to test your v1 and v2 series':
> > https://lkml.org/lkml/2017/12/11/364
> >
> > On ThunderX2, 112 online CPUs test results for v1 are like this:
> >
> > Host, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 81 110
> > Broadcast IPI: 0 2106
> >
> > Guest, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 10 18
> > Normal IPI: 305 525
> > Broadcast IPI: 0 9729
> >
> > Guest, v4.14 + VHE:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 176 343
> > Broadcast IPI: 0 9885
> >
> > And for v2.
> >
> > Host, v4.15:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 79 108
> > Broadcast IPI: 0 2102
> >
> > Guest, v4.15-rc:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 291 526
> > Broadcast IPI: 0 10439
> >
> > Guest, v4.15-rc + VHE:
> > Dry-run: 0 2
> > Self-IPI: 14 28
> > Normal IPI: 370 569
> > Broadcast IPI: 0 11688
> >
> > All times are normalized to v1 host dry-run time. Smaller - better.
> >
> > Results for v1 and v2 may vary because kernel version is changed.
> > What makes us worry is slowing down the "Normal IPI" test observed in
> > v2 series.
> It'd be interesting if you could profile your system to find our where
> you're spending time. My own tests, with a different benchmark, did show
> a 40% reduction in the number of *cycles*.
40% reduction is what I also observed for v1, to be specific - 42%.
So I was surprised when found v2 slower than vanilla kernel. Did you
observe 40% reduction for v2 or v1, or both?
I also think to switch to *cycles* as it (doubtly) might be CPU
frequency scaling issue, and do some profiling.
Yury
^ permalink raw reply
* [PATCH v2 3/4] thermal: armada: add support for CP110
From: Miquel RAYNAL @ 2017-12-11 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d48c916a2502f9c75e9ea4ba41300e2ffbb254d8.1512299484.git.baruch@tkos.co.il>
Hello Baruch,
On Sun, 3 Dec 2017 13:11:23 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> The CP110 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> This patch also adds an option of offset to the MSB of the control
> register. The existing DT binding for Armada 38x refers to a single
> 32 bit control register. It turns out that this is actually only the
> MSB of the control area. Changing the binding to fix that would break
> existing DT files, so the Armada 38x binding is left as is.
>
> The new CP110 binding increases the size of the control area to 64
> bits, thus moving the MSB to offset 4.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v2: No change
> ---
> drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c
> b/drivers/thermal/armada_thermal.c index 0eb82097571f..59b75f63945d
> 100644 --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -73,6 +73,7 @@ struct armada_thermal_data {
> unsigned int temp_shift;
> unsigned int temp_mask;
> unsigned int is_valid_shift;
> + unsigned int control_msb_offset;
> };
>
> static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -142,12 +143,14 @@ static void armada375_init_sensor(struct
> platform_device *pdev, static void armada380_init_sensor(struct
> platform_device *pdev, struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->control);
> + void __iomem *control_msb =
> + priv->control + priv->data->control_msb_offset;
> + unsigned long reg = readl_relaxed(control_msb);
>
> /* Reset hardware once */
> if (!(reg & A380_HW_RESET)) {
> reg |= A380_HW_RESET;
> - writel(reg, priv->control);
> + writel(reg, control_msb);
> mdelay(10);
> }
> }
> @@ -266,6 +269,19 @@ static const struct armada_thermal_data
> armada_ap806_data = { .signed_sample = true,
> };
>
> +static const struct armada_thermal_data armada_cp110_data = {
> + .is_valid = armada_is_valid,
> + .init_sensor = armada380_init_sensor,
I see the initialization for CP110 thermal IP is close to
Armada-380's, but, as you point it in the commit log it is still
different.
I don't know what is the best way to handle this but until now each
new compatible had his own ->init_sensor function, shouldn't we do
the same here as changes are requested? This would naturally avoid the
situation with Armada-380 bindings.
Thanks,
Miqu?l
^ 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