* [PATCH 3/6] soc: renesas: rcar-sysc: Provide helpers to power up/down CPUs
From: Geert Uytterhoeven @ 2018-05-30 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693916-11215-1-git-send-email-geert+renesas@glider.be>
Provide helpers to control CPU power areas from platform code, taking
just a CPU index. This will avoid having to pass full CPU power area
parameter blocks, and thus duplicating information already provided by
SoC-specific SYSC drivers.
This will be used on R-Car H1 only.
Later R-Car generations rely on APMU/RST for CPU power area control.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/soc/renesas/rcar-sysc.c | 40 +++++++++++++++++++++++++++++++++++
include/linux/soc/renesas/rcar-sysc.h | 2 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 95120acc4d806da6..4ad6dcd19420a045 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -310,6 +310,8 @@ struct rcar_pm_domains {
struct generic_pm_domain *domains[RCAR_PD_ALWAYS_ON + 1];
};
+static struct genpd_onecell_data *rcar_sysc_onecell_data;
+
static int __init rcar_sysc_pd_init(void)
{
const struct rcar_sysc_info *info;
@@ -356,6 +358,7 @@ static int __init rcar_sysc_pd_init(void)
domains->onecell_data.domains = domains->domains;
domains->onecell_data.num_domains = ARRAY_SIZE(domains->domains);
+ rcar_sysc_onecell_data = &domains->onecell_data;
for (i = 0, syscier = 0; i < info->num_areas; i++)
syscier |= BIT(info->areas[i].isr_bit);
@@ -449,3 +452,40 @@ void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
pr_debug("%s: syscier = 0x%08x\n", __func__, syscier);
iowrite32(syscier, rcar_sysc_base + SYSCIER);
}
+
+#ifdef CONFIG_ARCH_R8A7779
+static int rcar_sysc_power_cpu(unsigned int idx, bool on)
+{
+ struct generic_pm_domain *genpd;
+ struct rcar_sysc_pd *pd;
+ unsigned int i;
+
+ if (!rcar_sysc_onecell_data)
+ return -ENODEV;
+
+ for (i = 0; i < rcar_sysc_onecell_data->num_domains; i++) {
+ genpd = rcar_sysc_onecell_data->domains[i];
+ if (!genpd)
+ continue;
+
+ pd = to_rcar_pd(genpd);
+ if (!(pd->flags & PD_CPU) || pd->ch.chan_bit != idx)
+ continue;
+
+ return on ? rcar_sysc_power_up(&pd->ch)
+ : rcar_sysc_power_down(&pd->ch);
+ }
+
+ return -ENOENT;
+}
+
+int rcar_sysc_power_down_cpu(unsigned int cpu)
+{
+ return rcar_sysc_power_cpu(cpu, false);
+}
+
+int rcar_sysc_power_up_cpu(unsigned int cpu)
+{
+ return rcar_sysc_power_cpu(cpu, true);
+}
+#endif /* CONFIG_ARCH_R8A7779 */
diff --git a/include/linux/soc/renesas/rcar-sysc.h b/include/linux/soc/renesas/rcar-sysc.h
index 8a6086d2e9c37585..9020da2111fdeea9 100644
--- a/include/linux/soc/renesas/rcar-sysc.h
+++ b/include/linux/soc/renesas/rcar-sysc.h
@@ -13,5 +13,7 @@ struct rcar_sysc_ch {
int rcar_sysc_power_down(const struct rcar_sysc_ch *sysc_ch);
int rcar_sysc_power_up(const struct rcar_sysc_ch *sysc_ch);
void rcar_sysc_init(phys_addr_t base, u32 syscier);
+int rcar_sysc_power_down_cpu(unsigned int cpu);
+int rcar_sysc_power_up_cpu(unsigned int cpu);
#endif /* __LINUX_SOC_RENESAS_RCAR_SYSC_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/6] ARM: shmobile: r8a7779: Stop powering down secondary CPUs during early boot
From: Geert Uytterhoeven @ 2018-05-30 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693916-11215-1-git-send-email-geert+renesas@glider.be>
At .smp_prepare_cpus() time, CPUs 1-3 are still powered down:
- The bootloader doesn't enable CPUs 1-3,
- Non-boot CPUs are disabled by kexec before starting the new kernel.
Hence there is no need to try to power them down again, as it will fail
silently with -EIO anyway.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index c6951ee245889b8f..ff1e6fc0b861c4fc 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -97,11 +97,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
shmobile_smp_scu_prepare_cpus(R8A7779_SCU_BASE, max_cpus);
r8a7779_pm_init();
-
- /* power off secondary CPUs */
- r8a7779_platform_cpu_kill(1);
- r8a7779_platform_cpu_kill(2);
- r8a7779_platform_cpu_kill(3);
}
#ifdef CONFIG_HOTPLUG_CPU
--
2.7.4
^ permalink raw reply related
* [PATCH 1/6] ARM: shmobile: rcar-gen2: Remove explicit SYSC config and init
From: Geert Uytterhoeven @ 2018-05-30 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693916-11215-1-git-send-email-geert+renesas@glider.be>
If the R-Car system controller is described in DT, the rcar-sysc driver
configures SYSCIER and SYSCIMR based on the SoC-specific power area
definitions in r8a779*-sysc. The platform code still passed this
information to the rcar-sysc driver, for compatibility with old R-Car H2
and M2-W DTBs predating commit 8574de861978d518 ("ARM: dts: r8a7791: Add
SYSC PM Domains") in v4.7. The time has come to drop backwards
compatibility, and delegate everything to the DT enabled rcar-sysc
driver.
After the removal of the legacy SMP fallbacks, which powered up the SCUs
explicitly, there is no longer a need to force an early initialization
of the rcar-sysc driver. It will be initialized in time for secondary
CPU bringup by its early_initcall().
Hence all explicit SYSC configuration and initialization can be removed
from the R-Car Gen2 platform code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/pm-rcar-gen2.c | 25 -------------------------
1 file changed, 25 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index 5a798b406af05be0..345af3ebcc3aeeb6 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -15,7 +15,6 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/smp.h>
-#include <linux/soc/renesas/rcar-sysc.h>
#include <asm/io.h>
#include <asm/cputype.h>
#include "common.h"
@@ -46,23 +45,6 @@ static inline u32 phys_to_sbar(phys_addr_t addr)
return (addr >> 8) & 0xfffffc00;
}
-/* SYSC */
-#define SYSCIER 0x0c
-#define SYSCIMR 0x10
-
-#if defined(CONFIG_SMP)
-
-static void __init rcar_gen2_sysc_init(u32 syscier)
-{
- rcar_sysc_init(0xe6180000, syscier);
-}
-
-#else /* CONFIG_SMP */
-
-static inline void rcar_gen2_sysc_init(u32 syscier) {}
-
-#endif /* CONFIG_SMP */
-
void __init rcar_gen2_pm_init(void)
{
void __iomem *p;
@@ -72,7 +54,6 @@ void __init rcar_gen2_pm_init(void)
bool has_a7 = false;
bool has_a15 = false;
struct resource res;
- u32 syscier = 0;
int error;
if (once++)
@@ -89,11 +70,6 @@ void __init rcar_gen2_pm_init(void)
has_a7 = true;
}
- if (of_machine_is_compatible("renesas,r8a7790"))
- syscier = 0x013111ef;
- else if (of_machine_is_compatible("renesas,r8a7791"))
- syscier = 0x00111003;
-
np = of_find_compatible_node(NULL, NULL, "renesas,smp-sram");
if (!np) {
/* No smp-sram in DT, fall back to hardcoded address */
@@ -155,6 +131,5 @@ void __init rcar_gen2_pm_init(void)
}
iounmap(p);
- rcar_gen2_sysc_init(syscier);
shmobile_smp_apmu_suspend_init();
}
--
2.7.4
^ permalink raw reply related
* [PATCH 0/6] ARM: shmobile: rcar: Drop lehacy SYSC fallbacks
From: Geert Uytterhoeven @ 2018-05-30 15:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
When DT SYSC support was introduced in v4.7, legacy fallbacks were kept
to keep secondary CPUs working on R-Car H1, H2, and M2-W using old DTBs.
However, the time has come to drop these fallbacks, and clean up the
resulting code.
Most of this was written when I worked on DT SYSC support, but postponed
until the time was ripe. So basically I've been running this during the
last +2 years.
I avoided touching drivers/soc/renesas and arch/arm/mach-shmobile code
in the same patch. If you prefer some patches to be squashed, please
let me know.
Tested on Marzen (R-Car H1), Lager (R-Car H2), and Koelsch (R-Car M2-W).
Thanks!
Geert Uytterhoeven (6):
ARM: shmobile: rcar-gen2: Remove explicit SYSC config and init
ARM: shmobile: r8a7779: Stop powering down secondary CPUs during early
boot
soc: renesas: rcar-sysc: Provide helpers to power up/down CPUs
ARM: shmobile: r8a7779: Use rcar_sysc_power_{down,up}_cpu()
ARM: shmobile: r8a7779: Remove explicit SYSC config and init
soc: renesas: rcar-sysc: Drop legacy handling
arch/arm/mach-shmobile/Makefile | 2 +-
arch/arm/mach-shmobile/pm-r8a7779.c | 41 ----------------------
arch/arm/mach-shmobile/pm-rcar-gen2.c | 25 --------------
arch/arm/mach-shmobile/r8a7779.h | 2 --
arch/arm/mach-shmobile/smp-r8a7779.c | 54 ++++-------------------------
drivers/soc/renesas/rcar-sysc.c | 64 ++++++++++++++++++++++-------------
include/linux/soc/renesas/rcar-sysc.h | 13 ++-----
7 files changed, 50 insertions(+), 151 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/pm-r8a7779.c
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] PCI: versatile: include pci.h
From: Bjorn Helgaas @ 2018-05-30 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528154850.2647019-1-arnd@arndb.de>
On Mon, May 28, 2018 at 05:48:39PM +0200, Arnd Bergmann wrote:
> Two patches for PCI host drivers clashed recently, leading to a broken
> build for versatile-pci:
>
> drivers/pci/host/pci-versatile.c: In function 'versatile_pci_parse_request_of_pci_ranges':
> drivers/pci/host/pci-versatile.c:70:8: error: implicit declaration of function 'devm_of_pci_get_host_bridge_resources'; did you mean 'pci_get_host_bridge_device'? [-Werror=implicit-function-declaration]
>
> This adds the missing header inclusion that became necessary now.
>
> Fixes: 9e2aee80c78d ("PCI: Move private DT related functions into private header")
> Fixes: 64720fd1f630 ("PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, I added this in the merge where these two commits came together,
so hopefully there should be no bisection hole.
> ---
> drivers/pci/host/pci-versatile.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
> index ff2cd12b3978..994f32061b32 100644
> --- a/drivers/pci/host/pci-versatile.c
> +++ b/drivers/pci/host/pci-versatile.c
> @@ -15,6 +15,8 @@
> #include <linux/pci.h>
> #include <linux/platform_device.h>
>
> +#include "../pci.h"
> +
> static void __iomem *versatile_pci_base;
> static void __iomem *versatile_cfg_base[2];
>
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tero Kristo @ 2018-05-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530145047.GC5705@atomide.com>
On 30/05/18 17:50, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>
>> Add MCAN hwmod data and register it for dra762 silicons.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++++++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 62352d1e6361..a2cd7f865a60 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1355,6 +1355,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
>> },
>> };
>>
>> +/*
>> + * 'mcan' class
>> + *
>> + */
>> +static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
>> + .name = "mcan",
>> +};
>> +
>> +/* mcan */
>> +static struct omap_hwmod dra76x_mcan_hwmod = {
>> + .name = "mcan",
>> + .class = &dra76x_mcan_hwmod_class,
>> + .clkdm_name = "wkupaon_clkdm",
>> + .main_clk = "mcan_clk",
>> + .prcm = {
>> + .omap4 = {
>> + .clkctrl_offs = DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET,
>> + .context_offs = DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET,
>> + .modulemode = MODULEMODE_SWCTRL,
>> + },
>> + },
>> +};
>
> You should be now able to leave out at least the clkctrl_offs and modulemode
> here. Please also check if leaving out clkdm_name and main_clk now works :)
>
>> @@ -3818,6 +3841,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2 = {
>> .user = OCP_USER_MPU,
>> };
>>
>> +/* l3_main_1 -> mcan */
>> +static struct omap_hwmod_ocp_if dra76x_l3_main_1__mcan = {
>> + .master = &dra7xx_l3_main_1_hwmod,
>> + .slave = &dra76x_mcan_hwmod,
>> + .clk = "l3_iclk_div",
>> + .user = OCP_USER_MPU | OCP_USER_SDMA,
>> +};
>
> I think this we still need though for the clk. Tero, do you have any comments
> on what all clocks can now be left out?
For the OCP if part, I think that is still needed until we switch over
to full sysc driver. clkctrl_offs you probably also need because that is
used for mapping the omap_hwmod against a specific clkctrl clock. Those
can be only removed once we are done with hwmod (or figure out some
other way to assign the clkctrl clock to a hwmod.)
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 3/3] ARM: shmobile: apmu: Remove platsmp-apmu.h
From: Geert Uytterhoeven @ 2018-05-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693328-10559-1-git-send-email-geert+renesas@glider.be>
After the removal of the legacy SMP fallbacks, platsmp-apmu.h is no
longer needed outside platsmp-apmu.c.
Hence remove platsmp-apmu.h, and make the functions exported previously
static. As the header file also provided forward declarations, the code
in platsmp-apmu.c must be reshuffled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/platsmp-apmu.c | 200 +++++++++++++++++-----------------
arch/arm/mach-shmobile/platsmp-apmu.h | 24 ----
2 files changed, 100 insertions(+), 124 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/platsmp-apmu.h
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index 42c9405e556b14aa..9e1e85cf1899171d 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -23,7 +23,6 @@
#include <asm/smp_plat.h>
#include <asm/suspend.h>
#include "common.h"
-#include "platsmp-apmu.h"
#include "rcar-gen2.h"
static struct {
@@ -87,6 +86,104 @@ static int __maybe_unused apmu_wrap(int cpu, int (*fn)(void __iomem *p, int cpu)
return p ? fn(p, apmu_cpus[cpu].bit) : -EINVAL;
}
+#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_SUSPEND)
+/* nicked from arch/arm/mach-exynos/hotplug.c */
+static inline void cpu_enter_lowpower_a15(void)
+{
+ unsigned int v;
+
+ asm volatile(
+ " mrc p15, 0, %0, c1, c0, 0\n"
+ " bic %0, %0, %1\n"
+ " mcr p15, 0, %0, c1, c0, 0\n"
+ : "=&r" (v)
+ : "Ir" (CR_C)
+ : "cc");
+
+ flush_cache_louis();
+
+ asm volatile(
+ /*
+ * Turn off coherency
+ */
+ " mrc p15, 0, %0, c1, c0, 1\n"
+ " bic %0, %0, %1\n"
+ " mcr p15, 0, %0, c1, c0, 1\n"
+ : "=&r" (v)
+ : "Ir" (0x40)
+ : "cc");
+
+ isb();
+ dsb();
+}
+
+static void shmobile_smp_apmu_cpu_shutdown(unsigned int cpu)
+{
+
+ /* Select next sleep mode using the APMU */
+ apmu_wrap(cpu, apmu_power_off);
+
+ /* Do ARM specific CPU shutdown */
+ cpu_enter_lowpower_a15();
+}
+#endif
+
+#if defined(CONFIG_HOTPLUG_CPU)
+static void shmobile_smp_apmu_cpu_die(unsigned int cpu)
+{
+ /* For this particular CPU deregister boot vector */
+ shmobile_smp_hook(cpu, 0, 0);
+
+ /* Shutdown CPU core */
+ shmobile_smp_apmu_cpu_shutdown(cpu);
+
+ /* jump to shared mach-shmobile sleep / reset code */
+ shmobile_smp_sleep();
+}
+
+static int shmobile_smp_apmu_cpu_kill(unsigned int cpu)
+{
+ return apmu_wrap(cpu, apmu_power_off_poll);
+}
+#endif
+
+#if defined(CONFIG_SUSPEND)
+static int shmobile_smp_apmu_do_suspend(unsigned long cpu)
+{
+ shmobile_smp_hook(cpu, __pa_symbol(cpu_resume), 0);
+ shmobile_smp_apmu_cpu_shutdown(cpu);
+ cpu_do_idle(); /* WFI selects Core Standby */
+ return 1;
+}
+
+static inline void cpu_leave_lowpower(void)
+{
+ unsigned int v;
+
+ asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
+ " orr %0, %0, %1\n"
+ " mcr p15, 0, %0, c1, c0, 0\n"
+ " mrc p15, 0, %0, c1, c0, 1\n"
+ " orr %0, %0, %2\n"
+ " mcr p15, 0, %0, c1, c0, 1\n"
+ : "=&r" (v)
+ : "Ir" (CR_C), "Ir" (0x40)
+ : "cc");
+}
+
+static int shmobile_smp_apmu_enter_suspend(suspend_state_t state)
+{
+ cpu_suspend(smp_processor_id(), shmobile_smp_apmu_do_suspend);
+ cpu_leave_lowpower();
+ return 0;
+}
+
+void __init shmobile_smp_apmu_suspend_init(void)
+{
+ shmobile_suspend_ops.enter = shmobile_smp_apmu_enter_suspend;
+}
+#endif
+
#ifdef CONFIG_SMP
static void apmu_init_cpu(struct resource *res, int cpu, int bit)
{
@@ -162,7 +259,8 @@ static void __init shmobile_smp_apmu_setup_boot(void)
shmobile_boot_fn_gen2 = shmobile_boot_fn;
}
-int shmobile_smp_apmu_boot_secondary(unsigned int cpu, struct task_struct *idle)
+static int shmobile_smp_apmu_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
{
/* For this particular CPU register boot vector */
shmobile_smp_hook(cpu, __pa_symbol(shmobile_boot_apmu), 0);
@@ -189,101 +287,3 @@ static struct smp_operations apmu_smp_ops __initdata = {
CPU_METHOD_OF_DECLARE(shmobile_smp_apmu, "renesas,apmu", &apmu_smp_ops);
#endif /* CONFIG_SMP */
-
-#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_SUSPEND)
-/* nicked from arch/arm/mach-exynos/hotplug.c */
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "Ir" (CR_C)
- : "cc");
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (0x40)
- : "cc");
-
- isb();
- dsb();
-}
-
-static void shmobile_smp_apmu_cpu_shutdown(unsigned int cpu)
-{
-
- /* Select next sleep mode using the APMU */
- apmu_wrap(cpu, apmu_power_off);
-
- /* Do ARM specific CPU shutdown */
- cpu_enter_lowpower_a15();
-}
-#endif
-
-#if defined(CONFIG_HOTPLUG_CPU)
-void shmobile_smp_apmu_cpu_die(unsigned int cpu)
-{
- /* For this particular CPU deregister boot vector */
- shmobile_smp_hook(cpu, 0, 0);
-
- /* Shutdown CPU core */
- shmobile_smp_apmu_cpu_shutdown(cpu);
-
- /* jump to shared mach-shmobile sleep / reset code */
- shmobile_smp_sleep();
-}
-
-int shmobile_smp_apmu_cpu_kill(unsigned int cpu)
-{
- return apmu_wrap(cpu, apmu_power_off_poll);
-}
-#endif
-
-#if defined(CONFIG_SUSPEND)
-static int shmobile_smp_apmu_do_suspend(unsigned long cpu)
-{
- shmobile_smp_hook(cpu, __pa_symbol(cpu_resume), 0);
- shmobile_smp_apmu_cpu_shutdown(cpu);
- cpu_do_idle(); /* WFI selects Core Standby */
- return 1;
-}
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
-static int shmobile_smp_apmu_enter_suspend(suspend_state_t state)
-{
- cpu_suspend(smp_processor_id(), shmobile_smp_apmu_do_suspend);
- cpu_leave_lowpower();
- return 0;
-}
-
-void __init shmobile_smp_apmu_suspend_init(void)
-{
- shmobile_suspend_ops.enter = shmobile_smp_apmu_enter_suspend;
-}
-#endif
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.h b/arch/arm/mach-shmobile/platsmp-apmu.h
deleted file mode 100644
index 70424572b9da2e70..0000000000000000
--- a/arch/arm/mach-shmobile/platsmp-apmu.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * rmobile apmu definition
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef PLATSMP_APMU_H
-#define PLATSMP_APMU_H
-
-extern int shmobile_smp_apmu_boot_secondary(unsigned int cpu,
- struct task_struct *idle);
-extern void shmobile_smp_apmu_cpu_die(unsigned int cpu);
-extern int shmobile_smp_apmu_cpu_kill(unsigned int cpu);
-
-#endif /* PLATSMP_APMU_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: shmobile: apmu: Remove obsolete shmobile_smp_apmu_prepare_cpus()
From: Geert Uytterhoeven @ 2018-05-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693328-10559-1-git-send-email-geert+renesas@glider.be>
After the removal of the legacy SMP fallbacks, there are no more users
left of shmobile_smp_apmu_prepare_cpus().
Remove it, together with the legacy SMP config parser.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/platsmp-apmu.c | 40 -----------------------------------
arch/arm/mach-shmobile/platsmp-apmu.h | 8 -------
2 files changed, 48 deletions(-)
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index 778b6b618ce7c088..42c9405e556b14aa 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -106,38 +106,6 @@ static void apmu_init_cpu(struct resource *res, int cpu, int bit)
writel(x, apmu_cpus[cpu].iomem + DBGRCR_OFFS);
}
-static void apmu_parse_cfg(void (*fn)(struct resource *res, int cpu, int bit),
- struct rcar_apmu_config *apmu_config, int num)
-{
- int id;
- int k;
- int bit, index;
- bool is_allowed;
-
- for (k = 0; k < num; k++) {
- /* only enable the cluster that includes the boot CPU */
- is_allowed = false;
- for (bit = 0; bit < ARRAY_SIZE(apmu_config[k].cpus); bit++) {
- id = apmu_config[k].cpus[bit];
- if (id >= 0) {
- if (id == cpu_logical_map(0))
- is_allowed = true;
- }
- }
- if (!is_allowed)
- continue;
-
- for (bit = 0; bit < ARRAY_SIZE(apmu_config[k].cpus); bit++) {
- id = apmu_config[k].cpus[bit];
- if (id >= 0) {
- index = get_logical_index(id);
- if (index >= 0)
- fn(&apmu_config[k].iomem, index, bit);
- }
- }
- }
-}
-
static const struct of_device_id apmu_ids[] = {
{ .compatible = "renesas,apmu" },
{ /*sentinel*/ }
@@ -194,14 +162,6 @@ static void __init shmobile_smp_apmu_setup_boot(void)
shmobile_boot_fn_gen2 = shmobile_boot_fn;
}
-void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
- struct rcar_apmu_config *apmu_config,
- int num)
-{
- shmobile_smp_apmu_setup_boot();
- apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
-}
-
int shmobile_smp_apmu_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
/* For this particular CPU register boot vector */
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.h b/arch/arm/mach-shmobile/platsmp-apmu.h
index 76512c9a2545da75..70424572b9da2e70 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.h
+++ b/arch/arm/mach-shmobile/platsmp-apmu.h
@@ -16,14 +16,6 @@
#ifndef PLATSMP_APMU_H
#define PLATSMP_APMU_H
-struct rcar_apmu_config {
- struct resource iomem;
- int cpus[4];
-};
-
-extern void shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
- struct rcar_apmu_config *apmu_config,
- int num);
extern int shmobile_smp_apmu_boot_secondary(unsigned int cpu,
struct task_struct *idle);
extern void shmobile_smp_apmu_cpu_die(unsigned int cpu);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: shmobile: apmu: Move cpu_leave_lowpower() to SUSPEND section
From: Geert Uytterhoeven @ 2018-05-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693328-10559-1-git-send-email-geert+renesas@glider.be>
cpu_leave_lowpower() is used for suspend only, not for CPU hotplug.
Hence move it from the HOTPLUG_CPU || SUSPEND section to the SUSPEND
section.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/platsmp-apmu.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index ba732effc90b019f..778b6b618ce7c088 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -270,21 +270,6 @@ static void shmobile_smp_apmu_cpu_shutdown(unsigned int cpu)
/* Do ARM specific CPU shutdown */
cpu_enter_lowpower_a15();
}
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
#endif
#if defined(CONFIG_HOTPLUG_CPU)
@@ -315,6 +300,21 @@ static int shmobile_smp_apmu_do_suspend(unsigned long cpu)
return 1;
}
+static inline void cpu_leave_lowpower(void)
+{
+ unsigned int v;
+
+ asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
+ " orr %0, %0, %1\n"
+ " mcr p15, 0, %0, c1, c0, 0\n"
+ " mrc p15, 0, %0, c1, c0, 1\n"
+ " orr %0, %0, %2\n"
+ " mcr p15, 0, %0, c1, c0, 1\n"
+ : "=&r" (v)
+ : "Ir" (CR_C), "Ir" (0x40)
+ : "cc");
+}
+
static int shmobile_smp_apmu_enter_suspend(suspend_state_t state)
{
cpu_suspend(smp_processor_id(), shmobile_smp_apmu_do_suspend);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] ARM: shmobile: apmu: Cleanups after legacy SMP fallback removal
From: Geert Uytterhoeven @ 2018-05-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
Now the legacy SMP fallbacks for R-Car H2 and M2-W have been removed, a
few more code cleanups can be applied.
The third patch is a bit larger than I had hoped, due to the need to
reshuffle a few functions in the absence of forward declarations.
Tested on Lager (R-Car H2) and Koelsch (R-Car M2-W).
Thanks!
Geert Uytterhoeven (3):
ARM: shmobile: apmu: Move cpu_leave_lowpower() to SUSPEND section
ARM: shmobile: apmu: Remove obsolete shmobile_smp_apmu_prepare_cpus()
ARM: shmobile: apmu: Remove platsmp-apmu.h
arch/arm/mach-shmobile/platsmp-apmu.c | 240 ++++++++++++++--------------------
arch/arm/mach-shmobile/platsmp-apmu.h | 32 -----
2 files changed, 100 insertions(+), 172 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/platsmp-apmu.h
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 05/11] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties
From: Boris Brezillon @ 2018-05-30 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527686082-15142-6-git-send-email-frieder.schrempf@exceet.de>
On Wed, 30 May 2018 15:14:34 +0200
Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> The FSL QSPI driver was moved to the SPI framework and it now
> acts as a SPI controller. Therefore the subnodes need to set
> spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.
We should try to keep the current behavior even when
spi-[rx/tx]-bus-width are not defined. How about considering
spi-[rx/tx]-bus-width as board constraints and then let the core pick
the best mode based on these constraints plus the SPI NOR chip
limitations.
>
> Also the properties 'bus-num', 'fsl,spi-num-chipselects' and
> 'fsl,spi-flash-chipselects' were never read by the driver and
> can be removed.
>
> The 'reg' properties are adjusted to reflect the what bus and
> chipselect the flash is connected to, as the new driver needs
> this information.
>
> The property 'fsl,qspi-has-second-chip' is not needed anymore
> and will be removed after the old driver was disabled to avoid
> breaking ls1021a-moxa-uc-8410a.dts.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
> arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 ++++++--
> arch/arm/boot/dts/imx6sx-sdb.dts | 8 ++++++--
> arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
> arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
> 4 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
> index e3533e7..1a6f680 100644
> --- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
> +++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
> @@ -131,13 +131,17 @@
> #size-cells = <1>;
> compatible = "spansion,s25fl128s", "jedec,spi-nor";
> spi-max-frequency = <66000000>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <4>;
> };
>
> - flash1: s25fl128s at 1 {
> - reg = <1>;
> + flash1: s25fl128s at 2 {
> + reg = <2>;
Hm, you're breaking backward compat here. Can we try to re-use the
old numbering scheme instead of patching all DTs?
^ permalink raw reply
* [PATCH v2 6/6] ARM: dts: dra76x: Add MCAN node
From: Tony Lindgren @ 2018-05-30 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-7-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> From: Franklin S Cooper Jr <fcooper@ti.com>
>
> Add support for the MCAN peripheral which supports both classic
> CAN messages along with the new CAN-FD message.
...
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -27,6 +27,21 @@
> ti,syss-mask = <1>;
> clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
> clock-names = "fck";
> +
> + m_can0: mcan at 42c01a00 {
> + compatible = "bosch,m_can";
> + reg = <0x1a00 0x4000>, <0x0 0x18FC>;
> + reg-names = "m_can", "message_ram";
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "int0", "int1";
> + ti,hwmods = "mcan";
The "ti,hwmods" should be in the parent node now. But you may not even need
it, see the reset comment I made for the parent node patch.
> + clocks = <&mcan_clk>, <&l3_iclk_div>;
> + clock-names = "cclk", "hclk";
> + bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
> + status = "disabled";
And then you should be able to also leave out status = "disabled" as the
hardware is there for sure and we can idle it. Then a board specific
dts file can set it to "disabled" if reallly needed. Setting everything
manually to "disabled" and then again to "enabled" is the wrong way
around, the default is "enabled".
Regards,
Tony
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Mike Leach @ 2018-05-30 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5efe804f-364b-6ae1-3fca-ec7f6d8a383d@arm.com>
Hi Leo,
On 30 May 2018 at 10:45, Robert Walker <robert.walker@arm.com> wrote:
>
>
> On 28/05/18 23:13, Mathieu Poirier wrote:
>>
>> Leo and/or Robert,
>>
>> On Mon, May 28, 2018 at 04:45:00PM +0800, Leo Yan wrote:
>>>
>>> Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
>>> traces") reworks the samples generation flow from CoreSight trace to
>>> match the correct format so Perf report tool can display the samples
>>> properly.
>>>
>>> But the change has side effect for branch packet handling, it only
>>> generate branch samples by checking previous packet flag
>>> 'last_instr_taken_branch' is true, this results in below three kinds
>>> packets are missed to generate branch samples:
>>>
>>> - The start tracing packet at the beginning of tracing data;
>>> - The exception handling packet;
>>> - If one CS_ETM_TRACE_ON packet is inserted, we also miss to handle it
>>> for branch samples. CS_ETM_TRACE_ON packet itself can give the info
>>> that there have a discontinuity in the trace, on the other hand we
>>> also miss to generate proper branch sample for packets before and
>>> after CS_ETM_TRACE_ON packet.
>>>
>>> This patch is to add branch sample handling for up three kinds packets:
>>>
>>> - In function cs_etm__sample(), check if 'prev_packet->sample_type' is
>>> zero and in this case it generates branch sample for the start tracing
>>> packet; furthermore, we also need to handle the condition for
>>> prev_packet::end_addr is zero in the cs_etm__last_executed_instr();
>>>
>>> - In function cs_etm__sample(), check if 'prev_packet->exc' is true and
>>> generate branch sample for exception handling packet;
>>>
>>> - If there has one CS_ETM_TRACE_ON packet is coming, we firstly generate
>>> branch sample in the function cs_etm__flush(), this can save complete
>>> info for the previous CS_ETM_RANGE packet just before CS_ETM_TRACE_ON
>>> packet. We also generate branch sample for the new CS_ETM_RANGE
>>> packet after CS_ETM_TRACE_ON packet, this have two purposes, the
>>> first one purpose is to save the info for the new CS_ETM_RANGE packet,
>>> the second purpose is to save CS_ETM_TRACE_ON packet info so we can
>>> have hint for a discontinuity in the trace.
>>>
>>> For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
>>> 'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
>>> the decoder layer as dummy value. This patch is to convert these
>>> values to zeros for more readable; this is accomplished by functions
>>> cs_etm__last_executed_instr() and cs_etm__first_executed_instr(). The
>>> later one is a new function introduced by this patch.
>>>
>>> Reviewed-by: Robert Walker <robert.walker@arm.com>
>>> Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
>>> traces")
>>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>> ---
>>> tools/perf/util/cs-etm.c | 93
>>> +++++++++++++++++++++++++++++++++++++-----------
>>> 1 file changed, 73 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>>> index 822ba91..8418173 100644
>>> --- a/tools/perf/util/cs-etm.c
>>> +++ b/tools/perf/util/cs-etm.c
>>> @@ -495,6 +495,20 @@ static inline void
>>> cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq)
>>> static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet
>>> *packet)
>>> {
>>> /*
>>> + * The packet is the start tracing packet if the end_addr is
>>> zero,
>>> + * returns 0 for this case.
>>> + */
>>> + if (!packet->end_addr)
>>> + return 0;
>>
>>
>> What is considered to be the "start tracing packet"? Right now the only
>> two
>> kind of packets inserted in the decoder packet buffer queue are INST_RANGE
>> and
>> TRACE_ON. How can we hit a condition where packet->end-addr == 0?
>>
>>
>>> +
>>> + /*
>>> + * The packet is the CS_ETM_TRACE_ON packet if the end_addr is
>>> + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>>> + */
>>> + if (packet->end_addr == 0xdeadbeefdeadbeefUL)
>>> + return 0;
>>
>>
>> As it is with the above, I find triggering on addresses to be brittle and
>> hard
>> to maintain on the long run. Packets all have a sample_type field that
>> should
>> be used in cases like this one. That way we know exactly the condition
>> that is
>> targeted.
>>
>> While working on this set, please spin-off another patch that defines
>> CS_ETM_INVAL_ADDR 0xdeadbeefdeadbeefUL and replace all the cases where the
>> numeral is used. That way we stop using the hard coded value.
>>
>>> +
>>> + /*
>>> * The packet records the execution range with an exclusive end
>>> address
>>> *
>>> * A64 instructions are constant size, so the last executed
>>> @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct
>>> cs_etm_packet *packet)
>>> return packet->end_addr - A64_INSTR_SIZE;
>>> }
>>> +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet
>>> *packet)
>>> +{
>>> + /*
>>> + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
>>> + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>>> + */
>>> + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
>>> + return 0;
>>
>>
>> Same comment as above.
>>
>>> +
>>> + return packet->start_addr;
>>> +}
>>> +
>>> static inline u64 cs_etm__instr_count(const struct cs_etm_packet
>>> *packet)
>>> {
>>> /*
>>> @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct
>>> cs_etm_queue *etmq)
>>> be = &bs->entries[etmq->last_branch_pos];
>>> be->from = cs_etm__last_executed_instr(etmq->prev_packet);
>>> - be->to = etmq->packet->start_addr;
>>> + be->to = cs_etm__first_executed_instr(etmq->packet);
>>> /* No support for mispredict */
>>> be->flags.mispred = 0;
>>> be->flags.predicted = 1;
>>> @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct
>>> cs_etm_queue *etmq)
>>> sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
>>> sample.pid = etmq->pid;
>>> sample.tid = etmq->tid;
>>> - sample.addr = etmq->packet->start_addr;
>>> + sample.addr = cs_etm__first_executed_instr(etmq->packet);
>>> sample.id = etmq->etm->branches_id;
>>> sample.stream_id = etmq->etm->branches_id;
>>> sample.period = 1;
>>> @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue
>>> *etmq)
>>> etmq->period_instructions = instrs_over;
>>> }
>>> - if (etm->sample_branches &&
>>> - etmq->prev_packet &&
>>> - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>>> - etmq->prev_packet->last_instr_taken_branch) {
>>> - ret = cs_etm__synth_branch_sample(etmq);
>>> - if (ret)
>>> - return ret;
>>> + if (etm->sample_branches && etmq->prev_packet) {
>>> + bool generate_sample = false;
>>> +
>>> + /* Generate sample for start tracing packet */
>>> + if (etmq->prev_packet->sample_type == 0 ||
>>
>>
>> What kind of packet is sample_type == 0 ?
>>
>>> + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
>>> + generate_sample = true;
>>> +
>>> + /* Generate sample for exception packet */
>>> + if (etmq->prev_packet->exc == true)
>>> + generate_sample = true;
>>
>>
>> Please don't do that. Exception packets have a type of their own and can
>> be
>> added to the decoder packet queue the same way INST_RANGE and TRACE_ON
>> packets
>> are. Moreover exception packet containt an address that, if I'm reading
>> the
>> documenation properly, can be used to keep track of instructions that were
>> executed between the last address of the previous range packet and the
>> address
>> executed just before the exception occurred. Mike and Rob will have to
>> confirm
>> this as the decoder may be doing all that hard work for us.
>>
clarification on the exception packets....
The Opencsd output exception packet gives you the exception number,
and optionally the preferred return address. If this address is
present does depend a lot on the underlying protocol - will normally
be there with ETMv4.
Exceptions are marked differently in the underlying protocol - the
OCSD packets abstract away these differences.
consider the code:
0x1000: <some instructions>
0x1100: BR 0x2000
....
0x2000: <some instructions>
0x2020 BZ r4
Without an exception this would result in the packets
OCSD_RANGE(0x1000,0x1104, Last instr type=Br, taken) // recall that
range packets have start addr inclusive, end addr exclusive.
OCSD_RANGE(0x2000,0x2024, Last instr type=Br, <taken / not taken -
depends on condition>
Now consider an exception occurring before the BR 0x2000
this will result in:-
OCSD_RANGE(0x1000, 0x1100, Last instr type=Other)
OCSD_EXECEPTION(IRQ, ret-addr 0x1100)
OCSD_RANGE(IRQ_START, IRQ_END+4, Last instr type = BR, taken) //
this is more likely to have multiple ranges / branches before any
return, but simplified here.
OCSD_EXCEPTION_RETURN() // present if exception returns are
explicitly marked in underlying trace - may not always be depending on
circumstances.
OCSD_RANGE(0x1100,0x1104, Last=BR, taken) // continue on with short
range - just the branch
OCSD_RANGE(0x2000,0x2024, Last instr type=Br, <taken / not taken -
depends on condition>
Now consider the exception occurring after the BR, but before any
other instructions are executed.
OCSD_RANGE(0x1000,0x1104, Last instr type=Br, taken) // recall that
range packets have start addr inclusive, end addr exclusive.
OCSD_EXECEPTION(IRQ, ret-addr 0x2000) // here the preferred return
address is actually the target of the branch.
OCSD_RANGE(IRQ_START, IRQ_END+4, Last instr type = BR, taken) //
this is more likely to have multiple ranges / branches before any
return, but simplified here.
OCSD_RANGE(0x2000,0x2024, Last instr type=Br, <taken / not taken -
depends on condition>
So in general it is possible to arrive in the IRQ_START range with the
previous packet having been either a taken branch, a not taken branch,
or not a branch.
Care must be taken - whether AutoFDO or normal trace disassembly not
to assume that having the last range packet as a taken branch means
that the next range packet is the target, if there is an intervening
exception packet.
Regards
Mike
>>> +
>>> + /* Generate sample for normal branch packet */
>>> + if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>>> + etmq->prev_packet->last_instr_taken_branch)
>>> + generate_sample = true;
>>> +
>>> + if (generate_sample) {
>>> + ret = cs_etm__synth_branch_sample(etmq);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> }
>>> if (etm->sample_branches || etm->synth_opts.last_branch) {
>>> @@ -922,11 +963,16 @@ static int cs_etm__sample(struct cs_etm_queue
>>> *etmq)
>>> static int cs_etm__flush(struct cs_etm_queue *etmq)
>>> {
>>> int err = 0;
>>> + struct cs_etm_auxtrace *etm = etmq->etm;
>>> struct cs_etm_packet *tmp;
>>> - if (etmq->etm->synth_opts.last_branch &&
>>> - etmq->prev_packet &&
>>> - etmq->prev_packet->sample_type == CS_ETM_RANGE) {
>>> + if (!etmq->prev_packet)
>>> + return 0;
>>> +
>>> + if (etmq->prev_packet->sample_type != CS_ETM_RANGE)
>>> + return 0;
>>> +
>>> + if (etmq->etm->synth_opts.last_branch) {
>>
>>
>> If you add:
>>
>> if (!etmq->etm->synth_opts.last_branch)
>> return 0;
>>
>> You can avoid indenting the whole block.
>>
>>> /*
>>> * Generate a last branch event for the branches left in
>>> the
>>> * circular buffer at the end of the trace.
>>> @@ -939,18 +985,25 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
>>> err = cs_etm__synth_instruction_sample(
>>> etmq, addr,
>>> etmq->period_instructions);
>>> + if (err)
>>> + return err;
>>> etmq->period_instructions = 0;
>>> + }
>>> - /*
>>> - * Swap PACKET with PREV_PACKET: PACKET becomes
>>> PREV_PACKET for
>>> - * the next incoming packet.
>>> - */
>>> - tmp = etmq->packet;
>>> - etmq->packet = etmq->prev_packet;
>>> - etmq->prev_packet = tmp;
>>> + if (etm->sample_branches) {
>>> + err = cs_etm__synth_branch_sample(etmq);
>>> + if (err)
>>> + return err;
>>> }
>>> - return err;
>>> + /*
>>> + * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>>> + * the next incoming packet.
>>> + */
>>> + tmp = etmq->packet;
>>> + etmq->packet = etmq->prev_packet;
>>> + etmq->prev_packet = tmp;
>>
>>
>> Robert, I remember noticing that when you first submitted the code but
>> forgot to
>> go back to it. What is the point of swapping the packets? I understand
>>
>> etmq->prev_packet = etmq->packet;
>>
>> But not
>>
>> etmq->packet = tmp;
>>
>> After all etmq->packet will be clobbered as soon as
>> cs_etm_decoder__get_packet()
>> is called, which is alwasy right after either cs_etm__sample() or
>> cs_etm__flush().
>>
>
> This is code I inherited from the original versions of these patches, but it
> works because:
> - etmq->packet and etmq->prev_packet are pointers to struct cs_etm_packet
> allocated by zalloc() in cs_etm__alloc_queue()
> - cs_etm_decoder__get_packet() takes a pointer to struct cs_etm_packet and
> copies the contents of the first packet from the queue into the passed
> location with:
> *packet = decoder->packet_buffer[decoder->head]
>
> So the swap code is only swapping the pointers over, not the contents of the
> packets.
>
> Regards
>
> Rob
>
>
>
>> Thanks,
>> Mathieu
>>
>>
>>
>>> + return 0;
>>> }
>>> static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
>>> --
>>> 2.7.4
>>>
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-30 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-6-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> The ti-sysc driver provides support for manipulating the idlemodes
> and interconnect level resets.
...
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -11,6 +11,25 @@
> / {
> compatible = "ti,dra762", "ti,dra7";
>
> + ocp {
> +
> + target-module at 0x42c00000 {
> + compatible = "ti,sysc-dra7-mcan";
> + ranges = <0x0 0x42c00000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x42c01900 0x4>,
> + <0x42c01904 0x4>,
> + <0x42c01908 0x4>;
> + reg-names = "rev", "sysc", "syss";
> + ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
> + SYSC_DRA7_MCAN_ENAWAKEUP)>;
> + ti,syss-mask = <1>;
> + clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
> + clock-names = "fck";
> + };
> + };
> +
> };
Looks good to me except I think the reset won't do anything currently
with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
Can you please check? It might be worth adding the reset function to
ti-sysc.c for non "ti,hwmods" case and that just might remove the
need for any hwmod code for this module.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=W-MLU9c-SvfLgKAKGP1eHN5xO-013f2M09XUa+QeHzrA@mail.gmail.com>
On Wed, May 30, 2018 at 07:46:50AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 2:37 AM, Mark Brown <broonie@kernel.org> wrote:
> >> Linux vote for the lowest voltage it's comfortable with. Linux keeps
> >> track of the true voltage that the driver wants and will always change
> >> its vote back to that before enabling. Thus (assuming Linux is OK
> >> with 1.2 V - 1.4 V for a rail):
> > That's pretty much what it should do anyway with normally designed
> > hardware.
> I guess the question is: do we insist that the driver include this
> workaround, or are we OK with letting the hardware behave as the
> hardware does?
What you're describing sounds like what we should be doing normally, if
we're not doing that we should probably be fixing the core.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/a848ca01/attachment.sig>
^ permalink raw reply
* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Tony Lindgren @ 2018-05-30 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-5-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> The dra76x MCAN generic interconnect module has a its own
> format for the bits in the control registers.
...
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -1262,6 +1262,22 @@ static const struct sysc_capabilities sysc_omap4_usb_host_fs = {
> .regbits = &sysc_regbits_omap4_usb_host_fs,
> };
>
> +static const struct sysc_regbits sysc_regbits_dra7_mcan = {
> + .dmadisable_shift = -ENODEV,
> + .midle_shift = -ENODEV,
> + .sidle_shift = -ENODEV,
> + .clkact_shift = -ENODEV,
> + .enwkup_shift = 4,
> + .srst_shift = 0,
> + .emufree_shift = -ENODEV,
> + .autoidle_shift = -ENODEV,
> +};
> +
> +static const struct sysc_capabilities sysc_dra7_mcan = {
> + .type = TI_SYSC_DRA7_MCAN,
> + .regbits = &sysc_regbits_dra7_mcan,
> +};
> +
> static int sysc_init_pdata(struct sysc *ddata)
> {
> struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
> { .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
> { .compatible = "ti,sysc-usb-host-fs",
> .data = &sysc_omap4_usb_host_fs, },
> + { .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
> { },
> };
Looks good to me. And presumably you checked that no other dra7 modules
use sysconfig register bit layout like this?
Regards,
Tony
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Bjorn Helgaas @ 2018-05-30 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dfe2db8f974d94c9867f30ec83d9333@codeaurora.org>
On Wed, May 30, 2018 at 12:44:29AM -0700, okaya at codeaurora.org wrote:
> On 2018-05-30 00:37, Christoph Hellwig wrote:
> > On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> > > Bjorn and I discussed the need for such a "safe" mode feature when you
> > > want to bring up PCI for a platform. You want to turn off everything
> > > as
> > > a starter and just stick to bare minimum.
> >
> > Can we please make it a config option the instead of adding code
> > to every kernel? Also maybe the bringup should be in the name
> > to make this more clear?
>
> One other requirement was to have a runtime option rather than compile time
> option.
>
> When someone reported a problem, we wanted to be able to say "use this
> option and see if system boots" without doing any bisects or recompilation.
>
> This would be the first step in troubleshooting a system to see if
> fundamental features are working.
>
> I don't mind changing the name
> Bjorn mentioned safe option. I made it safemode. I am looking at Bjorn for
> suggestions at this moment.
This *was* my idea, but I'm starting to think it was a bad idea.
I don't want people to use pci= parameters as the normal way to get a
system to boot. That would be a huge support hassle (putting things
in release notes, diagnosing problems when people forget it, etc).
But the parameters *are* useful for debugging. If we had a
"pci=safemode" and it avoided some problem, the next step would be to
narrow it down by using the more specific flags (pci=nomsi, pci=noari,
pci=no_ext_tags, etc). So I think 95% of the value is in the specific
flags, and a "pci=safemode" might add a little bit of value but at the
cost of a small but nagging maintenance concern and code clutter.
Bjorn
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530103720.GH6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, May 29, 2018 at 10:23:20PM -0700, Doug Anderson wrote:
>
>> > + qcom,drms-mode-max-microamps = <10000 1000000>;
>
>> Things look pretty good to me now. I'm still hesitant about the whole
>> need to list the modes twice (once using the unordered
>> "regulator-allowed-modes" and once to match up against the ordered
>> "qcom,drms-mode-max-microamps"). I'm also still of the opinion that
>> the whole "drms-mode-max-microamps" ought to be a standard property
>> (not a qcom specific one) and handled in the regulator core.
>
> I'm confused as to why we are specifying the maximum current the device
> can deliver in a given mode in the DT - surely that's a fixed property
> of the hardware?
Said another way: you're saying that you'd expect the "max-microamps"
table to have one fewer element than the listed modes? So in the
above example you'd have:
drms-modes: LPM, HPM
max-microamps: 10000
...or in a more complicated case, you could have:
drms-modes: RET, LPM, AUTO, HPM
max-microamps: 1, 100, 10000
Did I understand you correctly?
I'm personally OK with that color for the shed. I kinda like the
symmetry of having the same number of elements in both lists (and
being able to print an error message if someone ends up asking for too
much current), but it's not a big deal for me either way.
-Doug
^ permalink raw reply
* Regression in Linux next again
From: Naresh Kamboju @ 2018-05-30 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530143338.GM6920@sirena.org.uk>
On 30 May 2018 at 20:03, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 04:03:15PM +0200, Maciej Purski wrote:
>
>> I'm afraid, I have no idea, how to fix it quickly. You can revert it and
>> in the next version I'll fix the build error and split the last patch even
>> more, so we could perform a more precise bisection. I'd be grateful if you
>> could push it on your test coupled branch and Tony could test it again before
>> merging it with next again.
>
> Yeah, if we could get testing from Tony first that'd be ideal.
Linux next 4.17.0-rc7-next-20180529 boot failed on x15 device.
Manually reproduced boot failed problem on x15 device.
The qemu_arm32 boots successfully.
Ref bug:
LKFT: linux-next: Boot failed on beagle board x15
https://bugs.linaro.org/show_bug.cgi?id=3863
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-30 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-2-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> From: Lokesh Vutla <lokeshvutla@ti.com>
>
> Add MCAN hwmod data and register it for dra762 silicons.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 62352d1e6361..a2cd7f865a60 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1355,6 +1355,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
> },
> };
>
> +/*
> + * 'mcan' class
> + *
> + */
> +static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
> + .name = "mcan",
> +};
> +
> +/* mcan */
> +static struct omap_hwmod dra76x_mcan_hwmod = {
> + .name = "mcan",
> + .class = &dra76x_mcan_hwmod_class,
> + .clkdm_name = "wkupaon_clkdm",
> + .main_clk = "mcan_clk",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET,
> + .context_offs = DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
You should be now able to leave out at least the clkctrl_offs and modulemode
here. Please also check if leaving out clkdm_name and main_clk now works :)
> @@ -3818,6 +3841,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2 = {
> .user = OCP_USER_MPU,
> };
>
> +/* l3_main_1 -> mcan */
> +static struct omap_hwmod_ocp_if dra76x_l3_main_1__mcan = {
> + .master = &dra7xx_l3_main_1_hwmod,
> + .slave = &dra76x_mcan_hwmod,
> + .clk = "l3_iclk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
I think this we still need though for the clk. Tero, do you have any comments
on what all clocks can now be left out?
Regards,
Tony
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Leo Yan @ 2018-05-30 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzPShMj1cbXZPb7Lzio+gKcmvhD2+KTYr7vP9ec1d6bmg@mail.gmail.com>
On Wed, May 30, 2018 at 08:45:46AM -0600, Mathieu Poirier wrote:
> On 29 May 2018 at 18:28, Leo Yan <leo.yan@linaro.org> wrote:
> > Hi Mathieu,
> >
> > On Tue, May 29, 2018 at 10:04:49AM -0600, Mathieu Poirier wrote:
> >
> > [...]
> >
> >> > As now this patch is big with more complex logic, so I consider to
> >> > split it into small patches:
> >> >
> >> > - Define CS_ETM_INVAL_ADDR;
> >> > - Fix for CS_ETM_TRACE_ON packet;
> >> > - Fix for exception packet;
> >> >
> >> > Does this make sense for you? I have concern that this patch is a
> >> > fixing patch, so not sure after spliting patches will introduce
> >> > trouble for applying them for other stable kernels ...
> >>
> >> Reverse the order:
> >>
> >> - Fix for CS_ETM_TRACE_ON packet;
> >> - Fix for exception packet;
> >> - Define CS_ETM_INVAL_ADDR;
> >>
> >> But you may not need to - see next comment.
> >
> > From the discussion context, I think here 'you may not need to' is
> > referring to my concern for applying patches on stable kernel, so I
> > should take this patch series as an enhancement and don't need to
> > consider much for stable kernel.
>
> Yes, that is what I meant.
Thanks for confirmation, will send new patch series according to the
discussion.
[...]
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530093701.GD6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 2:37 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, May 29, 2018 at 10:30:33PM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:56 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Yes, that's definitely not what's expected but it's unfortunately what
>> > the firmware chose to implement so we may well be stuck with it
>> > unfortunately.
>
>> We're not really stuck with it if we do what I was suggesting. I was
>> suggesting that every time we disable the regulator in Linux we have
>> Linux vote for the lowest voltage it's comfortable with. Linux keeps
>> track of the true voltage that the driver wants and will always change
>> its vote back to that before enabling. Thus (assuming Linux is OK
>> with 1.2 V - 1.4 V for a rail):
>
> That's pretty much what it should do anyway with normally designed
> hardware.
I guess the question is: do we insist that the driver include this
workaround, or are we OK with letting the hardware behave as the
hardware does?
-Doug
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Mathieu Poirier @ 2018-05-30 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530002837.GB11923@leoy-ThinkPad-X240s>
On 29 May 2018 at 18:28, Leo Yan <leo.yan@linaro.org> wrote:
> Hi Mathieu,
>
> On Tue, May 29, 2018 at 10:04:49AM -0600, Mathieu Poirier wrote:
>
> [...]
>
>> > As now this patch is big with more complex logic, so I consider to
>> > split it into small patches:
>> >
>> > - Define CS_ETM_INVAL_ADDR;
>> > - Fix for CS_ETM_TRACE_ON packet;
>> > - Fix for exception packet;
>> >
>> > Does this make sense for you? I have concern that this patch is a
>> > fixing patch, so not sure after spliting patches will introduce
>> > trouble for applying them for other stable kernels ...
>>
>> Reverse the order:
>>
>> - Fix for CS_ETM_TRACE_ON packet;
>> - Fix for exception packet;
>> - Define CS_ETM_INVAL_ADDR;
>>
>> But you may not need to - see next comment.
>
> From the discussion context, I think here 'you may not need to' is
> referring to my concern for applying patches on stable kernel, so I
> should take this patch series as an enhancement and don't need to
> consider much for stable kernel.
Yes, that is what I meant.
>
> On the other hand, your suggestion is possible to mean 'not need
> to' split into small patches (though I guess this is misunderstanding
> for your meaning).
>
> Could you clarify which is your meaning?
>
>> >> > +
>> >> > + /*
>> >> > * The packet records the execution range with an exclusive end address
>> >> > *
>> >> > * A64 instructions are constant size, so the last executed
>> >> > @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
>> >> > return packet->end_addr - A64_INSTR_SIZE;
>> >> > }
>> >> >
>> >> > +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
>> >> > +{
>> >> > + /*
>> >> > + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
>> >> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>> >> > + */
>> >> > + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
>> >> > + return 0;
>> >>
>> >> Same comment as above.
>> >
>> > Will do this.
>> >
>> >> > +
>> >> > + return packet->start_addr;
>> >> > +}
>> >> > +
>> >> > static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
>> >> > {
>> >> > /*
>> >> > @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq)
>> >> >
>> >> > be = &bs->entries[etmq->last_branch_pos];
>> >> > be->from = cs_etm__last_executed_instr(etmq->prev_packet);
>> >> > - be->to = etmq->packet->start_addr;
>> >> > + be->to = cs_etm__first_executed_instr(etmq->packet);
>> >> > /* No support for mispredict */
>> >> > be->flags.mispred = 0;
>> >> > be->flags.predicted = 1;
>> >> > @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq)
>> >> > sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
>> >> > sample.pid = etmq->pid;
>> >> > sample.tid = etmq->tid;
>> >> > - sample.addr = etmq->packet->start_addr;
>> >> > + sample.addr = cs_etm__first_executed_instr(etmq->packet);
>> >> > sample.id = etmq->etm->branches_id;
>> >> > sample.stream_id = etmq->etm->branches_id;
>> >> > sample.period = 1;
>> >> > @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>> >> > etmq->period_instructions = instrs_over;
>> >> > }
>> >> >
>> >> > - if (etm->sample_branches &&
>> >> > - etmq->prev_packet &&
>> >> > - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>> >> > - etmq->prev_packet->last_instr_taken_branch) {
>> >> > - ret = cs_etm__synth_branch_sample(etmq);
>> >> > - if (ret)
>> >> > - return ret;
>> >> > + if (etm->sample_branches && etmq->prev_packet) {
>> >> > + bool generate_sample = false;
>> >> > +
>> >> > + /* Generate sample for start tracing packet */
>> >> > + if (etmq->prev_packet->sample_type == 0 ||
>> >>
>> >> What kind of packet is sample_type == 0 ?
>> >
>> > Just as explained above, sample_type == 0 is the packet which
>> > initialized in the function cs_etm__alloc_queue().
>> >
>> >> > + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
>> >> > + generate_sample = true;
>> >> > +
>> >> > + /* Generate sample for exception packet */
>> >> > + if (etmq->prev_packet->exc == true)
>> >> > + generate_sample = true;
>> >>
>> >> Please don't do that. Exception packets have a type of their own and can be
>> >> added to the decoder packet queue the same way INST_RANGE and TRACE_ON packets
>> >> are. Moreover exception packet containt an address that, if I'm reading the
>> >> documenation properly, can be used to keep track of instructions that were
>> >> executed between the last address of the previous range packet and the address
>> >> executed just before the exception occurred. Mike and Rob will have to confirm
>> >> this as the decoder may be doing all that hard work for us.
>> >
>> > Sure, will wait for Rob and Mike to confirm for this.
>> >
>> > At my side, I dump the packet, the exception packet isn't passed to
>> > cs-etm.c layer, the decoder layer only sets the flag
>> > 'packet->exc = true' when exception packet is coming [1].
>>
>> That's because we didn't need the information. Now that we do a
>> function that will insert a packet in the decoder packet queue and
>> deal with the new packet type in the main decoder loop [2]. At that
>> point your work may not be eligible for stable anymore and I think it
>> is fine. Robert's work was an enhancement over mine and yours is an
>> enhancement over his.
>>
>> [2]. https://elixir.bootlin.com/linux/v4.17-rc7/source/tools/perf/util/cs-etm.c#L999
>
> Agree, will look into for exception packet and try to add new packet
> type for this.
>
> [...]
>
> Thanks,
> Leo Yan
^ permalink raw reply
* Regression in Linux next again
From: Tony Lindgren @ 2018-05-30 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530143338.GM6920@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [180530 14:36]:
> On Wed, May 30, 2018 at 04:03:15PM +0200, Maciej Purski wrote:
>
> > I'm afraid, I have no idea, how to fix it quickly. You can revert it and
> > in the next version I'll fix the build error and split the last patch even
> > more, so we could perform a more precise bisection. I'd be grateful if you
> > could push it on your test coupled branch and Tony could test it again before
> > merging it with next again.
>
> Yeah, if we could get testing from Tony first that'd be ideal.
I can boot test the patches easily no problem. Maciej, maybe email
me some debug version and I'll email you back the dmesg output.
Regards,
Tony
^ permalink raw reply
* Regression in Linux next again
From: Mark Brown @ 2018-05-30 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140318eucas1p2af2d01b9678e8914c2b8e099c584ec11~zcQzVKtj30757607576eucas1p2V@eucas1p2.samsung.com>
On Wed, May 30, 2018 at 04:03:15PM +0200, Maciej Purski wrote:
> I'm afraid, I have no idea, how to fix it quickly. You can revert it and
> in the next version I'll fix the build error and split the last patch even
> more, so we could perform a more precise bisection. I'd be grateful if you
> could push it on your test coupled branch and Tony could test it again before
> merging it with next again.
Yeah, if we could get testing from Tony first that'd be ideal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/597b2dc3/attachment.sig>
^ 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