* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Philippe Ombredanne @ 2017-12-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA93ih0C-aMpFAhU+5x6P=QjiOVRPZ0UL1wyKh1oeXzC8UjPXQ@mail.gmail.com>
Dear Masami-san,
On Tue, Dec 12, 2017 at 3:29 AM, Masami Hiramatsu
<masami.hiramatsu@linaro.org> wrote:
[...]
> Then what I'm considering is copyright notice lines. Those are usually
> treat as the header lines, not single line. So
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
>> +// Copyright 2014 Panasonic Corporation
>> +// Copyright 2015-2017 Socionext Inc.
>
> is acceptable? or should we keep C-style header lines for new drivers?
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +/*
>> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
>> + * Copyright 2014 Panasonic Corporation
>> + * Copyright 2015-2017 Socionext Inc.
>> + */
>
> I just concern that those lines are not "single". that's all. :)
My voice carries the weight of a down feather in this discussion and
to me the benefit of the first form is that you have removed two
lines. Both forms work fine.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] ASoC: sun4i-codec: fix to enable 12Khz and 24Khz audio playback and capture sample rates
From: Andrea Bondavalli @ 2017-12-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
H3 ASoC supports 12Khz and 24Khz audio sample rates but the current drivers doesn't advertise these rates properly and they cannot be used.
For example attempt to capture at 12Khz uses 11Khz (same applies to audio playback):
# arecord -f S16_LE -c 2 -r 12000 -D hw:0,0 -t raw /tmp/testS16_LE.raw
Recording raw data '/tmp/testS16_LE.raw' : Signed 16 bit Little Endian, Rate 12000 Hz, Stereo
Warning: rate is not accurate (requested = 12000Hz, got = 11025Hz)
This patch fixes the audio sample rates declared and supported by the driver according to the H3 data sheet.
Specifically for audio playback:
8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 96000, 192000
and for audio capture:
8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000
Signed-off-by: Andrea Bondavalli <andrea.bondavalli74@gmail.com>
---
sound/soc/sunxi/sun4i-codec.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 5da4efe..c79e8a4 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -590,12 +590,28 @@ static int sun4i_codec_hw_params(struct snd_pcm_substream *substream,
hwrate);
}
+
+static unsigned int sun4i_codec_src_rates[] = {
+ 8000, 11025, 12000, 16000, 22050, 24000, 32000,
+ 44100, 48000, 96000, 192000
+};
+
+
+static struct snd_pcm_hw_constraint_list sun4i_codec_constraints = {
+ .count = ARRAY_SIZE(sun4i_codec_src_rates),
+ .list = sun4i_codec_src_rates,
+};
+
+
static int sun4i_codec_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct sun4i_codec *scodec = snd_soc_card_get_drvdata(rtd->card);
+ snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE, &sun4i_codec_constraints);
+
/*
* Stop issuing DRQ when we have room for less than 16 samples
* in our TX FIFO
@@ -633,9 +649,7 @@ static struct snd_soc_dai_driver sun4i_codec_dai = {
.channels_max = 2,
.rate_min = 8000,
.rate_max = 192000,
- .rates = SNDRV_PCM_RATE_8000_48000 |
- SNDRV_PCM_RATE_96000 |
- SNDRV_PCM_RATE_192000,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
.sig_bits = 24,
@@ -645,11 +659,8 @@ static struct snd_soc_dai_driver sun4i_codec_dai = {
.channels_min = 1,
.channels_max = 2,
.rate_min = 8000,
- .rate_max = 192000,
- .rates = SNDRV_PCM_RATE_8000_48000 |
- SNDRV_PCM_RATE_96000 |
- SNDRV_PCM_RATE_192000 |
- SNDRV_PCM_RATE_KNOT,
+ .rate_max = 48000,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
.sig_bits = 24,
@@ -1128,7 +1139,7 @@ static const struct snd_soc_component_driver sun4i_codec_component = {
.name = "sun4i-codec",
};
-#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_8000_192000
+#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_CONTINUOUS
#define SUN4I_CODEC_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S32_LE)
--
2.7.4
^ permalink raw reply related
* [PATCH v2] arm64: dts: Hi3660: Fix up psci state id
From: Leo Yan @ 2017-12-12 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
idle state. From ftrace log we can observe CA73 CPUs can be easily
waken up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle
anything and sleep again; so there have tons of trace events for CA73
CPUs entering and exiting idle state.
On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
set its psci parameter as '0x0000001' and from this parameter it can
calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
takes 1 as a invalid value for state id, so the CPU cannot enter idle
state and directly bail out to kernel.
We want to create good practice for psci parameters platform definition,
so review the psci specification. The spec "ARM Power State Coordination
Interface - Platform Design Document (ARM DEN 0022D)" recommends state
ID in chapter "6.5 Recommended StateID Encoding". The recommended power
state IDs can be presented by below listed values; and it divides into
three fields, every field can use 4 bits to present power states
corresponding to core level, cluster level and system level:
0: Run
1: Standby
2: Retention
3: Powerdown
This commit changes psci parameter to compliance with the suggested
state ID in the doc. Except we change 'CPU_NAP' state psci parameter
to '0x0000002', this commit also changes 'CPU_SLEEP' and 'CLUSTER_SLEEP'
state parameters to '0x0010003' and '0x1010033' respectively.
Credits to Daniel, Sudeep and Soby for suggestion and consolidation.
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Soby Mathew <Soby.Mathew@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ab0b95b..99d5a46 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -147,7 +147,7 @@
CPU_NAP: cpu-nap {
compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0000001>;
+ arm,psci-suspend-param = <0x0000002>;
entry-latency-us = <7>;
exit-latency-us = <2>;
min-residency-us = <15>;
@@ -156,7 +156,7 @@
CPU_SLEEP: cpu-sleep {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x0010000>;
+ arm,psci-suspend-param = <0x0010003>;
entry-latency-us = <40>;
exit-latency-us = <70>;
min-residency-us = <3000>;
@@ -165,7 +165,7 @@
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <500>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
@@ -174,7 +174,7 @@
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <1000>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v7 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer
From: Auger Eric @ 2017-12-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-8-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The VGIC can now support the life-cycle of mapped level-triggered
> interrupts, and we no longer have to read back the timer state on every
> exit from the VM if we had an asserted timer interrupt signal, because
> the VGIC already knows if we hit the unlikely case where the guest
> disables the timer without ACKing the virtual timer interrupt.
>
> This means we rework a bit of the code to factor out the functionality
> to snapshot the timer state from vtimer_save_state(), and we can reuse
> this functionality in the sync path when we have an irqchip in
> userspace, and also to support our implementation of the
> get_input_level() function for the timer.
>
> This change also means that we can no longer rely on the timer's view of
> the interrupt line to set the active state, because we no longer
> maintain this state for mapped interrupts when exiting from the guest.
> Instead, we only set the active state if the virtual interrupt is
> active, and otherwise we simply let the timer fire again and raise the
> virtual interrupt from the ISR.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> include/kvm/arm_arch_timer.h | 2 ++
> virt/kvm/arm/arch_timer.c | 75 +++++++++++++++++++++-----------------------
> 2 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index 01ee473517e2..f57f795d704c 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -90,6 +90,8 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>
> void kvm_timer_init_vhe(void);
>
> +bool kvm_arch_timer_get_input_level(int vintid);
> +
> #define vcpu_vtimer(v) (&(v)->arch.timer_cpu.vtimer)
> #define vcpu_ptimer(v) (&(v)->arch.timer_cpu.ptimer)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index e78ba5e20f74..82d4963f63b8 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -343,6 +343,12 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> phys_timer_emulate(vcpu);
> }
>
> +static void __timer_snapshot_state(struct arch_timer_context *timer)
> +{
> + timer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + timer->cnt_cval = read_sysreg_el0(cntv_cval);
> +}
> +
> static void vtimer_save_state(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -354,10 +360,8 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
> if (!vtimer->loaded)
> goto out;
>
> - if (timer->enabled) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
> - }
> + if (timer->enabled)
> + __timer_snapshot_state(vtimer);
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> @@ -454,8 +458,7 @@ static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
> bool phys_active;
> int ret;
>
> - phys_active = vtimer->irq.level ||
> - kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
> + phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
>
> ret = irq_set_irqchip_state(host_vtimer_irq,
> IRQCHIP_STATE_ACTIVE,
> @@ -541,27 +544,19 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
> set_cntvoff(0);
> }
>
> -static void unmask_vtimer_irq(struct kvm_vcpu *vcpu)
> +/*
> + * With a userspace irqchip we have to check if the guest de-asserted the
> + * timer and if so, unmask the timer irq signal on the host interrupt
> + * controller to ensure that we see future timer signals.
> + */
> +static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
> - kvm_vtimer_update_mask_user(vcpu);
> - return;
> - }
> -
> - /*
> - * If the guest disabled the timer without acking the interrupt, then
> - * we must make sure the physical and virtual active states are in
> - * sync by deactivating the physical interrupt, because otherwise we
> - * wouldn't see the next timer interrupt in the host.
> - */
> - if (!kvm_vgic_map_is_active(vcpu, vtimer->irq.irq)) {
> - int ret;
> - ret = irq_set_irqchip_state(host_vtimer_irq,
> - IRQCHIP_STATE_ACTIVE,
> - false);
> - WARN_ON(ret);
> + __timer_snapshot_state(vtimer);
> + if (!kvm_timer_should_fire(vtimer))
> + kvm_vtimer_update_mask_user(vcpu);
> }
> }
>
> @@ -574,21 +569,7 @@ static void unmask_vtimer_irq(struct kvm_vcpu *vcpu)
> */
kernel doc comment is not valid anymore:
" Check if any of the timers have expired while we were running in the
guest, and inject an interrupt if that was the case.
Besides, looks good to me
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> {
> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> -
> - /*
> - * If we entered the guest with the vtimer output asserted we have to
> - * check if the guest has modified the timer so that we should lower
> - * the line at this point.
> - */
> - if (vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
> - if (!kvm_timer_should_fire(vtimer)) {
> - kvm_timer_update_irq(vcpu, false, vtimer);
> - unmask_vtimer_irq(vcpu);
> - }
> - }
> + unmask_vtimer_irq_user(vcpu);
> }
>
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> @@ -819,6 +800,22 @@ static bool timer_irqs_are_valid(struct kvm_vcpu *vcpu)
> return true;
> }
>
> +bool kvm_arch_timer_get_input_level(int vintid)
> +{
> + struct kvm_vcpu *vcpu = kvm_arm_get_running_vcpu();
> + struct arch_timer_context *timer;
> +
> + if (vintid == vcpu_vtimer(vcpu)->irq.irq)
> + timer = vcpu_vtimer(vcpu);
> + else
> + BUG(); /* We only map the vtimer so far */
> +
> + if (timer->loaded)
> + __timer_snapshot_state(timer);
> +
> + return kvm_timer_should_fire(timer);
> +}
> +
> int kvm_timer_enable(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -841,7 +838,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> }
>
> ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq,
> - NULL);
> + kvm_arch_timer_get_input_level);
> if (ret)
> return ret;
>
>
^ permalink raw reply
* [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
From: Linus Walleij @ 2017-12-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ef7cfa4-cc1a-f24b-0013-f36db82781e5@arm.com>
On Thu, Nov 30, 2017 at 5:07 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> On 30/11/17 15:51, Linus Walleij wrote:
>> On Sat, Nov 25, 2017 at 1:02 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>>
>>> All of the H5 boards in the kernel reference the MMC0 CD pin twice in
>>> their DT, so strict mode will make the MMC driver fail to load.
>>> To keep existing DTs working, disable strict mode in the H5 driver.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> Reported-by: Chris Obbard <obbardc@gmail.com>
>>
>> Patch applied with Maxime's ACK.
>
> Thanks for that (also to Maxime and Chen-Yu) and the smooth handling!
>
> Sorry, I just see that I didn't point this out explicitly, but this is
> to fix a regression introduced in 4.15-rc1, so is this on a branch that
> will be pushed for 4.15-rc, still? (Couldn't find anything quickly on
> kernel.org)
Should be upstream as:
commit 07c43a382d7de3db01cc28bf2e17ed151cde2046
Yours,
Linus Walleij
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Marek Szyprowski @ 2017-12-12 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=n9PvoYr1xwB8CHBmE00XaTUqT642g7F8nuZd-d031h5Q@mail.gmail.com>
Hi Javier,
On 2017-12-12 09:00, Javier Martinez Canillas wrote:
> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 2017-12-12 00:25, Shuah Khan wrote:
>>> On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
>>>> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>>>>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
>>>>> wrote:
>>>>>> So I gave a quick look to this, and at the very least there's a bug in
>>>>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>>>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>>>>
>>>>>> I've posted a fix for that:
>>>>>>
>>>>>> https://patchwork.kernel.org/patch/10105921/
>>>>>>
>>>>>> I believe this could be also be the cause for the boot failure, since
>>>>>> I see in the boot log that things start to go wrong after exynos-drm
>>>>>> fails to bind the HDMI component:
>>>>>>
>>>>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>>>>> 0xc1398690): -1
>>>>> Umm, -1 ? Looking that error code up in
>>>>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>>>>
>>>>> I suspect that's someone just returning -1 because they're lazy...
>>>>> which is real bad form and needs fixing.
>>>> Oh, it really is -EPERM:
>>>>
>>>> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
>>>> *drm_dev,
>>>> enum exynos_drm_output_type
>>>> out_type)
>>>> {
>>>> struct drm_crtc *crtc;
>>>>
>>>> drm_for_each_crtc(crtc, drm_dev)
>>>> if (to_exynos_crtc(crtc)->type == out_type)
>>>> return to_exynos_crtc(crtc);
>>>>
>>>> return ERR_PTR(-EPERM);
>>>> }
>>>>
>>>> Does "Operation not permitted" really convey the error here? It doesn't
>>>> look like a permission error to me.
>>>>
>>>> Can we please avoid abusing errno codes?
>>> I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
>>> with top commit g968edbd worked just fine for me last Friday. I ran
>>> several
>>> tests and everything checked out except the exynos-gsc lockdep issue I
>>> sent
>>> a 4.14 patch for.
>>>
>>> However, with 4.15-rc3, dmesg is gets filled with
>>>
>>> [ 342.337181] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 342.337470] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 342.337851] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.382346] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.396682] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399244] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399496] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399848] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.400163] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.400495] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.401294] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.401595] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>>
>>> Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
>>>
>>> I will start bisect and try to isolate the problem. I suspect this is
>>> related to dts
>>> changes perhaps? I used to this problem a while back and it has been
>>> fixed.
>>
>> This warning has been added intentionally, see following discussions:
>> https://patchwork.kernel.org/patch/10034919/
>> https://patchwork.kernel.org/patch/10070475/
>>
>> This means that your test apps should be updated or you should enable Exynos
>> IOMMU support in your config. Maybe it is a good time to finally enable it
>> in exynos_defconfig.
>>
> Has the issue that the boot-loader keeps the display controller
> enabled and scanning pages on the Exynos Chromebooks resolved?
>
> I think that's that preventing to enable it by default in
> exynos_defconfig since it caused boot failures when enabled on these
> machines. I don't follow exynos development too closely nowadays so
> maybe there's a fix in place now.
Not directly. I still didn't find time to properly add support for
devices, which were left in-working state (with active DMA
transactions) by bootloader, but due to some other changes in the
order of operations during boot process, power domains are
initialized very early and due to temporary lack of devices (which
are not yet added to the system), are turned off. This practically
stops FIMD for scanning framebuffer and "solves" this issue.
I've checked now and Exynos Snow Chromebook boots fine with IOMMU
support enabled, both with v4.15-rc3 and linux-next.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v2 17/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
From: Geert Uytterhoeven @ 2017-12-12 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512059986-21325-18-git-send-email-will.deacon@arm.com>
Hi Will,
On Thu, Nov 30, 2017 at 5:39 PM, Will Deacon <will.deacon@arm.com> wrote:
> Add a Kconfig entry to control use of the entry trampoline, which allows
> us to unmap the kernel whilst running in userspace and improve the
> robustness of KASLR.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
This is now commit 084eb77cd3a81134 in arm64/for-next/core.
> ---
> arch/arm64/Kconfig | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fdcc7b9bb15d..3af1657fcac3 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -833,6 +833,19 @@ config FORCE_MAX_ZONEORDER
> However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
> 4M allocations matching the default size used by generic code.
>
> +config UNMAP_KERNEL_AT_EL0
> + bool "Unmap kernel when running in userspace (aka \"KAISER\")"
But I believe this is no longer called KAISER?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-7-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> For mapped IRQs (with the HW bit set in the LR) we have to follow some
> rules of the architecture. One of these rules is that VM must not be
> allowed to deactivate a virtual interrupt with the HW bit set unless the
> physical interrupt is also active.
>
> This works fine when injecting mapped interrupts, because we leave it up
> to the injector to either set EOImode==1 or manually set the active
> state of the physical interrupt.
>
> However, the guest can set virtual interrupt to be pending or active by
> writing to the virtual distributor, which could lead to deactivating a
> virtual interrupt with the HW bit set without the physical interrupt
> being active.
>
> We could set the physical interrupt to active whenever we are about to
> enter the VM with a HW interrupt either pending or active, but that
> would be really slow, especially on GICv2. So we take the long way
> around and do the hard work when needed, which is expected to be
> extremely rare.
>
> When the VM sets the pending state for a HW interrupt on the virtual
> distributor we set the active state on the physical distributor, because
> the virtual interrupt can become active and then the guest can
> deactivate it.
>
> When the VM clears the pending state we also clear it on the physical
> side, because the injector might otherwise raise the interrupt. We also
> clear the physical active state when the virtual interrupt is not
> active, since otherwise a SPEND/CPEND sequence from the guest would
> prevent signaling of future interrupts.
>
> Changing the state of mapped interrupts from userspace is not supported,
> and it's expected that userspace unmaps devices from VFIO before
> attempting to set the interrupt state, because the interrupt state is
> driven by hardware.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/vgic/vgic-mmio.c | 71 +++++++++++++++++++++++++++++++++++++++----
> virt/kvm/arm/vgic/vgic.c | 7 +++++
> virt/kvm/arm/vgic/vgic.h | 1 +
> 3 files changed, 73 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index fdad95f62fa3..83d82bd7dc4e 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -16,6 +16,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <kvm/iodev.h>
> +#include <kvm/arm_arch_timer.h>
> #include <kvm/arm_vgic.h>
>
> #include "vgic.h"
> @@ -143,10 +144,22 @@ static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
> return vcpu;
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_spending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->pending_latch = true;
> + vgic_irq_set_phys_active(irq, true);
> +}
> +
> void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val)
> {
> + bool is_uaccess = !vgic_get_mmio_requester_vcpu();
> u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> int i;
> unsigned long flags;
> @@ -155,17 +168,45 @@ void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
> struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>
> spin_lock_irqsave(&irq->irq_lock, flags);
> - irq->pending_latch = true;
> -
> + if (irq->hw)
> + vgic_hw_irq_spending(vcpu, irq, is_uaccess);
> + else
> + irq->pending_latch = true;
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_cpending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->pending_latch = false;
> +
> + /*
> + * We don't want the guest to effectively mask the physical
> + * interrupt by doing a write to SPENDR followed by a write to
> + * CPENDR for HW interrupts, so we clear the active state on
> + * the physical side if the virtual interrupt is not active.
> + * This may lead to taking an additional interrupt on the
> + * host, but that should not be a problem as the worst that
> + * can happen is an additional vgic injection. We also clear
> + * the pending state to maintain proper semantics for edge HW
> + * interrupts.
> + */
> + vgic_irq_set_phys_pending(irq, false);
> + if (!irq->active)
> + vgic_irq_set_phys_active(irq, false);
> +}
> +
> void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val)
> {
> + bool is_uaccess = !vgic_get_mmio_requester_vcpu();
> u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> int i;
> unsigned long flags;
> @@ -175,7 +216,10 @@ void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,
>
> spin_lock_irqsave(&irq->irq_lock, flags);
>
> - irq->pending_latch = false;
> + if (irq->hw)
> + vgic_hw_irq_cpending(vcpu, irq, is_uaccess);
> + else
> + irq->pending_latch = false;
>
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> @@ -202,8 +246,19 @@ unsigned long vgic_mmio_read_active(struct kvm_vcpu *vcpu,
> return value;
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool active, bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->active = active;
> + vgic_irq_set_phys_active(irq, active);
> +}
> +
> static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> - bool new_active_state)
> + bool active)
> {
> unsigned long flags;
> struct kvm_vcpu *requester_vcpu = vgic_get_mmio_requester_vcpu();
> @@ -231,8 +286,12 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> irq->vcpu->cpu != -1) /* VCPU thread is running */
> cond_resched_lock(&irq->irq_lock);
>
> - irq->active = new_active_state;
> - if (new_active_state)
> + if (irq->hw)
> + vgic_hw_irq_change_active(vcpu, irq, active, !requester_vcpu);
> + else
> + irq->active = active;
> +
> + if (irq->active)
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> else
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index eadabb249d2a..f4c92fae9cd3 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -144,6 +144,13 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
> kfree(irq);
> }
>
> +void vgic_irq_set_phys_pending(struct vgic_irq *irq, bool pending)
> +{
> + WARN_ON(irq_set_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_PENDING,
> + pending));
> +}
> +
> /* Get the input level of a mapped IRQ directly from the physical GIC */
> bool vgic_get_phys_line_level(struct vgic_irq *irq)
> {
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index d0787983a357..12c37b89f7a3 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -146,6 +146,7 @@ struct vgic_irq *vgic_get_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> u32 intid);
> void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq);
> bool vgic_get_phys_line_level(struct vgic_irq *irq);
> +void vgic_irq_set_phys_pending(struct vgic_irq *irq, bool pending);
> void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active);
> bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
> unsigned long flags);
>
^ permalink raw reply
* [PATCH v7 5/8] KVM: arm/arm64: Support a vgic interrupt line level sample function
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-6-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The GIC sometimes need to sample the physical line of a mapped
> interrupt. As we know this to be notoriously slow, provide a callback
> function for devices (such as the timer) which can do this much faster
> than talking to the distributor, for example by comparing a few
> in-memory values. Fall back to the good old method of poking the
> physical GIC if no callback is provided.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> include/kvm/arm_vgic.h | 13 ++++++++++++-
> virt/kvm/arm/arch_timer.c | 3 ++-
> virt/kvm/arm/vgic/vgic.c | 12 +++++++++---
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 8c896540a72c..cdbd142ca7f2 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -130,6 +130,17 @@ struct vgic_irq {
> u8 priority;
> enum vgic_irq_config config; /* Level or edge */
>
> + /*
> + * Callback function pointer to in-kernel devices that can tell us the
> + * state of the input level of mapped level-triggered IRQ faster than
> + * peaking into the physical GIC.
> + *
> + * Always called in non-preemptible section and the functions can use
> + * kvm_arm_get_running_vcpu() to get the vcpu pointer for private
> + * IRQs.
> + */
> + bool (*get_input_level)(int vintid);
> +
> void *owner; /* Opaque pointer to reserve an interrupt
> for in-kernel devices. */
> };
> @@ -331,7 +342,7 @@ void kvm_vgic_init_cpu_hardware(void);
> int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
> bool level, void *owner);
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> - u32 vintid);
> + u32 vintid, bool (*get_input_level)(int vindid));
> int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int vintid);
> bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, unsigned int vintid);
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index dd5aca05c500..e78ba5e20f74 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -840,7 +840,8 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> return -EINVAL;
> }
>
> - ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq);
> + ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq,
> + NULL);
> if (ret)
> return ret;
>
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index 607cbbc27a1c..eadabb249d2a 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
Nit: the comment "Get the input level of a mapped IRQ directly from the
physical GIC" is not strictly correct anymore
> @@ -151,6 +151,9 @@ bool vgic_get_phys_line_level(struct vgic_irq *irq)
>
> BUG_ON(!irq->hw);
>
> + if (irq->get_input_level)
> + return irq->get_input_level(irq->intid);
> +
> WARN_ON(irq_get_irqchip_state(irq->host_irq,
> IRQCHIP_STATE_PENDING,
> &line_level));
> @@ -436,7 +439,8 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
>
> /* @irq->irq_lock must be held */
> static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> - unsigned int host_irq)
> + unsigned int host_irq,
> + bool (*get_input_level)(int vindid))
> {
> struct irq_desc *desc;
> struct irq_data *data;
> @@ -456,6 +460,7 @@ static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> irq->hw = true;
> irq->host_irq = host_irq;
> irq->hwintid = data->hwirq;
> + irq->get_input_level = get_input_level;
> return 0;
> }
>
> @@ -464,10 +469,11 @@ static inline void kvm_vgic_unmap_irq(struct vgic_irq *irq)
> {
> irq->hw = false;
> irq->hwintid = 0;
> + irq->get_input_level = NULL;
> }
>
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> - u32 vintid)
> + u32 vintid, bool (*get_input_level)(int vindid))
> {
> struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, vintid);
> unsigned long flags;
> @@ -476,7 +482,7 @@ int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> BUG_ON(!irq);
>
> spin_lock_irqsave(&irq->irq_lock, flags);
> - ret = kvm_vgic_map_irq(vcpu, irq, host_irq);
> + ret = kvm_vgic_map_irq(vcpu, irq, host_irq, get_input_level);
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
>
>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
^ permalink raw reply
* [PATCH v7 4/8] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-5-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> Level-triggered mapped IRQs are special because we only observe rising
> edges as input to the VGIC, and we don't set the EOI flag and therefore
> are not told when the level goes down, so that we can re-queue a new
> interrupt when the level goes up.
>
> One way to solve this problem is to side-step the logic of the VGIC and
> special case the validation in the injection path, but it has the
> unfortunate drawback of having to peak into the physical GIC state
> whenever we want to know if the interrupt is pending on the virtual
> distributor.
>
> Instead, we can maintain the current semantics of a level triggered
> interrupt by sort of treating it as an edge-triggered interrupt,
> following from the fact that we only observe an asserting edge. This
> requires us to be a bit careful when populating the LRs and when folding
> the state back in though:
>
> * We lower the line level when populating the LR, so that when
> subsequently observing an asserting edge, the VGIC will do the right
> thing.
>
> * If the guest never acked the interrupt while running (for example if
> it had masked interrupts at the CPU level while running), we have
> to preserve the pending state of the LR and move it back to the
> line_level field of the struct irq when folding LR state.
>
> If the guest never acked the interrupt while running, but changed the
> device state and lowered the line (again with interrupts masked) then
> we need to observe this change in the line_level.
>
> Both of the above situations are solved by sampling the physical line
> and set the line level when folding the LR back.
>
> * Finally, if the guest never acked the interrupt while running and
> sampling the line reveals that the device state has changed and the
> line has been lowered, we must clear the physical active state, since
> we will otherwise never be told when the interrupt becomes asserted
> again.
>
> This has the added benefit of making the timer optimization patches
> (https://lists.cs.columbia.edu/pipermail/kvmarm/2017-July/026343.html) a
> bit simpler, because the timer code doesn't have to clear the active
> state on the sync anymore. It also potentially improves the performance
> of the timer implementation because the GIC knows the state or the LR
> and only needs to clear the
> active state when the pending bit in the LR is still set, where the
> timer has to always clear it when returning from running the guest with
> an injected timer interrupt.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Looks good to me.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/vgic/vgic-v2.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.c | 23 +++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.h | 7 +++++++
> 4 files changed, 88 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 80897102da26..c32d7b93ffd1 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -105,6 +105,26 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
> irq->pending_latch = false;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only
> + * observe rising edges as input to the VGIC.
> + *
> + * If the guest never acked the interrupt we have to sample
> + * the physical line and set the line level, because the
> + * device state could have changed or we simply need to
> + * process the still pending interrupt later.
> + *
> + * If this causes us to lower the level, we have to also clear
> + * the physical active state, since we will otherwise never be
> + * told when the interrupt becomes asserted again.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) {
> + irq->line_level = vgic_get_phys_line_level(irq);
> +
> + if (!irq->line_level)
> + vgic_irq_set_phys_active(irq, false);
> + }
> +
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> @@ -162,6 +182,15 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
> val |= GICH_LR_EOI;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only observe
> + * rising edges as input to the VGIC. We therefore lower the line
> + * level here, so that we can take new virtual IRQs. See
> + * vgic_v2_fold_lr_state for more info.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT))
> + irq->line_level = false;
> +
> /* The GICv2 LR only holds five bits of priority. */
> val |= (irq->priority >> 3) << GICH_LR_PRIORITY_SHIFT;
>
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 2f05f732d3fd..a14423a0d383 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -96,6 +96,26 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
> irq->pending_latch = false;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only
> + * observe rising edges as input to the VGIC.
> + *
> + * If the guest never acked the interrupt we have to sample
> + * the physical line and set the line level, because the
> + * device state could have changed or we simply need to
> + * process the still pending interrupt later.
> + *
> + * If this causes us to lower the level, we have to also clear
> + * the physical active state, since we will otherwise never be
> + * told when the interrupt becomes asserted again.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT)) {
> + irq->line_level = vgic_get_phys_line_level(irq);
> +
> + if (!irq->line_level)
> + vgic_irq_set_phys_active(irq, false);
> + }
> +
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> @@ -145,6 +165,15 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
> val |= ICH_LR_EOI;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only observe
> + * rising edges as input to the VGIC. We therefore lower the line
> + * level here, so that we can take new virtual IRQs. See
> + * vgic_v3_fold_lr_state for more info.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT))
> + irq->line_level = false;
> +
> /*
> * We currently only support Group1 interrupts, which is a
> * known defect. This needs to be addressed at some point.
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index b168a328a9e0..607cbbc27a1c 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -144,6 +144,29 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
> kfree(irq);
> }
>
> +/* Get the input level of a mapped IRQ directly from the physical GIC */
> +bool vgic_get_phys_line_level(struct vgic_irq *irq)
> +{
> + bool line_level;
> +
> + BUG_ON(!irq->hw);
> +
> + WARN_ON(irq_get_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_PENDING,
> + &line_level));
> + return line_level;
> +}
> +
> +/* Set/Clear the physical active state */
> +void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active)
> +{
> +
> + BUG_ON(!irq->hw);
> + WARN_ON(irq_set_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_ACTIVE,
> + active));
> +}
> +
> /**
> * kvm_vgic_target_oracle - compute the target vcpu for an irq
> *
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index efbcf8f96f9c..d0787983a357 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -104,6 +104,11 @@ static inline bool irq_is_pending(struct vgic_irq *irq)
> return irq->pending_latch || irq->line_level;
> }
>
> +static inline bool vgic_irq_is_mapped_level(struct vgic_irq *irq)
> +{
> + return irq->config == VGIC_CONFIG_LEVEL && irq->hw;
> +}
> +
> /*
> * This struct provides an intermediate representation of the fields contained
> * in the GICH_VMCR and ICH_VMCR registers, such that code exporting the GIC
> @@ -140,6 +145,8 @@ vgic_get_mmio_region(struct kvm_vcpu *vcpu, struct vgic_io_device *iodev,
> struct vgic_irq *vgic_get_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> u32 intid);
> void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq);
> +bool vgic_get_phys_line_level(struct vgic_irq *irq);
> +void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active);
> bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
> unsigned long flags);
> void vgic_kick_vcpus(struct kvm *kvm);
>
^ permalink raw reply
* [PATCH v7 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <24ae6f9e-8f83-6b95-a7a0-d900c37b4a7f@redhat.com>
On 11/12/17 21:51, Auger Eric wrote:
> Hi Christoffer,
> On 07/12/17 11:54, Christoffer Dall wrote:
>> The timer was modeled after a strict idea of modelling an interrupt line
>> level in software, meaning that only transitions in the level needed to
>> be reported to the VGIC. This works well for the timer, because the
>> arch timer code is in complete control of the device and can track the
>> transitions of the line.
>>
>> However, as we are about to support using the HW bit in the VGIC not
>> just for the timer, but also for VFIO which cannot track transitions of
>> the interrupt line, we have to decide on an interface for level
>> triggered mapped interrupts to the GIC, which both the timer and VFIO
>> can use.
>>
>> VFIO only sees an asserting transition of the physical interrupt line,
>> and tells the VGIC when that happens. That means that part of the
>> interrupt flow is offloaded to the hardware.
>>
>> To use the same interface for VFIO devices and the timer, we therefore
>> have to change the timer (we cannot change VFIO because it doesn't know
>> the details of the device it is assigning to a VM).
>>
>> Luckily, changing the timer is simple, we just need to stop 'caching'
>> the line level, but instead let the VGIC know the state of the timer
>> every time there is a potential change in the line level, and when the
>> line level should be asserted from the timer ISR. The VGIC can ignore
>> extra notifications using its validate mechanism.
>
> I was confused by the fact we say we stop caching the line level but
> vtimer->irq.level still exists, is updated in the vtimer host ISR and
> kvm_timer_update_state() and read in many places.
>
> I feel difficult to figure out if each time we use the vtimer->irq.level
> value it is safe to use it.
>
> Also for the validate() to succeed we need the vgic irq->line_level to
> to be 0. I understand this is properly handled for mapped level irqs in
> next patch which does that on the populate_lr. However I currently fail
> to understand why the timer level sensitive mapped IRQ does not require
> the next patch to work.
OK reading again "[PATCH v7 7/8] KVM: arm/arm64: Provide a
get_input_level for the arch timer", I now understand it works because
we had the
kvm_timer_sync_hwstate toggling down the line on VM exit. After the
changes of next patch this can be safely removed.
Not related to this patch but I noticed
Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt now is outdated.
>
> Thanks
>
> Eric
>
>>
>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 4151250ce8da..dd5aca05c500 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> }
>> vtimer = vcpu_vtimer(vcpu);
>>
>> - if (!vtimer->irq.level) {
>> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> - if (kvm_timer_irq_can_fire(vtimer))
>> - kvm_timer_update_irq(vcpu, true, vtimer);
>> - }
>> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> + if (kvm_timer_irq_can_fire(vtimer))
>> + kvm_timer_update_irq(vcpu, true, vtimer);
>>
>> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
>> kvm_vtimer_update_mask_user(vcpu);
>> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> + bool level;
>>
>> if (unlikely(!timer->enabled))
>> return;
>>
>> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
>> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
>> + /*
>> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
>> + * of its lifecycle is offloaded to the hardware, and we therefore may
>> + * not have lowered the irq.level value before having to signal a new
>> + * interrupt, but have to signal an interrupt every time the level is
>> + * asserted.
>> + */
>> + level = kvm_timer_should_fire(vtimer);
>> + kvm_timer_update_irq(vcpu, level, vtimer);
>>
>> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
>> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>>
^ permalink raw reply
* [PATCH 1/4] ASoC: sun4i-i2s: Add support for A83T
From: Maxime Ripard @ 2017-12-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-2-wens@csie.org>
On Tue, Dec 12, 2017 at 04:11:45PM +0800, Chen-Yu Tsai wrote:
> The I2S controller in the A83T is mostly compatible with the one found
> in earlier SoCs such as the A20 and A31. While the documents publicly
> available for the A83T do not cover this hardware, the officially
> released BSP kernel does have register definitions for it. These were
> matched against the A20 user manual. The only difference is the TX FIFO
> and interrupt status registers have been swapped around, like what we
> have seen with the SPDIF controller.
>
> This patch adds support for this hardware.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/af34a175/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] [DO NOT MERGE] ARM: dts: sun8i: a83t: bpi-m3: Enable PCM5122 codec with I2S1
From: Maxime Ripard @ 2017-12-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-5-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:48PM +0800, Chen-Yu Tsai wrote:
> This patch enables a PiFi DAC+ V2.0, which is a PCM5122-based audio
> output DAC add-on board for the Raspberry Pi B+ and later, connected
> to the GPIO header of the Bananapi M3 via jumper cables. The power,
> ground, and I2C pins are in the same position, but the I2S ones are
> not.
>
> The I2C controller used is I2C2, while the I2S controller is I2S1.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>
> I'm sure I've asked this before, and IIRC the answer was yes: The I2C
> controllers available on the GPIO header all have proper, always-on,
> external pull-ups. Does that mean we can enable them by default, seeing
> as they are likely intended to be used this way (as I2C pins)?
>
> I think we have a few boards where either I2C or UARTs on the GPIO
> header are enabled by default.
The consensus we reached that we would fill the nodes, but leave them
disabled.
In this particular case, I guess it would help for the i2c controller,
but not for the i2s one.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/02cf0807/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings
From: Maxime Ripard @ 2017-12-12 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-4-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:47PM +0800, Chen-Yu Tsai wrote:
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
Same remark than for Mylene's patch here, you should have a per-SoC
compatible first.
Once fixed,
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/4e78d8eb/attachment.sig>
^ permalink raw reply
* [PATCH 2/4] ARM: dts: sun8i: a83t: Add I2S controller device nodes
From: Maxime Ripard @ 2017-12-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-3-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:46PM +0800, Chen-Yu Tsai wrote:
> The A83T has 3 I2S controllers. The first is multiplexed with the TDM
> controller. The pins are generally connected to the codec side of the
> AXP81x PMIC/codec/RTC chip. The second is free for other uses. The
> third only supports output, and is connected internally to the HDMI
> controller for HDMI audio output.
>
> This patch adds device nodes for the controllers, and a default pinmux
> setting for the second controller.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/9a112455/attachment.sig>
^ permalink raw reply
* [RFC PATCH][resend] pciehp: fix a race between pciehp and removing operations by sysfs
From: Xiongfeng Wang @ 2017-12-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
When the Attention button on a PCIE slot is pressed, 5 seconds later,
pciehp_power_thread() will be scheduled on slot->wq. This function will
get a global mutex lock 'pci_rescan_remove_lock' in
pciehp_unconfigure_device().
At the same time, we remove the pcie port by sysfs, which results in
pci_stop_and_remove_bus_device_locked() called. This function will get
the global mutex lock 'pci_rescan_remove_lock', and then release the
struct 'ctrl', which will wait until the work_struct on slot->wq is
finished.
If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
on slot->wq and tries to get the mutex lock. Then
pci_stop_and_remove_bus_device_locked() tries to drain workqueue
slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
Then a hung_task happens.
This patch solve this problem by schedule 'pciehp_power_thread()' on a
system workqueue instead of slot->wq.
The Call Trace we got is as following.
INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:2 D 0 4413 2 0x00000000
Workqueue: pciehp-0 pciehp_power_thread
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008beb33c>] schedule_preempt_disabled+0x28/0x40
[<ffff000008bec1dc>] __mutex_lock.isra.8+0x148/0x50c
[<ffff000008bec5c4>] __mutex_lock_slowpath+0x24/0x30
[<ffff000008bec618>] mutex_lock+0x48/0x54
[<ffff0000084d8188>] pci_lock_rescan_remove+0x20/0x28
[<ffff0000084f87c0>] pciehp_unconfigure_device+0x54/0x1cc
[<ffff0000084f8260>] pciehp_disable_slot+0x4c/0xbc
[<ffff0000084f8370>] pciehp_power_thread+0xa0/0xb8
[<ffff0000080e9ce8>] process_one_work+0x13c/0x3f8
[<ffff0000080ea004>] worker_thread+0x60/0x3e4
[<ffff0000080f0814>] kthread+0x10c/0x138
[<ffff0000080836c0>] ret_from_fork+0x10/0x50
INFO: task bash:31732 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0 31732 1 0x00000009
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008bee7b4>] schedule_timeout+0x1a0/0x340
[<ffff000008bebb88>] wait_for_common+0x108/0x1bc
[<ffff000008bebc64>] wait_for_completion+0x28/0x34
[<ffff0000080e7594>] flush_workqueue+0x130/0x488
[<ffff0000080e79b0>] drain_workqueue+0xc4/0x164
[<ffff0000080ec3cc>] destroy_workqueue+0x28/0x1f4
[<ffff0000084fa094>] pciehp_release_ctrl+0x34/0xe0
[<ffff0000084f75b0>] pciehp_remove+0x30/0x3c
[<ffff0000084f24d8>] pcie_port_remove_service+0x3c/0x54
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff00000876a018>] bus_remove_device+0xe0/0x11c
[<ffff000008766348>] device_del+0x200/0x304
[<ffff00000876646c>] device_unregister+0x20/0x38
[<ffff0000084f2560>] remove_iter+0x44/0x54
[<ffff000008765230>] device_for_each_child+0x4c/0x90
[<ffff0000084f2c98>] pcie_port_device_remove+0x2c/0x48
[<ffff0000084f2f48>] pcie_portdrv_remove+0x60/0x6c
[<ffff0000084e3de4>] pci_device_remove+0x48/0x110
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff0000084db028>] pci_stop_bus_device+0x9c/0xac
[<ffff0000084db190>] pci_stop_and_remove_bus_device_locked+0x24/0x3c
[<ffff0000084e5eb0>] remove_store+0x74/0x80
[<ffff000008764680>] dev_attr_store+0x44/0x5c
[<ffff0000082e7e1c>] sysfs_kf_write+0x5c/0x74
[<ffff0000082e7014>] kernfs_fop_write+0xcc/0x1dc
[<ffff0000082602e0>] __vfs_write+0x48/0x13c
[<ffff00000826174c>] vfs_write+0xa8/0x198
[<ffff000008262ce8>] SyS_write+0x54/0xb0
[<ffff000008083730>] el0_svc_naked+0x24/0x28
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
---
drivers/pci/hotplug/pciehp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index 83f3d4a..9d39d85 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -221,7 +221,7 @@ static void pciehp_queue_power_work(struct slot *p_slot, int req)
info->p_slot = p_slot;
INIT_WORK(&info->work, pciehp_power_thread);
info->req = req;
- queue_work(p_slot->wq, &info->work);
+ schedule_work(&info->work);
}
void pciehp_queue_pushbutton_work(struct work_struct *work)
--
1.7.12.4
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-12 8:27 UTC (permalink / raw)
To: linux-arm-kernel
Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Based on renesas-devel-20171211-v4.15-rc3
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a851c88e1e04..62dfc7781cc1 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -30,11 +30,6 @@
i2c7 = &i2c_dvfs;
};
- psci {
- compatible = "arm,psci-1.0", "arm,psci-0.2";
- method = "smc";
- };
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -208,6 +203,11 @@
<&a53_3>;
};
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
+ };
+
soc: soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Add reg properties to pciec[01] placeholder nodes
This is to stop the compiler complaining as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index bf971979aba8..388229072050 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1762,10 +1762,12 @@
};
pciec0: pcie at fe000000 {
+ reg = <0 0xfe000000 0 0x80000>;
/* placeholder */
};
pciec1: pcie at ee800000 {
+ reg = <0 0xee800000 0 0x80000>;
/* placeholder */
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.
This problem is flagged by the compiler as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 156 ++++++++++++++++---------------
1 file changed, 80 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c1b0d0344329..bf971979aba8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -154,6 +154,26 @@
clock-frequency = <0>;
};
+ pmu_a57 {
+ compatible = "arm,cortex-a57-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a57_0>,
+ <&a57_1>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a53_0>,
+ <&a53_1>,
+ <&a53_2>,
+ <&a53_3>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -190,18 +210,6 @@
resets = <&cpg 408>;
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
wdt0: watchdog at e6020000 {
compatible = "renesas,r8a7796-wdt",
"renesas,rcar-gen3-wdt";
@@ -337,26 +345,6 @@
reg = <0 0xe6060000 0 0x50c>;
};
- pmu_a57 {
- compatible = "arm,cortex-a57-pmu";
- interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a57_0>,
- <&a57_1>;
- };
-
- pmu_a53 {
- compatible = "arm,cortex-a53-pmu";
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a53_0>,
- <&a53_1>,
- <&a53_2>,
- <&a53_3>;
- };
-
ipmmu_vi0: mmu at febd0000 {
compatible = "renesas,ipmmu-r8a7796";
reg = <0 0xfebd0000 0 0x1000>;
@@ -1577,50 +1565,6 @@
status = "okay";
};
- thermal-zones {
- sensor_thermal1: sensor-thermal1 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
-
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal2: sensor-thermal2 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 1>;
-
- trips {
- sensor2_crit: sensor2-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal3: sensor-thermal3 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 2>;
-
- trips {
- sensor3_crit: sensor3-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
- };
-
rcar_sound: sound at ec500000 {
/*
* #sound-dai-cells is required
@@ -2027,4 +1971,64 @@
resets = <&cpg 822>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = <&gic GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ thermal-zones {
+ sensor_thermal1: sensor-thermal1 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal2: sensor-thermal2 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 1>;
+
+ trips {
+ sensor2_crit: sensor2-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal3: sensor-thermal3 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 2>;
+
+ trips {
+ sensor3_crit: sensor3-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 66 ++++++++++++++++----------------
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index cc0cca7c0494..c1b0d0344329 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -30,9 +30,34 @@
i2c7 = &i2c_dvfs;
};
- psci {
- compatible = "arm,psci-1.0", "arm,psci-0.2";
- method = "smc";
+ /*
+ * The external audio clocks are configured as 0 Hz fixed frequency
+ * clocks by default.
+ * Boards that provide audio clocks should override them.
+ */
+ audio_clk_a: audio_clk_a {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_b: audio_clk_b {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_c: audio_clk_c {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
};
cpus {
@@ -122,34 +147,16 @@
clock-frequency = <0>;
};
- /*
- * The external audio clocks are configured as 0 Hz fixed frequency
- * clocks by default.
- * Boards that provide audio clocks should override them.
- */
- audio_clk_a: audio_clk_a {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- };
-
- audio_clk_b: audio_clk_b {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- };
-
- audio_clk_c: audio_clk_c {
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <0>;
};
- /* External CAN clock - to be overridden by boards that provide it */
- can_clk: can {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
};
/* External SCIF clock - to be overridden by boards that provide it */
@@ -159,13 +166,6 @@
clock-frequency = <0>;
};
- /* External PCIe clock - can be overridden by the board */
- pcie_bus_clk: pcie_bus {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- };
-
soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: renesas: r8a7796: cleanup of make dtb W=1
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes make dtb W=1 builds clean.
Patch 1 sorts subnodes of the root node into alphabetical order
to... well bring some order to things.
Patch 2 moves nodes without reg properties out of the SoC bus,
this is in keeping with recent work for the r8a7795 SoC.
Patch 3 adds reg property to the place holder peciec[01] nodes
Et voil?, make dtb W=1 no longer emits warnings.
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Based on renesas-devel-20171211-v4.15-rc3
Simon Horman (3):
arm64: dts: renesas: r8a7796: sort subnodes of root node
alphabetically
arm64: dts: renesas: r8a7796: move nodes which have no reg property
out of bus
arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 216 ++++++++++++++++---------------
1 file changed, 111 insertions(+), 105 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Maxime Ripard @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hi,
On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
>
> As we discussed in private, Chen Yu's patch should be added in your series.
Not really, she mentionned the dependency in the cover letter, and
it's a good way to do things too. Sure, you can do it your way, but
there's no preference.
> Furthermore, MCPM is not automaticaly selected via imply.
Well, yes, is that an issue?
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
I guess this is with CONFIG_PROVE_LOCKING enabled?
> [ 0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> [ 0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
What are the changes you've made?
> [ 0.925418] Hardware name: Allwinner sun8i Family
> [ 0.930118] Backtrace:
> [ 0.932596] [<c010cc50>] (dump_backtrace) from [<c010cf0c>] (show_stack+0x18/0x1c)
> [ 0.940158] r7:c0b261e4 r6:60000013 r5:00000000 r4:c0b51958
> [ 0.945820] [<c010cef4>] (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0)
> [ 0.953045] [<c06bac40>] (dump_stack) from [<c0149d40>] (___might_sleep+0x150/0x170)
> [ 0.960779] r7:c0b261e4 r6:00000000 r5:000000ee r4:ee844000
> [ 0.966437] [<c0149bf0>] (___might_sleep) from [<c0149dc8>] (__might_sleep+0x68/0xa0)
> [ 0.974253] r4:c0861690
> [ 0.976796] [<c0149d60>] (__might_sleep) from [<c06d2918>] (mutex_lock+0x24/0x68)
> [ 0.984269] r6:c0892f6c r5:ffffffff r4:c0b1bb24
> [ 0.988891] [<c06d28f4>] (mutex_lock) from [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4)
> [ 0.996795] r5:ffffffff r4:ee98b014
> [ 1.000375] [<c01ccb48>] (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000
> [ 1.016447] r4:ee98b010
> [ 1.018989] [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.027158] r10:00000000 r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010
> [ 1.037511] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> [ 1.046371] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea19010
> [ 1.052026] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> [ 1.061062] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000
> [ 1.072454] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> [ 1.081228] r7:00000001 r6:c045cb24 r5:ee845ac0 r4:00000000
> [ 1.086883] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010
> [ 1.099750] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> [ 1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> [ 1.113919] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> [ 1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> [ 1.136089] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> [ 1.143564] r10:00000000 r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000
> [ 1.153915] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> [ 1.163210] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> [ 1.173372] r9:00000000 r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> [ 1.190229] r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000 r5:eedf1d04
> [ 1.198045] r4:eedf2154
> [ 1.200580] [<c0583300>] (of_platform_populate) from [<c03ef2a8>] (cci_platform_probe+0x3c/0x54)
> [ 1.209356] r10:00000000 r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00
> [ 1.219708] [<c03ef26c>] (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10
> [ 1.231881] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> [ 1.240742] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea18a10
> [ 1.246397] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> [ 1.255433] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000
> [ 1.266825] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> [ 1.275598] r7:00000001 r6:c045cb24 r5:ee845ce8 r4:00000000
> [ 1.281253] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10
> [ 1.294120] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> [ 1.302633] r7:c0b0a4c8 r6:c0b3e848 r5:eea18a10 r4:eea18a18
> [ 1.308288] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> [ 1.324796] r7:c0b0a4c8 r6:eea18a10 r5:ee993810 r4:eea18a18
> [ 1.330450] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> [ 1.337926] r10:00000000 r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00
> [ 1.348277] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> [ 1.357572] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> [ 1.367734] r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from [<c058315c>] (of_platform_bus_create+0x150/0x1f0)
> [ 1.384938] r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedefe1c
> [ 1.392754] r4:eedf1d04
> [ 1.395289] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> [ 1.404411] r10:00000001 r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c
> [ 1.414769] [<c0583300>] (of_platform_populate) from [<c0a25ee8>] (of_platform_default_populate_init+0x80/0x94)
> [ 1.424844] r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000 r5:c0775ce8
> [ 1.432661] r4:00000000
> [ 1.435200] [<c0a25e68>] (of_platform_default_populate_init) from [<c0102794>] (do_one_initcall+0x5c/0x194)
> [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>] (kernel_init_freeable+0x1d4/0x268)
> [ 1.457195] r9:00000004 r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>] (kernel_init+0x10/0x118)
> [ 1.473187] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0
> [ 1.481004] r4:00000000
> [ 1.483540] [<c06cf3a0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> [ 1.491098] Exception stack(0xee845fb0 to 0xee845ff8)
> [ 1.496146] 5fa0: 00000000 00000000 00000000 00000000
> [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.512480] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 1.519084] r5:c06cf3a0 r4:00000000
> [ 1.522737] ARM CCI_400_r1 PMU driver probed
>
> And only CPU 0 show up.
This looks more like a bug in the CCI code, and not in this serie
itself. Can you share your whole boot logs?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/cc5f0a81/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Keerthy @ 2017-12-12 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081923.GA10084@lenoch>
On Tuesday 12 December 2017 01:49 PM, Ladislav Michl wrote:
> On Tue, Dec 12, 2017 at 01:38:04PM +0530, Keerthy wrote:
>> On Tuesday 12 December 2017 01:31 PM, Ladislav Michl wrote:
>>> On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
>>>>
>>>>
>>>> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
>>>>> Keerthy,
>>>>>
>>>>> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
>>>>>> Remove all the unwanted exports from the driver
>>>>>
>>>>> I'm adding event capture capability to the pwm-omap driver and so far used
>>>>> v4.15-rc3 as codebase.
>>>>>
>>>>> Intended use is an IR receiver; for that I need to measure pulses width and
>>>>> spaces between pulses. So DM timer was setup to generate interupt after
>>>>> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
>>>>> TCAR_IT_FLAG is cleared.
>>>>>
>>>>> Of course, this is just proof of concept and needs to be polished and
>>>>> generalized, but to make it at least work I need functions you just
>>>>> unexported (plus some new).
>>>>>
>>>>> Question is whenever we need this level of indirection (omap_dm_timer_ops)
>>>>> or plain exports are enough.
>>>>
>>>> The general guidance is not to do plain exports and go via
>>>> omap_dm_timer_ops.
>>>
>>> ...in contrary what other clocksource drivers are doing.
>>>
>>> Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
>>> check for ops members to be assigned should be also extended or we should
>>> delete it altogether and assume all members are populated?
>>
>> It should be fine to extend omap_dm_timer_ops. What are the ops missing
>> for your new implementation?
>
> Read capture registers, configure capture and ack interrupt. Perhaps set_pwm
> could be extended to configure capture as well.
>
> I'll update my code on top of your changes and we'll see how it would work.
Okay Thanks!
>
>> Tony,
>>
>> Your thoughts on the above?
>>
>> R
^ permalink raw reply
* [PATCH] mmc: sdhci-of-arasan: Disable clk_xin clock in the remove
From: Flavio Ceolin @ 2017-12-12 8:19 UTC (permalink / raw)
To: linux-arm-kernel
clk_xin is properly prepared/enabled on sdhci_arasan_probe(), and
unprepared/disabled in the error path, but it is not being
unprepared/disabled on sdhci_arasan_remove().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
---
drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 0720ea7..69bd260 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -692,6 +692,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
struct clk *clk_ahb = sdhci_arasan->clk_ahb;
+ struct clk *clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
if (!IS_ERR(sdhci_arasan->phy)) {
if (sdhci_arasan->is_phy_on)
@@ -705,6 +706,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
clk_disable_unprepare(clk_ahb);
+ if (!IS_ERR(clk_xin))
+ clk_disable_unprepare(clk_xin);
+
return ret;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hello Corentin,
Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe <clabbe.montjoie@gmail.com> a ?crit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > Hello everyone,
> >
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> >
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Myl?ne
> >
>
> Hello
>
> As we discussed in private, Chen Yu's patch should be added in your
> series.
Yep, I will do that.
>
> Furthermore, MCPM is not automaticaly selected via imply.
It is selected if you run again a sunxi_defconfig. I guess I can change
to "select".
>
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [ 0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [ 0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [ 0.925418] Hardware name: Allwinner sun8i Family [ 0.930118]
> Backtrace: [ 0.932596] [<c010cc50>] (dump_backtrace) from
> [<c010cf0c>] (show_stack+0x18/0x1c) [ 0.940158] r7:c0b261e4
> r6:60000013 r5:00000000 r4:c0b51958 [ 0.945820] [<c010cef4>]
> (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0) [ 0.953045]
> [<c06bac40>] (dump_stack) from [<c0149d40>]
> (___might_sleep+0x150/0x170) [ 0.960779] r7:c0b261e4 r6:00000000
> r5:000000ee r4:ee844000 [ 0.966437] [<c0149bf0>] (___might_sleep)
> from [<c0149dc8>] (__might_sleep+0x68/0xa0) [ 0.974253]
> r4:c0861690 [ 0.976796] [<c0149d60>] (__might_sleep) from
> [<c06d2918>] (mutex_lock+0x24/0x68) [ 0.984269] r6:c0892f6c
> r5:ffffffff r4:c0b1bb24 [ 0.988891] [<c06d28f4>] (mutex_lock) from
> [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4) [ 0.996795]
> r5:ffffffff r4:ee98b014 [ 1.000375] [<c01ccb48>]
> (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [ 1.016447] r4:ee98b010 [ 1.018989]
> [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>]
> (platform_drv_probe+0x58/0xb8) [ 1.027158] r10:00000000
> r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010 [ 1.037511] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.046371] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea19010 [ 1.052026] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.061062] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000 [ 1.072454] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.081228] r7:00000001 r6:c045cb24
> r5:ee845ac0 r4:00000000 [ 1.086883] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010 [ 1.099750]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.108263] r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [ 1.113919] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.130429] r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [ 1.136089] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.143564] r10:00000000
> r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000 [ 1.153915] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.163210]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.173372] r9:00000000
> r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from
> [<c0583374>] (of_platform_populate+0x74/0xd4) [ 1.190229]
> r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000
> r5:eedf1d04 [ 1.198045] r4:eedf2154 [ 1.200580] [<c0583300>]
> (of_platform_populate) from [<c03ef2a8>]
> (cci_platform_probe+0x3c/0x54) [ 1.209356] r10:00000000
> r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00 [ 1.219708] [<c03ef26c>]
> (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10 [ 1.231881] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.240742] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [ 1.246397] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.255433] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000 [ 1.266825] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.275598] r7:00000001 r6:c045cb24
> r5:ee845ce8 r4:00000000 [ 1.281253] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10 [ 1.294120]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.302633] r7:c0b0a4c8
> r6:c0b3e848 r5:eea18a10 r4:eea18a18 [ 1.308288] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.324796] r7:c0b0a4c8 r6:eea18a10
> r5:ee993810 r4:eea18a18 [ 1.330450] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.337926] r10:00000000
> r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00 [ 1.348277] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.357572]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.367734] r9:c07759d8
> r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from
> [<c058315c>] (of_platform_bus_create+0x150/0x1f0) [ 1.384938]
> r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000
> r5:eedefe1c [ 1.392754] r4:eedf1d04 [ 1.395289] [<c058300c>]
> (of_platform_bus_create) from [<c0583374>]
> (of_platform_populate+0x74/0xd4) [ 1.404411] r10:00000001
> r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c [ 1.414769] [<c0583300>]
> (of_platform_populate) from [<c0a25ee8>]
> (of_platform_default_populate_init+0x80/0x94) [ 1.424844]
> r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000
> r5:c0775ce8 [ 1.432661] r4:00000000 [ 1.435200] [<c0a25e68>]
> (of_platform_default_populate_init) from [<c0102794>]
> (do_one_initcall+0x5c/0x194) [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>]
> (kernel_init_freeable+0x1d4/0x268) [ 1.457195] r9:00000004
> r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>]
> (kernel_init+0x10/0x118) [ 1.473187] r10:00000000 r9:00000000
> r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0 [ 1.481004]
> r4:00000000 [ 1.483540] [<c06cf3a0>] (kernel_init) from
> [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 1.491098] Exception
> stack(0xee845fb0 to 0xee845ff8) [ 1.496146]
> 5fa0: 00000000 00000000 00000000
> 00000000 [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 [ 1.512480] 5fe0: 00000000
> 00000000 00000000 00000000 00000013 00000000 [ 1.519084]
> r5:c06cf3a0 r4:00000000 [ 1.522737] ARM CCI_400_r1 PMU driver
> probed
>
> And only CPU 0 show up.
I am really sorry about that. I tested the patches but not with my last
modifications, I guess...
I will fix it in a V2.
Thank you for reporting the bug.
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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