* Re: [PATCH] ARM: dts: imx6qdl-nit6xlite: Remove invalid properties
From: Shawn Guo @ 2019-08-03 12:47 UTC (permalink / raw)
To: Fabio Estevam; +Cc: gary.bisson, linux-arm-kernel
In-Reply-To: <20190725134412.7872-1-festevam@gmail.com>
On Thu, Jul 25, 2019 at 10:44:12AM -0300, Fabio Estevam wrote:
> The "vqmmc-1-8-v" and "ocr-limit" properties are not documented
> anywhere, so just remove them.
>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Bitmain changes for v5.4
From: Manivannan Sadhasivam @ 2019-08-03 12:44 UTC (permalink / raw)
To: arm, olof, arnd; +Cc: linux-arm-kernel
Hi Arnd, Olof,
Please consider pulling the Bitmain SoC changes for v5.4. These changes
are supposed to be pulled in for 5.3 but I was waiting for the common
clock driver to be reviewed (still not), hence missing the timeline.
Details of the changes are in the signed tag.
Thanks,
Mani
---
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-bitmain.git tags/bitmain-soc-5.4
for you to fetch changes up to ca33f735b1195e9bafaa66f24dec40ea666e9840:
arm64: dts: bitmain: Modify pin controller memory map (2019-08-03 17:51:21 +0530)
----------------------------------------------------------------
Bitmain SoC changes for v5.4:
Most of the basic infrastructure is completed for BM1880 SoC except
common clock support. We are still couple of patchset away from
booting a distro from eMMC/SD with mainline. Below are the changes
for this cycle:
- Added Reset controller support to BM1880 SoC based on reset-simple
driver.
- Modified pinctrl memory map for BM1880 SoC. The initial pinctrl support
included the PWM registers as a part of the pinctrl memory map. But this
turned out to be useless as PWM registers are not handling any pin muxing
at all. So removed the PWM registers from pinctrl memory map.
----------------------------------------------------------------
Manivannan Sadhasivam (2):
arm64: dts: bitmain: Add reset controller support for BM1880 SoC
arm64: dts: bitmain: Modify pin controller memory map
arch/arm64/boot/dts/bitmain/bm1880.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/9] KVM: arm64: Support stolen time reporting via shared structure
From: Marc Zyngier @ 2019-08-03 11:55 UTC (permalink / raw)
To: Steven Price
Cc: kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, linux-arm-kernel, Paolo Bonzini, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20190802145017.42543-5-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:12 +0100
Steven Price <steven.price@arm.com> wrote:
> Implement the service call for configuring a shared structre between a
structure
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space. The hypervisor then uses WRITE_ONCE() to update the shared
> structre ensuring single copy atomicity of the 64-bit unsigned value
structure
> that reports stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 13 +++++-
> arch/arm64/kvm/Kconfig | 1 +
> include/kvm/arm_hypercalls.h | 1 +
> include/linux/kvm_types.h | 2 +
> virt/kvm/arm/arm.c | 18 ++++++++
> virt/kvm/arm/hypercalls.c | 70 +++++++++++++++++++++++++++++++
> 6 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f656169db8c3..78f270190d43 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -83,6 +84,11 @@ struct kvm_arch {
>
> /* Mandated version of PSCI */
> u32 psci_version;
> +
> + struct kvm_arch_pvtime {
> + void *st;
Is it really a void *? I'm sure you can use a proper type here...
> + gpa_t st_base;
> + } pvtime;
> };
>
> #define KVM_NR_MEM_OBJS 40
> @@ -338,8 +344,13 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
> * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + } steal;
> +};
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 35a5abcc4ca3..9f0710ab4292 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -7,6 +7,7 @@
> #include <asm/kvm_emulate.h>
>
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> {
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -35,6 +35,8 @@ typedef unsigned long gva_t;
> typedef u64 gpa_t;
> typedef u64 gfn_t;
>
> +#define GPA_INVALID (~(gpa_t)0)
> +
> typedef unsigned long hva_t;
> typedef u64 hpa_t;
> typedef u64 hfn_t;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index f645c0fbf7ec..ebd963d2580b 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -40,6 +40,10 @@
> #include <asm/kvm_coproc.h>
> #include <asm/sections.h>
>
> +#include <kvm/arm_hypercalls.h>
> +#include <kvm/arm_pmu.h>
> +#include <kvm/arm_psci.h>
> +
> #ifdef REQUIRES_VIRT
> __asm__(".arch_extension virt");
> #endif
> @@ -135,6 +139,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = vgic_present ?
> kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
>
> + kvm->arch.pvtime.st_base = GPA_INVALID;
> return ret;
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> @@ -371,6 +376,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vcpu_load_sysregs(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> + kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
>
> if (single_task_running())
> vcpu_clear_wfe_traps(vcpu);
> @@ -617,6 +623,15 @@ static void vcpu_req_sleep(struct kvm_vcpu *vcpu)
> smp_rmb();
> }
>
> +static void vcpu_req_record_steal(struct kvm_vcpu *vcpu)
> +{
> + int idx;
> +
> + idx = srcu_read_lock(&vcpu->kvm->srcu);
> + kvm_update_stolen_time(vcpu);
> + srcu_read_unlock(&vcpu->kvm->srcu, idx);
> +}
> +
> static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
> {
> return vcpu->arch.target >= 0;
> @@ -636,6 +651,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> * that a VCPU sees new virtual interrupts.
> */
> kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> +
> + if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
> + vcpu_req_record_steal(vcpu);
> }
> }
>
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index 2906b2df99df..196c71c8dd87 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -10,6 +10,70 @@
> #include <kvm/arm_hypercalls.h>
> #include <kvm/arm_psci.h>
>
> +
> +static struct pvclock_vcpu_stolen_time_info *pvtime_get_st(
> + struct kvm_vcpu *vcpu)
nit: on a single line.
> +{
> + struct pvclock_vcpu_stolen_time_info *st = vcpu->kvm->arch.pvtime.st;
> +
> + if (!st)
> + return NULL;
> +
> + return &st[kvm_vcpu_get_idx(vcpu)];
> +}
> +
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + u64 steal;
> + struct pvclock_vcpu_stolen_time_info *kaddr;
> +
> + if (vcpu->kvm->arch.pvtime.st_base == GPA_INVALID)
> + return -ENOTSUPP;
So for a guest that doesn't have stolen time support (which is 100% of
them for the foreseeable future), we still set a request, take the srcu
lock and end-up here for nothing. I'd rather we test this st_base
early, as it should never change once the guest has started.
> +
> + kaddr = pvtime_get_st(vcpu);
> +
> + if (!kaddr)
> + return -ENOTSUPP;
How can this happen?
> +
> + kaddr->revision = 0;
> + kaddr->attributes = 0;
Why does this need to be written each time we update the stolen time? I
have the feeling this would be better moved to the hypercall
initializing the data structure.
> +
> + /* Let's do the local bookkeeping */
> + steal = vcpu->arch.steal.steal;
> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> + vcpu->arch.steal.steal = steal;
> +
> + /* Now write out the value to the shared page */
> + WRITE_ONCE(kaddr->stolen_time, cpu_to_le64(steal));
Is there any requirement for this to be visible to another CPU than the
one this is being written from?
> +
> + return 0;
> +}
> +
> +static int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + u64 ret;
> + int err;
> +
> + /*
> + * Start counting stolen time from the time the guest requests
> + * the feature enabled.
> + */
> + vcpu->arch.steal.steal = 0;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> +
> + err = kvm_update_stolen_time(vcpu);
> +
> + if (err)
> + ret = SMCCC_RET_NOT_SUPPORTED;
> + else
> + ret = vcpu->kvm->arch.pvtime.st_base +
> + (sizeof(struct pvclock_vcpu_stolen_time_info) *
> + kvm_vcpu_get_idx(vcpu));
> +
> + smccc_set_retval(vcpu, ret, 0, 0, 0);
> + return 1;
> +}
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> u32 func_id = smccc_get_function(vcpu);
> @@ -57,8 +121,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_HV_PV_FEATURES:
> feature = smccc_get_arg1(vcpu);
> switch (feature) {
> + case ARM_SMCCC_HV_PV_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + val = SMCCC_RET_SUCCESS;
> + break;
> }
> break;
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + return kvm_hypercall_stolen_time(vcpu);
> default:
> return kvm_psci_call(vcpu);
> }
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Andy Yan @ 2019-08-03 11:46 UTC (permalink / raw)
To: heiko
Cc: devicetree, Andy Yan, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
Leez P710 is a RK3399 based SBC, designed by Leez team
from lenovo [0].
Specification
- Rockchip RK3399
- 4/2GB LPDDR4
- TF sd scard slot
- eMMC
- M.2 B-Key for 4G LTE
- AP6256 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- TYPE-C Power supply
[0] https://leez.lenovo.com
Signed-off-by: Andy Yan <andyshrk@gmail.com>
---
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-leez-p710.dts | 635 ++++++++++++++++++
3 files changed, 641 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 34865042f4e4..da9cd947abfa 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -329,6 +329,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Leez RK3399 P710
+ items:
+ - const: leez,p710
+ - const: rockchip,rk3399
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index daa2c78e22c3..1f18a9392d15 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
new file mode 100644
index 000000000000..b342f5e8692b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -0,0 +1,635 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Andy Yan <andy.yan@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Leez RK3399 P710";
+ compatible = "leez,p710", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
+ dc5v_adp: dc-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc5v_adapter";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc5v0_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc5v_adp>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc_lan: vcc3v3-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_lan";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc5v0_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_1v8>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-name = "vcc1v8_dvp";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcc1v8_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8: LDO_REG3 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-name = "vcca3v0_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcc0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcc0v9_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ };
+ };
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel1_gpio>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator@41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel2_gpio>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c1 {
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c3 {
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c4 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ status = "okay";
+};
+
+&i2s1 {
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ status = "okay";
+};
+
+&i2s2 {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_dvp>;
+ audio-supply = <&vcc_1v8>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+ status = "okay";
+ pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+ bt {
+ bt_enable_h: bt-enable-h {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_host_wake_l: bt-host-wake-l {
+ rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <2 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins =
+ <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_host_wake_l: wifi-host-wake-l {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+
+ vref-supply = <&vcc_1v8>;
+};
+
+&sdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ clock-frequency = <50000000>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_l>;
+ };
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cd &sdmmc_cmd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+};
+
+&tcphy0 {
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_enable_h>;
+ };
+};
+
+&uart2 {
+ 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";
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+ dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Takashi Iwai @ 2019-08-03 11:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linux-m68k,
Robin Murphy, x86, linux-kernel, iommu, linuxppc-dev,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] KVM: arm64: Implement PV_FEATURES call
From: Marc Zyngier @ 2019-08-03 11:21 UTC (permalink / raw)
To: Steven Price
Cc: kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, linux-arm-kernel, Paolo Bonzini, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20190802145017.42543-4-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:11 +0100
Steven Price <steven.price@arm.com> wrote:
> This provides a mechanism for querying which paravirtualized features
> are available in this hypervisor.
>
> Also add the header file which defines the ABI for the paravirtualized
> clock features we're about to add.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/pvclock-abi.h | 20 ++++++++++++++++++++
> include/linux/arm-smccc.h | 14 ++++++++++++++
> virt/kvm/arm/hypercalls.c | 9 +++++++++
> 3 files changed, 43 insertions(+)
> create mode 100644 arch/arm64/include/asm/pvclock-abi.h
>
> diff --git a/arch/arm64/include/asm/pvclock-abi.h b/arch/arm64/include/asm/pvclock-abi.h
> new file mode 100644
> index 000000000000..1f7cdc102691
> --- /dev/null
> +++ b/arch/arm64/include/asm/pvclock-abi.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2019 Arm Ltd. */
> +
> +#ifndef __ASM_PVCLOCK_ABI_H
> +#define __ASM_PVCLOCK_ABI_H
> +
> +/* The below structures and constants are defined in ARM DEN0057A */
> +
> +struct pvclock_vcpu_stolen_time_info {
> + __le32 revision;
> + __le32 attributes;
> + __le64 stolen_time;
> + /* Structure must be 64 byte aligned, pad to that size */
> + u8 padding[48];
> +} __packed;
> +
> +#define PV_VM_TIME_NOT_SUPPORTED -1
Isn't the intent for this to be the same value as
SMCCC_RET_NOT_SUPPORTED?
> +#define PV_VM_TIME_INVALID_PARAMETERS -2
It overlaps with SMCCC_RET_NOT_REQUIRED. Is that a problem? Should we
consider a spec change for this?
> +
> +#endif
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 080012a6f025..e7f129f26ebd 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -45,6 +45,7 @@
> #define ARM_SMCCC_OWNER_SIP 2
> #define ARM_SMCCC_OWNER_OEM 3
> #define ARM_SMCCC_OWNER_STANDARD 4
> +#define ARM_SMCCC_OWNER_STANDARD_HYP 5
> #define ARM_SMCCC_OWNER_TRUSTED_APP 48
> #define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
> #define ARM_SMCCC_OWNER_TRUSTED_OS 50
> @@ -302,5 +303,18 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
> #define SMCCC_RET_NOT_SUPPORTED -1
> #define SMCCC_RET_NOT_REQUIRED -2
>
> +/* Paravirtualised time calls (defined by ARM DEN0057A) */
> +#define ARM_SMCCC_HV_PV_FEATURES \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_STANDARD_HYP, \
> + 0x20)
> +
> +#define ARM_SMCCC_HV_PV_TIME_ST \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_STANDARD_HYP, \
> + 0x22)
> +
> #endif /*__ASSEMBLY__*/
> #endif /*__LINUX_ARM_SMCCC_H*/
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index f875241bd030..2906b2df99df 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -5,6 +5,7 @@
> #include <linux/kvm_host.h>
>
> #include <asm/kvm_emulate.h>
> +#include <asm/pvclock-abi.h>
>
> #include <kvm/arm_hypercalls.h>
> #include <kvm/arm_psci.h>
> @@ -48,6 +49,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> break;
> }
> break;
> + case ARM_SMCCC_HV_PV_FEATURES:
> + val = SMCCC_RET_SUCCESS;
> + break;
> + }
> + break;
> + case ARM_SMCCC_HV_PV_FEATURES:
> + feature = smccc_get_arg1(vcpu);
> + switch (feature) {
> }
> break;
> default:
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/9] KVM: arm64: Document PV-time interface
From: Marc Zyngier @ 2019-08-03 11:13 UTC (permalink / raw)
To: Steven Price
Cc: peter.maydell, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, linux-arm-kernel, Paolo Bonzini, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20190802145017.42543-2-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:09 +0100
Steven Price <steven.price@arm.com> wrote:
[+Peter for the userspace aspect of things]
Hi Steve,
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time" have not been fully agreed.
>
> User space can specify a reserved area of memory for the guest and
> inform KVM to populate the memory with information on time that the host
> kernel has stolen from the guest.
>
> A hypercall interface is provided for the guest to interrogate the
> hypervisor's support for this interface and the location of the shared
> memory structures.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virtual/kvm/arm/pvtime.txt | 107 +++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
> create mode 100644 Documentation/virtual/kvm/arm/pvtime.txt
>
> diff --git a/Documentation/virtual/kvm/arm/pvtime.txt b/Documentation/virtual/kvm/arm/pvtime.txt
> new file mode 100644
> index 000000000000..e6ae9799e1d5
> --- /dev/null
> +++ b/Documentation/virtual/kvm/arm/pvtime.txt
> @@ -0,0 +1,107 @@
> +Paravirtualized time support for arm64
> +======================================
> +
> +Arm specification DEN0057/A defined a standard for paravirtualised time
> +support for Aarch64 guests:
nit: AArch64
> +
> +https://developer.arm.com/docs/den0057/a
Between this file and the above document, which one is authoritative?
> +
> +KVM/Arm64 implements the stolen time part of this specification by providing
nit: KVM/arm64
> +some hypervisor service calls to support a paravirtualized guest obtaining a
> +view of the amount of time stolen from its execution.
> +
> +Two new SMCCC compatible hypercalls are defined:
> +
> +PV_FEATURES 0xC5000020
> +PV_TIME_ST 0xC5000022
> +
> +These are only available in the SMC64/HVC64 calling convention as
> +paravirtualized time is not available to 32 bit Arm guests.
> +
> +PV_FEATURES
> + Function ID: (uint32) : 0xC5000020
> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> + PV-time feature is supported by the hypervisor.
How is PV_FEATURES discovered? Is the intention to make it a generic
ARM-wide PV discovery mechanism, not specific to PV time?
> +
> +PV_TIME_ST
> + Function ID: (uint32) : 0xC5000022
> + Return value: (int64) : IPA of the stolen time data structure for this
> + (V)CPU. On failure:
> + NOT_SUPPORTED (-1)
> +
Is the size implicit? What are the memory attributes? This either needs
documenting here, or point to the right bit to the spec.
> +Stolen Time
> +-----------
> +
> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> +
> + Field | Byte Length | Byte Offset | Description
> + ----------- | ----------- | ----------- | --------------------------
> + Revision | 4 | 0 | Must be 0 for version 0.1
> + Attributes | 4 | 4 | Must be 0
> + Stolen time | 8 | 8 | Stolen time in unsigned
> + | | | nanoseconds indicating how
> + | | | much time this VCPU thread
> + | | | was involuntarily not
> + | | | running on a physical CPU.
> +
> +The structure will be updated by the hypervisor periodically as time is stolen
Is it really periodic? If so, when is the update frequency?
> +from the VCPU. It will be present within a reserved region of the normal
> +memory given to the guest. The guest should not attempt to write into this
> +memory. There is a structure by VCPU of the guest.
What if the vcpu writes to it? Does it get a fault? If there is a
structure per vcpu, what is the layout in memory? How does a vcpu find
its own data structure? Is that the address returned by PV_TIME_ST?
> +
> +User space interface
> +====================
> +
> +User space can request that KVM provide the paravirtualized time interface to
> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> +
> + struct kvm_create_device pvtime_device = {
> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> + .attr = 0,
> + .flags = 0,
> + };
> +
> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> +
> +The guest IPA of the structures must be given to KVM. This is the base address
nit: s/guest //
> +of an array of stolen time structures (one for each VCPU). For example:
> +
> + struct kvm_device_attr st_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_ST,
> + .addr = (u64)(unsigned long)&st_paddr
> + };
> +
> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
So the allocation itself is performed by the kernel? What are the
ordering requirements between creating vcpus and the device? What are
the alignment requirements for the base address?
> +
> +For migration (or save/restore) of a guest it is necessary to save the contents
> +of the shared page(s) and later restore them. KVM_DEV_ARM_PV_TIME_STATE_SIZE
> +provides the size of this data and KVM_DEV_ARM_PV_TIME_STATE allows the state
> +to be read/written.
Is the size variable depending on the number of vcpus?
> +
> +It is also necessary for the physical address to be set identically when
> +restoring.
> +
> + void *save_state(int fd, u64 attr, u32 *size) {
> + struct kvm_device_attr get_size = {
> + .group = KVM_DEV_ARM_PV_TIME_STATE_SIZE,
> + .attr = attr,
> + .addr = (u64)(unsigned long)size
> + };
> +
> + ioctl(fd, KVM_GET_DEVICE_ATTR, get_size);
> +
> + void *buffer = malloc(*size);
> +
> + struct kvm_device_attr get_state = {
> + .group = KVM_DEV_ARM_PV_TIME_STATE,
> + .attr = attr,
> + .addr = (u64)(unsigned long)size
> + };
> +
> + ioctl(fd, KVM_GET_DEVICE_ATTR, buffer);
> + }
> +
> + void *st_state = save_state(pvtime_fd, KVM_DEV_ARM_PV_TIME_ST, &st_size);
> +
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Christoph Hellwig @ 2019-08-03 10:30 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linux-m68k,
Robin Murphy, x86, linux-kernel, iommu, linuxppc-dev,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <s5hh870rn4t.wl-tiwai@suse.de>
On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> I wasn't careful enough to look at that change, sorry.
>
> The code there tries to check whether dma_mmap_coherent() would always
> fail on some platforms. Then the driver clears the mmap capability
> flag at the device open time and notifies user-space to fall back to
> the dumb read/write mode.
>
> So I'm afraid that simply dropping the check would cause the behavior
> regression, e.g. on PARISC.
>
> Is there any simple way to test whether dma_mmap_coherent() would work
> or not in general on the target platform? It's not necessarily in an
> ifdef at all.
This isn't really a platform, but a per-device question. I can add a
"bool dma_can_mmap(struct device *dev)" helper to check that. But how
do I get at a suitable struct device in hw_support_mmap()?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mm: Fix boot hang at clk init
From: Shawn Guo @ 2019-08-03 10:29 UTC (permalink / raw)
To: Leonard Crestez
Cc: Dong Aisheng, Abel Vesa, Stephen Boyd, Michael Turquette,
Jacky Bai, linux-imx, kernel, Fabio Estevam, Daniel Baluta,
linux-clk, linux-arm-kernel, Li Jun
In-Reply-To: <718c781b77081d6974fd91d5dff7b0f8737757b0.1564048197.git.leonard.crestez@nxp.com>
On Thu, Jul 25, 2019 at 12:50:53PM +0300, Leonard Crestez wrote:
> The assigned-clock-rates property is incorrect (4 elements while
> assigned-clocks has length 5) and boot hangs while assigning some
> unexpected rates.
>
> Fix by inserting another <400000000>, the intention is to assign both
> IMX8MM_CLK_AUDIO_AHB and IMX8MM_CLK_IPG_AUDIO_ROOT 400mhz.
>
> Fixes: df1703896a17 ("arm64: dts: imx8mm: Init rates and parents configs for clocks")
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> ---
> Changes since v1:
> * Insert and 400mhz instead of <0>
> Link to v1: https://patchwork.kernel.org/patch/11057515/
>
> Should probably be squashed into df1703896a17
Done, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kvm-unit-tests: psci_cpu_on_test FAILed
From: Marc Zyngier @ 2019-08-03 10:10 UTC (permalink / raw)
To: Zenghui Yu
Cc: drjones, kvm, suzuki.poulose, James Morse, linux-arm-kernel,
Wanghaibin (D), kvmarm, julien.thierry.kdev
In-Reply-To: <f58de1d7-a6ca-bd6d-8423-01d27326e078@huawei.com>
On Sat, 3 Aug 2019 17:27:41 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
> Hi Marc,
>
> On 2019/8/2 23:56, Marc Zyngier wrote:
> > On 02/08/2019 11:56, Zenghui Yu wrote:
> >> Hi folks,
> >>
> >> Running kvm-unit-tests with Linux 5.3.0-rc2 on Kunpeng 920, we will get
> >> the following fail info:
> >>
> >> [...]
> >> FAIL psci (4 tests, 1 unexpected failures)
> >> [...]
> >> and
> >> [...]
> >> INFO: unexpected cpu_on return value: caller=CPU9, ret=-2
> >> FAIL: cpu-on
> >> SUMMARY: 4 tests, 1 unexpected failures
> >>
> >>
> >> I think this is an issue had been fixed once by commit 6c7a5dce22b3
> >> ("KVM: arm/arm64: fix races in kvm_psci_vcpu_on"), which makes use of
> >> kvm->lock mutex to fix the race between two PSCI_CPU_ON calls - one
> >> does reset on the MPIDR register whilst another reads it.
> >>
> >> But commit 358b28f09f0 ("arm/arm64: KVM: Allow a VCPU to fully reset
> >> itself") later moves the reset work into check_vcpu_requests(), by
> >> making a KVM_REQ_VCPU_RESET request in PSCI code. Thus the reset work
> >> has not been protected by kvm->lock mutex anymore, and the race shows up
> >> again...
> >>
> >> Do we need a fix for this issue? At least achieve a mutex execution
> >> between the reset of MPIDR and kvm_mpidr_to_vcpu()?
> >
> > The thing is that the way we reset registers is marginally insane.
> > Yes, it catches most reset bugs. It also introduces many more in
> > the rest of the paths.
> >
> > The fun part is that there is hardly a need for resetting MPIDR.
> > It has already been set when we've created the vcpu. It is the
>
> (That means we can let reset_mpidr() do nothing?)
It should ever be only written once, as MPIDR is a constant from the
guest perspective. So it is not that it can do nothing. It is just that
there should never be any other value written to it.
>
> > poisoning of the sysreg array that creates a situation where
> > the MPIDR is temporarily invalid.
> >
> > So instead of poisoning the array, how about we just keep
> > track of the registers for which we've called a reset function?
> > It should be enough to track the most obvious bugs... I've
>
> The reset of DBG{BCR,BVR,WVR,WCR}n_EL1 registers will also be tracked.
> It may affect our judgment?
How so?
>
> > cobbled the following patch together, which seems to fix the
> > issue on my TX2 with 64 vcpus.
> >
> > Thoughts?
> >
> > M.
> >
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index f26e181d881c..17f46ee7dc83 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -2254,13 +2254,17 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
> > }
> > > static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
> > - const struct sys_reg_desc *table, size_t num)
> > + const struct sys_reg_desc *table, size_t num,
> > + unsigned long *bmap)
> > {
> > unsigned long i;
> > > for (i = 0; i < num; i++)
> > - if (table[i].reset)
> > + if (table[i].reset) {
> > table[i].reset(vcpu, &table[i]);
> > + if (bmap)
> > + set_bit(i, bmap);
>
> I think this should be:
> set_bit(table[i].reg, bmap);
>
> Am I wrong?
No, you're absolutely right.
>
> > + }
> > }
> > > /**
> > @@ -2772,21 +2776,23 @@ void kvm_sys_reg_table_init(void)
> > */
> > void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
> > {
> > + unsigned long *bmap;
> > size_t num;
> > const struct sys_reg_desc *table;
> > > - /* Catch someone adding a register without putting in reset entry. */
> > - memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
> > + bmap = bitmap_alloc(NR_SYS_REGS, GFP_KERNEL);
>
> LOCKDEP kernel will be not happy with this bitmap_alloc:
>
> " BUG: sleeping function called from invalid context at mm/slab.h:501
> in_atomic(): 1, irqs_disabled(): 0, pid: 8710, name: qemu-system-aar "
Well spotted. I guess GFP_ATOMIC is in order.
>
> > > /* Generic chip reset first (so target could override). */
> > - reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> > + reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs), bmap);
> > > table = get_target_table(vcpu->arch.target, true, &num);
> > - reset_sys_reg_descs(vcpu, table, num);
> > + reset_sys_reg_descs(vcpu, table, num, bmap);
> > > for (num = 1; num < NR_SYS_REGS; num++) {
> > - if (WARN(__vcpu_sys_reg(vcpu, num) == 0x4242424242424242,
> > + if (WARN(bmap && !test_bit(num, bmap),
> > "Didn't reset __vcpu_sys_reg(%zi)\n", num))
> > break;
> > }
> > +
> > + kfree(bmap);
> > }
> >
> >
>
> Some other minor questions about the sys reg resetting:
> 1. Pointer Authentication Registers haven't have reset entry yet,
> do they need? The same for ACTLR_EL1.
Pointer auth registers definitely have a reset function, set to
reset_unknown. So does ACTLR_EL1, which resets to the host's value.
> 2. Why does PMCR_EL0 register have no "reg" field, in sys_reg_descs[]?
This looks like a (very minor) bug. reset_pmcr writes directly to the
PMCR_EL0 shadow register without using r->reg as the register number.
But in the light of the reset tracking we want to add, this needs
fixing.
> I will test this patch with kvm-unit-tests next week!
Well, wait until I repost something a bit less buggy...
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
From: Linus Walleij @ 2019-08-03 9:51 UTC (permalink / raw)
To: Fabian Vogt; +Cc: Daniel Tang, open list:DRM PANEL DRIVERS, Linux ARM
In-Reply-To: <12154694.e2V3OH3Rcx@linux-e202.suse.de>
On Thu, Jul 25, 2019 at 9:26 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> On a real CX the LCD displays shows content without
> any other changes to the set, but has a ~3Hz pulsating effect scrolling from
> the top to the bottom and the gray text changes color slightly.
So you mean something meaningful appears in the LCD
but there are visual disturbances?
> Without the patchset applied everything looks perfectly.
>
> I tried setting vrefresh to 20, fb_bpp to 16 and forcing an inverted panel
> clock, but the pulsing didn't change.
>
> Using the emulated CX I compared the contents of the registers and found
> that only the IPC bit (which I tried to set, so that's likely not it) and
> the interrupt registers have a different content.
>
> Any idea?
I think it's the clock settings in patch 2/3.
I just set them to "1000" (1MHz since its in kHz) based on some
educated guesses.
The old driver set the clock to "1" (kHz) so just try that first,
maybe it is really that slow.
It's just that the old driver also set refres to 60 fps which doesn't
add up, but I think that setting is simply ignored and that is why
it works.
Yours,
Linus Walleij
Yours,
Linus Walleij
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Linus Walleij @ 2019-08-03 9:42 UTC (permalink / raw)
To: Timur Tabi
Cc: Kernel Build Reports Mailman List, Jeffrey Hugo, Lina Iyer,
Stephen Boyd, Mark Brown, Bjorn Andersson, Lee Jones, Linux ARM
In-Reply-To: <e974aa7e-98d4-1594-755b-6f57ab852cd7@kernel.org>
On Fri, Aug 2, 2019 at 4:51 AM Timur Tabi <timur@kernel.org> wrote:
> On 7/31/19 12:58 PM, Jeffrey Hugo wrote:
> >
> > static int gpiochip_alloc_valid_mask(struct gpio_chip *gc)
> > {
> > if (IS_ENABLED(CONFIG_OF_GPIO))
> > gc->need_valid_mask = of_gpio_need_valid_mask(gc);
> > if (!gc->need_valid_mask)
> > return 0;
>
> So this seems wrong on a system with OF and ACPI. It assumes that OF
> takes priority over ACPI if both are enabled, and that's not true in
> general. If anything, it's the other way around.
>
> IS_ENABLED(CONFIG_OF_GPIO) is not the correct test to see if OF should
> be used. I think this should be replaced with the OF equivalent of
> has_acpi_companion(), but even that might not be enough. Basically,
> of_gpio_need_valid_mask() should return three values, 0 = don't need it,
> 1 = does need it, -1 = gpio info is not in OF.
You're absolutely right.
Sboyd hacked up a patch to that effect and I applied it.
I haven't heard if QDF2400 is working again but I'd love to know!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kvm-unit-tests: psci_cpu_on_test FAILed
From: Zenghui Yu @ 2019-08-03 9:27 UTC (permalink / raw)
To: Marc Zyngier, drjones, James Morse, julien.thierry.kdev,
suzuki.poulose
Cc: linux-arm-kernel, Wanghaibin (D), kvmarm, kvm
In-Reply-To: <48a18685-ee81-83a7-9eea-63fe26690903@kernel.org>
Hi Marc,
On 2019/8/2 23:56, Marc Zyngier wrote:
> On 02/08/2019 11:56, Zenghui Yu wrote:
>> Hi folks,
>>
>> Running kvm-unit-tests with Linux 5.3.0-rc2 on Kunpeng 920, we will get
>> the following fail info:
>>
>> [...]
>> FAIL psci (4 tests, 1 unexpected failures)
>> [...]
>> and
>> [...]
>> INFO: unexpected cpu_on return value: caller=CPU9, ret=-2
>> FAIL: cpu-on
>> SUMMARY: 4 tests, 1 unexpected failures
>>
>>
>> I think this is an issue had been fixed once by commit 6c7a5dce22b3
>> ("KVM: arm/arm64: fix races in kvm_psci_vcpu_on"), which makes use of
>> kvm->lock mutex to fix the race between two PSCI_CPU_ON calls - one
>> does reset on the MPIDR register whilst another reads it.
>>
>> But commit 358b28f09f0 ("arm/arm64: KVM: Allow a VCPU to fully reset
>> itself") later moves the reset work into check_vcpu_requests(), by
>> making a KVM_REQ_VCPU_RESET request in PSCI code. Thus the reset work
>> has not been protected by kvm->lock mutex anymore, and the race shows up
>> again...
>>
>> Do we need a fix for this issue? At least achieve a mutex execution
>> between the reset of MPIDR and kvm_mpidr_to_vcpu()?
>
> The thing is that the way we reset registers is marginally insane.
> Yes, it catches most reset bugs. It also introduces many more in
> the rest of the paths.
>
> The fun part is that there is hardly a need for resetting MPIDR.
> It has already been set when we've created the vcpu. It is the
(That means we can let reset_mpidr() do nothing?)
> poisoning of the sysreg array that creates a situation where
> the MPIDR is temporarily invalid.
>
> So instead of poisoning the array, how about we just keep
> track of the registers for which we've called a reset function?
> It should be enough to track the most obvious bugs... I've
The reset of DBG{BCR,BVR,WVR,WCR}n_EL1 registers will also be tracked.
It may affect our judgment?
> cobbled the following patch together, which seems to fix the
> issue on my TX2 with 64 vcpus.
>
> Thoughts?
>
> M.
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index f26e181d881c..17f46ee7dc83 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2254,13 +2254,17 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
> }
>
> static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
> - const struct sys_reg_desc *table, size_t num)
> + const struct sys_reg_desc *table, size_t num,
> + unsigned long *bmap)
> {
> unsigned long i;
>
> for (i = 0; i < num; i++)
> - if (table[i].reset)
> + if (table[i].reset) {
> table[i].reset(vcpu, &table[i]);
> + if (bmap)
> + set_bit(i, bmap);
I think this should be:
set_bit(table[i].reg, bmap);
Am I wrong?
> + }
> }
>
> /**
> @@ -2772,21 +2776,23 @@ void kvm_sys_reg_table_init(void)
> */
> void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
> {
> + unsigned long *bmap;
> size_t num;
> const struct sys_reg_desc *table;
>
> - /* Catch someone adding a register without putting in reset entry. */
> - memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
> + bmap = bitmap_alloc(NR_SYS_REGS, GFP_KERNEL);
LOCKDEP kernel will be not happy with this bitmap_alloc:
" BUG: sleeping function called from invalid context at mm/slab.h:501
in_atomic(): 1, irqs_disabled(): 0, pid: 8710, name: qemu-system-aar "
>
> /* Generic chip reset first (so target could override). */
> - reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> + reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs), bmap);
>
> table = get_target_table(vcpu->arch.target, true, &num);
> - reset_sys_reg_descs(vcpu, table, num);
> + reset_sys_reg_descs(vcpu, table, num, bmap);
>
> for (num = 1; num < NR_SYS_REGS; num++) {
> - if (WARN(__vcpu_sys_reg(vcpu, num) == 0x4242424242424242,
> + if (WARN(bmap && !test_bit(num, bmap),
> "Didn't reset __vcpu_sys_reg(%zi)\n", num))
> break;
> }
> +
> + kfree(bmap);
> }
>
>
Some other minor questions about the sys reg resetting:
1. Pointer Authentication Registers haven't have reset entry yet,
do they need? The same for ACTLR_EL1.
2. Why does PMCR_EL0 register have no "reg" field, in sys_reg_descs[]?
I will test this patch with kvm-unit-tests next week!
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: imx8mn: Keep uart clocks on for early console
From: Shawn Guo @ 2019-08-03 9:04 UTC (permalink / raw)
To: Anson.Huang
Cc: sboyd, mturquette, linux-kernel, linux-clk, Linux-imx, kernel,
festevam, s.hauer, linux-arm-kernel
In-Reply-To: <20190724075017.11003-1-Anson.Huang@nxp.com>
On Wed, Jul 24, 2019 at 03:50:17PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Call imx_register_uart_clocks() API to keep uart clocks enabled
> when earlyprintk or earlycon is active.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: dts: mmp2: devicetree updates
From: Pavel Machek @ 2019-08-03 8:59 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
[-- Attachment #1.1: Type: text/plain, Size: 606 bytes --]
On Fri 2019-08-02 12:33:20, Lubomir Rintel wrote:
> Hi,
>
> Here's a couple of updates for the MMP2 SoC devicetree files.
>
> The only change from the last submission is the addition of the
> OLPC XO 1.75 dts file. Apart from that one, the patches are
> independent of each other, can be applied in any order.
>
> Hopefully I'm sending the patch set in the correct direction.
For the series:
Acked-by: Pavel Machek <pavel@ucw.cz>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] ARM: dts: mmp2: add OLPC XO 1.75 machine
From: Pavel Machek @ 2019-08-03 8:58 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20190802103326.531250-7-lkundrak@v3.sk>
[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]
On Fri 2019-08-02 12:33:26, Lubomir Rintel wrote:
> This is a fairly complete description of an OLPC XO 1.75 laptop.
> What's missing for now is the GPU, LCD controller, DCON, the panel and
> audio.
Ok, but I need GPU/LCD/panel... that's my only output. Is video
expected to work in 5.2? Does the firmware pass right device tree,
including the GPU/LCD/DCON?
Is there config somewhere I could use?
Thanks a lot,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: imx: Remove unused function statement
From: Shawn Guo @ 2019-08-03 8:58 UTC (permalink / raw)
To: Anson.Huang
Cc: aisheng.dong, abel.vesa, sboyd, mturquette, linux-kernel,
linux-clk, ping.bai, Linux-imx, kernel, festevam, s.hauer,
linux-arm-kernel, l.stach
In-Reply-To: <20190724062435.28074-1-Anson.Huang@nxp.com>
On Wed, Jul 24, 2019 at 02:24:35PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> imx_register_uart_clocks_hws() function is NOT implemented
> at all, remove it.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: imx7ulp: Make sure earlycon's clock is enabled
From: Shawn Guo @ 2019-08-03 8:57 UTC (permalink / raw)
To: Anson.Huang
Cc: aisheng.dong, gustavo, sboyd, mturquette, linux-kernel, linux-clk,
Linux-imx, kernel, festevam, s.hauer, linux-arm-kernel
In-Reply-To: <20190724030600.17839-1-Anson.Huang@nxp.com>
On Wed, Jul 24, 2019 at 11:06:00AM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Earlycon's clock could be disabled during kernel boot up,
> if earlycon is enabled and its clock is gated, then kernel
> boot up will fail. Make sure earlycon's clock is enabled
> during kernel boot up.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] tracing: Function stack size and its name mismatch in arm64
From: Joel Fernandes @ 2019-08-03 8:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, Catalin Marinas, Will Deacon, LKML, Ingo Molnar,
kernel-team, moderated list:ARM/STM32 ARCHITECTURE
In-Reply-To: <20190803082642.GA224541@google.com>
On Sat, Aug 3, 2019 at 4:26 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
> [snip]
> > > There is not PC in ARM64 stack, LR is used to for walk_stackframe in
> > > ARM64. Tere is no the issue in ARM32 because there is PC in ARM32 stack.
> > > PC is used to calculate the stack size in trace_stack.c, so the
> > > function name and its stack size appear to be off-by-one.
> > > ARM64 stack layout:
> > > LR
> > > FP
> > > ......
> > > LR
> > > FP
> > > ......
> >
> > I think you are not explaining the issue correctly. From looking at the
> > document, I think what you want to say is that the LR is saved *after*
> > the data for the function. Is that correct? If so, then yes, it would
> > cause the stack tracing algorithm to be incorrect.
> >
> > Most archs do this:
> >
> > On entry to a function:
> >
> > save return address
> > reserve local variables and such for current function
> >
> > I think you are saying that arm64 does this backwards.
> >
> > reserve local variables and such for current function
> > save return address (LR)
>
> Actually for arm64 it is like what you said about 'Most archs'. It saves FP
> and LR first onto the current stack frame, then assigns the top of the stack
> to FP (marking the new frame). Then executes branch-link, and then allocates
> space to variables on stack in the callee.
Just to add to that, when the branch-link (BL) instruction is
executed, the Link Register (LR) will contain the return address. This
why the existing LR needs to be saved first before the call. The
existing LR will contain the return address of the caller's original
caller.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] tracing: Function stack size and its name mismatch in arm64
From: Joel Fernandes @ 2019-08-03 8:26 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
kernel-team, linux-arm-kernel
In-Reply-To: <20190802112259.0530a648@gandalf.local.home>
On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
[snip]
> > There is not PC in ARM64 stack, LR is used to for walk_stackframe in
> > ARM64. Tere is no the issue in ARM32 because there is PC in ARM32 stack.
> > PC is used to calculate the stack size in trace_stack.c, so the
> > function name and its stack size appear to be off-by-one.
> > ARM64 stack layout:
> > LR
> > FP
> > ......
> > LR
> > FP
> > ......
>
> I think you are not explaining the issue correctly. From looking at the
> document, I think what you want to say is that the LR is saved *after*
> the data for the function. Is that correct? If so, then yes, it would
> cause the stack tracing algorithm to be incorrect.
>
> Most archs do this:
>
> On entry to a function:
>
> save return address
> reserve local variables and such for current function
>
> I think you are saying that arm64 does this backwards.
>
> reserve local variables and such for current function
> save return address (LR)
Actually for arm64 it is like what you said about 'Most archs'. It saves FP
and LR first onto the current stack frame, then assigns the top of the stack
to FP (marking the new frame). Then executes branch-link, and then allocates
space to variables on stack in the callee.
Disassembly of prog:
int foo(int x, int y) {
int a[32];
return (x + y + a[31]);
}
int bar(void) {
foo(1, 2);
}
confirms it:
000000000000073c <bar>:
73c: a9bf7bfd stp x29, x30, [sp, #-16]! <-- save FP and LR
740: 910003fd mov x29, sp <-- create new FP
744: 52800041 mov w1, #0x2 <-- pass arguments
748: 52800020 mov w0, #0x1
74c: 97fffff4 bl 71c <foo> <-- branch (sets LR)
750: d503201f nop
754: a8c17bfd ldp x29, x30, [sp], #16 <-- restore FP, LR
758: d65f03c0 ret
000000000000071c <foo>:
71c: d10243ff sub sp, sp, #0x90 <-- space for local var
720: b9000fe0 str w0, [sp, #12]
724: b9000be1 str w1, [sp, #8]
728: b9400fe1 ldr w1, [sp, #12]
72c: b9400be0 ldr w0, [sp, #8]
730: 0b000021 add w1, w1, w0
734: b9408fe0 ldr w0, [sp, #140]
738: 0b000020 add w0, w1, w0
73c: 910243ff add sp, sp, #0x90 <-- restore sp before ret
740: d65f03c0 ret
thanks,
- Joel
> For normal archs, we usually have something like this:
>
> sys_call_entry:
> [save regs and crap on stack ]
> bl sys_finit_module
> sys_call_entry+x:
> [ here's the address put into the lr regsister ]
>
> sys_finit_module:
> save lr on stack [syscall_entry+x]
> save more stuff on stack
> [..]
> bl load_module
> sys_finit_module+y:
>
> load_module:
> save lr on stack [sys_finit_module+y]
> save more stuff on stack
> [..]
> bl do_init_module
> load_module+z:
>
> do_init_module:
> save lr on stack [load_module+z]
> [ let's say we do the stack trace here! ]
>
> On the stack we have:
>
> data for kernel entry
> sys_call_entry+x [ lr saved in sys_finit_module ]
> data for sys_finit_module
> sys_finit_module+y [ lr saved in load_module ]
> data for load_module
> load_module+z [ lr saved in do_init_module
>
> When we call stack_trace_save() we get:
>
> sys_call_entry+x
> sys_finit_module+y
> load_module+z
>
> We then find those locations on the stack. Let's add some numbers here:
>
> 0: top of stack
> data for kernel entry
> 504: sys_call_entry+x
> data for sys_finit_module
> 856: sys_finit_module+y
> data for sys_load_module
> 904: load_module+z
> 1048: BOTTOM OF STACK HERE
>
> To do the work, we start from the bottom of the stack, looking for what
> was returned from the stack_trace_save
>
> start = 1048
> *p == load_module+z
> stack size = 1048 - 904
>
> Then we say load_module stack size is 144.
>
> What you are describing doesn't make any sense. Yes, we all add LR to
> the stack, not the PC! But if the issue is that the LR is saved *after*
> the function data, then that *will* make a difference. We then have:
>
>
> sys_call_entry:
> [save regs and crap on stack ]
> bl sys_finit_module
> sys_call_entry+x:
> [ here's the address put into the lr regsister ]
>
> sys_finit_module:
> save sys_finit_module stuff on stack
> save lr on stack [syscall_entry+x] <-- reversed order from before!
> [..]
> bl load_module
> sys_finit_module+y:
>
> load_module:
> save load_module stuff on stack
> save lr on stack [sys_finit_module+y]
> [..]
> bl do_init_module
> load_module+z:
>
> do_init_module:
> [ let's say we do the stack trace here! ]
>
> On the stack we have:
>
> data for sys_call_entry
> data for sys_finit_module
> sys_call_entry+x [ lr saved in sys_finit_module ]
> data for load_module
> sys_finit_module+y [ lr saved in load_module ]
> data for do_init_module
> load_module+z [ lr saved in do_init_module
>
> This also brings up the question of when the mcount is called?
>
> We get the same data from stack_trace_save():
>
> sys_call_entry+x
> sys_finit_module+y
> load_module+z
>
> But this time, the stack is different!
>
> 0: top of stack
> data from kernel entry
> data for sys_call_entry
> data for sys_finit_module
> 504: sys_call_entry+x
> data for sys_finit_module
> 856: sys_finit_module+y
> data for load_module
> 904: load_module+z
> data for do_init_module?
> 1048: BOTTOM OF STACK HERE
>
> So yes, the same algorithm is will come up with the wrong result,
> because...
>
> start = 1048
> *p == load_module+z
> stack size = 1048 - 904
>
> We just calculated the size of data for do_init_module, and not for
> load_module!
>
> Can someone confirm that this is the real issue?
>
> -- Steve
>
>
> >
> > Wrong info:
> > Depth Size Location (16 entries)
> > ----- ---- --------
> > 0) 5400 16 __update_load_avg_se.isra.2+0x28/0x220
> > 1) 5384 96 put_prev_entity+0x250/0x338
> > 2) 5288 80 pick_next_task_fair+0x4c4/0x508
> > 3) 5208 72 __schedule+0x100/0x600
> > 4) 5136 184 preempt_schedule_common+0x28/0x48
> > 5) 4952 32 preempt_schedule+0x28/0x30
> > 6) 4920 16 vprintk_emit+0x170/0x1f8
> > 7) 4904 128 vprintk_default+0x48/0x58
> > 8) 4776 64 vprintk_func+0xf8/0x1c8
> > 9) 4712 112 printk+0x70/0x90
> > 10) 4600 176 occupy_stack_init+0x64/0xc0 [kernel_stack]
> > 11) 4424 3376 do_one_initcall+0x68/0x248
> > 12) 1048 144 do_init_module+0x60/0x1f0
> > 13) 904 48 load_module+0x1d50/0x2340
> > 14) 856 352 sys_finit_module+0xd0/0xe8
> > 15) 504 504 el0_svc_naked+0x30/0x34
> >
> > Correct info:
> > Depth Size Location (18 entries)
> > ----- ---- --------
> > 0) 5464 48 cgroup_rstat_updated+0x20/0x100
> > 1) 5416 32 cgroup_base_stat_cputime_account_end.isra.0+0x30/0x60
> > 2) 5384 32 __cgroup_account_cputime+0x3c/0x48
> > 3) 5352 64 update_curr+0xc4/0x1d0
> > 4) 5288 72 pick_next_task_fair+0x444/0x508
> > 5) 5216 184 __schedule+0x100/0x600
> > 6) 5032 32 preempt_schedule_common+0x28/0x48
> > 7) 5000 16 preempt_schedule+0x28/0x30
> > 8) 4984 128 vprintk_emit+0x170/0x1f8
> > 9) 4856 64 vprintk_default+0x48/0x58
> > 10) 4792 112 vprintk_func+0xf8/0x1c8
> > 11) 4680 176 printk+0x70/0x90
> > 12) 4504 80 func_test+0x7c/0xb8 [kernel_stack]
> > 13) 4424 3376 occupy_stack_init+0x7c/0xc0 [kernel_stack]
> > 14) 1048 144 do_one_initcall+0x68/0x248
> > 15) 904 48 do_init_module+0x60/0x1f0
> > 16) 856 352 load_module+0x1d50/0x2340
> > 17) 504 504 sys_finit_module+0xd0/0xe8
> >
> > Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] ARM: dts: imx6qdl-wandboard: Add OV5645 camera support
From: Shawn Guo @ 2019-08-03 8:25 UTC (permalink / raw)
To: Fabio Estevam; +Cc: ezequiel, linux-arm-kernel
In-Reply-To: <20190722134546.15094-1-festevam@gmail.com>
On Mon, Jul 22, 2019 at 10:45:45AM -0300, Fabio Estevam wrote:
> From: Ezequiel Garcia <ezequiel@collabora.com>
>
> imx6qdl-wandboard can be connected to a OV5645 camera via
> MIPI CSI port. Add support for it.
>
> PAD_GPIO_6 has been originally used for the Ethernet FEC
> ERR006687 workaround, but it needs to be used to provide the
> camera sensor clock, so adjust it accordingly.
>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
Applied both, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] bus: imx-weim: optionally enable burst clock mode
From: Shawn Guo @ 2019-08-03 8:19 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Mark Rutland, devicetree, Kees Cook, Arnd Bergmann, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190712204316.16783-1-TheSven73@gmail.com>
On Fri, Jul 12, 2019 at 04:43:15PM -0400, Sven Van Asbroeck wrote:
> To enable burst clock mode, add the fsl,burst-clk-enable
> property to the weim bus's devicetree node.
>
> Example:
> weim: weim@21b8000 {
> compatible = "fsl,imx6q-weim";
> reg = <0x021b8000 0x4000>;
> clocks = <&clks 196>;
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <0 0 0x08000000 0x08000000>;
> fsl,weim-cs-gpr = <&gpr>;
> fsl,burst-clk-enable;
>
> client-device@0,0 {
> compatible = "something";
> reg = <0 0 0x02000000>;
> #address-cells = <1>;
> #size-cells = <1>;
> bank-width = <2>;
> fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
> 0x0000c000 0x1404a38e 0x00000000>;
> };
> };
>
> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Applied both, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] clk: imx8mm: Switch to platform driver
From: Shawn Guo @ 2019-08-03 8:13 UTC (permalink / raw)
To: Abel Vesa
Cc: Jacky Bai, Anson Huang, Stephen Boyd, Mike Turquette,
Linux Kernel Mailing List, NXP Linux Team, Sascha Hauer,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <1562682003-20951-1-git-send-email-abel.vesa@nxp.com>
On Tue, Jul 09, 2019 at 05:20:03PM +0300, Abel Vesa wrote:
> There is no strong reason for this to use CLK_OF_DECLARE instead
> of being a platform driver. Plus, this will now be aligned with the
> other i.MX8M clock drivers which are platform drivers.
>
> In order to make the clock provider a platform driver
> all the data and code needs to be outside of .init section.
>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 4/4] arm64: dts: imx8mm: Add opp-suspend property to OPP table
From: Shawn Guo @ 2019-08-03 8:12 UTC (permalink / raw)
To: Anson.Huang
Cc: nm, mark.rutland, ping.bai, ccaione, agx, angus, leonard.crestez,
festevam, abel.vesa, andrew.smirnov, vireshk, Linux-imx,
devicetree, kernel, linux-pm, s.hauer, robh+dt, daniel.baluta,
linux-arm-kernel, sboyd, linux-kernel, p.zabel, l.stach
In-Reply-To: <20190709080015.43442-4-Anson.Huang@nxp.com>
On Tue, Jul 09, 2019 at 04:00:15PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add opp-suspend property to each OPP, the of opp core will
> select the OPP HW supported and with highest rate to be
> suspend opp, it will speed up the suspend/resume process.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 3/4] arm64: dts: imx8mq: Add opp-suspend property to OPP table
From: Shawn Guo @ 2019-08-03 8:12 UTC (permalink / raw)
To: Anson.Huang
Cc: nm, mark.rutland, ping.bai, ccaione, agx, angus, leonard.crestez,
festevam, abel.vesa, andrew.smirnov, vireshk, Linux-imx,
devicetree, kernel, linux-pm, s.hauer, robh+dt, daniel.baluta,
linux-arm-kernel, sboyd, linux-kernel, p.zabel, l.stach
In-Reply-To: <20190709080015.43442-3-Anson.Huang@nxp.com>
On Tue, Jul 09, 2019 at 04:00:14PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add opp-suspend property to each OPP, the of opp core will
> select the OPP HW supported and with highest rate to be
> suspend opp, it will speed up the suspend/resume process.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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