* [PATCH 0/9] media: cedrus: Add H264 decoding support
From: Tomasz Figa @ 2018-06-14 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613140714.1686-1-maxime.ripard@bootlin.com>
Hi Maxime,
On Wed, Jun 13, 2018 at 11:07 PM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> Here is a preliminary version of the H264 decoding support in the
> cedrus driver.
Thanks for the series! Let me reply inline to some of the points raised here.
>
> As you might already know, the cedrus driver relies on the Request
> API, and is a reverse engineered driver for the video decoding engine
> found on the Allwinner SoCs.
>
> This work has been possible thanks to the work done by the people
> behind libvdpau-sunxi found here:
> https://github.com/linux-sunxi/libvdpau-sunxi/
>
> This driver is based on the last version of the cedrus driver sent by
> Paul, based on Request API v13 sent by Hans:
> https://lkml.org/lkml/2018/5/7/316
Just FYI, there is v15 already. :)
>
> This driver has been tested only with baseline profile videos, and is
> missing a few key features to decode videos with higher profiles.
> This has been tested using our cedrus-frame-test tool, which should be
> a quite generic v4l2-to-drm decoder using the request API to
> demonstrate the video decoding:
> https://github.com/free-electrons/cedrus-frame-test/, branch h264
>
> However, sending this preliminary version, I'd really like to start a
> discussion and get some feedback on the user-space API for the H264
> controls exposed through the request API.
>
> I've been using the controls currently integrated into ChromeOS that
> have a working version of this particular setup. However, these
> controls have a number of shortcomings and inconsistencies with other
> decoding API. I've worked with libva so far, but I've noticed already
> that:
Note that these controls are supposed to be defined exactly like the
bitstream headers deserialized into C structs in memory. I believe
Pawel (on CC) defined them based on the actual H264 specification.
> - The kernel UAPI expects to have the nal_ref_idc variable, while
> libva only exposes whether that frame is a reference frame or
> not. I've looked at the rockchip driver in the ChromeOS tree, and
> our own driver, and they both need only the information about
> whether the frame is a reference one or not, so maybe we should
> change this?
The fact that 2 drivers only need partial information doesn't mean
that we should ignore the data being already in the bitstream. IMHO
this API should to provide all the metadata available in the stream to
the kernel driver, as a replacement for bitstream parsing in firmware
(or in kernel... yuck).
> - The H264 bitstream exposes the picture default reference list (for
> both list 0 and list 1), the slice reference list and an override
> flag. The libva will only pass the reference list to be used (so
> either the picture default's or the slice's) depending on the
> override flag. The kernel UAPI wants the picture default reference
> list and the slice reference list, but doesn't expose the override
> flag, which prevents us from configuring properly the
> hardware. Our video decoding engine needs the three information,
> but we can easily adapt to having only one. However, having two
> doesn't really work for us.
Where does the override flag come from? If it's in the bitstream, then
I guess it was just missed when creating the structures.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <03f0f635-3fc2-085b-20e0-e1fcaa9e8062@microchip.com>
On 14/06/2018 14:52:25+0200, Nicolas Ferre wrote:
> > + gpio_keys {
> > + compatible = "gpio-keys";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + irqbtn at pb18 {
>
> I'm not sure that the @pb18 can be used like this. This address extension
> must be used in a "reg" property in the node. dtc used with warning switch
> on might trigger an error for this.
>
Indeed, no unit-address without a reg property.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/4] KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
From: Dave Martin @ 2018-06-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff9c9b77-20f5-42f0-23f5-09bdaebfcbe6@arm.com>
On Thu, Jun 14, 2018 at 01:50:00PM +0100, Marc Zyngier wrote:
> Hi Dave,
>
> On 14/06/18 12:42, Dave Martin wrote:
> > Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
> > guest/host thrashing") introduces a specific helper
> > kvm_arch_vcpu_put_fp() for saving the vcpu FPSIMD state during
> > vcpu_put().
> >
> > This function uses local_bh_disable()/_enable() to protect the
> > FPSIMD context manipulation from interruption by softirqs.
> >
> > This approach is not correct, because vcpu_put() can be invoked
> > either from the KVM host vcpu thread (when exiting the vcpu run
> > loop), or via a preempt notifier. In the former case, only
> > preemption is disabled. In the latter case, the function is called
> > from inside __schedule(), which means that IRQs are disabled.
> >
> > Use of local_bh_disable()/_enable() with IRQs disabled is considerd
> > an error, resulting in lockdep splats while running VMs if lockdep
> > is enabled.
> >
> > It is probably possible in theory to relax this restriction on
> > local_bh_disable()/_enable() usage, but for now this patch takes
> > the simple approach of managing softirq masking only if IRQs happen
> > to be enabled when kvm_arch_vcpu_put_fp() is called.
> >
> > Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
> > Reported-by: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > ---
> > arch/arm64/kvm/fpsimd.c | 16 ++++++++++++----
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> > index dc6ecfa..b51ff80 100644
> > --- a/arch/arm64/kvm/fpsimd.c
> > +++ b/arch/arm64/kvm/fpsimd.c
> > @@ -90,10 +90,8 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
> > * disappears and another task or vcpu appears that recycles the same
> > * struct fpsimd_state.
> > */
> > -void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > +static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > {
> > - local_bh_disable();
> > -
> > update_thread_flag(TIF_SVE,
> > vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
> >
> > @@ -105,6 +103,16 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > /* Ensure user trap controls are correctly restored */
> > fpsimd_bind_task_to_cpu();
> > }
> > +}
> > +
> >
> > - local_bh_enable();
> > +void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > +{
> > + if (irqs_disabled())
> > + __kvm_arch_vcpu_put_fp(vcpu);
> > + else {
> > + local_bh_disable();
> > + __kvm_arch_vcpu_put_fp(vcpu);
> > + local_bh_enable();
> > + }
> > }
> >
>
> I'm of the opinion to always run kvm_arch_vcpu_put_fp() with interrupt
> disabled. local_bh_enable() does quite a lot of stuff (running the
> softirqs), which adds overhead we could do without.
>
> I'd replace local_bh_{disable,enable} with local_irq_{save,restore).
I don't have a huge problem with that. This creates interrupt blackout
on run loop exit, but it's a) not worse than the blackout in
__schedule() and b) presumably the rare case compared with run loop
preemption.
So, while disabling interrupts seemed a bit brutal, in context it
doesn't look like such a big deal.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: correct voltage selector Firefly-RK3399
From: Heiko Stuebner @ 2018-06-14 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604171523.28454-1-xypron.glpk@gmx.de>
Am Montag, 4. Juni 2018, 19:15:23 CEST schrieb Heinrich Schuchardt:
> Without this patch the Firefly-RK3399 board boot process hangs after these
> lines:
>
> fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> fan53555-reg: supplied by vcc_sys
> vcc1v8_s3: supplied by vcc_1v8
>
> Blacklisting driver fan53555 allows booting.
>
> The device tree uses a value of fcs,suspend-voltage-selector different to
> any other board.
>
> Changing this setting to the usual value is sufficient to enable booting.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
applied for 4.19.
I've amended your commit message with the info from your reply about
the vendor kernel using the same value and added an appropriate Fixes
tag to possibly get it merged into stable.
Thanks
Heiko
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Nicolas Ferre @ 2018-06-14 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
On 14/06/2018 at 10:51, Ben Whitten wrote:
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 237 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e24249..1ee94ee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> at91sam9g25ek.dtb \
> at91sam9g35ek.dtb \
> at91sam9x25ek.dtb \
> - at91sam9x35ek.dtb
> + at91sam9x35ek.dtb \
> + at91-wb45n.dtb
> dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-kizbox2.dtb \
> at91-nattis-2-natte-2.dtb \
> diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-wb45n.dts
> new file mode 100644
> index 0000000..4e88815
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-wb45n.dts
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * at91-wb45n.dts - Device Tree file for WB45NBT board
> + *
> + * Copyright (C) 2018 Laird
> + *
> +*/
> +/dts-v1/;
> +#include "at91-wb45n.dtsi"
> +
> +/ {
> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
"laird" prefix must be added to
Documentation/devicetree/bindings/vendor-prefixes.txt before using it:
you can do a little patch as a first patch of this series.
Otherwise it will trigger a warning message while running
scripts/checkpatch.pl on top of your patch.
> +
> + ahb {
> + apb {
> + watchdog at fffffe40 {
> + status = "okay";
> + };
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + irqbtn at pb18 {
I'm not sure that the @pb18 can be used like this. This address
extension must be used in a "reg" property in the node. dtc used with
warning switch on might trigger an error for this.
> + label = "IRQBTN";
> + linux,code = <99>;
> + gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
> + gpio-key,wakeup = <1>;
> + };
> + };
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + status = "okay";
> +};
> +
> +&spi0 {
> + status = "okay";
> +};
> +
> +&macb0 {
> + status = "okay";
> +};
> +
> +&dbgu {
> + status = "okay";
> +};
> +
> +&usart0 {
> + status = "okay";
> +};
> +
> +&usart3 {
> + status = "okay";
> +};
> +
> +&i2c1 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-wb45n.dtsi
> new file mode 100644
> index 0000000..2fa58e2
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-wb45n.dtsi
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * at91-wb45n.dtsi - Device Tree file for WB45NBT board
> + *
> + * Copyright (C) 2018 Laird
> + *
> + */
> +
> +#include "at91sam9g25.dtsi"
> +
> +/ {
> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
> +
> + chosen {
> + bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x4000000>;
> + };
> +
> + ahb {
> + apb {
> + shdwc at fffffe10 {
I would advice you to take exactly the node name:
"shutdown-controller at fffffe10"; Anyway, it will go away after you use
the label notation as advised by Alexandre.
> + atmel,wakeup-mode = "low";
> + };
> +
> + pinctrl at fffff400 {
> + usb2 {
> + pinctrl_board_usb2: usb2-board {
> + atmel,pins =
> + <AT91_PIOB 11 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio vbus sense, deglitch */
> + };
> + };
> + };
> +
> + rstc at fffffe00 {
> + compatible = "atmel,sama5d3-rstc";
> + };
I don't think this node is needed.
> +
> + };
> + };
> +
> + atheros {
> + compatible = "atheros,ath6kl";
> + atheros,board-id = "SD32";
> + };
> +};
> +
> +&slow_xtal {
> + clock-frequency = <32768>;
> +};
> +
> +&main_xtal {
> + clock-frequency = <12000000>;
> +};
> +
> +&ebi {
> + status = "okay";
> + nand_controller: nand-controller {
> + pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb &pinctrl_nand_oe_we>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + nand at 3 {
> + reg = <0x3 0x0 0x800000>;
> + rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
> + cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> + nand-on-flash-bbt;
> + label = "atmel_nand";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + at91bootstrap at 0 {
> + label = "at91bs";
> + reg = <0x0 0x20000>;
> + };
> +
> + uboot at 20000 {
> + label = "u-boot";
> + reg = <0x20000 0x80000>;
> + };
> +
> + ubootenv at a0000 {
> + label = "u-boot-env";
> + reg = <0xa0000 0x20000>;
> + };
> +
> + ubootenv at c0000 {
> + label = "redund-env";
> + reg = <0xc0000 0x20000>;
> + };
> +
> + kernel-a at e0000 {
> + label = "kernel-a";
> + reg = <0xe0000 0x280000>;
> + };
> +
> + kernel-b at 360000 {
> + label = "kernel-b";
> + reg = <0x360000 0x280000>;
> + };
> +
> + rootfs-a at 5e0000 {
> + label = "rootfs-a";
> + reg = <0x5e0000 0x2600000>;
> + };
> +
> + rootfs-b at 2be0000 {
> + label = "rootfs-b";
> + reg = <0x2be0000 0x2600000>;
> + };
> +
> + user at 51e0000 {
> + label = "user";
> + reg = <0x51e0000 0x2dc0000>;
> + };
> +
> + logs at 7fa0000 {
> + label = "logs";
> + reg = <0x7fa0000 0x60000>;
> + };
> +
> + };
> + };
> + };
> +};
> +
> +&usb0 {
This must be &usb1 label, isn't it?
Because you are referring to ohci binding I suspect (found by having a
look at: atmel,oc-gpio property...).
> + num-ports = <2>;
> + atmel,vbus-gpio = <
> + &pioB 12 GPIO_ACTIVE_HIGH
> + &pioA 31 GPIO_ACTIVE_HIGH
> + >;
> + atmel,oc-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
> +};
> +
> +&macb0 {
> + phy-mode = "rmii";
> +};
> +
> +&spi0 {
> + cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>;
> +};
> +
> +&usb2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_board_usb2>;
> + atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&mmc0 {
> + pinctrl-0 = <
> + &pinctrl_mmc0_slot0_clk_cmd_dat0
> + &pinctrl_mmc0_slot0_dat1_3>;
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/4] KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
From: Marc Zyngier @ 2018-06-14 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-2-git-send-email-Dave.Martin@arm.com>
Hi Dave,
On 14/06/18 12:42, Dave Martin wrote:
> Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
> guest/host thrashing") introduces a specific helper
> kvm_arch_vcpu_put_fp() for saving the vcpu FPSIMD state during
> vcpu_put().
>
> This function uses local_bh_disable()/_enable() to protect the
> FPSIMD context manipulation from interruption by softirqs.
>
> This approach is not correct, because vcpu_put() can be invoked
> either from the KVM host vcpu thread (when exiting the vcpu run
> loop), or via a preempt notifier. In the former case, only
> preemption is disabled. In the latter case, the function is called
> from inside __schedule(), which means that IRQs are disabled.
>
> Use of local_bh_disable()/_enable() with IRQs disabled is considerd
> an error, resulting in lockdep splats while running VMs if lockdep
> is enabled.
>
> It is probably possible in theory to relax this restriction on
> local_bh_disable()/_enable() usage, but for now this patch takes
> the simple approach of managing softirq masking only if IRQs happen
> to be enabled when kvm_arch_vcpu_put_fp() is called.
>
> Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
> Reported-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/kvm/fpsimd.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index dc6ecfa..b51ff80 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -90,10 +90,8 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
> * disappears and another task or vcpu appears that recycles the same
> * struct fpsimd_state.
> */
> -void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> +static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> {
> - local_bh_disable();
> -
> update_thread_flag(TIF_SVE,
> vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
>
> @@ -105,6 +103,16 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> /* Ensure user trap controls are correctly restored */
> fpsimd_bind_task_to_cpu();
> }
> +}
> +
>
> - local_bh_enable();
> +void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> +{
> + if (irqs_disabled())
> + __kvm_arch_vcpu_put_fp(vcpu);
> + else {
> + local_bh_disable();
> + __kvm_arch_vcpu_put_fp(vcpu);
> + local_bh_enable();
> + }
> }
>
I'm of the opinion to always run kvm_arch_vcpu_put_fp() with interrupt
disabled. local_bh_enable() does quite a lot of stuff (running the
softirqs), which adds overhead we could do without.
I'd replace local_bh_{disable,enable} with local_irq_{save,restore).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-14 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2786d17e-1075-e0fb-1864-fb5900e4a2af@gmail.com>
On 21:36-20180613, Florian Fainelli wrote:
[...]
> >>> c) This workaround applies to only the boot processor. It is important
> >>> to apply workaround as necessary (context-save-restore) around low
> >>> power context loss OR additional processors as necessary in either
> >>> firmware support OR elsewhere in OS.
> >>
> >> About that, I don't know enough of uboot but are there existing PSCI or
> >> other seemingly standard secondary core support in uboot that would make
> >> us go through the same initialization as the boot CPU? If not, is
> >> everything going to be largely implementation specific and
> >> scattered between uboot and the hypervisors or kernel?
> >
> > in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard.
> > even within TI, Few of the SoCs use PSCI, others did implement custom
> > SMC calls (since they existed in an architecture prior to PSCI).
> >
> >>
> >> FWIW, this is what prompted me to submit this:
> >>
> >> https://patchwork.kernel.org/patch/10453643/
> >
> > That wont work in a generic manner for precisely the same reason I had to do
> > it with weak function in u-boot (some SoCs will only permit 'mcr
> > p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc
> > call to make it happen). Unfortunately, IMHO, at least at this
> > point, there'd be custom implementations per SoC and layers depending on
> > where to implement it.
>
> It won't work in a generic manner but it will work for some platforms
> where updating the firmware is impractical, and since the bits are write
> ignore if your PL does not allow it, this still seems like a net win for
> platforms where this is effective, and it does take care of Linux doing
> the SMP bring-up of secondary cores as well. That's what we have in our
> downstream tree at least, and I was hoping this could land upstream too.
I think it is clear from Russell's summary that we dont want "may work"
workaround in kernel/bootloaders. in case of u-boot (which this patch is
about), I'd suggest adding the CONFIG_*CVE* input to the Kconfig for the
SoC where you know for sure this works.
Does that sound a fair tradeoff?
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
From: Dave Martin @ 2018-06-14 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976039-25826-1-git-send-email-Dave.Martin@arm.com>
On Thu, Jun 14, 2018 at 12:33:55PM +0100, Dave Martin wrote:
> This series contains fixes for some issues observed since the KVM arm64
> pull request for 4.17.
*ahem*, that should read 4.18.
> The first patch (from Mark Rutland) adds a straightforward helper to
> modify particular bits in a system register conditionally. This is used
> by patch 3 (though obviously it could be coded round and patch 1
> dropped, if preferred).
>
> See other patches for details of the individual fixes.
>
> Dave Martin (3):
> KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
> KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
> KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
>
> Mark Rutland (1):
> arm64: introduce sysreg_clear_set()
>
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/include/asm/sysreg.h | 11 ++++++++++
> arch/arm64/kvm/fpsimd.c | 46 +++++++++++++++++++++++++++++----------
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Tony Lindgren @ 2018-06-14 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607233853.p7iw7nlxxuyi66og@kahuna>
Hi,
Some comments on the ranges below.
* Nishanth Menon <nm@ti.com> [180607 16:41]:
> + soc0: soc0 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
I suggest you leave out the soc0, that's not real. Just make
the cbass at 0 the top level interconnect. It can then provide
ranges to mcu interconnect which can provide ranges to the wkup
interconnect. So just model it after what's in the hardware :)
I found the following ranges based on a quick look at the TRM,
they could be split further if needed for power domains for
genpd for example.
main covers
0x0000000000 - 0x5402000000
main provides at least the following ranges for mcu
0x0028380000 - 0x002bc00000
0x0040080000 - 0x0041c80000
0x0045100000 - 0x0045180000
0x0045600000 - 0x0045640000
0x0045810000 - 0x0045860000
0x0045950000 - 0x0045950400
0x0045a50000 - 0x0045a50400
0x0045b04000 - 0x0045b06400
0x0045d10000 - 0x0045d24000
0x0046000000 - 0x0060000000
0x0400000000 - 0x0800000000
0x4c3c020000 - 0x4c3c030000
0x4c3e000000 - 0x4c3e040000
0x5400000000 - 0x5402000000
then mcu provides the following ranges for wkup
0x0042000000 - 0x0044410020
0x0045000000 - 0x0045030000
0x0045080000 - 0x00450a0000
0x0045808000 - 0x0045808800
0x0045b00000 - 0x0045b02400
This based on looking at "figure 1-1. device top-level
block diagram" and the memory map in TRM.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Nicolas Ferre @ 2018-06-14 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614095041.GW10521@piout.net>
On 14/06/2018 at 11:50, Alexandre Belloni wrote:
> On 14/06/2018 09:51:55+0100, Ben Whitten wrote:
>> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
>> arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 320 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
>> create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 1ee94ee..fd5f8a6 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
>> at91-sama5d4_ma5d4evk.dtb \
>> at91-sama5d4_xplained.dtb \
>> at91-sama5d4ek.dtb \
>> - at91-vinco.dtb
>> + at91-vinco.dtb \
>> + at91-wb50n.dtb
>
> I know we have been bad at this but this should be
> at91-<soc>-<board>.dtb so at91-sama5d31-wb50n.dtb
See new message by Alexandre.
Actually, the current convention is explained here:
https://elixir.bootlin.com/linux/latest/source/Documentation/arm/Microchip/README#L159
>> dtb-$(CONFIG_ARCH_ATLAS6) += \
>> atlas6-evb.dtb
>> dtb-$(CONFIG_ARCH_ATLAS7) += \
>> diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
>> new file mode 100644
>> index 0000000..ee4f823
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91-wb50n.dts
>> @@ -0,0 +1,116 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * at91-wb50n.dts - Device Tree file for wb50n evaluation board
>> + *
>> + * Copyright (C) 2018 Laird
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +#include "at91-wb50n.dtsi"
>> +
>> +/ {
>> + model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
>> + compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +
>> + ahb {
>> + apb {
>> + watchdog at fffffe40 {
>
> I don't mind if you want to have a preparation patch adding the
> necessary labels in the soc dtsi so you don't have to reproduce the
> ahb/apb hierarchy here.
I agree: +1
>> + ahb {
>> + apb {
>> + pinctrl at fffff200 {
>
> Ditto
>
>> + board {
>> + pinctrl_mmc0_cd: mmc0_cd {
>> + atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
>> + };
>> +
>> + pinctrl_usba_vbus: usba_vbus {
>> + atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
>> + };
>> + };
>> + };
>> + };
>> + };
>> +};
>> +
>> +&slow_osc {
>> + atmel,osc-bypass;
>> +};
>
> After the clock binding rework, this will have to be moved to the pmc
> node (the rework is not posted, this is just to remind me that this will
> have to be done).
>
>> +
>> +&usart1_clk {
>> + atmel,clk-output-range = <0 132000000>;
>> +};
>
> The datasheet explicitly states that 66 MHz is the maximum allowed
> frequency for the USART. Note that the new binding will not allow you to
> do that.
>
> However, I see the table disappeared from the latest datasheet. Maybe
> Nicolas can comment on that?
You're right, 66 MHz is the maximum frequency for all USART and UART on
this sama5d3 SoC.
The disappearing of this table is a bug in the latest datasheet. I can
see that the one "11121B?ATARM?08-Mar-13" still have it. I report this
issue to the team in charge of datasheets (it will be certainly fixed
for next release of this document).
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") uses fpsimd_save() to save the FPSIMD state
for a vcpu when scheduling the vcpu out. However, currently
current's value of TIF_SVE is restored before calling fpsimd_save()
which means that fpsimd_save() may erroneously attempt to save SVE
state from the vcpu. This enables current's vector state to be
polluted with guest data. current->thread.sve_state may be
unallocated or not large enough, so this can also trigger a NULL
dereference or buffer overrun.
Instead of this, TIF_SVE should be configured properly for the
guest when calling fpsimd_save() with the vcpu context loaded.
This patch ensures this my delaying restoration of current's
TIF_SVE until after the call to fpsimd_save().
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/fpsimd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 30c7a34..4aaf78e 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -99,9 +99,6 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
*/
static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
{
- update_thread_flag(TIF_SVE,
- vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
-
if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
/* Clean guest FP state to memory and invalidate cpu view */
fpsimd_save();
@@ -119,6 +116,9 @@ static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
else
sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0);
}
+
+ update_thread_flag(TIF_SVE,
+ vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") attempts to restore the configuration of
userspace SVE trapping via a call to fpsimd_bind_task_to_cpu(), but
the logic for determining when to do this is not correct.
The patch makes the errnoenous assumption that the only task that
may try to enter userspace with the currently loaded FPSIMD/SVE
register content is current. This may not be the case however: if
some other user task T is scheduled on the CPU during the execution
of the KVM run loop, and the vcpu does not try to use the registers
in the meantime, then T's state may be left there intact. If T
happens to be the next task to enter userspace on this CPU then the
hooks for reloading the register state and configuring traps will
be skipped.
(Also, current never has SVE state at this point anyway and should
always have the trap enabled, as a side-effect of the ioctl()
syscall needed to reach the KVM run loop in the first place.)
This patch instead restores the state of the EL0 trap from the
state observed at the most recent vcpu_load(), ensuring that the
trap is set correctly for the loaded context (if any).
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/fpsimd.c | 24 ++++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index fda9a8c..fe8777b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -306,6 +306,7 @@ struct kvm_vcpu_arch {
#define KVM_ARM64_FP_ENABLED (1 << 1) /* guest FP regs loaded */
#define KVM_ARM64_FP_HOST (1 << 2) /* host FP regs loaded */
#define KVM_ARM64_HOST_SVE_IN_USE (1 << 3) /* backup for host TIF_SVE */
+#define KVM_ARM64_HOST_SVE_ENABLED (1 << 4) /* SVE enabled for EL0 */
#define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index b51ff80..30c7a34 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -12,6 +12,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_host.h>
#include <asm/kvm_mmu.h>
+#include <asm/sysreg.h>
/*
* Called on entry to KVM_RUN unless this vcpu previously ran at least
@@ -61,10 +62,16 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
{
BUG_ON(!current->mm);
- vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
+ vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
+ KVM_ARM64_HOST_SVE_IN_USE |
+ KVM_ARM64_HOST_SVE_ENABLED);
vcpu->arch.flags |= KVM_ARM64_FP_HOST;
+
if (test_thread_flag(TIF_SVE))
vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;
+
+ if (read_sysreg(cpacr_el1) & CPACR_EL1_ZEN_EL0EN)
+ vcpu->arch.flags |= KVM_ARM64_HOST_SVE_ENABLED;
}
/*
@@ -99,9 +106,18 @@ static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
/* Clean guest FP state to memory and invalidate cpu view */
fpsimd_save();
fpsimd_flush_cpu_state();
- } else if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
- /* Ensure user trap controls are correctly restored */
- fpsimd_bind_task_to_cpu();
+ } else if (system_supports_sve()) {
+ /*
+ * The FPSIMD/SVE state in the CPU has not been touched, and we
+ * have SVE (and VHE): CPACR_EL1 (alias CPTR_EL2) has been
+ * reset to CPACR_EL1_DEFAULT by the Hyp code, disabling SVE
+ * for EL0. To avoid spurious traps, restore the trap state
+ * seen by kvm_arch_vcpu_load_fp():
+ */
+ if (vcpu->arch.flags & KVM_ARM64_HOST_SVE_ENABLED)
+ sysreg_clear_set(CPACR_EL1, 0, CPACR_EL1_ZEN_EL0EN);
+ else
+ sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0);
}
}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") introduces a specific helper
kvm_arch_vcpu_put_fp() for saving the vcpu FPSIMD state during
vcpu_put().
This function uses local_bh_disable()/_enable() to protect the
FPSIMD context manipulation from interruption by softirqs.
This approach is not correct, because vcpu_put() can be invoked
either from the KVM host vcpu thread (when exiting the vcpu run
loop), or via a preempt notifier. In the former case, only
preemption is disabled. In the latter case, the function is called
from inside __schedule(), which means that IRQs are disabled.
Use of local_bh_disable()/_enable() with IRQs disabled is considerd
an error, resulting in lockdep splats while running VMs if lockdep
is enabled.
It is probably possible in theory to relax this restriction on
local_bh_disable()/_enable() usage, but for now this patch takes
the simple approach of managing softirq masking only if IRQs happen
to be enabled when kvm_arch_vcpu_put_fp() is called.
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/fpsimd.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index dc6ecfa..b51ff80 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -90,10 +90,8 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
* disappears and another task or vcpu appears that recycles the same
* struct fpsimd_state.
*/
-void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
+static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
{
- local_bh_disable();
-
update_thread_flag(TIF_SVE,
vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
@@ -105,6 +103,16 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
/* Ensure user trap controls are correctly restored */
fpsimd_bind_task_to_cpu();
}
+}
+
- local_bh_enable();
+void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
+{
+ if (irqs_disabled())
+ __kvm_arch_vcpu_put_fp(vcpu);
+ else {
+ local_bh_disable();
+ __kvm_arch_vcpu_put_fp(vcpu);
+ local_bh_enable();
+ }
}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] arm64: introduce sysreg_clear_set()
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976039-25826-1-git-send-email-Dave.Martin@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Currently we have a couple of helpers to manipulate bits in particular
sysregs:
* config_sctlr_el1(u32 clear, u32 set)
* change_cpacr(u64 val, u64 mask)
The parameters of these differ in naming convention, order, and size,
which is unfortunate. They also differ slightly in behaviour, as
change_cpacr() skips the sysreg write if the bits are unchanged, which
is a useful optimization when sysreg writes are expensive.
Before we gain more yet another sysreg manipulation function, let's
unify these with a common helper, providing a consistent order for
clear/set operands, and the write skipping behaviour from
change_cpacr(). Code will be migrated to the new helper in subsequent
patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/sysreg.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6171178..a8f8481 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -728,6 +728,17 @@ asm(
asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
+/*
+ * Modify bits in a sysreg. Bits in the clear mask are zeroed, then bits in the
+ * set mask are set. Other bits are left as-is.
+ */
+#define sysreg_clear_set(sysreg, clear, set) do { \
+ u64 __scs_val = read_sysreg(sysreg); \
+ u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set); \
+ if (__scs_new != __scs_val) \
+ write_sysreg(__scs_new, sysreg); \
+} while (0)
+
static inline void config_sctlr_el1(u32 clear, u32 set)
{
u32 val;
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
From: Dave Martin @ 2018-06-14 11:33 UTC (permalink / raw)
To: linux-arm-kernel
This series contains fixes for some issues observed since the KVM arm64
pull request for 4.17.
The first patch (from Mark Rutland) adds a straightforward helper to
modify particular bits in a system register conditionally. This is used
by patch 3 (though obviously it could be coded round and patch 1
dropped, if preferred).
See other patches for details of the individual fixes.
Dave Martin (3):
KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
Mark Rutland (1):
arm64: introduce sysreg_clear_set()
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/sysreg.h | 11 ++++++++++
arch/arm64/kvm/fpsimd.c | 46 +++++++++++++++++++++++++++++----------
3 files changed, 47 insertions(+), 11 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 4/4] arm64: dts: rockchip: add Google Bob
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
After Kevin, the second chromebook-incarnation of the Gru series is Bob.
This materializes as the Asus Chromebook Flip C101PA, whose formfactor
is quite similar to Minnie from the Veyron series.
Add the devicetree file and binding update for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../devicetree/bindings/arm/rockchip.txt | 9 +++
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-gru-bob.dts | 79 +++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 1c1d62d03c4f..145ab0b0a030 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -66,6 +66,15 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
+- Google Bob (Asus Chromebook Flip C101PA):
+ Required root node properties:
+ compatible = "google,bob-rev13", "google,bob-rev12",
+ "google,bob-rev11", "google,bob-rev10",
+ "google,bob-rev9", "google,bob-rev8",
+ "google,bob-rev7", "google,bob-rev6",
+ "google,bob-rev5", "google,bob-rev4",
+ "google,bob", "google,gru", "rockchip,rk3399";
+
- Google Brain (dev-board):
Required root node properties:
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 48a83f882947..7c4311eac700 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -10,6 +10,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
new file mode 100644
index 000000000000..1ee0dc0d9f10
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Gru-Bob Rev 4+ board device tree source
+ *
+ * Copyright 2018 Google, Inc
+ */
+
+/dts-v1/;
+#include "rk3399-gru-chromebook.dtsi"
+
+/ {
+ model = "Google Bob";
+ compatible = "google,bob-rev13", "google,bob-rev12",
+ "google,bob-rev11", "google,bob-rev10",
+ "google,bob-rev9", "google,bob-rev8",
+ "google,bob-rev7", "google,bob-rev6",
+ "google,bob-rev5", "google,bob-rev4",
+ "google,bob", "google,gru", "rockchip,rk3399";
+
+ edp_panel: edp-panel {
+ compatible = "boe,nv101wxmn51", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&pp3300_disp>;
+
+ ports {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&edp_out_panel>;
+ };
+ };
+ };
+};
+
+&ap_i2c_ts {
+ touchscreen: touchscreen at 10 {
+ compatible = "elan,ekth3500";
+ reg = <0x10>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_int_l &touch_reset_l>;
+ reset-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ap_i2c_tp {
+ trackpad: trackpad at 15 {
+ compatible = "elan,ekth3000";
+ reg = <0x15>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&trackpad_int_l>;
+ wakeup-source;
+ };
+};
+
+&backlight {
+ pwms = <&cros_ec_pwm 0>;
+};
+
+&cpu_alert0 {
+ temperature = <65000>;
+};
+
+&cpu_alert1 {
+ temperature = <70000>;
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&pinctrl {
+ tpm {
+ h1_int_od_l: h1-int-od-l {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
--
2.17.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: rockchip: move core edp from rk3399-kevin to shared chromebook
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Bob needs the same backlight and core edp settings, so move these node to
the shared dtsi that both will use as a base.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 34 ++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 39 ++-----------------
2 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 32139e6910a3..8cce0f59d2ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -191,6 +191,23 @@
vin-supply = <&pp1800_pcie>;
};
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+ 17 18 19 20 21 22 23 24 25 26 27 28 29 30
+ 31 32 33 34 35 36 37 38 39 40 41 42 43 44
+ 45 46 47 48 49 50 51 52 53 54 55 56 57 58
+ 59 60 61 62 63 64 65 66 67 68 69 70 71 72
+ 73 74 75 76 77 78 79 80 81 82 83 84 85 86
+ 87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
+ default-brightness-level = <51>;
+ enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ power-supply = <&pp3300_disp>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_en>;
+ pwm-delay-us = <10000>;
+ };
};
&ppvar_bigcpu {
@@ -212,6 +229,23 @@
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
+&edp {
+ status = "okay";
+
+ ports {
+ edp_out: port at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_out_panel: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+};
+
ap_i2c_mic: &i2c1 {
status = "okay";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index e582ec9fbc97..2cc7c47d6a85 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -38,24 +38,6 @@
vin-supply = <&pp3300>;
};
- backlight: backlight {
- compatible = "pwm-backlight";
- pwms = <&cros_ec_pwm 1>;
- brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- 17 18 19 20 21 22 23 24 25 26 27 28 29 30
- 31 32 33 34 35 36 37 38 39 40 41 42 43 44
- 45 46 47 48 49 50 51 52 53 54 55 56 57 58
- 59 60 61 62 63 64 65 66 67 68 69 70 71 72
- 73 74 75 76 77 78 79 80 81 82 83 84 85 86
- 87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
- default-brightness-level = <51>;
- enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
- power-supply = <&pp3300_disp>;
- pinctrl-names = "default";
- pinctrl-0 = <&bl_en>;
- pwm-delay-us = <10000>;
- };
-
edp_panel: edp-panel {
compatible = "sharp,lq123p1jx31", "simple-panel";
backlight = <&backlight>;
@@ -87,6 +69,10 @@
};
};
+&backlight {
+ pwms = <&cros_ec_pwm 1>;
+};
+
&gpio_keys {
pinctrl-names = "default";
pinctrl-0 = <&bt_host_wake_l>, <&cpu1_pen_eject>;
@@ -243,23 +229,6 @@ ap_i2c_dig: &i2c2 {
};
};
-&edp {
- status = "okay";
-
- ports {
- edp_out: port at 1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- edp_out_panel: endpoint at 0 {
- reg = <0>;
- remote-endpoint = <&panel_in_edp>;
- };
- };
- };
-};
-
&ppvar_bigcpu_pwm {
regulator-min-microvolt = <798674>;
regulator-max-microvolt = <1302172>;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: rockchip: add phandles to some nodes on rk3399-gru
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Some nodes will need to be refined on a per board level, so add phandles
to them to reference them later.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 614b4f198cc0..ca07f6032200 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -267,7 +267,7 @@
pinctrl-names = "default";
pinctrl-0 = <&bt_host_wake_l>;
- wake-on-bt {
+ wake_on_bt: wake-on-bt {
label = "Wake-on-Bluetooth";
gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WAKEUP>;
@@ -285,7 +285,7 @@
status = "okay";
};
- sound {
+ sound: sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0 &i2s2>;
};
@@ -813,7 +813,7 @@ ap_i2c_audio: &i2c8 {
};
};
- wifi {
+ wifi: wifi {
wlan_module_reset_l: wlan-module-reset-l {
rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_pull_none>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Similar to rk3288-Veyron before, the Gru-series does contain Chromebook
(aka clamshell laptops) and non-Chromebook devices. And while the two
Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet-
device is quite different in its design.
Therefore move the Chromebook parts into a gru-chromebook dtsi file
to make sharing easier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 365 ++++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 8 +-
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 322 ---------------
3 files changed, 366 insertions(+), 329 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
new file mode 100644
index 000000000000..32139e6910a3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Gru-Chromebook shared properties
+ *
+ * Copyright 2018 Google, Inc
+ */
+
+#include "rk3399-gru.dtsi"
+
+/ {
+ pp900_ap: pp900-ap {
+ compatible = "regulator-fixed";
+ regulator-name = "pp900_ap";
+
+ /* EC turns on w/ pp900_ap_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ /* EC turns on w/ pp900_usb_en */
+ pp900_usb: pp900-ap {
+ };
+
+ /* EC turns on w/ pp900_pcie_en */
+ pp900_pcie: pp900-ap {
+ };
+
+ pp3000: pp3000 {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp3000_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
+ compatible = "pwm-regulator";
+ regulator-name = "ppvar_centerlogic_pwm";
+
+ pwms = <&pwm3 0 3337 0>;
+ pwm-supply = <&ppvar_sys>;
+ pwm-dutycycle-range = <100 0>;
+ pwm-dutycycle-unit = <100>;
+
+ /* EC turns on w/ ppvar_centerlogic_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <799434>;
+ regulator-max-microvolt = <1049925>;
+ };
+
+ ppvar_centerlogic: ppvar-centerlogic {
+ compatible = "vctrl-regulator";
+ regulator-name = "ppvar_centerlogic";
+
+ regulator-min-microvolt = <799434>;
+ regulator-max-microvolt = <1049925>;
+
+ ctrl-supply = <&ppvar_centerlogic_pwm>;
+ ctrl-voltage-range = <799434 1049925>;
+
+ regulator-settling-time-up-us = <378>;
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+ };
+
+ /* Schematics call this PPVAR even though it's fixed */
+ ppvar_logic: ppvar-logic {
+ compatible = "regulator-fixed";
+ regulator-name = "ppvar_logic";
+
+ /* EC turns on w/ ppvar_logic_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ pp1800_audio: pp1800-audio {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_audio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp1800_audio_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ vin-supply = <&pp1800>;
+ };
+
+ /* gpio is shared with pp3300_wifi_bt */
+ pp1800_pcie: pp1800-pcie {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_pcie";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_module_pd_l>;
+
+ enable-active-high;
+ gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+ /*
+ * Need to wait 1ms + ramp-up time before we can power on WiFi.
+ * This has been approximated as 8ms total.
+ */
+ regulator-enable-ramp-delay = <8000>;
+
+ vin-supply = <&pp1800>;
+ };
+
+ /* Always on; plain and simple */
+ pp3000_ap: pp3000_emmc: pp3000 {
+ };
+
+ pp1500_ap_io: pp1500-ap-io {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1500_ap_io";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp1500_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+
+ vin-supply = <&pp1800>;
+ };
+
+ pp3300_disp: pp3300-disp {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_disp";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp3300_disp_en>;
+
+ enable-active-high;
+ gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+
+ startup-delay-us = <2000>;
+ vin-supply = <&pp3300>;
+ };
+
+ /* EC turns on w/ pp3300_usb_en_l */
+ pp3300_usb: pp3300 {
+ };
+
+ /* gpio is shared with pp1800_pcie and pinctrl is set there */
+ pp3300_wifi_bt: pp3300-wifi-bt {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_wifi_bt";
+
+ enable-active-high;
+ gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+ vin-supply = <&pp3300>;
+ };
+
+ /*
+ * This is a bit of a hack. The WiFi module should be reset at least
+ * 1ms after its regulators have ramped up (max rampup time is ~7ms).
+ * With some stretching of the imagination, we can call the 1.8V
+ * regulator a supply.
+ */
+ wlan_pd_n: wlan-pd-n {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan_pd_n";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_module_reset_l>;
+
+ enable-active-high;
+ gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+
+ vin-supply = <&pp1800_pcie>;
+ };
+};
+
+&ppvar_bigcpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&ppvar_litcpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&ppvar_gpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&cdn_dp {
+ extcon = <&usbc_extcon0>, <&usbc_extcon1>;
+};
+
+ap_i2c_mic: &i2c1 {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ /* These are relatively safe rise/fall times */
+ i2c-scl-falling-time-ns = <50>;
+ i2c-scl-rising-time-ns = <300>;
+
+ headsetcodec: rt5514 at 57 {
+ compatible = "realtek,rt5514";
+ reg = <0x57>;
+ realtek,dmic-init-delay-ms = <20>;
+ };
+};
+
+ap_i2c_tp: &i2c5 {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ /* These are relatively safe rise/fall times */
+ i2c-scl-falling-time-ns = <50>;
+ i2c-scl-rising-time-ns = <300>;
+
+ /*
+ * Note strange pullup enable. Apparently this avoids leakage but
+ * still allows us to get nice 4.7K pullups for high speed i2c
+ * transfers. Basically we want the pullup on whenever the ap is
+ * alive, so the "en" pin just gets set to output high.
+ */
+ pinctrl-0 = <&i2c5_xfer &ap_i2c_tp_pu_en>;
+};
+
+&cros_ec {
+ cros_ec_pwm: ec-pwm {
+ compatible = "google,cros-ec-pwm";
+ #pwm-cells = <1>;
+ };
+
+ usbc_extcon1: extcon at 1 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <1>;
+
+ #extcon-cells = <0>;
+ };
+};
+
+&sound {
+ rockchip,codec = <&max98357a &headsetcodec
+ &codec &wacky_spi_audio &cdn_dp>;
+};
+
+&spi2 {
+ wacky_spi_audio: spi2 at 0 {
+ compatible = "realtek,rt5514";
+ reg = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mic_int>;
+ /* May run faster once verified. */
+ spi-max-frequency = <10000000>;
+ wakeup-source;
+ };
+};
+
+&pci_rootport {
+ mvl_wifi: wifi at 0,0 {
+ compatible = "pci1b4b,2b42";
+ reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
+ 0x83010000 0x0 0x00100000 0x0 0x00100000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_host_wake_l>;
+ wakeup-source;
+ };
+};
+
+&tcphy1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
+&u2phy1 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&pinctrl {
+ discrete-regulators {
+ pp1500_en: pp1500-en {
+ rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ pp1800_audio_en: pp1800-audio-en {
+ rockchip,pins = <RK_GPIO0 2 RK_FUNC_GPIO
+ &pcfg_pull_down>;
+ };
+
+ pp3000_en: pp3000-en {
+ rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ pp3300_disp_en: pp3300-disp-en {
+ rockchip,pins = <RK_GPIO4 27 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ wlan_module_pd_l: wlan-module-pd-l {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO
+ &pcfg_pull_down>;
+ };
+ };
+};
+
+&wifi {
+ wifi_perst_l: wifi-perst-l {
+ rockchip,pins = <2 27 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wlan_host_wake_l: wlan-host-wake-l {
+ rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 356c4d71c95b..e582ec9fbc97 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -6,7 +6,7 @@
*/
/dts-v1/;
-#include "rk3399-gru.dtsi"
+#include "rk3399-gru-chromebook.dtsi"
#include <dt-bindings/input/linux-event-codes.h>
/*
@@ -337,10 +337,4 @@ ap_i2c_dig: &i2c2 {
rockchip,pins = <0 13 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
-
- wifi {
- wlan_host_wake_l: wlan-host-wake-l {
- rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index e2a60680c66c..614b4f198cc0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -45,19 +45,6 @@
regulator-boot-on;
};
- pp900_ap: pp900-ap {
- compatible = "regulator-fixed";
- regulator-name = "pp900_ap";
-
- /* EC turns on w/ pp900_ap_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
-
- vin-supply = <&ppvar_sys>;
- };
-
pp1200_lpddr: pp1200-lpddr {
compatible = "regulator-fixed";
regulator-name = "pp1200_lpddr";
@@ -84,23 +71,6 @@
vin-supply = <&ppvar_sys>;
};
- pp3000: pp3000 {
- compatible = "regulator-fixed";
- regulator-name = "pp3000";
- pinctrl-names = "default";
- pinctrl-0 = <&pp3000_en>;
-
- enable-active-high;
- gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
-
- vin-supply = <&ppvar_sys>;
- };
-
pp3300: pp3300 {
compatible = "regulator-fixed";
regulator-name = "pp3300";
@@ -154,8 +124,6 @@
ctrl-voltage-range = <800107 1302232>;
regulator-settling-time-up-us = <322>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
};
ppvar_litcpu_pwm: ppvar-litcpu-pwm {
@@ -185,8 +153,6 @@
ctrl-voltage-range = <797743 1307837>;
regulator-settling-time-up-us = <384>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
};
ppvar_gpu_pwm: ppvar-gpu-pwm {
@@ -216,63 +182,12 @@
ctrl-voltage-range = <786384 1217747>;
regulator-settling-time-up-us = <390>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
- };
-
- ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
- compatible = "pwm-regulator";
- regulator-name = "ppvar_centerlogic_pwm";
-
- pwms = <&pwm3 0 3337 0>;
- pwm-supply = <&ppvar_sys>;
- pwm-dutycycle-range = <100 0>;
- pwm-dutycycle-unit = <100>;
-
- /* EC turns on w/ ppvar_centerlogic_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <799434>;
- regulator-max-microvolt = <1049925>;
- };
-
- ppvar_centerlogic: ppvar-centerlogic {
- compatible = "vctrl-regulator";
- regulator-name = "ppvar_centerlogic";
-
- regulator-min-microvolt = <799434>;
- regulator-max-microvolt = <1049925>;
-
- ctrl-supply = <&ppvar_centerlogic_pwm>;
- ctrl-voltage-range = <799434 1049925>;
-
- regulator-settling-time-up-us = <378>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
- };
-
- /* Schematics call this PPVAR even though it's fixed */
- ppvar_logic: ppvar-logic {
- compatible = "regulator-fixed";
- regulator-name = "ppvar_logic";
-
- /* EC turns on w/ ppvar_logic_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
-
- vin-supply = <&ppvar_sys>;
};
/* EC turns on w/ pp900_ddrpll_en */
pp900_ddrpll: pp900-ap {
};
- /* EC turns on w/ pp900_pcie_en */
- pp900_pcie: pp900-ap {
- };
-
/* EC turns on w/ pp900_pll_en */
pp900_pll: pp900-ap {
};
@@ -281,10 +196,6 @@
pp900_pmu: pp900-ap {
};
- /* EC turns on w/ pp900_usb_en */
- pp900_usb: pp900-ap {
- };
-
/* EC turns on w/ pp1800_s0_en_l */
pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 {
};
@@ -309,79 +220,6 @@
pp1800_usb: pp1800 {
};
- pp1500_ap_io: pp1500-ap-io {
- compatible = "regulator-fixed";
- regulator-name = "pp1500_ap_io";
- pinctrl-names = "default";
- pinctrl-0 = <&pp1500_en>;
-
- enable-active-high;
- gpio = <&gpio0 10 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
-
- vin-supply = <&pp1800>;
- };
-
- pp1800_audio: pp1800-audio {
- compatible = "regulator-fixed";
- regulator-name = "pp1800_audio";
- pinctrl-names = "default";
- pinctrl-0 = <&pp1800_audio_en>;
-
- enable-active-high;
- gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
-
- vin-supply = <&pp1800>;
- };
-
- /* gpio is shared with pp3300_wifi_bt */
- pp1800_pcie: pp1800-pcie {
- compatible = "regulator-fixed";
- regulator-name = "pp1800_pcie";
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_module_pd_l>;
-
- enable-active-high;
- gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
-
- /*
- * Need to wait 1ms + ramp-up time before we can power on WiFi.
- * This has been approximated as 8ms total.
- */
- regulator-enable-ramp-delay = <8000>;
-
- vin-supply = <&pp1800>;
- };
-
- /*
- * This is a bit of a hack. The WiFi module should be reset at least
- * 1ms after its regulators have ramped up (max rampup time is ~7ms).
- * With some stretching of the imagination, we can call the 1.8V
- * regulator a supply.
- */
- wlan_pd_n: wlan-pd-n {
- compatible = "regulator-fixed";
- regulator-name = "wlan_pd_n";
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_module_reset_l>;
-
- enable-active-high;
- gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
-
- vin-supply = <&pp1800_pcie>;
- };
-
- /* Always on; plain and simple */
- pp3000_ap: pp3000_emmc: pp3000 {
- };
-
pp3000_sd_slot: pp3000-sd-slot {
compatible = "regulator-fixed";
regulator-name = "pp3000_sd_slot";
@@ -420,34 +258,6 @@
pp3300_trackpad: pp3300-trackpad {
};
- /* EC turns on w/ pp3300_usb_en_l */
- pp3300_usb: pp3300 {
- };
-
- pp3300_disp: pp3300-disp {
- compatible = "regulator-fixed";
- regulator-name = "pp3300_disp";
- pinctrl-names = "default";
- pinctrl-0 = <&pp3300_disp_en>;
-
- enable-active-high;
- gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
-
- startup-delay-us = <2000>;
- vin-supply = <&pp3300>;
- };
-
- /* gpio is shared with pp1800_pcie and pinctrl is set there */
- pp3300_wifi_bt: pp3300-wifi-bt {
- compatible = "regulator-fixed";
- regulator-name = "pp3300_wifi_bt";
-
- enable-active-high;
- gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
-
- vin-supply = <&pp3300>;
- };
-
/* EC turns on w/ usb_a_en */
pp5000_usb_a_vbus: pp5000 {
};
@@ -478,14 +288,11 @@
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0 &i2s2>;
- rockchip,codec = <&max98357a &headsetcodec
- &codec &wacky_spi_audio &cdn_dp>;
};
};
&cdn_dp {
status = "okay";
- extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
/*
@@ -576,22 +383,6 @@
status = "okay";
};
-ap_i2c_mic: &i2c1 {
- status = "okay";
-
- clock-frequency = <400000>;
-
- /* These are relatively safe rise/fall times */
- i2c-scl-falling-time-ns = <50>;
- i2c-scl-rising-time-ns = <300>;
-
- headsetcodec: rt5514 at 57 {
- compatible = "realtek,rt5514";
- reg = <0x57>;
- realtek,dmic-init-delay-ms = <20>;
- };
-};
-
ap_i2c_ts: &i2c3 {
status = "okay";
@@ -602,24 +393,6 @@ ap_i2c_ts: &i2c3 {
i2c-scl-rising-time-ns = <300>;
};
-ap_i2c_tp: &i2c5 {
- status = "okay";
-
- clock-frequency = <400000>;
-
- /* These are relatively safe rise/fall times */
- i2c-scl-falling-time-ns = <50>;
- i2c-scl-rising-time-ns = <300>;
-
- /*
- * Note strange pullup enable. Apparently this avoids leakage but
- * still allows us to get nice 4.7K pullups for high speed i2c
- * transfers. Basically we want the pullup on whenever the ap is
- * alive, so the "en" pin just gets set to output high.
- */
- pinctrl-0 = <&i2c5_xfer &ap_i2c_tp_pu_en>;
-};
-
ap_i2c_audio: &i2c8 {
status = "okay";
@@ -693,17 +466,6 @@ ap_i2c_audio: &i2c8 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
-
- mvl_wifi: wifi at 0,0 {
- compatible = "pci1b4b,2b42";
- reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
- 0x83010000 0x0 0x00100000 0x0 0x00100000>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_host_wake_l>;
- wakeup-source;
- };
};
};
@@ -793,18 +555,6 @@ ap_i2c_audio: &i2c8 {
&spi2 {
status = "okay";
-
- wacky_spi_audio: spi2 at 0 {
- compatible = "realtek,rt5514";
- reg = <0>;
- interrupt-parent = <&gpio1>;
- interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&mic_int>;
- /* May run faster once verified. */
- spi-max-frequency = <10000000>;
- wakeup-source;
- };
};
&spi5 {
@@ -826,24 +576,12 @@ ap_i2c_audio: &i2c8 {
#size-cells = <0>;
};
- cros_ec_pwm: ec-pwm {
- compatible = "google,cros-ec-pwm";
- #pwm-cells = <1>;
- };
-
usbc_extcon0: extcon at 0 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <0>;
#extcon-cells = <0>;
};
-
- usbc_extcon1: extcon at 1 {
- compatible = "google,extcon-usbc-cros-ec";
- google,usb-port-id = <1>;
-
- #extcon-cells = <0>;
- };
};
};
@@ -859,19 +597,10 @@ ap_i2c_audio: &i2c8 {
extcon = <&usbc_extcon0>;
};
-&tcphy1 {
- status = "okay";
- extcon = <&usbc_extcon1>;
-};
-
&u2phy0 {
status = "okay";
};
-&u2phy1 {
- status = "okay";
-};
-
&u2phy0_host {
status = "okay";
};
@@ -892,22 +621,10 @@ ap_i2c_audio: &i2c8 {
status = "okay";
};
-&usb_host0_ehci {
- status = "okay";
-};
-
&usb_host0_ohci {
status = "okay";
};
-&usb_host1_ehci {
- status = "okay";
-};
-
-&usb_host1_ohci {
- status = "okay";
-};
-
&usbdrd3_0 {
status = "okay";
extcon = <&usbc_extcon0>;
@@ -918,16 +635,6 @@ ap_i2c_audio: &i2c8 {
dr_mode = "host";
};
-&usbdrd3_1 {
- status = "okay";
- extcon = <&usbc_extcon1>;
-};
-
-&usbdrd_dwc3_1 {
- status = "okay";
- dr_mode = "host";
-};
-
&vopb {
status = "okay";
};
@@ -986,26 +693,6 @@ ap_i2c_audio: &i2c8 {
};
discrete-regulators {
- pp1500_en: pp1500-en {
- rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
- pp1800_audio_en: pp1800-audio-en {
- rockchip,pins = <RK_GPIO0 2 RK_FUNC_GPIO
- &pcfg_pull_down>;
- };
-
- pp3300_disp_en: pp3300-disp-en {
- rockchip,pins = <RK_GPIO4 27 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
- pp3000_en: pp3000-en {
- rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
sd_io_pwr_en: sd-io-pwr-en {
rockchip,pins = <RK_GPIO2 2 RK_FUNC_GPIO
&pcfg_pull_none>;
@@ -1020,11 +707,6 @@ ap_i2c_audio: &i2c8 {
rockchip,pins = <RK_GPIO4 29 RK_FUNC_GPIO
&pcfg_pull_none>;
};
-
- wlan_module_pd_l: wlan-module-pd-l {
- rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO
- &pcfg_pull_down>;
- };
};
codec {
@@ -1132,10 +814,6 @@ ap_i2c_audio: &i2c8 {
};
wifi {
- wifi_perst_l: wifi-perst-l {
- rockchip,pins = <2 27 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
wlan_module_reset_l: wlan-module-reset-l {
rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_pull_none>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: rockchip: add RK3399-Gru-Bob and prepare for Scarlet
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
So far the Gru series of ChromeOS devices has seen 3 public devices.
Two clamshell devices with the already supported Kevin and Bob
(aka Chromebook Flip C101PA), as well as one table-style device Scarlet.
So this series not only adds a devicetree file for Bob, but also prepares
for Scarlets arrival, in that common properties of the clamshell-devices
get moved into a rk3399-gru-chromebook.dtsi, similar to what we have on
RK3288-Veyron, as Scarlet does some things a bit differently.
Scarlet itself needs a bit more time, as its display is connected via
dual-dsi, where the patches are still pending.
Heiko Stuebner (4):
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate
file
arm64: dts: rockchip: add phandles to some nodes on rk3399-gru
arm64: dts: rockchip: move core edp from rk3399-kevin to shared
chromebook
arm64: dts: rockchip: add Google Bob
.../devicetree/bindings/arm/rockchip.txt | 9 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-gru-bob.dts | 79 ++++
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 399 ++++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 47 +--
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 328 +-------------
6 files changed, 496 insertions(+), 367 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
--
2.17.0
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614090733.GV10521@piout.net>
On 14/06/2018 11:07:33+0200, Alexandre Belloni wrote:
> Hi,
>
> On 14/06/2018 09:51:54+0100, Ben Whitten wrote:
>
> This need a proper commit message. Maybe you can also add a link to the
> technical brief for the platform?
>
> > Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> > arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 237 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 7e24249..1ee94ee 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> > at91sam9g25ek.dtb \
> > at91sam9g35ek.dtb \
> > at91sam9x25ek.dtb \
> > - at91sam9x35ek.dtb
> > + at91sam9x35ek.dtb \
> > + at91-wb45n.dtb
>
> The proper name for the file is <soc>-board.dtb so this should be
> at91sam9g25-wb45n.dtb.
>
Nicolas tells me that the name was right, please disregard my comment
(also on the other patches).
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v5 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for the second CA7 of the R9A06G032
as well as the default value for the "cpu-release-addr" property.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r9a06g032.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 353e06f..3e45375 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -30,6 +30,8 @@
compatible = "arm,cortex-a7";
reg = <1>;
clocks = <&sysctrl R9A06G032_CLK_A7MP>;
+ enable-method = "renesas,r9a06g032-smp";
+ cpu-release-addr = <0 0x4000c204>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
requires a special enable method to get it started.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 90 ++++++++++++++++++++++++++++++++++
2 files changed, 91 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 0000000..882a838
--- /dev/null
+++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R9A06G032 Second CA7 enabler.
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from actions,s500-smp
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!cpu_bootaddr)
+ return -ENODEV;
+
+ spin_lock(&cpu_lock);
+
+ writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *dn;
+ int ret = -EINVAL, dns;
+ u32 bootaddr;
+
+ dn = of_get_cpu_node(1, NULL);
+ if (!dn) {
+ pr_err("CPU#1: missing device tree node\n");
+ return;
+ }
+ /*
+ * Determine the address from which the CPU is polling.
+ * The bootloader *does* change this property.
+ * Note: The property can be either 64 or 32 bits, so handle both cases
+ */
+ if (of_find_property(dn, "cpu-release-addr", &dns)) {
+ if (dns == sizeof(u64)) {
+ u64 temp;
+ ret = of_property_read_u64(dn,
+ "cpu-release-addr", &temp);
+ bootaddr = temp;
+ } else
+ ret = of_property_read_u32(dn,
+ "cpu-release-addr", &bootaddr);
+ }
+ of_node_put(dn);
+ if (ret) {
+ pr_err("CPU#1: invalid cpu-release-addr property\n");
+ return;
+ }
+ pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
+
+ cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+}
+
+static const struct smp_operations r9a06g032_smp_ops __initconst = {
+ .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
+ .smp_boot_secondary = r9a06g032_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(r9a06g032_smp,
+ "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for second CA7 of the R9A06G032
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+ "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v5:
+ Fixed a couple of typos
+ Added the Reviewed-by tags where appropriate
+ Rebased on base patch v9
+ Replaced the dts property with a 64 bits one.
+ Changed the driver to support 32 or 64 bits property.
v4:
+ Geert's comments adressed.
+ Renamed symbols to r9a06g032 to match the rest of patchset
+ Rebased on base patch v8
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 2 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 90 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox