* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Florian Fainelli @ 2018-06-07 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528309291-25579-1-git-send-email-scott.branden@broadcom.com>
On Wed, 6 Jun 2018 11:21:31 -0700, Scott Branden <scott.branden@broadcom.com> wrote:
> From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>
> Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
>
> Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
The following sensors are on I2C3 on the baseboard:
* isil,isl29023 light sensor
* fsl,mag3110 magnetometer
* fsl,mma8451 accelerometer
Added under i2cmux/i2c at 1 because they're not otherwise accessible.
These are all supported by iio with following configs:
* CONFIG_SENSORS_ISL29018
* CONFIG_MAG3110
* CONFIG_MMA8452
Tested with raw reads from iio sysfs.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 54b0139e978d..a6193240259d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -160,10 +160,31 @@
compatible = "maxim,max7310";
reg = <0x34>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ isl29023 at 44 {
+ compatible = "isil,isl29023";
+ reg = <0x44>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ mag3110 at 0e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ mma8451 at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
};
&ipu1_csi0_from_ipu1_csi0_mux {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] imx_v6_v7_defconfig: Enable imx6qdl-sabreauto sensors
From: Leonard Crestez @ 2018-06-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b31ca3ff50566c193003614d0bbf5e0a0e95901c.1528390418.git.leonard.crestez@nxp.com>
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 3a308437b088..7efcce8083d2 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -364,12 +364,14 @@ CONFIG_MXS_DMA=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
+CONFIG_MMA8452=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Fabio Estevam @ 2018-06-07 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b31ca3ff50566c193003614d0bbf5e0a0e95901c.1528390418.git.leonard.crestez@nxp.com>
Hi Leonard,
On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez <leonard.crestez@nxp.com> wrote:
> +
> + isl29023 at 44 {
According to Devicetree Specification v0.2 document:
"The name of a node should be somewhat generic, reflecting the function
of the device and not its precise programming model."
So you could write:
light-sensor at 44
> + compatible = "isil,isl29023";
> + reg = <0x44>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> + mag3110 at 0e {
No leading zero in unit address, please.
Building with W=1 will give you warnings about it.
magnetometer at e
> + compatible = "fsl,mag3110";
> + reg = <0x0e>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <29 IRQ_TYPE_EDGE_RISING>;
> + };
> +
> + mma8451 at 1c {
accelerometer at 1c
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Kim Phillips @ 2018-06-07 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <adbabdb0-df2c-be74-3cde-cda4f6bce579@arm.com>
On Thu, 7 Jun 2018 11:07:15 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
> > On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
> >> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
> >>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
> >>>> Hi Greg,
> >>>>
> >>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
> >>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
> >>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
> >>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>>>>>
> >>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
> >>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
> >>>>>>>>> Increment the refcnt for driver modules in current use by calling
> >>>>>>>>> module_get in coresight_build_path and module_put in release_path.
> >>>>>>>>>
> >>>>>>>>> This prevents driver modules from being unloaded when they are in use,
> >>>>>>>>> either in sysfs or perf mode.
> >>>>>>>>
> >>>>>>>> Why does it matter? Shouldn't you be allowed to remove any module at
> >>>>>>>> any point in time, much like a networking driver?
> >>>>
> >>>> The user doesn't have an explicit refcount on the individual components
> >>>> in a trace session. So, when a trace session is in progress, it is as
> >>>> good as having a "file" open on each component that is part of the
> >>>> active trace session. So, we don't want the driver to be removed when
> >>>> the component is being used in the trace collection.
> >>>
> >>> Why not? What's wrong with that happening and then the trace collection
> >>> starts failing with -ENODEV or something?
> >>
> >> May be I am missing something here. Can we allow the driver to be removed
> >> when one of its device is "turned ON" and we need the same
> >> driver to "turn it OFF" when the session ends ? To make a better
> >> comparison :
> >>
> >> Can we unload a usb_mass_storage module when a USB disk(which uses the
> >> module driver) is mounted and is being used ? I believe, the module
> >> will eventually get unloaded when we unmount the disk, if someone did
> >> a unload.
> >
> > No, mount causes the module count to be incrememted. Mount and
> > "open/close" are the old-school way of doing module reference counting.
> >
> > Look at how network drivers work today, you can unload any network
> > driver even if there is a valid network connection "up and running"
> > attached to it. It just gets torn down when that request happens.
>
> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
> look that easy from the coresight point due to the way the devices are
> used in an interconnected manner which could be part of multiple trace
> sessions.
>
> e.g, a funnel could be part of two independent trace sessions with
> different sets of sources/sinks. Tearing down the trace sessions is
> going to be a difficult task unless we make drastic changes to the PMU
> framework itself. But will see, what best we can do to make it modern
> :-)
> >
> >> We have a similar situation here. The only difference is the driver is
> >> referenced only when one of its device is in a trace session.
> >
> > I understand, I'm saying that you have to be very careful when messing
> > around with module reference counts to get it correct and perhaps you
> > should just change your design to not care about module reference counts
> > at all, like networking did 15+ years ago.
> >
> > Let's learn from the good examples in our past (like networking), and
> > not like the older bad examples (like mount/files).
> >
> >>> Remember, removing a kernel module is something that only happens very
> >>> rarely, and is an explicit choice by someone with root permissions. If
> >>> you want to remove that module, it should be able to go, as you know
> >>> what you are doing at that point in time.
> >>
> >> Right, but when a device is "in use" can we do that ? I thought the user
> >> will get a module is in use or busy, error.
> >
> > Try it on networking today :)
> >
> >>> Don't try to "protect the user from themselves" here, they want to shoot
> >>> their foot, make it hurt if they are aiming it there :)
> >>>
> >>
> >> The module_get/put added here are only triggered when we start a trace
> >> session, where we build a path for the current session from the configured
> >> "source" to the configured "sink" and the path is destroyed
> >> at the end of the trace session. i.e, the path is not a permanent thing.
> >> It is constructed per session. So it is perfectly possible to remove a
> >> device in between trace sessions.
> >
> > That's fine, but again, just be careful to get this correct. The patch
> > I reviewed did not seem to do that.
>
> Thanks for the useful suggestions, we will explore this more.
I'm going to assume the series is still valid after this discussion,
since technically just this patch can get dropped, and the user is able
to shoot themselves in the foot. This series is for development
purposes, after all.
Let me know if I'm missing something.
Thanks,
Kim
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Scott Branden @ 2018-06-07 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d35afa1f-e0fd-84f1-7d42-60595e22cc77@gmail.com>
Hi Rob,
Could you please kindly comment on change below.
It allows board variants to be added easily via a simple define for
different number of SATA ports.
On 18-06-04 09:22 AM, Florian Fainelli wrote:
> On 05/18/2018 11:34 AM, Scott Branden wrote:
>> Move remaining sata configuration to stingray-sata.dtsi and enable
>> ports based on NUM_SATA defined.
>> Now, all that needs to be done is define NUM_SATA per board.
> Rob could you review this and let us know if this approach is okay or
> not? Thank you!
>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
>> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
>> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
>> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
>> 4 files changed, 72 insertions(+), 64 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> index 8862ec9..cacc25e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -72,70 +72,6 @@
>> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
>> };
>>
>> -&sata0 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy0{
>> - status = "okay";
>> -};
>> -
>> -&sata1 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy1{
>> - status = "okay";
>> -};
>> -
>> -&sata2 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy2{
>> - status = "okay";
>> -};
>> -
>> -&sata3 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy3{
>> - status = "okay";
>> -};
>> -
>> -&sata4 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy4{
>> - status = "okay";
>> -};
>> -
>> -&sata5 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy5{
>> - status = "okay";
>> -};
>> -
>> -&sata6 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy6{
>> - status = "okay";
>> -};
>> -
>> -&sata7 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy7{
>> - status = "okay";
>> -};
>> -
>> &mdio_mux_iproc {
>> mdio at 10 {
>> gphy0: eth-phy at 10 {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> index 77efa28..a515346 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> index 5084b03..6a4d19e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> index 8c68e0c..7f6d176 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> @@ -43,7 +43,11 @@
>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -58,7 +62,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -73,7 +81,11 @@
>> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -88,7 +100,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -103,7 +119,11 @@
>> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -118,7 +138,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -133,7 +157,11 @@
>> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -148,7 +176,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -163,7 +195,11 @@
>> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -178,7 +214,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -193,7 +233,11 @@
>> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -208,7 +252,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -223,7 +271,11 @@
>> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -238,7 +290,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -253,7 +309,11 @@
>> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -268,11 +328,19 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_phy0: sata-phy at 0 {
>> reg = <0>;
>> #phy-cells = <0>;
>> };
>> };
>> +
>> +#if (NUM_SATA > 8)
>> +#error "NUM_SATA > 8"
>> +#endif
>> };
>>
>
^ permalink raw reply
* [PATCH] spi: clps711x: remove unused header
From: Corentin Labbe @ 2018-06-07 19:52 UTC (permalink / raw)
To: linux-arm-kernel
include/linux/platform_data/spi-clps711x.h is unused since 6acaadc852f1
("spi: clps711x: Driver refactor")
Let's remove it.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
include/linux/platform_data/spi-clps711x.h | 21 ---------------------
1 file changed, 21 deletions(-)
delete mode 100644 include/linux/platform_data/spi-clps711x.h
diff --git a/include/linux/platform_data/spi-clps711x.h b/include/linux/platform_data/spi-clps711x.h
deleted file mode 100644
index 301956e63143..000000000000
--- a/include/linux/platform_data/spi-clps711x.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * CLPS711X SPI bus driver definitions
- *
- * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
-#define ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
-
-/* Board specific platform_data */
-struct spi_clps711x_pdata {
- int *chipselect; /* Array of GPIO-numbers */
- int num_chipselect; /* Total count of GPIOs */
-};
-
-#endif
--
2.16.4
^ permalink raw reply related
* [PATCH v4 0/2] support exception state migration and set VSESR_EL2 by user space
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
This series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
Dongjiu Geng (2):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
Documentation/virtual/kvm/api.txt | 42 +++++++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 +++++++++++
arch/arm/kvm/guest.c | 12 +++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++
arch/arm64/kvm/guest.c | 36 +++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 4 ++++
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 19 ++++++++++++++++
12 files changed, 157 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
change since v3:
1. Fix the memset() issue in the kvm_arm_vcpu_get_events()
change since v2:
1. Add kvm_vcpu_events structure definition for arm platform to avoid the build errors.
change since v1:
Address Marc's comments, thanks Marc's review
1. serror_has_esr always true when ARM64_HAS_RAS_EXTN is set
2. remove Spurious blank line in kvm_arm_vcpu_set_events()
3. rename pend_guest_serror() to kvm_set_sei_esr()
4. Make kvm_arm_vcpu_get_events() did all the work rather than having this split responsibility.
5. using sizeof(events) instead of sizeof(struct kvm_vcpu_events)
this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
change since V12:
1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 ++++++++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 19 +++++++++++++++++++
11 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fdac969..8896737 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -835,11 +835,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -910,6 +929,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c7c28c8..39f9901 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index caae484..c3e6975 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -124,6 +124,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index a18f33e..c685f0e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 1dab3a9..18f61ff 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
return (unsigned long *)&vcpu->arch.hcr_el2;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 469de8a..357304a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
void __kvm_set_tpidr_el2(u64 tpidr_el2);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 04b3256..df4faee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 56a0260..60028f7 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ memset(events, 0, sizeof(events));
+
+ events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d8e7165..a55e91d 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -164,9 +164,9 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
inject_undef64(vcpu);
}
-static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
*vcpu_hcr(vcpu) |= HCR_VSE;
}
@@ -184,5 +184,5 @@ static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
*/
void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
- pend_guest_serror(vcpu, ESR_ELx_ISV);
+ kvm_set_sei_esr(vcpu, ESR_ELx_ISV);
}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a4c1b76..79ecba9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1107,6 +1107,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
break;
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp, sizeof(events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
r = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-07 20:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Sergei Shtylyov @ 2018-06-07 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
From: Sergei Shtylyov @ 2018-06-07 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x4000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp at fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
^ permalink raw reply
* [PATCH v2 3/5] arm64: dts: renesas: r8a77980: add DU support
From: Sergei Shtylyov @ 2018-06-07 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the generic R8A77980 part of the DU device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH v2 4/5] arm64: dts: renesas: r8a77980: add LVDS support
From: Sergei Shtylyov @ 2018-06-07 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port at 1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-07 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the Condor/V3HSK board dependent parts of the DU and LVDS device
nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
Analog Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- added the V3HSK DT update, reworded the description, renamed the patch;
- added a space between the HDMI node name and a brace.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120 ++++++++++++++++++++++++
2 files changed, 226 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -27,6 +27,63 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x48000000 0 0x78000000>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&vcc3v3_d5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ vcc1v8_d4: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_D4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc3v3_d5: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_D5";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&du {
+ status = "okay";
};
&extal_clk {
@@ -53,6 +110,64 @@
};
};
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
+};
+
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ #sound-dai-cells = <0>;
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&vcc1v8_d4>;
+ dvdd-supply = <&vcc1v8_d4>;
+ pvdd-supply = <&vcc1v8_d4>;
+ bgvdd-supply = <&vcc1v8_d4>;
+ dvdd-3v-supply = <&vcc3v3_d5>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
&pfc {
gether_pins: gether {
groups = "gether_mdio_a", "gether_rgmii",
@@ -60,6 +175,11 @@
function = "gether";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
From: Douglas Anderson @ 2018-06-07 20:46 UTC (permalink / raw)
To: linux-arm-kernel
This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
ports, and UART9. Note that I2C / SPI / UART are a bit strange on
sdm845 because each "serial engine" has 4 pins associated with it and
depending on which firmware has been loaded into the serial engine
(loaded by the BIOS) the serial engine can behave like an I2C port, a
SPI port, or a UART. As per the landed bindings that means that we
need to create one node for each possible mode that the port could be
in. With 16 serial engines that means 16 x 3 = 48 nodes.
We get away with only creating 33 nodes for now because it seems very
likely that SDM845-based boards will actually all use the same UART
(UART 9) for debug purposes. While another UART could be used for
something like Bluetooth communication we can cross that path when we
come to it. Some documentation that I saw implied that using a UART
for "high speed" communications actually needs yet another different
serial engine firmware anyway.
Note that quick measurements adding all these nodes adds ~10k of extra
space per dtb that they're included with. If this becomes a problem
we may need to think of a different way to structure this so that
boards only get the nodes they need (or figure out how to get dtc to
strip 'disabled' nodes). For now it seems OK.
These nodes were programmatically generated with a fairly dumb python
script. See http://crosreview.com/1091631 for the source.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1013 ++++++++++++++++++++++++++
1 file changed, 1013 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..2dc5c7dcc9aa 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -5,6 +5,7 @@
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*/
+#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
/ {
@@ -13,6 +14,41 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ i2c12 = &i2c12;
+ i2c13 = &i2c13;
+ i2c14 = &i2c14;
+ i2c15 = &i2c15;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
+ spi3 = &spi3;
+ spi4 = &spi4;
+ spi5 = &spi5;
+ spi6 = &spi6;
+ spi7 = &spi7;
+ spi8 = &spi8;
+ spi9 = &spi9;
+ spi10 = &spi10;
+ spi11 = &spi11;
+ spi12 = &spi12;
+ spi13 = &spi13;
+ spi14 = &spi14;
+ spi15 = &spi15;
+ };
+
chosen { };
memory at 80000000 {
@@ -206,6 +242,489 @@
#power-domain-cells = <1>;
};
+ qupv3_id_0: geniqup at 8c0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0x8c0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c0: i2c at 880000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c0_default>;
+ pinctrl-1 = <&qup_i2c0_sleep>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi0: spi at 880000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi0_default>;
+ pinctrl-1 = <&qup_spi0_sleep>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 884000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c1_default>;
+ pinctrl-1 = <&qup_i2c1_sleep>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi1: spi at 884000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi1_default>;
+ pinctrl-1 = <&qup_spi1_sleep>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 888000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c2_default>;
+ pinctrl-1 = <&qup_i2c2_sleep>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi2: spi at 888000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi2_default>;
+ pinctrl-1 = <&qup_spi2_sleep>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at 88c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c3_default>;
+ pinctrl-1 = <&qup_i2c3_sleep>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi3: spi at 88c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi3_default>;
+ pinctrl-1 = <&qup_spi3_sleep>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at 890000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c4_default>;
+ pinctrl-1 = <&qup_i2c4_sleep>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi4: spi at 890000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi4_default>;
+ pinctrl-1 = <&qup_spi4_sleep>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at 894000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c5_default>;
+ pinctrl-1 = <&qup_i2c5_sleep>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi5: spi at 894000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi5_default>;
+ pinctrl-1 = <&qup_spi5_sleep>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c6: i2c at 898000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c6_default>;
+ pinctrl-1 = <&qup_i2c6_sleep>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi6: spi at 898000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi6_default>;
+ pinctrl-1 = <&qup_spi6_sleep>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c7: i2c at 89c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c7_default>;
+ pinctrl-1 = <&qup_i2c7_sleep>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi7: spi at 89c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi7_default>;
+ pinctrl-1 = <&qup_spi7_sleep>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ qupv3_id_1: geniqup at ac0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0xac0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ i2c8: i2c at a80000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c8_default>;
+ pinctrl-1 = <&qup_i2c8_sleep>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi8: spi at a80000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi8_default>;
+ pinctrl-1 = <&qup_spi8_sleep>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c9: i2c at a84000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c9_default>;
+ pinctrl-1 = <&qup_i2c9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi9: spi at a84000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi9_default>;
+ pinctrl-1 = <&qup_spi9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ uart9: serial at a84000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_uart9_default>;
+ pinctrl-1 = <&qup_uart9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ i2c10: i2c at a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c10_default>;
+ pinctrl-1 = <&qup_i2c10_sleep>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi10: spi at a88000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi10_default>;
+ pinctrl-1 = <&qup_spi10_sleep>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c at a8c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c11_default>;
+ pinctrl-1 = <&qup_i2c11_sleep>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi11: spi at a8c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi11_default>;
+ pinctrl-1 = <&qup_spi11_sleep>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c12: i2c at a90000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c12_default>;
+ pinctrl-1 = <&qup_i2c12_sleep>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi12: spi at a90000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi12_default>;
+ pinctrl-1 = <&qup_spi12_sleep>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c13: i2c at a94000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c13_default>;
+ pinctrl-1 = <&qup_i2c13_sleep>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi13: spi at a94000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi13_default>;
+ pinctrl-1 = <&qup_spi13_sleep>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c14: i2c at a98000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c14_default>;
+ pinctrl-1 = <&qup_i2c14_sleep>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi14: spi at a98000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi14_default>;
+ pinctrl-1 = <&qup_spi14_sleep>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c15: i2c at a9c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c15_default>;
+ pinctrl-1 = <&qup_i2c15_sleep>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi15: spi at a9c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi15_default>;
+ pinctrl-1 = <&qup_spi15_sleep>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
tcsr_mutex_regs: syscon at 1f40000 {
compatible = "syscon";
reg = <0x1f40000 0x40000>;
@@ -219,6 +738,500 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+ qup_i2c0_default: qup-i2c0-default {
+ pinmux {
+ pins = "gpio0", "gpio1";
+ function = "qup0";
+ };
+ };
+
+ qup_i2c0_sleep: qup-i2c0-sleep {
+ pinmux {
+ pins = "gpio0", "gpio1";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c1_default: qup-i2c1-default {
+ pinmux {
+ pins = "gpio17", "gpio18";
+ function = "qup1";
+ };
+ };
+
+ qup_i2c1_sleep: qup-i2c1-sleep {
+ pinmux {
+ pins = "gpio17", "gpio18";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c2_default: qup-i2c2-default {
+ pinmux {
+ pins = "gpio27", "gpio28";
+ function = "qup2";
+ };
+ };
+
+ qup_i2c2_sleep: qup-i2c2-sleep {
+ pinmux {
+ pins = "gpio27", "gpio28";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c3_default: qup-i2c3-default {
+ pinmux {
+ pins = "gpio41", "gpio42";
+ function = "qup3";
+ };
+ };
+
+ qup_i2c3_sleep: qup-i2c3-sleep {
+ pinmux {
+ pins = "gpio41", "gpio42";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c4_default: qup-i2c4-default {
+ pinmux {
+ pins = "gpio89", "gpio90";
+ function = "qup4";
+ };
+ };
+
+ qup_i2c4_sleep: qup-i2c4-sleep {
+ pinmux {
+ pins = "gpio89", "gpio90";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c5_default: qup-i2c5-default {
+ pinmux {
+ pins = "gpio85", "gpio86";
+ function = "qup5";
+ };
+ };
+
+ qup_i2c5_sleep: qup-i2c5-sleep {
+ pinmux {
+ pins = "gpio85", "gpio86";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c6_default: qup-i2c6-default {
+ pinmux {
+ pins = "gpio45", "gpio46";
+ function = "qup6";
+ };
+ };
+
+ qup_i2c6_sleep: qup-i2c6-sleep {
+ pinmux {
+ pins = "gpio45", "gpio46";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c7_default: qup-i2c7-default {
+ pinmux {
+ pins = "gpio93", "gpio94";
+ function = "qup7";
+ };
+ };
+
+ qup_i2c7_sleep: qup-i2c7-sleep {
+ pinmux {
+ pins = "gpio93", "gpio94";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c8_default: qup-i2c8-default {
+ pinmux {
+ pins = "gpio65", "gpio66";
+ function = "qup8";
+ };
+ };
+
+ qup_i2c8_sleep: qup-i2c8-sleep {
+ pinmux {
+ pins = "gpio65", "gpio66";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c9_default: qup-i2c9-default {
+ pinmux {
+ pins = "gpio6", "gpio7";
+ function = "qup9";
+ };
+ };
+
+ qup_i2c9_sleep: qup-i2c9-sleep {
+ pinmux {
+ pins = "gpio6", "gpio7";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c10_default: qup-i2c10-default {
+ pinmux {
+ pins = "gpio55", "gpio56";
+ function = "qup10";
+ };
+ };
+
+ qup_i2c10_sleep: qup-i2c10-sleep {
+ pinmux {
+ pins = "gpio55", "gpio56";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c11_default: qup-i2c11-default {
+ pinmux {
+ pins = "gpio31", "gpio32";
+ function = "qup11";
+ };
+ };
+
+ qup_i2c11_sleep: qup-i2c11-sleep {
+ pinmux {
+ pins = "gpio31", "gpio32";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c12_default: qup-i2c12-default {
+ pinmux {
+ pins = "gpio49", "gpio50";
+ function = "qup12";
+ };
+ };
+
+ qup_i2c12_sleep: qup-i2c12-sleep {
+ pinmux {
+ pins = "gpio49", "gpio50";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c13_default: qup-i2c13-default {
+ pinmux {
+ pins = "gpio105", "gpio106";
+ function = "qup13";
+ };
+ };
+
+ qup_i2c13_sleep: qup-i2c13-sleep {
+ pinmux {
+ pins = "gpio105", "gpio106";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c14_default: qup-i2c14-default {
+ pinmux {
+ pins = "gpio33", "gpio34";
+ function = "qup14";
+ };
+ };
+
+ qup_i2c14_sleep: qup-i2c14-sleep {
+ pinmux {
+ pins = "gpio33", "gpio34";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c15_default: qup-i2c15-default {
+ pinmux {
+ pins = "gpio81", "gpio82";
+ function = "qup15";
+ };
+ };
+
+ qup_i2c15_sleep: qup-i2c15-sleep {
+ pinmux {
+ pins = "gpio81", "gpio82";
+ function = "gpio";
+ };
+ };
+
+ qup_spi0_default: qup-spi0-default {
+ pinmux {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ function = "qup0";
+ };
+ };
+
+ qup_spi0_sleep: qup-spi0-sleep {
+ pinmux {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ function = "gpio";
+ };
+ };
+
+ qup_spi1_default: qup-spi1-default {
+ pinmux {
+ pins = "gpio17", "gpio18",
+ "gpio19", "gpio20";
+ function = "qup1";
+ };
+ };
+
+ qup_spi1_sleep: qup-spi1-sleep {
+ pinmux {
+ pins = "gpio17", "gpio18",
+ "gpio19", "gpio20";
+ function = "gpio";
+ };
+ };
+
+ qup_spi2_default: qup-spi2-default {
+ pinmux {
+ pins = "gpio27", "gpio28",
+ "gpio29", "gpio30";
+ function = "qup2";
+ };
+ };
+
+ qup_spi2_sleep: qup-spi2-sleep {
+ pinmux {
+ pins = "gpio27", "gpio28",
+ "gpio29", "gpio30";
+ function = "gpio";
+ };
+ };
+
+ qup_spi3_default: qup-spi3-default {
+ pinmux {
+ pins = "gpio41", "gpio42",
+ "gpio43", "gpio44";
+ function = "qup3";
+ };
+ };
+
+ qup_spi3_sleep: qup-spi3-sleep {
+ pinmux {
+ pins = "gpio41", "gpio42",
+ "gpio43", "gpio44";
+ function = "gpio";
+ };
+ };
+
+ qup_spi4_default: qup-spi4-default {
+ pinmux {
+ pins = "gpio89", "gpio90",
+ "gpio91", "gpio92";
+ function = "qup4";
+ };
+ };
+
+ qup_spi4_sleep: qup-spi4-sleep {
+ pinmux {
+ pins = "gpio89", "gpio90",
+ "gpio91", "gpio92";
+ function = "gpio";
+ };
+ };
+
+ qup_spi5_default: qup-spi5-default {
+ pinmux {
+ pins = "gpio85", "gpio86",
+ "gpio87", "gpio88";
+ function = "qup5";
+ };
+ };
+
+ qup_spi5_sleep: qup-spi5-sleep {
+ pinmux {
+ pins = "gpio85", "gpio86",
+ "gpio87", "gpio88";
+ function = "gpio";
+ };
+ };
+
+ qup_spi6_default: qup-spi6-default {
+ pinmux {
+ pins = "gpio45", "gpio46",
+ "gpio47", "gpio48";
+ function = "qup6";
+ };
+ };
+
+ qup_spi6_sleep: qup-spi6-sleep {
+ pinmux {
+ pins = "gpio45", "gpio46",
+ "gpio47", "gpio48";
+ function = "gpio";
+ };
+ };
+
+ qup_spi7_default: qup-spi7-default {
+ pinmux {
+ pins = "gpio93", "gpio94",
+ "gpio95", "gpio96";
+ function = "qup7";
+ };
+ };
+
+ qup_spi7_sleep: qup-spi7-sleep {
+ pinmux {
+ pins = "gpio93", "gpio94",
+ "gpio95", "gpio96";
+ function = "gpio";
+ };
+ };
+
+ qup_spi8_default: qup-spi8-default {
+ pinmux {
+ pins = "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ function = "qup8";
+ };
+ };
+
+ qup_spi8_sleep: qup-spi8-sleep {
+ pinmux {
+ pins = "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ function = "gpio";
+ };
+ };
+
+ qup_spi9_default: qup-spi9-default {
+ pinmux {
+ pins = "gpio6", "gpio7",
+ "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
+
+ qup_spi9_sleep: qup-spi9-sleep {
+ pinmux {
+ pins = "gpio6", "gpio7",
+ "gpio4", "gpio5";
+ function = "gpio";
+ };
+ };
+
+ qup_spi10_default: qup-spi10-default {
+ pinmux {
+ pins = "gpio55", "gpio56",
+ "gpio53", "gpio54";
+ function = "qup10";
+ };
+ };
+
+ qup_spi10_sleep: qup-spi10-sleep {
+ pinmux {
+ pins = "gpio55", "gpio56",
+ "gpio53", "gpio54";
+ function = "gpio";
+ };
+ };
+
+ qup_spi11_default: qup-spi11-default {
+ pinmux {
+ pins = "gpio31", "gpio32",
+ "gpio33", "gpio34";
+ function = "qup11";
+ };
+ };
+
+ qup_spi11_sleep: qup-spi11-sleep {
+ pinmux {
+ pins = "gpio31", "gpio32",
+ "gpio33", "gpio34";
+ function = "gpio";
+ };
+ };
+
+ qup_spi12_default: qup-spi12-default {
+ pinmux {
+ pins = "gpio49", "gpio50",
+ "gpio51", "gpio52";
+ function = "qup12";
+ };
+ };
+
+ qup_spi12_sleep: qup-spi12-sleep {
+ pinmux {
+ pins = "gpio49", "gpio50",
+ "gpio51", "gpio52";
+ function = "gpio";
+ };
+ };
+
+ qup_spi13_default: qup-spi13-default {
+ pinmux {
+ pins = "gpio105", "gpio106",
+ "gpio107", "gpio108";
+ function = "qup13";
+ };
+ };
+
+ qup_spi13_sleep: qup-spi13-sleep {
+ pinmux {
+ pins = "gpio105", "gpio106",
+ "gpio107", "gpio108";
+ function = "gpio";
+ };
+ };
+
+ qup_spi14_default: qup-spi14-default {
+ pinmux {
+ pins = "gpio33", "gpio34",
+ "gpio31", "gpio32";
+ function = "qup14";
+ };
+ };
+
+ qup_spi14_sleep: qup-spi14-sleep {
+ pinmux {
+ pins = "gpio33", "gpio34",
+ "gpio31", "gpio32";
+ function = "gpio";
+ };
+ };
+
+ qup_spi15_default: qup-spi15-default {
+ pinmux {
+ pins = "gpio81", "gpio82",
+ "gpio83", "gpio84";
+ function = "qup15";
+ };
+ };
+
+ qup_spi15_sleep: qup-spi15-sleep {
+ pinmux {
+ pins = "gpio81", "gpio82",
+ "gpio83", "gpio84";
+ function = "gpio";
+ };
+ };
+
+ qup_uart9_default: qup-uart9-default {
+ pinmux {
+ pins = "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
+
+ qup_uart9_sleep: qup-uart9-sleep {
+ pinmux {
+ pins = "gpio4", "gpio5";
+ function = "gpio";
+ };
+ };
};
spmi_bus: spmi at c440000 {
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp
From: Douglas Anderson @ 2018-06-07 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607204608.27688-1-dianders@chromium.org>
The debug UART is very useful to have. I2C10 is enabled as an example
of a I2C port we can talk on for now. Eventually we'll want to put
peripherals under it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 52 +++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49913f1..e1eda143a725 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,56 @@
/ {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+ aliases {
+ serial0 = &uart9;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&i2c10 {
+ status = "okay";
+ clock-frequency = <400000>;
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&uart9 {
+ status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+
+&qup_i2c10_default {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&qup_uart9_default {
+ pinconf-tx {
+ pins = "gpio4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pinconf-rx {
+ pins = "gpio5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
+
+&qup_uart9_sleep {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ bias-pull-down;
+ };
};
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH] ARM64: dts: meson-gx: fix ATF reserved memory region
From: Kevin Hilman @ 2018-06-07 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Vendor firmware/uboot has different reserved regions depending on
firmware version, but current codebase reserves the same regions on
GXL and GXBB, so move the additional reserved memory region to common
.dtsi.
Found when putting a recent vendor u-boot on meson-gxbb-p200.
Recommended-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 8 --------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index b003f324ca31..b8dc4dbb391b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -35,6 +35,12 @@
no-map;
};
+ /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved_alt: secmon at 5000000 {
+ reg = <0x0 0x05000000 0x0 0x300000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
reusable;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 27538eea547b..c87a80e9bcc6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -13,14 +13,6 @@
/ {
compatible = "amlogic,meson-gxl";
- reserved-memory {
- /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
- secmon_reserved_alt: secmon at 5000000 {
- reg = <0x0 0x05000000 0x0 0x300000>;
- no-map;
- };
- };
-
soc {
usb0: usb at c9000000 {
status = "disabled";
--
2.11.0
^ permalink raw reply related
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Suzuki K Poulose @ 2018-06-07 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607121304.017d1d6804466050dd5c0af2@arm.com>
On 06/07/2018 06:13 PM, Kim Phillips wrote:
> On Thu, 7 Jun 2018 11:07:15 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
>>>> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
>>>>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
>>>>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
>>>>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
>>>>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>>>>>
>>>>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
>>>>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
>>>>>>>>>>> Increment the refcnt for driver modules in current use by calling
>>>>>>>>>>> module_get in coresight_build_path and module_put in release_path.
>>>>>>>>>>>
>>>>>>>>>>> This prevents driver modules from being unloaded when they are in use,
>>>>>>>>>>> either in sysfs or perf mode.
>>>>>>>>>>
>>>>>>>>>> Why does it matter? Shouldn't you be allowed to remove any module at
>>>>>>>>>> any point in time, much like a networking driver?
>>>>>>
>>>>>> The user doesn't have an explicit refcount on the individual components
>>>>>> in a trace session. So, when a trace session is in progress, it is as
>>>>>> good as having a "file" open on each component that is part of the
>>>>>> active trace session. So, we don't want the driver to be removed when
>>>>>> the component is being used in the trace collection.
>>>>>
>>>>> Why not? What's wrong with that happening and then the trace collection
>>>>> starts failing with -ENODEV or something?
>>>>
>>>> May be I am missing something here. Can we allow the driver to be removed
>>>> when one of its device is "turned ON" and we need the same
>>>> driver to "turn it OFF" when the session ends ? To make a better
>>>> comparison :
>>>>
>>>> Can we unload a usb_mass_storage module when a USB disk(which uses the
>>>> module driver) is mounted and is being used ? I believe, the module
>>>> will eventually get unloaded when we unmount the disk, if someone did
>>>> a unload.
>>>
>>> No, mount causes the module count to be incrememted. Mount and
>>> "open/close" are the old-school way of doing module reference counting.
>>>
>>> Look at how network drivers work today, you can unload any network
>>> driver even if there is a valid network connection "up and running"
>>> attached to it. It just gets torn down when that request happens.
>>
>> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
>> look that easy from the coresight point due to the way the devices are
>> used in an interconnected manner which could be part of multiple trace
>> sessions.
>>
>> e.g, a funnel could be part of two independent trace sessions with
>> different sets of sources/sinks. Tearing down the trace sessions is
>> going to be a difficult task unless we make drastic changes to the PMU
>> framework itself. But will see, what best we can do to make it modern
>> :-)
>>>
>>>> We have a similar situation here. The only difference is the driver is
>>>> referenced only when one of its device is in a trace session.
>>>
>>> I understand, I'm saying that you have to be very careful when messing
>>> around with module reference counts to get it correct and perhaps you
>>> should just change your design to not care about module reference counts
>>> at all, like networking did 15+ years ago.
>>>
>>> Let's learn from the good examples in our past (like networking), and
>>> not like the older bad examples (like mount/files).
>>>
>>>>> Remember, removing a kernel module is something that only happens very
>>>>> rarely, and is an explicit choice by someone with root permissions. If
>>>>> you want to remove that module, it should be able to go, as you know
>>>>> what you are doing at that point in time.
>>>>
>>>> Right, but when a device is "in use" can we do that ? I thought the user
>>>> will get a module is in use or busy, error.
>>>
>>> Try it on networking today :)
>>>
>>>>> Don't try to "protect the user from themselves" here, they want to shoot
>>>>> their foot, make it hurt if they are aiming it there :)
>>>>>
>>>>
>>>> The module_get/put added here are only triggered when we start a trace
>>>> session, where we build a path for the current session from the configured
>>>> "source" to the configured "sink" and the path is destroyed
>>>> at the end of the trace session. i.e, the path is not a permanent thing.
>>>> It is constructed per session. So it is perfectly possible to remove a
>>>> device in between trace sessions.
>>>
>>> That's fine, but again, just be careful to get this correct. The patch
>>> I reviewed did not seem to do that.
>>
>> Thanks for the useful suggestions, we will explore this more.
Kim,
>
> I'm going to assume the series is still valid after this discussion,
> since technically just this patch can get dropped, and the user is able
> to shoot themselves in the foot.
That doesn't mean the kernel can panic() if the user decided to unload
the module while the trace session is in progress. It only means that
the trace session could be stopped in between in the worst case. But
nothing more harmful to the system.
> This series is for development purposes, after all.
Do you mean that this series is for internal development purposes and
not upstream ? Making the drivers modular are always helpful, especially
for something related to tracing, that allows the module to be unloaded
after use. So, it would be good to have this series in, but in a manner
which is usable and doesn't cause harm to the overall system usage.
I think the summary of the discussion is that we need more robust code
to handle the situation, which also allows unloading the modules without
any trouble.
Cheers
Suzuki
>
> Let me know if I'm missing something.
>
> Thanks,
>
> Kim
>
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Mathieu Poirier @ 2018-06-07 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39d1089f-585d-bc19-2ecd-c9c9c812f85f@arm.com>
On 7 June 2018 at 15:10, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 06:13 PM, Kim Phillips wrote:
>>
>> On Thu, 7 Jun 2018 11:07:15 +0100
>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>>> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
>>>>
>>>> On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
>>>>>
>>>>> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
>>>>>>
>>>>>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
>>>>>>>
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
>>>>>>>>
>>>>>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
>>>>>>>>>
>>>>>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
>>>>>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Increment the refcnt for driver modules in current use by
>>>>>>>>>>>> calling
>>>>>>>>>>>> module_get in coresight_build_path and module_put in
>>>>>>>>>>>> release_path.
>>>>>>>>>>>>
>>>>>>>>>>>> This prevents driver modules from being unloaded when they are
>>>>>>>>>>>> in use,
>>>>>>>>>>>> either in sysfs or perf mode.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why does it matter? Shouldn't you be allowed to remove any
>>>>>>>>>>> module at
>>>>>>>>>>> any point in time, much like a networking driver?
>>>>>>>
>>>>>>>
>>>>>>> The user doesn't have an explicit refcount on the individual
>>>>>>> components
>>>>>>> in a trace session. So, when a trace session is in progress, it is as
>>>>>>> good as having a "file" open on each component that is part of the
>>>>>>> active trace session. So, we don't want the driver to be removed when
>>>>>>> the component is being used in the trace collection.
>>>>>>
>>>>>>
>>>>>> Why not? What's wrong with that happening and then the trace
>>>>>> collection
>>>>>> starts failing with -ENODEV or something?
>>>>>
>>>>>
>>>>> May be I am missing something here. Can we allow the driver to be
>>>>> removed
>>>>> when one of its device is "turned ON" and we need the same
>>>>> driver to "turn it OFF" when the session ends ? To make a better
>>>>> comparison :
>>>>>
>>>>> Can we unload a usb_mass_storage module when a USB disk(which uses the
>>>>> module driver) is mounted and is being used ? I believe, the module
>>>>> will eventually get unloaded when we unmount the disk, if someone did
>>>>> a unload.
>>>>
>>>>
>>>> No, mount causes the module count to be incrememted. Mount and
>>>> "open/close" are the old-school way of doing module reference counting.
>>>>
>>>> Look at how network drivers work today, you can unload any network
>>>> driver even if there is a valid network connection "up and running"
>>>> attached to it. It just gets torn down when that request happens.
>>>
>>>
>>> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
>>> look that easy from the coresight point due to the way the devices are
>>> used in an interconnected manner which could be part of multiple trace
>>> sessions.
>>>
>>> e.g, a funnel could be part of two independent trace sessions with
>>> different sets of sources/sinks. Tearing down the trace sessions is
>>> going to be a difficult task unless we make drastic changes to the PMU
>>> framework itself. But will see, what best we can do to make it modern
>>> :-)
>>>>
>>>>
>>>>> We have a similar situation here. The only difference is the driver is
>>>>> referenced only when one of its device is in a trace session.
>>>>
>>>>
>>>> I understand, I'm saying that you have to be very careful when messing
>>>> around with module reference counts to get it correct and perhaps you
>>>> should just change your design to not care about module reference counts
>>>> at all, like networking did 15+ years ago.
>>>>
>>>> Let's learn from the good examples in our past (like networking), and
>>>> not like the older bad examples (like mount/files).
>>>>
>>>>>> Remember, removing a kernel module is something that only happens very
>>>>>> rarely, and is an explicit choice by someone with root permissions.
>>>>>> If
>>>>>> you want to remove that module, it should be able to go, as you know
>>>>>> what you are doing at that point in time.
>>>>>
>>>>>
>>>>> Right, but when a device is "in use" can we do that ? I thought the
>>>>> user
>>>>> will get a module is in use or busy, error.
>>>>
>>>>
>>>> Try it on networking today :)
>>>>
>>>>>> Don't try to "protect the user from themselves" here, they want to
>>>>>> shoot
>>>>>> their foot, make it hurt if they are aiming it there :)
>>>>>>
>>>>>
>>>>> The module_get/put added here are only triggered when we start a trace
>>>>> session, where we build a path for the current session from the
>>>>> configured
>>>>> "source" to the configured "sink" and the path is destroyed
>>>>> at the end of the trace session. i.e, the path is not a permanent
>>>>> thing.
>>>>> It is constructed per session. So it is perfectly possible to remove a
>>>>> device in between trace sessions.
>>>>
>>>>
>>>> That's fine, but again, just be careful to get this correct. The patch
>>>> I reviewed did not seem to do that.
>>>
>>>
>>> Thanks for the useful suggestions, we will explore this more.
>
>
> Kim,
>
>>
>> I'm going to assume the series is still valid after this discussion,
>> since technically just this patch can get dropped, and the user is able
>> to shoot themselves in the foot.
>
>
> That doesn't mean the kernel can panic() if the user decided to unload the
> module while the trace session is in progress. It only means that
> the trace session could be stopped in between in the worst case. But
> nothing more harmful to the system.
>
>> This series is for development purposes, after all.
>
>
> Do you mean that this series is for internal development purposes and not
> upstream ? Making the drivers modular are always helpful, especially for
> something related to tracing, that allows the module to be unloaded after
> use. So, it would be good to have this series in, but in a manner which is
> usable and doesn't cause harm to the overall system usage.
Correct, we can't have a patchset that generates a kernel panic.
>
> I think the summary of the discussion is that we need more robust code
> to handle the situation, which also allows unloading the modules without
> any trouble.
The tricky part is the "unloading without any trouble". The first
thing to so is if the driver is being used, the _remove() functions
need to go through the same process as it would under normal
condition. That will allow to reinsert the module and have a fairly
good level of assurance that things will work properly.
Looking at things a little closer all the interconnection dependencies
in the core are done using a csdev and a lot of the current code is
already checking for a NULL condition (more checks may be needed with
the introduction of this set). The real problem is with the "path"
used to keep track of the devices taking part in active sessions.
Those can be accessed when a process is swapped in and out, mandating
something fast and efficient. One thing we could do is in a path,
keep track of a reference on csdev rather than make a copy of their
addresses. That way the _remove() functions could simply set those to
NULL, making it easy to deal with.
>
> Cheers
>
> Suzuki
>
>>
>> Let me know if I'm missing something.
>>
>> Thanks,
>>
>> Kim
>>
>
^ permalink raw reply
* [PATCH v4 14/14] coresight: allow the coresight core driver to be built as a module
From: Mathieu Poirier @ 2018-06-07 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-15-kim.phillips@arm.com>
On 5 June 2018 at 15:07, Kim Phillips <kim.phillips@arm.com> wrote:
> Allow to build coresight as a module. This enhances
> coresight developer efficiency by allowing the development to
> take place exclusively on the target, and without needing to
> reboot in between changes.
>
> - Kconfig becomes a tristate, to allow =m
> - append -core to source file name to allow module to
> be called coresight by the Makefile
> - modules can have only one init/exit, so we add the core bus
> register/unregister function calls to the etm_perf init/exit
> functions, since coresight.c does not have etm_pmu defined.
> - add a MODULE_DEVICE_TABLE for autoloading on boot
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/Kconfig | 5 ++++-
> drivers/hwtracing/coresight/Makefile | 7 +++++--
> .../coresight/{coresight.c => coresight-core.c} | 6 ------
> .../hwtracing/coresight/coresight-etm-perf.c | 17 ++++++++++++++++-
> 4 files changed, 25 insertions(+), 10 deletions(-)
> rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (99%)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index 181a44ea2d61..c05b265f7731 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -2,7 +2,7 @@
> # Coresight configuration
> #
> menuconfig CORESIGHT
> - bool "CoreSight Tracing Support"
> + tristate "CoreSight Tracing Support"
> select ARM_AMBA
> select PERF_EVENTS
> help
> @@ -12,6 +12,9 @@ menuconfig CORESIGHT
> specification and configure the right series of components when a
> trace source gets enabled.
>
> + To compile this driver as a module, choose M here: the
> + module will be called coresight.
> +
> if CORESIGHT
> config CORESIGHT_LINKS_AND_SINKS
> tristate "CoreSight Link and Sink drivers"
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 45d7a0f34170..ed2d4bcb017b 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -2,8 +2,11 @@
> #
> # Makefile for CoreSight drivers.
> #
> -obj-$(CONFIG_CORESIGHT) += coresight.o coresight-etm-perf.o
> -obj-$(CONFIG_OF) += of_coresight.o
> +obj-$(CONFIG_CORESIGHT) += coresight.o
> +coresight-objs := coresight-core.o coresight-etm-perf.o
> +ifeq ($(CONFIG_OF), y)
> +coresight-objs += of_coresight.o
> +endif
> obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
> coresight-tmc-objs := coresight-tmc-core.o coresight-tmc-etf.o \
> coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight-core.c
> similarity index 99%
> rename from drivers/hwtracing/coresight/coresight.c
> rename to drivers/hwtracing/coresight/coresight-core.c
> index 1c941351f1d1..f96258de1e9b 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -948,12 +948,6 @@ struct bus_type coresight_bustype = {
> .name = "coresight",
> };
>
> -static int __init coresight_init(void)
> -{
> - return bus_register(&coresight_bustype);
> -}
> -postcore_initcall(coresight_init);
> -
> struct coresight_device *coresight_register(struct coresight_desc *desc)
> {
> int i;
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 0fe7e43ea1c4..ceac9aee4a82 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -472,6 +472,10 @@ static int __init etm_perf_init(void)
> {
> int ret;
>
> + ret = bus_register(&coresight_bustype);
> + if (ret)
> + return ret;
> +
> etm_pmu.capabilities = PERF_PMU_CAP_EXCLUSIVE;
>
> etm_pmu.attr_groups = etm_pmu_attr_groups;
> @@ -494,4 +498,15 @@ static int __init etm_perf_init(void)
>
> return ret;
> }
> -device_initcall(etm_perf_init);
> +postcore_initcall(etm_perf_init);
> +
> +static void __exit etm_perf_exit(void)
> +{
> + perf_pmu_unregister(&etm_pmu);
> + bus_unregister(&coresight_bustype);
> +}
> +module_exit(etm_perf_exit);
I see the perf functionality as an accessory to the core rather than
the other way around. Initialisation in the core code should be
driving the PMU registration.
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight tracer driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Kim Phillips @ 2018-06-07 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39d1089f-585d-bc19-2ecd-c9c9c812f85f@arm.com>
On Thu, 7 Jun 2018 22:10:07 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 06:13 PM, Kim Phillips wrote:
> > I'm going to assume the series is still valid after this discussion,
> > since technically just this patch can get dropped, and the user is able
> > to shoot themselves in the foot.
>
> That doesn't mean the kernel can panic() if the user decided to unload
> the module while the trace session is in progress. It only means that
> the trace session could be stopped in between in the worst case. But
> nothing more harmful to the system.
FWIW, I didn't see the kernel panic in my basic tests; just some bad
accesses: the new remove functions take care of cleaning up most items,
and most drivers still depend on the links and sinks (funnel,
replicator) drivers, so they can't be upset too bad.
> > This series is for development purposes, after all.
>
> Do you mean that this series is for internal development purposes and
> not upstream ? Making the drivers modular are always helpful, especially
no, I'm posting them for upstream review because I'd like them upstream.
> for something related to tracing, that allows the module to be unloaded
> after use. So, it would be good to have this series in, but in a manner
> which is usable and doesn't cause harm to the overall system usage.
>
> I think the summary of the discussion is that we need more robust code
> to handle the situation, which also allows unloading the modules without
> any trouble.
Trouble's relative. My point was since the series is going to be used
mainly by developers testing their code, they already prepare for, and
expect badness to occur anyway. Greg's point isn't lost here, and in
my interpretation, his review of this patch was that it was in the
wrong direction of safety: it made things unnecessarily too safe, up
front, and that items relative to the perf core should strive to adhere
to the higher standards set in place by the networking subsystem. So,
this patch doesn't get his ack.
I compiled a new v5 series that omits this patch, and overwrote the v4
series here:
git://linux-arm.org/linux-kp.git, coresight-modules branch
but I'll hold of submitting a v5 for now.
I don't know how the perf core handles AUXTRACE drivers hanging up on
it. I see intel-pt record support can't be built as a module. I'm
guessing more testing for actual panics when using perf or sysfs is
what's being sought here?
Kim
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Mathieu Poirier @ 2018-06-07 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607164747.7e4bb30f69a1fb4c160b6ef1@arm.com>
On 7 June 2018 at 15:47, Kim Phillips <kim.phillips@arm.com> wrote:
> On Thu, 7 Jun 2018 22:10:07 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>> On 06/07/2018 06:13 PM, Kim Phillips wrote:
>> > I'm going to assume the series is still valid after this discussion,
>> > since technically just this patch can get dropped, and the user is able
>> > to shoot themselves in the foot.
>>
>> That doesn't mean the kernel can panic() if the user decided to unload
>> the module while the trace session is in progress. It only means that
>> the trace session could be stopped in between in the worst case. But
>> nothing more harmful to the system.
>
> FWIW, I didn't see the kernel panic in my basic tests; just some bad
> accesses: the new remove functions take care of cleaning up most items,
> and most drivers still depend on the links and sinks (funnel,
> replicator) drivers, so they can't be upset too bad.
>
>> > This series is for development purposes, after all.
>>
>> Do you mean that this series is for internal development purposes and
>> not upstream ? Making the drivers modular are always helpful, especially
>
> no, I'm posting them for upstream review because I'd like them upstream.
>
>> for something related to tracing, that allows the module to be unloaded
>> after use. So, it would be good to have this series in, but in a manner
>> which is usable and doesn't cause harm to the overall system usage.
>>
>> I think the summary of the discussion is that we need more robust code
>> to handle the situation, which also allows unloading the modules without
>> any trouble.
>
> Trouble's relative. My point was since the series is going to be used
> mainly by developers testing their code, they already prepare for, and
> expect badness to occur anyway. Greg's point isn't lost here, and in
> my interpretation, his review of this patch was that it was in the
> wrong direction of safety: it made things unnecessarily too safe, up
> front, and that items relative to the perf core should strive to adhere
> to the higher standards set in place by the networking subsystem. So,
> this patch doesn't get his ack.
Greg's point was that it's OK to let users harm themselves (which I
totally support), but if you're going to prevent it, make sure to do
it right.
>
> I compiled a new v5 series that omits this patch, and overwrote the v4
> series here:
>
> git://linux-arm.org/linux-kp.git, coresight-modules branch
>
> but I'll hold of submitting a v5 for now.
>
> I don't know how the perf core handles AUXTRACE drivers hanging up on
> it. I see intel-pt record support can't be built as a module. I'm
> guessing more testing for actual panics when using perf or sysfs is
> what's being sought here?
There are two ways to approach the problem:
1) Kill active trace sessions (either sysFS or perf) if a driver that
is being used is removed.
2) Deal with the removal in the coresight core, making sure we don't
access operations provided by removed drivers.
The end result in both cases will be the same: failure to properly
terminate the trace session because of user action.
I'm personally in favour of the second option, simply because it keeps
problems resolution with the CS subsystem.
>
> Kim
^ permalink raw reply
* [PATCH] ARM: spectre-v2: Try to set IBE bit for Cortex-A15 and Brahma-B15
From: Florian Fainelli @ 2018-06-07 22:58 UTC (permalink / raw)
To: linux-arm-kernel
Per the ARM reference manual for the Cortex-A15, The ACTLR:
Is a read/write register.
Common to the Secure and Non-secure states.
Is only accessible from PL1 or higher, with access rights that depend
on the mode:
* Read/write in Secure PL1 modes.
* Read-only and write-ignored in Non-secure PL1 and PL2 modes
if NSACR.NS_SMP is 0.
* Read/write in Non-secure PL1 and PL2 modes if NSACR.NS_SMP
is 1. In this case, all bits are write-ignored except for the SMP bit.
We can attempt to set this bit from within the kernel, which helps
avoiding firmware side modifications to set the IBE bit when that is
impractical. We do this within __v7_ca15mp_setup and __v7_b15mp_setup
because by then we already took those labels because the processors we
run on do match.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/proc-v7.S | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 6fe52819e014..a21cf3729efa 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -284,10 +284,16 @@ __v7_cr8mp_setup:
b 1f
__v7_ca7mp_setup:
__v7_ca12mp_setup:
+ b 2f
__v7_ca15mp_setup:
__v7_b15mp_setup:
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+ mrc p15, 0, r0, c1, c0, 1
+ orr r0, r0, #1 @ Enable IBE bit
+ mcr p15, 0, r0, c1, c0, 1
+#endif
__v7_ca17mp_setup:
- mov r10, #0
+2: mov r10, #0
1: adr r0, __v7_setup_stack_ptr
ldr r12, [r0]
add r12, r12, r0 @ the local stack
--
2.14.1
^ permalink raw reply related
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