* Re: [PATCH 08/13] swiotlb-xen: always use dma-direct helpers to alloc coherent pages
From: Boris Ostrovsky @ 2019-09-03 22:25 UTC (permalink / raw)
To: Christoph Hellwig, Stefano Stabellini, Konrad Rzeszutek Wilk,
Juergen Gross
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <5799ca4b-7993-b1c5-73fa-396a560f58e8@oracle.com>
(Now with correct address for Juergen)
On 9/3/19 6:15 PM, Boris Ostrovsky wrote:
> On 9/2/19 9:03 AM, Christoph Hellwig wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index b8808677ae1d..f9dd4cb6e4b3 100644
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>> * address. In fact on ARM virt_to_phys only works for kernel direct
>> * mapped RAM memory. Also see comment below.
>> */
>> - ret = xen_alloc_coherent_pages(hwdev, size, dma_handle, flags, attrs);
>> -
>> + ret = dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
>
> If I am reading __dma_direct_alloc_pages() correctly there is a path
> that will force us to use GFP_DMA32 and as Juergen pointed out in
> another message that may not be desirable.
>
> -boris
>
>
>
_______________________________________________
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 v1 1/3] perf cs-etm: Refactor instruction size handling
From: Mathieu Poirier @ 2019-09-03 22:22 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Alexander Shishkin, linux-kernel,
Arnaldo Carvalho de Melo, Adrian Hunter, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190830062421.31275-2-leo.yan@linaro.org>
On Fri, Aug 30, 2019 at 02:24:19PM +0800, Leo Yan wrote:
> There has several code pieces need to know the instruction size, but
> now every place calculates the instruction size separately.
>
> This patch refactors to create a new function cs_etm__instr_size() as
> a central place to analyze the instruction length based on ISA type
> and instruction value.
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
> 1 file changed, 30 insertions(+), 14 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index b3a5daaf1a8f..882a0718033d 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
> return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> }
>
> +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> + u8 trace_chan_id,
> + enum cs_etm_isa isa,
> + u64 addr)
> +{
> + int insn_len;
> +
> + /*
> + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> + * cs_etm__t32_instr_size().
> + */
> + if (isa == CS_ETM_ISA_T32)
> + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> + else
> + insn_len = 4;
> +
> + return insn_len;
> +}
> +
> static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> {
> /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> @@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> const struct cs_etm_packet *packet,
> u64 offset)
> {
> + int insn_len;
> +
> if (packet->isa == CS_ETM_ISA_T32) {
> u64 addr = packet->start_addr;
>
> while (offset > 0) {
> - addr += cs_etm__t32_instr_size(etmq,
> - trace_chan_id, addr);
> + addr += cs_etm__instr_size(etmq, trace_chan_id,
> + packet->isa, addr);
> offset--;
> }
> return addr;
> }
>
> - /* Assume a 4 byte instruction size (A32/A64) */
> - return packet->start_addr + offset * 4;
> + /* Return instruction size for A32/A64 */
> + insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> + packet->isa, packet->start_addr);
> + return packet->start_addr + offset * insn_len;
This patch will work but from where I stand it makes things difficult to
understand more than anything else. It is also adding coupling between function
cs_etm__instr_addr() and cs_etm__instr_size(), meaning the code needs to be
carefully inspected in order to make changes to either one.
Last but not least function cs_etm__instr_size() isn't used in the upcoming
patches. I really don't see what is gained here.
Thanks,
Mathieu
> }
>
> static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
> @@ -1090,16 +1114,8 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> return;
> }
>
> - /*
> - * T32 instruction size might be 32-bit or 16-bit, decide by calling
> - * cs_etm__t32_instr_size().
> - */
> - if (packet->isa == CS_ETM_ISA_T32)
> - sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> - sample->ip);
> - /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> - else
> - sample->insn_len = 4;
> + sample->insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> + packet->isa, sample->ip);
>
> cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
> sample->insn_len, (void *)sample->insn);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/13] swiotlb-xen: always use dma-direct helpers to alloc coherent pages
From: Boris Ostrovsky @ 2019-09-03 22:15 UTC (permalink / raw)
To: Christoph Hellwig, Stefano Stabellini, Konrad Rzeszutek Wilk,
gross
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <20190902130339.23163-9-hch@lst.de>
On 9/2/19 9:03 AM, Christoph Hellwig wrote:
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b8808677ae1d..f9dd4cb6e4b3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> * address. In fact on ARM virt_to_phys only works for kernel direct
> * mapped RAM memory. Also see comment below.
> */
> - ret = xen_alloc_coherent_pages(hwdev, size, dma_handle, flags, attrs);
> -
> + ret = dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
If I am reading __dma_direct_alloc_pages() correctly there is a path
that will force us to use GFP_DMA32 and as Juergen pointed out in
another message that may not be desirable.
-boris
_______________________________________________
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 v1 2/3] perf cs-etm: Add callchain to instruction sample
From: Mathieu Poirier @ 2019-09-03 22:07 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Alexander Shishkin, linux-kernel,
Arnaldo Carvalho de Melo, Adrian Hunter, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190830062421.31275-3-leo.yan@linaro.org>
On Fri, Aug 30, 2019 at 02:24:20PM +0800, Leo Yan wrote:
> Firstly, this patch adds support for the thread stack; when every branch
> packet is coming we will push or pop the stack based on the sample
> flags.
>
> Secondly, based on the thread stack we can synthesize call chain for the
> instruction sample, this can be used by itrace option '--itrace=g'.
>
In most cases using the word "secondly" is a good indication the patch should be
split.
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/util/cs-etm.c | 74 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 882a0718033d..ad573d3bd305 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -17,6 +17,7 @@
> #include <stdlib.h>
>
> #include "auxtrace.h"
> +#include "callchain.h"
> #include "color.h"
> #include "cs-etm.h"
> #include "cs-etm-decoder/cs-etm-decoder.h"
> @@ -69,6 +70,7 @@ struct cs_etm_traceid_queue {
> size_t last_branch_pos;
> union perf_event *event_buf;
> struct thread *thread;
> + struct ip_callchain *chain;
> struct branch_stack *last_branch;
> struct branch_stack *last_branch_rb;
> struct cs_etm_packet *prev_packet;
> @@ -246,6 +248,16 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue *etmq,
> if (!tidq->prev_packet)
> goto out_free;
>
> + if (etm->synth_opts.callchain) {
> + size_t sz = sizeof(struct ip_callchain);
> +
> + /* Add 1 to callchain_sz for callchain context */
> + sz += (etm->synth_opts.callchain_sz + 1) * sizeof(u64);
> + tidq->chain = zalloc(sz);
> + if (!tidq->chain)
> + goto out_free;
> + }
> +
> if (etm->synth_opts.last_branch) {
> size_t sz = sizeof(struct branch_stack);
>
> @@ -270,6 +282,7 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue *etmq,
> zfree(&tidq->last_branch);
> zfree(&tidq->prev_packet);
> zfree(&tidq->packet);
> + zfree(&tidq->chain);
> out:
> return rc;
> }
> @@ -541,6 +554,7 @@ static void cs_etm__free_traceid_queues(struct cs_etm_queue *etmq)
> zfree(&tidq->last_branch_rb);
> zfree(&tidq->prev_packet);
> zfree(&tidq->packet);
> + zfree(&tidq->chain);
> zfree(&tidq);
>
> /*
> @@ -1121,6 +1135,41 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> sample->insn_len, (void *)sample->insn);
> }
>
> +static void cs_etm__add_stack_event(struct cs_etm_queue *etmq,
> + struct cs_etm_traceid_queue *tidq)
> +{
> + struct cs_etm_auxtrace *etm = etmq->etm;
> + u8 trace_chan_id = tidq->trace_chan_id;
> + int insn_len;
> + u64 from_ip, to_ip;
> +
> + if (etm->synth_opts.callchain || etm->synth_opts.thread_stack) {
> +
> + from_ip = cs_etm__last_executed_instr(tidq->prev_packet);
> + to_ip = cs_etm__first_executed_instr(tidq->packet);
> +
> + /*
> + * T32 instruction size might be 32-bit or 16-bit, decide by
> + * calling cs_etm__t32_instr_size().
> + */
> + if (tidq->prev_packet->isa == CS_ETM_ISA_T32)
> + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> + from_ip);
> + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> + else
> + insn_len = 4;
> +
> + thread_stack__event(tidq->thread, tidq->prev_packet->cpu,
> + tidq->prev_packet->flags,
> + from_ip, to_ip, insn_len,
> + etmq->buffer->buffer_nr);
> + } else {
> + thread_stack__set_trace_nr(tidq->thread,
> + tidq->prev_packet->cpu,
> + etmq->buffer->buffer_nr);
Please add a comment on what the above does. As a rule of thumb I add a comment
per addition in a patch in order to help people understand what is happening and
some of the reasonning behing the code.
> + }
> +}
> +
> static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> struct cs_etm_traceid_queue *tidq,
> u64 addr, u64 period)
> @@ -1146,6 +1195,14 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>
> cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
>
> + if (etm->synth_opts.callchain) {
> + thread_stack__sample(tidq->thread, tidq->packet->cpu,
> + tidq->chain,
> + etm->synth_opts.callchain_sz + 1,
> + sample.ip, etm->kernel_start);
> + sample.callchain = tidq->chain;
> + }
> +
> if (etm->synth_opts.last_branch) {
> cs_etm__copy_last_branch_rb(etmq, tidq);
> sample.branch_stack = tidq->last_branch;
> @@ -1329,6 +1386,8 @@ static int cs_etm__synth_events(struct cs_etm_auxtrace *etm,
> attr.sample_type &= ~(u64)PERF_SAMPLE_ADDR;
> }
>
> + if (etm->synth_opts.callchain)
> + attr.sample_type |= PERF_SAMPLE_CALLCHAIN;
> if (etm->synth_opts.last_branch)
> attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
>
> @@ -1397,6 +1456,9 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> tidq->period_instructions = instrs_over;
> }
>
> + if (tidq->prev_packet->last_instr_taken_branch)
> + cs_etm__add_stack_event(etmq, tidq);
> +
> if (etm->sample_branches) {
> bool generate_sample = false;
>
> @@ -2596,7 +2658,17 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
> } else {
> itrace_synth_opts__set_default(&etm->synth_opts,
> session->itrace_synth_opts->default_no_sample);
> - etm->synth_opts.callchain = false;
> +
> + etm->synth_opts.thread_stack =
> + session->itrace_synth_opts->thread_stack;
> + }
> +
> + if (etm->synth_opts.callchain && !symbol_conf.use_callchain) {
> + symbol_conf.use_callchain = true;
> + if (callchain_register_param(&callchain_param) < 0) {
> + symbol_conf.use_callchain = false;
> + etm->synth_opts.callchain = false;
> + }
> }
>
> err = cs_etm__synth_events(etm, session);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] arm64: atomics: avoid out-of-line ll/sc atomics
From: Andrew Murray @ 2019-09-03 22:04 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, peterz, catalin.marinas, ndesaulniers,
Ard.Biesheuvel, Nathan Chancellor, robin.murphy, linux-arm-kernel
In-Reply-To: <20190903163753.huk5sjg4m27qu2zu@willie-the-truck>
On Tue, Sep 03, 2019 at 05:37:55PM +0100, Will Deacon wrote:
> On Tue, Sep 03, 2019 at 04:31:20PM +0100, Andrew Murray wrote:
> > On Tue, Sep 03, 2019 at 04:15:44PM +0100, Andrew Murray wrote:
> > > On Tue, Sep 03, 2019 at 03:45:34PM +0100, Will Deacon wrote:
> > > > Does it work if the only thing you change is the toolchain, and use GCC
> > > > instead?
> > >
> > > Yup.
> >
> > Also this is Clang generation:
> >
> > ffff8000100f2700 <__ptrace_link>:
> > ffff8000100f2700: f9426009 ldr x9, [x0, #1216]
> > ffff8000100f2704: 91130008 add x8, x0, #0x4c0
> > ffff8000100f2708: eb09011f cmp x8, x9
> > ffff8000100f270c: 540002a1 b.ne ffff8000100f2760 <__ptrace_link+0x60> // b.any
> > ffff8000100f2710: f9425829 ldr x9, [x1, #1200]
> > ffff8000100f2714: 9112c02a add x10, x1, #0x4b0
> > ffff8000100f2718: f9000528 str x8, [x9, #8]
> > ffff8000100f271c: f9026009 str x9, [x0, #1216]
> > ffff8000100f2720: f902640a str x10, [x0, #1224]
> > ffff8000100f2724: f9025828 str x8, [x1, #1200]
> > ffff8000100f2728: f9024001 str x1, [x0, #1152]
> > ffff8000100f272c: b4000162 cbz x2, ffff8000100f2758 <__ptrace_link+0x58>
> > ffff8000100f2730: b900985f str wzr, [x2, #152]
> > ffff8000100f2734: 14000004 b ffff8000100f2744 <__ptrace_link+0x44>
> > ffff8000100f2738: 14000001 b ffff8000100f273c <__ptrace_link+0x3c>
> > ffff8000100f273c: 14000006 b ffff8000100f2754 <__ptrace_link+0x54>
> > ffff8000100f2740: 14000001 b ffff8000100f2744 <__ptrace_link+0x44>
> > ffff8000100f2744: 52800028 mov w8, #0x1 // #1
> > ffff8000100f2748: b828005f stadd w8, [x2]
> > ffff8000100f274c: f9030002 str x2, [x0, #1536]
> > ffff8000100f2750: d65f03c0 ret
> > ffff8000100f2754: 140007fd b ffff8000100f4748 <ptrace_check_attach+0xf8>
> > ...
> >
> > This looks like the default path (before we write over it) will take you to
> > the LSE code (e.g. ffff8000100f2734). I'm pretty sure this is wrong, or at
> > least not what we expected to see. Also why 4 branches?
>
> So I reproduced this with a silly atomic_inc wrapper:
>
> void will_atomic_inc(atomic_t *v)
> {
> atomic_inc(v);
> }
>
> Compiles to:
>
> 0000000000000018 <will_atomic_inc>:
> 18: 14000004 b 28 <will_atomic_inc+0x10>
> 1c: 14000001 b 20 <will_atomic_inc+0x8>
> 20: 14000005 b 34 <will_atomic_inc+0x1c>
> 24: 14000001 b 28 <will_atomic_inc+0x10>
> 28: 52800028 mov w8, #0x1 // #1
> 2c: b828001f stadd w8, [x0]
> 30: d65f03c0 ret
> 34: 14000027 b d0 <dump_kernel_offset+0x60>
> 38: d65f03c0 ret
>
> which is going to explode.
I've come up with a simple reproducer for this issue:
static bool branch_jump()
{
asm_volatile_goto(
"1: b %l[l_yes2]"
: : : : l_yes2);
return false;
l_yes2:
return true;
}
static bool branch_test()
{
return (!branch_jump() && !branch_jump());
}
void andy_test(int *v)
{
if (branch_test())
*v = 0xff;
}
This leads to the following (it shouldn't do anything):
0000000000000000 <andy_test>:
0: 14000004 b 10 <andy_test+0x10>
4: 14000001 b 8 <andy_test+0x8>
8: 14000004 b 18 <andy_test+0x18>
c: 14000001 b 10 <andy_test+0x10>
10: 52801fe8 mov w8, #0xff // #255
14: b9000008 str w8, [x0]
18: d65f03c0 ret
The issue goes away with any of the following hunks:
@@ -55,7 +55,7 @@ static bool branch_jump()
static bool branch_test()
{
- return (!branch_jump() && !branch_jump());
+ return (!branch_jump());
}
void andy_test(int *v)
or:
@@ -53,14 +53,10 @@ static bool branch_jump()
return true;
}
-static bool branch_test()
-{
- return (!branch_jump() && !branch_jump());
-}
void andy_test(int *v)
{
- if (branch_test())
+ if (!branch_jump() && !branch_jump())
*v = 0xff;
}
Thanks,
Andrew Murray
>
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] soc: amlogic: updates for v5.4 (round 2)
From: Kevin Hilman @ 2019-09-03 22:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <CAK8P3a0_HEhvVk8Onk-9MBhnaBQT9B39+t6AGA3FRrH-_yMqVg@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
> On Fri, Aug 30, 2019 at 1:34 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> OK, here's the respin (round 2.1)
>>
>> The previous version was missing the bindings for the new driver, which
>> I had mistakenly put in the DT branch instead of here. Without the
>> bindings and associated headers, this branch did not build stanalone
>> (found by kbuild robot.)
>>
>> All that is fixed by this branch.
>>
>> As a result, I also needed to respin the DT64 pull. Since I moved the
>> bindings/header patche here, the respin of the DT64 pull will now have a
>> dependency merge of this branch.
>
> I've pulled round 2.1 into arm/drivers, but it seems that the
> patchwork integration
> failed to deal with the way this was sent:
>
> - https://patchwork.kernel.org/patch/11122205/ shows both the original
> pull request, and the updated one. It was meant to detect both pull
> requests as the same thing and mark the old one as superseded, but that
> did not happen.
>
> - Using pwclient to get the pull request only shows the original one
>
> - I actually tried pulling that after looking at it with pwclient instead of
> the email client. Thankfully, you had removed the original tag, so that
> failed and I took a closer look.
>
> I suspect it would have worked the way it did for
> https://patchwork.kernel.org/patch/11119171/ if you had specified
> the subject as
>
> [GIT PULL, v2] soc: amlogic: updates for v5.4 (round 2)
>
> i.e. kept the subject the same but the version inside of the [].
Ah, ok. Good to know.
Thanks,
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 v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Stephen Boyd @ 2019-09-03 21:45 UTC (permalink / raw)
To: Jack Pham, Jorge Ramirez
Cc: mark.rutland, robh, kishon, gregkh, linux-usb, khasim.mohammed,
linux-kernel, Bjorn Andersson, devicetree, linux-arm-msm,
andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <20190903173924.GB9754@jackp-linux.qualcomm.com>
Quoting Jack Pham (2019-09-03 10:39:24)
> On Mon, Sep 02, 2019 at 08:23:04AM +0200, Jorge Ramirez wrote:
> > On 8/30/19 20:28, Stephen Boyd wrote:
> > > Quoting Bjorn Andersson (2019-08-30 09:45:20)
> > >> On Fri 30 Aug 09:01 PDT 2019, Stephen Boyd wrote:
> > >>
> > >>>>>
> > >>>>> The USB-C connector is attached both to the HS and SS PHYs, so I think
> > >>>>> you should represent this external to this node and use of_graph to
> > >>>>> query it.
> > >>>>
> > >>>> but AFAICS we wont be able to retrieve the vbux-supply from an external
> > >>>> node (that interface does not exist).
> > >>>>
> > >>>> rob, do you have a suggestion?
> > >>>
> > >>> Shouldn't the vbus supply be in the phy? Or is this a situation where
> > >>> the phy itself doesn't have the vbus supply going to it because the PMIC
> > >>> gets in the way and handles the vbus for the connector by having the SoC
> > >>> communicate with the PMIC about when to turn the vbus on and off, etc?
> > >>>
> > >>
> > >> That's correct, the VBUS comes out of the PMIC and goes directly to the
> > >> connector.
> > >>
> > >> The additional complicating factor here is that the connector is wired
> > >> to a USB2 phy as well, so we need to wire up detection and vbus control
> > >> to both of them - but I think this will be fine, if we can only figure
> > >> out a sane way of getting hold of the vbus-supply.
> > >>
> > >
> > > Does it really matter to describe this situation though? Maybe it's
> > > simpler to throw the vbus supply into the phy and control it from the
> > > phy driver, even if it never really goes there. Or put it into the
> > > toplevel usb controller?
> > >
> > that would work for me - the connector definition seemed a better way to
> > explain the connectivity but since we cant retrieve the supply from the
> > external node is not of much functional use.
> >
> > but please let me know how to proceed. shall I add the supply back to
> > the phy?
So does the vbus actually go to the phy? I thought it never went there
and the power for the phy was different (and possibly lower in voltage).
>
> Putting it in the toplevel usb node makes sense to me, since that's
> usually the driver that knows when it's switching into host mode and
> needs to turn on VBUS. The dwc3-qcom driver & bindings currently don't
> do this but there's precedent in a couple of the other dwc3 "glues"--see
> Documentation/devicetree/bindings/usb/{amlogic\,dwc3,omap-usb}.txt
>
> One exception is if the PMIC is also USB-PD capable and can do power
> role swap, in which case the VBUS control needs to be done by the TCPM,
> so that'd be a case where having vbus-supply in the connector node might
> make more sense.
>
The other way is to implement the code to get the vbus supply out of a
connector. Then any driver can do the work if it knows it needs to and
we don't have to care that the vbus isn't going somewhere. I suppose
that would need an of_regulator_get() sort of API that can get the
regulator out of there? Or to make the connector into a struct device
that can get the regulator out per some generic connector driver and
then pass it through to the USB controller when it asks for it. Maybe
try to prototype that out?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: Amlogic updates for v5.4 (round 2)
From: Arnd Bergmann @ 2019-09-03 21:17 UTC (permalink / raw)
To: Kevin Hilman
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <7hv9ufmthb.fsf@baylibre.com>
On Fri, Aug 30, 2019 at 1:39 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Arnd, Olof,
>
> Kevin Hilman <khilman@baylibre.com> writes:
>
> > Another (final) round of 64-bit DT updates for Amlogic SoCs for v5.4.
> > Highlights are in the tag description, but of note is a tag pulled in
> > from the clock tree due to a handful of new clocks used for DVFS and
> > power domains.
>
> Here's the promised respin (round 2.1):
>
> In addition to the clock dependency listed above, this branch adds a
> bunch of DT users of a new PM domain driver, which has new bindings and
> DT headers added in my drivers PR. That drivers branch is also merged
> here to ensure this branch builds standlone also.
>
> Sorry for the noise on the first attempt.
>
Pulled manually into arm/dt now, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PULL 2/5] Renesas ARM SoC updates for v5.4
From: Arnd Bergmann @ 2019-09-03 21:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
Linux ARM
In-Reply-To: <20190823123643.18799-3-geert+renesas@glider.be>
On Fri, Aug 23, 2019 at 2:36 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Renesas ARM SoC updates for v5.4
>
> - Low-level debugging support for RZ/A2M.
>
Pulled into arm/soc, thanks!
This should be the last of your pull requests for the moment. Can you check that
everything is there once it hits linux-next (probably Wednesday, I may have just
missed today).
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: soc: Xilinx SoC changes for v5.4
From: Arnd Bergmann @ 2019-09-03 21:11 UTC (permalink / raw)
To: Michal Simek; +Cc: SoC Team, arm-soc, linux-arm
In-Reply-To: <8e00ba70-9403-4bf7-2870-a94758e37346@monstr.eu>
On Tue, Sep 3, 2019 at 4:19 PM Michal Simek <monstr@monstr.eu> wrote:
> ARM: Xilinx Zynq SoC patches for v5.4
>
> - Fix SMP trampoline code when FORTIFY_SOURCE is enabled
This looks quite hacky, but I don't really have a better idea here either,
the problem was already in the way it uses ioremap() to map
what is presumably just RAM. (if it's not RAM, the patch is also
required for other reasons).
----------------------------------------------------------------
> Luis Araneda (2):
> ARM: zynq: Support smp in thumb mode
> ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
Pulled into arm/soc, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v5.4 (#2)
From: Arnd Bergmann @ 2019-09-03 21:05 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, Marek Behún, SoC Team, arm-soc,
Olof Johansson, Linux ARM, Sebastian Hesselbarth
In-Reply-To: <87h85two0r.fsf@FE-laptop>
On Tue, Sep 3, 2019 at 2:41 PM Gregory CLEMENT
<gregory.clement@bootlin.com> wrote:
> Here is the second pull request for dt64 for mvebu for v5.4.
>
> For the Turris Mox board there was dependencies with moxtet header which
> was already merged in your arm/drivers branch. That the reason why I
> merged this branch in my mvebu/dt64 branch.
>
> Let me know if it is a problem and if you want that I do it in a
> different way.
I don't really like this, but it's too late to do it right now. The problem is
that I should have not picked up the patches from the list in the first
place if there are these dependencies.
This could have been communicated better in the patch series, but
it really my own fault.
> ----------------------------------------------------------------
> mvebu dt64 for 5.4 (part 2)
>
> Add support for Turris Mox board (Armada 3720 SoC based)
>
> ----------------------------------------------------------------
> Marek Behún (3):
> arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
> dt-bindings: marvell: document Turris Mox compatible
> arm64: dts: marvell: add DTS for Turris Mox
I think the best way forward would be for me to apply the
remaining patches on top of the arm/drivers branch, to avoid
also pulling in your other DT changes into arm/drivers, or pulling
in all of arm/drivers into arm/dt.
Would that work for you?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/8] mips: compat: vdso: Use legacy syscalls as fallback
From: Paul Burton @ 2019-09-03 21:00 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch@vger.kernel.org, Paul Burton, luto@kernel.org,
catalin.marinas@arm.com, 0x7f454c46@gmail.com,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
linux-kselftest@vger.kernel.org, tglx@linutronix.de,
salyzyn@android.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190830135902.20861-4-vincenzo.frascino@arm.com>
Hello,
Vincenzo Frascino wrote:
> The generic VDSO implementation uses the Y2038 safe clock_gettime64() and
> clock_getres_time64() syscalls as fallback for 32bit VDSO. This breaks
> seccomp setups because these syscalls might be not (yet) allowed.
>
> Implement the 32bit variants which use the legacy syscalls and select the
> variant in the core library.
>
> The 64bit time variants are not removed because they are required for the
> time64 based vdso accessors.
Applied to mips-next.
> commit 932bb934ed4d
> https://git.kernel.org/mips/c/932bb934ed4d
>
> Fixes: 00b26474c2f1 ("lib/vdso: Provide generic VDSO implementation")
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/7] i.MX drivers update for 5.4
From: Arnd Bergmann @ 2019-09-03 20:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-1-shawnguo@kernel.org>
On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> i.MX drivers update for 5.4:
> - A series from Anson Huang to add UID support for i.MX8 SoC and SCU
> drivers.
> - A series from Daniel Baluta to add DSP IPC driver for communication
> between host AP (Linux) and the firmware running on DSP embedded in
> i.MX8 SoCs.
> - A small fix for GPCv2 error code printing.
> - Switch from module_platform_driver_probe() to module_platform_driver()
> for imx-weim driver, as we need the driver to probe again when device
> is present later.
> - Add optional burst clock mode support for imx-weim driver.
Pulled into arm/drivers.
The module_platform_driver_probe() change looks like it should have been
in a bugfix branch, and I think there were some other patches that would
qualify in your other pull requests:
a95fbda08ee2 ("ARM: dts: imx7-colibri: disable HS400")
9846a4524ac9 ("ARM: dts: imx7d: cl-som-imx7: make ethernet work again")
7cb220a75ff3 ("arm64: dts: lx2160a: Fix incorrect I2C clock divider")
f64697bd0b9e ("arm64: dts: ls1028a: fix gpio nodes")
There may have been good reasons to not include them in the fixes
pull request, but my feeling is that you could be a little more aggressive
in categorizing bugfixes for backports or adding Cc:stable tags.
Thanks,
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] soc: amlogic: updates for v5.4 (round 2)
From: Arnd Bergmann @ 2019-09-03 20:40 UTC (permalink / raw)
To: Kevin Hilman
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <7h5zmfo8au.fsf@baylibre.com>
On Fri, Aug 30, 2019 at 1:34 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> OK, here's the respin (round 2.1)
>
> The previous version was missing the bindings for the new driver, which
> I had mistakenly put in the DT branch instead of here. Without the
> bindings and associated headers, this branch did not build stanalone
> (found by kbuild robot.)
>
> All that is fixed by this branch.
>
> As a result, I also needed to respin the DT64 pull. Since I moved the
> bindings/header patche here, the respin of the DT64 pull will now have a
> dependency merge of this branch.
I've pulled round 2.1 into arm/drivers, but it seems that the
patchwork integration
failed to deal with the way this was sent:
- https://patchwork.kernel.org/patch/11122205/ shows both the original
pull request, and the updated one. It was meant to detect both pull
requests as the same thing and mark the old one as superseded, but that
did not happen.
- Using pwclient to get the pull request only shows the original one
- I actually tried pulling that after looking at it with pwclient instead of
the email client. Thankfully, you had removed the original tag, so that
failed and I took a closer look.
I suspect it would have worked the way it did for
https://patchwork.kernel.org/patch/11119171/ if you had specified
the subject as
[GIT PULL, v2] soc: amlogic: updates for v5.4 (round 2)
i.e. kept the subject the same but the version inside of the [].
Arnd
_______________________________________________
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] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Jonas Karlman @ 2019-09-03 20:33 UTC (permalink / raw)
To: Jernej Škrabec, Neil Armstrong, Cheng-Yi Chiang
Cc: alsa-devel@alsa-project.org, tzungbi@chromium.org,
kuninori.morimoto.gx@renesas.com, zhengxing@rock-chips.com,
cain.cai@rock-chips.com, airlied@linux.ie, sam@ravnborg.org,
jeffy.chen@rock-chips.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, dianders@chromium.org,
a.hajda@samsung.com, eddie.cai@rock-chips.com,
Laurent.pinchart@ideasonboard.com, daniel@ffwll.ch, Yakir Yang,
enric.balletbo@collabora.com, linux-rockchip@lists.infradead.org,
dgreid@chromium.org, kuankuan.y@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <19353031.SdOy5F5fmg@jernej-laptop>
On 2019-09-03 20:08, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
>> Hi,
>>
>> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
>>> Hi,
>>>
>>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
>>>> From: Yakir Yang <ykk@rock-chips.com>
>>>>
>>>> When transmitting IEC60985 linear PCM audio, we configure the
>>>> Audio Sample Channel Status information of all the channel
>>>> status bits in the IEC60958 frame.
>>>> Refer to 60958-3 page 10 for frequency, original frequency, and
>>>> wordlength setting.
>>>>
>>>> This fix the issue that audio does not come out on some monitors
>>>> (e.g. LG 22CV241)
>>>>
>>>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>>>> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
>>>> ---
>>>>
>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++++++++++++++++++++++
>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++++++++
>>>> 2 files changed, 79 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>>>> bd65d0479683..34d46e25d610 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
>>>> freq, unsigned long pixel_clk)>>
>>>> return n;
>>>>
>>>> }
>>>>
>>>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
>>>> +{
>>>> + u8 aud_schnl_samplerate;
>>>> + u8 aud_schnl_8;
>>>> +
>>>> + /* These registers are on RK3288 using version 2.0a. */
>>>> + if (hdmi->version != 0x200a)
>>>> + return;
>>> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
>>> SoCs ?
>> After investigations, Amlogic sets these registers on their 2.0a version
>> aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
>> < 2.0a and > 2.0a IPs versions.
>>
>> Can you check on the Rockchip IP versions in RK3399 ?
>>
>> For reference, the HDMI 1.4a IP version allwinner setups is:
>> https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/vide
>> o/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539 (registers a
>> "scrambled" but a custom bit can reset to the original mapping, 0x1066 ...
>> 0x106f)
> For easier reading, here is similar, but annotated version: http://ix.io/1Ub6
> Check function bsp_hdmi_audio().
>
> Unless there is a special reason, you can just remove that check.
Agree, this check should not be needed, AUDSCHNLS7 used to be configured in my old
multi-channel patches that have seen lot of testing on Amlogic, Allwinner and Rockchip SoCs.
>
> Best regards,
> Jernej
>
>> Neil
>>
>>>> +
>>>> + switch (hdmi->sample_rate) {
>>>> + case 32000:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
>>>> + break;
>>>> + case 44100:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
>>>> + break;
>>>> + case 48000:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
>>>> + break;
>>>> + case 88200:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
>>>> + break;
>>>> + case 96000:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
>>>> + break;
>>>> + case 176400:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
>>>> + break;
>>>> + case 192000:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
>>>> + break;
>>>> + case 768000:
>>>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
>>>> + break;
>>>> + default:
>>>> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
>>>> + hdmi->sample_rate);
>>>> + return;
>>>> + }
>>>> +
>>>> + /* set channel status register */
>>>> + hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
>>>> + HDMI_FC_AUDSCHNLS7);
>>>> +
>>>> + /*
>>>> + * Set original frequency to be the same as frequency.
>>>> + * Use one-complement value as stated in IEC60958-3 page 13.
>>>> + */
>>>> + aud_schnl_8 = (~aud_schnl_samplerate) <<
>>>> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
>>>> +
>>>> + /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
>>>> + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
This looks wrong, user can use 16 and 24 bit wide audio streams.
>>>> +
>>>> + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
>>>> +}
>>>> +
>>>>
>>>> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
>>>>
>>>> unsigned long pixel_clk, unsigned int sample_rate)
>>>>
>>>> {
>>>>
>>>> @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
>>>> *hdmi,>>
>>>> hdmi->audio_cts = cts;
>>>> hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
>>>> spin_unlock_irq(&hdmi->audio_lock);
>>>>
>>>> +
>>>> + hdmi_set_schnl(hdmi);
I will suggest this function is called from or merged with dw_hdmi_set_sample_rate().
Similar to how AUDSCONF and AUDICONF0 is configured from dw_hdmi_set_channel_count().
Regards,
Jonas
>>>>
>>>> }
>>>>
>>>> static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
>>>> 6988f12d89d9..619ebc1c8354 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> @@ -158,6 +158,17 @@
>>>>
>>>> #define HDMI_FC_SPDDEVICEINF 0x1062
>>>> #define HDMI_FC_AUDSCONF 0x1063
>>>> #define HDMI_FC_AUDSSTAT 0x1064
>>>>
>>>> +#define HDMI_FC_AUDSV 0x1065
>>>> +#define HDMI_FC_AUDSU 0x1066
>>>> +#define HDMI_FC_AUDSCHNLS0 0x1067
>>>> +#define HDMI_FC_AUDSCHNLS1 0x1068
>>>> +#define HDMI_FC_AUDSCHNLS2 0x1069
>>>> +#define HDMI_FC_AUDSCHNLS3 0x106a
>>>> +#define HDMI_FC_AUDSCHNLS4 0x106b
>>>> +#define HDMI_FC_AUDSCHNLS5 0x106c
>>>> +#define HDMI_FC_AUDSCHNLS6 0x106d
>>>> +#define HDMI_FC_AUDSCHNLS7 0x106e
>>>> +#define HDMI_FC_AUDSCHNLS8 0x106f
>>>>
>>>> #define HDMI_FC_DATACH0FILL 0x1070
>>>> #define HDMI_FC_DATACH1FILL 0x1071
>>>> #define HDMI_FC_DATACH2FILL 0x1072
>>>>
>>>> @@ -706,6 +717,15 @@ enum {
>>>>
>>>> /* HDMI_FC_AUDSCHNLS7 field values */
>>>>
>>>> HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
>>>> HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
>>>>
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2,
>>>> + HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0,
>>>>
>>>> /* HDMI_FC_AUDSCHNLS8 field values */
>>>>
>>>> HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm: mediatek: soc driver updates for v5.4
From: Arnd Bergmann @ 2019-09-03 20:20 UTC (permalink / raw)
To: Matthias Brugger
Cc: SoC Team, arm-soc, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, Bibby Hsieh
In-Reply-To: <8c860e37-3816-d75f-fc37-ce496905ba73@gmail.com>
On Fri, Aug 23, 2019 at 6:43 PM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> cmdq helper:
> reoder function parameter and change size of the parameters
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Allwinner Drivers Changes for 5.4
From: Arnd Bergmann @ 2019-09-03 20:18 UTC (permalink / raw)
To: Maxime Ripard; +Cc: SoC Team, arm-soc, Chen-Yu Tsai, Linux ARM
In-Reply-To: <f9edfc8e-19b7-4b6e-897a-35f3bdcc8643.lettre@localhost>
On Fri, Aug 23, 2019 at 4:33 PM Maxime Ripard <mripard@kernel.org> wrote:
> ----------------------------------------------------------------
> Allwinner drivers patches for 5.4
>
> One driver to remove a redundant error message in the Allwinner RSB
> driver.
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PULL 4/5] Renesas driver updates for v5.4 (take two)
From: Arnd Bergmann @ 2019-09-03 20:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
Linux ARM
In-Reply-To: <20190823123643.18799-5-geert+renesas@glider.be>
On Fri, Aug 23, 2019 at 2:36 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Renesas driver updates for v5.4 (take two)
>
> - Improve "always-on" PM Domain handling on SH/R-Mobile SoCs,
> - Automatic errata selection for Cortex-A7/A9,
> - Small fixes and improvements.
>
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] soc: amlogic: driver updates for v5.4
From: Arnd Bergmann @ 2019-09-03 20:14 UTC (permalink / raw)
To: Kevin Hilman
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <7h7e77cwv5.fsf@baylibre.com>
On Wed, Aug 21, 2019 at 12:09 AM Kevin Hilman <khilman@baylibre.com> wrote:
> ----------------------------------------------------------------
> soc: amlogic: driver updates for v5.4
>
> Highlights
> - clk-measure: support new S905X3 and A311D SoCs
> - socinfo: support new S905X3 and A311D SoCs
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
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 00/17] coresight: next v5.3-rc6
From: Greg KH @ 2019-09-03 20:02 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: linux-arm-kernel
In-Reply-To: <20190829202842.580-1-mathieu.poirier@linaro.org>
On Thu, Aug 29, 2019 at 02:28:25PM -0600, Mathieu Poirier wrote:
> Good afternoon,
>
> Please consider the following for inclusion in the v5.4 cycle.
>
> Applies correctly to the char-misc-next (d4e34999a757) branch.
All now queued up,t hanks.
greg k-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 v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Greg KH @ 2019-09-03 19:59 UTC (permalink / raw)
To: Mike Leach
Cc: mathieu.poirier, corbet, coresight, suzuki.poulose, linux-doc,
linux-arm-kernel
In-Reply-To: <20190829213321.4092-10-mike.leach@linaro.org>
On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> Update document to include the new sysfs features added during this
> patchset.
>
> Updated to reflect the new sysfs component nameing schema.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> 1 file changed, 115 insertions(+), 68 deletions(-)
>
> 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
You are renaming sysfs directories that have been around since:
> Date: April 2015
???
Really?
That's brave.
What tool did you just break?
greg k-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 v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Mathieu Poirier @ 2019-09-03 19:42 UTC (permalink / raw)
To: Mike Leach
Cc: corbet, gregkh, coresight, suzuki.poulose, linux-doc,
linux-arm-kernel
In-Reply-To: <20190829213321.4092-10-mike.leach@linaro.org>
On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> Update document to include the new sysfs features added during this
> patchset.
>
> Updated to reflect the new sysfs component nameing schema.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> 1 file changed, 115 insertions(+), 68 deletions(-)
>
> 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.
> +
I didn't notice this in the first round - please split further. So one patch to
address the etm<N> and another for adding new features.
For patches 1, 3, 4 and 8:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> +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>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.
From: Mathieu Poirier @ 2019-09-03 19:38 UTC (permalink / raw)
To: Mike Leach
Cc: corbet, gregkh, coresight, suzuki.poulose, linux-doc,
linux-arm-kernel
In-Reply-To: <20190829213321.4092-12-mike.leach@linaro.org>
Hi Mike,
On Thu, Aug 29, 2019 at 10:33:21PM +0100, Mike Leach wrote:
> Add in detailed programmers reference for users wanting to program the
> CoreSight ETM 4.x driver using sysfs.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-reference.txt | 458 ++++++++++++++++++
> 1 file changed, 458 insertions(+)
> create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.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..f0c370870992
> --- /dev/null
> +++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> @@ -0,0 +1,458 @@
> +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
I suspect things look different on your end than they do on mine. The biggest
problem is related to multi-line fields. For instance the above looks like this
on my side:
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
It would be nicer to have multi-line fields aligned with the first line, such
as:
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
I'm also not sure about the prompt, i.e "$>". I suspect it should be "$" and
an additional ">" got inserted.
I wanted to read on but is it too difficult to know what is intentional and what
isn't. Please address and resend.
Thanks,
Mathieu
> +
> +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.
> --
> 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
* [PATCH 3/3] arm64: defconfig: Enable Qualcomm QUSB2 PHY
From: Lee Jones @ 2019-09-03 19:26 UTC (permalink / raw)
To: soc; +Cc: Lee Jones, linux-kernel, linux-arm-kernel
In-Reply-To: <20190903192625.14775-1-lee.jones@linaro.org>
Tested on the Lenovo Yoga C630 where this patch enables USB.
Without it USB devices are not enumerated.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index af7ca722b519..a94d002182ee 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -770,6 +770,7 @@ CONFIG_PHY_HISTB_COMBPHY=y
CONFIG_PHY_HISI_INNO_USB2=y
CONFIG_PHY_MVEBU_CP110_COMPHY=y
CONFIG_PHY_QCOM_QMP=m
+CONFIG_PHY_QCOM_QUSB2=m
CONFIG_PHY_QCOM_USB_HS=y
CONFIG_PHY_RCAR_GEN3_PCIE=y
CONFIG_PHY_RCAR_GEN3_USB2=y
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] arm64: defconfig: Enable the EFI Framebuffer
From: Lee Jones @ 2019-09-03 19:26 UTC (permalink / raw)
To: soc; +Cc: Lee Jones, linux-kernel, linux-arm-kernel
In-Reply-To: <20190903192625.14775-1-lee.jones@linaro.org>
Tested on the Lenovo Yoga C630 where this patch enables the
framebuffer (screen/monitor). Without it the device appears
not to boot.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0fe943ac53b5..af7ca722b519 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -540,6 +540,7 @@ CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_EFI=y
CONFIG_BACKLIGHT_GENERIC=m
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_LP855X=m
--
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