We are trying to achieve more types of Coresight source devices.
For example, we have a type of coresight source devic named TPDM.
In the process of using, sometimes mulitiple TPDMs need to be
connected to the different input ports on the same funnel.
Meanwhile, these TPDMs also need to output from different
ports on the funnel.
But, at present the Coresight driver assumes
a) Only support Coresight source type ETM, ETR and ETF
b) Funnels only support mulitiple inputs and one output
Which doesn't help to add the above feature for our new Coresight
source device TPDM. So, in order to accommodate the new device,
we develop the following patches.
a) Add support more types of Coresight source devices.
b) Add support for multiple output ports on funnel and the output
ports could be selected by Corsight source.
Applies on coresight/next.
http://git.linaro.org/kernel/coresight.git/log/?h=next
Tao Zhang (3):
coresight: add support to enable more coresight paths
coresight: funnel: add support for multiple output ports
dt-bindings: arm: add property for selecting funnel output port
.../devicetree/bindings/arm/coresight.txt | 5 +
drivers/hwtracing/coresight/coresight-core.c | 169 ++++++++++++++-------
drivers/hwtracing/coresight/coresight-platform.c | 9 ++
include/linux/coresight.h | 2 +
4 files changed, 127 insertions(+), 58 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi There,
I was wondering if you can pass my email to your buying manager:
We at Dioz Group own several brands, and the one that would be of great value to you is [ https://www.oasisapparelusa.site ]( https://www.oasisapparelusa.site/ )
Not sure if you know about Oasis Apparel, we are part of PPAI and currently working with Distributors like Proforma, Geiger, Halo, helping them in manufacturing all kinds of Custom Clothing and Promotional Items Project.
Oasis is based in Beverly Hills, CA. We are the largest custom clothing manufacturer, who can give you all the backend support and help you expand your portfolio in getting some BIG custom apparel orders with the minimum quantity of only 1000 on each style:
We Specialize In Private Label For All Type Of Apparel:
- Promotional Clothing
- Fitness and Yoga Clothing
- All type of Sublimation Clothing
- Marathon, Cycling, Triathlon, Sports Clothing
- Jackets, Hoodies, and Sweat-tops
- Other products – Bags, Towels, Caps, Scarfs/Beanies, and Footwear.
Our in-house design team can look after all your designing parts too and provide some outstanding designs and presentations.
Some Top Points:
- Factory direct out of Xiamen Island, China.
- Quick Turnaround times and lower price by almost 20-30%
- Best prices and very new styles available.
- In-house design team, Quick turnaround for free designs too.
- Delivery worldwide
Let me know if you have any projects that we could team up on and give you a quote.
Thanks,
--
Elena Miller
The Dioz Group Companies
Website: [ https://www.oasisapparelusa.site ]( https://www.oasisapparelusa.site/ )
Changes since v2:
* Collect acked and reviewed-by tags from v1 that were
missed in v2
* Add comment and commit message suggestions from Suzuki
* Rebase onto next-20210510 (also applies to perf/core)
Thanks
James
James Clark (2):
perf cs-etm: Refactor timestamp variable names
perf cs-etm: Set time on synthesised samples to preserve ordering
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++---
tools/perf/util/cs-etm.c | 57 +++++++++++--------
tools/perf/util/cs-etm.h | 4 +-
3 files changed, 44 insertions(+), 35 deletions(-)
--
2.28.0
On 5/11/21 2:41 AM, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> There are several purposes of doing this:
> - dropping dependency in bug.h
> - dropping a loop by moving out panic_notifier.h
> - unload kernel.h from something which has its own domain
>
> At the same time convert users tree-wide to use new headers, although
> for the time being include new header back to kernel.h to avoid twisted
> indirected includes for existing users.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
> Acked-by: Mike Rapoport <rppt(a)linux.ibm.com>
> Acked-by: Corey Minyard <cminyard(a)mvista.com>
> Acked-by: Christian Brauner <christian.brauner(a)ubuntu.com>
> Acked-by: Arnd Bergmann <arnd(a)arndb.de>
> Acked-by: Kees Cook <keescook(a)chromium.org>
> Acked-by: Wei Liu <wei.liu(a)kernel.org>
> Acked-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
> Co-developed-by: Andrew Morton <akpm(a)linux-foundation.org>
> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
> Acked-by: Sebastian Reichel <sre(a)kernel.org>
> Acked-by: Luis Chamberlain <mcgrof(a)kernel.org>
> Acked-by: Stephen Boyd <sboyd(a)kernel.org>
> Acked-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de>
> Acked-by: Helge Deller <deller(a)gmx.de> # parisc
> ---
> v3: rebased on top of v5.13-rc1, collected a few more tags
>
> Note WRT Andrew's SoB tag above: I have added it since part of the cases
> I took from him. Andrew, feel free to amend or tell me how you want me
> to do.
>
Acked-by: Alex Elder <elder(a)kernel.org>
. . .
> diff --git a/drivers/net/ipa/ipa_smp2p.c b/drivers/net/ipa/ipa_smp2p.c
> index a5f7a79a1923..34b68dc43886 100644
> --- a/drivers/net/ipa/ipa_smp2p.c
> +++ b/drivers/net/ipa/ipa_smp2p.c
> @@ -8,6 +8,7 @@
> #include <linux/device.h>
> #include <linux/interrupt.h>
> #include <linux/notifier.h>
> +#include <linux/panic_notifier.h>
> #include <linux/soc/qcom/smem.h>
> #include <linux/soc/qcom/smem_state.h>
>
. . .
Comprobante
body { background:#FFF;}
a { color: #555555;; }
Descargar todo como.zip archivos adjuntos ( 128 kb)
se anexa el seguiente comprobante fiscal digital
Remitente: Servicio de Administración Tributaria.Hemos identificado que tienes pendiente de presentar, al 01 de Mayo de 2021, lo siguiente:
A quien corresponda
correo electronico :coresight@lists.linaro.org
SERIE Y FOLIO:
398062
FECHA DE EMISION:
11/05/2021
MONTO TOTAL:
6298.20
Servicio de Administración Tributaria,
+34 1308 808 500 Capitales y áreas metropolitanas
While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:
- U+00a0 (' '): NO-BREAK SPACE
- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
.../coresight/coresight-etm4x-reference.rst | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
index b64d9a9c79df..e8ddfc144d9a 100644
--- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
@@ -15,14 +15,14 @@ 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.
+the 'TRC' prefix.
----
:File: ``mode`` (rw)
:Trace Registers: {CONFIGR + others}
:Notes:
- Bit select trace features. See ‘mode’ section below. Bits
+ 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.
@@ -89,7 +89,7 @@ the ‘TRC’ prefix.
: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
+ uses the current 'mode' setting. Select comparator range in
control register. Error if index is odd value.
:Depends: ``mode, addr_idx``
@@ -277,7 +277,7 @@ the ‘TRC’ prefix.
: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 filter bits. Setting '1' excludes trace from the
exception level.
:Syntax:
@@ -427,7 +427,7 @@ the ‘TRC’ prefix.
:Syntax:
``echo idx > vmid_idx``
- Where idx < numvmidc
+ Where idx < numvmidc
----
@@ -628,7 +628,7 @@ the reset parameter::
-The ‘mode’ sysfs parameter.
+The 'mode' sysfs parameter.
---------------------------
This is a bitfield selection parameter that sets the overall trace mode for the
@@ -696,7 +696,7 @@ Bit assignments shown below:-
ETM_MODE_QELEM(val)
**description:**
- ‘val’ determines level of Q element support enabled if
+ 'val' determines level of Q element support enabled if
implemented by the ETM [IDR0]
@@ -780,7 +780,7 @@ Bit assignments shown below:-
----
*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
+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)
--
2.30.2
On 2021-04-16 22:47, Mike Leach wrote:
> Hi
>
> On Fri, 16 Apr 2021 at 15:16, <taozha(a)codeaurora.org> wrote:
>>
>> On 2021-04-16 19:23, Alexander Shishkin wrote:
>> > Tao Zhang <taozha(a)codeaurora.org> writes:
>> >
>> >> Add property "coresight-name" for coresight component name. This
>> >> allows coresight driver to read device name from device entries.
>> >>
>> >> Signed-off-by: Tao Zhang <taozha(a)codeaurora.org>
>> >> ---
>> >> Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
>> >> 1 file changed, 2 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>> >> b/Documentation/devicetree/bindings/arm/coresight.txt
>> >> index d711676..0e980ce 100644
>> >> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>> >> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>> >> @@ -103,6 +103,8 @@ its hardware characteristcs.
>> >> powers down the coresight component also powers down and loses its
>> >> context. This property is currently only used for the ETM 4.x
>> >> driver.
>> >>
>> >> + * coresight-name: the name of the coresight devices.
>> >
>> > Which devices? Also, is it a common practice to extend device tree
>> > definitions based on arbitrary driver needs, or should there be some
>> > sort of a discussion first?
>> >
>> > Regards,
>> > --
>> > Alex
>> Through the device tree entries, we can define their own name for any
>> coresight device. This design is mainly used to facilitate the unified
>> naming of coresight devgies across targets. e.g, without this patch,
>> we
>> can only see from sysFS there are multiple funnels, but we cannot know
>> which funnel it is based on their names from sysFS. After applying
>> this
>> patch, we can directly know what device it is by observing the device
>> name in sysFS. And the common scripts can be developed, since applying
>> this patch, the same coresight device can have the same name across
>> targets. Each developer or vendor can define the name of each
>> coresight
>> device according to their preferences and products.
>>
>> Tao
>
> 1) I am concerned that this will break the existing protocol which
> associates a fixed device type name + number with each device - i.e.
> etm0, funnel1 etc.
> This naming convention allows for generic common scripts to be
> developed - see:
> ./tools/perf/tests/shel/test_arm_coresight.sh
> This relies on the device type prefixes to iterate across all devices
> in a system - and uses the connections links that are present in each
> of the devices to determine the topology.
> Replacing these with arbitrary names will break existing scripts.
>
Yes, agree with you. The patch should not break the existing protocol.
> 2) Using the current system it is entirely possible to determine which
> specific device a given name relates to.
> e.g. ls -al /sys/bus/coresight/devices/
>
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu0 ->
> ../../../devices/platform/soc/858000.cti/cti_cpu0
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu1 ->
> ../../../devices/platform/soc/859000.cti/cti_cpu1
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu2 ->
> ../../../devices/platform/soc/85a000.cti/cti_cpu2
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu3 ->
> ../../../devices/platform/soc/85b000.cti/cti_cpu3
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys0 ->
> ../../../devices/platform/soc/810000.cti/cti_sys0
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys1 ->
> ../../../devices/platform/soc/811000.cti/cti_sys1
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm0 ->
> ../../../devices/platform/soc/85c000.etm/etm0
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm1 ->
> ../../../devices/platform/soc/85d000.etm/etm1
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm2 ->
> ../../../devices/platform/soc/85e000.etm/etm2
> lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm3 ->
> ../../../devices/platform/soc/85f000.etm/etm3
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel0 ->
> ../../../devices/platform/soc/821000.funnel/funnel0
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel1 ->
> ../../../devices/platform/soc/841000.funnel/funnel1
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 replicator0 ->
> ../../../devices/platform/soc/824000.replicator/replicator0
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etf0 ->
> ../../../devices/platform/soc/825000.etf/tmc_etf0
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etr0 ->
> ../../../devices/platform/soc/826000.etr/tmc_etr0
> lrwxrwxrwx 1 root root 0 Apr 16 14:17 tpiu0 ->
> ../../../devices/platform/soc/820000.tpiu/tpiu
>
> Further topology can be determined using the connections sub-directory
> in each device:-
>
> ls -al /sys/bus/coresight/devices/etm0/connections/out\:0
> lrwxrwxrwx 1 root root 0 Apr 16 14:18
> /sys/bus/coresight/devices/etm0/connections/out:0 ->
> ../../../841000.funnel/funnel1
>
> Using this information it is possible to iterate across the entire
> topology of any coresight system.
>
Yes, these information can iterate across the entire topology of any
coresight
system. But it cannot quickly identify specific coresight devices across
targets.
e.g. If there are a lot of cti on one target, we need to identify the
cti by its
register address. The same function cti may has different register
address across
targets. This patch allow the same function coresight device has the
same name,
and it could be operated by scripts easily.
> 3) If there is some scripting requirement that cannot be solved with
> the information available above - then it would be better to add this
> name as an alias rather than a direct replacement.
> Therefore any coresight device could have an alias_name entry, that
> could be interrogated by a script and used as required. This avoids
> breaking any existing scripts using the established naming convention.
>
Agree with you. Can I use sysfs_create_link to create a kernel link
between
alias name and coresight device kobject? At the same time, the original
coresight device naming method remains unchanged. Thus, the existing
protocol
will not be broken.
Or is there any better suggeston on how to add alias name for coresight
device?
> 4) Any devicetree attribute should follow the <owner>,<attribute>
> naming convention. e.g. arm,some_attribute.
> I agree with Alex that it may not be normal practice to add in
> attributes in these circumstances - this does not appear to relate to
> a specific hardware feature or limitation. You may wish to discuss
> this with the device tree maintainers.
>
> Thanks and Regards
>
> Mike
Sure. I will update this according to your suggestion on patch v2.
Best.
Tao