* [PATCH v4 2/2] ARM: dts: TS-7970: add basic device tree
From: Shawn Guo @ 2017-12-21 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207160550.2782-2-sebastien.bourdelin@savoirfairelinux.com>
On Thu, Dec 07, 2017 at 11:05:50AM -0500, Sebastien Bourdelin wrote:
> These device trees add support for TS-7970 by Technologic Systems.
>
> More details here:
> https://wiki.embeddedarm.com/wiki/TS-7970
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Andrew Lunn @ 2017-12-21 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eRnWl-0006VL-TL@rmk-PC.armlinux.org.uk>
On Wed, Dec 20, 2017 at 11:11:55PM +0000, Russell King wrote:
> Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
> first three PHYs are used, the remaining PHY is unused. When we wire
> up the SFF sockets in a later commit, the omission of this causes the
> fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
> the auto-probing of the bus, and discovery of this PHY.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 03/12] mmc: sdhci-omap: Add custom set_uhs_signaling sdhci_host ops
From: Adrian Hunter @ 2017-12-21 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214130941.26666-4-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> UHS-1 DDR50 and MMC DDR52 mode require DDR bit to be
> set in the configuration register (MMCHS_CON). Add
> sdhci-omap specific set_uhs_signaling ops to set
> this bit. Also while setting the UHSMS bit, clock should be
> disabled.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Apart from 1 minor comment below:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index defe4eac020d..8f7239e2edc2 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -31,6 +31,7 @@
> #define SDHCI_OMAP_CON 0x12c
> #define CON_DW8 BIT(5)
> #define CON_DMA_MASTER BIT(20)
> +#define CON_DDR BIT(19)
> #define CON_CLKEXTFREE BIT(16)
> #define CON_PADEN BIT(15)
> #define CON_INIT BIT(1)
> @@ -93,6 +94,9 @@ struct sdhci_omap_host {
> u8 power_mode;
> };
>
> +static void sdhci_omap_start_clock(struct sdhci_omap_host *omap_host);
> +static void sdhci_omap_stop_clock(struct sdhci_omap_host *omap_host);
These forward declarations aren't needed are they.
> +
> static inline u32 sdhci_omap_readl(struct sdhci_omap_host *host,
> unsigned int offset)
> {
> @@ -471,6 +475,26 @@ static void sdhci_omap_init_74_clocks(struct sdhci_host *host, u8 power_mode)
> enable_irq(host->irq);
> }
>
> +static void sdhci_omap_set_uhs_signaling(struct sdhci_host *host,
> + unsigned int timing)
> +{
> + u32 reg;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_omap_stop_clock(omap_host);
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + if (timing == MMC_TIMING_UHS_DDR50 || timing == MMC_TIMING_MMC_DDR52)
> + reg |= CON_DDR;
> + else
> + reg &= ~CON_DDR;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + sdhci_set_uhs_signaling(host, timing);
> + sdhci_omap_start_clock(omap_host);
> +}
> +
> static struct sdhci_ops sdhci_omap_ops = {
> .set_clock = sdhci_omap_set_clock,
> .set_power = sdhci_omap_set_power,
> @@ -480,7 +504,7 @@ static struct sdhci_ops sdhci_omap_ops = {
> .set_bus_width = sdhci_omap_set_bus_width,
> .platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
> .reset = sdhci_reset,
> - .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .set_uhs_signaling = sdhci_omap_set_uhs_signaling,
> };
>
> static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
>
^ permalink raw reply
* [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Andrew Lunn @ 2017-12-21 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eRnWg-0006VE-GI@rmk-PC.armlinux.org.uk>
On Wed, Dec 20, 2017 at 11:11:50PM +0000, Russell King wrote:
> The interrupt specification for the GPIO expander is wrong - the
> expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
> 3, not 2.
Hi Russell
I'd also seen this interrupt storm. The whole interrupt architecture
for this expander does not look so good, so i just assumed it was a
design issue. Instead, it was me who probably made a typ0 :-(
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 02/12] mmc: sdhci-omap: Add card_busy host ops
From: Adrian Hunter @ 2017-12-21 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214130941.26666-3-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> card_busy ops is used by mmc core in
> 1) mmc_set_uhs_voltage to verify voltage switch
> 2) __mmc_start_request/mmc_poll_for_busy to check the card busy status
>
> While only DAT0 can be used to check the card busy status (in '2' above),
> CMD and DAT[0..3] is used to verify voltage switch (in '1' above).
>
> The voltage switching sequence for AM572x platform is mentioned
> in Figure 25-48. eMMC/SD/SDIO Power Switching Procedure of
> AM572x Sitara Processors Silicon Revision 2.0, 1.1 TRM
> (SPRUHZ6I - October 2014?Revised April 2017 [1]).
>
> Add card_busy host ops in sdhci_omap that checks for both CMD and
> DAT[0..3]. card_busy here returns true if one of CMD and DAT[0..3] is
> low though during voltage switch sequence all of CMD and DAT[0..3] has
> to be low (however haven't observed a case where some DAT lines are low
> and some are high).
Isn't it better to check DAT0 only since that is all that is defined for 'busy'.
>
> In the voltage switching sequence, CLKEXTFREE bit in MMCHS_CON
> should also be set after switching to 1.8v which is also taken
> care in the card_busy ops.
>
> [1] -> http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 62 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 96985786cadf..defe4eac020d 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -31,11 +31,20 @@
> #define SDHCI_OMAP_CON 0x12c
> #define CON_DW8 BIT(5)
> #define CON_DMA_MASTER BIT(20)
> +#define CON_CLKEXTFREE BIT(16)
> +#define CON_PADEN BIT(15)
> #define CON_INIT BIT(1)
> #define CON_OD BIT(0)
>
> #define SDHCI_OMAP_CMD 0x20c
>
> +#define SDHCI_OMAP_PSTATE 0x0224
> +#define PSTATE_CLEV BIT(24)
> +#define PSTATE_DLEV_SHIFT 20
> +#define PSTATE_DLEV_DAT(x) (1 << (PSTATE_DLEV_SHIFT + (x)))
> +#define PSTATE_DLEV (PSTATE_DLEV_DAT(0) | PSTATE_DLEV_DAT(1) | \
> + PSTATE_DLEV_DAT(2) | PSTATE_DLEV_DAT(3))
> +
> #define SDHCI_OMAP_HCTL 0x228
> #define HCTL_SDBP BIT(8)
> #define HCTL_SDVS_SHIFT 9
> @@ -191,6 +200,58 @@ static void sdhci_omap_conf_bus_power(struct sdhci_omap_host *omap_host,
> }
> }
>
> +static int sdhci_omap_card_busy(struct mmc_host *mmc)
> +{
> + int i;
> + u32 reg, ac12;
> + int ret = true;
> + struct sdhci_host *host = mmc_priv(mmc);
> + struct sdhci_pltfm_host *pltfm_host;
> + struct sdhci_omap_host *omap_host;
> + u32 ier = host->ier;
> +
> + pltfm_host = sdhci_priv(host);
> + omap_host = sdhci_pltfm_priv(pltfm_host);
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + ac12 = sdhci_omap_readl(omap_host, SDHCI_OMAP_AC12);
> + reg &= ~CON_CLKEXTFREE;
> + if (ac12 & AC12_V1V8_SIGEN)
> + reg |= CON_CLKEXTFREE;
> + reg |= CON_PADEN;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + disable_irq(host->irq);
> + ier |= SDHCI_INT_CARD_INT;
> + sdhci_writel(host, ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
> +
> + for (i = 0; i < 5; i++) {
> + /*
> + * Delay is required for PSTATE to correctly reflect
> + * DLEV/CLEV values after PADEM is set.
> + */
> + usleep_range(100, 200);
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_PSTATE);
> + if ((reg & PSTATE_CLEV) &&
> + ((reg & PSTATE_DLEV) == PSTATE_DLEV)) {
> + ret = false;
> + goto ret;
'break' is better than 'goto'
> + }
> + }
> +
> +ret:
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + reg &= ~(CON_CLKEXTFREE | CON_PADEN);
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> + enable_irq(host->irq);
> +
> + return ret;
> +}
> +
> static int sdhci_omap_start_signal_voltage_switch(struct mmc_host *mmc,
> struct mmc_ios *ios)
> {
> @@ -562,6 +623,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> host->mmc_host_ops.start_signal_voltage_switch =
> sdhci_omap_start_signal_voltage_switch;
> host->mmc_host_ops.set_ios = sdhci_omap_set_ios;
> + host->mmc_host_ops.card_busy = sdhci_omap_card_busy;
>
> sdhci_read_caps(host);
> host->caps |= SDHCI_CAN_DO_ADMA2;
>
^ permalink raw reply
* [PATCH 01/12] mmc: sdhci-omap: Update 'power_mode' outside sdhci_omap_init_74_clocks
From: Adrian Hunter @ 2017-12-21 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214130941.26666-2-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Updating 'power_mode' in sdhci_omap_init_74_clocks results in
> 'power_mode' never updated to MMC_POWER_OFF during card
> removal. This results in initialization sequence not sent to the
> card during re-insertion.
> Fix it here by adding sdhci_omap_set_power_mode to update power_mode.
> This function can also be used later to perform operations that
> are specific to a power mode (e.g, disable tuning during power off).
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 628bfe9a3d17..96985786cadf 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -244,6 +244,12 @@ static int sdhci_omap_start_signal_voltage_switch(struct mmc_host *mmc,
> return 0;
> }
>
> +static void sdhci_omap_set_power_mode(struct sdhci_omap_host *omap_host,
> + u8 power_mode)
> +{
> + omap_host->power_mode = power_mode;
> +}
> +
> static void sdhci_omap_set_bus_mode(struct sdhci_omap_host *omap_host,
> unsigned int mode)
> {
> @@ -273,6 +279,7 @@ static void sdhci_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>
> sdhci_omap_set_bus_mode(omap_host, ios->bus_mode);
> sdhci_set_ios(mmc, ios);
> + sdhci_omap_set_power_mode(omap_host, ios->power_mode);
> }
>
> static u16 sdhci_omap_calc_divisor(struct sdhci_pltfm_host *host,
> @@ -401,8 +408,6 @@ static void sdhci_omap_init_74_clocks(struct sdhci_host *host, u8 power_mode)
> sdhci_omap_writel(omap_host, SDHCI_OMAP_STAT, INT_CC_EN);
>
> enable_irq(host->irq);
> -
> - omap_host->power_mode = power_mode;
> }
>
> static struct sdhci_ops sdhci_omap_ops = {
> @@ -504,6 +509,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> omap_host->host = host;
> omap_host->base = host->ioaddr;
> omap_host->dev = dev;
> + omap_host->power_mode = MMC_POWER_UNDEFINED;
> host->ioaddr += offset;
>
> mmc = host->mmc;
>
^ permalink raw reply
* [Allwinner R40] Banana M2 Ultra sysreq reboot and shutdown exceptions
From: Hermann Lauer @ 2017-12-21 8:41 UTC (permalink / raw)
To: linux-arm-kernel
Hello all,
after a night of kernel compiling on Bananapi_M2_Ultra (Allwinner R40) the device was not responding
anymore, so I tried the sysreq sequence on the serial console.
<break>b (to reboot) produced the appended kernel exception.
Please tell if more information is needed (or if this is only cosmetic, as the device rebooted).
As a second case the log of a normal shutdown is attached, which ends also with an exception.
Many thanks and merry Xmas,
greetings
Hermann
[34221.492249] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) k
[34232.752912] sysrq: SysRq : Resetting
[34232.756510] CPU2: stopping
[34232.759221] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W 4.15.0-rc3-next-20171212 #1
[34232.767993] Hardware name: Allwinner sun8i Family
[34232.772722] [<c0114e10>] (unwind_backtrace) from [<c010e970>] (show_stack+0x20/0x24)
[34232.780465] [<c010e970>] (show_stack) from [<c08fcca0>] (dump_stack+0x90/0xa4)
[34232.787687] [<c08fcca0>] (dump_stack) from [<c0112454>] (handle_IPI+0x29c/0x2bc)
[34232.795081] [<c0112454>] (handle_IPI) from [<c010253c>] (gic_handle_irq+0x90/0x94)
[34232.802645] [<c010253c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[34232.810118] Exception stack(0xee149f38 to 0xee149f80)
[34232.815164] 9f20: 00000000 027a7444
[34232.823334] 9f40: eedd1420 c0121bc0 ee148000 c1005df8 c1005e5c 00000004 c10f084b c0b653b4
[34232.831503] 9f60: 00000000 ee149f94 ee149f98 ee149f88 c010a214 c010a218 600e0013 ffffffff
[34232.839676] [<c0101a0c>] (__irq_svc) from [<c010a218>] (arch_cpu_idle+0x48/0x4c)
[34232.847070] [<c010a218>] (arch_cpu_idle) from [<c0919a90>] (default_idle_call+0x30/0x3c)
[34232.855156] [<c0919a90>] (default_idle_call) from [<c019b4cc>] (do_idle+0xe4/0x158)
[34232.862808] [<c019b4cc>] (do_idle) from [<c019b800>] (cpu_startup_entry+0x28/0x2c)
[34232.870372] [<c019b800>] (cpu_startup_entry) from [<c0111f20>] (secondary_start_kernel+0x15c/0x184)
[34232.879412] [<c0111f20>] (secondary_start_kernel) from [<40102b8c>] (0x40102b8c)
[34232.886800] CPU0: stopping
[34232.889509] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.15.0-rc3-next-20171212 #1
[34232.898279] Hardware name: Allwinner sun8i Family
[34232.902987] [<c0114e10>] (unwind_backtrace) from [<c010e970>] (show_stack+0x20/0x24)
[34232.910725] [<c010e970>] (show_stack) from [<c08fcca0>] (dump_stack+0x90/0xa4)
[34232.917944] [<c08fcca0>] (dump_stack) from [<c0112454>] (handle_IPI+0x29c/0x2bc)
[34232.925334] [<c0112454>] (handle_IPI) from [<c010253c>] (gic_handle_irq+0x90/0x94)
[34232.932898] [<c010253c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[34232.940369] Exception stack(0xc1001ee0 to 0xc1001f28)
[34232.945419] 1ee0: 00000000 0279020c eedaf420 c0121bc0 c1000000 c1005df8 c1005e5c 00000001
[34232.953588] 1f00: c10f084b c0b653b4 c0e94a30 c1001f3c c1001f40 c1001f30 c010a214 c010a218
[34232.961753] 1f20: 60070013 ffffffff
[34232.965243] [<c0101a0c>] (__irq_svc) from [<c010a218>] (arch_cpu_idle+0x48/0x4c)
[34232.972634] [<c010a218>] (arch_cpu_idle) from [<c0919a90>] (default_idle_call+0x30/0x3c)
[34232.980718] [<c0919a90>] (default_idle_call) from [<c019b4cc>] (do_idle+0xe4/0x158)
[34232.988368] [<c019b4cc>] (do_idle) from [<c019b800>] (cpu_startup_entry+0x28/0x2c)
[34232.995932] [<c019b800>] (cpu_startup_entry) from [<c0912cc4>] (rest_init+0xc0/0xc4)
[34233.003671] [<c0912cc4>] (rest_init) from [<c0e00eb0>] (start_kernel+0x428/0x450)
[34233.011143] CPU3: stopping
[34233.013852] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G W 4.15.0-rc3-next-20171212 #1
[34233.022623] Hardware name: Allwinner sun8i Family
[34233.027330] [<c0114e10>] (unwind_backtrace) from [<c010e970>] (show_stack+0x20/0x24)
[34233.035068] [<c010e970>] (show_stack) from [<c08fcca0>] (dump_stack+0x90/0xa4)
[34233.042286] [<c08fcca0>] (dump_stack) from [<c0112454>] (handle_IPI+0x29c/0x2bc)
[34233.049676] [<c0112454>] (handle_IPI) from [<c010253c>] (gic_handle_irq+0x90/0x94)
[34233.057239] [<c010253c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[34233.064709] Exception stack(0xee14bf38 to 0xee14bf80)
[34233.069754] bf20: 00000000 0279f86c
[34233.077924] bf40: eede2420 c0121bc0 ee14a+-----------------------------+c10f084b c0b653b4
[34233.086093] bf60: 00000000 ee14bf94 ee14b| |60080013 ffffffff
[34233.094263] [<c0101a0c>] (__irq_svc) from| Cannot open /dev/ttyUSB0! |48/0x4c)
[34233.101655] [<c010a218>] (arch_cpu_idle) | |_call+0x30/0x3c)
[34233.109739] [<c0919a90>] (default_idle_ca+-----------------------------+0xe4/0x158)
[34233.117388] [<c019b4cc>] (do_idle) from [<c019b800>] (cpu_startup_entry+0x28/0x2c)
[34233.124952] [<c019b800>] (cpu_startup_entry) from [<c0111f20>] (secondary_start_kernel+0x15c/0x184)
[34233.133988] [<c0111f20>] (secondary_start_kernel) from [<40102b8c>] (0x40102b8c)
U-Boot SPL 2017.11-rc2 (Oct 20 2017 - 22:21:57)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2017.11-rc2 (Oct 20 2017 - 22:21:57 +0200) Allwinner Technology
CPU: Allwinner R40 (SUN8I 1701)
Model: Banana Pi BPI-M2-Ultra
I2C: ready
DRAM: 2 GiB
MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
*** Warning - bad CRC, using default environment
In: serial at 1c28000
Out: serial at 1c28000
Err: serial at 1c28000
SCSI: Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net: No ethernet found.
starting USB...
No controllers found
Hit any key to stop autoboot: 0
--- normal shutdown ---
[ 3826.601352] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 3826.606737] sd 0:0:0:0: [sda] Stopping disk
[ 3827.208326] reboot: Power down
[ 3829.265309] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 3829.781624] systemd-shutdow: 3 output lines suppressed due to ratelimiting
[ 3829.788652] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 3829.788652]
[ 3829.797779] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.15.0-rc3-next-20171212 #1
[ 3829.805770] Hardware name: Allwinner sun8i Family
[ 3829.810499] [<c0114e10>] (unwind_backtrace) from [<c010e970>] (show_stack+0x20/0x24)
[ 3829.818243] [<c010e970>] (show_stack) from [<c08fcca0>] (dump_stack+0x90/0xa4)
[ 3829.825466] [<c08fcca0>] (dump_stack) from [<c014ea58>] (panic+0x100/0x28c)
[ 3829.832427] [<c014ea58>] (panic) from [<c0154634>] (complete_and_exit+0x0/0x2c)
[ 3829.839734] [<c0154634>] (complete_and_exit) from [<c0175974>] (SyS_reboot+0x1c8/0x238)
[ 3829.847733] [<c0175974>] (SyS_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
[ 3829.855379] Exception stack(0xee109fa8 to 0xee109ff0)
[ 3829.860427] 9fa0: 00455660 4321fedc fee1dead 28121969 4321fedc 8b9c6d00
[ 3829.868597] 9fc0: 00455660 4321fedc 008b8028 00000058 008b80b0 008b8028 be919e94 fffff000
[ 3829.876763] 9fe0: 00000058 be919bc4 b6d08075 b6c8e6f6
[ 3829.881829] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 3829.881829]
--
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: Hermann.Lauer at iwr.uni-heidelberg.de
^ permalink raw reply
* [PATCH v3 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Shawn Guo @ 2017-12-21 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219181038.1369-1-stefan@agner.ch>
On Tue, Dec 19, 2017 at 07:10:30PM +0100, Stefan Agner wrote:
> The Colibri default which enables USB Host power is not necessarily
> tied to the OTG2 controller, some carrier board use the pin to
> control USB power for both controllers. Hence name the pinctrl
> group more generic.
>
> Also move the regulator to the generic eval-v3 device tree since
> the regulator is always on the carrier board. In the Colibri iMX7S
> case the regulator is just not used. This allows to reuse the
> regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH v3 1/3] ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings
From: Shawn Guo @ 2017-12-21 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512573319-6624-1-git-send-email-marcofrk@gmail.com>
On Wed, Dec 06, 2017 at 01:15:17PM -0200, Marco Franchi wrote:
> It is preferred to use the panel compatible string rather than passing
> the LCD timing in the device tree.
>
> So pass the "sii,43wvf1g" compatible string, which describes the parallel
> LCD.
>
> Also pass the 'backlight' property as described in
> Documentation/devicetree/bindings/display/panel/simple-panel.txt
>
> Signed-off-by: Marco Franchi <marcofrk@gmail.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH v3 6/6] coresight: etm4x: Support panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
ETMv4 hardware information and configuration needs to be saved as
metadata; these metadata should be compatible with tool 'perf' and
can be used for tracing data analysis. ETMv4 usually works as tracer
per CPU, we cannot wait to gather ETM info after the CPU has been panic
and cannot execute dump operations for itself; so should gather
metadata when the corresponding CPU is alive.
Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
won't change at the runtime. Those registers value are filled when
tracers are instantiated.
The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
dynamically configured, we record their value when enabling coresight
path. When operating from sysFS tracer these two registers are recorded
in etm4_enable_sysfs() and add kdump node into list, and remove the
kdump node in etm4_disable_sysfs(). When operating from perf,
etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
is used to record configuration registers and update dump buffer info,
this can avoid unnecessary list addition and deletion operations.
Removal of the tracers from the dump list is done in function
free_event_data().
Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++++++++++-
drivers/hwtracing/coresight/coresight-etm4x.c | 23 +++++++++++++++++++++++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 8a0ad77..fec779b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
}
for_each_cpu(cpu, mask) {
+ struct coresight_device *csdev;
+
+ csdev = per_cpu(csdev_src, cpu);
+ if (csdev)
+ coresight_kdump_del(csdev);
+
if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
coresight_release_path(event_data->path[cpu]);
}
@@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
static void *etm_setup_aux(int event_cpu, void **pages,
int nr_pages, bool overwrite)
{
- int cpu;
+ int cpu, ret;
cpumask_t *mask;
struct coresight_device *sink;
struct etm_event_data *event_data = NULL;
@@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
+
+ ret = coresight_kdump_add(csdev, cpu);
+ if (ret)
+ goto err;
}
if (!sink_ops(sink)->alloc_buffer)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index cf364a5..cbde398 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device *csdev,
static int etm4_enable_sysfs(struct coresight_device *csdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct etmv4_config *config = &drvdata->config;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
int ret;
spin_lock(&drvdata->spinlock);
+ /* Update meta data and add into kdump list */
+ metadata->trcconfigr = config->cfg;
+ metadata->trctraceidr = drvdata->trcid;
+
+ coresight_kdump_add(csdev, drvdata->cpu);
+ coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
+
/*
* Executing etm4_enable_hw on the cpu whose ETM is being enabled
* ensures that register writes occur when cpu is powered.
@@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
*/
smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
+ /* Delete from kdump list */
+ coresight_kdump_del(csdev);
+
spin_unlock(&drvdata->spinlock);
cpus_read_unlock();
@@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
u32 etmidr4;
u32 etmidr5;
struct etmv4_drvdata *drvdata = info;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
/* Make sure all registers are accessible */
etm4_os_unlock(drvdata);
@@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
/* NUMCNTR, bits[30:28] number of counters available for tracing */
drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
+
+ /* Update metadata */
+ metadata->magic = ETM4_METADATA_MAGIC;
+ metadata->cpu = drvdata->cpu;
+ metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
+ metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
+ metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
+ metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
+ metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
+
CS_LOCK(drvdata->base);
}
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index b3b5ea7..08dc8b7 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -198,6 +198,20 @@
#define ETM_EXLEVEL_NS_HYP BIT(14)
#define ETM_EXLEVEL_NS_NA BIT(15)
+#define ETM4_METADATA_MAGIC 0x4040404040404040ULL
+
+struct etmv4_metadata {
+ u64 magic;
+ u64 cpu;
+ u64 trcconfigr;
+ u64 trctraceidr;
+ u64 trcidr0;
+ u64 trcidr1;
+ u64 trcidr2;
+ u64 trcidr8;
+ u64 trcauthstatus;
+};
+
/**
* struct etmv4_config - configuration information related to an ETMv4
* @mode: Controls various modes supported by this ETM.
@@ -393,6 +407,7 @@ struct etmv4_drvdata {
bool atbtrig;
bool lpoverride;
struct etmv4_config config;
+ struct etmv4_metadata metadata;
};
/* Address comparator access types */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/6] coresight: Add and delete sink callback for panic kdump list
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
If the sink device has panic kdump callback, this means the sink device
wants to save tracing data for panic happening.
This commit adds node into panic kdump list when the sink device is
enabled, and delete node when the sink device is disabled.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..56798b1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -146,6 +146,14 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
if (ret)
return ret;
}
+
+ /* Add into panic kdump list */
+ if (sink_ops(csdev)->panic_cb) {
+ ret = coresight_kdump_add(csdev, 0);
+ if (ret)
+ return ret;
+ }
+
csdev->enable = true;
}
@@ -157,6 +165,10 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
static void coresight_disable_sink(struct coresight_device *csdev)
{
if (atomic_dec_return(csdev->refcnt) == 0) {
+ /* Delete from panic kdump list */
+ if (sink_ops(csdev)->panic_cb)
+ coresight_kdump_del(csdev);
+
if (sink_ops(csdev)->disable) {
sink_ops(csdev)->disable(csdev);
csdev->enable = false;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] coresight: tmc: Hook callback for panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
Since the panic kdump functionality has been ready, this patch is to
hook panic callback function for ETB/ETF. Since the driver data
structure has allocated buffer when the session started, so simply save
ETB/ETF trace data into the buffer when panic happens and update
related info into dump node.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 +++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index e2513b7..f823464 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -504,6 +504,34 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev,
CS_LOCK(drvdata->base);
}
+static void tmc_panic_cb(void *data)
+{
+ struct coresight_device *csdev = (struct coresight_device *)data;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ unsigned long flags;
+
+ if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+ drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+ return;
+
+ if (drvdata->mode == CS_MODE_DISABLED)
+ return;
+
+ spin_lock_irqsave(&drvdata->spinlock, flags);
+
+ CS_UNLOCK(drvdata->base);
+
+ tmc_flush_and_stop(drvdata);
+ tmc_etb_dump_hw(drvdata);
+
+ CS_LOCK(drvdata->base);
+
+ /* Update buffer info for panic dump */
+ coresight_kdump_update(csdev, drvdata->buf, drvdata->len);
+
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
+}
+
static const struct coresight_ops_sink tmc_etf_sink_ops = {
.enable = tmc_enable_etf_sink,
.disable = tmc_disable_etf_sink,
@@ -512,6 +540,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = {
.set_buffer = tmc_set_etf_buffer,
.reset_buffer = tmc_reset_etf_buffer,
.update_buffer = tmc_update_etf_buffer,
+ .panic_cb = tmc_panic_cb,
};
static const struct coresight_ops_link tmc_etf_link_ops = {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/6] coresight: Support panic kdump functionality
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
After kernel panic happens, coresight has many useful info can be used
for analysis. For example, the trace info from ETB RAM can be used to
check the CPU execution flows before crash. So we can save the tracing
data from sink devices, and rely on kdump to save DDR content and uses
"crash" tool to extract coresight dumping from vmcore file.
This patch is to add a simple framework to support panic dump
functionality; it registers panic notifier, and provide the general APIs
{coresight_kdump_add|coresight_kdump_del} as helper functions so any
coresight device can add itself into dump list or delete as needed.
This driver provides helper function coresight_kdump_update() to update
the dump buffer base address and buffer size. This function can be used
by coresight driver, e.g. it can be used to save ETM meta data info at
runtime and these info can be prepared pre panic happening.
When kernel panic happens, the notifier iterates dump list and calls
callback function to dump device specific info. The panic dump is
mainly used to dump trace data so we can get to know the execution flow
before the panic happens.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/Kconfig | 9 ++
drivers/hwtracing/coresight/Makefile | 1 +
.../hwtracing/coresight/coresight-panic-kdump.c | 154 +++++++++++++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 13 ++
include/linux/coresight.h | 7 +
5 files changed, 184 insertions(+)
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c..4812529 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
properly, please refer Documentation/trace/coresight-cpu-debug.txt
for detailed description and the example for usage.
+config CORESIGHT_PANIC_KDUMP
+ bool "CoreSight Panic Kdump driver"
+ depends on ARM || ARM64
+ help
+ This driver provides panic kdump functionality for CoreSight
+ devices. When a kernel panic happen a device supplied callback function
+ is used to save trace data to memory. From there we rely on kdump to extract
+ the trace data from kernel dump file.
+
endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 61db9dd..946fe19 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
+obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c b/drivers/hwtracing/coresight/coresight-panic-kdump.c
new file mode 100644
index 0000000..c21d20b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Linaro Limited.
+#include <linux/coresight.h>
+#include <linux/coresight-pmu.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/perf_event.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+#include "coresight-priv.h"
+
+typedef void (*coresight_cb_t)(void *data);
+
+/**
+ * struct coresight_kdump_node - Node information for dump
+ * @cpu: The cpu this node is affined to.
+ * @csdev: Handler for coresight device.
+ * @buf: Pointer for dump buffer.
+ * @buf_size: Length of dump buffer.
+ * @list: Hook to the list.
+ */
+struct coresight_kdump_node {
+ int cpu;
+ struct coresight_device *csdev;
+ char *buf;
+ unsigned int buf_size;
+ struct list_head list;
+};
+
+static DEFINE_SPINLOCK(coresight_kdump_lock);
+static LIST_HEAD(coresight_kdump_list);
+static struct notifier_block coresight_kdump_nb;
+
+int coresight_kdump_update(struct coresight_device *csdev, char *buf,
+ unsigned int buf_size)
+{
+ struct coresight_kdump_node *node = csdev->dump_node;
+
+ if (!node) {
+ dev_err(&csdev->dev, "Failed to update dump node.\n");
+ return -EINVAL;
+ }
+
+ node->buf = buf;
+ node->buf_size = buf_size;
+ return 0;
+}
+
+int coresight_kdump_add(struct coresight_device *csdev, int cpu)
+{
+ struct coresight_kdump_node *node;
+ unsigned long flags;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ csdev->dump_node = (void *)node;
+ node->cpu = cpu;
+ node->csdev = csdev;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+ list_add_tail(&node->list, &coresight_kdump_list);
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+ return 0;
+}
+
+void coresight_kdump_del(struct coresight_device *csdev)
+{
+ struct coresight_kdump_node *node, *next;
+ unsigned long flags;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+ list_for_each_entry_safe(node, next, &coresight_kdump_list, list) {
+ if (node->csdev == csdev) {
+ list_del(&node->list);
+ kfree(node);
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+}
+
+static coresight_cb_t
+coresight_kdump_get_cb(struct coresight_device *csdev)
+{
+ coresight_cb_t cb = NULL;
+
+ switch (csdev->type) {
+ case CORESIGHT_DEV_TYPE_SINK:
+ case CORESIGHT_DEV_TYPE_LINKSINK:
+ cb = sink_ops(csdev)->panic_cb;
+ break;
+ case CORESIGHT_DEV_TYPE_SOURCE:
+ cb = source_ops(csdev)->panic_cb;
+ break;
+ case CORESIGHT_DEV_TYPE_LINK:
+ cb = link_ops(csdev)->panic_cb;
+ break;
+ default:
+ dev_info(&csdev->dev, "Unsupport panic dump\n");
+ break;
+ }
+
+ return cb;
+}
+
+/**
+ * coresight_kdump_notify - Invoke panic dump callbacks, this is
+ * the main function to fulfill the panic dump. It distinguishs
+ * to two types: one is pre panic dump which the callback function
+ * handler is NULL and coresight drivers can use function
+ * coresight_kdump_update() to directly update dump buffer base
+ * address and buffer size, for this case this function does nothing
+ * and directly bail out; another case is for post panic dump so
+ * invoke callback on alive CPU.
+ *
+ * Returns: 0 on success.
+ */
+static int coresight_kdump_notify(struct notifier_block *nb,
+ unsigned long mode, void *_unused)
+{
+ struct coresight_kdump_node *node;
+ struct coresight_device *csdev;
+ coresight_cb_t cb;
+ unsigned long flags;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+
+ list_for_each_entry(node, &coresight_kdump_list, list) {
+ csdev = node->csdev;
+ cb = coresight_kdump_get_cb(csdev);
+ if (cb)
+ cb(csdev);
+ }
+
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+ return 0;
+}
+
+static int __init coresight_kdump_init(void)
+{
+ int ret;
+
+ coresight_kdump_nb.notifier_call = coresight_kdump_notify;
+ ret = atomic_notifier_chain_register(&panic_notifier_list,
+ &coresight_kdump_nb);
+ return ret;
+}
+late_initcall(coresight_kdump_init);
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index f1d0e21d..937750e 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -151,4 +151,17 @@ static inline int etm_readl_cp14(u32 off, unsigned int *val) { return 0; }
static inline int etm_writel_cp14(u32 off, u32 val) { return 0; }
#endif
+#ifdef CONFIG_CORESIGHT_PANIC_KDUMP
+extern int coresight_kdump_add(struct coresight_device *csdev, int cpu);
+extern void coresight_kdump_del(struct coresight_device *csdev);
+extern int coresight_kdump_update(struct coresight_device *csdev,
+ char *buf, unsigned int buf_size);
+#else
+static inline int
+coresight_kdump_add(struct coresight_device *csdev, int cpu) { return 0; }
+static inline void coresight_kdump_del(struct coresight_device *csdev) {}
+static inline int coresight_kdump_update(struct coresight_device *csdev,
+ char *buf, unsigned int buf_size) { return 0; }
+#endif
+
#endif
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index d950dad..43e40fa 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -171,6 +171,7 @@ struct coresight_device {
bool orphan;
bool enable; /* true only if configured as part of a path */
bool activated; /* true only if a sink is part of a path */
+ void *dump_node;
};
#define to_coresight_device(d) container_of(d, struct coresight_device, dev)
@@ -189,6 +190,7 @@ struct coresight_device {
* @set_buffer: initialises buffer mechanic before a trace session.
* @reset_buffer: finalises buffer mechanic after a trace session.
* @update_buffer: update buffer pointers after a trace session.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_sink {
int (*enable)(struct coresight_device *csdev, u32 mode);
@@ -205,6 +207,7 @@ struct coresight_ops_sink {
void (*update_buffer)(struct coresight_device *csdev,
struct perf_output_handle *handle,
void *sink_config);
+ void (*panic_cb)(void *data);
};
/**
@@ -212,10 +215,12 @@ struct coresight_ops_sink {
* Operations available for links.
* @enable: enables flow between iport and oport.
* @disable: disables flow between iport and oport.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_link {
int (*enable)(struct coresight_device *csdev, int iport, int oport);
void (*disable)(struct coresight_device *csdev, int iport, int oport);
+ void (*panic_cb)(void *data);
};
/**
@@ -227,6 +232,7 @@ struct coresight_ops_link {
* to the HW.
* @enable: enables tracing for a source.
* @disable: disables tracing for a source.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_source {
int (*cpu_id)(struct coresight_device *csdev);
@@ -235,6 +241,7 @@ struct coresight_ops_source {
struct perf_event *event, u32 mode);
void (*disable)(struct coresight_device *csdev,
struct perf_event *event);
+ void (*panic_cb)(void *data);
};
struct coresight_ops {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/6] doc: Add documentation for Coresight panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
Add detailed documentation for Coresight panic kdump, which contains
the idea for why need this and introduce the framework implementation
and usage.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
.../trace/coresight/coresight-panic-kdump.txt | 91 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 92 insertions(+)
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt b/Documentation/trace/coresight/coresight-panic-kdump.txt
new file mode 100644
index 0000000..6bf9cac
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
@@ -0,0 +1,91 @@
+ Coresight Panic Kdump
+ =====================
+
+ Author: Leo Yan <leo.yan@linaro.org>
+ Date: Dec 21th, 2017
+
+Introduction
+------------
+
+Coresight has different sinks for trace data, the trace data is quite useful
+for postmortem debugging. Embedded Trace Buffer (ETB) is one type sink which
+provides on-chip storage of trace data, usually uses SRAM as buffer with
+several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
+chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
+can avoid to be overwritted by other CPUs. Trace Memory Controller (TMC) is
+another kind sink designed as a successor to the CoreSight ETB to capture trace
+into DRAM.
+
+After Linux kernel trigger panic, the trace data keeps the last execution flow
+before issues happen. We could consider the trace data is quite useful for
+postmortem debugging, especially when we can record trace data into DRAM and rely
+on kdump to save them into vmcore file; at the end we can retrieve trace data
+from vmcore file and "offline" to analyze the execution flow.
+
+
+Implementation
+--------------
+
+Coresight panic kdump is a simple framework to support dump functionality,
+it maintains dump list with every node recording the dump buffer base address
+and buffer size. Coresight panic kdump provides the general APIs
+{coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight
+device can add itself into dump list or delete as needed.
+
+Generally coresight device set its 'panic_cb' in the ops structure, the panic
+notifier iterates dump list and invokes callback function to dump device specific
+info.
+
+For easily used by offline analysis, we also record tracer metadata so can
+retrieve tracer IDs and configuration, in this case the node records CPU number so
+can create connection between the metadata and specific CPU. The tracer
+driver uses helper function coresight_kdump_update() to update the dump
+buffer base address and buffer size; so the tracer can save metadata at runtime
+and these info can be prepared well pre panic happening.
+
+
+Usage
+-----
+
+Build Linux kernel with enabling 'CONFIG_CORESIGHT_PANIC_KDUMP' configuration.
+
+After system booting up, we need firstly prepare dump-capture kernel, this can
+refer doc [1] chapter 'Load the Dump-capture Kernel' for detailed steps. Then
+we need enable the coresight tracer, this can use either perf framework method
+or sysFS interface, please refer doc [2] chapter 'How to use the tracer modules'
+for detailed steps.
+
+When kernel panic happens, the panic kdump records trace data and launches
+dump-capture kernel, we can utilize the dump-capture kernel to save kernel dump
+file, this can refer doc [1] chapter 'Write Out the Dump File'.
+
+After get kernel dump file, we can use 'crash' tool + csdump.so extension to
+extract trace data and generate 'perf.data' file:
+
+ ./crash vmcore vmlinux
+ crash> extend csdump.so
+ crash> csdump output_dir
+
+ We can see in the 'output_dir' there will generate out three files:
+ output_dir/
+ ??? cstrace.bin -> trace raw data
+ ??? metadata.bin -> meta data
+ ??? perf.data -> 'perf' format compatible file
+
+Finally use 'perf' tool for offline analysis:
+
+ ./perf script -v -F cpu,event,ip,sym,symoff -i perf.data -k vmlinux --kallsyms /proc/kallsyms
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+ [001] instructions: ffff000008559ae0 pl011_console_write+0xa0
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+ [001] instructions: ffff000008559ae0 pl011_console_write+0xa0
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+
+[1] Documentation/kdump/kdump.txt
+[2] Documentation/trace/coresight/coresight.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index d7a6fc7..26276e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1309,6 +1309,7 @@ S: Maintained
F: drivers/hwtracing/coresight/*
F: Documentation/trace/coresight/coresight.txt
F: Documentation/trace/coresight/coresight-cpu-debug.txt
+F: Documentation/trace/coresight/coresight-panic-kdump.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/6] doc: Add Coresight documentation directory
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
For easily management and friendly adding more Coresight related
documentations, this commit creates one dedicated directory:
Documentation/trace/coresight. It moves Coresight related docs into
this new directory and updates MAINTAINERS file to reflect docs
movement.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
Documentation/trace/coresight-cpu-debug.txt | 187 ------------
Documentation/trace/coresight.txt | 332 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++++
Documentation/trace/coresight/coresight.txt | 332 +++++++++++++++++++++
MAINTAINERS | 4 +-
5 files changed, 521 insertions(+), 521 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt
deleted file mode 100644
index 2b9b51c..0000000
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ /dev/null
@@ -1,187 +0,0 @@
- Coresight CPU Debug Module
- ==========================
-
- Author: Leo Yan <leo.yan@linaro.org>
- Date: April 5th, 2017
-
-Introduction
-------------
-
-Coresight CPU debug module is defined in ARMv8-a architecture reference manual
-(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
-debug module and it is mainly used for two modes: self-hosted debug and
-external debug. Usually the external debug mode is well known as the external
-debugger connects with SoC from JTAG port; on the other hand the program can
-explore debugging method which rely on self-hosted debug mode, this document
-is to focus on this part.
-
-The debug module provides sample-based profiling extension, which can be used
-to sample CPU program counter, secure state and exception level, etc; usually
-every CPU has one dedicated debug module to be connected. Based on self-hosted
-debug mechanism, Linux kernel can access these related registers from mmio
-region when the kernel panic happens. The callback notifier for kernel panic
-will dump related registers for every CPU; finally this is good for assistant
-analysis for panic.
-
-
-Implementation
---------------
-
-- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
- registers to decide if sample-based profiling is implemented or not. On some
- platforms this hardware feature is fully or partially implemented; and if
- this feature is not supported then registration will fail.
-
-- At the time this documentation was written, the debug driver mainly relies on
- information gathered by the kernel panic callback notifier from three
- sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
- program counter; EDVIDSR has information for secure state, exception level,
- bit width, etc; EDCIDSR is context ID value which contains the sampled value
- of CONTEXTIDR_EL1.
-
-- The driver supports a CPU running in either AArch64 or AArch32 mode. The
- registers naming convention is a bit different between them, AArch64 uses
- 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
- 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
- use AArch64 naming convention.
-
-- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
- register bits definition. So the driver consolidates two difference:
-
- If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
- but ARMv7-a defines "PCSR samples are offset by a value that depends on the
- instruction set state". For ARMv7-a, the driver checks furthermore if CPU
- runs with ARM or thumb instruction set and calibrate PCSR value, the
- detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
- C11.11.34 "DBGPCSR, Program Counter Sampling Register".
-
- If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
- no offset applied and do not sample the instruction set state in AArch32
- state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
- in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
- state EDPCSR is sampled and no offset are applied.
-
-
-Clock and power domain
-----------------------
-
-Before accessing debug registers, we should ensure the clock and power domain
-have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
-Debug registers', the debug registers are spread into two domains: the debug
-domain and the CPU domain.
-
- +---------------+
- | |
- | |
- +----------+--+ |
- dbg_clock -->| |**| |<-- cpu_clock
- | Debug |**| CPU |
- dbg_power_domain -->| |**| |<-- cpu_power_domain
- +----------+--+ |
- | |
- | |
- +---------------+
-
-For debug domain, the user uses DT binding "clocks" and "power-domains" to
-specify the corresponding clock source and power supply for the debug logic.
-The driver calls the pm_runtime_{put|get} operations as needed to handle the
-debug power domain.
-
-For CPU domain, the different SoC designs have different power management
-schemes and finally this heavily impacts external debug module. So we can
-divide into below cases:
-
-- On systems with a sane power controller which can behave correctly with
- respect to CPU power domain, the CPU power domain can be controlled by
- register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ
- to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
- of CPU power down. As result, this can ensure the CPU power domain is
- powered on properly during the period when access debug related registers;
-
-- Some designs will power down an entire cluster if all CPUs on the cluster
- are powered down - including the parts of the debug registers that should
- remain powered in the debug power domain. The bits in EDPRCR are not
- respected in these cases, so these designs do not support debug over
- power down in the way that the CoreSight / Debug designers anticipated.
- This means that even checking EDPRSR has the potential to cause a bus hang
- if the target register is unpowered.
-
- In this case, accessing to the debug registers while they are not powered
- is a recipe for disaster; so we need preventing CPU low power states at boot
- time or when user enable module at the run time. Please see chapter
- "How to use the module" for detailed usage info for this.
-
-
-Device Tree Bindings
---------------------
-
-See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details.
-
-
-How to use the module
----------------------
-
-If you want to enable debugging functionality@boot time, you can add
-"coresight_cpu_debug.enable=1" to the kernel command line parameter.
-
-The driver also can work as module, so can enable the debugging when insmod
-module:
-# insmod coresight_cpu_debug.ko debug=1
-
-When boot time or insmod module you have not enabled the debugging, the driver
-uses the debugfs file system to provide a knob to dynamically enable or disable
-debugging:
-
-To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
-
-To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
-
-As explained in chapter "Clock and power domain", if you are working on one
-platform which has idle states to power off debug logic and the power
-controller cannot work well for the request from EDPRCR, then you should
-firstly constraint CPU idle states before enable CPU debugging feature; so can
-ensure the accessing to debug logic.
-
-If you want to limit idle states at boot time, you can use "nohlt" or
-"cpuidle.off=1" in the kernel command line.
-
-At the runtime you can disable idle states with below methods:
-
-It is possible to disable CPU idle states by way of the PM QoS
-subsystem, more specifically by using the "/dev/cpu_dma_latency"
-interface (see Documentation/power/pm_qos_interface.txt for more
-details). As specified in the PM QoS documentation the requested
-parameter will stay in effect until the file descriptor is released.
-For example:
-
-# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
-...
-Do some work...
-...
-# exec 3<>-
-
-The same can also be done from an application program.
-
-Disable specific CPU's specific idle state from cpuidle sysfs (see
-Documentation/cpuidle/sysfs.txt):
-# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
-
-
-Output format
--------------
-
-Here is an example of the debugging output format:
-
-ARM external debug module:
-coresight-cpu-debug 850000.debug: CPU[0]:
-coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 850000.debug: EDPCSR: [<ffff00000808e9bc>] handle_IPI+0x174/0x1d8
-coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
-coresight-cpu-debug 852000.debug: CPU[1]:
-coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 852000.debug: EDPCSR: [<ffff0000087fab34>] debug_notifier_call+0x23c/0x358
-coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
deleted file mode 100644
index a33c88c..0000000
--- a/Documentation/trace/coresight.txt
+++ /dev/null
@@ -1,332 +0,0 @@
- Coresight - HW Assisted Tracing on ARM
- ======================================
-
- Author: Mathieu Poirier <mathieu.poirier@linaro.org>
- Date: September 11th, 2014
-
-Introduction
-------------
-
-Coresight is an umbrella of technologies allowing for the debugging of ARM
-based SoC. It includes solutions for JTAG and HW assisted tracing. This
-document is concerned with the latter.
-
-HW assisted tracing is becoming increasingly useful when dealing with systems
-that have many SoCs and other components like GPU and DMA engines. ARM has
-developed a HW assisted tracing solution by means of different components, each
-being added to a design at synthesis time to cater to specific tracing needs.
-Components are generally categorised as source, link and sinks and are
-(usually) discovered using the AMBA bus.
-
-"Sources" generate a compressed stream representing the processor instruction
-path based on tracing scenarios as configured by users. From there the stream
-flows through the coresight system (via ATB bus) using links that are connecting
-the emanating source to a sink(s). Sinks serve as endpoints to the coresight
-implementation, either storing the compressed stream in a memory buffer or
-creating an interface to the outside world where data can be transferred to a
-host without fear of filling up the onboard coresight memory buffer.
-
-At typical coresight system would look like this:
-
- *****************************************************************
- **************************** AMBA AXI ****************************===||
- ***************************************************************** ||
- ^ ^ | ||
- | | * **
- 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ ||||||||||||
- 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System ||
- |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory ||
- | #######<-->: I : | #######<-->: I : : I : @@@<-| ||||||||||||
- | # ETM # ::::: | # PTM # ::::: ::::: @ |
- | ##### ^ ^ | ##### ^ ! ^ ! . | |||||||||
- | |->### | ! | |->### | ! | ! . | || DAP ||
- | | # | ! | | # | ! | ! . | |||||||||
- | | . | ! | | . | ! | ! . | | |
- | | . | ! | | . | ! | ! . | | *
- | | . | ! | | . | ! | ! . | | SWD/
- | | . | ! | | . | ! | ! . | | JTAG
- *****************************************************************<-|
- *************************** AMBA Debug APB ************************
- *****************************************************************
- | . ! . ! ! . |
- | . * . * * . |
- *****************************************************************
- ******************** Cross Trigger Matrix (CTM) *******************
- *****************************************************************
- | . ^ . . |
- | * ! * * |
- *****************************************************************
- ****************** AMBA Advanced Trace Bus (ATB) ******************
- *****************************************************************
- | ! =============== |
- | * ===== F =====<---------|
- | ::::::::: ==== U ====
- |-->:: CTI ::<!! === N ===
- | ::::::::: ! == N ==
- | ^ * == E ==
- | ! &&&&&&&&& IIIIIII == L ==
- |------>&& ETB &&<......II I =======
- | ! &&&&&&&&& II I .
- | ! I I .
- | ! I REP I<..........
- | ! I I
- | !!>&&&&&&&&& II I *Source: ARM ltd.
- |------>& TPIU &<......II I DAP = Debug Access Port
- &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell
- ; PTM = Program Trace Macrocell
- ; CTI = Cross Trigger Interface
- * ETB = Embedded Trace Buffer
- To trace port TPIU= Trace Port Interface Unit
- SWD = Serial Wire Debug
-
-While on target configuration of the components is done via the APB bus,
-all trace data are carried out-of-band on the ATB bus. The CTM provides
-a way to aggregate and distribute signals between CoreSight components.
-
-The coresight framework provides a central point to represent, configure and
-manage coresight devices on a platform. This first implementation centers on
-the basic tracing functionality, enabling components such ETM/PTM, funnel,
-replicator, TMC, TPIU and ETB. Future work will enable more
-intricate IP blocks such as STM and CTI.
-
-
-Acronyms and Classification
----------------------------
-
-Acronyms:
-
-PTM: Program Trace Macrocell
-ETM: Embedded Trace Macrocell
-STM: System trace Macrocell
-ETB: Embedded Trace Buffer
-ITM: Instrumentation Trace Macrocell
-TPIU: Trace Port Interface Unit
-TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
-TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
-CTI: Cross Trigger Interface
-
-Classification:
-
-Source:
- ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM
-Link:
- Funnel, replicator (intelligent or not), TMC-ETR
-Sinks:
- ETBv1.0, ETB1.1, TPIU, TMC-ETF
-Misc:
- CTI
-
-
-Device Tree Bindings
-----------------------
-
-See Documentation/devicetree/bindings/arm/coresight.txt for details.
-
-As of this writing drivers for ITM, STMs and CTIs are not provided but are
-expected to be added as the solution matures.
-
-
-Framework and implementation
-----------------------------
-
-The coresight framework provides a central point to represent, configure and
-manage coresight devices on a platform. Any coresight compliant device can
-register with the framework for as long as they use the right APIs:
-
-struct coresight_device *coresight_register(struct coresight_desc *desc);
-void coresight_unregister(struct coresight_device *csdev);
-
-The registering function is taking a "struct coresight_device *csdev" and
-register the device with the core framework. The unregister function takes
-a reference to a "struct coresight_device", obtained@registration time.
-
-If everything goes well during the registration process the new devices will
-show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
-
-root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:~#
-
-The functions take a "struct coresight_device", which looks like this:
-
-struct coresight_desc {
- enum coresight_dev_type type;
- struct coresight_dev_subtype subtype;
- const struct coresight_ops *ops;
- struct coresight_platform_data *pdata;
- struct device *dev;
- const struct attribute_group **groups;
-};
-
-
-The "coresight_dev_type" identifies what the device is, i.e, source link or
-sink while the "coresight_dev_subtype" will characterise that type further.
-
-The "struct coresight_ops" is mandatory and will tell the framework how to
-perform base operations related to the components, each component having
-a different set of requirement. For that "struct coresight_ops_sink",
-"struct coresight_ops_link" and "struct coresight_ops_source" have been
-provided.
-
-The next field, "struct coresight_platform_data *pdata" is acquired by calling
-"of_get_coresight_platform_data()", as part of the driver's _probe routine and
-"struct device *dev" gets the device reference embedded in the "amba_device":
-
-static int etm_probe(struct amba_device *adev, const struct amba_id *id)
-{
- ...
- ...
- drvdata->dev = &adev->dev;
- ...
-}
-
-Specific class of device (source, link, or sink) have generic operations
-that can be performed on them (see "struct coresight_ops"). The
-"**groups" is a list of sysfs entries pertaining to operations
-specific to that component only. "Implementation defined" customisations are
-expected to be accessed and controlled using those entries.
-
-Last but not least, "struct module *owner" is expected to be set to reflect
-the information carried in "THIS_MODULE".
-
-How to use the tracer modules
------------------------------
-
-Before trace collection can start, a coresight sink needs to be identify.
-There is no limit on the amount of sinks (nor sources) that can be enabled at
-any given moment. As a generic operation, all device pertaining to the sink
-class will have an "active" entry in sysfs:
-
-root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
-root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
-root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
-1
-root:/sys/bus/coresight/devices#
-
-At boot time the current etm3x driver will configure the first address
-comparator with "_stext" and "_etext", essentially tracing any instruction
-that falls within that range. As such "enabling" a source will immediately
-trigger a trace capture:
-
-root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
-1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
-
-Trace collection is stopped the same way:
-
-root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices#
-
-The content of the ETB buffer can be harvested directly from /dev:
-
-root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
-of=~/cstrace.bin
-
-64+0 records in
-64+0 records out
-32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
-root:/sys/bus/coresight/devices#
-
-The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
-
-Following is a DS-5 output of an experimental loop that increments a variable up
-to a certain value. The example is simple and yet provides a glimpse of the
-wealth of possibilities that coresight provides.
-
-Info Tracing enabled
-Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
-Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
-Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
-Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Timestamp Timestamp: 17106715833
-Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
-Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
-Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
-Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
-Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
-Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
-Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
-Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
-Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
-Info Tracing enabled
-Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
-Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
-Timestamp Timestamp: 17107041535
-
-How to use the STM module
--------------------------
-
-Using the System Trace Macrocell module is the same as the tracers - the only
-difference is that clients are driving the trace capture rather
-than the program flow through the code.
-
-As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
-
-root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root at genericarmv8:~#
-
-Like any other source a sink needs to be identified and the STM enabled before
-being used:
-
-root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
-root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
-
-From there user space applications can request and use channels using the devfs
-interface provided for that purpose by the generic STM API:
-
-root at genericarmv8:~# ls -l /dev/20100000.stm
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
-root at genericarmv8:~#
-
-Details on how to use the generic STM API can be found here [2].
-
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
diff --git a/Documentation/trace/coresight/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt
new file mode 100644
index 0000000..2b9b51c
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-cpu-debug.txt
@@ -0,0 +1,187 @@
+ Coresight CPU Debug Module
+ ==========================
+
+ Author: Leo Yan <leo.yan@linaro.org>
+ Date: April 5th, 2017
+
+Introduction
+------------
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--------------
+
+- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
+ registers to decide if sample-based profiling is implemented or not. On some
+ platforms this hardware feature is fully or partially implemented; and if
+ this feature is not supported then registration will fail.
+
+- At the time this documentation was written, the debug driver mainly relies on
+ information gathered by the kernel panic callback notifier from three
+ sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
+ program counter; EDVIDSR has information for secure state, exception level,
+ bit width, etc; EDCIDSR is context ID value which contains the sampled value
+ of CONTEXTIDR_EL1.
+
+- The driver supports a CPU running in either AArch64 or AArch32 mode. The
+ registers naming convention is a bit different between them, AArch64 uses
+ 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+ 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+ use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+ register bits definition. So the driver consolidates two difference:
+
+ If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
+ but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+ instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+ runs with ARM or thumb instruction set and calibrate PCSR value, the
+ detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+ C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+ If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+ no offset applied and do not sample the instruction set state in AArch32
+ state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+ in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+ state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+----------------------
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
+ +---------------+
+ | |
+ | |
+ +----------+--+ |
+ dbg_clock -->| |**| |<-- cpu_clock
+ | Debug |**| CPU |
+ dbg_power_domain -->| |**| |<-- cpu_power_domain
+ +----------+--+ |
+ | |
+ | |
+ +---------------+
+
+For debug domain, the user uses DT binding "clocks" and "power-domains" to
+specify the corresponding clock source and power supply for the debug logic.
+The driver calls the pm_runtime_{put|get} operations as needed to handle the
+debug power domain.
+
+For CPU domain, the different SoC designs have different power management
+schemes and finally this heavily impacts external debug module. So we can
+divide into below cases:
+
+- On systems with a sane power controller which can behave correctly with
+ respect to CPU power domain, the CPU power domain can be controlled by
+ register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ
+ to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
+ of CPU power down. As result, this can ensure the CPU power domain is
+ powered on properly during the period when access debug related registers;
+
+- Some designs will power down an entire cluster if all CPUs on the cluster
+ are powered down - including the parts of the debug registers that should
+ remain powered in the debug power domain. The bits in EDPRCR are not
+ respected in these cases, so these designs do not support debug over
+ power down in the way that the CoreSight / Debug designers anticipated.
+ This means that even checking EDPRSR has the potential to cause a bus hang
+ if the target register is unpowered.
+
+ In this case, accessing to the debug registers while they are not powered
+ is a recipe for disaster; so we need preventing CPU low power states at boot
+ time or when user enable module at the run time. Please see chapter
+ "How to use the module" for detailed usage info for this.
+
+
+Device Tree Bindings
+--------------------
+
+See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details.
+
+
+How to use the module
+---------------------
+
+If you want to enable debugging functionality@boot time, you can add
+"coresight_cpu_debug.enable=1" to the kernel command line parameter.
+
+The driver also can work as module, so can enable the debugging when insmod
+module:
+# insmod coresight_cpu_debug.ko debug=1
+
+When boot time or insmod module you have not enabled the debugging, the driver
+uses the debugfs file system to provide a knob to dynamically enable or disable
+debugging:
+
+To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
+# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
+
+To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
+# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
+
+As explained in chapter "Clock and power domain", if you are working on one
+platform which has idle states to power off debug logic and the power
+controller cannot work well for the request from EDPRCR, then you should
+firstly constraint CPU idle states before enable CPU debugging feature; so can
+ensure the accessing to debug logic.
+
+If you want to limit idle states at boot time, you can use "nohlt" or
+"cpuidle.off=1" in the kernel command line.
+
+At the runtime you can disable idle states with below methods:
+
+It is possible to disable CPU idle states by way of the PM QoS
+subsystem, more specifically by using the "/dev/cpu_dma_latency"
+interface (see Documentation/power/pm_qos_interface.txt for more
+details). As specified in the PM QoS documentation the requested
+parameter will stay in effect until the file descriptor is released.
+For example:
+
+# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
+...
+Do some work...
+...
+# exec 3<>-
+
+The same can also be done from an application program.
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
+# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
+
+
+Output format
+-------------
+
+Here is an example of the debugging output format:
+
+ARM external debug module:
+coresight-cpu-debug 850000.debug: CPU[0]:
+coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+coresight-cpu-debug 850000.debug: EDPCSR: [<ffff00000808e9bc>] handle_IPI+0x174/0x1d8
+coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
+coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
+coresight-cpu-debug 852000.debug: CPU[1]:
+coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+coresight-cpu-debug 852000.debug: EDPCSR: [<ffff0000087fab34>] debug_notifier_call+0x23c/0x358
+coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
+coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
diff --git a/Documentation/trace/coresight/coresight.txt b/Documentation/trace/coresight/coresight.txt
new file mode 100644
index 0000000..a33c88c
--- /dev/null
+++ b/Documentation/trace/coresight/coresight.txt
@@ -0,0 +1,332 @@
+ Coresight - HW Assisted Tracing on ARM
+ ======================================
+
+ Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ Date: September 11th, 2014
+
+Introduction
+------------
+
+Coresight is an umbrella of technologies allowing for the debugging of ARM
+based SoC. It includes solutions for JTAG and HW assisted tracing. This
+document is concerned with the latter.
+
+HW assisted tracing is becoming increasingly useful when dealing with systems
+that have many SoCs and other components like GPU and DMA engines. ARM has
+developed a HW assisted tracing solution by means of different components, each
+being added to a design at synthesis time to cater to specific tracing needs.
+Components are generally categorised as source, link and sinks and are
+(usually) discovered using the AMBA bus.
+
+"Sources" generate a compressed stream representing the processor instruction
+path based on tracing scenarios as configured by users. From there the stream
+flows through the coresight system (via ATB bus) using links that are connecting
+the emanating source to a sink(s). Sinks serve as endpoints to the coresight
+implementation, either storing the compressed stream in a memory buffer or
+creating an interface to the outside world where data can be transferred to a
+host without fear of filling up the onboard coresight memory buffer.
+
+At typical coresight system would look like this:
+
+ *****************************************************************
+ **************************** AMBA AXI ****************************===||
+ ***************************************************************** ||
+ ^ ^ | ||
+ | | * **
+ 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ ||||||||||||
+ 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System ||
+ |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory ||
+ | #######<-->: I : | #######<-->: I : : I : @@@<-| ||||||||||||
+ | # ETM # ::::: | # PTM # ::::: ::::: @ |
+ | ##### ^ ^ | ##### ^ ! ^ ! . | |||||||||
+ | |->### | ! | |->### | ! | ! . | || DAP ||
+ | | # | ! | | # | ! | ! . | |||||||||
+ | | . | ! | | . | ! | ! . | | |
+ | | . | ! | | . | ! | ! . | | *
+ | | . | ! | | . | ! | ! . | | SWD/
+ | | . | ! | | . | ! | ! . | | JTAG
+ *****************************************************************<-|
+ *************************** AMBA Debug APB ************************
+ *****************************************************************
+ | . ! . ! ! . |
+ | . * . * * . |
+ *****************************************************************
+ ******************** Cross Trigger Matrix (CTM) *******************
+ *****************************************************************
+ | . ^ . . |
+ | * ! * * |
+ *****************************************************************
+ ****************** AMBA Advanced Trace Bus (ATB) ******************
+ *****************************************************************
+ | ! =============== |
+ | * ===== F =====<---------|
+ | ::::::::: ==== U ====
+ |-->:: CTI ::<!! === N ===
+ | ::::::::: ! == N ==
+ | ^ * == E ==
+ | ! &&&&&&&&& IIIIIII == L ==
+ |------>&& ETB &&<......II I =======
+ | ! &&&&&&&&& II I .
+ | ! I I .
+ | ! I REP I<..........
+ | ! I I
+ | !!>&&&&&&&&& II I *Source: ARM ltd.
+ |------>& TPIU &<......II I DAP = Debug Access Port
+ &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell
+ ; PTM = Program Trace Macrocell
+ ; CTI = Cross Trigger Interface
+ * ETB = Embedded Trace Buffer
+ To trace port TPIU= Trace Port Interface Unit
+ SWD = Serial Wire Debug
+
+While on target configuration of the components is done via the APB bus,
+all trace data are carried out-of-band on the ATB bus. The CTM provides
+a way to aggregate and distribute signals between CoreSight components.
+
+The coresight framework provides a central point to represent, configure and
+manage coresight devices on a platform. This first implementation centers on
+the basic tracing functionality, enabling components such ETM/PTM, funnel,
+replicator, TMC, TPIU and ETB. Future work will enable more
+intricate IP blocks such as STM and CTI.
+
+
+Acronyms and Classification
+---------------------------
+
+Acronyms:
+
+PTM: Program Trace Macrocell
+ETM: Embedded Trace Macrocell
+STM: System trace Macrocell
+ETB: Embedded Trace Buffer
+ITM: Instrumentation Trace Macrocell
+TPIU: Trace Port Interface Unit
+TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
+TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
+CTI: Cross Trigger Interface
+
+Classification:
+
+Source:
+ ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM
+Link:
+ Funnel, replicator (intelligent or not), TMC-ETR
+Sinks:
+ ETBv1.0, ETB1.1, TPIU, TMC-ETF
+Misc:
+ CTI
+
+
+Device Tree Bindings
+----------------------
+
+See Documentation/devicetree/bindings/arm/coresight.txt for details.
+
+As of this writing drivers for ITM, STMs and CTIs are not provided but are
+expected to be added as the solution matures.
+
+
+Framework and implementation
+----------------------------
+
+The coresight framework provides a central point to represent, configure and
+manage coresight devices on a platform. Any coresight compliant device can
+register with the framework for as long as they use the right APIs:
+
+struct coresight_device *coresight_register(struct coresight_desc *desc);
+void coresight_unregister(struct coresight_device *csdev);
+
+The registering function is taking a "struct coresight_device *csdev" and
+register the device with the core framework. The unregister function takes
+a reference to a "struct coresight_device", obtained@registration time.
+
+If everything goes well during the registration process the new devices will
+show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
+
+root:~# ls /sys/bus/coresight/devices/
+replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+root:~#
+
+The functions take a "struct coresight_device", which looks like this:
+
+struct coresight_desc {
+ enum coresight_dev_type type;
+ struct coresight_dev_subtype subtype;
+ const struct coresight_ops *ops;
+ struct coresight_platform_data *pdata;
+ struct device *dev;
+ const struct attribute_group **groups;
+};
+
+
+The "coresight_dev_type" identifies what the device is, i.e, source link or
+sink while the "coresight_dev_subtype" will characterise that type further.
+
+The "struct coresight_ops" is mandatory and will tell the framework how to
+perform base operations related to the components, each component having
+a different set of requirement. For that "struct coresight_ops_sink",
+"struct coresight_ops_link" and "struct coresight_ops_source" have been
+provided.
+
+The next field, "struct coresight_platform_data *pdata" is acquired by calling
+"of_get_coresight_platform_data()", as part of the driver's _probe routine and
+"struct device *dev" gets the device reference embedded in the "amba_device":
+
+static int etm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ ...
+ ...
+ drvdata->dev = &adev->dev;
+ ...
+}
+
+Specific class of device (source, link, or sink) have generic operations
+that can be performed on them (see "struct coresight_ops"). The
+"**groups" is a list of sysfs entries pertaining to operations
+specific to that component only. "Implementation defined" customisations are
+expected to be accessed and controlled using those entries.
+
+Last but not least, "struct module *owner" is expected to be set to reflect
+the information carried in "THIS_MODULE".
+
+How to use the tracer modules
+-----------------------------
+
+Before trace collection can start, a coresight sink needs to be identify.
+There is no limit on the amount of sinks (nor sources) that can be enabled at
+any given moment. As a generic operation, all device pertaining to the sink
+class will have an "active" entry in sysfs:
+
+root:/sys/bus/coresight/devices# ls
+replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+root:/sys/bus/coresight/devices# ls 20010000.etb
+enable_sink status trigger_cntr
+root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
+root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
+1
+root:/sys/bus/coresight/devices#
+
+At boot time the current etm3x driver will configure the first address
+comparator with "_stext" and "_etext", essentially tracing any instruction
+that falls within that range. As such "enabling" a source will immediately
+trigger a trace capture:
+
+root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
+root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
+1
+root:/sys/bus/coresight/devices# cat 20010000.etb/status
+Depth: 0x2000
+Status: 0x1
+RAM read ptr: 0x0
+RAM wrt ptr: 0x19d3 <----- The write pointer is moving
+Trigger cnt: 0x0
+Control: 0x1
+Flush status: 0x0
+Flush ctrl: 0x2001
+root:/sys/bus/coresight/devices#
+
+Trace collection is stopped the same way:
+
+root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
+root:/sys/bus/coresight/devices#
+
+The content of the ETB buffer can be harvested directly from /dev:
+
+root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
+of=~/cstrace.bin
+
+64+0 records in
+64+0 records out
+32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
+root:/sys/bus/coresight/devices#
+
+The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
+
+Following is a DS-5 output of an experimental loop that increments a variable up
+to a certain value. The example is simple and yet provides a glimpse of the
+wealth of possibilities that coresight provides.
+
+Info Tracing enabled
+Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
+Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
+Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
+Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Timestamp Timestamp: 17106715833
+Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
+Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
+Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
+Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
+Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
+Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
+Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
+Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
+Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
+Info Tracing enabled
+Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
+Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
+Timestamp Timestamp: 17107041535
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source hwevent_select port_enable subsystem uevent
+hwevent_enable mgmt port_select traceid
+root at genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root at genericarmv8:~# ls -l /dev/20100000.stm
+crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
+root at genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 4641719..d7a6fc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1307,8 +1307,8 @@ M: Mathieu Poirier <mathieu.poirier@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/hwtracing/coresight/*
-F: Documentation/trace/coresight.txt
-F: Documentation/trace/coresight-cpu-debug.txt
+F: Documentation/trace/coresight/coresight.txt
+F: Documentation/trace/coresight/coresight-cpu-debug.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/6] Coresight: support panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
This patch set is to explore Coresight trace data for postmortem
debugging. When kernel panic happens, the Coresight panic kdump can
help save on-chip trace data and tracer metadata into DRAM, later
relies on kdump and crash/perf for "offline" analysis.
The documentation is important to understand the purpose of Coresight
panic kdump, the implementation and usage. Patches 0001/0002 are used
to relocate and add related documenation.
Patch 0003 introduces the simple panic kdump framework which can be
easily used by Coresight devices.
Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports
the dump for ETMv4. As Mathieu suggested, patch 0006 distinguish two
different tracer enabling mode: sysFS interface and perf mode.
This patch set have been verified on 96boards Hikey with tracer
enabling by sysFS interface.
Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
addition/deletion/updating separately for sysFS interface and perf
method.
Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
format compatible file.
* Refactored panic dump driver to support pre & post panic dump.
Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
functionality.
* Changed to use perf to analyse trace data.
Leo Yan (6):
doc: Add Coresight documentation directory
doc: Add documentation for Coresight panic kdump
coresight: Support panic kdump functionality
coresight: tmc: Hook callback for panic kdump
coresight: Add and delete sink callback for panic kdump list
coresight: etm4x: Support panic kdump
Documentation/trace/coresight-cpu-debug.txt | 187 ------------
Documentation/trace/coresight.txt | 332 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++++
.../trace/coresight/coresight-panic-kdump.txt | 91 ++++++
Documentation/trace/coresight/coresight.txt | 332 +++++++++++++++++++++
MAINTAINERS | 5 +-
drivers/hwtracing/coresight/Kconfig | 9 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 23 ++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +
.../hwtracing/coresight/coresight-panic-kdump.c | 154 ++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 13 +
drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 ++
drivers/hwtracing/coresight/coresight.c | 12 +
include/linux/coresight.h | 7 +
16 files changed, 887 insertions(+), 522 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102929.4755-1-stefan@agner.ch>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102929.4755-1-stefan@agner.ch>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC
From: Shawn Guo @ 2017-12-21 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206184844.uqbu6rmj4bponpuw@sirena.org.uk>
On Wed, Dec 06, 2017 at 06:48:44PM +0000, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 08:23:56AM +0100, Oleksij Rempel wrote:
> > 2017.12.06:
> > Adding Linus. Probably there is no maintainer for this patch set.
> > No changes are made, tested on v4.15-rc1.
>
> Have any of the i.MX maintainers said anything about this? I was about
> to reply to this asking if they were ever going to review it as it keeps
> on getting resent but I'm not seeing any interest from any of them but
> the main immediate audience is i.MX systems.
I will be happy to take the dts changes, after kernel/reboot and
regulator get accepted (ideally landed on mainline).
Shawn
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: exynos: config for v4.16
From: Krzysztof Kozlowski @ 2017-12-21 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-2-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.16
>
> for you to fetch changes up to 6b732dfb698991b5f518be1ddf329c1c2eb3d7cb:
>
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU (2017-12-14 18:57:38 +0100)
>
> ----------------------------------------------------------------
> Samsung defconfig changes for v4.16
>
> 1. Enable missing drivers for supported Exynos boards (PMU, CEC, MHL
> bridge, ASoC for Odroid XU3/XU4).
> 2. Enable Exynos IOMMU driver on exynos_defconfig.
>
> ----------------------------------------------------------------
> Marek Szyprowski (2):
> ARM: exynos_defconfig: Enable missing drivers for supported Exynos boards
> ARM: multi_v7_defconfig: Enable missing drivers for supported Exynos boards
>
> Shuah Khan (1):
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU
>
> arch/arm/configs/exynos_defconfig | 7 +++++++
> arch/arm/configs/multi_v7_defconfig | 5 +++++
> 2 files changed, 12 insertions(+)
I forgot to mention possible conflict for multi_v7_defconfig (with
changes coming from keystone tree). The resolution is to take
everything from both branches. Something like:
@@@ -558,7 -583,8 +559,9 @@@ CONFIG_VIDEO_STI_DELTA=
CONFIG_VIDEO_RENESAS_JPU=m
CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_V4L_TEST_DRIVERS=y
+CONFIG_VIDEO_VIVID=m
+ CONFIG_CEC_PLATFORM_DRIVERS=y
+ CONFIG_VIDEO_SAMSUNG_S5P_CEC=m
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_ML86V7667=m
@@@ -582,16 -613,12 +585,17 @@@ CONFIG_DRM_RCAR_DU=
CONFIG_DRM_RCAR_LVDS=y
CONFIG_DRM_SUN4I=m
CONFIG_DRM_TEGRA=y
+CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
-CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_NXP_PTN3460=m
+CONFIG_DRM_PARADE_PS8622=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_I2C_ADV7511_AUDIO=y
+ CONFIG_DRM_SII9234=m
CONFIG_DRM_STI=m
-CONFIG_DRM_VC4=y
+CONFIG_DRM_VC4=m
CONFIG_FB_ARMCLCD=y
CONFIG_FB_EFI=y
CONFIG_FB_WM8505=y
@@@ -626,9 -655,10 +630,10 @@@ CONFIG_SND_SOC_SAMSUNG=
CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994=m
CONFIG_SND_SOC_SMDK_WM8994_PCM=m
CONFIG_SND_SOC_SNOW=m
+ CONFIG_SND_SOC_ODROID=m
CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
-CONFIG_SND_SIMPLE_SCU_CARD=m
+CONFIG_SND_SOC_STI=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-21 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB12413F48FF7E083FD8E0FD36973D0@HE1PR04MB1241.eurprd04.prod.outlook.com>
Hi Rob,
> -----Original Message-----
> From: devicetree-owner at vger.kernel.org [mailto:devicetree-
> owner at vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> Sent: Tuesday, December 05, 2017 2:45 PM
> To: Rob Herring <robh@kernel.org>
> Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH][v3] dt-bindings: ifc: Update endianness usage
>
>
> > -----Original Message-----
> > From: Rob Herring [mailto:robh at kernel.org]
> > Sent: Tuesday, December 05, 2017 2:17 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> > shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
> >
> > On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > > IFC controller version < 2.0 support IFC register access as
> > > big endian. These controller version also require IFC NOR signals to
> > > be connected in reverse order with NOR flash.
> > >
> > > IFC >= 2.0 is other way around.
> > >
> > > So updating IFC binding to take care of both using endianness field.
> > >
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > > ---
> > > Changes for v2: updated subject
> > > Changes for v3: fixed typo for "big-endian"
> > >
> > > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6
> ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > index 89427b0..824a2ca 100644
> > > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > @@ -18,8 +18,10 @@ Properties:
> > > interrupt (NAND_EVTER_STAT). If there is only one,
> > > that interrupt reports both types of event.
> > >
> > > -- little-endian : If this property is absent, the big-endian mode will
> > > - be in use as default for registers.
> > > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > > + It also represents connection between controller and
> > > + NOR flash. If this property is absent, the big-endian
> > > + mode will be in use as default.
> >
> > My question on the prior version remains. I think if you need to handle
> > more than just register endianness, that should be done with the
> > compatible string.
> >
>
> I may not able to use compatible string as this information will also be used it
> drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
> I am trying to avoid controller specific details in generic file.
>
> This is the reason endianness property is being used.
>
Please let me know if I am not able to address your review comment
--prabhakar
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add memory node unit name
From: Lothar Waßmann @ 2017-12-21 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512575989-15627-1-git-send-email-marcofrk@gmail.com>
Hi,
On Wed, 6 Dec 2017 13:59:49 -0200 Marco Franchi wrote:
> Fix the following warnings from dtc by adding the unit name to memory
> nodes:
>
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>
> Converted using the following command:
>
> perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
>
> The files below were manually fixed:
> -imx1-ads.dts
> -imx1-apf9328.dts
>
The imx*.dtsi files all have this:
| memory { device_type = "memory"; reg = <0 0>; };
Thus you will end up with a 'memory' node with a reg = <0 0> entry and
an additional 'memory at ...' node with the correct 'reg' values.
Lothar Wa?mann
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: Specify interrupt-affinity for pmu node
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512462145-12664-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:22:25AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha@deif.com>
>
> From: Esben Haabendal <eha@deif.com>
Dropped the extra From line, fixed prefix and applied patch.
Shawn
>
> This avoids the warning
>
> hw perfevents: no interrupt-affinity property for /pmu, guessing.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> [RV: adapt commit log to the warning emitted in current mainline]
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> arch/arm/boot/dts/ls1021a.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 02a266faec9b..96dc1a29fc64 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -106,6 +106,7 @@
> compatible = "arm,cortex-a7-pmu";
> interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>;
> };
>
> reboot {
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: Add label to USB controllers
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512461794-12309-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:16:33AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Add usb2 and usb3 labels to USB2 and USB3 controller device tree nodes,
> for easier modification in board dts files.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Fixed prefix and applied the patch.
Shawn
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: add reboot node to .dtsi
From: Shawn Guo @ 2017-12-21 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512461568-12102-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:12:47AM +0100, Rasmus Villemoes wrote:
> The LS1021A can be reset via the dcfg regmap in the same way as the
> arm64 layerscape SoCs, so add the corresponding DT node.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
We use "ARM: ..." instead of "arm: ..." as prefix for DTS patches going
through i.MX tree.
I fixed prefix up and applied the patch.
Shawn
^ 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