* Re: [PATCH v5 17/18] dt-bindings: thermal: add binding document for r40 thermal controller
From: Rob Herring @ 2019-08-27 15:27 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-18-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:28 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner r40 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
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
* Re: [PATCH] fdt: Update CRC check for rng-seed
From: Will Deacon @ 2019-08-27 15:27 UTC (permalink / raw)
To: Hsin-Yi Wang; +Cc: Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190827103353.109218-1-hsinyi@chromium.org>
On Tue, Aug 27, 2019 at 06:33:53PM +0800, Hsin-Yi Wang wrote:
> Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
> from early_init_dt_verify() to early_init_dt_scan() since
> early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
>
> However, arm and some other arch won't call early_init_dt_scan(), they
> call early_init_dt_verify() then early_init_dt_scan_nodes().
>
> Restore of_fdt_crc32 to early_init_dt_verify() then update it in
> early_init_dt_scan_chosen() if fdt if updated.
>
> Fixes: 428826f5358c ("fdt: add support for rng-seed")
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
> drivers/of/fdt.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, I'll queue this up with the tags from Geert.
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 v5 14/18] dt-bindings: thermal: add binding document for h5 thermal controller
From: Rob Herring @ 2019-08-27 15:27 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-15-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:25 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner h5 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
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
* Re: [PATCH v5 12/18] dt-bindings: thermal: add binding document for a64 thermal controller
From: Rob Herring @ 2019-08-27 15:26 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-13-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:23 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner a64 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
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
* Re: [PATCH v5 10/18] dt-bindings: thermal: add binding document for h3 thermal controller
From: Rob Herring @ 2019-08-27 15:26 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-11-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:21 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner h3 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> .../bindings/thermal/sun8i-thermal.yaml | 81 ++++++++++++++++++-
> 1 file changed, 78 insertions(+), 3 deletions(-)
>
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
* Re: [PATCH] Documentation: add link to stm32mp157 docs
From: Alexandre Torgue @ 2019-08-27 15:23 UTC (permalink / raw)
To: Jonathan Corbet, Gerald BAEZA
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, linux-doc@vger.kernel.org
In-Reply-To: <20190827074825.64a28e88@lwn.net>
Hi Jonathan,
On 8/27/19 3:48 PM, Jonathan Corbet wrote:
> On Tue, 27 Aug 2019 12:19:32 +0000
> Gerald BAEZA <gerald.baeza@st.com> wrote:
>
>> Link to the online stm32mp157 documentation added
>> in the overview.
>>
>> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
>> ---
>> Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
>> index f62fdc8..8d5a476 100644
>> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
>> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
>> @@ -14,6 +14,12 @@ It features:
>> - Standard connectivity, widely inherited from the STM32 MCU family
>> - Comprehensive security support
>>
>> +Resources
>> +---------
>> +
>> +Datasheet and reference manual are publicly available on ST website:
>> +.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
>> +
>
> Adding the URL is a fine idea. But you don't need the extra syntax to
> create a link if you're not going to actually make a link out of it. So
> I'd take the ".. _STM32MP157:" part out and life will be good.
>
We also did it for older stm32 product. Idea was to not have the "full"
address but just a shortcut of the link when html file is read. It maybe
makes no sens ? (if yes we will have to update older stm32 overview :))
thanks
Alex
> Thanks,
>
> jon
>
_______________________________________________
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 05/20] arm64: dts: marvell: Prepare the introduction of AP807 based SoCs
From: Gregory CLEMENT @ 2019-08-27 15:20 UTC (permalink / raw)
To: Miquel Raynal, Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Maxime Chevallier, Nadav Haklai, Thomas Petazzoni, Miquel Raynal,
Konstantin Porotchkin, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel
In-Reply-To: <20190806145500.24109-6-miquel.raynal@bootlin.com>
Hi Miquel,
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> Prepare the support for Marvell AP807 die. This die is very similar to
> AP806 but uses different DDR PHY. AP807 is a major component of CN9130
> SoC series.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 448 +----------------
> arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 456 ++++++++++++++++++
> 2 files changed, 458 insertions(+), 446 deletions(-)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index a23ddd46efc5..cdadb28f287e 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -5,454 +5,10 @@
> * Device Tree file for Marvell Armada AP806.
> */
>
> -#include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/thermal/thermal.h>
> -
> -/dts-v1/;
> +#define AP_NAME ap806
I didn't find where AP_NAME is used.
> +#include "armada-ap80x.dtsi"
[...]
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> new file mode 100644
> index 000000000000..c44cd7c64bf6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
[...]
> + ap806 {
This file will be used for ap806 and for ap807 but the ap name will be
the same for both varirant?
Shouldn't you use the AP_NAME here?
Gregory
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
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] arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
When we fail to bring a secondary CPU online and it fails in an unknown
state, we should assume the worst and increment 'cpus_stuck_in_kernel'
so that things like kexec() are disabled.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1f8aeb77cba5..dc9fe879c279 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -147,6 +147,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
default:
pr_err("CPU%u: failed in unknown state : 0x%lx\n",
cpu, status);
+ cpus_stuck_in_kernel++;
break;
case CPU_KILL_ME:
if (!op_cpu_kill(cpu)) {
--
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
* [PATCH 2/3] arm64: smp: Don't enter kernel with NULL stack pointer or task struct
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
Although SMP bringup is inherently racy, we can significantly reduce
the window during which secondary CPUs can unexpectedly enter the
kernel by sanity checking the 'stack' and 'task' fields of the
'secondary_data' structure. If the booting CPU gave up waiting for us,
then they will have been cleared to NULL and we should spin in a WFE; WFI
loop instead.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/head.S | 8 ++++++++
arch/arm64/kernel/smp.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 2cdacd1c141b..0baadf335172 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -724,14 +724,22 @@ __secondary_switched:
adr_l x0, secondary_data
ldr x1, [x0, #CPU_BOOT_STACK] // get secondary_data.stack
+ cbz x1, __secondary_too_slow
mov sp, x1
ldr x2, [x0, #CPU_BOOT_TASK]
+ cbz x2, __secondary_too_slow
msr sp_el0, x2
mov x29, #0
mov x30, #0
b secondary_start_kernel
ENDPROC(__secondary_switched)
+__secondary_too_slow:
+ wfe
+ wfi
+ b __secondary_too_slow
+ENDPROC(__secondary_too_slow)
+
/*
* The booting CPU updates the failed status @__early_cpu_boot_status,
* with MMU turned off.
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 63c7a7682e93..1f8aeb77cba5 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -136,6 +136,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
secondary_data.task = NULL;
secondary_data.stack = NULL;
+ __flush_dcache_area(&secondary_data, sizeof(secondary_data));
status = READ_ONCE(secondary_data.status);
if (ret && status) {
--
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
* [PATCH 1/3] arm64: smp: Increase secondary CPU boot timeout value
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
When many debug options are enabled simultaneously (e.g. PROVE_LOCKING,
KMEMLEAK, DEBUG_PAGE_ALLOC, KASAN etc), it is possible for us to timeout
when attempting to boot a secondary CPU and give up. Unfortunately, the
CPU will /eventually/ appear, and sit in the background happily stuck
in a recursive exception due to a NULL stack pointer.
Increase the timeout to 5s, which will of course be enough for anybody.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 018a33e01b0e..63c7a7682e93 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -123,7 +123,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
* time out.
*/
wait_for_completion_timeout(&cpu_running,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(5000));
if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
--
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
* [PATCH 0/3] Try to make SMP booting slightly less fragile
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
Hi everyone,
After spending some time investigating SMP boot issues when using
(random?) configs from Qian Cai with lots of debug options enabled, I
hacked together these two patches which make SMP booting a little more
robust.
The whole thing is still a racy mess, but I'm not sure we can do much
about that without reworking it to use per-cpu data structures which
we can update atomically.
Will
--->8
Will Deacon (3):
arm64: smp: Increase secondary CPU boot timeout value
arm64: smp: Don't enter kernel with NULL stack pointer or task struct
arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
arch/arm64/kernel/head.S | 8 ++++++++
arch/arm64/kernel/smp.c | 4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
--
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
* [PATCH v3 0/5] stm32-ddr-pmu driver creation
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This series adds support for the DDRPERFM via a new stm32-ddr-pmu driver,
registered into the perf framework.
This driver is inspired from arch/arm/mm/cache-l2x0-pmu.c
---
Changes from v1:
- add 'resets' description (bindings) and using (driver). Thanks Rob.
- rebase on 5.2-rc1 (that includes the ddrperfm clock control patch).
Changes from v2:
- rebase on 5.3-rc6 that has to be completed with
'perf tools: fix alignment trap in perf stat': mandatory.
'Documentation: add link to stm32mp157 docs': referenced from this series.
- take into account all remarks from Mark Rutland: thanks for your time!
https://lkml.org/lkml/2019/6/26/388
- fix for event type filtering in stm32_ddr_pmu_event_init()
Gerald Baeza (5):
Documentation: perf: stm32: ddrperfm support
dt-bindings: perf: stm32: ddrperfm support
perf: stm32: ddrperfm driver creation
ARM: configs: enable STM32_DDR_PMU
ARM: dts: stm32: add ddrperfm on stm32mp157c
.../devicetree/bindings/perf/stm32-ddr-pmu.txt | 16 +
Documentation/perf/stm32-ddr-pmu.txt | 37 ++
arch/arm/boot/dts/stm32mp157c.dtsi | 8 +
arch/arm/configs/multi_v7_defconfig | 1 +
drivers/perf/Kconfig | 6 +
drivers/perf/Makefile | 1 +
drivers/perf/stm32_ddr_pmu.c | 426 +++++++++++++++++++++
7 files changed, 495 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
create mode 100644 Documentation/perf/stm32-ddr-pmu.txt
create mode 100644 drivers/perf/stm32_ddr_pmu.c
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 3/5] perf: stm32: ddrperfm driver creation
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
In-Reply-To: <1566918464-23927-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This perf drivers supports the read, write, activate, idle and total
time counters, described in the reference manual RM0436 that is
accessible from Documentation/arm/stm32/stm32mp157-overview.rst
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
drivers/perf/Kconfig | 6 +
drivers/perf/Makefile | 1 +
drivers/perf/stm32_ddr_pmu.c | 426 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 433 insertions(+)
create mode 100644 drivers/perf/stm32_ddr_pmu.c
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 09ae8a9..a3d917e 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -114,6 +114,12 @@ config THUNDERX2_PMU
The SoC has PMU support in its L3 cache controller (L3C) and
in the DDR4 Memory Controller (DMC).
+config STM32_DDR_PMU
+ tristate "STM32 DDR PMU"
+ depends on MACH_STM32MP157
+ help
+ Support for STM32 DDR performance monitor (DDRPERFM).
+
config XGENE_PMU
depends on ARCH_XGENE
bool "APM X-Gene SoC PMU"
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 2ebb4de..fd3368c 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_FSL_IMX8_DDR_PMU) += fsl_imx8_ddr_perf.o
obj-$(CONFIG_HISI_PMU) += hisilicon/
obj-$(CONFIG_QCOM_L2_PMU) += qcom_l2_pmu.o
obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
+obj-$(CONFIG_STM32_DDR_PMU) += stm32_ddr_pmu.o
obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/stm32_ddr_pmu.c b/drivers/perf/stm32_ddr_pmu.c
new file mode 100644
index 0000000..d0480e0
--- /dev/null
+++ b/drivers/perf/stm32_ddr_pmu.c
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This file is the STM32 DDR performance monitor (DDRPERFM) driver
+ *
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ * Author: Gerald Baeza <gerald.baeza@st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/hrtimer.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/perf_event.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+/*
+ * The PMU is able to freeze all counters and generate an interrupt when there
+ * is a counter overflow. But, relying on this means that we lose all the
+ * events that occur between the freeze and the interrupt handler execution.
+ * So we use a polling mechanism to avoid this lose of information.
+ * The fastest counter can overflow in ~8s @533MHz (that is the maximum DDR
+ * frequency supported on STM32MP157), so we poll in 4s intervals to ensure
+ * we don't reach this limit.
+ */
+#define POLL_MS 4000
+
+#define DDRPERFM_CTL 0x000
+#define DDRPERFM_CFG 0x004
+#define DDRPERFM_STATUS 0x008
+#define DDRPERFM_CCR 0x00C
+#define DDRPERFM_IER 0x010
+#define DDRPERFM_ISR 0x014
+#define DDRPERFM_ICR 0x018
+#define DDRPERFM_TCNT 0x020
+#define DDRPERFM_CNT(X) (0x030 + 8 * (X))
+#define DDRPERFM_HWCFG 0x3F0
+#define DDRPERFM_VER 0x3F4
+#define DDRPERFM_ID 0x3F8
+#define DDRPERFM_SID 0x3FC
+
+#define CTL_START 0x00000001
+#define CTL_STOP 0x00000002
+#define CCR_CLEAR_ALL 0x8000000F
+#define SID_MAGIC_ID 0xA3C5DD01
+
+enum {
+ READ_CNT,
+ WRITE_CNT,
+ ACTIVATE_CNT,
+ IDLE_CNT,
+ TIME_CNT,
+ PMU_NR_COUNTERS
+};
+
+struct stm32_ddr_pmu {
+ struct pmu pmu;
+ void __iomem *membase;
+ struct clk *clk;
+ struct hrtimer hrtimer;
+ cpumask_t pmu_cpu;
+ ktime_t poll_period;
+ struct perf_event *events[PMU_NR_COUNTERS];
+ u64 events_cnt[PMU_NR_COUNTERS];
+};
+
+static inline struct stm32_ddr_pmu *pmu_to_stm32_ddr_pmu(struct pmu *p)
+{
+ return container_of(p, struct stm32_ddr_pmu, pmu);
+}
+
+static inline struct stm32_ddr_pmu *hrtimer_to_stm32_ddr_pmu(struct hrtimer *h)
+{
+ return container_of(h, struct stm32_ddr_pmu, hrtimer);
+}
+
+static void stm32_ddr_pmu_event_configure(struct perf_event *event)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ u32 val;
+
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ if (config_base < TIME_CNT) {
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ val |= (1 << config_base);
+ writel_relaxed(val, stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ }
+}
+
+static void stm32_ddr_pmu_event_read(struct perf_event *event)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+ u64 prev_count, new_count, mask;
+ u32 val, offset, bit;
+
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ if (config_base == TIME_CNT) {
+ offset = DDRPERFM_TCNT;
+ bit = 1 << 31;
+ } else {
+ offset = DDRPERFM_CNT(config_base);
+ bit = 1 << config_base;
+ }
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_STATUS);
+ if (val & bit)
+ pr_warn("STM32 DDR PMU hardware counter overflow\n");
+ val = readl_relaxed(stm32_ddr_pmu->membase + offset);
+ writel_relaxed(bit, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ writel_relaxed(CTL_START, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ do {
+ prev_count = local64_read(&hw->prev_count);
+ new_count = prev_count + val;
+ } while (local64_xchg(&hw->prev_count, new_count) != prev_count);
+
+ mask = GENMASK_ULL(31, 0);
+ local64_add(val & mask, &event->count);
+
+ if (new_count < prev_count)
+ pr_warn("STM32 DDR PMU software counter rollover\n");
+}
+
+static void stm32_ddr_pmu_event_start(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ struct hw_perf_event *hw = &event->hw;
+
+ if (WARN_ON_ONCE(!(hw->state & PERF_HES_STOPPED)))
+ return;
+
+ if (flags & PERF_EF_RELOAD)
+ WARN_ON_ONCE(!(hw->state & PERF_HES_UPTODATE));
+
+ stm32_ddr_pmu_event_configure(event);
+
+ /* Clear all counters to synchronize them, then start */
+ writel_relaxed(CCR_CLEAR_ALL, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ writel_relaxed(CTL_START, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+ local64_set(&hw->prev_count, 0);
+ hw->state = 0;
+}
+
+static void stm32_ddr_pmu_event_stop(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+ u32 val, bit;
+
+ if (WARN_ON_ONCE(hw->state & PERF_HES_STOPPED))
+ return;
+
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+ if (config_base == TIME_CNT)
+ bit = 1 << 31;
+ else
+ bit = 1 << config_base;
+ writel_relaxed(bit, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ if (config_base < TIME_CNT) {
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ val &= ~bit;
+ writel_relaxed(val, stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ }
+
+ hw->state |= PERF_HES_STOPPED;
+
+ if (flags & PERF_EF_UPDATE) {
+ stm32_ddr_pmu_event_read(event);
+ hw->state |= PERF_HES_UPTODATE;
+ }
+}
+
+static int stm32_ddr_pmu_event_add(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+
+ stm32_ddr_pmu->events_cnt[config_base] = 0;
+ stm32_ddr_pmu->events[config_base] = event;
+
+ clk_enable(stm32_ddr_pmu->clk);
+ /*
+ * Pin the timer, so that the overflows are handled by the chosen
+ * event->cpu (this is the same one as presented in "cpumask"
+ * attribute).
+ */
+ hrtimer_start(&stm32_ddr_pmu->hrtimer, stm32_ddr_pmu->poll_period,
+ HRTIMER_MODE_REL_PINNED);
+
+ stm32_ddr_pmu_event_configure(event);
+
+ hw->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+
+ if (flags & PERF_EF_START)
+ stm32_ddr_pmu_event_start(event, 0);
+
+ return 0;
+}
+
+static void stm32_ddr_pmu_event_del(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ bool stop = true;
+ int i;
+
+ stm32_ddr_pmu_event_stop(event, PERF_EF_UPDATE);
+
+ stm32_ddr_pmu->events_cnt[config_base] += local64_read(&event->count);
+ stm32_ddr_pmu->events[config_base] = NULL;
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++)
+ if (stm32_ddr_pmu->events[i])
+ stop = false;
+ if (stop)
+ hrtimer_cancel(&stm32_ddr_pmu->hrtimer);
+
+ clk_disable(stm32_ddr_pmu->clk);
+}
+
+static int stm32_ddr_pmu_event_init(struct perf_event *event)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ struct hw_perf_event *hw = &event->hw;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ if (is_sampling_event(event))
+ return -EINVAL;
+
+ if (event->attach_state & PERF_ATTACH_TASK)
+ return -EINVAL;
+
+ if (event->attr.exclude_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest)
+ return -EINVAL;
+
+ if (event->cpu < 0)
+ return -EINVAL;
+
+ hw->config_base = event->attr.config;
+ event->cpu = cpumask_first(&stm32_ddr_pmu->pmu_cpu);
+
+ return 0;
+}
+
+static enum hrtimer_restart stm32_ddr_pmu_poll(struct hrtimer *hrtimer)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = hrtimer_to_stm32_ddr_pmu(hrtimer);
+ int i;
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++)
+ if (stm32_ddr_pmu->events[i])
+ stm32_ddr_pmu_event_read(stm32_ddr_pmu->events[i]);
+
+ hrtimer_forward_now(hrtimer, stm32_ddr_pmu->poll_period);
+
+ return HRTIMER_RESTART;
+}
+
+static ssize_t stm32_ddr_pmu_sysfs_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+ return sprintf(buf, "config=0x%lx\n", (unsigned long)eattr->var);
+}
+
+#define STM32_DDR_PMU_ATTR(_name, _func, _config) \
+ (&((struct dev_ext_attribute[]) { \
+ { __ATTR(_name, 0444, _func, NULL), (void *)_config } \
+ })[0].attr.attr)
+
+#define STM32_DDR_PMU_EVENT_ATTR(_name, _config) \
+ STM32_DDR_PMU_ATTR(_name, stm32_ddr_pmu_sysfs_show, \
+ (unsigned long)_config)
+
+static struct attribute *stm32_ddr_pmu_event_attrs[] = {
+ STM32_DDR_PMU_EVENT_ATTR(read_cnt, READ_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(write_cnt, WRITE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(activate_cnt, ACTIVATE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(idle_cnt, IDLE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(time_cnt, TIME_CNT),
+ NULL
+};
+
+static struct attribute_group stm32_ddr_pmu_event_attrs_group = {
+ .name = "events",
+ .attrs = stm32_ddr_pmu_event_attrs,
+};
+
+static const struct attribute_group *stm32_ddr_pmu_attr_groups[] = {
+ &stm32_ddr_pmu_event_attrs_group,
+ NULL,
+};
+
+static int stm32_ddr_pmu_device_probe(struct platform_device *pdev)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu;
+ struct reset_control *rst;
+ struct resource *res;
+ int i, ret;
+ u32 val;
+
+ stm32_ddr_pmu = devm_kzalloc(&pdev->dev, sizeof(struct stm32_ddr_pmu),
+ GFP_KERNEL);
+ if (!stm32_ddr_pmu)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, stm32_ddr_pmu);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ stm32_ddr_pmu->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(stm32_ddr_pmu->membase)) {
+ pr_warn("Unable to get STM32 DDR PMU membase\n");
+ return PTR_ERR(stm32_ddr_pmu->membase);
+ }
+
+ stm32_ddr_pmu->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(stm32_ddr_pmu->clk)) {
+ pr_warn("Unable to get STM32 DDR PMU clock\n");
+ return PTR_ERR(stm32_ddr_pmu->clk);
+ }
+
+ ret = clk_prepare_enable(stm32_ddr_pmu->clk);
+ if (ret) {
+ pr_warn("Unable to prepare STM32 DDR PMU clock\n");
+ return ret;
+ }
+
+ stm32_ddr_pmu->poll_period = ms_to_ktime(POLL_MS);
+ hrtimer_init(&stm32_ddr_pmu->hrtimer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ stm32_ddr_pmu->hrtimer.function = stm32_ddr_pmu_poll;
+
+ /*
+ * The PMU is assigned to the cpu0 and there is no need to manage cpu
+ * hot plug migration because cpu0 is always the first/last active cpu
+ * during low power transitions.
+ */
+ cpumask_set_cpu(0, &stm32_ddr_pmu->pmu_cpu);
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++) {
+ stm32_ddr_pmu->events[i] = NULL;
+ stm32_ddr_pmu->events_cnt[i] = 0;
+ }
+
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_SID);
+ if (val != SID_MAGIC_ID)
+ return -EINVAL;
+
+ stm32_ddr_pmu->pmu = (struct pmu) {
+ .task_ctx_nr = perf_invalid_context,
+ .start = stm32_ddr_pmu_event_start,
+ .stop = stm32_ddr_pmu_event_stop,
+ .add = stm32_ddr_pmu_event_add,
+ .del = stm32_ddr_pmu_event_del,
+ .event_init = stm32_ddr_pmu_event_init,
+ .attr_groups = stm32_ddr_pmu_attr_groups,
+ };
+ ret = perf_pmu_register(&stm32_ddr_pmu->pmu, "stm32_ddr_pmu", -1);
+ if (ret) {
+ pr_warn("Unable to register STM32 DDR PMU\n");
+ return ret;
+ }
+
+ rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+ if (!IS_ERR(rst)) {
+ reset_control_assert(rst);
+ udelay(2);
+ reset_control_deassert(rst);
+ }
+
+ pr_info("stm32-ddr-pmu: probed (DDRPERFM ID=0x%08x VER=0x%08x)\n",
+ readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_ID),
+ readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_VER));
+
+ clk_disable(stm32_ddr_pmu->clk);
+
+ return 0;
+}
+
+static int stm32_ddr_pmu_device_remove(struct platform_device *pdev)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = platform_get_drvdata(pdev);
+
+ perf_pmu_unregister(&stm32_ddr_pmu->pmu);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_ddr_pmu_of_match[] = {
+ { .compatible = "st,stm32-ddr-pmu" },
+ { },
+};
+
+static struct platform_driver stm32_ddr_pmu_driver = {
+ .driver = {
+ .name = "stm32-ddr-pmu",
+ .of_match_table = of_match_ptr(stm32_ddr_pmu_of_match),
+ },
+ .probe = stm32_ddr_pmu_device_probe,
+ .remove = stm32_ddr_pmu_device_remove,
+};
+
+module_platform_driver(stm32_ddr_pmu_driver);
+
+MODULE_DESCRIPTION("Perf driver for STM32 DDR performance monitor");
+MODULE_AUTHOR("Gerald Baeza <gerald.baeza@st.com>");
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/5] Documentation: perf: stm32: ddrperfm support
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
In-Reply-To: <1566918464-23927-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This documentation introduces the DDRPERFM, the stm32-ddr-pmu driver
supporting it and how to use it with the perf tool.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/perf/stm32-ddr-pmu.txt | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/perf/stm32-ddr-pmu.txt
diff --git a/Documentation/perf/stm32-ddr-pmu.txt b/Documentation/perf/stm32-ddr-pmu.txt
new file mode 100644
index 0000000..557bf47
--- /dev/null
+++ b/Documentation/perf/stm32-ddr-pmu.txt
@@ -0,0 +1,37 @@
+STM32 DDR Performance Monitor (DDRPERFM)
+========================================
+
+The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
+See Documentation/arm/stm32/stm32mp157-overview.rst to get access to
+STM32MP157 reference manual RM0436 where DDRPERFM is described.
+
+
+The five following counters are supported by stm32-ddr-pmu driver:
+ cnt0: read operations counters (read_cnt)
+ cnt1: write operations counters (write_cnt)
+ cnt2: active state counters (activate_cnt)
+ cnt3: idle state counters (idle_cnt)
+ tcnt: time count, present for all sets (time_cnt)
+
+The stm32-ddr-pmu driver relies on the perf PMU framework to expose the
+counters via sysfs:
+ $ ls /sys/bus/event_source/devices/ddrperfm/events
+ activate_cnt idle_cnt read_cnt time_cnt write_cnt
+
+
+The perf PMU framework is usually invoked via the 'perf stat' tool.
+
+The DDRPERFM is a system monitor that cannot isolate the traffic coming from a
+given thread or CPU, that is why stm32-ddr-pmu driver rejects any 'perf stat'
+call that does not request a system-wide collection: the '-a, --all-cpus'
+option is mandatory!
+
+Example:
+ $ perf stat -e ddrperfm/read_cnt/,ddrperfm/time_cnt/ -a sleep 20
+ Performance counter stats for 'system wide':
+
+ 342541560 ddrperfm/read_cnt/
+ 10660011400 ddrperfm/time_cnt/
+
+ 20.021068551 seconds time elapsed
+
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/5] ARM: configs: enable STM32_DDR_PMU
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
In-Reply-To: <1566918464-23927-1-git-send-email-gerald.baeza@st.com>
STM32_DDR_PMU enables the perf driver that
controls the DDR Performance Monitor (DDRPERFM)
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6a40bc2..8fa4690 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1011,6 +1011,7 @@ CONFIG_PHY_DM816X_USB=m
CONFIG_OMAP_USB2=y
CONFIG_TI_PIPE3=y
CONFIG_TWL4030_USB=m
+CONFIG_STM32_DDR_PMU=m
CONFIG_MESON_MX_EFUSE=m
CONFIG_ROCKCHIP_EFUSE=m
CONFIG_NVMEM_IMX_OCOTP=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: perf: stm32: ddrperfm support
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
In-Reply-To: <1566918464-23927-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This documentation indicates how to enable stm32-ddr-pmu driver on
DDRPERFM peripheral, via the device tree.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
diff --git a/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt b/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
new file mode 100644
index 0000000..87ab12e
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
@@ -0,0 +1,16 @@
+* STM32 DDR Performance Monitor (DDRPERFM)
+
+Required properties:
+- compatible: must be "st,stm32-ddr-pmu".
+- reg: physical address and length of the registers set.
+- clocks: phandle and specifier for DDRPERFM input clock
+- resets: phandle and specifier for DDRPERFM reset
+
+Example:
+ ddrperfm: perf@5a007000 {
+ compatible = "st,stm32-ddr-pmu";
+ reg = <0x5a007000 0x400>;
+ clocks = <&rcc DDRPERFM>;
+ resets = <&rcc DDRPERFM_R>;
+ };
+
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 5/5] ARM: dts: stm32: add ddrperfm on stm32mp157c
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
In-Reply-To: <1566918464-23927-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded
in STM32MP1 SOC.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 0c4e6eb..6ea6933 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1378,6 +1378,14 @@
};
};
+ ddrperfm: perf@5a007000 {
+ compatible = "st,stm32-ddr-pmu";
+ reg = <0x5a007000 0x400>;
+ clocks = <&rcc DDRPERFM>;
+ resets = <&rcc DDRPERFM_R>;
+ status = "okay";
+ };
+
usart1: serial@5c000000 {
compatible = "st,stm32h7-uart";
reg = <0x5c000000 0x400>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Continuous SD IO causes hung task messages
From: Russell King - ARM Linux admin @ 2019-08-27 15:06 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190827145216.GM13294@shell.armlinux.org.uk>
On Tue, Aug 27, 2019 at 03:52:17PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 27, 2019 at 03:36:34PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> > > On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > Hi,
> > > >
> > > > While dd'ing the contents of a SD card, I get hung task timeout
> > > > messages as per below. However, the dd is making progress. Any
> > > > ideas?
> > > >
> > > > Presumably, mmc_rescan doesn't get a look-in while IO is progressing
> > > > for the card?
> > >
> > > Is it a regression?
> > >
> > > There not much of recent mmc core and mmc block changes, that I can
> > > think of at this point.
> >
> > No idea - I just repaired the SD socket after the D2 line became
> > disconnected, and decided to run that command as a test.
> >
> > > > ARM64 host, Macchiatobin, uSD card.
> > >
> > > What mmc host driver is it? mmci?
> >
> > sdhci-xenon.
> >
> > I'm just trying with one CPU online, then I'll try with two. My
> > suspicion is that there's a problem in the ARM64 arch code where
> > unlocking a mutex doesn't get noticed on other CPUs.
> >
> > Hmm, I thought I'd try bringing another CPU online, but it seems
> > like the ARM64 CPU hotplug code is broken:
> >
> > [ 3552.029689] CPU1: shutdown
> > [ 3552.031099] psci: CPU1 killed.
> > [ 3949.835212] CPU1: failed to come online
> > [ 3949.837753] CPU1: failed in unknown state : 0x0
> >
> > which means I can only take CPUs down, I can't bring them back
> > online without rebooting.
>
> Okay, running on a single CPU shows no problems.
>
> Running on four CPUs (as originally) shows that the kworker thread
> _never_ gets scheduled, so the warning is not false.
>
> With three CPUs, same problem.
>
> root@arm-d06300000000:~# ps aux | grep ' D '
> root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
> root@arm-d06300000000:~# cat /proc/34/sched
> kworker/1:1 (34, #threads: 1)
> -------------------------------------------------------------------
> se.exec_start : 318689.992440
> se.vruntime : 37750.882357
> se.sum_exec_runtime : 9.421240
> se.nr_migrations : 0
> nr_switches : 1174
> nr_voluntary_switches : 1171
> nr_involuntary_switches : 3
> se.load.weight : 1048576
> se.runnable_weight : 1048576
> se.avg.load_sum : 6
> se.avg.runnable_load_sum : 6
> se.avg.util_sum : 5170
> se.avg.load_avg : 0
> se.avg.runnable_load_avg : 0
> se.avg.util_avg : 0
> se.avg.last_update_time : 318689991680
> se.avg.util_est.ewma : 10
> se.avg.util_est.enqueued : 0
> policy : 0
> prio : 120
> clock-delta : 0
>
> The only thing that changes there is "clock-delta". When I kill the
> dd, I get:
>
> root@arm-d06300000000:~# cat /proc/34/sched
> kworker/1:1 (34, #threads: 1)
> -------------------------------------------------------------------
> se.exec_start : 574025.791680
> se.vruntime : 79996.657300
> se.sum_exec_runtime : 10.916400
> se.nr_migrations : 0
> nr_switches : 1403
> nr_voluntary_switches : 1400
> nr_involuntary_switches : 3
> se.load.weight : 1048576
> se.runnable_weight : 1048576
> se.avg.load_sum : 15
> se.avg.runnable_load_sum : 15
> se.avg.util_sum : 15007
> se.avg.load_avg : 0
> se.avg.runnable_load_avg : 0
> se.avg.util_avg : 0
> se.avg.last_update_time : 574025791488
> se.avg.util_est.ewma : 10
> se.avg.util_est.enqueued : 0
> policy : 0
> prio : 120
> clock-delta : 40
>
> so the thread makes forward progress.
>
> Down to two CPUs:
>
> root@arm-d06300000000:~# ps aux | grep ' D '
> root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
>
> Same symptoms. dd and md5sum switch between CPU 0 and CPU1.
Hmm.
static blk_status_t mmc_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
mq->in_flight[issue_type] += 1;
get_card = (mmc_tot_in_flight(mq) == 1);
if (get_card)
mmc_get_card(card, &mq->ctx);
mmc_get_card() gets the host lock according to the card.
So, if we always have requests in flight (which is probably the case
here) we never drop the host lock, and mmc_rescan() never gets a look
in - hence blocking the kworker.
So this is a real issue with MMC, and not down to something in the
arch.
I suspect the reason that single-CPU doesn't show it is because it is
unable to keep multiple requests in flight.
--
RMK's Patch system: https://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
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Leonard Crestez @ 2019-08-27 15:04 UTC (permalink / raw)
To: Jurgen Lambrecht
Cc: Aisheng Dong, Robin Gong, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1e2fe2dc-f5ea-db73-59cf-c61ec558131a@televic.com>
On 27.08.2019 16:35, Jurgen Lambrecht wrote:
> We are updating our kernel on our custom board with an iMX6UL from 3.14
> to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin v3.5
> the kernel hangs when booting, only "Starting kernel ..." is printed (by
> uBoot I think).
If you enable "earlycon" you should be able to see an useful error
message from crashes in early boot.
Enabling earlycon is board-specific: if you have a correct
/chosen/stdout-path reference in dts just adding "earlycon" to kernel
cmdline should work otherwise you can specify
earlycon=ec_imx6q,0x202000,115200 with the exact address depending on
which uart is console on your board.
> When I remove the sdma bin (built-in the kernel via EXTRA_FIRMWARE),
> then it boots.
>
> I found that the slab allocator (menu config -> General setup -> Choose
> SLAB allocator) is the culprit: when using imx_v6_v7_defconfig the
> kernel boots, but not with our config (based on a tiny config I think).
> And the config that makes the difference is the slab allocator: with
> SLUB or SLAB the kernel (with sdma bin) boots, but not with SLOB.
>
> I don't know how to force selecting SLUB in Kconfig when selecting
> IMX_SDMA, but anyhow first this issue must be confirmed on other
> processors from the iMX family.
If there's an incompatibility between SLOB and sdma then it's sounds
like a bug which should be fixed, not worked around via kconfig.
I tried to enable EXTRA_FIRMWARE on v4.19.68 and imx6ul-14x14-evk booted
worked fine for me with these changes:
diff --git arch/arm/configs/imx_v6_v7_defconfig
arch/arm/configs/imx_v6_v7_defconfig
index 7f524cee1357..cedd4d2e0e02 100644
--- arch/arm/configs/imx_v6_v7_defconfig
+++ arch/arm/configs/imx_v6_v7_defconfig
@@ -11,8 +11,8 @@ CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
-# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
+CONFIG_SLOB=y
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MXC=y
CONFIG_MACH_MX31LILLY=y
@@ -90,6 +90,10 @@ CONFIG_RFKILL_INPUT=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
+CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx6q.bin"
+CONFIG_EXTRA_FIRMWARE_DIR="../linux-firmware"
+CONFIG_FW_LOADER_USER_HELPER=y
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_IMX_WEIM=y
CONFIG_CONNECTOR=y
Please try to get a stack dump with earlycon.
--
Regards,
Leonard
_______________________________________________
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: Continuous SD IO causes hung task messages
From: Russell King - ARM Linux admin @ 2019-08-27 14:52 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190827143634.GL13294@shell.armlinux.org.uk>
On Tue, Aug 27, 2019 at 03:36:34PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> > On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > Hi,
> > >
> > > While dd'ing the contents of a SD card, I get hung task timeout
> > > messages as per below. However, the dd is making progress. Any
> > > ideas?
> > >
> > > Presumably, mmc_rescan doesn't get a look-in while IO is progressing
> > > for the card?
> >
> > Is it a regression?
> >
> > There not much of recent mmc core and mmc block changes, that I can
> > think of at this point.
>
> No idea - I just repaired the SD socket after the D2 line became
> disconnected, and decided to run that command as a test.
>
> > > ARM64 host, Macchiatobin, uSD card.
> >
> > What mmc host driver is it? mmci?
>
> sdhci-xenon.
>
> I'm just trying with one CPU online, then I'll try with two. My
> suspicion is that there's a problem in the ARM64 arch code where
> unlocking a mutex doesn't get noticed on other CPUs.
>
> Hmm, I thought I'd try bringing another CPU online, but it seems
> like the ARM64 CPU hotplug code is broken:
>
> [ 3552.029689] CPU1: shutdown
> [ 3552.031099] psci: CPU1 killed.
> [ 3949.835212] CPU1: failed to come online
> [ 3949.837753] CPU1: failed in unknown state : 0x0
>
> which means I can only take CPUs down, I can't bring them back
> online without rebooting.
Okay, running on a single CPU shows no problems.
Running on four CPUs (as originally) shows that the kworker thread
_never_ gets scheduled, so the warning is not false.
With three CPUs, same problem.
root@arm-d06300000000:~# ps aux | grep ' D '
root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
root@arm-d06300000000:~# cat /proc/34/sched
kworker/1:1 (34, #threads: 1)
-------------------------------------------------------------------
se.exec_start : 318689.992440
se.vruntime : 37750.882357
se.sum_exec_runtime : 9.421240
se.nr_migrations : 0
nr_switches : 1174
nr_voluntary_switches : 1171
nr_involuntary_switches : 3
se.load.weight : 1048576
se.runnable_weight : 1048576
se.avg.load_sum : 6
se.avg.runnable_load_sum : 6
se.avg.util_sum : 5170
se.avg.load_avg : 0
se.avg.runnable_load_avg : 0
se.avg.util_avg : 0
se.avg.last_update_time : 318689991680
se.avg.util_est.ewma : 10
se.avg.util_est.enqueued : 0
policy : 0
prio : 120
clock-delta : 0
The only thing that changes there is "clock-delta". When I kill the
dd, I get:
root@arm-d06300000000:~# cat /proc/34/sched
kworker/1:1 (34, #threads: 1)
-------------------------------------------------------------------
se.exec_start : 574025.791680
se.vruntime : 79996.657300
se.sum_exec_runtime : 10.916400
se.nr_migrations : 0
nr_switches : 1403
nr_voluntary_switches : 1400
nr_involuntary_switches : 3
se.load.weight : 1048576
se.runnable_weight : 1048576
se.avg.load_sum : 15
se.avg.runnable_load_sum : 15
se.avg.util_sum : 15007
se.avg.load_avg : 0
se.avg.runnable_load_avg : 0
se.avg.util_avg : 0
se.avg.last_update_time : 574025791488
se.avg.util_est.ewma : 10
se.avg.util_est.enqueued : 0
policy : 0
prio : 120
clock-delta : 40
so the thread makes forward progress.
Down to two CPUs:
root@arm-d06300000000:~# ps aux | grep ' D '
root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
Same symptoms. dd and md5sum switch between CPU 0 and CPU1.
--
RMK's Patch system: https://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
* Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Andrew Murray @ 2019-08-27 14:48 UTC (permalink / raw)
To: Xiaowei Bao
Cc: christophe leroy, mark.rutland@arm.com, bhelgaas@google.com,
lorenzo.pieralisi@arm.co, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org, Leo Li,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, Roy Zang,
jingoohan1@gmail.com, shawnguo@kernel.org,
gustavo.pimentel@synopsys.com, linuxppc-dev@lists.ozlabs.org,
Mingkai Hu
In-Reply-To: <AM5PR04MB3299EBADE7BC04C3465B7DB7F5A60@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Sun, Aug 25, 2019 at 03:07:32AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: christophe leroy <christophe.leroy@c-s.fr>
> > Sent: 2019年8月24日 14:45
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>; Andrew Murray
> > <andrew.murray@arm.com>
> > Cc: mark.rutland@arm.com; Roy Zang <roy.zang@nxp.com>;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; devicetree@vger.kernel.org;
> > gregkh@linuxfoundation.org; linuxppc-dev@lists.ozlabs.org;
> > linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; kishon@ti.com; M.h.
> > Lian <minghuan.lian@nxp.com>; robh+dt@kernel.org;
> > gustavo.pimentel@synopsys.com; jingoohan1@gmail.com;
> > bhelgaas@google.com; Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org;
> > Mingkai Hu <mingkai.hu@nxp.com>; linux-arm-kernel@lists.infradead.org
> > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> > ls1088a and ls2088a
> >
> >
> >
> > Le 24/08/2019 à 02:18, Xiaowei Bao a écrit :
> > >
> > >
> > >> -----Original Message-----
> > >> From: Andrew Murray <andrew.murray@arm.com>
> > >> Sent: 2019年8月23日 22:28
> > >> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > >> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > >> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > >> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org;
> > M.h.
> > >> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > >> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > >> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > >> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > >> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> > >> for ls1088a and ls2088a
> > >>
> > >> On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > >>> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > >>> difference between LS1 and LS2 platform, so refactor the code of the
> > >>> EP driver.
> > >>>
> > >>> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > >>> ---
> > >>> v2:
> > >>> - New mechanism for layerscape EP driver.
> > >>
> > >> Was there a v1 of this patch?
> > >
> > > Yes, but I don't know how to comments, ^_^
> >
> > As far as I can see, in the previous version of the series
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > work.ozlabs.org%2Fproject%2Flinuxppc-dev%2Flist%2F%3Fseries%3D125315
> > %26state%3D*&data=02%7C01%7Cxiaowei.bao%40nxp.com%7C1befe9
> > a67c8046f9535e08d7285eaab6%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> > 7C0%7C0%7C637022259387139020&sdata=p4wbycd04Z7qRUfAoZtwc
> > UP7pR%2FuA3%2FjVcWMz6YyQVQ%3D&reserved=0),
> > the 8/10 was something completely different, and I can't find any other patch
> > in the series that could have been the v1 of this patch.
>
> Thanks, I will correct it to v1 in next version patch.
I think you numbered it correctly (so please leave it as v2, referring to
the patch series revision) - I got confused trying to find a previous
version of this patch.
Perhaps in the future when new patches are introduced in a series you can
indicate that in the description patch revision history (e.g. introduced
in v2).
Thanks,
Andrew Murray
>
> >
> > Christophe
> >
> > >
> > >>
> > >>>
> > >>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > >>> ++++++++++++++++++++------
> > >>> 1 file changed, 58 insertions(+), 18 deletions(-)
> > >>>
> > >>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> index 7ca5fe8..2a66f07 100644
> > >>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> @@ -20,27 +20,29 @@
> > >>>
> > >>> #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > >>>
> > >>> -struct ls_pcie_ep {
> > >>> - struct dw_pcie *pci;
> > >>> - struct pci_epc_features *ls_epc;
> > >>> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > >>> +
> > >>> +struct ls_pcie_ep_drvdata {
> > >>> + u32 func_offset;
> > >>> + const struct dw_pcie_ep_ops *ops;
> > >>> + const struct dw_pcie_ops *dw_pcie_ops;
> > >>> };
> > >>>
> > >>> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > >>> +struct ls_pcie_ep {
> > >>> + struct dw_pcie *pci;
> > >>> + struct pci_epc_features *ls_epc;
> > >>> + const struct ls_pcie_ep_drvdata *drvdata; };
> > >>>
> > >>> static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > >>> return 0;
> > >>> }
> > >>>
> > >>> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > >>> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > >>> .start_link = ls_pcie_establish_link, };
> > >>>
> > >>> -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > >>> - { .compatible = "fsl,ls-pcie-ep",},
> > >>> - { },
> > >>> -};
> > >>> -
> > >>> static const struct pci_epc_features*
> > >>> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10 +84,44
> > >>> @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > >>> }
> > >>> }
> > >>>
> > >>> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > >>> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > >>> + u8 func_no)
> > >>> +{
> > >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > >>> + u8 header_type;
> > >>> +
> > >>> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > >>> +
> > >>> + if (header_type & (1 << 7))
> > >>> + return pcie->drvdata->func_offset * func_no;
> > >>> + else
> > >>> + return 0;
> > >>
> > >> It looks like there isn't a PCI define for multi function, the
> > >> nearest I could find was PCI_HEADER_TYPE_MULTIDEVICE in
> > >> hotplug/ibmphp.h. A comment above the test might be helpful to explain
> > the test.
> > >
> > > Yes, I have not find the PCI_HEADER_TYPE_MULTIDEVICE define. OK, I
> > > will add The comments in next version patch.
> > >
> > >>
> > >> As the ls_pcie_ep_drvdata structures are static, the unset
> > >> .func_offset will be initialised to 0, so you could just drop the test above.
> > >
> > > OK, thanks
> > >
> > >>
> > >> However something to the effect of the following may help spot
> > >> misconfiguration:
> > >>
> > >> WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > >> pcie->drvdata->func_offset * func_no;
> > >
> > > Thanks a lot, this looks better.
> > >
> > >>
> > >> The WARN is probably quite useful as if you are attempting to use
> > >> non-zero functions and func_offset isn't set - then things may appear
> > >> to work normally but actually will break horribly.
> > >
> > > got it, thanks.
> > >
> > >>
> > >> Thanks,
> > >>
> > >> Andrew Murray
> > >>
> > >>> +}
> > >>> +
> > >>> +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > >>> .ep_init = ls_pcie_ep_init,
> > >>> .raise_irq = ls_pcie_ep_raise_irq,
> > >>> .get_features = ls_pcie_ep_get_features,
> > >>> + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > >>> +
> > >>> +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > >>> + .ops = &ls_pcie_ep_ops,
> > >>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > >>> +
> > >>> +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > >>> + .func_offset = 0x20000,
> > >>> + .ops = &ls_pcie_ep_ops,
> > >>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > >>> +
> > >>> +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > >>> + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > >>> + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > >>> + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > >>> + { },
> > >>> };
> > >>>
> > >>> static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -98,7
> > >>> +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > >>> int ret;
> > >>>
> > >>> ep = &pci->ep;
> > >>> - ep->ops = &pcie_ep_ops;
> > >>> + ep->ops = pcie->drvdata->ops;
> > >>>
> > >>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > >> "addr_space");
> > >>> if (!res)
> > >>> @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct
> > >> platform_device *pdev)
> > >>> if (!ls_epc)
> > >>> return -ENOMEM;
> > >>>
> > >>> - dbi_base = platform_get_resource_byname(pdev,
> > IORESOURCE_MEM,
> > >> "regs");
> > >>> - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > >>> - if (IS_ERR(pci->dbi_base))
> > >>> - return PTR_ERR(pci->dbi_base);
> > >>> + pcie->drvdata = of_device_get_match_data(dev);
> > >>>
> > >>> - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > >>> pci->dev = dev;
> > >>> - pci->ops = &ls_pcie_ep_ops;
> > >>> + pci->ops = pcie->drvdata->dw_pcie_ops;
> > >>> +
> > >>> pcie->pci = pci;
> > >>>
> > >>> ls_epc->linkup_notifier = false,
> > >>> @@ -152,6 +185,13 @@ static int __init ls_pcie_ep_probe(struct
> > >>> platform_device *pdev)
> > >>>
> > >>> pcie->ls_epc = ls_epc;
> > >>>
> > >>> + dbi_base = platform_get_resource_byname(pdev,
> > IORESOURCE_MEM,
> > >> "regs");
> > >>> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > >>> + if (IS_ERR(pci->dbi_base))
> > >>> + return PTR_ERR(pci->dbi_base);
> > >>> +
> > >>> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > >>> +
> > >>> platform_set_drvdata(pdev, pcie);
> > >>>
> > >>> ret = ls_add_pcie_ep(pcie, pdev);
> > >>> --
> > >>> 2.9.5
> > >>>
> >
> > ---
> > L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
> > antivirus Avast.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > avast.com%2Fantivirus&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > C1befe9a67c8046f9535e08d7285eaab6%7C686ea1d3bc2b4c6fa92cd99c5c3
> > 01635%7C0%7C0%7C637022259387139020&sdata=JAYds7X%2FHVxgtrg
> > e%2F%2FvnP84zdb2yReXcctQUiSLC11I%3D&reserved=0
>
_______________________________________________
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 v7 6/6] arm64: dts: marvell: Add cpu clock node on Armada 7K/8K
From: Gregory CLEMENT @ 2019-08-27 14:40 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: devicetree, Jason Cooper, Andrew Lunn, Antoine Tenart,
Maxime Chevallier, Rob Herring, Thomas Petazzoni,
Miquèl Raynal, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190710134346.30239-7-gregory.clement@bootlin.com>
> Add cpu clock node on AP
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Applied on mvebu/dt64
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 4 ++++
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 7 +++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
> index 2baafe12ebd4..472211159979 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
> @@ -20,24 +20,28 @@
> compatible = "arm,cortex-a72";
> reg = <0x000>;
> enable-method = "psci";
> + clocks = <&cpu_clk 0>;
> };
> cpu1: cpu@1 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> reg = <0x001>;
> enable-method = "psci";
> + clocks = <&cpu_clk 0>;
> };
> cpu2: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> reg = <0x100>;
> enable-method = "psci";
> + clocks = <&cpu_clk 1>;
> };
> cpu3: cpu@101 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> reg = <0x101>;
> enable-method = "psci";
> + clocks = <&cpu_clk 1>;
> };
> };
> };
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 91dad7e4ee59..fca6536494b3 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -280,6 +280,13 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + cpu_clk: clock-cpu@278 {
> + compatible = "marvell,ap806-cpu-clock";
> + clocks = <&ap_clk 0>, <&ap_clk 1>;
> + #clock-cells = <1>;
> + reg = <0x278 0xa30>;
> + };
> +
> ap_thermal: thermal-sensor@80 {
> compatible = "marvell,armada-ap806-thermal";
> reg = <0x80 0x10>;
> --
> 2.20.1
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Continuous SD IO causes hung task messages
From: Russell King - ARM Linux admin @ 2019-08-27 14:36 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <CAPDyKFp7e2OD_idam3-2sEd0wJU5OcP=H04G1OvHmAUo2Y-bYw@mail.gmail.com>
On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > Hi,
> >
> > While dd'ing the contents of a SD card, I get hung task timeout
> > messages as per below. However, the dd is making progress. Any
> > ideas?
> >
> > Presumably, mmc_rescan doesn't get a look-in while IO is progressing
> > for the card?
>
> Is it a regression?
>
> There not much of recent mmc core and mmc block changes, that I can
> think of at this point.
No idea - I just repaired the SD socket after the D2 line became
disconnected, and decided to run that command as a test.
> > ARM64 host, Macchiatobin, uSD card.
>
> What mmc host driver is it? mmci?
sdhci-xenon.
I'm just trying with one CPU online, then I'll try with two. My
suspicion is that there's a problem in the ARM64 arch code where
unlocking a mutex doesn't get noticed on other CPUs.
Hmm, I thought I'd try bringing another CPU online, but it seems
like the ARM64 CPU hotplug code is broken:
[ 3552.029689] CPU1: shutdown
[ 3552.031099] psci: CPU1 killed.
[ 3949.835212] CPU1: failed to come online
[ 3949.837753] CPU1: failed in unknown state : 0x0
which means I can only take CPUs down, I can't bring them back
online without rebooting.
--
RMK's Patch system: https://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
* Re: [RFC PATCH 5/7] arm64: smp: use generic SMP stop common code
From: Cristian Marussi @ 2019-08-27 14:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-arch, mark.rutland, peterz, catalin.marinas, linux-kernel,
Christoph Hellwig, takahiro.akashi, james.morse,
hidehiro.kawai.ez, will, dave.martin, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1908270025340.1939@nanos.tec.linutronix.de>
Hi
On 26/08/2019 23:26, Thomas Gleixner wrote:
> On Mon, 26 Aug 2019, Cristian Marussi wrote:
>> On 8/26/19 4:32 PM, Christoph Hellwig wrote:
>>>> +config ARCH_USE_COMMON_SMP_STOP
>>>> + def_bool y if SMP
>>>
>>> The option belongs into common code and the arch code shoud only
>>> select it.
>>>
>>
>> In fact that was my first approach, but then I noticed that in kernel/ topdir
>> there was no generic Kconfig but only subsystem specific ones:
>>
>> Kconfig.freezer Kconfig.hz Kconfig.locks Kconfig.preempt
>
> arch/Kconfig
>
Ok I'll move it there in v2.
Thanks for the review.
Cristian
> Thanks,
>
> tglx
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: sound: Convert Allwinner A33 codec to a schema
From: Chen-Yu Tsai @ 2019-08-27 14:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Linux-ALSA, Liam Girdwood, Rob Herring,
Mark Brown, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190827142547.14577-3-mripard@kernel.org>
On Tue, Aug 27, 2019 at 10:25 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The Allwinner A33 SoC have an embedded audio codec that is supported in Linux,
> with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../sound/allwinner,sun8i-a33-codec.yaml | 57 +++++++++++++++++
> .../bindings/sound/sun8i-a33-codec.txt | 63 -------------------
> 2 files changed, 57 insertions(+), 63 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
> delete mode 100644 Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
> new file mode 100644
> index 000000000000..5e7cc05bbff1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/allwinner,sun8i-a33-codec.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner A33 Codec Device Tree Bindings
> +
> +maintainers:
> + - Chen-Yu Tsai <wens@csie.org>
> + - Maxime Ripard <maxime.ripard@bootlin.com>
> +
> +properties:
> + "#sound-dai-cells":
> + const: 0
> +
> + compatible:
> + const: allwinner,sun8i-a33-codec
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: Bus Clock
> + - description: Module Clock
> +
> + clock-names:
> + items:
> + - const: bus
> + - const: mod
> +
> +required:
> + - "#sound-dai-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + audio-codec@1c22e00 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun8i-a33-codec";
> + reg = <0x01c22e00 0x400>;
> + interrupts = <0 29 4>;
> + clocks = <&ccu 47>, <&ccu 92>;
> + clock-names = "bus", "mod";
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
> deleted file mode 100644
> index 7ecf6bd60d27..000000000000
> --- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
> +++ /dev/null
> @@ -1,63 +0,0 @@
> -Allwinner SUN8I audio codec
> -------------------------------------
> -
> -On Sun8i-A33 SoCs, the audio is separated in different parts:
> - - A DAI driver. It uses the "sun4i-i2s" driver which is
> - documented here:
> - Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
> - - An analog part of the codec which is handled as PRCM registers.
> - See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
> - - An digital part of the codec which is documented in this current
> - binding documentation.
> - - And finally, an audio card which links all the above components.
> - The simple-audio card will be used.
> - See Documentation/devicetree/bindings/sound/simple-card.txt
> -
> -This bindings documentation exposes Sun8i codec (digital part).
> -
> -Required properties:
> -- compatible: must be "allwinner,sun8i-a33-codec"
> -- reg: must contain the registers location and length
> -- interrupts: must contain the codec interrupt
> -- clocks: a list of phandle + clock-specifer pairs, one for each entry
> - in clock-names.
> -- clock-names: should contain followings:
> - - "bus": the parent APB clock for this controller
> - - "mod": the parent module clock
> -
> -Here is an example to add a sound card and the codec binding on sun8i SoCs that
> -are similar to A33 using simple-card:
> -
> - sound {
> - compatible = "simple-audio-card";
> - simple-audio-card,name = "sun8i-a33-audio";
> - simple-audio-card,format = "i2s";
> - simple-audio-card,frame-master = <&link_codec>;
> - simple-audio-card,bitclock-master = <&link_codec>;
> - simple-audio-card,mclk-fs = <512>;
> - simple-audio-card,aux-devs = <&codec_analog>;
> - simple-audio-card,routing =
> - "Left DAC", "Digital Left DAC",
> - "Right DAC", "Digital Right DAC";
At some point we should start listing the endpoints available for routing?
ChenYu
> -
> - simple-audio-card,cpu {
> - sound-dai = <&dai>;
> - };
> -
> - link_codec: simple-audio-card,codec {
> - sound-dai = <&codec>;
> - };
> -
> - soc@1c00000 {
> - [...]
> -
> - audio-codec@1c22e00 {
> - #sound-dai-cells = <0>;
> - compatible = "allwinner,sun8i-a33-codec";
> - reg = <0x01c22e00 0x400>;
> - interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> - clock-names = "bus", "mod";
> - };
> - };
> -
> --
> 2.21.0
>
_______________________________________________
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