* Re: [PATCH 4/4] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 2:16 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Masami Hiramatsu, H. Peter Anvin, Steven Rostedt, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566232996.v8nlwmnjqa.naveen@linux.ibm.com>
On Mon, 19 Aug 2019 22:22:12 +0530 "Naveen N. Rao" wrote:
>
>
> Jisheng Zhang wrote:
> > This patch implements KPROBES_ON_FTRACE for arm64.
> >
> > ~ # mount -t debugfs debugfs /sys/kernel/debug/
> > ~ # cd /sys/kernel/debug/
> > /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
> >
> > before the patch:
> >
> > /sys/kernel/debug # cat kprobes/list
> > ffffff801009ff7c k _do_fork+0x4 [DISABLED]
>
> This looks wrong -- we should not be allowing kprobe to be registered on
Yes. I made a mistake when dumping this log. The kernel isn't as clean
as "before the patch".
> ftrace address without KPROBES_ON_FTRACE. Is _do_fork+0x4 the location
> of ftrace entry on arm64?
Indeed, w/o KPROBES_ON_FTRACE, it should be _do_fork+0x0
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 2:05 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190820090130.844fc064030db67efb05ceb1@kernel.org>
On Tue, 20 Aug 2019 09:01:30 +0900 Masami Hiramatsu wrote:
>
> Hi Jisheng,
Hi,
>
> On Mon, 19 Aug 2019 11:36:09 +0000
> Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>
> > For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> > correspondingly.
>
> No, I think you have misunderstood what the ftrace_call_adjust() does.
> Ftrace's rec->ip is already adjusted when initializing it. Kprobes
> checks the list after initialized (adjusted). So you don't need to
> adjust it again.
This is not to adjust the ftarce's rec->ip, but to adjust the struct kprobe
addr member. Because check_kprobe_address_safe()=>arch_check_ftrace_location
will check the kprobe's addr with ftrace's rec->ip. Since ftrace's rec->ip
is already adjusted, there will be mismatch if we don't adjust kprobe's addr
correspondingly.
However, this patch is wrong. I should not update the kprobe's addr
for non-ftrace-entry. Will fix this in next version.
Thanks
>
> BTW, this type of hidden adjustment should be avoided by design.
> If you find user specifies wrong address, return error instead of
> adjust it silently.
>
> Thank you,
>
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > kernel/kprobes.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 9873fc627d61..f8400753a8a9 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> > addr = kprobe_addr(p);
> > if (IS_ERR(addr))
> > return PTR_ERR(addr);
> > +#ifdef CONFIG_KPROBES_ON_FTRACE
> > + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> > +#endif
> > p->addr = addr;
> >
> > ret = check_kprobe_rereg(p);
> > --
> > 2.23.0.rc1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] kprobes: move kprobe_ftrace_handler() from x86 and make it weak
From: Jisheng Zhang @ 2019-08-20 1:56 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190820090735.a55e7d0b685adecf68fdb55b@kernel.org>
On Tue, 20 Aug 2019 09:07:35 +0900 Masami Hiramatsu wrote:
>
>
> Hi Jisheng,
Hi,
>
> On Mon, 19 Aug 2019 11:37:32 +0000
> Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>
> > This code could be reused. So move it from x86 to common code.
>
> Yes, it can be among some arch, but at first, please make your
> architecture implementation. After making sure that is enough
> stable, we will optimize (consolidate) the code.
Got it. I will duplicate the function firstly then make the consolidation
as a TODO.
>
> For example,
> > - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
>
> This may depend on arch implementation of kprobes.
Indeed, for arm64, would be as simple as s/ip/pc.
Thanks
>
> Could you make a copy and update comments on arm64?
>
> Thank you,
>
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > arch/x86/kernel/kprobes/ftrace.c | 44 --------------------------------
> > kernel/kprobes.c | 44 ++++++++++++++++++++++++++++++++
> > 2 files changed, 44 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> > index c2ad0b9259ca..91ae1e3e65f7 100644
> > --- a/arch/x86/kernel/kprobes/ftrace.c
> > +++ b/arch/x86/kernel/kprobes/ftrace.c
> > @@ -12,50 +12,6 @@
> >
> > #include "common.h"
> >
> > -/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> > -void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> > - struct ftrace_ops *ops, struct pt_regs *regs)
> > -{
> > - struct kprobe *p;
> > - struct kprobe_ctlblk *kcb;
> > -
> > - /* Preempt is disabled by ftrace */
> > - p = get_kprobe((kprobe_opcode_t *)ip);
> > - if (unlikely(!p) || kprobe_disabled(p))
> > - return;
> > -
> > - kcb = get_kprobe_ctlblk();
> > - if (kprobe_running()) {
> > - kprobes_inc_nmissed_count(p);
> > - } else {
> > - unsigned long orig_ip = instruction_pointer(regs);
> > - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> > -
> > - __this_cpu_write(current_kprobe, p);
> > - kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> > - if (!p->pre_handler || !p->pre_handler(p, regs)) {
> > - /*
> > - * Emulate singlestep (and also recover regs->ip)
> > - * as if there is a 5byte nop
> > - */
> > - instruction_pointer_set(regs,
> > - (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> > - if (unlikely(p->post_handler)) {
> > - kcb->kprobe_status = KPROBE_HIT_SSDONE;
> > - p->post_handler(p, regs, 0);
> > - }
> > - instruction_pointer_set(regs, orig_ip);
> > - }
> > - /*
> > - * If pre_handler returns !0, it changes regs->ip. We have to
> > - * skip emulating post_handler.
> > - */
> > - __this_cpu_write(current_kprobe, NULL);
> > - }
> > -}
> > -NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> > -
> > int arch_prepare_kprobe_ftrace(struct kprobe *p)
> > {
> > p->ainsn.insn = NULL;
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index f8400753a8a9..479148ee1822 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -960,6 +960,50 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> > #endif /* CONFIG_OPTPROBES */
> >
> > #ifdef CONFIG_KPROBES_ON_FTRACE
> > +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> > +void __weak kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> > + struct ftrace_ops *ops, struct pt_regs *regs)
> > +{
> > + struct kprobe *p;
> > + struct kprobe_ctlblk *kcb;
> > +
> > + /* Preempt is disabled by ftrace */
> > + p = get_kprobe((kprobe_opcode_t *)ip);
> > + if (unlikely(!p) || kprobe_disabled(p))
> > + return;
> > +
> > + kcb = get_kprobe_ctlblk();
> > + if (kprobe_running()) {
> > + kprobes_inc_nmissed_count(p);
> > + } else {
> > + unsigned long orig_ip = instruction_pointer(regs);
> > + /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> > +
> > + __this_cpu_write(current_kprobe, p);
> > + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> > + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> > + /*
> > + * Emulate singlestep (and also recover regs->ip)
> > + * as if there is a 5byte nop
> > + */
> > + instruction_pointer_set(regs,
> > + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> > + if (unlikely(p->post_handler)) {
> > + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> > + p->post_handler(p, regs, 0);
> > + }
> > + instruction_pointer_set(regs, orig_ip);
> > + }
> > + /*
> > + * If pre_handler returns !0, it changes regs->ip. We have to
> > + * skip emulating post_handler.
> > + */
> > + __this_cpu_write(current_kprobe, NULL);
> > + }
> > +}
> > +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> > +
> > static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> > .func = kprobe_ftrace_handler,
> > .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> > --
> > 2.23.0.rc1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: imx8mn: fix audio pll setting
From: Peng Fan @ 2019-08-20 1:55 UTC (permalink / raw)
To: mturquette@baylibre.com, sboyd@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com
Cc: Peng Fan, Jacky Bai, Anson Huang, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
From: Peng Fan <peng.fan@nxp.com>
The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index c5838710e1d8..0e7fb39bcb44 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -51,8 +51,8 @@ static const struct imx_pll14xx_rate_table imx8mn_pll1416x_tbl[] = {
};
static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
- PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
- PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
};
static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 1:51 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Masami Hiramatsu, H. Peter Anvin, Steven Rostedt, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566232801.derqq08wxh.naveen@linux.ibm.com>
On Mon, 19 Aug 2019 22:13:02 +0530 "Naveen N. Rao" wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Jisheng Zhang wrote:
> > For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> > correspondingly.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > kernel/kprobes.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 9873fc627d61..f8400753a8a9 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> > addr = kprobe_addr(p);
> > if (IS_ERR(addr))
> > return PTR_ERR(addr);
> > +#ifdef CONFIG_KPROBES_ON_FTRACE
> > + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> > +#endif
> > p->addr = addr;
>
> I'm not sure what this is achieving, but looks wrong to me.
Indeed, I didn't take care of non-ftrace addr when KPROBES_ON_FTRACE, will
update in next version.
thanks
>
> If you intend to have kprobes default to using ftrace entry for probing
> functions, consider over-riding kprobe_lookup_name() -- see powerpc
> variant for example.
>
>
> - Naveen
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Build regression in Linux 5.3-rc5 with CONFIG_XEN=y
From: Christoph Hellwig @ 2019-08-20 1:24 UTC (permalink / raw)
To: Stefan Wahren
Cc: iommu, Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <0b019cdc-6f0e-c37f-2be7-c24293acb8cd@gmx.net>
Hi Stefan,
please try the patch below.
---
From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 20 Aug 2019 10:08:38 +0900
Subject: arm: select the dma-noncoherent symbols for all swiotlb builds
We need to provide the arch hooks for non-coherent dma-direct
and swiotlb for all swiotlb builds, not just when LPAS is enabled.
Without that the Xen build that selects SWIOTLB indirectly through
SWIOTLB_XEN fails to build.
Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Reported-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/Kconfig | 4 ++++
arch/arm/mm/Kconfig | 4 ----
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..24360211534a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,8 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
+ select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
@@ -18,6 +20,8 @@ config ARM
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
+ select ARCH_HAS_SYNC_DMA_FOR_DEVICE if SWIOTLB
+ select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB
select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c54cd7ed90ba..c1222c0e9fd3 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -664,10 +664,6 @@ config ARM_LPAE
!CPU_32v4 && !CPU_32v3
select PHYS_ADDR_T_64BIT
select SWIOTLB
- select ARCH_HAS_DMA_COHERENT_TO_PFN
- select ARCH_HAS_DMA_MMAP_PGPROT
- select ARCH_HAS_SYNC_DMA_FOR_DEVICE
- select ARCH_HAS_SYNC_DMA_FOR_CPU
help
Say Y if you have an ARMv7 processor supporting the LPAE page
table format and you would like to access memory beyond the
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] perf cs-etm: Support sample flags 'insn' and 'insnlen'
From: Leo Yan @ 2019-08-20 1:12 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Coresight ML, Linux Kernel Mailing List, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190819185054.GB3929@kernel.org>
On Mon, Aug 19, 2019 at 03:50:54PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 19, 2019 at 12:08:26PM -0600, Mathieu Poirier escreveu:
> > On Thu, 15 Aug 2019 at 02:30, Leo Yan <leo.yan@linaro.org> wrote:
> > >
> > > The synthetic branch and instruction samples are missed to set
> > > instruction related info, thus perf tool fails to display samples with
> > > flags '-F,+insn,+insnlen'.
> > >
> > > CoreSight trace decoder has provided sufficient information to decide
> > > the instruction size based on the isa type: A64/A32 instruction are
> > > 32-bit size, but one exception is the T32 instruction size, which might
> > > be 32-bit or 16-bit.
> > >
> > > This patch handles for these cases and it reads the instruction values
> > > from DSO file; thus can support flags '-F,+insn,+insnlen'.
>
> > The code seems to be correct. I have also tested this patch.
>
> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Thanks, applied.
Thanks a lot, Mathieu & Arnaldo.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] kprobes/x86: use instruction_pointer and instruction_pointer_set
From: Masami Hiramatsu @ 2019-08-20 0:09 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192543.32cec143@xhacker.debian>
On Mon, 19 Aug 2019 11:36:48 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> This is to make the kprobe_ftrace_handler() common, so we can move it
> to common code in next patch.
>
BTW, this patch looks good, without next patch. Could you update the
patch description and resend it with my Ack?
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> arch/x86/kernel/kprobes/ftrace.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> index 681a4b36e9bb..c2ad0b9259ca 100644
> --- a/arch/x86/kernel/kprobes/ftrace.c
> +++ b/arch/x86/kernel/kprobes/ftrace.c
> @@ -28,9 +28,9 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> if (kprobe_running()) {
> kprobes_inc_nmissed_count(p);
> } else {
> - unsigned long orig_ip = regs->ip;
> + unsigned long orig_ip = instruction_pointer(regs);
> /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - regs->ip = ip + sizeof(kprobe_opcode_t);
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
>
> __this_cpu_write(current_kprobe, p);
> kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> @@ -39,12 +39,13 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> * Emulate singlestep (and also recover regs->ip)
> * as if there is a 5byte nop
> */
> - regs->ip = (unsigned long)p->addr + MCOUNT_INSN_SIZE;
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> if (unlikely(p->post_handler)) {
> kcb->kprobe_status = KPROBE_HIT_SSDONE;
> p->post_handler(p, regs, 0);
> }
> - regs->ip = orig_ip;
> + instruction_pointer_set(regs, orig_ip);
> }
> /*
> * If pre_handler returns !0, it changes regs->ip. We have to
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] kprobes: move kprobe_ftrace_handler() from x86 and make it weak
From: Masami Hiramatsu @ 2019-08-20 0:07 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192628.5f550074@xhacker.debian>
Hi Jisheng,
On Mon, 19 Aug 2019 11:37:32 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> This code could be reused. So move it from x86 to common code.
Yes, it can be among some arch, but at first, please make your
architecture implementation. After making sure that is enough
stable, we will optimize (consolidate) the code.
For example,
> - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
This may depend on arch implementation of kprobes.
Could you make a copy and update comments on arm64?
Thank you,
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> arch/x86/kernel/kprobes/ftrace.c | 44 --------------------------------
> kernel/kprobes.c | 44 ++++++++++++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 44 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> index c2ad0b9259ca..91ae1e3e65f7 100644
> --- a/arch/x86/kernel/kprobes/ftrace.c
> +++ b/arch/x86/kernel/kprobes/ftrace.c
> @@ -12,50 +12,6 @@
>
> #include "common.h"
>
> -/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> -void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> - struct ftrace_ops *ops, struct pt_regs *regs)
> -{
> - struct kprobe *p;
> - struct kprobe_ctlblk *kcb;
> -
> - /* Preempt is disabled by ftrace */
> - p = get_kprobe((kprobe_opcode_t *)ip);
> - if (unlikely(!p) || kprobe_disabled(p))
> - return;
> -
> - kcb = get_kprobe_ctlblk();
> - if (kprobe_running()) {
> - kprobes_inc_nmissed_count(p);
> - } else {
> - unsigned long orig_ip = instruction_pointer(regs);
> - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> -
> - __this_cpu_write(current_kprobe, p);
> - kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> - if (!p->pre_handler || !p->pre_handler(p, regs)) {
> - /*
> - * Emulate singlestep (and also recover regs->ip)
> - * as if there is a 5byte nop
> - */
> - instruction_pointer_set(regs,
> - (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> - if (unlikely(p->post_handler)) {
> - kcb->kprobe_status = KPROBE_HIT_SSDONE;
> - p->post_handler(p, regs, 0);
> - }
> - instruction_pointer_set(regs, orig_ip);
> - }
> - /*
> - * If pre_handler returns !0, it changes regs->ip. We have to
> - * skip emulating post_handler.
> - */
> - __this_cpu_write(current_kprobe, NULL);
> - }
> -}
> -NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> -
> int arch_prepare_kprobe_ftrace(struct kprobe *p)
> {
> p->ainsn.insn = NULL;
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index f8400753a8a9..479148ee1822 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -960,6 +960,50 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> #endif /* CONFIG_OPTPROBES */
>
> #ifdef CONFIG_KPROBES_ON_FTRACE
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void __weak kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t *)ip);
> + if (unlikely(!p) || kprobe_disabled(p))
> + return;
> +
> + kcb = get_kprobe_ctlblk();
> + if (kprobe_running()) {
> + kprobes_inc_nmissed_count(p);
> + } else {
> + unsigned long orig_ip = instruction_pointer(regs);
> + /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> +
> + __this_cpu_write(current_kprobe, p);
> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> + /*
> + * Emulate singlestep (and also recover regs->ip)
> + * as if there is a 5byte nop
> + */
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> + if (unlikely(p->post_handler)) {
> + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> + p->post_handler(p, regs, 0);
> + }
> + instruction_pointer_set(regs, orig_ip);
> + }
> + /*
> + * If pre_handler returns !0, it changes regs->ip. We have to
> + * skip emulating post_handler.
> + */
> + __this_cpu_write(current_kprobe, NULL);
> + }
> +}
> +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> +
> static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> .func = kprobe_ftrace_handler,
> .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 02/11] dt-bindings: power: amlogic, meson-gx-pwrc: Add SM1 bindings
From: Kevin Hilman @ 2019-08-20 0:05 UTC (permalink / raw)
To: Martin Blumenstingl, Neil Armstrong
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
jbrunet
In-Reply-To: <CAFBinCAT1JaK6ksD9OzCK_wEEWJdaZL2vLzGeCzVVbz9V67btQ@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> Hi Neil,
>
> On Mon, Jul 1, 2019 at 12:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
> [...]
>> +General Purpose Power Controller
>> +--------------------------------
>>
>> +The Amlogic SM1 SoCs embeds a General Purpose Power Controller used
>> +to control the power domain for, at least, the USB PHYs and PCIe
>> +peripherals.
> AFAIK each binding document should only describe one IP block.
> this one seems to be new / different
>
> should it get it's own file?
> also should it be a .yaml binding?
I don't think this is a new IP block. Comparing across the various
(64-bit) SoCs, it seems to be very similar across all SoCs.
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +Required properties:
>> +- compatible: should be one of the following :
>> + - "amlogic,meson-sm1-pwrc" for the Meson SM1 SoCs
>> +- #power-domain-cells: should be 0
>> +- amlogic,hhi-sysctrl: phandle to the HHI sysctrl node
>> +
>> +Parent node should have the following properties :
>> +- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"
>> +- reg: base address and size of the AO system control register space.
>> +
>> +
>> +Example:
>> +-------
>> +
>> +ao_sysctrl: sys-ctrl@0 {
>> + compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd";
>> + reg = <0x0 0x0 0x0 0x100>;
>> +
>> + pwrc: power-controller {
>> + compatible = "amlogic,meson-sm1-pwrc";
>> + #power-domain-cells = <1>;
>> + amlogic,hhi-sysctrl = <&hhi>;
>> + };
>> +};
>
> I'm not sure that we want to mix HHI and AO power domains in one driver again
We're not mixing here. These are all EE domains. They just have some
control registers in the AO memory region.
> back in March I asked a few questions about modelling the power
> domains and Kevin explained that we can implement them hierarchical:
> [0]
> unfortunately I didn't have the time to work on this - however, now
> that we implement a new driver: should we follow this hierarchical
> approach?
The more I look at this, I don't think we have a commpelling need to
model them hierarchically. The main reason being is that of the 3
top-level domains I listed[0], we can only managing the EE domains in the
kernel. It doesn't make sense to model/manage AO domains because, well,
they are always-on (AO). The CPU domains are managed my the PSCI
firmware, and we don't/won't have any control over that.
For that reason, I think it makes the most sense to have a generic
driver that handles all the EE domains.
IMO, the SM1 driver that Neil wrote in patch 4 of this series is 80%
there. If we generalize that little more, it can be quite easily used
for all the EE domains.
Kevin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2019-March/010512.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Masami Hiramatsu @ 2019-08-20 0:01 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192505.483c0bf0@xhacker.debian>
Hi Jisheng,
On Mon, 19 Aug 2019 11:36:09 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> correspondingly.
No, I think you have misunderstood what the ftrace_call_adjust() does.
Ftrace's rec->ip is already adjusted when initializing it. Kprobes
checks the list after initialized (adjusted). So you don't need to
adjust it again.
BTW, this type of hidden adjustment should be avoided by design.
If you find user specifies wrong address, return error instead of
adjust it silently.
Thank you,
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> kernel/kprobes.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 9873fc627d61..f8400753a8a9 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> addr = kprobe_addr(p);
> if (IS_ERR(addr))
> return PTR_ERR(addr);
> +#ifdef CONFIG_KPROBES_ON_FTRACE
> + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> +#endif
> p->addr = addr;
>
> ret = check_kprobe_rereg(p);
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 04/11] soc: amlogic: Add support for SM1 power controller
From: Kevin Hilman @ 2019-08-19 23:56 UTC (permalink / raw)
To: Neil Armstrong, jbrunet
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190701104705.18271-5-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add support for the General Purpose Amlogic SM1 Power controller,
> dedicated to the PCIe, USB, NNA and GE2D Power Domains.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
I like this driver in general, but as I look at all the EE power domains
for GX, G12 and SM1 they are really very similar. I had started to
generalize the gx-pwrc-vpu driver and it ends up looking just like this.
I think this driver could be generalized just a little bit more and then
replace the the GX-specific VPU one, and AFAICT, then be used across all
the 64-bit SoCs, and be called "meson-pwrc-ee" or something like that...
> ---
> drivers/soc/amlogic/Kconfig | 11 ++
> drivers/soc/amlogic/Makefile | 1 +
> drivers/soc/amlogic/meson-sm1-pwrc.c | 245 +++++++++++++++++++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/soc/amlogic/meson-sm1-pwrc.c
>
> diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
> index 5501ad5650b2..596f1afef1a7 100644
> --- a/drivers/soc/amlogic/Kconfig
> +++ b/drivers/soc/amlogic/Kconfig
> @@ -36,6 +36,17 @@ config MESON_GX_PM_DOMAINS
> Say yes to expose Amlogic Meson GX Power Domains as
> Generic Power Domains.
>
> +config MESON_SM1_PM_DOMAINS
> + bool "Amlogic Meson SM1 Power Domains driver"
> + depends on ARCH_MESON || COMPILE_TEST
> + depends on PM && OF
> + default ARCH_MESON
> + select PM_GENERIC_DOMAINS
> + select PM_GENERIC_DOMAINS_OF
> + help
> + Say yes to expose Amlogic Meson SM1 Power Domains as
> + Generic Power Domains.
> +
> config MESON_MX_SOCINFO
> bool "Amlogic Meson MX SoC Information driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
> index bf2d109f61e9..f99935499ee6 100644
> --- a/drivers/soc/amlogic/Makefile
> +++ b/drivers/soc/amlogic/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_MESON_CLK_MEASURE) += meson-clk-measure.o
> obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
> obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
> obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
> +obj-$(CONFIG_MESON_SM1_PM_DOMAINS) += meson-sm1-pwrc.o
> diff --git a/drivers/soc/amlogic/meson-sm1-pwrc.c b/drivers/soc/amlogic/meson-sm1-pwrc.c
> new file mode 100644
> index 000000000000..9ece1d06f417
> --- /dev/null
> +++ b/drivers/soc/amlogic/meson-sm1-pwrc.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2017 BayLibre, SAS
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + */
> +
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/bitfield.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <dt-bindings/power/meson-sm1-power.h>
> +
> +/* AO Offsets */
> +
> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
> +
> +/* HHI Offsets */
> +
> +#define HHI_MEM_PD_REG0 (0x40 << 2)
> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
> +
> +struct meson_sm1_pwrc;
> +
> +struct meson_sm1_pwrc_mem_domain {
> + unsigned int reg;
> + unsigned int mask;
> +};
> +
> +struct meson_sm1_pwrc_domain_desc {
> + char *name;
> + unsigned int sleep_reg;
> + unsigned int sleep_bit;
> + unsigned int iso_reg;
> + unsigned int iso_bit;
> + unsigned int mem_pd_count;
> + struct meson_sm1_pwrc_mem_domain *mem_pd;
> +};
If you add resets and clocks (using clk bulk like my other proposed
patch to gx-pwrc-vpu) then this could be used for VPU also. We could
ignore my clk bulk patch and then just deprecate the old driver and use
this one for everything.
We would just need SoC-specific tables selected by compatible-string to
select the memory pds, and the clocks and resets could (optionaly) come
from the DT.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
From: Chanwoo Choi @ 2019-08-19 23:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kukjin Kim, Vladimir Zapolskiy,
Kamil Konieczny, Herbert Xu, David S. Miller, Sylwester Nawrocki,
Tomasz Figa, Michael Turquette, Stephen Boyd, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-crypto, linux-clk,
cpgs (cpgs@samsung.com)
In-Reply-To: <20190818172750.20921-1-krzk@kernel.org>
Hi Krzysztof,
On 19. 8. 19. 오전 2:27, Krzysztof Kozlowski wrote:
> Extend the patterns to cover all related files in respective
> categories:
> 1. Samsung Exynos ARM architecture: add soc drivers headers and make
> directory matches consistent,
> 2. Samsung Security SubSystem driver (crypto): add bindings,
> 3. Samsung SoC clock drivers: add S3C24xx, S3C64xx and S5Pv210 bindings.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Kamil Konieczny <k.konieczny@partner.samsung.com>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> ---
> MAINTAINERS | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 420567d1519a..35a4002ac58b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2199,8 +2199,9 @@ F: drivers/*/*s3c24*
> F: drivers/*/*/*s3c24*
> F: drivers/*/*s3c64xx*
> F: drivers/*/*s5pv210*
> -F: drivers/memory/samsung/*
> -F: drivers/soc/samsung/*
> +F: drivers/memory/samsung/
> +F: drivers/soc/samsung/
> +F: include/linux/soc/samsung/
> F: Documentation/arm/samsung/
> F: Documentation/devicetree/bindings/arm/samsung/
> F: Documentation/devicetree/bindings/sram/samsung-sram.txt
> @@ -14174,6 +14175,8 @@ M: Kamil Konieczny <k.konieczny@partner.samsung.com>
> L: linux-crypto@vger.kernel.org
> L: linux-samsung-soc@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/crypto/samsung-slimsss.txt
> +F: Documentation/devicetree/bindings/crypto/samsung-sss.txt
> F: drivers/crypto/s5p-sss.c
>
> SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
> @@ -14194,6 +14197,8 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
> F: drivers/clk/samsung/
> F: include/dt-bindings/clock/exynos*.h
> F: Documentation/devicetree/bindings/clock/exynos*.txt
> +F: Documentation/devicetree/bindings/clock/samsung,s3c*
> +F: Documentation/devicetree/bindings/clock/samsung,s5p*
>
> SAMSUNG SPI DRIVERS
> M: Kukjin Kim <kgene@kernel.org>
>
For clock part,
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Chanwoo Choi @ 2019-08-19 23:44 UTC (permalink / raw)
To: Leonard Crestez, Artur Świgoń, georgi.djakov@linaro.org,
Viresh Kumar
Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Saravana Kannan, linux-pm@vger.kernel.org, Rafael J. Wysocki,
sw0312.kim@samsung.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Lukasz Luba,
inki.dae@samsung.com, myungjoo.ham@samsung.com, krzk@kernel.org,
cpgs (cpgs@samsung.com), linux-arm-kernel@lists.infradead.org,
m.szyprowski@samsung.com
In-Reply-To: <VI1PR04MB7023B5095F706635354C4C50EED70@VI1PR04MB7023.eurprd04.prod.outlook.com>
Hi Artur and Leonard,
On 19. 8. 9. 오전 12:00, Leonard Crestez wrote:
> On 29.07.2019 04:49, Chanwoo Choi wrote:
>> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The devfreq target() callback provided by exynos-bus now selects either the
>>> frequency calculated by the devfreq governor or the frequency requested via
>>> the interconnect API for the given node, whichever is higher.
>>
>> Basically, I agree to support the QoS requirement between devices.
>> But, I think that need to consider the multiple cases.
>>
>> 1. When changing the devfreq governor by user,
>> For example of the connection between bus_dmc/leftbus/display on patch8,
>> there are possible multiple cases with various devfreq governor
>> which is changed on the runtime by user through sysfs interface.
>>
>> If users changes the devfreq governor as following:
>> Before,
>> - bus_dmc (simple_ondemand, available frequency 100/200/300/400 MHz)
>> --> bus_leftbus(simple_ondemand, available frequency 100/200/300/400 MHz)
>> ----> bus_display(passive)
>>
>> After changed governor of bus_dmc,
>> if the min_freq by interconnect requirement is 400Mhz,
>> - bus_dmc (powersave) : min_freq and max_freq and cur_freq is 100MHz
>> --> bus_leftbus(simple_ondemand) : cur_freq is 400Mhz
>> ----> bus_display(passive)
>>
>> The final frequency is 400MHz of bus_dmc
>> even if the min_freq/max_freq/cur_freq is 100MHz.
>> It cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>>
>> 2. When disabling the some frequency by devfreq-thermal throttling,
>> This patch checks the min_freq of interconnect requirement
>> in the exynos_bus_target() and exynos_bus_passive_target().
>> Also, it cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>> For example of bus_dmc bus,
>> - The available frequencies are 100MHz, 200MHz, 300MHz, 400MHz
>> - Disable 400MHz by devfreq-thermal throttling
>> - min_freq is 100MHz
>> - max_freq is 300MHz
>> - min_freq of interconnect is 400MHz
>>
>> In result, the final frequency is 400MHz by exynos_bus_target()
>> There are no problem for working. But, the user cannot know
>> reason why cur_freq is 400MHz even if max_freq is 300MHz.
>>
>> Basically, update_devfreq() considers the all constraints
>> of min_freq/max_freq to decide the proper target frequency.
>
> I think that applying the interconnect min_freq via dev_pm_qos can help
> with many of these concerns: update_devfreq controls all the min/max
> handling, sysfs is accurate and better decisions can be made regarding
> thermal. Enforcing constraints in the core is definitely better.
>
> This wouldn't even be a very big change, you don't need to actually move
> the interconnect code outside of devfreq. Just make every devfreq/icc
> node register a dev_pm_qos_request for itself during registration and
> call dev_pm_qos_update_request inside exynos_bus_icc_set.
>
> See: https://patchwork.kernel.org/patch/11084279/
I agree this approach of Leonard. If we use the dev_pm_qos[1] feature,
it resolve the issue of my comment1/2.
In summary, when receive the minimum frequency requirement
from interconnect path, the each bus uses the dev_pm_qos interface
in order to inform the minimum frequency from interconnect to devfreq.
And then the devfreq core will execute the update_devfreq()
with all frequency requirements as following:
- the user input (min/max frequency though devfreq sysfs
- the target frequency provided by devfreq governor
- the minimum frequency from interconnect path
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/8] soc: ti: Add OMAP PRM driver
From: Suman Anna @ 2019-08-19 23:20 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
Hi Tero,
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Hi,
>
> This series adds OMAP PRM driver which initially supports only reset
> handling. Later on, power domain support can be added to this to get
> rid of the current OMAP power domain handling code which resides
> under the mach-omap2 platform directory. Initially, reset data is
> added for AM3, OMAP4 and DRA7 SoCs.
Wakeup M3 remoteproc driver is fully upstream, so we should be able to
test that driver as well if you can add the AM4 data. That will also
unblock my PRUSS.
If you can add the data to others as well, it will help in easier
migration of the individual drivers, otherwise the ti-sysc interconnect,
hwmod, and hwmod reset data combinations will all have to be supported
in code.
regards
Suman
>
> I've been testing the reset handling logic with OMAP remoteproc
> driver which has been converted to use generic reset framework. This
> part is a work in progress, so will be posting patches from that part
> later on.
>
> -Tero
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/8] soc: ti: omap-prm: add support for denying idle for reset clockdomain
From: Suman Anna @ 2019-08-19 23:16 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-5-git-send-email-t-kristo@ti.com>
Hi Tero,
On 8/7/19 2:48 AM, Tero Kristo wrote:
> TI SoCs hardware reset signals require the parent clockdomain to be
> in force wakeup mode while de-asserting the reset, otherwise it may
> never complete. To support this, add pdata hooks to control the
> clockdomain directly.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 32 ++++++++++++++++++++++++++++----
> include/linux/platform_data/ti-prm.h | 21 +++++++++++++++++++++
> 2 files changed, 49 insertions(+), 4 deletions(-)
> create mode 100644 include/linux/platform_data/ti-prm.h
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index d412af3..870515e3 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -16,6 +16,8 @@
> #include <linux/reset-controller.h>
> #include <linux/delay.h>
>
> +#include <linux/platform_data/ti-prm.h>
> +
> struct omap_rst_map {
> s8 rst;
> s8 st;
> @@ -24,6 +26,7 @@ struct omap_rst_map {
> struct omap_prm_data {
> u32 base;
> const char *name;
> + const char *clkdm_name;
> u16 pwstctrl;
> u16 pwstst;
> u16 rstctl;
> @@ -40,6 +43,8 @@ struct omap_prm {
> struct omap_reset_data {
> struct reset_controller_dev rcdev;
> struct omap_prm *prm;
> + struct clockdomain *clkdm;
> + struct device *dev;
> };
>
> #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
> @@ -108,6 +113,8 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> int st_bit = id;
> bool has_rstst;
> int timeout = 0;
> + struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
> + int ret = 0;
>
> /* check the current status to avoid de-asserting the line twice */
> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
> @@ -125,13 +132,16 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
> }
>
> + if (pdata->clkdm_deny_idle && reset->clkdm)
> + pdata->clkdm_deny_idle(reset->clkdm);
> +
> /* de-assert the reset control line */
> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
> v &= ~(1 << id);
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>
> if (!has_rstst)
> - return 0;
> + goto exit;
>
> /* wait for the status to be set */
> while (1) {
> @@ -140,13 +150,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> if (v)
> break;
> timeout++;
> - if (timeout > OMAP_RESET_MAX_WAIT)
> - return -EBUSY;
> + if (timeout > OMAP_RESET_MAX_WAIT) {
> + ret = -EBUSY;
> + goto exit;
> + }
>
> udelay(1);
> }
>
> - return 0;
> +exit:
> + if (pdata->clkdm_allow_idle && reset->clkdm)
> + pdata->clkdm_allow_idle(reset->clkdm);
> +
> + return ret;
> }
>
> static const struct reset_control_ops omap_reset_ops = {
> @@ -159,6 +175,8 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
> struct omap_prm *prm)
> {
> struct omap_reset_data *reset;
> + struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
Please add checks for NULL callbacks. I don't think these are optional
right, so better to check in init rather than during runtime. Granted
you will probably not run into this after patch 8, but would be good to
check and print an error in case pdata quirks is missed out.
> + char buf[32];
>
> /*
> * Check if we have resets. If either rstctl or rstst is
> @@ -177,9 +195,15 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
> reset->rcdev.ops = &omap_reset_ops;
> reset->rcdev.of_node = pdev->dev.of_node;
> reset->rcdev.nr_resets = OMAP_MAX_RESETS;
> + reset->dev = &pdev->dev;
>
> reset->prm = prm;
>
> + sprintf(buf, "%s_clkdm", prm->data->clkdm_name ? prm->data->clkdm_name :
> + prm->data->name);
> +
> + reset->clkdm = pdata->clkdm_lookup(buf);
Not checking return status?
regards
Suman
> +
> return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
> }
>
> diff --git a/include/linux/platform_data/ti-prm.h b/include/linux/platform_data/ti-prm.h
> new file mode 100644
> index 0000000..28154c3
> --- /dev/null
> +++ b/include/linux/platform_data/ti-prm.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * TI PRM (Power & Reset Manager) platform data
> + *
> + * Copyright (C) 2019 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo@ti.com>
> + */
> +
> +#ifndef _LINUX_PLATFORM_DATA_TI_PRM_H
> +#define _LINUX_PLATFORM_DATA_TI_PRM_H
> +
> +struct clockdomain;
> +
> +struct ti_prm_platform_data {
> + void (*clkdm_deny_idle)(struct clockdomain *clkdm);
> + void (*clkdm_allow_idle)(struct clockdomain *clkdm);
> + struct clockdomain * (*clkdm_lookup)(const char *name);
> +};
> +
> +#endif /* _LINUX_PLATFORM_DATA_TI_PRM_H */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] soc: ti: omap-prm: add dra7 PRM data
From: Suman Anna @ 2019-08-19 23:12 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-8-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM data for dra7 family of SoCs.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index fadfc7f..05b7749 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -73,6 +73,31 @@ struct omap_prm_data omap4_prm_data[] = {
> { },
> };
>
> +static struct omap_prm_data dra7_prm_data[] = {
Same comment as on other data, static const.
regards
Suman
> + { .name = "mpu", .base = 0x4ae06300, .pwstst = 0x4 },
> + { .name = "dsp1", .base = 0x4ae06400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "ipu", .base = 0x4ae06500, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14, .clkdm_name = "ipu1" },
> + { .name = "coreaon", .base = 0x4ae06628, .pwstst = 0x4 },
> + { .name = "core", .base = 0x4ae06700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214, .clkdm_name = "ipu2" },
> + { .name = "iva", .base = 0x4ae06f00, .pwstst = 0x4 },
> + { .name = "cam", .base = 0x4ae07000, .pwstst = 0x4 },
> + { .name = "dss", .base = 0x4ae07100, .pwstst = 0x4 },
> + { .name = "gpu", .base = 0x4ae07200, .pwstst = 0x4 },
> + { .name = "l3init", .base = 0x4ae07300, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "l4per", .base = 0x4ae07400, .pwstst = 0x4 },
> + { .name = "custefuse", .base = 0x4ae07600, .pwstst = 0x4 },
> + { .name = "wkupaon", .base = 0x4ae07724, .pwstst = 0x4 },
> + { .name = "emu", .base = 0x4ae07900, .pwstst = 0x4 },
> + { .name = "dsp2", .base = 0x4ae07b00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "eve1", .base = 0x4ae07b40, .pwstst = 0x4 },
> + { .name = "eve2", .base = 0x4ae07b80, .pwstst = 0x4 },
> + { .name = "eve3", .base = 0x4ae07bc0, .pwstst = 0x4 },
> + { .name = "eve4", .base = 0x4ae07c00, .pwstst = 0x4 },
> + { .name = "rtc", .base = 0x4ae07c60, .pwstst = 0x4 },
> + { .name = "vpe", .base = 0x4ae07c80, .pwstst = 0x4 },
> + { },
> +};
> +
> struct omap_rst_map am3_wkup_rst_map[] = {
> { .rst = 3, .st = 5 },
> { .rst = -1 },
> @@ -91,6 +116,7 @@ struct omap_prm_data am3_prm_data[] = {
>
> static const struct of_device_id omap_prm_id_table[] = {
> { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> + { .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
> { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
> { },
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/8] soc: ti: omap_prm: add data for am33xx
From: Suman Anna @ 2019-08-19 23:11 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-7-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM instance data for AM33xx SoC. Includes some basic register
> definitions and reset data for now.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index 9b8d5945..fadfc7f 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -73,8 +73,25 @@ struct omap_prm_data omap4_prm_data[] = {
> { },
> };
>
> +struct omap_rst_map am3_wkup_rst_map[] = {
static const here and below.
regards
Suman
> + { .rst = 3, .st = 5 },
> + { .rst = -1 },
> +};
> +
> +struct omap_prm_data am3_prm_data[] = {
> + { .name = "per", .base = 0x44e00c00, .pwstctrl = 0xc, .pwstst = 0x8, .flags = OMAP_PRM_NO_RSTST },
> + { .name = "wkup", .base = 0x44e00d00, .pwstctrl = 0x4, .pwstst = 0x8, .rstst = 0xc, .rstmap = am3_wkup_rst_map },
> + { .name = "mpu", .base = 0x44e00e00, .pwstst = 0x4 },
> + { .name = "device", .base = 0x44e00f00, .rstctl = 0x0, .rstst = 0x8 },
> + { .name = "rtc", .base = 0x44e01000, .pwstst = 0x4 },
> + { .name = "gfx", .base = 0x44e01100, .pwstst = 0x10, .rstctl = 0x4, .rstst = 0x14 },
> + { .name = "cefuse", .base = 0x44e01200, .pwstst = 0x4 },
> + { },
> +};
> +
> static const struct of_device_id omap_prm_id_table[] = {
> { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> + { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
> { },
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Suman Anna @ 2019-08-19 23:08 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-6-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM data for omap4 family of SoCs.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index 870515e3..9b8d5945 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -54,7 +54,27 @@ struct omap_reset_data {
>
> #define OMAP_PRM_NO_RSTST BIT(0)
>
> +struct omap_prm_data omap4_prm_data[] = {
static const
regards
Suman
> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214 },
> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst = 0x4 },
> + { },
> +};
> +
> static const struct of_device_id omap_prm_id_table[] = {
> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> { },
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] soc: ti: add initial PRM driver with reset control support
From: Suman Anna @ 2019-08-19 23:01 UTC (permalink / raw)
To: Tero Kristo, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt
Cc: tony, devicetree
In-Reply-To: <59709a2d-f13a-bd55-8aba-864c1cf2f19e@ti.com>
Hi Tero,
On 8/19/19 4:32 AM, Tero Kristo wrote:
> On 08/08/2019 08:26, Keerthy wrote:
>>
>>
>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>> Add initial PRM (Power and Reset Management) driver for TI OMAP class
>>> SoCs. Initially this driver only supports reset control, but can be
>>> extended to support rest of the functionality, like powerdomain
>>> control, PRCM irq support etc.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> arch/arm/mach-omap2/Kconfig | 1 +
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/omap_prm.c | 216
>>> ++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 218 insertions(+)
>>> create mode 100644 drivers/soc/ti/omap_prm.c
>>>
>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>> index fdb6743..42ad063 100644
>>> --- a/arch/arm/mach-omap2/Kconfig
>>> +++ b/arch/arm/mach-omap2/Kconfig
>>> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
>>> select TI_SYSC
>>> select OMAP_IRQCHIP
>>> select CLKSRC_TI_32K
>>> + select RESET_CONTROLLER
Use ARCH_HAS_RESET_CONTROLLER instead.
>>> help
>>> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>>> index b3868d3..788b5cd 100644
>>> --- a/drivers/soc/ti/Makefile
>>> +++ b/drivers/soc/ti/Makefile
>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
>>> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
>>> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
>>> obj-$(CONFIG_AMX3_PM) += pm33xx.o
>>> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
>>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>> new file mode 100644
>>> index 0000000..7c89eb8
>>> --- /dev/null
>>> +++ b/drivers/soc/ti/omap_prm.c
>>> @@ -0,0 +1,216 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * OMAP2+ PRM driver
>>> + *
>>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>> + * Tero Kristo <t-kristo@ti.com>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/device.h>
>>> +#include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/reset-controller.h>
>>> +#include <linux/delay.h>
>>> +
>>> +struct omap_rst_map {
>>> + s8 rst;
>>> + s8 st;
>>> +};
>>> +
>>> +struct omap_prm_data {
>>> + u32 base;
>>> + const char *name;
>>> + u16 pwstctrl;
>>> + u16 pwstst;
>>> + u16 rstctl;
Minor nit, can you use rstctrl instead here so that it is in sync with
the other variables and with the register names used in TRM.
>>> + u16 rstst;
>>> + struct omap_rst_map *rstmap;
>>> + u8 flags;
>>> +};
>>> +
>>> +struct omap_prm {
>>> + const struct omap_prm_data *data;
>>> + void __iomem *base;
>>> +};
>>> +
>>> +struct omap_reset_data {
>>> + struct reset_controller_dev rcdev;
>>> + struct omap_prm *prm;
>>> +};
>>> +
>>> +#define to_omap_reset_data(p) container_of((p), struct
>>> omap_reset_data, rcdev)
>>> +
>>> +#define OMAP_MAX_RESETS 8
>>> +#define OMAP_RESET_MAX_WAIT 10000
>>> +
>>> +#define OMAP_PRM_NO_RSTST BIT(0)
>>> +
>>> +static const struct of_device_id omap_prm_id_table[] = {
>>> + { },
>>> +};
>>
>> This table is blank and we are doing of_match_device against it.
>
> Yes, it gets populated with other patches in series, one entry per soc.
>
>>
>>> +
>>> +static int omap_reset_status(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> +
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>> + v &= 1 << id;
>>> + v >>= id;
>>> +
>>> + return v;
>>> +}
>>> +
>>> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> +
>>> + /* assert the reset control line */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + v |= 1 << id;
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
>>> + unsigned long id)
>>> +{
>>> + struct omap_rst_map *map = reset->prm->data->rstmap;
>>> +
>>> + while (map && map->rst >= 0) {
>>> + if (map->rst == id)
>>> + return map->st;
>>> +
>>> + map++;
>>> + }
>>> +
>>> + return id;
>>> +}
>>> +
>>> +/*
>>> + * Note that status will not change until clocks are on, and clocks
>>> cannot be
>>> + * enabled until reset is deasserted. Consumer drivers must check
>>> status
>>> + * separately after enabling clocks.
>>> + */
>>> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> + int st_bit = id;
No need to initialize this, will always get overwritten below.
>>> + bool has_rstst;
>>> +
>>> + /* check the current status to avoid de-asserting the line twice */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + if (!(v & BIT(id)))
>>> + return -EEXIST;
>>> +
>>> + has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
>>> +
>>> + if (has_rstst) {
>>> + st_bit = omap_reset_get_st_bit(reset, id);
>>> +
>>> + /* Clear the reset status by writing 1 to the status bit */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>> + v |= 1 << st_bit;
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
>>> + }
>>> +
>>> + /* de-assert the reset control line */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + v &= ~(1 << id);
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct reset_control_ops omap_reset_ops = {
>>> + .assert = omap_reset_assert,
>>> + .deassert = omap_reset_deassert,
>>> + .status = omap_reset_status,
>>> +};
>>> +
>>> +static int omap_prm_reset_probe(struct platform_device *pdev,
>>> + struct omap_prm *prm)
Call this omap_prm_reset_init or something similar to avoid confusion.
>>> +{
>>> + struct omap_reset_data *reset;
>>> +
>>> + /*
>>> + * Check if we have resets. If either rstctl or rstst is
>>> + * non-zero, we have reset registers in place. Additionally
>>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>>> + */
>>> + if (!prm->data->rstctl && !prm->data->rstst &&
>>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>>> + return 0;
>>> +
>>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>>> + if (!reset)
>>> + return -ENOMEM;
>>> +
>>> + reset->rcdev.owner = THIS_MODULE;
>>> + reset->rcdev.ops = &omap_reset_ops;
>>> + reset->rcdev.of_node = pdev->dev.of_node;
>>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
Suggest adding a number of resets to prm->data, and using it so that we
don't even entertain any resets beyond the actual number of resets.
You actually seem to be using the bit-position directly in client data
instead of a reset number. I am not sure if this is accepted practice
with reset controllers, do you incur any memory wastage?
>>> +
>>> + reset->prm = prm;
>>> +
>>> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>>> +}
>>> +
>>> +static int omap_prm_probe(struct platform_device *pdev)
>>> +{
>>> + struct resource *res;
>>> + const struct omap_prm_data *data;
>>> + struct omap_prm *prm;
>>> + const struct of_device_id *match;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res)
>>> + return -ENODEV;
>>> +
>>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>>> + if (!match)
>>> + return -ENOTSUPP;
Use of_device_get_match_data() instead to do both match and get the
data. That can perhaps be the first block.
>>> +
>>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>>> + if (!prm)
>>> + return -ENOMEM;
Perhaps move the allocate after the match check to streamline.
>>> +
>>> + data = match->data;
>>> +
>>> + while (data->base != res->start) {
>>> + if (!data->base)
>>> + return -EINVAL;
>>> + data++;
>>> + }
>>> +
>>> + prm->data = data;
>>> +
>>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (!prm->base)
>>> + return -ENOMEM;
>>> +
>>> + return omap_prm_reset_probe(pdev, prm);
>>> +}
>>> +
>>> +static struct platform_driver omap_prm_driver = {
>>> + .probe = omap_prm_probe,
>>> + .driver = {
>>> + .name = KBUILD_MODNAME,
>>> + .of_match_table = omap_prm_id_table,
>>> + },
>>> +};
>>> +builtin_platform_driver(omap_prm_driver);
>>> +
>>> +MODULE_ALIAS("platform:prm");
Drop this and use MODULE_DEVICE_TABLE instead on omap_prm_id_table if
retaining, but I don't think these need to be defined.
regards
Suman
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_DESCRIPTION("omap2+ prm driver");
>>
>> It is a builtin_platform_driver so do we need the MODULE*?
>
> Well, thats debatable, however some existing drivers do introduce this
> even if they are builtin.
>
> -Tero
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] coresight: tmc-etr: Fix perf_data check.
From: Mathieu Poirier @ 2019-08-19 22:55 UTC (permalink / raw)
To: Yabin Cui
Cc: Alexander Shishkin, Linux Kernel Mailing List, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20190815184628.183186-1-yabinc@google.com>
On Thu, 15 Aug 2019 at 12:46, Yabin Cui <yabinc@google.com> wrote:
>
> When tracing etm data of multiple threads on multiple cpus through
> perf interface, each cpu has a unique etr_perf_buffer while sharing
> the same etr device. There is no guarantee that the last cpu starts
> etm tracing also stops last. This makes perf_data check fail.
>
> Fix it by checking etr_buf instead of etr_perf_buffer.
> Also move the code setting and clearing perf_buf to more suitable
> places.
>
> Fixes: 3147da92a8a8 ("coresight: tmc-etr: Allocate and free ETR memory buffers for CPU-wide scenarios")
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
>
> v2 -> v3:
> moved place of setting drvdata->perf_buf based on review comment.
> Also moved place of clearing drvdata->perf_buf from
> tmc_update_etr_buffer() to tmc_disable_etr_sink() for below
> situation:
>
> cpu 0 enable etr device (set perf_buf)
> cpu 0 update etr buffer (clear perf_buf)
> cpu 1 enable etr device (perf_buf isn't set because pid set by cpu 0)
> cpu 0 disable etr device
> cpu 1 update etr buffer (perf_buf == NULL, check fails)
>
> To fix it, we need to move clearing perf_buf to the disable function.
>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 8 ++++----
> drivers/hwtracing/coresight/coresight-tmc.h | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 17006705287a..80af313f55d7 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1484,7 +1484,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> goto out;
> }
>
> - if (WARN_ON(drvdata->perf_data != etr_perf)) {
> + if (WARN_ON(drvdata->perf_buf != etr_buf)) {
> lost = true;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> goto out;
> @@ -1496,8 +1496,6 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> tmc_sync_etr_buf(drvdata);
>
> CS_LOCK(drvdata->base);
> - /* Reset perf specific data */
> - drvdata->perf_data = NULL;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> size = etr_buf->len;
> @@ -1556,7 +1554,6 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
> }
>
> etr_perf->head = PERF_IDX2OFF(handle->head, etr_perf);
> - drvdata->perf_data = etr_perf;
>
> /*
> * No HW configuration is needed if the sink is already in
> @@ -1572,6 +1569,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
> /* Associate with monitored process. */
> drvdata->pid = pid;
> drvdata->mode = CS_MODE_PERF;
> + drvdata->perf_buf = etr_perf->etr_buf;
> atomic_inc(csdev->refcnt);
> }
>
> @@ -1617,6 +1615,8 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
> /* Dissociate from monitored process. */
> drvdata->pid = -1;
> drvdata->mode = CS_MODE_DISABLED;
> + /* Reset perf specific data */
> + drvdata->perf_buf = NULL;
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index 1ed50411cc3c..f9a0c95e9ba2 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -178,8 +178,8 @@ struct etr_buf {
> * device configuration register (DEVID)
> * @idr: Holds etr_bufs allocated for this ETR.
> * @idr_mutex: Access serialisation for idr.
> - * @perf_data: PERF buffer for ETR.
> - * @sysfs_data: SYSFS buffer for ETR.
> + * @sysfs_buf: SYSFS buffer for ETR.
> + * @perf_buf: PERF buffer for ETR.
> */
> struct tmc_drvdata {
> void __iomem *base;
> @@ -202,7 +202,7 @@ struct tmc_drvdata {
> struct idr idr;
> struct mutex idr_mutex;
> struct etr_buf *sysfs_buf;
> - void *perf_data;
> + struct etr_buf *perf_buf;
> };
I have applied your patch.
Thanks,
Mathieu
>
> struct etr_buf_operations {
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Jordan Crouse @ 2019-08-19 22:34 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, will, iommu, linux-arm-kernel
In-Reply-To: <6596469d5fa1e918145fdd4e6b1a3ad67f7cde2e.1566238530.git.robin.murphy@arm.com>
On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> Now that callers are free to use a given table for TTBR1 if they wish
> (all they need do is shift the provided attributes when constructing
> their final TCR value), the only remaining impediment is the address
> validation on map/unmap. The fact that the LPAE address space split is
> symmetric makes this easy to accommodate - by simplifying the current
> range checks into explicit tests that address bits above IAS are all
> zero, it then follows straightforwardly to add the inverse test to
> allow the all-ones case as well.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 09cb20671fbb..f39c50356351 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> arm_lpae_iopte *ptep = data->pgd;
> int ret, lvl = ARM_LPAE_START_LVL(data);
> arm_lpae_iopte prot;
> + long iaext = (long)iova >> data->iop.cfg.ias;
>
> /* If no access, then nothing to do */
> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> return 0;
>
> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
> - paddr >= (1ULL << data->iop.cfg.oas)))
> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
> return -ERANGE;
>
> prot = arm_lpae_prot_to_pte(data, iommu_prot);
We'll want to cast away the sign extended bits before mapping the iova, this
might be a good patch for that too as long as we are calculating the iaext.
> @@ -647,8 +647,9 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> arm_lpae_iopte *ptep = data->pgd;
> int lvl = ARM_LPAE_START_LVL(data);
> + long iaext = (long)iova >> data->iop.cfg.ias;
>
> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
> + if (WARN_ON(iaext && ~iaext))
> return 0;
>
> return __arm_lpae_unmap(data, iova, size, lvl, ptep);
And here too.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Lubashev, Igor @ 2019-08-19 22:22 UTC (permalink / raw)
To: Mathieu Poirier, Arnaldo Carvalho de Melo
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Linux Kernel Mailing List, James Morris, Alexander Shishkin,
Ingo Molnar, Leo Yan, Namhyung Kim, Jiri Olsa, linux-arm-kernel
In-Reply-To: <CANLsYkyPkcJWmBZzyjGj3vJRgEtuaun7HQjN1=5wcOyTPnfhmQ@mail.gmail.com>
On Mon, August 19, 2019 at 12:51 PM Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Thu, 15 Aug 2019 at 15:42, Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Thu, Aug 15, 2019 at 02:16:48PM -0600, Mathieu Poirier escreveu:
> > > On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com>
> wrote:
> > > >
> > > > > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> > > > > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de
> > > > > Melo
> > > > > escreveu:
> > > > > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier
> escreveu:
> > > > > > > # echo 0 > /proc/sys/kernel/kptr_restrict #
> > > > > > > ./tools/perf/perf record -e instructions:k uname
> > > > > > > perf: Segmentation fault
> > > > > > > Obtained 10 stack frames.
> > > > > > > ./tools/perf/perf(sighandler_dump_stack+0x44)
> > > > > > > [0x55af9e5da5d4]
> > > > > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > > > > [0x55af9e590337]
> > > > > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > > > > [0x7fd31ef99b97]
> > > > > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation
> > > > > > > fault
> > > > > > >
> > > > > > > I can reproduce this on both x86 and ARM64.
> > > > > >
> > > > > > I don't see this with these two csets removed:
> > > > > >
> > > > > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict
> > > > > > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > > > > > perf_event_paranoid checks
> > > > > >
> > > > > > Which were the ones I guessed were related to the problem you
> > > > > > reported, so they are out of my ongoing perf/core pull request
> > > > > > to Ingo/Thomas, now trying with these applied and your
> instructions...
> > > > >
> > > > > Can't repro:
> > > > >
> > > > > [root@quaco ~]# cat /proc/sys/kernel/kptr_restrict
> > > > > 0
> > > > > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf
> record:
> > > > > Woken up 1 times to write data ] [ perf record: Captured and
> > > > > wrote 0.024 MB perf.data (1 samples) ] [root@quaco ~]# echo 1 >
> > > > > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e
> > > > > instructions:k uname Linux [ perf record: Woken up 1 times to write
> data ] [ perf record:
> > > > > Captured and wrote 0.024 MB perf.data (1 samples) ] [root@quaco
> > > > > ~]# echo
> > > > > 0 > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record
> > > > > -e instructions:k uname Linux [ perf record: Woken up 1 times to
> > > > > write data ] [ perf record: Captured and wrote 0.024 MB
> > > > > perf.data (1 samples) ] [root@quaco ~]#
> > > > >
> > > > > [acme@quaco perf]$ git log --oneline --author Lubashev tools/
> > > > > 7ff5b5911144 (HEAD -> perf/cap, acme.korg/tmp.perf/cap,
> > > > > acme.korg/perf/cap) perf symbols: Use CAP_SYSLOG with
> > > > > kptr_restrict checks d7604b66102e perf tools: Use CAP_SYS_ADMIN
> > > > > with perf_event_paranoid checks c766f3df635d perf ftrace: Use
> > > > > CAP_SYS_ADMIN instead of euid==0 c22e150e3afa perf tools: Add
> > > > > helpers to use capabilities if present
> > > > > 74d5f3d06f70 tools build: Add capability-related feature
> > > > > detection perf version 5.3.rc4.g7ff5b5911144 [acme@quaco perf]$
> > > >
> > > > I got an ARM64 cloud VM, but I cannot reproduce.
> > > > # cat /proc/sys/kernel/kptr_restrict
> > > > 0
> > > >
> > > > Perf trace works fine (does not die):
> > > > # ./perf trace -a
> > > >
> > > > Here is my setup:
> > > > Repo: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> > > > Branch: tmp.perf/cap
> > > > Commit: 7ff5b5911 "perf symbols: Use CAP_SYSLOG with kptr_restrict
> checks"
> > > > gcc --version: gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
> > > > uname -a: Linux arm-4-par-1 4.9.93-mainline-rev1 #1 SMP Tue Apr 10
> > > > 09:54:46 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux lsb_release
> > > > -a: Ubuntu 18.04.3 LTS
> > > >
> > > > Auto-detecting system features:
> > > > ... dwarf: [ on ]
> > > > ... dwarf_getlocations: [ on ]
> > > > ... glibc: [ on ]
> > > > ... gtk2: [ on ]
> > > > ... libaudit: [ on ]
> > > > ... libbfd: [ on ]
> > > > ... libcap: [ on ]
> > > > ... libelf: [ on ]
> > > > ... libnuma: [ on ]
> > > > ... numa_num_possible_cpus: [ on ]
> > > > ... libperl: [ on ]
> > > > ... libpython: [ on ]
> > > > ... libcrypto: [ on ]
> > > > ... libunwind: [ on ]
> > > > ... libdw-dwarf-unwind: [ on ]
> > > > ... zlib: [ on ]
> > > > ... lzma: [ on ]
> > > > ... get_cpuid: [ OFF ]
> > > > ... bpf: [ on ]
> > > > ... libaio: [ on ]
> > > > ... libzstd: [ on ]
> > > > ... disassembler-four-args: [ on ]
> > > >
> > > > I also could not reproduce on x86:
> > > > lsb_release -a: Ubuntu 18.04.1 LTS gcc --version: gcc (Ubuntu
> > > > 7.4.0-1ubuntu1~18.04aka10.0.0) 7.4.0 uname -r: 4.4.0-154-generic
> > >
> > > I isolated the problem to libcap-dev - if it is not installed a
> > > segmentation fault will occur. Since this set is about using
> > > capabilities it is obvious that not having it on a system should
> > > fail a trace session, but it should not crash it.
> >
> > It shouldn't crash on x86_64:
> >
> > root@quaco ~]# sysctl kernel.kptr_restrict kernel.kptr_restrict = 0
> > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf
> > record: Woken up 1 times to write data ] [ perf record: Captured and
> > wrote 0.023 MB perf.data (5 samples) ] [root@quaco ~]# ldd ~/bin/perf
> > | grep libcap [root@quaco ~]# perf -v perf version
> > 5.3.rc4.g329ca330bf8b [root@quaco ~]# [acme@quaco perf]$ git log
> > --oneline -4 329ca330bf8b (HEAD -> perf/cap) perf symbols: Use
> > CAP_SYSLOG with kptr_restrict checks f7b9999387af perf tools: Use
> > CAP_SYS_ADMIN with perf_event_paranoid checks
> > 4d0489cf1c47 (acme.korg/tmp.perf/script-switch-on-off, perf/core) perf
> > report: Add --switch-on/--switch-off events
> > 2f53ae347f59 perf top: Add --switch-on/--switch-off events [acme@quaco
> > perf]$
> >
> > > If libcap-dev is not installed function
> > > symbol__restricted_filename() will return true, which in turn will
> > > prevent symbol_name to be set in
> > > machine__get_running_kernel_start(). That prevents function
> > > map__set_kallsyms_ref_reloc_sym() from being called in
> > > machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym
> > > being NULL in _perf_event__synthesize_kernel_mmap() and a
> > > segmentation fault.
> >
> > Can you please try with my perf/cap branch? Perhaps you're using
> > Igor's original set of patches? I made changes to the fallback, he was
> > making it return false while I made it fallback to geteuid() == 0, as
> > was before his patches.
>
> Things are working properly on your perf/cap branch. I tested with on both
> x86 and ARM.
Mathieu, you are probably testing with euid==0. If you were to test with euid!=0 but with CAP_SYSLOG and no libcap (and kptr_restrict=0, perf_event_paranoid=2), you would likely hit the bug that you identified in __perf_event__synthesize_kermel_mmap().
See https://lkml.kernel.org/lkml/930a59730c0d495f8c5acf4f99048e8d@usma1ex-dag1mb6.msg.corp.akamai.com for the fix (Option 1 only or Options 1+2).
Arnaldo, once we decide what the right fix is, I am happy to post the update (options 1, 1+2) as a patch series.
- Igor
> > > I am not sure how this can be fixed. I counted a total of 19
> > > instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
> > > care to check if kmap->ref_reloc_sym is valid before proceeding. As
> > > such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
> > > guaranteed to be valid. If I am correct then all we need is to
> > > check for a valid pointer in _perf_event__synthesize_kernel_mmap().
> > > Otherwise it will be a little harder.
> > >
> > > Mathieu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: omap: add new binding for PRM instances
From: Suman Anna @ 2019-08-19 21:28 UTC (permalink / raw)
To: Tero Kristo, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt
Cc: tony, devicetree
In-Reply-To: <aa5538ae-76b4-942b-dc98-6e55628cf36a@ti.com>
Hi Tero,
On 8/19/19 4:28 AM, Tero Kristo wrote:
> On 08/08/2019 07:35, Keerthy wrote:
>>
>>
>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>> of these will act as a power domain controller and potentially as a
>>> reset
>>> provider.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 24
>>> ++++++++++++++++++++++
>>> 1 file changed, 24 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>> b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>> new file mode 100644
>>> index 0000000..e0ae87b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>> @@ -0,0 +1,24 @@
>>> +OMAP PRM instance bindings
>>> +
>>> +Power and Reset Manager is an IP block on OMAP family of devices which
>>> +handle the power domains and their current state, and provide reset
>>> +handling for the domains and/or separate IP blocks under the power
>>> domain
>>> +hierarchy.
So, I see that you are adding these as flat nodes directly under the prm
nodes where we have the clocks and clock_domains. Are you anticipating a
single DT node and/or driver managing both power-domains and resets?
>>> +
>>> +Required properties:
>>> +- compatible: Must be one of:
>>> + "ti,am3-prm-inst"
>>> + "ti,am4-prm-inst"
>>> + "ti,omap4-prm-inst"
>>> + "ti,omap5-prm-inst"
>>> + "ti,dra7-prm-inst"
What about OMAP2, OMAP3, DM814x, DM816x?
regards
Suman
>>> +- reg: Contains PRM instance register address range
>>> + (base address and length)
>>
>> How about reset-cells property, Isn't that a mandatory property?
>
> It is optional, but you are right, should be added to this.
>
> -Tero
>
>>
>>> +
>>> +Example:
>>> +
>>> +prm_dsp2: prm@1b00 {
>>> + compatible = "ti,dra7-prm-inst";
>>> + reg = <0x1b00 0x40>;
>>> + #reset-cells = <1>;
>>> +};
>>>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 8/8] coresight: etm4x: docs: Additional documentation for ETM4x.
From: Mike Leach @ 2019-08-19 20:57 UTC (permalink / raw)
To: mathieu.poirier, linux-arm-kernel, coresight; +Cc: suzuki.poulose, mike.leach
In-Reply-To: <20190819205720.24457-1-mike.leach@linaro.org>
Update existing docs for new sysfs API features.
Add new ETMv4 reference document for sysfs programming.
Move coresight documentation to common directory.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
.../testing/sysfs-bus-coresight-devices-etm4x | 183 ++++---
.../{ => coresight}/coresight-cpu-debug.txt | 0
.../coresight/coresight-etm4x-reference.txt | 459 ++++++++++++++++++
.../trace/{ => coresight}/coresight.txt | 0
MAINTAINERS | 3 +-
5 files changed, 575 insertions(+), 70 deletions(-)
rename Documentation/trace/{ => coresight}/coresight-cpu-debug.txt (100%)
create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.txt
rename Documentation/trace/{ => coresight}/coresight.txt (100%)
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
index 36258bc1b473..112c50ae9986 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
@@ -1,4 +1,4 @@
-What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
+What: /sys/bus/coresight/devices/etm<N>/enable_source
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -8,82 +8,82 @@ Description: (RW) Enable/disable tracing on this specific trace entiry.
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cpu
+What: /sys/bus/coresight/devices/etm<N>/cpu
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) The CPU this tracing entity is associated with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
+What: /sys/bus/coresight/devices/etm<N>/nr_pe_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of PE comparator inputs that are
available for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
+What: /sys/bus/coresight/devices/etm<N>/nr_addr_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of address comparator pairs that are
available for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
+What: /sys/bus/coresight/devices/etm<N>/nr_cntr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of counters that are available for
tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
+What: /sys/bus/coresight/devices/etm<N>/nr_ext_inp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates how many external inputs are implemented.
-What: /sys/bus/coresight/devices/<memory_map>.etm/numcidc
+What: /sys/bus/coresight/devices/etm<N>/numcidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of Context ID comparators that are
available for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/numvmidc
+What: /sys/bus/coresight/devices/etm<N>/numvmidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of VMID comparators that are available
for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
+What: /sys/bus/coresight/devices/etm<N>/nrseqstate
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of sequencer states that are
implemented.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_resource
+What: /sys/bus/coresight/devices/etm<N>/nr_resource
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of resource selection pairs that are
available for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
+What: /sys/bus/coresight/devices/etm<N>/nr_ss_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of single-shot comparator controls that
are available for tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/reset
+What: /sys/bus/coresight/devices/etm<N>/reset
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (W) Cancels all configuration on a trace unit and set it back
to its boot configuration.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mode
+What: /sys/bus/coresight/devices/etm<N>/mode
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -91,302 +91,349 @@ Description: (RW) Controls various modes supported by this ETM, for example
P0 instruction tracing, branch broadcast, cycle counting and
context ID tracing.
-What: /sys/bus/coresight/devices/<memory_map>.etm/pe
+What: /sys/bus/coresight/devices/etm<N>/pe
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which PE to trace.
-What: /sys/bus/coresight/devices/<memory_map>.etm/event
+What: /sys/bus/coresight/devices/etm<N>/event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the tracing of arbitrary events from bank 0 to 3.
-What: /sys/bus/coresight/devices/<memory_map>.etm/event_instren
+What: /sys/bus/coresight/devices/etm<N>/event_instren
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the behavior of the events in bank 0 to 3.
-What: /sys/bus/coresight/devices/<memory_map>.etm/event_ts
+What: /sys/bus/coresight/devices/etm<N>/event_ts
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the insertion of global timestamps in the trace
streams.
-What: /sys/bus/coresight/devices/<memory_map>.etm/syncfreq
+What: /sys/bus/coresight/devices/etm<N>/syncfreq
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls how often trace synchronization requests occur.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
+What: /sys/bus/coresight/devices/etm<N>/cyc_threshold
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Sets the threshold value for cycle counting.
-What: /sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
+What: /sys/bus/coresight/devices/etm<N>/bb_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which regions in the memory map are enabled to
use branch broadcasting.
-What: /sys/bus/coresight/devices/<memory_map>.etm/event_vinst
+What: /sys/bus/coresight/devices/etm<N>/event_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls instruction trace filtering.
-What: /sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
+What: /sys/bus/coresight/devices/etm<N>/s_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In Secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
-What: /sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
+What: /sys/bus/coresight/devices/etm<N>/ns_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In non-secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
-What: /sys/bus/coresight/devices/<memory_map>.etm/addr_idx
+What: /sys/bus/coresight/devices/etm<N>/addr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which address comparator or pair (of comparators) to
work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
+What: /sys/bus/coresight/devices/etm<N>/addr_instdatatype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls what type of comparison the trace unit performs.
-What: /sys/bus/coresight/devices/<memory_map>.etm/addr_single
+What: /sys/bus/coresight/devices/etm<N>/addr_single
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup single address comparator values.
-What: /sys/bus/coresight/devices/<memory_map>.etm/addr_range
+What: /sys/bus/coresight/devices/etm<N>/addr_range
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup address range comparator values.
-What: /sys/bus/coresight/devices/<memory_map>.etm/seq_idx
+What: /sys/bus/coresight/devices/etm<N>/seq_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which sequensor.
-What: /sys/bus/coresight/devices/<memory_map>.etm/seq_state
+What: /sys/bus/coresight/devices/etm<N>/seq_state
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Use this to set, or read, the sequencer state.
-What: /sys/bus/coresight/devices/<memory_map>.etm/seq_event
+What: /sys/bus/coresight/devices/etm<N>/seq_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer state to a specific state.
-What: /sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
+What: /sys/bus/coresight/devices/etm<N>/seq_reset_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer to state 0 when a programmed event
occurs.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
+What: /sys/bus/coresight/devices/etm<N>/cntr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which counter unit to work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
+What: /sys/bus/coresight/devices/etm<N>/cntrldvr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the reload count value of the
specific counter.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_val
+What: /sys/bus/coresight/devices/etm<N>/cntr_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the current count value of the
specific counter.
-What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
+What: /sys/bus/coresight/devices/etm<N>/cntr_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the operation of the selected counter.
-What: /sys/bus/coresight/devices/<memory_map>.etm/res_idx
+What: /sys/bus/coresight/devices/etm<N>/res_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which resource selection unit to work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
+What: /sys/bus/coresight/devices/etm<N>/res_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the selection of the resources in the trace unit.
-What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
+What: /sys/bus/coresight/devices/etm<N>/ctxid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which context ID comparator to work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
+What: /sys/bus/coresight/devices/etm<N>/ctxid_pid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the context ID comparator value to trigger on.
-What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
+What: /sys/bus/coresight/devices/etm<N>/ctxid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 context ID comparator value
registers (if implemented).
-What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
+What: /sys/bus/coresight/devices/etm<N>/vmid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which virtual machine ID comparator to work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_val
+What: /sys/bus/coresight/devices/etm<N>/vmid_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the virtual machine ID comparator value to
trigger on.
-What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
+What: /sys/bus/coresight/devices/etm<N>/vmid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 virtual machine ID comparator value
registers (if implemented).
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
+What: /sys/bus/coresight/devices/etm<N>/addr_exlevel_s_ns
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (RW) Set the Exception Level matching bits for secure and
+ non-secure exception levels.
+
+What: /sys/bus/coresight/devices/etm<N>/vinst_pe_cmp_start_stop
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (RW) Access the start stop control register for PE input
+ comparators.
+
+What: /sys/bus/coresight/devices/etm<N>/addr_cmp_view
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (R) Print the current settings for the selected address
+ comparator.
+
+What: /sys/bus/coresight/devices/etm<N>/sshot_idx
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (RW) Select the single shot control register to access.
+
+What: /sys/bus/coresight/devices/etm<N>/sshot_ctrl
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (RW) Access the selected single shot control register.
+
+What: /sys/bus/coresight/devices/etm<N>/sshot_status
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (R) Print the current value of the selected single shot
+ status register.
+
+What: /sys/bus/coresight/devices/etm<N>/sshot_pe_ctrl
+Date: August 2019
+KernelVersion: 5.4
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
+Description: (RW) Access the selected single show PE comparator control
+ register.
+
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcoslsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the OS Lock Status Register (0x304).
The value it taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdcr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Control Register
(0x310). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Status Register
(0x314). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trclsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the SW Lock Status Register
(0xFB4). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcauthstatus
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Authentication Status Register
(0xFB8). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device ID Register
(0xFC8). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device Type Register
(0xFCC). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID0 Register
(0xFE0). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID1 Register
(0xFE4). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID2 Register
(0xFE8). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID3 Register
(0xFEC). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcconfig
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trcconfig
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace configuration register
(0x010) as currently set by SW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trctraceid
+What: /sys/bus/coresight/devices/etm<N>/mgmt/trctraceid
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace ID register (0x040).
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E0).
The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E4).
The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -394,7 +441,7 @@ Description: (R) Returns the maximum size of the data value, data address,
VMID, context ID and instuction address in the trace unit
(0x1E8). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -403,42 +450,42 @@ Description: (R) Returns the value associated with various resources
architecture specification for more details (0x1E8).
The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr4
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F0).
The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr5
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F4).
The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr8
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the maximum speculation depth of the instruction
trace stream. (0x180). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr9
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P0 right-hand keys that the trace unit
can use (0x184). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr10
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P1 right-hand keys that the trace unit
can use (0x188). The value is taken directly from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr11
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -446,7 +493,7 @@ Description: (R) Returns the number of special P1 right-hand keys that the
trace unit can use (0x18C). The value is taken directly from
the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr12
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -454,7 +501,7 @@ Description: (R) Returns the number of conditional P1 right-hand keys that
the trace unit can use (0x190). The value is taken directly
from the HW.
-What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
+What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr13
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt
similarity index 100%
rename from Documentation/trace/coresight-cpu-debug.txt
rename to Documentation/trace/coresight/coresight-cpu-debug.txt
diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.txt b/Documentation/trace/coresight/coresight-etm4x-reference.txt
new file mode 100644
index 000000000000..72e81bbbef43
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
@@ -0,0 +1,459 @@
+ETMv4 sysfs linux driver programming reference - v2.
+====================================================
+
+Supplement to existing ETMv4 driver documentation.
+
+Sysfs files and directories
+---------------------------
+
+Root: /sys/bus/coresight/devices/etm<N>
+
+
+The following paragraphs explain the association between sysfs files and the
+ETMv4 registers that they effect. Note the register names are given without
+the ‘TRC’ prefix.
+
+File : mode (rw)
+Trace Registers : {CONFIGR + others}
+Notes : Bit select trace features. See ‘mode’ section below. Bits
+ in this will cause equivalent programming of trace config and
+ other registers to enable the features requested.
+Syntax & eg : 'echo bitfield > mode'
+ bitfield up to 32 bits setting trace features.
+Example : $> echo 0x > mode
+
+File : reset (wo)
+Trace Registers : All
+Notes : Reset all programming to trace nothing / no logic programmed.
+Syntax : 'echo 1 > reset'
+
+File : enable_source (wo)
+Trace Registers : PRGCTLR, All hardware regs.
+Notes : >0: Programs up the hardware with the current values held in
+ the driver and enables trace.
+ 0: disable trace hardware.
+Syntax : 'echo 1 > enable_source'
+
+File : cpu (ro)
+Trace Registers : None.
+Notes : CPU ID that this ETM is attached to.
+Example :$> cat cpu
+ $> 0
+
+File : addr_idx (rw)
+Trace Registers : None.
+Notes : Virtual register to index address comparator and range
+ features. Set index for first of the pair in a range.
+Syntax : 'echo idx > addr_idx'
+ Where idx < nr_addr_cmp x 2
+
+File : addr_range (rw)
+Trace Registers : ACVR[idx, idx+1], VIIECTLR
+Notes : Pair of addresses for a range selected by addr_idx. Include
+ / exclude according to the optional parameter, or if omitted
+ uses the current ‘mode’ setting. Select comparator range in
+ control register. Error if index is odd value.
+Depends : mode, addr_idx
+Syntax : 'echo addr1 addr2 [exclude] > addr_range'
+ Where addr1 and addr2 define the range and addr1 < addr2.
+ Optional exclude value - 0 for include, 1 for exclude.
+Example : $> echo 0x0000 0x2000 0 > addr_range
+
+File : addr_single (rw)
+Trace Registers : ACVR[idx]
+Notes : Set a single address comparator according to addr_idx. This
+ is used if the address comparator is used as part of event
+ generation logic etc.
+Depends : addr_idx
+Syntax : 'echo addr1 > addr_single'
+
+File : addr_start (rw)
+Trace Registers : ACVR[idx], VISSCTLR
+Notes : Set a trace start address comparator according to addr_idx.
+ Select comparator in control register.
+Depends : addr_idx
+Syntax : 'echo addr1 > addr_start'
+
+File : addr_stop (rw)
+Trace Registers : ACVR[idx], VISSCTLR
+Notes : Set a trace stop address comparator according to addr_idx.
+ Select comparator in control register.
+Depends : addr_idx
+Syntax : 'echo addr1 > addr_stop'
+
+File : addr_context (rw)
+Trace Registers : ACATR[idx,{6:4}]
+Notes : Link context ID comparator to address comparator addr_idx
+Depends : addr_idx.
+Syntax : 'echo ctxt_idx > addr_context'
+ Where ctxt_idx is the index of the linked context id / vmid
+ comparator.
+
+File : addr_ctxtype (rw)
+Trace Registers : ACATR[idx,{3:2}]
+Notes : Input value string. Set type for linked context ID comparator
+Depends : addr_idx
+Syntax : 'echo type > addr_ctxtype'
+ Type one of {all, vmid, ctxid, none}
+Example : $> echo ctxid > addr_ctxtype
+
+File : addr_exlevel_s_ns (rw)
+Trace Registers : ACATR[idx,{14:8}]
+Notes : Set the ELx secure and non-secure matching bits for the
+ selected address comparator
+Depends : addr_idx
+Syntax : 'echo val > addr_exlevel_s_ns'
+ val is a 7 bit value for exception levels to exclude. Input
+ value shifted to correct bits in register.
+Example : $> echo 0x4F > addr_exlevel_s_ns
+
+File : addr_instdatatype (rw)
+Trace Registers : ACATR[idx,{1:0}]
+Notes : Set the comparator address type for matching. Driver only
+ supports setting instruction address type.
+Depends : addr_idx
+
+File : addr_cmp_view (ro)
+Trace Registers : ACVR[idx, idx+1], ACATR[idx], VIIECTLR
+Notes : Read the currently selected address comparator. If part of
+ address range then display both addresses.
+Depends : addr_idx
+Syntax : 'cat addr_cmp_view'
+Example : $> cat addr_cmp_view
+ addr_cmp[0] range 0x0 0xffffffffffffffff include ctrl(0x4b00)
+
+File : nr_addr_cmp (ro)
+Trace Registers : From IDR4
+Notes : Number of address comparator pairs
+
+File : sshot_idx (rw)
+Trace Registers : None
+Notes : Select single shot register set.
+
+File : sshot_ctrl (rw)
+Trace Registers : SSCCR[idx]
+Notes : Access a single shot comparator control register.
+Depends : sshot_idx
+Syntax : 'echo val > sshot_ctrl'
+ Writes val into the selected control register.
+
+File : sshot_status (ro)
+Trace Registers : SSCSR[idx]
+Notes : Read a single shot comparator status register
+Depends : sshot_idx
+Syntax : 'cat sshot_status'
+ Read status.
+Example : $> cat sshot_status
+ 0x1
+
+File : sshot_pe_ctrl (rw)
+Trace Registers : SSPCICR[idx]
+Notes : Access a single shot PE comparator input control register.
+Depends : sshot_idx
+Syntax : echo val > sshot_pe_ctrl
+ Writes val into the selected control register.
+
+File : ns_exlevel_vinst (rw)
+Trace Registers : VICTLR{23:20}
+Notes : Program non-secure exception level filters. Set / clear NS
+ exception filter bits. Setting ‘1’ excludes trace from the
+ exception level.
+Syntax : 'echo bitfield > ns_exlevel_viinst'
+ Where bitfield contains bits to set clear for EL0 to EL2
+Example : %> echo 0x4 > ns_exlevel_viinst
+ ; Exclude EL2 NS trace.
+
+File : vinst_pe_cmp_start_stop (rw)
+Trace Registers : VIPCSSCTLR
+Notes : Access PE start stop comparator input control registers
+
+File : bb_ctrl (rw)
+Trace Registers : BBCTLR
+Notes : Define ranges that Branch Broadcast will operate in.
+ Default (0x0) is all addresses.
+Depends : BB enabled.
+
+File : cyc_threshold (rw)
+Trace Registers : CCCTLR
+Notes : Set the threshold for which cycle counts will be emitted.
+ Error if attempt to set below minimum defined in IDR3, masked
+ to width of valid bits.
+Depends : CC enabled.
+
+File : syncfreq (rw)
+Trace Registers : SYNCPR
+Notes : Set trace synchronisation period. Power of 2 value, 0 (off)
+ or 8-20. Driver defaults to 12 (every 4096 bytes).
+
+File : cntr_idx (rw)
+Trace Registers : none
+Notes : Select the counter to access
+Syntax : 'echo idx > cntr_idx'
+ Where idx < nr_cntr
+
+File : cntr_ctrl (rw)
+Trace Registers : CNTCTLR[idx]
+Notes : Set counter control value
+Depends : cntr_idx
+Syntax : 'echo val > cntr_ctrl'
+ Where val is per ETMv4 spec.
+
+File : cntrldvr (rw)
+Trace Registers : CNTRLDVR[idx]
+Notes : Set counter reload value
+Depends : cntr_idx
+Syntax : 'echo val > cntrldvr'
+ Where val is per ETMv4 spec.
+
+File : nr_cntr (ro)
+Trace Registers : From IDR5
+Notes : Number of counters implemented.
+
+File : ctxid_idx (rw)
+Trace Registers : None
+Notes : Select the context ID comparator to access
+Syntax : 'echo idx > ctxid_idx'
+ Where idx < numcidc
+
+File : ctxid_pid (rw)
+Trace Registers : CIDCVR[idx]
+Notes : Set the context ID comparator value
+Depends : ctxid_idx
+
+File : ctxid_masks (rw)
+Trace Registers : CIDCCTLR0, CIDCCTLR1, CIDCVR<0-7>
+Notes : Pair of values to set the byte masks for 1-8 context ID
+ comparators. Automatically clears masked bytes to 0 in CID
+ value registers.
+Syntax : 'echo m3m2m1m0 [m7m6m5m4] > ctxid_masks'
+ 32 bit values made up of mask bytes, where mN represents a
+ byte mask value for Ctxt ID comparator N.
+ Second value not required on systems that have fewer than 4
+ context ID comparators
+
+File : numcidc (ro)
+Trace Registers : From IDR4
+Notes : Number of Context ID comparators
+
+File : vmid_idx (rw)
+Trace Registers : None
+Notes : Select the VM ID comparator to access.
+Syntax : 'echo idx > vmid_idx'
+ Where idx < numvmidc
+
+File : vmid_val (rw)
+Trace Registers : VMIDCVR[idx]
+Notes : Set the VM ID comparator value
+Depends : vmid_idx
+
+File : vmid_masks (rw)
+Trace Registers : VMIDCCTLR0, VMIDCCTLR1, VMIDCVR<0-7>
+Notes : Pair of values to set the byte masks for 1-8 VM ID
+ comparators. Automatically clears masked bytes to 0 in VMID
+ value registers.
+Syntax : 'echo m3m2m1m0 [m7m6m5m4] > vmid_masks'
+ Where mN represents a byte mask value for VMID comparator N.
+ Second value not required on systems that have fewer than
+ 4 VMID comparators.
+
+File : numvmidc (ro)
+Trace Registers : From IDR4
+Notes : Number of VMID comparators
+
+File : res_idx (rw)
+Trace Registers : None.
+Notes : Select the resource selector control to access. Must be 2 or
+ higher as selectors 0 and 1 are hardwired.
+Syntax : 'echo idx > res_idx'
+ Where 2 <= idx < nr_resource x 2
+
+File : res_ctrl (rw)
+Trace Registers : RSCTLR[idx]
+Notes : Set resource selector control value. Value per ETMv4 spec.
+Depends : res_idx
+Syntax : 'echo val > res_cntr'
+ Where val is per ETMv4 spec.
+
+File : nr_resource (ro)
+Trace Registers : From IDR4
+Notes : Number of resource selector pairs
+
+File : event (rw)
+Trace Registers : EVENTCTRL0R
+Notes : Set up to 4 implemented event fields.
+Syntax : 'echo ev3ev2ev1ev0 > event'
+ Where evN is an 8 bit event field. Up to 4 event fields make up
+ the 32bit input value. Number of valid fields implementation
+ dependent defined in IDR0.
+
+File : event_instren (rw)
+Trace Registers : EVENTCTRL1R
+Notes : Choose events which insert event packets into trace stream.
+Depends : EVENTCTRL0R
+Syntax : 'echo bitfield > event_instren'
+ Where bitfield is up to 4 bits according to number of event
+ fields.
+
+File : event_ts (rw)
+Trace Registers : TSCTLR
+Notes : Set the event that will generate timestamp requests.
+Depends : TS activated
+Syntax : 'echo evfield > event_ts'
+ Where evfield is an 8 bit event selector.
+
+File : seq_idx (rw)
+Trace Registers : None
+Notes : Sequencer event register select - 0 to 2
+
+
+File : seq_state (rw)
+Trace Registers : SEQSTR
+Notes : Sequencer current state - 0 to 3.
+
+File : seq_event (rw)
+Trace Registers : SEQEVR[idx]
+Notes : State transition event registers
+Depends : seq_idx
+Syntax : 'echo evBevF > seq_event'
+ Where evBevF is a 16 bit value made up of two event selectors,
+ evB - back, evF - forwards.
+
+File : seq_reset_event (rw)
+Trace Registers : SEQRSTEVR
+Notes : Sequencer reset event
+Syntax : 'echo evfield > seq_reset_event'
+ Where evfield is an 8 bit event selector.
+
+File : nrseqstate (ro)
+Trace Registers : From IDR5
+Notes : Number of sequencer states (0 or 4)
+
+File : nr_pe_cmp (ro)
+Trace Registers : From IDR4
+Notes : Number of PE comparator inputs
+
+File : nr_ext_inp (ro)
+Trace Registers : From IDR5
+Notes : Number of external inputs
+
+File : nr_ss_cmp (ro)
+Trace Registers : From IDR4
+Notes : Number of Single Shot control registers
+
+Note: When programming any address comparator the driver will tag the
+comparator with a type used - i.e. RANGE, SINGLE, START, STOP. Once this tag
+is set, then only the values can be changed using the same sysfs file / type
+used to program it.
+
+Thus:-
+% echo 0 > addr_idx ; select address comparator 0
+% echo 0x1000 0x5000 0 > addr_range ; set address range on comparators 0 and 1.
+% echo 0x2000 > addr_start ; this will error as comparator 0 is a
+ ; range comparator
+% echo 2 > addr_idx ; select address comparator 2
+% echo 0x2000 > addr_start ; this is OK as comparator 2 is unused,
+% echo 0x3000 > addr_stop ; this will error as comparator 2 a start
+ ; address comparator
+% echo 2 > addr_idx ; select address comparator 3
+% echo 0x3000 > addr_stop ; this is OK
+
+To remove programming on all the comparators (and all the other hardware) use
+the reset parameter:
+
+% echo 1 > reset
+
+The ‘mode’ sysfs parameter.
+---------------------------
+
+This is a bitfield selection parameter that sets the overall trace mode for the
+ETM. The table below describes the bits, using the defines from the driver
+source file, along with a description of the feature these represent. Many
+features are optional and therefore dependent on implementation in the
+hardware.
+
+Bit assignements shown below:-
+
+bit (0) : #define ETM_MODE_EXCLUDE
+description : This is the default value for the include / exclude function when
+ setting address ranges. Set 1 for exclude range. When the mode
+ parameter is set this value is applied to the currently indexed
+ address range.
+
+bit (4) : #define ETM_MODE_BB
+description : Set to enable branch broadcast if supported in hardware [IDR0].
+
+bit (5) : #define ETMv4_MODE_CYCACC
+description : Set to enable cycle accurate trace if supported [IDR0].
+
+bit (6) : ETMv4_MODE_CTXID
+description : Set to enable context ID tracing if supported in hardware [IDR2].
+
+bit (7) : ETM_MODE_VMID
+description : Set to enable virtual machine ID tracing if supported [IDR2].
+
+bit (11) : ETMv4_MODE_TIMESTAMP
+description : Set to enable timestamp generation if supported [IDR0].
+
+bit (12) : ETM_MODE_RETURNSTACK
+description : Set to enable trace return stack use if supported [IDR0].
+
+bit (13-14) : ETM_MODE_QELEM(val)
+description : ‘val’ determines level of Q element support enabled if
+ implemented by the ETM [IDR0]
+
+bit (19) : ETM_MODE_ATB_TRIGGER
+description : Set to enable the ATBTRIGGER bit in the event control register
+ [EVENTCTLR1] if supported [IDR5].
+
+bit (20) : ETM_MODE_LPOVERRIDE
+description : Set to enable the LPOVERRIDE bit in the event control register
+ [EVENTCTLR1], if supported [IDR5].
+
+bit (21) : ETM_MODE_ISTALL_EN
+description : Set to enable the ISTALL bit in the stall control register
+ [STALLCTLR]
+
+bit (23) : ETM_MODE_INSTPRIO
+description : Set to enable the INSTPRIORITY bit in the stall control register
+ [STALLCTLR] , if supported [IDR0].
+
+bit (24) : ETM_MODE_NOOVERFLOW
+description : Set to enable the NOOVERFLOW bit in the stall control register
+ [STALLCTLR], if supported [IDR3].
+
+bit (25) : ETM_MODE_TRACE_RESET
+description : Set to enable the TRCRESET bit in the viewinst control register
+ [VICTLR] , if supported [IDR3].
+
+bit (26) : ETM_MODE_TRACE_ERR
+description : Set to enable the TRCCTRL bit in the viewinst control register
+ [VICTLR].
+
+bit (27) : ETM_MODE_VIEWINST_STARTSTOP
+description : Set the initial state value of the ViewInst start / stop logic
+ in the viewinst control register [VICTLR]
+
+bit (30) : ETM_MODE_EXCL_KERN
+description : Set default trace setup to exclude kernel mode trace (see note a)
+
+bit (31) : ETM_MODE_EXCL_USER
+description : Set default trace setup to exclude user space trace (see note a)
+
+Note a) On startup the ETM is programmed to trace the complete address space
+using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
+set EL exclude bits for NS state in either user space (EL0) or kernel space
+(EL1) in the address range comparator. (the default setting excludes all
+secure EL, and NS EL2)
+
+Once the reset parameter has been used, and/or custom programming has been
+implemented - using these bits will result in the EL bits for address
+comparator 0 being set in the same way.
+
+Note b) Bits 2-3, 8-10, 15-16, 18, 22, control features that only work with
+data trace. As A profile data trace is architecturally prohibited in ETMv4,
+these have been omitted here. Possible uses could be where a kernel has
+support for control of R or M profile infrastructure as part of a heterogeneous
+system.
+
+Bits 17, 28-29 are unused.
+
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight/coresight.txt
similarity index 100%
rename from Documentation/trace/coresight.txt
rename to Documentation/trace/coresight/coresight.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e3c4b4..777b77fde29b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1582,8 +1582,7 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
L: linux-arm-kernel@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/*
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.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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