* [PATCH v3 1/1] KVM: ARM64: Fix the issues when guest PMCCFILTR is configured
From: Marc Zyngier @ 2016-11-17 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117133039.GH22855@arm.com>
On 17/11/16 13:30, Will Deacon wrote:
> On Wed, Nov 16, 2016 at 11:09:20AM -0600, Wei Huang wrote:
>> KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
>> But this function can't deals with PMCCFILTR correctly because the evtCount
>> bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
>> type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
>> function shouldn't return immediately; instead it needs to check further
>> if select_idx is ARMV8_PMU_CYCLE_IDX.
>>
>> Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
>> blindly to attr.config. Instead it ought to convert the request to the
>> "cpu cycle" event type (i.e. 0x11).
>>
>> To support this patch and to prevent duplicated definitions, a limited
>> set of ARMv8 perf event types were relocated from perf_event.c to
>> asm/perf_event.h.
>>
>> Signed-off-by: Wei Huang <wei@redhat.com>
>> ---
>> arch/arm64/include/asm/perf_event.h | 10 +++++++++-
>> arch/arm64/kernel/perf_event.c | 10 +---------
>> virt/kvm/arm/pmu.c | 8 +++++---
>> 3 files changed, 15 insertions(+), 13 deletions(-)
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> I'm assuming this will go via kvm-arm.
Yup, I'll take it. Thanks.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] ARM: shmobile: document SK-RZG1E board
From: Simon Horman @ 2016-11-17 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479387356.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Document the SK-RZG1E device tree bindings, listing it as a supported board.
This allows to use checkpatch.pl to validate .dts files referring to the
SK-RZG1E board.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 0af01f9a01f4..3c7acf22957a 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -77,6 +77,8 @@ Boards:
compatible = "renesas,salvator-x", "renesas,r8a7796";
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
+ - SK-RZG1E (YR8A77450S000BE)
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745"
- SK-RZG1M (YR8A77430S000BE)
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
- Wheat
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 1/2] ARM: shmobile: r8a7745: basic SoC support
From: Simon Horman @ 2016-11-17 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479387356.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Add minimal support for the RZ/G1E (R8A7745) SoC.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
arch/arm/mach-shmobile/Kconfig | 4 ++++
arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 9a60cb38cf56..0af01f9a01f4 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -15,6 +15,8 @@ SoCs:
compatible = "renesas,r8a7740"
- RZ/G1M (R8A77430)
compatible = "renesas,r8a7743"
+ - RZ/G1E (R8A77450)
+ compatible = "renesas,r8a7745"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6fbd9b7d2d67..f0b5e7dfa6d0 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -73,6 +73,10 @@ config ARCH_R8A7743
select ARCH_RCAR_GEN2
select ARM_ERRATA_798181 if SMP
+config ARCH_R8A7745
+ bool "RZ/G1E (R8A77450)"
+ select ARCH_RCAR_GEN2
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index d6b4841e51a9..14c1f0ed2ecb 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -235,6 +235,7 @@ MACHINE_END
static const char * const rz_g1_boards_compat_dt[] __initconst = {
"renesas,r8a7743",
+ "renesas,r8a7745",
NULL,
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Simon Horman @ 2016-11-17 13:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these second round of Renesas ARM based SoC updates for v4.10.
This pull request is based on the previous round of
such requests, tagged as renesas-soc-for-v4.10,
which I have already sent a pull-request for.
The following changes since commit 9652623f8f019edc93a7a934a10b7d0b90421d5a:
ARM: shmobile: r8a7779/marzen: Add board part number to DT bindings (2016-11-04 10:25:45 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v4.10
for you to fetch changes up to 4af239175d00c1866cc6b41f3eabcf93c45dcc40:
ARM: shmobile: document SK-RZG1E board (2016-11-15 10:59:35 +0100)
----------------------------------------------------------------
Second Round of Renesas ARM Based SoC Updates for v4.10
* Basic support for r8a7745 SoC
----------------------------------------------------------------
Sergei Shtylyov (2):
ARM: shmobile: r8a7745: basic SoC support
ARM: shmobile: document SK-RZG1E board
Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
arch/arm/mach-shmobile/Kconfig | 4 ++++
arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
3 files changed, 9 insertions(+)
^ permalink raw reply
* [PATCH v3 1/1] KVM: ARM64: Fix the issues when guest PMCCFILTR is configured
From: Will Deacon @ 2016-11-17 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479316160-8567-1-git-send-email-wei@redhat.com>
On Wed, Nov 16, 2016 at 11:09:20AM -0600, Wei Huang wrote:
> KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
> But this function can't deals with PMCCFILTR correctly because the evtCount
> bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
> type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
> function shouldn't return immediately; instead it needs to check further
> if select_idx is ARMV8_PMU_CYCLE_IDX.
>
> Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
> blindly to attr.config. Instead it ought to convert the request to the
> "cpu cycle" event type (i.e. 0x11).
>
> To support this patch and to prevent duplicated definitions, a limited
> set of ARMv8 perf event types were relocated from perf_event.c to
> asm/perf_event.h.
>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arch/arm64/include/asm/perf_event.h | 10 +++++++++-
> arch/arm64/kernel/perf_event.c | 10 +---------
> virt/kvm/arm/pmu.c | 8 +++++---
> 3 files changed, 15 insertions(+), 13 deletions(-)
Acked-by: Will Deacon <will.deacon@arm.com>
I'm assuming this will go via kvm-arm.
Will
^ permalink raw reply
* i.MX6UL: feature state of linux-fslc 4.1.x vs mainline
From: Nicolae Rosia @ 2016-11-17 12:56 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm wondering if there is a table of missing features that are present
in Linux freescale 4.1.x [0] and are not present in latest mainline
kernel with regards to NXP i.MX6UL SoC.
Is there a reason why I should go with linux-fslc for this SoC ?
Best regards,
Nicolae
[0] https://github.com/Freescale/linux-fslc/tree/4.1-1.0.x-imx
^ permalink raw reply
* [PATCH v8 5/7] arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
From: Vijay Kilari @ 2016-11-17 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116185227.GE3811@cbox>
On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:31PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> ICC_VMCR_EL2 supports virtual access to ICC_IGRPEN1_EL1.Enable
>> and ICC_IGRPEN0_EL1.Enable fields. Add grpen0 and grpen1 member
>> variables to struct vmcr to support read and write of these fields.
>>
>> Also refactor vgic_set_vmcr and vgic_get_vmcr() code.
>> Drop ICH_VMCR_CTLR_SHIFT and ICH_VMCR_CTLR_MASK macros and instead
>> use ICH_VMCR_EOI* and ICH_VMCR_CBPR* macros
>> .
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> ---
>> include/linux/irqchip/arm-gic-v3.h | 2 --
>> virt/kvm/arm/vgic/vgic-mmio-v2.c | 16 ----------------
>> virt/kvm/arm/vgic/vgic-mmio.c | 16 ++++++++++++++++
>> virt/kvm/arm/vgic/vgic-v3.c | 10 ++++++++--
>> virt/kvm/arm/vgic/vgic.h | 5 +++++
>> 5 files changed, 29 insertions(+), 20 deletions(-)
>>
>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
>> index d48d886..61646aa 100644
>> --- a/include/linux/irqchip/arm-gic-v3.h
>> +++ b/include/linux/irqchip/arm-gic-v3.h
>> @@ -404,8 +404,6 @@
>> #define ICH_HCR_EN (1 << 0)
>> #define ICH_HCR_UIE (1 << 1)
>>
>> -#define ICH_VMCR_CTLR_SHIFT 0
>> -#define ICH_VMCR_CTLR_MASK (0x21f << ICH_VMCR_CTLR_SHIFT)
>> #define ICH_VMCR_CBPR_SHIFT 4
>> #define ICH_VMCR_CBPR_MASK (1 << ICH_VMCR_CBPR_SHIFT)
>> #define ICH_VMCR_EOIM_SHIFT 9
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> index 2cb04b7..ad353b5 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> @@ -212,22 +212,6 @@ static void vgic_mmio_write_sgipends(struct kvm_vcpu *vcpu,
>> }
>> }
>>
>> -static void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
>> -{
>> - if (kvm_vgic_global_state.type == VGIC_V2)
>> - vgic_v2_set_vmcr(vcpu, vmcr);
>> - else
>> - vgic_v3_set_vmcr(vcpu, vmcr);
>> -}
>> -
>> -static void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
>> -{
>> - if (kvm_vgic_global_state.type == VGIC_V2)
>> - vgic_v2_get_vmcr(vcpu, vmcr);
>> - else
>> - vgic_v3_get_vmcr(vcpu, vmcr);
>> -}
>> -
>> #define GICC_ARCH_VERSION_V2 0x2
>>
>> /* These are for userland accesses only, there is no guest-facing emulation. */
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
>> index 9939d1d..173d6f0 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
>> @@ -416,6 +416,22 @@ int vgic_validate_mmio_region_addr(struct kvm_device *dev,
>> return -ENXIO;
>> }
>>
>> +void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
>> +{
>> + if (kvm_vgic_global_state.type == VGIC_V2)
>> + vgic_v2_set_vmcr(vcpu, vmcr);
>> + else
>> + vgic_v3_set_vmcr(vcpu, vmcr);
>> +}
>> +
>> +void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
>> +{
>> + if (kvm_vgic_global_state.type == VGIC_V2)
>> + vgic_v2_get_vmcr(vcpu, vmcr);
>> + else
>> + vgic_v3_get_vmcr(vcpu, vmcr);
>> +}
>> +
>> /*
>> * kvm_mmio_read_buf() returns a value in a format where it can be converted
>> * to a byte array and be directly observed as the guest wanted it to appear
>> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
>> index 9f0dae3..967c295 100644
>> --- a/virt/kvm/arm/vgic/vgic-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-v3.c
>> @@ -175,10 +175,13 @@ void vgic_v3_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
>> {
>> u32 vmcr;
>>
>> - vmcr = (vmcrp->ctlr << ICH_VMCR_CTLR_SHIFT) & ICH_VMCR_CTLR_MASK;
>> + vmcr = (vmcrp->ctlr << ICH_VMCR_CBPR_SHIFT) & ICH_VMCR_CBPR_MASK;
>> + vmcr |= (vmcrp->ctlr << ICH_VMCR_EOIM_SHIFT) & ICH_VMCR_EOIM_MASK;
>
> This looks weird: The EOImode field is bit[2] in the CTLR, and VEOIM is
> bit[9] in the ICH_VMCR, but you're just shifting the ctlr field left by
> 9 and then masking off everything by bit 9, so you'll end with never
> being able to set VEOIM I think...
>
OK
> Also, we do we now forget about VFIQEn and VAckCtl? The latter I can
> understand because it's deprecated, but why the first? This particular
> piece of information would be very nice to have in the commit message.
I understand that group 0 interrupts are not handled. So vFIQEn can be ignored.
Spec says, if SRE=1 (non-secure) this bit is RES1 also it is alias to
ICC_CTLR_EL1
if SRE is 1. However there is no bit in ICC_CTLR_EL1 for FIQen. It is defined
only in GICV_CTLR which is used when SRE=0.
^ permalink raw reply
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Arnd Bergmann @ 2016-11-17 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479148025-469-1-git-send-email-krzk@kernel.org>
On Monday, November 14, 2016 8:27:05 PM CET Krzysztof Kozlowski wrote:
> @@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
> config HZ_FIXED
> int
> default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS4
> + ARCH_S5PV210
> default 128 if SOC_AT91RM9200
> default 0
After further research, I've concluded that we should also drop the
settings for ARCH_S5PV210 and ARCH_S3C24XX here.
ARCH_S5PV210 behaves exactly like EXYNOS here, it has 32-bit timers
so there won't be any overflow with 100Hz.
For ARCH_S3C24XX, it the requirement was that HZ_100 could not
be used with the old arch/arm/plat-samsung/time.c code that would
overflow its 16-bit counter.
However, the new drivers/clocksource/samsung_pwm_timer.c configures
the clock divider to '50' instead of '6', so there is no longer
a 16-bit overflow before the 100Hz tick, it now overflows every
3.7ms for the typical 12MHz clock.
Arnd
^ permalink raw reply
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Abhimanyu Saini @ 2016-11-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114063346.GH3310@dragon>
> > Following levels of DTSI/DTS files have been created for the LS2088A
> > SoC family:
> >
> > - fsl-ls2088a.dtsi:
> > DTS-Include file for FSL LS2088A SoC.
> >
> > - fsl-ls2088a-qds.dts:
> > DTS file for FSL LS2088A QDS board.
> >
> > - fsl-ls2088a-rdb.dts:
> > DTS file for FSL LS2088A RDB board.
>
> I compared the following files.
>
> fsl-ls2088a.dtsi vs. fsl-ls2080a.dtsi
> fsl-ls2088a-qds.dtsi vs. fsl-ls2080a-qds.dtsi fsl-ls2088a-rdb.dtsi vs.
> fsl-ls2080a-rdb.dtsi
>
> They are basically identical except a couple of small changes. Can we do
> something to have these SoCs share the dts files at some level to avoid
> maintaining duplicated files?
Hi Shawn,
Yes, we could reorganize DTSI and DTS file.
I can create fsl-ls2080a-ls2088a.dtsi and move all the common nodes to this file,
Then fsl-ls2080a.dtsi and fsl-ls2088a.dtsi which will include
the common file and add ls2080a and ls2088a specific nodes respectively.
Same hierarchy can be created for fsl-ls2080a-qds.dts, fsl-ls2080a-rdb,
fsl-ls2088a-qds.dts and fsl-ls2088a-rdb, wherein the common nodes will lie in
fsl-ls2080a-ls2088a-qds.dts and fsl-ls2080a-ls2088a-rdb.dts
What do you think?
Abhimanyu
^ permalink raw reply
* [PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared
From: Brian Starkey @ 2016-11-17 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c6xls-0006wf-Jg@rmk-PC.armlinux.org.uk>
Hi Russell,
On Wed, Nov 16, 2016 at 10:48:52AM +0000, Russell King wrote:
>The TDA998x contains two different I2C devices - there is the HDMI
>encoder, and the TDA9950 CEC engine. These two share the same interrupt
>signal.
>
>In order to allow a driver for the CEC engine to work, we need to be
>able to share the interrupt with the CEC driver, so convert the handler
>and registration to allow this to happen.
>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>---
>This patch follows on from:
> "drm/i2c: tda998x: power down pre-filter and color conversion"
>which is now part of my drm-tda998x-devel branch, a branch which will
>shortly be part of linux-next. This patch and the following patch are
>not part of that branch yet.
>
>I don't believe I received any testing for the power-down patch above
>either, so if I can have some tested-bys/reviewed-bys for it and these
>two patches, that'd be great. Thanks.
I tested these two and the power-down one on mali-dp and hdlcd. The
output, hotplugging and EDID continued to work; so you can have my
tested-by and reviewed-by for all 3.
Cheers,
Brian
>
>As my Juno has now been fixed, I've been able to test these two patches
>on the HDLCD on Juno and Dove Cubox.
>
> drivers/gpu/drm/i2c/tda998x_drv.c | 52 ++++++++++++++++++++-------------------
> 1 file changed, 27 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
>index bf5eec0c1b4f..74fb59a35269 100644
>--- a/drivers/gpu/drm/i2c/tda998x_drv.c
>+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>@@ -634,28 +634,30 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
> bool handled = false;
>
> sta = cec_read(priv, REG_CEC_INTSTATUS);
>- cec = cec_read(priv, REG_CEC_RXSHPDINT);
>- lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>- flag0 = reg_read(priv, REG_INT_FLAGS_0);
>- flag1 = reg_read(priv, REG_INT_FLAGS_1);
>- flag2 = reg_read(priv, REG_INT_FLAGS_2);
>- DRM_DEBUG_DRIVER(
>- "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
>- sta, cec, lvl, flag0, flag1, flag2);
>-
>- if (cec & CEC_RXSHPDINT_HPD) {
>- if (lvl & CEC_RXSHPDLEV_HPD)
>- tda998x_edid_delay_start(priv);
>- else
>- schedule_work(&priv->detect_work);
>-
>- handled = true;
>- }
>+ if (sta & CEC_INTSTATUS_HDMI) {
>+ cec = cec_read(priv, REG_CEC_RXSHPDINT);
>+ lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>+ flag0 = reg_read(priv, REG_INT_FLAGS_0);
>+ flag1 = reg_read(priv, REG_INT_FLAGS_1);
>+ flag2 = reg_read(priv, REG_INT_FLAGS_2);
>+ DRM_DEBUG_DRIVER(
>+ "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
>+ sta, cec, lvl, flag0, flag1, flag2);
>+
>+ if (cec & CEC_RXSHPDINT_HPD) {
>+ if (lvl & CEC_RXSHPDLEV_HPD)
>+ tda998x_edid_delay_start(priv);
>+ else
>+ schedule_work(&priv->detect_work);
>+
>+ handled = true;
>+ }
>
>- if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>- priv->wq_edid_wait = 0;
>- wake_up(&priv->wq_edid);
>- handled = true;
>+ if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>+ priv->wq_edid_wait = 0;
>+ wake_up(&priv->wq_edid);
>+ handled = true;
>+ }
> }
>
> return IRQ_RETVAL(handled);
>@@ -1542,7 +1544,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
>
> /* initialize the optional IRQ */
> if (client->irq) {
>- int irqf_trigger;
>+ unsigned long irq_flags;
>
> /* init read EDID waitqueue and HDP work */
> init_waitqueue_head(&priv->wq_edid);
>@@ -1552,11 +1554,11 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
> reg_read(priv, REG_INT_FLAGS_1);
> reg_read(priv, REG_INT_FLAGS_2);
>
>- irqf_trigger =
>+ irq_flags =
> irqd_get_trigger_type(irq_get_irq_data(client->irq));
>+ irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
> ret = request_threaded_irq(client->irq, NULL,
>- tda998x_irq_thread,
>- irqf_trigger | IRQF_ONESHOT,
>+ tda998x_irq_thread, irq_flags,
> "tda998x", priv);
> if (ret) {
> dev_err(&client->dev,
>--
>2.7.4
>
^ permalink raw reply
* [PATCH 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Code cleanup for improving code readability and error path fixes
and cleanup removing use of devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 34 +++++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 164e2e1..382a7f9 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -222,13 +222,18 @@ static void dspi_rx_dma_callback(void *arg)
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
+ if (rx_word)
+ len = dma->curr_xfer_len / 2;
+ else
+ len = dma->curr_xfer_len;
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
for (i = 0; i < len; i++) {
d = dspi->dma->rx_dma_buf[i];
- rx_word ? (*(u16 *)dspi->rx = d) :
- (*(u8 *)dspi->rx = d);
+ if (rx_word)
+ *(u16 *)dspi->rx = d;
+ else
+ *(u8 *)dspi->rx = d;
dspi->rx += rx_word + 1;
}
}
@@ -247,17 +252,27 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
+ if (tx_word)
+ len = dma->curr_xfer_len / 2;
+ else
+ len = dma->curr_xfer_len;
for (i = 0; i < len - 1; i++) {
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
dspi->tx += tx_word + 1;
}
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(u8 *) dspi->tx;
+
if (dspi->cs_change) {
dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
SPI_PUSHR_PCS(dspi->cs) |
@@ -440,15 +455,16 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
return 0;
err_slave_config:
- devm_kfree(dev, dma->rx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->rx_dma_buf, dma->rx_dma_phys);
err_rx_dma_buf:
- devm_kfree(dev, dma->tx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->tx_dma_buf, dma->tx_dma_phys);
err_tx_dma_buf:
dma_release_channel(dma->chan_tx);
err_tx_channel:
dma_release_channel(dma->chan_rx);
- devm_kfree(dev, dma);
dspi->dma = NULL;
return ret;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers. Use the cs_change variable and correctly set or
reset the CONT bit accordingly for case where peripherals require
the chip select to be asserted between sequential transfers.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index aee8c88..164e2e1 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
}
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
- dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
- SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(0);
+ if (dspi->cs_change) {
+ dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
+ SPI_PUSHR_PCS(dspi->cs) |
+ SPI_PUSHR_CTAS(0);
+ } else {
+ dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
+ SPI_PUSHR_PCS(dspi->cs) |
+ SPI_PUSHR_CTAS(0) |
+ SPI_PUSHR_CONT;
+ }
dspi->tx += tx_word + 1;
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Currently dmaengine_prep_slave_single was being called with length
set to the complete DMA buffer size. This resulted in unwanted bytes
being transferred to the SPI register leading to clock and MOSI lines
having unwanted data even after chip select got deasserted and the
required bytes having been transferred.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b1ee1f5..aee8c88 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES /
+ (tx_word ? 2 : 1),
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -281,7 +284,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES /
+ (tx_word ? 2 : 1),
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Current DMA implementation had a bug where the DMA transfer would
exit the loop in dspi_transfer_one_message after the completion of
a single transfer. This results in a multi message transfer submitted
with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index bc64700..b1ee1f5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -714,7 +714,7 @@ static int dspi_transfer_one_message(struct spi_master *master,
SPI_RSER_TFFFE | SPI_RSER_TFFFD |
SPI_RSER_RFDFE | SPI_RSER_RFDFD);
status = dspi_dma_xfer(dspi);
- goto out;
+ break;
default:
dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
trans_mode);
@@ -722,9 +722,13 @@ static int dspi_transfer_one_message(struct spi_master *master,
goto out;
}
- if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
- dev_err(&dspi->pdev->dev, "wait transfer complete fail!\n");
- dspi->waitflags = 0;
+ if (trans_mode != DSPI_DMA_MODE) {
+ if (wait_event_interruptible(dspi->waitq,
+ dspi->waitflags))
+ dev_err(&dspi->pdev->dev,
+ "wait transfer complete fail!\n");
+ dspi->waitflags = 0;
+ }
if (transfer->delay_usecs)
udelay(transfer->delay_usecs);
--
2.10.2
^ permalink raw reply related
* [PATCH 0/4] Fixes for Vybrid SPI DMA implementation
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111122036.fubv7b4jc5vkdxhc@sirena.org.uk>
Hello,
The following set of patches have fixes for Vybrid SPI DMA
implementation along with some minor clean ups requested
at time when v3 version of SPI DMA support patch was accepted.
This series of patches is based on top of branch topic/fsl-dspi.
http://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/log/?h=topic/fsl-dspi
The patches have been tested on a Toradex Colibri Vybrid VF61 module.
Thanks & Regards,
Sanchayan.
Sanchayan Maity (4):
spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
spi: spi-fsl-dspi: Fix incorrect DMA setup
spi: spi-fsl-dspi: Fix continuous selection format
spi: spi-fsl-dspi: Minor code cleanup and error path fixes
drivers/spi/spi-fsl-dspi.c | 69 ++++++++++++++++++++++++++++++++++------------
1 file changed, 51 insertions(+), 18 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH] arm: dma-mapping: Reset the device's dma_ops
From: Marek Szyprowski @ 2016-11-17 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479381645-3230-1-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
On 2016-11-17 12:20, Sricharan R wrote:
> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
> ,dma_ops should be cleared in the teardown path. Otherwise
> this causes problem when the probe of device is retried after
> being deferred. The device's iommu structures are cleared
> after EPROBEDEFER error, but on the next try dma_ops will still
> be set to old value, which is not right.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/dma-mapping.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index ab4f745..a40f03e 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
>
> __arm_iommu_detach_device(dev);
> arm_iommu_release_mapping(mapping);
> + set_dma_ops(dev, NULL);
> }
>
> #else
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [RFC PATCH] of: base: add support to get machine model name
From: Sudeep Holla @ 2016-11-17 11:50 UTC (permalink / raw)
To: linux-arm-kernel
Currently platforms/drivers needing to get the machine model name are
replicating the same snippet of code. In some case, the OF reference
counting is either missing or incorrect.
This patch adds support to read the machine model name either using
the "model" or the "compatible" property in the device tree root node.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/mach-imx/cpu.c | 4 +---
arch/arm/mach-mxs/mach-mxs.c | 3 +--
arch/mips/cavium-octeon/setup.c | 12 ++----------
arch/mips/generic/proc.c | 15 +++------------
arch/sh/boards/of-generic.c | 6 +-----
drivers/of/base.c | 34 ++++++++++++++++++++++++++++++++++
drivers/soc/fsl/guts.c | 3 +--
drivers/soc/renesas/renesas-soc.c | 4 +---
include/linux/of.h | 6 ++++++
9 files changed, 50 insertions(+), 37 deletions(-)
Hi,
While trying to fix a simple build warning(as below) in -next for fsl/guts.c,
I came across this code duplication in multiple places.
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
With CONFIG_DEBUG_SECTION_MISMATCH enabled, the details are reported:
WARNING: vmlinux.o(.text+0x55d014): Section mismatch in reference from the
function fsl_guts_probe() to the function
.init.text:of_flat_dt_get_machine_name()
The function fsl_guts_probe() references
the function __init of_flat_dt_get_machine_name().
This is often because fsl_guts_probe lacks a __init
annotation or the annotation of of_flat_dt_get_machine_name is wrong.
I can split the patch if needed if people are OK with the idea.
Regards,
Sudeep
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index b3347d32349f..846f40008752 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -85,9 +85,7 @@ struct device * __init imx_soc_device_init(void)
soc_dev_attr->family = "Freescale i.MX";
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
- of_node_put(root);
+ ret = of_machine_get_model_name(&soc_dev_attr->machine);
if (ret)
goto free_soc;
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index e4f21086b42b..ed9af3a894f0 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -391,8 +391,7 @@ static void __init mxs_machine_init(void)
if (!soc_dev_attr)
return;
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
+ ret = of_machine_get_model_name(&soc_dev_attr->machine);
if (ret)
return;
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 9a2db1c013d9..2e2b1b5befa4 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -498,16 +498,8 @@ static void __init init_octeon_system_type(void)
char const *board_type;
board_type = cvmx_board_type_to_string(octeon_bootinfo->board_type);
- if (board_type == NULL) {
- struct device_node *root;
- int ret;
-
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &board_type);
- of_node_put(root);
- if (ret)
- board_type = "Unsupported Board";
- }
+ if (!board_type && of_machine_get_model_name(&board_type))
+ board_type = "Unsupported Board";
snprintf(octeon_system_type, sizeof(octeon_system_type), "%s (%s)",
board_type, octeon_model_get_string(read_c0_prid()));
diff --git a/arch/mips/generic/proc.c b/arch/mips/generic/proc.c
index 42b33250a4a2..f7fc067bf908 100644
--- a/arch/mips/generic/proc.c
+++ b/arch/mips/generic/proc.c
@@ -10,20 +10,11 @@
#include <linux/of.h>
-#include <asm/bootinfo.h>
-
const char *get_system_type(void)
{
const char *str;
- int err;
-
- err = of_property_read_string(of_root, "model", &str);
- if (!err)
- return str;
-
- err = of_property_read_string_index(of_root, "compatible", 0, &str);
- if (!err)
- return str;
- return "Unknown";
+ if (of_machine_get_model_name(&str))
+ return "Unknown";
+ return str;
}
diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index 1fb6d5714bae..938a14499298 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -135,11 +135,7 @@ static void __init sh_of_setup(char **cmdline_p)
board_time_init = sh_of_time_init;
sh_mv.mv_name = "Unknown SH model";
- root = of_find_node_by_path("/");
- if (root) {
- of_property_read_string(root, "model", &sh_mv.mv_name);
- of_node_put(root);
- }
+ of_machine_get_model_name(&sh_mv.mv_name);
sh_of_smp_probe();
}
diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0bccb54a9bd..752cb8eefd6e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -546,6 +546,40 @@ int of_machine_is_compatible(const char *compat)
EXPORT_SYMBOL(of_machine_is_compatible);
/**
+ * of_machine_get_model_name - Find and read the model name or the compatible
+ * value for the machine.
+ * @model: pointer to null terminated return string, modified only if
+ * return value is 0.
+ *
+ * Returns a string containing either the model name or the compatible value
+ * of the machine if found, else return error.
+ *
+ * Search for a machine model name or the compatible if model name is missing
+ * in a device tree node and retrieve a null terminated string value (pointer
+ * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
+ * tree is not found and other error returned by of_property_read_string on
+ * failure.
+ */
+int of_machine_get_model_name(const char **model)
+{
+ int error;
+ struct device_node *root;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -EINVAL;
+
+ error = of_property_read_string(root, "model", model);
+ if (error)
+ error = of_property_read_string_index(root, "compatible",
+ 0, model);
+ of_node_put(root);
+
+ return error;
+}
+EXPORT_SYMBOL(of_machine_get_model_name);
+
+/**
* __of_device_is_available - check if a device is available for use
*
* @device: Node to check for availability, with locks already held
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 0ac88263c2d7..94aef0465451 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -152,8 +152,7 @@ static int fsl_guts_probe(struct platform_device *pdev)
return PTR_ERR(guts->regs);
/* Register soc device */
- machine = of_flat_dt_get_machine_name();
- if (machine)
+ if (!of_machine_get_model_name(&machine))
soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
svr = fsl_guts_get_svr();
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 330960312296..d9a119073de5 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -228,9 +228,7 @@ static int __init renesas_soc_init(void)
if (!soc_dev_attr)
return -ENOMEM;
- np = of_find_node_by_path("/");
- of_property_read_string(np, "model", &soc_dev_attr->machine);
- of_node_put(np);
+ of_machine_get_model_name(&soc_dev_attr->machine);
soc_dev_attr->family = kstrdup_const(family->name, GFP_KERNEL);
soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..13fc66531f1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
extern int of_alias_get_highest_id(const char *stem);
extern int of_machine_is_compatible(const char *compat);
+extern int of_machine_get_model_name(const char **model);
extern int of_add_property(struct device_node *np, struct property *prop);
extern int of_remove_property(struct device_node *np, struct property *prop);
@@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
return 0;
}
+static inline int of_machine_get_model_name(const char **model)
+{
+ return -EINVAL;
+}
+
static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
{
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] thermal: Fix module autoload for drivers
From: Javier Martinez Canillas @ 2016-11-17 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476455702-21748-1-git-send-email-javier@osg.samsung.com>
Hello Eduardo,
On Fri, Oct 14, 2016 at 11:34 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello,
>
> This small series contains trivial fixes to allow modules to be autoloaded
> when its correspoinding thermal device is registered.
>
> Best regards,
> Javier
>
>
> Javier Martinez Canillas (3):
> thermal: max77620: Fix module autoload
> thermal: tango: Fix module autoload
> thermal: db8500: Fix module autoload
>
Any comments about these patches?
Best regards,
Javier
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-17 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258013-6669-1-git-send-email-vijay.kilari@gmail.com>
Hi Vijaya,
On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
>
> v7 => v8:
> - Rebased to 4.9-rc3
I noticed when looking at this series that there are quite a few
conflicts when applying to kvmarm/queue, so if you could rebase the next
verson on kvmarm/queue, then you'll make Marc's life a bit easier.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Christoffer Dall @ 2016-11-17 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6vbFj3aoSiqc4n_92rZgONeQVhp-GtTkEhW3=pt9P1hGQ@mail.gmail.com>
On Thu, Nov 17, 2016 at 04:56:53PM +0530, Vijay Kilari wrote:
> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>
> >> Read and write of some registers like ISPENDR and ICPENDR
> >> from userspace requires special handling when compared to
> >> guest access for these registers.
> >>
> >> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> for handling of ISPENDR, ICPENDR registers handling.
> >>
> >> Add infrastructure to support guest and userspace read
> >> and write for the required registers
> >> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
> >>
> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> ---
> >> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
> >> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
> >> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
> >> 4 files changed, 169 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> index b44b359..0b32f40 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> >> return -ENXIO;
> >> }
> >>
> >> -/*
> >> - * When userland tries to access the VGIC register handlers, we need to
> >> - * create a usable struct vgic_io_device to be passed to the handlers and we
> >> - * have to set up a buffer similar to what would have happened if a guest MMIO
> >> - * access occurred, including doing endian conversions on BE systems.
> >> - */
> >> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> >> - bool is_write, int offset, u32 *val)
> >> -{
> >> - unsigned int len = 4;
> >> - u8 buf[4];
> >> - int ret;
> >> -
> >> - if (is_write) {
> >> - vgic_data_host_to_mmio_bus(buf, len, *val);
> >> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
> >> - } else {
> >> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
> >> - if (!ret)
> >> - *val = vgic_data_mmio_bus_to_host(buf, len);
> >> - }
> >> -
> >> - return ret;
> >> -}
> >> -
> >> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> >> int offset, u32 *val)
> >> {
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> index 0d3c76a..ce2708d 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
> >> return 0;
> >> }
> >>
> >> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + u32 value = 0;
> >> + int i;
> >> +
> >> + /*
> >> + * A level triggerred interrupt pending state is latched in both
> >> + * "soft_pending" and "line_level" variables. Userspace will save
> >> + * and restore soft_pending and line_level separately.
> >> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> + * handling of ISPENDR and ICPENDR.
> >> + */
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
> >> + value |= (1U << i);
> >> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
> >> + value |= (1U << i);
> >> +
> >> + vgic_put_irq(vcpu->kvm, irq);
> >> + }
> >> +
> >> + return value;
> >> +}
> >> +
> >> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len,
> >> + unsigned long val)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + int i;
> >> +
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + spin_lock(&irq->irq_lock);
> >> + if (test_bit(i, &val)) {
> >> + irq->pending = true;
> >> + irq->soft_pending = true;
> >
> > In the vgic_mmio_write_spending function we only set the soft_pending
> > state to true if the interrupt is a level-triggered interrupt.
> >
> > Should we check if that's the case here as well before setting the
> > soft_pending state?
>
> Yes, can be done. But it puts hard requirement that irq config should
> be restored
> before updating pending state.
Ah, I see.
ok, I think you should keep it the way it is then, but please add a
comment to that effect.
> In any case, the soft_pending is used only if interrupt is level-triggered.
>
Yes, indeed.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Marek Szyprowski @ 2016-11-17 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116123918.qzaqczaqri2hab43@localhost>
Hi Catalin,
On 2016-11-16 13:39, Catalin Marinas wrote:
> On Wed, Nov 16, 2016 at 10:20:13AM +0100, Marek Szyprowski wrote:
>> fs_initcall is definitely too late to initialize DMA-debug hash tables,
>> because some drivers might get probed and use DMA mapping framework
>> already in core_initcall. Late initialization of DMA-debug results in
>> false warning about accessing memory, that was not allocated. This issue
>> has been observed on ARM 32bit, but the same driver can be used also on
>> ARM64.
>>
>> This patch moves initialization of DMA-debug to core_initcall. This is
>> safe from the initialization perspective. dma_debug_do_init() internally
>> calls debugfs functions and debugfs also gets initialised at
>> core_initcall(), and that is earlier than arch code in the link order,
>> so it will get initialized just before the DMA-debug.
> Do we really want to rely on the link order within an initcall level?
> What guarantees this?
There are many places in the kernel which rely on link order and I'm
convinced
that calling initcalls in link order is guaranteed.
> I hope someone sorts out the deferred probe or some other dependency
> detection mechanism to address this issue. But in the meantime I
> wouldn't merge a patch which relies on just the link order.
This has nothing to deferred probe. This patch is related to initialization
of dma-debug framework. In my initial submission for ARM arch I proposed
pure_initcall to have this infrastructure available as early as possible,
but Russell pointed that dma-debug depends on debugfs initialization, so
it should be initialized after it. He also pointed that core_initcall will
be fine for this.
Please also note that dt devices are also populated from core_initcall and
drivers can then bind to them and try to use dma-mapping api, what results
in false warnings about using uninitialized memory as dma-debug framework
is unable to track allocations done before its initialization.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Matthias Brugger @ 2016-11-17 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115180813.GB1852@obsidianresearch.com>
On 15/11/16 19:08, Jason Gunthorpe wrote:
>
> On Tue, Nov 15, 2016 at 12:05:15PM +0100, Matthias Brugger wrote:
>> On 09/11/16 23:58, Jason Gunthorpe wrote:
>>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>
>> Please add a commit message, although it is cristal clear what this patch
>> does :)
>
> As you say, it is crystal clear already, and this is an acceptable commit
> message.. Please suggest a text if you want to see something
> different.
>
"Function dev_err doesn't add a newline at the end of the string. This
will lead to a hard to read kernel log. This patch fixes this."
With this (or something similar added):
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Regards,
Matthias
^ permalink raw reply
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Vijay Kilari @ 2016-11-17 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116185215.GC3811@cbox>
On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> Read and write of some registers like ISPENDR and ICPENDR
>> from userspace requires special handling when compared to
>> guest access for these registers.
>>
>> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> for handling of ISPENDR, ICPENDR registers handling.
>>
>> Add infrastructure to support guest and userspace read
>> and write for the required registers
>> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> ---
>> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
>> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
>> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
>> 4 files changed, 169 insertions(+), 51 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> index b44b359..0b32f40 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> return -ENXIO;
>> }
>>
>> -/*
>> - * When userland tries to access the VGIC register handlers, we need to
>> - * create a usable struct vgic_io_device to be passed to the handlers and we
>> - * have to set up a buffer similar to what would have happened if a guest MMIO
>> - * access occurred, including doing endian conversions on BE systems.
>> - */
>> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
>> - bool is_write, int offset, u32 *val)
>> -{
>> - unsigned int len = 4;
>> - u8 buf[4];
>> - int ret;
>> -
>> - if (is_write) {
>> - vgic_data_host_to_mmio_bus(buf, len, *val);
>> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
>> - } else {
>> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
>> - if (!ret)
>> - *val = vgic_data_mmio_bus_to_host(buf, len);
>> - }
>> -
>> - return ret;
>> -}
>> -
>> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> int offset, u32 *val)
>> {
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> index 0d3c76a..ce2708d 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
>> return 0;
>> }
>>
>> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + u32 value = 0;
>> + int i;
>> +
>> + /*
>> + * A level triggerred interrupt pending state is latched in both
>> + * "soft_pending" and "line_level" variables. Userspace will save
>> + * and restore soft_pending and line_level separately.
>> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> + * handling of ISPENDR and ICPENDR.
>> + */
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
>> + value |= (1U << i);
>> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
>> + value |= (1U << i);
>> +
>> + vgic_put_irq(vcpu->kvm, irq);
>> + }
>> +
>> + return value;
>> +}
>> +
>> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len,
>> + unsigned long val)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + int i;
>> +
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + spin_lock(&irq->irq_lock);
>> + if (test_bit(i, &val)) {
>> + irq->pending = true;
>> + irq->soft_pending = true;
>
> In the vgic_mmio_write_spending function we only set the soft_pending
> state to true if the interrupt is a level-triggered interrupt.
>
> Should we check if that's the case here as well before setting the
> soft_pending state?
Yes, can be done. But it puts hard requirement that irq config should
be restored
before updating pending state.
In any case, the soft_pending is used only if interrupt is level-triggered.
>
> Otherwise, this patch looks good.
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH] arm: dma-mapping: Reset the device's dma_ops
From: Sricharan R @ 2016-11-17 11:20 UTC (permalink / raw)
To: linux-arm-kernel
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Otherwise
this causes problem when the probe of device is retried after
being deferred. The device's iommu structures are cleared
after EPROBEDEFER error, but on the next try dma_ops will still
be set to old value, which is not right.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab4f745..a40f03e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
__arm_iommu_detach_device(dev);
arm_iommu_release_mapping(mapping);
+ set_dma_ops(dev, NULL);
}
#else
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: Will Deacon @ 2016-11-17 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117022023.GA5704@linaro.org>
Hi Akashi,
On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> On Wed, Nov 16, 2016 at 04:30:15PM +0000, Will Deacon wrote:
> > I thought limit was just a physical address, and then
>
> No, it's not.
Quite right, it's a size. Sorry about that.
> > memblock_mem_limit_remove_map operated on the end of the nearest memblock?
>
> No, but "max_addr" returned by __find_max_addr() is a physical address
> and the end address of memory of "limit" size in total.
>
> > You could leave the __find_max_addr call in memblock_mem_limit_remove_map,
> > given that I don't think you need/want it for memblock_cap_memory_range.
> >
> > > So I added an extra argument, exact, to a common function to specify
> > > distinct behaviors. Confusing? Please see the patch below.
> >
> > Oh yikes, this certainly wasn't what I had in mind! My observation was
> > just that memblock_mem_limit_remove_map(limit) does:
> >
> >
> > 1. memblock_isolate_range(limit - limit+ULLONG_MAX)
> > 2. memblock_remove_region(all non-nomap regions in the isolated region)
> > 3. truncate reserved regions to limit
> >
> > and your memblock_cap_memory_range(base, size) does:
> >
> > 1. memblock_isolate_range(base - base+size)
> > 2, memblock_remove_region(all non-nomap regions above and below the
> > isolated region)
> > 3. truncate reserved regions around the isolated region
> >
> > so, assuming we can invert the isolation in one of the cases, then they
> > could share the same underlying implementation.
>
> Please see my simplified patch below which would explain what I meant.
> (Note that the size is calculated by 'max_addr - 0'.)
>
> > I'm probably just missing something here, because the patch you've ended
> > up with is far more involved than I anticipated...
>
> I hope that it will meet almost your anticipation.
It looks much better, thanks! Just one question below.
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7608bc3..fea1688 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> (phys_addr_t)ULLONG_MAX);
> }
>
> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> +{
> + int start_rgn, end_rgn;
> + int i, ret;
> +
> + if (!size)
> + return;
> +
> + ret = memblock_isolate_range(&memblock.memory, base, size,
> + &start_rgn, &end_rgn);
> + if (ret)
> + return;
> +
> + /* remove all the MAP regions */
> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> + memblock_remove_region(&memblock.memory, i);
In the case that we have only one, giant memblock that covers base all
of base + size, can't we end up with start_rgn = end_rgn = 0? In which
case, we'd end up accidentally removing the map regions here.
The existing code:
> - /* remove all the MAP regions above the limit */
> - for (i = end_rgn - 1; i >= start_rgn; i--) {
> - if (!memblock_is_nomap(&type->regions[i]))
> - memblock_remove_region(type, i);
> - }
seems to handle this.
Will
^ 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