* [PATCHv2 09/10] arm64: frace: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the ftrace exports
to the assembly files the functions are defined in.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 5 -----
arch/arm64/kernel/entry-ftrace.S | 4 ++++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index c142103bc0fe..4ca8d2b245d2 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -28,8 +28,3 @@
#include <asm/checksum.h>
-#ifdef CONFIG_FUNCTION_TRACER
-EXPORT_SYMBOL(_mcount);
-NOKPROBE_SYMBOL(_mcount);
-#endif
-
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 032e24d2d554..81b8eb5c4633 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -120,6 +120,8 @@ skip_ftrace_call: // }
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
mcount_exit
ENDPROC(_mcount)
+EXPORT_SYMBOL(_mcount)
+NOKPROBE(_mcount)
#else /* CONFIG_DYNAMIC_FTRACE */
/*
@@ -131,6 +133,8 @@ ENDPROC(_mcount)
ENTRY(_mcount)
ret
ENDPROC(_mcount)
+EXPORT_SYMBOL(_mcount)
+NOKPROBE(_mcount)
/*
* void ftrace_caller(unsigned long return_address)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 06/10] arm64: page: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the copy_page and
clear_page exports to the assembly files the functions are defined in.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 3 ---
arch/arm64/lib/clear_page.S | 1 +
arch/arm64/lib/copy_page.S | 1 +
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 74e29e69190b..784b257d9643 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -30,9 +30,6 @@
#include <asm/checksum.h>
-EXPORT_SYMBOL(copy_page);
-EXPORT_SYMBOL(clear_page);
-
/* user mem (segment) */
EXPORT_SYMBOL(__arch_copy_from_user);
EXPORT_SYMBOL(__arch_copy_to_user);
diff --git a/arch/arm64/lib/clear_page.S b/arch/arm64/lib/clear_page.S
index ef08e905e35b..6d13b0d64ad5 100644
--- a/arch/arm64/lib/clear_page.S
+++ b/arch/arm64/lib/clear_page.S
@@ -37,3 +37,4 @@ ENTRY(clear_page)
b.ne 1b
ret
ENDPROC(clear_page)
+EXPORT_SYMBOL(clear_page)
diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
index 076c43715e64..98313e24a987 100644
--- a/arch/arm64/lib/copy_page.S
+++ b/arch/arm64/lib/copy_page.S
@@ -87,3 +87,4 @@ alternative_else_nop_endif
ret
ENDPROC(copy_page)
+EXPORT_SYMBOL(copy_page)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 02/10] arm64: move memstart_addr export inline
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
Since we define memstart_addr in a C file, we can have the export
immediately after the definition of the symbol, as we do elsewhere.
As a step towards removing arm64ksyms.c, move the export of
memstart_addr to init.c, where the symbol is defined.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 3 ---
arch/arm64/mm/init.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index c4003c18a18b..73237dc8a994 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -40,9 +40,6 @@ EXPORT_SYMBOL(__arch_copy_to_user);
EXPORT_SYMBOL(__arch_clear_user);
EXPORT_SYMBOL(__arch_copy_in_user);
- /* physical memory */
-EXPORT_SYMBOL(memstart_addr);
-
/* string / mem functions */
#ifndef CONFIG_KASAN
EXPORT_SYMBOL(strchr);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b432d9fcada..2983e0fc1786 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -59,6 +59,8 @@
* that cannot be mistaken for a real physical address.
*/
s64 memstart_addr __ro_after_init = -1;
+EXPORT_SYMBOL(memstart_addr);
+
phys_addr_t arm64_dma_phys_limit __ro_after_init;
#ifdef CONFIG_BLK_DEV_INITRD
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 03/10] arm64: add EXPORT_SYMBOL_NOKASAN()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
So that we can export symbols directly from assembly files, let's make
use of the generic <asm/export.h>. We have a few symbols that we'll want
to conditionally export for !KASAN kernel builds, so we add a helper for
that in <asm/assembler.h>.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/assembler.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 953208267252..d8b9d3a427d1 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -23,6 +23,8 @@
#ifndef __ASM_ASSEMBLER_H
#define __ASM_ASSEMBLER_H
+#include <asm-generic/export.h>
+
#include <asm/asm-offsets.h>
#include <asm/cpufeature.h>
#include <asm/debug-monitors.h>
@@ -490,6 +492,13 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU
#else
#define NOKPROBE(x)
#endif
+
+#ifdef CONFIG_KASAN
+#define EXPORT_SYMBOL_NOKASAN(name)
+#else
+#define EXPORT_SYMBOL_NOKASAN(name) EXPORT_SYMBOL(name)
+#endif
+
/*
* Emit a 64-bit absolute little endian symbol reference in a way that
* ensures that it will be resolved at build time, even when building a
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 04/10] arm64: tishift: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the tishift exports
to the assembly file the functions are defined in.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 7 -------
arch/arm64/lib/tishift.S | 5 +++++
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 73237dc8a994..d80e9cfc3062 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -68,10 +68,3 @@ NOKPROBE_SYMBOL(_mcount);
EXPORT_SYMBOL(__arm_smccc_smc);
EXPORT_SYMBOL(__arm_smccc_hvc);
- /* tishift.S */
-extern long long __ashlti3(long long a, int b);
-EXPORT_SYMBOL(__ashlti3);
-extern long long __ashrti3(long long a, int b);
-EXPORT_SYMBOL(__ashrti3);
-extern long long __lshrti3(long long a, int b);
-EXPORT_SYMBOL(__lshrti3);
diff --git a/arch/arm64/lib/tishift.S b/arch/arm64/lib/tishift.S
index 0fdff97794de..047622536535 100644
--- a/arch/arm64/lib/tishift.S
+++ b/arch/arm64/lib/tishift.S
@@ -5,6 +5,8 @@
#include <linux/linkage.h>
+#include <asm/assembler.h>
+
ENTRY(__ashlti3)
cbz x2, 1f
mov x3, #64
@@ -25,6 +27,7 @@ ENTRY(__ashlti3)
mov x0, x2
ret
ENDPROC(__ashlti3)
+EXPORT_SYMBOL(__ashlti3)
ENTRY(__ashrti3)
cbz x2, 1f
@@ -46,6 +49,7 @@ ENTRY(__ashrti3)
mov x1, x2
ret
ENDPROC(__ashrti3)
+EXPORT_SYMBOL(__ashrti3)
ENTRY(__lshrti3)
cbz x2, 1f
@@ -67,3 +71,4 @@ ENTRY(__lshrti3)
mov x1, x2
ret
ENDPROC(__lshrti3)
+EXPORT_SYMBOL(__lshrti3)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 01/10] arm64: remove bitop exports
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
Now that the arm64 bitops are inlines built atop of the regular atomics,
we don't need to export anything.
Remove the redundant exports.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 72f63a59b008..c4003c18a18b 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -62,14 +62,6 @@ EXPORT_SYMBOL(__memset);
EXPORT_SYMBOL(__memcpy);
EXPORT_SYMBOL(__memmove);
- /* atomic bitops */
-EXPORT_SYMBOL(set_bit);
-EXPORT_SYMBOL(test_and_set_bit);
-EXPORT_SYMBOL(clear_bit);
-EXPORT_SYMBOL(test_and_clear_bit);
-EXPORT_SYMBOL(change_bit);
-EXPORT_SYMBOL(test_and_change_bit);
-
#ifdef CONFIG_FUNCTION_TRACER
EXPORT_SYMBOL(_mcount);
NOKPROBE_SYMBOL(_mcount);
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [Freedreno] [PATCH] drm/msm/a6xx: Add support for an interconnect path
From: Jordan Crouse @ 2018-12-07 18:07 UTC (permalink / raw)
To: freedreno, robdclark
Cc: linux-arm-msm, dianders, dri-devel, linux-kernel, georgi.djakov,
linux-arm-kernel
In-Reply-To: <20181207170656.13208-1-jcrouse@codeaurora.org>
On Fri, Dec 07, 2018 at 10:06:56AM -0700, Jordan Crouse wrote:
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also optimize for power but that will require some device tree
> infrastructure that does not yet exist.
>
> v3: Use macros and change port string per Georgi Djakov
Rob had asked earlier if it would be appropriate and/or possible to merge this
with the generic interconnect patches and with his blessing I would like to
renew that request. This should merge cleanly against tip of tree and it would
be nice to get this support in at the same time that the base patches go in.
Jordan
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20 ++++++++++++++++++++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +++++++++
> drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> 4 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index 843a9d40c05e..990c4350f0c4 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -5,6 +5,7 @@ config DRM_MSM
> depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> depends on OF && COMMON_CLK
> depends on MMU
> + depends on INTERCONNECT || !INTERCONNECT
> select QCOM_MDT_LOADER if ARCH_QCOM
> select REGULATOR
> select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 546599a7ab05..f37a9bfe5c30 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -2,6 +2,7 @@
> /* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
>
> #include <linux/clk.h>
> +#include <linux/interconnect.h>
> #include <linux/pm_opp.h>
> #include <soc/qcom/cmd-db.h>
>
> @@ -63,6 +64,9 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
>
> static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> + struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
> + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> + struct msm_gpu *gpu = &adreno_gpu->base;
> int ret;
>
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
> @@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
>
> gmu->freq = gmu->gpu_freqs[index];
> +
> + /*
> + * Eventually we will want to scale the path vote with the frequency but
> + * for now leave it at max so that the performance is nominal.
> + */
> + icc_set(gpu->icc_path, 0, MBps_to_icc(7216));
> }
>
> void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> @@ -680,6 +690,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
>
> int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> {
> + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> + struct msm_gpu *gpu = &adreno_gpu->base;
> struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> int status, ret;
>
> @@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> if (ret)
> goto out;
>
> + /* Set the bus quota to a reasonable value for boot */
> + icc_set(gpu->icc_path, 0, MBps_to_icc(3072));
> +
> a6xx_gmu_irq_enable(gmu);
>
> /* Check to see if we are doing a cold or warm boot */
> @@ -735,6 +750,8 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
>
> int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> {
> + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> + struct msm_gpu *gpu = &adreno_gpu->base;
> struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> u32 val;
>
> @@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> /* Tell RPMh to power off the GPU */
> a6xx_rpmh_stop(gmu);
>
> + /* Remove the bus vote */
> + icc_set(gpu->icc_path, 0, 0);
> +
> clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
>
> pm_runtime_put_sync(gmu->dev);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 93d70f4a2154..7403ade9aabc 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -18,6 +18,7 @@
> */
>
> #include <linux/ascii85.h>
> +#include <linux/interconnect.h>
> #include <linux/kernel.h>
> #include <linux/pm_opp.h>
> #include <linux/slab.h>
> @@ -695,6 +696,11 @@ static int adreno_get_pwrlevels(struct device *dev,
>
> DBG("fast_rate=%u, slow_rate=27000000", gpu->fast_rate);
>
> + /* Check for an interconnect path for the bus */
> + gpu->icc_path = of_icc_get(dev, "gfx-mem");
> + if (IS_ERR(gpu->icc_path))
> + gpu->icc_path = NULL;
> +
> return 0;
> }
>
> @@ -733,10 +739,13 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
>
> void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
> {
> + struct msm_gpu *gpu = &adreno_gpu->base;
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
> release_firmware(adreno_gpu->fw[i]);
>
> + icc_put(gpu->icc_path);
> +
> msm_gpu_cleanup(&adreno_gpu->base);
> }
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index f82bac086666..12fc5b1cb39d 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -19,6 +19,7 @@
> #define __MSM_GPU_H__
>
> #include <linux/clk.h>
> +#include <linux/interconnect.h>
> #include <linux/regulator/consumer.h>
>
> #include "msm_drv.h"
> @@ -119,6 +120,8 @@ struct msm_gpu {
> struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
> uint32_t fast_rate;
>
> + struct icc_path *icc_path;
> +
> /* Hang and Inactivity Detection:
> */
> #define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
> --
> 2.18.0
>
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] arm64: assorted fixes for dcache_by_line_op
From: Ard Biesheuvel @ 2018-12-07 18:01 UTC (permalink / raw)
To: Will Deacon
Cc: Suzuki K. Poulose, Marc Zyngier, Catalin Marinas,
Linux Kernel Mailing List, Robin Murphy, Dave Martin,
linux-arm-kernel
In-Reply-To: <20181207175326.GB11430@edgewater-inn.cambridge.arm.com>
On Fri, 7 Dec 2018 at 18:53, Will Deacon <will.deacon@arm.com> wrote:
>
> Hi Ard,
>
> Cheers for looking at this.
>
> On Thu, Dec 06, 2018 at 04:57:34PM +0100, Ard Biesheuvel wrote:
> > This fixes two issues in dcache_by_line_op: patch #4 fixes the logic
> > that is applied when patching DC CVAP instructions, and patch #5 gets
> > rid of some unintended undefined symbols resulting from incorrect use
> > of conditional GAS directives.
> >
> > Patches #1 to #3 are groundwork for #4.
> >
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> > Cc: Dave Martin <Dave.Martin@arm.com>
> >
> > Ard Biesheuvel (5):
> > arm64/alternative_cb: move callback reference into replacements
> > section
> > arm64/alternative_cb: add nr_alts parameter to callback handlers
> > arm64/alternative_cb: add support for alternative sequences
> > arm64/assembler: use callback to 3-way alt-patch DC CVAP instructions
> > arm64/mm: use string comparisons in dcache_by_line_op
> >
> > arch/arm64/include/asm/alternative.h | 54 +++++++++++---------
> > arch/arm64/include/asm/assembler.h | 17 +++---
> > arch/arm64/include/asm/kvm_mmu.h | 4 +-
> > arch/arm64/kernel/alternative.c | 22 +++++---
> > arch/arm64/kernel/cpu_errata.c | 24 ++++++---
> > arch/arm64/kvm/va_layout.c | 8 +--
> > 6 files changed, 79 insertions(+), 50 deletions(-)
>
> Whilst I can see that this solves the problem, I do wonder whether the
> additional infrastructure is really worth it. Couldn't we just do something
> really simple like the diff below instead?
>
That looks fine to me, although not as elegant :-) You are in a better
position to assess if the additional infrastructure may see other uses
in the near future.
In any case, I don't feel strongly about it, so pick whatever you feel
is most suitable. (I just spotted the undefined symbols when I was
playing with lld.)
> --->8
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 953208267252..8dea015b6599 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -390,27 +390,38 @@ alternative_endif
> * size: size of the region
> * Corrupts: kaddr, size, tmp1, tmp2
> */
> + .macro __dcache_op_workaround_clean_cache, op, kaddr
> +alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> + dc \op, \kaddr
> +alternative_else
> + dc civac, \kaddr
> +alternative_endif
> + .endm
> +
> .macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
> dcache_line_size \tmp1, \tmp2
> add \size, \kaddr, \size
> sub \tmp2, \tmp1, #1
> bic \kaddr, \kaddr, \tmp2
> 9998:
> - .if (\op == cvau || \op == cvac)
> -alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> - dc \op, \kaddr
> -alternative_else
> - dc civac, \kaddr
> -alternative_endif
> - .elseif (\op == cvap)
> + .ifc \op, cvau
> + __dcache_op_workaround_clean_cache \op, \kaddr
> + .else
> + .ifc \op, cvac
> + __dcache_op_workaround_clean_cache \op, \kaddr
> + .else
> + .ifc \op, cvap
> alternative_if ARM64_HAS_DCPOP
> sys 3, c7, c12, 1, \kaddr // dc cvap
> -alternative_else
> - dc cvac, \kaddr
> -alternative_endif
> + b 9996f
> +alternative_else_nop_endif
> + __dcache_op_workaround_clean_cache cvac, \kaddr
> +9996:
> .else
> dc \op, \kaddr
> .endif
> + .endif
> + .endif
> add \kaddr, \kaddr, \tmp1
> cmp \kaddr, \size
> b.lo 9998b
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Russell King - ARM Linux @ 2018-12-07 18:00 UTC (permalink / raw)
To: Tony Lindgren; +Cc: netdev, linux-omap, linux-arm-kernel
In-Reply-To: <20181206221447.GM6707@atomide.com>
Hi Tony,
You know most of what's been going on from IRC, but here's the patch
which gets me:
1) working interrupts for networking
2) solves the stuck-wakeup problem
It also contains some of the debug bits I added.
I think what this means is that we should strip out ec0daae685b2
("gpio: omap: Add level wakeup handling for omap4 based SoCs").
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 3d021f648c5d..528ffd1b9832 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -11,7 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-
+#define DEBUG
#include <linux/init.h>
#include <linux/module.h>
#include <linux/interrupt.h>
@@ -366,10 +366,14 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
trigger & IRQ_TYPE_LEVEL_LOW);
omap_gpio_rmw(base, bank->regs->leveldetect1, gpio_bit,
trigger & IRQ_TYPE_LEVEL_HIGH);
+ /*
+ * We need the edge detect enabled for the idle mode detection
+ * to function on OMAP4430.
+ */
omap_gpio_rmw(base, bank->regs->risingdetect, gpio_bit,
- trigger & IRQ_TYPE_EDGE_RISING);
+ trigger & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH));
omap_gpio_rmw(base, bank->regs->fallingdetect, gpio_bit,
- trigger & IRQ_TYPE_EDGE_FALLING);
+ trigger & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW));
bank->context.leveldetect0 =
readl_relaxed(bank->base + bank->regs->leveldetect0);
@@ -910,14 +914,16 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
if (trigger)
omap_set_gpio_triggering(bank, offset, trigger);
+ omap_set_gpio_irqenable(bank, offset, 1);
+
/* For level-triggered GPIOs, the clearing must be done after
- * the HW source is cleared, thus after the handler has run */
- if (bank->level_mask & BIT(offset)) {
- omap_set_gpio_irqenable(bank, offset, 0);
+ * the HW source is cleared, thus after the handler has run.
+ * OMAP4 needs this done _after_ enabing the interrupt to clear
+ * the wakeup status.
+ */
+ if (bank->level_mask & BIT(offset))
omap_clear_gpio_irqstatus(bank, offset);
- }
- omap_set_gpio_irqenable(bank, offset, 1);
raw_spin_unlock_irqrestore(&bank->lock, flags);
}
@@ -1520,6 +1526,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
struct device *dev = bank->chip.parent;
u32 l1 = 0, l2 = 0;
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
+
if (bank->funcs.idle_enable_level_quirk)
bank->funcs.idle_enable_level_quirk(bank);
@@ -1553,6 +1563,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
bank->get_context_loss_count(dev);
omap_gpio_dbck_disable(bank);
+
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
}
static void omap_gpio_init_context(struct gpio_bank *p);
@@ -1563,6 +1577,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
u32 l = 0, gen, gen0, gen1;
int c;
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
+
/*
* On the first resume during the probe, the context has not
* been initialised and so initialise it now. Also initialise
@@ -1648,6 +1666,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
}
bank->workaround_enabled = false;
+
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
}
static void omap_gpio_init_context(struct gpio_bank *p)
@@ -1720,6 +1742,7 @@ static int __maybe_unused omap_gpio_runtime_suspend(struct device *dev)
error = -EBUSY;
goto unlock;
}
+ dev_dbg(dev, "%s()\n", __func__);
omap_gpio_idle(bank, true);
bank->is_suspended = true;
unlock:
@@ -1741,6 +1764,7 @@ static int __maybe_unused omap_gpio_runtime_resume(struct device *dev)
error = -EBUSY;
goto unlock;
}
+ dev_dbg(dev, "%s()\n", __func__);
omap_gpio_unidle(bank);
bank->is_suspended = false;
unlock:
@@ -1827,8 +1851,8 @@ static const struct omap_gpio_platform_data omap4_pdata = {
.regs = &omap4_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
- .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER |
- OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN,
+ .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER /* |
+ OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN */,
};
static const struct of_device_id omap_gpio_match[] = {
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4] arm64: dts: rockchip: Add DT for nanopc-t4
From: Rob Herring @ 2018-12-07 17:56 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Mark Rutland, devicetree, heiko, linux-kernel, linux-rockchip,
linux-arm-kernel, Enric Balletbo i Serra, Ezequiel Garcia,
Liang Chen
In-Reply-To: <20181127091235.50351-1-tomeu.vizoso@collabora.com>
On Tue, Nov 27, 2018 at 10:07:03AM +0100, Tomeu Vizoso wrote:
> This adds a device tree for the NanoPC-T4 SBC, which is based on the
> Rockchip RK3399 SoC and marketed by FriendlyELEC.
>
> Known working:
>
> - Serial
> - Ethernet
> - HDMI
> - USB 2.0
>
> All of the interesting stuff is in a .dtsi because there are at least
> two other boards that share most of it: NanoPi M4 and NanoPi NEO4.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>
> ---
>
> v2: - Rename compatible from friendlyelec to friendlyarm, to match
> existing bindings
> - Remove superfluous node spi1
>
> v3: - Rewrite regulator tree to match the schematics (Heiko)
> - Sort top-level nodes alphabetically (Heiko)
> - Used defines for GPIO numbers (Heiko)
> - Enabled rga (Heiko)
> - Removed cdn_dp node (Heiko)
> - Removed dependencies to fusb0 as extcon (Heiko)
> - Removed superfluous properties (Heiko)
>
> v4: - Replace underscores in node names (Heiko)
> - Reorder entry in makefile (Heiko)
> - Remove superfluous properties and nodes (Heiko and Shawn)
> - Use xin32k as one of the clock outputs of the RK808 (Heiko)
> ---
> .../devicetree/bindings/arm/rockchip.txt | 4 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399-nanopc-t4.dts | 18 +
> .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 732 ++++++++++++++++++
> 4 files changed, 755 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 0cc71236d639..e907d309486e 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -71,6 +71,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
>
> +- FriendlyElec NanoPC-T4 board:
> + Required root node properties:
> + - compatible = "friendlyarm,nanopc-t4", "rockchip,rk3399";
> +
> - ChipSPARK PopMetal-RK3288 board:
> Required root node properties:
> - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 49042c477870..19c129702e06 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-ficus.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
> new file mode 100644
> index 000000000000..0965712b4464
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * FriendlyElec NanoPC-T4 board device tree source
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + */
> +
> +/dts-v1/;
> +#include "rk3399-nanopi4.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPC-T4";
> + compatible = "friendlyarm,nanopc-t4", "rockchip,rk3399";
> +};
> +
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> new file mode 100644
> index 000000000000..e10b98d637d3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> @@ -0,0 +1,732 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * RK3399-based FriendlyElec boards device tree source
> + *
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + vdd_5v: vdd-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc5v0_core: vcc5v0-core {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_core";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vdd_5v>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_core>;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vdd_5v>;
> + };
> +
> + vcc5v0_usb1: vcc5v0-usb1 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb1";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc5v0_usb2: vcc5v0-usb2 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb2";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + /* switched by pmic_sleep */
> + vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vcc_1v8>;
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0_pwr_h>;
> + regulator-always-on;
> + regulator-max-microvolt = <3000000>;
> + regulator-min-microvolt = <3000000>;
> + regulator-name = "vcc3v0_sd";
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + vbus_typec: vbus-typec {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vbus_typec";
> + regulator-always-on;
> + vin-supply = <&vdd_5v>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&power_key>;
> +
> + button@0 {
Build your dtb with W=1 and fix any warnings at least not in the SoC
dtsi file. This line will warn about a unit-address without a reg
property. Just use 'power' for the node name.
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] scsi: ufs: Add HI3670 SoC UFS driver support
From: Manivannan Sadhasivam @ 2018-12-07 17:51 UTC (permalink / raw)
To: vinholikatti, jejb, martin.petersen, liwei213, robh+dt
Cc: devicetree, guodong.xu, linux-scsi, linux-kernel, amit.kucheria,
john.stultz, Manivannan Sadhasivam, linux-arm-kernel
In-Reply-To: <20181207175151.8969-1-manivannan.sadhasivam@linaro.org>
Add HI3670 SoC UFS driver support by extending the common ufs-hisi
driver. One major difference between HI3660 ad HI3670 SoCs interms of
UFS is the PHY. HI3670 has a 10nm variant PHY and hence this parameter is
used to distinguish the configuration.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/scsi/ufs/ufs-hisi.c | 127 +++++++++++++++++++++++++++++-------
drivers/scsi/ufs/ufs-hisi.h | 4 ++
2 files changed, 109 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 452e19f8fb47..f2d3df357a97 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -66,7 +66,7 @@ static int ufs_hisi_check_hibern8(struct ufs_hba *hba)
return err;
}
-static void ufs_hi3660_clk_init(struct ufs_hba *hba)
+static void ufs_hisi_clk_init(struct ufs_hba *hba)
{
struct ufs_hisi_host *host = ufshcd_get_variant(hba);
@@ -80,7 +80,7 @@ static void ufs_hi3660_clk_init(struct ufs_hba *hba)
ufs_sys_ctrl_set_bits(host, BIT_SYSCTRL_REF_CLOCK_EN, PHY_CLK_CTRL);
}
-static void ufs_hi3660_soc_init(struct ufs_hba *hba)
+static void ufs_hisi_soc_init(struct ufs_hba *hba)
{
struct ufs_hisi_host *host = ufshcd_get_variant(hba);
u32 reg;
@@ -139,6 +139,7 @@ static void ufs_hi3660_soc_init(struct ufs_hba *hba)
static int ufs_hisi_link_startup_pre_change(struct ufs_hba *hba)
{
+ struct ufs_hisi_host *host = ufshcd_get_variant(hba);
int err;
uint32_t value;
uint32_t reg;
@@ -153,6 +154,14 @@ static int ufs_hisi_link_startup_pre_change(struct ufs_hba *hba)
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8121, 0x0), 0x2D);
/* MPHY CBOVRCTRL3 */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8122, 0x0), 0x1);
+
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /* MPHY CBOVRCTRL4 */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8127, 0x0), 0x98);
+ /* MPHY CBOVRCTRL5 */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8128, 0x0), 0x1);
+ }
+
/* Unipro VS_MphyCfgUpdt */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0xD085, 0x0), 0x1);
/* MPHY RXOVRCTRL4 rx0 */
@@ -173,10 +182,21 @@ static int ufs_hisi_link_startup_pre_change(struct ufs_hba *hba)
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8113, 0x0), 0x1);
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0xD085, 0x0), 0x1);
- /* Tactive RX */
- ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x4), 0x7);
- /* Tactive RX */
- ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x5), 0x7);
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /* RX_Hibern8Time_Capability*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0092, 0x4), 0xA);
+ /* RX_Hibern8Time_Capability*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0092, 0x5), 0xA);
+ /* RX_Min_ActivateTime */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008f, 0x4), 0xA);
+ /* RX_Min_ActivateTime*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008f, 0x5), 0xA);
+ } else {
+ /* Tactive RX */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x4), 0x7);
+ /* Tactive RX */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x5), 0x7);
+ }
/* Gear3 Synclength */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0095, 0x4), 0x4F);
@@ -208,7 +228,8 @@ static int ufs_hisi_link_startup_pre_change(struct ufs_hba *hba)
if (err)
dev_err(hba->dev, "ufs_hisi_check_hibern8 error\n");
- ufshcd_writel(hba, UFS_HCLKDIV_NORMAL_VALUE, UFS_REG_HCLKDIV);
+ if (!(host->caps & UFS_HISI_CAP_PHY10nm))
+ ufshcd_writel(hba, UFS_HCLKDIV_NORMAL_VALUE, UFS_REG_HCLKDIV);
/* disable auto H8 */
reg = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
@@ -253,7 +274,7 @@ static int ufs_hisi_link_startup_post_change(struct ufs_hba *hba)
return 0;
}
-static int ufs_hi3660_link_startup_notify(struct ufs_hba *hba,
+static int ufs_hisi_link_startup_notify(struct ufs_hba *hba,
enum ufs_notify_change_status status)
{
int err = 0;
@@ -391,6 +412,28 @@ static void ufs_hisi_set_dev_cap(struct ufs_hisi_dev_params *hisi_param)
static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
{
+ struct ufs_hisi_host *host = ufshcd_get_variant(hba);
+
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /*
+ * Boston platform need to set SaveConfigTime to 0x13,
+ * and change sync length to maximum value
+ */
+ /* VS_DebugSaveConfigTime */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0xD0A0), 0x13);
+ /* g1 sync length */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x1552), 0x4f);
+ /* g2 sync length */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x1554), 0x4f);
+ /* g3 sync length */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x1556), 0x4f);
+ /* PA_Hibern8Time */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x15a7), 0xA);
+ /* PA_Tactivate */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x15a8), 0xA);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0xd085, 0x0), 0x01);
+ }
+
if (hba->dev_quirks & UFS_DEVICE_QUIRK_HOST_VS_DEBUGSAVECONFIGTIME) {
pr_info("ufs flash device must set VS_DebugSaveConfigTime 0x10\n");
/* VS_DebugSaveConfigTime */
@@ -429,7 +472,7 @@ static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
ufshcd_dme_set(hba, UIC_ARG_MIB(0xd046), 32767);
}
-static int ufs_hi3660_pwr_change_notify(struct ufs_hba *hba,
+static int ufs_hisi_pwr_change_notify(struct ufs_hba *hba,
enum ufs_notify_change_status status,
struct ufs_pa_layer_attr *dev_max_params,
struct ufs_pa_layer_attr *dev_req_params)
@@ -567,25 +610,72 @@ static int ufs_hi3660_init(struct ufs_hba *hba)
return ret;
}
- ufs_hi3660_clk_init(hba);
+ ufs_hisi_clk_init(hba);
+
+ ufs_hisi_soc_init(hba);
+
+ return 0;
+}
+
+static int ufs_hi3670_init(struct ufs_hba *hba)
+{
+ int ret = 0;
+ struct device *dev = hba->dev;
+ struct ufs_hisi_host *host;
+
+ ret = ufs_hisi_init_common(hba);
+ if (ret) {
+ dev_err(dev, "%s: ufs common init fail\n", __func__);
+ return ret;
+ }
+
+ ufs_hisi_clk_init(hba);
+
+ ufs_hisi_soc_init(hba);
- ufs_hi3660_soc_init(hba);
+ /* Add cap for 10nm PHY variant on HI3670 SoC */
+ host = ufshcd_get_variant(hba);
+ host->caps |= UFS_HISI_CAP_PHY10nm;
return 0;
}
-static struct ufs_hba_variant_ops ufs_hba_hisi_vops = {
+static struct ufs_hba_variant_ops ufs_hba_hi3660_vops = {
.name = "hi3660",
.init = ufs_hi3660_init,
- .link_startup_notify = ufs_hi3660_link_startup_notify,
- .pwr_change_notify = ufs_hi3660_pwr_change_notify,
+ .link_startup_notify = ufs_hisi_link_startup_notify,
+ .pwr_change_notify = ufs_hisi_pwr_change_notify,
.suspend = ufs_hisi_suspend,
.resume = ufs_hisi_resume,
};
+static struct ufs_hba_variant_ops ufs_hba_hi3670_vops = {
+ .name = "hi3670",
+ .init = ufs_hi3670_init,
+ .link_startup_notify = ufs_hisi_link_startup_notify,
+ .pwr_change_notify = ufs_hisi_pwr_change_notify,
+ .suspend = ufs_hisi_suspend,
+ .resume = ufs_hisi_resume,
+};
+
+static const struct of_device_id ufs_hisi_of_match[] = {
+ { .compatible = "hisilicon,hi3660-ufs", .data = &ufs_hba_hi3660_vops },
+ { .compatible = "hisilicon,hi3670-ufs", .data = &ufs_hba_hi3670_vops },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, ufs_hisi_of_match);
+
static int ufs_hisi_probe(struct platform_device *pdev)
{
- return ufshcd_pltfrm_init(pdev, &ufs_hba_hisi_vops);
+ const struct of_device_id *of_id;
+ struct ufs_hba_variant_ops *vops;
+ struct device *dev = &pdev->dev;
+
+ of_id = of_match_node(ufs_hisi_of_match, dev->of_node);
+ vops = (struct ufs_hba_variant_ops *)of_id->data;
+
+ return ufshcd_pltfrm_init(pdev, vops);
}
static int ufs_hisi_remove(struct platform_device *pdev)
@@ -596,13 +686,6 @@ static int ufs_hisi_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id ufs_hisi_of_match[] = {
- { .compatible = "hisilicon,hi3660-ufs" },
- {},
-};
-
-MODULE_DEVICE_TABLE(of, ufs_hisi_of_match);
-
static const struct dev_pm_ops ufs_hisi_pm_ops = {
.suspend = ufshcd_pltfrm_suspend,
.resume = ufshcd_pltfrm_resume,
diff --git a/drivers/scsi/ufs/ufs-hisi.h b/drivers/scsi/ufs/ufs-hisi.h
index 3df9cd7acc29..667dfe39b57e 100644
--- a/drivers/scsi/ufs/ufs-hisi.h
+++ b/drivers/scsi/ufs/ufs-hisi.h
@@ -91,6 +91,9 @@ enum {
#define UFS_HISI_LIMIT_HS_RATE PA_HS_MODE_B
#define UFS_HISI_LIMIT_DESIRED_MODE FAST
+#define UFS_HISI_CAP_RESERVED BIT(0)
+#define UFS_HISI_CAP_PHY10nm BIT(1)
+
struct ufs_hisi_host {
struct ufs_hba *hba;
void __iomem *ufs_sys_ctrl;
@@ -112,4 +115,5 @@ struct ufs_hisi_host {
ufs_sys_ctrl_writel((host), \
((~(mask)) & (ufs_sys_ctrl_readl((host), (reg)))), \
(reg))
+
#endif /* UFS_HISI_H_ */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/5] arm64: assorted fixes for dcache_by_line_op
From: Will Deacon @ 2018-12-07 17:53 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Suzuki Poulose, Marc Zyngier, Catalin Marinas, linux-kernel,
Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
Hi Ard,
Cheers for looking at this.
On Thu, Dec 06, 2018 at 04:57:34PM +0100, Ard Biesheuvel wrote:
> This fixes two issues in dcache_by_line_op: patch #4 fixes the logic
> that is applied when patching DC CVAP instructions, and patch #5 gets
> rid of some unintended undefined symbols resulting from incorrect use
> of conditional GAS directives.
>
> Patches #1 to #3 are groundwork for #4.
>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> Cc: Dave Martin <Dave.Martin@arm.com>
>
> Ard Biesheuvel (5):
> arm64/alternative_cb: move callback reference into replacements
> section
> arm64/alternative_cb: add nr_alts parameter to callback handlers
> arm64/alternative_cb: add support for alternative sequences
> arm64/assembler: use callback to 3-way alt-patch DC CVAP instructions
> arm64/mm: use string comparisons in dcache_by_line_op
>
> arch/arm64/include/asm/alternative.h | 54 +++++++++++---------
> arch/arm64/include/asm/assembler.h | 17 +++---
> arch/arm64/include/asm/kvm_mmu.h | 4 +-
> arch/arm64/kernel/alternative.c | 22 +++++---
> arch/arm64/kernel/cpu_errata.c | 24 ++++++---
> arch/arm64/kvm/va_layout.c | 8 +--
> 6 files changed, 79 insertions(+), 50 deletions(-)
Whilst I can see that this solves the problem, I do wonder whether the
additional infrastructure is really worth it. Couldn't we just do something
really simple like the diff below instead?
Will
--->8
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 953208267252..8dea015b6599 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -390,27 +390,38 @@ alternative_endif
* size: size of the region
* Corrupts: kaddr, size, tmp1, tmp2
*/
+ .macro __dcache_op_workaround_clean_cache, op, kaddr
+alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
+ dc \op, \kaddr
+alternative_else
+ dc civac, \kaddr
+alternative_endif
+ .endm
+
.macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
dcache_line_size \tmp1, \tmp2
add \size, \kaddr, \size
sub \tmp2, \tmp1, #1
bic \kaddr, \kaddr, \tmp2
9998:
- .if (\op == cvau || \op == cvac)
-alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
- dc \op, \kaddr
-alternative_else
- dc civac, \kaddr
-alternative_endif
- .elseif (\op == cvap)
+ .ifc \op, cvau
+ __dcache_op_workaround_clean_cache \op, \kaddr
+ .else
+ .ifc \op, cvac
+ __dcache_op_workaround_clean_cache \op, \kaddr
+ .else
+ .ifc \op, cvap
alternative_if ARM64_HAS_DCPOP
sys 3, c7, c12, 1, \kaddr // dc cvap
-alternative_else
- dc cvac, \kaddr
-alternative_endif
+ b 9996f
+alternative_else_nop_endif
+ __dcache_op_workaround_clean_cache cvac, \kaddr
+9996:
.else
dc \op, \kaddr
.endif
+ .endif
+ .endif
add \kaddr, \kaddr, \tmp1
cmp \kaddr, \size
b.lo 9998b
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: hisilicon: hi3670: Add UFS controller support
From: Manivannan Sadhasivam @ 2018-12-07 17:51 UTC (permalink / raw)
To: vinholikatti, jejb, martin.petersen, liwei213, robh+dt
Cc: devicetree, guodong.xu, linux-scsi, linux-kernel, amit.kucheria,
john.stultz, Manivannan Sadhasivam, linux-arm-kernel
In-Reply-To: <20181207175151.8969-1-manivannan.sadhasivam@linaro.org>
Add UFS controller support for HiSilicon HI3670 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
index 6ccdf5040ffd..285219dd657f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
@@ -654,6 +654,24 @@
clock-names = "apb_pclk";
};
+ /* UFS */
+ ufs: ufs@ff3c0000 {
+ compatible = "hisilicon,hi3670-ufs", "jedec,ufs-2.1";
+ /* 0: HCI standard */
+ /* 1: UFS SYS CTRL */
+ reg = <0x0 0xff3c0000 0x0 0x1000>,
+ <0x0 0xff3e0000 0x0 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg_ctrl HI3670_CLK_GATE_UFSIO_REF>,
+ <&crg_ctrl HI3670_CLK_GATE_UFS_SUBSYS>;
+ clock-names = "ref_clk", "phy_clk";
+ freq-table-hz = <0 0>, <0 0>;
+ /* offset: 0x84; bit: 12 */
+ resets = <&crg_rst 0x84 12>;
+ reset-names = "rst";
+ };
+
/* SD */
dwmmc1: dwmmc1@ff37f000 {
compatible = "hisilicon,hi3670-dw-mshc";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: ufs: Add HI3670 UFS controller binding
From: Manivannan Sadhasivam @ 2018-12-07 17:51 UTC (permalink / raw)
To: vinholikatti, jejb, martin.petersen, liwei213, robh+dt
Cc: devicetree, guodong.xu, linux-scsi, linux-kernel, amit.kucheria,
john.stultz, Manivannan Sadhasivam, linux-arm-kernel
In-Reply-To: <20181207175151.8969-1-manivannan.sadhasivam@linaro.org>
Add devicetree binding for HI3670 UFS controller. HI3760 SoC is very
similar to HI3660 SoC with almost same IPs. Only major difference interms
of UFS is the PHY. HI3670 has 10nm PHY.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
index a48c44817367..a327c1e24365 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
+++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
@@ -6,7 +6,9 @@ Each UFS Host Controller should have its own node.
Required properties:
- compatible : compatible list, contains one of the following -
"hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
- host controller present on Hi36xx chipset.
+ host controller present on Hi3660 chipset.
+ "hisilicon,hi3670-ufs", "jedec,ufs-2.1" for hisi ufs
+ host controller present on Hi3670 chipset.
- reg : should contain UFS register address space & UFS SYS CTRL register address,
- interrupt-parent : interrupt device
- interrupts : interrupt number
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Add UFS controller support for HI3670 SoC
From: Manivannan Sadhasivam @ 2018-12-07 17:51 UTC (permalink / raw)
To: vinholikatti, jejb, martin.petersen, liwei213, robh+dt
Cc: devicetree, guodong.xu, linux-scsi, linux-kernel, amit.kucheria,
john.stultz, Manivannan Sadhasivam, linux-arm-kernel
Hello,
This patchset adds UFS controller support for HiSilicon HI3670 SoC.
HI3760 SoC is very similar to HI3660 SoC with almost same IPs, hence
the same driver is extended to provide UFS support. Only major difference
is the PHY. HI3670 has 10nm PHY, hence that parameter is used to
distinguish the difference between two in driver.
Thanks,
Mani
Manivannan Sadhasivam (3):
dt-bindings: ufs: Add HI3670 UFS controller binding
arm64: dts: hisilicon: hi3670: Add UFS controller support
scsi: ufs: Add HI3670 SoC UFS driver support
.../devicetree/bindings/ufs/ufs-hisi.txt | 4 +-
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 18 +++
drivers/scsi/ufs/ufs-hisi.c | 127 +++++++++++++++---
drivers/scsi/ufs/ufs-hisi.h | 4 +
4 files changed, 130 insertions(+), 23 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
From: Catalin Marinas @ 2018-12-07 17:42 UTC (permalink / raw)
To: Douglas Anderson
Cc: Michal Hocko, Benjamin Herrenschmidt, linux-sh, Peter Zijlstra,
kgdb-bugreport, Will Deacon, linux-kernel, Rich Felker,
Paul Mackerras, Michael Ellerman, H. Peter Anvin, sparclinux,
Daniel Thompson, Yoshinori Sato, linux-hexagon, x86, Russell King,
Ingo Molnar, Huang Ying, James Hogan, linux-snps-arc,
Mike Rapoport, Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Christophe Leroy, Vineet Gupta, linux-mips, Ralf Baechle,
Richard Kuo, Paul Burton, Jason Wessel, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20181205033828.6156-1-dianders@chromium.org>
On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> Douglas Anderson (4):
> kgdb: Remove irq flags from roundup
> kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> kgdb: Don't round up a CPU that failed rounding up before
> kdb: Don't back trace on a cpu that didn't round up
FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y
on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts
disabled when they shouldn't and it trips over the BUG at
mm/vmalloc.c:1380 (called via do_fork -> copy_process).
Now, I don't think these patches make things worse on arm64 since prior
to them the kgdb boot tests on arm64 were stuck in a loop (RUN
singlestep).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] Fix OMAP4430 SDP Ethernet startup
From: Santosh Shilimkar @ 2018-12-07 17:41 UTC (permalink / raw)
To: Russell King - ARM Linux, Tony Lindgren, linux-arm-kernel,
linux-omap, Santosh Shilimkar
In-Reply-To: <20181207125224.GW6920@n2100.armlinux.org.uk>
On 12/7/2018 4:52 AM, Russell King - ARM Linux wrote:
> It was noticed that unbinding and rebinding the KSZ8851 ethernet
> resulted in the driver reporting "failed to read device ID" at probe.
> Probing the reset line with a 'scope while repeatedly attempting to
> bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> constantly held at zero, meaning the device is held in reset, and
> does not respond on the SPI bus.
>
> Experimentation with the startup delay on the regulator set to 50ms
> shows that the reset is positively released after 20ms.
>
> Schematics for this board are not available, and the traces are buried
> in the inner layers of the board which makes tracing where the RSTN pin
> extremely difficult. We can only guess that the RSTN pin is wired to a
> reset generator chip driven off the ethernet supply, which fits the
> observed behaviour.
>
> Include this delay in the regulator startup delay - effectively
> treating the reset as a "supply stable" indicator.
>
> This can not be modelled as a delay in the KSZ8851 driver since the
> reset generation is board specific - if the RSTN pin had been wired to
> a GPIO, reset could be released earlier via the already provided support
> in the KSZ8851 driver.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
Sure. We can add this. Thanks for patch.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: Use of_node_name_eq for node name comparisons
From: Mathieu Poirier @ 2018-12-07 17:36 UTC (permalink / raw)
To: Rob Herring
Cc: Alexander Shishkin, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20181205195050.4759-34-robh@kernel.org>
On Wed, Dec 05, 2018 at 01:50:50PM -0600, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/hwtracing/coresight/of_coresight.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 89092f83567e..7045930fc958 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -80,8 +80,8 @@ static struct device_node *of_coresight_get_port_parent(struct device_node *ep)
> * Skip one-level up to the real device node, if we
> * are using the new bindings.
> */
> - if (!of_node_cmp(parent->name, "in-ports") ||
> - !of_node_cmp(parent->name, "out-ports"))
> + if (of_node_name_eq(parent, "in-ports") ||
> + of_node_name_eq(parent, "out-ports"))
> parent = of_get_next_parent(parent);
Applied - thanks.
>
> return parent;
> --
> 2.19.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] Refactor dummy DMA ops
From: Robin Murphy @ 2018-12-07 17:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-pci, catalin.marinas, rjw, linux-kernel, will.deacon,
linux-acpi, iommu, gregkh, bhelgaas, lenb, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20181207170519.GA26857@lst.de>
On 07/12/2018 17:05, Christoph Hellwig wrote:
> So I'd really prefer if we had a separate dummy.c file, like in
> my take on your previous patch here:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/e01adddc1733fa414dc16cd22e8f58be9b64a025
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/596bde76e5944a3f4beb8c2769067ca88dda127a
>
> Otherwise this looks fine. If you don't minde I'll take your patches,
> apply the move to a separate file and merge it into the above tree.
Sure - TBH I did consider creating a separate file, but then didn't for
mysterious reasons that don't stand up to scrutiny. If you're happy to
do the fixup on top that's fine by me (if culling .map_resource was
intentional, please scrub the last bit of the commit message to match).
I'll make the equivalent change locally anyway just in case there's any
other cause to resend.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] i.MX8MQ support for GPCv2 irqchip driver
From: Marc Zyngier @ 2018-12-07 17:30 UTC (permalink / raw)
To: Andrey Smirnov
Cc: A.s. Dong, Richard Zhu, Jason Cooper, linux-arm-kernel,
linux-kernel, linux-imx, Thomas Gleixner, Leonard Crestez,
cphealy, l.stach
In-Reply-To: <20181206073125.7255-1-andrew.smirnov@gmail.com>
On 06/12/2018 07:31, Andrey Smirnov wrote:
> Everyone:
>
> This series is 4 trivial (and optional) changes and a patch to add
> support for i.MX8MQ to GPCv2 irqchip driver. Bingings for new GPC
> variant were taken from [gpcv2-imx8mq]. Hopefully all of the patches
> are self-explanatory.
>
> Feedback is welcome!
>
> Thanks,
> Andrey Smrinov
>
> [gpcv2-imx8mq] https://lore.kernel.org/linux-arm-kernel/20181116154927.16152-3-l.stach@pengutronix.de/
>
> Andrey Smirnov (5):
> irqchip/irq-imx-gpcv2: Remove unused code
> irqchip/irq-imx-gpcv2: Share reg offset calculation code
> irqchip/irq-imx-gpcv2: Make use of BIT() macro
> irqchip/irq-imx-gpcv2: Make error messages more consistent
> irqchip/irq-imx-gpcv2: Add support for i.MX8MQ
>
> drivers/irqchip/irq-imx-gpcv2.c | 61 ++++++++++++++++++++++++---------
> 1 file changed, 44 insertions(+), 17 deletions(-)
>
I've queued this for 4.21.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Suzuki K Poulose @ 2018-12-07 17:28 UTC (permalink / raw)
To: Will Deacon
Cc: ard.biesheuvel, catalin.marinas, Steve Capper, linux-mm, jcm,
linux-arm-kernel
In-Reply-To: <20181207152529.GB2682@edgewater-inn.cambridge.arm.com>
On 07/12/2018 15:26, Will Deacon wrote:
> On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
>> On 12/06/2018 10:50 PM, Steve Capper wrote:
>>> For cases where there is a mismatch in ARMv8.2-LVA support between CPUs
>>> we have to be careful in allowing secondary CPUs to boot if 52-bit
>>> virtual addresses have already been enabled on the boot CPU.
>>>
>>> This patch adds code to the secondary startup path. If the boot CPU has
>>> enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the
>>> secondary can also enable 52-bit support. If not, the secondary is
>>> prevented from booting and an error message is displayed indicating why.
>>>
>>> Technically this patch could be implemented using the cpufeature code
>>> when considering 52-bit userspace support. However, we employ low level
>>> checks here as the cpufeature code won't be able to run if we have
>>> mismatched 52-bit kernel va support.
>>>
>>> Signed-off-by: Steve Capper <steve.capper@arm.com>
>>>
>>
>> The patch looks good to me, except for one comment below.
>>
>>> ---
>>>
>>> Patch is new in V5 of the series
>>> ---
>>> arch/arm64/kernel/head.S | 26 ++++++++++++++++++++++++++
>>> arch/arm64/kernel/smp.c | 5 +++++
>>> 2 files changed, 31 insertions(+)
>>>
>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>>> index f60081be9a1b..58fcc1edd852 100644
>>> --- a/arch/arm64/kernel/head.S
>>> +++ b/arch/arm64/kernel/head.S
>>> @@ -707,6 +707,7 @@ secondary_startup:
>>> /*
>>> * Common entry point for secondary CPUs.
>>> */
>>> + bl __cpu_secondary_check52bitva
>>> bl __cpu_setup // initialise processor
>>> adrp x1, swapper_pg_dir
>>> bl __enable_mmu
>>> @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
>>> ret
>>> ENDPROC(__enable_mmu)
>>> +ENTRY(__cpu_secondary_check52bitva)
>>> +#ifdef CONFIG_ARM64_52BIT_VA
>>> + ldr_l x0, vabits_user
>>> + cmp x0, #52
>>> + b.ne 2f > +
>>> + mrs_s x0, SYS_ID_AA64MMFR2_EL1
>>> + and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
>>> + cbnz x0, 2f
>>> +
>>> + adr_l x0, va52mismatch
>>> + mov w1, #1
>>> + strb w1, [x0]
>>> + dmb sy
>>> + dc ivac, x0 // Invalidate potentially stale cache line
>>
>> You may have to clear this variable before a CPU is brought up to avoid
>> raising a false error message when another secondary CPU doesn't boot
>> for some other reason (say granule support) after a CPU failed with lack
>> of 52bitva. It is really a crazy corner case.
>
> Can't we just follow the example set by the EL2 setup in the way that is
> uses __boot_cpu_mode? In that case, we only need one variable and you can
> detect a problem by comparing the two halves.
The only difference here is, the support is bolted at boot CPU time and hence
we need to verify each and every CPU, unlike the __boot_cpu_mode where we
check for mismatch after the SMP CPUs are brought up. If we decide to make
the choice later, something like that could work. The only caveat is the 52bit
kernel VA will have to do something like the above.
Cheers
Suzuki
>
> Will
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/12] perf/core: Generalise event exclusion checking
From: Will Deacon @ 2018-12-07 17:25 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Peter Zijlstra, Benjamin Herrenschmidt,
Paul Mackerras, Shawn Guo, Michael Ellerman, x86, Russell King,
Ingo Molnar, Matt Turner, suzuki.poulose, Sascha Hauer,
Arnaldo Carvalho de Melo, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, robin.murphy, linux-kernel,
linux-alpha, Borislav Petkov, linuxppc-dev
In-Reply-To: <1544114849-47266-1-git-send-email-andrew.murray@arm.com>
On Thu, Dec 06, 2018 at 04:47:17PM +0000, Andrew Murray wrote:
> Many PMU drivers do not have the capability to exclude counting events
> that occur in specific contexts such as idle, kernel, guest, etc. These
> drivers indicate this by returning an error in their event_init upon
> testing the events attribute flags.
>
> However this approach requires that each time a new event modifier is
> added to perf, all the perf drivers need to be modified to indicate that
> they don't support the attribute. This results in additional boiler-plate
> code common to many drivers that needs to be maintained. Furthermore the
> drivers are not consistent with regards to the error value they return
> when reporting unsupported attributes.
>
> This patchset allow PMU drivers to advertise their inability to exclude
> based on context via a new capability: PERF_PMU_CAP_NO_EXCLUDE. This
> allows the perf core to reject requests for exclusion events where there
> is no support in the PMU.
>
> This is a functional change, in particular:
>
> - Some drivers will now additionally (but correctly) report unsupported
> exclusion flags. It's typical for existing userspace tools such as
> perf to handle such errors by retrying the system call without the
> unsupported flags.
>
> - Drivers that do not support any exclusion that previously reported
> -EPERM or -EOPNOTSUPP will now report -EINVAL - this is consistent
> with the majority and results in userspace perf retrying without
> exclusion.
>
> All drivers touched by this patchset have been compile tested.
For the bits under arch/arm/ and drivers/perf:
Acked-by: Will Deacon <will.deacon@arm.com>
Note that I've queued the TX2 uncore PMU for 4.21 [1], which could also
benefit from your new flag.
Will
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=69c32972d59388c041268e8206e8eb1acff29b9a
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Ard Biesheuvel @ 2018-12-07 17:18 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20181207171529.GA2044@edgewater-inn.cambridge.arm.com>
On Fri, 7 Dec 2018 at 18:15, Will Deacon <will.deacon@arm.com> wrote:
>
> On Fri, Dec 07, 2018 at 06:03:35PM +0100, Ard Biesheuvel wrote:
> > On Fri, 7 Dec 2018 at 17:22, Will Deacon <will.deacon@arm.com> wrote:
> > > On Fri, Dec 07, 2018 at 05:05:16PM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 7 Dec 2018 at 16:49, Will Deacon <will.deacon@arm.com> wrote:
> > > > > On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> > > > > > On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> > > > > > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > > > > > > index 4d6f917b654e..a424355240c5 100644
> > > > > > > --- a/arch/arm64/include/asm/atomic_lse.h
> > > > > > > +++ b/arch/arm64/include/asm/atomic_lse.h
> > > > > > > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> > > > > > >
> > > > > > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > > > > > > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > > > > - unsigned long old, \
> > > > > > > + u##sz old, \
> > > > > > > u##sz new) \
> > > > > > > { \
> > > > > > > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > > > > > > - register unsigned long x1 asm ("x1") = old; \
> > > > > > > + register u##sz x1 asm ("x1") = old; \
> > > > > >
> > > > > > This looks backwards to me, but perhaps I am missing something:
> > > > > > changing from unsigned long to a narrower type makes it the compiler's
> > > > > > job to perform the cast, no? Given that 'cas' ignores the upper bits
> > > > > > anyway, what does this change buy us?
> > > > >
> > > > > A narrowing cast doesn't actually result in any additional instructions --
> > > > > the masking occurs if you do a widening cast. In this case, the change I'm
> > > > > proposing means we avoid the redundant widening casts for the LSE operations
> > > > > because, as you point out, the underlying instruction only operates on the
> > > > > relevant bits.
> > > > >
> > > >
> > > > Playing around with some code, I found out that
> > > >
> > > > static inline void foo(unsigned char x)
> > > > {
> > > > asm("" :: "r"(x));
> > > > }
> > > >
> > > > void bar(unsigned long l)
> > > > {
> > > > foo(l);
> > > > }
> > > >
> > > > produces different code than
> > > >
> > > > static inline void foo(unsigned longr x)
> > > > {
> > > > asm("" :: "r"(x));
> > > > }
> > > >
> > > > void bar(unsigned long l)
> > > > {
> > > > foo((unsigned char)l);
> > > > }
> > > >
> > > > so what you are saying appears to be accurate. Whether it is correct,
> > > > is another matter, though, since the 'unsigned char' argument passed
> > > > into the asm() block may have higher bits set.
> > >
> > > Right, which is why I've kept the casting for sizes < 32 bits in the LL/SC
> > > code.
> > >
> >
> > OK.
> >
> > So if we are relying on the cast to occur implicitly by the cas
> > instruction, does it really make sense to change the prototype?
> > Shouldn't we keep it at unsigned long so that we explicitly pass the
> > whole value in (but use an explicit cast in the LL/SC implementation
> > as you did)
>
> If we change the prototype of the __cmpxchg_case_* functions so that the
> old and new parameters are unsigned long, then we'll get widening casts
> (and explicit masking) for any caller of cmpxchg() that passes narrower
> types such as u16.
>
> Or are you suggesting something else?
>
No. It's all a bit counter intuitive, at least to me, but if this gets
rid of the casts, then let's go with it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] Fix OMAP4430 SDP Ethernet startup
From: Tony Lindgren @ 2018-12-07 17:16 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Ujfalusi, linux-omap, linux-arm-kernel, Santosh Shilimkar
In-Reply-To: <20181207135751.GZ6920@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [181207 13:58]:
> On Fri, Dec 07, 2018 at 03:40:13PM +0200, Peter Ujfalusi wrote:
> > Russell,
> >
> > On 07/12/2018 14.52, Russell King - ARM Linux wrote:
> > > It was noticed that unbinding and rebinding the KSZ8851 ethernet
> > > resulted in the driver reporting "failed to read device ID" at probe.
> > > Probing the reset line with a 'scope while repeatedly attempting to
> > > bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> > > constantly held at zero, meaning the device is held in reset, and
> > > does not respond on the SPI bus.
> > >
> > > Experimentation with the startup delay on the regulator set to 50ms
> > > shows that the reset is positively released after 20ms.
> > >
> > > Schematics for this board are not available, and the traces are buried
> > > in the inner layers of the board which makes tracing where the RSTN pin
> > > extremely difficult. We can only guess that the RSTN pin is wired to a
> > > reset generator chip driven off the ethernet supply, which fits the
> > > observed behaviour.
> >
> > Based on the schematics of the Blaze device (which should be very close
> > to SDP4430):
> >
> > TPS22902YFPR is used as the regulator switch (gpio48 controlled)
> > The VOUT is routed to TPS3808G01DBV (SCH Note: Threshold set at 90%.
> > Vsense: 0.405V).
> >
> > According to the TPS3808 data sheet the RESET delay time when Ct is open
> > (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
> >
> > The 20ms you are seeing confirms this setup.
>
> Thanks for the confirmation and information. The Blaze schematics
> are also unavailable afaics.
Thanks applying into omap-for-v4.20/fixes with updated notes
from Peter for the wiring.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: WIP: UFS on apq8098
From: Evan Green @ 2018-12-07 17:14 UTC (permalink / raw)
To: marc.w.gonzalez
Cc: jhugo, linux-arm-msm, sboyd, Bjorn Andersson, Andy Gross,
nicolas.dechesne, linux-arm-kernel
In-Reply-To: <bf10cc14-75f0-05b0-dea7-cb19beef5d5d@free.fr>
On Fri, Dec 7, 2018 at 4:10 AM Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
>
> On 06/12/2018 17:45, Evan Green wrote:
>
> > I'll throw my random thought into the hopper here. With one particular
> > brand of UFS part on SDM845 we needed to make sure we banged on the
> > ufs_reset pin before the device would re-initialize fully. My hunch
> > says this is not your issue, but it can't hurt to make sure this is
> > happening.
>
> You might be on to something.
>
> Downstream handles the pinctrl nodes, while upstream doesn't.
>
> $ git grep pinc vendor -- drivers/scsi/ufs/
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c:static int ufshcd_parse_pinctrl_info(struct ufs_hba *hba)
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: /* Try to obtain pinctrl handle */
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: hba->pctrl = devm_pinctrl_get(hba->dev);
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: err = ufshcd_parse_pinctrl_info(hba);
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: dev_dbg(&pdev->dev, "%s: unable to parse pinctrl data %d\n",
> vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
> vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-assert"));
> vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
> vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-deassert"));
> vendor:drivers/scsi/ufs/ufshcd.h: struct pinctrl *pctrl;
>
> $ git grep pinc master -- drivers/scsi/ufs/
> /* NOTHING */
We did this by abusing the "init" pinctrl state, which I think gets
handled automagically. In our board file we have something like this
(forgive the paste butchering):
&ufshc1 {
status = "okay";
pinctrl-names = "init", "default";
pinctrl-0 = <&ufs_dev_reset_assert>;
pinctrl-1 = <&ufs_dev_reset_deassert>;
vcc-supply = <&src_pp2950_l20a>;
vcc-max-microamp = <600000>;
};
&tlmm {
ufs_dev_reset_assert: ufs_dev_reset_assert {
config {
pins = "ufs_reset";
bias-pull-down; /* default: pull down */
drive-strength = <8>; /* default: 3.1 mA */
output-low; /* active low reset */
};
};
ufs_dev_reset_deassert: ufs_dev_reset_deassert {
config {
pins = "ufs_reset";
bias-pull-down; /* default: pull down */
drive-strength = <8>;
output-high; /* active low reset */
};
};
};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox