* Re: [PATCH v2 2/4] clk: meson: add g12a cpu dynamic divider driver
From: Martin Blumenstingl @ 2019-08-03 18:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, linux-clk, linux-kernel, linux-arm-kernel, jbrunet
In-Reply-To: <20190731084019.8451-3-narmstrong@baylibre.com>
On Wed, Jul 31, 2019 at 10:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add a clock driver for the cpu dynamic divider, this divider needs
> to have a flag set before setting the divider value then removed
> while writing the new value to the register.
>
> This drivers implements this behavior and will be used essentially
> on the Amlogic G12A and G12B SoCs for cpu clock trees.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
personally I would add:
Suggested-by: Jerome Brunet <jbrunet@baylibre.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 4/6] arm64: dts: meson: sei510: Add minimal thermal zone
From: Martin Blumenstingl @ 2019-08-03 18:29 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190731153529.30159-5-glaroque@baylibre.com>
Hi Guillaume,
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
<glaroque@baylibre.com> wrote:
>
> Add minimal thermal zone for DDR and CPU sensor
so high DDR (controller?) temperatures will throttle Mali and high PLL
temperatures will throttle the CPU?
to get things started I'm fine with this, but I think it should be
mentioned here
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> .../boot/dts/amlogic/meson-g12a-sei510.dts | 56 +++++++++++++++++++
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> index 979449968a5f..2c16a2cba0a3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> @@ -10,6 +10,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/gpio/meson-g12a-gpio.h>
> #include <dt-bindings/sound/meson-g12a-tohdmitx.h>
> +#include <dt-bindings/thermal/thermal.h>
>
> / {
> compatible = "seirobotics,sei510", "amlogic,g12a";
> @@ -33,6 +34,53 @@
> ethernet0 = ðmac;
> };
>
> + thermal-zones {
> + cpu-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <100>;
> + thermal-sensors = <&cpu_temp>;
> +
> + trips {
> + cpu_critical: cpu-critical {
> + temperature = <110000>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map {
> + trip = <&cpu_critical>;
> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +
> + ddr-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <100>;
> + thermal-sensors = <&ddr_temp>;
> +
> + trips {
> + ddr_critical: ddr-critical {
> + temperature = <110000>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map {
> + trip = <&ddr_critical>;
> + cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> + };
> +
> mono_dac: audio-codec-0 {
> compatible = "maxim,max98357a";
> #sound-dai-cells = <0>;
> @@ -321,6 +369,7 @@
> operating-points-v2 = <&cpu_opp_table>;
> clocks = <&clkc CLKID_CPU_CLK>;
> clock-latency = <50000>;
> + #cooling-cells = <2>;
> };
>
> &cpu1 {
> @@ -328,6 +377,7 @@
> operating-points-v2 = <&cpu_opp_table>;
> clocks = <&clkc CLKID_CPU_CLK>;
> clock-latency = <50000>;
> + #cooling-cells = <2>;
> };
>
> &cpu2 {
> @@ -335,6 +385,7 @@
> operating-points-v2 = <&cpu_opp_table>;
> clocks = <&clkc CLKID_CPU_CLK>;
> clock-latency = <50000>;
> + #cooling-cells = <2>;
> };
>
> &cpu3 {
> @@ -342,6 +393,7 @@
> operating-points-v2 = <&cpu_opp_table>;
> clocks = <&clkc CLKID_CPU_CLK>;
> clock-latency = <50000>;
> + #cooling-cells = <2>;
> };
>
> &cvbs_vdac_port {
> @@ -368,6 +420,10 @@
> status = "okay";
> };
>
> +&mali {
> + #cooling-cells = <2>;
> +};
is there something device-specific in this patch? I'm wondering
whether we can move all of this go g12a.dtsi to simplify maintenance
in the future
Martin
_______________________________________________
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 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Martin Blumenstingl @ 2019-08-03 18:24 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190731153529.30159-3-glaroque@baylibre.com>
Hi Guillaume,
(I still don't have any experience with the thermal framework, so
below are some general comments)
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
<glaroque@baylibre.com> wrote:
I would add a patch description here:
"
Amlogic G12A and G12B SoCs integrate two thermal sensors with the same design.
One is located close to the DDR (controller?) and the other one is
located close to the PLLs (between the CPU and GPU).
The calibration data for each of the thermal sensors instance is
stored in a different location within the AO region.
Implement reading the temperature from each thermal sensor.
The IP block has more functionality, which may be added to this driver
in the future:
- reading up to 16 stored temperature samples
- chip reset when the temperature exceeds a configurable threshold
- up to four interrupts when the temperature has risen above a
configurable threshold
- up to four interrupts when the temperature has fallen below a
configurable threshold
"
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> drivers/thermal/Kconfig | 11 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/amlogic_thermal.c | 332 ++++++++++++++++++++++++++++++
> 3 files changed, 344 insertions(+)
> create mode 100644 drivers/thermal/amlogic_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 9966364a6deb..0f31bb4bc372 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -348,6 +348,17 @@ config MTK_THERMAL
> Enable this option if you want to have support for thermal management
> controller present in Mediatek SoCs
>
> +config AMLOGIC_THERMAL
we typically use "MESON" in the Kconfig symbols:
$ grep -c AMLOGIC .config
1
$ grep -c MESON .config
33
I also wonder if we should add G12 or G12A so we don't conflict with
upcoming thermal sensors with a different design (assuming that this
will be a thing).
for example we already have three different USB2 PHY drivers
[...]
> +/*
> + * Calculate a temperature value from a temperature code.
> + * The unit of the temperature is degree Celsius.
is it really degree Celsius or millicelsius?
> + */
> +static int code_to_temp(struct amlogic_thermal *pdata, int temp_code)
PREFIX_thermal_code_to_millicelsius?
[...]
> +static int amlogic_thermal_enable(struct amlogic_thermal *data)
> +{
> + clk_prepare_enable(data->clk);
no clock error handling?
> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
> + TSENSOR_CFG_REG1_ENABLE, TSENSOR_CFG_REG1_ENABLE);
> +
> + return 0;
> +}
> +
> +static int amlogic_thermal_disable(struct amlogic_thermal *data)
> +{
> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
> + TSENSOR_CFG_REG1_ENABLE, 0);
> + clk_disable(data->clk);
either clk_disable_unprepare here or use only clk_enable in
amlogic_thermal_enable and move prepare/unprepare somewhere else
> +
> + return 0;
> +}
> +
> +static int amlogic_thermal_get_temp(void *data, int *temp)
> +{
> + unsigned int tvalue;
> + struct amlogic_thermal *pdata = data;
> +
> + if (!data)
> + return -EINVAL;
> +
> + regmap_read(pdata->regmap, TSENSOR_STAT0, &tvalue);
> + *temp = code_to_temp(pdata,
> + tvalue & TSENSOR_READ_TEMP_MASK);
maybe simply move the implementation from code_to_temp here?
[...]
> +static const struct amlogic_thermal_data amlogic_thermal_g12_cpu_param = {
> + .u_efuse_off = 0x128,
> + .soc = &amlogic_thermal_g12,
based on the variable name I expected this to be an enum of some sort.
I would have expected it to be called calibration_parameters or
similar to match the explanation in the driver description
(no need to change it if you prefer it like this, I just want to make
you aware of this)
> + .regmap_config = &amlogic_thermal_regmap_config_g12,
if regmap_config is always the same you may also pass it directly to
devm_regmap_init_mmio
> +};
> +
> +static const struct amlogic_thermal_data amlogic_thermal_g12_ddr_param = {
> + .u_efuse_off = 0xF0,
I believe we use lower-case hex everywhere else
[...]
> +static const struct of_device_id of_amlogic_thermal_match[] = {
> + {
> + .compatible = "amlogic,g12-ddr-thermal",
> + .data = &amlogic_thermal_g12_ddr_param,
> + },
> + {
> + .compatible = "amlogic,g12-cpu-thermal",
> + .data = &amlogic_thermal_g12_cpu_param,
> + },
> + { /* end */ }
other drivers use "sentinel", but personally I have no preference here
[...]
> + pdata->tzd = devm_thermal_zone_of_sensor_register
> + (&pdev->dev,
> + 0,
> + pdata,
> + &amlogic_thermal_ops);
I believe the opening brace has to go onto the same line as the function name
[...]
> + ret = amlogic_thermal_enable(pdata);
> + if (ret)
> + clk_unprepare(pdata->clk);
clk_disable_unprepare, else you'll leave the clock prepared
> +#ifdef CONFIG_PM_SLEEP
> +static int amlogic_thermal_suspend(struct device *dev)
> +{
> + struct amlogic_thermal *data = dev_get_drvdata(dev);
> +
> + return amlogic_thermal_disable(data);
> +}
> +
> +static int amlogic_thermal_resume(struct device *dev)
> +{
> + struct amlogic_thermal *data = dev_get_drvdata(dev);
> +
> + return amlogic_thermal_enable(data);
> +}
> +#endif
instead of using an #ifdef here annotate the suspend/resume functions
with __maybe_unused, see [0]
Martin
[0] https://lore.kernel.org/patchwork/patch/732981/
_______________________________________________
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 18:13 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190803185817.11285b2a@why>
On Sat, 3 Aug 2019 18:58:17 +0100
Marc Zyngier <maz@kernel.org> wrote:
> 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
> > 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
> > 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;
> > + 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);
>
> Something troubles me. Here, you've set the request on load. But you
> can be preempted at any time (preemption gets disabled just after).
>
> I have the feeling that should you get preempted right here, you'll
> end-up having accumulated the wrong amount of steal time, as the
> request put via load when you'll get scheduled back in will only get
> processed after a full round of entry/exit/entry, which doesn't look
> great.
Ah, no. We're saved by the check for pending requests right before we
jump in the guest, causing an early exit and the whole shebang to be
restarted.
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 0/9] arm64: Stolen time support
From: Marc Zyngier @ 2019-08-03 18:05 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-1-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:08 +0100
Steven Price <steven.price@arm.com> wrote:
Hi Steven,
> This series add support for paravirtualized time for arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
>
> https://developer.arm.com/docs/den0057/a
>
> It implements support for stolen time, allowing the guest to
> identify time when it is forcibly not executing.
>
> It doesn't implement support for Live Physical Time (LPT) as there are
> some concerns about the overheads and approach in the above
> specification, and I expect an updated version of the specification to
> be released soon with just the stolen time parts.
Thanks for posting this.
My current concern with this series is around the fact that we allocate
memory from the kernel on behalf of the guest. It is the first example
of such thing in the ARM port, and I can't really say I'm fond of it.
x86 seems to get away with it by having the memory allocated from
userspace, why I tend to like more. Yes, put_user is more
expensive than a straight store, but this isn't done too often either.
What is the rational for your current approach?
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 4/9] KVM: arm64: Support stolen time reporting via shared structure
From: Marc Zyngier @ 2019-08-03 17:58 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
> 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
> 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;
> + 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);
Something troubles me. Here, you've set the request on load. But you
can be preempted at any time (preemption gets disabled just after).
I have the feeling that should you get preempted right here, you'll
end-up having accumulated the wrong amount of steal time, as the
request put via load when you'll get scheduled back in will only get
processed after a full round of entry/exit/entry, which doesn't look
great.
Am I getting it right?
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 v2 3/6] arm64: dts: amlogic: g12: add temperature sensor
From: Martin Blumenstingl @ 2019-08-03 17:52 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190731153529.30159-4-glaroque@baylibre.com>
Hi Guillaume,
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
<glaroque@baylibre.com> wrote:
>
> Add cpu and ddr temperature sensors for G12 Socs
>
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
with the nit-pick below addressed:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../boot/dts/amlogic/meson-g12-common.dtsi | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> index 06e186ca41e3..7f862a3490fb 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> @@ -1353,6 +1353,28 @@
> };
> };
>
> + cpu_temp: temperature-sensor@34800 {
> + compatible = "amlogic,g12-cpu-thermal",
> + "amlogic,g12-thermal";
> + reg = <0x0 0x34800 0x0 0x50>;
> + interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_TS>;
> + status = "okay";
I believe nodes are enabled automatically if they don't have a status property
> + #thermal-sensor-cells = <0>;
> + amlogic,ao-secure = <&sec_AO>;
> + };
> +
> + ddr_temp: temperature-sensor@34c00 {
> + compatible = "amlogic,g12-ddr-thermal",
> + "amlogic,g12-thermal";
> + reg = <0x0 0x34c00 0x0 0x50>;
> + interrupts = <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_TS>;
> + status = "okay";
same here
Martin
_______________________________________________
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 6/9] KVM: arm64: Provide a PV_TIME device to user space
From: Marc Zyngier @ 2019-08-03 17:34 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190803135113.6cdf500c@why>
On Sat, 3 Aug 2019 13:51:13 +0100
Marc Zyngier <maz@kernel.org> wrote:
[forgot that one]
> On Fri, 2 Aug 2019 15:50:14 +0100
> Steven Price <steven.price@arm.com> wrote:
[...]
> > +static int __init kvm_pvtime_init(void)
> > +{
> > + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
> > +
> > + return 0;
> > +}
> > +
> > +late_initcall(kvm_pvtime_init);
Why is it an initcall? So far, the only initcall we've used is the one
that initializes KVM itself. Can't we just the device_ops just like we
do for the vgic?
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] ARM: imx: Drop imx_anatop_init()
From: Shawn Guo @ 2019-08-03 16:09 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Peter Chen, linux-kernel, linux-imx, Chris Healy, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190731180131.8597-1-andrew.smirnov@gmail.com>
On Wed, Jul 31, 2019 at 11:01:31AM -0700, Andrey Smirnov wrote:
> With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
> detect in mxs_phy_hw_init()") in tree all of the necessary charger
> setup is done by the USB PHY driver which covers all of the affected
> i.MX6 SoCs.
>
> NOTE: Imx_anatop_init() was also called for i.MX7D, but looking at its
> datasheet it appears to have a different USB PHY IP block, so
> executing i.MX6 charger disable configuration seems unnecessary.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
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] ARM: dts: imx53: Update LCD panel node on M53Menlo
From: Shawn Guo @ 2019-08-03 16:00 UTC (permalink / raw)
To: Marek Vasut; +Cc: Fabio Estevam, NXP Linux Team, linux-arm-kernel
In-Reply-To: <20190803134940.6060-1-marex@denx.de>
On Sat, Aug 03, 2019 at 03:49:40PM +0200, Marek Vasut wrote:
> Update the panel node with latest version of the panel used on the system.
> Add missing pincontrol phandle to the panel node.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> To: linux-arm-kernel@lists.infradead.org
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] ARM: dts: vf610-bk4: Fix qspi node description
From: Shawn Guo @ 2019-08-03 15:53 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland, devicetree, Sascha Hauer, linux-kernel,
Stefan Agner, Rob Herring, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190731141151.7196-1-lukma@denx.de>
On Wed, Jul 31, 2019 at 04:11:51PM +0200, Lukasz Majewski wrote:
> Before this change the device tree description of qspi node for
> second memory on BK4 board was wrong (applicable to old, removed
> fsl-quadspi.c driver).
>
> As a result this memory was not recognized correctly when used
> with the new spi-fsl-qspi.c driver.
>
> From the dt-bindings:
>
> "Required SPI slave node properties:
> - reg: There are two buses (A and B) with two chip selects each.
> This encodes to which bus and CS the flash is connected:
> <0>: Bus A, CS 0
> <1>: Bus A, CS 1
> <2>: Bus B, CS 0
> <3>: Bus B, CS 1"
>
> According to above with new driver the second SPI-NOR memory shall
> have reg=<2> as it is connected to Bus B, CS 0.
>
> Fixes: a67d2c52a82f ("ARM: dts: Add support for Liebherr's BK4 device (vf610 based)")
> Suggested-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> Reviewed-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
* Re: [PATCH v3 2/2] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
From: Shawn Guo @ 2019-08-03 15:47 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, Sascha Hauer, linux-kernel,
Schrempf Frieder, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190729172007.3275-2-krzk@kernel.org>
On Mon, Jul 29, 2019 at 07:20:07PM +0200, Krzysztof Kozlowski wrote:
> Add support for i.MX6UL modules from Kontron Electronics GmbH (before
> acquisition: Exceet Electronics) and evalkit boards based on it:
>
> 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
> (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
> 256 MB NAND and other interfaces,
> 2. N6310 S: evalkit, w/wo eMMC, without display,
> 3. N6310 S 43: evalkit with 4.3" display,
> 4. N6310 S 50: evalkit with 5.0" display.
>
> This includes device nodes for unsupported displays (Admatec
> T043C004800272T2A and T070P133T0S301).
Do not include unsupported devices.
>
> The work is based on Exceet/Kontron source code (GPLv2) with numerous
> changes:
> 1. Reorganize files,
> 2. Rename Exceet -> Kontron,
> 3. Rename models/compatibles to match newest Kontron product naming,
> 4. Fix coding style errors and adjust to device tree coding guidelines,
> 5. Fix DTC warnings,
> 6. Extend compatibles so eval boards inherit the SoM compatible,
> 7. Use defines instead of GPIO and interrupt flag values,
> 8. Use proper vendor compatible for Macronix SPI NOR,
> 9. Sort nodes alphabetically.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v2, after Fabio's review:
> 1. Add "imx6ul" compatible to board name (that's what I understood from
> review),
> 2. Add vendor/device prefix to eeprom and document the compatible,
> 3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
> AG in Switzerland (also making LCD panels),
> 4. Use generic names for nodes,
> 5. Use IRQ_TYPE_LEVEL_LOW,
> 6. Move iomux to the end of files,
> 7. Remove regulators node (include regulators in top level),
> 8. Remove cpu clock-frequency,
> 9. Other minor fixes pointed by Fabio.
>
> Changes since v1, after Frieder's review:
> 1. Remove unneeded license notes,
> 2. Add Kontron copyright (2018),
> 3. Rename the files/models/compatibles to new naming - N6310,
> 4. Remove unneeded CPU operating points override,
> 5. Switch regulator nodes into simple children nodes without addresses
> (so not simple bus),
> 6. Use proper vendor compatible for Macronix SPI NOR.
> ---
> .../devicetree/bindings/arm/fsl.yaml | 4 +
> .../devicetree/bindings/eeprom/at25.txt | 1 +
Please make them two separate patches.
> arch/arm/boot/dts/Makefile | 3 +
> .../boot/dts/imx6ul-kontron-n6310-s-43.dts | 119 +++++
> .../boot/dts/imx6ul-kontron-n6310-s-50.dts | 119 +++++
Are they identical except the display node? Please manage to save
duplicated data.
> arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 420 ++++++++++++++++++
> .../boot/dts/imx6ul-kontron-n6310-som.dtsi | 134 ++++++
> 7 files changed, 800 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 7294ac36f4c0..6a6c09d67dea 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -161,6 +161,10 @@ properties:
> items:
> - enum:
> - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> + - kontron,imx6ul-n6310-s # Kontron N6310 S Board
> + - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board
> + - kontron,imx6ul-n6310-s-50 # Kontron N6310 S 50 Board
> - const: fsl,imx6ul
>
> - description: i.MX6ULL based Boards
> diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
> index b3bde97dc199..42577dd113dd 100644
> --- a/Documentation/devicetree/bindings/eeprom/at25.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at25.txt
> @@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
> Required properties:
> - compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
> Example "<vendor>,<type>" values:
> + "anvo,anv32e61w"
> "microchip,25lc040"
> "st,m95m02"
> "st,m95256"
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9159fa2cea90..28b6cb3454a3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -569,6 +569,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-geam.dtb \
> imx6ul-isiot-emmc.dtb \
> imx6ul-isiot-nand.dtb \
> + imx6ul-kontron-n6310-s.dtb \
> + imx6ul-kontron-n6310-s-43.dtb \
> + imx6ul-kontron-n6310-s-50.dtb \
> imx6ul-liteboard.dtb \
> imx6ul-opos6uldev.dtb \
> imx6ul-pico-hobbit.dtb \
> diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> new file mode 100644
> index 000000000000..c83793725245
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 exceet electronics GmbH
> + * Copyright (C) 2018 Kontron Electronics GmbH
> + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> + */
> +
> +#include "imx6ul-kontron-n6310-s.dts"
> +
> +/ {
> + model = "Kontron N6310 S 43";
> + compatible = "kontron,imx6ul-n6310-s-43", "kontron,imx6ul-n6310-s",
> + "kontron,imx6ul-n6310-som", "fsl,imx6ul";
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm7 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + status = "okay";
> + };
> +
> + panel {
> + compatible = "admatecde,t043c004800272t2a";
Undocumented/unsupported compatible?
> + backlight = <&backlight>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> + };
> +};
> +
> +&i2c4 {
> + touchscreen@5d {
> + compatible = "goodix,gt928";
> + reg = <0x5d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_cap_touch>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
> + irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
> + status = "okay";
> +
> + port {
> + display_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> +};
> +
> +&pwm7 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm7>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_lcdif_dat: lcdifdatgrp {
> + fsl,pins = <
> + MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
> + MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
> + MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
> + MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
> + MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
> + MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
> + MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
> + MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
> + MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
> + MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
> + MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
> + MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
> + MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
> + MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
> + MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
> + MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
> + MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
> + MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
> + MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
> + MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
> + MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
> + MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
> + MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
> + MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
> + >;
> + };
> +
> + pinctrl_lcdif_ctrl: lcdifctrlgrp {
> + fsl,pins = <
> + MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
> + MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
> + MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
> + MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
> + MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
> + >;
> + };
> +
> + pinctrl_cap_touch: captouchgrp {
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
> + MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
> + MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
> + >;
> + };
> +
> + pinctrl_pwm7: pwm7grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
> + >;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> new file mode 100644
> index 000000000000..f9c9afa58771
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 exceet electronics GmbH
> + * Copyright (C) 2018 Kontron Electronics GmbH
> + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> + */
> +
> +#include "imx6ul-kontron-n6310-s.dts"
> +
> +/ {
> + model = "Kontron N6310 S 50";
> + compatible = "kontron,imx6ul-n6310-s-50", "kontron,imx6ul-n6310-s",
> + "kontron,imx6ul-n6310-som", "fsl,imx6ul";
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm7 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + status = "okay";
> + };
> +
> + panel {
> + compatible = "admatecde,t070p133t0s301";
> + backlight = <&backlight>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> + };
> +};
> +
> +&i2c4 {
> + touchscreen@5d {
> + compatible = "goodix,gt928";
> + reg = <0x5d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_cap_touch>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
> + irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
> + status = "okay";
> +
> + port {
> + display_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> +};
> +
> +&pwm7 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm7>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_lcdif_dat: lcdifdatgrp {
> + fsl,pins = <
> + MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
> + MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
> + MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
> + MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
> + MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
> + MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
> + MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
> + MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
> + MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
> + MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
> + MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
> + MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
> + MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
> + MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
> + MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
> + MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
> + MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
> + MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
> + MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
> + MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
> + MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
> + MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
> + MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
> + MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
> + >;
> + };
> +
> + pinctrl_lcdif_ctrl: lcdifctrlgrp {
> + fsl,pins = <
> + MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
> + MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
> + MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
> + MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
> + MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
> + >;
> + };
> +
> + pinctrl_cap_touch: captouchgrp {
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
> + MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
> + MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
> + >;
> + };
> +
> + pinctrl_pwm7: pwm7grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
> + >;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> new file mode 100644
> index 000000000000..4206a4b3f0df
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 exceet electronics GmbH
> + * Copyright (C) 2018 Kontron Electronics GmbH
> + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6ul-kontron-n6310-som.dtsi"
> +
> +/ {
> + model = "Kontron N6310 S";
> + compatible = "kontron,imx6ul-n6310-s", "kontron,imx6ul-n6310-som",
> + "fsl,imx6ul";
> +
> + pwm-beeper {
> + compatible = "pwm-beeper";
> + pwms = <&pwm8 0 5000>;
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> + led1 {
> + label = "debug-led1";
> + gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + led2 {
> + label = "debug-led2";
> + gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + led3 {
> + label = "debug-led3";
> + gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + reg_vref_adc: regulator-vref-adc {
> + compatible = "regulator-fixed";
> + regulator-name = "vref-adc";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg1_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
> +
> +&adc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_adc1>;
> + num-channels = <3>;
> + vref-supply = <®_vref_adc>;
> + status = "okay";
> +};
> +
> +&can2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "okay";
> +};
> +
> +&ecspi1 {
> + cs-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi1>;
> + status = "okay";
> +
> + eeprom@0 {
> + compatible = "anvo,anv32e61w", "atmel,at25";
> + reg = <0>;
> + spi-max-frequency = <20000000>;
> + spi-cpha;
> + spi-cpol;
> + pagesize = <1>;
> + size = <8192>;
> + address-width = <16>;
> + };
> +};
> +
> +&fec1 {
> + pinctrl-0 = <&pinctrl_enet1>;
> + /delete-node/ mdio;
> +};
> +
> +&fec2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet2 &pinctrl_enet2_mdio>;
> + phy-mode = "rmii";
> + phy-handle = <ðphy2>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + reg = <1>;
> + micrel,led-mode = <0>;
> + clocks = <&clks IMX6UL_CLK_ENET_REF>;
> + clock-names = "rmii-ref";
> + };
> +
> + ethphy2: ethernet-phy@2 {
> + reg = <2>;
> + micrel,led-mode = <0>;
> + clocks = <&clks IMX6UL_CLK_ENET2_REF>;
> + clock-names = "rmii-ref";
> + };
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +};
> +
> +&i2c4 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c4>;
> + status = "okay";
> +
> + rtc@32 {
> + compatible = "epson,rx8900";
> + reg = <0x32>;
> + };
> +};
> +
> +&pwm8 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm8>;
> + status = "okay";
> +};
> +
> +&snvs_poweroff {
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + linux,rs485-enabled-at-boot-time;
> + rs485-rx-during-tx;
> + rs485-rts-active-low;
> + uart-has-rtscts;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + fsl,uart-has-rtscts;
> + status = "okay";
> +};
> +
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + status = "okay";
> +};
> +
> +&usbotg1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg1>;
> + dr_mode = "otg";
> + srp-disable;
> + hnp-disable;
> + adp-disable;
> + vbus-supply = <®_usb_otg1_vbus>;
> + status = "okay";
> +};
> +
> +&usbotg2 {
> + dr_mode = "host";
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
Check Documentation/devicetree/bindings/power/wakeup-source.txt
> + vmmc-supply = <®_3v3>;
> + voltage-ranges = <3300 3300>;
> + no-1-8-v;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> + non-removable;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
> + vmmc-supply = <®_3v3>;
> + voltage-ranges = <3300 3300>;
> + no-1-8-v;
> + status = "okay";
> +};
> +
> +&wdog1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + status = "okay";
We usually put 'status' at the end of property list.
> + fsl,ext-reset-output;
> +};
> +
> +&iomuxc {
> + pinctrl-0 = <&pinctrl_reset_out &pinctrl_gpio>;
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
> + >;
> + };
> +
> + pinctrl_gpio: gpio {
Please consistently name the node like:
pinctrl_xxx: xxxgrp
And keep them well sorted alphabetically.
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0 /* DOUT1 */
> + MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x1b0b0 /* DIN1 */
> + MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x1b0b0 /* DOUT2 */
> + MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x1b0b0 /* DIN2 */
> + >;
> + };
> +
> + pinctrl_usbotg1: usbotg1 {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_leds: gpio_leds {
> + fsl,pins = <
> + MX6UL_PAD_UART5_TX_DATA__GPIO1_IO30 0x1b0b0 /* LED H14 */
> + MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x1b0b0 /* LED H15 */
> + MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0 /* LED H16 */
> + >;
> + };
> +
> + /* FRAM */
> + pinctrl_ecspi1: ecspi1grp-1 {
Meaningless '-1' suffix.
Shawn
> + fsl,pins = <
> + MX6UL_PAD_CSI_DATA07__ECSPI1_MISO 0x100b1
> + MX6UL_PAD_CSI_DATA06__ECSPI1_MOSI 0x100b1
> + MX6UL_PAD_CSI_DATA04__ECSPI1_SCLK 0x100b1
> + MX6UL_PAD_CSI_DATA05__GPIO4_IO26 0x100b1 /* ECSPI1-CS1 */
> + >;
> + };
> +
> + pinctrl_enet2: enet2grp {
> + fsl,pins = <
> + MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
> + MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0
> + MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0
> + MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0
> + MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0
> + MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0
> + MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0
> + MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b009
> + >;
> + };
> +
> + pinctrl_enet2_mdio: enet2mdiogrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
> + MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp{
> + fsl,pins = <
> + MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x1b020
> + MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x1b020
> + >;
> + };
> +
> + pinctrl_pwm8: pwm8grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_HSYNC__PWM8_OUT 0x110b0
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX6UL_PAD_NAND_DATA04__UART2_DCE_TX 0x1b0b1
> + MX6UL_PAD_NAND_DATA05__UART2_DCE_RX 0x1b0b1
> + MX6UL_PAD_NAND_DATA06__UART2_DCE_CTS 0x1b0b1
> + /*
> + * mux unused RTS to make sure it doesn't cause
> + * any interrupts when it is undefined
> + */
> + MX6UL_PAD_NAND_DATA07__UART2_DCE_RTS 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX6UL_PAD_UART3_TX_DATA__UART3_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART3_RX_DATA__UART3_DCE_RX 0x1b0b1
> + MX6UL_PAD_UART3_CTS_B__UART3_DCE_CTS 0x1b0b1
> + MX6UL_PAD_UART3_RTS_B__UART3_DCE_RTS 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX6UL_PAD_UART4_TX_DATA__UART4_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART4_RX_DATA__UART4_DCE_RX 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
> + MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x100b1 /* SD1_CD */
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10059
> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> + fsl,pins = <
> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100b9
> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170b9
> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170b9
> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170b9
> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170b9
> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170b9
> + >;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> + fsl,pins = <
> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_PIXCLK__I2C1_SCL 0x4001b8b0
> + MX6UL_PAD_CSI_MCLK__I2C1_SDA 0x4001b8b0
> + >;
> + };
> +
> + pinctrl_i2c4: i2c4grp {
> + fsl,pins = <
> + MX6UL_PAD_UART2_TX_DATA__I2C4_SCL 0x4001f8b0
> + MX6UL_PAD_UART2_RX_DATA__I2C4_SDA 0x4001f8b0
> + >;
> + };
> +
> + pinctrl_adc1: adc1grp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
> + MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
> + MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0xb0
> + >;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
> new file mode 100644
> index 000000000000..798ff0028e29
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
> @@ -0,0 +1,134 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 exceet electronics GmbH
> + * Copyright (C) 2018 Kontron Electronics GmbH
> + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> + */
> +
> +#include "imx6ul.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Kontron N6310 SOM";
> + compatible = "kontron,imx6ul-n6310-som", "fsl,imx6ul";
> +
> + memory@80000000 {
> + reg = <0x80000000 0x10000000>;
> + device_type = "memory";
> + };
> +};
> +
> +&ecspi2 {
> + cs-gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi2>;
> + status = "okay";
> +
> + spi-flash@0 {
> + compatible = "mxicy,mx25v8035f", "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> +};
> +
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1_mdio>;
> + phy-mode = "rmii";
> + phy-handle = <ðphy1>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + reg = <1>;
> + micrel,led-mode = <0>;
> + clocks = <&clks IMX6UL_CLK_ENET_REF>;
> + clock-names = "rmii-ref";
> + };
> + };
> +};
> +
> +&fec2 {
> + phy-mode = "rmii";
> + status = "disabled";
> +};
> +
> +&qspi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_qspi>;
> + status = "okay";
> +
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-nand";
> + spi-max-frequency = <108000000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + reg = <0>;
> +
> + partition@0 {
> + label = "ubi1";
> + reg = <0x00000000 0x08000000>;
> + };
> +
> + partition@8000000 {
> + label = "ubi2";
> + reg = <0x08000000 0x08000000>;
> + };
> + };
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_reset_out>;
> +
> + pinctrl_reset_out: rstoutgrp {
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_ecspi2: ecspi2grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_DATA03__ECSPI2_MISO 0x100b1
> + MX6UL_PAD_CSI_DATA02__ECSPI2_MOSI 0x100b1
> + MX6UL_PAD_CSI_DATA00__ECSPI2_SCLK 0x100b1
> + MX6UL_PAD_CSI_DATA01__GPIO4_IO22 0x100b1
> + >;
> + };
> +
> + pinctrl_enet1: enet1grp {
> + fsl,pins = <
> + MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
> + MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
> + MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
> + MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
> + MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
> + MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
> + MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
> + MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b009
> + >;
> + };
> +
> + pinctrl_enet1_mdio: enet1mdiogrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
> + MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
> + >;
> + };
> +
> + pinctrl_qspi: qspigrp {
> + fsl,pins = <
> + MX6UL_PAD_NAND_WP_B__QSPI_A_SCLK 0x70a1
> + MX6UL_PAD_NAND_READY_B__QSPI_A_DATA00 0x70a1
> + MX6UL_PAD_NAND_CE0_B__QSPI_A_DATA01 0x70a1
> + MX6UL_PAD_NAND_CE1_B__QSPI_A_DATA02 0x70a1
> + MX6UL_PAD_NAND_CLE__QSPI_A_DATA03 0x70a1
> + MX6UL_PAD_NAND_DQS__QSPI_A_SS0_B 0x70a1
> + >;
> + };
> +};
> --
> 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
* Re: [PATCH] arm64: defconfig: CONFIG_DRM_ETNAVIV=m
From: Shawn Guo @ 2019-08-03 15:15 UTC (permalink / raw)
To: Christian Gmeiner
Cc: Leonard Crestez, Anson Huang, Maxime Ripard, Catalin Marinas,
linux-kernel, etnaviv, Marcin Juszkiewicz, Dinh Nguyen,
Jagan Teki, Olof Johansson, Simon Horman, Bjorn Andersson,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190802122102.3932-1-christian.gmeiner@gmail.com>
On Fri, Aug 02, 2019 at 02:20:28PM +0200, Christian Gmeiner wrote:
> For imx8 we want to enable etnaviv, let's enable it
> in defconfig, it will be useful to have it enabled for KernelCI
> boot and runtime testing.
>
> Signed-off-by: Christian Gmeiner <christian.gmeiner@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
* Re: [PATCH] ARM: dts: imx25-pdk: native-mode is part of display-timings
From: Shawn Guo @ 2019-08-03 15:08 UTC (permalink / raw)
To: Martin Kaiser
Cc: linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190729142316.21900-1-martin@kaiser.cx>
On Mon, Jul 29, 2019 at 04:23:16PM +0200, Martin Kaiser wrote:
> Move the native-mode property inside the display-timings node.
>
> According to
> Documentation/devicetree/bindings/display/panel/display-timing.txt.
> native-mode is a property of the display-timings node.
>
> If it's located outside of display-timings, the native-mode setting is
> ignored and the first display timing is used (which is a problem only if
> someone adds another display timing).
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
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] clk: imx8mq: Mark AHB clock as critical
From: Shawn Guo @ 2019-08-03 15:04 UTC (permalink / raw)
To: Abel Vesa
Cc: Anson Huang, Stephen Boyd, Mike Turquette,
Linux Kernel Mailing List, linux-clk, Sascha Hauer, Fabio Estevam,
Guido Gunther, linux-arm-kernel
In-Reply-To: <1564471375-6736-1-git-send-email-abel.vesa@nxp.com>
On Tue, Jul 30, 2019 at 10:22:55AM +0300, Abel Vesa wrote:
> Initially, the TMU_ROOT clock was marked as critical, which automatically
> made the AHB clock to stay always on. Since the TMU_ROOT clock is not
> marked as critical anymore, following commit:
>
> 431bdd1df48e ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT")
The commit ID is not stable before the commit actually lands mainline.
I could possibly rebase the branch.
>
> all the clocks that derive from ipg_root clock (and implicitly ahb clock)
> would also have to enable, along with their own gate, the AHB clock.
>
> But considering that AHB is actually a bus that has to be always on, we mark
> it as critical in the clock provider driver and then all the clocks that
> derive from it can be controlled through the dedicated per IP gate which
> follows after the ipg_root clock.
>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> Tested-by: Daniel Baluta <daniel.baluta@nxp.com>
> Fixes: 431bdd1df48e ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT")
Dropped commit ID above and Fixes tag here, and applied the patch.
Thanks for the fixing.
Shawn
_______________________________________________
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: imx8mq-evk: Unbypass audio_pll1
From: Shawn Guo @ 2019-08-03 14:56 UTC (permalink / raw)
To: Daniel Baluta
Cc: devicetree, baruch, abel.vesa, ccaione, andrew.smirnov, s.hauer,
angus, linux-kernel, linux-imx, festevam, shengjiu.wang,
linux-arm-kernel, l.stach
In-Reply-To: <20190728140817.12509-1-daniel.baluta@nxp.com>
On Sun, Jul 28, 2019 at 05:08:17PM +0300, Daniel Baluta wrote:
> Making audio_pll1 parent of audio_pll1_bypass, will allow
> setting rates multiple of 8000 for children.
>
> After unbypass clk hierarchy looks like this:
> * osc_25m
> * audio_pll1
> * audio_pll1_bypass
> * audio_pll1_out
> * sai2
> * sai2_root_clk
>
> Signed-off-by: Daniel Baluta <daniel.baluta@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] ARM: dts: imx: Cleanup style around assignment operator
From: Shawn Guo @ 2019-08-03 14:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, Sascha Hauer, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190727142640.23014-1-krzk@kernel.org>
On Sat, Jul 27, 2019 at 04:26:40PM +0200, Krzysztof Kozlowski wrote:
> Use a space before and after assignment operator to have consistent
> style.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
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 01/11] dt-bindings: firmware: imx-scu: new binding to parse clocks from device tree
From: Shawn Guo @ 2019-08-03 14:42 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree, sboyd, mturquette, Rob Herring, linux-imx, kernel,
fabio.estevam, linux-clk, linux-arm-kernel
In-Reply-To: <1563289265-10977-2-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 11:00:55PM +0800, Dong Aisheng wrote:
> There's a few limitations on the original one cell clock binding
> (#clock-cells = <1>) that we have to define some SW clock IDs for device
> tree to reference. This may cause troubles if we want to use common
> clock IDs for multi platforms support when the clock of those platforms
> are mostly the same.
> e.g. Current clock IDs name are defined with SS prefix.
>
> However the device may reside in different SS across CPUs, that means the
> SS prefix may not valid anymore for a new SoC. Furthermore, the device
> availability of those clocks may also vary a bit.
>
> For such situation, we want to eliminate the using of SW Clock IDs and
> change to use a more close to HW one instead.
> For SCU clocks usage, only two params required: Resource id + Clock Type.
If this is how SCU firmware addresses the clock, I agree that it's worth
witching to this new bindings, which describes the hardware (SCU
firmware in this case) better, IMO.
> Both parameters are platform independent. So we could use two cells binding
> to pass those parameters,
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> ChangeLog:
> v2->v3:
> * Changed to two cells binding and register all clocks in driver
> instead of parse from device tree.
> v1->v2:
> * changed to one cell binding inspired by arm,scpi.txt
> Documentation/devicetree/bindings/arm/arm,scpi.txt
> Resource ID is encoded in 'reg' property.
> Clock type is encoded in generic clock-indices property.
> Then we don't have to search all the DT nodes to fetch
> those two value to construct clocks which is relatively
> low efficiency.
> * Add required power-domain property as well.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 12 +++++++-----
> include/dt-bindings/firmware/imx/rsrc.h | 17 +++++++++++++++++
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index 5d7dbab..351d335 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -89,7 +89,10 @@ Required properties:
> "fsl,imx8qm-clock"
> "fsl,imx8qxp-clock"
> followed by "fsl,scu-clk"
> -- #clock-cells: Should be 1. Contains the Clock ID value.
> +- #clock-cells: Should be either
> + 2: Contains the Resource and Clock ID value.
> + or
> + 1: Contains the Clock ID value. (DEPRECATED)
> - clocks: List of clock specifiers, must contain an entry for
> each required entry in clock-names
> - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
> @@ -162,7 +165,7 @@ firmware {
>
> clk: clk {
> compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
> - #clock-cells = <1>;
> + #clock-cells = <2>;
> };
>
> iomuxc {
> @@ -192,8 +195,7 @@ serial@5a060000 {
> ...
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_lpuart0>;
> - clocks = <&clk IMX8QXP_UART0_CLK>,
> - <&clk IMX8QXP_UART0_IPG_CLK>;
> - clock-names = "per", "ipg";
> + clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
> + clock-names = "ipg";
> power-domains = <&pd IMX_SC_R_UART_0>;
> };
> diff --git a/include/dt-bindings/firmware/imx/rsrc.h b/include/dt-bindings/firmware/imx/rsrc.h
> index 4e61f64..fbeaca7 100644
> --- a/include/dt-bindings/firmware/imx/rsrc.h
> +++ b/include/dt-bindings/firmware/imx/rsrc.h
> @@ -547,4 +547,21 @@
> #define IMX_SC_R_ATTESTATION 545
> #define IMX_SC_R_LAST 546
>
> +/*
> + * Defines for SC PM CLK
> + */
> +#define IMX_SC_PM_CLK_SLV_BUS 0 /* Slave bus clock */
> +#define IMX_SC_PM_CLK_MST_BUS 1 /* Master bus clock */
> +#define IMX_SC_PM_CLK_PER 2 /* Peripheral clock */
> +#define IMX_SC_PM_CLK_PHY 3 /* Phy clock */
> +#define IMX_SC_PM_CLK_MISC 4 /* Misc clock */
> +#define IMX_SC_PM_CLK_MISC0 0 /* Misc 0 clock */
> +#define IMX_SC_PM_CLK_MISC1 1 /* Misc 1 clock */
> +#define IMX_SC_PM_CLK_MISC2 2 /* Misc 2 clock */
> +#define IMX_SC_PM_CLK_MISC3 3 /* Misc 3 clock */
> +#define IMX_SC_PM_CLK_MISC4 4 /* Misc 4 clock */
> +#define IMX_SC_PM_CLK_CPU 2 /* CPU clock */
> +#define IMX_SC_PM_CLK_PLL 4 /* PLL */
> +#define IMX_SC_PM_CLK_BYPASS 4 /* Bypass clock */
It seems that there are several sets of clock type which apply to
different resources/devices? If so, can you separate them a bit with
some comments to make the list easier for readers?
Shawn
> +
> #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] i2c: stm32: Use the correct style for SPDX License Identifier
From: Nishad Kamdar @ 2019-08-03 14:13 UTC (permalink / raw)
To: Pierre-Yves MORDRET, Maxime Coquelin, Alexandre Torgue
Cc: Greg Kroah-Hartman, linux-kernel, linux-i2c,
Uwe Kleine-König, Joe Perches, linux-stm32, linux-arm-kernel
This patch corrects the SPDX License Identifier style
in header file related to STM32 Driver for I2C hardware
bus support.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
---
drivers/i2c/busses/i2c-stm32.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-stm32.h b/drivers/i2c/busses/i2c-stm32.h
index 868755f82f88..2c21893905a3 100644
--- a/drivers/i2c/busses/i2c-stm32.h
+++ b/drivers/i2c/busses/i2c-stm32.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* i2c-stm32.h
*
--
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 -next 07/12] crypto: picoxcell - use devm_platform_ioremap_resource() to simplify code
From: Jamie Iles @ 2019-08-03 14:13 UTC (permalink / raw)
To: YueHaibing
Cc: heiko, gary.hook, clabbe.montjoie, linux-arm-kernel, jamie,
linux-stm32, jesper.nilsson, linux-samsung-soc, herbert, krzk,
linux-rockchip, wens, agross, thomas.lendacky, alexandre.torgue,
antoine.tenart, linux-arm-msm, mripard, linux-mediatek,
lars.persson, matthias.bgg, linux-arm-kernel, linux-kernel,
linux-crypto, mcoquelin.stm32, kgene, davem
In-Reply-To: <20190802132809.8116-8-yuehaibing@huawei.com>
On Fri, Aug 02, 2019 at 09:28:04PM +0800, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Jamie Iles <jamie@jamieiles.com>
> ---
> drivers/crypto/picoxcell_crypto.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
> index b985cb85..9a939b4 100644
> --- a/drivers/crypto/picoxcell_crypto.c
> +++ b/drivers/crypto/picoxcell_crypto.c
> @@ -1624,7 +1624,7 @@ MODULE_DEVICE_TABLE(of, spacc_of_id_table);
> static int spacc_probe(struct platform_device *pdev)
> {
> int i, err, ret;
> - struct resource *mem, *irq;
> + struct resource *irq;
> struct device_node *np = pdev->dev.of_node;
> struct spacc_engine *engine = devm_kzalloc(&pdev->dev, sizeof(*engine),
> GFP_KERNEL);
> @@ -1653,8 +1653,7 @@ static int spacc_probe(struct platform_device *pdev)
>
> engine->name = dev_name(&pdev->dev);
>
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - engine->regs = devm_ioremap_resource(&pdev->dev, mem);
> + engine->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(engine->regs))
> return PTR_ERR(engine->regs);
>
> --
> 2.7.4
>
>
_______________________________________________
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] Gemini updates for v5.4 take one
From: Linus Walleij @ 2019-08-03 13:53 UTC (permalink / raw)
To: arm-soc, soc; +Cc: Hans Ulli Kroll, Linux ARM
Hi ARM SoC folks,
here are some Gemini patches for the v5.4 kernel cycle,
maybe there will be more, who knows.
Details in the signed tag, please pull it in!
Yours,
Linus Walleij
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/gemini-dts-v5.4-1
for you to fetch changes up to e8547e12d5d6a40a16263cc8678d7025e54c379a:
ARM: dts: gemini: Mount root from mtdblock3 (2019-07-26 13:42:57 +0200)
----------------------------------------------------------------
DTS updates for the Gemini platform:
- Fix up some pin config confusion
- Use redboot partition parsing on the SL93512r
- Mount root on mtdblock3 by default
----------------------------------------------------------------
Linus Walleij (3):
ARM: dts: gemini: Fix up confused pin settings
ARM: dts: gemini: Switch to redboot partition parsing
ARM: dts: gemini: Mount root from mtdblock3
arch/arm/boot/dts/gemini-nas4220b.dts | 37 ++++-------------------
arch/arm/boot/dts/gemini-sl93512r.dts | 56 ++++++++++-------------------------
2 files changed, 21 insertions(+), 72 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx53: Update LCD panel node on M53Menlo
From: Marek Vasut @ 2019-08-03 13:49 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marek Vasut, Fabio Estevam, Shawn Guo, NXP Linux Team
Update the panel node with latest version of the panel used on the system.
Add missing pincontrol phandle to the panel node.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
To: linux-arm-kernel@lists.infradead.org
---
arch/arm/boot/dts/imx53-m53menlo.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-m53menlo.dts b/arch/arm/boot/dts/imx53-m53menlo.dts
index 10acc5331ba6..719ed5ca454a 100644
--- a/arch/arm/boot/dts/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/imx53-m53menlo.dts
@@ -54,7 +54,8 @@
};
panel {
- compatible = "edt,etm070080dh6";
+ compatible = "edt,etm0700g0dh6";
+ pinctrl-0 = <&pinctrl_display_gpio>;
enable-gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
port {
--
2.20.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 v3 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree
From: Shawn Guo @ 2019-08-03 13:50 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree, sboyd, mturquette, Rob Herring, linux-imx, kernel,
fabio.estevam, linux-clk, linux-arm-kernel
In-Reply-To: <1563289265-10977-3-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 11:00:56PM +0800, Dong Aisheng wrote:
> MX8QM and MX8QXP LPCG Clocks are mostly the same except they may reside
> in different subsystems across CPUs and also vary a bit on the availability.
>
> Same as SCU clock, we want to move the clock definition into device tree
> which can fully decouple the dependency of Clock ID definition from device
> tree and make us be able to write a fully generic lpcg clock driver.
>
> And we can also use the existence of clock nodes in device tree to address
> the device and clock availability differences across different SoCs.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> ChangeLog:
> v2->v3:
> * no changes
> v1->v2:
> * Update example
> * Add power domain property
> ---
> .../devicetree/bindings/clock/imx8qxp-lpcg.txt | 34 ++++++++++++++++++----
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> index 965cfa4..6fc2fd8 100644
> --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> @@ -11,6 +11,21 @@ enabled by these control bits, it might still not be running based
> on the base resource.
>
> Required properties:
> +- compatible: Should be one of:
> + "fsl,imx8qxp-lpcg"
> + "fsl,imx8qm-lpcg" followed by "fsl,imx8qxp-lpcg".
> +- reg: Address and length of the register set.
> +- #clock-cells: Should be 1. One LPCG supports multiple clocks.
> +- clocks: Input parent clocks phandle array for each clock.
> +- bit-offset: An integer array indicating the bit offset for each clock.
I guess that the driver should be able to figure bit offset from
'clock-indices' property.
> +- hw-autogate: Boolean array indicating whether supports HW autogate for
> + each clock.
Not sure why it needs to be a property in DT. Or asking it different
way, when it should be true and when false?
Shawn
> +- clock-output-names: Shall be the corresponding names of the outputs.
> + NOTE this property must be specified in the same order
> + as the clock bit-offset and hw-autogate property.
> +- power-domains: Should contain the power domain used by this clock.
> +
> +Legacy binding (DEPRECATED):
> - compatible: Should be one of:
> "fsl,imx8qxp-lpcg-adma",
> "fsl,imx8qxp-lpcg-conn",
> @@ -33,10 +48,17 @@ Examples:
>
> #include <dt-bindings/clock/imx8qxp-clock.h>
>
> -conn_lpcg: clock-controller@5b200000 {
> - compatible = "fsl,imx8qxp-lpcg-conn";
> - reg = <0x5b200000 0xb0000>;
> +sdhc0_lpcg: clock-controller@5b200000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x5b200000 0x10000>;
> #clock-cells = <1>;
> + clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
> + <&conn_ipg_clk>, <&conn_axi_clk>;
> + bit-offset = <0 16 20>;
> + clock-output-names = "sdhc0_lpcg_per_clk",
> + "sdhc0_lpcg_ipg_clk",
> + "sdhc0_lpcg_ahb_clk";
> + power-domains = <&pd IMX_SC_R_SDHC_0>;
> };
>
> usdhc1: mmc@5b010000 {
> @@ -44,8 +66,8 @@ usdhc1: mmc@5b010000 {
> interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
> reg = <0x5b010000 0x10000>;
> - clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>,
> - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>,
> - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>;
> + clocks = <&sdhc0_lpcg 1>,
> + <&sdhc0_lpcg 0>,
> + <&sdhc0_lpcg 2>;
> clock-names = "ipg", "per", "ahb";
> };
> --
> 2.7.4
>
_______________________________________________
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 6/9] KVM: arm64: Provide a PV_TIME device to user space
From: Marc Zyngier @ 2019-08-03 12:51 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-7-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:14 +0100
Steven Price <steven.price@arm.com> wrote:
> Allow user space to inform the KVM host where in the physical memory
> map the paravirtualized time structures should be located.
>
> A device is created which provides the base address of an array of
> Stolen Time (ST) structures, one for each VCPU. There must be (64 *
> total number of VCPUs) bytes of memory available at this location.
>
> The address is given in terms of the physical address visible to
> the guest and must be 64 byte aligned. The memory should be marked as
> reserved to the guest to stop it allocating it for other purposes.
Why? You seem to be allocating the memory from the kernel, so as far as
the guest is concerned, this isn't generally usable memory.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/kvm_mmu.h | 2 +
> arch/arm64/include/uapi/asm/kvm.h | 6 +
> arch/arm64/kvm/Makefile | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/mmu.c | 44 +++++++
> virt/kvm/arm/pvtime.c | 190 ++++++++++++++++++++++++++++++
> 6 files changed, 245 insertions(+)
> create mode 100644 virt/kvm/arm/pvtime.c
>
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index befe37d4bc0e..88c8a4b2836f 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -157,6 +157,8 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm);
> void kvm_free_stage2_pgd(struct kvm *kvm);
> int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> phys_addr_t pa, unsigned long size, bool writable);
> +int kvm_phys_addr_memremap(struct kvm *kvm, phys_addr_t guest_ipa,
> + phys_addr_t pa, unsigned long size, bool writable);
>
> int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a507716ae2f..95516a4198ea 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -367,6 +367,12 @@ struct kvm_vcpu_events {
> #define KVM_PSCI_RET_INVAL PSCI_RET_INVALID_PARAMS
> #define KVM_PSCI_RET_DENIED PSCI_RET_DENIED
>
> +/* Device Control API: PV_TIME */
> +#define KVM_DEV_ARM_PV_TIME_PADDR 0
> +#define KVM_DEV_ARM_PV_TIME_ST 0
> +#define KVM_DEV_ARM_PV_TIME_STATE_SIZE 1
> +#define KVM_DEV_ARM_PV_TIME_STATE 2
> +
> #endif
>
> #endif /* __ARM_KVM_H__ */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index 73dce4d47d47..5ffbdc39e780 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -14,6 +14,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/e
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arm.o $(KVM)/arm/mmu.o $(KVM)/arm/mmio.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/psci.o $(KVM)/arm/perf.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hypercalls.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/pvtime.o
>
> kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o va_layout.o
> kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index a7c19540ce21..04bffafa0708 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1222,6 +1222,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_ARM_VGIC_ITS KVM_DEV_TYPE_ARM_VGIC_ITS
> KVM_DEV_TYPE_XIVE,
> #define KVM_DEV_TYPE_XIVE KVM_DEV_TYPE_XIVE
> + KVM_DEV_TYPE_ARM_PV_TIME,
> +#define KVM_DEV_TYPE_ARM_PV_TIME KVM_DEV_TYPE_ARM_PV_TIME
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 38b4c910b6c3..be28a4aee451 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1368,6 +1368,50 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> return ret;
> }
>
> +/**
> + * kvm_phys_addr_memremap - map a memory range to guest IPA
> + *
> + * @kvm: The KVM pointer
> + * @guest_ipa: The IPA at which to insert the mapping
> + * @pa: The physical address of the memory
> + * @size: The size of the mapping
> + */
> +int kvm_phys_addr_memremap(struct kvm *kvm, phys_addr_t guest_ipa,
> + phys_addr_t pa, unsigned long size, bool writable)
> +{
> + phys_addr_t addr, end;
> + int ret = 0;
> + unsigned long pfn;
> + struct kvm_mmu_memory_cache cache = { 0, };
> +
> + end = (guest_ipa + size + PAGE_SIZE - 1) & PAGE_MASK;
> + pfn = __phys_to_pfn(pa);
> +
> + for (addr = guest_ipa; addr < end; addr += PAGE_SIZE) {
> + pte_t pte = pfn_pte(pfn, PAGE_S2);
> +
> + if (writable)
> + pte = kvm_s2pte_mkwrite(pte);
> +
> + ret = mmu_topup_memory_cache(&cache,
> + kvm_mmu_cache_min_pages(kvm),
> + KVM_NR_MEM_OBJS);
> + if (ret)
> + goto out;
> + spin_lock(&kvm->mmu_lock);
> + ret = stage2_set_pte(kvm, &cache, addr, &pte, 0);
> + spin_unlock(&kvm->mmu_lock);
> + if (ret)
> + goto out;
> +
> + pfn++;
> + }
> +
> +out:
> + mmu_free_memory_cache(&cache);
> + return ret;
> +}
This is an exact copy of kvm_phys_addr_ioremap(), with only the memory
attributes changing. Surely we can have a shared implementation that
takes the memory attribute as a parameter.
> +
> static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
> {
> kvm_pfn_t pfn = *pfnp;
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> new file mode 100644
> index 000000000000..9051bc07eae1
> --- /dev/null
> +++ b/virt/kvm/arm/pvtime.c
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 Arm Ltd.
> +
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_mmu.h>
> +
> +/* We currently only support PV time on ARM64 */
> +#ifdef CONFIG_ARM64
And we're only compiling it on arm64, so why the #ifdef?
> +
> +#include <asm/pvclock-abi.h>
> +
> +static int max_stolen_size(void)
> +{
> + int size = KVM_MAX_VCPUS * sizeof(struct pvclock_vcpu_stolen_time_info);
So we're always allocating enough memory for 512 CPUs? That's an
additional 32kB of contiguous memory...
> +
> + return ALIGN(size, PAGE_SIZE);
> +}
> +
> +static int kvm_arm_pvtime_create(struct kvm_device *dev, u32 type)
> +{
> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> +
> + pvtime->st = alloc_pages_exact(max_stolen_size(),
> + GFP_KERNEL | __GFP_ZERO);
> + if (!pvtime->st)
> + return -ENOMEM;
Is there any chance we could use a vmalloc allocation instead? This
would lift the requirement on having physically contiguous memory.
> +
> + return 0;
> +}
> +
> +static void kvm_arm_pvtime_destroy(struct kvm_device *dev)
> +{
> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> +
> + pvtime->st_base = GPA_INVALID;
> + free_pages_exact(pvtime->st, max_stolen_size());
> + kfree(dev);
> +}
> +
> +static int pvtime_map_pages(struct kvm *kvm, gpa_t guest_paddr,
> + void *kaddr, int size)
> +{
> + return kvm_phys_addr_memremap(kvm, guest_paddr,
> + virt_to_phys(kaddr),
> + size, false);
> +}
> +
> +static int pvtime_save_state(struct kvm *kvm, u64 type, void __user *user)
> +{
> + void *source;
> + size_t size;
> +
> + switch (type) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + source = kvm->arch.pvtime.st;
> + size = sizeof(struct pvclock_vcpu_stolen_time_info) *
> + atomic_read(&kvm->online_vcpus);
> + break;
> + default:
> + return -ENXIO;
> + }
> +
> + if (copy_to_user(user, source, size))
> + return -EFAULT;
> + return 0;
> +}
> +
> +static int pvtime_restore_state(struct kvm *kvm, u64 type, void __user *user)
> +{
> + void *dest;
> + size_t size;
> +
> + switch (type) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + dest = kvm->arch.pvtime.st;
> + size = sizeof(struct pvclock_vcpu_stolen_time_info) *
> + atomic_read(&kvm->online_vcpus);
> + break;
> + default:
> + return -ENXIO;
> + }
> +
> + if (copy_from_user(dest, user, size))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +static int kvm_arm_pvtime_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + struct kvm_arch_pvtime *pvtime = &dev->kvm->arch.pvtime;
> + u64 __user *user = (u64 __user *)attr->addr;
> + u64 paddr;
> + int ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_PADDR:
> + if (get_user(paddr, user))
> + return -EFAULT;
> + if (paddr & 63)
> + return -EINVAL;
You should check whether the device fits into the IPA space for this
guest, and whether it overlaps with anything else.
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + if (pvtime->st_base != GPA_INVALID)
> + return -EEXIST;
> + ret = pvtime_map_pages(dev->kvm, paddr, pvtime->st,
> + max_stolen_size());
Consider moving the size directly into pvtime_map_pages(), and dropping
the pvtime->st parameter. All you need is kvm and paddr.
> + if (ret)
> + return ret;
> + pvtime->st_base = paddr;
> + return 0;
> + }
> + break;
> + case KVM_DEV_ARM_PV_TIME_STATE_SIZE:
> + return -EPERM;
> + case KVM_DEV_ARM_PV_TIME_STATE:
> + return pvtime_restore_state(dev->kvm, attr->attr, user);
> + }
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pvtime_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + u64 __user *user = (u64 __user *)attr->addr;
> + u32 size;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_PADDR:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + if (put_user(dev->kvm->arch.pvtime.st_base, user))
> + return -EFAULT;
> + return 0;
> + }
> + break;
> + case KVM_DEV_ARM_PV_TIME_STATE_SIZE:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + size = sizeof(struct pvclock_vcpu_stolen_time_info);
> + size *= atomic_read(&dev->kvm->online_vcpus);
> + break;
> + default:
> + return -ENXIO;
> + }
> + if (put_user(size, user))
> + return -EFAULT;
> + return 0;
> + case KVM_DEV_ARM_PV_TIME_STATE:
> + return pvtime_save_state(dev->kvm, attr->attr, user);
> + }
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pvtime_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PV_TIME_PADDR:
> + case KVM_DEV_ARM_PV_TIME_STATE_SIZE:
> + case KVM_DEV_ARM_PV_TIME_STATE:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_PV_TIME_ST:
> + return 0;
> + }
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static const struct kvm_device_ops pvtime_ops = {
> + "Arm PV time",
> + .create = kvm_arm_pvtime_create,
> + .destroy = kvm_arm_pvtime_destroy,
> + .set_attr = kvm_arm_pvtime_set_attr,
> + .get_attr = kvm_arm_pvtime_get_attr,
> + .has_attr = kvm_arm_pvtime_has_attr
> +};
> +
> +static int __init kvm_pvtime_init(void)
> +{
> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
> +
> + return 0;
> +}
> +
> +late_initcall(kvm_pvtime_init);
> +
> +#endif
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] 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
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